Date: Thu, 14 Mar 2024 13:49:28 +0000
From: Abdellatif El Khlifi <abdellatif.elkhlifi@....com>
To: Robin Murphy <robin.murphy@....com>
Cc: Bjorn Andersson <andersson@...nel.org>,
	Mathieu Poirier <mathieu.poirier@...aro.org>,
	Rob Herring <robh+dt@...nel.org>, Liviu Dudau <liviu.dudau@....com>,
	Sudeep Holla <sudeep.holla@....com>,
	Lorenzo Pieralisi <lpieralisi@...nel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
	Conor Dooley <conor+dt@...nel.org>, Drew.Reed@....com,
	Adam.Johnston@....com, linux-arm-kernel@...ts.infradead.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-remoteproc@...r.kernel.org
Subject: Re: [PATCH 3/3] dt-bindings: remoteproc: Add Arm remoteproc

Hi Robin,

> > +  firmware-name:
> > +    description: |
> > +      Default name of the firmware to load to the remote processor.
> 
> So... is loading the firmware image achieved by somehow bitbanging it
> through the one reset register, maybe? I find it hard to believe this is a
> complete and functional binding.
> 
> 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 ?

> For instance right now it seems somewhat tenuous to describe two consecutive
> 32-bit registers as separate "reg" entries, but *maybe* it's OK if that's
> all there ever is. However if it's actually going to end up needing several
> more additional MMIO and/or memory regions for other functionality, then
> describing each register and location individually is liable to get
> unmanageable really fast, and a higher-level functional grouping (e.g. these
> reset-related registers together as a single 8-byte region) would likely be
> a better design.

Currently the HW provides only 2 registers to control the remote processors:

The reset control and status registers.

It makes sense to me to use a mapped region of 8 bytes for both registers rather
than individual registers (since they are consecutive).
I'll update that, thanks for the suggestion.

Abdellatif,
Cheers

Powered by blists - more mailing lists