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

[Michal Simek]

On 4/15/26 10:24, Krzysztof Kozlowski wrote:
> 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.

And we have it which is Microblaze with bram (block ram) which is mapped to host 
CPU memory range which is going to be loaded by firmware and start by toggling 
gpio.
I think what we only don't have is proper compatible string which will describe 
this HW. If you don't like generic name we can describe it specifically for this 
configuration.

amd,microblaze-mem-gpio-rproc for example without any generic fallback.

Or we could create a spec, design recommendation for this type of configuration 
if that helps.

What do you suggest?

Thanks,
Michal