SDM845 System Cache Driver

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

Signed-off-by Channagoud Kadabi <[email protected]>

Signed-off-by Rishabh Bhatnagar <[email protected]>

---
 .../devicetree/bindings/arm/msm/qcom,llcc.txt      | 60 ++++++++++++++++++++++
 1 file changed, 60 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/msm/qcom,llcc.txt

Quoted 11 lines · Rishabh Bhatnagar

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

Signed-off-by Channagoud Kadabi <[email protected]>

Signed-off-by Rishabh Bhatnagar <[email protected]>

---
 .../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

Quoted 16 lines · Rob Herring

Quoted 4 lines · Rishabh Bhatnagar

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

Quoted 8 lines

Signed-off-by Channagoud Kadabi <[email protected]>

Signed-off-by Rishabh Bhatnagar <[email protected]>

---
 .../devicetree/bindings/arm/msm/qcom,llcc.txt      | 60
++++++++++++++++++++++
 1 file changed, 60 insertions(+)
 create mode 100644

Documentation/devicetree/bindings/arm/msm/qcom,llcc.txt

Quoted 3 lines

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.

Quoted 40 lines · On Fri, Apr 27, 2018 at 5:57 PM, <[email protected]> wrote:

Quoted 16 lines · Rob Herring

Quoted 4 lines · Rishabh Bhatnagar

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

Quoted 8 lines

Signed-off-by Channagoud Kadabi <[email protected]>

Signed-off-by Rishabh Bhatnagar <[email protected]>

---
 .../devicetree/bindings/arm/msm/qcom,llcc.txt      | 60
++++++++++++++++++++++
 1 file changed, 60 insertions(+)
 create mode 100644

Documentation/devicetree/bindings/arm/msm/qcom,llcc.txt

Quoted 3 lines

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

Quoted 4 lines

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

Quoted 54 lines · Rob Herring

Quoted 40 lines · On Fri, Apr 27, 2018 at 5:57 PM, <[email protected]> wrote:

Quoted 16 lines · Rob Herring

Quoted 4 lines · Rishabh Bhatnagar

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

Quoted 8 lines

Signed-off-by Channagoud Kadabi <[email protected]>

Signed-off-by Rishabh Bhatnagar <[email protected]>

---
 .../devicetree/bindings/arm/msm/qcom,llcc.txt      | 60
++++++++++++++++++++++
 1 file changed, 60 insertions(+)
 create mode 100644

Documentation/devicetree/bindings/arm/msm/qcom,llcc.txt

Quoted 3 lines

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

Quoted 4 lines

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.

Quoted 1 line

Rob

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

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?

drivers/soc/qcom/Kconfig +0 -0

index e050eb8..2b09321 100644

drivers/soc/qcom/Kconfig +10 -0

+	  driver.
+
+config QCOM_SDM845_LLCC
+	tristate "Qualcomm Technologies, Inc. SDM845 LLCC driver"
+	depends on QCOM_LLCC
+	help
+	  Say yes here to enable the LLCC driver for SDM845. This provides
+	  data required to configure LLCC so that clients can start using the
+	  LLCC slices.
+
 config QCOM_MDT_LOADER
 	tristate
 	select QCOM_SCM

LLCC (Last Level Cache Controller) provides additional cache memory in the system. LLCC is partitioned into multiple slices and each slice gets its own priority, size, ID and other config parameters. LLCC driver programs these parameters for each slice. Clients that are assigned to use LLCC need to get information such size & ID of the slice they get and activate or deactivate the slice as needed. LLCC driver provides API for the clients to perform these operations.

Signed-off-by Channagoud Kadabi <[email protected]>

Signed-off-by Rishabh Bhatnagar <[email protected]>

---
  drivers/soc/qcom/Kconfig           |  17 ++
  drivers/soc/qcom/Makefile          |   2 +
  drivers/soc/qcom/llcc-sdm845.c     | 108 +++++++++++
  drivers/soc/qcom/llcc-slice.c      | 380

  include/linux/soc/qcom/llcc-qcom.h | 167 ++++++++++++++++
  5 files changed, 674 insertions(+)

create mode 100644 drivers/soc/qcom/llcc-sdm845.c create mode 100644 drivers/soc/qcom/llcc-slice.c create mode 100644 include/linux/soc/qcom/llcc-qcom.h

drivers/soc/qcom/llcc-slice.c new file +19 -0

new file mode 100644
index 0000000..fd2b607
@@ -0,0 +1,380 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2017-2018, The Linux Foundation. All rights reserved.
+ *
+ */
+
+#include <linux/bitmap.h>
+#include <linux/bitops.h>
+#include <linux/device.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/mutex.h>
+#include <linux/of_device.h>
+#include <linux/regmap.h>
+#include <linux/slab.h>
+#include <linux/soc/qcom/llcc-qcom.h>
+
+#define ACTIVATE                      0x1
+#define DEACTIVATE                    0x2

drivers/soc/qcom/llcc-slice.c new file +16 -0

