From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heiko =?ISO-8859-1?Q?St=FCbner?= Subject: Re: [PATCH] ARM: dts: rockchip: Reserve unusable memory region on rk3066 Date: Tue, 04 Oct 2016 20:56:27 +0200 Message-ID: <2236986.cydz8Jad7F@diego> References: <20161001140939.GA31220@vaio-ubuntu> <2391111.dvDuarNnp9@phil> <81d1fb8b-ee0e-35a7-77db-5e15c3f46449@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <81d1fb8b-ee0e-35a7-77db-5e15c3f46449-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "Linux-rockchip" Errors-To: linux-rockchip-bounces+glpar-linux-rockchip=m.gmane.org-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org To: =?utf-8?B?UGF3ZcWC?= Jarosz Cc: Mark Rutland , linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org List-Id: linux-rockchip.vger.kernel.org SGkgUGF3ZcWCLAoKQW0gRGllbnN0YWcsIDQuIE9rdG9iZXIgMjAxNiwgMTM6NTY6MDcgc2Nocmll YiBQYXdlxYIgSmFyb3N6Ogo+ID4+Pj4gSSBkb24ndCB0aGluayB0aGlzIGlzIGEgc2FuZSB3b3Jr YXJvdW5kLCBidXQgaXQgaXMgYXQgYmVzdCBkaWZmaWN1bHQgdG8KPiA+Pj4+IHRlbGwsIGdpdmVu IHRoZXJlJ3Mgbm8gcmVhc29uIGdpdmVuIGZvciB3aHkgdGhpcyBtZW1vcnkgaXMgdW51c2FibGUu Cj4gPj4+PiAKPiA+Pj4+IEZvciBpbnN0YW5jZSwgaWYgYnVzIGFjY2Vzc2VzIHRvIHRoaXMgYWRk cmVzcyBoYW5nLCB0aGVuIHRoaXMgcGF0Y2gKPiA+Pj4+IG9ubHkKPiA+Pj4+IG1ha2VzIHRoZSBo YW5kIGxlc3MgbGlrZWx5LCBzaW5jZSB0aGUga2VybmVsIHdpbGwgc3RpbGwgbWFwIHRoZSByZWdp b24KPiA+Pj4+IChhbmQKPiA+Pj4+IHRoZXJlZm9yZSB0aGUgQ1BVIGNhbiBwZXJmb3JtIHNwZWN1 bGF0aXZlIGFjY2Vzc2VzKS4KPiA+Pj4+IAo+ID4+Pj4gQXJlIGlzc3VlcyB3aXRoIHRoaXMgbWVt b3J5IGNvbnNpc3RlbnRseSBzZWVuIGluIHByYWN0aWNlPwo+ID4+Pj4gCj4gPj4+PiBDYW4geW91 IGVuYWJsZSBDT05GSUdfTUVNVEVTVCBhbmQgcGFzcyAnbWVtdGVzdCcgdG8gdGhlIGtlcm5lbCwg dG8KPiA+Pj4+IGRldGVybWluZSBpZiB0aGUgbWVtb3J5IGlzIHJldHVybmluZyBlcnJvbmVvdXMg dmFsdWVzPwo+ID4+PiAKPiA+Pj4ganVzdCBmb3IgdGhlIHNha2Ugb2YgY29tcGxldGVuZXNzLCBv biB0aGUgcmszMjg4IHRoZSBpc3N1ZSB3YXMgdGhlIGRtYQo+ID4+PiBub3QKPiA+Pj4gYmVpbmcg YWJsZSB0byBhY2Nlc3MgdGhlIHNwZWNpZmljIG1lbW9yeSByZWdpb24gKGludGVyZXN0aW5nbHkg YWxzbyB0aGUKPiA+Pj4gbGFzdCAxNk1CIGJ1dCBvZiB0aGUgNEdCIGFyZWEgc3VwcG9ydGVkIG9u IHRoZSByazMyODgpLiBTbyBtZW1vcnkgaXRzZWxmCj4gPj4+IHdhcyBvaywganVzdCBkbWEgYWNj ZXNzIHRvIGl0IGZhaWxlZC4KPiA+PiAKPiA+PiBIb3cgb2RkLgo+ID4+IAo+ID4+PiBXZSBkaWRu J3QgZmluZCBhbnkgb3RoZXIgc2FuZSBzb2x1dGlvbiB0byBsaW1pdCB0aGUgZG1hIGFjY2VzcyBp biBhCj4gPj4+IGdlbmVyYWwgd2F5IGF0IHRoZSB0aW1lLCBzbyBvcHRlZCBmb3IganVzdCBibG9j a2luZyB0aGUgbWVtb3J5IHJlZ2lvbgo+ID4+PiAoYXMKPiA+Pj4gaXQgd2FzIHNpbWlsYXJseSBv bmx5Cj4gPj4gCj4gPj4gSSB3YXMgdW5kZXIgdGhlIGltcHJlc3Npb24gdGhhdCBkbWEtcmFuZ2Vz IGNvdWxkIGRlc2NyaWJlIHRoaXMga2luZCBvZgo+ID4+IERNQSBhZGRyZXNzaW5nIGxpbWl0YXRp b24uIFdhcyB0aGVyZSBzb21lIHByb2JsZW0gd2l0aCB0aGF0PyBQZXJoYXBzIHRoZQo+ID4+IGRy aXZlciBpcyBub3QgYWNxdWlyaW5nL2NvbmZpZ3VyaW5nIGl0cyBtYXNrIGNvcnJlY3RseT8KPiA+ IAo+ID4gSSByZW1lbWJlciBsb29raW5nIGF0IChhbmQgdHJ5aW5nKSBkaWZmZXJlbnQgb3B0aW9u cyBiYWNrIHRoZW4uCj4gPiAKPiA+IGRtYS1tYXNrIHdhbnRlZCBwb3dlci1vZi0yIHZhbHVlcyAo c28gaXQncyBlaXRoZXIgNEdCIG9yIDJHQiAob3IgbG93ZXIpKSwKPiA+IHpvbmUtZG1hIHdhcyBh IDMyYml0IChhbmQgbm9uLWR0KSB0aGluZyBhbmQgZG1hLXJhbmdlcyBzZWVtIHRvIHNpbXBseSBh bHNvCj4gPiBjYWxjdWxhdGUgYSBkbWEtbWFzayBmcm9tIHRoZSB2YWx1ZSwgc28geW91J3JlIGRv d24gdG8gMkdCIGFnYWluLgo+ID4gCj4gPiBTbyBqdXN0IGJsb2NraW5nIG9mIHRob3NlIDE2TUIg YXQgdGhlIGVuZCBmb3IgNEdCIGRldmljZXMgc29tZWhvdyBzb3VuZGVkCj4gPiBuaWNlciB0aGFu IGxpbWl0aW5nIGRtYSBhY2Nlc3MgdG8gb25seSBoYWxmIHRoZSBtZW1vcnkuCj4gPiAKPiA+IEkg bWF5IGJlIG92ZXJsb29raW5nIHNvbWV0aGluZyBidXQgdGhhdCB3YXMgd2hhdCBJIGNhbWUgdXAg d2l0aCBsYXN0IHllYXIuCj4gPiAKPiA+IAo+ID4gSGVpa28KPiAKPiBJcyB0aGVyZSBhIGNoYW5j ZSB0byBhY2NlcHQgdGhpcyBwYXRjaD8KPiAKPiBJIGtub3cgaXQncyBub3QgdGhlIGJlc3Qgc29s dXRpb24gdG8gdGhpcyBwcm9ibGVtLCBidXQgaSBkb24ndCBrbm93Cj4gYSBiZXR0ZXIgb25lLgoK dGhlcmUgaXMgYWx3YXlzIGEgImNoYW5jZSIuIEJ1dCB3aXRoIGNoYW5nZXMgbGlrZSB0aGVzZSwg d2UgYWx3YXlzIHRyeSB0byBmaW5kIAphIHJlYWwgY2F1c2UgZmlyc3QsIGJlZm9yZSByZXNvcnRp bmcgdG8gc29sdXRpb25zIGxpa2UgdGhpcy4gU28gaXQncyBkZWZpbml0bHkgCm5vdCBvZmYgdGhl IHRhYmxlLCBidXQgSSdkIGxpa2UgdG8gaW52ZXN0aWdhdGUgZnVydGhlciBmaXJzdCwgc28gdGhh dCB3ZSBkb24ndCAKYWNjdW11bGF0ZSB1bm5lY2Vzc2FyeSBoYWNrcyBvdmVyIHRpbWUuCgpFc3Bl Y2lhbGx5IHRoYXQgeW91ciByZWdpb24gc2VlbXMgdG8gYmUgaW4gdGhlIG1pZGRsZSBvZiB0aGUg ZGVzaWduYXRlZCByYW0gCmFyZWEgaXMgc3RyYW5nZS4KCkNvdWxkIHlvdSBwbGVhc2UgdGVsbCB3 aGljaCBib2FyZCB5b3UncmUgdXNpbmcgKGFuZCBob3cgbXVjaCBtZW1vcnkgaXQgaGFzKQoKClRo YW5rcwpIZWlrbwoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18KTGludXgtcm9ja2NoaXAgbWFpbGluZyBsaXN0CkxpbnV4LXJvY2tjaGlwQGxpc3RzLmluZnJh ZGVhZC5vcmcKaHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51 eC1yb2NrY2hpcAo= From mboxrd@z Thu Jan 1 00:00:00 1970 From: heiko@sntech.de (Heiko =?ISO-8859-1?Q?St=FCbner?=) Date: Tue, 04 Oct 2016 20:56:27 +0200 Subject: [PATCH] ARM: dts: rockchip: Reserve unusable memory region on rk3066 In-Reply-To: <81d1fb8b-ee0e-35a7-77db-5e15c3f46449@gmail.com> References: <20161001140939.GA31220@vaio-ubuntu> <2391111.dvDuarNnp9@phil> <81d1fb8b-ee0e-35a7-77db-5e15c3f46449@gmail.com> Message-ID: <2236986.cydz8Jad7F@diego> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Pawe?, Am Dienstag, 4. Oktober 2016, 13:56:07 schrieb Pawe? Jarosz: > >>>> I don't think this is a sane workaround, but it is at best difficult to > >>>> tell, given there's no reason given for why this memory is unusable. > >>>> > >>>> For instance, if bus accesses to this address hang, then this patch > >>>> only > >>>> makes the hand less likely, since the kernel will still map the region > >>>> (and > >>>> therefore the CPU can perform speculative accesses). > >>>> > >>>> Are issues with this memory consistently seen in practice? > >>>> > >>>> Can you enable CONFIG_MEMTEST and pass 'memtest' to the kernel, to > >>>> determine if the memory is returning erroneous values? > >>> > >>> just for the sake of completeness, on the rk3288 the issue was the dma > >>> not > >>> being able to access the specific memory region (interestingly also the > >>> last 16MB but of the 4GB area supported on the rk3288). So memory itself > >>> was ok, just dma access to it failed. > >> > >> How odd. > >> > >>> We didn't find any other sane solution to limit the dma access in a > >>> general way at the time, so opted for just blocking the memory region > >>> (as > >>> it was similarly only > >> > >> I was under the impression that dma-ranges could describe this kind of > >> DMA addressing limitation. Was there some problem with that? Perhaps the > >> driver is not acquiring/configuring its mask correctly? > > > > I remember looking at (and trying) different options back then. > > > > dma-mask wanted power-of-2 values (so it's either 4GB or 2GB (or lower)), > > zone-dma was a 32bit (and non-dt) thing and dma-ranges seem to simply also > > calculate a dma-mask from the value, so you're down to 2GB again. > > > > So just blocking of those 16MB at the end for 4GB devices somehow sounded > > nicer than limiting dma access to only half the memory. > > > > I may be overlooking something but that was what I came up with last year. > > > > > > Heiko > > Is there a chance to accept this patch? > > I know it's not the best solution to this problem, but i don't know > a better one. there is always a "chance". But with changes like these, we always try to find a real cause first, before resorting to solutions like this. So it's definitly not off the table, but I'd like to investigate further first, so that we don't accumulate unnecessary hacks over time. Especially that your region seems to be in the middle of the designated ram area is strange. Could you please tell which board you're using (and how much memory it has) Thanks Heiko