From: Michal Simek <michal.simek@amd.com>
To: Krzysztof Kozlowski <krzk@kernel.org>,
Ben Levinsky <ben.levinsky@amd.com>
Cc: andersson@kernel.org, mathieu.poirier@linaro.org,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
linux-remoteproc@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, tanmay.shah@amd.com
Subject: Re: [PATCH v2 1/2] dt-bindings: remoteproc: document AMD BRAM-based rproc
Date: Tue, 28 Apr 2026 11:04:06 +0200 [thread overview]
Message-ID: <86e464f2-974b-441d-9459-dd957c16993d@amd.com> (raw)
In-Reply-To: <998b67ff-192a-478f-a9c6-ddcd7773e27c@kernel.org>
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
next prev parent reply other threads:[~2026-04-28 9:11 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-27 16:27 [PATCH v2 0/2] remoteproc: add AMD BRAM-based remote processor driver Ben Levinsky
2026-04-27 16:27 ` [PATCH v2 1/2] dt-bindings: remoteproc: document AMD BRAM-based rproc Ben Levinsky
2026-04-28 6:50 ` Krzysztof Kozlowski
2026-04-28 8:33 ` Michal Simek
2026-04-28 8:47 ` Krzysztof Kozlowski
2026-04-28 9:04 ` Michal Simek [this message]
2026-04-28 9:14 ` Krzysztof Kozlowski
2026-04-28 13:09 ` Michal Simek
2026-04-28 13:12 ` Krzysztof Kozlowski
2026-04-28 13:18 ` Michal Simek
2026-04-28 13:28 ` Krzysztof Kozlowski
2026-04-27 16:27 ` [PATCH v2 2/2] remoteproc: add AMD BRAM-based remote processor driver Ben Levinsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86e464f2-974b-441d-9459-dd957c16993d@amd.com \
--to=michal.simek@amd.com \
--cc=andersson@kernel.org \
--cc=ben.levinsky@amd.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=krzk+dt@kernel.org \
--cc=krzk@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=mathieu.poirier@linaro.org \
--cc=robh@kernel.org \
--cc=tanmay.shah@amd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox