Re: [PATCH v6 2/2] mmc: sdhci-msm: Initial support for MSM chipsets
Hi Bjorn,
> Hi Georgi,
>
> Thanks for working on this, unfortunately it seems like I need to port
> the rpm regulators to be able to test this.
> But I did find that...
>
Yes, the regulators support is still missing upstream. Until then, a basic
testing can be done by bypassing the regulators init part in order to use
the power on defaults for regulators and maybe also clocks.
> On Fri, Sep 27, 2013 at 9:57 AM, Georgi Djakov wrote:
>> ...
>> +static irqreturn_t sdhci_msm_pwr_irq(int irq, void *data)
>> +{
>> + struct sdhci_msm_host *msm_host = (struct sdhci_msm_host *)data;
>> ...
>> +static int sdhci_msm_probe(struct platform_device *pdev)
>> +{
>> + struct sdhci_host *host;
>> + struct sdhci_msm_host *msm_host;
>> ...
>> + ret = devm_request_threaded_irq(&pdev->dev, msm_host->pwr_irq,
>> NULL,
>> + sdhci_msm_pwr_irq, IRQF_ONESHOT,
>> + dev_name(&pdev->dev), host);
>> ...
>
> ...sdhci_msm_pwr_irq() expects the data pointer to be msm_host, not
> sdhci_host, so right now I only get a panic. So I suspect you mean
> msm_host as the last param here.
Yes, you are right, I have also noticed this and it is fixed in the next
version which i will be posting in the next few days. Thanks!
BR,
Georgi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5] mmc: sdhci-msm: Add support for MSM chipsets
This platform driver adds the support of Secure Digital Host Controller
Interface compliant controller found in Qualcomm MSM chipsets.
CC: Asutosh Das
CC: Venkat Gopalakrishnan
CC: Sahitya Tummala
CC: Subhash Jadavani
Signed-off-by: Georgi Djakov
---
Changes from v4:
- Simplified sdhci_msm_vreg_disable() and sdhci_msm_set_vdd_io_vol()
- Use devm_ioremap_resource() instead of devm_ioremap()
- Converted IS_ERR_OR_NULL to IS_ERR
- Disable regulators in sdhci_msm_remove()
- Check for DT node at the beginning in sdhci_msm_probe()
- Removed more redundant code
- Changes in some error messages
- Minor fixes
Changes from v3:
- Allocate memory for all required structs at once
- Added termination entry in sdhci_msm_dt_match[]
- Fixed a missing sdhci_pltfm_free() in probe()
- Removed redundant of_match_ptr
- Removed the unneeded function sdhci_msm_vreg_reset()
Changes from v2:
- Added DT bindings for clocks
- Moved voltage regulators data to platform data
- Removed unneeded includes
- Removed obsolete and wrapper functions
- Removed error checking where unnecessary
- Removed redundant _clk suffix from clock names
- Just return instead of goto where possible
- Minor fixes
Changes from v1:
- GPIO references are replaced by pinctrl
- DT parsing is done mostly by mmc_of_parse()
- Use of_match_device() for DT matching
- A few minor changes
.../devicetree/bindings/mmc/sdhci-msm.txt | 71 +++
drivers/mmc/host/Kconfig | 13 +
drivers/mmc/host/Makefile |1 +
drivers/mmc/host/sdhci-msm.c | 627
4 files changed, 712 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mmc/sdhci-msm.txt
create mode 100644 drivers/mmc/host/sdhci-msm.c
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
new file mode 100644
index 000..ee112da
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
@@ -0,0 +1,71 @@
+* Qualcomm SDHCI controller (sdhci-msm)
+
+This file documents differences between the core properties in mmc.txt
+and the properties used by the sdhci-msm driver.
+
+Required properties:
+- compatible: should be "qcom,sdhci-msm"
+- reg: should contain SDHC, SD Core register map
+- reg-names: indicates various resources passed to driver (via reg proptery)
by name
+ "reg-names" examples are "hc_mem" and "core_mem"
+- interrupts: should contain SDHC interrupts
+- interrupt-names: indicates interrupts passed to driver (via interrupts
property) by name
+ "interrupt-names" examples are "hc_irq" and "pwr_irq"
+- -supply: phandle to the regulator device tree node
+ "supply-name" examples are "vdd" and "vdd-io"
+- pinctrl-names: Should contain only one value - "default".
+- pinctrl-0: Should specify pin control groups used for this controller.
+- clocks: phandles to clock instances of the device tree nodes
+- clock-names:
+ iface: Main peripheral bus clock (PCLK/HCLK - AHB Bus clock) (required)
+ core: SDC MMC clock (MCLK) (required)
+ bus: SDCC bus voter clock (optional)
+
+Optional properties:
+- qcom,bus-speed-mode - specifies supported bus speed modes by host
+ The supported bus speed modes are :
+ "HS200_1p8v" - indicates that host can support HS200 at 1.8v
+ "HS200_1p2v" - indicates that host can support HS200 at 1.2v
+ "DDR_1p8v" - indicates that host can support DDR mode at 1.8v
+ "DDR_1p2v" - indicates that host can support DDR mode at 1.2v
+
+In the following, can be vdd (flash core voltage) or vdd-io (I/O
voltage).
+- qcom,-always-on - specifies whether supply should be kept "on"
always.
+- qcom,-lpm-sup - specifies whether supply can be kept in low power
mode (lpm).
+- qcom,-voltage-level - specifies voltage levels for supply. Should be
+specified in pairs (min, max), units uV.
+- qcom,-current-level - specifies load levels for supply in lpm or
high power mode
+ (hpm). Should be specified in pairs (lpm, hpm), units uA.
+
+Example:
+
+ aliases {
+ sdhc1 = &sdhc_1;
+ };
+
+ sdhc_1: qcom,sdhc@f9824900 {
+ compatible = "qcom,sdhci-msm";
+ reg = <0xf9824900 0x11c>, <0xf9824000 0x800>;
+ reg-names = "hc_mem", "core_mem";
+ interrupts = <0 123 0>, <0 138 0>;
+ interrupt-names = "hc_irq", "pwr_irq";
+ bus-width = <4>;
+ non-removable;
+
+ vdd-supply = <&pm8941_l21>;
+ vdd-io-supply = <&pm8941_l13>;
+ qcom,vdd-voltage-level = <295 295>;
+ qcom,vdd-current-level =
Re: [PATCH v5] mmc: sdhci-msm: Add support for MSM chipsets
Hi Stan,
Thank you for the detailed review on this patch.
On 09/17/2013 05:55 PM, Stanimir Varbanov wrote:
Hi Georgi,
Thanks for the patch.
I have some commnets below.
On 09/16/2013 05:23 PM, Georgi Djakov wrote:
This platform driver adds the support of Secure Digital Host Controller
Interface compliant controller found in Qualcomm MSM chipsets.
CC: Asutosh Das
CC: Venkat Gopalakrishnan
CC: Sahitya Tummala
CC: Subhash Jadavani
Signed-off-by: Georgi Djakov
---
Changes from v4:
- Simplified sdhci_msm_vreg_disable() and sdhci_msm_set_vdd_io_vol()
- Use devm_ioremap_resource() instead of devm_ioremap()
- Converted IS_ERR_OR_NULL to IS_ERR
- Disable regulators in sdhci_msm_remove()
- Check for DT node at the beginning in sdhci_msm_probe()
- Removed more redundant code
- Changes in some error messages
- Minor fixes
Changes from v3:
- Allocate memory for all required structs at once
- Added termination entry in sdhci_msm_dt_match[]
- Fixed a missing sdhci_pltfm_free() in probe()
- Removed redundant of_match_ptr
- Removed the unneeded function sdhci_msm_vreg_reset()
Changes from v2:
- Added DT bindings for clocks
- Moved voltage regulators data to platform data
- Removed unneeded includes
- Removed obsolete and wrapper functions
- Removed error checking where unnecessary
- Removed redundant _clk suffix from clock names
- Just return instead of goto where possible
- Minor fixes
Changes from v1:
- GPIO references are replaced by pinctrl
- DT parsing is done mostly by mmc_of_parse()
- Use of_match_device() for DT matching
- A few minor changes
.../devicetree/bindings/mmc/sdhci-msm.txt | 71 +++
drivers/mmc/host/Kconfig | 13 +
drivers/mmc/host/Makefile |1 +
drivers/mmc/host/sdhci-msm.c | 627
4 files changed, 712 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mmc/sdhci-msm.txt
create mode 100644 drivers/mmc/host/sdhci-msm.c
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
new file mode 100644
index 000..ee112da
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
@@ -0,0 +1,71 @@
+* Qualcomm SDHCI controller (sdhci-msm)
+
+This file documents differences between the core properties in mmc.txt
+and the properties used by the sdhci-msm driver.
+
+Required properties:
+- compatible: should be "qcom,sdhci-msm"
+- reg: should contain SDHC, SD Core register map
+- reg-names: indicates various resources passed to driver (via reg proptery)
by name
+ "reg-names" examples are "hc_mem" and "core_mem"
+- interrupts: should contain SDHC interrupts
+- interrupt-names: indicates interrupts passed to driver (via interrupts
property) by name
+ "interrupt-names" examples are "hc_irq" and "pwr_irq"
+- -supply: phandle to the regulator device tree node
+ "supply-name" examples are "vdd" and "vdd-io"
+- pinctrl-names: Should contain only one value - "default".
+- pinctrl-0: Should specify pin control groups used for this controller.
+- clocks: phandles to clock instances of the device tree nodes
+- clock-names:
+ iface: Main peripheral bus clock (PCLK/HCLK - AHB Bus clock) (required)
+ core: SDC MMC clock (MCLK) (required)
+ bus: SDCC bus voter clock (optional)
+
+Optional properties:
+- qcom,bus-speed-mode - specifies supported bus speed modes by host
+ The supported bus speed modes are :
+ "HS200_1p8v" - indicates that host can support HS200 at 1.8v
+ "HS200_1p2v" - indicates that host can support HS200 at 1.2v
+ "DDR_1p8v" - indicates that host can support DDR mode at 1.8v
+ "DDR_1p2v" - indicates that host can support DDR mode at 1.2v
+
+In the following, can be vdd (flash core voltage) or vdd-io (I/O
voltage).
+- qcom,-always-on - specifies whether supply should be kept "on"
always.
+- qcom,-lpm-sup - specifies whether supply can be kept in low power
mode (lpm).
+- qcom,-voltage-level - specifies voltage levels for supply. Should be
+specified in pairs (min, max), units uV.
+- qcom,-current-level - specifies load levels for supply in lpm or
high power mode
+ (hpm). Should be specified in pairs (lpm, hpm), units uA.
+
+Example:
+
+ aliases {
+ sdhc1 = &sdhc_1;
+ };
+
+ sdhc_1: qcom,sdhc@f9824900 {
+ compatible = "qcom,sdhci-msm";
+ reg = <0xf9824900 0x11c>, <0xf9824000 0x800>;
+ reg-names = "hc_mem", "core_mem";
+ interrupts = <0 123 0>, <0 138 0>;
+ interrupt-names = "hc_irq", "pwr_irq";
+ bus-width = <4>;
+ non-removable;
+
Re: [PATCH RFC v3] mmc: sdhci-msm: Add support for MSM chipsets
Hi Jaehoon, On 08/27/2013 11:55 AM, Jaehoon Chung wrote: Hi Georgi, I found the sdhci_msm_vreg_reset(). Why do you run enable->disable? +/* + * Reset vreg by ensuring it is off during probe. A call + * to enable vreg is needed to balance disable vreg + */ +static int sdhci_msm_vreg_reset(struct sdhci_msm_pltfm_data *pdata) I think that controller didn't have responsibility to ensure whether power is enabled or not at probing time. If just needed to balance vreg, then i think this function can be removed. How about? Also before using regulator_is_enabled(), i had found the hole for balancing the vreg. Thank you! I'll remove this function. BR, Georgi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC v3] mmc: sdhci-msm: Add support for MSM chipsets
Hi Ivan,
On 08/23/2013 10:34 AM, Ivan T. Ivanov wrote:
Hi Georgi,
On Tue, 2013-08-20 at 19:44 +0300, Georgi Djakov wrote:
This platform driver adds the support of Secure Digital Host
Controller Interface compliant controller in MSM chipsets.
CC: Asutosh Das
CC: Venkat Gopalakrishnan
CC: Sahitya Tummala
CC: Subhash Jadavani
Signed-off-by: Georgi Djakov
---
Changes from v2:
- Added DT bindings for clocks
- Moved voltage regulators data to platform data
- Removed unneeded includes
- Removed obsolete and wrapper functions
- Removed error checking where unnecessary
- Removed redundant _clk suffix from clock names
- Just return instead of goto where possible
- Minor fixes
Is this version intermediate step before you address
all previous comments?
+
+static const struct of_device_id sdhci_msm_dt_match[] = {
+ {.compatible = "qcom,sdhci-msm"},
Missing termination entry
+};
+
+MODULE_DEVICE_TABLE(of, sdhci_msm_dt_match);
+
+static int sdhci_msm_probe(struct platform_device *pdev)
+{
+ struct sdhci_host *host;
+ struct sdhci_pltfm_host *pltfm_host;
+ struct sdhci_msm_host *msm_host;
+ struct resource *core_memres = NULL;
+ int ret = 0, dead = 0;
+ struct pinctrl *pinctrl;
+
+ msm_host = devm_kzalloc(&pdev->dev, sizeof(struct sdhci_msm_host),
+ GFP_KERNEL);
+ if (!msm_host)
+ return -ENOMEM;
+
+ host = sdhci_pltfm_init(pdev, &msm_host->sdhci_msm_pdata, 0);
+ if (IS_ERR(host)) {
+ dev_err(mmc_dev(host->mmc), "sdhci_pltfm_init error\n");
+ return PTR_ERR(host);
+ }
+
+ pltfm_host = sdhci_priv(host);
+ pltfm_host->priv = msm_host;
+ msm_host->mmc = host->mmc;
+ msm_host->pdev = pdev;
+
+ ret = mmc_of_parse(host->mmc);
+ if (ret)
Shouldn't sdhci_pltfm_init operation be reverted?
+ return ret;
+
+ /* Extract platform data */
+ if (pdev->dev.of_node) {
+ msm_host->pdata = sdhci_msm_populate_pdata(&pdev->dev);
+ if (!msm_host->pdata) {
+ dev_err(&pdev->dev, "DT parsing error\n");
+ goto pltfm_free;
+ }
+ } else {
+ dev_err(&pdev->dev, "No device tree node\n");
+ goto pltfm_free;
+ }
+
+ /* Setup pins */
+ pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
+ if (IS_ERR(pinctrl))
+ dev_warn(&pdev->dev, "pins are not configured by the driver\n");
+
+ /* Setup Clocks */
+
+ /* Setup SDCC bus voter clock. */
+ msm_host->bus_clk = devm_clk_get(&pdev->dev, "bus");
+ if (!IS_ERR_OR_NULL(msm_host->bus_clk)) {
+ /* Vote for max. clk rate for max. performance */
+ ret = clk_set_rate(msm_host->bus_clk, INT_MAX);
+ if (ret)
+ goto pltfm_free;
+ ret = clk_prepare_enable(msm_host->bus_clk);
+ if (ret)
+ goto pltfm_free;
+ }
+
+ /* Setup main peripheral bus clock */
+ msm_host->pclk = devm_clk_get(&pdev->dev, "iface");
+ if (!IS_ERR(msm_host->pclk)) {
+ ret = clk_prepare_enable(msm_host->pclk);
+ if (ret) {
+ dev_err(&pdev->dev,
+ "Main peripheral clock setup failed (%d)\n",
+ ret);
+ goto bus_clk_disable;
+ }
+ }
+
+ /* Setup SDC MMC clock */
+ msm_host->clk = devm_clk_get(&pdev->dev, "core");
+ if (IS_ERR(msm_host->clk)) {
+ ret = PTR_ERR(msm_host->clk);
+ dev_err(&pdev->dev, "SDC MMC clock setup failed (%d)\n", ret);
+ goto pclk_disable;
+ }
+
+ ret = clk_prepare_enable(msm_host->clk);
+ if (ret)
+ goto pclk_disable;
+
+ /* Setup regulators */
+ ret = sdhci_msm_vreg_init(&pdev->dev, msm_host->pdata, true);
+ if (ret) {
+ dev_err(&pdev->dev, "Regulator setup failed (%d)\n", ret);
+ goto clk_disable;
+ }
+
+ /* Reset the core and Enable SDHC mode */
+ core_memres = platform_get_resource_byname(pdev,
+ IORESOURCE_MEM, "core_mem");
+ msm_host->core_mem = devm_ioremap(&pdev->dev, core_memres->start,
+ resource_size(core_memres));
+
+ if (!msm_host->core_mem) {
+ dev_err(&pdev->dev, "Failed to remap registers\n");
+ ret = -ENOMEM;
+ goto vre
[PATCH v4] mmc: sdhci-msm: Add support for MSM chipsets
This platform driver adds the support of Secure Digital Host Controller
Interface compliant controller found in Qualcomm MSM chipsets.
CC: Asutosh Das
CC: Venkat Gopalakrishnan
CC: Sahitya Tummala
CC: Subhash Jadavani
Signed-off-by: Georgi Djakov
---
Changes from v3:
- Allocate memory for all required structs at once
- Added termination entry in sdhci_msm_dt_match[]
- Fixed a missing sdhci_pltfm_free() in probe()
- Removed redundant of_match_ptr
- Removed the unneeded function sdhci_msm_vreg_reset()
Changes from v2:
- Added DT bindings for clocks
- Moved voltage regulators data to platform data
- Removed unneeded includes
- Removed obsolete and wrapper functions
- Removed error checking where unnecessary
- Removed redundant _clk suffix from clock names
- Just return instead of goto where possible
- Minor fixes
Changes from v1:
- GPIO references are replaced by pinctrl
- DT parsing is done mostly by mmc_of_parse()
- Use of_match_device() for DT matching
- A few minor changes
.../devicetree/bindings/mmc/sdhci-msm.txt | 71 +++
drivers/mmc/host/Kconfig | 13 +
drivers/mmc/host/Makefile |1 +
drivers/mmc/host/sdhci-msm.c | 660
4 files changed, 745 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mmc/sdhci-msm.txt
create mode 100644 drivers/mmc/host/sdhci-msm.c
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
new file mode 100644
index 000..ee112da
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
@@ -0,0 +1,71 @@
+* Qualcomm SDHCI controller (sdhci-msm)
+
+This file documents differences between the core properties in mmc.txt
+and the properties used by the sdhci-msm driver.
+
+Required properties:
+- compatible: should be "qcom,sdhci-msm"
+- reg: should contain SDHC, SD Core register map
+- reg-names: indicates various resources passed to driver (via reg proptery)
by name
+ "reg-names" examples are "hc_mem" and "core_mem"
+- interrupts: should contain SDHC interrupts
+- interrupt-names: indicates interrupts passed to driver (via interrupts
property) by name
+ "interrupt-names" examples are "hc_irq" and "pwr_irq"
+- -supply: phandle to the regulator device tree node
+ "supply-name" examples are "vdd" and "vdd-io"
+- pinctrl-names: Should contain only one value - "default".
+- pinctrl-0: Should specify pin control groups used for this controller.
+- clocks: phandles to clock instances of the device tree nodes
+- clock-names:
+ iface: Main peripheral bus clock (PCLK/HCLK - AHB Bus clock) (required)
+ core: SDC MMC clock (MCLK) (required)
+ bus: SDCC bus voter clock (optional)
+
+Optional properties:
+- qcom,bus-speed-mode - specifies supported bus speed modes by host
+ The supported bus speed modes are :
+ "HS200_1p8v" - indicates that host can support HS200 at 1.8v
+ "HS200_1p2v" - indicates that host can support HS200 at 1.2v
+ "DDR_1p8v" - indicates that host can support DDR mode at 1.8v
+ "DDR_1p2v" - indicates that host can support DDR mode at 1.2v
+
+In the following, can be vdd (flash core voltage) or vdd-io (I/O
voltage).
+- qcom,-always-on - specifies whether supply should be kept "on"
always.
+- qcom,-lpm-sup - specifies whether supply can be kept in low power
mode (lpm).
+- qcom,-voltage-level - specifies voltage levels for supply. Should be
+specified in pairs (min, max), units uV.
+- qcom,-current-level - specifies load levels for supply in lpm or
high power mode
+ (hpm). Should be specified in pairs (lpm, hpm), units uA.
+
+Example:
+
+ aliases {
+ sdhc1 = &sdhc_1;
+ };
+
+ sdhc_1: qcom,sdhc@f9824900 {
+ compatible = "qcom,sdhci-msm";
+ reg = <0xf9824900 0x11c>, <0xf9824000 0x800>;
+ reg-names = "hc_mem", "core_mem";
+ interrupts = <0 123 0>, <0 138 0>;
+ interrupt-names = "hc_irq", "pwr_irq";
+ bus-width = <4>;
+ non-removable;
+
+ vdd-supply = <&pm8941_l21>;
+ vdd-io-supply = <&pm8941_l13>;
+ qcom,vdd-voltage-level = <295 295>;
+ qcom,vdd-current-level = <9000 80>;
+ qcom,vdd-io-always-on;
+ qcom,vdd-io-lpm-sup;
+ qcom,vdd-io-voltage-level = <180 295>;
+ qcom,vdd-io-current-level = <6 22000>;
+ qcom,bus-speed-mode = "HS200_1p8v", "DDR_1p8v";
+
+ pinctrl-names = "default";
+
[PATCH v6 0/2] mmc: sdhci-msm: Add support for MSM chipsets
This patchset adds support of the Secure Digital Host Controller Interface compliant controller found in Qualcomm MSM chipsets. It has been tested on a APQ8074 Dragonboard. Changes from v5: - Driver is split into multiple patches - Do not initialize variables that are assigned later in code - Remove some useless comments - Use shorter variable names - Change pr_err() to dev_err() - Optimized sdhci_msm_setup_vreg() - Some code alignment fixes - Improved DT values sanity check - Added dev_dbg print for sdhci controller version in probe() - Added usleep_range() after SW reset - it can take some time - Added SDHCI_QUIRK_SINGLE_POWER_WRITE - power handled by PMIC - Renamed DT property vdd-io to vddio Changes from v4: - Simplified sdhci_msm_vreg_disable() and sdhci_msm_set_vdd_io_vol() - Use devm_ioremap_resource() instead of devm_ioremap() - Converted IS_ERR_OR_NULL to IS_ERR - Disable regulators in sdhci_msm_remove() - Check for DT node at the beginning in sdhci_msm_probe() - Removed more redundant code - Changes in some error messages - Minor fixes Changes from v3: - Allocate memory for all required structs at once - Added termination entry in sdhci_msm_dt_match[] - Fixed a missing sdhci_pltfm_free() in probe() - Removed redundant of_match_ptr - Removed the unneeded function sdhci_msm_vreg_reset() Changes from v2: - Added DT bindings for clocks - Moved voltage regulators data to platform data - Removed unneeded includes - Removed obsolete and wrapper functions - Removed error checking where unnecessary - Removed redundant _clk suffix from clock names - Just return instead of goto where possible - Minor fixes Changes from v1: - GPIO references are replaced by pinctrl - DT parsing is done mostly by mmc_of_parse() - Use of_match_device() for DT matching - A few minor changes Georgi Djakov (2): mmc: sdhci-msm: Initial SDHCI MSM driver documentation mmc: sdhci-msm: Initial support for MSM chipsets .../devicetree/bindings/mmc/sdhci-msm.txt | 70 +++ drivers/mmc/host/Kconfig | 13 + drivers/mmc/host/Makefile |1 + drivers/mmc/host/sdhci-msm.c | 644 4 files changed, 728 insertions(+) create mode 100644 Documentation/devicetree/bindings/mmc/sdhci-msm.txt create mode 100644 drivers/mmc/host/sdhci-msm.c -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 2/2] mmc: sdhci-msm: Initial support for MSM chipsets
This platform driver adds the initial support of Secure
Digital Host Controller Interface compliant controller
found in Qualcomm MSM chipsets.
CC: Asutosh Das
CC: Venkat Gopalakrishnan
CC: Sahitya Tummala
CC: Subhash Jadavani
Signed-off-by: Georgi Djakov
---
drivers/mmc/host/Kconfig | 13 +
drivers/mmc/host/Makefile|1 +
drivers/mmc/host/sdhci-msm.c | 644 ++
3 files changed, 658 insertions(+)
create mode 100644 drivers/mmc/host/sdhci-msm.c
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 8a4c066..2b31471 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -322,6 +322,19 @@ config MMC_ATMELMCI
If unsure, say N.
+config MMC_SDHCI_MSM
+ tristate "Qualcomm SDHCI Controller Support"
+ depends on ARCH_MSM
+ depends on MMC_SDHCI_PLTFM
+ help
+ This selects the Secure Digital Host Controller Interface (SDHCI)
+ support present in MSM SOCs from Qualcomm. The controller
+ supports SD/MMC/SDIO devices.
+
+ If you have a controller with this interface, say Y or M here.
+
+ If unsure, say N.
+
config MMC_MSM
tristate "Qualcomm SDCC Controller Support"
depends on MMC && ARCH_MSM
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index d422e21..efd6e6a 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -63,6 +63,7 @@ obj-$(CONFIG_MMC_SDHCI_OF_ESDHC) += sdhci-of-esdhc.o
obj-$(CONFIG_MMC_SDHCI_OF_HLWD)+= sdhci-of-hlwd.o
obj-$(CONFIG_MMC_SDHCI_BCM_KONA) += sdhci-bcm-kona.o
obj-$(CONFIG_MMC_SDHCI_BCM2835)+= sdhci-bcm2835.o
+obj-$(CONFIG_MMC_SDHCI_MSM)+= sdhci-msm.o
ifeq ($(CONFIG_CB710_DEBUG),y)
CFLAGS-cb710-mmc+= -DDEBUG
diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
new file mode 100644
index 000..55cb62f
--- /dev/null
+++ b/drivers/mmc/host/sdhci-msm.c
@@ -0,0 +1,644 @@
+/*
+ * drivers/mmc/host/sdhci-msm.c - Qualcomm MSM SDHCI Platform
+ * driver source file
+ *
+ * Copyright (c) 2013, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include "sdhci-pltfm.h"
+
+#define CORE_HC_MODE 0x78
+#define HC_MODE_EN 0x1
+
+#define CORE_POWER 0x0
+#define CORE_SW_RST(1 << 7)
+
+#define CORE_PWRCTL_STATUS 0xdc
+#define CORE_PWRCTL_MASK 0xe0
+#define CORE_PWRCTL_CLEAR 0xe4
+#define CORE_PWRCTL_CTL0xe8
+
+#define CORE_PWRCTL_BUS_OFF0x01
+#define CORE_PWRCTL_BUS_ON (1 << 1)
+#define CORE_PWRCTL_IO_LOW (1 << 2)
+#define CORE_PWRCTL_IO_HIGH(1 << 3)
+
+#define CORE_PWRCTL_BUS_SUCCESS0x01
+#define CORE_PWRCTL_BUS_FAIL (1 << 1)
+#define CORE_PWRCTL_IO_SUCCESS (1 << 2)
+#define CORE_PWRCTL_IO_FAIL(1 << 3)
+
+#define INT_MASK 0xf
+
+/* This structure keeps information per regulator */
+struct sdhci_msm_reg_data {
+ struct regulator *reg;
+ const char *name;
+ /* voltage level to be set */
+ u32 low_vol_level;
+ u32 high_vol_level;
+ /* Load values for low power and high power mode */
+ u32 lpm_uA;
+ u32 hpm_uA;
+
+ /* is this regulator needs to be always on? */
+ bool is_always_on;
+ /* is low power mode setting required for this regulator? */
+ bool lpm_sup;
+};
+
+struct sdhci_msm_pltfm_data {
+ u32 caps; /* Supported UHS-I Modes */
+ u32 caps2; /* More capabilities */
+ struct sdhci_msm_reg_data vdd; /* VDD/VCC regulator info */
+ struct sdhci_msm_reg_data vdd_io; /* VDD IO regulator info */
+};
+
+struct sdhci_msm_host {
+ struct platform_device *pdev;
+ void __iomem *core_mem; /* MSM SDCC mapped address */
+ int pwr_irq;/* power irq */
+ struct clk *clk;/* main SD/MMC bus clock */
+ struct clk *pclk; /* SDHC peripheral bus clock */
+ struct clk *bus_clk;/* SDHC bus voter clock */
+ struct sdhci_msm_pltfm_data pdata;
+ struct mmc_host *mmc;
+ struct sdhci_pltfm_data sdhci_msm_pdata;
+};
+
+enum vdd_io_level {
+ /* set vdd_io->low_vol_level */
+ VDD_IO_LOW,
+ /* set vdd_io->high_vol_level */
+ VDD_
[PATCH v6 1/2] mmc: sdhci-msm: Initial SDHCI MSM driver documentation
This patch adds documentation for Qualcomm SDHCI MSM driver.
It contains the differences between the core properties in mmc.txt and
the properties used by the sdhci-msm driver.
Signed-off-by: Georgi Djakov
---
.../devicetree/bindings/mmc/sdhci-msm.txt | 70
1 file changed, 70 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mmc/sdhci-msm.txt
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
new file mode 100644
index 000..81dd221
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
@@ -0,0 +1,70 @@
+* Qualcomm SDHCI controller (sdhci-msm)
+
+This file documents differences between the core properties in mmc.txt
+and the properties used by the sdhci-msm driver.
+
+Required properties:
+- compatible: should contain "qcom,sdhci-msm"
+- reg: should contain SDHC, SD Core register map
+- reg-names: indicates various resources passed to driver (via reg proptery)
by name
+ "reg-names" examples are "hc_mem" and "core_mem"
+- interrupts: should contain SDHC interrupts
+- interrupt-names: indicates interrupts passed to driver (via interrupts
property) by name
+ "interrupt-names" examples are "hc_irq" and "pwr_irq"
+- vdd-supply: phandle to the regulator for the vdd (flash core voltage) supply.
+- vddio-supply: phandle to the regulator for the vdd-io (i/o voltage) supply.
+- pinctrl-names: Should contain only one value - "default".
+- pinctrl-0: Should specify pin control groups used for this controller.
+- clocks: A list of phandle + clock-specifier pairs for the clocks listed in
clock-names
+- clock-names: Should contain the following:
+ "iface" - Main peripheral bus clock (PCLK/HCLK - AHB Bus clock)
(required)
+ "core" - SDC MMC clock (MCLK) (required)
+ "bus" - SDCC bus voter clock (optional)
+
+Optional properties:
+- qcom,bus-speed-mode: specifies the supported bus speed modes by host
+ The supported bus speed modes are :
+ "HS200_1p8v" - indicates that host can support HS200 at 1.8v
+ "HS200_1p2v" - indicates that host can support HS200 at 1.2v
+ "DDR_1p8v" - indicates that host can support DDR mode at 1.8v
+ "DDR_1p2v" - indicates that host can support DDR mode at 1.2v
+
+- qcom,{vdd,vddio}-always-on - specifies whether the supply should be kept
"on" always.
+- qcom,{vdd,vddio}-lpm-sup - specifies whether the supply can be kept in low
power mode.
+- qcom,{vdd,vddio}-voltage-level - specifies voltage levels for the supply.
+ Should be specified in pairs (min, max), units uV.
+- qcom,{vdd,vddio}-current-level - specifies load levels for the supply in lpm
+ or high power mode (hpm). Should be specified in pairs (lpm, hpm),
units uA.
+
+Example:
+
+ aliases {
+ sdhc1 = &sdhc_1;
+ };
+
+ sdhc_1: qcom,sdhc@f9824900 {
+ compatible = "qcom,sdhci-msm";
+ reg = <0xf9824900 0x11c>, <0xf9824000 0x800>;
+ reg-names = "hc_mem", "core_mem";
+ interrupts = <0 123 0>, <0 138 0>;
+ interrupt-names = "hc_irq", "pwr_irq";
+ bus-width = <4>;
+ non-removable;
+
+ vdd-supply = <&pm8941_l21>;
+ vddio-supply = <&pm8941_l13>;
+ qcom,vdd-voltage-level = <295 295>;
+ qcom,vdd-current-level = <9000 80>;
+ qcom,vddio-always-on;
+ qcom,vddio-lpm-sup;
+ qcom,vddio-voltage-level = <180 295>;
+ qcom,vddio-current-level = <6 22000>;
+ qcom,bus-speed-mode = "HS200_1p8v", "DDR_1p8v";
+
+ pinctrl-names = "default"
+ pinctrl-0 = <&sdc1_clk &sdc1_cmd &sdc1_data>;
+
+ clocks = <&iface>, <&core>, <&bus>;
+ clock-names = "iface", "core", "bus";
+
+ };
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/5] mmc: sdhci: Add quirks for Qualcomm MSM SDHCI controller
This patchset adds quirks for various workarounds and performance improvements required for Qualcomm MSM SDHCI driver. 1. Read Transfer Active/ Write Transfer Active may be not de-asserted after end of transaction. 2. Slow interrupt clearance at 400KHz may cause host driver interrupt handler to be called twice. 3. Controller does not support tuning commands as defined in SD 3.0 spec and CMD CRC errors are expected for tuning commands. 4. Improve the speed of secure discard operations by not using the calculated value, but the default one instead. 5. Controller can not handle large timeout values for R1B commands. Patches are based on v3.11-rc5. Georgi Djakov (5): mmc: sdhci: add quirk for R/W Transfer Active EOT mmc: sdhci: add quirk for slow interrupt clearance mmc: sdhci: add quirk to ignore CMD CRC err for tuning commands mmc: sdhci: add quirk for max_discard calculation mmc: sdhci: add quirk to ignore timeout err for R1B drivers/mmc/host/sdhci.c | 35 ++- include/linux/mmc/sdhci.h | 14 ++ 2 files changed, 48 insertions(+), 1 deletion(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] mmc: sdhci: add quirk to ignore CMD CRC err for tuning commands
The Qualcomm MSM SDHCI controller doesn't support tuning as specified
by the Standard Host Controller 3.0 spec. As a result of which, CMD CRC
errors are expected for tuning commands. Hence, add a new quirk
SDHCI_QUIRK2_IGNORE_CMDCRC_FOR_TUNING to ignore those errors for tuning
commands.
CC: Sahitya Tummala
Signed-off-by: Georgi Djakov
---
drivers/mmc/host/sdhci.c | 20
include/linux/mmc/sdhci.h |2 ++
2 files changed, 22 insertions(+)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index d3c9e59..39544b4 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2244,6 +2244,16 @@ static void sdhci_cmd_irq(struct sdhci_host *host, u32
intmask)
SDHCI_INT_INDEX))
host->cmd->error = -EILSEQ;
+ if (host->quirks2 & SDHCI_QUIRK2_IGNORE_CMDCRC_FOR_TUNING) {
+ if ((host->cmd->opcode == MMC_SEND_TUNING_BLOCK_HS200) ||
+ (host->cmd->opcode == MMC_SEND_TUNING_BLOCK)) {
+ if (intmask & SDHCI_INT_CRC) {
+ sdhci_reset(host, SDHCI_RESET_CMD);
+ host->cmd->error = 0;
+ }
+ }
+ }
+
if (host->cmd->error) {
tasklet_schedule(&host->finish_tasklet);
return;
@@ -2271,6 +2281,16 @@ static void sdhci_cmd_irq(struct sdhci_host *host, u32
intmask)
* fall through and take the SDHCI_INT_RESPONSE */
}
+ if (host->quirks2 & SDHCI_QUIRK2_IGNORE_CMDCRC_FOR_TUNING) {
+ if ((host->cmd->opcode == MMC_SEND_TUNING_BLOCK_HS200) ||
+ (host->cmd->opcode == MMC_SEND_TUNING_BLOCK)) {
+ if (intmask & SDHCI_INT_CRC) {
+ sdhci_finish_command(host);
+ return;
+ }
+ }
+ }
+
if (intmask & SDHCI_INT_RESPONSE)
sdhci_finish_command(host);
}
diff --git a/include/linux/mmc/sdhci.h b/include/linux/mmc/sdhci.h
index afd7cdf..603ef9d 100644
--- a/include/linux/mmc/sdhci.h
+++ b/include/linux/mmc/sdhci.h
@@ -102,6 +102,8 @@ struct sdhci_host {
#define SDHCI_QUIRK2_RDWR_TX_ACTIVE_EOT(1<<6)
/* Controller clears interrupt slowly and IRQ handler may be called twice */
#define SDHCI_QUIRK2_SLOW_INT_CLR (1<<7)
+/* Ignore CMD CRC errors for tuning commands */
+#define SDHCI_QUIRK2_IGNORE_CMDCRC_FOR_TUNING (1<<8)
int irq;/* Device IRQ */
void __iomem *ioaddr; /* Mapped address */
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/5] mmc: sdhci: add quirk to ignore timeout err for R1B
This patch adds a quirk to ignore data timeout error for R1B commands
as there will be no data associated and the busy timeout value for these
commands could be larger than the maximum timeout value that controller
can handle.
CC: Sahitya Tummala
Signed-off-by: Georgi Djakov
---
drivers/mmc/host/sdhci.c |3 +++
include/linux/mmc/sdhci.h |4
2 files changed, 7 insertions(+)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index e21bb6f..f120b14 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2353,6 +2353,9 @@ static void sdhci_data_irq(struct sdhci_host *host, u32
intmask)
}
}
+ if (host->quirks2 & SDHCI_QUIRK2_IGNORE_DATATOUT_FOR_R1BCMD)
+ return;
+
pr_err("%s: Got data interrupt 0x%08x even "
"though no data operation was in progress.\n",
mmc_hostname(host->mmc), (unsigned)intmask);
diff --git a/include/linux/mmc/sdhci.h b/include/linux/mmc/sdhci.h
index f42f6dd..ad65fb8 100644
--- a/include/linux/mmc/sdhci.h
+++ b/include/linux/mmc/sdhci.h
@@ -108,6 +108,10 @@ struct sdhci_host {
* the mmc queue. Otherwise, it takes a long time for secure discard kind of
* operations to complete. */
#define SDHCI_QUIRK2_USE_MAX_DISCARD_SIZE (1<<9)
+/* Ignore data timeout error for R1B commands as there will be no data
+ * associated and the busy timeout value for these commands could be larger
+ * than the maximum timeout value that controller can handle. */
+#define SDHCI_QUIRK2_IGNORE_DATATOUT_FOR_R1BCMD(1<<10)
int irq;/* Device IRQ */
void __iomem *ioaddr; /* Mapped address */
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/5] mmc: sdhci: add quirk for slow interrupt clearance
Initial version of Qualcomm SDHC has a hardware issue. This patch adds
a quirk SDHCI_QUIRK2_SLOW_INT_CLR to enable a workaround.
Hardware issue: Slow interrupt clearance at 400KHz may cause host
driver interrupt handler to be called twice.
Software workaround: Add 40us delay in interrupt handler when operating at
initialization frequency(400KHz).
CC: Venkat Gopalakrishnan
CC: Asutosh Das
CC: Sahitya Tummala
Signed-off-by: Georgi Djakov
---
drivers/mmc/host/sdhci.c |6 ++
include/linux/mmc/sdhci.h |2 ++
2 files changed, 8 insertions(+)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 57659fb..d3c9e59 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2460,12 +2460,18 @@ again:
if (intmask & SDHCI_INT_CMD_MASK) {
sdhci_writel(host, intmask & SDHCI_INT_CMD_MASK,
SDHCI_INT_STATUS);
+ if ((host->quirks2 & SDHCI_QUIRK2_SLOW_INT_CLR) &&
+ (host->clock <= 40))
+ udelay(40);
sdhci_cmd_irq(host, intmask & SDHCI_INT_CMD_MASK);
}
if (intmask & SDHCI_INT_DATA_MASK) {
sdhci_writel(host, intmask & SDHCI_INT_DATA_MASK,
SDHCI_INT_STATUS);
+ if ((host->quirks2 & SDHCI_QUIRK2_SLOW_INT_CLR) &&
+ (host->clock <= 40))
+ udelay(40);
sdhci_data_irq(host, intmask & SDHCI_INT_DATA_MASK);
}
diff --git a/include/linux/mmc/sdhci.h b/include/linux/mmc/sdhci.h
index 3783f4c..afd7cdf 100644
--- a/include/linux/mmc/sdhci.h
+++ b/include/linux/mmc/sdhci.h
@@ -100,6 +100,8 @@ struct sdhci_host {
#define SDHCI_QUIRK2_BROKEN_HOST_CONTROL (1<<5)
/* Controller cannot de-assert Read/Write Transfer Active after transaction */
#define SDHCI_QUIRK2_RDWR_TX_ACTIVE_EOT(1<<6)
+/* Controller clears interrupt slowly and IRQ handler may be called twice */
+#define SDHCI_QUIRK2_SLOW_INT_CLR (1<<7)
int irq;/* Device IRQ */
void __iomem *ioaddr; /* Mapped address */
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/5] mmc: sdhci: add quirk for max_discard calculation
The SDHCI driver by default specifies a parameter that causes the core
layer to calculate a max discard value which will be set on the mmc queue.
Unfortunately the value calculated because of this would be very small
compared to what comes in by default. As a result of this, any secure
discard kind of operations are very slow.
Add quirk so that the SDHCI host can use the default max_discard value.
CC: Krishna Konda
Signed-off-by: Georgi Djakov
---
drivers/mmc/host/sdhci.c |3 ++-
include/linux/mmc/sdhci.h |4
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 39544b4..e21bb6f 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2957,7 +2957,8 @@ int sdhci_add_host(struct sdhci_host *host)
if (host->quirks & SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK)
host->timeout_clk = mmc->f_max / 1000;
- mmc->max_discard_to = (1 << 27) / host->timeout_clk;
+ if (!(host->quirks2 & SDHCI_QUIRK2_USE_MAX_DISCARD_SIZE))
+ mmc->max_discard_to = (1 << 27) / host->timeout_clk;
mmc->caps |= MMC_CAP_SDIO_IRQ | MMC_CAP_ERASE | MMC_CAP_CMD23;
diff --git a/include/linux/mmc/sdhci.h b/include/linux/mmc/sdhci.h
index 603ef9d..f42f6dd 100644
--- a/include/linux/mmc/sdhci.h
+++ b/include/linux/mmc/sdhci.h
@@ -104,6 +104,10 @@ struct sdhci_host {
#define SDHCI_QUIRK2_SLOW_INT_CLR (1<<7)
/* Ignore CMD CRC errors for tuning commands */
#define SDHCI_QUIRK2_IGNORE_CMDCRC_FOR_TUNING (1<<8)
+/* Dont use the max_discard_to so that the maximum discard unit gets picked by
+ * the mmc queue. Otherwise, it takes a long time for secure discard kind of
+ * operations to complete. */
+#define SDHCI_QUIRK2_USE_MAX_DISCARD_SIZE (1<<9)
int irq;/* Device IRQ */
void __iomem *ioaddr; /* Mapped address */
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/5] mmc: sdhci: add quirk for R/W Transfer Active EOT
Initial version of Qualcomm SDHC has a hardware issue. This patch adds
a quirk SDHCI_QUIRK2_RDWR_TX_ACTIVE_EOT to enable a workaround.
Hardware issue: Read Transfer Active/ Write Transfer Active may be
not de-asserted after end of transaction.
Software workaround: Set Software Reset for DAT line in Software Reset
Register (Bit 2).
CC: Venkat Gopalakrishnan
CC: Asutosh Das
CC: Sahitya Tummala
Signed-off-by: Georgi Djakov
---
drivers/mmc/host/sdhci.c |3 +++
include/linux/mmc/sdhci.h |2 ++
2 files changed, 5 insertions(+)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index a78bd4f..57659fb 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2155,6 +2155,9 @@ static void sdhci_tasklet_finish(unsigned long param)
controllers do not like that. */
sdhci_reset(host, SDHCI_RESET_CMD);
sdhci_reset(host, SDHCI_RESET_DATA);
+ } else {
+ if (host->quirks2 & SDHCI_QUIRK2_RDWR_TX_ACTIVE_EOT)
+ sdhci_reset(host, SDHCI_RESET_DATA);
}
host->mrq = NULL;
diff --git a/include/linux/mmc/sdhci.h b/include/linux/mmc/sdhci.h
index e3c6a74..3783f4c 100644
--- a/include/linux/mmc/sdhci.h
+++ b/include/linux/mmc/sdhci.h
@@ -98,6 +98,8 @@ struct sdhci_host {
#define SDHCI_QUIRK2_CARD_ON_NEEDS_BUS_ON (1<<4)
/* Controller has a non-standard host control register */
#define SDHCI_QUIRK2_BROKEN_HOST_CONTROL (1<<5)
+/* Controller cannot de-assert Read/Write Transfer Active after transaction */
+#define SDHCI_QUIRK2_RDWR_TX_ACTIVE_EOT(1<<6)
int irq;/* Device IRQ */
void __iomem *ioaddr; /* Mapped address */
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC v2] mmc: sdhci-msm: Add support for MSM chipsets
Hi Ivan,
On 08/15/2013 10:22 AM, Ivan T. Ivanov wrote:
Hi Georgi,
I have several comments below.
Shouldn't we add required clocks here? It looks that some of them
are optional and others mandatory.
Yes, there are various clocks for MMC, SD/SDIO and at least 400mhz must
be provided for the initialization process.
I'll create a device-tree properties for clocks. Thanks!
+#include
+#include
It seems that this is not required.
Correct, many of them are not required. Thanks!
+#define CORE_PWRCTL_STATUS 0xDC
Please use lower chars for hex numbers
Ok.
+/* This structure keeps information per regulator */
+struct sdhci_msm_reg_data {
+ /* voltage regulator handle */
+ struct regulator *reg;
+ /* regulator name */
+ const char *name;
+ /* voltage level to be set */
+ u32 low_vol_level;
+ u32 high_vol_level;
+ /* Load values for low power and high power mode */
+ u32 lpm_uA;
+ u32 hpm_uA;
+
+ /* is this regulator enabled? */
+ bool is_enabled;
+ /* is this regulator needs to be always on? */
+ bool is_always_on;
+ /* is low power mode setting required for this regulator? */
+ bool lpm_sup;
+};
+
+/*
+ * This structure keeps information for all the
+ * regulators required for a SDCC slot.
+ */
+struct sdhci_msm_slot_reg_data {
+ /* keeps VDD/VCC regulator info */
+ struct sdhci_msm_reg_data *vdd_data;
+ /* keeps VDD IO regulator info */
+ struct sdhci_msm_reg_data *vdd_io_data;
Why not allocate memory at once? I looks like both of
them are required.
Agree. I'll merge all of them into one structure. Thanks!
+ pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ dev_err(dev, "failed to allocate memory for platform data\n");
+ goto out;
Just return immediately? Here and bellow.
Ok.
+ /* Get the regulator handle */
+ vreg->reg = devm_regulator_get(dev, vreg->name);
+ if (IS_ERR(vreg->reg)) {
+ ret = PTR_ERR(vreg->reg);
+ pr_err("%s: devm_regulator_get(%s) failed. ret=%d\n",
+ __func__, vreg->name, ret);
__func__ did not bring any additional info. Please remove it.
Ok.
+ goto out;
+ }
+
+ /* sanity check */
+ if (!vreg->high_vol_level || !vreg->hpm_uA) {
+ pr_err("%s: %s invalid constraints specified\n",
+ __func__, vreg->name);
same thing ...
+ ret = -EINVAL;
+ }
+
+out:
+ return ret;
+}
+
+static void sdhci_msm_vreg_deinit_reg(struct sdhci_msm_reg_data *vreg)
+{
+ if (vreg->reg)
If regulator reference has to be checked it should be IS_ERR(vreg->reg).
+ devm_regulator_put(vreg->reg);
There is no need for this with device managed resources.
Ok.
+}
+
+static int sdhci_msm_vreg_set_optimum_mode(struct sdhci_msm_reg_data
+ *vreg, int uA_load)
+{
+ int ret = 0;
+
+ /*
+* regulators that do not support regulator_set_voltage also
+* do not support regulator_set_optimum_mode
+*/
+ ret = regulator_set_optimum_mode(vreg->reg, uA_load);
+ if (ret < 0)
+ pr_err
+ ("%s: regulator_set_optimum_mode(%s,uA_load=%d) fail(%d)\n",
+__func__, vreg->name, uA_load, ret);
+ else
+ /*
+* regulator_set_optimum_mode() can return non zero
+* value even for success case.
+*/
+ ret = 0;
+ return ret;
Is it really necessary to have function wrapper?
Will clean it.
+/* This init function should be called only once for each SDHC slot */
+static int sdhci_msm_vreg_init(struct device *dev,
+ struct sdhci_msm_pltfm_data *pdata, bool is_init)
+{
+ int ret = 0;
+ struct sdhci_msm_slot_reg_data *curr_slot;
+ struct sdhci_msm_reg_data *curr_vdd_reg, *curr_vdd_io_reg;
+
+ curr_slot = pdata->vreg_data;
+ if (!curr_slot)
This could not happen.
+ goto out;
+
+ curr_vdd_reg = curr_slot->vdd_data;
+ curr_vdd_io_reg = curr_slot->vdd_io_data;
+
+ if (!is_init)
+ /* Deregister all regulators from regulator framework */
+ goto vdd_io_reg_deinit;
+
+ /*
+* Get the regulator handle from voltage regulator framework
+* and then try to set the voltage level for the regulator
+*/
+ if (curr_vdd_reg) {
Why you check for this? It is alway true.
+ ret = sdhci_msm_vreg_init_reg(dev, curr_vdd_reg);
+ if (ret)
+ goto out;
+ }
+ if (curr_vdd_io_reg) {
+ ret = sdhci_msm_vreg_init_reg(dev, curr_vdd_io_reg);
+ if (ret)
+ goto vdd_reg_deinit;
+ }
+ re
Re: [PATCH RFC v2] mmc: sdhci-msm: Add support for MSM chipsets
Hi Jaehoon,
Thank you for noticing this and providing feedback. I will make it use
the framework function.
BR,
Georgi
On 08/19/2013 10:27 AM, Jaehoon Chung wrote:
Hi Georgi,
I found the you use the "vreg->is_enabled".
why don't you use the regulator_is_enabled()? i think better that use this
function.
Is there a special reason that use the "vreg->is_enabled"?
Best Regards,
Jaehoon Chung
On 08/13/2013 11:06 PM, Georgi Djakov wrote:
This platform driver adds the support of Secure Digital Host
Controller Interface compliant controller in MSM chipsets.
CC: Asutosh Das
CC: Venkat Gopalakrishnan
CC: Sahitya Tummala
CC: Subhash Jadavani
Signed-off-by: Georgi Djakov
---
Changes from v1:
- GPIO references are replaced by pinctrl
- DT parsing is done mostly by mmc_of_parse()
- Use of_match_device() for DT matching
- A few minor changes
.../devicetree/bindings/mmc/sdhci-msm.txt | 62 ++
drivers/mmc/host/Kconfig | 13 +
drivers/mmc/host/Makefile |1 +
drivers/mmc/host/sdhci-msm.c | 813
4 files changed, 889 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mmc/sdhci-msm.txt
create mode 100644 drivers/mmc/host/sdhci-msm.c
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
new file mode 100644
index 000..4008f1f
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
@@ -0,0 +1,62 @@
+* Qualcomm SDHCI controller (sdhci-msm)
+
+This file documents differences between the core properties in mmc.txt
+and the properties used by the sdhci-msm driver.
+
+Required properties:
+- compatible: should be "qcom,sdhci-msm"
+- reg: should contain SDHC, SD Core register map
+- reg-names: indicates various resources passed to driver (via reg proptery)
by name
+ "reg-names" examples are "hc_mem" and "core_mem"
+- interrupts: should contain SDHC interrupts
+- interrupt-names: indicates interrupts passed to driver (via interrupts
property) by name
+ "interrupt-names" examples are "hc_irq" and "pwr_irq"
+- -supply: phandle to the regulator device tree node
+ "supply-name" examples are "vdd" and "vdd-io"
+- pinctrl-names: Should contain only one value - "default".
+- pinctrl-0: Should specify pin control groups used for this controller.
+
+Optional properties:
+- qcom,bus-speed-mode - specifies supported bus speed modes by host
+ The supported bus speed modes are :
+ "HS200_1p8v" - indicates that host can support HS200 at 1.8v
+ "HS200_1p2v" - indicates that host can support HS200 at 1.2v
+ "DDR_1p8v" - indicates that host can support DDR mode at 1.8v
+ "DDR_1p2v" - indicates that host can support DDR mode at 1.2v
+
+In the following, can be vdd (flash core voltage) or vdd-io (I/O
voltage).
+- qcom,-always-on - specifies whether supply should be kept "on"
always.
+- qcom,-lpm-sup - specifies whether supply can be kept in low power
mode (lpm).
+- qcom,-voltage-level - specifies voltage levels for supply. Should be
+specified in pairs (min, max), units uV.
+- qcom,-current-level - specifies load levels for supply in lpm or
high power mode
+ (hpm). Should be specified in pairs (lpm, hpm), units uA.
+
+Example:
+
+ aliases {
+ sdhc1 = &sdhc_1;
+ };
+
+ sdhc_1: qcom,sdhc@f9824900 {
+ compatible = "qcom,sdhci-msm";
+ reg = <0xf9824900 0x11c>, <0xf9824000 0x800>;
+ reg-names = "hc_mem", "core_mem";
+ interrupts = <0 123 0>, <0 138 0>;
+ interrupt-names = "hc_irq", "pwr_irq";
+ bus-width = <4>;
+ non-removable;
+
+ vdd-supply = <&pm8941_l21>;
+ vdd-io-supply = <&pm8941_l13>;
+ qcom,vdd-voltage-level = <295 295>;
+ qcom,vdd-current-level = <9000 80>;
+ qcom,vdd-io-always-on;
+ qcom,vdd-io-lpm-sup;
+ qcom,vdd-io-voltage-level = <180 295>;
+ qcom,vdd-io-current-level = <6 22000>;
+ qcom,bus-speed-mode = "HS200_1p8v", "DDR_1p8v";
+
+ pinctrl-names = "default"
+ pinctrl-0 = <&sdc1_clk &sdc1_cmd &sdc1_data>;
+ };
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 8a4c066..2b31471 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -322,6 +322,19 @@ config MMC_ATMELMCI
If unsure, say N.
+config MMC_SDHCI_MSM
+ tristate &q
[PATCH] mmc: sdhci-msm: Add support for MSM chipsets
This platform driver adds the support of Secure Digital Host
Controller Interface compliant controller in MSM chipsets.
CC: Asutosh Das
CC: Venkat Gopalakrishnan
CC: Sahitya Tummala
CC: Subhash Jadavani
Signed-off-by: Georgi Djakov
---
This is an initial version of the Qualcomm MSM SDHCI driver.
It is based on the SDHCI code from coreaurora.org with minor
modifications. The MMC standard DT bindings are used where
possible. The patch applies to v3.11-rc3.
.../devicetree/bindings/mmc/sdhci-msm.txt | 71 ++
drivers/mmc/host/Kconfig | 13 +
drivers/mmc/host/Makefile |1 +
drivers/mmc/host/sdhci-msm.c | 968
4 files changed, 1053 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mmc/sdhci-msm.txt
create mode 100644 drivers/mmc/host/sdhci-msm.c
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
new file mode 100644
index 000..c7b21c8
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
@@ -0,0 +1,71 @@
+* Qualcomm SDHCI controller (sdhci-msm)
+
+This file documents differences between the core properties in mmc.txt
+and the properties used by the sdhci-msm driver.
+
+Required properties:
+- compatible: should be "qcom,sdhci-msm"
+- reg: should contain SDHC, SD Core register map
+- reg-names: indicates various resources passed to driver (via reg proptery)
by name
+ "reg-names" examples are "hc_mem" and "core_mem"
+- interrupts: should contain SDHC interrupts
+- interrupt-names: indicates interrupts passed to driver (via interrupts
property) by name
+ "interrupt-names" examples are "hc_irq" and "pwr_irq"
+- -supply: phandle to the regulator device tree node
+ "supply-name" examples are "vdd" and "vdd-io"
+
+Optional properties:
+- qcom,bus-speed-mode - specifies supported bus speed modes by host
+ The supported bus speed modes are :
+ "HS200_1p8v" - indicates that host can support HS200 at 1.8v
+ "HS200_1p2v" - indicates that host can support HS200 at 1.2v
+ "DDR_1p8v" - indicates that host can support DDR mode at 1.8v
+ "DDR_1p2v" - indicates that host can support DDR mode at 1.2v
+
+In the following, can be vdd (flash core voltage) or vdd-io (I/O
voltage).
+- qcom,-always-on - specifies whether supply should be kept "on"
always.
+- qcom,-lpm-sup - specifies whether supply can be kept in low power
mode (lpm).
+- qcom,-voltage-level - specifies voltage levels for supply. Should be
+specified in pairs (min, max), units uV.
+- qcom,-current-level - specifies load levels for supply in lpm or
high power mode
+ (hpm). Should be specified in pairs (lpm, hpm), units uA.
+
+- gpios - specifies gpios assigned for sdhc slot.
+- qcom,gpio-names - a list of strings that map in order to the list of gpios
+
+Example:
+
+ aliases {
+ sdhc1 = &sdhc_1;
+ };
+
+ sdhc_1: qcom,sdhc@f9824900 {
+ compatible = "qcom,sdhci-msm";
+ reg = <0xf9824900 0x11c>, <0xf9824000 0x800>;
+ reg-names = "hc_mem", "core_mem";
+ interrupts = <0 123 0>, <0 138 0>;
+ interrupt-names = "hc_irq", "pwr_irq";
+
+ vdd-supply = <&pm8941_l21>;
+ vdd-io-supply = <&pm8941_l13>;
+ qcom,vdd-voltage-level = <295 295>;
+ qcom,vdd-current-level = <9000 80>;
+
+ qcom,vdd-io-always-on;
+ qcom,vdd-io-lpm-sup;
+ qcom,vdd-io-voltage-level = <180 295>;
+ qcom,vdd-io-current-level = <6 22000>;
+
+ bus-width = <4>;
+ non-removable;
+ qcom,bus-speed-mode = "HS200_1p8v", "DDR_1p8v";
+
+ gpios = <&msmgpio 40 0>, /* CLK */
+ <&msmgpio 39 0>, /* CMD */
+ <&msmgpio 38 0>, /* DATA0 */
+ <&msmgpio 37 0>, /* DATA1 */
+ <&msmgpio 36 0>, /* DATA2 */
+ <&msmgpio 35 0>; /* DATA3 */
+ qcom,gpio-names = "CLK", "CMD", "DAT0", "DAT1", "DAT2", "DAT3";
+ };
+
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 8a4c066..2b31471 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -322,6 +322,19 @@ config MMC_ATMELMCI
If unsure, say N.
+config MMC_SDHCI_MSM
+ tristate "Qualcomm SDHCI Contro
Re: [PATCH] mmc: sdhci-msm: Add support for MSM chipsets
On 07/31/2013 03:19 AM, Bjorn Andersson wrote:
On Tue, Jul 30, 2013 at 8:22 AM, Georgi Djakov wrote:
This platform driver adds the support of Secure Digital Host
Controller Interface compliant controller in MSM chipsets.
[snip]
+
+ sdhc_1: qcom,sdhc@f9824900 {
+ compatible = "qcom,sdhci-msm";
+ reg = <0xf9824900 0x11c>, <0xf9824000 0x800>;
+ reg-names = "hc_mem", "core_mem";
+ interrupts = <0 123 0>, <0 138 0>;
+ interrupt-names = "hc_irq", "pwr_irq";
+
+ vdd-supply = <&pm8941_l21>;
+ vdd-io-supply = <&pm8941_l13>;
+ qcom,vdd-voltage-level = <295 295>;
+ qcom,vdd-current-level = <9000 80>;
+
+ qcom,vdd-io-always-on;
+ qcom,vdd-io-lpm-sup;
+ qcom,vdd-io-voltage-level = <180 295>;
+ qcom,vdd-io-current-level = <6 22000>;
+
+ bus-width = <4>;
+ non-removable;
+ qcom,bus-speed-mode = "HS200_1p8v", "DDR_1p8v";
+
+ gpios = <&msmgpio 40 0>, /* CLK */
+ <&msmgpio 39 0>, /* CMD */
+ <&msmgpio 38 0>, /* DATA0 */
+ <&msmgpio 37 0>, /* DATA1 */
+ <&msmgpio 36 0>, /* DATA2 */
+ <&msmgpio 35 0>; /* DATA3 */
+ qcom,gpio-names = "CLK", "CMD", "DAT0", "DAT1", "DAT2", "DAT3";
I believe these gpio references (and in the rest of the patch) should
be replaced by pinctrl. As far as I can see it provides what you want
and gives you configurability and potential sleep states of those pins
nicely integrated.
Thanks! I'll make it use the pinctrl driver that is coming too.
BR,
Georgi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC v3] mmc: sdhci-msm: Add support for MSM chipsets
This platform driver adds the support of Secure Digital Host
Controller Interface compliant controller in MSM chipsets.
CC: Asutosh Das
CC: Venkat Gopalakrishnan
CC: Sahitya Tummala
CC: Subhash Jadavani
Signed-off-by: Georgi Djakov
---
Changes from v2:
- Added DT bindings for clocks
- Moved voltage regulators data to platform data
- Removed unneeded includes
- Removed obsolete and wrapper functions
- Removed error checking where unnecessary
- Removed redundant _clk suffix from clock names
- Just return instead of goto where possible
- Minor fixes
Changes from v1:
- GPIO references are replaced by pinctrl
- DT parsing is done mostly by mmc_of_parse()
- Use of_match_device() for DT matching
- A few minor changes
.../devicetree/bindings/mmc/sdhci-msm.txt | 71 ++
drivers/mmc/host/Kconfig | 13 +
drivers/mmc/host/Makefile |1 +
drivers/mmc/host/sdhci-msm.c | 687
4 files changed, 772 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mmc/sdhci-msm.txt
create mode 100644 drivers/mmc/host/sdhci-msm.c
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
new file mode 100644
index 000..ee112da
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
@@ -0,0 +1,71 @@
+* Qualcomm SDHCI controller (sdhci-msm)
+
+This file documents differences between the core properties in mmc.txt
+and the properties used by the sdhci-msm driver.
+
+Required properties:
+- compatible: should be "qcom,sdhci-msm"
+- reg: should contain SDHC, SD Core register map
+- reg-names: indicates various resources passed to driver (via reg proptery)
by name
+ "reg-names" examples are "hc_mem" and "core_mem"
+- interrupts: should contain SDHC interrupts
+- interrupt-names: indicates interrupts passed to driver (via interrupts
property) by name
+ "interrupt-names" examples are "hc_irq" and "pwr_irq"
+- -supply: phandle to the regulator device tree node
+ "supply-name" examples are "vdd" and "vdd-io"
+- pinctrl-names: Should contain only one value - "default".
+- pinctrl-0: Should specify pin control groups used for this controller.
+- clocks: phandles to clock instances of the device tree nodes
+- clock-names:
+ iface: Main peripheral bus clock (PCLK/HCLK - AHB Bus clock) (required)
+ core: SDC MMC clock (MCLK) (required)
+ bus: SDCC bus voter clock (optional)
+
+Optional properties:
+- qcom,bus-speed-mode - specifies supported bus speed modes by host
+ The supported bus speed modes are :
+ "HS200_1p8v" - indicates that host can support HS200 at 1.8v
+ "HS200_1p2v" - indicates that host can support HS200 at 1.2v
+ "DDR_1p8v" - indicates that host can support DDR mode at 1.8v
+ "DDR_1p2v" - indicates that host can support DDR mode at 1.2v
+
+In the following, can be vdd (flash core voltage) or vdd-io (I/O
voltage).
+- qcom,-always-on - specifies whether supply should be kept "on"
always.
+- qcom,-lpm-sup - specifies whether supply can be kept in low power
mode (lpm).
+- qcom,-voltage-level - specifies voltage levels for supply. Should be
+specified in pairs (min, max), units uV.
+- qcom,-current-level - specifies load levels for supply in lpm or
high power mode
+ (hpm). Should be specified in pairs (lpm, hpm), units uA.
+
+Example:
+
+ aliases {
+ sdhc1 = &sdhc_1;
+ };
+
+ sdhc_1: qcom,sdhc@f9824900 {
+ compatible = "qcom,sdhci-msm";
+ reg = <0xf9824900 0x11c>, <0xf9824000 0x800>;
+ reg-names = "hc_mem", "core_mem";
+ interrupts = <0 123 0>, <0 138 0>;
+ interrupt-names = "hc_irq", "pwr_irq";
+ bus-width = <4>;
+ non-removable;
+
+ vdd-supply = <&pm8941_l21>;
+ vdd-io-supply = <&pm8941_l13>;
+ qcom,vdd-voltage-level = <295 295>;
+ qcom,vdd-current-level = <9000 80>;
+ qcom,vdd-io-always-on;
+ qcom,vdd-io-lpm-sup;
+ qcom,vdd-io-voltage-level = <180 295>;
+ qcom,vdd-io-current-level = <6 22000>;
+ qcom,bus-speed-mode = "HS200_1p8v", "DDR_1p8v";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdc1_clk &sdc1_cmd &sdc1_data>;
+
+ clocks = <&iface>, <&core>, <&bus>;
+ clock-names = "iface", "core", "bus";
+
+ };
diff --git a/drive
[PATCH RFC v2] mmc: sdhci-msm: Add support for MSM chipsets
This platform driver adds the support of Secure Digital Host
Controller Interface compliant controller in MSM chipsets.
CC: Asutosh Das
CC: Venkat Gopalakrishnan
CC: Sahitya Tummala
CC: Subhash Jadavani
Signed-off-by: Georgi Djakov
---
Changes from v1:
- GPIO references are replaced by pinctrl
- DT parsing is done mostly by mmc_of_parse()
- Use of_match_device() for DT matching
- A few minor changes
.../devicetree/bindings/mmc/sdhci-msm.txt | 62 ++
drivers/mmc/host/Kconfig | 13 +
drivers/mmc/host/Makefile |1 +
drivers/mmc/host/sdhci-msm.c | 813
4 files changed, 889 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mmc/sdhci-msm.txt
create mode 100644 drivers/mmc/host/sdhci-msm.c
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
new file mode 100644
index 000..4008f1f
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
@@ -0,0 +1,62 @@
+* Qualcomm SDHCI controller (sdhci-msm)
+
+This file documents differences between the core properties in mmc.txt
+and the properties used by the sdhci-msm driver.
+
+Required properties:
+- compatible: should be "qcom,sdhci-msm"
+- reg: should contain SDHC, SD Core register map
+- reg-names: indicates various resources passed to driver (via reg proptery)
by name
+ "reg-names" examples are "hc_mem" and "core_mem"
+- interrupts: should contain SDHC interrupts
+- interrupt-names: indicates interrupts passed to driver (via interrupts
property) by name
+ "interrupt-names" examples are "hc_irq" and "pwr_irq"
+- -supply: phandle to the regulator device tree node
+ "supply-name" examples are "vdd" and "vdd-io"
+- pinctrl-names: Should contain only one value - "default".
+- pinctrl-0: Should specify pin control groups used for this controller.
+
+Optional properties:
+- qcom,bus-speed-mode - specifies supported bus speed modes by host
+ The supported bus speed modes are :
+ "HS200_1p8v" - indicates that host can support HS200 at 1.8v
+ "HS200_1p2v" - indicates that host can support HS200 at 1.2v
+ "DDR_1p8v" - indicates that host can support DDR mode at 1.8v
+ "DDR_1p2v" - indicates that host can support DDR mode at 1.2v
+
+In the following, can be vdd (flash core voltage) or vdd-io (I/O
voltage).
+- qcom,-always-on - specifies whether supply should be kept "on"
always.
+- qcom,-lpm-sup - specifies whether supply can be kept in low power
mode (lpm).
+- qcom,-voltage-level - specifies voltage levels for supply. Should be
+specified in pairs (min, max), units uV.
+- qcom,-current-level - specifies load levels for supply in lpm or
high power mode
+ (hpm). Should be specified in pairs (lpm, hpm), units uA.
+
+Example:
+
+ aliases {
+ sdhc1 = &sdhc_1;
+ };
+
+ sdhc_1: qcom,sdhc@f9824900 {
+ compatible = "qcom,sdhci-msm";
+ reg = <0xf9824900 0x11c>, <0xf9824000 0x800>;
+ reg-names = "hc_mem", "core_mem";
+ interrupts = <0 123 0>, <0 138 0>;
+ interrupt-names = "hc_irq", "pwr_irq";
+ bus-width = <4>;
+ non-removable;
+
+ vdd-supply = <&pm8941_l21>;
+ vdd-io-supply = <&pm8941_l13>;
+ qcom,vdd-voltage-level = <295 295>;
+ qcom,vdd-current-level = <9000 80>;
+ qcom,vdd-io-always-on;
+ qcom,vdd-io-lpm-sup;
+ qcom,vdd-io-voltage-level = <180 295>;
+ qcom,vdd-io-current-level = <6 22000>;
+ qcom,bus-speed-mode = "HS200_1p8v", "DDR_1p8v";
+
+ pinctrl-names = "default"
+ pinctrl-0 = <&sdc1_clk &sdc1_cmd &sdc1_data>;
+ };
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 8a4c066..2b31471 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -322,6 +322,19 @@ config MMC_ATMELMCI
If unsure, say N.
+config MMC_SDHCI_MSM
+ tristate "Qualcomm SDHCI Controller Support"
+ depends on ARCH_MSM
+ depends on MMC_SDHCI_PLTFM
+ help
+ This selects the Secure Digital Host Controller Interface (SDHCI)
+ support present in MSM SOCs from Qualcomm. The controller
+ supports SD/MMC/SDIO devices.
+
+ If you have a controller with this interface, say Y or M here.
+
+ If unsure, say N.
+
config MMC_MSM
tristate "Qualcomm SDCC Controller S
Re: [PATCH] mmc: sdhci-msm: Add set_uhs_signaling() implementation
On 07/20/2016 01:15 PM, Adrian Hunter wrote:
> On 19/07/16 17:52, Georgi Djakov wrote:
>> From: Ritesh Harjani
>>
>> To allow UHS mode to work properly, we need to implement a Qualcomm
>> specific set_uhs_signaling() callback function. This function differs
>> from the sdhci_set_uhs_signaling() in that we need check the clock
>> rate and enable UHS timing only if the frequency is above 100MHz.
>>
>> Signed-off-by: Ritesh Harjani
>> Signed-off-by: Georgi Djakov
>> ---
>>
>> This patch resolves the mmc_select_hs200 timeouts noticed after merging
>> commit a5c1f3e55c99 ("mmc: mmc: do not use CMD13 to get status after
>> speed mode switch")
>>
>> mmc0: mmc_select_hs200 failed, error -110
>> mmc0: error -110 whilst initialising MMC card
>> mmc0: Reset 0x1 never completed.
>> sdhci: === REGISTER DUMP (mmc0)===
>> sdhci: Sys addr: 0x | Version: 0x2e02
>> sdhci: Blk size: 0x4000 | Blk cnt: 0x
>> sdhci: Argument: 0x | Trn mode: 0x
>> sdhci: Present: 0x01f8 | Host ctl: 0x
>> sdhci: Power: 0x | Blk gap: 0x
>> sdhci: Wake-up: 0x | Clock: 0x0003
>> sdhci: Timeout: 0x | Int stat: 0x
>> sdhci: Int enab: 0x | Sig enab: 0x
>> sdhci: AC12 err: 0x | Slot int: 0x
>> sdhci: Caps: 0x322dc8b2 | Caps_1: 0x8007
>> sdhci: Cmd: 0x | Max curr: 0x
>> sdhci: Host ctl2: 0x
>> sdhci: ADMA Err: 0x | ADMA Ptr: 0x
>> sdhci: ===
>
> This information needs to be in the commit message. I think you should add
> a fixes tag too. e.g.
>
> Fixes: a5c1f3e55c99 ("mmc: mmc: do not use CMD13 to get status after...")
>
> Otherwise:
>
> Acked-by: Adrian Hunter
Thanks Adrian!
Ulf, do you want me to resend?
BR,
Georgi
[PATCH v6 2/3] clk: qcom: Add regmap mux-div clocks support
Add support for hardware that can switch both parent clocks and divider
at the same time. This avoids generating intermediate frequencies from
either the old parent clock and new divider or new parent clock and
old divider combinations.
Signed-off-by: Georgi Djakov
---
drivers/clk/qcom/Makefile | 1 +
drivers/clk/qcom/clk-regmap-mux-div.c | 254 ++
drivers/clk/qcom/clk-regmap-mux-div.h | 58
3 files changed, 313 insertions(+)
create mode 100644 drivers/clk/qcom/clk-regmap-mux-div.c
create mode 100644 drivers/clk/qcom/clk-regmap-mux-div.h
diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index 7d27f47f0c92..d3e142e577b0 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -9,6 +9,7 @@ clk-qcom-y += clk-rcg2.o
clk-qcom-y += clk-branch.o
clk-qcom-y += clk-regmap-divider.o
clk-qcom-y += clk-regmap-mux.o
+clk-qcom-y += clk-regmap-mux-div.o
clk-qcom-y += reset.o
clk-qcom-$(CONFIG_QCOM_GDSC) += gdsc.o
diff --git a/drivers/clk/qcom/clk-regmap-mux-div.c
b/drivers/clk/qcom/clk-regmap-mux-div.c
new file mode 100644
index ..ec87f496606a
--- /dev/null
+++ b/drivers/clk/qcom/clk-regmap-mux-div.c
@@ -0,0 +1,254 @@
+/*
+ * Copyright (c) 2015, Linaro Limited
+ * Copyright (c) 2014, The Linux Foundation. All rights reserved.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include "clk-regmap-mux-div.h"
+
+#define CMD_RCGR 0x0
+#define CMD_RCGR_UPDATEBIT(0)
+#define CMD_RCGR_DIRTY_CFG BIT(4)
+#define CMD_RCGR_ROOT_OFF BIT(31)
+#define CFG_RCGR 0x4
+
+#define to_clk_regmap_mux_div(_hw) \
+ container_of(to_clk_regmap(_hw), struct clk_regmap_mux_div, clkr)
+
+int __mux_div_set_src_div(struct clk_regmap_mux_div *md, u32 src, u32 div)
+{
+ int ret, count;
+ u32 val, mask;
+ const char *name = clk_hw_get_name(&md->clkr.hw);
+
+ val = (div << md->hid_shift) | (src << md->src_shift);
+ mask = ((BIT(md->hid_width) - 1) << md->hid_shift) |
+ ((BIT(md->src_width) - 1) << md->src_shift);
+
+ ret = regmap_update_bits(md->clkr.regmap, CFG_RCGR + md->reg_offset,
+mask, val);
+ if (ret)
+ return ret;
+
+ ret = regmap_update_bits(md->clkr.regmap, CMD_RCGR + md->reg_offset,
+CMD_RCGR_UPDATE, CMD_RCGR_UPDATE);
+ if (ret)
+ return ret;
+
+ /* Wait for update to take effect */
+ for (count = 500; count > 0; count--) {
+ ret = regmap_read(md->clkr.regmap, CMD_RCGR + md->reg_offset,
+ &val);
+ if (ret)
+ return ret;
+ if (!(val & CMD_RCGR_UPDATE))
+ return 0;
+ udelay(1);
+ }
+
+ pr_err("%s: RCG did not update its configuration", name);
+ return -EBUSY;
+}
+
+static void __mux_div_get_src_div(struct clk_regmap_mux_div *md, u32 *src,
+ u32 *div)
+{
+ u32 val, __div, __src;
+ const char *name = clk_hw_get_name(&md->clkr.hw);
+
+ regmap_read(md->clkr.regmap, CMD_RCGR + md->reg_offset, &val);
+
+ if (val & CMD_RCGR_DIRTY_CFG) {
+ pr_err("%s: RCG configuration is pending\n", name);
+ return;
+ }
+
+ regmap_read(md->clkr.regmap, CFG_RCGR + md->reg_offset, &val);
+ __src = (val >> md->src_shift);
+ __src &= BIT(md->src_width) - 1;
+ *src = __src;
+
+ __div = (val >> md->hid_shift);
+ __div &= BIT(md->hid_width) - 1;
+ *div = __div;
+}
+
+static int mux_div_enable(struct clk_hw *hw)
+{
+ struct clk_regmap_mux_div *md = to_clk_regmap_mux_div(hw);
+
+ return __mux_div_set_src_div(md, md->src, md->div);
+}
+
+static inline bool is_better_rate(unsigned long req, unsigned long best,
+ unsigned long new)
+{
+ return (req <= new && new < best) || (best < req && best < new);
+}
+
+static int mux_div_determine_rate(struct clk_hw *hw,
+ struct clk_rate_request *req)
+{
+ struct clk_regmap_mux_div *md = to_clk_regmap_mux_div(hw);
+ un
[PATCH v6 0/3] Add support for Qualcomm A53 CPU clock
This patchset adds support for the A53 CPU clock and allows scaling of the CPU frequency on msm8916 based platforms. Changes since v5 (https://lkml.org/lkml/2016/2/1/407) * Rebase to clk-next and update according to the recent API changes. Changes since v4 (https://lkml.org/lkml/2015/12/14/367) * Convert to builtin drivers as now __clk_lookup() is used Changes since v3 (https://lkml.org/lkml/2015/8/12/585) * Split driver into two parts - and separate A53 PLL and A53 clock controller drivers. * Drop the safe switch hook patch. Add a clock notifier in the clock provider to handle switching via safe mux and divider configuration. Changes since v2 (https://lkml.org/lkml/2015/7/24/526) * Drop gpll0_vote patch. * Switch to the new clk_hw_* APIs. * Rebase to the current clk-next. Changes since v1 (https://lkml.org/lkml/2015/6/12/193) * Drop SR2 PLL patch, as it is already applied. * Add gpll0_vote rate propagation patch. * Update/rebase patches to the current clk-next. Georgi Djakov (3): clk: qcom: Add A53 PLL support clk: qcom: Add regmap mux-div clocks support clk: qcom: Add A53 clock driver .../devicetree/bindings/clock/qcom,a53-pll.txt | 18 ++ .../devicetree/bindings/clock/qcom,a53cc.txt | 23 ++ drivers/clk/qcom/Kconfig | 17 ++ drivers/clk/qcom/Makefile | 3 + drivers/clk/qcom/a53-pll.c | 94 drivers/clk/qcom/a53cc.c | 155 + drivers/clk/qcom/clk-regmap-mux-div.c | 254 + drivers/clk/qcom/clk-regmap-mux-div.h | 58 + 8 files changed, 622 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/qcom,a53-pll.txt create mode 100644 Documentation/devicetree/bindings/clock/qcom,a53cc.txt create mode 100644 drivers/clk/qcom/a53-pll.c create mode 100644 drivers/clk/qcom/a53cc.c create mode 100644 drivers/clk/qcom/clk-regmap-mux-div.c create mode 100644 drivers/clk/qcom/clk-regmap-mux-div.h
[PATCH v6 1/3] clk: qcom: Add A53 PLL support
Add support for the PLL, which generates the higher range of CPU
frequencies on MSM8916 platforms.
Signed-off-by: Georgi Djakov
---
.../devicetree/bindings/clock/qcom,a53-pll.txt | 18 +
drivers/clk/qcom/Kconfig | 9 +++
drivers/clk/qcom/Makefile | 1 +
drivers/clk/qcom/a53-pll.c | 94 ++
4 files changed, 122 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/qcom,a53-pll.txt
create mode 100644 drivers/clk/qcom/a53-pll.c
diff --git a/Documentation/devicetree/bindings/clock/qcom,a53-pll.txt
b/Documentation/devicetree/bindings/clock/qcom,a53-pll.txt
new file mode 100644
index ..5cf0af1eecf9
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,a53-pll.txt
@@ -0,0 +1,18 @@
+A53 PLL Binding
+---
+The A53 PLL is the main CPU PLL used for frequencies above 1GHz.
+
+Required properties :
+- compatible : Shall contain only one of the following:
+
+ "qcom,a53-pll"
+
+- reg : shall contain base register location and length
+
+Example:
+
+ a53pll: a53pll@0b016000 {
+ compatible = "qcom,a53-pll";
+ reg = <0x0b016000 0x40>;
+ };
+
diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
index 0146d3c2547f..a889f0b14b54 100644
--- a/drivers/clk/qcom/Kconfig
+++ b/drivers/clk/qcom/Kconfig
@@ -150,3 +150,12 @@ config MSM_MMCC_8996
Support for the multimedia clock controller on msm8996 devices.
Say Y if you want to support multimedia devices such as display,
graphics, video encode/decode, camera, etc.
+
+config QCOM_A53PLL
+ bool "A53 PLL"
+ depends on COMMON_CLK_QCOM
+ help
+ Support for the A53 PLL on some Qualcomm devices. It provides
+ support for CPU frequencies above 1GHz.
+ Say Y if you want to support CPU frequency scaling on devices
+ such as MSM8916.
diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index 1fb1f5476cb0..7d27f47f0c92 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -29,3 +29,4 @@ obj-$(CONFIG_MSM_LCC_8960) += lcc-msm8960.o
obj-$(CONFIG_MSM_MMCC_8960) += mmcc-msm8960.o
obj-$(CONFIG_MSM_MMCC_8974) += mmcc-msm8974.o
obj-$(CONFIG_MSM_MMCC_8996) += mmcc-msm8996.o
+obj-$(CONFIG_QCOM_A53PLL) += a53-pll.o
diff --git a/drivers/clk/qcom/a53-pll.c b/drivers/clk/qcom/a53-pll.c
new file mode 100644
index ..43902080f34b
--- /dev/null
+++ b/drivers/clk/qcom/a53-pll.c
@@ -0,0 +1,94 @@
+/*
+ * Copyright (c) 2016, Linaro Limited
+ * Copyright (c) 2014, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+
+#include "clk-pll.h"
+#include "clk-regmap.h"
+
+static struct pll_freq_tbl a53pll_freq[] = {
+ { 99840, 52, 0x0, 0x1, 0 },
+ { 109440, 57, 0x0, 0x1, 0 },
+ { 115200, 62, 0x0, 0x1, 0 },
+ { 120960, 65, 0x0, 0x1, 0 },
+ { 140160, 73, 0x0, 0x1, 0 },
+};
+
+static const struct regmap_config a53pll_regmap_config = {
+ .reg_bits = 32,
+ .reg_stride = 4,
+ .val_bits = 32,
+ .max_register = 0x40,
+ .fast_io= true,
+ .val_format_endian = REGMAP_ENDIAN_LITTLE,
+};
+
+static const struct of_device_id qcom_a53pll_match_table[] = {
+ { .compatible = "qcom,a53-pll" },
+ { }
+};
+
+static int qcom_a53pll_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct device_node *node = dev->of_node;
+ struct clk_pll *pll;
+ struct resource *res;
+ void __iomem *base;
+ struct regmap *regmap;
+ struct clk_init_data init;
+
+ pll = devm_kzalloc(dev, sizeof(*pll), GFP_KERNEL);
+ if (!pll)
+ return -ENOMEM;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ base = devm_ioremap_resource(dev, res);
+ if (IS_ERR(base))
+ return PTR_ERR(base);
+
+ regmap = devm_regmap_init_mmio(dev, base, &a53pll_regmap_config);
+ if (IS_ERR(regmap))
+ return PTR_ERR(regmap);
+
+ pll->l_reg = 0x04,
+ pll->m_reg = 0x08,
+ pll->n_reg = 0x0c,
+ pll->config_reg = 0x14,
+ pll->mode_reg = 0x00,
+ pll->status_reg = 0x1c,
+ pll->status_bit = 16,
+
[PATCH v6 3/3] clk: qcom: Add A53 clock driver
Add a driver for the A53 Clock Controller. It is a hardware block that
implements a combined mux and half integer divider functionality. It can
choose between a fixed-rate clock or the dedicated A53 PLL. The source
and the divider can be set both at the same time.
This is required for enabling CPU frequency scaling on platforms like
MSM8916.
Signed-off-by: Georgi Djakov
---
.../devicetree/bindings/clock/qcom,a53cc.txt | 23 +++
drivers/clk/qcom/Kconfig | 8 ++
drivers/clk/qcom/Makefile | 1 +
drivers/clk/qcom/a53cc.c | 155 +
4 files changed, 187 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/qcom,a53cc.txt
create mode 100644 drivers/clk/qcom/a53cc.c
diff --git a/Documentation/devicetree/bindings/clock/qcom,a53cc.txt
b/Documentation/devicetree/bindings/clock/qcom,a53cc.txt
new file mode 100644
index ..3a1e8e6675ab
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,a53cc.txt
@@ -0,0 +1,23 @@
+Qualcomm A53 CPU Clock Controller Binding
+
+The A53 CPU Clock Controller is hardware, which provides a combined
+mux and divider functionality for the CPU clocks. It can choose between
+a fixed rate clock and the dedicated A53 PLL.
+
+Required properties :
+- compatible : shall contain:
+
+ "qcom,a53cc"
+
+- reg : shall contain base register location and length
+ of the APCS region
+- #clock-cells : shall contain 1
+
+Example:
+
+ apcs: syscon@b011000 {
+ compatible = "qcom,a53cc", "syscon";
+ reg = <0x0b011000 0x1000>;
+ #clock-cells = <1>;
+ };
+
diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
index a889f0b14b54..59dfcdc340e4 100644
--- a/drivers/clk/qcom/Kconfig
+++ b/drivers/clk/qcom/Kconfig
@@ -159,3 +159,11 @@ config QCOM_A53PLL
support for CPU frequencies above 1GHz.
Say Y if you want to support CPU frequency scaling on devices
such as MSM8916.
+
+config QCOM_A53CC
+ bool "A53 Clock Controller"
+ depends on COMMON_CLK_QCOM && QCOM_A53PLL
+ help
+ Support for the A53 clock controller on some Qualcomm devices.
+ Say Y if you want to support CPU frequency scaling on devices
+ such as MSM8916.
diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index d3e142e577b0..980a5d729aa4 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -30,4 +30,5 @@ obj-$(CONFIG_MSM_LCC_8960) += lcc-msm8960.o
obj-$(CONFIG_MSM_MMCC_8960) += mmcc-msm8960.o
obj-$(CONFIG_MSM_MMCC_8974) += mmcc-msm8974.o
obj-$(CONFIG_MSM_MMCC_8996) += mmcc-msm8996.o
+obj-$(CONFIG_QCOM_A53CC) += a53cc.o
obj-$(CONFIG_QCOM_A53PLL) += a53-pll.o
diff --git a/drivers/clk/qcom/a53cc.c b/drivers/clk/qcom/a53cc.c
new file mode 100644
index ..4d20db9da407
--- /dev/null
+++ b/drivers/clk/qcom/a53cc.c
@@ -0,0 +1,155 @@
+/*
+ * Copyright (c) 2016, Linaro Limited
+ * Copyright (c) 2014, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "clk-regmap.h"
+#include "clk-regmap-mux-div.h"
+
+enum {
+ P_GPLL0,
+ P_A53PLL,
+};
+
+static const struct parent_map gpll0_a53cc_map[] = {
+ { P_GPLL0, 4 },
+ { P_A53PLL, 5 },
+};
+
+static const char * const gpll0_a53cc[] = {
+ "gpll0_vote",
+ "a53pll",
+};
+
+static const struct regmap_config a53cc_regmap_config = {
+ .reg_bits = 32,
+ .reg_stride = 4,
+ .val_bits = 32,
+ .max_register = 0x1000,
+ .fast_io= true,
+ .val_format_endian = REGMAP_ENDIAN_LITTLE,
+};
+
+static const struct of_device_id qcom_a53cc_match_table[] = {
+ { .compatible = "qcom,a53cc" },
+ { }
+};
+
+/*
+ * We use the notifier function for switching to a temporary safe configuration
+ * (mux and divider), while the a53 pll is reconfigured.
+ */
+static int a53cc_notifier_cb(struct notifier_block *nb, unsigned long event,
+void *data)
+{
+ int ret = 0;
+ struct clk_regmap_mux_div *md = container_of(nb,
+struct clk_regmap_mux_div,
+
Re: [PATCH v3] mmc: sdhci-msm: Add pm_runtime and system PM support
On 09/08/2016 11:02 AM, Adrian Hunter wrote: On 01/09/16 17:23, Pramod Gurav wrote: Provides runtime PM callbacks to enable and disable clock resources when idle. Also support system PM callbacks to be called during system suspend and resume. Signed-off-by: Pramod Gurav Can we get some Tested/Reviewed/Acked-by from people using this driver? Hi Pramod, Thanks for the patch. Unfortunately, my db410c board fails to boot when i apply it. [1.778433] mmc0: new HS200 MMC card at address 0001 [1.783115] mmcblk0: mmc0:0001 DS2008 7.28 GiB [1.783337] mmcblk0boot0: mmc0:0001 DS2008 partition 1 4.00 MiB [1.787025] mmcblk0boot1: mmc0:0001 DS2008 partition 2 4.00 MiB [1.792893] mmcblk0rpmb: mmc0:0001 DS2008 partition 3 4.00 MiB [1.802603] mmcblk0: p1 p2 p3 p4 p5 p6 p7 p8 p9 p10 [2.693631] blk_update_request: I/O error, dev mmcblk0, sector 462880 [2.710381] blk_update_request: I/O error, dev mmcblk0, sector 462880 [2.710443] Buffer I/O error on dev mmcblk0p10, logical block 0, async page read [2.724827] blk_update_request: I/O error, dev mmcblk0, sector 462881 [2.724853] Buffer I/O error on dev mmcblk0p10, logical block 1, async page read ... More I/O errors are following and it is unable to mount the rootfs from the eMMC. When i retried booting, got also the following: [2.877149] mmcblk0: error -110 sending status command, retrying [2.879408] mmcblk0: error -110 sending status command, retrying [2.884436] mmcblk0: error -110 sending status command, aborting [2.896826] mmc0: cache flush error -110 BR, Georgi
Re: [PATCH v3 1/3] interconnect: Add generic on-chip interconnect API
Hi Amit,
On 11/02/2017 09:28 AM, Amit Kucheria wrote:
[..>> +Interconnect node is the software definition of the interconnect
hardware
>> +port. Each interconnect provider consists of multiple interconnect nodes,
>> +which are connected to other SoC components including other interconnect
>> +providers. The point on the diagram where the CPUs connects to the memory is
>> +called an interconnect node, which belongs to the Mem NoC interconnect
>> provider.
>> +
>> +Interconnect endpoits are the first or the last element of the path. Every
>
> s/endpoits/endpoints
>
Ok!
>> +endpoint is a node, but not every node is an endpoint.
>> +
>> +Interconnect path is everything between two endpoints including all the
>> nodes
>> +that have to be traversed to reach from a source to destination node. It may
>> +include multiple master-slave pairs across several interconnect providers.
>> +
>> +Interconnect consumers are the entities which make use of the data paths
>> exposed
>> +by the providers. The consumers send requests to providers requesting
>> various
>> +throughput, latency and priority. Usually the consumers are device drivers,
>> that
>> +send request based on their needs. An example for a consumer is a a video
>
> typo: is a video>
Ok!
[..]
>> +/**
>> + * interconnect_set() - set constraints on a path between two endpoints
>> + * @path: reference to the path returned by interconnect_get()
>> + * @creq: request from the consumer, containing its requirements
>> + *
>> + * This function is used by an interconnect consumer to express its own
>> needs
>> + * in term of bandwidth and QoS for a previously requested path between two
>> + * endpoints. The requests are aggregated and each node is updated
>> accordingly.
>> + *
>> + * Returns 0 on success, or an approproate error code otherwise.
>> + */
>> +int interconnect_set(struct interconnect_path *path,
>> +struct interconnect_creq *creq)
>> +{
>> + struct interconnect_node *next, *prev = NULL;
>> + size_t i;
>> + int ret = 0;
>> +
>> + for (i = 0; i < path->num_nodes; i++, prev = next) {
>> + next = path->reqs[i].node;
>> +
>> + /*
>> +* Both endpoints should be valid and master-slave pairs of
>
> Losing the 'and' improves readability.
>
Ok!
>> +* the same interconnect provider that will be configured.
>> +*/
>> + if (!next || !prev)
>> + continue;
>> + if (next->icp != prev->icp)
>> + continue;
>> +
>> + mutex_lock(&next->icp->lock);
>> +
>> + /* update the consumer request for this path */
>> + path->reqs[i].avg_bw = creq->avg_bw;
>> + path->reqs[i].peak_bw = creq->peak_bw;
>> +
>> + /* aggregate all requests */
>> + interconnect_aggregate_icn(next);
>> + interconnect_aggregate_icp(next->icp);
>> +
>> + if (next->icp->ops->set) {
>> + /* commit the aggregated constraints */
>> + ret = next->icp->ops->set(prev, next,
>> &next->icp->creq);
>> + }
>
> A comment here on how the contraints are propagated along the path
> would be good. At the moment, this seems to go to each provider along
> the path, take the provider lock and set the new constraints, then
> move on to the next provider. Is there any need to make the changes
> along the entire path "atomic"?
Yes, the above is correct. There is no such need at least for the
hardware i am currently playing with. We can add support for that later
if needed.
>
> I'm trying to understand what happens in the case where a new request
> comes along while the previous path is still be traversed.
It just gets aggregated and set and this seems to not be an issue as the
paths are valid. Now I am trying to keep it simple and if anything needs
serialization we can add some locking later.
>
>> + mutex_unlock(&next->icp->lock);
>> + if (ret)
>> + goto out;
>> + }
>> +
>> +out:
>> + return ret;
>> +}
>> +
>> +/**
>> + * interconnect_get() - return a handle for path between two endpoints
>
> This is not used currently by the msm8916 platform driver? Is this
> expected to be called by leaf device drivers or by higher layer bus
> drivers? I suspect a mix of the two, but an example would be nice.
This is called by a consumer driver to express its for example bandwidth
needs between various endpoints. Will add some examples.
[..]
>> +/**
>> + * struct icp - interconnect provider (controller) entity that might
>> + * provide multiple interconnect controls
>> + *
>> + * @icp_list: list of the registered interconnect providers
>> + * @nodes: internal list of the interconnect provider nodes
>> + * @ops: pointer to device specific struct icp_ops
>> + * @dev: the device this interconnect provider
Re: [PATCH v3 3/3] interconnect: Add Qualcomm msm8916 interconnect provider driver
Hi Amit,
On 11/02/2017 09:28 AM, Amit Kucheria wrote:
> On Fri, Sep 8, 2017 at 10:48 PM, Georgi Djakov
> wrote:
>> Add driver for the Qualcomm interconnect buses found in msm8916 based
>> platforms. This patch contains only a partial topology to make reviewing
>> easier.
>>
>> Signed-off-by: Georgi Djakov
>> ---
>> drivers/interconnect/Kconfig | 5 +
>> drivers/interconnect/Makefile| 1 +
>> drivers/interconnect/qcom/Kconfig| 11 +
>> drivers/interconnect/qcom/Makefile | 1 +
>> drivers/interconnect/qcom/interconnect_msm8916.c | 375
>> +++
>> include/linux/interconnect/qcom-msm8916.h| 92 ++
>> 6 files changed, 485 insertions(+)
>> create mode 100644 drivers/interconnect/qcom/Kconfig
>> create mode 100644 drivers/interconnect/qcom/Makefile
>> create mode 100644 drivers/interconnect/qcom/interconnect_msm8916.c
>> create mode 100644 include/linux/interconnect/qcom-msm8916.h
>>
>> diff --git a/drivers/interconnect/Kconfig b/drivers/interconnect/Kconfig
>> index 1e50e951cdc1..b123a76e2f9d 100644
>> --- a/drivers/interconnect/Kconfig
>> +++ b/drivers/interconnect/Kconfig
>> @@ -8,3 +8,8 @@ menuconfig INTERCONNECT
>>
>> If unsure, say no.
>>
>> +if INTERCONNECT
>> +
>> +source "drivers/interconnect/qcom/Kconfig"
>> +
>> +endif
>> diff --git a/drivers/interconnect/Makefile b/drivers/interconnect/Makefile
>> index d9da6a6c3560..62a01de24aeb 100644
>> --- a/drivers/interconnect/Makefile
>> +++ b/drivers/interconnect/Makefile
>> @@ -1 +1,2 @@
>> obj-$(CONFIG_INTERCONNECT) += interconnect.o
>> +obj-$(CONFIG_INTERCONNECT_QCOM)+= qcom/
>> diff --git a/drivers/interconnect/qcom/Kconfig
>> b/drivers/interconnect/qcom/Kconfig
>> new file mode 100644
>> index ..86465dc37bd4
>> --- /dev/null
>> +++ b/drivers/interconnect/qcom/Kconfig
>> @@ -0,0 +1,11 @@
>> +config INTERCONNECT_QCOM
>> + bool "Qualcomm Network-on-Chip interconnect drivers"
>> + depends on INTERCONNECT
>> + depends on ARCH_QCOM || COMPILE_TEST
>> + default y
>> +
>> +config INTERCONNECT_QCOM_MSM8916
>> + tristate "Qualcomm MSM8916 interconnect driver"
>> + depends on INTERCONNECT_QCOM
>> + help
>> + This is a driver for the Qualcomm Network-on-Chip on msm8916-based
>> platforms.
>> diff --git a/drivers/interconnect/qcom/Makefile
>> b/drivers/interconnect/qcom/Makefile
>> new file mode 100644
>> index ..0831080e1100
>> --- /dev/null
>> +++ b/drivers/interconnect/qcom/Makefile
>> @@ -0,0 +1 @@
>> +obj-$(CONFIG_INTERCONNECT_QCOM_MSM8916) += interconnect_msm8916.o
>> diff --git a/drivers/interconnect/qcom/interconnect_msm8916.c
>> b/drivers/interconnect/qcom/interconnect_msm8916.c
>> new file mode 100644
>> index ..9b001e100974
>> --- /dev/null
>> +++ b/drivers/interconnect/qcom/interconnect_msm8916.c
>> @@ -0,0 +1,375 @@
>> +/*
>> + * Copyright (C) 2017 Linaro Ltd
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 and
>> + * only version 2 as published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#define to_qcom_icp(_icp) \
>> + container_of(_icp, struct qcom_interconnect_provider, icp)
>> +#define to_qcom_node(_node) \
>> + container_of(_node, struct qcom_interconnect_node, node)
>> +
>> +enum qcom_bus_type {
>> + QCOM_BUS_TYPE_NOC = 0,
>> + QCOM_BUS_TYPE_MEM,
>> +};
>> +
>> +struct qcom_interconnect_provider {
>> + struct icp icp;
>> + void __iomem*base;
>> + struct clk *bus_clk;
>> + struct clk *bus_a_clk;
>> + u32 base_offset;
>> + u32 qos_offset;
&g
Re: [PATCH v9 0/7] Add support for Qualcomm A53 CPU clock
On 09/21/2017 07:49 PM, Georgi Djakov wrote: > This patchset adds support for the A53 CPU clock on MSM8916 platforms > and allows scaling of the CPU frequency on msm8916 based platforms. > > Changes since v8 (https://lkml.org/lkml/2017/6/23/476) > * Converted APCS mailbox driver to use regmap and to populate child > platform devices that will handle the rest of the functionality > provided by APCS block. > * Picked Rob's Ack for the PLL binding. > * Changed the APCS binding and put it into a separate patch. > * Addressed review comments. > * Minor changes. Hi Stephen and Bjorn. A gentle ping on this..
Re: [PATCH v9 3/7] mailbox: qcom: Move the apcs struct into a separate header
Hi Bjorn, Thanks for reviewing! On 10/26/2017 07:28 AM, Bjorn Andersson wrote: > On Thu 21 Sep 09:49 PDT 2017, Georgi Djakov wrote: > >> Move the structure shared by the APCS IPC device and its subdevices >> into a separate header file. >> > > As you're creating the apcs regmap with devm_regmap_init_mmio() you can > just call dev_get_regmap(dev->parent) in your child to get the handle. Ok, thanks! > > But I would prefer that you just add the clock code to the existing > driver. This will require an ack from Stephen, and i got the impression that he prefers a separate clk driver [1]. Stephen, are you ok with registering the clocks from the apcs mailbox driver? [1] https://lkml.org/lkml/2017/6/26/750
Re: [PATCH] soc: qcom: smd-rpm: Correct the active vs sleep state flagging
On 10/13/2015 11:57 PM, Bjorn Andersson wrote: > The BIT() was incorrectly inherited from family A and should not be used > on family B where the state is denoted by an enum. > > Reported-by: Georgi Djakov > Signed-off-by: Bjorn Andersson Tested-by: Georgi Djakov > --- > drivers/soc/qcom/smd-rpm.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/soc/qcom/smd-rpm.c b/drivers/soc/qcom/smd-rpm.c > index b5feb58dbd9f..2969321e1b09 100644 > --- a/drivers/soc/qcom/smd-rpm.c > +++ b/drivers/soc/qcom/smd-rpm.c > @@ -126,7 +126,7 @@ int qcom_rpm_smd_write(struct qcom_smd_rpm *rpm, > pkt->hdr.length = cpu_to_le32(sizeof(struct qcom_rpm_request) + count); > > pkt->req.msg_id = cpu_to_le32(msg_id++); > - pkt->req.flags = cpu_to_le32(BIT(state)); > + pkt->req.flags = cpu_to_le32(state); > pkt->req.type = cpu_to_le32(type); > pkt->req.id = cpu_to_le32(id); > pkt->req.data_len = cpu_to_le32(count); > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/2] Add initial support for RPM clocks
On 08/03/2015 07:48 PM, Georgi Djakov wrote: > This patchset adds initial support for the clocks controlled by > the RPM (Resource Power Manager) processor on Qualcomm platforms. > It depends on Bjorn's Qualcomm SMD & RPM patches, that are now in > linux-next: https://lkml.org/lkml/2015/7/27/1125 > > The first patch implements the RPM clock operations, which are > using a shared memory for sending requests to the RPM processor. > The second patch adds the support of RPM clocks on the MSM8916 > platform. > > Changes since v1 (https://lkml.org/lkml/2015/7/9/257): > * Changed the driver name to clk-smd-rpm, also build it only > when it is needed - suggested by Srini and Bjorn. > * More detailed binding example. > * Minor changes. > > Georgi Djakov (2): > clk: qcom: Add support for RPM Clocks > clk: qcom: Add MSM8916 RPM clock driver > > .../devicetree/bindings/clock/qcom,rpmcc.txt | 35 > drivers/clk/qcom/Kconfig |4 + > drivers/clk/qcom/Makefile |2 + > drivers/clk/qcom/clk-smd-rpm.c | 165 > drivers/clk/qcom/clk-smd-rpm.h | 139 ++ > drivers/clk/qcom/gcc-msm8916.c | 13 -- > drivers/clk/qcom/rpmcc-msm8916.c | 196 > > include/dt-bindings/clock/qcom,rpmcc-msm8916.h | 44 + > 8 files changed, 585 insertions(+), 13 deletions(-) > create mode 100644 Documentation/devicetree/bindings/clock/qcom,rpmcc.txt > create mode 100644 drivers/clk/qcom/clk-smd-rpm.c > create mode 100644 drivers/clk/qcom/clk-smd-rpm.h > create mode 100644 drivers/clk/qcom/rpmcc-msm8916.c > create mode 100644 include/dt-bindings/clock/qcom,rpmcc-msm8916.h > Hi Stephen, any comments on this? Thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] clk: qcom: Add support for RPM Clocks
Hi Stephen,
On 09/02/2015 11:31 PM, Stephen Boyd wrote:
> On 08/03, Georgi Djakov wrote:
>> diff --git a/drivers/clk/qcom/clk-smd-rpm.c b/drivers/clk/qcom/clk-smd-rpm.c
>> new file mode 100644
>> index ..e564673ec3a5
>> --- /dev/null
>> +++ b/drivers/clk/qcom/clk-smd-rpm.c
[..]
>> +static int clk_smd_rpm_set_rate(struct clk_hw *hw, unsigned long rate,
>> +unsigned long parent_rate)
>> +{
>> +struct clk_smd_rpm *r = to_clk_smd_rpm(hw);
>> +int ret = 0;
>> +
>> +if (r->enabled) {
>> +u32 value;
>> +struct clk_smd_rpm *peer = r->peer;
>> +
>> +/* Take peer clock's rate into account only if it's enabled. */
>> +if (peer->enabled)
>
> This peer stuff almost doesn't even matter because we're only
> sending active set requests. Why can't this code be updated to
> send both active and sleep set requests? The sleep set stuff
> won't be cached, etc., but I don't see a problem in doing both.
> Otherwise we should drop all the peer stuff until we introduce
> active only clocks.
Initially I tried sending both active and sleep sets, but as they are
not cached like in downstream (yet) i got hangs during boot. Disabling
caching in downstream kernel also caused the same hangs, so i left
this out for now. Will try debugging it further.
Will fix the rest according to your comments. Thank you!
BR,
Georgi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 0/8] Add initial support for RPM clocks
This patchset adds initial support for the clocks controlled by the RPM (Resource Power Manager) processor on Qualcomm platforms. The RPM is a dedicated hardware engine for managing the shared SoC resources in order to keep the lowest power profile. It communicates with other hardware subsystems via shared memory and accepts clock requests, aggregates the requests and turns the clocks on/off or scales them on demand. Until now the RPM clock controller was not supported and a hard- coded fixed-rate clocks were registered in the drivers. Now we try to do a smooth transition by moving the xo oscillator to DT (where it actually belongs) and handle both cases when RPMCC is enabled or disabled (also to avoid breakage on current boards). Changes since v2 (https://lkml.org/lkml/2015/8/3/513) * Addressed various comments from Stephen. Thanks! * Added sleep sets support. * Added a mutex in the RPM driver. * Support both scenarios - RPMCC enabled or disabled. * Make RPMCC more generic in order to support other SMD RPM based platforms. Changes since v1 (https://lkml.org/lkml/2015/7/9/257): * Changed the driver name to clk-smd-rpm, also build it only when it is needed - suggested by Srini and Bjorn. * More detailed binding example. * Minor changes. Georgi Djakov (8): arm64: dts: qcom: 8x16: Add fixed rate on-board oscillator clk: qcom: msm8916: Set the parent of xo to xo_board clk: qcom: msm8916: Ignore sleep_clk_src registration errors arm64: dts: qcom: 8x16: Add fixed rate sleep clock oscillator clk: qcom: Add support for RPM Clocks clk: qcom: Add RPM clock controller driver clk: qcom: msm8916: Use RPMCC if it is enabled clk: qcom: msm8916: Remove hard-coded sleep_clk_src .../devicetree/bindings/clock/qcom,rpmcc.txt | 35 +++ arch/arm64/boot/dts/qcom/msm8916.dtsi | 16 ++ drivers/clk/qcom/Kconfig | 11 + drivers/clk/qcom/Makefile |2 + drivers/clk/qcom/clk-smd-rpm.c | 260 drivers/clk/qcom/clk-smd-rpm.h | 142 +++ drivers/clk/qcom/gcc-msm8916.c | 15 +- drivers/clk/qcom/rpmcc.c | 198 +++ include/dt-bindings/clock/qcom,rpmcc-msm8916.h | 44 9 files changed, 714 insertions(+), 9 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/qcom,rpmcc.txt create mode 100644 drivers/clk/qcom/clk-smd-rpm.c create mode 100644 drivers/clk/qcom/clk-smd-rpm.h create mode 100644 drivers/clk/qcom/rpmcc.c create mode 100644 include/dt-bindings/clock/qcom,rpmcc-msm8916.h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 7/8] clk: qcom: msm8916: Use RPMCC if it is enabled
The RPM clock controller driver takes care of registering the
xo clock. Do not register it in this driver if RPM is enabled.
Signed-off-by: Georgi Djakov
---
drivers/clk/qcom/gcc-msm8916.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/clk/qcom/gcc-msm8916.c b/drivers/clk/qcom/gcc-msm8916.c
index 4bb7d8415ba7..3e1062fed230 100644
--- a/drivers/clk/qcom/gcc-msm8916.c
+++ b/drivers/clk/qcom/gcc-msm8916.c
@@ -3359,13 +3359,15 @@ static int gcc_msm8916_probe(struct platform_device
*pdev)
struct clk *clk;
struct device *dev = &pdev->dev;
- /* Temporary until RPM clocks supported */
- clk = clk_register_fixed_factor(dev, "xo", "xo_board", 0, 1, 1);
- if (IS_ERR(clk))
- return PTR_ERR(clk);
-
- clk_register_fixed_rate(dev, "sleep_clk_src", NULL,
- CLK_IS_ROOT, 32768);
+ if (!IS_ENABLED(CONFIG_QCOM_RPMCC)) {
+ /* RPM clocks are not enabled */
+ clk = clk_register_fixed_factor(dev, "xo", "xo_board", 0, 1, 1);
+ if (IS_ERR(clk))
+ return PTR_ERR(clk);
+
+ clk_register_fixed_rate(dev, "sleep_clk_src", NULL,
+ CLK_IS_ROOT, 32768);
+ }
return qcom_cc_probe(pdev, &gcc_msm8916_desc);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 8/8] clk: qcom: msm8916: Remove hard-coded sleep_clk_src
The sleep_clk_src has been moved to DT, so we do not need to register it in the GCC driver anymore. Signed-off-by: Georgi Djakov --- drivers/clk/qcom/gcc-msm8916.c |3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/clk/qcom/gcc-msm8916.c b/drivers/clk/qcom/gcc-msm8916.c index 3e1062fed230..6b687790fe24 100644 --- a/drivers/clk/qcom/gcc-msm8916.c +++ b/drivers/clk/qcom/gcc-msm8916.c @@ -3364,9 +3364,6 @@ static int gcc_msm8916_probe(struct platform_device *pdev) clk = clk_register_fixed_factor(dev, "xo", "xo_board", 0, 1, 1); if (IS_ERR(clk)) return PTR_ERR(clk); - - clk_register_fixed_rate(dev, "sleep_clk_src", NULL, - CLK_IS_ROOT, 32768); } return qcom_cc_probe(pdev, &gcc_msm8916_desc); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 2/8] clk: qcom: msm8916: Set the parent of xo to xo_board
Remove the hard-coded clock rate from the driver and set the XO parent to the on-board XO oscillator that is defined in the DT. Signed-off-by: Georgi Djakov --- drivers/clk/qcom/gcc-msm8916.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/clk/qcom/gcc-msm8916.c b/drivers/clk/qcom/gcc-msm8916.c index d0a0313d6bef..3c0668b12142 100644 --- a/drivers/clk/qcom/gcc-msm8916.c +++ b/drivers/clk/qcom/gcc-msm8916.c @@ -3360,7 +3360,7 @@ static int gcc_msm8916_probe(struct platform_device *pdev) struct device *dev = &pdev->dev; /* Temporary until RPM clocks supported */ - clk = clk_register_fixed_rate(dev, "xo", NULL, CLK_IS_ROOT, 1920); + clk = clk_register_fixed_factor(dev, "xo", "xo_board", 0, 1, 1); if (IS_ERR(clk)) return PTR_ERR(clk); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 6/8] clk: qcom: Add RPM clock controller driver
Add support for clocks that are controlled by the RPM processor
on Qualcomm msm8916 based platforms.
Signed-off-by: Georgi Djakov
---
.../devicetree/bindings/clock/qcom,rpmcc.txt | 35
drivers/clk/qcom/Kconfig |8 +
drivers/clk/qcom/Makefile |1 +
drivers/clk/qcom/rpmcc.c | 198
include/dt-bindings/clock/qcom,rpmcc-msm8916.h | 44 +
5 files changed, 286 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/qcom,rpmcc.txt
create mode 100644 drivers/clk/qcom/rpmcc.c
create mode 100644 include/dt-bindings/clock/qcom,rpmcc-msm8916.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt
b/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt
new file mode 100644
index ..bd0fd0cd50dc
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt
@@ -0,0 +1,35 @@
+Qualcomm RPM Clock Controller Binding
+
+The RPM is a dedicated hardware engine for managing the shared
+SoC resources in order to keep the lowest power profile. It
+communicates with other hardware subsystems via shared memory
+and accepts clock requests, aggregates the requests and turns
+the clocks on/off or scales them on demand.
+
+Required properties :
+- compatible : shall contain only one of the following:
+
+ "qcom,rpmcc-msm8916"
+
+- #clock-cells : shall contain 1
+
+Example:
+ smd {
+ compatible = "qcom,smd";
+
+ rpm {
+ interrupts = <0 168 1>;
+ qcom,ipc = <&apcs 8 0>;
+ qcom,smd-edge = <15>;
+
+ rpm_requests {
+ compatible = "qcom,rpm-msm8916";
+ qcom,smd-channels = "rpm_requests";
+
+ rpmcc: qcom,rpmcc {
+ compatible = "qcom,rpmcc-msm8916";
+ #clock-cells = <1>;
+ };
+ };
+ };
+ };
diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
index f06a331e9a24..29aaebcdeffa 100644
--- a/drivers/clk/qcom/Kconfig
+++ b/drivers/clk/qcom/Kconfig
@@ -12,6 +12,14 @@ config COMMON_CLK_QCOM
select REGMAP_MMIO
select RESET_CONTROLLER
+config QCOM_RPMCC
+ tristate "Qualcomm RPM Clock Controller"
+ depends on QCOM_SMD_RPM && COMMON_CLK_QCOM
+ select QCOM_CLK_SMD_RPM
+ help
+ Support for the clocks exposed by the Resource Power Manager
+ processor on devices like apq8016, apq8084 and msm8974.
+
config APQ_GCC_8084
tristate "APQ8084 Global Clock Controller"
select QCOM_GDSC
diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index b0bc0d3d585f..e58a567ddb42 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -11,6 +11,7 @@ clk-qcom-y += clk-regmap-mux.o
clk-qcom-y += reset.o
clk-qcom-$(CONFIG_QCOM_CLK_SMD_RPM) += clk-smd-rpm.o
clk-qcom-$(CONFIG_QCOM_GDSC) += gdsc.o
+clk-qcom-$(CONFIG_QCOM_RPMCC) += rpmcc.o
obj-$(CONFIG_APQ_GCC_8084) += gcc-apq8084.o
obj-$(CONFIG_APQ_MMCC_8084) += mmcc-apq8084.o
diff --git a/drivers/clk/qcom/rpmcc.c b/drivers/clk/qcom/rpmcc.c
new file mode 100644
index ..88283e2c95f7
--- /dev/null
+++ b/drivers/clk/qcom/rpmcc.c
@@ -0,0 +1,198 @@
+/*
+ * Copyright (c) 2015, Linaro Limited
+ * Copyright (c) 2014, The Linux Foundation. All rights reserved.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "clk-smd-rpm.h"
+#include
+
+#define CXO_ID 0x0
+#define QDSS_ID0x1
+#define BUS_SCALING0x2
+
+#define PCNOC_ID 0x0
+#define SNOC_ID0x1
+#define BIMC_ID0x0
+
+#define BB_CLK1_ID 0x1
+#define BB_CLK2_ID 0x2
+#define RF_CLK1_ID 0x4
+#define RF_CLK2_ID 0x5
+
+struct rpm_cc {
+ struct qcom_rpm *rpm;
+ struct clk_onecell_data data;
+ struct clk *clks[];
+};
+
+/* SMD clocks */
+DEFINE_CLK_SMD_RPM(pcnoc_clk, pcnoc_a_clk, QCOM_SMD_RPM_BUS_CLK, PCNOC_ID,
NULL);
+DEFINE_CLK_SMD_RPM(snoc_c
[PATCH v3 3/8] clk: qcom: msm8916: Ignore sleep_clk_src registration errors
We are moving the sleep clock to the DT. While all patches are merged, we will ignore sleep_clk_src registration errors. By ignoring this error, the msm8916 boards will continue booting during this transition period, otherwise the clock controller initialization will fail. Signed-off-by: Georgi Djakov --- drivers/clk/qcom/gcc-msm8916.c |6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/clk/qcom/gcc-msm8916.c b/drivers/clk/qcom/gcc-msm8916.c index 3c0668b12142..4bb7d8415ba7 100644 --- a/drivers/clk/qcom/gcc-msm8916.c +++ b/drivers/clk/qcom/gcc-msm8916.c @@ -3364,10 +3364,8 @@ static int gcc_msm8916_probe(struct platform_device *pdev) if (IS_ERR(clk)) return PTR_ERR(clk); - clk = clk_register_fixed_rate(dev, "sleep_clk_src", NULL, - CLK_IS_ROOT, 32768); - if (IS_ERR(clk)) - return PTR_ERR(clk); + clk_register_fixed_rate(dev, "sleep_clk_src", NULL, + CLK_IS_ROOT, 32768); return qcom_cc_probe(pdev, &gcc_msm8916_desc); } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 4/8] arm64: dts: qcom: 8x16: Add fixed rate sleep clock oscillator
The sleep clock oscillator should be in the DT instead of being
hard-coded into the clock drivers.
Signed-off-by: Georgi Djakov
---
arch/arm64/boot/dts/qcom/msm8916.dtsi |7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi
b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index 355a2acea796..fda4d5cd574a 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -87,6 +87,13 @@
clock-frequency = <1920>;
clock-output-names = "xo_board";
};
+
+ sleep_clk: sleep_clk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <32768>;
+ clock-output-names = "sleep_clk_src";
+ };
};
soc: soc {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 5/8] clk: qcom: Add support for RPM Clocks
This adds initial support for clocks controlled by the Resource
Power Manager (RPM) processor found on some Qualcomm SoCs.
The RPM is a dedicated hardware engine for managing the shared
SoC resources in order to keep the lowest power profile. It
communicates with other hardware subsystems via shared memory
and accepts clock requests, aggregates the requests and turns
the clocks on/off or scales them on demand.
This driver is based on the codeaurora.org driver:
https://www.codeaurora.org/cgit/quic/la/kernel/msm-3.10/tree/drivers/clk/qcom/clock-rpm.c
Signed-off-by: Georgi Djakov
---
drivers/clk/qcom/Kconfig |3 +
drivers/clk/qcom/Makefile |1 +
drivers/clk/qcom/clk-smd-rpm.c | 260
drivers/clk/qcom/clk-smd-rpm.h | 142 ++
4 files changed, 406 insertions(+)
create mode 100644 drivers/clk/qcom/clk-smd-rpm.c
create mode 100644 drivers/clk/qcom/clk-smd-rpm.h
diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
index ee4c83aab4f4..f06a331e9a24 100644
--- a/drivers/clk/qcom/Kconfig
+++ b/drivers/clk/qcom/Kconfig
@@ -1,3 +1,6 @@
+config QCOM_CLK_SMD_RPM
+ bool
+
config QCOM_GDSC
bool
select PM_GENERIC_DOMAINS if PM
diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index fe6252349e55..b0bc0d3d585f 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -9,6 +9,7 @@ clk-qcom-y += clk-branch.o
clk-qcom-y += clk-regmap-divider.o
clk-qcom-y += clk-regmap-mux.o
clk-qcom-y += reset.o
+clk-qcom-$(CONFIG_QCOM_CLK_SMD_RPM) += clk-smd-rpm.o
clk-qcom-$(CONFIG_QCOM_GDSC) += gdsc.o
obj-$(CONFIG_APQ_GCC_8084) += gcc-apq8084.o
diff --git a/drivers/clk/qcom/clk-smd-rpm.c b/drivers/clk/qcom/clk-smd-rpm.c
new file mode 100644
index ..aa634bdf0aae
--- /dev/null
+++ b/drivers/clk/qcom/clk-smd-rpm.c
@@ -0,0 +1,260 @@
+/*
+ * Copyright (c) 2015, Linaro Limited
+ * Copyright (c) 2014, The Linux Foundation. All rights reserved.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "clk-smd-rpm.h"
+
+#define to_clk_smd_rpm(_hw) container_of(_hw, struct clk_smd_rpm, hw)
+
+static DEFINE_MUTEX(rpm_clk_lock);
+
+static int clk_smd_rpm_set_rate_active(struct clk_smd_rpm *r,
+ unsigned long value)
+{
+ struct clk_smd_rpm_req req = {
+ .key = r->rpm_key,
+ .nbytes = sizeof(u32),
+ .value = DIV_ROUND_UP(value, 1000), /* RPM expects kHz */
+ };
+
+ return qcom_rpm_smd_write(r->rpm, QCOM_SMD_RPM_ACTIVE_STATE,
+ r->rpm_res_type, r->rpm_clk_id, &req,
+ sizeof(req));
+}
+
+static int clk_smd_rpm_set_rate_sleep(struct clk_smd_rpm *r,
+ unsigned long value)
+{
+ struct clk_smd_rpm_req req = {
+ .key = r->rpm_key,
+ .nbytes = sizeof(u32),
+ .value = DIV_ROUND_UP(value, 1000), /* RPM expects kHz */
+ };
+
+ return qcom_rpm_smd_write(r->rpm, QCOM_SMD_RPM_SLEEP_STATE,
+ r->rpm_res_type, r->rpm_clk_id, &req,
+ sizeof(req));
+}
+
+static void to_active_sleep(struct clk_smd_rpm *r, unsigned long rate,
+ unsigned long *active, unsigned long *sleep)
+{
+ *active = rate;
+
+ /*
+* Active-only clocks don't care what the rate is during sleep. So,
+* they vote for zero.
+*/
+ if (r->active_only)
+ *sleep = 0;
+ else
+ *sleep = *active;
+}
+
+static int clk_smd_rpm_prepare(struct clk_hw *hw)
+{
+ struct clk_smd_rpm *r = to_clk_smd_rpm(hw);
+ struct clk_smd_rpm *peer = r->peer;
+ unsigned long this_rate = 0, this_sleep_rate = 0;
+ unsigned long peer_rate = 0, peer_sleep_rate = 0;
+ unsigned long active_rate, sleep_rate;
+ int ret = 0;
+
+ mutex_lock(&rpm_clk_lock);
+
+ /* Don't send requests to the RPM if the rate has not been set. */
+ if (!r->rate)
+ goto out;
+
+ to_active_sleep(r, r->rate, &this_rate, &this_sleep_rate);
+
+ /* Take peer clock's rate into account only if it's enabled. */
+ if (peer->enabled)
+ to_active_sleep(peer, peer->rate,
+ &peer_rat
[PATCH v3 1/8] arm64: dts: qcom: 8x16: Add fixed rate on-board oscillator
Add the on-board XO oscillator. This patch prepares for adding support
for RPM controlled clocks. In order to do smooth transition and support
both cases (RPM clock driver is enabled or nor), we first move the XO to
the DT and change the GCC fixed-rate root clock to a dummy pass-through
clock. Then if the RPM driver is enabled, we set the parent of the XO
clock in the RPM clock driver to xo_board.
The advantage of doing so is that the rate of the XO clock is not hard-
coded in the GCC driver anymore, but comes from the board layout, so
that is why it should be in DT anyway.
Signed-off-by: Georgi Djakov
---
arch/arm64/boot/dts/qcom/msm8916.dtsi |9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi
b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index 8748fcca70f4..355a2acea796 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -80,6 +80,15 @@
;
};
+ clocks {
+ xo_board: xo_board {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <1920>;
+ clock-output-names = "xo_board";
+ };
+ };
+
soc: soc {
#address-cells = <1>;
#size-cells = <1>;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] arm64: dts: qcom: Enable eMMC on apq8016-sbc board
Enable the eMMC on the APQ8016 SBC board (also known as DragonBoard 410c),
so that we can use its internal storage.
Signed-off-by: Georgi Djakov
---
arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi |4
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
index 3fc3be447edd..8cea426e58af 100644
--- a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
+++ b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
@@ -86,3 +86,7 @@
};
};
};
+
+&sdhc_1 {
+ status = "okay";
+};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re:[PATCH v7 2/8] dt-bindings: Introduce interconnect provider bindings
Hi Rob, On 08/03/2018 12:02 AM, Rob Herring wrote: > On Tue, Jul 31, 2018 at 10:13 AM Georgi Djakov > wrote: >> >> This binding is intended to represent the interconnect hardware present >> in some of the modern SoCs. Currently it consists only of a binding for >> the interconnect hardware devices (provider). > > If you want the bindings reviewed, then you need to send them to the > DT list. CC'ing me is pointless, I get CC'ed too many things to read. Ops, ok! > The consumer and producer binding should be a single patch. One is not > useful without the other. The reason for splitting them is that they can be reviewed separately. Also we can rely on platform data instead of using DT and the consumer binding. However will do as you suggest. > There is also a patch series from Maxime Ripard that's addressing the > same general area. See "dt-bindings: Add a dma-parent property". We > don't need multiple ways to address describing the device to memory > paths, so you all had better work out a common solution. Looks like this fits exactly into the interconnect API concept. I see MBUS as interconnect provider and display/camera as consumers, that report their bandwidth needs. I am also planning to add support for priority. Thanks, Georgi
Re: [PATCH v7 2/8] dt-bindings: Introduce interconnect provider bindings
Hi Maxime, On 08/27/2018 06:08 PM, Maxime Ripard wrote: > Hi! > > On Fri, Aug 24, 2018 at 05:51:37PM +0300, Georgi Djakov wrote: >> Hi Maxime, >> >> On 08/20/2018 06:32 PM, Maxime Ripard wrote: >>> Hi Georgi, >>> >>> On Tue, Aug 07, 2018 at 05:54:38PM +0300, Georgi Djakov wrote: >>>>> There is also a patch series from Maxime Ripard that's addressing the >>>>> same general area. See "dt-bindings: Add a dma-parent property". We >>>>> don't need multiple ways to address describing the device to memory >>>>> paths, so you all had better work out a common solution. >>>> >>>> Looks like this fits exactly into the interconnect API concept. I see >>>> MBUS as interconnect provider and display/camera as consumers, that >>>> report their bandwidth needs. I am also planning to add support for >>>> priority. >>> >>> Thanks for working on this. After looking at your serie, the one thing >>> I'm a bit uncertain about (and the most important one to us) is how we >>> would be able to tell through which interconnect the DMA are done. >>> >>> This is important to us since our topology is actually quite simple as >>> you've seen, but the RAM is not mapped on that bus and on the CPU's, >>> so we need to apply an offset to each buffer being DMA'd. >> >> Ok, i see - your problem is not about bandwidth scaling but about using >> different memory ranges by the driver to access the same location. > > Well, it turns out that the problem we are bitten by at the moment is > the memory range one, but the controller it goes through also provides > bandwidth scaling, priorities and so on, so it's not too far off. Thanks for the clarification. Alright, so this will fit nicely into the model as a provider. I agree that we should try to use the same binding to describe a path from a master to memory in DT. >> So this is not really the same and your problem is different. Also >> the interconnect bindings are describing a path and >> endpoints. However i am open to any ideas. > > It's describing a path and endpoints, but it can describe multiple of > them for the same device, right? If so, we'd need to provide > additional information to distinguish which path is used for DMA. Sure, multiple paths are supported. BR, Georgi
Re: [PATCH v7 2/8] dt-bindings: Introduce interconnect provider bindings
Hi Rob and Maxime, On 08/27/2018 06:11 PM, Maxime Ripard wrote: > On Fri, Aug 24, 2018 at 10:35:23AM -0500, Rob Herring wrote: >> On Fri, Aug 24, 2018 at 9:51 AM Georgi Djakov >> wrote: >>> >>> Hi Maxime, >>> >>> On 08/20/2018 06:32 PM, Maxime Ripard wrote: >>>> Hi Georgi, >>>> >>>> On Tue, Aug 07, 2018 at 05:54:38PM +0300, Georgi Djakov wrote: >>>>>> There is also a patch series from Maxime Ripard that's addressing the >>>>>> same general area. See "dt-bindings: Add a dma-parent property". We >>>>>> don't need multiple ways to address describing the device to memory >>>>>> paths, so you all had better work out a common solution. >>>>> >>>>> Looks like this fits exactly into the interconnect API concept. I see >>>>> MBUS as interconnect provider and display/camera as consumers, that >>>>> report their bandwidth needs. I am also planning to add support for >>>>> priority. >>>> >>>> Thanks for working on this. After looking at your serie, the one thing >>>> I'm a bit uncertain about (and the most important one to us) is how we >>>> would be able to tell through which interconnect the DMA are done. >>>> >>>> This is important to us since our topology is actually quite simple as >>>> you've seen, but the RAM is not mapped on that bus and on the CPU's, >>>> so we need to apply an offset to each buffer being DMA'd. >>> >>> Ok, i see - your problem is not about bandwidth scaling but about using >>> different memory ranges by the driver to access the same location. So >>> this is not really the same and your problem is different. Also the >>> interconnect bindings are describing a path and endpoints. However i am >>> open to any ideas. >> >> It may be different things you need, but both are related to the path >> between a bus master and memory. We can't have each 'problem' >> described in a different way. Well, we could as long as each platform >> has different problems, but that's unlikely. >> >> It could turn out that the only commonality is property naming >> convention, but that's still better than 2 independent solutions. > > Yeah, I really don't think the two issues are unrelated. Can we maybe > have a particular interconnect-names value to mark the interconnect > being used to perform DMA? We can call one of the paths "dma" and use it to perform DMA for the current device. I don't see a problem with this. The name of the path is descriptive and makes sense. And by doing we avoid adding more DT properties, which would be an other option. This also makes me think that it might be a good idea to have a standard name for the path to memory as i expect some people will call it "mem", others "ddr" etc. Thanks, Georgi >> I know you each want to just fix your issues, but the fact that DT >> doesn't model the DMA side of the bus structure has been an issue at >> least since the start of DT on ARM. Either we should address this in a >> flexible way or we can just continue to manage without. So I'm not >> inclined to take something that only addresses one SoC family. > > I'd really like to have it addressed. We're getting bit by this, and > the hacks we have don't work well anymore.
Re: [PATCH v7 8/8] interconnect: Allow endpoints translation via DT
Hi Saravana,
On 08/02/2018 10:12 PM, skan...@codeaurora.org wrote:
> On 2018-08-02 05:07, Georgi Djakov wrote:
>> Hi Saravana,
>>
>> On 08/02/2018 01:57 AM, skan...@codeaurora.org wrote:
>>> On 2018-07-31 09:13, Georgi Djakov wrote:
>>>> Currently we support only platform data for specifying the interconnect
>>>> endpoints. As now the endpoints are hard-coded into the consumer driver
>>>> this may lead to complications when a single driver is used by multiple
>>>> SoCs, which may have different interconnect topology.
>>>> To avoid cluttering the consumer drivers, introduce a translation
>>>> function
>>>> to help us get the board specific interconnect data from device-tree.
>>>>
>>>> Signed-off-by: Georgi Djakov
>>>> ---
>>>>  drivers/interconnect/core.c | 62
>>>> Â include/linux/interconnect.h |Â 7
>>>> Â 2 files changed, 69 insertions(+)
>>>>
>>>> diff --git a/drivers/interconnect/core.c b/drivers/interconnect/core.c
>>>> index 9fef180cf77e..d1b6adff0a3d 100644
>>>> --- a/drivers/interconnect/core.c
>>>> +++ b/drivers/interconnect/core.c
>> [..]
>>>> --- a/include/linux/interconnect.h
>>>> +++ b/include/linux/interconnect.h
>>>> @@ -17,6 +17,7 @@ struct device;
>>>>
>>>> Â struct icc_path *icc_get(struct device *dev, const int src_id,
>>>> Â const int dst_id);
>>>> +struct icc_path *of_icc_get(struct device *dev, const char *name);
>>>> Â void icc_put(struct icc_path *path);
>>>> Â int icc_set(struct icc_path *path, u32 avg_bw, u32 peak_bw);
>>>>
>>>> @@ -28,6 +29,12 @@ static inline struct icc_path *icc_get(struct
>>>> device *dev, const int src_id,
>>>> return NULL;
>>>> Â }
>>>>
>>>> +static inline struct icc_path *of_icc_get(struct device *dev,
>>>> +Â const char *name)
>>>> +{
>>>> +Â Â Â return NULL;
>>>> +}
>>>> +
>>>
>>> Might want to return PTR(-ENODEV) or some error code so that client
>>> doesn't have to do NULL check AND an error check?
>>>
>>> -Saravana
>>
>> NULL is returned when CONFIG_INTERCONNECT=n. Configuration of
>> interconnects by consumer drivers could be optional and that's why null
>> is returned instead of an error. The consumer drivers decide how to
>> proceed in this case and if there is a hard requirement for interconnect
>> support, then i would suggest to express it as a dependency in Kconfig.
>
> Ehh... you could make the same argument with an error. If it's not
> mandatory for functioning, they can ignore a specific error and
> continue? At a minimum, these stub functions returning NULL doesn't
> match with the documentation that says these APIs will only ever return
> ERR_PTR().
>
> -Saravana
Here i am trying to align with other frameworks, which provide some
resources to consumers. The regulator/clock/reset frameworks return
NULL, so i prefer to do the same here. Drivers are free to handle NULL
specifically, but they don't have to. This NULL may also mean that
interconnects have been already configured by bootloader or firmware.
Of course i accept the comment to update the documentation to mention this.
Thanks,
Georgi
[PATCH v8 0/8] Introduce on-chip interconnect API
NULL pointer check in msm8916 driver. (Alex) * [patch 6]: Add missing depend on QCOM_SMD_RPM in Kconfig. (Evan) * [patch 3]: Don't check for errors on debugfs calls, remove debugfs directory when module is unloaded (Greg) Changes since patchset v5 (https://lkml.org/lkml/2018/6/20/453) * Fix the modular build, make rpm-smd driver a module. * Optimize locking and move to higher level. (Evan) * Code cleanups. Fix typos. (Evan, Matthias) * Add the source node to the path. (Evan) * Rename path_allocate() to path_init() with minor refactoring. (Evan) * Rename *_remove() functions to *_destroy(). * Return fixed errors in icc_link_destroy(). (Evan) * Fix krealloc() usage in icc_link_destroy(). (Evan) * Add missing kfree() in icc_node_create(). (Matthias) * Make icc_node_add() return void. (Matthias) * Change mutex_init to mutex_lock in icc_provider_add(). (Matthias) * Add new icc_node_del() function to delete nodes from provider. * Fix the header guard to reflect the path in smd-rpm.h. (Evan) * Check for errors returned by qcom_icc_rpm_smd_send(). (Evan) * Propagate the error of icc_provider_del(). (Evan) Changes since patchset v4 (https://lkml.org/lkml/2018/3/9/856) * Simplified locking by using a single global mutex. (Evan) * Changed the aggregation function interface. * Implemented functions for node, link, provider removal. (Evan) * Naming changes on variables and functions, removed redundant code. (Evan) * Fixes and clarifications in the docs. (Matthias, Evan, Amit, Alexandre) * Removed mandatory reg DT property, made interconnect-names optional. (Bjorn) * Made interconnect-cells property required to align with other bindings. (Neil) * Moved msm8916 specific bindings into a separate file and patch. (Bjorn) * Use the names, instead of the hardcoded ids for topology. (Matthias) * Init the node before creating the links. (Evan) * Added icc_units_to_bps macro. (Amit) Changes since patchset v3 (https://lkml.org/lkml/2017/9/8/544) * Refactored the constraints aggregation. * Use the IDR API. * Split the provider and consumer bindings into separate patches and propose new bindings for consumers, which allows to specify the local source port. * Adopted the icc_ prefix for API functions. * Introduced separate API functions for creating interconnect nodes and links. * Added DT lookup support in addition to platform data. * Dropped the event tracing patch for now. * Added a patch to provide summary via debugfs. * Use macro for the list of topology definitions in the platform driver. * Various minor changes. Changes since patchset v2 (https://lkml.org/lkml/2017/7/20/825) * Split the aggregation into per node and per provider. Cache the aggregated values. * Various small refactorings and cleanups in the framework. * Added a patch introducing basic tracepoint support for monitoring the time required to update the interconnect nodes. Changes since patchset v1 (https://lkml.org/lkml/2017/6/27/890) * Updates in the documentation. * Changes in request aggregation, locking. * Dropped the aggregate() callback and use the default as it currently sufficient for the single vendor driver. Will add it later when needed. * Dropped the dt-bindings draft patch for now. Changes since RFC v2 (https://lkml.org/lkml/2017/6/12/316) * Converted documentation to rst format. * Fixed an incorrect call to mutex_lock. Renamed max_bw to peak_bw. Changes since RFC v1 (https://lkml.org/lkml/2017/5/15/605) * Refactored code into shorter functions. * Added a new aggregate() API function. * Rearranged some structs to reduce padding bytes. Changes since RFC v0 (https://lkml.org/lkml/2017/3/1/599) * Removed DT support and added optional Patch 3 with new bindings proposal. * Converted the topology into internal driver data. * Made the framework modular. * interconnect_get() now takes (src and dst ports as arguments). * Removed public declarations of some structs. * Now passing prev/next nodes to the vendor driver. * Properly remove requests on _put(). * Added refcounting. * Updated documentation. * Changed struct interconnect_path to use array instead of linked list. Georgi Djakov (8): interconnect: Add generic on-chip interconnect API dt-bindings: Introduce interconnect binding interconnect: Allow endpoints translation via DT interconnect: Add debugfs support interconnect: qcom: Add RPM communication dt-bindings: interconnect: Document qcom,msm8916 NoC bindings interconnect: qcom: Add msm8916 interconnect provider driver MAINTAINERS: add a maintainer for the interconnect API .../bindings/interconnect/interconnect.txt| 60 ++ .../bindings/interconnect/qcom-msm8916.txt| 41 + .../bindings/interconnect/qcom-smd.txt| 32 + Documentation/interconnect/interconnect.rst | 94 +++ MAINTAINERS | 10 + drivers/Kconfig | 2 + drivers/Makefile | 1 + drivers/interconnect/Kconfig | 15 + dr
[PATCH v8 2/8] dt-bindings: Introduce interconnect binding
This binding is intended to represent the relations between the interconnect
controllers (providers) and consumer device nodes. It will allow creating links
between consumers and interconnect paths (exposed by interconnect providers).
Signed-off-by: Georgi Djakov
---
.../bindings/interconnect/interconnect.txt| 60 +++
1 file changed, 60 insertions(+)
create mode 100644
Documentation/devicetree/bindings/interconnect/interconnect.txt
diff --git a/Documentation/devicetree/bindings/interconnect/interconnect.txt
b/Documentation/devicetree/bindings/interconnect/interconnect.txt
new file mode 100644
index ..5cb7d3c8d44d
--- /dev/null
+++ b/Documentation/devicetree/bindings/interconnect/interconnect.txt
@@ -0,0 +1,60 @@
+Interconnect Provider Device Tree Bindings
+=
+
+The purpose of this document is to define a common set of generic interconnect
+providers/consumers properties.
+
+
+= interconnect providers =
+
+The interconnect provider binding is intended to represent the interconnect
+controllers in the system. Each provider registers a set of interconnect
+nodes, which expose the interconnect related capabilities of the interconnect
+to consumer drivers. These capabilities can be throughput, latency, priority
+etc. The consumer drivers set constraints on interconnect path (or endpoints)
+depending on the use case. Interconnect providers can also be interconnect
+consumers, such as in the case where two network-on-chip fabrics interface
+directly
+
+Required properties:
+- compatible : contains the interconnect provider compatible string
+- #interconnect-cells : number of cells in a interconnect specifier needed to
+ encode the interconnect node id
+
+Example:
+
+ snoc: snoc@58 {
+ compatible = "qcom,msm8916-snoc";
+ #interconnect-cells = <1>;
+ reg = <0x58 0x14000>;
+ clock-names = "bus_clk", "bus_a_clk";
+ clocks = <&rpmcc RPM_SMD_SNOC_CLK>,
+<&rpmcc RPM_SMD_SNOC_A_CLK>;
+ };
+
+
+= interconnect consumers =
+
+The interconnect consumers are device nodes which dynamically express their
+bandwidth requirements along interconnect paths they are connected to. There
+can be multiple interconnect providers on a SoC and the consumer may consume
+multiple paths from different providers depending on use case and the
+components it has to interact with.
+
+Required properties:
+interconnects : Pairs of phandles and interconnect provider specifier to denote
+ the edge source and destination ports of the interconnect path.
+
+Optional properties:
+interconnect-names : List of interconnect path name strings sorted in the same
+order as the interconnects property. Consumers drivers
will use
+interconnect-names to match interconnect paths with
interconnect
+specifiers.
+
+Example:
+
+ sdhci@7864000 {
+ ...
+ interconnects = <&pnoc MASTER_SDCC_1 &bimc SLAVE_EBI_CH0>;
+ interconnect-names = "ddr";
+ };
[PATCH v8 1/8] interconnect: Add generic on-chip interconnect API
This patch introduces a new API to get requirements and configure the interconnect buses across the entire chipset to fit with the current demand. The API is using a consumer/provider-based model, where the providers are the interconnect buses and the consumers could be various drivers. The consumers request interconnect resources (path) between endpoints and set the desired constraints on this data flow path. The providers receive requests from consumers and aggregate these requests for all master-slave pairs on that path. Then the providers configure each participating in the topology node according to the requested data flow path, physical links and constraints. The topology could be complicated and multi-tiered and is SoC specific. Signed-off-by: Georgi Djakov Reviewed-by: Evan Green --- Documentation/interconnect/interconnect.rst | 94 drivers/Kconfig | 2 + drivers/Makefile| 1 + drivers/interconnect/Kconfig| 10 + drivers/interconnect/Makefile | 2 + drivers/interconnect/core.c | 573 include/linux/interconnect-provider.h | 125 + include/linux/interconnect.h| 42 ++ 8 files changed, 849 insertions(+) create mode 100644 Documentation/interconnect/interconnect.rst create mode 100644 drivers/interconnect/Kconfig create mode 100644 drivers/interconnect/Makefile create mode 100644 drivers/interconnect/core.c create mode 100644 include/linux/interconnect-provider.h create mode 100644 include/linux/interconnect.h diff --git a/Documentation/interconnect/interconnect.rst b/Documentation/interconnect/interconnect.rst new file mode 100644 index ..b8107dcc4cd3 --- /dev/null +++ b/Documentation/interconnect/interconnect.rst @@ -0,0 +1,94 @@ +.. SPDX-License-Identifier: GPL-2.0 + += +GENERIC SYSTEM INTERCONNECT SUBSYSTEM += + +Introduction + + +This framework is designed to provide a standard kernel interface to control +the settings of the interconnects on an SoC. These settings can be throughput, +latency and priority between multiple interconnected devices or functional +blocks. This can be controlled dynamically in order to save power or provide +maximum performance. + +The interconnect bus is hardware with configurable parameters, which can be +set on a data path according to the requests received from various drivers. +An example of interconnect buses are the interconnects between various +components or functional blocks in chipsets. There can be multiple interconnects +on an SoC that can be multi-tiered. + +Below is a simplified diagram of a real-world SoC interconnect bus topology. + +:: + + ++++ + | HW Accelerator |--->| M NoC |<---+ + ++++| + | |++ + +-+ +-+ V +--+ || + | DDR | |++ | PCIe | || + +-+ || Slaves | +--+ || +^ ^|++ | | C NoC| +| |V V || + +--+ ++ || +-+ + | |-->||-->||-->| CPU | + | |-->||<--|| +-+ + | Mem NoC | | S NoC | ++ + | |<--||-+| + | |<--||<--+ || ++ + +--+ ++ | |+-->| Slaves | + ^ ^^^ ^ | |++ + | ||| | | V + +--+ | +-+ +-+ +-+ ++ ++ + | CPUs | | | GPU | | DSP | | Masters |-->| P NoC|-->| Slaves | + +--+ | +-+ +-+ +-+ ++ ++ + | + +---+ + | Modem | + +---+ + +Terminology +--- + +Interconnect provider is the software definition of the interconnect hardware. +The interconnect providers on the above diagram are M NoC, S NoC, C NoC, P NoC +and Mem NoC. + +Interconnect node is the software definition of the interconnect hardware +port. Each interconnect provider consists of multiple interconnect nodes, +which are connected to other SoC components including other interconnect +providers. The point on the diagram where the CPUs connect to the memory is +called an interconnect node, which belongs to the Mem NoC interconnect prov
[PATCH v8 4/8] interconnect: Add debugfs support
Add a functionality to provide information about the current constraints
per each node and provider.
Signed-off-by: Georgi Djakov
Reviewed-by: Evan Green
---
drivers/interconnect/core.c | 78 +
1 file changed, 78 insertions(+)
diff --git a/drivers/interconnect/core.c b/drivers/interconnect/core.c
index 8f874d1b0a0f..288ef83c3bc0 100644
--- a/drivers/interconnect/core.c
+++ b/drivers/interconnect/core.c
@@ -6,6 +6,7 @@
* Author: Georgi Djakov
*/
+#include
#include
#include
#include
@@ -17,10 +18,12 @@
#include
#include
#include
+#include
static DEFINE_IDR(icc_idr);
static LIST_HEAD(icc_provider_list);
static DEFINE_MUTEX(icc_lock);
+static struct dentry *icc_debugfs_dir;
/**
* struct icc_req - constraints that are attached to each node
@@ -49,6 +52,62 @@ struct icc_path {
struct icc_req reqs[];
};
+#ifdef CONFIG_DEBUG_FS
+
+static void icc_summary_show_one(struct seq_file *s, struct icc_node *n)
+{
+ if (!n)
+ return;
+
+ seq_printf(s, "%-30s %12d %12d\n",
+ n->name, n->avg_bw, n->peak_bw);
+}
+
+static int icc_summary_show(struct seq_file *s, void *data)
+{
+ struct icc_provider *provider;
+
+ seq_puts(s, " node avg
peak\n");
+ seq_puts(s,
"\n");
+
+ mutex_lock(&icc_lock);
+
+ list_for_each_entry(provider, &icc_provider_list, provider_list) {
+ struct icc_node *n;
+
+ list_for_each_entry(n, &provider->nodes, node_list) {
+ struct icc_req *r;
+
+ icc_summary_show_one(s, n);
+ hlist_for_each_entry(r, &n->req_list, req_node) {
+ if (!r->dev)
+ continue;
+
+ seq_printf(s, "%-26s %12d %12d\n",
+ dev_name(r->dev), r->avg_bw,
+ r->peak_bw);
+ }
+ }
+ }
+
+ mutex_unlock(&icc_lock);
+
+ return 0;
+}
+
+static int icc_summary_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, icc_summary_show, inode->i_private);
+}
+
+static const struct file_operations icc_summary_fops = {
+ .open = icc_summary_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release= single_release,
+};
+#endif
+
static struct icc_node *node_find(const int id)
{
return idr_find(&icc_idr, id);
@@ -646,6 +705,25 @@ int icc_provider_del(struct icc_provider *provider)
}
EXPORT_SYMBOL_GPL(icc_provider_del);
+static int __init icc_init(void)
+{
+#ifdef CONFIG_DEBUG_FS
+ icc_debugfs_dir = debugfs_create_dir("interconnect", NULL);
+ debugfs_create_file("interconnect_summary", 0444,
+ icc_debugfs_dir, NULL, &icc_summary_fops);
+#endif
+ return 0;
+}
+
+static void __exit icc_exit(void)
+{
+#ifdef CONFIG_DEBUG_FS
+ debugfs_remove_recursive(icc_debugfs_dir);
+#endif
+}
+module_init(icc_init);
+module_exit(icc_exit);
+
MODULE_AUTHOR("Georgi Djakov
[PATCH v8 8/8] MAINTAINERS: add a maintainer for the interconnect API
Add myself as the maintainer of the interconnect API. Signed-off-by: Georgi Djakov --- MAINTAINERS | 10 ++ 1 file changed, 10 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 32fbc6f732d4..ed1b534c901b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7420,6 +7420,16 @@ L: linux-g...@vger.kernel.org S: Maintained F: drivers/gpio/gpio-intel-mid.c +INTERCONNECT API +M: Georgi Djakov +S: Maintained +F: Documentation/interconnect/ +F: Documentation/devicetree/bindings/interconnect/ +F: drivers/interconnect/ +F: include/dt-bindings/interconnect/ +F: include/linux/interconnect-provider.h +F: include/linux/interconnect.h + INVENSENSE MPU-3050 GYROSCOPE DRIVER M: Linus Walleij L: linux-...@vger.kernel.org
[PATCH v8 6/8] dt-bindings: interconnect: Document qcom,msm8916 NoC bindings
Document the device-tree bindings of the Network-On-Chip interconnect
hardware found on Qualcomm msm8916 platforms.
Signed-off-by: Georgi Djakov
Reviewed-by: Evan Green
---
.../bindings/interconnect/qcom-msm8916.txt| 41
include/dt-bindings/interconnect/qcom.h | 98 +++
2 files changed, 139 insertions(+)
create mode 100644
Documentation/devicetree/bindings/interconnect/qcom-msm8916.txt
create mode 100644 include/dt-bindings/interconnect/qcom.h
diff --git a/Documentation/devicetree/bindings/interconnect/qcom-msm8916.txt
b/Documentation/devicetree/bindings/interconnect/qcom-msm8916.txt
new file mode 100644
index ..744df51df4ed
--- /dev/null
+++ b/Documentation/devicetree/bindings/interconnect/qcom-msm8916.txt
@@ -0,0 +1,41 @@
+Qualcomm MSM8916 Network-On-Chip interconnect driver binding
+
+
+Required properties :
+- compatible : shall contain only one of the following:
+ "qcom,msm8916-bimc"
+ "qcom,msm8916-pnoc"
+ "qcom,msm8916-snoc"
+- #interconnect-cells : should contain 1
+- reg : shall contain base register location and length
+
+Optional properties :
+clocks : list of phandles and specifiers to all interconnect bus clocks
+clock-names : clock names should include both "bus_clk" and "bus_a_clk"
+
+Examples:
+
+ snoc: snoc@58 {
+ compatible = "qcom,msm8916-snoc";
+ #interconnect-cells = <1>;
+ reg = <0x58 0x14000>;
+ clock-names = "bus_clk", "bus_a_clk";
+ clocks = <&rpmcc RPM_SMD_SNOC_CLK>,
+<&rpmcc RPM_SMD_SNOC_A_CLK>;
+ };
+ bimc: bimc@40 {
+ compatible = "qcom,msm8916-bimc";
+ #interconnect-cells = <1>;
+ reg = <0x40 0x62000>;
+ clock-names = "bus_clk", "bus_a_clk";
+ clocks = <&rpmcc RPM_SMD_BIMC_CLK>,
+<&rpmcc RPM_SMD_BIMC_A_CLK>;
+ };
+ pnoc: pnoc@50 {
+ compatible = "qcom,msm8916-pnoc";
+ #interconnect-cells = <1>;
+ reg = <0x50 0x11000>;
+ clock-names = "bus_clk", "bus_a_clk";
+ clocks = <&rpmcc RPM_SMD_PCNOC_CLK>,
+<&rpmcc RPM_SMD_PCNOC_A_CLK>;
+ };
diff --git a/include/dt-bindings/interconnect/qcom.h
b/include/dt-bindings/interconnect/qcom.h
new file mode 100644
index 0000..f4d154f0afbf
--- /dev/null
+++ b/include/dt-bindings/interconnect/qcom.h
@@ -0,0 +1,98 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Qualcomm interconnect IDs
+ *
+ * Copyright (c) 2018, Linaro Ltd.
+ * Author: Georgi Djakov
+ */
+
+#ifndef __DT_BINDINGS_INTERCONNECT_QCOM_H
+#define __DT_BINDINGS_INTERCONNECT_QCOM_H
+
+#define BIMC_SNOC_MAS 0
+#define BIMC_SNOC_SLV 1
+#define MASTER_AMPSS_M02
+#define MASTER_BLSP_1 3
+#define MASTER_CRYPTO_CORE04
+#define MASTER_DEHR5
+#define MASTER_GRAPHICS_3D 6
+#define MASTER_JPEG7
+#define MASTER_LPASS 8
+#define MASTER_MDP_PORT0 9
+#define MASTER_QDSS_BAM10
+#define MASTER_QDSS_ETR11
+#define MASTER_SDCC_1 12
+#define MASTER_SDCC_2 13
+#define MASTER_SNOC_CFG14
+#define MASTER_SPDM15
+#define MASTER_TCU_0 16
+#define MASTER_TCU_1 17
+#define MASTER_USB_HS 18
+#define MASTER_VFE 19
+#define MASTER_VIDEO_P020
+#define PNOC_INT_0 21
+#define PNOC_INT_1 22
+#define PNOC_M_0 23
+#define PNOC_M_1 24
+#define PNOC_SLV_0 25
+#define PNOC_SLV_1 26
+#define PNOC_SLV_2 27
+#define PNOC_SLV_3 28
+#define PNOC_SLV_4 29
+#define PNOC_SLV_8 30
+#define PNOC_SLV_9 31
+#define PNOC_SNOC_MAS 32
+#define PNOC_SNOC_SLV 33
+#define SLAVE_AMPSS_L2 34
+#define SLAVE_BIMC_CFG 35
+#define SLAVE_BLSP_1 36
+#define SLAVE_BOOT_ROM 37
+#define SLAVE_CAMERA_CFG
[PATCH v8 7/8] interconnect: qcom: Add msm8916 interconnect provider driver
Add driver for the Qualcomm interconnect buses found in msm8916 based
platforms.
Signed-off-by: Georgi Djakov
---
drivers/interconnect/Kconfig| 5 +
drivers/interconnect/Makefile | 1 +
drivers/interconnect/qcom/Kconfig | 9 +
drivers/interconnect/qcom/Makefile | 2 +
drivers/interconnect/qcom/msm8916.c | 510
5 files changed, 527 insertions(+)
create mode 100644 drivers/interconnect/qcom/msm8916.c
diff --git a/drivers/interconnect/Kconfig b/drivers/interconnect/Kconfig
index a261c7d41deb..07a8276fa35a 100644
--- a/drivers/interconnect/Kconfig
+++ b/drivers/interconnect/Kconfig
@@ -8,3 +8,8 @@ menuconfig INTERCONNECT
If unsure, say no.
+if INTERCONNECT
+
+source "drivers/interconnect/qcom/Kconfig"
+
+endif
diff --git a/drivers/interconnect/Makefile b/drivers/interconnect/Makefile
index 97fca2e09d24..7944cbca0527 100644
--- a/drivers/interconnect/Makefile
+++ b/drivers/interconnect/Makefile
@@ -1,2 +1,3 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_INTERCONNECT) += core.o
+obj-$(CONFIG_INTERCONNECT_QCOM)+= qcom/
diff --git a/drivers/interconnect/qcom/Kconfig
b/drivers/interconnect/qcom/Kconfig
index 812e9464765a..add6d7e1e24e 100644
--- a/drivers/interconnect/qcom/Kconfig
+++ b/drivers/interconnect/qcom/Kconfig
@@ -12,3 +12,12 @@ config INTERCONNECT_QCOM_SMD_RPM
help
This is a driver for communicating interconnect related configuration
details with a remote processor (RPM) on Qualcomm platforms.
+
+config INTERCONNECT_QCOM_MSM8916
+ tristate "Qualcomm MSM8916 interconnect driver"
+ depends on INTERCONNECT_QCOM
+ depends on QCOM_SMD_RPM
+ select INTERCONNECT_QCOM_SMD_RPM
+ help
+ This is a driver for the Qualcomm Network-on-Chip on msm8916-based
+ platforms.
diff --git a/drivers/interconnect/qcom/Makefile
b/drivers/interconnect/qcom/Makefile
index 5b65e4011b59..53f3380277f6 100644
--- a/drivers/interconnect/qcom/Makefile
+++ b/drivers/interconnect/qcom/Makefile
@@ -1,2 +1,4 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_INTERCONNECT_QCOM_SMD_RPM) += smd-rpm.o
+
+obj-$(CONFIG_INTERCONNECT_QCOM_MSM8916) += msm8916.o
diff --git a/drivers/interconnect/qcom/msm8916.c
b/drivers/interconnect/qcom/msm8916.c
new file mode 100644
index ..74145f4f74f1
--- /dev/null
+++ b/drivers/interconnect/qcom/msm8916.c
@@ -0,0 +1,510 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 Linaro Ltd
+ * Author: Georgi Djakov
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "smd-rpm.h"
+
+#define RPM_BUS_MASTER_REQ 0x73616d62
+#define RPM_BUS_SLAVE_REQ 0x766c7362
+
+#define to_qcom_provider(_provider) \
+ container_of(_provider, struct qcom_icc_provider, provider)
+
+enum qcom_qos_mode {
+ QCOM_QOS_MODE_BYPASS = 0,
+ QCOM_QOS_MODE_FIXED,
+ QCOM_QOS_MODE_MAX,
+};
+
+struct qcom_icc_provider {
+ struct icc_provider provider;
+ void __iomem*base;
+ struct clk *bus_clk;
+ struct clk *bus_a_clk;
+};
+
+#define MSM8916_MAX_LINKS 8
+
+/**
+ * struct qcom_icc_node - Qualcomm specific interconnect nodes
+ * @name: the node name used in debugfs
+ * @id: a unique node identifier
+ * @links: an array of nodes where we can go next while traversing
+ * @num_links: the total number of @links
+ * @port: the offset index into the masters QoS register space
+ * @buswidth: width of the interconnect between a node and the bus (bytes)
+ * @ap_owned: the AP CPU does the writing to QoS registers
+ * @qos_mode: QoS mode for ap_owned resources
+ * @mas_rpm_id:RPM id for devices that are bus masters
+ * @slv_rpm_id:RPM id for devices that are bus slaves
+ * @rate: current bus clock rate in Hz
+ */
+struct qcom_icc_node {
+ unsigned char *name;
+ u16 id;
+ u16 links[MSM8916_MAX_LINKS];
+ u16 num_links;
+ u16 port;
+ u16 buswidth;
+ bool ap_owned;
+ enum qcom_qos_mode qos_mode;
+ int mas_rpm_id;
+ int slv_rpm_id;
+ u64 rate;
+};
+
+struct qcom_icc_desc {
+ struct qcom_icc_node **nodes;
+ size_t num_nodes;
+};
+
+#define DEFINE_QNODE(_name, _id, _port, _buswidth, _ap_owned, \
+ _mas_rpm_id, _slv_rpm_id, _qos_mode,\
+ _numlinks, ...) \
+ static struct qcom_icc_node _name = { \
+ .name = #_name, \
+ .id = _id, \
+ .port = _port, \
+ .buswidth = _buswidth, \
+
[PATCH v8 3/8] interconnect: Allow endpoints translation via DT
Currently we support only platform data for specifying the interconnect
endpoints. As now the endpoints are hard-coded into the consumer driver
this may lead to complications when a single driver is used by multiple
SoCs, which may have different interconnect topology.
To avoid cluttering the consumer drivers, introduce a translation function
to help us get the board specific interconnect data from device-tree.
Signed-off-by: Georgi Djakov
Reviewed-by: Evan Green
---
drivers/interconnect/core.c | 78
include/linux/interconnect.h | 7
2 files changed, 85 insertions(+)
diff --git a/drivers/interconnect/core.c b/drivers/interconnect/core.c
index 9ca39aca4982..8f874d1b0a0f 100644
--- a/drivers/interconnect/core.c
+++ b/drivers/interconnect/core.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
static DEFINE_IDR(icc_idr);
@@ -192,6 +193,83 @@ static int apply_constraints(struct icc_path *path)
return ret;
}
+/**
+ * of_icc_get() - get a path handle from a DT node based on name
+ * @dev: device pointer for the consumer device
+ * @name: interconnect path name
+ *
+ * This function will search for a path two endpoints and return an
+ * icc_path handle on success. Use icc_put() to release constraints when
+ * they are not needed anymore.
+ * If the interconnect API is disabled, NULL is returned and the consumer
+ * drivers will still build. Drivers are free to handle this specifically,
+ * but they don't have to. NULL is also returned when the "interconnects"
+ * DT property is missing.
+ *
+ * Return: icc_path pointer on success or ERR_PTR() on error. NULL is returned
+ * when the API is disabled or the "interconnects" DT property is missing.
+ */
+struct icc_path *of_icc_get(struct device *dev, const char *name)
+{
+ struct device_node *np = NULL;
+ struct of_phandle_args src_args, dst_args;
+ u32 src_id, dst_id;
+ int idx = 0;
+ int ret;
+
+ if (!dev || !dev->of_node)
+ return ERR_PTR(-ENODEV);
+
+ np = dev->of_node;
+
+ /*
+* When the consumer DT node do not have "interconnects" property
+* return a NULL path to skip setting constraints.
+*/
+ if (!of_find_property(np, "interconnects", NULL))
+ return NULL;
+
+ /*
+* We use a combination of phandle and specifier for endpoint. For now
+* lets support only global ids and extend this is the future if needed
+* without breaking DT compatibility.
+*/
+ if (name) {
+ idx = of_property_match_string(np, "interconnect-names", name);
+ if (idx < 0)
+ return ERR_PTR(idx);
+ }
+
+ ret = of_parse_phandle_with_args(np, "interconnects",
+"#interconnect-cells", idx * 2,
+&src_args);
+ if (ret)
+ return ERR_PTR(ret);
+
+ of_node_put(src_args.np);
+
+ if (!src_args.args_count || src_args.args_count > 1)
+ return ERR_PTR(-EINVAL);
+
+ src_id = src_args.args[0];
+
+ ret = of_parse_phandle_with_args(np, "interconnects",
+"#interconnect-cells", idx * 2 + 1,
+&dst_args);
+ if (ret)
+ return ERR_PTR(ret);
+
+ of_node_put(dst_args.np);
+
+ if (!dst_args.args_count || dst_args.args_count > 1)
+ return ERR_PTR(-EINVAL);
+
+ dst_id = dst_args.args[0];
+
+ return icc_get(dev, src_id, dst_id);
+}
+EXPORT_SYMBOL_GPL(of_icc_get);
+
/**
* icc_set() - set constraints on an interconnect path between two endpoints
* @path: reference to the path returned by icc_get()
diff --git a/include/linux/interconnect.h b/include/linux/interconnect.h
index 593215371fd6..ae6744da9bc2 100644
--- a/include/linux/interconnect.h
+++ b/include/linux/interconnect.h
@@ -17,6 +17,7 @@ struct device;
struct icc_path *icc_get(struct device *dev, const int src_id,
const int dst_id);
+struct icc_path *of_icc_get(struct device *dev, const char *name);
void icc_put(struct icc_path *path);
int icc_set(struct icc_path *path, u32 avg_bw, u32 peak_bw);
@@ -28,6 +29,12 @@ static inline struct icc_path *icc_get(struct device *dev,
const int src_id,
return NULL;
}
+static inline struct icc_path *of_icc_get(struct device *dev,
+ const char *name)
+{
+ return NULL;
+}
+
static inline void icc_put(struct icc_path *path)
{
}
[PATCH v8 5/8] interconnect: qcom: Add RPM communication
On some Qualcomm SoCs, there is a remote processor, which controls some of
the Network-On-Chip interconnect resources. Other CPUs express their needs
by communicating with this processor. Add a driver to handle communication
with this remote processor.
Signed-off-by: Georgi Djakov
Reviewed-by: Evan Green
---
.../bindings/interconnect/qcom-smd.txt| 32 +++
drivers/interconnect/qcom/Kconfig | 14 +++
drivers/interconnect/qcom/Makefile| 2 +
drivers/interconnect/qcom/smd-rpm.c | 91 +++
drivers/interconnect/qcom/smd-rpm.h | 16
5 files changed, 155 insertions(+)
create mode 100644 Documentation/devicetree/bindings/interconnect/qcom-smd.txt
create mode 100644 drivers/interconnect/qcom/Kconfig
create mode 100644 drivers/interconnect/qcom/Makefile
create mode 100644 drivers/interconnect/qcom/smd-rpm.c
create mode 100644 drivers/interconnect/qcom/smd-rpm.h
diff --git a/Documentation/devicetree/bindings/interconnect/qcom-smd.txt
b/Documentation/devicetree/bindings/interconnect/qcom-smd.txt
new file mode 100644
index ..2325167f6eaf
--- /dev/null
+++ b/Documentation/devicetree/bindings/interconnect/qcom-smd.txt
@@ -0,0 +1,32 @@
+Qualcomm SMD-RPM interconnect driver binding
+
+The RPM (Resource Power Manager) is a dedicated hardware engine
+for managing the shared SoC resources in order to keep the lowest
+power profile. It communicates with other hardware subsystems via
+the shared memory driver (SMD) back-end and accepts requests for
+various resources.
+
+Required properties :
+- compatible : shall contain only one of the following:
+ "qcom,interconnect-smd-rpm"
+
+Example:
+ smd {
+ compatible = "qcom,smd";
+
+ rpm {
+ interrupts = ;
+ qcom,ipc = <&apcs 8 0>;
+ qcom,smd-edge = <15>;
+
+ rpm_requests {
+ compatible = "qcom,rpm-msm8916";
+ qcom,smd-channels = "rpm_requests";
+
+ interconnect-smd-rpm {
+ compatible =
"qcom,interconnect-smd-rpm";
+ };
+
+ };
+ };
+ };
diff --git a/drivers/interconnect/qcom/Kconfig
b/drivers/interconnect/qcom/Kconfig
new file mode 100644
index ..812e9464765a
--- /dev/null
+++ b/drivers/interconnect/qcom/Kconfig
@@ -0,0 +1,14 @@
+config INTERCONNECT_QCOM
+ bool "Qualcomm Network-on-Chip interconnect drivers"
+ depends on INTERCONNECT
+ depends on ARCH_QCOM || COMPILE_TEST
+ help
+ Support for Qualcomm's Network-on-Chip interconnect hardware.
+
+config INTERCONNECT_QCOM_SMD_RPM
+ tristate "Qualcomm SMD RPM interconnect driver"
+ depends on INTERCONNECT_QCOM
+ depends on QCOM_SMD_RPM
+ help
+ This is a driver for communicating interconnect related configuration
+ details with a remote processor (RPM) on Qualcomm platforms.
diff --git a/drivers/interconnect/qcom/Makefile
b/drivers/interconnect/qcom/Makefile
new file mode 100644
index ..5b65e4011b59
--- /dev/null
+++ b/drivers/interconnect/qcom/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_INTERCONNECT_QCOM_SMD_RPM) += smd-rpm.o
diff --git a/drivers/interconnect/qcom/smd-rpm.c
b/drivers/interconnect/qcom/smd-rpm.c
new file mode 100644
index ..48b7a2a6eb84
--- /dev/null
+++ b/drivers/interconnect/qcom/smd-rpm.c
@@ -0,0 +1,91 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * RPM over SMD communication wrapper for interconnects
+ *
+ * Copyright (C) 2018 Linaro Ltd
+ * Author: Georgi Djakov
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include "smd-rpm.h"
+
+#defineRPM_KEY_BW 0x7762
+
+static struct qcom_icc_rpm {
+ struct qcom_smd_rpm *rpm;
+} icc_rpm_smd;
+
+struct icc_rpm_smd_req {
+ __le32 key;
+ __le32 nbytes;
+ __le32 value;
+};
+
+bool qcom_icc_rpm_smd_available(void)
+{
+ if (!icc_rpm_smd.rpm)
+ return false;
+
+ return true;
+}
+EXPORT_SYMBOL_GPL(qcom_icc_rpm_smd_available);
+
+int qcom_icc_rpm_smd_send(int ctx, int rsc_type, int id, u32 val)
+{
+ struct icc_rpm_smd_req req = {
+ .key = cpu_to_le32(RPM_KEY_BW),
+ .nbytes = cpu_to_le32(sizeof(u32)),
+ .value = cpu_to_le32(val),
+ };
+
+ return qcom_rpm_smd_write(icc_rpm_smd.rpm, ctx, rsc_type, id, &req,
+ sizeof(req));
+}
+EXPORT_SYMBOL_GPL(qcom_icc_rpm_smd_send);
+
+static int qcom_icc_rpm_smd_probe(struct platform_device *pdev)
+{
+ icc_rpm_smd.rpm = dev_get_drvdata(p
Re: [PATCH v3 2/2] PM / devfreq: Add devfreq driver for interconnect bandwidth voting
Hi Saravana,
On 08/02/2018 03:57 AM, Saravana Kannan wrote:
> This driver registers itself as a devfreq device that allows devfreq
> governors to make bandwidth votes for an interconnect path. This allows
> applying various policies for different interconnect paths using devfreq
> governors.
>
> Example uses:
> * Use the devfreq performance governor to set the CPU to DDR interconnect
> path for maximum performance.
> * Use the devfreq performance governor to set the GPU to DDR interconnect
> path for maximum performance.
> * Use the CPU frequency to device frequency mapping governor to scale the
> DDR frequency based on the needs of the CPUs' current frequency.
Usually CPUs and GPUs have dedicated cpufreq/devfreq drivers and i was
wondering if the interconnect support could be put into these drivers
directly?
>
> Signed-off-by: Saravana Kannan
> ---
> Documentation/devicetree/bindings/devfreq/icbw.txt | 21
> drivers/devfreq/Kconfig| 13 +++
> drivers/devfreq/Makefile | 1 +
> drivers/devfreq/devfreq_icbw.c | 116
> +
> 4 files changed, 151 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/devfreq/icbw.txt
> create mode 100644 drivers/devfreq/devfreq_icbw.c
>
> diff --git a/Documentation/devicetree/bindings/devfreq/icbw.txt
> b/Documentation/devicetree/bindings/devfreq/icbw.txt
> new file mode 100644
> index 000..36cf045
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/devfreq/icbw.txt
> @@ -0,0 +1,21 @@
> +Interconnect bandwidth device
> +
> +icbw is a device that represents an interconnect path that connects two
> +devices. This device is typically used to vote for BW requirements between
> +two devices. Eg: CPU to DDR, GPU to DDR, etc
> +
> +Required properties:
> +- compatible:Must be "devfreq-icbw"
> +- interconnects: Pairs of phandles and interconnect provider specifier
> + to denote the edge source and destination ports of
> + the interconnect path. See also:
> + Documentation/devicetree/bindings/interconnect/interconnect.txt
> +- interconnect-names:Must have one entry with the name "path".
> +
> +Example:
> +
> + qcom,cpubw {
> + compatible = "devfreq-icbw";
> + interconnects = <&snoc MASTER_APSS_1 &bimc SLAVE_EBI_CH0>;
> + interconnect-names = "path";
interconnect-names is optional when there is only a single path.
> + };
> diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
> index 3d9ae68..590370e 100644
> --- a/drivers/devfreq/Kconfig
> +++ b/drivers/devfreq/Kconfig
> @@ -121,6 +121,19 @@ config ARM_RK3399_DMC_DEVFREQ
>It sets the frequency for the memory controller and reads the
> usage counts
>from hardware.
>
> +config DEVFREQ_ICBW
> + bool "DEVFREQ device for making bandwidth votes on interconnect paths"
Can this be a module?
> + select DEVFREQ_GOV_PERFORMANCE
> + select DEVFREQ_GOV_POWERSAVE
> + select DEVFREQ_GOV_USERSPACE
> + default n
There's no need to specify this default. It is 'n' by default anyway.
Also maybe you want to add something like:
depends on INTERCONNECT=y
Thanks,
Georgi
> + help
> + Different devfreq governors use this devfreq device to make
> + bandwidth votes for interconnect paths between different devices
> + (Eg: CPU to DDR, GPU to DDR, etc). This driver provides a generic
> + interface so that the devfreq governors can be shared across SoCs
> + and architectures.
> +
> source "drivers/devfreq/event/Kconfig"
Re: [PATCH v7 2/8] dt-bindings: Introduce interconnect provider bindings
Hi Maxime, On 08/20/2018 06:32 PM, Maxime Ripard wrote: > Hi Georgi, > > On Tue, Aug 07, 2018 at 05:54:38PM +0300, Georgi Djakov wrote: >>> There is also a patch series from Maxime Ripard that's addressing the >>> same general area. See "dt-bindings: Add a dma-parent property". We >>> don't need multiple ways to address describing the device to memory >>> paths, so you all had better work out a common solution. >> >> Looks like this fits exactly into the interconnect API concept. I see >> MBUS as interconnect provider and display/camera as consumers, that >> report their bandwidth needs. I am also planning to add support for >> priority. > > Thanks for working on this. After looking at your serie, the one thing > I'm a bit uncertain about (and the most important one to us) is how we > would be able to tell through which interconnect the DMA are done. > > This is important to us since our topology is actually quite simple as > you've seen, but the RAM is not mapped on that bus and on the CPU's, > so we need to apply an offset to each buffer being DMA'd. Ok, i see - your problem is not about bandwidth scaling but about using different memory ranges by the driver to access the same location. So this is not really the same and your problem is different. Also the interconnect bindings are describing a path and endpoints. However i am open to any ideas. Thanks, Georgi
Re: [PATCH v6 1/8] interconnect: Add generic on-chip interconnect API
Hi Evan,
Thanks for helping to improve this!
On 07/11/2018 01:34 AM, Evan Green wrote:
> Ahoy Georgi!
> On Mon, Jul 9, 2018 at 8:51 AM Georgi Djakov wrote:
>>
>> This patch introduces a new API to get requirements and configure the
>> interconnect buses across the entire chipset to fit with the current
>> demand.
>>
>> The API is using a consumer/provider-based model, where the providers are
>> the interconnect buses and the consumers could be various drivers.
>> The consumers request interconnect resources (path) between endpoints and
>> set the desired constraints on this data flow path. The providers receive
>> requests from consumers and aggregate these requests for all master-slave
>> pairs on that path. Then the providers configure each participating in the
>> topology node according to the requested data flow path, physical links and
>> constraints. The topology could be complicated and multi-tiered and is SoC
>> specific.
>>
>> Signed-off-by: Georgi Djakov
>> ---
[..]
>> +Interconnect node is the software definition of the interconnect hardware
>> +port. Each interconnect provider consists of multiple interconnect nodes,
>> +which are connected to other SoC components including other interconnect
>> +providers. The point on the diagram where the CPUs connects to the memory is
>
> CPUs connect
Ok.
[..]
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>
> I needed to add #include to get struct_size() (used
> in path_init) in order to get this to compile, but maybe my kernel is
> missing some upstream picks.
Yes, should be included.
>> +#include
>> +
>> +static DEFINE_IDR(icc_idr);
>> +static LIST_HEAD(icc_provider_list);
>> +static DEFINE_MUTEX(icc_lock);
>> +
>> +/**
>> + * struct icc_req - constraints that are attached to each node
>> + *
>> + * @req_node: entry in list of requests for the particular @node
>> + * @node: the interconnect node to which this constraint applies
>> + * @dev: reference to the device that sets the constraints
>> + * @avg_bw: an integer describing the average bandwidth in kbps
>> + * @peak_bw: an integer describing the peak bandwidth in kbps
>> + */
>> +struct icc_req {
>> + struct hlist_node req_node;
>> + struct icc_node *node;
>> + struct device *dev;
>> + u32 avg_bw;
>> + u32 peak_bw;
>> +};
>> +
>> +/**
>> + * struct icc_path - interconnect path structure
>> + * @num_nodes: number of hops (nodes)
>> + * @reqs: array of the requests applicable to this path of nodes
>> + */
>> +struct icc_path {
>> + size_t num_nodes;
>> + struct icc_req reqs[];
>> +};
>> +
>> +static struct icc_node *node_find(const int id)
>> +{
>> + return idr_find(&icc_idr, id);
>
> Wasn't there going to be a warning if the mutex is not held?
I think that it would be really useful if the functions are exported,
but for now let's skip it.
>> +}
>> +
>> +static struct icc_path *path_init(struct device *dev, struct icc_node *dst,
>> + ssize_t num_nodes)
>> +{
>> + struct icc_node *node = dst;
>> + struct icc_path *path;
>> + size_t i;
>> +
>> + path = kzalloc(struct_size(path, reqs, num_nodes), GFP_KERNEL);
>> + if (!path)
>> + return ERR_PTR(-ENOMEM);
>> +
>> + path->num_nodes = num_nodes;
>> +
>
> There should probably also be a warning here about holding the lock,
> since you're modifying node->req_list.
This is called only by path_find() with the lock held.
>> + for (i = 0; i < num_nodes; i++) {
>> + hlist_add_head(&path->reqs[i].req_node, &node->req_list);
>> +
>> + path->reqs[i].node = node;
>> + path->reqs[i].dev = dev;
>> + /* reference to previous node was saved during path
>> traversal */
>> + node = node->reverse;
>> + }
>> +
>> + return path;
>> +}
>> +
>> +static struct icc_path *path_find(struct device *dev, struct icc_node *src,
>> + struct icc_node *dst)
>> +{
>> + struct icc_node *n, *node = NULL;
>> + struct icc_provider *provider;
>> + struct list_head traverse_list;
>> + struct list_head edge_list;
>> + struct list_head visited_
Re: [PATCH v6 1/8] interconnect: Add generic on-chip interconnect API
Hi Alexandre,
On 07/11/2018 07:21 PM, Alexandre Bailon wrote:
> On 07/09/2018 05:50 PM, Georgi Djakov wrote:
>> This patch introduces a new API to get requirements and configure the
>> interconnect buses across the entire chipset to fit with the current
>> demand.
>>
>> The API is using a consumer/provider-based model, where the providers are
>> the interconnect buses and the consumers could be various drivers.
>> The consumers request interconnect resources (path) between endpoints and
>> set the desired constraints on this data flow path. The providers receive
>> requests from consumers and aggregate these requests for all master-slave
>> pairs on that path. Then the providers configure each participating in the
>> topology node according to the requested data flow path, physical links and
>> constraints. The topology could be complicated and multi-tiered and is SoC
>> specific.
>>
>> Signed-off-by: Georgi Djakov
>> ---
[..]
>> +static int apply_constraints(struct icc_path *path)
>> +{
>> +struct icc_node *next, *prev = NULL;
>> +int ret;
>> +int i;
>> +
>> +for (i = 0; i < path->num_nodes; i++, prev = next) {
>> +struct icc_provider *p;
>> +
>> +next = path->reqs[i].node;
>> +/*
>> + * Both endpoints should be valid master-slave pairs of the
>> + * same interconnect provider that will be configured.
>> + */
>> +if (!prev || next->provider != prev->provider)
>> +continue;
>> +
>> +p = next->provider;
>> +
>> +aggregate_provider(p);
>> +
>> +/* set the constraints */
>> +ret = p->set(prev, next, p->avg_bw, p->peak_bw);
> I'm confuse here.
> In path_init(), the first reqs' node takes the node.
> But here, this same element is assigned to prev, which is used as src by
> set(). For me this looks like prev and next have been inverted.
Ok, right. Will change the order of reqs to go from the source to the
destination.
Thanks,
Georgi
>> +if (ret)
>> +goto out;
>> +}
>> +out:
>> +return ret;
>> +}
>> +
Re: [PATCH v6 3/8] interconnect: Add debugfs support
Hi Greg,
On 15.07.18 г. 15:15, Greg KH wrote:
> On Mon, Jul 09, 2018 at 06:50:59PM +0300, Georgi Djakov wrote:
>> +static int __init icc_debugfs_init(void)
>> +{
>> +struct dentry *file;
>> +
>> +icc_debugfs_dir = debugfs_create_dir("interconnect", NULL);
>> +if (!icc_debugfs_dir) {
>> +pr_err("interconnect: error creating debugfs directory\n");
>> +return -ENODEV;
>> +}
>
> You should never care about the return value of a debugfs call. Just
> ignore it and move on.
Ok!
>> +file = debugfs_create_file("interconnect_summary", 0444,
>> + icc_debugfs_dir, NULL, &icc_summary_fops);
>> +if (!file)
>> +return -ENODEV;
>
> Again, do not check this.
>
> Where do you remove this directory and file from the system when the
> code shuts down?
Will take care of this! Thanks for the feedback!
Georgi
Re: [PATCH v6 4/8] interconnect: qcom: Add RPM communication
Hi Evan,
On 07/11/2018 01:34 AM, Evan Green wrote:
> On Mon, Jul 9, 2018 at 8:51 AM Georgi Djakov wrote:
>>
>> On some Qualcomm SoCs, there is a remote processor, which controls some of
>> the Network-On-Chip interconnect resources. Other CPUs express their needs
>> by communicating with this processor. Add a driver to handle communication
>> with this remote processor.
>>
>> Signed-off-by: Georgi Djakov
>> ---
>> .../bindings/interconnect/qcom-smd.txt| 32 +++
>> drivers/interconnect/qcom/Kconfig | 11 +++
>> drivers/interconnect/qcom/Makefile| 2 +
>> drivers/interconnect/qcom/smd-rpm.c | 91 +++
>> drivers/interconnect/qcom/smd-rpm.h | 15 +++
>> 5 files changed, 151 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/interconnect/qcom-smd.txt
>> create mode 100644 drivers/interconnect/qcom/Kconfig
>> create mode 100644 drivers/interconnect/qcom/Makefile
>> create mode 100644 drivers/interconnect/qcom/smd-rpm.c
>> create mode 100644 drivers/interconnect/qcom/smd-rpm.h
>>
>> diff --git a/Documentation/devicetree/bindings/interconnect/qcom-smd.txt
>> b/Documentation/devicetree/bindings/interconnect/qcom-smd.txt
>> new file mode 100644
>> index ..88a5aeb50935
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/interconnect/qcom-smd.txt
>> @@ -0,0 +1,32 @@
>> +Qualcomm SMD-RPM interconnect driver binding
>> +
>> +The RPM (Resource Power Manager) is a dedicated hardware engine
>> +for managing the shared SoC resources in order to keep the lowest
>> +power profile. It communicates with other hardware subsystems via
>> +the shared memory driver (SMD) back-end and accepts requests for
>> +various resources.
>> +
>> +Required properties :
>> +- compatible : shall contain only one of the following:
>> + "qcom,interconnect-smd-rpm"
>> +
>> +Example:
>> + smd {
>> + compatible = "qcom,smd";
>> +
>> + rpm {
>> + interrupts = <0 168 1>;
>> + qcom,ipc = <&apcs 8 0>;
>> + qcom,smd-edge = <15>;
>> +
>> + rpm_requests {
>> + compatible = "qcom,rpm-msm8916";
>> + qcom,smd-channels = "rpm_requests";
>> +
>> + interconnect-smd-rpm {
>> + compatible =
>> "qcom,interconnect-smd-rpm";
>> + };
>> +
>> + };
>> + };
>> + };
>> diff --git a/drivers/interconnect/qcom/Kconfig
>> b/drivers/interconnect/qcom/Kconfig
>> new file mode 100644
>> index ..b0c2ff928d88
>> --- /dev/null
>> +++ b/drivers/interconnect/qcom/Kconfig
>> @@ -0,0 +1,11 @@
>> +config INTERCONNECT_QCOM
>> + bool "Qualcomm Network-on-Chip interconnect drivers"
>> + depends on INTERCONNECT
>> + depends on ARCH_QCOM || COMPILE_TEST
>> +
>> +config INTERCONNECT_QCOM_SMD_RPM
>> + tristate "Qualcomm SMD RPM interconnect driver"
>> + depends on INTERCONNECT_QCOM
>
> Should this also depend on CONFIG_QCOM_SMD_RPM, since it uses
> qcom_rpm_smd_write?
Yes, you are right.
>> + help
>> + This is a driver for communicating interconnect related
>> configuration
>> + details with a remote processor (RPM) on Qualcomm platforms.
> ...
>> diff --git a/drivers/interconnect/qcom/smd-rpm.h
>> b/drivers/interconnect/qcom/smd-rpm.h
>> new file mode 100644
>> index ..c33b91a3dd51
>> --- /dev/null
>> +++ b/drivers/interconnect/qcom/smd-rpm.h
>> @@ -0,0 +1,15 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +/*
>> + * Copyright (c) 2018, Linaro Ltd.
>> + * Author: Georgi Djakov
>> + */
>> +
>> +#ifndef __DRIVERS_INTERCONNECT_QCOM_RPM_H
>> +#define __DRIVERS_INTERCONNECT_QCOM_RPM_H
>
> Nit: this still doesn't quite match, it would need an _SMD like:
> __DRIVERS_INTERCONNECT_QCOM_SMD_RPM_H
>
Ok, thanks!
Georgi
Re: [PATCH v6 6/8] interconnect: qcom: Add msm8916 interconnect provider driver
Hi Matthias,
On 07/10/2018 02:56 AM, Matthias Kaehlcke wrote:
> Hi,
>
> On Mon, Jul 09, 2018 at 06:51:02PM +0300, Georgi Djakov wrote:
>> Add driver for the Qualcomm interconnect buses found in msm8916 based
>> platforms.
>>
>> Signed-off-by: Georgi Djakov
>> ---
>> drivers/interconnect/Kconfig| 5 +
>> drivers/interconnect/Makefile | 1 +
>> drivers/interconnect/qcom/Kconfig | 10 +
>> drivers/interconnect/qcom/Makefile | 2 +
>> drivers/interconnect/qcom/msm8916.c | 499
>> 5 files changed, 517 insertions(+)
>> create mode 100644 drivers/interconnect/qcom/msm8916.c
>>
[..]
>> +/**
>> + * struct qcom_icc_node - Qualcomm specific interconnect nodes
>> + * @name: the node name used in debugfs
>> + * @links: an array of nodes where we can go next while traversing
>> + * @id: a unique node identifier
>
> nit: move up to keep 'links' and 'num_links' together? Also 'name' and
> 'id' are similar fields, so keeping them together makes sense.
Ok.
>> + * @num_links: the total number of @links
>> + * @port: the offset index into the masters QoS register space
>> + * @buswidth: width of the interconnect between a node and the bus (bytes)
>> + * @ap_owned: the AP CPU does the writing to QoS registers
>> + * @qos_mode: QoS mode for ap_owned resources
>> + * @mas_rpm_id: RPM id for devices that are bus masters
>> + * @slv_rpm_id: RPM id for devices that are bus slaves
>> + * @rate: current bus clock rate in Hz
>> + */
>> +struct qcom_icc_node {
>> +unsigned char *name;
>> +u16 links[MSM8916_MAX_LINKS];
>> +u16 id;
>> +u16 num_links;
>> +u16 port;
>> +u16 buswidth;
>> +bool ap_owned;
>> +enum qcom_qos_mode qos_mode;
>> +int mas_rpm_id;
>> +int slv_rpm_id;
>> +u64 rate;
>> +};
>> +
>> +struct qcom_icc_desc {
>> +struct qcom_icc_node **nodes;
>> +size_t num_nodes;
>> +};
>> +
>> +#define DEFINE_QNODE(_name, _id, _port, _buswidth, _ap_owned,
>> \
>> +_mas_rpm_id, _slv_rpm_id, _qos_mode,\
>> +_numlinks, ...) \
>> +static struct qcom_icc_node _name = { \
>> +.id = _id, \
>> +.name = #_name, \
>
> nit: init fields in same order as parameters.
Ok.
>> +.port = _port, \
>> +.buswidth = _buswidth, \
>> +.qos_mode = _qos_mode, \
>> +.ap_owned = _ap_owned, \
>> +.mas_rpm_id = _mas_rpm_id, \
>> +.slv_rpm_id = _slv_rpm_id, \
>> +.num_links = _numlinks, \
>> +.links = { __VA_ARGS__ }, \
>> +}
>> +
>> +DEFINE_QNODE(mas_video, MASTER_VIDEO_P0, 8, 16, 1, -1, -1,
>> QCOM_QOS_MODE_BYPASS, 2, SNOC_MM_INT_0, SNOC_MM_INT_2);
>> +DEFINE_QNODE(mas_jpeg, MASTER_JPEG, 6, 16, 1, -1, -1, QCOM_QOS_MODE_BYPASS,
>> 2, SNOC_MM_INT_0, SNOC_MM_INT_2);
>> +DEFINE_QNODE(mas_vfe, MASTER_VFE, 9, 16, 1, -1, -1, QCOM_QOS_MODE_BYPASS,
>> 2, SNOC_MM_INT_1, SNOC_MM_INT_2);
>> +DEFINE_QNODE(mas_mdp, MASTER_MDP_PORT0, 7, 16, 1, -1, -1,
>> QCOM_QOS_MODE_BYPASS, 2, SNOC_MM_INT_0, SNOC_MM_INT_2);
>> +DEFINE_QNODE(mas_qdss_bam, MASTER_QDSS_BAM, 11, 16, 1, -1, -1,
>> QCOM_QOS_MODE_FIXED, 1, SNOC_QDSS_INT);
>> +DEFINE_QNODE(mas_snoc_cfg, MASTER_SNOC_CFG, 0, 16, 0, 20, -1,
>> QCOM_QOS_MODE_BYPASS, 1, SNOC_QDSS_INT);
>> +DEFINE_QNODE(mas_qdss_etr, MASTER_QDSS_ETR, 10, 16, 1, -1, -1,
>> QCOM_QOS_MODE_FIXED, 1, SNOC_QDSS_INT);
>> +DEFINE_QNODE(mm_int_0, SNOC_MM_INT_0, 0, 16, 1, -1, -1,
>> QCOM_QOS_MODE_FIXED, 1, SNOC_MM_INT_BIMC);
>> +DEFINE_QNODE(mm_int_1, SNOC_MM_INT_1, 0, 16, 1, -1, -1,
>> QCOM_QOS_MODE_FIXED, 1, SNOC_MM_INT_BIMC);
>> +DEFINE_QNODE(mm_int_2, SNOC_MM_INT_2, 0, 16, 1, -1, -1,
>> QCOM_QOS_MODE_FIXED, 1, SNOC_INT_0);
>> +DEFINE_QNODE(mm_int_bimc, SNOC_MM_INT_BIMC, 0, 16, 1, -1, -1,
>> QCOM_QOS_MODE_FIXED, 1, SNOC_BIMC_1_MAS);
>> +DEFINE_QNODE(snoc_int_0, SNOC_INT_0, 0, 8, 0, 99, 130, QCOM_QOS_MODE_FIXED,
>> 3, SLAVE_QDSS_STM, SLAVE_SYSTEM_IMEM, MNOC_BIMC_MAS);
Re: [PATCH v6 6/8] interconnect: qcom: Add msm8916 interconnect provider driver
Hi, On 07/11/2018 01:34 AM, Evan Green wrote: > On Mon, Jul 9, 2018 at 8:51 AM Georgi Djakov wrote: >> >> Add driver for the Qualcomm interconnect buses found in msm8916 based >> platforms. >> >> Signed-off-by: Georgi Djakov >> --- >> drivers/interconnect/Kconfig| 5 + >> drivers/interconnect/Makefile | 1 + >> drivers/interconnect/qcom/Kconfig | 10 + >> drivers/interconnect/qcom/Makefile | 2 + >> drivers/interconnect/qcom/msm8916.c | 499 >> 5 files changed, 517 insertions(+) >> create mode 100644 drivers/interconnect/qcom/msm8916.c >> >> diff --git a/drivers/interconnect/Kconfig b/drivers/interconnect/Kconfig >> index a261c7d41deb..07a8276fa35a 100644 >> --- a/drivers/interconnect/Kconfig >> +++ b/drivers/interconnect/Kconfig >> @@ -8,3 +8,8 @@ menuconfig INTERCONNECT >> >> If unsure, say no. >> >> +if INTERCONNECT >> + >> +source "drivers/interconnect/qcom/Kconfig" >> + >> +endif >> diff --git a/drivers/interconnect/Makefile b/drivers/interconnect/Makefile >> index 97fca2e09d24..7944cbca0527 100644 >> --- a/drivers/interconnect/Makefile >> +++ b/drivers/interconnect/Makefile >> @@ -1,2 +1,3 @@ >> # SPDX-License-Identifier: GPL-2.0 >> obj-$(CONFIG_INTERCONNECT) += core.o >> +obj-$(CONFIG_INTERCONNECT_QCOM)+= qcom/ >> diff --git a/drivers/interconnect/qcom/Kconfig >> b/drivers/interconnect/qcom/Kconfig >> index b0c2ff928d88..a87afdef1bf7 100644 >> --- a/drivers/interconnect/qcom/Kconfig >> +++ b/drivers/interconnect/qcom/Kconfig >> @@ -2,6 +2,8 @@ config INTERCONNECT_QCOM >> bool "Qualcomm Network-on-Chip interconnect drivers" >> depends on INTERCONNECT >> depends on ARCH_QCOM || COMPILE_TEST >> + help >> + Support for Qualcomm's Network-on-Chip interconnect hardware. >> >> config INTERCONNECT_QCOM_SMD_RPM >> tristate "Qualcomm SMD RPM interconnect driver" >> @@ -9,3 +11,11 @@ config INTERCONNECT_QCOM_SMD_RPM >> help >> This is a driver for communicating interconnect related >> configuration >> details with a remote processor (RPM) on Qualcomm platforms. >> + >> +config INTERCONNECT_QCOM_MSM8916 >> + tristate "Qualcomm MSM8916 interconnect driver" >> + depends on INTERCONNECT_QCOM >> + select INTERCONNECT_QCOM_SMD_RPM > > I'm not a kconfig expert, maybe someone else could chime in. I have > this impression that folks don't like select. Is there a way to do > this with depends instead? If I'm way off here, ignore me. It could be done with depends, but i think that it would be easier for the user to choose only the SoC driver, without having to look into what dependencies need to be enabled for each. Here we are using select only locally and if there are any dependencies on other subsystems (like the QCOM_SMD_RPM), they should be put under the interconnect platform driver. Of course i am open for other arguments and suggestions. Thanks, Georgi
Re: [PATCH v6 6/8] interconnect: qcom: Add msm8916 interconnect provider driver
Hi Alexandre,
On 07/11/2018 06:42 PM, Alexandre Bailon wrote:
> On 07/09/2018 05:51 PM, Georgi Djakov wrote:
>> Add driver for the Qualcomm interconnect buses found in msm8916 based
>> platforms.
>>
>> Signed-off-by: Georgi Djakov
>> ---
>> drivers/interconnect/Kconfig| 5 +
>> drivers/interconnect/Makefile | 1 +
>> drivers/interconnect/qcom/Kconfig | 10 +
>> drivers/interconnect/qcom/Makefile | 2 +
>> drivers/interconnect/qcom/msm8916.c | 499
>> 5 files changed, 517 insertions(+)
>> create mode 100644 drivers/interconnect/qcom/msm8916>>
[..]
>> +static int qcom_icc_set(struct icc_node *src, struct icc_node *dst,
>> +u32 avg, u32 peak)
>> +{
>> +struct qcom_icc_provider *qp;
>> +struct qcom_icc_node *qn;
>> +struct icc_node *node;
>> +struct icc_provider *provider;
>> +u64 avg_bw = icc_units_to_bps(avg);
>> +u64 peak_bw = icc_units_to_bps(peak);
>> +u64 rate = 0;
>> +int ret = 0;
>> +
>> +if (!src)
> NIT: I think that src can't be NULL (there is a if statement to avoid it
> in apply_constraints()).
Yes, true!
Thanks,
Georgi
Re: [PATCH v6 7/8] dt-bindings: Introduce interconnect consumers bindings
Hi, On 07/11/2018 01:34 AM, Evan Green wrote: > On Mon, Jul 9, 2018 at 8:51 AM Georgi Djakov wrote: >> >> Add documentation for the interconnect consumer bindings, that will allow >> to link a device node (consumer) to its interconnect controller hardware. >> >> Tha aim is to enable drivers to request a framework API to configure an >> interconnect path by providing their struct device pointer and a name. >> >> Signed-off-by: Georgi Djakov >> --- >> .../bindings/interconnect/interconnect.txt| 27 +++ >> 1 file changed, 27 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/interconnect/interconnect.txt >> b/Documentation/devicetree/bindings/interconnect/interconnect.txt >> index 6e2b2971b094..0ad65dccbe8b 100644 >> --- a/Documentation/devicetree/bindings/interconnect/interconnect.txt >> +++ b/Documentation/devicetree/bindings/interconnect/interconnect.txt >> @@ -31,3 +31,30 @@ Example: >> clocks = <&rpmcc RPM_SMD_SNOC_CLK>, >> <&rpmcc RPM_SMD_SNOC_A_CLK>; >> }; >> + >> + >> += interconnect consumers = >> + >> +The interconnect consumers are device nodes which consume the interconnect >> +path(s) provided by the interconnect provider. There can be multiple > > I wonder if this sentence could be more descriptive. Maybe something like: > > The interconnect consumers are device nodes which dynamically express > their bandwidth requirements along interconnect paths they are > connected to. > > ...or choose a better one if this one's a mouthful. > This sounds much better. Thank you! Georgi
[PATCH v7 0/8] Introduce on-chip interconnect API
Evan) * Code cleanups. Fix typos. (Evan, Matthias) * Add the source node to the path. (Evan) * Rename path_allocate() to path_init() with minor refactoring. (Evan) * Rename *_remove() functions to *_destroy(). * Return fixed errors in icc_link_destroy(). (Evan) * Fix krealloc() usage in icc_link_destroy(). (Evan) * Add missing kfree() in icc_node_create(). (Matthias) * Make icc_node_add() return void. (Matthias) * Change mutex_init to mutex_lock in icc_provider_add(). (Matthias) * Add new icc_node_del() function to delete nodes from provider. * Fix the header guard to reflect the path in smd-rpm.h. (Evan) * Check for errors returned by qcom_icc_rpm_smd_send(). (Evan) * Propagate the error of icc_provider_del(). (Evan) Changes since patchset v4 (https://lkml.org/lkml/2018/3/9/856) * Simplified locking by using a single global mutex. (Evan) * Changed the aggregation function interface. * Implemented functions for node, link, provider removal. (Evan) * Naming changes on variables and functions, removed redundant code. (Evan) * Fixes and clarifications in the docs. (Matthias, Evan, Amit, Alexandre) * Removed mandatory reg DT property, made interconnect-names optional. (Bjorn) * Made interconnect-cells property required to align with other bindings. (Neil) * Moved msm8916 specific bindings into a separate file and patch. (Bjorn) * Use the names, instead of the hardcoded ids for topology. (Matthias) * Init the node before creating the links. (Evan) * Added icc_units_to_bps macro. (Amit) Changes since patchset v3 (https://lkml.org/lkml/2017/9/8/544) * Refactored the constraints aggregation. * Use the IDR API. * Split the provider and consumer bindings into separate patches and propose new bindings for consumers, which allows to specify the local source port. * Adopted the icc_ prefix for API functions. * Introduced separate API functions for creating interconnect nodes and links. * Added DT lookup support in addition to platform data. * Dropped the event tracing patch for now. * Added a patch to provide summary via debugfs. * Use macro for the list of topology definitions in the platform driver. * Various minor changes. Changes since patchset v2 (https://lkml.org/lkml/2017/7/20/825) * Split the aggregation into per node and per provider. Cache the aggregated values. * Various small refactorings and cleanups in the framework. * Added a patch introducing basic tracepoint support for monitoring the time required to update the interconnect nodes. Changes since patchset v1 (https://lkml.org/lkml/2017/6/27/890) * Updates in the documentation. * Changes in request aggregation, locking. * Dropped the aggregate() callback and use the default as it currently sufficient for the single vendor driver. Will add it later when needed. * Dropped the dt-bindings draft patch for now. Changes since RFC v2 (https://lkml.org/lkml/2017/6/12/316) * Converted documentation to rst format. * Fixed an incorrect call to mutex_lock. Renamed max_bw to peak_bw. Changes since RFC v1 (https://lkml.org/lkml/2017/5/15/605) * Refactored code into shorter functions. * Added a new aggregate() API function. * Rearranged some structs to reduce padding bytes. Changes since RFC v0 (https://lkml.org/lkml/2017/3/1/599) * Removed DT support and added optional Patch 3 with new bindings proposal. * Converted the topology into internal driver data. * Made the framework modular. * interconnect_get() now takes (src and dst ports as arguments). * Removed public declarations of some structs. * Now passing prev/next nodes to the vendor driver. * Properly remove requests on _put(). * Added refcounting. * Updated documentation. * Changed struct interconnect_path to use array instead of linked list. Georgi Djakov (8): interconnect: Add generic on-chip interconnect API dt-bindings: Introduce interconnect provider bindings interconnect: Add debugfs support interconnect: qcom: Add RPM communication dt-bindings: interconnect: Document qcom,msm8916 NoC bindings interconnect: qcom: Add msm8916 interconnect provider driver dt-bindings: Introduce interconnect consumers bindings interconnect: Allow endpoints translation via DT .../bindings/interconnect/interconnect.txt| 60 ++ .../bindings/interconnect/qcom-msm8916.txt| 39 + .../bindings/interconnect/qcom-smd.txt| 32 + Documentation/interconnect/interconnect.rst | 96 +++ drivers/Kconfig | 2 + drivers/Makefile | 1 + drivers/interconnect/Kconfig | 15 + drivers/interconnect/Makefile | 3 + drivers/interconnect/core.c | 709 ++ drivers/interconnect/qcom/Kconfig | 23 + drivers/interconnect/qcom/Makefile| 4 + drivers/interconnect/qcom/msm8916.c | 510 + drivers/interconnect/qcom/smd-rpm.c | 91 +++ drivers/interconnect/qcom/smd-rpm.h | 16 + include/dt-bindings/interconnect/qco
[PATCH v7 4/8] interconnect: qcom: Add RPM communication
On some Qualcomm SoCs, there is a remote processor, which controls some of
the Network-On-Chip interconnect resources. Other CPUs express their needs
by communicating with this processor. Add a driver to handle communication
with this remote processor.
Signed-off-by: Georgi Djakov
---
.../bindings/interconnect/qcom-smd.txt| 32 +++
drivers/interconnect/qcom/Kconfig | 14 +++
drivers/interconnect/qcom/Makefile| 2 +
drivers/interconnect/qcom/smd-rpm.c | 91 +++
drivers/interconnect/qcom/smd-rpm.h | 16
5 files changed, 155 insertions(+)
create mode 100644 Documentation/devicetree/bindings/interconnect/qcom-smd.txt
create mode 100644 drivers/interconnect/qcom/Kconfig
create mode 100644 drivers/interconnect/qcom/Makefile
create mode 100644 drivers/interconnect/qcom/smd-rpm.c
create mode 100644 drivers/interconnect/qcom/smd-rpm.h
diff --git a/Documentation/devicetree/bindings/interconnect/qcom-smd.txt
b/Documentation/devicetree/bindings/interconnect/qcom-smd.txt
new file mode 100644
index ..88a5aeb50935
--- /dev/null
+++ b/Documentation/devicetree/bindings/interconnect/qcom-smd.txt
@@ -0,0 +1,32 @@
+Qualcomm SMD-RPM interconnect driver binding
+
+The RPM (Resource Power Manager) is a dedicated hardware engine
+for managing the shared SoC resources in order to keep the lowest
+power profile. It communicates with other hardware subsystems via
+the shared memory driver (SMD) back-end and accepts requests for
+various resources.
+
+Required properties :
+- compatible : shall contain only one of the following:
+ "qcom,interconnect-smd-rpm"
+
+Example:
+ smd {
+ compatible = "qcom,smd";
+
+ rpm {
+ interrupts = <0 168 1>;
+ qcom,ipc = <&apcs 8 0>;
+ qcom,smd-edge = <15>;
+
+ rpm_requests {
+ compatible = "qcom,rpm-msm8916";
+ qcom,smd-channels = "rpm_requests";
+
+ interconnect-smd-rpm {
+ compatible =
"qcom,interconnect-smd-rpm";
+ };
+
+ };
+ };
+ };
diff --git a/drivers/interconnect/qcom/Kconfig
b/drivers/interconnect/qcom/Kconfig
new file mode 100644
index ..812e9464765a
--- /dev/null
+++ b/drivers/interconnect/qcom/Kconfig
@@ -0,0 +1,14 @@
+config INTERCONNECT_QCOM
+ bool "Qualcomm Network-on-Chip interconnect drivers"
+ depends on INTERCONNECT
+ depends on ARCH_QCOM || COMPILE_TEST
+ help
+ Support for Qualcomm's Network-on-Chip interconnect hardware.
+
+config INTERCONNECT_QCOM_SMD_RPM
+ tristate "Qualcomm SMD RPM interconnect driver"
+ depends on INTERCONNECT_QCOM
+ depends on QCOM_SMD_RPM
+ help
+ This is a driver for communicating interconnect related configuration
+ details with a remote processor (RPM) on Qualcomm platforms.
diff --git a/drivers/interconnect/qcom/Makefile
b/drivers/interconnect/qcom/Makefile
new file mode 100644
index ..5b65e4011b59
--- /dev/null
+++ b/drivers/interconnect/qcom/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_INTERCONNECT_QCOM_SMD_RPM) += smd-rpm.o
diff --git a/drivers/interconnect/qcom/smd-rpm.c
b/drivers/interconnect/qcom/smd-rpm.c
new file mode 100644
index ..48b7a2a6eb84
--- /dev/null
+++ b/drivers/interconnect/qcom/smd-rpm.c
@@ -0,0 +1,91 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * RPM over SMD communication wrapper for interconnects
+ *
+ * Copyright (C) 2018 Linaro Ltd
+ * Author: Georgi Djakov
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include "smd-rpm.h"
+
+#defineRPM_KEY_BW 0x7762
+
+static struct qcom_icc_rpm {
+ struct qcom_smd_rpm *rpm;
+} icc_rpm_smd;
+
+struct icc_rpm_smd_req {
+ __le32 key;
+ __le32 nbytes;
+ __le32 value;
+};
+
+bool qcom_icc_rpm_smd_available(void)
+{
+ if (!icc_rpm_smd.rpm)
+ return false;
+
+ return true;
+}
+EXPORT_SYMBOL_GPL(qcom_icc_rpm_smd_available);
+
+int qcom_icc_rpm_smd_send(int ctx, int rsc_type, int id, u32 val)
+{
+ struct icc_rpm_smd_req req = {
+ .key = cpu_to_le32(RPM_KEY_BW),
+ .nbytes = cpu_to_le32(sizeof(u32)),
+ .value = cpu_to_le32(val),
+ };
+
+ return qcom_rpm_smd_write(icc_rpm_smd.rpm, ctx, rsc_type, id, &req,
+ sizeof(req));
+}
+EXPORT_SYMBOL_GPL(qcom_icc_rpm_smd_send);
+
+static int qcom_icc_rpm_smd_probe(struct platform_device *pdev)
+{
+ icc_rpm_smd.rpm = dev_get_drvdata(pdev->de
[PATCH v7 3/8] interconnect: Add debugfs support
Add a functionality to provide information about the current constraints
per each node and provider.
Signed-off-by: Georgi Djakov
---
drivers/interconnect/core.c | 78 +
1 file changed, 78 insertions(+)
diff --git a/drivers/interconnect/core.c b/drivers/interconnect/core.c
index 1de4997bc75a..9fef180cf77e 100644
--- a/drivers/interconnect/core.c
+++ b/drivers/interconnect/core.c
@@ -6,6 +6,7 @@
* Author: Georgi Djakov
*/
+#include
#include
#include
#include
@@ -16,10 +17,12 @@
#include
#include
#include
+#include
static DEFINE_IDR(icc_idr);
static LIST_HEAD(icc_provider_list);
static DEFINE_MUTEX(icc_lock);
+static struct dentry *icc_debugfs_dir;
/**
* struct icc_req - constraints that are attached to each node
@@ -48,6 +51,62 @@ struct icc_path {
struct icc_req reqs[];
};
+#ifdef CONFIG_DEBUG_FS
+
+static void icc_summary_show_one(struct seq_file *s, struct icc_node *n)
+{
+ if (!n)
+ return;
+
+ seq_printf(s, "%-30s %12d %12d\n",
+ n->name, n->avg_bw, n->peak_bw);
+}
+
+static int icc_summary_show(struct seq_file *s, void *data)
+{
+ struct icc_provider *provider;
+
+ seq_puts(s, " node avg
peak\n");
+ seq_puts(s,
"\n");
+
+ mutex_lock(&icc_lock);
+
+ list_for_each_entry(provider, &icc_provider_list, provider_list) {
+ struct icc_node *n;
+
+ list_for_each_entry(n, &provider->nodes, node_list) {
+ struct icc_req *r;
+
+ icc_summary_show_one(s, n);
+ hlist_for_each_entry(r, &n->req_list, req_node) {
+ if (!r->dev)
+ continue;
+
+ seq_printf(s, "%-26s %12d %12d\n",
+ dev_name(r->dev), r->avg_bw,
+ r->peak_bw);
+ }
+ }
+ }
+
+ mutex_unlock(&icc_lock);
+
+ return 0;
+}
+
+static int icc_summary_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, icc_summary_show, inode->i_private);
+}
+
+static const struct file_operations icc_summary_fops = {
+ .open = icc_summary_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release= single_release,
+};
+#endif
+
static struct icc_node *node_find(const int id)
{
return idr_find(&icc_idr, id);
@@ -564,6 +623,25 @@ int icc_provider_del(struct icc_provider *provider)
}
EXPORT_SYMBOL_GPL(icc_provider_del);
+static int __init icc_init(void)
+{
+#ifdef CONFIG_DEBUG_FS
+ icc_debugfs_dir = debugfs_create_dir("interconnect", NULL);
+ debugfs_create_file("interconnect_summary", 0444,
+ icc_debugfs_dir, NULL, &icc_summary_fops);
+#endif
+ return 0;
+}
+
+static void __exit icc_exit(void)
+{
+#ifdef CONFIG_DEBUG_FS
+ debugfs_remove_recursive(icc_debugfs_dir);
+#endif
+}
+module_init(icc_init);
+module_exit(icc_exit);
+
MODULE_AUTHOR("Georgi Djakov
[PATCH v7 7/8] dt-bindings: Introduce interconnect consumers bindings
Add documentation for the interconnect consumer bindings, that will allow
to link a device node (consumer) to its interconnect controller hardware.
Tha aim is to enable drivers to request a framework API to configure an
interconnect path by providing their struct device pointer and a name.
Signed-off-by: Georgi Djakov
---
.../bindings/interconnect/interconnect.txt| 27 +++
1 file changed, 27 insertions(+)
diff --git a/Documentation/devicetree/bindings/interconnect/interconnect.txt
b/Documentation/devicetree/bindings/interconnect/interconnect.txt
index 6e2b2971b094..5cb7d3c8d44d 100644
--- a/Documentation/devicetree/bindings/interconnect/interconnect.txt
+++ b/Documentation/devicetree/bindings/interconnect/interconnect.txt
@@ -31,3 +31,30 @@ Example:
clocks = <&rpmcc RPM_SMD_SNOC_CLK>,
<&rpmcc RPM_SMD_SNOC_A_CLK>;
};
+
+
+= interconnect consumers =
+
+The interconnect consumers are device nodes which dynamically express their
+bandwidth requirements along interconnect paths they are connected to. There
+can be multiple interconnect providers on a SoC and the consumer may consume
+multiple paths from different providers depending on use case and the
+components it has to interact with.
+
+Required properties:
+interconnects : Pairs of phandles and interconnect provider specifier to denote
+ the edge source and destination ports of the interconnect path.
+
+Optional properties:
+interconnect-names : List of interconnect path name strings sorted in the same
+order as the interconnects property. Consumers drivers
will use
+interconnect-names to match interconnect paths with
interconnect
+specifiers.
+
+Example:
+
+ sdhci@7864000 {
+ ...
+ interconnects = <&pnoc MASTER_SDCC_1 &bimc SLAVE_EBI_CH0>;
+ interconnect-names = "ddr";
+ };
[PATCH v7 8/8] interconnect: Allow endpoints translation via DT
Currently we support only platform data for specifying the interconnect
endpoints. As now the endpoints are hard-coded into the consumer driver
this may lead to complications when a single driver is used by multiple
SoCs, which may have different interconnect topology.
To avoid cluttering the consumer drivers, introduce a translation function
to help us get the board specific interconnect data from device-tree.
Signed-off-by: Georgi Djakov
---
drivers/interconnect/core.c | 62
include/linux/interconnect.h | 7
2 files changed, 69 insertions(+)
diff --git a/drivers/interconnect/core.c b/drivers/interconnect/core.c
index 9fef180cf77e..d1b6adff0a3d 100644
--- a/drivers/interconnect/core.c
+++ b/drivers/interconnect/core.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include
@@ -251,6 +252,67 @@ static int apply_constraints(struct icc_path *path)
return ret;
}
+struct icc_path *of_icc_get(struct device *dev, const char *name)
+{
+ struct device_node *np = NULL;
+ struct of_phandle_args src_args, dst_args;
+ u32 src_id, dst_id;
+ int idx = 0;
+ int ret;
+
+ if (!dev || !dev->of_node)
+ return ERR_PTR(-ENODEV);
+
+ np = dev->of_node;
+
+ /*
+* When the consumer DT node do not have "interconnects" property
+* return a NULL path to skip setting constraints.
+*/
+ if (!of_find_property(np, "interconnects", NULL))
+ return NULL;
+
+ /*
+* We use a combination of phandle and specifier for endpoint. For now
+* lets support only global ids and extend this is the future if needed
+* without breaking DT compatibility.
+*/
+ if (name) {
+ idx = of_property_match_string(np, "interconnect-names", name);
+ if (idx < 0)
+ return ERR_PTR(idx);
+ }
+
+ ret = of_parse_phandle_with_args(np, "interconnects",
+"#interconnect-cells", idx * 2,
+&src_args);
+ if (ret)
+ return ERR_PTR(ret);
+
+ of_node_put(src_args.np);
+
+ if (!src_args.args_count || src_args.args_count > 1)
+ return ERR_PTR(-EINVAL);
+
+ src_id = src_args.args[0];
+
+ ret = of_parse_phandle_with_args(np, "interconnects",
+"#interconnect-cells", idx * 2 + 1,
+&dst_args);
+ if (ret)
+ return ERR_PTR(ret);
+
+ of_node_put(dst_args.np);
+
+ if (!dst_args.args_count || dst_args.args_count > 1)
+ return ERR_PTR(-EINVAL);
+
+ dst_id = dst_args.args[0];
+
+ return icc_get(dev, src_id, dst_id);
+}
+EXPORT_SYMBOL_GPL(of_icc_get);
+
/**
* icc_set() - set constraints on an interconnect path between two endpoints
* @path: reference to the path returned by icc_get()
diff --git a/include/linux/interconnect.h b/include/linux/interconnect.h
index 593215371fd6..ae6744da9bc2 100644
--- a/include/linux/interconnect.h
+++ b/include/linux/interconnect.h
@@ -17,6 +17,7 @@ struct device;
struct icc_path *icc_get(struct device *dev, const int src_id,
const int dst_id);
+struct icc_path *of_icc_get(struct device *dev, const char *name);
void icc_put(struct icc_path *path);
int icc_set(struct icc_path *path, u32 avg_bw, u32 peak_bw);
@@ -28,6 +29,12 @@ static inline struct icc_path *icc_get(struct device *dev,
const int src_id,
return NULL;
}
+static inline struct icc_path *of_icc_get(struct device *dev,
+ const char *name)
+{
+ return NULL;
+}
+
static inline void icc_put(struct icc_path *path)
{
}
[PATCH v7 1/8] interconnect: Add generic on-chip interconnect API
This patch introduces a new API to get requirements and configure the interconnect buses across the entire chipset to fit with the current demand. The API is using a consumer/provider-based model, where the providers are the interconnect buses and the consumers could be various drivers. The consumers request interconnect resources (path) between endpoints and set the desired constraints on this data flow path. The providers receive requests from consumers and aggregate these requests for all master-slave pairs on that path. Then the providers configure each participating in the topology node according to the requested data flow path, physical links and constraints. The topology could be complicated and multi-tiered and is SoC specific. Signed-off-by: Georgi Djakov --- Documentation/interconnect/interconnect.rst | 96 drivers/Kconfig | 2 + drivers/Makefile| 1 + drivers/interconnect/Kconfig| 10 + drivers/interconnect/Makefile | 2 + drivers/interconnect/core.c | 569 include/linux/interconnect-provider.h | 125 + include/linux/interconnect.h| 42 ++ 8 files changed, 847 insertions(+) create mode 100644 Documentation/interconnect/interconnect.rst create mode 100644 drivers/interconnect/Kconfig create mode 100644 drivers/interconnect/Makefile create mode 100644 drivers/interconnect/core.c create mode 100644 include/linux/interconnect-provider.h create mode 100644 include/linux/interconnect.h diff --git a/Documentation/interconnect/interconnect.rst b/Documentation/interconnect/interconnect.rst new file mode 100644 index ..e628881ee218 --- /dev/null +++ b/Documentation/interconnect/interconnect.rst @@ -0,0 +1,96 @@ +.. SPDX-License-Identifier: GPL-2.0 + += +GENERIC SYSTEM INTERCONNECT SUBSYSTEM += + +Introduction + + +This framework is designed to provide a standard kernel interface to control +the settings of the interconnects on a SoC. These settings can be throughput, +latency and priority between multiple interconnected devices or functional +blocks. This can be controlled dynamically in order to save power or provide +maximum performance. + +The interconnect bus is a hardware with configurable parameters, which can be +set on a data path according to the requests received from various drivers. +An example of interconnect buses are the interconnects between various +components or functional blocks in chipsets. There can be multiple interconnects +on a SoC that can be multi-tiered. + +Below is a simplified diagram of a real-world SoC interconnect bus topology. + +:: + + ++++ + | HW Accelerator |--->| M NoC |<---+ + ++++| + | |++ + +-+ +-+ V +--+ || + | DDR | |++ | PCIe | || + +-+ || Slaves | +--+ || +^ ^|++ | | C NoC| +| |V V || + +--+ ++ || +-+ + | |-->||-->||-->| CPU | + | |-->||<--|| +-+ + | Mem NoC | | S NoC | ++ + | |<--||-+| + | |<--||<--+ || ++ + +--+ ++ | |+-->| Slaves | + ^ ^^^ ^ | |++ + | ||| | | V + +--+ | +-+ +-+ +-+ ++ ++ + | CPUs | | | GPU | | DSP | | Masters |-->| P NoC|-->| Slaves | + +--+ | +-+ +-+ +-+ ++ ++ + | + +---+ + | Modem | + +---+ + +Terminology +--- + +Interconnect provider is the software definition of the interconnect hardware. +The interconnect providers on the above diagram are M NoC, S NoC, C NoC, P NoC +and Mem NoC. + +Interconnect node is the software definition of the interconnect hardware +port. Each interconnect provider consists of multiple interconnect nodes, +which are connected to other SoC components including other interconnect +providers. The point on the diagram where the CPUs connect to the memory is +called an interconnect node, which belongs to the Mem NoC interconnect provider. + +Interconnect endpoin
[PATCH v7 6/8] interconnect: qcom: Add msm8916 interconnect provider driver
Add driver for the Qualcomm interconnect buses found in msm8916 based
platforms.
Signed-off-by: Georgi Djakov
---
drivers/interconnect/Kconfig| 5 +
drivers/interconnect/Makefile | 1 +
drivers/interconnect/qcom/Kconfig | 9 +
drivers/interconnect/qcom/Makefile | 2 +
drivers/interconnect/qcom/msm8916.c | 510
5 files changed, 527 insertions(+)
create mode 100644 drivers/interconnect/qcom/msm8916.c
diff --git a/drivers/interconnect/Kconfig b/drivers/interconnect/Kconfig
index a261c7d41deb..07a8276fa35a 100644
--- a/drivers/interconnect/Kconfig
+++ b/drivers/interconnect/Kconfig
@@ -8,3 +8,8 @@ menuconfig INTERCONNECT
If unsure, say no.
+if INTERCONNECT
+
+source "drivers/interconnect/qcom/Kconfig"
+
+endif
diff --git a/drivers/interconnect/Makefile b/drivers/interconnect/Makefile
index 97fca2e09d24..7944cbca0527 100644
--- a/drivers/interconnect/Makefile
+++ b/drivers/interconnect/Makefile
@@ -1,2 +1,3 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_INTERCONNECT) += core.o
+obj-$(CONFIG_INTERCONNECT_QCOM)+= qcom/
diff --git a/drivers/interconnect/qcom/Kconfig
b/drivers/interconnect/qcom/Kconfig
index 812e9464765a..add6d7e1e24e 100644
--- a/drivers/interconnect/qcom/Kconfig
+++ b/drivers/interconnect/qcom/Kconfig
@@ -12,3 +12,12 @@ config INTERCONNECT_QCOM_SMD_RPM
help
This is a driver for communicating interconnect related configuration
details with a remote processor (RPM) on Qualcomm platforms.
+
+config INTERCONNECT_QCOM_MSM8916
+ tristate "Qualcomm MSM8916 interconnect driver"
+ depends on INTERCONNECT_QCOM
+ depends on QCOM_SMD_RPM
+ select INTERCONNECT_QCOM_SMD_RPM
+ help
+ This is a driver for the Qualcomm Network-on-Chip on msm8916-based
+ platforms.
diff --git a/drivers/interconnect/qcom/Makefile
b/drivers/interconnect/qcom/Makefile
index 5b65e4011b59..53f3380277f6 100644
--- a/drivers/interconnect/qcom/Makefile
+++ b/drivers/interconnect/qcom/Makefile
@@ -1,2 +1,4 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_INTERCONNECT_QCOM_SMD_RPM) += smd-rpm.o
+
+obj-$(CONFIG_INTERCONNECT_QCOM_MSM8916) += msm8916.o
diff --git a/drivers/interconnect/qcom/msm8916.c
b/drivers/interconnect/qcom/msm8916.c
new file mode 100644
index ..74145f4f74f1
--- /dev/null
+++ b/drivers/interconnect/qcom/msm8916.c
@@ -0,0 +1,510 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 Linaro Ltd
+ * Author: Georgi Djakov
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "smd-rpm.h"
+
+#define RPM_BUS_MASTER_REQ 0x73616d62
+#define RPM_BUS_SLAVE_REQ 0x766c7362
+
+#define to_qcom_provider(_provider) \
+ container_of(_provider, struct qcom_icc_provider, provider)
+
+enum qcom_qos_mode {
+ QCOM_QOS_MODE_BYPASS = 0,
+ QCOM_QOS_MODE_FIXED,
+ QCOM_QOS_MODE_MAX,
+};
+
+struct qcom_icc_provider {
+ struct icc_provider provider;
+ void __iomem*base;
+ struct clk *bus_clk;
+ struct clk *bus_a_clk;
+};
+
+#define MSM8916_MAX_LINKS 8
+
+/**
+ * struct qcom_icc_node - Qualcomm specific interconnect nodes
+ * @name: the node name used in debugfs
+ * @id: a unique node identifier
+ * @links: an array of nodes where we can go next while traversing
+ * @num_links: the total number of @links
+ * @port: the offset index into the masters QoS register space
+ * @buswidth: width of the interconnect between a node and the bus (bytes)
+ * @ap_owned: the AP CPU does the writing to QoS registers
+ * @qos_mode: QoS mode for ap_owned resources
+ * @mas_rpm_id:RPM id for devices that are bus masters
+ * @slv_rpm_id:RPM id for devices that are bus slaves
+ * @rate: current bus clock rate in Hz
+ */
+struct qcom_icc_node {
+ unsigned char *name;
+ u16 id;
+ u16 links[MSM8916_MAX_LINKS];
+ u16 num_links;
+ u16 port;
+ u16 buswidth;
+ bool ap_owned;
+ enum qcom_qos_mode qos_mode;
+ int mas_rpm_id;
+ int slv_rpm_id;
+ u64 rate;
+};
+
+struct qcom_icc_desc {
+ struct qcom_icc_node **nodes;
+ size_t num_nodes;
+};
+
+#define DEFINE_QNODE(_name, _id, _port, _buswidth, _ap_owned, \
+ _mas_rpm_id, _slv_rpm_id, _qos_mode,\
+ _numlinks, ...) \
+ static struct qcom_icc_node _name = { \
+ .name = #_name, \
+ .id = _id, \
+ .port = _port, \
+ .buswidth = _buswidth, \
+
[PATCH v7 2/8] dt-bindings: Introduce interconnect provider bindings
This binding is intended to represent the interconnect hardware present
in some of the modern SoCs. Currently it consists only of a binding for
the interconnect hardware devices (provider).
Signed-off-by: Georgi Djakov
---
.../bindings/interconnect/interconnect.txt| 33 +++
1 file changed, 33 insertions(+)
create mode 100644
Documentation/devicetree/bindings/interconnect/interconnect.txt
diff --git a/Documentation/devicetree/bindings/interconnect/interconnect.txt
b/Documentation/devicetree/bindings/interconnect/interconnect.txt
new file mode 100644
index ..6e2b2971b094
--- /dev/null
+++ b/Documentation/devicetree/bindings/interconnect/interconnect.txt
@@ -0,0 +1,33 @@
+Interconnect Provider Device Tree Bindings
+=
+
+The purpose of this document is to define a common set of generic interconnect
+providers/consumers properties.
+
+
+= interconnect providers =
+
+The interconnect provider binding is intended to represent the interconnect
+controllers in the system. Each provider registers a set of interconnect
+nodes, which expose the interconnect related capabilities of the interconnect
+to consumer drivers. These capabilities can be throughput, latency, priority
+etc. The consumer drivers set constraints on interconnect path (or endpoints)
+depending on the use case. Interconnect providers can also be interconnect
+consumers, such as in the case where two network-on-chip fabrics interface
+directly
+
+Required properties:
+- compatible : contains the interconnect provider compatible string
+- #interconnect-cells : number of cells in a interconnect specifier needed to
+ encode the interconnect node id
+
+Example:
+
+ snoc: snoc@58 {
+ compatible = "qcom,msm8916-snoc";
+ #interconnect-cells = <1>;
+ reg = <0x58 0x14000>;
+ clock-names = "bus_clk", "bus_a_clk";
+ clocks = <&rpmcc RPM_SMD_SNOC_CLK>,
+<&rpmcc RPM_SMD_SNOC_A_CLK>;
+ };
[PATCH v7 5/8] dt-bindings: interconnect: Document qcom,msm8916 NoC bindings
Document the device-tree bindings Network-On-Chip interconnect driver
for Qualcomm msm8916 platforms.
Signed-off-by: Georgi Djakov
---
.../bindings/interconnect/qcom-msm8916.txt| 39
include/dt-bindings/interconnect/qcom.h | 187 ++
2 files changed, 226 insertions(+)
create mode 100644
Documentation/devicetree/bindings/interconnect/qcom-msm8916.txt
create mode 100644 include/dt-bindings/interconnect/qcom.h
diff --git a/Documentation/devicetree/bindings/interconnect/qcom-msm8916.txt
b/Documentation/devicetree/bindings/interconnect/qcom-msm8916.txt
new file mode 100644
index ..f309eaed3d19
--- /dev/null
+++ b/Documentation/devicetree/bindings/interconnect/qcom-msm8916.txt
@@ -0,0 +1,39 @@
+Qualcomm MSM8916 Network-On-Chip interconnect driver binding
+
+
+Required properties :
+- compatible : shall contain only one of the following:
+ "qcom,msm8916-bimc"
+ "qcom,msm8916-pnoc"
+ "qcom,msm8916-snoc"
+- #interconnect-cells : should contain 1
+- reg : shall contain base register location and length
+
+Optional properties :
+clocks : list of phandles and specifiers to all interconnect bus clocks
+clock-names : clock names should include both "bus_clk" and "bus_a_clk"
+
+Examples:
+
+ snoc: snoc@58 {
+ compatible = "qcom,msm8916-snoc";
+ #interconnect-cells = <1>;
+ reg = <0x58 0x14000>;
+ clock-names = "bus_clk", "bus_a_clk";
+ clocks = <&rpmcc RPM_SMD_SNOC_CLK>, <&rpmcc
RPM_SMD_SNOC_A_CLK>;
+ };
+ bimc: bimc@40 {
+ compatible = "qcom,msm8916-bimc";
+ #interconnect-cells = <1>;
+ reg = <0x40 0x62000>;
+ clock-names = "bus_clk", "bus_a_clk";
+ clocks = <&rpmcc RPM_SMD_BIMC_CLK>, <&rpmcc
RPM_SMD_BIMC_A_CLK>;
+ };
+ pnoc: pnoc@50 {
+ compatible = "qcom,msm8916-pnoc";
+ #interconnect-cells = <1>;
+ reg = <0x50 0x11000>;
+ clock-names = "bus_clk", "bus_a_clk";
+ clocks = <&rpmcc RPM_SMD_PCNOC_CLK>, <&rpmcc
RPM_SMD_PCNOC_A_CLK>;
+ };
+
diff --git a/include/dt-bindings/interconnect/qcom.h
b/include/dt-bindings/interconnect/qcom.h
new file mode 100644
index 0000..2177a216e17e
--- /dev/null
+++ b/include/dt-bindings/interconnect/qcom.h
@@ -0,0 +1,187 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Qualcomm interconnect IDs
+ *
+ * Copyright (c) 2018, Linaro Ltd.
+ * Author: Georgi Djakov
+ */
+
+#ifndef __QCOM_INTERCONNECT_IDS_H
+#define __QCOM_INTERCONNECT_IDS_H
+
+#define MASTER_AMPSS_M0 1
+#define MASTER_AMPSS_M1 2
+#define MASTER_LPASS_PROC 11
+#define MASTER_MSS_PROCI 12
+#define MASTER_MSS_PROCD 13
+#define MASTER_MSS_MDM_PORT0 14
+#define MASTER_LPASS 15
+#define MASTER_MDP_PORT0 22
+#define MASTER_MDP_PORT1 23
+#define MASTER_ROTATOR 25
+#define MASTER_GRAPHICS_3D 26
+#define MASTER_VFE 29
+#define MASTER_SPDM 36
+#define MASTER_PCIE 45
+#define MASTER_CRYPTO 47
+#define MASTER_QDSS_BAM 53
+#define MASTER_SNOC_CFG 54
+#define MASTER_CRYPTO_CORE0 55
+#define MASTER_OCMEM_DMA 58
+#define MASTER_QDSS_ETR 60
+#define MASTER_USB3 61
+#define MASTER_JPEG 62
+#define MASTER_VIDEO_P0 63
+#define MASTER_VIDEO_P1 64
+#define MASTER_JPEG_OCMEM 66
+#define MASTER_VIDEO_P0_OCMEM 68
+#define MASTER_DEHR 75
+#define MASTER_QDSS_DAP 76
+#define MASTER_TIC 77
+#define MASTER_SDCC_1 78
+#define MASTER_SDCC_2 81
+#define MASTER_TSIF 82
+#define MASTER_BLSP_2 84
+#define MASTER_BLSP_1 86
+#define MASTER_USB_HS 87
+#define MASTER_IPA 90
+#define MASTER_UFS 95
+#define MASTER_PCIE_1 100
+#define MASTER_USB3_1 101
+#define MASTER_CNOC_MNOC_MMSS_CFG 102
+#define MASTER_CNOC_MNOC_CFG 103
+#define MASTER_TCU_0 104
+#define MASTER_TCU_1 105
+#define MASTER_CPP 106
+
+#define SNOC_MM_INT_0 1
+#define SNOC_MM_INT_1 10001
+#define SNOC_MM_INT_2 10002
+#define SNOC_MM_INT_BIMC 10003
+#define SNOC_INT_0 10004
+#define SNOC_INT_1 10005
+#define SNOC_INT_BIMC 10006
+#define SNOC_BIMC_0_MAS 10007
+#define SNOC_BIMC_1_MAS 10008
+#define SNOC_QDSS_INT 10009
+#define PNOC_SNOC_MAS 10010
+#define PNOC_SNOC_SLV 10011
+#define PNOC_INT_0 10012
+#define PNOC_INT_1 10013
+#define PNOC_M_0 10014
+#define PNOC_M_1 10015
+#define BIMC_SNOC_MAS 10016
+#define BIMC_SNOC_SLV 10017
+#define PNOC_SLV_0 10018
+#define PNOC_SLV_1 10019
+#define PNOC_SLV_2 10020
+#define PNOC_SLV_3 10021
+#define PNOC_SLV_4 10022
+#
Re: [PATCH v7 1/8] interconnect: Add generic on-chip interconnect API
Hi Randy, On 08/02/2018 03:05 AM, Randy Dunlap wrote: > On 07/31/2018 09:13 AM, Georgi Djakov wrote: >> This patch introduces a new API to get requirements and configure the >> interconnect buses across the entire chipset to fit with the current >> demand. >> >> The API is using a consumer/provider-based model, where the providers are >> the interconnect buses and the consumers could be various drivers. >> The consumers request interconnect resources (path) between endpoints and >> set the desired constraints on this data flow path. The providers receive >> requests from consumers and aggregate these requests for all master-slave >> pairs on that path. Then the providers configure each participating in the >> topology node according to the requested data flow path, physical links and >> constraints. The topology could be complicated and multi-tiered and is SoC >> specific. >> >> Signed-off-by: Georgi Djakov >> --- >> Documentation/interconnect/interconnect.rst | 96 >> drivers/Kconfig | 2 + >> drivers/Makefile| 1 + >> drivers/interconnect/Kconfig| 10 + >> drivers/interconnect/Makefile | 2 + >> drivers/interconnect/core.c | 569 >> include/linux/interconnect-provider.h | 125 + >> include/linux/interconnect.h| 42 ++ >> 8 files changed, 847 insertions(+) >> create mode 100644 Documentation/interconnect/interconnect.rst >> create mode 100644 drivers/interconnect/Kconfig >> create mode 100644 drivers/interconnect/Makefile >> create mode 100644 drivers/interconnect/core.c >> create mode 100644 include/linux/interconnect-provider.h >> create mode 100644 include/linux/interconnect.h >> >> diff --git a/Documentation/interconnect/interconnect.rst >> b/Documentation/interconnect/interconnect.rst >> new file mode 100644 >> index ..e628881ee218 >> --- /dev/null >> +++ b/Documentation/interconnect/interconnect.rst >> @@ -0,0 +1,96 @@ >> +.. SPDX-License-Identifier: GPL-2.0 >> + >> += >> +GENERIC SYSTEM INTERCONNECT SUBSYSTEM >> += >> + >> +Introduction >> + >> + >> +This framework is designed to provide a standard kernel interface to control >> +the settings of the interconnects on a SoC. These settings can be >> throughput, > > I would say: on an SoC. > > Do you pronounce that as "sock" or the letters S.O.C.? Ah right indeed, this should be based on the phonetics and not the writing. >> +latency and priority between multiple interconnected devices or functional >> +blocks. This can be controlled dynamically in order to save power or provide >> +maximum performance. >> + >> +The interconnect bus is a hardware with configurable parameters, which can >> be > > bus is hardware Ok. >> +set on a data path according to the requests received from various drivers. >> +An example of interconnect buses are the interconnects between various >> +components or functional blocks in chipsets. There can be multiple >> interconnects >> +on a SoC that can be multi-tiered. > > an SoC > >> + >> +Below is a simplified diagram of a real-world SoC interconnect bus topology. >> + >> +:: >> + >> + ++++ >> + | HW Accelerator |--->| M NoC |<---+ >> + ++++| >> + | |++ >> + +-+ +-+ V +--+ || >> + | DDR | |++ | PCIe | || >> + +-+ || Slaves | +--+ || >> +^ ^|++ | | C NoC| >> +| |V V || >> + +--+ ++ || >> +-+ >> + | |-->||-->||-->| CPU >> | >> + | |-->||<--|| >> +-+ >> + | Mem NoC | | S NoC | ++ >> + | |<--||-+| >> + | |<--||<--+
Re: [PATCH v7 8/8] interconnect: Allow endpoints translation via DT
Hi Saravana,
On 08/02/2018 01:57 AM, skan...@codeaurora.org wrote:
> On 2018-07-31 09:13, Georgi Djakov wrote:
>> Currently we support only platform data for specifying the interconnect
>> endpoints. As now the endpoints are hard-coded into the consumer driver
>> this may lead to complications when a single driver is used by multiple
>> SoCs, which may have different interconnect topology.
>> To avoid cluttering the consumer drivers, introduce a translation
>> function
>> to help us get the board specific interconnect data from device-tree.
>>
>> Signed-off-by: Georgi Djakov
>> ---
>>  drivers/interconnect/core.c | 62
>> Â include/linux/interconnect.h |Â 7
>> Â 2 files changed, 69 insertions(+)
>>
>> diff --git a/drivers/interconnect/core.c b/drivers/interconnect/core.c
>> index 9fef180cf77e..d1b6adff0a3d 100644
>> --- a/drivers/interconnect/core.c
>> +++ b/drivers/interconnect/core.c
[..]
>> --- a/include/linux/interconnect.h
>> +++ b/include/linux/interconnect.h
>> @@ -17,6 +17,7 @@ struct device;
>>
>> Â struct icc_path *icc_get(struct device *dev, const int src_id,
>> Â const int dst_id);
>> +struct icc_path *of_icc_get(struct device *dev, const char *name);
>> Â void icc_put(struct icc_path *path);
>> Â int icc_set(struct icc_path *path, u32 avg_bw, u32 peak_bw);
>>
>> @@ -28,6 +29,12 @@ static inline struct icc_path *icc_get(struct
>> device *dev, const int src_id,
>> return NULL;
>> Â }
>>
>> +static inline struct icc_path *of_icc_get(struct device *dev,
>> +Â const char *name)
>> +{
>> +Â Â Â return NULL;
>> +}
>> +
>
> Might want to return PTR(-ENODEV) or some error code so that client
> doesn't have to do NULL check AND an error check?
>
> -Saravana
NULL is returned when CONFIG_INTERCONNECT=n. Configuration of
interconnects by consumer drivers could be optional and that's why null
is returned instead of an error. The consumer drivers decide how to
proceed in this case and if there is a hard requirement for interconnect
support, then i would suggest to express it as a dependency in Kconfig.
Thanks,
Georgi
Re: [PATCH v3 2/2] PM / devfreq: Add devfreq driver for interconnect bandwidth voting
Hi MyungJoo, On 08/02/2018 01:13 PM, MyungJoo Ham wrote: >> This driver registers itself as a devfreq device that allows devfreq >> governors to make bandwidth votes for an interconnect path. This allows >> applying various policies for different interconnect paths using devfreq >> governors. >> > > First of all, the name, "devfreq_icbw", is not appropriate for a > devfreq device driver. It confuses; it looks like a part of the > framework itself. > >> diff --git a/drivers/devfreq/devfreq_icbw.c b/drivers/devfreq/devfreq_icbw.c >> new file mode 100644 >> index 000..231fb21 >> --- /dev/null >> +++ b/drivers/devfreq/devfreq_icbw.c >> @@ -0,0 +1,116 @@ >> +// SPDX-License-Identifier: GPL-2.0 >> +/* >> + * Copyright (c) 2013-2014, 2018, The Linux Foundation. All rights reserved. >> + */ >> + >> +#define pr_fmt(fmt) "icbw: " fmt >> + >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include > > Where can I find this file? It is part of the On-chip interconnect API, which is currently under review and is available here: https://lkml.org/lkml/2018/7/31/647 Thanks, Georgi
[PATCH] arm64: defconfig: Switch to the correct Qualcomm SMD driver
The SMD driver is migrated to a new RPMSG-based one and the old
driver was removed with:
commit 395a48053af6 ("soc: qcom: smd: Remove standalone driver")
However in defconfig we still have the old driver leaving the
SMD-regulator driver with unsatisfied dependencies. The result
is that the SMD-regulator driver is not compiled and the apq8016
boards could not probe their onboard storage and mount rootfs.
Fix this by switching to the new SMD driver, so that the required
driver is compiled again.
Reported-by: Leo Yan
Signed-off-by: Georgi Djakov
---
arch/arm64/configs/defconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index ce072859e3b2..08f6f96057d4 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -470,9 +470,9 @@ CONFIG_BCM2835_MBOX=y
CONFIG_HI6220_MBOX=y
CONFIG_ARM_SMMU=y
CONFIG_ARM_SMMU_V3=y
+CONFIG_RPMSG_QCOM_SMD=y
CONFIG_RASPBERRYPI_POWER=y
CONFIG_QCOM_SMEM=y
-CONFIG_QCOM_SMD=y
CONFIG_QCOM_SMD_RPM=y
CONFIG_ROCKCHIP_PM_DOMAINS=y
CONFIG_ARCH_TEGRA_132_SOC=y
Re: [PATCH v11 2/6] mailbox: qcom: Create APCS child device for clock controller
Hi Jassi, On 01/27/2018 05:44 AM, Jassi Brar wrote: > On Thu, Jan 4, 2018 at 10:26 PM, Georgi Djakov > wrote: >> Hi Jassi, >> >> On 12/29/2017 08:14 AM, Jassi Brar wrote: >>> Hi Bjorn, >>> >>> On Sun, Dec 24, 2017 at 10:36 AM, Bjorn Andersson >>> wrote: >>>> On Fri 22 Dec 20:57 PST 2017, Jassi Brar wrote: >>>> >>>>> On Tue, Dec 5, 2017 at 9:16 PM, Georgi Djakov >>>>> wrote: >>>>>> There is a clock controller functionality provided by the APCS hardware >>>>>> block of msm8916 devices. The device-tree would represent an APCS node >>>>>> with both mailbox and clock provider properties. >>>>>> >>>>> The spec might depict a 'clock' box and 'mailbox' box inside the >>>>> bigger APCS box. However, from the code I see in this patchset, they >>>>> are orthogonal and can & should be represented as independent DT >>>>> nodes. >>>> >>>> The APCS consists of a number of different hardware blocks, one of them >>>> being the "APCS global" block, which is what this node and drivers >>>> relate to. On 8916 this contains both the IPC register and clock >>>> control. But it's still just one block according to the hardware >>>> specification. >>>> >>>> As such DT should describe the one hardware block by one node IMHO. >>>> >>> In my even humbler opinion, DT should describe a h/w functional unit >>> which _could_ be seen as a standalone component. >> >> The APCS is one separate register block related to the CPU cluster. I >> haven't seen any strict guidelines for such cases in the DT docs, and >> during the discussion got the impression that this is the preferred >> binding. Rob has also reviewed the binding, so we should be fine to move >> forward with this one. >> > Well, I can't overrule Rob. But I am really not happy with random > device spawning from mailbox drivers. I know there are such instances > already in the kernel but that doesn't make it legit... unless there > is some hard dependency. Is there? The dependency is that on this SoC, these functionalities are combined into this "CPU subsystem" block. Initially APCS was a syscon and it was discussed it an year ago in this mail thread [1] and we are trying to move away from the syscon and come up with some bindings. During v8 and v9 of this patchset i have switched from multiple child nodes to a single node as this seem to be the preferred form. >>> For example, if this APCS had a mac controller, would we also populate >>> a netdev from mailbox driver? And what if next revision moves/drops >>> this clock controller out of APCS, keeping mailbox controller exactly >>> same? >> >> The clock controller may change in some next SoC architecture and that's >> why the SoC version is also part of the the compatible string. >> > So the mailbox driver will be updated to spawn yet another type of clock? > And again for next revision and so on... I know that is unlikely but > the point is why not have separate clock drivers for independent h/w > clocks? Each revision re-shuffles the APCS block, so at least the offsets would be different. I don't see anything bad with spawning a child device, but what are the other options? Should we go back on the bindings and suggest something new all over again? Or do you have any other idea? Could you please explain your point further? Thanks, Georgi [1] https://lkml.org/lkml/2017/3/20/991
Re: [PATCH v11 2/6] mailbox: qcom: Create APCS child device for clock controller
On 02/01/2018 08:57 AM, Jassi Brar wrote: > On Thu, Feb 1, 2018 at 12:10 AM, Georgi Djakov > wrote: >> >> Hi Jassi, >> >> On 01/27/2018 05:44 AM, Jassi Brar wrote: >>> On Thu, Jan 4, 2018 at 10:26 PM, Georgi Djakov >>> wrote: >>>> Hi Jassi, >>>> >>>> On 12/29/2017 08:14 AM, Jassi Brar wrote: >>>>> Hi Bjorn, >>>>> >>>>> On Sun, Dec 24, 2017 at 10:36 AM, Bjorn Andersson >>>>> wrote: >>>>>> On Fri 22 Dec 20:57 PST 2017, Jassi Brar wrote: >>>>>> >>>>>>> On Tue, Dec 5, 2017 at 9:16 PM, Georgi Djakov >>>>>>> wrote: >>>>>>>> There is a clock controller functionality provided by the APCS hardware >>>>>>>> block of msm8916 devices. The device-tree would represent an APCS node >>>>>>>> with both mailbox and clock provider properties. >>>>>>>> >>>>>>> The spec might depict a 'clock' box and 'mailbox' box inside the >>>>>>> bigger APCS box. However, from the code I see in this patchset, they >>>>>>> are orthogonal and can & should be represented as independent DT >>>>>>> nodes. >>>>>> >>>>>> The APCS consists of a number of different hardware blocks, one of them >>>>>> being the "APCS global" block, which is what this node and drivers >>>>>> relate to. On 8916 this contains both the IPC register and clock >>>>>> control. But it's still just one block according to the hardware >>>>>> specification. >>>>>> >>>>>> As such DT should describe the one hardware block by one node IMHO. >>>>>> >>>>> In my even humbler opinion, DT should describe a h/w functional unit >>>>> which _could_ be seen as a standalone component. >>>> >>>> The APCS is one separate register block related to the CPU cluster. I >>>> haven't seen any strict guidelines for such cases in the DT docs, and >>>> during the discussion got the impression that this is the preferred >>>> binding. Rob has also reviewed the binding, so we should be fine to move >>>> forward with this one. >>>> >>> Well, I can't overrule Rob. But I am really not happy with random >>> device spawning from mailbox drivers. I know there are such instances >>> already in the kernel but that doesn't make it legit... unless there >>> is some hard dependency. Is there? >> >> The dependency is that on this SoC, these functionalities are combined >> into this "CPU subsystem" block. >> > I see the register space is shared between mailbox and the clock. So I > guess, yes, simply creating a device here and passing the common > regmap is tidier. Which patches are already picked up? Patches 3, 4 and 6 are already picked into the clk tree. Still pending are patches 1, 2 and 5. Thanks, Georgi
Re: [PATCH v11 2/6] mailbox: qcom: Create APCS child device for clock controller
Hi Jassi, On 12/29/2017 08:14 AM, Jassi Brar wrote: > Hi Bjorn, > > On Sun, Dec 24, 2017 at 10:36 AM, Bjorn Andersson > wrote: >> On Fri 22 Dec 20:57 PST 2017, Jassi Brar wrote: >> >>> On Tue, Dec 5, 2017 at 9:16 PM, Georgi Djakov >>> wrote: >>>> There is a clock controller functionality provided by the APCS hardware >>>> block of msm8916 devices. The device-tree would represent an APCS node >>>> with both mailbox and clock provider properties. >>>> >>> The spec might depict a 'clock' box and 'mailbox' box inside the >>> bigger APCS box. However, from the code I see in this patchset, they >>> are orthogonal and can & should be represented as independent DT >>> nodes. >> >> The APCS consists of a number of different hardware blocks, one of them >> being the "APCS global" block, which is what this node and drivers >> relate to. On 8916 this contains both the IPC register and clock >> control. But it's still just one block according to the hardware >> specification. >> >> As such DT should describe the one hardware block by one node IMHO. >> > In my even humbler opinion, DT should describe a h/w functional unit > which _could_ be seen as a standalone component. The APCS is one separate register block related to the CPU cluster. I haven't seen any strict guidelines for such cases in the DT docs, and during the discussion got the impression that this is the preferred binding. Rob has also reviewed the binding, so we should be fine to move forward with this one. > For example, if this APCS had a mac controller, would we also populate > a netdev from mailbox driver? And what if next revision moves/drops > this clock controller out of APCS, keeping mailbox controller exactly > same? The clock controller may change in some next SoC architecture and that's why the SoC version is also part of the the compatible string. Thanks, Georgi
Re: [PATCH v11 0/6] Add support for Qualcomm A53 CPU clock
On 12/05/2017 05:46 PM, Georgi Djakov wrote: > This patchset adds support for the A53 CPU clock on MSM8916 platforms > and allows scaling of the CPU frequency on msm8916 based platforms. > > Changes since v10 (https://lkml.org/lkml/2017/12/1/577) > * Addressed Bjorn's comments on APCS clock driver. > * Picked Acks from Rob and Bjorn. > [..] > > Georgi Djakov (6): > mailbox: qcom: Convert APCS IPC driver to use regmap > mailbox: qcom: Create APCS child device for clock controller > clk: qcom: Add A53 PLL support > clk: qcom: Add regmap mux-div clocks support > dt-bindings: mailbox: qcom: Document the APCS clock binding > clk: qcom: Add APCS clock controller support > Hi Jassi, Do you want me to re-send the pending mailbox patches? Thanks, Georgi
[PATCH v4 6/7] dt-bindings: Introduce interconnect consumers bindings
Add documentation for the interconnect consumer bindings, that will allow
to link a device node (consumer) to its interconnect controller hardware.
Tha aim is to enable drivers to request a framework API to configure an
interconnect path by providing their struct device pointer and a name.
Signed-off-by: Georgi Djakov
---
.../bindings/interconnect/interconnect.txt | 23 ++
1 file changed, 23 insertions(+)
diff --git a/Documentation/devicetree/bindings/interconnect/interconnect.txt
b/Documentation/devicetree/bindings/interconnect/interconnect.txt
index 70612bb201e4..7935abf10c4b 100644
--- a/Documentation/devicetree/bindings/interconnect/interconnect.txt
+++ b/Documentation/devicetree/bindings/interconnect/interconnect.txt
@@ -45,3 +45,26 @@ Examples:
status = "okay";
};
+= interconnect consumers =
+
+The interconnect consumers are device nodes which consume the interconnect
+path(s) provided by the interconnect provider. There can be multiple
+interconnect providers on a SoC and the consumer may consume multiple paths
+from different providers depending on usecase and the components it has to
+interact with.
+
+Required-properties:
+interconnects: Pairs of phandles and interconnect provider specifier to denote
+ the source and the destination port of the interconnect path.
+interconnect-names: List of interconnect path name strings sorted in the same
+ order as the interconnects property. Consumers drivers will use
+ interconnect-names to match interconnect paths with interconnect
+ specifiers.
+
+Example:
+
+ sdhci@7864000 {
+ ...
+ interconnects = <&pnoc 78 &bimc 512>
+ interconnect-names = "memory";
+ };
[PATCH v4 7/7] interconnect: Allow endpoints translation via DT
Currently we support only platform data for specifying the interconnect
endpoints. As now the endpoints are hard-coded into the consumer driver
this may leed to complications when a single driver is used by multiple
SoCs, which may have different interconnect topology.
To avoid cluttering the consumer drivers, introduce a translation function
to help us get the board specific interconnect data from device-tree.
Signed-off-by: Georgi Djakov
---
drivers/interconnect/core.c | 38 ++
include/linux/interconnect.h | 6 ++
2 files changed, 44 insertions(+)
diff --git a/drivers/interconnect/core.c b/drivers/interconnect/core.c
index a06f752a6aaa..014993473763 100644
--- a/drivers/interconnect/core.c
+++ b/drivers/interconnect/core.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
static DEFINE_IDR(icc_idr);
@@ -297,6 +298,43 @@ static int constraints_apply(struct icc_path *path)
return 0;
}
+struct icc_path *of_icc_get(struct device *dev, const char *name)
+{
+ struct device_node *np;
+ u32 src_id, dst_id;
+ int index, ret;
+
+ if (!dev || !name)
+ return NULL;
+
+ np = dev->of_node;
+
+ index = of_property_match_string(np, "interconnect-names", name);
+ if (index < 0)
+ return ERR_PTR(index);
+
+ /*
+* We use a combination of phandle and specifier for endpoint. For now
+* lets support only global ids and extend this is the future if needed
+* without breaking DT compatibility.
+*/
+ ret = of_property_read_u32_index(np, "interconnects", index * 2 + 1,
+&src_id);
+ if (ret) {
+ dev_err(dev, "interconnect src port is invalid (%d)\n", ret);
+ return ERR_PTR(ret);
+ }
+ ret = of_property_read_u32_index(np, "interconnects", index * 2 + 3,
+&dst_id);
+ if (ret) {
+ dev_err(dev, "interconnect dst port is invalid (%d)\n", ret);
+ return ERR_PTR(ret);
+ }
+
+ return icc_get(src_id, dst_id);
+}
+EXPORT_SYMBOL_GPL(of_icc_get);
+
/**
* icc_set() - set constraints on an interconnect path between two endpoints
* @path: reference to the path returned by icc_get()
diff --git a/include/linux/interconnect.h b/include/linux/interconnect.h
index 5a7cf72b76a5..996c48ea67d5 100644
--- a/include/linux/interconnect.h
+++ b/include/linux/interconnect.h
@@ -16,6 +16,7 @@ struct device;
#if IS_ENABLED(CONFIG_INTERCONNECT)
struct icc_path *icc_get(const int src_id, const int dst_id);
+struct icc_path *of_icc_get(struct device *dev, const char *name);
void icc_put(struct icc_path *path);
int icc_set(struct icc_path *path, u32 avg_bw, u32 peak_bw);
@@ -26,6 +27,11 @@ static inline struct icc_path *icc_get(const int src_id,
const int dst_id)
return NULL;
}
+static inline struct icc_path *of_icc_get(struct device *dev, const char *name)
+{
+ return NULL;
+}
+
static inline void icc_put(struct icc_path *path)
{
}
[PATCH v4 5/7] interconnect: qcom: Add msm8916 interconnect provider driver
Add driver for the Qualcomm interconnect buses found in msm8916 based
platforms.
Signed-off-by: Georgi Djakov
---
drivers/interconnect/Kconfig| 5 +
drivers/interconnect/Makefile | 1 +
drivers/interconnect/qcom/Kconfig | 11 +
drivers/interconnect/qcom/Makefile | 2 +
drivers/interconnect/qcom/msm8916.c | 482
include/linux/interconnect/qcom.h | 350 ++
6 files changed, 851 insertions(+)
create mode 100644 drivers/interconnect/qcom/Kconfig
create mode 100644 drivers/interconnect/qcom/msm8916.c
create mode 100644 include/linux/interconnect/qcom.h
diff --git a/drivers/interconnect/Kconfig b/drivers/interconnect/Kconfig
index a261c7d41deb..07a8276fa35a 100644
--- a/drivers/interconnect/Kconfig
+++ b/drivers/interconnect/Kconfig
@@ -8,3 +8,8 @@ menuconfig INTERCONNECT
If unsure, say no.
+if INTERCONNECT
+
+source "drivers/interconnect/qcom/Kconfig"
+
+endif
diff --git a/drivers/interconnect/Makefile b/drivers/interconnect/Makefile
index 5edf0ae80818..5971b811c2d7 100644
--- a/drivers/interconnect/Makefile
+++ b/drivers/interconnect/Makefile
@@ -1 +1,2 @@
obj-$(CONFIG_INTERCONNECT) += core.o
+obj-$(CONFIG_INTERCONNECT_QCOM)+= qcom/
diff --git a/drivers/interconnect/qcom/Kconfig
b/drivers/interconnect/qcom/Kconfig
new file mode 100644
index ..86465dc37bd4
--- /dev/null
+++ b/drivers/interconnect/qcom/Kconfig
@@ -0,0 +1,11 @@
+config INTERCONNECT_QCOM
+ bool "Qualcomm Network-on-Chip interconnect drivers"
+ depends on INTERCONNECT
+ depends on ARCH_QCOM || COMPILE_TEST
+ default y
+
+config INTERCONNECT_QCOM_MSM8916
+ tristate "Qualcomm MSM8916 interconnect driver"
+ depends on INTERCONNECT_QCOM
+ help
+ This is a driver for the Qualcomm Network-on-Chip on msm8916-based
platforms.
diff --git a/drivers/interconnect/qcom/Makefile
b/drivers/interconnect/qcom/Makefile
index 095bdef1ee6e..a0c13a25e8db 100644
--- a/drivers/interconnect/qcom/Makefile
+++ b/drivers/interconnect/qcom/Makefile
@@ -1 +1,3 @@
obj-y += smd-rpm.o
+
+obj-$(CONFIG_INTERCONNECT_QCOM_MSM8916) += msm8916.o
diff --git a/drivers/interconnect/qcom/msm8916.c
b/drivers/interconnect/qcom/msm8916.c
new file mode 100644
index ..d5b54f8261c8
--- /dev/null
+++ b/drivers/interconnect/qcom/msm8916.c
@@ -0,0 +1,482 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 Linaro Ltd
+ * Author: Georgi Djakov
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "smd-rpm.h"
+
+#define RPM_MASTER_FIELD_BW0x7762
+#define RPM_BUS_MASTER_REQ 0x73616d62
+#define RPM_BUS_SLAVE_REQ 0x766c7362
+
+#define to_qcom_provider(_provider) \
+ container_of(_provider, struct qcom_icc_provider, provider)
+
+#define DEFINE_QNODE(_name, _id, _port, _buswidth, _ap_owned, \
+ _mas_rpm_id, _slv_rpm_id, _qos_mode,\
+ _numlinks, ...) \
+ static struct qcom_icc_node _name = { \
+ .id = _id, \
+ .name = #_name, \
+ .port = _port, \
+ .buswidth = _buswidth, \
+ .qos_mode = _qos_mode, \
+ .ap_owned = _ap_owned, \
+ .mas_rpm_id = _mas_rpm_id, \
+ .slv_rpm_id = _slv_rpm_id, \
+ .num_links = _numlinks, \
+ .links = { __VA_ARGS__ }, \
+ }
+
+enum qcom_qos_mode {
+ QCOM_QOS_MODE_BYPASS = 0,
+ QCOM_QOS_MODE_FIXED,
+ QCOM_QOS_MODE_MAX,
+};
+
+struct qcom_icc_provider {
+ struct icc_provider provider;
+ void __iomem*base;
+ struct clk *bus_clk;
+ struct clk *bus_a_clk;
+};
+
+#define MSM8916_MAX_LINKS 8
+
+/**
+ * struct qcom_icc_node - Qualcomm specific interconnect nodes
+ * @name: the node name used in debugfs
+ * @links: an array of nodes where we can go next while traversing
+ * @id: a unique node identifier
+ * @num_links: the total number of @links
+ * @port: the offset index into the masters QoS register space
+ * @buswidth: width of the interconnect between a node and the bus
+ * @ap_owned: the AP CPU does the writing to QoS registers
+ * @rpm: reference to the RPM SMD driver
+ * @qos_mode: QoS mode for ap_owned resources
+ * @mas_rpm_id:RPM id for devices that are bus masters
+ * @slv_rpm_id:RPM id for devices th
[PATCH v4 4/7] interconnect: qcom: Add RPM communication
On some Qualcomm SoCs, there is a remote processor, which controls some of
the Network-On-Chip interconnect resources. Other CPUs express their needs
by communicating with this processor. Add a driver to handle comminication
with this remote processor.
Signed-off-by: Georgi Djakov
---
.../devicetree/bindings/interconnect/qcom-smd.txt | 31
drivers/interconnect/qcom/Makefile | 1 +
drivers/interconnect/qcom/smd-rpm.c| 90 ++
drivers/interconnect/qcom/smd-rpm.h| 15
4 files changed, 137 insertions(+)
create mode 100644 Documentation/devicetree/bindings/interconnect/qcom-smd.txt
create mode 100644 drivers/interconnect/qcom/Makefile
create mode 100644 drivers/interconnect/qcom/smd-rpm.c
create mode 100644 drivers/interconnect/qcom/smd-rpm.h
diff --git a/Documentation/devicetree/bindings/interconnect/qcom-smd.txt
b/Documentation/devicetree/bindings/interconnect/qcom-smd.txt
new file mode 100644
index ..14e83ed7019b
--- /dev/null
+++ b/Documentation/devicetree/bindings/interconnect/qcom-smd.txt
@@ -0,0 +1,31 @@
+Qualcomm SMD-RPM interconnect driver binding
+
+The RPM is a dedicated hardware engine for managing the shared
+SoC resources in order to keep the lowest power profile. It
+communicates with other hardware subsystems via shared memory
+and accepts requests for various resources.
+
+Required properties :
+- compatible : shall contain only one of the following:
+ "qcom,interconnect-smd-rpm"
+
+Example:
+ smd {
+ compatible = "qcom,smd";
+
+ rpm {
+ interrupts = <0 168 1>;
+ qcom,ipc = <&apcs 8 0>;
+ qcom,smd-edge = <15>;
+
+ rpm_requests {
+ compatible = "qcom,rpm-msm8916";
+ qcom,smd-channels = "rpm_requests";
+
+ interconnect-smd-rpm {
+ compatible =
"qcom,interconnect-smd-rpm";
+ };
+
+ };
+ };
+ };
diff --git a/drivers/interconnect/qcom/Makefile
b/drivers/interconnect/qcom/Makefile
new file mode 100644
index ..095bdef1ee6e
--- /dev/null
+++ b/drivers/interconnect/qcom/Makefile
@@ -0,0 +1 @@
+obj-y += smd-rpm.o
diff --git a/drivers/interconnect/qcom/smd-rpm.c
b/drivers/interconnect/qcom/smd-rpm.c
new file mode 100644
index ..0cf772f51642
--- /dev/null
+++ b/drivers/interconnect/qcom/smd-rpm.c
@@ -0,0 +1,90 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * RPM over SMD communication wrapper for interconects
+ *
+ * Copyright (C) 2018 Linaro Ltd
+ * Author: Georgi Djakov
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include "smd-rpm.h"
+
+#defineRPM_KEY_BW 0x7762
+
+static struct qcom_icc_rpm {
+ struct qcom_smd_rpm *rpm;
+} icc_rpm_smd;
+
+struct icc_rpm_smd_req {
+ __le32 key;
+ __le32 nbytes;
+ __le32 value;
+};
+
+bool qcom_icc_rpm_smd_available(void)
+{
+ if (!icc_rpm_smd.rpm)
+ return false;
+
+ return true;
+}
+
+int qcom_icc_rpm_smd_send(int ctx, int rsc_type, int id, u32 val)
+{
+ struct icc_rpm_smd_req req = {
+ .key = cpu_to_le32(RPM_KEY_BW),
+ .nbytes = cpu_to_le32(sizeof(u32)),
+ .value = cpu_to_le32(val),
+ };
+
+ return qcom_rpm_smd_write(icc_rpm_smd.rpm, ctx, rsc_type, id, &req,
+ sizeof(req));
+}
+EXPORT_SYMBOL(qcom_icc_rpm_smd_send);
+
+static int qcom_icc_rpm_smd_probe(struct platform_device *pdev)
+{
+ icc_rpm_smd.rpm = dev_get_drvdata(pdev->dev.parent);
+ if (!icc_rpm_smd.rpm) {
+ dev_err(&pdev->dev, "unable to retrieve handle to RPM\n");
+ return -ENODEV;
+ }
+
+ return 0;
+}
+
+static const struct of_device_id qcom_icc_rpm_smd_dt_match[] = {
+ { .compatible = "qcom,interconnect-smd-rpm", },
+ { },
+};
+
+MODULE_DEVICE_TABLE(of, qcom_interconnect_rpm_smd_dt_match);
+
+static struct platform_driver qcom_interconnect_rpm_smd_driver = {
+ .driver = {
+ .name = "qcom-interconnect-smd-rpm",
+ .of_match_table = qcom_icc_rpm_smd_dt_match,
+ },
+ .probe = qcom_icc_rpm_smd_probe,
+};
+
+static int __init rpm_smd_interconnect_init(void)
+{
+ return platform_driver_register(&qcom_interconnect_rpm_smd_driver);
+}
+subsys_initcall(rpm_smd_interconnect_init);
+
+static void __exit rpm_smd_interconnect_exit(void)
+{
+ platform_driver_unregister(&qcom_interconnect_rpm_smd_driver);
+}
+module_exit(rpm_smd_interconnect_exit)
+
+MODULE_
[PATCH v4 2/7] dt-bindings: Introduce interconnect provider bindings
This binding is intended to represent the interconnect hardware present
in some of the modern SoCs. Currently it consists only of a binding for
the interconnect hardware devices (provider).
Signed-off-by: Georgi Djakov
---
.../bindings/interconnect/interconnect.txt | 47 ++
1 file changed, 47 insertions(+)
create mode 100644
Documentation/devicetree/bindings/interconnect/interconnect.txt
diff --git a/Documentation/devicetree/bindings/interconnect/interconnect.txt
b/Documentation/devicetree/bindings/interconnect/interconnect.txt
new file mode 100644
index ..70612bb201e4
--- /dev/null
+++ b/Documentation/devicetree/bindings/interconnect/interconnect.txt
@@ -0,0 +1,47 @@
+Interconnect Provider Device Tree Bindings
+=
+
+The purpose of this document is to define a common set of generic interconnect
+providers/consumers properties.
+
+
+= interconnect providers =
+
+The interconnect provider binding is intended to represent the interconnect
+controllers in the system. Each provider registers a set of interconnect
+nodes, which expose the interconnect related capabilities of the interconnect
+to consumer drivers. These capabilities can be throughput, latency, priority
+etc. The consumer drivers set constraints on interconnect path (or endpoints)
+depending on the usecase. Interconnect providers can also be interconnect
+consumers, such as in the case where two network-on-chip fabrics interface
+directly
+
+Required properties:
+- compatible : contains the interconnect provider vendor specific compatible
+ string
+- reg : register space of the interconnect controller hardware
+
+Examples:
+
+ snoc: snoc@58 {
+ compatible = "qcom,msm8916-snoc";
+ reg = <0x58 0x14000>;
+ clock-names = "bus_clk", "bus_a_clk";
+ clocks = <&rpmcc RPM_SMD_SNOC_CLK>, <&rpmcc
RPM_SMD_SNOC_A_CLK>;
+ status = "okay";
+ };
+ bimc: bimc@40 {
+ compatible = "qcom,msm8916-bimc";
+ reg = <0x40 0x62000>;
+ clock-names = "bus_clk", "bus_a_clk";
+ clocks = <&rpmcc RPM_SMD_BIMC_CLK>, <&rpmcc
RPM_SMD_BIMC_A_CLK>;
+ status = "okay";
+ };
+ pnoc: pnoc@50 {
+ compatible = "qcom,msm8916-pnoc";
+ reg = <0x50 0x11000>;
+ clock-names = "bus_clk", "bus_a_clk";
+ clocks = <&rpmcc RPM_SMD_PCNOC_CLK>, <&rpmcc
RPM_SMD_PCNOC_A_CLK>;
+ status = "okay";
+ };
+
[PATCH v4 3/7] interconnect: Add debugfs support
Add a functionality to provide information about the current constraints
per each node and provider.
Signed-off-by: Georgi Djakov
---
drivers/interconnect/core.c | 70 +
1 file changed, 70 insertions(+)
diff --git a/drivers/interconnect/core.c b/drivers/interconnect/core.c
index 6306e258b9b9..a06f752a6aaa 100644
--- a/drivers/interconnect/core.c
+++ b/drivers/interconnect/core.c
@@ -6,6 +6,7 @@
* Author: Georgi Djakov
*/
+#include
#include
#include
#include
@@ -15,11 +16,13 @@
#include
#include
#include
+#include
static DEFINE_IDR(icc_idr);
static LIST_HEAD(icc_provider_list);
static DEFINE_MUTEX(icc_provider_list_mutex);
static DEFINE_MUTEX(icc_path_mutex);
+static struct dentry *icc_debugfs_dir;
/**
* struct icc_req - constraints that are attached to each node
@@ -46,6 +49,73 @@ struct icc_path {
struct icc_req reqs[0];
};
+#ifdef CONFIG_DEBUG_FS
+
+static void icc_summary_show_one(struct seq_file *s, struct icc_node *n)
+{
+ if (!n)
+ return;
+
+ seq_printf(s, "%-30s %12d %12d\n",
+ n->name, n->avg_bw, n->peak_bw);
+}
+
+static int icc_summary_show(struct seq_file *s, void *data)
+{
+ struct icc_provider *provider;
+
+ seq_puts(s, " node avg
peak\n");
+ seq_puts(s,
"\n");
+
+ mutex_lock(&icc_provider_list_mutex);
+
+ list_for_each_entry(provider, &icc_provider_list, provider_list) {
+ struct icc_node *n;
+
+ mutex_lock(&provider->lock);
+ list_for_each_entry(n, &provider->nodes, node_list) {
+ icc_summary_show_one(s, n);
+ }
+ mutex_unlock(&provider->lock);
+ }
+
+ mutex_unlock(&icc_provider_list_mutex);
+
+ return 0;
+}
+
+static int icc_summary_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, icc_summary_show, inode->i_private);
+}
+
+static const struct file_operations icc_summary_fops = {
+ .open = icc_summary_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release= single_release,
+};
+
+static int __init icc_debugfs_init(void)
+{
+ struct dentry *file;
+
+ icc_debugfs_dir = debugfs_create_dir("interconnect", NULL);
+ if (!icc_debugfs_dir) {
+ pr_err("interconnect: error creating debugfs directory\n");
+ return -ENODEV;
+ }
+
+ file = debugfs_create_file("interconnect_summary", 0444,
+ icc_debugfs_dir, NULL, &icc_summary_fops);
+ if (!file)
+ return -ENODEV;
+
+ return 0;
+}
+late_initcall(icc_debugfs_init);
+#endif
+
static struct icc_node *node_find(const int id)
{
struct icc_node *node;
[PATCH v4 0/7] Introduce on-chip interconnect API
* Dropped the aggregate() callback and use the default as it currently sufficient for the single vendor driver. Will add it later when needed. * Dropped the dt-bindings draft patch for now. Changes since RFC v2 (https://lkml.org/lkml/2017/6/12/316) * Converted documentation to rst format. * Fixed an incorrect call to mutex_lock. Renamed max_bw to peak_bw. Changes since RFC v1 (https://lkml.org/lkml/2017/5/15/605) * Refactored code into shorter functions. * Added a new aggregate() API function. * Rearranged some structs to reduce padding bytes. Changes since RFC v0 (https://lkml.org/lkml/2017/3/1/599) * Removed DT support and added optional Patch 3 with new bindings proposal. * Converted the topology into internal driver data. * Made the framework modular. * interconnect_get() now takes (src and dst ports as arguments). * Removed public declarations of some structs. * Now passing prev/next nodes to the vendor driver. * Properly remove requests on _put(). * Added refcounting. * Updated documentation. * Changed struct interconnect_path to use array instead of linked list. Georgi Djakov (7): interconnect: Add generic on-chip interconnect API dt-bindings: Introduce interconnect provider bindings interconnect: Add debugfs support interconnect: qcom: Add RPM communication interconnect: qcom: Add msm8916 interconnect provider driver dt-bindings: Introduce interconnect consumers bindings interconnect: Allow endpoints translation via DT .../bindings/interconnect/interconnect.txt | 70 +++ .../devicetree/bindings/interconnect/qcom-smd.txt | 31 ++ Documentation/interconnect/interconnect.rst| 96 drivers/Kconfig| 2 + drivers/Makefile | 1 + drivers/interconnect/Kconfig | 15 + drivers/interconnect/Makefile | 2 + drivers/interconnect/core.c| 597 + drivers/interconnect/qcom/Kconfig | 11 + drivers/interconnect/qcom/Makefile | 3 + drivers/interconnect/qcom/msm8916.c| 482 + drivers/interconnect/qcom/smd-rpm.c| 90 drivers/interconnect/qcom/smd-rpm.h| 15 + include/linux/interconnect-provider.h | 109 include/linux/interconnect.h | 46 ++ include/linux/interconnect/qcom.h | 350 16 files changed, 1920 insertions(+) create mode 100644 Documentation/devicetree/bindings/interconnect/interconnect.txt create mode 100644 Documentation/devicetree/bindings/interconnect/qcom-smd.txt create mode 100644 Documentation/interconnect/interconnect.rst create mode 100644 drivers/interconnect/Kconfig create mode 100644 drivers/interconnect/Makefile create mode 100644 drivers/interconnect/core.c create mode 100644 drivers/interconnect/qcom/Kconfig create mode 100644 drivers/interconnect/qcom/Makefile create mode 100644 drivers/interconnect/qcom/msm8916.c create mode 100644 drivers/interconnect/qcom/smd-rpm.c create mode 100644 drivers/interconnect/qcom/smd-rpm.h create mode 100644 include/linux/interconnect-provider.h create mode 100644 include/linux/interconnect.h create mode 100644 include/linux/interconnect/qcom.h
[PATCH v4 1/7] interconnect: Add generic on-chip interconnect API
This patch introduce a new API to get requirements and configure the interconnect buses across the entire chipset to fit with the current demand. The API is using a consumer/provider-based model, where the providers are the interconnect buses and the consumers could be various drivers. The consumers request interconnect resources (path) between endpoints and set the desired constraints on this data flow path. The providers receive requests from consumers and aggregate these requests for all master-slave pairs on that path. Then the providers configure each participating in the topology node according to the requested data flow path, physical links and constraints. The topology could be complicated and multi-tiered and is SoC specific. Signed-off-by: Georgi Djakov --- Documentation/interconnect/interconnect.rst | 96 ++ drivers/Kconfig | 2 + drivers/Makefile| 1 + drivers/interconnect/Kconfig| 10 + drivers/interconnect/Makefile | 1 + drivers/interconnect/core.c | 489 include/linux/interconnect-provider.h | 109 +++ include/linux/interconnect.h| 40 +++ 8 files changed, 748 insertions(+) create mode 100644 Documentation/interconnect/interconnect.rst create mode 100644 drivers/interconnect/Kconfig create mode 100644 drivers/interconnect/Makefile create mode 100644 drivers/interconnect/core.c create mode 100644 include/linux/interconnect-provider.h create mode 100644 include/linux/interconnect.h diff --git a/Documentation/interconnect/interconnect.rst b/Documentation/interconnect/interconnect.rst new file mode 100644 index ..23eba68e8424 --- /dev/null +++ b/Documentation/interconnect/interconnect.rst @@ -0,0 +1,96 @@ +.. SPDX-License-Identifier: GPL-2.0 + += +GENERIC SYSTEM INTERCONNECT SUBSYSTEM += + +Introduction + + +This framework is designed to provide a standard kernel interface to control +the settings of the interconnects on a SoC. These settings can be throughput, +latency and priority between multiple interconnected devices or functional +blocks. This can be controlled dynamically in order to save power or provide +maximum performance. + +The interconnect bus is a hardware with configurable parameters, which can be +set on a data path according to the requests received from various drivers. +An example of interconnect buses are the interconnects between various +components or functional blocks in chipsets. There can be multiple interconnects +on a SoC that can be multi-tiered. + +Below is a simplified diagram of a real-world SoC interconnect bus topology. + +:: + + ++++ + | HW Accelerator |--->| M NoC |<---+ + ++++| + | |++ + +-+ +-+ V +--+ || + | DDR | |++ | PCIe | || + +-+ || Slaves | +--+ || +^ ^|++ | | C NoC| +| |V V || + +--+ ++ || +-+ + | |-->||-->||-->| CPU | + | |-->||<--|| +-+ + | Mem NoC | | S NoC | ++ + | |<--||-+| + | |<--||<--+ || ++ + +--+ ++ | |+-->| Slaves | + ^ ^^^ ^ | |++ + | ||| | | V + +--+ | +-+ +-+ +-+ ++ ++ + | CPUs | | | GPU | | DSP | | Masters |-->| P NoC|-->| Slaves | + +--+ | +-+ +-+ +-+ ++ ++ + | + +---+ + | Modem | + +---+ + +Terminology +--- + +Interconnect provider is the software definition of the interconnect hardware. +The interconnect providers on the above diagram are M NoC, S NoC, C NoC and Mem +NoC. + +Interconnect node is the software definition of the interconnect hardware +port. Each interconnect provider consists of multiple interconnect nodes, +which are connected to other SoC components including other interconnect +providers. The point on the diagram where the CPUs connects to the memory is +called an interconnect node, which belongs to the Mem NoC interconnect provider. + +Interconn
[PATCH v4 1/7] interconnect: Add generic on-chip interconnect API
Hi Matthias,
On 04/06/2018 08:38 PM, Matthias Kaehlcke wrote:
> On Fri, Mar 09, 2018 at 11:09:52PM +0200, Georgi Djakov wrote:
>> This patch introduce a new API to get requirements and configure the
>> interconnect buses across the entire chipset to fit with the current
>> demand.
>>
>> The API is using a consumer/provider-based model, where the providers are
>> the interconnect buses and the consumers could be various drivers.
>> The consumers request interconnect resources (path) between endpoints and
>> set the desired constraints on this data flow path. The providers receive
>> requests from consumers and aggregate these requests for all master-slave
>> pairs on that path. Then the providers configure each participating in the
>> topology node according to the requested data flow path, physical links and
>> constraints. The topology could be complicated and multi-tiered and is SoC
>> specific.
>>
>> Signed-off-by: Georgi Djakov
>> ---
>> Documentation/interconnect/interconnect.rst | 96 ++
>> drivers/Kconfig | 2 +
>> drivers/Makefile| 1 +
>> drivers/interconnect/Kconfig| 10 +
>> drivers/interconnect/Makefile | 1 +
>> drivers/interconnect/core.c | 489
>>
>> include/linux/interconnect-provider.h | 109 +++
>> include/linux/interconnect.h| 40 +++
>> 8 files changed, 748 insertions(+)
>> create mode 100644 Documentation/interconnect/interconnect.rst
>> create mode 100644 drivers/interconnect/Kconfig
>> create mode 100644 drivers/interconnect/Makefile
>> create mode 100644 drivers/interconnect/core.c
>> create mode 100644 include/linux/interconnect-provider.h
>> create mode 100644 include/linux/interconnect.h
>>
>> diff --git a/Documentation/interconnect/interconnect.rst
>> b/Documentation/interconnect/interconnect.rst
>> new file mode 100644
>> index ..23eba68e8424
>> --- /dev/null
>> +++ b/Documentation/interconnect/interconnect.rst
[..]
>> +Terminology
>> +---
>> +
>> +Interconnect provider is the software definition of the interconnect
>> hardware.
>> +The interconnect providers on the above diagram are M NoC, S NoC, C NoC and
>> Mem
>> +NoC.
>
> Should P NoC be part of that list?
>
Yes, it should be!
>> +
>> +Interconnect node is the software definition of the interconnect hardware
>> +port. Each interconnect provider consists of multiple interconnect nodes,
>> +which are connected to other SoC components including other interconnect
>> +providers. The point on the diagram where the CPUs connects to the memory is
>> +called an interconnect node, which belongs to the Mem NoC interconnect
>> provider.
>> +
>> +Interconnect endpoints are the first or the last element of the path. Every
>> +endpoint is a node, but not every node is an endpoint.
>> +
>> +Interconnect path is everything between two endpoints including all the
>> nodes
>> +that have to be traversed to reach from a source to destination node. It may
>> +include multiple master-slave pairs across several interconnect providers.
>> +
>> +Interconnect consumers are the entities which make use of the data paths
>> exposed
>> +by the providers. The consumers send requests to providers requesting
>> various
>> +throughput, latency and priority. Usually the consumers are device drivers,
>> that
>> +send request based on their needs. An example for a consumer is a video
>> decoder
>> +that supports various formats and image sizes.
>> +
>> +Interconnect providers
>> +--
[..]
>> +static void node_aggregate(struct icc_node *node)
>> +{
>> +struct icc_req *r;
>> +u32 agg_avg = 0;
>
> Should this be u64 to avoid overflow in case of a large number of
> constraints and high bandwidths?
These values are proposed to be in kbps and u32 seems to be enough for
now, but in the future we can switch to u64 if needed.
>
>> +u32 agg_peak = 0;
>> +
>> +hlist_for_each_entry(r, &node->req_list, req_node) {
>> +/* sum(averages) and max(peaks) */
>> +agg_avg += r->avg_bw;
>> +agg_peak = max(agg_peak, r->peak_bw);
>> +}
>> +
>> +node->avg_bw = agg_avg;
>
> Is it really intended to store the sum of averages here rather than
> the overall average?
Yes, the intention is to sum all the averages in total, so
[PATCH v4 5/7] interconnect: qcom: Add msm8916 interconnect provider driver
Hi Matthias, On 04/06/2018 01:58 AM, Matthias Kaehlcke wrote: > On Fri, Mar 09, 2018 at 11:09:56PM +0200, Georgi Djakov wrote: >> Add driver for the Qualcomm interconnect buses found in msm8916 based >> platforms. >> >> Signed-off-by: Georgi Djakov >> --- >> drivers/interconnect/Kconfig| 5 + >> drivers/interconnect/Makefile | 1 + >> drivers/interconnect/qcom/Kconfig | 11 + >> drivers/interconnect/qcom/Makefile | 2 + >> drivers/interconnect/qcom/msm8916.c | 482 >> >> include/linux/interconnect/qcom.h | 350 ++ >> 6 files changed, 851 insertions(+) >> create mode 100644 drivers/interconnect/qcom/Kconfig >> create mode 100644 drivers/interconnect/qcom/msm8916.c >> create mode 100644 include/linux/interconnect/qcom.h >> [..] >> + >> +DEFINE_QNODE(mas_video, 63, 8, 16, 1, -1, -1, QCOM_QOS_MODE_BYPASS, 2, >> 1, 10002); > > IIUC this should be something like: > > +DEFINE_QNODE(mas_video, MASTER_VIDEO_P0, MASTER_ADM_PORT1, 16, 1, -1, > -1, QCOM_QOS_MODE_BYPASS, 2, SNOC_MM_INT_0, SNOC_MM_INT_2); > > and similar for the other nodes. > Yes, exactly. >> +DEFINE_QNODE(mas_jpeg, 62, 6, 16, 1, -1, -1, QCOM_QOS_MODE_BYPASS, 2, >> 1, 10002); >> +DEFINE_QNODE(mas_vfe, 29, 9, 16, 1, -1, -1, QCOM_QOS_MODE_BYPASS, 2, 10001, >> 10002); >> +DEFINE_QNODE(mas_mdp, 22, 7, 16, 1, -1, -1, QCOM_QOS_MODE_BYPASS, 2, 1, >> 10002); >> +DEFINE_QNODE(mas_qdss_bam, 53, 11, 16, 1, -1, -1, QCOM_QOS_MODE_FIXED, 1, >> 10009); >> +DEFINE_QNODE(mas_snoc_cfg, 54, 0, 16, 0, 20, -1, QCOM_QOS_MODE_BYPASS, 1, >> 10009); >> +DEFINE_QNODE(mas_qdss_etr, 60, 10, 16, 1, -1, -1, QCOM_QOS_MODE_FIXED, 1, >> 10009); >> +DEFINE_QNODE(mm_int_0, 1, 0, 16, 1, -1, -1, QCOM_QOS_MODE_FIXED, 1, >> 10003); >> +DEFINE_QNODE(mm_int_1, 10001, 0, 16, 1, -1, -1, QCOM_QOS_MODE_FIXED, 1, >> 10003); >> +DEFINE_QNODE(mm_int_2, 10002, 0, 16, 1, -1, -1, QCOM_QOS_MODE_FIXED, 1, >> 10004); >> +DEFINE_QNODE(mm_int_bimc, 10003, 0, 16, 1, -1, -1, QCOM_QOS_MODE_FIXED, 1, >> 10008); >> +DEFINE_QNODE(snoc_int_0, 10004, 0, 8, 0, 99, 130, QCOM_QOS_MODE_FIXED, 3, >> 588, 519, 10027); >> +DEFINE_QNODE(snoc_int_1, 10005, 0, 8, 0, 100, 131, QCOM_QOS_MODE_FIXED, 3, >> 517, 663, 664); >> +DEFINE_QNODE(snoc_int_bimc, 10006, 0, 8, 0, 101, 132, QCOM_QOS_MODE_FIXED, >> 1, 10007); >> +DEFINE_QNODE(snoc_bimc_0_mas, 10007, 0, 8, 0, 3, -1, QCOM_QOS_MODE_FIXED, >> 1, 10025); >> +DEFINE_QNODE(snoc_bimc_1_mas, 10008, 0, 16, 1, -1, -1, QCOM_QOS_MODE_FIXED, >> 1, 10026); >> +DEFINE_QNODE(qdss_int, 10009, 0, 8, 1, -1, -1, QCOM_QOS_MODE_FIXED, 2, >> 10004, 10006); >> +DEFINE_QNODE(bimc_snoc_slv, 10017, 0, 8, 1, -1, -1, QCOM_QOS_MODE_FIXED, 2, >> 10004, 10005); >> +DEFINE_QNODE(snoc_pnoc_mas, 10027, 0, 8, 0, -1, -1, QCOM_QOS_MODE_FIXED, 1, >> 10028); >> +DEFINE_QNODE(pnoc_snoc_slv, 10011, 0, 8, 0, -1, 45, QCOM_QOS_MODE_FIXED, 3, >> 10004, 10006, 10005); >> +DEFINE_QNODE(slv_srvc_snoc, 587, 0, 8, 0, -1, 29, QCOM_QOS_MODE_FIXED, 0, >> 0); >> +DEFINE_QNODE(slv_qdss_stm, 588, 0, 4, 0, -1, 30, QCOM_QOS_MODE_FIXED, 0, 0); >> +DEFINE_QNODE(slv_imem, 519, 0, 8, 0, -1, 26, QCOM_QOS_MODE_FIXED, 0, 0); >> +DEFINE_QNODE(slv_apss, 517, 0, 4, 0, -1, 20, QCOM_QOS_MODE_FIXED, 0, 0); >> +DEFINE_QNODE(slv_cats_0, 663, 0, 16, 0, -1, 106, QCOM_QOS_MODE_FIXED, 0, 0); >> +DEFINE_QNODE(slv_cats_1, 664, 0, 8, 0, -1, 107, QCOM_QOS_MODE_FIXED, 0, 0); >> +DEFINE_QNODE(mas_apss, 1, 0, 8, 1, -1, -1, QCOM_QOS_MODE_FIXED, 3, 512, >> 10016, 514); >> +DEFINE_QNODE(mas_tcu0, 104, 5, 8, 1, -1, -1, QCOM_QOS_MODE_FIXED, 3, 512, >> 10016, 514); >> +DEFINE_QNODE(mas_tcu1, 105, 6, 8, 1, -1, -1, QCOM_QOS_MODE_FIXED, 3, 512, >> 10016, 514); >> +DEFINE_QNODE(mas_gfx, 26, 2, 8, 1, -1, -1, QCOM_QOS_MODE_FIXED, 3, 512, >> 10016, 514); >> +DEFINE_QNODE(bimc_snoc_mas, 10016, 0, 8, 1, -1, -1, QCOM_QOS_MODE_FIXED, 1, >> 10017); >> +DEFINE_QNODE(snoc_bimc_0_slv, 10025, 0, 8, 0, -1, 24, QCOM_QOS_MODE_FIXED, >> 1, 512); >> +DEFINE_QNODE(snoc_bimc_1_slv, 10026, 0, 8, 1, -1, -1, QCOM_QOS_MODE_FIXED, >> 1, 512); >> +DEFINE_QNODE(slv_ebi_ch0, 512, 0, 8, 0, -1, 0, QCOM_QOS_MODE_FIXED, 0, 0); >> +DEFINE_QNODE(slv_apps_l2, 514, 0, 8, 0, -1, -1, QCOM_QOS_MODE_FIXED, 0, 0); >> +DEFINE_QNODE(snoc_pnoc_slv, 10028, 0, 8, 0, -1, -1, QCOM_QOS_MODE_FIXED, 1, >> 10012); >> +DEFINE_QNODE(pnoc_int_0, 10012, 0, 8, 0, -1, -1, QCOM_QOS_MODE_FIXED, 8, >> 10010, 10018, 10019, 10020, 10021, 10022,
Re: [PATCH v9 2/8] dt-bindings: Introduce interconnect binding
Hi Rob,
Thanks for the comments!
On 09/25/2018 09:02 PM, Rob Herring wrote:
> On Fri, Aug 31, 2018 at 05:01:45PM +0300, Georgi Djakov wrote:
>> This binding is intended to represent the relations between the interconnect
>> controllers (providers) and consumer device nodes. It will allow creating
>> links
>> between consumers and interconnect paths (exposed by interconnect providers).
>
> As I mentioned in person, I want to see other SoC families using this
> before accepting. They don't have to be ready for upstream, but WIP
> patches or even just a "yes, this works for us and we're going to use
> this binding on X".
Other than the 3 Qualcomm SoCs (msm8916, msm8996, sdm845) that are
currently using this binding, there is ongoing work from at least two
other vendors that would be using this same binding. I will check on
what is their progress so far.
> Also, I think the QCom GPU use of this should be fully sorted out. Or
> more generically how this fits into OPP binding which seems to be never
> ending extended...
I see this as a further step. It could be OPP binding which include
bandwidth values or some separate DT property. Jordan has already
proposed something, do you have any initial comments on that?
BR,
Georgi
>> Signed-off-by: Georgi Djakov
>> ---
>> .../bindings/interconnect/interconnect.txt| 60 +++
>> 1 file changed, 60 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/interconnect/interconnect.txt
>>
>> diff --git a/Documentation/devicetree/bindings/interconnect/interconnect.txt
>> b/Documentation/devicetree/bindings/interconnect/interconnect.txt
>> new file mode 100644
>> index ..5cb7d3c8d44d
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/interconnect/interconnect.txt
>> @@ -0,0 +1,60 @@
>> +Interconnect Provider Device Tree Bindings
>> +=
>> +
>> +The purpose of this document is to define a common set of generic
>> interconnect
>> +providers/consumers properties.
>> +
>> +
>> += interconnect providers =
>> +
>> +The interconnect provider binding is intended to represent the interconnect
>> +controllers in the system. Each provider registers a set of interconnect
>> +nodes, which expose the interconnect related capabilities of the
>> interconnect
>> +to consumer drivers. These capabilities can be throughput, latency, priority
>> +etc. The consumer drivers set constraints on interconnect path (or
>> endpoints)
>> +depending on the use case. Interconnect providers can also be interconnect
>> +consumers, such as in the case where two network-on-chip fabrics interface
>> +directly
>
> missing '.'
>
>> +
>> +Required properties:
>> +- compatible : contains the interconnect provider compatible string
>> +- #interconnect-cells : number of cells in a interconnect specifier needed
>> to
>> +encode the interconnect node id
>> +
>> +Example:
>> +
>> +snoc: snoc@58 {
>> +compatible = "qcom,msm8916-snoc";
>> +#interconnect-cells = <1>;
>> +reg = <0x58 0x14000>;
>> +clock-names = "bus_clk", "bus_a_clk";
>> +clocks = <&rpmcc RPM_SMD_SNOC_CLK>,
>> + <&rpmcc RPM_SMD_SNOC_A_CLK>;
>> +};
>> +
>> +
>> += interconnect consumers =
>> +
>> +The interconnect consumers are device nodes which dynamically express their
>> +bandwidth requirements along interconnect paths they are connected to. There
>> +can be multiple interconnect providers on a SoC and the consumer may consume
>> +multiple paths from different providers depending on use case and the
>> +components it has to interact with.
>> +
>> +Required properties:
>> +interconnects : Pairs of phandles and interconnect provider specifier to
>> denote
>> +the edge source and destination ports of the interconnect path.
>> +
>> +Optional properties:
>> +interconnect-names : List of interconnect path name strings sorted in the
>> same
>> + order as the interconnects property. Consumers drivers
>> will use
>> + interconnect-names to match interconnect paths with
>> interconnect
>> + specifiers.
>
> specifier pairs.
>
>> +
>> +Example:
>> +
>> +sdhci@7864000 {
>> +...
>> +interconnects = <&pnoc MASTER_SDCC_1 &bimc SLAVE_EBI_CH0>;
>> +interconnect-names = "ddr";
>> +};
Re: [PATCH v9 2/8] dt-bindings: Introduce interconnect binding
Hi Sudeep, On 09/26/2018 05:48 PM, Sudeep Holla wrote: > On Wed, Sep 26, 2018 at 05:42:15PM +0300, Georgi Djakov wrote: >> Hi Rob, >> >> Thanks for the comments! >> >> On 09/25/2018 09:02 PM, Rob Herring wrote: >>> On Fri, Aug 31, 2018 at 05:01:45PM +0300, Georgi Djakov wrote: >>>> This binding is intended to represent the relations between the >>>> interconnect >>>> controllers (providers) and consumer device nodes. It will allow creating >>>> links >>>> between consumers and interconnect paths (exposed by interconnect >>>> providers). >>> >>> As I mentioned in person, I want to see other SoC families using this >>> before accepting. They don't have to be ready for upstream, but WIP >>> patches or even just a "yes, this works for us and we're going to use >>> this binding on X". >> >> Other than the 3 Qualcomm SoCs (msm8916, msm8996, sdm845) that are >> currently using this binding, there is ongoing work from at least two >> other vendors that would be using this same binding. I will check on >> what is their progress so far. >> >>> Also, I think the QCom GPU use of this should be fully sorted out. Or >>> more generically how this fits into OPP binding which seems to be never >>> ending extended... >> >> I see this as a further step. It could be OPP binding which include >> bandwidth values or some separate DT property. Jordan has already >> proposed something, do you have any initial comments on that? > > I am curious as how this fits into new systems which have firmware driven > CPUFreq and other DVFS. I would like to avoid using this in such systems > and leave it upto the firmware to scale the bus/interconnect based on the > other components that are connected to it and active. This can be used with firmware driven systems too. In this case the interconnect platform driver will not manage the interconnects directly, but will collect data and provide hints to the firmware. Then the firmware can take into account these hints and do the scaling. Thanks, Georgi
[PATCH v10 0/8] Introduce on-chip interconnect API
thin the provider from the framework to the platform driver's set() callback, as the aggregation point could be SoC specific. * [patch 1]: Include missing header, reset state only of the traversed nodes, move more code into path_init(), add more asserts, move misplaced mutex, simplify icc_link_destroy() (Evan) * [patch 1]: Fix the order of requests to go from source to destination. (Alex) * [patch 7]: Use better wording in the documentation. (Evan) * [patch 6]: Reorder struct members, sort nodes alphabetically, improve naming of variables , add missing clk_disable_unprepare() in error paths. (Matthias) * [patch 6]: Remove redundant NULL pointer check in msm8916 driver. (Alex) * [patch 6]: Add missing depend on QCOM_SMD_RPM in Kconfig. (Evan) * [patch 3]: Don't check for errors on debugfs calls, remove debugfs directory when module is unloaded (Greg) Changes since patchset v5 (https://lkml.org/lkml/2018/6/20/453) * Fix the modular build, make rpm-smd driver a module. * Optimize locking and move to higher level. (Evan) * Code cleanups. Fix typos. (Evan, Matthias) * Add the source node to the path. (Evan) * Rename path_allocate() to path_init() with minor refactoring. (Evan) * Rename *_remove() functions to *_destroy(). * Return fixed errors in icc_link_destroy(). (Evan) * Fix krealloc() usage in icc_link_destroy(). (Evan) * Add missing kfree() in icc_node_create(). (Matthias) * Make icc_node_add() return void. (Matthias) * Change mutex_init to mutex_lock in icc_provider_add(). (Matthias) * Add new icc_node_del() function to delete nodes from provider. * Fix the header guard to reflect the path in smd-rpm.h. (Evan) * Check for errors returned by qcom_icc_rpm_smd_send(). (Evan) * Propagate the error of icc_provider_del(). (Evan) Changes since patchset v4 (https://lkml.org/lkml/2018/3/9/856) * Simplified locking by using a single global mutex. (Evan) * Changed the aggregation function interface. * Implemented functions for node, link, provider removal. (Evan) * Naming changes on variables and functions, removed redundant code. (Evan) * Fixes and clarifications in the docs. (Matthias, Evan, Amit, Alexandre) * Removed mandatory reg DT property, made interconnect-names optional. (Bjorn) * Made interconnect-cells property required to align with other bindings. (Neil) * Moved msm8916 specific bindings into a separate file and patch. (Bjorn) * Use the names, instead of the hardcoded ids for topology. (Matthias) * Init the node before creating the links. (Evan) * Added icc_units_to_bps macro. (Amit) Changes since patchset v3 (https://lkml.org/lkml/2017/9/8/544) * Refactored the constraints aggregation. * Use the IDR API. * Split the provider and consumer bindings into separate patches and propose new bindings for consumers, which allows to specify the local source port. * Adopted the icc_ prefix for API functions. * Introduced separate API functions for creating interconnect nodes and links. * Added DT lookup support in addition to platform data. * Dropped the event tracing patch for now. * Added a patch to provide summary via debugfs. * Use macro for the list of topology definitions in the platform driver. * Various minor changes. Changes since patchset v2 (https://lkml.org/lkml/2017/7/20/825) * Split the aggregation into per node and per provider. Cache the aggregated values. * Various small refactorings and cleanups in the framework. * Added a patch introducing basic tracepoint support for monitoring the time required to update the interconnect nodes. Changes since patchset v1 (https://lkml.org/lkml/2017/6/27/890) * Updates in the documentation. * Changes in request aggregation, locking. * Dropped the aggregate() callback and use the default as it currently sufficient for the single vendor driver. Will add it later when needed. * Dropped the dt-bindings draft patch for now. Changes since RFC v2 (https://lkml.org/lkml/2017/6/12/316) * Converted documentation to rst format. * Fixed an incorrect call to mutex_lock. Renamed max_bw to peak_bw. Changes since RFC v1 (https://lkml.org/lkml/2017/5/15/605) * Refactored code into shorter functions. * Added a new aggregate() API function. * Rearranged some structs to reduce padding bytes. Changes since RFC v0 (https://lkml.org/lkml/2017/3/1/599) * Removed DT support and added optional Patch 3 with new bindings proposal. * Converted the topology into internal driver data. * Made the framework modular. * interconnect_get() now takes (src and dst ports as arguments). * Removed public declarations of some structs. * Now passing prev/next nodes to the vendor driver. * Properly remove requests on _put(). * Added refcounting. * Updated documentation. * Changed struct interconnect_path to use array instead of linked list. David Dai (2): interconnect: qcom: Add sdm845 interconnect provider driver arm64: dts: sdm845: Add interconnect provider DT nodes Georgi Djakov (5): interconnect: Add generic on-chip interconnect API dt-bindings: Int
[PATCH v10 4/7] interconnect: Add debugfs support
Add a functionality to provide information about the current constraints
per each node and provider.
Signed-off-by: Georgi Djakov
Reviewed-by: Evan Green
---
drivers/interconnect/core.c | 71 +
1 file changed, 71 insertions(+)
diff --git a/drivers/interconnect/core.c b/drivers/interconnect/core.c
index ebc42ef9fa46..efe39e8934cc 100644
--- a/drivers/interconnect/core.c
+++ b/drivers/interconnect/core.c
@@ -6,6 +6,7 @@
* Author: Georgi Djakov
*/
+#include
#include
#include
#include
@@ -17,10 +18,12 @@
#include
#include
#include
+#include
static DEFINE_IDR(icc_idr);
static LIST_HEAD(icc_providers);
static DEFINE_MUTEX(icc_lock);
+static struct dentry *icc_debugfs_dir;
/**
* struct icc_req - constraints that are attached to each node
@@ -48,6 +51,59 @@ struct icc_path {
struct icc_req reqs[];
};
+static void icc_summary_show_one(struct seq_file *s, struct icc_node *n)
+{
+ if (!n)
+ return;
+
+ seq_printf(s, "%-30s %12u %12u\n",
+ n->name, n->avg_bw, n->peak_bw);
+}
+
+static int icc_summary_show(struct seq_file *s, void *data)
+{
+ struct icc_provider *provider;
+
+ seq_puts(s, " node avg
peak\n");
+ seq_puts(s,
"\n");
+
+ mutex_lock(&icc_lock);
+
+ list_for_each_entry(provider, &icc_providers, provider_list) {
+ struct icc_node *n;
+
+ list_for_each_entry(n, &provider->nodes, node_list) {
+ struct icc_req *r;
+
+ icc_summary_show_one(s, n);
+ hlist_for_each_entry(r, &n->req_list, req_node) {
+ if (!r->dev)
+ continue;
+
+ seq_printf(s, "%-26s %12u %12u\n",
+ dev_name(r->dev), r->avg_bw,
+ r->peak_bw);
+ }
+ }
+ }
+
+ mutex_unlock(&icc_lock);
+
+ return 0;
+}
+
+static int icc_summary_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, icc_summary_show, inode->i_private);
+}
+
+static const struct file_operations icc_summary_fops = {
+ .open = icc_summary_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release= single_release,
+};
+
static struct icc_node *node_find(const int id)
{
return idr_find(&icc_idr, id);
@@ -720,6 +776,21 @@ int icc_provider_del(struct icc_provider *provider)
}
EXPORT_SYMBOL_GPL(icc_provider_del);
+static int __init icc_init(void)
+{
+ icc_debugfs_dir = debugfs_create_dir("interconnect", NULL);
+ debugfs_create_file("interconnect_summary", 0444,
+ icc_debugfs_dir, NULL, &icc_summary_fops);
+ return 0;
+}
+
+static void __exit icc_exit(void)
+{
+ debugfs_remove_recursive(icc_debugfs_dir);
+}
+module_init(icc_init);
+module_exit(icc_exit);
+
MODULE_AUTHOR("Georgi Djakov
[PATCH v10 2/7] dt-bindings: Introduce interconnect binding
This binding is intended to represent the relations between the interconnect
controllers (providers) and consumer device nodes. It will allow creating links
between consumers and interconnect paths (exposed by interconnect providers).
Signed-off-by: Georgi Djakov
---
.../bindings/interconnect/interconnect.txt| 60 +++
1 file changed, 60 insertions(+)
create mode 100644
Documentation/devicetree/bindings/interconnect/interconnect.txt
diff --git a/Documentation/devicetree/bindings/interconnect/interconnect.txt
b/Documentation/devicetree/bindings/interconnect/interconnect.txt
new file mode 100644
index ..6775c07e1574
--- /dev/null
+++ b/Documentation/devicetree/bindings/interconnect/interconnect.txt
@@ -0,0 +1,60 @@
+Interconnect Provider Device Tree Bindings
+=
+
+The purpose of this document is to define a common set of generic interconnect
+providers/consumers properties.
+
+
+= interconnect providers =
+
+The interconnect provider binding is intended to represent the interconnect
+controllers in the system. Each provider registers a set of interconnect
+nodes, which expose the interconnect related capabilities of the interconnect
+to consumer drivers. These capabilities can be throughput, latency, priority
+etc. The consumer drivers set constraints on interconnect path (or endpoints)
+depending on the use case. Interconnect providers can also be interconnect
+consumers, such as in the case where two network-on-chip fabrics interface
+directly.
+
+Required properties:
+- compatible : contains the interconnect provider compatible string
+- #interconnect-cells : number of cells in a interconnect specifier needed to
+ encode the interconnect node id
+
+Example:
+
+ snoc: interconnect@58 {
+ compatible = "qcom,msm8916-snoc";
+ #interconnect-cells = <1>;
+ reg = <0x58 0x14000>;
+ clock-names = "bus_clk", "bus_a_clk";
+ clocks = <&rpmcc RPM_SMD_SNOC_CLK>,
+<&rpmcc RPM_SMD_SNOC_A_CLK>;
+ };
+
+
+= interconnect consumers =
+
+The interconnect consumers are device nodes which dynamically express their
+bandwidth requirements along interconnect paths they are connected to. There
+can be multiple interconnect providers on a SoC and the consumer may consume
+multiple paths from different providers depending on use case and the
+components it has to interact with.
+
+Required properties:
+interconnects : Pairs of phandles and interconnect provider specifier to denote
+ the edge source and destination ports of the interconnect path.
+
+Optional properties:
+interconnect-names : List of interconnect path name strings sorted in the same
+order as the interconnects property. Consumers drivers
will use
+interconnect-names to match interconnect paths with
interconnect
+specifier pairs.
+
+Example:
+
+ sdhci@7864000 {
+ ...
+ interconnects = <&pnoc MASTER_SDCC_1 &bimc SLAVE_EBI_CH0>;
+ interconnect-names = "sdhc-ddr";
+ };
[PATCH v10 7/7] MAINTAINERS: add a maintainer for the interconnect API
Add myself as the maintainer of the interconnect API. Signed-off-by: Georgi Djakov --- MAINTAINERS | 10 ++ 1 file changed, 10 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 380e43f585d3..4f426863ff3b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7694,6 +7694,16 @@ L: linux-g...@vger.kernel.org S: Maintained F: drivers/gpio/gpio-intel-mid.c +INTERCONNECT API +M: Georgi Djakov +S: Maintained +F: Documentation/interconnect/ +F: Documentation/devicetree/bindings/interconnect/ +F: drivers/interconnect/ +F: include/dt-bindings/interconnect/ +F: include/linux/interconnect-provider.h +F: include/linux/interconnect.h + INVENSENSE MPU-3050 GYROSCOPE DRIVER M: Linus Walleij L: linux-...@vger.kernel.org
