Re: [PATCH 3/3] dt-bindings: remoteproc: Add Arm remoteproc

From: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc: Robin Murphy <robin.murphy@arm.com>,
	Bjorn Andersson <andersson@kernel.org>,
	Mathieu Poirier <mathieu.poirier@linaro.org>,
	Rob Herring <robh+dt@kernel.org>,
	Liviu Dudau <liviu.dudau@arm.com>,
	Sudeep Holla <sudeep.holla@arm.com>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Conor Dooley <conor+dt@kernel.org>,
	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 3/3] dt-bindings: remoteproc: Add Arm remoteproc
Date: Thu, 14 Mar 2024 15:20:18 +0000	[thread overview]
Message-ID: <20240314152018.GA41711@e130802.arm.com> (raw)
In-Reply-To: <d3b7fd09-76ef-42b3-aaf9-de0369a28e03@linaro.org>

Hi Krzysztof,

On Thu, Mar 14, 2024 at 02:56:53PM +0100, Krzysztof Kozlowski wrote:
> On 14/03/2024 14:49, Abdellatif El Khlifi wrote:
> >> Frankly at the moment I'd be inclined to say it isn't even a remoteproc
> >> binding (or driver) at all, it's a reset controller. Bindings are a contract
> >> for describing the hardware, not the current state of Linux driver support -
> >> if this thing still needs mailboxes, shared memory, a reset vector register,
> >> or whatever else to actually be useful, those should be in the binding from
> >> day 1 so that a) people can write and deploy correct DTs now, such that
> >> functionality becomes available on their systems as soon as driver support
> >> catches up, and b) the community has any hope of being able to review
> >> whether the binding is appropriately designed and specified for the purpose
> >> it intends to serve.
> > 
> > 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).
> > 
> > The plan for the driver is as follows:
> > 
> >     Step 1: provide a foundation driver capable of turning the core on/off
> >     Step 2: provide mailbox support for comms
> >     Step 3: provide FW reload capability
> > 
> > Steps 2 & 3 are waiting for a HW update so the Cortex-A35 (running Linux) can
> > share memory with the remote core.
> > 
> > So, when memory sharing becomes available in the FPGA and FVP the
> > DT binding will be upgraded with:
> > 
> >     - mboxes property specifying the RX/TX mailboxes (based on MHU v2)
> >     - memory-region property describing the virtio vrings
> > 
> > Currently the mailbox controller does exist in the HW but is not
> > usable via virtio (no memory sharing available).
> > 
> > Do you recommend I add the mboxes property even currently we can't do the comms ?
> 
> Bindings should be complete, regardless whether Linux driver supports it
> or not. Please see writing bindings document for explanation on this and
> other rules.
> 
> So yes: please describe as much as possible/reasonable.

I'll do thanks.

Cheers,
Abdellatif

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel