[PATCH v1] misc: fastrpc: Move fastrpc driver to misc/fastrpc/

[Dmitry Baryshkov]

On Fri, 21 Jun 2024 at 09:19, Bjorn Andersson <andersson at kernel.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 at quicinc.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.

-- 
With best wishes
Dmitry