[PATCH v2 0/2] remoteproc: add AMD BRAM-based remote processor driver

[PATCH v2 0/2] remoteproc: add AMD BRAM-based remote processor driver

[Ben Levinsky]

Add a BRAM-based remoteproc driver and corresponding binding
for AMD soft processors located in programmable logic.

v2:
  This version pivots the series away from a MicroBlaze-specific
  binding and driver shape and instead models a BRAM-based soft-core
  processor subsystem more generally.

  This follows the upstream feedback that amd,microblaze was too tied
  to the processor architecture while also being too generic as a DT
  compatible for the hardware interface being described.

  Patch 1, dt-bindings: remoteproc: document AMD BRAM-based rproc

  - Renamed the binding away from amd,microblaze and reframed it
    around a BRAM-based soft-core processor subsystem.
  - Dropped the redundant trailing "binding" wording from the patch
    subject.
  - Rewrote the binding text to describe the hardware rather than the
    Linux remoteproc framework.
  - Reworked the example to address the original dt_binding_check
    complaints about the root node and simple-pm-bus example shape.
  - Added a clocks property for the soft-core subsystem.

  Patch 2, remoteproc: add AMD BRAM-based remote processor driver

  - Renamed the driver away from the MicroBlaze-specific name to match
    the BRAM-based binding.
  - Added clock handling for the soft-core subsystem and the matching
    COMMON_CLK dependency in Kconfig.
  - Cleaned up the reset comments and removed the success dev_dbg()
    message called out in review.

Ben Levinsky (2):
  dt-bindings: remoteproc: document AMD BRAM-based rproc
  remoteproc: add AMD BRAM-based remote processor driver

 .../bindings/remoteproc/amd,bram-rproc.yaml   |  98 +++++++
 MAINTAINERS                                   |   7 +
 drivers/remoteproc/Kconfig                    |  14 +
 drivers/remoteproc/Makefile                   |   1 +
 drivers/remoteproc/amd_bram_rproc.c           | 243 ++++++++++++++++++
 5 files changed, 363 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml
 create mode 100644 drivers/remoteproc/amd_bram_rproc.c

-- 
2.34.1

[PATCH v2 1/2] dt-bindings: remoteproc: document AMD BRAM-based rproc

[Ben Levinsky]

Describe an AMD BRAM-based soft-core processor subsystem instantiated in
programmable logic and using dual-port BRAM for firmware storage and
execution.

The binding models a soft-core processor subsystem instantiated in AMD
programmable logic and using dual-port BRAM for firmware storage and
execution. The remoteproc device is represented as a child node whose
reg property describes the firmware memory window in the processor-local
address space. The parent bus node provides standard devicetree address
translation through ranges so Linux can access the same BRAM through the
system physical address space.

A clock input feeds the soft-core processor subsystem, and an active-low
reset GPIO holds the processor in reset until firmware loading
completes. The firmware-name property is optional.

Signed-off-by: Ben Levinsky <ben.levinsky@amd.com>
---
 .../bindings/remoteproc/amd,bram-rproc.yaml   | 98 +++++++++++++++++++
 1 file changed, 98 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml

diff --git a/Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml
new file mode 100644
index 000000000000..f16657dc0d9f
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml
@@ -0,0 +1,98 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/amd,bram-rproc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: AMD BRAM-based Remote Processor
+
+maintainers:
+  - Ben Levinsky <ben.levinsky@amd.com>
+
+description: |
+  Soft-core processor subsystem instantiated in AMD programmable logic and
+  using dual-port BRAM for firmware storage and execution.
+
+  Hardware Architecture:
+
+    Host (PS)                        Programmable Logic (PL)
+    =========                        ======================
+
+    AXI Interface -----------------> AXI BRAM Controller (Host Port)
+                                             |
+                                             | Port A
+                                             v
+                                     +-----------------+
+                                     |  Dual-Port BRAM |
+                                     | (shared memory) |
+                                     +-----------------+
+                                             ^
+                                             | Port B
+                                             |
+                                     AXI BRAM Controller (Soft-core Port)
+                                             ^
+                                             | LMB
+                                             |
+                                     Soft-core CPU (MicroBlaze/V)
+
+    GPIO --------------------------> Proc Sys Reset ----> CPU Reset Signal
+
+    Clock -------------------------> Clock Distribution -> CPU Clock
+
+  Memory Architecture:
+
+    The dual-port BRAM allows simultaneous access from both processors:
+      - Port A: Connected to the host AXI BRAM controller for firmware loading
+      - Port B: Connected to the soft-core local memory bus for execution
+
+  The reg property describes the executable BRAM window in the processor-local
+  address space. The parent bus node translates that window to the system
+  physical address space by using standard devicetree address translation
+  through ranges. A clock input and a reset GPIO control the subsystem.
+
+properties:
+  compatible:
+    const: amd,bram-rproc
+
+  reg:
+    maxItems: 1
+    description:
+      Processor-local address and size of the BRAM firmware memory window,
+      as seen by the soft-core processor (typically 0x0 for reset vector).
+      The parent bus ranges property must translate this window to the
+      corresponding system physical address.
+
+  clocks:
+    maxItems: 1
+    description:
+      Clock input for the soft-core processor subsystem.
+
+  firmware-name:
+    maxItems: 1
+    description:
+      Name of the firmware ELF file to load.
+
+  reset-gpios:
+    maxItems: 1
+    description:
+      GPIO specifier controlling the soft-core reset input.
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - reset-gpios
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/gpio/gpio.h>
+    remoteproc@0 {
+      compatible = "amd,bram-rproc";
+      reg = <0x0 0x40000>;
+      clocks = <&pl_clk>;
+      firmware-name = "firmware.elf";
+      reset-gpios = <&gpio0 0 GPIO_ACTIVE_LOW>;
+    };
+...
-- 
2.34.1

Re: [PATCH v2 1/2] dt-bindings: remoteproc: document AMD BRAM-based rproc

[Krzysztof Kozlowski]

