From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C0940C4360C for ; Tue, 8 Oct 2019 15:59:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9A171206C0 for ; Tue, 8 Oct 2019 15:59:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lixom-net.20150623.gappssmtp.com header.i=@lixom-net.20150623.gappssmtp.com header.b="M/ESIIsD" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726257AbfJHP75 (ORCPT ); Tue, 8 Oct 2019 11:59:57 -0400 Received: from mail-io1-f67.google.com ([209.85.166.67]:32868 "EHLO mail-io1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725908AbfJHP75 (ORCPT ); Tue, 8 Oct 2019 11:59:57 -0400 Received: by mail-io1-f67.google.com with SMTP id z19so37756825ior.0 for ; Tue, 08 Oct 2019 08:59:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lixom-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tBcYZS8wTLJ+jyCTUqfygduDl+keSPK2KmttGIFgonY=; b=M/ESIIsDxB9Ncm/b7SrUpQK2qVva33uQVjzi0rmMNZWq+KjIL4kQkdUI6PDLqU/YO0 NizkAN6jpaDwaYsdMmnkZNXTiTw1jJ+zVkTDYA/lUqABHr4pIaFRqaMSCzBxtVbHR1VZ W5O61xR+bDEC4nuTDqOy/p8AXbBLd8hpsQv8gtlYA7SRZXmD5ks72VKXDo1PFN8cDKDc u1FSmMLttZ1FH2imVoFaRFZGhWVppi2xW4NChmzu3G/5rUR84dHQwCFid99lcEpRkHXZ 32yB2Ijm9S2jk5yGsVvOUma6diTYFfZIsF4IzLIRtWRF67jK0JXedwEtHlt4eLm/N8rT mJDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tBcYZS8wTLJ+jyCTUqfygduDl+keSPK2KmttGIFgonY=; b=SVRELT3bVBgSnuoi53DetlLcdZmra0jJyZ6n4zWLR8ogIJsTXtsyaTmWwLtO8wyMsx Ku95CYav6r/YOUcOv3PwZjpTIGiPbq1QOeWnxHfEEHs2rSnjtuWwB2BYHic6C/tSPQzP yFcTjkxJPaOi6A8HM6IV66tsEBlOAp6AlrqqAe4QpfBecym5DKx2IXeNvnUEI3DCT2ht l5DOtmLJGjTNpNAyqt/DickzXKG34L+Knps6D5LKxjyO8YRn9b3knFUtXb3ZZGt8WzWM X8pjweQR81lcOKRw5wCoVl7hMrPfbkL2XaIhP5X7xWXlF0mCf2R17/mSZbX9PNfEwczk fPlw== X-Gm-Message-State: APjAAAUW4TiXSh3//HIW28lFEkiCRhVLG78d0QNt0N3jZCg9eaHtNYgK JXPtN2Nk6g7yhLFji54Gbcm8UNWYk3dhWNtl5oxwYQ== X-Google-Smtp-Source: APXvYqymrV9utqTVCvOUYGzIJ6y1+AXeNbE8gVyHhEeLwYRevHtWq7pSIXdwblnHIwynvlpahdExjkvZ4QC8O2T4/QY= X-Received: by 2002:a6b:ca85:: with SMTP id a127mr29155336iog.278.1570550395547; Tue, 08 Oct 2019 08:59:55 -0700 (PDT) MIME-Version: 1.0 References: <20190822192451.5983-1-scott.branden@broadcom.com> <20190822192451.5983-6-scott.branden@broadcom.com> <61c3e8a2-b230-844e-466c-ba45b42542a1@ideasonboard.com> In-Reply-To: <61c3e8a2-b230-844e-466c-ba45b42542a1@ideasonboard.com> From: Olof Johansson Date: Tue, 8 Oct 2019 08:59:43 -0700 Message-ID: Subject: Re: [PATCH 5/7] bcm-vk: add bcm_vk UAPI To: kieran.bingham@ideasonboard.com Cc: Scott Branden , Luis Chamberlain , Greg Kroah-Hartman , David Brown , Alexander Viro , Shuah Khan , Bjorn Andersson , Shuah Khan , Arnd Bergmann , "Rafael J . Wysocki" , Linux Kernel Mailing List , linux-arm-msm , linux-fsdevel@vger.kernel.org, BCM Kernel Feedback , Andrew Morton , Dan Carpenter , Colin Ian King , Kees Cook , Takashi Iwai , "open list:KERNEL SELFTEST FRAMEWORK" , Ohad Ben-Cohen Content-Type: text/plain; charset="UTF-8" Sender: linux-arm-msm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org On Tue, Aug 27, 2019 at 7:49 AM Kieran Bingham wrote: > > Hi Scott, > > On 22/08/2019 20:24, Scott Branden wrote: > > Add user space api for bcm-vk driver. > > > > Signed-off-by: Scott Branden > > --- > > include/uapi/linux/misc/bcm_vk.h | 88 ++++++++++++++++++++++++++++++++ > > 1 file changed, 88 insertions(+) > > create mode 100644 include/uapi/linux/misc/bcm_vk.h > > > > diff --git a/include/uapi/linux/misc/bcm_vk.h b/include/uapi/linux/misc/bcm_vk.h > > new file mode 100644 > > index 000000000000..df7dfd7f0702 > > --- /dev/null > > +++ b/include/uapi/linux/misc/bcm_vk.h > > @@ -0,0 +1,88 @@ > > +/* SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) */ > > +/* > > + * Copyright(c) 2018 Broadcom > > + */ > > + > > +#ifndef __UAPI_LINUX_MISC_BCM_VK_H > > +#define __UAPI_LINUX_MISC_BCM_VK_H > > + > > +#include > > +#include > > + > > +struct vk_metadata { > > + /* struct version, always backwards compatible */ > > + __u32 version; > > + > > + /* Version 0 fields */ > > + __u32 card_status; > > +#define VK_CARD_STATUS_FASTBOOT_READY BIT(0) > > +#define VK_CARD_STATUS_FWLOADER_READY BIT(1) > > + > > + __u32 firmware_version; > > + __u32 fw_status; > > + /* End version 0 fields */ > > + > > + __u64 reserved[14]; > > + /* Total of 16*u64 for all versions */ > > +}; > > + > > +struct vk_image { > > + __u32 type; /* Type of image */ > > +#define VK_IMAGE_TYPE_BOOT1 1 /* 1st stage (load to SRAM) */ > > +#define VK_IMAGE_TYPE_BOOT2 2 /* 2nd stage (load to DDR) */ > > + char filename[64]; /* Filename of image */ > > +}; > > + > > +/* default firmware images names */ > > +#define VK_BOOT1_DEF_FILENAME "vk-boot1.bin" > > +#define VK_BOOT2_DEF_FILENAME "vk-boot2.bin" > > + > > +struct vk_access { > > + __u8 barno; /* BAR number to use */ > > + __u8 type; /* Type of access */ > > +#define VK_ACCESS_READ 0 > > +#define VK_ACCESS_WRITE 1 > > + __u32 len; /* length of data */ > > + __u64 offset; /* offset in BAR */ > > + __u32 *data; /* where to read/write data to */ > > +}; > > + > > +struct vk_reset { > > + __u32 arg1; > > + __u32 arg2; > > +}; > > + > > +#define VK_MAGIC 0x5E > > + > > +/* Get metadata from Valkyrie (firmware version, card status, etc) */ > > +#define VK_IOCTL_GET_METADATA _IOR(VK_MAGIC, 0x1, struct vk_metadata) > > + > > +/* Load image to Valkyrie */ > > +#define VK_IOCTL_LOAD_IMAGE _IOW(VK_MAGIC, 0x2, struct vk_image) > > + > > +/* Read data from Valkyrie */ > > +#define VK_IOCTL_ACCESS_BAR _IOWR(VK_MAGIC, 0x3, struct vk_access) > > + > > +/* Send Reset to Valkyrie */ > > +#define VK_IOCTL_RESET _IOW(VK_MAGIC, 0x4, struct vk_reset) > > It sounds a bit like the valkyrie is a generic asynchronous coprocessor, > does it merit using the remoteproc interfaces to control it ? > > Or is it really just a single purpose cell doing video operations ? Remoteproc brings some useful shared functionality, in particular around loading and parsing firmware formats for platforms where the remote processor uses system carved out memory to run, etc. For something like a PCIe device, it *can* be used but it really doesn't bring any immediate benefit, especially if there aren't multiple in-kernel drivers that need to talk to the hardware in an abstracted way. -Olof -Olof