Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp5532301pxb; Wed, 26 Jan 2022 14:18:55 -0800 (PST) X-Google-Smtp-Source: ABdhPJwkCqaUL7NmiYT7pkEnPM0+/iRaXn+XG/Ck5l4NAIbhs/DKSYk9Hp0jYcMrzYX8lROc0AWr X-Received: by 2002:aa7:c3cd:: with SMTP id l13mr984891edr.93.1643235535571; Wed, 26 Jan 2022 14:18:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643235535; cv=none; d=google.com; s=arc-20160816; b=uhRwIQgAhQpV+jKSNlfo7X8wmrehWu6YZAWbOIWdcvaqnSXgXRVgCO4mPpjO9YzQi+ 4N5Jn3APQcNc6y1/nqkChaByJOOcUzogo7Sfoh4AiOFfO6UBYW0u/jD5gzYQi5lFWlSP HiCZr89grHxIfBMlHRur549gXxIL1nZvra/BUnbkcH4sbwBydF4+sbBbbs8xt8Jwnz8O cJm7BlRFx1g/SEMiFp7PO/f/9T0n5JlUCnxVl2uwEuWbS7ZNUYUDeD7UNYdmuIXEGTxh 3fzPPnTM4P4thGknR69IcvdSz93FK1SBMOpus7lwkVvO/xBWDSXOes5oYHN4wecZChIy pFgQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=Fiqxr9WvJc8dTYlWkypJHXgtIa3fflHuloS/kZK9mNg=; b=lZ+AHUUVnLhGh7pGE3tBhF3m7bHjZVSPfRE1sDXcbhw3Bu9Z7ksxQGcJd04dNbw0gy ZIvERmQKi7DNmKW4hhgHWBtG7dDmF20d/jTySgqVgMrZajBwwbtYAiYaE03c2q9grCL8 99mRnXGxFCQ7hNYN0GeAblrZoqfmywnlW5WAIccGUxbkImsEyNWEY5O9YU8Aw3GIQ4kL 1vY98cGHgv4JOBJVTrpuwMYdHyWb66gFDY81P4n5cTsK18VLLvSVh/iNBT6FhUHsqRmR F1VNEaBKQ1/RRkCi9RB9vqbVoXYzdxMIE0W8FAbDOwMK+TON0+R9ItZmPtxMro8130nw anug== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@foss.st.com header.s=selector1 header.b="dIM//TrR"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=foss.st.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ne16si282455ejc.424.2022.01.26.14.18.30; Wed, 26 Jan 2022 14:18:55 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@foss.st.com header.s=selector1 header.b="dIM//TrR"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=foss.st.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236445AbiAZQYc (ORCPT + 99 others); Wed, 26 Jan 2022 11:24:32 -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 Content-Transfer-Encoding: 8bit Content-Type: text/plain 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-kernel@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(-) -- 2.25.1