Re: [PATCH 1/2] dt-bindings: remoteproc: add AMD MicroBlaze binding

[Krzysztof Kozlowski <krzk@kernel.org>]

On 15/04/2026 10:06, Michal Simek wrote:
> 
> 
> On 4/15/26 09:07, Krzysztof Kozlowski wrote:
>> On 15/04/2026 08:55, Michal Simek wrote:
>>>>>
>>>>> Does it make sense?
>>>>
>>>> Yes, drop from DT. No need for generic stuff. Or describe the hardware.
>>>
>>> You need to describe that connection to HW. GPIOs, memory location, etc.
>>> It means there must be any description.
>>
>> No, you can write user-space driver or pass everything through SW nodes.
>> No need for DT description.
> 
> The firmware memory typically sits behind AXI-to-AXI bridges and 
> 
> interconnect switches. The bus topology varies between FPGA designs. 
> 
> DT ranges-based address translation is the standard way to describe 
> 
> this, and pushing it into userspace would just mean hardcoding what 
> 
> ranges already provides.
> 
> I don't think SW nodes should be used here.
> 
>>
>> But if you want a DT description, then it must be for the specific
>> hardware, since the hardware is not generic.
> 
> But there is specific HW loaded. It is loaded at power up and don't change over 
> life cycle. What I am just saying that access to this fixed HW (in fpga) is 
> generic. At this stage memory and gpio only.
> 
> What I was trying to say is that the hardware topology (memory window + 
> 
> reset GPIO) is the same regardless of the soft-core cpu (MicroBlaze,
> RISC-V, etc.)/fpga, so naming it after the ISA architecture felt wrong to me 
> 
> too.
> 
> When I look at other bindings. For example this one.
> Documentation/devicetree/bindings/remoteproc/qcom,glink-rpm-edge.yaml

That's a subnode of other device. Not an independent device.

Plus I dislike most of Qualcomm remoteproc bindings and find them way to
downstreamish, written to match downstream approaches without respecting
DT rules.

> 
> the compatible describes the communication mechanism (FIFO-based G-Link), not 
> the specific processor behind it. 
> 
>   
> 
> Our case is similar the compatible describes the control mechanism firmware 
> loaded through a memory window, processor started via GPIO reset. What sits 
> behind that interface varies and is opaque to the binding.
>   
> 
> Would something like "amd,mem-gpio-rproc" be acceptable, following the same 
> pattern where the compatible identifies the interface mechanism?

Not for me. You have a very specific physical remote processor. That's
what you write bindings for.

Best regards,
Krzysztof