On Mon, Apr 27, 2026 at 09:27:02AM -0700, Ben Levinsky wrote:
> Describe an AMD BRAM-based soft-core processor subsystem instantiated in
> programmable logic and using dual-port BRAM for firmware storage and
> execution.
> 
> The binding models a soft-core processor subsystem instantiated in AMD
> programmable logic and using dual-port BRAM for firmware storage and
> execution. The remoteproc device is represented as a child node whose
> reg property describes the firmware memory window in the processor-local
> address space. The parent bus node provides standard devicetree address
> translation through ranges so Linux can access the same BRAM through the
> system physical address space.
> 
> A clock input feeds the soft-core processor subsystem, and an active-low
> reset GPIO holds the processor in reset until firmware loading
> completes. The firmware-name property is optional.
> 
> Signed-off-by: Ben Levinsky <ben.levinsky@amd.com>
> ---
>  .../bindings/remoteproc/amd,bram-rproc.yaml   | 98 +++++++++++++++++++
>  1 file changed, 98 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml
> 
> diff --git a/Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml
> new file mode 100644
> index 000000000000..f16657dc0d9f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml
> @@ -0,0 +1,98 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/remoteproc/amd,bram-rproc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: AMD BRAM-based Remote Processor
> +
> +maintainers:
> +  - Ben Levinsky <ben.levinsky@amd.com>
> +
> +description: |
> +  Soft-core processor subsystem instantiated in AMD programmable logic and
> +  using dual-port BRAM for firmware storage and execution.

Isn't the soft-core or FPGA still part of some Xilinx SoC? Or is this
completely different thing from SoC and there is a design WITHOUT SoC
using this remote proc?

Best regards,
Krzysztof

Re: [PATCH v2 1/2] dt-bindings: remoteproc: document AMD BRAM-based rproc

[Michal Simek]

On 4/28/26 08:50, Krzysztof Kozlowski wrote:
> On Mon, Apr 27, 2026 at 09:27:02AM -0700, Ben Levinsky wrote:
>> Describe an AMD BRAM-based soft-core processor subsystem instantiated in
>> programmable logic and using dual-port BRAM for firmware storage and
>> execution.
>>
>> The binding models a soft-core processor subsystem instantiated in AMD
>> programmable logic and using dual-port BRAM for firmware storage and
>> execution. The remoteproc device is represented as a child node whose
>> reg property describes the firmware memory window in the processor-local
>> address space. The parent bus node provides standard devicetree address
>> translation through ranges so Linux can access the same BRAM through the
>> system physical address space.
>>
>> A clock input feeds the soft-core processor subsystem, and an active-low
>> reset GPIO holds the processor in reset until firmware loading
>> completes. The firmware-name property is optional.
>>
>> Signed-off-by: Ben Levinsky <ben.levinsky@amd.com>
>> ---
>>   .../bindings/remoteproc/amd,bram-rproc.yaml   | 98 +++++++++++++++++++
>>   1 file changed, 98 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml
>> new file mode 100644
>> index 000000000000..f16657dc0d9f
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml
>> @@ -0,0 +1,98 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/remoteproc/amd,bram-rproc.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: AMD BRAM-based Remote Processor
>> +
>> +maintainers:
>> +  - Ben Levinsky <ben.levinsky@amd.com>
>> +
>> +description: |
>> +  Soft-core processor subsystem instantiated in AMD programmable logic and
>> +  using dual-port BRAM for firmware storage and execution.
> 
> Isn't the soft-core or FPGA still part of some Xilinx SoC? Or is this
> completely different thing from SoC and there is a design WITHOUT SoC
> using this remote proc?

In 99% case this is going to be used on Xilinx SOC with programmable logic next 
to ARM core.
soft core means - means VHDL/Verilog code synthesized to programmable 
logic/fpga. It means exact location in chip varies based on build and constraints.

hard core - physical HW location - like ARM cores in our chip.

(ARM is providing RTL/code that even ARM cores in fpga emulated platforms are 
actually used as soft cores).

Not sure if you want me to talk about that 1% use cases which are also possible 
but don't think anybody will design them.

Thanks,
Michal

Re: [PATCH v2 1/2] dt-bindings: remoteproc: document AMD BRAM-based rproc

[Krzysztof Kozlowski]

On 28/04/2026 10:33, Michal Simek wrote:
> 
> 
> On 4/28/26 08:50, Krzysztof Kozlowski wrote:
>> On Mon, Apr 27, 2026 at 09:27:02AM -0700, Ben Levinsky wrote:
>>> Describe an AMD BRAM-based soft-core processor subsystem instantiated in
>>> programmable logic and using dual-port BRAM for firmware storage and
>>> execution.
>>>
>>> The binding models a soft-core processor subsystem instantiated in AMD
>>> programmable logic and using dual-port BRAM for firmware storage and
>>> execution. The remoteproc device is represented as a child node whose
>>> reg property describes the firmware memory window in the processor-local
>>> address space. The parent bus node provides standard devicetree address
>>> translation through ranges so Linux can access the same BRAM through the
>>> system physical address space.
>>>
>>> A clock input feeds the soft-core processor subsystem, and an active-low
>>> reset GPIO holds the processor in reset until firmware loading
>>> completes. The firmware-name property is optional.
>>>
>>> Signed-off-by: Ben Levinsky <ben.levinsky@amd.com>
>>> ---
>>>   .../bindings/remoteproc/amd,bram-rproc.yaml   | 98 +++++++++++++++++++
>>>   1 file changed, 98 insertions(+)
>>>   create mode 100644 Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml
>>>
>>> diff --git a/Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml
>>> new file mode 100644
>>> index 000000000000..f16657dc0d9f
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml
>>> @@ -0,0 +1,98 @@
>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>> +%YAML 1.2
>>> +---
>>> +$id: http://devicetree.org/schemas/remoteproc/amd,bram-rproc.yaml#
>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>> +
>>> +title: AMD BRAM-based Remote Processor
>>> +
>>> +maintainers:
>>> +  - Ben Levinsky <ben.levinsky@amd.com>
>>> +
>>> +description: |
>>> +  Soft-core processor subsystem instantiated in AMD programmable logic and
>>> +  using dual-port BRAM for firmware storage and execution.
>>
>> Isn't the soft-core or FPGA still part of some Xilinx SoC? Or is this
>> completely different thing from SoC and there is a design WITHOUT SoC
>> using this remote proc?
> 
> In 99% case this is going to be used on Xilinx SOC with programmable logic next 
> to ARM core.
> soft core means - means VHDL/Verilog code synthesized to programmable 
> logic/fpga. It means exact location in chip varies based on build and constraints.
> 
> hard core - physical HW location - like ARM cores in our chip.
> 
> (ARM is providing RTL/code that even ARM cores in fpga emulated platforms are 
> actually used as soft cores).
> 
> Not sure if you want me to talk about that 1% use cases which are also possible 
> but don't think anybody will design them.

