[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6f59552d-d7a3-5e05-3465-e707c1b7eaf2@quicinc.com>
Date: Fri, 21 Jun 2024 09:40:09 -0600
From: Jeffrey Hugo <quic_jhugo@...cinc.com>
To: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
Bjorn Andersson
<andersson@...nel.org>
CC: Ekansh Gupta <quic_ekangupt@...cinc.com>,
Oded Gabbay
<ogabbay@...nel.org>, <srinivas.kandagatla@...aro.org>,
<linux-arm-msm@...r.kernel.org>, <gregkh@...uxfoundation.org>,
<quic_bkumar@...cinc.com>, <linux-kernel@...r.kernel.org>,
<quic_chennak@...cinc.com>, <dri-devel@...ts.freedesktop.org>,
Daniel Vetter
<daniel@...ll.ch>, Dave Airlie <airlied@...il.com>
Subject: Re: [PATCH v1] misc: fastrpc: Move fastrpc driver to misc/fastrpc/
On 6/21/2024 5:19 AM, Dmitry Baryshkov wrote:
> On Fri, 21 Jun 2024 at 09:19, Bjorn Andersson <andersson@...nel.org> wrote:
>>
>> On Wed, Jun 12, 2024 at 09:28:39PM GMT, Dmitry Baryshkov wrote:
>>> On Wed, Jun 12, 2024 at 12:17:28PM +0530, Ekansh Gupta wrote:
>>>> Move fastrpc.c from misc/ to misc/fastrpc/. New C files are planned
>>>> to be added for PD notifications and other missing features. Adding
>>>> and maintaining new files from within fastrpc directory would be easy.
>>>>
>>>> Example of feature that is being planned to be introduced in a new C
>>>> file:
>>>> https://lore.kernel.org/all/20240606165939.12950-6-quic_ekangupt@quicinc.com/
>>>>
>>>> Signed-off-by: Ekansh Gupta <quic_ekangupt@...cinc.com>
>>>> ---
>>>> MAINTAINERS | 2 +-
>>>> drivers/misc/Kconfig | 13 +------------
>>>> drivers/misc/Makefile | 2 +-
>>>> drivers/misc/fastrpc/Kconfig | 16 ++++++++++++++++
>>>> drivers/misc/fastrpc/Makefile | 2 ++
>>>> drivers/misc/{ => fastrpc}/fastrpc.c | 0
>>>> 6 files changed, 21 insertions(+), 14 deletions(-)
>>>> create mode 100644 drivers/misc/fastrpc/Kconfig
>>>> create mode 100644 drivers/misc/fastrpc/Makefile
>>>> rename drivers/misc/{ => fastrpc}/fastrpc.c (100%)
>>>
>>> Please consider whether it makes sense to move to drivers/accel instead
>>> (and possibly writing a better Kconfig entry, specifying that the driver
>>> is to be used to offload execution to the DSP).
>>>
>>
>> Wouldn't this come with the expectation of following the ABIs of
>> drivers/accel and thereby breaking userspace?
>
> As I wrote earlier, that depends on the accel/ maintainers decision,
> whether it's acceptable to have non-DRM_ACCEL code underneath.
> But at least I'd try doing that on the grounds of keeping the code at
> the proper place in the drivers/ tree, raising awareness of the
> FastRPC, etc.
> For example current fastrpc driver bypasses dri-devel reviews, while
> if I remember correctly, at some point it was suggested that all
> dma-buf-handling drivers should also notify the dri-devel ML.
>
> Also having the driver under drivers/accels makes it possible and
> logical to implement DRM_ACCEL uAPI at some point. In the ideal world
> we should be able to declare existing FastRPC uAPI as legacy /
> deprecated / backwards compatibility only and migrate to the
> recommended uAPI approach, which is DRM_ACCEL.
>
I suspect Vetter/Airlie need to be involved in this.
Its my understanding that accelerator drivers are able to reside in misc
as long as there is no use of dma-buf. Use of dma-buf means they need
to be in drm/accel.
There is precedent for moving a driver from misc to accel (HabanaLabs).
Right now, I'm not aware that fastRPC meets the requirements for
drm/accel. There is an open source userspace driver, but I'm not aware
of an open source compiler. From what I know of the architecture, it
should be possible to utilize upstream LLVM to produce one.
-Jeff
Powered by blists - more mailing lists