| Message ID | 1444380548-17366-1-git-send-email-qipeng.zha@intel.com (mailing list archive) |
|---|---|
| State | Changes Requested, archived |
| Headers | show |
T24gRnJpLCAyMDE1LTEwLTA5IGF0IDE2OjQ5ICswODAwLCBRaXBlbmcgWmhhIHdyb3RlOg0KPiBU aGlzIGRyaXZlciBwcm92aWRlcyBzdXBwb3J0IGZvciBQLVVuaXQgbWFpbGJveCBJUEMgb24gSW50 ZWwgDQo+IHBsYXRmb3Jtcy4NCj4gVGhlIGhlYXJ0IG9mIHRoZSBQLVVuaXQgaXMgdGhlIEZveHRv biBtaWNyb2NvbnRyb2xsZXIgYW5kIGl0cyANCj4gZmlybXdhcmUsDQo+IHdoaWNoIHByb3ZpZGUg bWFpbGJveCBpbnRlcmZhY2UgZm9yIHBvd2VyIG1hbmFnZW1lbnQgdXNhZ2UuDQoNCkV2ZXJ5dGhp bmcgaXMgcXVpdGUgb2theSwgZXhjZXB0IHRoaXMgQkFSIHRoaW5neS4NCg0KQ2FuIHlvdSBwcm92 aWRlIGEgRFNEVCBleGNlcnB0IGZvciB0aGUgZGV2aWNlIHRvIHNlZSB3aGF0IGlzIHRoZXJlPw0K DQpJIGNhbid0IGZpbmQgc3VjaCBkZXZpY2UgKGJ5IEFDUEkgaWQpIGluIHRoZSB0YWJsZXMgb2Yg dGhlIGFjY2Vzc2libGUNCmhhcmR3YXJlIGluIG91ciBsYWIuDQoNCj4gDQo+IFNpZ25lZC1vZmYt Ynk6IFFpcGVuZyBaaGEgPHFpcGVuZy56aGFAaW50ZWwuY29tPg0KPiANCj4gLS0tDQo+IGNoYW5n ZSBpbiB2Nw0KPiAgVXBkYXRlIGlwY19lcnJfc3RyaW5nKCkncyByZXR1cm4gdHlwZSB0byAiY29u c3QgY2hhciAqIiBmcm9tICJjaGFyIA0KPiAqIjsNCj4gIEFkZCB0ZXJtaW5hdG9yIGluIGFjcGkg aWQgYXJyYXkuDQo+IA0KPiBjaGFuZ2UgaW4gdjYNCj4gIFVwZGF0ZSBoZWFkZXIgZmlsZTsNCj4g IFVwZGF0ZSBpbnRlcmZhY2Ugb2YgbG93bGV2ZWwgcmVnaXN0ZXIgYWNjZXNzOw0KPiAgUmVzdHJ1 Y3R1cmUgaW1wbGVtZW50YXRpb24gb2YgdHdvIGNvbW1hbmQgZnVuY3Rpb25zOw0KPiAgU2F2ZSBJ UEMgcHJpdmF0ZSBkYXRhIHBvaW50ZXIgdG8gcGRldidzIHByaXY7DQo+IA0KPiBjaGFuZ2UgaW4g djUNCj4gIEZpeCBjb21tZW5kIHN0eWxlIGluIGhlYWRlciBmaWxlOw0KPiAgUmVwbGFjZSBFSU5W QUwgd2l0aCBFTk9ERVYgaW4gc3R1YiBmdW5jdGlvbnM7DQo+ICBSZXBsYWNlIGlwY19lcnJfc291 cmNlcyBhcnJheSB3aXRoIGlwY19lcnJfc3RyaW5nIGZ1bmN0aW9uOw0KPiAgQ29ycmVjdCBjb21t ZW50czogImlmIGludmFsaWQiIC0+ICJpZiBub3QgdXNlZCI7DQo+ICBQcm9wYWdhdGUgcmV0dXJu IGVycm9yIG9mIGRldm1fcmVxdWVzdF9pcnEuDQo+IA0KPiBjaGFuZ2UgaW4gdjQNCj4gIEZpeCB0 d28gY29kZSBzdHlsZSBpc3N1ZXM6IG1ha2UgLyogYXMgYSB3aG9sZSBsaW5lIGFuZCByZXBsYWNl DQo+ICJyZXR1cm4gcmV0IiB3aXRoICJnb3RvIG91dCI7DQo+ICBSZXBsYWNlIC1FSU5WQUwgd2l0 aCAtRU5YSU8gZm9yIGZhaWx1cmVzIGR1ZSB0byByZXNvdXJjZS4NCj4gDQo+IGNoYW5nZSBpbiB2 Mw0KPiAgRml4IGNvbXBpbGUgaXNzdWUgaW4gaW50ZWxfcHVuaXRfaXBjLmgsIGl0IGhhcHBlbmVk IHdoZW4gYnVpbHQtaW4NCj4gYW5kIHRoZSBoZWFkZXIgZmlsZSBpcyBpbmNsdWRlZCBpbiBvdGhl ciBzb3VyY2UgZmlsZS4NCj4gDQo+IGNoYW5nZSBpbiB2Mg0KPiAgRml4IGlzc3VlcyBpbiBjb2Rl IHN0eWxlIGFuZCBjb21tZW50czsNCj4gIFJlbW92ZSAiZGVmYXVsdCB5IiBpbiBLY29uZmlnOw0K PiAgUmVtb3ZlIHNvbWUgaGVhZGVyIGZpbGVzOw0KPiAgUmVwbGFjZSByZXF1ZXN0X21lbV9yZWdp b24gd2l0aCBkZXZtX3JlcXVlc3RfbWVtX3JlZ2lvbiwNCj4gYW5kIHNhbWUgZm9yIHJlcXVlc3Rf aXJxOw0KPiAgQ2hhbmdlIHRvIHVzZSBwcmVmaXggb2YgSVBDX1BVTklUXyB0byBkZWZpbmUgY29t bWFuZHM7DQo+IC0tLQ0KPiAgTUFJTlRBSU5FUlMgICAgICAgICAgICAgICAgICAgICAgICAgICAg fCAgIDQgKy0NCj4gIGFyY2gveDg2L2luY2x1ZGUvYXNtL2ludGVsX3B1bml0X2lwYy5oIHwgMTAx ICsrKysrKysrKysNCj4gIGRyaXZlcnMvcGxhdGZvcm0veDg2L0tjb25maWcgICAgICAgICAgIHwg ICA2ICsNCj4gIGRyaXZlcnMvcGxhdGZvcm0veDg2L01ha2VmaWxlICAgICAgICAgIHwgICAxICsN Cj4gIGRyaXZlcnMvcGxhdGZvcm0veDg2L2ludGVsX3B1bml0X2lwYy5jIHwgMzM2IA0KPiArKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysNCj4gIDUgZmlsZXMgY2hhbmdlZCwgNDQ3IGlu c2VydGlvbnMoKyksIDEgZGVsZXRpb24oLSkNCj4gIGNyZWF0ZSBtb2RlIDEwMDY0NCBhcmNoL3g4 Ni9pbmNsdWRlL2FzbS9pbnRlbF9wdW5pdF9pcGMuaA0KPiAgY3JlYXRlIG1vZGUgMTAwNjQ0IGRy aXZlcnMvcGxhdGZvcm0veDg2L2ludGVsX3B1bml0X2lwYy5jDQo+IA0KPiBkaWZmIC0tZ2l0IGEv TUFJTlRBSU5FUlMgYi9NQUlOVEFJTkVSUw0KPiBpbmRleCAxM2FjODYxLi5jZjcxMzg3IDEwMDY0 NA0KPiAtLS0gYS9NQUlOVEFJTkVSUw0KPiArKysgYi9NQUlOVEFJTkVSUw0KPiBAQCAtNTIwNywx MiArNTIwNywxNCBAQCBGOglpbmNsdWRlL3VhcGkvbGludXgvbWVpLmgNCj4gIEY6CWRyaXZlcnMv bWlzYy9tZWkvKg0KPiAgRjoJRG9jdW1lbnRhdGlvbi9taXNjLWRldmljZXMvbWVpLyoNCj4gIA0K PiAtSU5URUwgUE1DIElQQyBEUklWRVINCj4gK0lOVEVMIFBNQy9QLVVuaXQgSVBDIERSSVZFUg0K PiAgTToJWmhhIFFpcGVuZzxxaXBlbmcuemhhQGludGVsLmNvbT4NCj4gIEw6CXBsYXRmb3JtLWRy aXZlci14ODZAdmdlci5rZXJuZWwub3JnDQo+ICBTOglNYWludGFpbmVkDQo+ICBGOglkcml2ZXJz L3BsYXRmb3JtL3g4Ni9pbnRlbF9wbWNfaXBjLmMNCj4gK0Y6CWRyaXZlcnMvcGxhdGZvcm0veDg2 L2ludGVsX3B1bml0X2lwYy5jDQo+ICBGOglhcmNoL3g4Ni9pbmNsdWRlL2FzbS9pbnRlbF9wbWNf aXBjLmgNCj4gK0Y6CWFyY2gveDg2L2luY2x1ZGUvYXNtL2ludGVsX3B1bml0X2lwYy5oDQo+ICAN Cj4gIElPQzMgRVRIRVJORVQgRFJJVkVSDQo+ICBNOglSYWxmIEJhZWNobGUgPHJhbGZAbGludXgt bWlwcy5vcmc+DQo+IGRpZmYgLS1naXQgYS9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9pbnRlbF9wdW5p dF9pcGMuaCANCj4gYi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9pbnRlbF9wdW5pdF9pcGMuaA0KPiBu ZXcgZmlsZSBtb2RlIDEwMDY0NA0KPiBpbmRleCAwMDAwMDAwLi4yMDFlYjlkDQo+IC0tLSAvZGV2 L251bGwNCj4gKysrIGIvYXJjaC94ODYvaW5jbHVkZS9hc20vaW50ZWxfcHVuaXRfaXBjLmgNCj4g QEAgLTAsMCArMSwxMDEgQEANCj4gKyNpZm5kZWYgX0FTTV9YODZfSU5URUxfUFVOSVRfSVBDX0hf DQo+ICsjZGVmaW5lICBfQVNNX1g4Nl9JTlRFTF9QVU5JVF9JUENfSF8NCj4gKw0KPiArLyoNCj4g KyAqIFRocmVlIHR5cGVzIG9mIDhiaXQgUC1Vbml0IElQQyBjb21tYW5kcyBhcmUgc3VwcG9ydGVk LA0KPiArICogYml0Wzc6Nl06IFswMF06IEJJT1M7IFswMV06IEdURDsgWzEwXTogSVNQRC4NCj4g KyAqLw0KPiArdHlwZWRlZiBlbnVtIHsNCj4gKwlCSU9TX0lQQyA9IDAsDQo+ICsJR1REUklWRVJf SVBDLA0KPiArCUlTUERSSVZFUl9JUEMsDQo+ICsJUkVTRVJWRURfSVBDLA0KPiArfSBJUENfVFlQ RTsNCj4gKw0KPiArI2RlZmluZSBJUENfVFlQRV9PRkZTRVQJCQk2DQo+ICsjZGVmaW5lIElQQ19Q VU5JVF9CSU9TX0NNRF9CQVNFCQkoQklPU19JUEMgPDwgDQo+IElQQ19UWVBFX09GRlNFVCkNCj4g KyNkZWZpbmUgSVBDX1BVTklUX0dURF9DTURfQkFTRQkJKEdURERSSVZFUl9JUEMgPDwgDQo+IElQ Q19UWVBFX09GRlNFVCkNCj4gKyNkZWZpbmUgSVBDX1BVTklUX0lTUERfQ01EX0JBU0UJCShJU1BE UklWRVJfSVBDIDw8IA0KPiBJUENfVFlQRV9PRkZTRVQpDQo+ICsjZGVmaW5lIElQQ19QVU5JVF9D TURfVFlQRV9NQVNLCQkoUkVTRVJWRURfSVBDIDw8IA0KPiBJUENfVFlQRV9PRkZTRVQpDQo+ICsN Cj4gKy8qIEJJT1MgPT4gUGNvZGUgY29tbWFuZHMgKi8NCj4gKyNkZWZpbmUgSVBDX1BVTklUX0JJ T1NfWkVSTwkJCShJUENfUFVOSVRfQklPU19DTURfDQo+IEJBU0UgfCAweDAwKQ0KPiArI2RlZmlu ZSBJUENfUFVOSVRfQklPU19WUl9JTlRFUkZBQ0UJCShJUENfUFVOSVRfQklPU19DTURfDQo+IEJB U0UgfCAweDAxKQ0KPiArI2RlZmluZSBJUENfUFVOSVRfQklPU19SRUFEX1BDUwkJCShJUENfUFVO SVRfQg0KPiBJT1NfQ01EX0JBU0UgfCAweDAyKQ0KPiArI2RlZmluZSBJUENfUFVOSVRfQklPU19X UklURV9QQ1MJCShJUENfUFVOSVRfQklPU19DTURfDQo+IEJBU0UgfCAweDAzKQ0KPiArI2RlZmlu ZSBJUENfUFVOSVRfQklPU19SRUFEX1BDVV9DT05GSUcJCShJUENfUFVOSVRfQklPU19DTURfDQo+ IEJBU0UgfCAweDA0KQ0KPiArI2RlZmluZSBJUENfUFVOSVRfQklPU19XUklURV9QQ1VfQ09ORklH CQkoSVBDX1BVTklUX0INCj4gSU9TX0NNRF9CQVNFIHwgMHgwNSkNCj4gKyNkZWZpbmUgSVBDX1BV TklUX0JJT1NfUkVBRF9QTDFfU0VUVElORwkJKElQQ19QVU5JVF9CDQo+IElPU19DTURfQkFTRSB8 IDB4MDYpDQo+ICsjZGVmaW5lIElQQ19QVU5JVF9CSU9TX1dSSVRFX1BMMV9TRVRUSU5HCShJUENf UFVOSVRfQklPU19DTURfDQo+IEJBU0UgfCAweDA3KQ0KPiArI2RlZmluZSBJUENfUFVOSVRfQklP U19UUklHR0VSX1ZERF9SQU0JCShJUENfUFVOSVRfQklPU19DTURfDQo+IEJBU0UgfCAweDA4KQ0K PiArI2RlZmluZSBJUENfUFVOSVRfQklPU19SRUFEX1RFTEVfSU5GTwkJKElQQ19QVU5JVF9CSU9T X0NNRF8NCj4gQkFTRSB8IDB4MDkpDQo+ICsjZGVmaW5lIElQQ19QVU5JVF9CSU9TX1JFQURfVEVM RV9UUkFDRV9DVFJMCShJUENfUFVOSVRfQklPU19DTURfDQo+IEJBU0UgfCAweDBhKQ0KPiArI2Rl ZmluZSBJUENfUFVOSVRfQklPU19XUklURV9URUxFX1RSQUNFX0NUUkwJKElQQ19QVU5JVF9CSU9T X0NNRF8NCj4gQkFTRSB8IDB4MGIpDQo+ICsjZGVmaW5lIElQQ19QVU5JVF9CSU9TX1JFQURfVEVM RV9FVkVOVF9DVFJMCShJUENfUFVOSVRfQklPU19DTURfDQo+IEJBU0UgfCAweDBjKQ0KPiArI2Rl ZmluZSBJUENfUFVOSVRfQklPU19XUklURV9URUxFX0VWRU5UX0NUUkwJKElQQ19QVU5JVF9CSU9T X0NNRF8NCj4gQkFTRSB8IDB4MGQpDQo+ICsjZGVmaW5lIElQQ19QVU5JVF9CSU9TX1JFQURfVEVM RV9UUkFDRQkJKElQQ19QVU5JVF9CSU9TX0NNRF8NCj4gQkFTRSB8IDB4MGUpDQo+ICsjZGVmaW5l IElQQ19QVU5JVF9CSU9TX1dSSVRFX1RFTEVfVFJBQ0UJCShJUENfUFVOSVRfQg0KPiBJT1NfQ01E X0JBU0UgfCAweDBmKQ0KPiArI2RlZmluZSBJUENfUFVOSVRfQklPU19SRUFEX1RFTEVfRVZFTlQJ CShJUENfUFVOSVRfQklPU19DTURfDQo+IEJBU0UgfCAweDEwKQ0KPiArI2RlZmluZSBJUENfUFVO SVRfQklPU19XUklURV9URUxFX0VWRU5UCQkoSVBDX1BVTklUX0INCj4gSU9TX0NNRF9CQVNFIHwg MHgxMSkNCj4gKyNkZWZpbmUgSVBDX1BVTklUX0JJT1NfUkVBRF9NT0RVTEVfVEVNUAkJKElQQ19Q VU5JVF9CDQo+IElPU19DTURfQkFTRSB8IDB4MTIpDQo+ICsjZGVmaW5lIElQQ19QVU5JVF9CSU9T X1JFU0VSVkVECQkJKElQQ19QVU5JVF9CDQo+IElPU19DTURfQkFTRSB8IDB4MTMpDQo+ICsjZGVm aW5lIElQQ19QVU5JVF9CSU9TX1JFQURfVk9MVEFHRV9PVkVSCShJUENfUFVOSVRfQklPU19DTURf DQo+IEJBU0UgfCAweDE0KQ0KPiArI2RlZmluZSBJUENfUFVOSVRfQklPU19XUklURV9WT0xUQUdF X09WRVIJKElQQ19QVU5JVF9CSU9TX0NNRF8NCj4gQkFTRSB8IDB4MTUpDQo+ICsjZGVmaW5lIElQ Q19QVU5JVF9CSU9TX1JFQURfUkFUSU9fT1ZFUgkJKElQQ19QVU5JVF9CSU9TX0NNRF8NCj4gQkFT RSB8IDB4MTYpDQo+ICsjZGVmaW5lIElQQ19QVU5JVF9CSU9TX1dSSVRFX1JBVElPX09WRVIJCShJ UENfUFVOSVRfQg0KPiBJT1NfQ01EX0JBU0UgfCAweDE3KQ0KPiArI2RlZmluZSBJUENfUFVOSVRf QklPU19SRUFEX1ZGX0dMX0NUUkwJCShJUENfUFVOSVRfQklPU19DTURfDQo+IEJBU0UgfCAweDE4 KQ0KPiArI2RlZmluZSBJUENfUFVOSVRfQklPU19XUklURV9WRl9HTF9DVFJMCQkoSVBDX1BVTklU X0INCj4gSU9TX0NNRF9CQVNFIHwgMHgxOSkNCj4gKyNkZWZpbmUgSVBDX1BVTklUX0JJT1NfUkVB RF9GTV9TT0NfVEVNUF9USFJFU0gJKElQQ19QVU5JVF9CSU9TX0NNRF8NCj4gQkFTRSB8IDB4MWEp DQo+ICsjZGVmaW5lIElQQ19QVU5JVF9CSU9TX1dSSVRFX0ZNX1NPQ19URU1QX1RIUkVTSAkoSVBD X1BVTklUX0INCj4gSU9TX0NNRF9CQVNFIHwgMHgxYikNCj4gKw0KPiArLyogR1QgRHJpdmVyID0+ IFBjb2RlIGNvbW1hbmRzICovDQo+ICsjZGVmaW5lIElQQ19QVU5JVF9HVERfWkVSTwkJCShJUENf UFVOSVRfR1REX0NNRF9CDQo+IEFTRSB8IDB4MDApDQo+ICsjZGVmaW5lIElQQ19QVU5JVF9HVERf Q09ORklHCQkJKElQQ19QVU5JVF9HVERfQ01EX0INCj4gQVNFIHwgMHgwMSkNCj4gKyNkZWZpbmUg SVBDX1BVTklUX0dURF9SRUFEX0lDQ1BfTElDX0NEWU5fU0NBTAkoSVBDX1BVTklUX0dURF9DTURf Qg0KPiBBU0UgfCAweDAyKQ0KPiArI2RlZmluZSBJUENfUFVOSVRfR1REX1dSSVRFX0lDQ1BfTElD X0NEWU5fU0NBTAkoSVBDX1BVTklUX0dURF9DTURfQg0KPiBBU0UgfCAweDAzKQ0KPiArI2RlZmlu ZSBJUENfUFVOSVRfR1REX0dFVF9XTV9WQUwJCShJUENfUFVOSVRfR1REX0NNRF9CDQo+IEFTRSB8 IDB4MDYpDQo+ICsjZGVmaW5lIElQQ19QVU5JVF9HVERfV1JJVEVfQ09ORklHX1dJU0hSRVEJKElQ Q19QVU5JVF9HVERfQ01EX0INCj4gQVNFIHwgMHgwNykNCj4gKyNkZWZpbmUgSVBDX1BVTklUX0dU RF9SRUFEX1JFUV9EVVRZX0NZQ0xFCShJUENfUFVOSVRfR1REX0NNRF9CDQo+IEFTRSB8IDB4MTYp DQo+ICsjZGVmaW5lIElQQ19QVU5JVF9HVERfRElTX1ZPTF9GUkVRX0NIR19SRVFVRVNUCShJUENf UFVOSVRfR1REX0NNRF9CDQo+IEFTRSB8IDB4MTcpDQo+ICsjZGVmaW5lIElQQ19QVU5JVF9HVERf RFlOQV9EVVRZX0NZQ0xFX0NUUkwJKElQQ19QVU5JVF9HVERfQ01EX0INCj4gQVNFIHwgMHgxYSkN Cj4gKyNkZWZpbmUgSVBDX1BVTklUX0dURF9EWU5BX0RVVFlfQ1lDTEVfVFVOSU5HCShJUENfUFVO SVRfR1REX0NNRF9CDQo+IEFTRSB8IDB4MWMpDQo+ICsNCj4gKy8qIElTUCBEcml2ZXIgPT4gUGNv ZGUgY29tbWFuZHMgKi8NCj4gKyNkZWZpbmUgSVBDX1BVTklUX0lTUERfWkVSTwkJCShJUENfUFVO SVRfSVNQRF9DTURfDQo+IEJBU0UgfCAweDAwKQ0KPiArI2RlZmluZSBJUENfUFVOSVRfSVNQRF9D T05GSUcJCQkoSVBDX1BVTklUX0lTUERfQ01EXw0KPiBCQVNFIHwgMHgwMSkNCj4gKyNkZWZpbmUg SVBDX1BVTklUX0lTUERfR0VUX0lTUF9MVFJfVkFMCQkoSVBDX1BVTklUX0lTUERfQ01EXw0KPiBC QVNFIHwgMHgwMikNCj4gKyNkZWZpbmUgSVBDX1BVTklUX0lTUERfQUNDRVNTX0lVX0ZSRVFfQk9V TkRTCShJUENfUFVOSVRfSVNQRF9DTURfDQo+IEJBU0UgfCAweDAzKQ0KPiArI2RlZmluZSBJUENf UFVOSVRfSVNQRF9SRUFEX0NEWU5fTEVWRUwJCShJUENfUFVOSVRfSVNQRF9DTURfDQo+IEJBU0Ug fCAweDA0KQ0KPiArI2RlZmluZSBJUENfUFVOSVRfSVNQRF9XUklURV9DRFlOX0xFVkVMCQkoSVBD X1BVTklUX0kNCj4gU1BEX0NNRF9CQVNFIHwgMHgwNSkNCj4gKw0KPiArLyogRXJyb3IgY29kZXMg Ki8NCj4gKyNkZWZpbmUgSVBDX1BVTklUX0VSUl9TVUNDRVNTCQkJMA0KPiArI2RlZmluZSBJUENf UFVOSVRfRVJSX0lOVkFMSURfQ01ECQkxDQo+ICsjZGVmaW5lIElQQ19QVU5JVF9FUlJfSU5WQUxJ RF9QQVJBTUVURVIJCTINCj4gKyNkZWZpbmUgSVBDX1BVTklUX0VSUl9DTURfVElNRU9VVAkJMw0K PiArI2RlZmluZSBJUENfUFVOSVRfRVJSX0NNRF9MT0NLRUQJCTQNCj4gKyNkZWZpbmUgSVBDX1BV TklUX0VSUl9JTlZBTElEX1ZSX0lECQk1DQo+ICsjZGVmaW5lIElQQ19QVU5JVF9FUlJfVlJfRVJS CQkJNg0KPiArDQo+ICsjaWYgSVNfRU5BQkxFRChDT05GSUdfSU5URUxfUFVOSVRfSVBDKQ0KPiAr DQo+ICtpbnQgaW50ZWxfcHVuaXRfaXBjX3NpbXBsZV9jb21tYW5kKGludCBjbWQsIGludCBwYXJh MSwgaW50IHBhcmEyKTsNCj4gK2ludCBpbnRlbF9wdW5pdF9pcGNfY29tbWFuZCh1MzIgY21kLCB1 MzIgcGFyYTEsIHUzMiBwYXJhMiwgdTMyICppbiwgDQo+IHUzMiAqb3V0KTsNCj4gKw0KPiArI2Vs c2UNCj4gKw0KPiArc3RhdGljIGlubGluZSBpbnQgaW50ZWxfcHVuaXRfaXBjX3NpbXBsZV9jb21t YW5kKGludCBjbWQsDQo+ICsJCQkJCQkgIGludCBwYXJhMSwgaW50IA0KPiBwYXJhMikNCj4gK3sN Cj4gKwlyZXR1cm4gLUVOT0RFVjsNCj4gK30NCj4gKw0KPiArc3RhdGljIGlubGluZSBpbnQgaW50 ZWxfcHVuaXRfaXBjX2NvbW1hbmQodTMyIGNtZCwgdTMyIHBhcmExLCB1MzIgDQo+IHBhcmEyLA0K PiArCQkJCQkgIHUzMiAqaW4sIHUzMiAqb3V0KQ0KPiArew0KPiArCXJldHVybiAtRU5PREVWOw0K PiArfQ0KPiArDQo+ICsjZW5kaWYgLyogQ09ORklHX0lOVEVMX1BVTklUX0lQQyAqLw0KPiArDQo+ ICsjZW5kaWYNCj4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvcGxhdGZvcm0veDg2L0tjb25maWcgDQo+ IGIvZHJpdmVycy9wbGF0Zm9ybS94ODYvS2NvbmZpZw0KPiBpbmRleCAzNDZmMWZkLi45OTQ4MzY5 IDEwMDY0NA0KPiAtLS0gYS9kcml2ZXJzL3BsYXRmb3JtL3g4Ni9LY29uZmlnDQo+ICsrKyBiL2Ry aXZlcnMvcGxhdGZvcm0veDg2L0tjb25maWcNCj4gQEAgLTg5MSw0ICs4OTEsMTAgQEAgY29uZmln IElOVEVMX1BNQ19JUEMNCj4gIAlUaGUgUE1DIGlzIGFuIEFSQyBwcm9jZXNzb3Igd2hpY2ggZGVm aW5lcyBJUEMgY29tbWFuZHMgZm9yIA0KPiBjb21tdW5pY2F0aW9uDQo+ICAJd2l0aCBvdGhlciBl bnRpdGllcyBpbiB0aGUgQ1BVLg0KPiAgDQo+ICtjb25maWcgSU5URUxfUFVOSVRfSVBDDQo+ICsJ dHJpc3RhdGUgIkludGVsIFAtVW5pdCBJUEMgRHJpdmVyIg0KPiArCS0tLWhlbHAtLS0NCj4gKwkg IFRoaXMgZHJpdmVyIHByb3ZpZGVzIHN1cHBvcnQgZm9yIEludGVsIFAtVW5pdCBNYWlsYm94IElQ QyANCj4gbWVjaGFuaXNtLA0KPiArCSAgd2hpY2ggaXMgdXNlZCB0byBicmlkZ2UgdGhlIGNvbW11 bmljYXRpb25zIGJldHdlZW4ga2VybmVsIA0KPiBhbmQgUC1Vbml0Lg0KPiArDQo+ICBlbmRpZiAj IFg4Nl9QTEFURk9STV9ERVZJQ0VTDQo+IGRpZmYgLS1naXQgYS9kcml2ZXJzL3BsYXRmb3JtL3g4 Ni9NYWtlZmlsZSANCj4gYi9kcml2ZXJzL3BsYXRmb3JtL3g4Ni9NYWtlZmlsZQ0KPiBpbmRleCAx MDUxMzcyLi5lZWE3NjVmIDEwMDY0NA0KPiAtLS0gYS9kcml2ZXJzL3BsYXRmb3JtL3g4Ni9NYWtl ZmlsZQ0KPiArKysgYi9kcml2ZXJzL3BsYXRmb3JtL3g4Ni9NYWtlZmlsZQ0KPiBAQCAtNTksMyAr NTksNCBAQCBvYmotJChDT05GSUdfSU5URUxfU01BUlRDT05ORUNUKQkrPSBpbnRlbA0KPiAtc21h cnRjb25uZWN0Lm8NCj4gIG9iai0kKENPTkZJR19QVlBBTklDKSAgICAgICAgICAgKz0gcHZwYW5p Yy5vDQo+ICBvYmotJChDT05GSUdfQUxJRU5XQVJFX1dNSSkJKz0gYWxpZW53YXJlLXdtaS5vDQo+ ICBvYmotJChDT05GSUdfSU5URUxfUE1DX0lQQykJKz0gaW50ZWxfcG1jX2lwYy5vDQo+ICtvYmot JChDT05GSUdfSU5URUxfUFVOSVRfSVBDKQkrPSBpbnRlbF9wdW5pdF9pcGMubw0KPiBkaWZmIC0t Z2l0IGEvZHJpdmVycy9wbGF0Zm9ybS94ODYvaW50ZWxfcHVuaXRfaXBjLmMgDQo+IGIvZHJpdmVy cy9wbGF0Zm9ybS94ODYvaW50ZWxfcHVuaXRfaXBjLmMNCj4gbmV3IGZpbGUgbW9kZSAxMDA2NDQN Cj4gaW5kZXggMDAwMDAwMC4uYzc4YWI1Nw0KPiAtLS0gL2Rldi9udWxsDQo+ICsrKyBiL2RyaXZl cnMvcGxhdGZvcm0veDg2L2ludGVsX3B1bml0X2lwYy5jDQo+IEBAIC0wLDAgKzEsMzM2IEBADQo+ ICsvKg0KPiArICogRHJpdmVyIGZvciB0aGUgSW50ZWwgUC1Vbml0IE1haWxib3ggSVBDIG1lY2hh bmlzbQ0KPiArICoNCj4gKyAqIChDKSBDb3B5cmlnaHQgMjAxNSBJbnRlbCBDb3Jwb3JhdGlvbg0K PiArICoNCj4gKyAqIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlz dHJpYnV0ZSBpdCBhbmQvb3IgDQo+IG1vZGlmeQ0KPiArICogaXQgdW5kZXIgdGhlIHRlcm1zIG9m IHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSB2ZXJzaW9uIDIgYXMNCj4gKyAqIHB1Ymxp c2hlZCBieSB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLg0KPiArICoNCj4gKyAqIFRoZSBo ZWFydCBvZiB0aGUgUC1Vbml0IGlzIHRoZSBGb3h0b24gbWljcm9jb250cm9sbGVyIGFuZCBpdHMg DQo+IGZpcm13YXJlLA0KPiArICogd2hpY2ggcHJvdmlkZSBtYWlsYm94IGludGVyZmFjZSBmb3Ig cG93ZXIgbWFuYWdlbWVudCB1c2FnZS4NCj4gKyAqLw0KPiArDQo+ICsjaW5jbHVkZSA8bGludXgv bW9kdWxlLmg+DQo+ICsjaW5jbHVkZSA8bGludXgvYWNwaS5oPg0KPiArI2luY2x1ZGUgPGxpbnV4 L2RlbGF5Lmg+DQo+ICsjaW5jbHVkZSA8bGludXgvZGV2aWNlLmg+DQo+ICsjaW5jbHVkZSA8bGlu dXgvaW50ZXJydXB0Lmg+DQo+ICsjaW5jbHVkZSA8bGludXgvcGxhdGZvcm1fZGV2aWNlLmg+DQo+ ICsjaW5jbHVkZSA8YXNtL2ludGVsX3B1bml0X2lwYy5oPg0KPiArDQo+ICsvKiBJUEMgTWFpbGJv eCByZWdpc3RlcnMgKi8NCj4gKyNkZWZpbmUgREFUQV9MT1cJCTB4MA0KPiArI2RlZmluZSBJTlRF UkZBQ0UJCTB4NA0KPiArI2RlZmluZQkJQ01EX1JVTgkJCSgxIDw8IDMxKQ0KPiArI2RlZmluZQkJ Q01EX0VSUkNPREVfTUFTSwkweEZGDQo+ICsjZGVmaW5lCQlDTURfUEFSQTFfU0hJRlQJCTgNCj4g KyNkZWZpbmUJCUNNRF9QQVJBMl9TSElGVAkJMTYNCj4gKyNkZWZpbmUgREFUQV9ISUdICQkweDgN Cj4gKw0KPiArI2RlZmluZSBNQUlMQk9YX1JFR0lTVEVSX1NQQUNFCQkweDEwDQo+ICsjZGVmaW5l IENNRF9USU1FT1VUX1NFQ09ORFMJCTENCj4gKw0KPiArdHlwZWRlZiBzdHJ1Y3Qgew0KPiArCXN0 cnVjdCBkZXZpY2UgKmRldjsNCj4gKwlzdHJ1Y3QgbXV0ZXggbG9jazsNCj4gKwlpbnQgaXJxOw0K PiArCXN0cnVjdCBjb21wbGV0aW9uIGNtZF9jb21wbGV0ZTsNCj4gKwl2b2lkIF9faW9tZW0gKmJh c2VbUkVTRVJWRURfSVBDXTsNCj4gKwlJUENfVFlQRSB0eXBlOw0KPiArfSBJUENfREVWOw0KPiAr DQo+ICtzdGF0aWMgSVBDX0RFViAqcHVuaXRfaXBjZGV2Ow0KPiArDQo+ICtzdGF0aWMgaW5saW5l IHUzMiBpcGNfcmVhZF9zdGF0dXMoSVBDX0RFViAqaXBjZGV2LCBJUENfVFlQRSB0eXBlKQ0KPiAr ew0KPiArCXJldHVybiByZWFkbChpcGNkZXYtPmJhc2VbdHlwZV0gKyBJTlRFUkZBQ0UpOw0KPiAr fQ0KPiArDQo+ICtzdGF0aWMgaW5saW5lIHZvaWQgaXBjX3dyaXRlX2NtZChJUENfREVWICppcGNk ZXYsIElQQ19UWVBFIHR5cGUsIHUzMiANCj4gY21kKQ0KPiArew0KPiArCXdyaXRlbChjbWQsIGlw Y2Rldi0+YmFzZVt0eXBlXSArIElOVEVSRkFDRSk7DQo+ICt9DQo+ICsNCj4gK3N0YXRpYyBpbmxp bmUgdTMyIGlwY19yZWFkX2RhdGFfbG93KElQQ19ERVYgKmlwY2RldiwgSVBDX1RZUEUgdHlwZSkN Cj4gK3sNCj4gKwlyZXR1cm4gcmVhZGwoaXBjZGV2LT5iYXNlW3R5cGVdICsgREFUQV9MT1cpOw0K PiArfQ0KPiArDQo+ICtzdGF0aWMgaW5saW5lIHUzMiBpcGNfcmVhZF9kYXRhX2hpZ2goSVBDX0RF ViAqaXBjZGV2LCBJUENfVFlQRSB0eXBlKQ0KPiArew0KPiArCXJldHVybiByZWFkbChpcGNkZXYt PmJhc2VbdHlwZV0gKyBEQVRBX0hJR0gpOw0KPiArfQ0KPiArDQo+ICtzdGF0aWMgaW5saW5lIHZv aWQgaXBjX3dyaXRlX2RhdGFfbG93KElQQ19ERVYgKmlwY2RldiwgSVBDX1RZUEUgDQo+IHR5cGUs IHUzMiBkYXRhKQ0KPiArew0KPiArCXdyaXRlbChkYXRhLCBpcGNkZXYtPmJhc2VbdHlwZV0gKyBE QVRBX0xPVyk7DQo+ICt9DQo+ICsNCj4gK3N0YXRpYyBpbmxpbmUgdm9pZCBpcGNfd3JpdGVfZGF0 YV9oaWdoKElQQ19ERVYgKmlwY2RldiwgSVBDX1RZUEUgDQo+IHR5cGUsIHUzMiBkYXRhKQ0KPiAr ew0KPiArCXdyaXRlbChkYXRhLCBpcGNkZXYtPmJhc2VbdHlwZV0gKyBEQVRBX0hJR0gpOw0KPiAr fQ0KPiArDQo+ICtzdGF0aWMgY29uc3QgY2hhciAqaXBjX2Vycl9zdHJpbmcoaW50IGVycm9yKQ0K PiArew0KPiArCWlmIChlcnJvciA9PSBJUENfUFVOSVRfRVJSX1NVQ0NFU1MpDQo+ICsJCXJldHVy biAibm8gZXJyb3IiOw0KPiArCWVsc2UgaWYgKGVycm9yID09IElQQ19QVU5JVF9FUlJfSU5WQUxJ RF9DTUQpDQo+ICsJCXJldHVybiAiaW52YWxpZCBjb21tYW5kIjsNCj4gKwllbHNlIGlmIChlcnJv ciA9PSBJUENfUFVOSVRfRVJSX0lOVkFMSURfUEFSQU1FVEVSKQ0KPiArCQlyZXR1cm4gImludmFs aWQgcGFyYW1ldGVyIjsNCj4gKwllbHNlIGlmIChlcnJvciA9PSBJUENfUFVOSVRfRVJSX0NNRF9U SU1FT1VUKQ0KPiArCQlyZXR1cm4gImNvbW1hbmQgdGltZW91dCI7DQo+ICsJZWxzZSBpZiAoZXJy b3IgPT0gSVBDX1BVTklUX0VSUl9DTURfTE9DS0VEKQ0KPiArCQlyZXR1cm4gImNvbW1hbmQgbG9j a2VkIjsNCj4gKwllbHNlIGlmIChlcnJvciA9PSBJUENfUFVOSVRfRVJSX0lOVkFMSURfVlJfSUQp DQo+ICsJCXJldHVybiAiaW52YWxpZCB2ciBpZCI7DQo+ICsJZWxzZSBpZiAoZXJyb3IgPT0gSVBD X1BVTklUX0VSUl9WUl9FUlIpDQo+ICsJCXJldHVybiAidnIgZXJyb3IiOw0KPiArCWVsc2UNCj4g KwkJcmV0dXJuICJ1bmtub3duIGVycm9yIjsNCj4gK30NCj4gKw0KPiArc3RhdGljIGludCBpbnRl bF9wdW5pdF9pcGNfY2hlY2tfc3RhdHVzKElQQ19ERVYgKmlwY2RldiwgSVBDX1RZUEUgDQo+IHR5 cGUpDQo+ICt7DQo+ICsJaW50IGxvb3BzID0gQ01EX1RJTUVPVVRfU0VDT05EUyAqIFVTRUNfUEVS X1NFQzsNCj4gKwlpbnQgZXJyY29kZTsNCj4gKwlpbnQgc3RhdHVzOw0KPiArDQo+ICsJaWYgKGlw Y2Rldi0+aXJxKSB7DQo+ICsJCWlmICghd2FpdF9mb3JfY29tcGxldGlvbl90aW1lb3V0KCZpcGNk ZXYNCj4gLT5jbWRfY29tcGxldGUsDQo+ICsJCQkJCQkgQ01EX1RJTUVPVVRfU0VDT05EUyANCj4g KiBIWikpIHsNCj4gKwkJCWRldl9lcnIoaXBjZGV2LT5kZXYsICJJUEMgdGltZWQgb3V0XG4iKTsN Cj4gKwkJCXJldHVybiAtRVRJTUVET1VUOw0KPiArCQl9DQo+ICsJfSBlbHNlIHsNCj4gKwkJd2hp bGUgKChpcGNfcmVhZF9zdGF0dXMoaXBjZGV2LCB0eXBlKSAmIENNRF9SVU4pICYmIA0KPiAtLWxv b3BzKQ0KPiArCQkJdWRlbGF5KDEpOw0KPiArCQlpZiAoIWxvb3BzKSB7DQo+ICsJCQlkZXZfZXJy KGlwY2Rldi0+ZGV2LCAiSVBDIHRpbWVkIG91dFxuIik7DQo+ICsJCQlyZXR1cm4gLUVUSU1FRE9V VDsNCj4gKwkJfQ0KPiArCX0NCj4gKw0KPiArCXN0YXR1cyA9IGlwY19yZWFkX3N0YXR1cyhpcGNk ZXYsIHR5cGUpOw0KPiArCWVycmNvZGUgPSBzdGF0dXMgJiBDTURfRVJSQ09ERV9NQVNLOw0KPiAr CWlmIChlcnJjb2RlKSB7DQo+ICsJCWRldl9lcnIoaXBjZGV2LT5kZXYsICJJUEMgZmFpbGVkOiAl cywgDQo+IElQQ19TVFM9MHgleFxuIiwNCj4gKwkJCWlwY19lcnJfc3RyaW5nKGVycmNvZGUpLCBz dGF0dXMpOw0KPiArCQlyZXR1cm4gLUVJTzsNCj4gKwl9DQo+ICsNCj4gKwlyZXR1cm4gMDsNCj4g K30NCj4gKw0KPiArLyoqDQo+ICsgKiBpbnRlbF9wdW5pdF9pcGNfc2ltcGxlX2NvbW1hbmQoKSAt IFNpbXBsZSBJUEMgY29tbWFuZA0KPiArICogQGNtZDoJSVBDIGNvbW1hbmQgY29kZS4NCj4gKyAq IEBwYXJhMToJRmlyc3QgOGJpdCBwYXJhbWV0ZXIsIHNldCAwIGlmIG5vdCB1c2VkLg0KPiArICog QHBhcmEyOglTZWNvbmQgOGJpdCBwYXJhbWV0ZXIsIHNldCAwIGlmIG5vdCB1c2VkLg0KPiArICoN Cj4gKyAqIFNlbmQgYSBJUEMgY29tbWFuZCB0byBQLVVuaXQgd2hlbiB0aGVyZSBpcyBubyBkYXRh IHRyYW5zYWN0aW9uDQo+ICsgKg0KPiArICogUmV0dXJuOglJUEMgZXJyb3IgY29kZSBvciAwIG9u IHN1Y2Nlc3MuDQo+ICsgKi8NCj4gK2ludCBpbnRlbF9wdW5pdF9pcGNfc2ltcGxlX2NvbW1hbmQo aW50IGNtZCwgaW50IHBhcmExLCBpbnQgcGFyYTIpDQo+ICt7DQo+ICsJSVBDX0RFViAqaXBjZGV2 ID0gcHVuaXRfaXBjZGV2Ow0KPiArCUlQQ19UWVBFIHR5cGU7DQo+ICsJdTMyIHZhbDsNCj4gKwlp bnQgcmV0Ow0KPiArDQo+ICsJbXV0ZXhfbG9jaygmaXBjZGV2LT5sb2NrKTsNCj4gKw0KPiArCXJl aW5pdF9jb21wbGV0aW9uKCZpcGNkZXYtPmNtZF9jb21wbGV0ZSk7DQo+ICsJdHlwZSA9IChjbWQg JiBJUENfUFVOSVRfQ01EX1RZUEVfTUFTSykgPj4gSVBDX1RZUEVfT0ZGU0VUOw0KPiArDQo+ICsJ dmFsID0gY21kICYgfklQQ19QVU5JVF9DTURfVFlQRV9NQVNLOw0KPiArCXZhbCB8PSBDTURfUlVO IHwgcGFyYTIgPDwgQ01EX1BBUkEyX1NISUZUIHwgcGFyYTEgPDwgDQo+IENNRF9QQVJBMV9TSElG VDsNCj4gKwlpcGNfd3JpdGVfY21kKGlwY2RldiwgdHlwZSwgdmFsKTsNCj4gKwlyZXQgPSBpbnRl bF9wdW5pdF9pcGNfY2hlY2tfc3RhdHVzKGlwY2RldiwgdHlwZSk7DQo+ICsNCj4gKwltdXRleF91 bmxvY2soJmlwY2Rldi0+bG9jayk7DQo+ICsNCj4gKwlyZXR1cm4gcmV0Ow0KPiArfQ0KPiArRVhQ T1JUX1NZTUJPTChpbnRlbF9wdW5pdF9pcGNfc2ltcGxlX2NvbW1hbmQpOw0KPiArDQo+ICsvKioN Cj4gKyAqIGludGVsX3B1bml0X2lwY19jb21tYW5kKCkgLSBJUEMgY29tbWFuZCB3aXRoIGRhdGEg YW5kIHBvaW50ZXJzDQo+ICsgKiBAY21kOglJUEMgY29tbWFuZCBjb2RlLg0KPiArICogQHBhcmEx OglGaXJzdCA4Yml0IHBhcmFtZXRlciwgc2V0IDAgaWYgbm90IHVzZWQuDQo+ICsgKiBAcGFyYTI6 CVNlY29uZCA4Yml0IHBhcmFtZXRlciwgc2V0IDAgaWYgbm90IHVzZWQuDQo+ICsgKiBAaW46CQlJ bnB1dCBkYXRhLCAzMmJpdCBmb3IgQklPUyBjbWQsIHR3byAzMmJpdCANCj4gZm9yIEdURCBhbmQg SVNQRC4NCj4gKyAqIEBvdXQ6CU91dHB1dCBkYXRhLg0KPiArICoNCj4gKyAqIFNlbmQgYSBJUEMg Y29tbWFuZCB0byBQLVVuaXQgd2l0aCBkYXRhIHRyYW5zYWN0aW9uDQo+ICsgKg0KPiArICogUmV0 dXJuOglJUEMgZXJyb3IgY29kZSBvciAwIG9uIHN1Y2Nlc3MuDQo+ICsgKi8NCj4gK2ludCBpbnRl bF9wdW5pdF9pcGNfY29tbWFuZCh1MzIgY21kLCB1MzIgcGFyYTEsIHUzMiBwYXJhMiwgdTMyICpp biwgDQo+IHUzMiAqb3V0KQ0KPiArew0KPiArCUlQQ19ERVYgKmlwY2RldiA9IHB1bml0X2lwY2Rl djsNCj4gKwlJUENfVFlQRSB0eXBlOw0KPiArCXUzMiB2YWw7DQo+ICsJaW50IHJldDsNCj4gKw0K PiArCW11dGV4X2xvY2soJmlwY2Rldi0+bG9jayk7DQo+ICsNCj4gKwlyZWluaXRfY29tcGxldGlv bigmaXBjZGV2LT5jbWRfY29tcGxldGUpOw0KPiArCXR5cGUgPSAoY21kICYgSVBDX1BVTklUX0NN RF9UWVBFX01BU0spID4+IElQQ19UWVBFX09GRlNFVDsNCj4gKwlpcGNfd3JpdGVfZGF0YV9sb3co aXBjZGV2LCB0eXBlLCAqaW4pOw0KPiArDQo+ICsJaWYgKHR5cGUgPT0gR1REUklWRVJfSVBDIHx8 IHR5cGUgPT0gSVNQRFJJVkVSX0lQQykNCj4gKwkJaXBjX3dyaXRlX2RhdGFfaGlnaChpcGNkZXYs IHR5cGUsICorK2luKTsNCj4gKw0KPiArCXZhbCA9IGNtZCAmIH5JUENfUFVOSVRfQ01EX1RZUEVf TUFTSzsNCj4gKwl2YWwgfD0gQ01EX1JVTiB8IHBhcmEyIDw8IENNRF9QQVJBMl9TSElGVCB8IHBh cmExIDw8IA0KPiBDTURfUEFSQTFfU0hJRlQ7DQo+ICsJaXBjX3dyaXRlX2NtZChpcGNkZXYsIHR5 cGUsIHZhbCk7DQo+ICsNCj4gKwlyZXQgPSBpbnRlbF9wdW5pdF9pcGNfY2hlY2tfc3RhdHVzKGlw Y2RldiwgdHlwZSk7DQo+ICsJaWYgKHJldCkNCj4gKwkJZ290byBvdXQ7DQo+ICsJKm91dCA9IGlw Y19yZWFkX2RhdGFfbG93KGlwY2RldiwgdHlwZSk7DQo+ICsNCj4gKwlpZiAodHlwZSA9PSBHVERS SVZFUl9JUEMgfHwgdHlwZSA9PSBJU1BEUklWRVJfSVBDKQ0KPiArCQkqKytvdXQgPSBpcGNfcmVh ZF9kYXRhX2hpZ2goaXBjZGV2LCB0eXBlKTsNCj4gKw0KPiArb3V0Og0KPiArCW11dGV4X3VubG9j aygmaXBjZGV2LT5sb2NrKTsNCj4gKwlyZXR1cm4gcmV0Ow0KPiArfQ0KPiArRVhQT1JUX1NZTUJP TF9HUEwoaW50ZWxfcHVuaXRfaXBjX2NvbW1hbmQpOw0KPiArDQo+ICtzdGF0aWMgaXJxcmV0dXJu X3QgaW50ZWxfcHVuaXRfaW9jKGludCBpcnEsIHZvaWQgKmRldl9pZCkNCj4gK3sNCj4gKwlJUENf REVWICppcGNkZXYgPSAoSVBDX0RFViAqKWRldl9pZDsNCj4gKw0KPiArCWNvbXBsZXRlKCZpcGNk ZXYtPmNtZF9jb21wbGV0ZSk7DQo+ICsJcmV0dXJuIElSUV9IQU5ETEVEOw0KPiArfQ0KPiArDQo+ ICtzdGF0aWMgaW50IGludGVsX3B1bml0X2dldF9iYXJzKHN0cnVjdCBwbGF0Zm9ybV9kZXZpY2Ug KnBkZXYpDQo+ICt7DQo+ICsJc3RydWN0IHJlc291cmNlICpyZXMwLCAqcmVzMTsNCj4gKwl2b2lk IF9faW9tZW0gKmFkZHI7DQo+ICsJaW50IHNpemU7DQo+ICsNCj4gKwlyZXMwID0gcGxhdGZvcm1f Z2V0X3Jlc291cmNlKHBkZXYsIElPUkVTT1VSQ0VfTUVNLCAwKTsNCj4gKwlpZiAoIXJlczApIHsN Cj4gKwkJZGV2X2VycigmcGRldi0+ZGV2LCAiRmFpbGVkIHRvIGdldCBpb21lbSANCj4gcmVzb3Vy Y2VcbiIpOw0KPiArCQlyZXR1cm4gLUVOWElPOw0KPiArCX0NCj4gKwlzaXplID0gcmVzb3VyY2Vf c2l6ZShyZXMwKTsNCj4gKwlpZiAoIWRldm1fcmVxdWVzdF9tZW1fcmVnaW9uKCZwZGV2LT5kZXYs IHJlczAtPnN0YXJ0LA0KPiArCQkJCSAgICAgc2l6ZSwgcGRldi0+bmFtZSkpIHsNCj4gKwkJZGV2 X2VycigmcGRldi0+ZGV2LCAiRmFpbGVkIHRvIHJlcXVlc3QgaW9tZW0gDQo+IHJlc291Y2VcbiIp Ow0KPiArCQlyZXR1cm4gLUVCVVNZOw0KPiArCX0NCj4gKw0KPiArCXJlczEgPSBwbGF0Zm9ybV9n ZXRfcmVzb3VyY2UocGRldiwgSU9SRVNPVVJDRV9NRU0sIDEpOw0KPiArCWlmICghcmVzMSkgew0K PiArCQlkZXZfZXJyKCZwZGV2LT5kZXYsICJGYWlsZWQgdG8gZ2V0IGlvbWVtIA0KPiByZXNvdXJj ZTFcbiIpOw0KPiArCQlyZXR1cm4gLUVOWElPOw0KPiArCX0NCj4gKwlzaXplID0gcmVzb3VyY2Vf c2l6ZShyZXMxKTsNCj4gKwlpZiAoIWRldm1fcmVxdWVzdF9tZW1fcmVnaW9uKCZwZGV2LT5kZXYs IHJlczEtPnN0YXJ0LA0KPiArCQkJCSAgICAgc2l6ZSwgcGRldi0+bmFtZSkpIHsNCj4gKwkJZGV2 X2VycigmcGRldi0+ZGV2LCAiRmFpbGVkIHRvIHJlcXVlc3QgaW9tZW0gDQo+IHJlc291Y2UxXG4i KTsNCj4gKwkJcmV0dXJuIC1FQlVTWTsNCj4gKwl9DQo+ICsNCj4gKwlhZGRyID0gaW9yZW1hcF9u b2NhY2hlKHJlczAtPnN0YXJ0LA0KPiArCQkJICAgICAgIHJlc291cmNlX3NpemUocmVzMCkgKyAN Cj4gcmVzb3VyY2Vfc2l6ZShyZXMxKSk7DQo+ICsJaWYgKCFhZGRyKSB7DQo+ICsJCWRldl9lcnIo JnBkZXYtPmRldiwgIkZhaWxlZCB0byBpb3JlbWFwIGlwYyBiYXNlXG4iKTsNCj4gKwkJcmV0dXJu ICAtRU5PTUVNOw0KPiArCX0NCj4gKwlwdW5pdF9pcGNkZXYtPmJhc2VbQklPU19JUENdID0gYWRk cjsNCj4gKwlhZGRyICs9IE1BSUxCT1hfUkVHSVNURVJfU1BBQ0U7DQo+ICsJcHVuaXRfaXBjZGV2 LT5iYXNlW0dURFJJVkVSX0lQQ10gPSBhZGRyOw0KPiArCWFkZHIgKz0gTUFJTEJPWF9SRUdJU1RF Ul9TUEFDRTsNCj4gKwlwdW5pdF9pcGNkZXYtPmJhc2VbSVNQRFJJVkVSX0lQQ10gPSBhZGRyOw0K PiArDQo+ICsJcmV0dXJuIDA7DQo+ICt9DQo+ICsNCj4gK3N0YXRpYyBpbnQgaW50ZWxfcHVuaXRf aXBjX3Byb2JlKHN0cnVjdCBwbGF0Zm9ybV9kZXZpY2UgKnBkZXYpDQo+ICt7DQo+ICsJaW50IGly cSwgcmV0Ow0KPiArDQo+ICsJcHVuaXRfaXBjZGV2ID0gZGV2bV9remFsbG9jKCZwZGV2LT5kZXYs DQo+ICsJCQkJICAgIHNpemVvZigqcHVuaXRfaXBjZGV2KSwgDQo+IEdGUF9LRVJORUwpOw0KPiAr CWlmICghcHVuaXRfaXBjZGV2KQ0KPiArCQlyZXR1cm4gLUVOT01FTTsNCj4gKw0KPiArCXBsYXRm b3JtX3NldF9kcnZkYXRhKHBkZXYsIHB1bml0X2lwY2Rldik7DQo+ICsNCj4gKwlpcnEgPSBwbGF0 Zm9ybV9nZXRfaXJxKHBkZXYsIDApOw0KPiArCWlmIChpcnEgPCAwKSB7DQo+ICsJCXB1bml0X2lw Y2Rldi0+aXJxID0gMDsNCj4gKwkJZGV2X3dhcm4oJnBkZXYtPmRldiwgIkludmFsaWQgSVJRLCB1 c2luZyBwb2xsaW5nIA0KPiBtb2RlXG4iKTsNCj4gKwl9IGVsc2Ugew0KPiArCQlyZXQgPSBkZXZt X3JlcXVlc3RfaXJxKCZwZGV2LT5kZXYsIGlycSwgDQo+IGludGVsX3B1bml0X2lvYywNCj4gKwkJ CQkgICAgICAgSVJRRl9OT19TVVNQRU5ELCANCj4gImludGVsX3B1bml0X2lwYyIsDQo+ICsJCQkJ ICAgICAgICZwdW5pdF9pcGNkZXYpOw0KPiArCQlpZiAocmV0KSB7DQo+ICsJCQlkZXZfZXJyKCZw ZGV2LT5kZXYsICJGYWlsZWQgdG8gcmVxdWVzdCBpcnE6IA0KPiAlZFxuIiwgaXJxKTsNCj4gKwkJ CXJldHVybiByZXQ7DQo+ICsJCX0NCj4gKwkJcHVuaXRfaXBjZGV2LT5pcnEgPSBpcnE7DQo+ICsJ fQ0KPiArDQo+ICsJcmV0ID0gaW50ZWxfcHVuaXRfZ2V0X2JhcnMocGRldik7DQo+ICsJaWYgKHJl dCkNCj4gKwkJZ290byBvdXQ7DQo+ICsNCj4gKwlwdW5pdF9pcGNkZXYtPmRldiA9ICZwZGV2LT5k ZXY7DQo+ICsJbXV0ZXhfaW5pdCgmcHVuaXRfaXBjZGV2LT5sb2NrKTsNCj4gKwlpbml0X2NvbXBs ZXRpb24oJnB1bml0X2lwY2Rldi0+Y21kX2NvbXBsZXRlKTsNCj4gKw0KPiArb3V0Og0KPiArCXJl dHVybiByZXQ7DQo+ICt9DQo+ICsNCj4gK3N0YXRpYyBpbnQgaW50ZWxfcHVuaXRfaXBjX3JlbW92 ZShzdHJ1Y3QgcGxhdGZvcm1fZGV2aWNlICpwZGV2KQ0KPiArew0KPiArCUlQQ19ERVYgKmlwY2Rl diA9IHBsYXRmb3JtX2dldF9kcnZkYXRhKHBkZXYpOw0KPiArDQo+ICsJaW91bm1hcChpcGNkZXYt PmJhc2VbQklPU19JUENdKTsNCj4gKw0KPiArCXJldHVybiAwOw0KPiArfQ0KPiArDQo+ICtzdGF0 aWMgY29uc3Qgc3RydWN0IGFjcGlfZGV2aWNlX2lkIHB1bml0X2lwY19hY3BpX2lkc1tdID0gew0K PiArCXsgIklOVDM0RDQiLCAwIH0sDQo+ICsJeyB9DQo+ICt9Ow0KPiArDQo+ICtzdGF0aWMgc3Ry dWN0IHBsYXRmb3JtX2RyaXZlciBpbnRlbF9wdW5pdF9pcGNfZHJpdmVyID0gew0KPiArCS5wcm9i ZSA9IGludGVsX3B1bml0X2lwY19wcm9iZSwNCj4gKwkucmVtb3ZlID0gaW50ZWxfcHVuaXRfaXBj X3JlbW92ZSwNCj4gKwkuZHJpdmVyID0gew0KPiArCQkubmFtZSA9ICJpbnRlbF9wdW5pdF9pcGMi LA0KPiArCQkuYWNwaV9tYXRjaF90YWJsZSA9IEFDUElfUFRSKHB1bml0X2lwY19hY3BpX2lkcyks DQo+ICsJfSwNCj4gK307DQo+ICsNCj4gK3N0YXRpYyBpbnQgX19pbml0IGludGVsX3B1bml0X2lw Y19pbml0KHZvaWQpDQo+ICt7DQo+ICsJcmV0dXJuIHBsYXRmb3JtX2RyaXZlcl9yZWdpc3Rlcigm aW50ZWxfcHVuaXRfaXBjX2RyaXZlcik7DQo+ICt9DQo+ICsNCj4gK3N0YXRpYyB2b2lkIF9fZXhp dCBpbnRlbF9wdW5pdF9pcGNfZXhpdCh2b2lkKQ0KPiArew0KPiArCXBsYXRmb3JtX2RyaXZlcl91 bnJlZ2lzdGVyKCZpbnRlbF9wdW5pdF9pcGNfZHJpdmVyKTsNCj4gK30NCj4gKw0KPiArTU9EVUxF X0FVVEhPUigiWmhhIFFpcGVuZyA8cWlwZW5nLnpoYUBpbnRlbC5jb20+Iik7DQo+ICtNT0RVTEVf REVTQ1JJUFRJT04oIkludGVsIFAtVW5pdCBJUEMgZHJpdmVyIik7DQo+ICtNT0RVTEVfTElDRU5T RSgiR1BMIHYyIik7DQo+ICsNCj4gKy8qIFNvbWUgbW9kdWxlcyBhcmUgZGVwZW5kZW50IG9uIHRo aXMsIHNvIGluaXQgZWFybGllciAqLw0KPiArZnNfaW5pdGNhbGwoaW50ZWxfcHVuaXRfaXBjX2lu aXQpOw0KPiArbW9kdWxlX2V4aXQoaW50ZWxfcHVuaXRfaXBjX2V4aXQpOw0KDQotLSANCkFuZHkg U2hldmNoZW5rbyA8YW5kcml5LnNoZXZjaGVua29AaW50ZWwuY29tPg0KSW50ZWwgRmlubGFuZCBP eQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0KSW50ZWwgRmlubGFuZCBPeQpSZWdpc3RlcmVkIEFkZHJlc3M6IFBMIDI4 MSwgMDAxODEgSGVsc2lua2kgCkJ1c2luZXNzIElkZW50aXR5IENvZGU6IDAzNTc2MDYgLSA0IApE b21pY2lsZWQgaW4gSGVsc2lua2kgCgpUaGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIG1h eSBjb250YWluIGNvbmZpZGVudGlhbCBtYXRlcmlhbCBmb3IKdGhlIHNvbGUgdXNlIG9mIHRoZSBp bnRlbmRlZCByZWNpcGllbnQocykuIEFueSByZXZpZXcgb3IgZGlzdHJpYnV0aW9uCmJ5IG90aGVy cyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQKcmVj aXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGFuZCBkZWxldGUgYWxsIGNvcGllcy4K -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
>Everything is quite okay, except this BAR thingy. >Can you provide a DSDT excerpt for the device to see what is there? >I can't find such device (by ACPI id) in the tables of the accessible hardware in our lab. Please check below acpi device definition from BIOS. Punit device is created in pmc driver, since BIOS finally reject to create a separate device for Punit. Scope (\_SB) { Device(IPC1) { … Name (RBUF, ResourceTemplate () { Memory32Fixed (ReadWrite, 0x00000000, 0x00001000, BAR0) // IPC1 Bar // Memory32Fixed (ReadWrite, 0x00000000, 0x00001000, BAR1) // SSRAM Memory32Fixed (ReadWrite, 0x00000000, 0x00001000, MDAT) // PUnit BIOS mailbox Data Memory32Fixed (ReadWrite, 0x00000000, 0x00001000, MINF) // PUnit BIOS mailbox Interface and GTD/ISPD mailbox IO (Decode16, 0x400, 0x480, 0x4, 0x80) // ACPI IO Base address Interrupt (ResourceConsumer, Level, ActiveLow, Exclusive, , , ) {40} // IPC1 IRQ }) … } }//end scope
On Sat, Oct 10, 2015 at 03:07:53AM +0000, Zha, Qipeng wrote: > > >Everything is quite okay, except this BAR thingy. > > >Can you provide a DSDT excerpt for the device to see what is there? > > >I can't find such device (by ACPI id) in the tables of the accessible hardware in our lab. > > Please check below acpi device definition from BIOS. > Punit device is created in pmc driver, since BIOS finally reject to create a separate device for Punit. > Qipeng, sorry for the delay. I've been under a rather absurd load. I'd like to close on this so we can get this into -next ASAP. Thank you for posting the DSDT. Help us parse what this means so we're all seeing the same thing. I see a total of 3 memory addresses and the following IO base address. Unfortunately, the comments don't map directly to the driver code, so I need to piece this together. The code in question from the driver is: #define MAILBOX_REGISTER_SPACE 0x10 +static int intel_punit_get_bars(struct platform_device *pdev) +{ + struct resource *res0, *res1; + void __iomem *addr; + int size; + + res0 = platform_get_resource(pdev, IORESOURCE_MEM, 0); + if (!res0) { + dev_err(&pdev->dev, "Failed to get iomem resource\n"); + return -ENXIO; + } + size = resource_size(res0); + if (!devm_request_mem_region(&pdev->dev, res0->start, + size, pdev->name)) { + dev_err(&pdev->dev, "Failed to request iomem resouce\n"); + return -EBUSY; + } + + res1 = platform_get_resource(pdev, IORESOURCE_MEM, 1); + if (!res1) { + dev_err(&pdev->dev, "Failed to get iomem resource1\n"); + return -ENXIO; + } + size = resource_size(res1); + if (!devm_request_mem_region(&pdev->dev, res1->start, + size, pdev->name)) { + dev_err(&pdev->dev, "Failed to request iomem resouce1\n"); + return -EBUSY; + } + + addr = ioremap_nocache(res0->start, + resource_size(res0) + resource_size(res1)); + if (!addr) { + dev_err(&pdev->dev, "Failed to ioremap ipc base\n"); + return -ENOMEM; + } + punit_ipcdev->base[BIOS_IPC] = addr; + addr += MAILBOX_REGISTER_SPACE; + punit_ipcdev->base[GTDRIVER_IPC] = addr; + addr += MAILBOX_REGISTER_SPACE; + punit_ipcdev->base[ISPDRIVER_IPC] = addr; + + return 0; +} > Scope (\_SB) { > Device(IPC1) > { > … > Name (RBUF, ResourceTemplate () > { > Memory32Fixed (ReadWrite, 0x00000000, 0x00001000, BAR0) // IPC1 Bar size: 0x1000 IPC1 BAR, I presume this maps to res0 in the driver? Then the start of this 4096 byte region is assigned by: punit_ipcdev->base[BIOS_IPC] = addr; And everything else assigned by intel_punit_get_bards is contained within this addr since MAILBOX_REGISTER_SPACE is only 0x10. Do I have that correct? > // Memory32Fixed (ReadWrite, 0x00000000, 0x00001000, BAR1) // SSRAM > Memory32Fixed (ReadWrite, 0x00000000, 0x00001000, MDAT) // PUnit BIOS mailbox Data size: 0x1000 And this would be res1 in the driver? > Memory32Fixed (ReadWrite, 0x00000000, 0x00001000, MINF) // PUnit BIOS mailbox Interface and GTD/ISPD mailbox size: 0x1000 This seems odd, especially with the comments in the DSD. A more natural mapping would have been each of the Memory32Fixed macros mapping to the BIOS_IPC, GTDRIVER_IPC, and ISPDRIVER_IPC BARs in the driver. This would indeed be the case if MAILBOX_REGISTER_SPACE was 0x1000 instead of 0x10. Also, if that were the case, then those BARs should be set by using the mapped addr for the 3 separate resources - which is what Andy was getting at. Qipeng, I assume I misinterpretted something above. Can you point out where I've got this wrong and how the driver is doing the only thing it can given the resources provided by the DSDT? Thanks, > IO (Decode16, 0x400, 0x480, 0x4, 0x80) // ACPI IO Base address > Interrupt (ResourceConsumer, Level, ActiveLow, Exclusive, , , ) {40} // IPC1 IRQ > }) > > … > } > }//end scope
On Sat, 2015-10-10 at 03:07 +0000, Zha, Qipeng wrote: > > > > Everything is quite okay, except this BAR thingy. > > > Can you provide a DSDT excerpt for the device to see what is there? > > > I can't find such device (by ACPI id) in the tables of the > > accessible hardware in our lab. > > Please check below acpi device definition from BIOS. > Punit device is created in pmc driver, since BIOS finally reject to > create a separate device for Punit. Thank you for mention this one. It's unfortunately a show stopper for using this module as a driver (you can't assign two drivers to the same device). You have to convert is to a library. Moreover, I briefly looked at the intel_pmc_ipc and it should be refactored a in a few ways: a) split to core part, PCI driver, and ACPI driver, b) improved regarding to comments you got in this review (many comments are applied to what we have there). Darren, your opinion? > > Scope (\_SB) { > Device(IPC1) > { > … > Name (RBUF, ResourceTemplate () > { > Memory32Fixed (ReadWrite, 0x00000000, 0x00001000, BAR0) // > IPC1 Bar > // Memory32Fixed (ReadWrite, 0x00000000, 0x00001000, BAR1) // > SSRAM > Memory32Fixed (ReadWrite, 0x00000000, 0x00001000, MDAT) // > PUnit BIOS mailbox Data > Memory32Fixed (ReadWrite, 0x00000000, 0x00001000, MINF) // > PUnit BIOS mailbox Interface and GTD/ISPD mailbox > IO (Decode16, 0x400, 0x480, 0x4, 0x80) // > ACPI IO Base address > Interrupt (ResourceConsumer, Level, ActiveLow, Exclusive, , , > ) {40} // IPC1 IRQ > }) > > … > } > }//end scope -- Andy Shevchenko <andriy.shevchenko@intel.com> Intel Finland Oy --------------------------------------------------------------------- Intel Finland Oy Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
On Thu, 2015-10-15 at 13:35 +0300, Andy Shevchenko wrote: > On Sat, 2015-10-10 at 03:07 +0000, Zha, Qipeng wrote: > > > > > > Everything is quite okay, except this BAR thingy. > > > > > Can you provide a DSDT excerpt for the device to see what is > > > there? > > > > > I can't find such device (by ACPI id) in the tables of the > > > accessible hardware in our lab. > > > > Please check below acpi device definition from BIOS. > > Punit device is created in pmc driver, since BIOS finally reject to > > > > create a separate device for Punit. > > Thank you for mention this one. It's unfortunately a show stopper for > using this module as a driver (you can't assign two drivers to the > same > device). You have to convert is to a library. Oh, I'm sorry, I really missed that the IDs are different. So, discard this part. > > Moreover, I briefly looked at the intel_pmc_ipc and it should be > refactored a in a few ways: a) split to core part, PCI driver, and > ACPI > driver, b) improved regarding to comments you got in this review > (many > comments are applied to what we have there). > > Darren, your opinion? This by the way still valid. > > > > > Scope (\_SB) { > > Device(IPC1) > > { > > … > > Name (RBUF, ResourceTemplate () > > { > > Memory32Fixed (ReadWrite, 0x00000000, 0x00001000, BAR0) > > // > > IPC1 Bar > > // Memory32Fixed (ReadWrite, 0x00000000, 0x00001000, BAR1) > > // > > SSRAM > > Memory32Fixed (ReadWrite, 0x00000000, 0x00001000, MDAT) > > // > > PUnit BIOS mailbox Data > > Memory32Fixed (ReadWrite, 0x00000000, 0x00001000, MINF) > > // > > PUnit BIOS mailbox Interface and GTD/ISPD mailbox > > IO (Decode16, 0x400, 0x480, 0x4, 0x80) > > // > > ACPI IO Base address > > Interrupt (ResourceConsumer, Level, ActiveLow, Exclusive, , > > , > > ) {40} // IPC1 IRQ > > }) > > > > … > > } > > }//end scope > -- Andy Shevchenko <andriy.shevchenko@intel.com> Intel Finland Oy --------------------------------------------------------------------- Intel Finland Oy Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
On Thu, Oct 15, 2015 at 10:39:35AM +0000, Shevchenko, Andriy wrote: > On Thu, 2015-10-15 at 13:35 +0300, Andy Shevchenko wrote: > > On Sat, 2015-10-10 at 03:07 +0000, Zha, Qipeng wrote: > > > > > > > > Everything is quite okay, except this BAR thingy. > > > > > > > Can you provide a DSDT excerpt for the device to see what is > > > > there? > > > > > > > I can't find such device (by ACPI id) in the tables of the > > > > accessible hardware in our lab. > > > > > > Please check below acpi device definition from BIOS. > > > Punit device is created in pmc driver, since BIOS finally reject to > > > > > > create a separate device for Punit. > > > > Thank you for mention this one. It's unfortunately a show stopper for > > using this module as a driver (you can't assign two drivers to the > > same > > device). You have to convert is to a library. > > Oh, I'm sorry, I really missed that the IDs are different. > So, discard this part. > > > > > Moreover, I briefly looked at the intel_pmc_ipc and it should be > > refactored a in a few ways: a) split to core part, PCI driver, and > > ACPI > > driver, b) improved regarding to comments you got in this review > > (many > > comments are applied to what we have there). > > > > Darren, your opinion? > > This by the way still valid. I'm a bit confused. Are you just bringing up that the intel_pmc_ipc driver could also be improved? Or are you sugesting that this driver needs to be refactored together with the intel_pmc_ipc driver? With respect to the intel_punit_ipc driver, I've tried to parse/map the DSDT to the BAR mapping in the driver which you raised concerns about. Can you review that bit and help us come to a conclusion on that since you asked for the DSDT? (See separate response to Qipeng on that). Thanks, > > > > > > > > > Scope (\_SB) { > > > Device(IPC1) > > > { > > > … > > > Name (RBUF, ResourceTemplate () > > > { > > > Memory32Fixed (ReadWrite, 0x00000000, 0x00001000, BAR0) > > > // > > > IPC1 Bar > > > // Memory32Fixed (ReadWrite, 0x00000000, 0x00001000, BAR1) > > > // > > > SSRAM > > > Memory32Fixed (ReadWrite, 0x00000000, 0x00001000, MDAT) > > > // > > > PUnit BIOS mailbox Data > > > Memory32Fixed (ReadWrite, 0x00000000, 0x00001000, MINF) > > > // > > > PUnit BIOS mailbox Interface and GTD/ISPD mailbox > > > IO (Decode16, 0x400, 0x480, 0x4, 0x80) > > > // > > > ACPI IO Base address > > > Interrupt (ResourceConsumer, Level, ActiveLow, Exclusive, , > > > , > > > ) {40} // IPC1 IRQ > > > }) > > > > > > … > > > } > > > }//end scope > > > > -- > Andy Shevchenko <andriy.shevchenko@intel.com> > Intel Finland Oy > --------------------------------------------------------------------- > Intel Finland Oy > Registered Address: PL 281, 00181 Helsinki > Business Identity Code: 0357606 - 4 > Domiciled in Helsinki > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies.
T24gVGh1LCAyMDE1LTEwLTE1IGF0IDA4OjI5IC0wNzAwLCBEYXJyZW4gSGFydCB3cm90ZToNCj4g T24gVGh1LCBPY3QgMTUsIDIwMTUgYXQgMTA6Mzk6MzVBTSArMDAwMCwgU2hldmNoZW5rbywgQW5k cml5IHdyb3RlOg0KPiA+IE9uIFRodSwgMjAxNS0xMC0xNSBhdCAxMzozNSArMDMwMCwgQW5keSBT aGV2Y2hlbmtvIHdyb3RlOg0KPiA+ID4gT24gU2F0LCAyMDE1LTEwLTEwIGF0IDAzOjA3ICswMDAw LCBaaGEsIFFpcGVuZyB3cm90ZToNCj4gPiA+ID4gPiANCj4gPiA+ID4gPiBFdmVyeXRoaW5nIGlz IHF1aXRlIG9rYXksIGV4Y2VwdCB0aGlzIEJBUiB0aGluZ3kuDQo+ID4gPiA+IA0KPiA+ID4gPiA+ IENhbiB5b3UgcHJvdmlkZSBhIERTRFQgZXhjZXJwdCBmb3IgdGhlIGRldmljZSB0byBzZWUgd2hh dCBpcyANCj4gPiA+ID4gPiB0aGVyZT8NCj4gPiA+ID4gDQo+ID4gPiA+ID4gSSBjYW4ndCBmaW5k IHN1Y2ggZGV2aWNlIChieSBBQ1BJIGlkKSBpbiB0aGUgdGFibGVzIG9mIHRoZSANCj4gPiA+ID4g PiBhY2Nlc3NpYmxlIGhhcmR3YXJlIGluIG91ciBsYWIuDQo+ID4gPiA+IA0KPiA+ID4gPiBQbGVh c2UgY2hlY2sgYmVsb3cgYWNwaSBkZXZpY2UgZGVmaW5pdGlvbiBmcm9tIEJJT1MuDQo+ID4gPiA+ IFB1bml0IGRldmljZSBpcyBjcmVhdGVkIGluIHBtYyBkcml2ZXIsIHNpbmNlIEJJT1MgZmluYWxs eSANCj4gPiA+ID4gcmVqZWN0IHRvIA0KPiA+ID4gPiANCj4gPiA+ID4gY3JlYXRlIGEgc2VwYXJh dGUgZGV2aWNlIGZvciBQdW5pdC4NCj4gPiA+IA0KPiA+ID4gDQo+ID4gPiBNb3Jlb3ZlciwgSSBi cmllZmx5IGxvb2tlZCBhdCB0aGUgaW50ZWxfcG1jX2lwYyBhbmQgaXQgc2hvdWxkIGJlDQo+ID4g PiByZWZhY3RvcmVkIGEgaW4gYSBmZXcgd2F5czogYSkgc3BsaXQgdG8gY29yZSBwYXJ0LCBQQ0kg ZHJpdmVyLCANCj4gPiA+IGFuZCANCj4gPiA+IEFDUEkNCj4gPiA+IGRyaXZlciwgYikgaW1wcm92 ZWQgcmVnYXJkaW5nIHRvIGNvbW1lbnRzIHlvdSBnb3QgaW4gdGhpcyByZXZpZXcgDQo+ID4gPiAo bWFueQ0KPiA+ID4gY29tbWVudHMgYXJlIGFwcGxpZWQgdG8gd2hhdCB3ZSBoYXZlIHRoZXJlKS4N Cj4gPiA+IA0KPiA+ID4gRGFycmVuLCB5b3VyIG9waW5pb24/DQo+ID4gDQo+ID4gVGhpcyBieSB0 aGUgd2F5IHN0aWxsIHZhbGlkLg0KPiANCj4gSSdtIGEgYml0IGNvbmZ1c2VkLg0KDQpTb3JyeSBm b3IgdGhpcy4NCg0KPiAgQXJlIHlvdSBqdXN0IGJyaW5naW5nIHVwIHRoYXQgdGhlIGludGVsX3Bt Y19pcGMgZHJpdmVyIGNvdWxkDQo+IGFsc28gYmUgaW1wcm92ZWQ/DQo+IA0KDQpUaGF0IGlzLCBi dXQgZm9yIGZ1dHVyZS4gSXQncyBub3QgYSBjb25jZXJuIHJpZ2h0IG5vdy4NCg0KPiANCj4gV2l0 aCByZXNwZWN0IHRvIHRoZSBpbnRlbF9wdW5pdF9pcGMgZHJpdmVyLCBJJ3ZlIHRyaWVkIHRvIHBh cnNlL21hcCANCj4gdGhlIERTRFQgdG8NCj4gdGhlIEJBUiBtYXBwaW5nIGluIHRoZSBkcml2ZXIg d2hpY2ggeW91IHJhaXNlZCBjb25jZXJucyBhYm91dC4gQ2FuIA0KPiB5b3UgcmV2aWV3DQo+IHRo YXQgYml0IGFuZCBoZWxwIHVzIGNvbWUgdG8gYSBjb25jbHVzaW9uIG9uIHRoYXQgc2luY2UgeW91 IGFza2VkIGZvciANCj4gdGhlIERTRFQ/DQo+IChTZWUgc2VwYXJhdGUgcmVzcG9uc2UgdG8gUWlw ZW5nIG9uIHRoYXQpLg0KDQpZZXMsIEknbSBmb2xsb3cgdGhlIGRpc2N1c3Npb24uIEkgd291bGQg bGlrZSB0byB1bmRlcnN0YW5kIHdoYXQgdGhvc2UNCnRocmVlIHJlc291cmNlcyBmb3I/IEFuZCB0 aGVyZSBpcyBvbmUgSU8gKElPIHJlc291cmNlKSBmb3IgdW5jbGVhcg0KcmVhc29uLg0KDQo+IA0K PiBUaGFua3MsDQo+IA0KPiA+IA0KPiA+ID4gDQo+ID4gPiA+IA0KPiA+ID4gPiAgIFNjb3BlIChc X1NCKSB7DQo+ID4gPiA+ICAgICBEZXZpY2UoSVBDMSkNCj4gPiA+ID4gICAgIHsNCj4gPiA+ID4g ICAgICAg4oCmDQo+ID4gPiA+ICAgICAgIE5hbWUgKFJCVUYsIFJlc291cmNlVGVtcGxhdGUgKCkN Cj4gPiA+ID4gICAgICAgew0KPiA+ID4gPiAgICAgICAgIE1lbW9yeTMyRml4ZWQgKFJlYWRXcml0 ZSwgMHgwMDAwMDAwMCwgMHgwMDAwMTAwMCwgQkFSMCkNCj4gPiA+ID4gICAgDQo+ID4gPiA+ICAv LyANCj4gPiA+ID4gSVBDMSBCYXINCj4gPiA+ID4gICAgICAvLyAgIE1lbW9yeTMyRml4ZWQgKFJl YWRXcml0ZSwgMHgwMDAwMDAwMCwgMHgwMDAwMTAwMCwgDQo+ID4gPiA+IEJBUjEpIA0KPiA+ID4g PiAgLy8gDQo+ID4gPiA+IFNTUkFNDQo+ID4gPiA+ICAgICAgICAgTWVtb3J5MzJGaXhlZCAoUmVh ZFdyaXRlLCAweDAwMDAwMDAwLCAweDAwMDAxMDAwLCBNREFUKQ0KPiA+ID4gPiAgICANCj4gPiA+ ID4gIC8vIA0KPiA+ID4gPiBQVW5pdCBCSU9TIG1haWxib3ggRGF0YQ0KPiA+ID4gPiAgICAgICAg IE1lbW9yeTMyRml4ZWQgKFJlYWRXcml0ZSwgMHgwMDAwMDAwMCwgMHgwMDAwMTAwMCwgTUlORikN Cj4gPiA+ID4gICAgDQo+ID4gPiA+ICAvLyANCj4gPiA+ID4gUFVuaXQgQklPUyBtYWlsYm94IElu dGVyZmFjZSBhbmQgR1REL0lTUEQgbWFpbGJveA0KPiA+ID4gPiAgICAgICAgIElPIChEZWNvZGUx NiwgMHg0MDAsIDB4NDgwLCAweDQsIDB4ODApICAgICAgICAgICAgICAgICANCj4gPiA+ID4gICAg DQo+ID4gPiA+ICAvLyANCj4gPiA+ID4gQUNQSSBJTyBCYXNlIGFkZHJlc3MNCj4gPiA+ID4gICAg ICAgICBJbnRlcnJ1cHQgKFJlc291cmNlQ29uc3VtZXIsIExldmVsLCBBY3RpdmVMb3csIA0KPiA+ ID4gPiBFeGNsdXNpdmUsICwgDQo+ID4gPiA+ICwgDQo+ID4gPiA+ICkgezQwfSAgLy8gSVBDMSBJ UlEgIA0KPiA+ID4gPiAgICAgICB9KQ0KPiA+ID4gPiANCj4gPiA+ID4gICAgICAg4oCmDQo+ID4g PiA+ICAgICB9DQo+ID4gPiA+ICAgfS8vZW5kIHNjb3BlDQo+ID4gPiANCg0KDQotLSANCkFuZHkg U2hldmNoZW5rbyA8YW5kcml5LnNoZXZjaGVua29AaW50ZWwuY29tPg0KSW50ZWwgRmlubGFuZCBP eQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0KSW50ZWwgRmlubGFuZCBPeQpSZWdpc3RlcmVkIEFkZHJlc3M6IFBMIDI4 MSwgMDAxODEgSGVsc2lua2kgCkJ1c2luZXNzIElkZW50aXR5IENvZGU6IDAzNTc2MDYgLSA0IApE b21pY2lsZWQgaW4gSGVsc2lua2kgCgpUaGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIG1h eSBjb250YWluIGNvbmZpZGVudGlhbCBtYXRlcmlhbCBmb3IKdGhlIHNvbGUgdXNlIG9mIHRoZSBp bnRlbmRlZCByZWNpcGllbnQocykuIEFueSByZXZpZXcgb3IgZGlzdHJpYnV0aW9uCmJ5IG90aGVy cyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQKcmVj aXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGFuZCBkZWxldGUgYWxsIGNvcGllcy4K -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Qipeng, can you comment on my understanding of the DSDT and the driver? On Wed, Oct 14, 2015 at 10:16:06PM -0700, Darren Hart wrote: > On Sat, Oct 10, 2015 at 03:07:53AM +0000, Zha, Qipeng wrote: > > > > >Everything is quite okay, except this BAR thingy. > > > > >Can you provide a DSDT excerpt for the device to see what is there? > > > > >I can't find such device (by ACPI id) in the tables of the accessible hardware in our lab. > > > > Please check below acpi device definition from BIOS. > > Punit device is created in pmc driver, since BIOS finally reject to create a separate device for Punit. > > > > Qipeng, sorry for the delay. I've been under a rather absurd load. I'd like to > close on this so we can get this into -next ASAP. Thank you for posting the > DSDT. > > Help us parse what this means so we're all seeing the same thing. I see a total > of 3 memory addresses and the following IO base address. Unfortunately, the > comments don't map directly to the driver code, so I need to piece this > together. > > The code in question from the driver is: > > #define MAILBOX_REGISTER_SPACE 0x10 > > +static int intel_punit_get_bars(struct platform_device *pdev) > +{ > + struct resource *res0, *res1; > + void __iomem *addr; > + int size; > + > + res0 = platform_get_resource(pdev, IORESOURCE_MEM, 0); > + if (!res0) { > + dev_err(&pdev->dev, "Failed to get iomem resource\n"); > + return -ENXIO; > + } > + size = resource_size(res0); > + if (!devm_request_mem_region(&pdev->dev, res0->start, > + size, pdev->name)) { > + dev_err(&pdev->dev, "Failed to request iomem resouce\n"); > + return -EBUSY; > + } > + > + res1 = platform_get_resource(pdev, IORESOURCE_MEM, 1); > + if (!res1) { > + dev_err(&pdev->dev, "Failed to get iomem resource1\n"); > + return -ENXIO; > + } > + size = resource_size(res1); > + if (!devm_request_mem_region(&pdev->dev, res1->start, > + size, pdev->name)) { > + dev_err(&pdev->dev, "Failed to request iomem resouce1\n"); > + return -EBUSY; > + } > + > + addr = ioremap_nocache(res0->start, > + resource_size(res0) + resource_size(res1)); > + if (!addr) { > + dev_err(&pdev->dev, "Failed to ioremap ipc base\n"); > + return -ENOMEM; > + } > + punit_ipcdev->base[BIOS_IPC] = addr; > + addr += MAILBOX_REGISTER_SPACE; > + punit_ipcdev->base[GTDRIVER_IPC] = addr; > + addr += MAILBOX_REGISTER_SPACE; > + punit_ipcdev->base[ISPDRIVER_IPC] = addr; > + > + return 0; > +} > > > > Scope (\_SB) { > > Device(IPC1) > > { > > … > > Name (RBUF, ResourceTemplate () > > { > > Memory32Fixed (ReadWrite, 0x00000000, 0x00001000, BAR0) // IPC1 Bar > > size: 0x1000 > IPC1 BAR, I presume this maps to res0 in the driver? > > Then the start of this 4096 byte region is assigned by: > > punit_ipcdev->base[BIOS_IPC] = addr; > > And everything else assigned by intel_punit_get_bards is contained within this > addr since MAILBOX_REGISTER_SPACE is only 0x10. > > Do I have that correct? > > > // Memory32Fixed (ReadWrite, 0x00000000, 0x00001000, BAR1) // SSRAM > > Memory32Fixed (ReadWrite, 0x00000000, 0x00001000, MDAT) // PUnit BIOS mailbox Data > > size: 0x1000 > And this would be res1 in the driver? > > > Memory32Fixed (ReadWrite, 0x00000000, 0x00001000, MINF) // PUnit BIOS mailbox Interface and GTD/ISPD mailbox > > size: 0x1000 > > This seems odd, especially with the comments in the DSD. A more natural mapping would have been each of the Memory32Fixed macros mapping to the BIOS_IPC, GTDRIVER_IPC, and ISPDRIVER_IPC BARs in the driver. This would indeed be the case if MAILBOX_REGISTER_SPACE was 0x1000 instead of 0x10. Also, if that were the case, then those BARs should be set by using the mapped addr for the 3 separate resources - which is what Andy was getting at. > > Qipeng, I assume I misinterpretted something above. Can you point out where I've got this wrong and how the driver is doing the only thing it can given the resources provided by the DSDT? > > Thanks, > > > > IO (Decode16, 0x400, 0x480, 0x4, 0x80) // ACPI IO Base address > > Interrupt (ResourceConsumer, Level, ActiveLow, Exclusive, , , ) {40} // IPC1 IRQ > > }) > > > > … > > } > > }//end scope > > -- > Darren Hart > Intel Open Source Technology Center
Pj5RaXBlbmcsIGNhbiB5b3UgY29tbWVudCBvbiBteSB1bmRlcnN0YW5kaW5nIG9mIHRoZSBEU0RU IGFuZCB0aGUgZHJpdmVyPw0KPj4gPiAgICAgIC8vICAgTWVtb3J5MzJGaXhlZCAoUmVhZFdyaXRl LCAweDAwMDAwMDAwLCAweDAwMDAxMDAwLCBCQVIxKSAgLy8gU1NSQU0NCj4+ID4gICAgICAgICBN ZW1vcnkzMkZpeGVkIChSZWFkV3JpdGUsIDB4MDAwMDAwMDAsIDB4MDAwMDEwMDAsIE1EQVQpICAg IC8vIFBVbml0IEJJT1MgbWFpbGJveCBEYXRhDQo+PiBzaXplOiAweDEwMDANCj4+IEFuZCB0aGlz IHdvdWxkIGJlIHJlczEgaW4gdGhlIGRyaXZlcj8NCj4+ID4gICAgICAgICBNZW1vcnkzMkZpeGVk IChSZWFkV3JpdGUsIDB4MDAwMDAwMDAsIDB4MDAwMDEwMDAsIE1JTkYpICAgIC8vIFBVbml0IEJJ T1MgbWFpbGJveCBJbnRlcmZhY2UgYW5kIEdURC9JU1BEIG1haWxib3gNCg0KV2hlbiBib290IHVw LCBCSU9TIHdpbGwgcmV3cml0ZSB0aGUgc2l6ZSBvZiB0aGVzZSBlbnRyaWVzLCAgYWN0dWFsbHkg dGhlIHNpemUgZm9yIHRoaXMgZW50cnkgd2lsbCBjaGFuZ2UgdG8gNEIsIG5vdCB0aGUgZGVmYXVs dCAweDEwMDAuDQpUaGlzIGlzIHJlYWwgc3RyYW5nZSBpbXBsZW1lbnRhdGlvbiBmb3IgdXMsIGFz IGJlZm9yZSBtZW50aW9uZWQsIEJJT1MgaW1wbGVtZW50IGxpa2UgdGhpcyB0byBtYWtlIGl0IGNv bXBhdGlibGUgZm9yIHdvcyBkcml2ZXIuDQoNCk9uIFdlZCwgT2N0IDE0LCAyMDE1IGF0IDEwOjE2 OjA2UE0gLTA3MDAsIERhcnJlbiBIYXJ0IHdyb3RlOg0KPiBPbiBTYXQsIE9jdCAxMCwgMjAxNSBh dCAwMzowNzo1M0FNICswMDAwLCBaaGEsIFFpcGVuZyB3cm90ZToNCj4gPiANCj4gPiA+RXZlcnl0 aGluZyBpcyBxdWl0ZSBva2F5LCBleGNlcHQgdGhpcyBCQVIgdGhpbmd5Lg0KPiA+IA0KPiA+ID5D YW4geW91IHByb3ZpZGUgYSBEU0RUIGV4Y2VycHQgZm9yIHRoZSBkZXZpY2UgdG8gc2VlIHdoYXQg aXMgdGhlcmU/DQo+ID4gDQo+ID4gPkkgY2FuJ3QgZmluZCBzdWNoIGRldmljZSAoYnkgQUNQSSBp ZCkgaW4gdGhlIHRhYmxlcyBvZiB0aGUgYWNjZXNzaWJsZSBoYXJkd2FyZSBpbiBvdXIgbGFiLg0K PiA+IA0KPiA+IFBsZWFzZSBjaGVjayBiZWxvdyBhY3BpIGRldmljZSBkZWZpbml0aW9uIGZyb20g QklPUy4NCj4gPiBQdW5pdCBkZXZpY2UgaXMgY3JlYXRlZCBpbiBwbWMgZHJpdmVyLCBzaW5jZSBC SU9TIGZpbmFsbHkgcmVqZWN0IHRvIGNyZWF0ZSBhIHNlcGFyYXRlIGRldmljZSBmb3IgUHVuaXQu DQo+ID4gDQo+IA0KPiBRaXBlbmcsIHNvcnJ5IGZvciB0aGUgZGVsYXkuIEkndmUgYmVlbiB1bmRl ciBhIHJhdGhlciBhYnN1cmQgbG9hZC4gSSdkIA0KPiBsaWtlIHRvIGNsb3NlIG9uIHRoaXMgc28g d2UgY2FuIGdldCB0aGlzIGludG8gLW5leHQgQVNBUC4gVGhhbmsgeW91IA0KPiBmb3IgcG9zdGlu ZyB0aGUgRFNEVC4NCj4gDQo+IEhlbHAgdXMgcGFyc2Ugd2hhdCB0aGlzIG1lYW5zIHNvIHdlJ3Jl IGFsbCBzZWVpbmcgdGhlIHNhbWUgdGhpbmcuIEkgDQo+IHNlZSBhIHRvdGFsIG9mIDMgbWVtb3J5 IGFkZHJlc3NlcyBhbmQgdGhlIGZvbGxvd2luZyBJTyBiYXNlIGFkZHJlc3MuIA0KPiBVbmZvcnR1 bmF0ZWx5LCB0aGUgY29tbWVudHMgZG9uJ3QgbWFwIGRpcmVjdGx5IHRvIHRoZSBkcml2ZXIgY29k ZSwgc28gDQo+IEkgbmVlZCB0byBwaWVjZSB0aGlzIHRvZ2V0aGVyLg0KPiANCj4gVGhlIGNvZGUg aW4gcXVlc3Rpb24gZnJvbSB0aGUgZHJpdmVyIGlzOg0KPiANCj4gI2RlZmluZSBNQUlMQk9YX1JF R0lTVEVSX1NQQUNFIDB4MTANCj4gDQo+ICtzdGF0aWMgaW50IGludGVsX3B1bml0X2dldF9iYXJz KHN0cnVjdCBwbGF0Zm9ybV9kZXZpY2UgKnBkZXYpIHsNCj4gKyAgICAgICBzdHJ1Y3QgcmVzb3Vy Y2UgKnJlczAsICpyZXMxOw0KPiArICAgICAgIHZvaWQgX19pb21lbSAqYWRkcjsNCj4gKyAgICAg ICBpbnQgc2l6ZTsNCj4gKw0KPiArICAgICAgIHJlczAgPSBwbGF0Zm9ybV9nZXRfcmVzb3VyY2Uo cGRldiwgSU9SRVNPVVJDRV9NRU0sIDApOw0KPiArICAgICAgIGlmICghcmVzMCkgew0KPiArICAg ICAgICAgICAgICAgZGV2X2VycigmcGRldi0+ZGV2LCAiRmFpbGVkIHRvIGdldCBpb21lbSByZXNv dXJjZVxuIik7DQo+ICsgICAgICAgICAgICAgICByZXR1cm4gLUVOWElPOw0KPiArICAgICAgIH0N Cj4gKyAgICAgICBzaXplID0gcmVzb3VyY2Vfc2l6ZShyZXMwKTsNCj4gKyAgICAgICBpZiAoIWRl dm1fcmVxdWVzdF9tZW1fcmVnaW9uKCZwZGV2LT5kZXYsIHJlczAtPnN0YXJ0LA0KPiArICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc2l6ZSwgcGRldi0+bmFtZSkpIHsNCj4gKyAg ICAgICAgICAgICAgIGRldl9lcnIoJnBkZXYtPmRldiwgIkZhaWxlZCB0byByZXF1ZXN0IGlvbWVt IHJlc291Y2VcbiIpOw0KPiArICAgICAgICAgICAgICAgcmV0dXJuIC1FQlVTWTsNCj4gKyAgICAg ICB9DQo+ICsNCj4gKyAgICAgICByZXMxID0gcGxhdGZvcm1fZ2V0X3Jlc291cmNlKHBkZXYsIElP UkVTT1VSQ0VfTUVNLCAxKTsNCj4gKyAgICAgICBpZiAoIXJlczEpIHsNCj4gKyAgICAgICAgICAg ICAgIGRldl9lcnIoJnBkZXYtPmRldiwgIkZhaWxlZCB0byBnZXQgaW9tZW0gcmVzb3VyY2UxXG4i KTsNCj4gKyAgICAgICAgICAgICAgIHJldHVybiAtRU5YSU87DQo+ICsgICAgICAgfQ0KPiArICAg ICAgIHNpemUgPSByZXNvdXJjZV9zaXplKHJlczEpOw0KPiArICAgICAgIGlmICghZGV2bV9yZXF1 ZXN0X21lbV9yZWdpb24oJnBkZXYtPmRldiwgcmVzMS0+c3RhcnQsDQo+ICsgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBzaXplLCBwZGV2LT5uYW1lKSkgew0KPiArICAgICAgICAg ICAgICAgZGV2X2VycigmcGRldi0+ZGV2LCAiRmFpbGVkIHRvIHJlcXVlc3QgaW9tZW0gcmVzb3Vj ZTFcbiIpOw0KPiArICAgICAgICAgICAgICAgcmV0dXJuIC1FQlVTWTsNCj4gKyAgICAgICB9DQo+ ICsNCj4gKyAgICAgICBhZGRyID0gaW9yZW1hcF9ub2NhY2hlKHJlczAtPnN0YXJ0LA0KPiArICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgcmVzb3VyY2Vfc2l6ZShyZXMwKSArIHJlc291cmNl X3NpemUocmVzMSkpOw0KPiArICAgICAgIGlmICghYWRkcikgew0KPiArICAgICAgICAgICAgICAg ZGV2X2VycigmcGRldi0+ZGV2LCAiRmFpbGVkIHRvIGlvcmVtYXAgaXBjIGJhc2VcbiIpOw0KPiAr ICAgICAgICAgICAgICAgcmV0dXJuICAtRU5PTUVNOw0KPiArICAgICAgIH0NCj4gKyAgICAgICBw dW5pdF9pcGNkZXYtPmJhc2VbQklPU19JUENdID0gYWRkcjsNCj4gKyAgICAgICBhZGRyICs9IE1B SUxCT1hfUkVHSVNURVJfU1BBQ0U7DQo+ICsgICAgICAgcHVuaXRfaXBjZGV2LT5iYXNlW0dURFJJ VkVSX0lQQ10gPSBhZGRyOw0KPiArICAgICAgIGFkZHIgKz0gTUFJTEJPWF9SRUdJU1RFUl9TUEFD RTsNCj4gKyAgICAgICBwdW5pdF9pcGNkZXYtPmJhc2VbSVNQRFJJVkVSX0lQQ10gPSBhZGRyOw0K PiArDQo+ICsgICAgICAgcmV0dXJuIDA7DQo+ICt9DQo+IA0KPiANCj4gPiAgIFNjb3BlIChcX1NC KSB7DQo+ID4gICAgIERldmljZShJUEMxKQ0KPiA+ICAgICB7DQo+ID4gICAgICAg4oCmDQo+ID4g ICAgICAgTmFtZSAoUkJVRiwgUmVzb3VyY2VUZW1wbGF0ZSAoKQ0KPiA+ICAgICAgIHsNCj4gPiAg ICAgICAgIE1lbW9yeTMyRml4ZWQgKFJlYWRXcml0ZSwgMHgwMDAwMDAwMCwgMHgwMDAwMTAwMCwg QkFSMCkgICAgLy8gSVBDMSBCYXINCj4gDQo+IHNpemU6IDB4MTAwMA0KPiBJUEMxIEJBUiwgSSBw cmVzdW1lIHRoaXMgbWFwcyB0byByZXMwIGluIHRoZSBkcml2ZXI/DQo+IA0KPiBUaGVuIHRoZSBz dGFydCBvZiB0aGlzIDQwOTYgYnl0ZSByZWdpb24gaXMgYXNzaWduZWQgYnk6DQo+IA0KPiBwdW5p dF9pcGNkZXYtPmJhc2VbQklPU19JUENdID0gYWRkcjsNCj4gDQo+IEFuZCBldmVyeXRoaW5nIGVs c2UgYXNzaWduZWQgYnkgaW50ZWxfcHVuaXRfZ2V0X2JhcmRzIGlzIGNvbnRhaW5lZCANCj4gd2l0 aGluIHRoaXMgYWRkciBzaW5jZSBNQUlMQk9YX1JFR0lTVEVSX1NQQUNFIGlzIG9ubHkgMHgxMC4N Cj4gDQo+IERvIEkgaGF2ZSB0aGF0IGNvcnJlY3Q/DQo+IA0KPiA+ICAgICAgLy8gICBNZW1vcnkz MkZpeGVkIChSZWFkV3JpdGUsIDB4MDAwMDAwMDAsIDB4MDAwMDEwMDAsIEJBUjEpICAvLyBTU1JB TQ0KPiA+ICAgICAgICAgTWVtb3J5MzJGaXhlZCAoUmVhZFdyaXRlLCAweDAwMDAwMDAwLCAweDAw MDAxMDAwLCBNREFUKSAgICAvLyBQVW5pdCBCSU9TIG1haWxib3ggRGF0YQ0KPiANCj4gc2l6ZTog MHgxMDAwDQo+IEFuZCB0aGlzIHdvdWxkIGJlIHJlczEgaW4gdGhlIGRyaXZlcj8NCj4gDQo+ID4g ICAgICAgICBNZW1vcnkzMkZpeGVkIChSZWFkV3JpdGUsIDB4MDAwMDAwMDAsIDB4MDAwMDEwMDAs IE1JTkYpICAgIC8vIFBVbml0IEJJT1MgbWFpbGJveCBJbnRlcmZhY2UgYW5kIEdURC9JU1BEIG1h aWxib3gNCj4gDQo+IHNpemU6IDB4MTAwMA0KPiANCj4gVGhpcyBzZWVtcyBvZGQsIGVzcGVjaWFs bHkgd2l0aCB0aGUgY29tbWVudHMgaW4gdGhlIERTRC4gQSBtb3JlIG5hdHVyYWwgbWFwcGluZyB3 b3VsZCBoYXZlIGJlZW4gZWFjaCBvZiB0aGUgTWVtb3J5MzJGaXhlZCBtYWNyb3MgbWFwcGluZyB0 byB0aGUgQklPU19JUEMsIEdURFJJVkVSX0lQQywgYW5kIElTUERSSVZFUl9JUEMgQkFScyBpbiB0 aGUgZHJpdmVyLiBUaGlzIHdvdWxkIGluZGVlZCBiZSB0aGUgY2FzZSBpZiBNQUlMQk9YX1JFR0lT VEVSX1NQQUNFIHdhcyAweDEwMDAgaW5zdGVhZCBvZiAweDEwLiBBbHNvLCBpZiB0aGF0IHdlcmUg dGhlIGNhc2UsIHRoZW4gdGhvc2UgQkFScyBzaG91bGQgYmUgc2V0IGJ5IHVzaW5nIHRoZSBtYXBw ZWQgYWRkciBmb3IgdGhlIDMgc2VwYXJhdGUgcmVzb3VyY2VzIC0gd2hpY2ggaXMgd2hhdCBBbmR5 IHdhcyBnZXR0aW5nIGF0Lg0KPiANCj4gUWlwZW5nLCBJIGFzc3VtZSBJIG1pc2ludGVycHJldHRl ZCBzb21ldGhpbmcgYWJvdmUuIENhbiB5b3UgcG9pbnQgb3V0IHdoZXJlIEkndmUgZ290IHRoaXMg d3JvbmcgYW5kIGhvdyB0aGUgZHJpdmVyIGlzIGRvaW5nIHRoZSBvbmx5IHRoaW5nIGl0IGNhbiBn aXZlbiB0aGUgcmVzb3VyY2VzIHByb3ZpZGVkIGJ5IHRoZSBEU0RUPw0KPiANCj4gVGhhbmtzLA0K PiANCj4gDQo+ID4gICAgICAgICBJTyAoRGVjb2RlMTYsIDB4NDAwLCAweDQ4MCwgMHg0LCAweDgw KSAgICAgICAgICAgICAgICAgICAgIC8vIEFDUEkgSU8gQmFzZSBhZGRyZXNzDQo+ID4gICAgICAg ICBJbnRlcnJ1cHQgKFJlc291cmNlQ29uc3VtZXIsIExldmVsLCBBY3RpdmVMb3csIEV4Y2x1c2l2 ZSwgLCAsICkgezQwfSAgLy8gSVBDMSBJUlEgIA0KPiA+ICAgICAgIH0pDQo+ID4gDQo+ID4gICAg ICAg4oCmDQo+ID4gICAgIH0NCj4gPiAgIH0vL2VuZCBzY29wZQ0KPiANCj4gLS0NCj4gRGFycmVu IEhhcnQNCj4gSW50ZWwgT3BlbiBTb3VyY2UgVGVjaG5vbG9neSBDZW50ZXINCg0KLS0NCkRhcnJl biBIYXJ0DQpJbnRlbCBPcGVuIFNvdXJjZSBUZWNobm9sb2d5IENlbnRlcg0K -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Oct 22, 2015 at 01:01:32AM +0000, Zha, Qipeng wrote: > >>Qipeng, can you comment on my understanding of the DSDT and the driver? > >> > // Memory32Fixed (ReadWrite, 0x00000000, 0x00001000, BAR1) // SSRAM > >> > Memory32Fixed (ReadWrite, 0x00000000, 0x00001000, MDAT) // PUnit BIOS mailbox Data > >> size: 0x1000 > >> And this would be res1 in the driver? > >> > Memory32Fixed (ReadWrite, 0x00000000, 0x00001000, MINF) // PUnit BIOS mailbox Interface and GTD/ISPD mailbox > > When boot up, BIOS will rewrite the size of these entries, actually the size for this entry will change to 4B, not the default 0x1000. > This is real strange implementation for us, as before mentioned, BIOS implement like this to make it compatible for wos driver. > +Rafael - we're having some trouble mapping the ACPI declared resources to the driver code using them. Qipeng has indicated that the BIOS team is doing something rather bizarre to meet some requirement from the WOS drivers. Can you have a look at this thread? I haven't been able to map the ACPI resources to the driver resources in a way that makes sense to me, and this is holding up merging the driver. Qipeng, this is very strange indeed. How does BIOS change this in a way that doesn't change the resources ACPI reports to the OS? Is the ASL fragment you provided collected from a running Linux system using acpidump? If so, then the resources ACPI advertises to the OS are not actually available... and that can't be acceptable. Qipeng, I want to get this driver merged, but we have to do the due diligence to understand how these resources are being used. I've asked several questions to try and clarify this, but your responses have been very short and do not fully address the questions. I need your help to fully describe what is going on with the BARs before I can sign this off and ask Linus to merge it. Thanks, Darren > On Wed, Oct 14, 2015 at 10:16:06PM -0700, Darren Hart wrote: > > On Sat, Oct 10, 2015 at 03:07:53AM +0000, Zha, Qipeng wrote: > > > > > > >Everything is quite okay, except this BAR thingy. > > > > > > >Can you provide a DSDT excerpt for the device to see what is there? > > > > > > >I can't find such device (by ACPI id) in the tables of the accessible hardware in our lab. > > > > > > Please check below acpi device definition from BIOS. > > > Punit device is created in pmc driver, since BIOS finally reject to create a separate device for Punit. > > > > > > > Qipeng, sorry for the delay. I've been under a rather absurd load. I'd > > like to close on this so we can get this into -next ASAP. Thank you > > for posting the DSDT. > > > > Help us parse what this means so we're all seeing the same thing. I > > see a total of 3 memory addresses and the following IO base address. > > Unfortunately, the comments don't map directly to the driver code, so > > I need to piece this together. > > > > The code in question from the driver is: > > > > #define MAILBOX_REGISTER_SPACE 0x10 > > > > +static int intel_punit_get_bars(struct platform_device *pdev) { > > + struct resource *res0, *res1; > > + void __iomem *addr; > > + int size; > > + > > + res0 = platform_get_resource(pdev, IORESOURCE_MEM, 0); > > + if (!res0) { > > + dev_err(&pdev->dev, "Failed to get iomem resource\n"); > > + return -ENXIO; > > + } > > + size = resource_size(res0); > > + if (!devm_request_mem_region(&pdev->dev, res0->start, > > + size, pdev->name)) { > > + dev_err(&pdev->dev, "Failed to request iomem resouce\n"); > > + return -EBUSY; > > + } > > + > > + res1 = platform_get_resource(pdev, IORESOURCE_MEM, 1); > > + if (!res1) { > > + dev_err(&pdev->dev, "Failed to get iomem resource1\n"); > > + return -ENXIO; > > + } > > + size = resource_size(res1); > > + if (!devm_request_mem_region(&pdev->dev, res1->start, > > + size, pdev->name)) { > > + dev_err(&pdev->dev, "Failed to request iomem resouce1\n"); > > + return -EBUSY; > > + } > > + > > + addr = ioremap_nocache(res0->start, > > + resource_size(res0) + resource_size(res1)); > > + if (!addr) { > > + dev_err(&pdev->dev, "Failed to ioremap ipc base\n"); > > + return -ENOMEM; > > + } > > + punit_ipcdev->base[BIOS_IPC] = addr; > > + addr += MAILBOX_REGISTER_SPACE; > > + punit_ipcdev->base[GTDRIVER_IPC] = addr; > > + addr += MAILBOX_REGISTER_SPACE; > > + punit_ipcdev->base[ISPDRIVER_IPC] = addr; > > + > > + return 0; > > +} > > > > > > > Scope (\_SB) { > > > Device(IPC1) > > > { > > > … > > > Name (RBUF, ResourceTemplate () > > > { > > > Memory32Fixed (ReadWrite, 0x00000000, 0x00001000, BAR0) // IPC1 Bar > > > > size: 0x1000 > > IPC1 BAR, I presume this maps to res0 in the driver? > > > > Then the start of this 4096 byte region is assigned by: > > > > punit_ipcdev->base[BIOS_IPC] = addr; > > > > And everything else assigned by intel_punit_get_bards is contained > > within this addr since MAILBOX_REGISTER_SPACE is only 0x10. > > > > Do I have that correct? > > > > > // Memory32Fixed (ReadWrite, 0x00000000, 0x00001000, BAR1) // SSRAM > > > Memory32Fixed (ReadWrite, 0x00000000, 0x00001000, MDAT) // PUnit BIOS mailbox Data > > > > size: 0x1000 > > And this would be res1 in the driver? > > > > > Memory32Fixed (ReadWrite, 0x00000000, 0x00001000, MINF) // PUnit BIOS mailbox Interface and GTD/ISPD mailbox > > > > size: 0x1000 > > > > This seems odd, especially with the comments in the DSD. A more natural mapping would have been each of the Memory32Fixed macros mapping to the BIOS_IPC, GTDRIVER_IPC, and ISPDRIVER_IPC BARs in the driver. This would indeed be the case if MAILBOX_REGISTER_SPACE was 0x1000 instead of 0x10. Also, if that were the case, then those BARs should be set by using the mapped addr for the 3 separate resources - which is what Andy was getting at. > > > > Qipeng, I assume I misinterpretted something above. Can you point out where I've got this wrong and how the driver is doing the only thing it can given the resources provided by the DSDT? > > > > Thanks, > > > > > > > IO (Decode16, 0x400, 0x480, 0x4, 0x80) // ACPI IO Base address > > > Interrupt (ResourceConsumer, Level, ActiveLow, Exclusive, , , ) {40} // IPC1 IRQ > > > }) > > > > > > … > > > } > > > }//end scope > > > > -- > > Darren Hart > > Intel Open Source Technology Center > > -- > Darren Hart > Intel Open Source Technology Center
> -----Original Message----- > From: Darren Hart [mailto:dvhart@infradead.org] > Sent: Thursday, October 22, 2015 11:05 AM > To: Zha, Qipeng; Rafael Wysocki > Cc: Shevchenko, Andriy; platform-driver-x86@vger.kernel.org; Westerberg, > Mika > Subject: Re: [PATCH v7] platform:x86: add Intel P-Unit mailbox IPC driver > > On Thu, Oct 22, 2015 at 01:01:32AM +0000, Zha, Qipeng wrote: > > >>Qipeng, can you comment on my understanding of the DSDT and the > driver? > > >> > // Memory32Fixed (ReadWrite, 0x00000000, 0x00001000, BAR1) // > SSRAM > > >> > Memory32Fixed (ReadWrite, 0x00000000, 0x00001000, MDAT) // > PUnit BIOS mailbox Data > > >> size: 0x1000 > > >> And this would be res1 in the driver? > > >> > Memory32Fixed (ReadWrite, 0x00000000, 0x00001000, MINF) // > PUnit BIOS mailbox Interface and GTD/ISPD mailbox > > > > When boot up, BIOS will rewrite the size of these entries, actually the size > for this entry will change to 4B, not the default 0x1000. > > This is real strange implementation for us, as before mentioned, BIOS > implement like this to make it compatible for wos driver. > > > > +Rafael - we're having some trouble mapping the ACPI declared resources > +to the > driver code using them. Qipeng has indicated that the BIOS team is doing > something rather bizarre to meet some requirement from the WOS drivers. > Can you have a look at this thread? I haven't been able to map the ACPI > resources to the driver resources in a way that makes sense to me, and this is > holding up merging the driver. > > Qipeng, this is very strange indeed. How does BIOS change this in a way that > doesn't change the resources ACPI reports to the OS? > > Is the ASL fragment you provided collected from a running Linux system > using acpidump? If so, then the resources ACPI advertises to the OS are not > actually available... and that can't be acceptable. +1. Please confirm that the excerpt has been copied from running Linux OS machine, otherwise please provide the *real* (run-time) excerpt from DSDT using either acpidump or manually copied from /sys/firmware/acpi/tables/DSDT (IIRC). > > Qipeng, I want to get this driver merged, but we have to do the due diligence > to understand how these resources are being used. I've asked several > questions to try and clarify this, but your responses have been very short and > do not fully address the questions. I need your help to fully describe what is > going on with the BARs before I can sign this off and ask Linus to merge it. -- Andy Shevchenko <andriy.shevchenko@intel.com> --------------------------------------------------------------------- Intel Finland Oy Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
Darren, Andriy: Thanks for your kind review, try to make clear as below. +Gavin, Our BIOS developer. On Thu, Oct 22, 2015 at 01:01:32AM +0000, Zha, Qipeng wrote: > >>Qipeng, can you comment on my understanding of the DSDT and the driver? > >> > // Memory32Fixed (ReadWrite, 0x00000000, 0x00001000, BAR1) // SSRAM > >> > Memory32Fixed (ReadWrite, 0x00000000, 0x00001000, MDAT) // PUnit BIOS mailbox Data > >> size: 0x1000 > >> And this would be res1 in the driver? > >> > Memory32Fixed (ReadWrite, 0x00000000, 0x00001000, MINF) // PUnit BIOS mailbox Interface and GTD/ISPD mailbox > > When boot up, BIOS will rewrite the size of these entries, actually the size for this entry will change to 4B, not the default 0x1000. > This is real strange implementation for us, as before mentioned, BIOS implement like this to make it compatible for wos driver. > >+Rafael - we're having some trouble mapping the ACPI declared resources >+to the >driver code using them. Qipeng has indicated that the BIOS team is doing something rather bizarre to meet some requirement from the WOS drivers. Can you have a look at this thread? I haven't been able to map the ACPI resources to the driver resources in a way that makes sense to me, and this is holding up merging the driver. >Qipeng, this is very strange indeed. How does BIOS change this in a way that doesn't change the resources ACPI reports to the OS? >Is the ASL fragment you provided collected from a running Linux system using acpidump? If so, then the resources ACPI advertises to the OS are not actually available... and that can't be acceptable. >Qipeng, I want to get this driver merged, but we have to do the due diligence to understand how these resources are being used. I've asked several questions to try and clarify this, but your responses have been very short and do not fully address the questions. I need your help to fully describe what is going on with the BARs before I can sign this off and ask Linus to merge it. >Memory32Fixed (ReadWrite, 0x00000000, 0x00001000, MDAT) // PUnit BIOS mailbox Data This is map to res0 > Memory32Fixed (ReadWrite, 0x00000000, 0x00001000, MINF) // PUnit BIOS mailbox Interface and GTD/ISPD mailbox This is map to res1 These two entries are firstly parsed in pmc driver firstly and reported to punit driver. >Is the ASL fragment you provided collected from a running Linux system using acpidump? If so, then the resources ACPI advertises to the OS are not actually available... and that can't be acceptable. This is real ASL code I got from BIOS team and validated on bxt platform. Confirmed BIOS runtime code will update "acpi table" in memory before switch to os, for those resource which need to get/read from hardware dynamically, in this case, MINF and MDAT is set in runtime when boot BIOS and size of res0 is set as 4B. > On Wed, Oct 14, 2015 at 10:16:06PM -0700, Darren Hart wrote: > > On Sat, Oct 10, 2015 at 03:07:53AM +0000, Zha, Qipeng wrote: > > > > > > >Everything is quite okay, except this BAR thingy. > > > > > > >Can you provide a DSDT excerpt for the device to see what is there? > > > > > > >I can't find such device (by ACPI id) in the tables of the accessible hardware in our lab. > > > > > > Please check below acpi device definition from BIOS. > > > Punit device is created in pmc driver, since BIOS finally reject to create a separate device for Punit. > > > > > > > Qipeng, sorry for the delay. I've been under a rather absurd load. > > I'd like to close on this so we can get this into -next ASAP. Thank > > you for posting the DSDT. > > > > Help us parse what this means so we're all seeing the same thing. I > > see a total of 3 memory addresses and the following IO base address. > > Unfortunately, the comments don't map directly to the driver code, > > so I need to piece this together. > > > > The code in question from the driver is: > > > > #define MAILBOX_REGISTER_SPACE 0x10 > > > > +static int intel_punit_get_bars(struct platform_device *pdev) { > > + struct resource *res0, *res1; > > + void __iomem *addr; > > + int size; > > + > > + res0 = platform_get_resource(pdev, IORESOURCE_MEM, 0); > > + if (!res0) { > > + dev_err(&pdev->dev, "Failed to get iomem resource\n"); > > + return -ENXIO; > > + } > > + size = resource_size(res0); > > + if (!devm_request_mem_region(&pdev->dev, res0->start, > > + size, pdev->name)) { > > + dev_err(&pdev->dev, "Failed to request iomem resouce\n"); > > + return -EBUSY; > > + } > > + > > + res1 = platform_get_resource(pdev, IORESOURCE_MEM, 1); > > + if (!res1) { > > + dev_err(&pdev->dev, "Failed to get iomem resource1\n"); > > + return -ENXIO; > > + } > > + size = resource_size(res1); > > + if (!devm_request_mem_region(&pdev->dev, res1->start, > > + size, pdev->name)) { > > + dev_err(&pdev->dev, "Failed to request iomem resouce1\n"); > > + return -EBUSY; > > + } > > + > > + addr = ioremap_nocache(res0->start, > > + resource_size(res0) + resource_size(res1)); > > + if (!addr) { > > + dev_err(&pdev->dev, "Failed to ioremap ipc base\n"); > > + return -ENOMEM; > > + } > > + punit_ipcdev->base[BIOS_IPC] = addr; > > + addr += MAILBOX_REGISTER_SPACE; > > + punit_ipcdev->base[GTDRIVER_IPC] = addr; > > + addr += MAILBOX_REGISTER_SPACE; > > + punit_ipcdev->base[ISPDRIVER_IPC] = addr; > > + > > + return 0; > > +} > > > > > > > Scope (\_SB) { > > > Device(IPC1) > > > { > > > … > > > Name (RBUF, ResourceTemplate () > > > { > > > Memory32Fixed (ReadWrite, 0x00000000, 0x00001000, BAR0) // IPC1 Bar > > > > size: 0x1000 > > IPC1 BAR, I presume this maps to res0 in the driver? > > > > Then the start of this 4096 byte region is assigned by: > > > > punit_ipcdev->base[BIOS_IPC] = addr; > > > > And everything else assigned by intel_punit_get_bards is contained > > within this addr since MAILBOX_REGISTER_SPACE is only 0x10. > > > > Do I have that correct? > > > > > // Memory32Fixed (ReadWrite, 0x00000000, 0x00001000, BAR1) // SSRAM > > > Memory32Fixed (ReadWrite, 0x00000000, 0x00001000, MDAT) // PUnit BIOS mailbox Data > > > > size: 0x1000 > > And this would be res1 in the driver? > > > > > Memory32Fixed (ReadWrite, 0x00000000, 0x00001000, MINF) // PUnit BIOS mailbox Interface and GTD/ISPD mailbox > > > > size: 0x1000 > > > > This seems odd, especially with the comments in the DSD. A more natural mapping would have been each of the Memory32Fixed macros mapping to the BIOS_IPC, GTDRIVER_IPC, and ISPDRIVER_IPC BARs in the driver. This would indeed be the case if MAILBOX_REGISTER_SPACE was 0x1000 instead of 0x10. Also, if that were the case, then those BARs should be set by using the mapped addr for the 3 separate resources - which is what Andy was getting at. > > > > Qipeng, I assume I misinterpretted something above. Can you point out where I've got this wrong and how the driver is doing the only thing it can given the resources provided by the DSDT? > > > > Thanks, > > > > > > > IO (Decode16, 0x400, 0x480, 0x4, 0x80) // ACPI IO Base address > > > Interrupt (ResourceConsumer, Level, ActiveLow, Exclusive, , , ) {40} // IPC1 IRQ > > > }) > > > > > > … > > > } > > > }//end scope > > > > -- > > Darren Hart > > Intel Open Source Technology Center > > -- > Darren Hart > Intel Open Source Technology Center -- Darren Hart Intel Open Source Technology Center
On Thu, Oct 22, 2015 at 03:18:16PM +0000, Zha, Qipeng wrote: > >Is the ASL fragment you provided collected from a running Linux system using > >acpidump? If so, then the resources ACPI advertises to the OS are not > >actually available... and that can't be acceptable. > This is real ASL code I got from BIOS team and validated on bxt platform. > Confirmed BIOS runtime code will update "acpi table" in memory before switch > to os, for those resource which need to get/read from hardware dynamically, > in this case, MINF and MDAT is set in runtime when boot BIOS and size of res0 > is set as 4B. So the ASL you provided was not what the Linux kernel is seeing, correct? Can you please provide a DSDT disassembly from the running Linux system please, such as: # cp /sys/firmware/acpi/tables/DSDT DSDT.dat # iasl -d DSDT.dat Then find this device in DSDT.dsl and paste it here please.
On Thursday, October 22, 2015 05:43:07 PM Darren Hart wrote: > On Thu, Oct 22, 2015 at 03:18:16PM +0000, Zha, Qipeng wrote: > > >Is the ASL fragment you provided collected from a running Linux system using > > >acpidump? If so, then the resources ACPI advertises to the OS are not > > >actually available... and that can't be acceptable. > > This is real ASL code I got from BIOS team and validated on bxt platform. > > Confirmed BIOS runtime code will update "acpi table" in memory before switch > > to os, for those resource which need to get/read from hardware dynamically, > > in this case, MINF and MDAT is set in runtime when boot BIOS and size of res0 > > is set as 4B. > > So the ASL you provided was not what the Linux kernel is seeing, correct? > > Can you please provide a DSDT disassembly from the running Linux system please, > such as: > > # cp /sys/firmware/acpi/tables/DSDT DSDT.dat > # iasl -d DSDT.dat > > Then find this device in DSDT.dsl and paste it here please. Or even better send the full output of acpidump from that system (when running). Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
>So the ASL you provided was not what the Linux kernel is seeing, correct? >Can you please provide a DSDT disassembly from the running Linux system please, such as: ># cp /sys/firmware/acpi/tables/DSDT DSDT.dat # iasl -d DSDT.dat >Then find this device in DSDT.dsl and paste it here please. Sorry for late feedback, got dsdt from lab machine since my board got broken, Please check. Scope (\_SB) { Device (IPC1) { Name (_ADR, Zero) // _ADR: Address Name (_HID, "INT34D2") // _HID: Hardware ID Name (_CID, "INT34D2") // _CID: Compatible ID Name (_DDN, "Intel(R) IPCI controller ") // _DDN: DOS Device Name Name (_UID, One) // _UID: Unique ID Name (RBUF, ResourceTemplate () { Memory32Fixed (ReadWrite, 0x00000000, // Address Base 0x00002000, // Address Length _Y08) Memory32Fixed (ReadWrite, 0x00000000, // Address Base 0x00000004, // Address Length _Y09) Memory32Fixed (ReadWrite, 0x00000000, // Address Base 0x00000040, // Address Length _Y0A) IO (Decode16, 0x0400, // Range Minimum 0x0480, // Range Maximum 0x04, // Alignment 0x80, // Length ) Memory32Fixed (ReadWrite, 0x00000000, // Address Base 0x00002000, // Address Length _Y0B) Interrupt (ResourceConsumer, Level, ActiveLow, Exclusive, ,, ) { 0x00000028, } }) Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings { CreateDWordField (RBUF, \_SB.IPC1._Y08._BAS, B0BA) // _BAS: Base Address CreateDWordField (RBUF, \_SB.IPC1._Y08._LEN, B0LN) // _LEN: Length Store (DD1A, B0BA) Store (DD1L, B0LN) CreateDWordField (RBUF, \_SB.IPC1._Y09._BAS, BM01) // _BAS: Base Address CreateDWordField (RBUF, \_SB.IPC1._Y09._LEN, BML1) // _LEN: Length CreateDWordField (RBUF, \_SB.IPC1._Y0A._BAS, BM02) // _BAS: Base Address CreateDWordField (RBUF, \_SB.IPC1._Y0A._LEN, BML2) // _LEN: Length Store (BMDA, BM01) Store (0x04, BML1) Store (BMIA, BM02) Store (0x40, BML2) CreateDWordField (RBUF, \_SB.IPC1._Y0B._BAS, B1BA) // _BAS: Base Address CreateDWordField (RBUF, \_SB.IPC1._Y0B._LEN, B1LN) // _LEN: Length Store (DD3A, B1BA) Store (DD3L, B1LN) Return (RBUF) } Method (_STA, 0, NotSerialized) // _STA: Status { Return (0x0F) } -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
T24gTW9uLCAyMDE1LTEwLTI2IGF0IDA4OjUxICswMDAwLCBaaGEsIFFpcGVuZyB3cm90ZToNCj4g PiBTbyB0aGUgQVNMIHlvdSBwcm92aWRlZCB3YXMgbm90IHdoYXQgdGhlIExpbnV4IGtlcm5lbCBp cyBzZWVpbmcsDQo+ID4gY29ycmVjdD8NCj4gDQo+ID4gQ2FuIHlvdSBwbGVhc2UgcHJvdmlkZSBh IERTRFQgZGlzYXNzZW1ibHkgZnJvbSB0aGUgcnVubmluZyBMaW51eA0KPiA+IHN5c3RlbSBwbGVh c2UsIHN1Y2ggYXM6DQo+IA0KPiA+ICMgY3AgL3N5cy9maXJtd2FyZS9hY3BpL3RhYmxlcy9EU0RU IERTRFQuZGF0ICMgaWFzbCAtZCBEU0RULmRhdA0KPiANCj4gPiBUaGVuIGZpbmQgdGhpcyBkZXZp Y2UgaW4gRFNEVC5kc2wgYW5kIHBhc3RlIGl0IGhlcmUgcGxlYXNlLg0KPiANCj4gU29ycnkgZm9y IGxhdGUgZmVlZGJhY2sswqDCoGdvdCBkc2R0IGZyb20gbGFiIG1hY2hpbmUgc2luY2UgbXkgYm9h cmQNCj4gZ290IGJyb2tlbiwNCj4gUGxlYXNlIGNoZWNrLg0KPiANCj4gU2NvcGUgKFxfU0IpDQo+ IMKgwqDCoMKgwqDCoMKgwqB7DQo+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoERldmljZSAoSVBD MSkNCj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgew0KPiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoE5hbWUgKF9BRFIsIFplcm8pwqDCoC8vIF9BRFI6IEFkZHJlc3MNCj4gwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqBOYW1lIChfSElELCAiSU5UMzREMiIpwqDCoC8vIF9I SUQ6IEhhcmR3YXJlIElEDQo+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgTmFtZSAo X0NJRCwgIklOVDM0RDIiKcKgwqAvLyBfQ0lEOiBDb21wYXRpYmxlIElEDQo+IMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgTmFtZSAoX0RETiwgIkludGVsKFIpIElQQ0kgY29udHJvbGxl ciAiKcKgwqAvLyBfREROOg0KPiBET1MgRGV2aWNlIE5hbWUNCj4gwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqBOYW1lIChfVUlELCBPbmUpwqDCoC8vIF9VSUQ6IFVuaXF1ZSBJRA0KPiDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoE5hbWUgKFJCVUYsIFJlc291cmNlVGVtcGxh dGUgKCkNCj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqB7DQo+IMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqBNZW1vcnkzMkZpeGVkIChSZWFkV3JpdGUsDQo+ IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoDB4MDAwMDAw MDAswqDCoMKgwqDCoMKgwqDCoMKgLy8gQWRkcmVzcyBCYXNlDQo+IMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoDB4MDAwMDIwMDAswqDCoMKgwqDCoMKgwqDC oMKgLy8gQWRkcmVzcyBMZW5ndGgNCj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgX1kwOCkNCj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoE1lbW9yeTMyRml4ZWQgKFJlYWRXcml0ZSwNCj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgMHgwMDAwMDAwMCzCoMKgwqDCoMKgwqDCoMKgwqAv LyBBZGRyZXNzIEJhc2UNCj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgMHgwMDAwMDAwNCzCoMKgwqDCoMKgwqDCoMKgwqAvLyBBZGRyZXNzIExlbmd0aA0K PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqBfWTA5KQ0K PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgTWVtb3J5MzJGaXhlZCAo UmVhZFdyaXRlLA0KPiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqAweDAwMDAwMDAwLMKgwqDCoMKgwqDCoMKgwqDCoC8vIEFkZHJlc3MgQmFzZQ0KPiDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAweDAwMDAwMDQwLMKg wqDCoMKgwqDCoMKgwqDCoC8vIEFkZHJlc3MgTGVuZ3RoDQo+IMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoF9ZMEEpDQo+IMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqBJTyAoRGVjb2RlMTYsDQo+IMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoDB4MDQwMCzCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoC8vIFJhbmdlIE1pbmltdW0NCj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgMHgwNDgwLMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgLy8gUmFuZ2Ug TWF4aW11bQ0KPiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqAweDA0LMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoC8vIEFsaWdubWVudA0KPiDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAweDgwLMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoC8vIExlbmd0aA0KPiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqApDQo+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqBNZW1vcnkzMkZpeGVkIChSZWFkV3JpdGUsDQo+IMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoDB4MDAwMDAwMDAswqDCoMKgwqDCoMKg wqDCoMKgLy8gQWRkcmVzcyBCYXNlDQo+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoDB4MDAwMDIwMDAswqDCoMKgwqDCoMKgwqDCoMKgLy8gQWRkcmVzcyBM ZW5ndGgNCj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg X1kwQikNCj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoEludGVycnVw dCAoUmVzb3VyY2VDb25zdW1lciwgTGV2ZWwsIEFjdGl2ZUxvdywNCj4gRXhjbHVzaXZlLCAsLCAp DQo+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqB7DQo+IMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoDB4MDAwMDAwMjgsDQo+IMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqB9DQo+IMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgfSkNCj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqBN ZXRob2QgKF9DUlMsIDAsIE5vdFNlcmlhbGl6ZWQpwqDCoC8vIF9DUlM6IEN1cnJlbnQNCj4gUmVz b3VyY2UgU2V0dGluZ3MNCj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqB7DQo+IMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqBDcmVhdGVEV29yZEZpZWxkIChS QlVGLCBcX1NCLklQQzEuX1kwOC5fQkFTLA0KPiBCMEJBKcKgwqAvLyBfQkFTOiBCYXNlIEFkZHJl c3MNCj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoENyZWF0ZURXb3Jk RmllbGQgKFJCVUYsIFxfU0IuSVBDMS5fWTA4Ll9MRU4sDQo+IEIwTE4pwqDCoC8vIF9MRU46IExl bmd0aA0KPiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgU3RvcmUgKERE MUEsIEIwQkEpDQo+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqBTdG9y ZSAoREQxTCwgQjBMTikNCg0KZGQxYSwgZGQxbCBoYXMgYmVlbiBzdG9yZWQgdG8gUmVzb3VyY2Ug MA0KDQo+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqBDcmVhdGVEV29y ZEZpZWxkIChSQlVGLCBcX1NCLklQQzEuX1kwOS5fQkFTLA0KPiBCTTAxKcKgwqAvLyBfQkFTOiBC YXNlIEFkZHJlc3MNCj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoENy ZWF0ZURXb3JkRmllbGQgKFJCVUYsIFxfU0IuSVBDMS5fWTA5Ll9MRU4sDQo+IEJNTDEpwqDCoC8v IF9MRU46IExlbmd0aA0KPiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg Q3JlYXRlRFdvcmRGaWVsZCAoUkJVRiwgXF9TQi5JUEMxLl9ZMEEuX0JBUywNCj4gQk0wMinCoMKg Ly8gX0JBUzogQmFzZSBBZGRyZXNzDQo+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqBDcmVhdGVEV29yZEZpZWxkIChSQlVGLCBcX1NCLklQQzEuX1kwQS5fTEVOLA0KPiBC TUwyKcKgwqAvLyBfTEVOOiBMZW5ndGgNCj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoFN0b3JlIChCTURBLCBCTTAxKQ0KPiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgU3RvcmUgKDB4MDQsIEJNTDEpDQo+IMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqBTdG9yZSAoQk1JQSwgQk0wMikNCj4gwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoFN0b3JlICgweDQwLCBCTUwyKQ0KDQpibWRhLCAweDA0 IC0+IFJlc291cmNlIDENCmJtaWEsIDB4NDAgLT4gUmVzb3VyY2UgMg0KDQo+IMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqBDcmVhdGVEV29yZEZpZWxkIChSQlVGLCBcX1NC LklQQzEuX1kwQi5fQkFTLA0KPiBCMUJBKcKgwqAvLyBfQkFTOiBCYXNlIEFkZHJlc3MNCj4gwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoENyZWF0ZURXb3JkRmllbGQgKFJC VUYsIFxfU0IuSVBDMS5fWTBCLl9MRU4sDQo+IEIxTE4pwqDCoC8vIF9MRU46IExlbmd0aA0KPiDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgU3RvcmUgKEREM0EsIEIxQkEp DQo+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqBTdG9yZSAoREQzTCwg QjFMTikNCg0KZGQzYSwgZGQzbCAtPiBSZXNvdXJjZSAzDQoNCg0KQ2FuIHlvdSBjcmVhdGUgYSB0 ZW1wb3JhcnkgbWV0aG9kIGluIHRoZSAtPnByb2JlKCkgb2YgdGhpcyBkcml2ZXIgdG8NCml0ZXJh dGUgb3ZlciByZXNvdXJjZXMgYW5kIHByaW50IHRoZW0gb3V0PyBPciB0ZWxsIHRoZSB2YWx1ZXMg QklPUyBzZXQNCnBlciB2YWx1ZXMgZGQxYSwgZGQxbCwgZGQzYSwgZGQzbCwgYm1kYSwgYm1pYS4N Cg0KQUZBSVUgeW91IGFyZSB1c2luZyBvbmx5IHJlc291cmNlcyAwIGFuZCAxLiBDYW4geW91IHB1 dCBoZXJlIHNtYWxsDQpkZXNjcmlwdGlvbiBvZiB3aGF0IGVhY2ggcmVzb3VyY2UgaXMgbWVhbnQg Zm9yPyAoSSBndWVzcyBjb3VwbGUgb2YgdGhlbQ0KdG8gUC1Vbml0LCBhbmQgY291cGxlIHJlbGF0 ZWQgdG8gd2hhdCB5b3UgYXJlIHRyeWluZyB0byBnZXQsIHJpZ2h0PykNCg0KQWxzbywgaXQncyBu b3QgY2xlYXIgdGhlIHB1cnBvc2Ugb2YgSU8gcmVzb3VyY2UuIFdoYXQgaXMgZm9yPw0KDQo+IMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqBSZXR1cm4gKFJCVUYpDQo+IMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgfQ0KPiANCj4gwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqBNZXRob2QgKF9TVEEsIDAsIE5vdFNlcmlhbGl6ZWQpwqDCoC8vIF9TVEE6 IFN0YXR1cw0KPiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoHsNCj4gwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoFJldHVybiAoMHgwRikNCj4gwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqB9DQoNCi0tIA0KQW5keSBTaGV2Y2hlbmtvIDxhbmRyaXku c2hldmNoZW5rb0BpbnRlbC5jb20+DQpJbnRlbCBGaW5sYW5kIE95DQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KSW50 ZWwgRmlubGFuZCBPeQpSZWdpc3RlcmVkIEFkZHJlc3M6IFBMIDI4MSwgMDAxODEgSGVsc2lua2kg CkJ1c2luZXNzIElkZW50aXR5IENvZGU6IDAzNTc2MDYgLSA0IApEb21pY2lsZWQgaW4gSGVsc2lu a2kgCgpUaGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVu dGlhbCBtYXRlcmlhbCBmb3IKdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQo cykuIEFueSByZXZpZXcgb3IgZGlzdHJpYnV0aW9uCmJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9o aWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQKcmVjaXBpZW50LCBwbGVhc2UgY29u dGFjdCB0aGUgc2VuZGVyIGFuZCBkZWxldGUgYWxsIGNvcGllcy4K -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Oct 27, 2015 at 12:30:31PM +0000, Shevchenko, Andriy wrote: > On Mon, 2015-10-26 at 08:51 +0000, Zha, Qipeng wrote: > > > So the ASL you provided was not what the Linux kernel is seeing, > > > correct? > > > > > Can you please provide a DSDT disassembly from the running Linux > > > system please, such as: > > > > > # cp /sys/firmware/acpi/tables/DSDT DSDT.dat # iasl -d DSDT.dat > > > > > Then find this device in DSDT.dsl and paste it here please. > > > > Sorry for late feedback, got dsdt from lab machine since my board > > got broken, > > Please check. > > > > Scope (\_SB) > > { > > Device (IPC1) > > { > > Name (_ADR, Zero) // _ADR: Address > > Name (_HID, "INT34D2") // _HID: Hardware ID > > Name (_CID, "INT34D2") // _CID: Compatible ID > > Name (_DDN, "Intel(R) IPCI controller ") // _DDN: > > DOS Device Name > > Name (_UID, One) // _UID: Unique ID > > Name (RBUF, ResourceTemplate () > > { > > Memory32Fixed (ReadWrite, > > 0x00000000, // Address Base > > 0x00002000, // Address Length > > _Y08) > > Memory32Fixed (ReadWrite, > > 0x00000000, // Address Base > > 0x00000004, // Address Length > > _Y09) > > Memory32Fixed (ReadWrite, > > 0x00000000, // Address Base > > 0x00000040, // Address Length > > _Y0A) > > IO (Decode16, > > 0x0400, // Range Minimum > > 0x0480, // Range Maximum > > 0x04, // Alignment > > 0x80, // Length > > ) > > Memory32Fixed (ReadWrite, > > 0x00000000, // Address Base > > 0x00002000, // Address Length > > _Y0B) > > Interrupt (ResourceConsumer, Level, ActiveLow, > > Exclusive, ,, ) > > { > > 0x00000028, > > } > > }) > > Method (_CRS, 0, NotSerialized) // _CRS: Current > > Resource Settings > > { > > CreateDWordField (RBUF, \_SB.IPC1._Y08._BAS, > > B0BA) // _BAS: Base Address > > CreateDWordField (RBUF, \_SB.IPC1._Y08._LEN, > > B0LN) // _LEN: Length > > Store (DD1A, B0BA) > > Store (DD1L, B0LN) > > dd1a, dd1l has been stored to Resource 0 > > > CreateDWordField (RBUF, \_SB.IPC1._Y09._BAS, > > BM01) // _BAS: Base Address > > CreateDWordField (RBUF, \_SB.IPC1._Y09._LEN, > > BML1) // _LEN: Length > > CreateDWordField (RBUF, \_SB.IPC1._Y0A._BAS, > > BM02) // _BAS: Base Address > > CreateDWordField (RBUF, \_SB.IPC1._Y0A._LEN, > > BML2) // _LEN: Length > > Store (BMDA, BM01) > > Store (0x04, BML1) > > Store (BMIA, BM02) > > Store (0x40, BML2) > > bmda, 0x04 -> Resource 1 > bmia, 0x40 -> Resource 2 > > > CreateDWordField (RBUF, \_SB.IPC1._Y0B._BAS, > > B1BA) // _BAS: Base Address > > CreateDWordField (RBUF, \_SB.IPC1._Y0B._LEN, > > B1LN) // _LEN: Length > > Store (DD3A, B1BA) > > Store (DD3L, B1LN) > > dd3a, dd3l -> Resource 3 > > > Can you create a temporary method in the ->probe() of this driver to > iterate over resources and print them out? Or tell the values BIOS set > per values dd1a, dd1l, dd3a, dd3l, bmda, bmia. > > AFAIU you are using only resources 0 and 1. Can you put here small > description of what each resource is meant for? (I guess couple of them > to P-Unit, and couple related to what you are trying to get, right?) While the driver code merges the ranges of res0 and res1: line 244-245: addr = ioremap_nocache(res0->start, resource_size(res0) + resource_size(res1)); It appears that we're using very little of this: punit_ipcdev->base[BIOS_IPC] = addr; addr += MAILBOX_REGISTER_SPACE; punit_ipcdev->base[GTDRIVER_IPC] = addr; addr += MAILBOX_REGISTER_SPACE; punit_ipcdev->base[ISPDRIVER_IPC] = addr; MAILBOX_REGISTER_SPACE is 0x10, but I don't know how long ISPDRIVER_IPC is expected to be, but it apears to be 4 bytes. This would mean we're using a total of 0x24 starting res0->start. res0 has a length of 0x2000 per the ASL above, and we're only referencing 0x24 of it. Why, then, do we merge the lengths of res0 and res1, presumably to 0x2004, when we only use 0x24? Or, am I misreading this? Also, Qipeng, you mentioned earlier that the firmware reported a length of 0x4B I believe? I don't see that in this ASL.
> On Mon, 2015-10-26 at 08:51 +0000, Zha, Qipeng wrote: > > > So the ASL you provided was not what the Linux kernel is seeing, > > > correct? > > > > > Can you please provide a DSDT disassembly from the running Linux > > > system please, such as: > > > > > # cp /sys/firmware/acpi/tables/DSDT DSDT.dat # iasl -d DSDT.dat > > > > > Then find this device in DSDT.dsl and paste it here please. > > > > Sorry for late feedback, got dsdt from lab machine since my board > > got broken, Please check. > > > > Scope (\_SB) > > { > > Device (IPC1) > > { > > Name (_ADR, Zero) // _ADR: Address > > Name (_HID, "INT34D2") // _HID: Hardware ID > > Name (_CID, "INT34D2") // _CID: Compatible ID > > Name (_DDN, "Intel(R) IPCI controller ") // _DDN: > > DOS Device Name > > Name (_UID, One) // _UID: Unique ID > > Name (RBUF, ResourceTemplate () > > { > > Memory32Fixed (ReadWrite, > > 0x00000000, // Address Base > > 0x00002000, // Address Length > > _Y08) > > Memory32Fixed (ReadWrite, > > 0x00000000, // Address Base > > 0x00000004, // Address Length > > _Y09) > > Memory32Fixed (ReadWrite, > > 0x00000000, // Address Base > > 0x00000040, // Address Length > > _Y0A) > > IO (Decode16, > > 0x0400, // Range Minimum > > 0x0480, // Range Maximum > > 0x04, // Alignment > > 0x80, // Length > > ) > > Memory32Fixed (ReadWrite, > > 0x00000000, // Address Base > > 0x00002000, // Address Length > > _Y0B) > > Interrupt (ResourceConsumer, Level, ActiveLow, > > Exclusive, ,, ) > > { > > 0x00000028, > > } > > }) > > Method (_CRS, 0, NotSerialized) // _CRS: Current > > Resource Settings > > { > > CreateDWordField (RBUF, \_SB.IPC1._Y08._BAS, > > B0BA) // _BAS: Base Address > > CreateDWordField (RBUF, \_SB.IPC1._Y08._LEN, > > B0LN) // _LEN: Length > > Store (DD1A, B0BA) > > Store (DD1L, B0LN) > > dd1a, dd1l has been stored to Resource 0 > > > CreateDWordField (RBUF, \_SB.IPC1._Y09._BAS, > > BM01) // _BAS: Base Address > > CreateDWordField (RBUF, \_SB.IPC1._Y09._LEN, > > BML1) // _LEN: Length > > CreateDWordField (RBUF, \_SB.IPC1._Y0A._BAS, > > BM02) // _BAS: Base Address > > CreateDWordField (RBUF, \_SB.IPC1._Y0A._LEN, > > BML2) // _LEN: Length > > Store (BMDA, BM01) > > Store (0x04, BML1) > > Store (BMIA, BM02) > > Store (0x40, BML2) > > bmda, 0x04 -> Resource 1 > bmia, 0x40 -> Resource 2 > > > CreateDWordField (RBUF, \_SB.IPC1._Y0B._BAS, > > B1BA) // _BAS: Base Address > > CreateDWordField (RBUF, \_SB.IPC1._Y0B._LEN, > > B1LN) // _LEN: Length > > Store (DD3A, B1BA) > > Store (DD3L, B1LN) > > dd3a, dd3l -> Resource 3 > > > Can you create a temporary method in the ->probe() of this driver to > iterate over resources and print them out? Or tell the values BIOS set > per values dd1a, dd1l, dd3a, dd3l, bmda, bmia. > > AFAIU you are using only resources 0 and 1. Can you put here small > description of what each resource is meant for? (I guess couple of > them to P-Unit, and couple related to what you are trying to get, > right?) >While the driver code merges the ranges of res0 and res1: >line 244-245: addr = ioremap_nocache(res0->start, resource_size(res0) + resource_size(res1)); >It appears that we're using very little of this: > punit_ipcdev->base[BIOS_IPC] = addr; > addr += MAILBOX_REGISTER_SPACE; > punit_ipcdev->base[GTDRIVER_IPC] = addr; > addr += MAILBOX_REGISTER_SPACE; > punit_ipcdev->base[ISPDRIVER_IPC] = addr; >MAILBOX_REGISTER_SPACE is 0x10, but I don't know how long ISPDRIVER_IPC is expected to be, but it apears to be 4 bytes. This would mean we're using a total of 0x24 starting res0->start. res0 has a length of 0x2000 per the ASL above, and we're only referencing 0x24 of it. >Why, then, do we merge the lengths of res0 and res1, presumably to 0x2004, when we only use 0x24? >Or, am I misreading this? >Also, Qipeng, you mentioned earlier that the firmware reported a length of 0x4B I believe? I don't see that in this ASL. Memory32Fixed (ReadWrite, 0x00000000, // Address Base 0x00002000, // Address Length _Y08) dd1a, dd1l -> Resource 0 This is PMC controller memory space, not related to Punit. bmda, 0x04 -> Resource 1 bmia, 0x40 -> Resource 2 These two are for Punit memory space, and bmia = bmda + 4, They are mapped to res0,res1 in Punit driver, size of res0 is set as 4B(Store (0x04, BML1)). Other resource are for other PMC functions, not related to Punit either. -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 2015-10-30 at 06:11 +0000, Zha, Qipeng wrote: > > On Mon, 2015-10-26 at 08:51 +0000, Zha, Qipeng wrote: > > > > So the ASL you provided was not what the Linux kernel is > > > > seeing, > > > > correct? > > > > > > > Can you please provide a DSDT disassembly from the running > > > > Linux > > > > system please, such as: > > > > > > > # cp /sys/firmware/acpi/tables/DSDT DSDT.dat # iasl -d DSDT.dat > > > > > > > Then find this device in DSDT.dsl and paste it here please. > > > > > > Sorry for late feedback, got dsdt from lab machine since my > > > board > > > got broken, Please check. > > > > > > Scope (\_SB) > > > { > > > Device (IPC1) > > > { > > > Name (_ADR, Zero) // _ADR: Address > > > Name (_HID, "INT34D2") // _HID: Hardware ID > > > Name (_CID, "INT34D2") // _CID: Compatible ID > > > Name (_DDN, "Intel(R) IPCI controller ") // > > > _DDN: > > > DOS Device Name > > > Name (_UID, One) // _UID: Unique ID > > > Name (RBUF, ResourceTemplate () > > > { > > > Memory32Fixed (ReadWrite, > > > 0x00000000, // Address Base > > > 0x00002000, // Address Length > > > _Y08) > > > Memory32Fixed (ReadWrite, > > > 0x00000000, // Address Base > > > 0x00000004, // Address Length > > > _Y09) > > > Memory32Fixed (ReadWrite, > > > 0x00000000, // Address Base > > > 0x00000040, // Address Length > > > _Y0A) > > > IO (Decode16, > > > 0x0400, // Range Minimum > > > 0x0480, // Range Maximum > > > 0x04, // Alignment > > > 0x80, // Length > > > ) > > > Memory32Fixed (ReadWrite, > > > 0x00000000, // Address Base > > > 0x00002000, // Address Length > > > _Y0B) > > > Interrupt (ResourceConsumer, Level, > > > ActiveLow, > > > Exclusive, ,, ) > > > { > > > 0x00000028, > > > } > > > }) > > > Method (_CRS, 0, NotSerialized) // _CRS: Current > > > Resource Settings > > > { > > > CreateDWordField (RBUF, \_SB.IPC1._Y08._BAS, > > > B0BA) // _BAS: Base Address > > > CreateDWordField (RBUF, \_SB.IPC1._Y08._LEN, > > > B0LN) // _LEN: Length > > > Store (DD1A, B0BA) > > > Store (DD1L, B0LN) > > > > dd1a, dd1l has been stored to Resource 0 > > > > > CreateDWordField (RBUF, \_SB.IPC1._Y09._BAS, > > > BM01) // _BAS: Base Address > > > CreateDWordField (RBUF, \_SB.IPC1._Y09._LEN, > > > BML1) // _LEN: Length > > > CreateDWordField (RBUF, \_SB.IPC1._Y0A._BAS, > > > BM02) // _BAS: Base Address > > > CreateDWordField (RBUF, \_SB.IPC1._Y0A._LEN, > > > BML2) // _LEN: Length > > > Store (BMDA, BM01) > > > Store (0x04, BML1) > > > Store (BMIA, BM02) > > > Store (0x40, BML2) > > > > bmda, 0x04 -> Resource 1 > > bmia, 0x40 -> Resource 2 > > > > > CreateDWordField (RBUF, \_SB.IPC1._Y0B._BAS, > > > B1BA) // _BAS: Base Address > > > CreateDWordField (RBUF, \_SB.IPC1._Y0B._LEN, > > > B1LN) // _LEN: Length > > > Store (DD3A, B1BA) > > > Store (DD3L, B1LN) > > > > dd3a, dd3l -> Resource 3 > > > > > > Can you create a temporary method in the ->probe() of this driver > > to > > iterate over resources and print them out? Or tell the values BIOS > > set > > per values dd1a, dd1l, dd3a, dd3l, bmda, bmia. > > > > AFAIU you are using only resources 0 and 1. Can you put here small > > description of what each resource is meant for? (I guess couple of > > them to P-Unit, and couple related to what you are trying to get, > > right?) > > > While the driver code merges the ranges of res0 and res1: > > > line 244-245: > addr = ioremap_nocache(res0->start, > resource_size(res0) + > resource_size(res1)); > > > It appears that we're using very little of this: > > > punit_ipcdev->base[BIOS_IPC] = addr; > > addr += MAILBOX_REGISTER_SPACE; > > punit_ipcdev->base[GTDRIVER_IPC] = addr; > > addr += MAILBOX_REGISTER_SPACE; > > punit_ipcdev->base[ISPDRIVER_IPC] = addr; > > > MAILBOX_REGISTER_SPACE is 0x10, but I don't know how long > > ISPDRIVER_IPC is expected to be, but it apears to be 4 bytes. This > > would mean we're using a total of 0x24 starting res0->start. res0 > > has a length of 0x2000 per the ASL above, and we're only > > referencing 0x24 of it. > > > Why, then, do we merge the lengths of res0 and res1, presumably to > > 0x2004, when we only use 0x24? > > > Or, am I misreading this? > > > Also, Qipeng, you mentioned earlier that the firmware reported a > > length of 0x4B I believe? I don't see that in this ASL. > > > Memory32Fixed (ReadWrite, > 0x00000000, // Address Base > 0x00002000, // Address Length > _Y08) > dd1a, dd1l -> Resource 0 > This is PMC controller memory space, not related to Punit. > > bmda, 0x04 -> Resource 1 > bmia, 0x40 -> Resource 2 > These two are for Punit memory space, and bmia = bmda + 4, > They are mapped to res0,res1 in Punit driver, size of res0 is set as > 4B(Store (0x04, BML1)). > > Other resource are for other PMC functions, not related to Punit > either. Are the values top secret? Can you please provide all numbers, including not relevant? -- Andy Shevchenko <andriy.shevchenko@intel.com> Intel Finland Oy --------------------------------------------------------------------- Intel Finland Oy Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
diff --git a/MAINTAINERS b/MAINTAINERS index 13ac861..cf71387 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5207,12 +5207,14 @@ F: include/uapi/linux/mei.h F: drivers/misc/mei/* F: Documentation/misc-devices/mei/* -INTEL PMC IPC DRIVER +INTEL PMC/P-Unit IPC DRIVER M: Zha Qipeng<qipeng.zha@intel.com> L: platform-driver-x86@vger.kernel.org S: Maintained F: drivers/platform/x86/intel_pmc_ipc.c +F: drivers/platform/x86/intel_punit_ipc.c F: arch/x86/include/asm/intel_pmc_ipc.h +F: arch/x86/include/asm/intel_punit_ipc.h IOC3 ETHERNET DRIVER M: Ralf Baechle <ralf@linux-mips.org> diff --git a/arch/x86/include/asm/intel_punit_ipc.h b/arch/x86/include/asm/intel_punit_ipc.h new file mode 100644 index 0000000..201eb9d --- /dev/null +++ b/arch/x86/include/asm/intel_punit_ipc.h @@ -0,0 +1,101 @@ +#ifndef _ASM_X86_INTEL_PUNIT_IPC_H_ +#define _ASM_X86_INTEL_PUNIT_IPC_H_ + +/* + * Three types of 8bit P-Unit IPC commands are supported, + * bit[7:6]: [00]: BIOS; [01]: GTD; [10]: ISPD. + */ +typedef enum { + BIOS_IPC = 0, + GTDRIVER_IPC, + ISPDRIVER_IPC, + RESERVED_IPC, +} IPC_TYPE; + +#define IPC_TYPE_OFFSET 6 +#define IPC_PUNIT_BIOS_CMD_BASE (BIOS_IPC << IPC_TYPE_OFFSET) +#define IPC_PUNIT_GTD_CMD_BASE (GTDDRIVER_IPC << IPC_TYPE_OFFSET) +#define IPC_PUNIT_ISPD_CMD_BASE (ISPDRIVER_IPC << IPC_TYPE_OFFSET) +#define IPC_PUNIT_CMD_TYPE_MASK (RESERVED_IPC << IPC_TYPE_OFFSET) + +/* BIOS => Pcode commands */ +#define IPC_PUNIT_BIOS_ZERO (IPC_PUNIT_BIOS_CMD_BASE | 0x00) +#define IPC_PUNIT_BIOS_VR_INTERFACE (IPC_PUNIT_BIOS_CMD_BASE | 0x01) +#define IPC_PUNIT_BIOS_READ_PCS (IPC_PUNIT_BIOS_CMD_BASE | 0x02) +#define IPC_PUNIT_BIOS_WRITE_PCS (IPC_PUNIT_BIOS_CMD_BASE | 0x03) +#define IPC_PUNIT_BIOS_READ_PCU_CONFIG (IPC_PUNIT_BIOS_CMD_BASE | 0x04) +#define IPC_PUNIT_BIOS_WRITE_PCU_CONFIG (IPC_PUNIT_BIOS_CMD_BASE | 0x05) +#define IPC_PUNIT_BIOS_READ_PL1_SETTING (IPC_PUNIT_BIOS_CMD_BASE | 0x06) +#define IPC_PUNIT_BIOS_WRITE_PL1_SETTING (IPC_PUNIT_BIOS_CMD_BASE | 0x07) +#define IPC_PUNIT_BIOS_TRIGGER_VDD_RAM (IPC_PUNIT_BIOS_CMD_BASE | 0x08) +#define IPC_PUNIT_BIOS_READ_TELE_INFO (IPC_PUNIT_BIOS_CMD_BASE | 0x09) +#define IPC_PUNIT_BIOS_READ_TELE_TRACE_CTRL (IPC_PUNIT_BIOS_CMD_BASE | 0x0a) +#define IPC_PUNIT_BIOS_WRITE_TELE_TRACE_CTRL (IPC_PUNIT_BIOS_CMD_BASE | 0x0b) +#define IPC_PUNIT_BIOS_READ_TELE_EVENT_CTRL (IPC_PUNIT_BIOS_CMD_BASE | 0x0c) +#define IPC_PUNIT_BIOS_WRITE_TELE_EVENT_CTRL (IPC_PUNIT_BIOS_CMD_BASE | 0x0d) +#define IPC_PUNIT_BIOS_READ_TELE_TRACE (IPC_PUNIT_BIOS_CMD_BASE | 0x0e) +#define IPC_PUNIT_BIOS_WRITE_TELE_TRACE (IPC_PUNIT_BIOS_CMD_BASE | 0x0f) +#define IPC_PUNIT_BIOS_READ_TELE_EVENT (IPC_PUNIT_BIOS_CMD_BASE | 0x10) +#define IPC_PUNIT_BIOS_WRITE_TELE_EVENT (IPC_PUNIT_BIOS_CMD_BASE | 0x11) +#define IPC_PUNIT_BIOS_READ_MODULE_TEMP (IPC_PUNIT_BIOS_CMD_BASE | 0x12) +#define IPC_PUNIT_BIOS_RESERVED (IPC_PUNIT_BIOS_CMD_BASE | 0x13) +#define IPC_PUNIT_BIOS_READ_VOLTAGE_OVER (IPC_PUNIT_BIOS_CMD_BASE | 0x14) +#define IPC_PUNIT_BIOS_WRITE_VOLTAGE_OVER (IPC_PUNIT_BIOS_CMD_BASE | 0x15) +#define IPC_PUNIT_BIOS_READ_RATIO_OVER (IPC_PUNIT_BIOS_CMD_BASE | 0x16) +#define IPC_PUNIT_BIOS_WRITE_RATIO_OVER (IPC_PUNIT_BIOS_CMD_BASE | 0x17) +#define IPC_PUNIT_BIOS_READ_VF_GL_CTRL (IPC_PUNIT_BIOS_CMD_BASE | 0x18) +#define IPC_PUNIT_BIOS_WRITE_VF_GL_CTRL (IPC_PUNIT_BIOS_CMD_BASE | 0x19) +#define IPC_PUNIT_BIOS_READ_FM_SOC_TEMP_THRESH (IPC_PUNIT_BIOS_CMD_BASE | 0x1a) +#define IPC_PUNIT_BIOS_WRITE_FM_SOC_TEMP_THRESH (IPC_PUNIT_BIOS_CMD_BASE | 0x1b) + +/* GT Driver => Pcode commands */ +#define IPC_PUNIT_GTD_ZERO (IPC_PUNIT_GTD_CMD_BASE | 0x00) +#define IPC_PUNIT_GTD_CONFIG (IPC_PUNIT_GTD_CMD_BASE | 0x01) +#define IPC_PUNIT_GTD_READ_ICCP_LIC_CDYN_SCAL (IPC_PUNIT_GTD_CMD_BASE | 0x02) +#define IPC_PUNIT_GTD_WRITE_ICCP_LIC_CDYN_SCAL (IPC_PUNIT_GTD_CMD_BASE | 0x03) +#define IPC_PUNIT_GTD_GET_WM_VAL (IPC_PUNIT_GTD_CMD_BASE | 0x06) +#define IPC_PUNIT_GTD_WRITE_CONFIG_WISHREQ (IPC_PUNIT_GTD_CMD_BASE | 0x07) +#define IPC_PUNIT_GTD_READ_REQ_DUTY_CYCLE (IPC_PUNIT_GTD_CMD_BASE | 0x16) +#define IPC_PUNIT_GTD_DIS_VOL_FREQ_CHG_REQUEST (IPC_PUNIT_GTD_CMD_BASE | 0x17) +#define IPC_PUNIT_GTD_DYNA_DUTY_CYCLE_CTRL (IPC_PUNIT_GTD_CMD_BASE | 0x1a) +#define IPC_PUNIT_GTD_DYNA_DUTY_CYCLE_TUNING (IPC_PUNIT_GTD_CMD_BASE | 0x1c) + +/* ISP Driver => Pcode commands */ +#define IPC_PUNIT_ISPD_ZERO (IPC_PUNIT_ISPD_CMD_BASE | 0x00) +#define IPC_PUNIT_ISPD_CONFIG (IPC_PUNIT_ISPD_CMD_BASE | 0x01) +#define IPC_PUNIT_ISPD_GET_ISP_LTR_VAL (IPC_PUNIT_ISPD_CMD_BASE | 0x02) +#define IPC_PUNIT_ISPD_ACCESS_IU_FREQ_BOUNDS (IPC_PUNIT_ISPD_CMD_BASE | 0x03) +#define IPC_PUNIT_ISPD_READ_CDYN_LEVEL (IPC_PUNIT_ISPD_CMD_BASE | 0x04) +#define IPC_PUNIT_ISPD_WRITE_CDYN_LEVEL (IPC_PUNIT_ISPD_CMD_BASE | 0x05) + +/* Error codes */ +#define IPC_PUNIT_ERR_SUCCESS 0 +#define IPC_PUNIT_ERR_INVALID_CMD 1 +#define IPC_PUNIT_ERR_INVALID_PARAMETER 2 +#define IPC_PUNIT_ERR_CMD_TIMEOUT 3 +#define IPC_PUNIT_ERR_CMD_LOCKED 4 +#define IPC_PUNIT_ERR_INVALID_VR_ID 5 +#define IPC_PUNIT_ERR_VR_ERR 6 + +#if IS_ENABLED(CONFIG_INTEL_PUNIT_IPC) + +int intel_punit_ipc_simple_command(int cmd, int para1, int para2); +int intel_punit_ipc_command(u32 cmd, u32 para1, u32 para2, u32 *in, u32 *out); + +#else + +static inline int intel_punit_ipc_simple_command(int cmd, + int para1, int para2) +{ + return -ENODEV; +} + +static inline int intel_punit_ipc_command(u32 cmd, u32 para1, u32 para2, + u32 *in, u32 *out) +{ + return -ENODEV; +} + +#endif /* CONFIG_INTEL_PUNIT_IPC */ + +#endif diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig index 346f1fd..9948369 100644 --- a/drivers/platform/x86/Kconfig +++ b/drivers/platform/x86/Kconfig @@ -891,4 +891,10 @@ config INTEL_PMC_IPC The PMC is an ARC processor which defines IPC commands for communication with other entities in the CPU. +config INTEL_PUNIT_IPC + tristate "Intel P-Unit IPC Driver" + ---help--- + This driver provides support for Intel P-Unit Mailbox IPC mechanism, + which is used to bridge the communications between kernel and P-Unit. + endif # X86_PLATFORM_DEVICES diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile index 1051372..eea765f 100644 --- a/drivers/platform/x86/Makefile +++ b/drivers/platform/x86/Makefile @@ -59,3 +59,4 @@ obj-$(CONFIG_INTEL_SMARTCONNECT) += intel-smartconnect.o obj-$(CONFIG_PVPANIC) += pvpanic.o obj-$(CONFIG_ALIENWARE_WMI) += alienware-wmi.o obj-$(CONFIG_INTEL_PMC_IPC) += intel_pmc_ipc.o +obj-$(CONFIG_INTEL_PUNIT_IPC) += intel_punit_ipc.o diff --git a/drivers/platform/x86/intel_punit_ipc.c b/drivers/platform/x86/intel_punit_ipc.c new file mode 100644 index 0000000..c78ab57 --- /dev/null +++ b/drivers/platform/x86/intel_punit_ipc.c @@ -0,0 +1,336 @@ +/* + * Driver for the Intel P-Unit Mailbox IPC mechanism + * + * (C) Copyright 2015 Intel Corporation + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * The heart of the P-Unit is the Foxton microcontroller and its firmware, + * which provide mailbox interface for power management usage. + */ + +#include <linux/module.h> +#include <linux/acpi.h> +#include <linux/delay.h> +#include <linux/device.h> +#include <linux/interrupt.h> +#include <linux/platform_device.h> +#include <asm/intel_punit_ipc.h> + +/* IPC Mailbox registers */ +#define DATA_LOW 0x0 +#define INTERFACE 0x4 +#define CMD_RUN (1 << 31) +#define CMD_ERRCODE_MASK 0xFF +#define CMD_PARA1_SHIFT 8 +#define CMD_PARA2_SHIFT 16 +#define DATA_HIGH 0x8 + +#define MAILBOX_REGISTER_SPACE 0x10 +#define CMD_TIMEOUT_SECONDS 1 + +typedef struct { + struct device *dev; + struct mutex lock; + int irq; + struct completion cmd_complete; + void __iomem *base[RESERVED_IPC]; + IPC_TYPE type; +} IPC_DEV; + +static IPC_DEV *punit_ipcdev; + +static inline u32 ipc_read_status(IPC_DEV *ipcdev, IPC_TYPE type) +{ + return readl(ipcdev->base[type] + INTERFACE); +} + +static inline void ipc_write_cmd(IPC_DEV *ipcdev, IPC_TYPE type, u32 cmd) +{ + writel(cmd, ipcdev->base[type] + INTERFACE); +} + +static inline u32 ipc_read_data_low(IPC_DEV *ipcdev, IPC_TYPE type) +{ + return readl(ipcdev->base[type] + DATA_LOW); +} + +static inline u32 ipc_read_data_high(IPC_DEV *ipcdev, IPC_TYPE type) +{ + return readl(ipcdev->base[type] + DATA_HIGH); +} + +static inline void ipc_write_data_low(IPC_DEV *ipcdev, IPC_TYPE type, u32 data) +{ + writel(data, ipcdev->base[type] + DATA_LOW); +} + +static inline void ipc_write_data_high(IPC_DEV *ipcdev, IPC_TYPE type, u32 data) +{ + writel(data, ipcdev->base[type] + DATA_HIGH); +} + +static const char *ipc_err_string(int error) +{ + if (error == IPC_PUNIT_ERR_SUCCESS) + return "no error"; + else if (error == IPC_PUNIT_ERR_INVALID_CMD) + return "invalid command"; + else if (error == IPC_PUNIT_ERR_INVALID_PARAMETER) + return "invalid parameter"; + else if (error == IPC_PUNIT_ERR_CMD_TIMEOUT) + return "command timeout"; + else if (error == IPC_PUNIT_ERR_CMD_LOCKED) + return "command locked"; + else if (error == IPC_PUNIT_ERR_INVALID_VR_ID) + return "invalid vr id"; + else if (error == IPC_PUNIT_ERR_VR_ERR) + return "vr error"; + else + return "unknown error"; +} + +static int intel_punit_ipc_check_status(IPC_DEV *ipcdev, IPC_TYPE type) +{ + int loops = CMD_TIMEOUT_SECONDS * USEC_PER_SEC; + int errcode; + int status; + + if (ipcdev->irq) { + if (!wait_for_completion_timeout(&ipcdev->cmd_complete, + CMD_TIMEOUT_SECONDS * HZ)) { + dev_err(ipcdev->dev, "IPC timed out\n"); + return -ETIMEDOUT; + } + } else { + while ((ipc_read_status(ipcdev, type) & CMD_RUN) && --loops) + udelay(1); + if (!loops) { + dev_err(ipcdev->dev, "IPC timed out\n"); + return -ETIMEDOUT; + } + } + + status = ipc_read_status(ipcdev, type); + errcode = status & CMD_ERRCODE_MASK; + if (errcode) { + dev_err(ipcdev->dev, "IPC failed: %s, IPC_STS=0x%x\n", + ipc_err_string(errcode), status); + return -EIO; + } + + return 0; +} + +/** + * intel_punit_ipc_simple_command() - Simple IPC command + * @cmd: IPC command code. + * @para1: First 8bit parameter, set 0 if not used. + * @para2: Second 8bit parameter, set 0 if not used. + * + * Send a IPC command to P-Unit when there is no data transaction + * + * Return: IPC error code or 0 on success. + */ +int intel_punit_ipc_simple_command(int cmd, int para1, int para2) +{ + IPC_DEV *ipcdev = punit_ipcdev; + IPC_TYPE type; + u32 val; + int ret; + + mutex_lock(&ipcdev->lock); + + reinit_completion(&ipcdev->cmd_complete); + type = (cmd & IPC_PUNIT_CMD_TYPE_MASK) >> IPC_TYPE_OFFSET; + + val = cmd & ~IPC_PUNIT_CMD_TYPE_MASK; + val |= CMD_RUN | para2 << CMD_PARA2_SHIFT | para1 << CMD_PARA1_SHIFT; + ipc_write_cmd(ipcdev, type, val); + ret = intel_punit_ipc_check_status(ipcdev, type); + + mutex_unlock(&ipcdev->lock); + + return ret; +} +EXPORT_SYMBOL(intel_punit_ipc_simple_command); + +/** + * intel_punit_ipc_command() - IPC command with data and pointers + * @cmd: IPC command code. + * @para1: First 8bit parameter, set 0 if not used. + * @para2: Second 8bit parameter, set 0 if not used. + * @in: Input data, 32bit for BIOS cmd, two 32bit for GTD and ISPD. + * @out: Output data. + * + * Send a IPC command to P-Unit with data transaction + * + * Return: IPC error code or 0 on success. + */ +int intel_punit_ipc_command(u32 cmd, u32 para1, u32 para2, u32 *in, u32 *out) +{ + IPC_DEV *ipcdev = punit_ipcdev; + IPC_TYPE type; + u32 val; + int ret; + + mutex_lock(&ipcdev->lock); + + reinit_completion(&ipcdev->cmd_complete); + type = (cmd & IPC_PUNIT_CMD_TYPE_MASK) >> IPC_TYPE_OFFSET; + ipc_write_data_low(ipcdev, type, *in); + + if (type == GTDRIVER_IPC || type == ISPDRIVER_IPC) + ipc_write_data_high(ipcdev, type, *++in); + + val = cmd & ~IPC_PUNIT_CMD_TYPE_MASK; + val |= CMD_RUN | para2 << CMD_PARA2_SHIFT | para1 << CMD_PARA1_SHIFT; + ipc_write_cmd(ipcdev, type, val); + + ret = intel_punit_ipc_check_status(ipcdev, type); + if (ret) + goto out; + *out = ipc_read_data_low(ipcdev, type); + + if (type == GTDRIVER_IPC || type == ISPDRIVER_IPC) + *++out = ipc_read_data_high(ipcdev, type); + +out: + mutex_unlock(&ipcdev->lock); + return ret; +} +EXPORT_SYMBOL_GPL(intel_punit_ipc_command); + +static irqreturn_t intel_punit_ioc(int irq, void *dev_id) +{ + IPC_DEV *ipcdev = (IPC_DEV *)dev_id; + + complete(&ipcdev->cmd_complete); + return IRQ_HANDLED; +} + +static int intel_punit_get_bars(struct platform_device *pdev) +{ + struct resource *res0, *res1; + void __iomem *addr; + int size; + + res0 = platform_get_resource(pdev, IORESOURCE_MEM, 0); + if (!res0) { + dev_err(&pdev->dev, "Failed to get iomem resource\n"); + return -ENXIO; + } + size = resource_size(res0); + if (!devm_request_mem_region(&pdev->dev, res0->start, + size, pdev->name)) { + dev_err(&pdev->dev, "Failed to request iomem resouce\n"); + return -EBUSY; + } + + res1 = platform_get_resource(pdev, IORESOURCE_MEM, 1); + if (!res1) { + dev_err(&pdev->dev, "Failed to get iomem resource1\n"); + return -ENXIO; + } + size = resource_size(res1); + if (!devm_request_mem_region(&pdev->dev, res1->start, + size, pdev->name)) { + dev_err(&pdev->dev, "Failed to request iomem resouce1\n"); + return -EBUSY; + } + + addr = ioremap_nocache(res0->start, + resource_size(res0) + resource_size(res1)); + if (!addr) { + dev_err(&pdev->dev, "Failed to ioremap ipc base\n"); + return -ENOMEM; + } + punit_ipcdev->base[BIOS_IPC] = addr; + addr += MAILBOX_REGISTER_SPACE; + punit_ipcdev->base[GTDRIVER_IPC] = addr; + addr += MAILBOX_REGISTER_SPACE; + punit_ipcdev->base[ISPDRIVER_IPC] = addr; + + return 0; +} + +static int intel_punit_ipc_probe(struct platform_device *pdev) +{ + int irq, ret; + + punit_ipcdev = devm_kzalloc(&pdev->dev, + sizeof(*punit_ipcdev), GFP_KERNEL); + if (!punit_ipcdev) + return -ENOMEM; + + platform_set_drvdata(pdev, punit_ipcdev); + + irq = platform_get_irq(pdev, 0); + if (irq < 0) { + punit_ipcdev->irq = 0; + dev_warn(&pdev->dev, "Invalid IRQ, using polling mode\n"); + } else { + ret = devm_request_irq(&pdev->dev, irq, intel_punit_ioc, + IRQF_NO_SUSPEND, "intel_punit_ipc", + &punit_ipcdev); + if (ret) { + dev_err(&pdev->dev, "Failed to request irq: %d\n", irq); + return ret; + } + punit_ipcdev->irq = irq; + } + + ret = intel_punit_get_bars(pdev); + if (ret) + goto out; + + punit_ipcdev->dev = &pdev->dev; + mutex_init(&punit_ipcdev->lock); + init_completion(&punit_ipcdev->cmd_complete); + +out: + return ret; +} + +static int intel_punit_ipc_remove(struct platform_device *pdev) +{ + IPC_DEV *ipcdev = platform_get_drvdata(pdev); + + iounmap(ipcdev->base[BIOS_IPC]); + + return 0; +} + +static const struct acpi_device_id punit_ipc_acpi_ids[] = { + { "INT34D4", 0 }, + { } +}; + +static struct platform_driver intel_punit_ipc_driver = { + .probe = intel_punit_ipc_probe, + .remove = intel_punit_ipc_remove, + .driver = { + .name = "intel_punit_ipc", + .acpi_match_table = ACPI_PTR(punit_ipc_acpi_ids), + }, +}; + +static int __init intel_punit_ipc_init(void) +{ + return platform_driver_register(&intel_punit_ipc_driver); +} + +static void __exit intel_punit_ipc_exit(void) +{ + platform_driver_unregister(&intel_punit_ipc_driver); +} + +MODULE_AUTHOR("Zha Qipeng <qipeng.zha@intel.com>"); +MODULE_DESCRIPTION("Intel P-Unit IPC driver"); +MODULE_LICENSE("GPL v2"); + +/* Some modules are dependent on this, so init earlier */ +fs_initcall(intel_punit_ipc_init); +module_exit(intel_punit_ipc_exit);
This driver provides support for P-Unit mailbox IPC on Intel platforms. The heart of the P-Unit is the Foxton microcontroller and its firmware, which provide mailbox interface for power management usage. Signed-off-by: Qipeng Zha <qipeng.zha@intel.com> --- change in v7 Update ipc_err_string()'s return type to "const char *" from "char *"; Add terminator in acpi id array. change in v6 Update header file; Update interface of lowlevel register access; Restructure implementation of two command functions; Save IPC private data pointer to pdev's priv; change in v5 Fix commend style in header file; Replace EINVAL with ENODEV in stub functions; Replace ipc_err_sources array with ipc_err_string function; Correct comments: "if invalid" -> "if not used"; Propagate return error of devm_request_irq. change in v4 Fix two code style issues: make /* as a whole line and replace "return ret" with "goto out"; Replace -EINVAL with -ENXIO for failures due to resource. change in v3 Fix compile issue in intel_punit_ipc.h, it happened when built-in and the header file is included in other source file. change in v2 Fix issues in code style and comments; Remove "default y" in Kconfig; Remove some header files; Replace request_mem_region with devm_request_mem_region, and same for request_irq; Change to use prefix of IPC_PUNIT_ to define commands; --- MAINTAINERS | 4 +- arch/x86/include/asm/intel_punit_ipc.h | 101 ++++++++++ drivers/platform/x86/Kconfig | 6 + drivers/platform/x86/Makefile | 1 + drivers/platform/x86/intel_punit_ipc.c | 336 +++++++++++++++++++++++++++++++++ 5 files changed, 447 insertions(+), 1 deletion(-) create mode 100644 arch/x86/include/asm/intel_punit_ipc.h create mode 100644 drivers/platform/x86/intel_punit_ipc.c