Then I would treat it exactly like every other block of a SoC - you need
a SoC specific compatible. If there is a fallback, SoC specific
compatible should be used in the fallback as well - that's all already
documented in writing-bindings.

If this is ever used standalone, outside of SoC, then maybe it will need
its own wiring thus it will get its own compatible.

Best regards,
Krzysztof

Re: [PATCH v2 1/2] dt-bindings: remoteproc: document AMD BRAM-based rproc

[Michal Simek]

On 4/28/26 10:47, Krzysztof Kozlowski wrote:
> On 28/04/2026 10:33, Michal Simek wrote:
>>
>>
>> On 4/28/26 08:50, Krzysztof Kozlowski wrote:
>>> On Mon, Apr 27, 2026 at 09:27:02AM -0700, Ben Levinsky wrote:
>>>> Describe an AMD BRAM-based soft-core processor subsystem instantiated in
>>>> programmable logic and using dual-port BRAM for firmware storage and
>>>> execution.
>>>>
>>>> The binding models a soft-core processor subsystem instantiated in AMD
>>>> programmable logic and using dual-port BRAM for firmware storage and
>>>> execution. The remoteproc device is represented as a child node whose
>>>> reg property describes the firmware memory window in the processor-local
>>>> address space. The parent bus node provides standard devicetree address
>>>> translation through ranges so Linux can access the same BRAM through the
>>>> system physical address space.
>>>>
>>>> A clock input feeds the soft-core processor subsystem, and an active-low
>>>> reset GPIO holds the processor in reset until firmware loading
>>>> completes. The firmware-name property is optional.
>>>>
>>>> Signed-off-by: Ben Levinsky <ben.levinsky@amd.com>
>>>> ---
>>>>    .../bindings/remoteproc/amd,bram-rproc.yaml   | 98 +++++++++++++++++++
>>>>    1 file changed, 98 insertions(+)
>>>>    create mode 100644 Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml
>>>> new file mode 100644
>>>> index 000000000000..f16657dc0d9f
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml
>>>> @@ -0,0 +1,98 @@
>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>> +%YAML 1.2
>>>> +---
>>>> +$id: http://devicetree.org/schemas/remoteproc/amd,bram-rproc.yaml#
>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>> +
>>>> +title: AMD BRAM-based Remote Processor
>>>> +
>>>> +maintainers:
>>>> +  - Ben Levinsky <ben.levinsky@amd.com>
>>>> +
>>>> +description: |
>>>> +  Soft-core processor subsystem instantiated in AMD programmable logic and
>>>> +  using dual-port BRAM for firmware storage and execution.
>>>
>>> Isn't the soft-core or FPGA still part of some Xilinx SoC? Or is this
>>> completely different thing from SoC and there is a design WITHOUT SoC
>>> using this remote proc?
>>
>> In 99% case this is going to be used on Xilinx SOC with programmable logic next
>> to ARM core.
>> soft core means - means VHDL/Verilog code synthesized to programmable
>> logic/fpga. It means exact location in chip varies based on build and constraints.
>>
>> hard core - physical HW location - like ARM cores in our chip.
>>
>> (ARM is providing RTL/code that even ARM cores in fpga emulated platforms are
>> actually used as soft cores).
>>
>> Not sure if you want me to talk about that 1% use cases which are also possible
>> but don't think anybody will design them.
> 
> Then I would treat it exactly like every other block of a SoC - you need
> a SoC specific compatible. If there is a fallback, SoC specific
> compatible should be used in the fallback as well - that's all already
> documented in writing-bindings.

But which SOC? We have ZynqMP, Versal, Versal NET, Versal Gen 2. And all of 
these will use this configuration.
Do you want to list all of them?

Thanks,
Michal

Re: [PATCH v2 1/2] dt-bindings: remoteproc: document AMD BRAM-based rproc

[Krzysztof Kozlowski]

