On Fri, 21 Jun 2024 at 09:19, Bjorn Andersson <andersson@xxxxxxxxxx> 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@xxxxxxxxxxx/ > > > > > > Signed-off-by: Ekansh Gupta <quic_ekangupt@xxxxxxxxxxx> > > > --- > > > 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