+#define ATTR0_BONUS_WAYS_SHIFT        0x10
+#define LLCC_STATUS_READ_DELAY 100
+
+#define CACHE_LINE_SIZE_SHIFT 6
+
+#define LLCC_COMMON_STATUS0            0x0003000c
+#define LLCC_LB_CNT_MASK               0xf0000000
+#define LLCC_LB_CNT_SHIFT              28
+
+#define MAX_CAP_TO_BYTES(n) (n * 1024)
+#define LLCC_TRP_ACT_CTRLn(n) (n * 0x1000)
+#define LLCC_TRP_STATUSn(n)   (4 + n * 0x1000)
+#define LLCC_TRP_ATTR0_CFGn(n) (0x21000 + 0x8 * n)
+#define LLCC_TRP_ATTR1_CFGn(n) (0x21004 + 0x8 * n)
+
+#define BANK_OFFSET_STRIDE     0x80000

drivers/soc/qcom/llcc-slice.c new file +9 -0

+{
+       struct of_phandle_args phargs;
+       struct llcc_drv_data *drv;
+       const struct llcc_slice_config *llcc_data_ptr;
+       struct llcc_slice_desc *desc;
+       struct platform_device *pdev;
+       u32 sz, count;
+
+       if (of_parse_phandle_with_args(dev->of_node, "cache-slices",

drivers/soc/qcom/llcc-slice.c new file +25 -0

+
+       llcc_data_ptr = drv->cfg;
+       sz = drv->cfg_size;
+       count = 0;
+
+       while (llcc_data_ptr && count < sz) {
+               if (llcc_data_ptr->usecase_id == phargs.args[0])
+                       break;
+               llcc_data_ptr++;
+               count++;
+       }
+
+       if (llcc_data_ptr == NULL || count == sz)
+               return ERR_PTR(-ENODEV);
+
+       desc = devm_kzalloc(dev, sizeof(*desc), GFP_KERNEL);
+       if (!desc)
+               return ERR_PTR(-ENOMEM);
+
+       desc->slice_id = llcc_data_ptr->slice_id;
+       desc->slice_size = llcc_data_ptr->max_cap;
+       desc->dev = &pdev->dev;
+
+       return desc;
+}

drivers/soc/qcom/llcc-slice.c new file +32 -0

+               if (!strcmp(name, slice_name))
+                       break;
+               index++;
+       }
+       return llcc_slice_get_entry(dev, index);
+}
+EXPORT_SYMBOL_GPL(llcc_slice_getd);
+
+/**
+ * llcc_slice_putd - llcc slice descritpor
+ * @desc: Pointer to llcc slice descriptor
+ */
+void llcc_slice_putd(struct llcc_slice_desc *desc)
+{
+       devm_kfree(desc->dev, desc);
+}
+EXPORT_SYMBOL_GPL(llcc_slice_putd);
+
+static int llcc_update_act_ctrl(struct llcc_drv_data *drv, u32 sid,
+                               u32 act_ctrl_reg_val, u32 status)
+{
+       u32 act_ctrl_reg;
+       u32 status_reg;
+       u32 slice_status;
+       int ret = 0;
+
+       act_ctrl_reg = drv->bcast_off + LLCC_TRP_ACT_CTRLn(sid);
+       status_reg = drv->bcast_off + LLCC_TRP_STATUSn(sid);
+
+       /* Set the ACTIVE trigger */
+       act_ctrl_reg_val |= ACT_CTRL_ACT_TRIG;
+       ret = regmap_write(drv->regmap, act_ctrl_reg, act_ctrl_reg_val);

drivers/soc/qcom/llcc-slice.c new file +22 -0

+       return ret;
+}
+
+/**
+ * llcc_slice_activate - Activate the llcc slice
+ * @desc: Pointer to llcc slice descriptor
+ *
+ * A value of zero will be returned on success and a negative errno will
+ * be returned in error cases
+ */
+int llcc_slice_activate(struct llcc_slice_desc *desc)
+{
+       int ret;
+       u32 act_ctrl_val;
+       struct llcc_drv_data *drv;
+
+       drv = dev_get_drvdata(desc->dev);
+       if (!drv)
+               return -EINVAL;
+
+       mutex_lock(&drv->lock);
+       if (test_bit(desc->slice_id, drv->bitmap)) {

drivers/soc/qcom/llcc-slice.c new file +19 -0

+       mutex_unlock(&drv->lock);
+
+       return ret;
+}
+EXPORT_SYMBOL_GPL(llcc_slice_activate);
+
+/**
+ * llcc_slice_deactivate - Deactivate the llcc slice
+ * @desc: Pointer to llcc slice descriptor
+ *
+ * A value of zero will be returned on success and a negative errno will
+ * be returned in error cases
+ */
+int llcc_slice_deactivate(struct llcc_slice_desc *desc)
+{
+       u32 act_ctrl_val;
+       int ret;
+       struct llcc_drv_data *drv;
+