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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 7DACAC54E64 for ; Mon, 25 Mar 2024 17:14:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=8f9QtW3M45n2rWg2E8/d/wtjgAHuvgMaUg+aO8s6Y2E=; b=lDnRIlgPEx2HZa mhFl+10jDF7cqAFvn73y12nZ5QOOVDUsCNfwNXXr1oQFZFJ1GbpgWdJe31h287aFHQmrL1ByTl+7q TaqkuiKlp74jTPnK/dCCokdvEpxT5YZMhcKzPNbWZ80Aef6B99w35woHzkbcLAXsixBEFTrfjtrqT OOzPU77sY5X3I7eB92Gp/OAxbcNU1fmmsN4INSsm8hbhga9fP/kwGBRAUCRB9ds6BSC0BXo0DokYk OYAWn7jxABFbRKhn31/2aQG6My10gVHO7cbLGjPyNrpSIsSob+YYoDktVzvhi87OzQdgax95iwx4W mk3r9hqhI5xLSfgQ1ecg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rontV-00000000yuP-0577; Mon, 25 Mar 2024 17:13:57 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rontP-00000000yqE-1Yfi for linux-arm-kernel@lists.infradead.org; Mon, 25 Mar 2024 17:13:55 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 833E92F4; Mon, 25 Mar 2024 10:14:21 -0700 (PDT) Received: from e130802.arm.com (unknown [10.57.72.91]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E16353F64C; Mon, 25 Mar 2024 10:13:44 -0700 (PDT) Date: Mon, 25 Mar 2024 17:13:39 +0000 From: Abdellatif El Khlifi To: Mathieu Poirier Cc: Sudeep Holla , Abdellatif El Khlifi , Bjorn Andersson , Rob Herring , Liviu Dudau , Lorenzo Pieralisi , Krzysztof Kozlowski , Conor Dooley , Drew.Reed@arm.com, Adam.Johnston@arm.com, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-remoteproc@vger.kernel.org Subject: Re: [PATCH 1/3] remoteproc: Add Arm remoteproc driver Message-ID: <20240325171339.GA368569@e130802.arm.com> References: <20240307194026.GA355455@e130802.arm.com> <20240311114442.GA82865@e130802.arm.com> <20240312173252.GA38992@e130802.arm.com> <20240313171756.GA82165@e130802.arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240325_101351_879795_EDE5BC52 X-CRM114-Status: GOOD ( 36.50 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Mathieu, > > > > > > > > This is an initial patchset for allowing to turn on and off the remote processor. > > > > > > > > The FW is already loaded before the Corstone-1000 SoC is powered on and this > > > > > > > > is done through the FPGA board bootloader in case of the FPGA target. Or by the Corstone-1000 FVP model > > > > > > > > (emulator). > > > > > > > > > > > > > > > >From the above I take it that booting with a preloaded firmware is a > > > > > > > scenario that needs to be supported and not just a temporary stage. > > > > > > > > > > > > The current status of the Corstone-1000 SoC requires that there is > > > > > > a preloaded firmware for the external core. Preloading is done externally > > > > > > either through the FPGA bootloader or the emulator (FVP) before powering > > > > > > on the SoC. > > > > > > > > > > > > > > > > Ok > > > > > > > > > > > Corstone-1000 will be upgraded in a way that the A core running Linux is able > > > > > > to share memory with the remote core and also being able to access the remote > > > > > > core memory so Linux can copy the firmware to. This HW changes are still > > > > > > This is why this patchset is relying on a preloaded firmware. And it's the step 1 > > > > > > of adding remoteproc support for Corstone. > > > > > > > > > > > > > > > > Ok, so there is a HW problem where A core and M core can't see each other's > > > > > memory, preventing the A core from copying the firmware image to the proper > > > > > location. > > > > > > > > > > When the HW is fixed, will there be a need to support scenarios where the > > > > > firmware image has been preloaded into memory? > > > > > > > > No, this scenario won't apply when we get the HW upgrade. No need for an > > > > external entity anymore. The firmware(s) will all be files in the linux filesystem. > > > > > > > > > > Very well. I am willing to continue with this driver but it does so little that > > > I wonder if it wouldn't simply be better to move forward with upstreaming when > > > the HW is fixed. The choice is yours. > > > > > > > I think Robin has raised few points that need clarification. I think it was > > done as part of DT binding patch. I share those concerns and I wanted to > > reaching to the same concerns by starting the questions I asked on corstone > > device tree changes. > > > > I also agree with Robin's point of view. Proceeding with an initial > driver with minimal functionality doesn't preclude having complete > bindings. But that said and as I pointed out, it might be better to > wait for the HW to be fixed before moving forward. We checked with the HW teams. The missing features will be implemented but this will take time. The foundation driver as it is right now is still valuable for people wanting to know how to power control Corstone external systems in a future proof manner (even in the incomplete state). We prefer to address all the review comments made so it can be merged. This includes making the DT binding as complete as possible as you advised. Then, once the HW is ready, I'll implement the comms and the FW reload part. Is that OK please ? Cheers, Abdellatif _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel