Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp102637ybv; Sat, 22 Feb 2020 00:03:46 -0800 (PST) X-Google-Smtp-Source: APXvYqyHx4FcLo0aq8DzGbsJpoR4LNZGadGVAA74vvAEDVqzG4e9XZhOOy57D1uUVSzGarZxrKkH X-Received: by 2002:a9d:6d81:: with SMTP id x1mr33808387otp.9.1582358626093; Sat, 22 Feb 2020 00:03:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582358626; cv=none; d=google.com; s=arc-20160816; b=m7H33UoJbQuo135OJvkWjbI3eg+0JGmOzeXEk5XO0ESlc3piMff3w77tfP9l930wGu PL6r5y/6H9l6GOyjjCLIZ5gbPgHBvWCnGvhCkSE3QCMnrWmRSre4m4lRKLwDjH/4tTuw PEg0P+NUONGL+nFt5e1Le3KbgmR3SA87qtED7+0LVLGdCbaEbJbOOsmNX3MJmmmClLuL VWkyLbeA3womQN2YsXKBnHmgSc5JEYdI0KZlzUqQxtTNvp5Idghvvwka4yENha10DZc9 etNuGpoAe5wOw6pDmnGLAo3407KP8zZJvhQNPhwqmXus7iHvwzCVpAewS9f54T+0fQgi HTUQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version; bh=hG49V3gOqfZNE3AAtnPNMZfJludAFoZsmYC5k8de9rk=; b=SbZS9NvLugo8J4q7eGg0iiTEvETPlRUh0+9hlC7vYmm/2lPU0VvSqGe+qZ1Z2SYoas tBHyf3VmlMDTQSLz+dwLlIHbYzpQr/NFpwXQn6hQ4bFIQ9AtdDRU4rXW5QeS3sQhou9z pZKfbYxrrj5aQKD9jxL42/CuTauNePXniH0Ak+uVb9d2FfycVYds27Sc7sNVUL+6om0U S50aIdFFRCn1qlOu4TBFkNGLA7H89V7C8wHAv1d54eN3RtnYuLxwq/+tscq5JjBlyrJm gohR3EZxbsW+yxGrniBwHxKtwRDRKVPcov1JZcldyVlB9SHPwLxBGLWVBOpI0GK0i/qn TOPw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t22si2759354otc.167.2020.02.22.00.03.32; Sat, 22 Feb 2020 00:03:46 -0800 (PST) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727334AbgBVIDE (ORCPT + 99 others); Sat, 22 Feb 2020 03:03:04 -0500 Received: from mout.kundenserver.de ([212.227.126.134]:55497 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726808AbgBVIDD (ORCPT ); Sat, 22 Feb 2020 03:03:03 -0500 Received: from mail-lj1-f170.google.com ([209.85.208.170]) by mrelayeu.kundenserver.de (mreue012 [212.227.15.129]) with ESMTPSA (Nemesis) id 1MGQ85-1jDNxT0E8L-00Gmo9; Sat, 22 Feb 2020 09:03:02 +0100 Received: by mail-lj1-f170.google.com with SMTP id w1so4663095ljh.5; Sat, 22 Feb 2020 00:03:01 -0800 (PST) X-Gm-Message-State: APjAAAXzm3mazZhpifv6NLwNUOZwOlo1AXN5boy8wUSX/H3CDKpMt+O5 rZW0g871fIpzP2DTUA4cwHcEtUsYDjUs/bnkz+M= X-Received: by 2002:a2e:8e70:: with SMTP id t16mr24610761ljk.73.1582358581384; Sat, 22 Feb 2020 00:03:01 -0800 (PST) MIME-Version: 1.0 References: <20200220004825.23372-1-scott.branden@broadcom.com> <20200220004825.23372-7-scott.branden@broadcom.com> <20200220074711.GA3261162@kroah.com> In-Reply-To: From: Arnd Bergmann Date: Sat, 22 Feb 2020 09:02:44 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 6/7] misc: bcm-vk: add Broadcom VK driver To: Scott Branden Cc: Greg Kroah-Hartman , Luis Chamberlain , David Brown , Alexander Viro , Shuah Khan , Bjorn Andersson , Shuah Khan , "Rafael J . Wysocki" , "linux-kernel@vger.kernel.org" , linux-arm-msm , Linux FS-devel Mailing List , BCM Kernel Feedback , Olof Johansson , Andrew Morton , Dan Carpenter , Colin Ian King , Kees Cook , Takashi Iwai , "open list:KERNEL SELFTEST FRAMEWORK" , Andy Gross , Desmond Yan , James Hu Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:XZlkbUR4fxvy+eE3fvD5js5E7JSWv9M4hJtyepE/iQGN5bhv2kl LCRDkcdhGgVq9hhYgkCZgDR+VchB2qOw2MftAiiGtTFUU2tweq60mZQa635lfEwtVeEKbWs MnJ61uB+Wp7wWZPjOAtlkBmAImwxQO7Ykpn56BlDB0JVbz66Aa27T17gmP7vhlQd6/sfeSy QsAJR7A4fAvOlUoULX7cg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:vCKx0DV6jsY=:ZsJCmUIHVEjxqelF+v30ky lC0Y/TQGa+3Rw3L57lffpcaWs4ZYYhg5vv9wGqlr5jlabbaOpg8V67KH3ZE8IA2X/mtc9J+zm +EboEKThaasEeUHgCpyTARgb+oHTQ56g3rp/+CsQjvWyy/zTQQCBVgU6n8JjWHRX3V92XBGEH RQ/NcjEF4Xpxec+a++cxJFDCxYMiooJceIVUQK0ypZH9Tjge/LCnt+soje2RgAvYyPbQbI2ZB s/hJH7tSKNQd3OHAgjGQszvL9rhTIVK3KHDrBJ5RTR7jXSm3QJjvnCUu4bIh+beLlODSh5Hpj 3DwCH1bmvrAC19pFXm7+GeKaerf5aOVGe1dWZgBIcpiies54HKXei/5dQ+qwJ4Rghe6+z86PM LOTRPDeMSSIau5D0FPh+/g3FRWjz9rkDaI2cccpJZ7dePCAlgkm+HoQasDKk4caYqTbvbW7bk md5LyLt70Gj1Iqdd/5KpIKLP9hYOH1yTpoYk08qsKv7XjBsChcJDivxd95HrpuuL4KyrmIzhg Cd0DrT7KyLpDyA8K9dkDwPMgRNa+hu86CAkGa7gy/3lCJ8C6ZtllEDFI611rgZW6stxPrfr2F lZ3GXKge51OQZ69LqB16KRYr3kyj0YHkPoQbmyRiI/tRT2N2VWYa2HGrmCgwIwqmVgsECMGap RtZ14uQm+RrA4IzULJoPDdmF3NU6c7EvQCMpRV79y1zUFq9T6HLkt7BsPViE+FtoR5pGtSiTC w8l6oJop0NZNhSkYHu0sKe1Vj+nrZNI7bLi9oFSaMtX9gJRXB9x1XOBrRSLEecrfDX3CMIYp/ iWjjodC82c9+3yzaXUbBiwhSHDAYsYqdIQLoIak8F6KxcPWWTk= Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Feb 21, 2020 at 7:19 PM Scott Branden 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