From patchwork Wed Jan 26 16:24:01 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Arnaud POULIQUEN X-Patchwork-Id: 12725430 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 120B3C28CF5 for ; Wed, 26 Jan 2022 16:24:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236759AbiAZQYb (ORCPT ); Wed, 26 Jan 2022 11:24:31 -0500 Received: from mx07-00178001.pphosted.com ([185.132.182.106]:57468 "EHLO mx07-00178001.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236736AbiAZQY0 (ORCPT ); Wed, 26 Jan 2022 11:24:26 -0500 Received: from pps.filterd (m0241204.ppops.net [127.0.0.1]) by mx07-00178001.pphosted.com (8.16.1.2/8.16.1.2) with ESMTP id 20QCbu9J017387; Wed, 26 Jan 2022 17:24:14 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=foss.st.com; h=from : to : cc : subject : date : message-id : mime-version : content-transfer-encoding : content-type; s=selector1; bh=Fiqxr9WvJc8dTYlWkypJHXgtIa3fflHuloS/kZK9mNg=; b=dIM//TrRaau/P+Q11pVcDuNsRdx3Yg73c6Su4J3X/u2a7J5mvcbjI8BeAhuN7oXSalUX V4/hBR6G94mBjP/nua0Jw9NDJIBtRMUVPMWi4pyW/XMKpS1BI2BsQiEPGNESmlaFC62d H2IugLCvvOAnFOhNcaUtWZ4ayePZvnt2Er4pj0PROMhO4y/KRsl7bkRCrXfxMFs3blME +WAiu2g6it/o9xmFnkloAfvkkxsPtpSpdHDtZkV4TjOqgTZLrpjjlrx2nYARA2c32MYA Ogb7fWOopqdS3SBglmo0yEtT2hIVoNTwb0idlmb6pYwBiygJNR6FifENQXIUK4yyqjmk GQ== Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by mx07-00178001.pphosted.com (PPS) with ESMTPS id 3du26mjr11-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 26 Jan 2022 17:24:14 +0100 Received: from euls16034.sgp.st.com (euls16034.sgp.st.com [10.75.44.20]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 53FCD100038; Wed, 26 Jan 2022 17:24:13 +0100 (CET) Received: from Webmail-eu.st.com (sfhdag2node2.st.com [10.75.127.5]) by euls16034.sgp.st.com (STMicroelectronics) with ESMTP id 47B452291D2; Wed, 26 Jan 2022 17:24:13 +0100 (CET) Received: from localhost (10.75.127.49) by SFHDAG2NODE2.st.com (10.75.127.5) with Microsoft SMTP Server (TLS) id 15.0.1497.26; Wed, 26 Jan 2022 17:24:12 +0100 From: Arnaud Pouliquen To: Bjorn Andersson , Mathieu Poirier CC: , , , Rob Herring , Christoph Hellwig , Stefano Stabellini , Bruce Ashfield , Subject: [RFC PATCH v3 0/4] remoteproc: restructure the remoteproc VirtIO device Date: Wed, 26 Jan 2022 17:24:01 +0100 Message-ID: <20220126162405.1131323-1-arnaud.pouliquen@foss.st.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 X-Originating-IP: [10.75.127.49] X-ClientProxiedBy: SFHDAG2NODE1.st.com (10.75.127.4) To SFHDAG2NODE2.st.com (10.75.127.5) X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.816,Hydra:6.0.425,FMLib:17.11.62.513 definitions=2022-01-26_05,2022-01-26_01,2021-12-02_01 Precedence: bulk List-ID: X-Mailing-List: linux-remoteproc@vger.kernel.org Update from V2 [1]: In order to better handle error cases and to have something more symmetrical between the functions in charge of rvdev initialization/deletion, the patchset has been reworked. - Introduction in the first patch, of rproc_vdev_data structure which allows to better decorrelate the rproc from the management of the rvdev structure. This structure is reused in the last patch of the series for the creation of the remoteproc virtio platform device. - In addition to the previous version, the management of the vring lifecycle has been fully migrated to the remoteproc_virtio.c (rproc_parse_vring, rproc_alloc_vring, rproc_free_vring) [1] https://lkml.org/lkml/2021/12/22/111 Patchset description: This series is a part of the work initiated a long time ago in the series "remoteproc: Decorelate virtio from core"[2] Objective of the work: - Update the remoteproc VirtIO device creation (use platform device) - Allow to declare remoteproc VirtIO device in DT - declare resources associated to a remote proc VirtIO - declare a list of VirtIO supported by the platform. - Prepare the enhancement to more VirtIO devices (e.g I2C, audio, video, ...). For instance be able to declare a I2C device in a virtio-i2C node. - Keep the legacy working! - Try to improve the picture about concerns reported by Christoph Hellwing [3][4] [2] https://lkml.org/lkml/2020/4/16/1817 [3] https://lkml.org/lkml/2021/6/23/607 [4] https://patchwork.kernel.org/project/linux-remoteproc/patch/AOKowLclCbOCKxyiJ71WeNyuAAj2q8EUtxrXbyky5E@cp7-web-042.plabs.ch/ In term of device tree this would result in such hiearchy (stm32mp1 example with 2 virtio RPMSG): m4_rproc: m4@10000000 { compatible = "st,stm32mp1-m4"; reg = <0x10000000 0x40000>, <0x30000000 0x40000>, <0x38000000 0x10000>; memory-region = <&retram>, <&mcuram>,<&mcuram2>; mboxes = <&ipcc 2>, <&ipcc 3>; mbox-names = "shutdown", "detach"; status = "okay"; #address-cells = <1>; #size-cells = <0>; vdev@0 { compatible = "rproc-virtio"; reg = <0>; virtio,id = <7>; /* RPMSG */ memory-region = <&vdev0vring0>, <&vdev0vring1>, <&vdev0buffer>; mboxes = <&ipcc 0>, <&ipcc 1>; mbox-names = "vq0", "vq1"; status = "okay"; }; vdev@1 { compatible = "rproc-virtio"; reg = <1>; virtio,id = <7>; /*RPMSG */ memory-region = <&vdev1vring0>, <&vdev1vring1>, <&vdev1buffer>; mboxes = <&ipcc 4>, <&ipcc 5>; mbox-names = "vq0", "vq1"; status = "okay"; }; }; I have divided the work in 4 steps to simplify the review, This series implements only the step 1: step 1: redefine the remoteproc VirtIO device as a platform device - migrate rvdev management in remoteproc virtio.c, - create a remotproc virtio config ( can be disabled for platform that not use VirtIO IPC. step 2: add possibility to declare and prob a VirtIO sub node - VirtIO bindings declaration, - multi DT VirtIO devices support, - introduction of a remote proc virtio bind device mechanism , => https://github.com/arnopo/linux/commits/step2-virtio-in-DT step 3: Add memory declaration in VirtIO subnode => https://github.com/arnopo/linux/commits/step3-virtio-memories step 4: Add mailbox declaration in VirtIO subnode => https://github.com/arnopo/linux/commits/step4-virtio-mailboxes Arnaud Pouliquen (4): remoteproc: core: Introduce virtio device add/remove functions remoteproc: core: Introduce rproc_register_rvdev function remoteproc: Move rproc_vdev management to remoteproc_virtio.c remoteproc: virtio: Create platform device for the remoteproc_virtio drivers/remoteproc/remoteproc_core.c | 159 +++---------------- drivers/remoteproc/remoteproc_internal.h | 33 +++- drivers/remoteproc/remoteproc_virtio.c | 193 ++++++++++++++++++++--- include/linux/remoteproc.h | 6 +- 4 files changed, 227 insertions(+), 164 deletions(-)