On 28/04/2026 11:04, Michal Simek wrote:
> 
> 
> On 4/28/26 10:47, Krzysztof Kozlowski wrote:
>> On 28/04/2026 10:33, Michal Simek wrote:
>>>
>>>
>>> On 4/28/26 08:50, Krzysztof Kozlowski wrote:
>>>> On Mon, Apr 27, 2026 at 09:27:02AM -0700, Ben Levinsky wrote:
>>>>> Describe an AMD BRAM-based soft-core processor subsystem instantiated in
>>>>> programmable logic and using dual-port BRAM for firmware storage and
>>>>> execution.
>>>>>
>>>>> The binding models a soft-core processor subsystem instantiated in AMD
>>>>> programmable logic and using dual-port BRAM for firmware storage and
>>>>> execution. The remoteproc device is represented as a child node whose
>>>>> reg property describes the firmware memory window in the processor-local
>>>>> address space. The parent bus node provides standard devicetree address
>>>>> translation through ranges so Linux can access the same BRAM through the
>>>>> system physical address space.
>>>>>
>>>>> A clock input feeds the soft-core processor subsystem, and an active-low
>>>>> reset GPIO holds the processor in reset until firmware loading
>>>>> completes. The firmware-name property is optional.
>>>>>
>>>>> Signed-off-by: Ben Levinsky <ben.levinsky@amd.com>
>>>>> ---
>>>>>    .../bindings/remoteproc/amd,bram-rproc.yaml   | 98 +++++++++++++++++++
>>>>>    1 file changed, 98 insertions(+)
>>>>>    create mode 100644 Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml
>>>>> new file mode 100644
>>>>> index 000000000000..f16657dc0d9f
>>>>> --- /dev/null
>>>>> +++ b/Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml
>>>>> @@ -0,0 +1,98 @@
>>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>>> +%YAML 1.2
>>>>> +---
>>>>> +$id: http://devicetree.org/schemas/remoteproc/amd,bram-rproc.yaml#
>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>>> +
>>>>> +title: AMD BRAM-based Remote Processor
>>>>> +
>>>>> +maintainers:
>>>>> +  - Ben Levinsky <ben.levinsky@amd.com>
>>>>> +
>>>>> +description: |
>>>>> +  Soft-core processor subsystem instantiated in AMD programmable logic and
>>>>> +  using dual-port BRAM for firmware storage and execution.
>>>>
>>>> Isn't the soft-core or FPGA still part of some Xilinx SoC? Or is this
>>>> completely different thing from SoC and there is a design WITHOUT SoC
>>>> using this remote proc?
>>>
>>> In 99% case this is going to be used on Xilinx SOC with programmable logic next
>>> to ARM core.
>>> soft core means - means VHDL/Verilog code synthesized to programmable
>>> logic/fpga. It means exact location in chip varies based on build and constraints.
>>>
>>> hard core - physical HW location - like ARM cores in our chip.
>>>
>>> (ARM is providing RTL/code that even ARM cores in fpga emulated platforms are
>>> actually used as soft cores).
>>>
>>> Not sure if you want me to talk about that 1% use cases which are also possible
>>> but don't think anybody will design them.
>>
>> Then I would treat it exactly like every other block of a SoC - you need
>> a SoC specific compatible. If there is a fallback, SoC specific
>> compatible should be used in the fallback as well - that's all already
>> documented in writing-bindings.
> 
> But which SOC? We have ZynqMP, Versal, Versal NET, Versal Gen 2. And all of 
> these will use this configuration.
> Do you want to list all of them?

"Then I would treat it exactly like every other block of a SoC"

Best regards,
Krzysztof

Re: [PATCH v2 1/2] dt-bindings: remoteproc: document AMD BRAM-based rproc

[Michal Simek]

On 4/28/26 11:14, Krzysztof Kozlowski wrote:
> On 28/04/2026 11:04, Michal Simek wrote:
>>
>>
>> On 4/28/26 10:47, Krzysztof Kozlowski wrote:
>>> On 28/04/2026 10:33, Michal Simek wrote:
>>>>
>>>>
>>>> On 4/28/26 08:50, Krzysztof Kozlowski wrote:
>>>>> On Mon, Apr 27, 2026 at 09:27:02AM -0700, Ben Levinsky wrote:
>>>>>> Describe an AMD BRAM-based soft-core processor subsystem instantiated in
>>>>>> programmable logic and using dual-port BRAM for firmware storage and
>>>>>> execution.
>>>>>>
>>>>>> The binding models a soft-core processor subsystem instantiated in AMD
>>>>>> programmable logic and using dual-port BRAM for firmware storage and
>>>>>> execution. The remoteproc device is represented as a child node whose
>>>>>> reg property describes the firmware memory window in the processor-local
>>>>>> address space. The parent bus node provides standard devicetree address
>>>>>> translation through ranges so Linux can access the same BRAM through the
>>>>>> system physical address space.
>>>>>>
>>>>>> A clock input feeds the soft-core processor subsystem, and an active-low
>>>>>> reset GPIO holds the processor in reset until firmware loading
>>>>>> completes. The firmware-name property is optional.
>>>>>>
>>>>>> Signed-off-by: Ben Levinsky <ben.levinsky@amd.com>
>>>>>> ---
>>>>>>     .../bindings/remoteproc/amd,bram-rproc.yaml   | 98 +++++++++++++++++++
>>>>>>     1 file changed, 98 insertions(+)
>>>>>>     create mode 100644 Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml
>>>>>> new file mode 100644
>>>>>> index 000000000000..f16657dc0d9f
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml
>>>>>> @@ -0,0 +1,98 @@
>>>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>>>> +%YAML 1.2
>>>>>> +---
>>>>>> +$id: http://devicetree.org/schemas/remoteproc/amd,bram-rproc.yaml#
>>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>>>> +
>>>>>> +title: AMD BRAM-based Remote Processor
>>>>>> +
>>>>>> +maintainers:
>>>>>> +  - Ben Levinsky <ben.levinsky@amd.com>
>>>>>> +
>>>>>> +description: |
>>>>>> +  Soft-core processor subsystem instantiated in AMD programmable logic and
>>>>>> +  using dual-port BRAM for firmware storage and execution.
>>>>>
>>>>> Isn't the soft-core or FPGA still part of some Xilinx SoC? Or is this
>>>>> completely different thing from SoC and there is a design WITHOUT SoC
>>>>> using this remote proc?
>>>>
>>>> In 99% case this is going to be used on Xilinx SOC with programmable logic next
>>>> to ARM core.
>>>> soft core means - means VHDL/Verilog code synthesized to programmable
>>>> logic/fpga. It means exact location in chip varies based on build and constraints.
>>>>
>>>> hard core - physical HW location - like ARM cores in our chip.
>>>>
>>>> (ARM is providing RTL/code that even ARM cores in fpga emulated platforms are
>>>> actually used as soft cores).
>>>>
>>>> Not sure if you want me to talk about that 1% use cases which are also possible
>>>> but don't think anybody will design them.
>>>
>>> Then I would treat it exactly like every other block of a SoC - you need
>>> a SoC specific compatible. If there is a fallback, SoC specific
>>> compatible should be used in the fallback as well - that's all already
>>> documented in writing-bindings.
>>
>> But which SOC? We have ZynqMP, Versal, Versal NET, Versal Gen 2. And all of
>> these will use this configuration.
>> Do you want to list all of them?
> 
> "Then I would treat it exactly like every other block of a SoC"

