[Letux-kernel] regression: drm/omapdrm: Move commit_modeset_enables() before commit_planes()

[Matthijs van Duin]

On 23 April 2017 at 11:17, H. Nikolaus Schaller <hns at goldelico.com> wrote:
> Hi Matthijs,
> [reduced list audience since this is not (yet) an LKML topic].
>
> Am 23.04.2017 um 01:52 schrieb Matthijs van Duin <matthijsvanduin at gmail.com>:
> > It looks like the reasoning is something along the lines of: the patch
> > forces buffers to be pinned at allocation time, hence
> > omap_gem_{get,put}_paddr should only take/drop *additional* references
> > and never let the refcount hit zero, which instead happens in free.
>
> and this is triggered on OMAP3 by some ioctls from Xorg because we also skip
> TILER setup.

Yes, because when the first round of obvious breakage due to my
patches came around, you ignored my plea to *not* *merge* *them* and
instead patched on top of it, which now caused further breakage.


> To be self-critical: I also don't ever see all side-effects of my work (you know the Pyra hardware issues...).
> Nobody can. This is why peer-review was invented.

Except I never asked for "peer-review" since I already stated very
clearly and unambiguously that these patches were incredibly hacky and
unsuitable for merging. This was never an oversight. The patches had
very specific goals: to confirm that the TILER slowness on omap5 was
largely due to software (and fixable in software) rather than due to
the hardware itself, and to get a demo working. It succeeded in these
goals.

Since then this work hasn't received much attention anymore since hw
issues had higher priority. Also, as I've said previously, I'd regard
fixing the dma-buf api for tiled buffers to be the highest priority
task w.r.t. tiler-related kernel stuff currently, and I think that
should also yield some of the tools necessary to properly deal with a
tiled fbdev.

I don't even really know why I'm trying to explain this again since
I'm pretty sure I've already said all this before...