On 23 April 2017 at 11:17, H. Nikolaus Schaller hns@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@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...