No issue. Here is snippet.

   properties:
     compatible:
       items:
         - enum:
             - xlnx,zynqmp-bram-rproc
             - xlnx,versal-bram-rproc
             - xlnx,versal-net-bram-rproc
             - amd,versal2-bram-rproc
         - const: amd,bram-rproc

   The example should also be updated:

   examples:
     - |
       #include <dt-bindings/gpio/gpio.h>
       remoteproc@0 {
         compatible = "xlnx,zynqmp-bram-rproc", "amd,bram-rproc";
         reg = <0x0 0x40000>;
         clocks = <&pl_clk>;
         firmware-name = "firmware.elf";
         reset-gpios = <&gpio0 0 GPIO_ACTIVE_LOW>;
       };

Thanks,
Michal

Re: [PATCH v2 1/2] dt-bindings: remoteproc: document AMD BRAM-based rproc

[Krzysztof Kozlowski]

On 28/04/2026 15:09, Michal Simek wrote:
> 
> 
> On 4/28/26 11:14, Krzysztof Kozlowski wrote:
>> On 28/04/2026 11:04, Michal Simek wrote:
>>>
>>>
>>> On 4/28/26 10:47, Krzysztof Kozlowski wrote:
>>>> On 28/04/2026 10:33, Michal Simek wrote:
>>>>>
>>>>>
>>>>> On 4/28/26 08:50, Krzysztof Kozlowski wrote:
>>>>>> On Mon, Apr 27, 2026 at 09:27:02AM -0700, Ben Levinsky wrote:
>>>>>>> Describe an AMD BRAM-based soft-core processor subsystem instantiated in
>>>>>>> programmable logic and using dual-port BRAM for firmware storage and
>>>>>>> execution.
>>>>>>>
>>>>>>> The binding models a soft-core processor subsystem instantiated in AMD
>>>>>>> programmable logic and using dual-port BRAM for firmware storage and
>>>>>>> execution. The remoteproc device is represented as a child node whose
>>>>>>> reg property describes the firmware memory window in the processor-local
>>>>>>> address space. The parent bus node provides standard devicetree address
>>>>>>> translation through ranges so Linux can access the same BRAM through the
>>>>>>> system physical address space.
>>>>>>>
>>>>>>> A clock input feeds the soft-core processor subsystem, and an active-low
>>>>>>> reset GPIO holds the processor in reset until firmware loading
>>>>>>> completes. The firmware-name property is optional.
>>>>>>>
>>>>>>> Signed-off-by: Ben Levinsky <ben.levinsky@amd.com>
>>>>>>> ---
>>>>>>>     .../bindings/remoteproc/amd,bram-rproc.yaml   | 98 +++++++++++++++++++
>>>>>>>     1 file changed, 98 insertions(+)
>>>>>>>     create mode 100644 Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml
>>>>>>>
>>>>>>> diff --git a/Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml
>>>>>>> new file mode 100644
>>>>>>> index 000000000000..f16657dc0d9f
>>>>>>> --- /dev/null
>>>>>>> +++ b/Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml
>>>>>>> @@ -0,0 +1,98 @@
>>>>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>>>>> +%YAML 1.2
>>>>>>> +---
>>>>>>> +$id: http://devicetree.org/schemas/remoteproc/amd,bram-rproc.yaml#
>>>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>>>>> +
>>>>>>> +title: AMD BRAM-based Remote Processor
>>>>>>> +
>>>>>>> +maintainers:
>>>>>>> +  - Ben Levinsky <ben.levinsky@amd.com>
>>>>>>> +
>>>>>>> +description: |
>>>>>>> +  Soft-core processor subsystem instantiated in AMD programmable logic and
>>>>>>> +  using dual-port BRAM for firmware storage and execution.
>>>>>>
>>>>>> Isn't the soft-core or FPGA still part of some Xilinx SoC? Or is this
>>>>>> completely different thing from SoC and there is a design WITHOUT SoC
>>>>>> using this remote proc?
>>>>>
>>>>> In 99% case this is going to be used on Xilinx SOC with programmable logic next
>>>>> to ARM core.
>>>>> soft core means - means VHDL/Verilog code synthesized to programmable
>>>>> logic/fpga. It means exact location in chip varies based on build and constraints.
>>>>>
>>>>> hard core - physical HW location - like ARM cores in our chip.
>>>>>
>>>>> (ARM is providing RTL/code that even ARM cores in fpga emulated platforms are
>>>>> actually used as soft cores).
>>>>>
>>>>> Not sure if you want me to talk about that 1% use cases which are also possible
>>>>> but don't think anybody will design them.
>>>>
>>>> Then I would treat it exactly like every other block of a SoC - you need
>>>> a SoC specific compatible. If there is a fallback, SoC specific
>>>> compatible should be used in the fallback as well - that's all already
>>>> documented in writing-bindings.
>>>
>>> But which SOC? We have ZynqMP, Versal, Versal NET, Versal Gen 2. And all of
>>> these will use this configuration.
>>> Do you want to list all of them?
>>
>> "Then I would treat it exactly like every other block of a SoC"
> 
> No issue. Here is snippet.
> 
>    properties:
>      compatible:
>        items:
>          - enum:
>              - xlnx,zynqmp-bram-rproc
>              - xlnx,versal-bram-rproc
>              - xlnx,versal-net-bram-rproc
>              - amd,versal2-bram-rproc
>          - const: amd,bram-rproc
> 
>    The example should also be updated:

Yes, except what I wrote earlier and is mentioned in the writing
bindings doc - the specific compatible should be also the fallback.

Best regards,
Krzysztof

Re: [PATCH v2 1/2] dt-bindings: remoteproc: document AMD BRAM-based rproc

[Michal Simek]

