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 18088C6FD1F for ; Tue, 26 Mar 2024 14:21:09 +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:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=atfG22PSLykyWTsPNyEU47cYFxa7veyX4s/Wiw3AfpQ=; b=EUWAC5it7lMNir UF2alWTegCHryfj24b0PaeEWUvR3qZ66IACNXnTgbUey0RiIyPRodRgS6BRbGfXcpQ++7KiSTL2HP 3tDRvdY1CAsm1cZFXasObmgfOFmYH2XVdMIqrPT1/44r0+5g7mXJYuSPWMKYYmE4K/2+zpK9bWykd +ijVrkRqBfYDGl4ywK5aQKUPLV9+SiDrzr6VPo0kfx1cgyDL98vs8vA1d1CC7fZCLgiQFyd0gJ0vh oBrGQmkbyYvDwaCE8/XyO8/kckwCpUAI58nJ6NC/2HacNYddE4Beuy5vtvW1OV9DPX3coM38GDdAC u4yTF0sHHLmMi6V60Vcw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rp7fb-00000004tZE-1GwG; Tue, 26 Mar 2024 14:20:55 +0000 Received: from mail-ed1-x52d.google.com ([2a00:1450:4864:20::52d]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rp7fY-00000004tXT-1d7Z for linux-arm-kernel@lists.infradead.org; Tue, 26 Mar 2024 14:20:53 +0000 Received: by mail-ed1-x52d.google.com with SMTP id 4fb4d7f45d1cf-56bf6418434so3974798a12.0 for ; Tue, 26 Mar 2024 07:20:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1711462849; x=1712067649; darn=lists.infradead.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=w0pAKQRmRJlibruDxzELT+hsaTaozLHFzCa7oaB4xn8=; b=ue4nJcriShLoIKRU8utW4nX1czykMWB8EQ5ufatDHcmwFqYnTQWcjj5oKRG+YvtLWv SWKY4J0mOjzUrT6AqO7IVQeJNGdc8ecKp/nkR2QDg/iNpkQoESBbJELe5KGqbqQO1QEX rX6yHAJSQ4ADgp1e91quYIj9FxriESsdi4P6iykVcOgBEewc4W7gPGQxAmQJRwXPNZCT bS6ePDj8LCGoKu4xFhx/XYLzIWYJj7wq0XFCAgnEedGQXU3nf6siXwa+rlaVi2lAwl/i jIhv7dJ5cKfBArjEXLwK4mH/fFO36RVx4CvVan8pqTzHws0vOe8V9Kd0jLKZoBw6N2Fu gS+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711462849; x=1712067649; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=w0pAKQRmRJlibruDxzELT+hsaTaozLHFzCa7oaB4xn8=; b=lQEk+ONNVWPQk2uexCEU0GB31oGsvsDU6pbhAOW6K1weuOS9sEV4ta19Ys3fPAErpu qod52huLZb1pLevbaxCXqw5N8kG1ZNkPhGsVIk6MS66FLXtKC0QqtbpCo38oEXrK5fW8 tsz9K4m8vSL0/RkhstORk/ttSLaCLzOq3FkqH4xXs3mpgf0+siBQi6hgYKTrEh56QpCE s5c9KTRJrwLcdmQTroo7y4UTjbRZdjDjax5F0jkxsBnb1LoqpzaOzskH3PPZN22ZifZp R/f2huvMHh5y+u1bEG6I4h4IbNKzwgYP69SXTwfiUfeial+7bofpXSu02Umth0c84+jl Hx+A== X-Forwarded-Encrypted: i=1; AJvYcCWLLtjmM8VHZKpM0wo1cR+GQVPyWEnn/pDJ5cfM4DgLXFJcnIF0XKM5nfdBR79fmtTlB+jIeQ3NERLka110Fd7Q6Mw7xbtLAUeowHGx/ixhK7Y56Mw= X-Gm-Message-State: AOJu0YywMOmnsR7aVk6Yt9rJghc4TOrmNWhnYDuCgXZehsvWA8WVeCof 6eMhR90yt1MZPh2arSgKRbHqZEJFGvTOcC+FMP/CX9GSHV7njPsr79Gx5lmWSUomuP3VWTbNnfI 5+n/9UuJFlZU5GeFgA748YPvViT8a51bjUaxZ8w== X-Google-Smtp-Source: AGHT+IHUzEZjvpgRrsCaJghKSKw3iJjB0Ths2J/HVSVaWGgZXcyLBL9k9H9rRvQGerf20MW83Wx/xJluM2WUtm1Yl3c= X-Received: by 2002:a50:9f4a:0:b0:56c:19d2:85be with SMTP id b68-20020a509f4a000000b0056c19d285bemr3317223edf.11.1711462848915; Tue, 26 Mar 2024 07:20:48 -0700 (PDT) MIME-Version: 1.0 References: <20240307194026.GA355455@e130802.arm.com> <20240311114442.GA82865@e130802.arm.com> <20240312173252.GA38992@e130802.arm.com> <20240313171756.GA82165@e130802.arm.com> <20240325171339.GA368569@e130802.arm.com> In-Reply-To: <20240325171339.GA368569@e130802.arm.com> From: Mathieu Poirier Date: Tue, 26 Mar 2024 08:20:37 -0600 Message-ID: Subject: Re: [PATCH 1/3] remoteproc: Add Arm remoteproc driver To: Abdellatif El Khlifi Cc: Sudeep Holla , 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240326_072052_493883_B459236C X-CRM114-Status: GOOD ( 39.67 ) 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 On Mon, 25 Mar 2024 at 11:13, Abdellatif El Khlifi wrote: > > 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 ? > I'm in agreement with that plan as long as we agree the current preloaded heuristic is temporary and is not a valid long term scenario. > Cheers, > Abdellatif _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel