On 1/17/23 12:16 AM, Krzysztof Kozlowski wrote:
On 16/01/2023 18:43, Tanmay Shah wrote:
On 1/15/23 6:38 AM, Krzysztof Kozlowski wrote:
On 13/01/2023 19:08, Tanmay Shah wrote:
On 1/12/23 11:52 PM, Krzysztof Kozlowski wrote:
On 13/01/2023 08:30, Tanmay Shah wrote:
This patch introduces bindings for TCM memory address space on AMD-xilinx
platforms. As of now TCM addresses are hardcoded in xilinx remoteproc
driver. This bindings will help in defining TCM in device-tree and
make it's access platform agnostic and data-driven from the driver.
Subject: drop second/last, redundant "bindings". The "dt-bindings"
prefix is already stating that these are bindings.
Ack.
Where is driver or DTS? Are you now adding a dead binding without users?
TCM is used by drivers/remoteproc/xlnx_r5_remoteproc.c driver. Howerver,
we have hardcode addresses in TCM as bindings are not available yet.
I don't see usage of these compatibles there. You also did not supply
DTS here. Please provide users of bindings within the same patchset.
ACK. I will supply dts as well.
However, Is it ok if I convert this patch to RFC patch, and once
bindings are fixed I will send actual patch with driver support.
If bindings design is not correct then I might have to change
corresponding driver design lot.
First, why this driver is particularly special? Why should have other
treatment then all other cases?
It's not different than others and shouldn't be treated differently. I
just didn't know correct bindings representation.
Now I have some idea how this should be represented, so I will send
bindings patch, dts patch and driver patch all in same series.
Second, so think about bindings and do not submit something for "driver"
but something describing hardware.
ACK. It will take me some time to post next patch, as I will add support
of this tcm device in xlnx remoteproc driver as well.
Thanks for all your suggestions, they were helpful.
Best regards,
Krzysztof
