Re: [PATCH v2 2/2] drm/omap: partial workaround for DRA7xx DMM errata i878

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

Hi Tomi,

On Wednesday, 4 April 2018 13:33:02 EEST Tomi Valkeinen wrote:
> On 04/04/18 13:28, Laurent Pinchart wrote:
> > On Wednesday, 4 April 2018 13:02:04 EEST Tomi Valkeinen wrote:
> >> On 04/04/18 12:51, Laurent Pinchart wrote:
> >>> On Wednesday, 4 April 2018 10:37:05 EEST Tomi Valkeinen wrote:
> >>>> On 04/04/18 00:11, Laurent Pinchart wrote:
> >>>>> I assume access to DMM-mapped buffers to be way more frequent than
> >>>>> access to the DMM registers. If that's the case, this partial
> >>>>> workaround should only slightly lower the probability of system lock-
> >>>>> up. Do you have plans to implement a workaround that will fix the
> >>>>> problem completely ?
> >>>> 
> >>>> CPU only accesses memory via DMM when using TILER 2D buffers, which are
> >>>> not officially supported. For non-2D, the pages are mapped directly to
> >>>> the CPU without DMM in between.
> >>> 
> >>> What is the DMM used for with non-2D then ? Does it need to be setup at
> >>> all ?
> >> 
> >> It creates a contiguous view of memory for IPs without IOMMUs, like DSS.
> > 
> > OK, got it. In that case the CPU accesses don't need to go through the
> > DMM, only the device accesses do, as the CPU will go through the MMU.
> > Sorry for the noise.
> 
> Slightly related, just thinking out loud:
> 
> This is the first part of the work-around. The other part would be to
> make TILER 2D available to the CPU via some kind of indirect access.
> TILER 2D memory is mapped in a custom way to the CPU even now (if I
> recall right, only two pages are mapped at once, with a custom DMM
> mapping for those).
> 
> I think sDMA would be the choice there too, allocating two pages as a
> "cache" and using sDMA to fill and flush those pages.

Thinking out loud too, I suppose we would trigger the sDMA to flush the page 
out when it has to be evicted from the usergart, through the same mechanism we 
use to evict the TILER 2D mapping now. If the sDMA is fast enough it could 
complete before the CPU fills the next page, and we wouldn't have any 
noticeable delay (there would be extra memory bandwidth consumption though).

However, when faulting a page in, we would also need to use sDMA to read the 
data, right ? That sDMA transfer could only be triggered at the time of the 
page fault, so every access resulting in a fault would be delayed by a page-
sized sDMA transfer. I wonder if the resulting performances would be 
acceptable.

> I haven't spent any time on that, as TILER 2D has other issues and is
> not very usable.

Maybe we should just not use it then ;-)

-- 
Regards,

Laurent Pinchart



_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel