[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAFqt6zYBhzN1RWw1erXuo5x2zU6cq8akXLmfpYdLsvxAp+93OA@mail.gmail.com>
Date: Thu, 5 Jul 2018 10:11:23 +0530
From: Souptick Joarder <jrdr.linux@...il.com>
To: Tomi Valkeinen <tomi.valkeinen@...com>
Cc: airlied@...ux.ie, dri-devel@...ts.freedesktop.org,
linux-kernel@...r.kernel.org, Matthew Wilcox <willy@...radead.org>,
Laurent Pinchart <laurent.pinchart@...asonboard.com>
Subject: Re: [PATCH v2] gpu: drm: omapdrm: Adding new typedef vm_fault_t
On Fri, Jun 8, 2018 at 4:17 PM, Souptick Joarder <jrdr.linux@...il.com> wrote:
> On Fri, Jun 8, 2018 at 11:47 AM, Tomi Valkeinen <tomi.valkeinen@...com> wrote:
>> Hi,
>>
>> On 22/05/18 21:13, Souptick Joarder wrote:
>>> Use new return type vm_fault_t for fault handler. For
>>> now, this is just documenting that the function returns
>>> a VM_FAULT value rather than an errno. Once all instances
>>> are converted, vm_fault_t will become a distinct type.
>>>
>>> Ref-> commit 1c8f422059ae ("mm: change return type to vm_fault_t")
>>>
>>> Previously vm_insert_mixed() returns err which driver
>>> mapped into VM_FAULT_* type. Also return value of
>>> vm_insert_mixed() not handled correctly and 0 was
>>> returned inside fault_2d() as default. The new function
>>> vmf_insert_mixed() will replace this inefficiency by
>>> returning correct VM_FAULT_* type.
>>>
>>> vmf_error() is the newly introduce inline function
>>> in 4.17-rc6.
>>>
>>> Signed-off-by: Souptick Joarder <jrdr.linux@...il.com>
>>> Reviewed-by: Matthew Wilcox <mawilcox@...rosoft.com>
>>> ---
>>> v2: Fixed kbuild error by initialized ret
>>> in fault_2d().
>>>
>>> drivers/gpu/drm/omapdrm/omap_gem.c | 51 +++++++++++++++++---------------------
>>> drivers/gpu/drm/omapdrm/omap_gem.h | 3 ++-
>>> 2 files changed, 25 insertions(+), 29 deletions(-)
>>
>> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@...com>
>>
>> It's too late to get this to 4.18 via my normal routes. If you have
>> other similar patches queued and Linus/maintainers are ok to merge this
>> late, feel free to queue this that way.
>>
>> Otherwise I can pick this up for my 4.19 patches.
>>
>
> 4.19 looks ok. In case, we have pushed this patch into 4.18-rc-x along
> with few others, will notify you.
Tomi, this patch can be merged in 4.19.
Powered by blists - more mailing lists