On 4/28/26 15:12, Krzysztof Kozlowski wrote:
> On 28/04/2026 15:09, Michal Simek wrote:
>>
>>
>> On 4/28/26 11:14, Krzysztof Kozlowski wrote:
>>> On 28/04/2026 11:04, Michal Simek wrote:
>>>>
>>>>
>>>> On 4/28/26 10:47, Krzysztof Kozlowski wrote:
>>>>> On 28/04/2026 10:33, Michal Simek wrote:
>>>>>>
>>>>>>
>>>>>> On 4/28/26 08:50, Krzysztof Kozlowski wrote:
>>>>>>> On Mon, Apr 27, 2026 at 09:27:02AM -0700, Ben Levinsky wrote:
>>>>>>>> Describe an AMD BRAM-based soft-core processor subsystem instantiated in
>>>>>>>> programmable logic and using dual-port BRAM for firmware storage and
>>>>>>>> execution.
>>>>>>>>
>>>>>>>> The binding models a soft-core processor subsystem instantiated in AMD
>>>>>>>> programmable logic and using dual-port BRAM for firmware storage and
>>>>>>>> execution. The remoteproc device is represented as a child node whose
>>>>>>>> reg property describes the firmware memory window in the processor-local
>>>>>>>> address space. The parent bus node provides standard devicetree address
>>>>>>>> translation through ranges so Linux can access the same BRAM through the
>>>>>>>> system physical address space.
>>>>>>>>
>>>>>>>> A clock input feeds the soft-core processor subsystem, and an active-low
>>>>>>>> reset GPIO holds the processor in reset until firmware loading
>>>>>>>> completes. The firmware-name property is optional.
>>>>>>>>
>>>>>>>> Signed-off-by: Ben Levinsky <ben.levinsky@amd.com>
>>>>>>>> ---
>>>>>>>>      .../bindings/remoteproc/amd,bram-rproc.yaml   | 98 +++++++++++++++++++
>>>>>>>>      1 file changed, 98 insertions(+)
>>>>>>>>      create mode 100644 Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml
>>>>>>>>
>>>>>>>> diff --git a/Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml
>>>>>>>> new file mode 100644
>>>>>>>> index 000000000000..f16657dc0d9f
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml
>>>>>>>> @@ -0,0 +1,98 @@
>>>>>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>>>>>> +%YAML 1.2
>>>>>>>> +---
>>>>>>>> +$id: http://devicetree.org/schemas/remoteproc/amd,bram-rproc.yaml#
>>>>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>>>>>> +
>>>>>>>> +title: AMD BRAM-based Remote Processor
>>>>>>>> +
>>>>>>>> +maintainers:
>>>>>>>> +  - Ben Levinsky <ben.levinsky@amd.com>
>>>>>>>> +
>>>>>>>> +description: |
>>>>>>>> +  Soft-core processor subsystem instantiated in AMD programmable logic and
>>>>>>>> +  using dual-port BRAM for firmware storage and execution.
>>>>>>>
>>>>>>> Isn't the soft-core or FPGA still part of some Xilinx SoC? Or is this
>>>>>>> completely different thing from SoC and there is a design WITHOUT SoC
>>>>>>> using this remote proc?
>>>>>>
>>>>>> In 99% case this is going to be used on Xilinx SOC with programmable logic next
>>>>>> to ARM core.
>>>>>> soft core means - means VHDL/Verilog code synthesized to programmable
>>>>>> logic/fpga. It means exact location in chip varies based on build and constraints.
>>>>>>
>>>>>> hard core - physical HW location - like ARM cores in our chip.
>>>>>>
>>>>>> (ARM is providing RTL/code that even ARM cores in fpga emulated platforms are
>>>>>> actually used as soft cores).
>>>>>>
>>>>>> Not sure if you want me to talk about that 1% use cases which are also possible
>>>>>> but don't think anybody will design them.
>>>>>
>>>>> Then I would treat it exactly like every other block of a SoC - you need
>>>>> a SoC specific compatible. If there is a fallback, SoC specific
>>>>> compatible should be used in the fallback as well - that's all already
>>>>> documented in writing-bindings.
>>>>
>>>> But which SOC? We have ZynqMP, Versal, Versal NET, Versal Gen 2. And all of
>>>> these will use this configuration.
>>>> Do you want to list all of them?
>>>
>>> "Then I would treat it exactly like every other block of a SoC"
>>
>> No issue. Here is snippet.
>>
>>     properties:
>>       compatible:
>>         items:
>>           - enum:
>>               - xlnx,zynqmp-bram-rproc
>>               - xlnx,versal-bram-rproc
>>               - xlnx,versal-net-bram-rproc
>>               - amd,versal2-bram-rproc
>>           - const: amd,bram-rproc
>>
>>     The example should also be updated:
> 
> Yes, except what I wrote earlier and is mentioned in the writing
> bindings doc - the specific compatible should be also the fallback.

   properties:
     compatible:
       oneOf:
         - const: xlnx,zynqmp-bram-rproc
         - items:
             - enum:
                 - xlnx,versal-bram-rproc
                 - xlnx,versal-net-bram-rproc
                 - amd,versal2-bram-rproc
             - const: xlnx,zynqmp-bram-rproc

Good now?

M

Re: [PATCH v2 1/2] dt-bindings: remoteproc: document AMD BRAM-based rproc

[Krzysztof Kozlowski]

On 28/04/2026 15:18, Michal Simek wrote:
>>>
>>>     properties:
>>>       compatible:
>>>         items:
>>>           - enum:
>>>               - xlnx,zynqmp-bram-rproc
>>>               - xlnx,versal-bram-rproc
>>>               - xlnx,versal-net-bram-rproc
>>>               - amd,versal2-bram-rproc
>>>           - const: amd,bram-rproc
>>>
>>>     The example should also be updated:
>>
>> Yes, except what I wrote earlier and is mentioned in the writing
>> bindings doc - the specific compatible should be also the fallback.
> 
>    properties:
>      compatible:
>        oneOf:
>          - const: xlnx,zynqmp-bram-rproc
>          - items:
>              - enum:
>                  - xlnx,versal-bram-rproc
>                  - xlnx,versal-net-bram-rproc
>                  - amd,versal2-bram-rproc
>              - const: xlnx,zynqmp-bram-rproc
> 
> Good now?

