Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20200220004825.23372-1-scott.branden@broadcom.com>
 <20200220004825.23372-7-scott.branden@broadcom.com> <20200220074711.GA3261162@kroah.com>
 <ee53fe6f-53de-87c0-db16-989cc15abbce@broadcom.com>
In-Reply-To: <ee53fe6f-53de-87c0-db16-989cc15abbce@broadcom.com>
From:   Arnd Bergmann <arnd@arndb.de>
Date:   Sat, 22 Feb 2020 09:02:44 +0100
Message-ID: <CAK8P3a0y8RfjEng4AsMr4MAPGMTXduiFOyfUzazgw9c+KVWmYA@mail.gmail.com>
Subject: Re: [PATCH v2 6/7] misc: bcm-vk: add Broadcom VK driver
To:     Scott Branden <scott.branden@broadcom.com>
Cc:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Luis Chamberlain <mcgrof@kernel.org>,
        David Brown <david.brown@linaro.org>,
        Alexander Viro <viro@zeniv.linux.org.uk>,
        Shuah Khan <shuah@kernel.org>,
        Bjorn Andersson <bjorn.andersson@linaro.org>,
        Shuah Khan <skhan@linuxfoundation.org>,
        "Rafael J . Wysocki" <rafael@kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        linux-arm-msm <linux-arm-msm@vger.kernel.org>,
        Linux FS-devel Mailing List <linux-fsdevel@vger.kernel.org>,
        BCM Kernel Feedback <bcm-kernel-feedback-list@broadcom.com>,
        Olof Johansson <olof@lixom.net>,
        Andrew Morton <akpm@linux-foundation.org>,
        Dan Carpenter <dan.carpenter@oracle.com>,
        Colin Ian King <colin.king@canonical.com>,
        Kees Cook <keescook@chromium.org>,
        Takashi Iwai <tiwai@suse.de>,
        "open list:KERNEL SELFTEST FRAMEWORK" 
        <linux-kselftest@vger.kernel.org>, Andy Gross <agross@kernel.org>,
        Desmond Yan <desmond.yan@broadcom.com>,
        James Hu <james.hu@broadcom.com>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Fri, Feb 21, 2020 at 7:19 PM Scott Branden
<scott.branden@broadcom.com> wrote:
> On 2020-02-19 11:47 p.m., Greg Kroah-Hartman wrote:

> > Have you worked with the V4L developers to tie this into the proper
> > in-kernel apis for this type of functionality?
> We looked at the V4L model doesn't have any support for anything we are
> doing in this driver.
> We also want a driver that doesn't care about video.  It could be
> offloading crypto or other operations.
> We talked with Olof about all of this previously and he said leave it as
> a misc driver for now.
> He was going to discuss at linux plumbers conference that we need some
> sort of offload engine model that such devices could fit into.

I see. Have you looked at the "uacce" driver submission? It seems
theirs is similar enough that there might be some way to share interfaces.

> > Using a tty driver seems like the totally incorrect way to do this, what
> > am I missing?
> tty driver is used to provide console access to the processors running
> on vk.
> Data is sent using the bcm_vk_msg interface by read/write operations
> from user space.
> VK then gets the messages and DMA's the data to/from host memory when
> needed to process.

In turn here, it sounds like you'd want to look at what drivers/misc/mic/
and the mellanox bluefield drivers are doing. As I understand, they have the
same requirements for console, but have a nicer approach of providing
abstract 'virtio' channels between the PCIe endpoint and the host, and
then run regular virtio based drivers (console, tty, block, filesystem,
network, ...) along with application specific ones to provide the custom
high-level protocols. This is also similar to what the drivers/pci/endpoint
(from the other end) as the drivers/ntb (pci host on both ends) frameworks
and of course the rpmsg/remoteproc framework do.

In the long run, I would want much more consolidation between the
low-level parts of all these frameworks, but moving your high-level
protocols to the same virtio method would sound like a step in the
direction towards a generialized framework and easier sharing of
the abstractions.

       Arnd