Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
From:   Oded Gabbay <oded.gabbay@gmail.com>
Date:   Sun, 31 Jul 2022 14:45:34 +0300
Message-ID: <CAFCwf11=9qpNAepL7NL+YAV_QO=Wv6pnWPhKHKAepK3fNn+2Dg@mail.gmail.com>
Subject: New subsystem for acceleration devices
To:     Yuji Ishikawa <yuji2.ishikawa@toshiba.co.jp>,
        Jiho Chu <jiho.chu@samsung.com>
Cc:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Arnd Bergmann <arnd@arndb.de>,
        "Linux-Kernel@Vger. Kernel. Org" <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hi,
Greg and I talked a couple of months ago about preparing a new accel
subsystem for compute/acceleration devices that are not GPUs and I
think your drivers that you are now trying to upstream fit it as well.

Would you be open/interested in migrating your drivers to this new subsystem ?

Because there were no outstanding candidates, I have done so far only
a basic and partial implementation of the infrastructure for this
subsystem, but if you are willing to join I believe I can finish it
rather quickly.

At start, the new subsystem will provide only a common device
character (e.g. /dev/acX) so everyone will do open/close/ioctl on the
same device character. Also sysfs/debugfs entries will be under that
device and maybe an IOCTL to retrieve information.

In the future I plan to move some of habanalabs driver's code into the
subsystem itself, for common tasks such as memory management, dma
memory allocation, etc.

Of course, you will be able to add your own IOCTLs as you see fit.
There will be a range of IOCTLs which are device-specific (similar to
drm).

wdyt ?

Thanks,
Oded