Yes, looks good to me!

Best regards,
Krzysztof

[PATCH v2 2/2] remoteproc: add AMD BRAM-based remote processor driver

[Ben Levinsky]

Add a remoteproc driver for AMD soft-core processor subsystems
instantiated in programmable logic and using dual-port BRAM for
firmware storage and execution.

The driver parses the firmware memory window from the remoteproc device
node's reg property, interprets that address and size in the
processor-local address space, and then uses standard devicetree
address translation through the parent bus ranges property to obtain
the corresponding Linux-visible system physical address.

The resulting translated region is registered as the executable
remoteproc carveout and coredump segment.

The processor is controlled through an active-low reset GPIO and a
subsystem clock. The clock is enabled before reset is released, and the
processor is kept in reset until firmware loading completes.

The firmware-name property is optional, allowing the firmware image to
be assigned later. Firmware images without a resource table are also
accepted.

Signed-off-by: Ben Levinsky <ben.levinsky@amd.com>
---
 MAINTAINERS                         |   7 +
 drivers/remoteproc/Kconfig          |  14 ++
 drivers/remoteproc/Makefile         |   1 +
 drivers/remoteproc/amd_bram_rproc.c | 243 ++++++++++++++++++++++++++++
 4 files changed, 265 insertions(+)
 create mode 100644 drivers/remoteproc/amd_bram_rproc.c

diff --git a/MAINTAINERS b/MAINTAINERS
index c871acf2179c..172539971950 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1037,6 +1037,13 @@ S:	Maintained
 F:	Documentation/devicetree/bindings/w1/amd,axi-1wire-host.yaml
 F:	drivers/w1/masters/amd_axi_w1.c
 
+AMD BRAM REMOTEPROC DRIVER
+M:	Ben Levinsky <ben.levinsky@amd.com>
+L:	linux-remoteproc@vger.kernel.org
+S:	Maintained
+F:	Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml
+F:	drivers/remoteproc/amd_bram_rproc.c
+
 AMD CDX BUS DRIVER
 M:	Nipun Gupta <nipun.gupta@amd.com>
 M:	Nikhil Agarwal <nikhil.agarwal@amd.com>
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index ee54436fea5a..9a2a887ede8a 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -23,6 +23,20 @@ config REMOTEPROC_CDEV
 
 	  It's safe to say N if you don't want to use this interface.
 
+config AMD_BRAM_REMOTEPROC
+	tristate "AMD BRAM-based remoteproc support"
+	depends on OF && COMMON_CLK && (GPIOLIB || COMPILE_TEST)
+	help
+	  Say y or m here to support a BRAM-based remote processor managed
+	  through the remoteproc framework.
+
+	  This driver matches designs where executable firmware memory is
+	  described in the BRAM-local address space and translated to
+	  the system physical address space with standard devicetree address
+	  translation.
+
+	  If unsure, say N.
+
 config IMX_REMOTEPROC
 	tristate "i.MX remoteproc support"
 	depends on ARCH_MXC
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 1c7598b8475d..5c39664b50c3 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -11,6 +11,7 @@ remoteproc-y				+= remoteproc_sysfs.o
 remoteproc-y				+= remoteproc_virtio.o
 remoteproc-y				+= remoteproc_elf_loader.o
 obj-$(CONFIG_REMOTEPROC_CDEV)		+= remoteproc_cdev.o
+obj-$(CONFIG_AMD_BRAM_REMOTEPROC)	+= amd_bram_rproc.o
 obj-$(CONFIG_IMX_REMOTEPROC)		+= imx_rproc.o
 obj-$(CONFIG_IMX_DSP_REMOTEPROC)	+= imx_dsp_rproc.o
 obj-$(CONFIG_INGENIC_VPU_RPROC)		+= ingenic_rproc.o
