Hi Beleswar & Mathieu,
Please find my comments below.
On 7/29/25 10:34 AM, Mathieu Poirier wrote:
Hi Beleswar,
On Thu, Jul 24, 2025 at 07:01:44PM +0530, Beleswar Padhi wrote:
When attaching to a remote processor, it is implied that the rproc was
booted by an external entity. Thus, it's carveo
On 7/21/25 10:26 AM, Mathieu Poirier wrote:
On Mon, Jul 21, 2025 at 02:57:24PM +0800, Peng Fan wrote:
On Wed, Jul 16, 2025 at 02:30:47PM -0700, Tanmay Shah wrote:
AMD-Xilinx platform driver does not support iommu or recovery mechanism
yet. Disable both features in platform driver.
Signed
On 7/21/25 10:24 AM, Mathieu Poirier wrote:
Good morning,
On Wed, Jul 16, 2025 at 02:30:47PM -0700, Tanmay Shah wrote:
AMD-Xilinx platform driver does not support iommu or recovery mechanism
yet. Disable both features in platform driver.
Signed-off-by: Tanmay Shah
---
drivers/remoteproc
Fix kernel-doc warnings generated by following command:
`scripts/kernel-doc -Werror -Wshort-desc -Wall \
drivers/remoteproc/xlnx_r5_remoteproc.c > /dev/null`
warning: missing initial short description on line:
* struct mbox_info
...
Total 8 warnings fixed
Signed-off-by: Tanmay S
- Disable unsupported features from platform driver
- Fix kernle-doc warnings to make documentation better
Tanmay Shah (2):
remoteproc: xlnx: disable unsupported features
remoteproc: xlnx: fix kernel-doc warnings
drivers/remoteproc/xlnx_r5_remoteproc.c | 18 ++
1 file
AMD-Xilinx platform driver does not support iommu or recovery mechanism
yet. Disable both features in platform driver.
Signed-off-by: Tanmay Shah
---
drivers/remoteproc/xlnx_r5_remoteproc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c
b/drivers
ted due to bad refcount of power-domain managed by platform
management controller.
Signed-off-by: Tanmay Shah
---
drivers/remoteproc/xlnx_r5_remoteproc.c | 40 +
1 file changed, 40 insertions(+)
diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c
b/drivers/
When operating in split mode, it is a valid usecase to have
only one core enabled in the cluster. Remove exact core count
expecatation from the driver.
Signed-off-by: Tanmay Shah
---
Changes in v3:
- Fix commit message
- Add details about split mode configuration in comment
Change in v2
On 6/13/25 12:18 PM, Mathieu Poirier wrote:
Good day,
On Tue, Jun 10, 2025 at 12:27:38PM -0700, Tanmay Shah wrote:
It's a valid use case to have only one core enabled in cluster in split
mode. Remove exact core count expecatation from the driver.
I suggest:
"When operating in
It's a valid use case to have only one core enabled in cluster in split
mode. Remove exact core count expecatation from the driver.
Signed-off-by: Tanmay Shah
---
Change in v2:
- limit core_count to max 2
drivers/remoteproc/xlnx_r5_remoteproc.c | 5 +
1 file changed, 1 insertion(
ff-by: Tanmay Shah
---
drivers/remoteproc/xlnx_r5_remoteproc.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c
b/drivers/remoteproc/xlnx_r5_remoteproc.c
index 1af89782e116..f314dd5bdb26 100644
--- a/drivers/remoteproc/xlnx_r5_remoteproc.c
+++ b/dr
It's a valid use case to have only one core enabled in cluster in split
mode. Remove exact core count expecatation from the driver.
Signed-off-by: Tanmay Shah
---
drivers/remoteproc/xlnx_r5_remoteproc.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/remot
user.
Signed-off-by: Tanmay Shah
---
Changes in v2:
- Add comment on why version check is needed before calling EEMI call
to fw.
drivers/remoteproc/xlnx_r5_remoteproc.c | 34 -
1 file changed, 33 insertions(+), 1 deletion(-)
diff --git a/drivers/remoteproc
Hello Rob,
Thanks for the patch. Please find my comments below.
On 4/23/25 2:42 PM, Rob Herring (Arm) wrote:
Use the newly added of_reserved_mem_region_to_resource() and
of_reserved_mem_region_count() functions to handle "memory-region"
properties.
The error handling is a bit different in s
On 5/1/25 10:44 AM, Tanmay Shah wrote:
Hi Mathieu,
I tested this patchset on top of recent for-next branch. I don't see
issue on AMD-xlnx ZynqMP platform. With this:
Tested-by: Tanmay Shah
Hi Mathieu,
Looks like I said it too soon. Firmware loading works with this series,
but
Hi Mathieu,
I tested this patchset on top of recent for-next branch. I don't see
issue on AMD-xlnx ZynqMP platform. With this:
Tested-by: Tanmay Shah
On 4/24/25 9:14 AM, Mathieu Poirier wrote:
Arnaud, Daniel, Iuliana, Andrew and Tanmay - please test this patchset
on the platforms yo
On 4/22/25 2:10 PM, Mathieu Poirier wrote:
On Tue, 22 Apr 2025 at 12:30, Tanmay Shah wrote:
On 4/22/25 12:49 PM, Mathieu Poirier wrote:
On Tue, 22 Apr 2025 at 10:10, Tanmay Shah wrote:
On 4/22/25 10:59 AM, Mathieu Poirier wrote:
Good morning,
On Mon, Apr 14, 2025 at 11:46:01AM
On 4/22/25 12:49 PM, Mathieu Poirier wrote:
On Tue, 22 Apr 2025 at 10:10, Tanmay Shah wrote:
On 4/22/25 10:59 AM, Mathieu Poirier wrote:
Good morning,
On Mon, Apr 14, 2025 at 11:46:01AM -0700, Tanmay Shah wrote:
Powering off RPU using force_pwrdwn call results in system failure
if
On 4/22/25 10:59 AM, Mathieu Poirier wrote:
Good morning,
On Mon, Apr 14, 2025 at 11:46:01AM -0700, Tanmay Shah wrote:
Powering off RPU using force_pwrdwn call results in system failure
if there are multiple users of that RPU node. Better mechanism is to use
request_node and release_node
user.
Signed-off-by: Tanmay Shah
---
drivers/remoteproc/xlnx_r5_remoteproc.c | 29 -
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c
b/drivers/remoteproc/xlnx_r5_remoteproc.c
index 5aeedeaf3c41..3597359c0fc8 100644
--- a
.
Signed-off-by: Tanmay Shah
---
Changes in v5:
- remoteproc: xlnx: remove genpool use for OCM sram
Changes in v4:
- Free previously allocalted genpool if adding carveouts fail for any
sram.
- add comment about sram size used in creating carveouts.
Changes in v3:
- make @sram an array
On 8/26/24 11:22 AM, Mathieu Poirier wrote:
> Good morning,
>
> First and foremost the overall structure of your code has improved immensely
> and
> I commend you for that.
>
Thanks! I hope to get better.
> On Mon, Aug 19, 2024 at 10:09:38AM -0700, Tanmay Shah wrote:
.
Signed-off-by: Tanmay Shah
---
Changes in v4:
- Free previously allocalted genpool if adding carveouts fail for any
sram.
- add comment about sram size used in creating carveouts.
Changes in v3:
- make @sram an array rather than an array of pointers
- fix of_node_put usage to maintain
.
Signed-off-by: Tanmay Shah
---
Changes in v2:
- Expand commit message with power-domains related information.
Changes in v3:
- make @sram an array rather than an array of pointers
- fix of_node_put usage to maintain proper refcount of node
- s/proprty/property
- Use gen pool framework for mapping
Reviewed-by: Tanmay Shah
On 8/11/24 10:34 AM, Krzysztof Kozlowski wrote:
> All nodes need an explicit additionalProperties or unevaluatedProperties
> unless a $ref has one that's false. Add missing additionalProperties
> to fix dt_binding_check warning:
>
> xlnx,zynqmp-r
Hello Mathieu,
Thanks for reviews.
All the comments looks good, I will send next revision addressing them all.
On 7/22/24 11:39 AM, Mathieu Poirier wrote:
> Good morning,
>
> On Mon, Jul 15, 2024 at 06:39:54PM -0700, Tanmay Shah wrote:
>> AMD-Xilinx zynqmp platform contains on-c
.
Signed-off-by: Tanmay Shah
---
Changes in v2:
- Expand commit message with power-domains related information.
drivers/remoteproc/xlnx_r5_remoteproc.c | 131
1 file changed, 131 insertions(+)
diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c
b/drivers/remoteproc
AMD-Xilinx zynqmp platform contains on-chip sram memory (OCM).
R5 cores can access OCM and access is faster than DDR memory but slower
than TCM memories available. Sram region can have optional multiple
power-domains.
Signed-off-by: Tanmay Shah
---
drivers/remoteproc/xlnx_r5_remoteproc.c | 131
It is possible that remote processor is already running before
linux boot or remoteproc platform driver probe. Implement required
remoteproc framework ops to provide resource table address and
connect or disconnect with remote processor in such case.
Signed-off-by: Tanmay Shah
---
Changes in v6
On 6/18/24 11:55 AM, Mathieu Poirier wrote:
> On Tue, Jun 18, 2024 at 11:45:28AM -0500, Tanmay Shah wrote:
>>
>>
>> On 6/17/24 10:40 AM, Mathieu Poirier wrote:
>> > Good day,
>> >
>> > On Mon, Jun 10, 2024 at 08:42:27AM -0700, Tanmay Shah wrot
On 6/17/24 10:40 AM, Mathieu Poirier wrote:
> Good day,
>
> On Mon, Jun 10, 2024 at 08:42:27AM -0700, Tanmay Shah wrote:
>> It is possible that remote processor is already running before
>> linux boot or remoteproc platform driver probe. Implement required
>>
It is possible that remote processor is already running before
linux boot or remoteproc platform driver probe. Implement required
remoteproc framework ops to provide resource table address and
connect or disconnect with remote processor in such case.
Signed-off-by: Tanmay Shah
---
Changes in v5
On 6/4/24 3:23 PM, Bjorn Andersson wrote:
> On Mon, Jun 03, 2024 at 01:34:38PM -0700, Tanmay Shah wrote:
>> It is possible that remote processor is already running before
>> linux boot or remoteproc platform driver probe. Implement required
>> remoteproc framework ops to p
On 6/4/24 10:34 AM, Mathieu Poirier wrote:
Hi Mathieu,
Thanks for reviews.
Please find my comments below.
> Hi Tanmay,
>
> On Mon, Jun 03, 2024 at 01:34:38PM -0700, Tanmay Shah wrote:
>> It is possible that remote processor is already running before
>> linux boot o
It is possible that remote processor is already running before
linux boot or remoteproc platform driver probe. Implement required
remoteproc framework ops to provide resource table address and
connect or disconnect with remote processor in such case.
Signed-off-by: Tanmay Shah
---
Changes in v4
It is possible that remote processor is already running before
linux boot or remoteproc platform driver probe. Implement required
remoteproc framework ops to provide resource table address and
connect or disconnect with remote processor in such case.
Signed-off-by: Tanmay Shah
Changes in v3
On 5/23/24 12:05 PM, Mathieu Poirier wrote:
> On Wed, May 22, 2024 at 09:36:26AM -0500, Tanmay Shah wrote:
>>
>>
>> On 5/21/24 12:56 PM, Mathieu Poirier wrote:
>> > Hi Tanmay,
>> >
>> > On Fri, May 10, 2024 at 05:51:25PM -0700, Tanmay Shah wrot
On 5/21/24 12:56 PM, Mathieu Poirier wrote:
> Hi Tanmay,
>
> On Fri, May 10, 2024 at 05:51:25PM -0700, Tanmay Shah wrote:
>> It is possible that remote processor is already running before
>> linux boot or remoteproc platform driver probe. Implement required
>>
AMD-Xilinx zynqmp platform contains on-chip sram memory (OCM).
R5 cores can access OCM and access is faster than DDR memory but slower
than TCM memories available. Sram region can have optional multiple
power-domains.
Signed-off-by: Tanmay Shah
---
Changes in v2:
- Fix integer assignement to
It is possible that remote processor is already running before
linux boot or remoteproc platform driver probe. Implement required
remoteproc framework ops to provide resource table address and
connect or disconnect with remote processor in such case.
Signed-off-by: Tanmay Shah
---
Changes in v2
moteproc.c:995:26: sparse: warning: Using plain
integer as NULL pointer
Tanmay Shah (2):
drivers: remoteproc: xlnx: add attach detach support
drivers: remoteproc: xlnx: add sram support
drivers/remoteproc/xlnx_r5_remoteproc.c | 385 +++-
1 file changed, 380 insert
It is possible that remote processor is already running before
linux boot or remoteproc platform driver probe. Implement required
remoteproc framework ops to provide resource table address and
connect or disconnect with remote processor in such case.
Signed-off-by: Tanmay Shah
---
drivers
AMD-Xilinx zynqmp platform contains on-chip sram memory (OCM).
R5 cores can access OCM and access is faster than DDR memory but slower
than TCM memories available. Sram region can have optional multiple
power-domains.
Signed-off-by: Tanmay Shah
---
drivers/remoteproc/xlnx_r5_remoteproc.c | 221
code execution or data access compare
to DDR memory. Such sram region is made available to remoteproc nodes
via "sram" property. Add support in driver to parse and use OCM memory
via sram property.
Tanmay Shah (2):
drivers: remoteproc: xlnx: add attach detach support
drivers: remote
Add "else" case for default tcm mode to silent following static check:
zynqmp_r5_cluster_init()
error: uninitialized symbol 'tcm_mode'.
Fixes: a6b974b40f94 ("drivers: remoteproc: xlnx: Add Versal and Versal-NET
support")
Signed-off-by: Tanmay Shah
---
drivers/r
port")
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/202404231839.ohiy9lw8-...@intel.com/
Signed-off-by: Tanmay Shah
---
drivers/remoteproc/xlnx_r5_remoteproc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/remoteproc/xlnx_r5_rem
On 4/23/24 11:06 AM, Nathan Chancellor wrote:
> Hi Tanmay,
>
> On Thu, Apr 18, 2024 at 03:01:25PM -0700, Tanmay Shah wrote:
>> AMD-Xilinx Versal platform is successor of ZynqMP platform.
>> Real-time Processing Unit R5 cluster IP on Versal is same as
>> of ZynqMP
Processing Unit has two clusters and each
cluster contains dual core ARM Cortex-R52 processors. Each R52
core is assigned 128KB of TCM memory.
Signed-off-by: Tanmay Shah
---
drivers/remoteproc/xlnx_r5_remoteproc.c | 53 -
1 file changed, 17 insertions(+), 36 deletions(-)
diff
ZynqMP TCM information was fixed in driver. Now ZynqMP TCM information
is available in device-tree. Parse TCM information in driver
as per new bindings.
Signed-off-by: Tanmay Shah
---
Changes in v15:
- Use hardcode TCM addresses as fallback method if "reg" unavailable
- Remove
Signed-off-by: Radhey Shyam Pandey
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Tanmay Shah
---
.../remoteproc/xlnx,zynqmp-r5fss.yaml | 279 --
1 file changed, 257 insertions(+), 22 deletions(-)
diff --git
a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5f
t for future
platorms as well.
Signed-off-by: Tanmay Shah
---
drivers/remoteproc/xlnx_r5_remoteproc.c | 146 ++--
1 file changed, 12 insertions(+), 134 deletions(-)
diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c
b/drivers/remoteproc/xlnx_r5_remoteproc.c
index cfbd97b
-tree nodes can't be used simultaneously one
of them must be disabled. For zcu102-1.0 and zcu102-1.1 board
remoteproc split mode dts node is enabled and lockstep mode
dts is disabled.
Signed-off-by: Tanmay Shah
---
.../boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts | 8 +++
arch/arm64/boot/dts/x
t flexible.
- Add "items:" list in power-domains property
Radhey Shyam Pandey (1):
dt-bindings: remoteproc: add Tightly Coupled Memory (TCM) bindings
Tanmay Shah (3):
remoteproc: zynqmp: fix lockstep mode memory region
dts: zynqmp: add properties for TCM in remoteproc
remot
On 4/11/24 11:12 AM, Mathieu Poirier wrote:
> On Wed, Apr 10, 2024 at 05:36:30PM -0500, Tanmay Shah wrote:
>>
>>
>> On 4/10/24 11:59 AM, Mathieu Poirier wrote:
>> > On Mon, Apr 08, 2024 at 01:53:14PM -0700, Tanmay Shah wrote:
>> >> ZynqMP TCM infor
On 4/10/24 11:59 AM, Mathieu Poirier wrote:
> On Mon, Apr 08, 2024 at 01:53:14PM -0700, Tanmay Shah wrote:
>> ZynqMP TCM information was fixed in driver. Now ZynqMP TCM information
>> is available in device-tree. Parse TCM information in driver
>> as per new bindings.
ZynqMP TCM information was fixed in driver. Now ZynqMP TCM information
is available in device-tree. Parse TCM information in driver
as per new bindings.
Signed-off-by: Tanmay Shah
---
Changes in v14:
- Add Versal platform support
- Add Versal-NET platform support
- Maintain backward
-tree nodes can't be used simultaneously one
of them must be disabled. For zcu102-1.0 and zcu102-1.1 board
remoteproc split mode dts node is enabled and lockstep mode
dts is disabled.
Signed-off-by: Tanmay Shah
---
Changes in v14:
- Add xlnx,tcm-mode property in remoteproc node
.../boo
Signed-off-by: Radhey Shyam Pandey
Signed-off-by: Tanmay Shah
---
Changes in v14:
- Remove previous RB tag
- Add xlnx,tcm-mode property
- Add Versal platform support
- Add Versal-NET platform support
.../remoteproc/xlnx,zynqmp-r5fss.yaml | 279 --
1 file ch
mation available in device-tree
This patch series continues previous effort to upstream ZynqMP
TCM bindings:
Previous v4 version link:
https://lore.kernel.org/all/20230829181900.2561194-1-tanmay.s...@amd.com/
Previous v3 version link:
https://lore.kernel.org/all/1689964908-22371-1-git-send-email-radh
t for future
platorms as well.
Signed-off-by: Tanmay Shah
---
drivers/remoteproc/xlnx_r5_remoteproc.c | 146 ++--
1 file changed, 12 insertions(+), 134 deletions(-)
diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c
b/drivers/remoteproc/xlnx_r5_remoteproc.c
index cfbd97b
On 3/22/24 12:44 AM, Krzysztof Kozlowski wrote:
> On 21/03/2024 16:13, Tanmay Shah wrote:
>>
>>
>> On 3/21/24 2:39 AM, Krzysztof Kozlowski wrote:
>>> On 20/03/2024 16:14, Tanmay Shah wrote:
>>>>
>>>>
>>>> On 3/20/24 2:40 AM,
On 3/21/24 2:39 AM, Krzysztof Kozlowski wrote:
> On 20/03/2024 16:14, Tanmay Shah wrote:
>>
>>
>> On 3/20/24 2:40 AM, Krzysztof Kozlowski wrote:
>>> On 19/03/2024 15:42, Tanmay Shah wrote:
>>>>
>>>>
>>>> On 3/19/24 12:30 AM,
On 3/20/24 2:40 AM, Krzysztof Kozlowski wrote:
> On 19/03/2024 15:42, Tanmay Shah wrote:
>>
>>
>> On 3/19/24 12:30 AM, Krzysztof Kozlowski wrote:
>>> On 19/03/2024 01:51, Tanmay Shah wrote:
>>>> Hello Krzysztof,
>>>>
>>>> Thank
On 3/19/24 12:29 AM, Krzysztof Kozlowski wrote:
> On 11/03/2024 18:59, Tanmay Shah wrote:
>> From: Radhey Shyam Pandey
>>
>> Introduce bindings for TCM memory address space on AMD-xilinx Zynq
>> UltraScale+ platform. It will help in defining TCM in device-tree
>&
On 3/19/24 12:25 AM, Krzysztof Kozlowski wrote:
> On 19/03/2024 02:06, Tanmay Shah wrote:
>>
>>
>> On 3/17/24 1:55 PM, Krzysztof Kozlowski wrote:
>>> On 15/03/2024 22:15, Tanmay Shah wrote:
>>>> AMD-Xilinx Versal and Versal-NET are successor of Zynq
On 3/19/24 12:30 AM, Krzysztof Kozlowski wrote:
> On 19/03/2024 01:51, Tanmay Shah wrote:
>> Hello Krzysztof,
>>
>> Thanks for reviews. Please find my comments below.
>>
>> On 3/17/24 1:53 PM, Krzysztof Kozlowski wrote:
>>> On 15/03/2024 22:15, Tan
On 3/17/24 1:55 PM, Krzysztof Kozlowski wrote:
> On 15/03/2024 22:15, Tanmay Shah wrote:
>> AMD-Xilinx Versal and Versal-NET are successor of ZynqMP platform. ZynqMP
>> remoteproc driver is mostly compatible with new platforms except few
>> platform specific differences.
&
Hello Krzysztof,
Thanks for reviews. Please find my comments below.
On 3/17/24 1:53 PM, Krzysztof Kozlowski wrote:
> On 15/03/2024 22:15, Tanmay Shah wrote:
>> AMD-Xilinx Versal-NET platform is successor of Versal platform. It
>> contains multiple clusters of cortex-R52 real-
On 3/17/24 1:50 PM, Krzysztof Kozlowski wrote:
> On 15/03/2024 22:15, Tanmay Shah wrote:
>> AMD-Xilinx Versal platform is successor of ZynqMP platform. Real-time
>> Processor Unit R5 cluster IP on Versal is same as of ZynqMP Platform.
>> Only difference is power-domai
Hello,
Thanks for reviews, please find my comments below.
On 3/17/24 9:50 AM, Conor Dooley wrote:
> On Fri, Mar 15, 2024 at 02:15:31PM -0700, Tanmay Shah wrote:
>> AMD-Xilinx Versal platform is successor of ZynqMP platform. Real-time
>> Processor Unit R5 cluster IP on Versal is sa
AMD-Xilinx Versal platform is successor of ZynqMP platform. Real-time
Processor Unit R5 cluster IP on Versal is same as of ZynqMP Platform.
Only difference is power-domains ID needed by power management firmware.
Hence, keeping the compatible property same as of zynqmp node.
Signed-off-by: Tanmay
Hence that call to PMC firmware is avoided in the
driver for Versal-NET platform.
Signed-off-by: Tanmay Shah
---
drivers/remoteproc/xlnx_r5_remoteproc.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c
b/drivers/remot
memory. ATCM memory is 64KB, BTCM
and CTCM memoreis are 32KB each. Each TCM memory has its own dedicated
power-domain that needs to be requested before using it.
Signed-off-by: Tanmay Shah
---
.../remoteproc/xlnx,zynqmp-r5fss.yaml | 220 +++---
1 file changed, 184 insertions
ds on follwoing series:
Link: https://lore.kernel.org/all/20240311175926.1625180-1-tanmay.s...@amd.com/
title: add zynqmp TCM bindings
Tanmay Shah (3):
dt-bindings: remoteproc: add Versal platform support
dt-bindings: remoteproc: add Versal-NET platform
drivers: remoteproc: add Versal and Versa
On 3/12/24 7:13 AM, Krzysztof Kozlowski wrote:
> On 11/03/2024 18:59, Tanmay Shah wrote:
>> From: Radhey Shyam Pandey
>>
>> Introduce bindings for TCM memory address space on AMD-xilinx Zynq
>> UltraScale+ platform. It will help in defining TCM in device-tree
>&
On 3/12/24 7:10 AM, Krzysztof Kozlowski wrote:
> On 11/03/2024 17:27, Tanmay Shah wrote:
> >>> +then:
> >>> + patternProperties:
> >>> +"^r5f@[0-9a-f]+$":
> >>> + type: object
> >>> +
> >>
On 3/12/24 7:10 AM, Krzysztof Kozlowski wrote:
> On 11/03/2024 19:39, Tanmay Shah wrote:
> >>> +
> >>> +else:
> >>> + patternProperties:
> >>> +"^r5f@[0-9a-f]+$":
> >>> +
On 3/9/24 7:25 AM, Krzysztof Kozlowski wrote:
> On 01/03/2024 19:16, Tanmay Shah wrote:
> > From: Radhey Shyam Pandey
> >
> > Introduce bindings for TCM memory address space on AMD-xilinx Zynq
> > UltraScale+ platform. It will help in defining TCM in device-tr
ZynqMP TCM information was fixed in driver. Now ZynqMP TCM information
is available in device-tree. Parse TCM information in driver
as per new bindings.
Signed-off-by: Tanmay Shah
---
drivers/remoteproc/xlnx_r5_remoteproc.c | 112 ++--
1 file changed, 107 insertions(+), 5
-tree nodes can't be used simultaneously one
of them must be disabled. For zcu102-1.0 and zcu102-1.1 board
remoteproc split mode dts node is enabled and lockstep mode
dts is disabled.
Signed-off-by: Tanmay Shah
---
.../boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts | 8 +++
arch/arm64/boot/dts/x
Signed-off-by: Radhey Shyam Pandey
Signed-off-by: Tanmay Shah
---
Changes in v13:
- Have power-domains property for lockstep case instead of
keeping it flexible.
- Add "items:" list in power-domains property
Changes in v12:
- add "reg", "reg-names" a
t for future
platorms as well.
Signed-off-by: Tanmay Shah
---
drivers/remoteproc/xlnx_r5_remoteproc.c | 145 ++--
1 file changed, 12 insertions(+), 133 deletions(-)
diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c
b/drivers/remoteproc/xlnx_r5_remoteproc.c
index 4395ede
nues previous effort to upstream ZynqMP
TCM bindings:
Previous v4 version link:
https://lore.kernel.org/all/20230829181900.2561194-1-tanmay.s...@amd.com/
Previous v3 version link:
https://lore.kernel.org/all/1689964908-22371-1-git-send-email-radhey.shyam.pan...@amd.com/
Radhey Shyam Pandey (
Hello Krzysztof,
Thanks for reviews. Please find my comments below.
On 3/9/24 7:25 AM, Krzysztof Kozlowski wrote:
> On 01/03/2024 19:16, Tanmay Shah wrote:
> > From: Radhey Shyam Pandey
> >
> > Introduce bindings for TCM memory address space on AMD-xilinx Zynq
> > Ul
-tree nodes can't be used simultaneously one
of them must be disabled. For zcu102-1.0 and zcu102-1.1 board
remoteproc split mode dts node is enabled and lockstep mode
dts is disabled.
Signed-off-by: Tanmay Shah
---
.../boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts | 8 +++
arch/arm64/boot/dts/x
Signed-off-by: Radhey Shyam Pandey
Signed-off-by: Tanmay Shah
---
Changes in v12:
- add "reg", "reg-names" and "power-domains" in pattern properties
- add "reg" and "reg-names" in required list
- keep "power-domains" in requi
ZynqMP TCM information was fixed in driver. Now ZynqMP TCM information
is available in device-tree. Parse TCM information in driver
as per new bindings.
Signed-off-by: Tanmay Shah
---
Changes in v12:
- None
Changes in v11:
- Remove redundant initialization of the variable
- return
t for future
platorms as well.
Signed-off-by: Tanmay Shah
---
Changes in v12:
- None
drivers/remoteproc/xlnx_r5_remoteproc.c | 145 ++--
1 file changed, 12 insertions(+), 133 deletions(-)
diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c
b/drivers/remot
evious v3 version link:
https://lore.kernel.org/all/1689964908-22371-1-git-send-email-radhey.shyam.pan...@amd.com/
Radhey Shyam Pandey (1):
dt-bindings: remoteproc: add Tightly Coupled Memory (TCM) bindings
Radhey Shyam Pandey (1):
dt-bindings: remoteproc: add Tightly Coupled Memory (TCM) binding
Thanks for reviews.
Ack to all comments, I will address in next revision.
Tanmay
On 2/29/24 3:59 AM, Krzysztof Kozlowski wrote:
> On 19/02/2024 18:44, Tanmay Shah wrote:
> > From: Radhey Shyam Pandey
> >
> > Introduce bindings for TCM memory address space on AMD-xilin
On 2/28/24 11:08 AM, Mathieu Poirier wrote:
> On Mon, Feb 19, 2024 at 09:44:34AM -0800, Tanmay Shah wrote:
> > In lockstep mode, r5 core0 uses TCM of R5 core1. Following is lockstep
> > mode memory region as per hardware reference manual.
> >
> > | *TCM*
patch. So dtbs-check failure only with bindings patch is expected.
How to resolve this? Should I send dtb changes same as bindings? Or we can
ignore dtbs-check errors for now?
Thanks,
Tanmay
On 2/19/24 11:44 AM, Tanmay Shah wrote:
> From: Radhey Shyam Pandey
>
> Introduce bindings for T
On 2/28/24 11:06 AM, Mathieu Poirier wrote:
> On Mon, Feb 19, 2024 at 09:44:37AM -0800, Tanmay Shah wrote:
> > ZynqMP TCM information was fixed in driver. Now ZynqMP TCM information
> > is available in device-tree. Parse TCM information in driver
> > as per new bindings.
&
Hello,
By mistake same set of patches were sent twice in same git send-email command.
Anyone can be reviewed. Please let me know if I need to take any action to fix
it.
Thanks.
On 2/19/24 11:44 AM, Tanmay Shah wrote:
> Tightly-Coupled Memories(TCMs) are low-latency memory that provi
ZynqMP TCM information was fixed in driver. Now ZynqMP TCM information
is available in device-tree. Parse TCM information in driver
as per new bindings.
Signed-off-by: Tanmay Shah
---
Changes in v11:
- Remove redundant initialization of the variable
- return correct error code if memory
-tree nodes can't be used simultaneously one
of them must be disabled. For zcu102-1.0 and zcu102-1.1 board
remoteproc split mode dts node is enabled and lockstep mode
dts is disabled.
Signed-off-by: Tanmay Shah
---
.../boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts | 8 +++
arch/arm64/boot/dts/x
Signed-off-by: Radhey Shyam Pandey
Signed-off-by: Tanmay Shah
---
Changes in v11:
- Fix yamllint warning and reduce indentation as needed
.../remoteproc/xlnx,zynqmp-r5fss.yaml | 192 --
1 file changed, 170 insertions(+), 22 deletions(-)
diff --git
a/Documentation/
9181900.2561194-1-tanmay.s...@amd.com/
Previous v3 version link:
https://lore.kernel.org/all/1689964908-22371-1-git-send-email-radhey.shyam.pan...@amd.com/
Radhey Shyam Pandey (1):
dt-bindings: remoteproc: add Tightly Coupled Memory (TCM) bindings
Radhey Shyam Pandey (1):
dt-bindings: remoteproc: a
t for future
platorms as well.
Signed-off-by: Tanmay Shah
---
drivers/remoteproc/xlnx_r5_remoteproc.c | 145 ++--
1 file changed, 12 insertions(+), 133 deletions(-)
diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c
b/drivers/remoteproc/xlnx_r5_remoteproc.c
index 4395ede
ZynqMP TCM information was fixed in driver. Now ZynqMP TCM information
is available in device-tree. Parse TCM information in driver
as per new bindings.
Signed-off-by: Tanmay Shah
---
Changes in v11:
- Remove redundant initialization of the variable
- return correct error code if memory
1 - 100 of 215 matches
Mail list logo
