[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3167776.tAZEmiy1TT@phil>
Date: Sun, 18 Feb 2018 11:53:49 +0100
From: Heiko Stuebner <heiko@...ech.de>
To: linux-rockchip@...ts.infradead.org
Cc: Thierry Escande <thierry.escande@...labora.com>,
Archit Taneja <architt@...eaurora.org>,
Inki Dae <inki.dae@...sung.com>,
Thierry Reding <thierry.reding@...il.com>,
Sandy Huang <hjc@...k-chips.com>,
Sean Paul <seanpaul@...omium.org>,
David Airlie <airlied@...ux.ie>,
Tomasz Figa <tfiga@...omium.org>,
Enric Balletbo i Serra <enric.balletbo@...labora.com>,
Zain Wang <wzz@...k-chips.com>, Lin Huang <hl@...k-chips.com>,
Douglas Anderson <dianders@...omium.org>,
dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
Yakir Yang <ykk@...k-chips.com>,
Ørjan Eide <orjan.eide@....com>,
Mark Yao <mark.yao@...k-chips.com>,
Haixia Shi <hshi@...omium.org>
Subject: Re: [PATCH v3 03/43] drm/rockchip: Respect page offset for PRIME mmap calls
Am Dienstag, 30. Januar 2018, 21:28:33 CET schrieb Thierry Escande:
> From: Ørjan Eide <orjan.eide@....com>
>
> When mapping external DMA-bufs through the PRIME mmap call, we might be
> given an offset which has to be respected. However for the internal DRM
> GEM mmap path, we have to ignore the fake mmap offset used to identify
> the buffer only. Currently the code always zeroes out vma->vm_pgoff,
> which breaks the former.
>
> This patch fixes the problem by moving the vm_pgoff assignment to a
> function that is used only for GEM mmap path, so that the PRIME path
> retains the original offset.
>
> Cc: Daniel Kurtz <djkurtz@...omium.org>
> Signed-off-by: Ørjan Eide <orjan.eide@....com>
> Signed-off-by: Tomasz Figa <tfiga@...omium.org>
> Signed-off-by: Sean Paul <seanpaul@...omium.org>
> Signed-off-by: Thierry Escande <thierry.escande@...labora.com>
> Tested-by: Heiko Stuebner <heiko@...ech.de>
applied to drm-misc.
So I've picked up the "easy" patches that I have read somewhat often
and also tested myself using the lima driver on some Rockchip socs
(rk3036 + mali400 and rk3328 + mali450).
I'll try to also look at the rest but no guarantees on timing as they
look a lot more involved in real graphics-related stuff :-)
Thanks
Heiko
Powered by blists - more mailing lists