diff --git a/drivers/remoteproc/amd_bram_rproc.c b/drivers/remoteproc/amd_bram_rproc.c
new file mode 100644
index 000000000000..aa346b80e84c
--- /dev/null
+++ b/drivers/remoteproc/amd_bram_rproc.c
@@ -0,0 +1,243 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * AMD BRAM-based Remote Processor driver
+ *
+ * Copyright (C) 2026 Advanced Micro Devices, Inc.
+ *
+ * This driver supports soft-core processors (MicroBlaze, MicroBlaze-V, or
+ * similar) instantiated in AMD programmable logic, using dual-port BRAM
+ * for firmware storage and execution.
+ *
+ * The firmware memory (BRAM) is described in the processor-local address
+ * space and translated to the Linux-visible system physical address with
+ * standard devicetree address translation.
+ *
+ * Reset is controlled via GPIO connected to Processor System Reset IP.
+ */
+
+#include <linux/clk.h>
+#include <linux/dma-mapping.h>
+#include <linux/gpio/consumer.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/platform_device.h>
+#include <linux/remoteproc.h>
+
+#include "remoteproc_internal.h"
+
+/**
+ * struct amd_bram_rproc - AMD BRAM-based remoteproc private data
+ * @dev: device pointer
+ * @reset: GPIO descriptor for reset control (active-low)
+ * @clk: processor clock
+ */
+struct amd_bram_rproc {
+	struct device *dev;
+	struct gpio_desc *reset;
+	struct clk *clk;
+};
+
+static int amd_bram_rproc_mem_map(struct rproc *rproc,
+				  struct rproc_mem_entry *mem)
+{
+	void __iomem *va;
+
+	va = ioremap_wc(mem->dma, mem->len);
+	if (!va)
+		return -ENOMEM;
+
+	mem->va = (__force void *)va;
+	mem->is_iomem = true;
+
+	return 0;
+}
+
+static int amd_bram_rproc_mem_unmap(struct rproc *rproc,
+				    struct rproc_mem_entry *mem)
+{
+	iounmap((void __iomem *)mem->va);
+
+	return 0;
+}
+
+static int amd_bram_rproc_prepare(struct rproc *rproc)
+{
+	struct amd_bram_rproc *priv = rproc->priv;
+	struct rproc_mem_entry *mem;
+	struct resource res;
+	u64 da, size;
+	int ret;
+
+	ret = of_property_read_reg(priv->dev->of_node, 0, &da, &size);
+	if (ret) {
+		dev_err(priv->dev, "failed to parse executable memory reg\n");
+		return ret;
+	}
+
+	if (!size || size > U32_MAX) {
+		dev_err(priv->dev, "invalid executable memory size\n");
+		return -EINVAL;
+	}
+
+	if (da > U32_MAX) {
+		dev_err(priv->dev, "invalid executable memory address\n");
+		return -EINVAL;
+	}
+
+	ret = of_address_to_resource(priv->dev->of_node, 0, &res);
+	if (ret) {
+		dev_err(priv->dev, "failed to translate executable memory reg\n");
+		return ret;
+	}
+
+	mem = rproc_mem_entry_init(priv->dev, NULL, (dma_addr_t)res.start,
+				   (size_t)size, da,
+				   amd_bram_rproc_mem_map,
+				   amd_bram_rproc_mem_unmap,
+				   dev_name(priv->dev));
+	if (!mem)
+		return -ENOMEM;
+
+	rproc_add_carveout(rproc, mem);
+	rproc_coredump_add_segment(rproc, da, (size_t)size);
+
+	return 0;
+}
+
+static int amd_bram_rproc_start(struct rproc *rproc)
+{
+	struct amd_bram_rproc *priv = rproc->priv;
+	int ret;
+
+	/* Enable clock before releasing reset */
+	ret = clk_prepare_enable(priv->clk);
+	if (ret) {
+		dev_err(priv->dev, "failed to enable clock: %d\n", ret);
+		return ret;
+	}
+
+	/* Deassert reset and let the processor run. */
+	ret = gpiod_set_value_cansleep(priv->reset, 0);
+	if (ret) {
+		dev_err(priv->dev, "failed to deassert reset: %d\n", ret);
+		clk_disable_unprepare(priv->clk);
+		return ret;
+	}
+
+	return 0;
+}
+
+static int amd_bram_rproc_stop(struct rproc *rproc)
+{
+	struct amd_bram_rproc *priv = rproc->priv;
+	int ret;
+
+	/* Assert reset before disabling the processor clock. */
+	ret = gpiod_set_value_cansleep(priv->reset, 1);
+	if (ret) {
+		dev_err(priv->dev, "failed to assert reset: %d\n", ret);
+		return ret;
+	}
+
+	/* Disable clock after asserting reset */
+	clk_disable_unprepare(priv->clk);
+
+	return 0;
+}
+
+static int amd_bram_rproc_parse_fw(struct rproc *rproc,
+				   const struct firmware *fw)
+{
+	int ret;
+
+	ret = rproc_elf_load_rsc_table(rproc, fw);
+	if (ret == -EINVAL) {
+		dev_dbg(&rproc->dev, "no resource table found\n");
+		return 0;
+	}
+
+	return ret;
+}
+
+static const struct rproc_ops amd_bram_rproc_ops = {
+	.prepare	= amd_bram_rproc_prepare,
+	.start		= amd_bram_rproc_start,
+	.stop		= amd_bram_rproc_stop,
+	.load		= rproc_elf_load_segments,
+	.sanity_check	= rproc_elf_sanity_check,
+	.get_boot_addr	= rproc_elf_get_boot_addr,
+	.parse_fw	= amd_bram_rproc_parse_fw,
+};
+
+static int amd_bram_rproc_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct amd_bram_rproc *priv;
+	const char *fw_name = NULL;
+	struct rproc *rproc;
+	int ret;
+
+	ret = rproc_of_parse_firmware(dev, 0, &fw_name);
+	if (ret < 0 && ret != -EINVAL)
+		return dev_err_probe(dev, ret,
+				     "failed to parse firmware-name property\n");
+
+	rproc = devm_rproc_alloc(dev, dev_name(dev), &amd_bram_rproc_ops,
+				 fw_name, sizeof(*priv));
+	if (!rproc)
+		return -ENOMEM;
+
+	priv = rproc->priv;
+	priv->dev = dev;
+
+	/* Get the processor clock */
+	priv->clk = devm_clk_get(dev, NULL);
+	if (IS_ERR(priv->clk))
+		return dev_err_probe(dev, PTR_ERR(priv->clk),
+				     "failed to get clock\n");
+
+	/*
+	 * Keep the processor in reset until remoteproc has finished loading
+	 * firmware into the executable memory window described by reg and
+	 * translated through the parent bus ranges property.
+	 */
+	priv->reset = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
+	if (IS_ERR(priv->reset))
+		return dev_err_probe(dev, PTR_ERR(priv->reset),
+				     "failed to get reset gpio\n");
+
+	rproc->auto_boot = false;
+
+	ret = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64));
+	if (ret)
+		return dev_err_probe(dev, ret, "failed to set DMA mask\n");
+
+	platform_set_drvdata(pdev, rproc);
+
+	ret = devm_rproc_add(dev, rproc);
+	if (ret)
+		return dev_err_probe(dev, ret, "failed to register rproc\n");
+
+	return 0;
+}
+
+static const struct of_device_id amd_bram_rproc_of_match[] = {
+	{ .compatible = "amd,bram-rproc" },
+	{ /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, amd_bram_rproc_of_match);
+
+static struct platform_driver amd_bram_rproc_driver = {
+	.probe = amd_bram_rproc_probe,
+	.driver = {
+		.name = "amd-bram-rproc",
+		.of_match_table = amd_bram_rproc_of_match,
+	},
+};
+module_platform_driver(amd_bram_rproc_driver);
+
+MODULE_DESCRIPTION("AMD BRAM-based Remote Processor driver");
+MODULE_AUTHOR("Ben Levinsky <ben.levinsky@amd.com>");
+MODULE_LICENSE("GPL");
-- 
2.34.1