Hello Scott,
On 10/28/2014 01:08 PM, Scott Wood wrote:
On Tue, 2014-10-28 at 09:36 -0500, Kumar Gala wrote:
quoted
On Oct 22, 2014, at 9:09 AM, Emil Medve [off-list ref] wrote:
quoted
The Buffer Manager is part of the Data-Path Acceleration Architecture (DPAA).
BMan supports hardware allocation and deallocation of buffers belonging to
pools originally created by software with configurable depletion thresholds.
This binding covers the CCSR space programming model
Signed-off-by: Emil Medve <redacted>
Change-Id: I3ec479bfb3c91951e96902f091f5d7d2adbef3b2
---
.../devicetree/bindings/powerpc/fsl/bman.txt | 98 ++++++++++++++++++++++
1 file changed, 98 insertions(+)
create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/bman.txt
Should these really be in bindings/powerpc/fsl, aren’t you guys using this on ARM SoCs as well?
The hardware on the ARM SoCs is different enough that I'm not sure the
same binding will cover it. That said, putting things under <arch>
should be a last resort if nowhere else fits.
OTC started ported the driver to the the ARM SoC and the feedback has
been that the driver needed minimal changes. The IOMMU has been the only
area of concern, and a small change to the binding has been suggested
Cheers,
On Wed, 2014-10-29 at 16:40 -0500, Emil Medve wrote:
Hello Scott,
On 10/28/2014 01:08 PM, Scott Wood wrote:
quoted
On Tue, 2014-10-28 at 09:36 -0500, Kumar Gala wrote:
quoted
On Oct 22, 2014, at 9:09 AM, Emil Medve [off-list ref] wrote:
quoted
The Buffer Manager is part of the Data-Path Acceleration Architecture (DPAA).
BMan supports hardware allocation and deallocation of buffers belonging to
pools originally created by software with configurable depletion thresholds.
This binding covers the CCSR space programming model
Signed-off-by: Emil Medve <redacted>
Change-Id: I3ec479bfb3c91951e96902f091f5d7d2adbef3b2
---
.../devicetree/bindings/powerpc/fsl/bman.txt | 98 ++++++++++++++++++++++
1 file changed, 98 insertions(+)
create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/bman.txt
Should these really be in bindings/powerpc/fsl, aren’t you guys using this on ARM SoCs as well?
The hardware on the ARM SoCs is different enough that I'm not sure the
same binding will cover it. That said, putting things under <arch>
should be a last resort if nowhere else fits.
OTC started ported the driver to the the ARM SoC and the feedback has
been that the driver needed minimal changes. The IOMMU has been the only
area of concern, and a small change to the binding has been suggested
Do we need something in the binding to indicate device endianness?
If this binding is going to continue to be relevant to future DPAA
generations, I think we really ought to deal with the possibility that
there is more than one datapath instance, by having phandles and/or a
parent container to connect the related components.
-Scott
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTGludXhwcGMtZGV2IFtt
YWlsdG86bGludXhwcGMtZGV2LQ0KPiBib3VuY2VzK3ZhcnVuLnNldGhpPWZyZWVzY2FsZS5jb21A
bGlzdHMub3psYWJzLm9yZ10gT24gQmVoYWxmIE9mIEVtaWwNCj4gTWVkdmUNCj4gU2VudDogVGh1
cnNkYXksIE9jdG9iZXIgMzAsIDIwMTQgMzoxMCBBTQ0KPiBUbzogV29vZCBTY290dC1CMDc0MjE7
IEt1bWFyIEdhbGENCj4gQ2M6IG1hcmsucnV0bGFuZEBhcm0uY29tOyBkZXZpY2V0cmVlQHZnZXIu
a2VybmVsLm9yZzsNCj4gcGF3ZWwubW9sbEBhcm0uY29tOyBjb3JiZXRAbHduLm5ldDsgVGhvcnBl
IEdlb2ZmLVIwMTM2MTsNCj4gaWpjK2RldmljZXRyZWVAaGVsbGlvbi5vcmcudWs7IGxpbnV4LWRv
Y0B2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4cHBjLQ0KPiBkZXZAb3psYWJzLm9yZzsgcm9iaCtkdEBr
ZXJuZWwub3JnDQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggMS80XSBkdC9iaW5kaW5nczogSW50cm9k
dWNlIHRoZSBGU0wgUW9ySVEgRFBBQSBCTWFuDQo+IA0KPiBIZWxsbyBTY290dCwNCj4gDQo+IA0K
PiBPbiAxMC8yOC8yMDE0IDAxOjA4IFBNLCBTY290dCBXb29kIHdyb3RlOg0KPiA+IE9uIFR1ZSwg
MjAxNC0xMC0yOCBhdCAwOTozNiAtMDUwMCwgS3VtYXIgR2FsYSB3cm90ZToNCj4gPj4gT24gT2N0
IDIyLCAyMDE0LCBhdCA5OjA5IEFNLCBFbWlsIE1lZHZlIDxFbWlsaWFuLk1lZHZlQGZyZWVzY2Fs
ZS5jb20+DQo+IHdyb3RlOg0KPiA+Pg0KPiA+Pj4gVGhlIEJ1ZmZlciBNYW5hZ2VyIGlzIHBhcnQg
b2YgdGhlIERhdGEtUGF0aCBBY2NlbGVyYXRpb24gQXJjaGl0ZWN0dXJlDQo+IChEUEFBKS4NCj4g
Pj4+IEJNYW4gc3VwcG9ydHMgaGFyZHdhcmUgYWxsb2NhdGlvbiBhbmQgZGVhbGxvY2F0aW9uIG9m
IGJ1ZmZlcnMNCj4gPj4+IGJlbG9uZ2luZyB0byBwb29scyBvcmlnaW5hbGx5IGNyZWF0ZWQgYnkg
c29mdHdhcmUgd2l0aCBjb25maWd1cmFibGUNCj4gZGVwbGV0aW9uIHRocmVzaG9sZHMuDQo+ID4+
PiBUaGlzIGJpbmRpbmcgY292ZXJzIHRoZSBDQ1NSIHNwYWNlIHByb2dyYW1taW5nIG1vZGVsDQo+
ID4+Pg0KPiA+Pj4gU2lnbmVkLW9mZi1ieTogRW1pbCBNZWR2ZSA8RW1pbGlhbi5NZWR2ZUBGcmVl
c2NhbGUuY29tPg0KPiA+Pj4gQ2hhbmdlLUlkOiBJM2VjNDc5YmZiM2M5MTk1MWU5NjkwMmYwOTFm
NWQ3ZDJhZGJlZjNiMg0KPiA+Pj4gLS0tDQo+ID4+PiAuLi4vZGV2aWNldHJlZS9iaW5kaW5ncy9w
b3dlcnBjL2ZzbC9ibWFuLnR4dCAgICAgICB8IDk4DQo+ICsrKysrKysrKysrKysrKysrKysrKysN
Cj4gPj4+IDEgZmlsZSBjaGFuZ2VkLCA5OCBpbnNlcnRpb25zKCspDQo+ID4+PiBjcmVhdGUgbW9k
ZSAxMDA2NDQNCj4gPj4+IERvY3VtZW50YXRpb24vZGV2aWNldHJlZS9iaW5kaW5ncy9wb3dlcnBj
L2ZzbC9ibWFuLnR4dA0KPiA+Pg0KPiA+PiBTaG91bGQgdGhlc2UgcmVhbGx5IGJlIGluIGJpbmRp
bmdzL3Bvd2VycGMvZnNsLCBhcmVu4oCZdCB5b3UgZ3V5cyB1c2luZyB0aGlzIG9uDQo+IEFSTSBT
b0NzIGFzIHdlbGw/DQo+ID4NCj4gPiBUaGUgaGFyZHdhcmUgb24gdGhlIEFSTSBTb0NzIGlzIGRp
ZmZlcmVudCBlbm91Z2ggdGhhdCBJJ20gbm90IHN1cmUgdGhlDQo+ID4gc2FtZSBiaW5kaW5nIHdp
bGwgY292ZXIgaXQuICBUaGF0IHNhaWQsIHB1dHRpbmcgdGhpbmdzIHVuZGVyIDxhcmNoPg0KPiA+
IHNob3VsZCBiZSBhIGxhc3QgcmVzb3J0IGlmIG5vd2hlcmUgZWxzZSBmaXRzLg0KPiANCj4gT1RD
IHN0YXJ0ZWQgcG9ydGVkIHRoZSBkcml2ZXIgdG8gdGhlIHRoZSBBUk0gU29DIGFuZCB0aGUgZmVl
ZGJhY2sgaGFzIGJlZW4NCj4gdGhhdCB0aGUgZHJpdmVyIG5lZWRlZCBtaW5pbWFsIGNoYW5nZXMu
IFRoZSBJT01NVSBoYXMgYmVlbiB0aGUgb25seSBhcmVhDQo+IG9mIGNvbmNlcm4sIGFuZCBhIHNt
YWxsIGNoYW5nZSB0byB0aGUgYmluZGluZyBoYXMgYmVlbiBzdWdnZXN0ZWQNCklPTU1VIHNwZWNp
ZmljIGJpbmRpbmcgd291bGQgYmUgZGlmZmVyZW50LiBUaGUgYmluZGluZyB3b3VsZCBoYXZlIHRv
IGNvbXBseSB0byB0aGUgYXJtLXNtbXUgYmluZGluZyAod2hpY2ggbmVlZHMgdG8gYmUgdXBkYXRl
ZCkuDQoNCi1WYXJ1bg0K