Re: [PATCH] ARM: dts: rockchip: Reserve unusable memory region on rk3066

["Paweł Jarosz" <paweljarosz3691-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

>>>> 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.