On Mon, Apr 30, 2018 at 05:37:49PM -0700, rishabhb at codeaurora.org wrote:

On 2018-04-30 07:33, Rob Herring wrote:

quoted

On Fri, Apr 27, 2018 at 5:57 PM,  [off-list ref] wrote:

quoted

On 2018-04-27 07:21, Rob Herring wrote:

quoted

On Mon, Apr 23, 2018 at 04:09:31PM -0700, Rishabh Bhatnagar wrote:

quoted

Documentation for last level cache controller device tree bindings,
client bindings usage examples.

Signed-off-by: Channagoud Kadabi <redacted>
Signed-off-by: Rishabh Bhatnagar <redacted>
---
 .../devicetree/bindings/arm/msm/qcom,llcc.txt      | 60
++++++++++++++++++++++
 1 file changed, 60 insertions(+)
 create mode 100644
Documentation/devicetree/bindings/arm/msm/qcom,llcc.txt

My comments on v4 still apply.

Rob

Hi Rob,
Reposting our replies to your comments on v4:

This is partially true, a bunch of SoCs would support this design but
clients IDs are not expected to change. So Ideally client drivers
could
hard code these IDs.

However I have other concerns of moving the client Ids in the driver.
The way the APIs implemented today are as follows:
#1. Client calls into system cache driver to get cache slice handle
with the usecase Id as input.
#2. System cache driver gets the phandle of system cache instance from
the client device to obtain the private data.
#3. Based on the usecase Id perform look up in the private data to get
cache slice handle.
#4. Return the cache slice handle to client

If we don't have the connection between client & system cache then the
 private data needs to declared as static global in the system cache
driver,
that limits us to have just once instance of system cache block.

How many instances do you have?

It is easier to put the data into the kernel and move it to DT later
than vice-versa. I don't think it is a good idea to do a custom
binding here and one that only addresses caches and nothing else in
the interconnect. So either we define an extensible and future-proof
binding or put the data into the kernel for now.

Rob

Hi rob,
Currently we have only instance but how do you propose we handle multiple
instances in future?

Worry about that when you have more that one. If it's only a  
theoretical possibility then it can wait.

Currently we do a lookup in the private data of the driver to get the slice
handle but, if we were to remove the client connection we will have to make
lookup table as global and we can't have more than one instance.
Also, can you suggest any extensible interconnect binding that we can refer
to?

There's been some work to add interconnect support for QCom chips. ATM, 
there is no binding for it and it is just a kernel driver and subsystem. 
I'm sure you can Google that to find as easily as me.

Rob