[Letux-kernel] Looking for guidance/hints for fixing/implementing/understanding Tiler

[Russell Mullens]

On Thu, Jun 20, 2019 at 3:49 PM Matthijs van Duin <matthijsvanduin at gmail.com>
wrote:

> > > It's currently hooked up to a HDMI display but I thought that would
> > > be enough to get rotation working for all output types.
>
> It should and I've used the uEVM for most development and testing,
> although we've had a weird issue specific to DSI.  I don't really
> remember the details, other than that I fixed it by reverting mainline
> commit 865afb11949e "drm/fb-helper: reject any changes to the fbdev"
>
>
> > > I hope that I'm correct that Tiler code is located in
> > > /drivers/gpu/drm/omapdrm. What I'm not sure of is where I need to be
> > > fixing the 'problem'.
> >
> > The question is what you consider as "the problem".
>
> My patches definitely still have plenty of open issues, some minor while
> others make it impossible to mainline them in their current form.
>
> (For an overview of my patches see
> https://www.pyra-handheld.com/pipermail/kernel/2017-March/001747.html )
>
> patch/tiler-memtype:
>
> Instead of letting userspace control the memory type directly, it may be
> nicer to allow userspace to promise constraints on its usage (at the
> very least "will never read from userspace mapping", but it may be nice
> to add "will never write to userspace mapping" for symmetry, which if
> combined imply that no userspace mapping is needed) and select optimal
> memory type based on those constraints (+ whether or not the platform
> suffers from the tiler/cortex-a15 erratum).
>
> patch/tiler-fast:
>
> To avoid the performance penalty from frequent page faults, I forcibly
> pin tiled buffers as soon as they're allocated.  This won't be
> acceptable upstream since the page fault mechanism, while slow as fuck,
> was used because of issues with running out of TILER (or technically
> PAT) memory space, probably in part because tiled ("2d") and non-tiled
> ("1d") competed for the same space prior to omap5.  It may be desirable
> to see if better memory/performance trade-offs are possible than my
> aggressive pin-on-allocate strategy, or at the very least it needs to be
> controlled by a module parameter (with the current mainline behaviour as
> default).
>
> patch/tiler-buf-fbdev:
>
> This one is a just a big mess.  Forcing the legacy fbdev to be 8192
> pixels wide to make it physically contiguous in tiler memory is
> completely excessive and unnecessary, and was just a quick hack to get
> it working asap.  The proper fix would be to properly implement kmap for
> tiled buffers (part of the dma-buf API and currently horribly broken)
> and use that to map the buffer contiguously into kernel virtual memory.
>
> For mainline it will also need to be optional, since other targets may
> be not care about fbdev rotation and want to avoid wasting tiler memory.
> An interesting idea I had was that it should be possible to initially
> allocate framebuffers in non-tiled memory and move them to tiled memory
> the first time a rotated view is requested, but this would add a lot of
> complexity and it would still require the pitch (in bytes) to be rounded
> up to the page size (since this can't be changed later) hence it
> wouldn't be zero-cost to those who don't care about rotation.
>
> patch/tiler-fbdev:
>
> There is now a mainline mechanism to allow a panel to specify its
> natural orientation, and we should move to using that instead of a
> module parameter (if we haven't already).  Last time I worked on this
> mainline was still lacking support for sideways rotations, so that part
> of the patch should move to mainline unless there's some reason the
> approach I used isn't acceptable for mainline (in which case any
> objections will need to be addressed).
>
> other issues:
>
> dma-buf export of tiled buffers is currently broken.  I've started work
> on that in the past, but I don't remember how far I got.  I'd need to
> dig around in my work-in-progress.
>
>
> > > I think my problem is that I don't understand the linux frameworks
> > > around either memory allocation or display subsystems
> > > (GEM/DRI/DRM/other?) and I don't know where to go looking to start
> > > understanding them. I'm not even sure if it could be a DMA issue
> > > that I should be looking at.
>
> So, to clarify: rotation using TILER works in mainline, but
>
> 1. the performance of userspace mappings of tiled buffers is abysmal, in
> part due to generating excessive page faults (only two pages are mapped
> to userspace at any given time) and in part due to using an erratum on
> omap5 and vayu (dra7xx/am57xx) resulting from the way the Cortex-A15
> interacts with TILER, for which the workaround in mainline is far more
> detrimental to performance than it needs to be.
>
> 2. rotation isn't supported for the legacy fbdev.  (as mentioned above,
> some mainline support has been introduced at some point, but this
> doesn't suffice yet)
>
>
> > Well, the main resource is Matthijs' knowledge. Unfortunately he does
> > not have much time to discuss anything and I am not even sure if he
> > follows these lists.
>
> I try to, and sharing what I know is the least I can do.
>
>
> Matthijs
>

Perfect. Thanks to both Matthijs and Nikolaus  for all the information. Has
definitely given me a lot to go back over and review.
I was stuck on 4.19.24 for a long time because I didn't want the base to be
moving underneath me whilst I tried to get a fundamental understanding. I
have just updated but haven't had a chance to push the new build to the
device.

Sorry for not signing up to the mailing lists properly when I first sent
this message. It has been corrected.

I'll go back into my hole and see what I can dig up.

-- 
Russell Mullens
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.goldelico.com/pipermail/letux-kernel/attachments/20190620/4b3a780b/attachment.html>