[PATCH] ARM: multi_v7_defconfig: Enable required QCOM SPMI/PMIC drivers

[Andy Gross]

This patch enables the QCOM SPMI and PMIC related drivers that are now
required to boot some supported devices.

Signed-off-by: Andy Gross 
---
 arch/arm/configs/multi_v7_defconfig | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index 69a22fd..8a5227e 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -340,10 +340,13 @@ CONFIG_SPI_TEGRA20_SFLASH=y
 CONFIG_SPI_TEGRA20_SLINK=y
 CONFIG_SPI_XILINX=y
 CONFIG_SPI_SPIDEV=y
+CONFIG_SPMI=y
 CONFIG_PINCTRL_AS3722=y
 CONFIG_PINCTRL_PALMAS=y
 CONFIG_PINCTRL_APQ8064=y
 CONFIG_PINCTRL_APQ8084=y
+CONFIG_PINCTRL_QCOM_SPMI_PMIC=y
+CONFIG_PINCTRL_QCOM_SSBI_PMIC=y
 CONFIG_GPIO_SYSFS=y
 CONFIG_GPIO_GENERIC_PLATFORM=y
 CONFIG_GPIO_DAVINCI=y
@@ -407,6 +410,7 @@ CONFIG_MFD_MAX8907=y
 CONFIG_MFD_RK808=y
 CONFIG_MFD_PM8921_CORE=y
 CONFIG_MFD_QCOM_RPM=y
+CONFIG_MFD_SPMI_PMIC=y
 CONFIG_MFD_SEC_CORE=y
 CONFIG_MFD_STMPE=y
 CONFIG_MFD_PALMAS=y
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 5/6] clk: qcom: gdsc: Do not check for disabled status on votable gdscs

[Rajendra Nayak]

Some gdscs might be controlled via voting registers and might not
really disable when the kernel intends to disable them (due to other
votes keeping them enabled)
Mark these gdscs with a flag for we do not check/wait on a disable
status for these gdscs within the kernel disable callback.

Signed-off-by: Rajendra Nayak 
---
 drivers/clk/qcom/gcc-msm8996.c  |  4 
 drivers/clk/qcom/gdsc.c |  4 
 drivers/clk/qcom/gdsc.h | 15 ---
 drivers/clk/qcom/mmcc-msm8996.c |  3 +++
 4 files changed, 19 insertions(+), 7 deletions(-)

diff --git a/drivers/clk/qcom/gcc-msm8996.c b/drivers/clk/qcom/gcc-msm8996.c
index c5bce5f..bb8c61f 100644
--- a/drivers/clk/qcom/gcc-msm8996.c
+++ b/drivers/clk/qcom/gcc-msm8996.c
@@ -3067,6 +3067,7 @@ static struct gdsc aggre0_noc_gdsc = {
.name = "aggre0_noc",
},
.pwrsts = PWRSTS_OFF_ON,
+   .flags = VOTABLE,
 };
 
 static struct gdsc hlos1_vote_aggre0_noc_gdsc = {
@@ -3075,6 +3076,7 @@ static struct gdsc hlos1_vote_aggre0_noc_gdsc = {
.name = "hlos1_vote_aggre0_noc",
},
.pwrsts = PWRSTS_OFF_ON,
+   .flags = VOTABLE,
 };
 
 static struct gdsc hlos1_vote_lpass_adsp_gdsc = {
@@ -3083,6 +3085,7 @@ static struct gdsc hlos1_vote_lpass_adsp_gdsc = {
.name = "hlos1_vote_lpass_adsp",
},
.pwrsts = PWRSTS_OFF_ON,
+   .flags = VOTABLE,
 };
 
 static struct gdsc hlos1_vote_lpass_core_gdsc = {
@@ -3091,6 +3094,7 @@ static struct gdsc hlos1_vote_lpass_core_gdsc = {
.name = "hlos1_vote_lpass_core",
},
.pwrsts = PWRSTS_OFF_ON,
+   .flags = VOTABLE,
 };
 
 static struct gdsc usb30_gdsc = {
diff --git a/drivers/clk/qcom/gdsc.c b/drivers/clk/qcom/gdsc.c
index fb2e43c..984537f 100644
--- a/drivers/clk/qcom/gdsc.c
+++ b/drivers/clk/qcom/gdsc.c
@@ -65,6 +65,10 @@ static int gdsc_toggle_logic(struct gdsc *sc, bool en)
if (ret)
return ret;
 
+   /* If disabling votable gdscs, don't poll on status */
+   if ((sc->flags & VOTABLE) && !en)
+   return 0;
+
timeout = jiffies + usecs_to_jiffies(TIMEOUT_US);
 
if (sc->gds_hw_ctrl) {
diff --git a/drivers/clk/qcom/gdsc.h b/drivers/clk/qcom/gdsc.h
index 66a43be..91cbb09 100644
--- a/drivers/clk/qcom/gdsc.h
+++ b/drivers/clk/qcom/gdsc.h
@@ -20,13 +20,6 @@
 struct regmap;
 struct reset_controller_dev;
 
-/* Powerdomain allowable state bitfields */
-#define PWRSTS_OFF BIT(0)
-#define PWRSTS_RET BIT(1)
-#define PWRSTS_ON  BIT(2)
-#define PWRSTS_OFF_ON  (PWRSTS_OFF | PWRSTS_ON)
-#define PWRSTS_RET_ON  (PWRSTS_RET | PWRSTS_ON)
-
 /**
  * struct gdsc - Globally Distributed Switch Controller
  * @pd: generic power domain
@@ -49,6 +42,14 @@ struct gdsc {
unsigned int*cxcs;
unsigned intcxc_count;
const u8pwrsts;
+/* Powerdomain allowable state bitfields */
+#define PWRSTS_OFF BIT(0)
+#define PWRSTS_RET BIT(1)
+#define PWRSTS_ON  BIT(2)
+#define PWRSTS_OFF_ON  (PWRSTS_OFF | PWRSTS_ON)
+#define PWRSTS_RET_ON  (PWRSTS_RET | PWRSTS_ON)
+   const u8flags;
+#define VOTABLEBIT(0)
struct reset_controller_dev *rcdev;
unsigned int*resets;
unsigned intreset_count;
diff --git a/drivers/clk/qcom/mmcc-msm8996.c b/drivers/clk/qcom/mmcc-msm8996.c
index 236acf5..a0a7338 100644
--- a/drivers/clk/qcom/mmcc-msm8996.c
+++ b/drivers/clk/qcom/mmcc-msm8996.c
@@ -2925,6 +2925,7 @@ struct gdsc mmagic_video_gdsc = {
.name = "mmagic_video",
},
.pwrsts = PWRSTS_OFF_ON,
+   .flags = VOTABLE,
 };
 
 struct gdsc mmagic_mdss_gdsc = {
@@ -2934,6 +2935,7 @@ struct gdsc mmagic_mdss_gdsc = {
.name = "mmagic_mdss",
},
.pwrsts = PWRSTS_OFF_ON,
+   .flags = VOTABLE,
 };
 
 struct gdsc mmagic_camss_gdsc = {
@@ -2943,6 +2945,7 @@ struct gdsc mmagic_camss_gdsc = {
.name = "mmagic_camss",
},
.pwrsts = PWRSTS_OFF_ON,
+   .flags = VOTABLE,
 };
 
 struct gdsc venus_gdsc = {
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/6] clk: qcom: gdsc: Add support for gdscs with gds hw controller

[Rajendra Nayak]

Some gdsc power domains can have a gds_hw_controller block inside
to help ensure all slave devices within the power domain are idle
before the gdsc is actually switched off.
This is mainly useful in power domains which host a MMU, in which
case its necessary to make sure there are no outstanding MMU operations
or pending bus transactions before the power domain is turned off.

In gdscs with gds_hw_controller block, its necessary to check the
gds_hw_ctrl status bits instead of the ones in gdscr, to determine
the state of the powerdomain.

Signed-off-by: Rajendra Nayak 
---
 drivers/clk/qcom/gdsc.c | 38 ++
 drivers/clk/qcom/gdsc.h |  2 ++
 2 files changed, 24 insertions(+), 16 deletions(-)

diff --git a/drivers/clk/qcom/gdsc.c b/drivers/clk/qcom/gdsc.c
index a164c38..fb2e43c 100644
--- a/drivers/clk/qcom/gdsc.c
+++ b/drivers/clk/qcom/gdsc.c
@@ -42,12 +42,12 @@
 
 #define domain_to_gdsc(domain) container_of(domain, struct gdsc, pd)
 
-static int gdsc_is_enabled(struct gdsc *sc)
+static int gdsc_is_enabled(struct gdsc *sc, unsigned int reg)
 {
u32 val;
int ret;
 
-   ret = regmap_read(sc->regmap, sc->gdscr, &val);
+   ret = regmap_read(sc->regmap, reg, &val);
if (ret)
return ret;
 
@@ -58,30 +58,34 @@ static int gdsc_toggle_logic(struct gdsc *sc, bool en)
 {
int ret;
u32 val = en ? 0 : SW_COLLAPSE_MASK;
-   u32 check = en ? PWR_ON_MASK : 0;
unsigned long timeout;
+   unsigned int status_reg = sc->gdscr;
 
ret = regmap_update_bits(sc->regmap, sc->gdscr, SW_COLLAPSE_MASK, val);
if (ret)
return ret;
 
timeout = jiffies + usecs_to_jiffies(TIMEOUT_US);
-   do {
-   ret = regmap_read(sc->regmap, sc->gdscr, &val);
-   if (ret)
-   return ret;
 
-   if ((val & PWR_ON_MASK) == check)
+   if (sc->gds_hw_ctrl) {
+   status_reg = sc->gds_hw_ctrl;
+   /*
+* The gds hw controller asserts/de-asserts the status bit soon
+* after it receives a power on/off request from a master.
+* The controller then takes around 8 xo cycles to start its internal
+* state machine and update the status bit. During this time, the
+* status bit does not reflect the true status of the core.
+* Add a delay of 1 us between writing to the SW_COLLAPSE bit and
+* polling the status bit
+*/
+   udelay(1);
+   }
+
+   do {
+   if (gdsc_is_enabled(sc, status_reg) == en)
return 0;
} while (time_before(jiffies, timeout));
 
-   ret = regmap_read(sc->regmap, sc->gdscr, &val);
-   if (ret)
-   return ret;
-
-   if ((val & PWR_ON_MASK) == check)
-   return 0;
-
return -ETIMEDOUT;
 }
 
@@ -165,6 +169,7 @@ static int gdsc_init(struct gdsc *sc)
 {
u32 mask, val;
int on, ret;
+   unsigned int reg;
 
/*
 * Disable HW trigger: collapse/restore occur based on registers writes.
@@ -185,7 +190,8 @@ static int gdsc_init(struct gdsc *sc)
return ret;
}
 
-   on = gdsc_is_enabled(sc);
+   reg = sc->gds_hw_ctrl ? sc->gds_hw_ctrl : sc->gdscr;
+   on = gdsc_is_enabled(sc, reg);
if (on < 0)
return on;
 
diff --git a/drivers/clk/qcom/gdsc.h b/drivers/clk/qcom/gdsc.h
index 4e9dfc1..66a43be 100644
--- a/drivers/clk/qcom/gdsc.h
+++ b/drivers/clk/qcom/gdsc.h
@@ -32,6 +32,7 @@ struct reset_controller_dev;
  * @pd: generic power domain
  * @regmap: regmap for MMIO accesses
  * @gdscr: gsdc control register
+ * @gds_hw_ctrl: gds_hw_ctrl register
  * @cxcs: offsets of branch registers to toggle mem/periph bits in
  * @cxc_count: number of @cxcs
  * @pwrsts: Possible powerdomain power states
@@ -44,6 +45,7 @@ struct gdsc {
struct generic_pm_domain*parent;
struct regmap   *regmap;
unsigned intgdscr;
+   unsigned intgds_hw_ctrl;
unsigned int*cxcs;
unsigned intcxc_count;
const u8pwrsts;
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/6] clk: qcom: gdsc: Add GDSCs in msm8996 GCC

[Rajendra Nayak]

Add all data for the GDSCs which are part of msm8996 GCC block

Signed-off-by: Rajendra Nayak 
---
 arch/arm64/boot/dts/qcom/msm8996.dtsi|  1 +
 drivers/clk/qcom/gcc-msm8996.c   | 88 
 include/dt-bindings/clock/qcom,gcc-msm8996.h | 11 
 3 files changed, 100 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi 
b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index 2c2736d..31e7bd9 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -147,6 +147,7 @@
compatible = "qcom,gcc-msm8996";
#clock-cells = <1>;
#reset-cells = <1>;
+   #power-domain-cells = <1>;
reg = <0x30 0x9>;
};
 
diff --git a/drivers/clk/qcom/gcc-msm8996.c b/drivers/clk/qcom/gcc-msm8996.c
index 16d7c32..c5bce5f 100644
--- a/drivers/clk/qcom/gcc-msm8996.c
+++ b/drivers/clk/qcom/gcc-msm8996.c
@@ -30,6 +30,7 @@
 #include "clk-rcg.h"
 #include "clk-branch.h"
 #include "reset.h"
+#include "gdsc.h"
 
 #define F(f, s, h, m, n) { (f), (s), (2 * (h) - 1), (m), (n) }
 
@@ -3059,6 +3060,79 @@ static struct clk_hw *gcc_msm8996_hws[] = {
&ufs_ice_core_postdiv_clk_src.hw,
 };
 
+static struct gdsc aggre0_noc_gdsc = {
+   .gdscr = 0x81004,
+   .gds_hw_ctrl = 0x81028,
+   .pd = {
+   .name = "aggre0_noc",
+   },
+   .pwrsts = PWRSTS_OFF_ON,
+};
+
+static struct gdsc hlos1_vote_aggre0_noc_gdsc = {
+   .gdscr = 0x7d024,
+   .pd = {
+   .name = "hlos1_vote_aggre0_noc",
+   },
+   .pwrsts = PWRSTS_OFF_ON,
+};
+
+static struct gdsc hlos1_vote_lpass_adsp_gdsc = {
+   .gdscr = 0x7d034,
+   .pd = {
+   .name = "hlos1_vote_lpass_adsp",
+   },
+   .pwrsts = PWRSTS_OFF_ON,
+};
+
+static struct gdsc hlos1_vote_lpass_core_gdsc = {
+   .gdscr = 0x7d038,
+   .pd = {
+   .name = "hlos1_vote_lpass_core",
+   },
+   .pwrsts = PWRSTS_OFF_ON,
+};
+
+static struct gdsc usb30_gdsc = {
+   .gdscr = 0xf004,
+   .pd = {
+   .name = "usb30",
+   },
+   .pwrsts = PWRSTS_OFF_ON,
+};
+
+static struct gdsc pcie0_gdsc = {
+   .gdscr = 0x6b004,
+   .pd = {
+   .name = "pcie0",
+   },
+   .pwrsts = PWRSTS_OFF_ON,
+};
+
+static struct gdsc pcie1_gdsc = {
+   .gdscr = 0x6d004,
+   .pd = {
+   .name = "pcie1",
+   },
+   .pwrsts = PWRSTS_OFF_ON,
+};
+
+static struct gdsc pcie2_gdsc = {
+   .gdscr = 0x6e004,
+   .pd = {
+   .name = "pcie2",
+   },
+   .pwrsts = PWRSTS_OFF_ON,
+};
+
+static struct gdsc ufs_gdsc = {
+   .gdscr = 0x75004,
+   .pd = {
+   .name = "ufs",
+   },
+   .pwrsts = PWRSTS_OFF_ON,
+};
+
 static struct clk_regmap *gcc_msm8996_clocks[] = {
[GPLL0_EARLY] = &gpll0_early.clkr,
[GPLL0] = &gpll0.clkr,
@@ -3245,6 +3319,18 @@ static struct clk_regmap *gcc_msm8996_clocks[] = {
[GCC_RX1_USB2_CLKREF_CLK] = &gcc_rx1_usb2_clkref_clk.clkr,
 };
 
+static struct gdsc *gcc_msm8996_gdscs[] = {
+   [AGGRE0_NOC_GDSC] = &aggre0_noc_gdsc,
+   [HLOS1_VOTE_AGGRE0_NOC_GDSC] = &hlos1_vote_aggre0_noc_gdsc,
+   [HLOS1_VOTE_LPASS_ADSP_GDSC] = &hlos1_vote_lpass_adsp_gdsc,
+   [HLOS1_VOTE_LPASS_CORE_GDSC] = &hlos1_vote_lpass_core_gdsc,
+   [USB30_GDSC] = &usb30_gdsc,
+   [PCIE0_GDSC] = &pcie0_gdsc,
+   [PCIE1_GDSC] = &pcie1_gdsc,
+   [PCIE2_GDSC] = &pcie2_gdsc,
+   [UFS_GDSC] = &ufs_gdsc,
+};
+
 static const struct qcom_reset_map gcc_msm8996_resets[] = {
[GCC_SYSTEM_NOC_BCR] = { 0x4000 },
[GCC_CONFIG_NOC_BCR] = { 0x5000 },
@@ -3363,6 +3449,8 @@ static const struct qcom_cc_desc gcc_msm8996_desc = {
.num_clks = ARRAY_SIZE(gcc_msm8996_clocks),
.resets = gcc_msm8996_resets,
.num_resets = ARRAY_SIZE(gcc_msm8996_resets),
+   .gdscs = gcc_msm8996_gdscs,
+   .num_gdscs = ARRAY_SIZE(gcc_msm8996_gdscs),
 };
 
 static const struct of_device_id gcc_msm8996_match_table[] = {
diff --git a/include/dt-bindings/clock/qcom,gcc-msm8996.h 
b/include/dt-bindings/clock/qcom,gcc-msm8996.h
index 888e75c..6f814db 100644
--- a/include/dt-bindings/clock/qcom,gcc-msm8996.h
+++ b/include/dt-bindings/clock/qcom,gcc-msm8996.h
@@ -336,4 +336,15 @@
 #define GCC_MSS_Q6_BCR 99
 #define GCC_QREFS_VBG_CAL_BCR  100
 
+/* Indexes for GDSCs */
+#define AGGRE0_NOC_GDSC0
+#define HLOS1_VOTE_AGGRE0_NOC_GDSC 1
+#define HLOS1_VOTE_LPASS_ADSP_GDSC 2
+#define HLOS1_VOTE_LPASS_CORE_GDSC 3
+#define USB30_GDSC 4
+#define PCIE0_GDSC 5
+#define PCIE1_GDSC 6
+#define PCIE2_GDSC 7
+#define UFS_GDSC   8
+
 #endif
-- 
QUALCOMM INDIA, on behalf of Qualcomm In

[PATCH 0/6] Add support for MSM8996 GDSCs

[Rajendra Nayak]

This series adds support for GDSCs' which are part of gcc and mmcc
in QCOM msm8996 SoC. Series applies on top of the patches[1] which
adds support for MSM8996 clocks.

There are many more cases of gdscs within gdscs (hierarchical power
domains) in msm8996 (msm8974 has one such instance which is supported
upstream) and hence the series adds support within gdsc driver to
handle this.

Also msm8996 has gdscs with gds hw controllers within, for ensuring
slave device idleness before gdscs are powered off, hence the series
also adds support for gdscs with gds hw controllers.

ToDo: Series does not yet add support for gpu gdscs which are part
of mmcc.

Tested on apq8096 dragonboards to make sure all modelled gdscs can
be turned on/off successfully.

[1] https://lkml.org/lkml/2015/11/17/949 

Rajendra Nayak (6):
  clk: qcom: gdsc: Add support for hierarchical power domains
  clk: qcom: gdsc: Add support for gdscs with gds hw controller
  clk: qcom: gdsc: Add GDSCs in msm8996 GCC
  clk: qcom: gdsc: Add mmcc gdscs for msm8996 family
  clk: qcom: gdsc: Do not check for disabled status on votable gdscs
  clk: qcom: mmcc8974: Use gdscs .parent and remove genpd calls

 arch/arm64/boot/dts/qcom/msm8996.dtsi |   2 +
 drivers/clk/qcom/common.c |  14 ++-
 drivers/clk/qcom/gcc-msm8996.c|  92 +++
 drivers/clk/qcom/gdsc.c   |  69 ---
 drivers/clk/qcom/gdsc.h   |  34 --
 drivers/clk/qcom/mmcc-msm8974.c   |  14 +--
 drivers/clk/qcom/mmcc-msm8996.c   | 157 ++
 include/dt-bindings/clock/qcom,gcc-msm8996.h  |  11 ++
 include/dt-bindings/clock/qcom,mmcc-msm8996.h |  17 +++
 9 files changed, 363 insertions(+), 47 deletions(-)

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/6] clk: qcom: gdsc: Add support for hierarchical power domains

[Rajendra Nayak]

Some qcom SoCs' can have hierarchical power domains. Let the gdsc structs
specify the parents (if any) and the driver add genpd subdomains for them.

Signed-off-by: Rajendra Nayak 
---
 drivers/clk/qcom/common.c | 14 +-
 drivers/clk/qcom/gdsc.c   | 27 +--
 drivers/clk/qcom/gdsc.h   | 17 -
 3 files changed, 46 insertions(+), 12 deletions(-)

diff --git a/drivers/clk/qcom/common.c b/drivers/clk/qcom/common.c
index 8fa4772..cf100f9 100644
--- a/drivers/clk/qcom/common.c
+++ b/drivers/clk/qcom/common.c
@@ -98,6 +98,7 @@ int qcom_cc_really_probe(struct platform_device *pdev,
struct clk **clks;
struct qcom_reset_controller *reset;
struct qcom_cc *cc;
+   struct gdsc_desc *scd;
size_t num_clks = desc->num_clks;
struct clk_regmap **rclks = desc->clks;
 
@@ -143,15 +144,18 @@ int qcom_cc_really_probe(struct platform_device *pdev,
devm_add_action(dev, qcom_cc_reset_unregister, &reset->rcdev);
 
if (desc->gdscs && desc->num_gdscs) {
-   ret = gdsc_register(dev, desc->gdscs, desc->num_gdscs,
-   &reset->rcdev, regmap);
+   scd = devm_kzalloc(dev, sizeof(*scd), GFP_KERNEL);
+   if (!scd)
+   return -ENOMEM;
+   scd->dev = dev;
+   scd->scs = desc->gdscs;
+   scd->num = desc->num_gdscs;
+   ret = gdsc_register(scd, &reset->rcdev, regmap);
if (ret)
return ret;
+   devm_add_action(dev, qcom_cc_gdsc_unregister, scd);
}
 
-   devm_add_action(dev, qcom_cc_gdsc_unregister, dev);
-
-
return 0;
 }
 EXPORT_SYMBOL_GPL(qcom_cc_really_probe);
diff --git a/drivers/clk/qcom/gdsc.c b/drivers/clk/qcom/gdsc.c
index da9fad8..a164c38 100644
--- a/drivers/clk/qcom/gdsc.c
+++ b/drivers/clk/qcom/gdsc.c
@@ -201,11 +201,14 @@ static int gdsc_init(struct gdsc *sc)
return 0;
 }
 
-int gdsc_register(struct device *dev, struct gdsc **scs, size_t num,
+int gdsc_register(struct gdsc_desc *desc,
  struct reset_controller_dev *rcdev, struct regmap *regmap)
 {
int i, ret;
struct genpd_onecell_data *data;
+   struct device *dev = desc->dev;
+   struct gdsc **scs = desc->scs;
+   size_t num = desc->num;
 
data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
if (!data)
@@ -228,10 +231,30 @@ int gdsc_register(struct device *dev, struct gdsc **scs, 
size_t num,
data->domains[i] = &scs[i]->pd;
}
 
+   /* Add subdomains */
+   for (i = 0; i < num; i++) {
+   if (!scs[i])
+   continue;
+   if (scs[i]->parent)
+   pm_genpd_add_subdomain(scs[i]->parent, &scs[i]->pd);
+   }
+
return of_genpd_add_provider_onecell(dev->of_node, data);
 }
 
-void gdsc_unregister(struct device *dev)
+void gdsc_unregister(struct gdsc_desc *desc)
 {
+   int i;
+   struct device *dev = desc->dev;
+   struct gdsc **scs = desc->scs;
+   size_t num = desc->num;
+
+   /* Remove subdomains */
+   for (i = 0; i < num; i++) {
+   if (!scs[i])
+   continue;
+   if (scs[i]->parent)
+   pm_genpd_remove_subdomain(scs[i]->parent, &scs[i]->pd);
+   }
of_genpd_del_provider(dev->of_node);
 }
diff --git a/drivers/clk/qcom/gdsc.h b/drivers/clk/qcom/gdsc.h
index 5ded268..4e9dfc1 100644
--- a/drivers/clk/qcom/gdsc.h
+++ b/drivers/clk/qcom/gdsc.h
@@ -41,6 +41,7 @@ struct reset_controller_dev;
  */
 struct gdsc {
struct generic_pm_domainpd;
+   struct generic_pm_domain*parent;
struct regmap   *regmap;
unsigned intgdscr;
unsigned int*cxcs;
@@ -51,18 +52,24 @@ struct gdsc {
unsigned intreset_count;
 };
 
+struct gdsc_desc {
+   struct device *dev;
+   struct gdsc **scs;
+   size_t num;
+};
+
 #ifdef CONFIG_QCOM_GDSC
-int gdsc_register(struct device *, struct gdsc **, size_t n,
- struct reset_controller_dev *, struct regmap *);
-void gdsc_unregister(struct device *);
+int gdsc_register(struct gdsc_desc *desc, struct reset_controller_dev *,
+ struct regmap *);
+void gdsc_unregister(struct gdsc_desc *desc);
 #else
-static inline int gdsc_register(struct device *d, struct gdsc **g, size_t n,
+static inline int gdsc_register(struct gdsc_desc *desc,
struct reset_controller_dev *rcdev,
struct regmap *r)
 {
return -ENOSYS;
 }
 
-static inline void gdsc_unregister(struct device *d) {};
+static inline void gdsc_unregister(struct gdsc_desc *desc) {};
 #endif /* CONFIG_QCOM_GDSC */
 #endif /* __QCOM_GDSC_H__ */
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
o

[PATCH 4/6] clk: qcom: gdsc: Add mmcc gdscs for msm8996 family

[Rajendra Nayak]

Add all gdsc data which are part of mmcc on msm8996 family

Signed-off-by: Rajendra Nayak 
---
 arch/arm64/boot/dts/qcom/msm8996.dtsi |   1 +
 drivers/clk/qcom/mmcc-msm8996.c   | 154 ++
 include/dt-bindings/clock/qcom,mmcc-msm8996.h |  17 +++
 3 files changed, 172 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi 
b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index 31e7bd9..0506fb8 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -252,6 +252,7 @@
compatible = "qcom,mmcc-msm8996";
#clock-cells = <1>;
#reset-cells = <1>;
+   #power-domain-cells = <1>;
reg = <0x8c 0x4>;
assigned-clocks = <&mmcc MMPLL9_PLL>,
  <&mmcc MMPLL1_PLL>,
diff --git a/drivers/clk/qcom/mmcc-msm8996.c b/drivers/clk/qcom/mmcc-msm8996.c
index 064f3ea..236acf5 100644
--- a/drivers/clk/qcom/mmcc-msm8996.c
+++ b/drivers/clk/qcom/mmcc-msm8996.c
@@ -32,6 +32,7 @@
 #include "clk-rcg.h"
 #include "clk-branch.h"
 #include "reset.h"
+#include "gdsc.h"
 
 #define F(f, s, h, m, n) { (f), (s), (2 * (h) - 1), (m), (n) }
 
@@ -2917,6 +2918,141 @@ static struct clk_hw *mmcc_msm8996_hws[] = {
&gpll0_div.hw,
 };
 
+struct gdsc mmagic_video_gdsc = {
+   .gdscr = 0x119c,
+   .gds_hw_ctrl = 0x120c,
+   .pd = {
+   .name = "mmagic_video",
+   },
+   .pwrsts = PWRSTS_OFF_ON,
+};
+
+struct gdsc mmagic_mdss_gdsc = {
+   .gdscr = 0x247c,
+   .gds_hw_ctrl = 0x2480,
+   .pd = {
+   .name = "mmagic_mdss",
+   },
+   .pwrsts = PWRSTS_OFF_ON,
+};
+
+struct gdsc mmagic_camss_gdsc = {
+   .gdscr = 0x3c4c,
+   .gds_hw_ctrl = 0x3c50,
+   .pd = {
+   .name = "mmagic_camss",
+   },
+   .pwrsts = PWRSTS_OFF_ON,
+};
+
+struct gdsc venus_gdsc = {
+   .gdscr = 0x1024,
+   .cxcs = (unsigned int []){ 0x1028, 0x1034, 0x1038 },
+   .cxc_count = 3,
+   .pd = {
+   .name = "venus",
+   },
+   .parent = &mmagic_video_gdsc.pd,
+   .pwrsts = PWRSTS_OFF_ON,
+};
+
+struct gdsc venus_core0_gdsc = {
+   .gdscr = 0x1040,
+   .cxcs = (unsigned int []){ 0x1048 },
+   .cxc_count = 1,
+   .pd = {
+   .name = "venus_core0",
+   },
+   .pwrsts = PWRSTS_OFF_ON,
+};
+
+struct gdsc venus_core1_gdsc = {
+   .gdscr = 0x1044,
+   .cxcs = (unsigned int []){ 0x104c },
+   .cxc_count = 1,
+   .pd = {
+   .name = "venus_core1",
+   },
+   .pwrsts = PWRSTS_OFF_ON,
+};
+
+struct gdsc camss_gdsc = {
+   .gdscr = 0x34a0,
+   .cxcs = (unsigned int []){ 0x36bc, 0x36c4 },
+   .cxc_count = 2,
+   .pd = {
+   .name = "camss",
+   },
+   .parent = &mmagic_camss_gdsc.pd,
+   .pwrsts = PWRSTS_OFF_ON,
+};
+
+struct gdsc vfe0_gdsc = {
+   .gdscr = 0x3664,
+   .cxcs = (unsigned int []){ 0x36a8 },
+   .cxc_count = 1,
+   .pd = {
+   .name = "vfe0",
+   },
+   .parent = &camss_gdsc.pd,
+   .pwrsts = PWRSTS_OFF_ON,
+};
+
+struct gdsc vfe1_gdsc = {
+   .gdscr = 0x3674,
+   .cxcs = (unsigned int []){ 0x36ac },
+   .cxc_count = 1,
+   .pd = {
+   .name = "vfe0",
+   },
+   .parent = &camss_gdsc.pd,
+   .pwrsts = PWRSTS_OFF_ON,
+};
+
+struct gdsc jpeg_gdsc = {
+   .gdscr = 0x35a4,
+   .cxcs = (unsigned int []){ 0x35a8, 0x35b0, 0x35c0, 0x35b8 },
+   .cxc_count = 4,
+   .pd = {
+   .name = "jpeg",
+   },
+   .parent = &camss_gdsc.pd,
+   .pwrsts = PWRSTS_OFF_ON,
+};
+
+struct gdsc cpp_gdsc = {
+   .gdscr = 0x36d4,
+   .cxcs = (unsigned int []){ 0x36b0 },
+   .cxc_count = 1,
+   .pd = {
+   .name = "cpp",
+   },
+   .parent = &camss_gdsc.pd,
+   .pwrsts = PWRSTS_OFF_ON,
+};
+
+struct gdsc fd_gdsc = {
+   .gdscr = 0x3b64,
+   .cxcs = (unsigned int []){ 0x3b68, 0x3b6c },
+   .cxc_count = 2,
+   .pd = {
+   .name = "fd",
+   },
+   .parent = &camss_gdsc.pd,
+   .pwrsts = PWRSTS_OFF_ON,
+};
+
+struct gdsc mdss_gdsc = {
+   .gdscr = 0x2304,
+   .cxcs = (unsigned int []){ 0x2310, 0x231c },
+   .cxc_count = 2,
+   .pd = {
+   .name = "mdss",
+   },
+   .parent = &mmagic_mdss_gdsc.pd,
+   .pwrsts = PWRSTS_OFF_ON,
+};
+
 static struct clk_regmap *mmcc_msm8996_clocks[] = {
[MMPLL0_EARLY] = &mmpll0_early.clkr,
[MMPLL0_PLL] = &mmpll0.clkr,
@@ -3093,6 +3229,22 @@ static struct clk_regmap *mmcc_msm8996_clocks[] = {
[FD_AHB_CLK] = &fd_ahb_clk.clkr,
 };
 
+static struct gdsc *mmcc_msm8996_gdscs[] = {
+   [MMAGIC_VIDEO_GDSC] = &mmagic_video_gdsc,
+   [MMAGIC_MDSS_GDSC] = &mmagic_mdss_gdsc,
+   [MMAGIC_CAMSS_GDSC] = &mmagic_camss_gdsc,
+  

arm64: dts: qcom: Add apq8096 dragonboard dts skeletons

[Rajendra Nayak]

Add new dtsi and dts files for the apq8096 dragonboards with just
a serial device used as debug console

Signed-off-by: Rajendra Nayak 
---
Patch applies on top of Stephens' patches to add msm8996 dtsi
https://lkml.org/lkml/2015/11/17/955

 arch/arm64/boot/dts/qcom/Makefile |  2 +-
 arch/arm64/boot/dts/qcom/apq8096-dragonboard.dts  | 21 
 arch/arm64/boot/dts/qcom/apq8096-dragonboard.dtsi | 30 +++
 3 files changed, 52 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/boot/dts/qcom/apq8096-dragonboard.dts
 create mode 100644 arch/arm64/boot/dts/qcom/apq8096-dragonboard.dtsi

diff --git a/arch/arm64/boot/dts/qcom/Makefile 
b/arch/arm64/boot/dts/qcom/Makefile
index fa1f661..bd992ef 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -1,5 +1,5 @@
 dtb-$(CONFIG_ARCH_QCOM)+= apq8016-sbc.dtb msm8916-mtp.dtb
-dtb-$(CONFIG_ARCH_QCOM)+= msm8996-mtp.dtb
+dtb-$(CONFIG_ARCH_QCOM)+= msm8996-mtp.dtb apq8096-dragonboard.dtb
 
 always := $(dtb-y)
 subdir-y   := $(dts-dirs)
diff --git a/arch/arm64/boot/dts/qcom/apq8096-dragonboard.dts 
b/arch/arm64/boot/dts/qcom/apq8096-dragonboard.dts
new file mode 100644
index 000..65f4a6a
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/apq8096-dragonboard.dts
@@ -0,0 +1,21 @@
+/*
+ * Copyright (c) 2014-2015, 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.
+ */
+
+/dts-v1/;
+
+#include "apq8096-dragonboard.dtsi"
+
+/ {
+   model = "Qualcomm Technologies, Inc. APQ 8096 DragonBoard";
+   compatible = "qcom,apq8096-dragonboard";
+};
diff --git a/arch/arm64/boot/dts/qcom/apq8096-dragonboard.dtsi 
b/arch/arm64/boot/dts/qcom/apq8096-dragonboard.dtsi
new file mode 100644
index 000..9bab5c0
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/apq8096-dragonboard.dtsi
@@ -0,0 +1,30 @@
+/*
+ * Copyright (c) 2014-2015, 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 "msm8996.dtsi"
+
+/ {
+   aliases {
+   serial0 = &blsp2_uart1;
+   };
+
+   chosen {
+   stdout-path = "serial0";
+   };
+
+   soc {
+   serial@75b {
+   status = "okay";
+   };
+   };
+};
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 6/6] clk: qcom: mmcc8974: Use gdscs .parent and remove genpd calls

[Rajendra Nayak]

With gdsc driver capable of handling hierarchical power domains,
specify oxili_gdsc as parent of oxilicx_gdsc.

Remove all direct calls to genpd from the mmcc clock driver. The
adding and removing of subdomains is now handled from within
the gdsc driver.

Signed-off-by: Rajendra Nayak 
---
 drivers/clk/qcom/mmcc-msm8974.c | 14 ++
 1 file changed, 2 insertions(+), 12 deletions(-)

diff --git a/drivers/clk/qcom/mmcc-msm8974.c b/drivers/clk/qcom/mmcc-msm8974.c
index 9d790bc..12cea42 100644
--- a/drivers/clk/qcom/mmcc-msm8974.c
+++ b/drivers/clk/qcom/mmcc-msm8974.c
@@ -2400,6 +2400,7 @@ static struct gdsc oxilicx_gdsc = {
.pd = {
.name = "oxilicx",
},
+   .parent = &oxili_gdsc.pd,
.pwrsts = PWRSTS_OFF_ON,
 };
 
@@ -2624,22 +2625,11 @@ static int mmcc_msm8974_probe(struct platform_device 
*pdev)
clk_pll_configure_sr_hpm_lp(&mmpll1, regmap, &mmpll1_config, true);
clk_pll_configure_sr_hpm_lp(&mmpll3, regmap, &mmpll3_config, false);
 
-   ret = qcom_cc_really_probe(pdev, &mmcc_msm8974_desc, regmap);
-   if (ret)
-   return ret;
-
-   return pm_genpd_add_subdomain(&oxili_gdsc.pd, &oxilicx_gdsc.pd);
-}
-
-static int mmcc_msm8974_remove(struct platform_device *pdev)
-{
-   pm_genpd_remove_subdomain(&oxili_gdsc.pd, &oxilicx_gdsc.pd);
-   return 0;
+   return qcom_cc_really_probe(pdev, &mmcc_msm8974_desc, regmap);
 }
 
 static struct platform_driver mmcc_msm8974_driver = {
.probe  = mmcc_msm8974_probe,
-   .remove = mmcc_msm8974_remove,
.driver = {
.name   = "mmcc-msm8974",
.of_match_table = mmcc_msm8974_match_table,
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/2] ARM: Replace calls to __aeabi_{u}idiv with udiv/sdiv instructions

[Nicolas Pitre]

On Thu, 26 Nov 2015, Måns Rullgård wrote:

> Russell King - ARM Linux  writes:
> 
> > On Thu, Nov 26, 2015 at 12:50:08AM +, Måns Rullgård wrote:
> >> If not calling the function saves an I-cache miss, the benefit can be
> >> substantial.  No, I have no proof of this being a problem, but it's
> >> something that could happen.
> >
> > That's a simplistic view of modern CPUs.
> >
> > As I've already said, modern CPUs which have branch prediction, but
> > they also have speculative instruction fetching and speculative data
> > prefetching - which the CPUs which have idiv support will have.
> >
> > With such features, the branch predictor is able to learn that the
> > branch will be taken, and because of the speculative instruction
> > fetching, it can bring the cache line in so that it has the
> > instructions it needs with minimal or, if working correctly,
> > without stalling the CPU pipeline.
> 
> It doesn't matter how many fancy features the CPU has.  Executing more
> branches and using more cache lines puts additional pressure on those
> resources, reducing overall performance.  Besides, the performance
> counters readily show that the prediction is nothing near as perfect as
> you seem to believe.

OK... Let's try to come up with actual numbers.

We know that letting gcc emit idiv by itself is the ultimate solution. 
And it is free of maintenance on our side besides passing the 
appropriate argument to gcc of course. So this is worth doing.

For the case where you have a set of target machines in your kernel that 
may or may not have idiv, then the first step should be to patch 
__aeabi_uidiv and __aeabi_idiv.  This is a pretty small and simple 
change that might turn out to be more than good enough. It is necessary 
anyway as the full patching solution does not cover all cases.

Then, IMHO, it would be a good idea to get performance numbers to 
compare that first step and the full patching solution. Of course the 
full patching will yield better performance. It has to. But if the 
difference is not significant enough, then it might not be worth 
introducing the implied complexity into mainline.  And it is not because 
the approach is bad. In fact I think this is a very cool hack. But it 
comes with a cost in maintenance and that cost has to be justified.

Just to have an idea, I produced the attached micro benchmark. I tested 
on a TC2 forced to a single Cortex-A15 core and I got those results:

Testing INLINE_DIV ...

real0m7.182s
user0m7.170s
sys 0m0.000s

Testing PATCHED_DIV ...

real0m7.181s
user0m7.170s
sys 0m0.000s

Testing OUTOFLINE_DIV ...

real0m7.181s
user0m7.170s
sys 0m0.005s

Testing LIBGCC_DIV ...

real0m18.659s
user0m18.635s
sys 0m0.000s

As you can see, whether the div is inline or out-of-line, whether 
arguments are moved into r0-r1 or not, makes no difference at all on a 
Cortex-A15.

Now forcing it onto a Cortex-A7 core:

Testing INLINE_DIV ...

real0m8.917s
user0m8.895s
sys 0m0.005s

Testing PATCHED_DIV ...

real0m11.666s
user0m11.645s
sys 0m0.000s

Testing OUTOFLINE_DIV ...

real0m13.065s
user0m13.025s
sys 0m0.000s

Testing LIBGCC_DIV ...

real0m51.815s
user0m51.750s
sys 0m0.005s

So on A cortex-A7 the various overheads become visible. How significant 
is it in practice with normal kernel usage? I don't know.


Nicolas
#!/bin/sh
set -e
for test in INLINE_DIV PATCHED_DIV OUTOFLINE_DIV LIBGCC_DIV; do
  gcc -o divtest_$test divtest.S -D$test
  echo "Testing $test ..."
  time ./divtest_$test
  echo
  rm -f divtest_$test
done

.arm
.arch_extension idiv

.globl main
main:

stmfd   sp!, {r4, r5, lr}

mov r4, #17
1:  mov r5, #1

2:
#if defined(INLINE_DIV)

udivr0, r4, r5

#elif defined(OUTOFLINE_DIV)

mov r0, r4
mov r1, r5
bl  my_div

#elif defined(PATCHED_DIV)

mov r0, r4
mov r1, r5
udivr0, r0, r1

#elif defined(LIBGCC_DIV)

mov r0, r4
mov r1, r5
bl  __aeabi_uidiv

#else
#error "define INLINE_DIV, OUTOFLINE_DIV or LIBGCC_DIV"
#endif

add r5, r5, #1
cmp r4, r5
bhs 2b
addsr4, r4, r4, lsl #1
bpl 1b

mov r0, #0
ldmfd   sp!, {r4, r5, pc}

.space 1024

my_div:

udivr0, r0, r1
bx  lr

Re: [PATCH v2 2/2] ARM: Replace calls to __aeabi_{u}idiv with udiv/sdiv instructions

[Måns Rullgård]

Russell King - ARM Linux  writes:

> On Thu, Nov 26, 2015 at 12:50:08AM +, Måns Rullgård wrote:
>> If not calling the function saves an I-cache miss, the benefit can be
>> substantial.  No, I have no proof of this being a problem, but it's
>> something that could happen.
>
> That's a simplistic view of modern CPUs.
>
> As I've already said, modern CPUs which have branch prediction, but
> they also have speculative instruction fetching and speculative data
> prefetching - which the CPUs which have idiv support will have.
>
> With such features, the branch predictor is able to learn that the
> branch will be taken, and because of the speculative instruction
> fetching, it can bring the cache line in so that it has the
> instructions it needs with minimal or, if working correctly,
> without stalling the CPU pipeline.

It doesn't matter how many fancy features the CPU has.  Executing more
branches and using more cache lines puts additional pressure on those
resources, reducing overall performance.  Besides, the performance
counters readily show that the prediction is nothing near as perfect as
you seem to believe.

-- 
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/2] ARM: Replace calls to __aeabi_{u}idiv with udiv/sdiv instructions

[Russell King - ARM Linux]

On Thu, Nov 26, 2015 at 12:50:08AM +, Måns Rullgård wrote:
> If not calling the function saves an I-cache miss, the benefit can be
> substantial.  No, I have no proof of this being a problem, but it's
> something that could happen.

That's a simplistic view of modern CPUs.

As I've already said, modern CPUs which have branch prediction, but
they also have speculative instruction fetching and speculative data
prefetching - which the CPUs which have idiv support will have.

With such features, the branch predictor is able to learn that the
branch will be taken, and because of the speculative instruction
fetching, it can bring the cache line in so that it has the
instructions it needs with minimal or, if working correctly,
without stalling the CPU pipeline.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/2] ARM: Replace calls to __aeabi_{u}idiv with udiv/sdiv instructions

[Måns Rullgård]

Nicolas Pitre  writes:

> On Thu, 26 Nov 2015, Måns Rullgård wrote:
>
>> Nicolas Pitre  writes:
>> 
>> > 3) In fact I was wondering if the overhead of the branch and back is 
>> >really significant compared to the non trivial cost of a idiv 
>> >instruction and all the complex infrastructure required to patch 
>> >those branches directly, and consequently if the performance 
>> >difference is actually worth it versus simply doing (2) alone.
>> 
>> Depending on the operands, the div instruction can take as few as 3
>> cycles on a Cortex-A7.
>
> Even the current software based implementation can produce a result with 
> about 5 simple ALU instructions depending on the operands.
>
> The average cycle count is more important than the easy-way-out case. 
> And then how significant the two branches around it are compared to idiv 
> alone from direct patching of every call to it.

If not calling the function saves an I-cache miss, the benefit can be
substantial.  No, I have no proof of this being a problem, but it's
something that could happen.

Of course, none of this is going to be as good as letting the compiler
generate div instructions directly.

-- 
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/2] ARM: Replace calls to __aeabi_{u}idiv with udiv/sdiv instructions

[Nicolas Pitre]

On Thu, 26 Nov 2015, Måns Rullgård wrote:

> Nicolas Pitre  writes:
> 
> > On Wed, 25 Nov 2015, Stephen Boyd wrote:
> >
> >> The ARM compiler inserts calls to __aeabi_uidiv() and
> >> __aeabi_idiv() when it needs to perform division on signed and
> >> unsigned integers. If a processor has support for the udiv and
> >> sdiv division instructions the calls to these support routines
> >> can be replaced with those instructions. Now that recordmcount
> >> records the locations of calls to these library functions in
> >> two sections (one for udiv and one for sdiv), iterate over these
> >> sections early at boot and patch the call sites with the
> >> appropriate division instruction when we determine that the
> >> processor supports the division instructions. Using the division
> >> instructions should be faster and less power intensive than
> >> running the support code.
> >
> > A few remarks:
> >
> > 1) The code assumes unconditional branches to __aeabi_idiv and 
> >__aeabi_uidiv. What if there are conditional branches? Also, tail 
> >call optimizations will generate a straight b opcode rather than a bl 
> >and patching those will obviously have catastrophic results.  I think 
> >you should validate the presence of a bl before patching over it.
> 
> I did a quick check on a compiled kernel I had nearby, and there are no
> conditional or tail calls to those functions, so although they should
> obviously be checked for correctness, performance is unlikely to matter
> for those.

I'm more worried about correctness than performance.  This kind of 
patching should be done defensively.

> However, there are almost half as many calls to __aeabi_{u}idivmod as to
> the plain div functions, 129 vs 228 for signed and unsigned combined.
> For best results, these functions should also be patched with the
> hardware instructions.  Obviously the call sites for these can't be
> patched.

Current __aeabi_{u}idivmod implementations are simple wrappers around a 
call to __aeabi_{u}idiv so they'd get the benefit automatically 
regardless of the chosen approach.

> > 2) For those cases where a call to __aeabi_uidiv and __aeabi_idiv is not 
> >patched due to (1), you could patch a uidiv/idiv plus "bx lr" 
> >at those function entry points too.
> >
> > 3) In fact I was wondering if the overhead of the branch and back is 
> >really significant compared to the non trivial cost of a idiv 
> >instruction and all the complex infrastructure required to patch 
> >those branches directly, and consequently if the performance 
> >difference is actually worth it versus simply doing (2) alone.
> 
> Depending on the operands, the div instruction can take as few as 3
> cycles on a Cortex-A7.

Even the current software based implementation can produce a result with 
about 5 simple ALU instructions depending on the operands.

The average cycle count is more important than the easy-way-out case. 
And then how significant the two branches around it are compared to idiv 
alone from direct patching of every call to it.


Nicolas

Re: [PATCH v2 2/2] ARM: Replace calls to __aeabi_{u}idiv with udiv/sdiv instructions

[Måns Rullgård]

Nicolas Pitre  writes:

> On Wed, 25 Nov 2015, Stephen Boyd wrote:
>
>> The ARM compiler inserts calls to __aeabi_uidiv() and
>> __aeabi_idiv() when it needs to perform division on signed and
>> unsigned integers. If a processor has support for the udiv and
>> sdiv division instructions the calls to these support routines
>> can be replaced with those instructions. Now that recordmcount
>> records the locations of calls to these library functions in
>> two sections (one for udiv and one for sdiv), iterate over these
>> sections early at boot and patch the call sites with the
>> appropriate division instruction when we determine that the
>> processor supports the division instructions. Using the division
>> instructions should be faster and less power intensive than
>> running the support code.
>
> A few remarks:
>
> 1) The code assumes unconditional branches to __aeabi_idiv and 
>__aeabi_uidiv. What if there are conditional branches? Also, tail 
>call optimizations will generate a straight b opcode rather than a bl 
>and patching those will obviously have catastrophic results.  I think 
>you should validate the presence of a bl before patching over it.

I did a quick check on a compiled kernel I had nearby, and there are no
conditional or tail calls to those functions, so although they should
obviously be checked for correctness, performance is unlikely to matter
for those.

However, there are almost half as many calls to __aeabi_{u}idivmod as to
the plain div functions, 129 vs 228 for signed and unsigned combined.
For best results, these functions should also be patched with the
hardware instructions.  Obviously the call sites for these can't be
patched.

> 2) For those cases where a call to __aeabi_uidiv and __aeabi_idiv is not 
>patched due to (1), you could patch a uidiv/idiv plus "bx lr" 
>at those function entry points too.
>
> 3) In fact I was wondering if the overhead of the branch and back is 
>really significant compared to the non trivial cost of a idiv 
>instruction and all the complex infrastructure required to patch 
>those branches directly, and consequently if the performance 
>difference is actually worth it versus simply doing (2) alone.

Depending on the operands, the div instruction can take as few as 3
cycles on a Cortex-A7.

-- 
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/2] ARM: Replace calls to __aeabi_{u}idiv with udiv/sdiv instructions

[Russell King - ARM Linux]

On Wed, Nov 25, 2015 at 01:51:04PM -0800, Stephen Boyd wrote:
> diff --git a/arch/arm/include/asm/cputype.h b/arch/arm/include/asm/cputype.h
> index 85e374f873ac..48c77d422a0d 100644
> --- a/arch/arm/include/asm/cputype.h
> +++ b/arch/arm/include/asm/cputype.h
> @@ -250,8 +250,14 @@ static inline int cpu_is_pj4(void)
>  
>   return 0;
>  }
> +
> +static inline bool __attribute_const__ cpu_is_pj4_nomp(void)
> +{
> + return read_cpuid_part() == 0x56005810;

One other thing here, we really ought to avoid adding more magic numbers
to this file.  We have the ARM processors nicely #defined, but not a lot
else.  Maybe its time that we continued with the nice definitions for
these part numbers?

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/2] ARM: Replace calls to __aeabi_{u}idiv with udiv/sdiv instructions

[Russell King - ARM Linux]

On Wed, Nov 25, 2015 at 06:09:13PM -0500, Nicolas Pitre wrote:
> 3) In fact I was wondering if the overhead of the branch and back is 
>really significant compared to the non trivial cost of a idiv 
>instruction and all the complex infrastructure required to patch 
>those branches directly, and consequently if the performance 
>difference is actually worth it versus simply doing (2) alone.

I definitely agree with you on this, given that modern CPUs which
are going to be benefitting from idiv are modern CPUs with a branch
predictor (and if it's not predicting such unconditional calls and
returns it's not much use as a branch predictor!)

I think what we need to see is the performance of existing kernels,
vs patching the idiv instructions at every callsite, vs patching
the called function itself.

> > +#ifdef CONFIG_ARM_PATCH_UIDIV
> > +/* "sdiv r0, r0, r1" or "mrc p6, 1, r0, CR0, CR1, 4" if we're on pj4 w/o 
> > MP */
> > +static u32 __attribute_const__ sdiv_instruction(void)
> > +{
> > +   if (IS_ENABLED(CONFIG_THUMB2_KERNEL)) {
> > +   if (cpu_is_pj4_nomp())
> > +   return __opcode_to_mem_thumb32(0xee300691);
> > +   return __opcode_to_mem_thumb32(0xfb90f0f1);
> > +   }
> > +
> > +   if (cpu_is_pj4_nomp())
> > +   return __opcode_to_mem_arm(0xee300691);
> > +   return __opcode_to_mem_arm(0xe710f110);
> > +}
> > +
> > +/* "udiv r0, r0, r1" or "mrc p6, 1, r0, CR0, CR1, 0" if we're on pj4 w/o 
> > MP */
> > +static u32 __attribute_const__ udiv_instruction(void)
> > +{
> > +   if (IS_ENABLED(CONFIG_THUMB2_KERNEL)) {
> > +   if (cpu_is_pj4_nomp())
> > +   return __opcode_to_mem_thumb32(0xee300611);
> > +   return __opcode_to_mem_thumb32(0xfbb0f0f1);
> > +   }
> > +
> > +   if (cpu_is_pj4_nomp())
> > +   return __opcode_to_mem_arm(0xee300611);
> > +   return __opcode_to_mem_arm(0xe730f110);
> > +}

Any reason the above aren't marked with __init_or_module as well, as
the compiler can choose not to inline them?

> > +
> > +static void __init_or_module patch(u32 **addr, size_t count, u32 insn)
> > +{
> > +   for (; count != 0; count -= 4)
> > +   **addr++ = insn;
> > +}
> > +
> > +void __init_or_module patch_udiv(void *addr, size_t size)
> > +{
> > +   patch(addr, size, udiv_instruction());
> > +}
> > +
> > +void __init_or_module patch_sdiv(void *addr, size_t size)
> > +{
> > +   return patch(addr, size, sdiv_instruction());
> > +}
> > +
> > +static void __init patch_aeabi_uidiv(void)
> > +{
> > +   extern char __start_udiv_loc[], __stop_udiv_loc[];
> > +   extern char __start_idiv_loc[], __stop_idiv_loc[];
> > +   unsigned int mask;
> > +
> > +   if (IS_ENABLED(CONFIG_THUMB2_KERNEL))
> > +   mask = HWCAP_IDIVT;
> > +   else
> > +   mask = HWCAP_IDIVA;
> > +
> > +   if (!(elf_hwcap & mask))
> > +   return;
> > +
> > +   patch_udiv(__start_udiv_loc, __stop_udiv_loc - __start_udiv_loc);
> > +   patch_sdiv(__start_idiv_loc, __stop_idiv_loc - __start_idiv_loc);

I'm left really concerned about this.  We're modifying code with all
the caches on, and the above is not only missing any coherency of the
I/D paths, it's also missing any branch predictor maintanence.  So, if
we've executed any divisions at this point, the predictor could already
predicted one of these branches that's being modified.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/2] scripts: Add a recorduidiv program

[Russell King - ARM Linux]

On Wed, Nov 25, 2015 at 01:51:03PM -0800, Stephen Boyd wrote:
> The ARM compiler inserts calls to __aeabi_uidiv() and
> __aeabi_idiv() when it needs to perform division on signed and
> unsigned integers. If a processor has support for the udiv and
> sdiv division instructions the calls to these support routines
> can be replaced with those instructions. Therefore, record the
> location of calls to these library functions into two sections
> (one for udiv and one for sdiv) similar to how we trace calls to
> mcount. When the kernel boots up it will check to see if the
> processor supports the instructions and then patch the call sites
> with the instruction.

Do we have any resolution on these programs which modify the object
files in-place, rather than breaking any hard-links which may be
present (eg, as a result of using ccache in hard-link mode) ?

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/2] ARM: Replace calls to __aeabi_{u}idiv with udiv/sdiv instructions

[Nicolas Pitre]

On Wed, 25 Nov 2015, Stephen Boyd wrote:

> The ARM compiler inserts calls to __aeabi_uidiv() and
> __aeabi_idiv() when it needs to perform division on signed and
> unsigned integers. If a processor has support for the udiv and
> sdiv division instructions the calls to these support routines
> can be replaced with those instructions. Now that recordmcount
> records the locations of calls to these library functions in
> two sections (one for udiv and one for sdiv), iterate over these
> sections early at boot and patch the call sites with the
> appropriate division instruction when we determine that the
> processor supports the division instructions. Using the division
> instructions should be faster and less power intensive than
> running the support code.

A few remarks:

1) The code assumes unconditional branches to __aeabi_idiv and 
   __aeabi_uidiv. What if there are conditional branches? Also, tail 
   call optimizations will generate a straight b opcode rather than a bl 
   and patching those will obviously have catastrophic results.  I think 
   you should validate the presence of a bl before patching over it.

2) For those cases where a call to __aeabi_uidiv and __aeabi_idiv is not 
   patched due to (1), you could patch a uidiv/idiv plus "bx lr" 
   at those function entry points too.

3) In fact I was wondering if the overhead of the branch and back is 
   really significant compared to the non trivial cost of a idiv 
   instruction and all the complex infrastructure required to patch 
   those branches directly, and consequently if the performance 
   difference is actually worth it versus simply doing (2) alone.

4) Please add some printing to the boot log (debug level should be fine)  
   about the fact that you did modify n branch instances with a div 
   insn. That _could_ turn out to be a useful clue when debugging kernel 
   "strangeties".

> Cc: Nicolas Pitre 
> Cc: Arnd Bergmann 
> Cc: Steven Rostedt 
> Cc: Måns Rullgård 
> Cc: Thomas Petazzoni 
> Signed-off-by: Stephen Boyd 
> ---
>  arch/arm/Kconfig   | 14 +
>  arch/arm/include/asm/cputype.h |  8 -
>  arch/arm/include/asm/setup.h   |  3 ++
>  arch/arm/kernel/module.c   | 40 +
>  arch/arm/kernel/setup.c| 68 
> ++
>  arch/arm/kernel/vmlinux.lds.S  | 13 
>  6 files changed, 145 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 0365cbbc9179..aa8bc7da6331 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1617,6 +1617,20 @@ config AEABI
>  
> To use this you need GCC version 4.0.0 or later.
>  
> +config ARM_PATCH_UIDIV
> + bool "Runtime patch calls to __aeabi_{u}idiv() with udiv/sdiv"
> + depends on CPU_32v7 && !XIP_KERNEL && AEABI
> + help
> +   Some v7 CPUs have support for the udiv and sdiv instructions
> +   that can be used in place of calls to __aeabi_uidiv and __aeabi_idiv
> +   functions provided by the ARM runtime ABI.
> +
> +   Enabling this option allows the kernel to modify itself to replace
> +   branches to these library functions with the udiv and sdiv
> +   instructions themselves. Typically this will be faster and less
> +   power intensive than running the library support code to do
> +   integer division.
> +
>  config OABI_COMPAT
>   bool "Allow old ABI binaries to run with this kernel (EXPERIMENTAL)"
>   depends on AEABI && !THUMB2_KERNEL
> diff --git a/arch/arm/include/asm/cputype.h b/arch/arm/include/asm/cputype.h
> index 85e374f873ac..48c77d422a0d 100644
> --- a/arch/arm/include/asm/cputype.h
> +++ b/arch/arm/include/asm/cputype.h
> @@ -250,8 +250,14 @@ static inline int cpu_is_pj4(void)
>  
>   return 0;
>  }
> +
> +static inline bool __attribute_const__ cpu_is_pj4_nomp(void)
> +{
> + return read_cpuid_part() == 0x56005810;
> +}
>  #else
> -#define cpu_is_pj4() 0
> +#define cpu_is_pj4() 0
> +#define cpu_is_pj4_nomp()0
>  #endif
>  
>  static inline int __attribute_const__ cpuid_feature_extract_field(u32 
> features,
> diff --git a/arch/arm/include/asm/setup.h b/arch/arm/include/asm/setup.h
> index e0adb9f1bf94..a514552d5cbd 100644
> --- a/arch/arm/include/asm/setup.h
> +++ b/arch/arm/include/asm/setup.h
> @@ -25,4 +25,7 @@ extern int arm_add_memory(u64 start, u64 size);
>  extern void early_print(const char *str, ...);
>  extern void dump_machine_table(void);
>  
> +extern void patch_udiv(void *addr, size_t size);
> +extern void patch_sdiv(void *addr, size_t size);
> +
>  #endif
> diff --git a/arch/arm/kernel/module.c b/arch/arm/kernel/module.c
> index efdddcb97dd1..aa59e5cfe6a0 100644
> --- a/arch/arm/kernel/module.c
> +++ b/arch/arm/kernel/module.c
> @@ -20,7 +20,9 @@
>  #include 
>  #include 
>  
> +#include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -51,6 +53,38 @@ void *module_alloc(unsigned long size)
>  }
>  #endif
>  
> +#ifdef CONFIG_ARM_PATCH

Re: [PATCH v2 1/3] ARM: qcom: Make an option for qcom clocksource platforms

[Arnd Bergmann]

On Wednesday 25 November 2015 14:22:21 Stephen Boyd wrote:
> 
> >
> > Is there any common way to classify these, e.g. calling them
> > 'pre-2013 models' or 'Snapdragon S4' as a way to identify them?
> 
> I was thinking I could leave it as ARCH_MSM_8X60 because that covers the
> 6 and the 9, but that doesn't make me feel great. I have no idea what
> Snapdragon S4 is, and that didn't exist when 8660 was first released.
> pre-2013 models seems alright. Or perhaps ARCH_QCOM_PRE_8974?
> 
> Internally (and sort of leaked externally now) we called MSM8960 and its
> variants A-family, and the generation after B-family, so perhaps
> ARCH_QCOM_A_FAMILY would be appropriate? The problem there is no end
> user knows about this distinction.

I think using internal code names like ARCH_QCOM_A_FAMILY here is fine,
a lot of other platforms do similar things. Regarding end users,
it's probably enough to explain the distinction in the help text,
something like:

The A-family includes all Snapdragon S1/S2/S3/S4 chips before 2013,
up to the MSM8x60 and APQ8064 models.

The B-family includes all Snapdragon 2xx/4xx/6xx/8xx models starting
in 2013 with the MSM8x74.

https://en.wikipedia.org/wiki/List_of_Qualcomm_Snapdragon_device has
a good overview that translates the marketing names into the model
numbers but it doesn't have internal code names, so I'm not sure where the
APQ8064 fits it, as it was marketed as both the "S4 Pro" and the "600",
depending on the revision.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] ARM: dts: qcom: Remove size elements from pmic reg properties

[Stephen Boyd]

The #size-cells for the pmics are 0, but we specify a size in the
reg property so that MPP and GPIO modules can figure out how many
pins there are. Now that we've done that by counting irqs, we can
remove the size elements in the reg properties and be DT
compliant.

Signed-off-by: Stephen Boyd 
---
 arch/arm/boot/dts/qcom-pm8841.dtsi |  4 ++--
 arch/arm/boot/dts/qcom-pm8941.dtsi | 22 +++---
 2 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/arch/arm/boot/dts/qcom-pm8841.dtsi 
b/arch/arm/boot/dts/qcom-pm8841.dtsi
index 9f357f68713c..0512f645922e 100644
--- a/arch/arm/boot/dts/qcom-pm8841.dtsi
+++ b/arch/arm/boot/dts/qcom-pm8841.dtsi
@@ -11,7 +11,7 @@
 
pm8841_mpps: mpps@a000 {
compatible = "qcom,pm8841-mpp", "qcom,spmi-mpp";
-   reg = <0xa000 0x400>;
+   reg = <0xa000>;
gpio-controller;
#gpio-cells = <2>;
interrupts = <4 0xa0 0 IRQ_TYPE_NONE>,
@@ -22,7 +22,7 @@
 
temp-alarm@2400 {
compatible = "qcom,spmi-temp-alarm";
-   reg = <0x2400 0x100>;
+   reg = <0x2400>;
interrupts = <4 0x24 0 IRQ_TYPE_EDGE_RISING>;
};
};
diff --git a/arch/arm/boot/dts/qcom-pm8941.dtsi 
b/arch/arm/boot/dts/qcom-pm8941.dtsi
index 64622bd251d1..3960b96273ec 100644
--- a/arch/arm/boot/dts/qcom-pm8941.dtsi
+++ b/arch/arm/boot/dts/qcom-pm8941.dtsi
@@ -12,15 +12,15 @@
 
rtc@6000 {
compatible = "qcom,pm8941-rtc";
-   reg = <0x6000 0x100>,
- <0x6100 0x100>;
+   reg = <0x6000>,
+ <0x6100>;
reg-names = "rtc", "alarm";
interrupts = <0x0 0x61 0x1 IRQ_TYPE_EDGE_RISING>;
};
 
pwrkey@800 {
compatible = "qcom,pm8941-pwrkey";
-   reg = <0x800 0x100>;
+   reg = <0x800>;
interrupts = <0x0 0x8 0 IRQ_TYPE_EDGE_BOTH>;
debounce = <15625>;
bias-pull-up;
@@ -28,7 +28,7 @@
 
charger@1000 {
compatible = "qcom,pm8941-charger";
-   reg = <0x1000 0x700>;
+   reg = <0x1000>;
interrupts = <0x0 0x10 7 IRQ_TYPE_EDGE_BOTH>,
 <0x0 0x10 5 IRQ_TYPE_EDGE_BOTH>,
 <0x0 0x10 4 IRQ_TYPE_EDGE_BOTH>,
@@ -49,7 +49,7 @@
 
pm8941_gpios: gpios@c000 {
compatible = "qcom,pm8941-gpio", "qcom,spmi-gpio";
-   reg = <0xc000 0x2400>;
+   reg = <0xc000>;
gpio-controller;
#gpio-cells = <2>;
interrupts = <0 0xc0 0 IRQ_TYPE_NONE>,
@@ -92,7 +92,7 @@
 
pm8941_mpps: mpps@a000 {
compatible = "qcom,pm8941-mpp", "qcom,spmi-mpp";
-   reg = <0xa000 0x800>;
+   reg = <0xa000>;
gpio-controller;
#gpio-cells = <2>;
interrupts = <0 0xa0 0 IRQ_TYPE_NONE>,
@@ -107,7 +107,7 @@
 
pm8941_temp: temp-alarm@2400 {
compatible = "qcom,spmi-temp-alarm";
-   reg = <0x2400 0x100>;
+   reg = <0x2400>;
interrupts = <0 0x24 0 IRQ_TYPE_EDGE_RISING>;
io-channels = <&pm8941_vadc VADC_DIE_TEMP>;
io-channel-names = "thermal";
@@ -116,7 +116,7 @@
 
pm8941_vadc: vadc@3100 {
compatible = "qcom,spmi-vadc";
-   reg = <0x3100 0x100>;
+   reg = <0x3100>;
interrupts = <0x0 0x31 0x0 IRQ_TYPE_EDGE_RISING>;
#address-cells = <1>;
#size-cells = <0>;
@@ -141,14 +141,14 @@
 
pm8941_iadc: iadc@3600 {
compatible = "qcom,pm8941-iadc", "qcom,spmi-iadc";
-   reg = <0x3600 0x100>;
+   reg = <0x3600>;
interrupts = <0x0 0x36 0x0 IRQ_TYPE_EDGE_RISING>;
qcom,external-resistor-micro-ohms = <1>;
};
 
coincell@2800 {
compatible = "qcom,pm8941-coincell";
-   reg = <0x2800 0x100>;
+   reg = <0x2800>;
status = "disabled";
};
};
@@ -161,7 +161,7 @@
 
wled@d800 {
compatible = "qcom,pm8941-wled";
-   reg = <0x

[PATCH 2/2] ARM64: dts: qcom: Remove size elements from pmic reg properties

[Stephen Boyd]

The #size-cells for the pmics are 0, but we specify a size in the
reg property so that MPP and GPIO modules can figure out how many
pins there are. Now that we've done that by counting irqs, we can
remove the size elements in the reg properties and be DT
compliant.

Signed-off-by: Stephen Boyd 
---
 arch/arm64/boot/dts/qcom/pm8916.dtsi | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/pm8916.dtsi 
b/arch/arm64/boot/dts/qcom/pm8916.dtsi
index 37432451ee4c..f71679b15d54 100644
--- a/arch/arm64/boot/dts/qcom/pm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/pm8916.dtsi
@@ -12,7 +12,7 @@
 
rtc@6000 {
compatible = "qcom,pm8941-rtc";
-   reg = <0x6000 0x6100>;
+   reg = <0x6000>;
reg-names = "rtc", "alarm";
interrupts = <0x0 0x61 0x1 IRQ_TYPE_EDGE_RISING>;
};
@@ -27,7 +27,7 @@
 
pm8916_gpios: gpios@c000 {
compatible = "qcom,pm8916-gpio";
-   reg = <0xc000 0x400>;
+   reg = <0xc000>;
gpio-controller;
#gpio-cells = <2>;
interrupts = <0 0xc0 0 IRQ_TYPE_NONE>,
@@ -38,7 +38,7 @@
 
pm8916_mpps: mpps@a000 {
compatible = "qcom,pm8916-mpp";
-   reg = <0xa000 0x400>;
+   reg = <0xa000>;
gpio-controller;
#gpio-cells = <2>;
interrupts = <0 0xa0 0 IRQ_TYPE_NONE>,
@@ -49,7 +49,7 @@
 
pm8916_temp: temp-alarm@2400 {
compatible = "qcom,spmi-temp-alarm";
-   reg = <0x2400 0x100>;
+   reg = <0x2400>;
interrupts = <0 0x24 0 IRQ_TYPE_EDGE_RISING>;
io-channels = <&pm8916_vadc VADC_DIE_TEMP>;
io-channel-names = "thermal";
@@ -58,7 +58,7 @@
 
pm8916_vadc: vadc@3100 {
compatible = "qcom,spmi-vadc";
-   reg = <0x3100 0x100>;
+   reg = <0x3100>;
interrupts = <0x0 0x31 0x0 IRQ_TYPE_EDGE_RISING>;
#address-cells = <1>;
#size-cells = <0>;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/2] qcom: Remove size elements from pmic reg properties

[Stephen Boyd]

These patches remove the size elements from the pmic reg properties.
Technically they shouldn't be there because size-cells is 0 for the
parent node, but we've put them there so that MPP and gpio drivers
can figure out how many gpios there are.

So once the gpio and mpp drivers are fixed to count the irqs instead
of look at this reg property, we can apply this patch to remove the size
elements and be DT compliant. That would be a complicated cross-merge
between pinctrl and arm-soc trees though, so perhaps this series should
wait until the two trees meet in v4.5?

Stephen Boyd (2):
  ARM: dts: qcom: Remove size elements from pmic reg properties
  ARM64: dts: qcom: Remove size elements from pmic reg properties

 arch/arm/boot/dts/qcom-pm8841.dtsi   |  4 ++--
 arch/arm/boot/dts/qcom-pm8941.dtsi   | 22 +++---
 arch/arm64/boot/dts/qcom/pm8916.dtsi | 10 +-
 3 files changed, 18 insertions(+), 18 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/3] ARM: qcom: Make an option for qcom clocksource platforms

[Stephen Boyd]

On 11/25/15 14:08, Arnd Bergmann wrote:
> On Wednesday 25 November 2015 13:04:36 Stephen Boyd wrote:
>> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
>> index 2c2b28ee4811..999d523ac09f 100644
>> --- a/arch/arm/Makefile
>> +++ b/arch/arm/Makefile
>> @@ -148,8 +148,7 @@ textofs-$(CONFIG_PM_H1940)  := 0x00108000
>>  ifeq ($(CONFIG_ARCH_SA1100),y)
>>  textofs-$(CONFIG_SA) := 0x00208000
>>  endif
>> -textofs-$(CONFIG_ARCH_MSM8X60) := 0x00208000
>> -textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000
>> +textofs-$(CONFIG_HAVE_CLKSRC_QCOM) := 0x00208000
>>  textofs-$(CONFIG_ARCH_AXXIA) := 0x00308000
>>  
>>  # Machine directory name.  This list is sorted alphanumerically
>> diff --git a/arch/arm/mach-qcom/Kconfig b/arch/arm/mach-qcom/Kconfig
>> index 2256cd1e25d1..35a03967d9c2 100644
>> --- a/arch/arm/mach-qcom/Kconfig
>> +++ b/arch/arm/mach-qcom/Kconfig
>> @@ -10,6 +10,14 @@ menuconfig ARCH_QCOM
>>  
>>  if ARCH_QCOM
>>  
>> +config HAVE_CLKSRC_QCOM
>> +   bool "Support platforms with qcom clocksource"
>> +   default y
>> +   select CLKSRC_QCOM
>> +   help
>> + Select this option if you want to support platforms
>> + with the qcom clocksource such as MSM8660 and MSM8960.
> Hmm, if we use the option for two things, I think it could use
> a different identifier and title, as it seems counterintuitive
> to make the text offset based on the clocksource driver.

Ok.

>
> Is there any common way to classify these, e.g. calling them
> 'pre-2013 models' or 'Snapdragon S4' as a way to identify them?

I was thinking I could leave it as ARCH_MSM_8X60 because that covers the
6 and the 9, but that doesn't make me feel great. I have no idea what
Snapdragon S4 is, and that didn't exist when 8660 was first released.
pre-2013 models seems alright. Or perhaps ARCH_QCOM_PRE_8974?

Internally (and sort of leaked externally now) we called MSM8960 and its
variants A-family, and the generation after B-family, so perhaps
ARCH_QCOM_A_FAMILY would be appropriate? The problem there is no end
user knows about this distinction.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/3] ARM: qcom: Make an option for qcom clocksource platforms

[Arnd Bergmann]

On Wednesday 25 November 2015 13:04:36 Stephen Boyd wrote:
> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> index 2c2b28ee4811..999d523ac09f 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -148,8 +148,7 @@ textofs-$(CONFIG_PM_H1940)  := 0x00108000
>  ifeq ($(CONFIG_ARCH_SA1100),y)
>  textofs-$(CONFIG_SA) := 0x00208000
>  endif
> -textofs-$(CONFIG_ARCH_MSM8X60) := 0x00208000
> -textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000
> +textofs-$(CONFIG_HAVE_CLKSRC_QCOM) := 0x00208000
>  textofs-$(CONFIG_ARCH_AXXIA) := 0x00308000
>  
>  # Machine directory name.  This list is sorted alphanumerically
> diff --git a/arch/arm/mach-qcom/Kconfig b/arch/arm/mach-qcom/Kconfig
> index 2256cd1e25d1..35a03967d9c2 100644
> --- a/arch/arm/mach-qcom/Kconfig
> +++ b/arch/arm/mach-qcom/Kconfig
> @@ -10,6 +10,14 @@ menuconfig ARCH_QCOM
>  
>  if ARCH_QCOM
>  
> +config HAVE_CLKSRC_QCOM
> +   bool "Support platforms with qcom clocksource"
> +   default y
> +   select CLKSRC_QCOM
> +   help
> + Select this option if you want to support platforms
> + with the qcom clocksource such as MSM8660 and MSM8960.

Hmm, if we use the option for two things, I think it could use
a different identifier and title, as it seems counterintuitive
to make the text offset based on the clocksource driver.

Is there any common way to classify these, e.g. calling them
'pre-2013 models' or 'Snapdragon S4' as a way to identify them?

The way it appears in Kconfig also still needs to reflect how
this is a subset of the supported platforms (as your current
patch does correctly).

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 2/2] ARM: Replace calls to __aeabi_{u}idiv with udiv/sdiv instructions

[Stephen Boyd]

The ARM compiler inserts calls to __aeabi_uidiv() and
__aeabi_idiv() when it needs to perform division on signed and
unsigned integers. If a processor has support for the udiv and
sdiv division instructions the calls to these support routines
can be replaced with those instructions. Now that recordmcount
records the locations of calls to these library functions in
two sections (one for udiv and one for sdiv), iterate over these
sections early at boot and patch the call sites with the
appropriate division instruction when we determine that the
processor supports the division instructions. Using the division
instructions should be faster and less power intensive than
running the support code.

Cc: Nicolas Pitre 
Cc: Arnd Bergmann 
Cc: Steven Rostedt 
Cc: Måns Rullgård 
Cc: Thomas Petazzoni 
Signed-off-by: Stephen Boyd 
---
 arch/arm/Kconfig   | 14 +
 arch/arm/include/asm/cputype.h |  8 -
 arch/arm/include/asm/setup.h   |  3 ++
 arch/arm/kernel/module.c   | 40 +
 arch/arm/kernel/setup.c| 68 ++
 arch/arm/kernel/vmlinux.lds.S  | 13 
 6 files changed, 145 insertions(+), 1 deletion(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 0365cbbc9179..aa8bc7da6331 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1617,6 +1617,20 @@ config AEABI
 
  To use this you need GCC version 4.0.0 or later.
 
+config ARM_PATCH_UIDIV
+   bool "Runtime patch calls to __aeabi_{u}idiv() with udiv/sdiv"
+   depends on CPU_32v7 && !XIP_KERNEL && AEABI
+   help
+ Some v7 CPUs have support for the udiv and sdiv instructions
+ that can be used in place of calls to __aeabi_uidiv and __aeabi_idiv
+ functions provided by the ARM runtime ABI.
+
+ Enabling this option allows the kernel to modify itself to replace
+ branches to these library functions with the udiv and sdiv
+ instructions themselves. Typically this will be faster and less
+ power intensive than running the library support code to do
+ integer division.
+
 config OABI_COMPAT
bool "Allow old ABI binaries to run with this kernel (EXPERIMENTAL)"
depends on AEABI && !THUMB2_KERNEL
diff --git a/arch/arm/include/asm/cputype.h b/arch/arm/include/asm/cputype.h
index 85e374f873ac..48c77d422a0d 100644
--- a/arch/arm/include/asm/cputype.h
+++ b/arch/arm/include/asm/cputype.h
@@ -250,8 +250,14 @@ static inline int cpu_is_pj4(void)
 
return 0;
 }
+
+static inline bool __attribute_const__ cpu_is_pj4_nomp(void)
+{
+   return read_cpuid_part() == 0x56005810;
+}
 #else
-#define cpu_is_pj4()   0
+#define cpu_is_pj4()   0
+#define cpu_is_pj4_nomp()  0
 #endif
 
 static inline int __attribute_const__ cpuid_feature_extract_field(u32 features,
diff --git a/arch/arm/include/asm/setup.h b/arch/arm/include/asm/setup.h
index e0adb9f1bf94..a514552d5cbd 100644
--- a/arch/arm/include/asm/setup.h
+++ b/arch/arm/include/asm/setup.h
@@ -25,4 +25,7 @@ extern int arm_add_memory(u64 start, u64 size);
 extern void early_print(const char *str, ...);
 extern void dump_machine_table(void);
 
+extern void patch_udiv(void *addr, size_t size);
+extern void patch_sdiv(void *addr, size_t size);
+
 #endif
diff --git a/arch/arm/kernel/module.c b/arch/arm/kernel/module.c
index efdddcb97dd1..aa59e5cfe6a0 100644
--- a/arch/arm/kernel/module.c
+++ b/arch/arm/kernel/module.c
@@ -20,7 +20,9 @@
 #include 
 #include 
 
+#include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -51,6 +53,38 @@ void *module_alloc(unsigned long size)
 }
 #endif
 
+#ifdef CONFIG_ARM_PATCH_UIDIV
+static int module_patch_aeabi_uidiv(unsigned long loc, const Elf32_Sym *sym)
+{
+   extern char __aeabi_uidiv[], __aeabi_idiv[];
+   unsigned long udiv_addr = (unsigned long)__aeabi_uidiv;
+   unsigned long sdiv_addr = (unsigned long)__aeabi_idiv;
+   unsigned int mask;
+
+   if (IS_ENABLED(CONFIG_THUMB2_KERNEL))
+   mask = HWCAP_IDIVT;
+   else
+   mask = HWCAP_IDIVA;
+
+   if (elf_hwcap & mask) {
+   if (sym->st_value == udiv_addr) {
+   patch_udiv(&loc, sizeof(loc));
+   return 1;
+   } else if (sym->st_value == sdiv_addr) {
+   patch_sdiv(&loc, sizeof(loc));
+   return 1;
+   }
+   }
+
+   return 0;
+}
+#else
+static int module_patch_aeabi_uidiv(unsigned long loc, const Elf32_Sym *sym)
+{
+   return 0;
+}
+#endif
+
 int
 apply_relocate(Elf32_Shdr *sechdrs, const char *strtab, unsigned int symindex,
   unsigned int relindex, struct module *module)
@@ -109,6 +143,9 @@ apply_relocate(Elf32_Shdr *sechdrs, const char *strtab, 
unsigned int symindex,
return -ENOEXEC;
}
 
+   if (module_patch_aeabi_uidiv(loc, sym))
+   br

[PATCH v2 1/2] scripts: Add a recorduidiv program

[Stephen Boyd]

The ARM compiler inserts calls to __aeabi_uidiv() and
__aeabi_idiv() when it needs to perform division on signed and
unsigned integers. If a processor has support for the udiv and
sdiv division instructions the calls to these support routines
can be replaced with those instructions. Therefore, record the
location of calls to these library functions into two sections
(one for udiv and one for sdiv) similar to how we trace calls to
mcount. When the kernel boots up it will check to see if the
processor supports the instructions and then patch the call sites
with the instruction.

Cc: Nicolas Pitre 
Cc: Arnd Bergmann 
Cc: Steven Rostedt 
Cc: Måns Rullgård 
Cc: Michal Marek 
Signed-off-by: Stephen Boyd 
---
 scripts/Makefile   |   1 +
 scripts/Makefile.build |  17 +-
 scripts/recorduidiv.c  | 745 +
 3 files changed, 761 insertions(+), 2 deletions(-)
 create mode 100644 scripts/recorduidiv.c

diff --git a/scripts/Makefile b/scripts/Makefile
index fd0d53d4a234..26b9ebd8be31 100644
--- a/scripts/Makefile
+++ b/scripts/Makefile
@@ -15,6 +15,7 @@ hostprogs-$(CONFIG_KALLSYMS) += kallsyms
 hostprogs-$(CONFIG_LOGO) += pnmtologo
 hostprogs-$(CONFIG_VT)   += conmakehash
 hostprogs-$(BUILD_C_RECORDMCOUNT) += recordmcount
+hostprogs-$(CONFIG_ARM_PATCH_UIDIV) += recorduidiv
 hostprogs-$(CONFIG_BUILDTIME_EXTABLE_SORT) += sortextable
 hostprogs-$(CONFIG_ASN1)+= asn1_compiler
 hostprogs-$(CONFIG_MODULE_SIG)  += sign-file
diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index 01df30af4d4a..142e5db29d3b 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -241,12 +241,25 @@ cmd_record_mcount =   
\
fi;
 endif
 
+ifdef CONFIG_ARM_PATCH_UIDIV
+# Due to recursion, we must skip empty.o.
+# The empty.o file is created in the make process in order to determine
+#  the target endianness and word size. It is made before all other C
+#  files, including recorduidiv.
+cmd_record_uidiv = \
+   if [ $(@) != "scripts/mod/empty.o" ]; then  \
+   $(objtree)/scripts/recorduidiv "$(@)";  \
+   fi;
+recorduidiv_source := $(srctree)/scripts/recorduidiv.c
+endif
+
 define rule_cc_o_c
$(call echo-cmd,checksrc) $(cmd_checksrc) \
$(call echo-cmd,cc_o_c) $(cmd_cc_o_c);\
$(cmd_modversions)\
$(call echo-cmd,record_mcount)\
$(cmd_record_mcount)  \
+   $(call echo-cmd,record_uidiv) $(cmd_record_uidiv) \
scripts/basic/fixdep $(depfile) $@ '$(call make-cmd,cc_o_c)' >\
  $(dot-target).tmp;  \
rm -f $(depfile); \
@@ -254,13 +267,13 @@ define rule_cc_o_c
 endef
 
 # Built-in and composite module parts
-$(obj)/%.o: $(src)/%.c $(recordmcount_source) FORCE
+$(obj)/%.o: $(src)/%.c $(recordmcount_source) $(recorduidiv_source) FORCE
$(call cmd,force_checksrc)
$(call if_changed_rule,cc_o_c)
 
 # Single-part modules are special since we need to mark them in $(MODVERDIR)
 
-$(single-used-m): $(obj)/%.o: $(src)/%.c $(recordmcount_source) FORCE
+$(single-used-m): $(obj)/%.o: $(src)/%.c $(recordmcount_source) 
$(recorduidiv_source) FORCE
$(call cmd,force_checksrc)
$(call if_changed_rule,cc_o_c)
@{ echo $(@:.o=.ko); echo $@; } > $(MODVERDIR)/$(@F:.o=.mod)
diff --git a/scripts/recorduidiv.c b/scripts/recorduidiv.c
new file mode 100644
index ..a2af5c46cb6d
--- /dev/null
+++ b/scripts/recorduidiv.c
@@ -0,0 +1,745 @@
+/*
+ * recorduidiv.c: construct a table of the locations of calls to 
'__aeabi_uidiv'
+ * and '__aeabi_idiv' so that the kernel can replace them with idiv and sdiv
+ * instructions.
+ *
+ * Copyright 2009 John F. Reiser .  All rights reserved.
+ * Licensed under the GNU General Public License, version 2 (GPLv2).
+ *
+ * Restructured to fit Linux format, as well as other updates:
+ *  Copyright 2010 Steven Rostedt , Red Hat Inc.
+ *
+ * Copyright (c) 2015 The Linux Foundation. All rights reserved.
+ */
+
+/*
+ * Strategy: alter the .o file in-place.
+ *
+ * Append a new STRTAB that has the new section names, followed by a new array
+ * ElfXX_Shdr[] that has the new section headers, followed by the section
+ * contents for __udiv_loc and __idiv_loc and their relocations. The old
+ * shstrtab strings, and the old ElfXX_Shdr[] array, remain as "garbage"
+ * (commonly, a couple kilobytes.) Subsequent processing by /bin/ld (or the
+ * kernel module loader) will ignore the garbage regions, because they are not
+ * designated by the new .e_shoff nor the new ElfXX_Shdr[].  [In order to
+ * remove the garbage, then use "ld -r" to create a new file that om

[PATCH v2 0/2] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions

[Stephen Boyd]

This is a respin of a patch series from about a year ago[1]. I realized
that we already had most of the code in recordmcount to figure out
where we make calls to particular functions, so recording where
we make calls to the integer division functions should be easy enough
to add support for using the same design. Looking back on the thread
it seems like Mans was thinking along the same lines, although it wasn't
obvious to me back then or even over the last few days when I wrote this.

This series copies and reworks recordmcount to record the locations of the
calls to the library integer division functions on ARM builds, and puts those
locations into a table that we use to patch instructions at boot. The first
patch adds the recorduidiv program, and the second patch implements the
runtime patching for modules and kernel code. The module part hooks into
the relocation patching code we already have.

The discussion surrounding adding ARMv7VE so that this patchset isn't
as necessary is still on going, so I'm just sending out these patches for
now. Assuming we can come to a conclusion on how to implement ARMv7VE
I'll finish up those patches.

Comments/feedback appreciated.

Changes from v1:
 * Add suport for PJ4 udiv/sdiv mrc opcodes
 * Create a new program for recording uidiv instead of modifying recordmcount

[1] 
http://lkml.kernel.org/r/1383951632-6090-1-git-send-email-sb...@codeaurora.org

Cc: Nicolas Pitre 
Cc: Arnd Bergmann 
Cc: Steven Rostedt 
Cc: Måns Rullgård 
Cc: Thomas Petazzoni 
Cc: Michal Marek 
Cc: Russell King - ARM Linux 

Stephen Boyd (2):
  scripts: Add a recorduidiv program
  ARM: Replace calls to __aeabi_{u}idiv with udiv/sdiv instructions

 arch/arm/Kconfig   |  14 +
 arch/arm/include/asm/cputype.h |   8 +-
 arch/arm/include/asm/setup.h   |   3 +
 arch/arm/kernel/module.c   |  40 +++
 arch/arm/kernel/setup.c|  68 
 arch/arm/kernel/vmlinux.lds.S  |  13 +
 scripts/Makefile   |   1 +
 scripts/Makefile.build |  17 +-
 scripts/recorduidiv.c  | 745 +
 9 files changed, 906 insertions(+), 3 deletions(-)
 create mode 100644 scripts/recorduidiv.c

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V7 1/3] dma: qcom_bam_dma: move to qcom directory

[Andy Gross]

On Sun, Nov 22, 2015 at 09:28:23PM -0500, Sinan Kaya wrote:
> Creating a QCOM directory for all QCOM DMA source files.
> 
> Signed-off-by: Sinan Kaya 
> ---

Kind of nice having a different directory.

Reviewed-by: Andy Gross 
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] MAINTAINERS: Add rules for Qualcomm dts files

[Andy Gross]

On Mon, Nov 23, 2015 at 09:55:03PM -0800, Bjorn Andersson wrote:
> Make the get_maintainer script pick up the proper maintainers for the
> Qualcomm dts files.
> 
> Signed-off-by: Bjorn Andersson 
> ---

Good catch.  I'll queue this up.  Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: dts: qcom: msm8974: Add i2c8 node

[Andy Gross]

On Mon, Nov 23, 2015 at 09:54:34PM -0800, Bjorn Andersson wrote:
> Signed-off-by: Bjorn Andersson 
> ---
>  arch/arm/boot/dts/qcom-msm8974.dtsi | 11 +++
>  1 file changed, 11 insertions(+)
> 

Looks fine to me.   I'll queue it up.

--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: qcom: select ARM_CPU_SUSPEND for power management

[Andy Gross]

On Tue, Nov 24, 2015 at 11:13:09PM +0100, Arnd Bergmann wrote:
> The qcom spm driver uses cpu_resume_arm(), which is not included
> in the kernel in all configurations:
> 
> drivers/built-in.o: In function `qcom_cpu_spc':
> :(.text+0xbc022): undefined reference to `cpu_suspend'
> drivers/built-in.o: In function `qcom_cpuidle_init':
> :(.init.text+0x610c): undefined reference to `cpu_resume_arm'
> 
> This adds a 'select' Kconfig statement to ensure it's always
> enabled.
> 
> Signed-off-by: Arnd Bergmann 
> ---
> This has been broken for a while but not even shown up in many thousands of
> randconfig builds until today. Please queue it up for 4.5 unless you think
> it should really go into 4.4 as well.

Thanks Arnd.  I'll add this to my list for the pull request.

--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 2/3] ARM: qcom_defconfig: Enable HAVE_ARM_ARCH_TIMER

[Stephen Boyd]

Enable this config in the defconfig so that we can delete the
selection logic surrounding it that exists in mach-qcom/Kconfig.

Acked-by: Arnd Bergmann 
Signed-off-by: Stephen Boyd 
---
 arch/arm/configs/qcom_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/qcom_defconfig b/arch/arm/configs/qcom_defconfig
index ee54a706e8a3..6f34da7afd75 100644
--- a/arch/arm/configs/qcom_defconfig
+++ b/arch/arm/configs/qcom_defconfig
@@ -22,6 +22,7 @@ CONFIG_ARCH_MSM8X60=y
 CONFIG_ARCH_MSM8960=y
 CONFIG_ARCH_MSM8974=y
 CONFIG_SMP=y
+CONFIG_HAVE_ARM_ARCH_TIMER=y
 CONFIG_PREEMPT=y
 CONFIG_AEABI=y
 CONFIG_HIGHMEM=y
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 3/3] ARM: qcom: Drop ARCH_MSM* configs

[Stephen Boyd]

Drop these configs now that we select the clocksources we need
via the defconfig.

Acked-by: Arnd Bergmann 
Signed-off-by: Stephen Boyd 
---
 arch/arm/mach-qcom/Kconfig | 12 
 1 file changed, 12 deletions(-)

diff --git a/arch/arm/mach-qcom/Kconfig b/arch/arm/mach-qcom/Kconfig
index 35a03967d9c2..0945056e3cdf 100644
--- a/arch/arm/mach-qcom/Kconfig
+++ b/arch/arm/mach-qcom/Kconfig
@@ -18,16 +18,4 @@ config HAVE_CLKSRC_QCOM
  Select this option if you want to support platforms
  with the qcom clocksource such as MSM8660 and MSM8960.
 
-config ARCH_MSM8X60
-   bool "Enable support for MSM8X60"
-   select CLKSRC_QCOM
-
-config ARCH_MSM8960
-   bool "Enable support for MSM8960"
-   select CLKSRC_QCOM
-
-config ARCH_MSM8974
-   bool "Enable support for MSM8974"
-   select HAVE_ARM_ARCH_TIMER
-
 endif
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 0/3] Remove ARCH_MSM* configs

[Stephen Boyd]

This patch series allows us to remove the ARCH_MSM* configs that live
in mach-qcom/Kconfig. They're mostly proxy configs for user selectable
clocksource configurations anyway.

Changes from v1:
 * Patch 1 replaced with one that moves config to mach-qcom/Kconfig
 * Applied Arnd's acks to patches 2 and 3

Stephen Boyd (3):
  ARM: qcom: Make an option for qcom clocksource platforms
  ARM: qcom_defconfig: Enable HAVE_ARM_ARCH_TIMER
  ARM: qcom: Drop ARCH_MSM* configs

 arch/arm/Makefile   |  3 +--
 arch/arm/configs/qcom_defconfig |  1 +
 arch/arm/mach-qcom/Kconfig  | 16 ++--
 3 files changed, 8 insertions(+), 12 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/3] ARM: qcom: Make an option for qcom clocksource platforms

[Stephen Boyd]

We want to remove the ARCH_MSM* configs in mach-qcom/Kconfig
because they are mostly proxy configs for selecting the right
clocksource driver. Therefore, make a new config for platforms
that use the qcom clocksource driver. We'll also make this the
determining factor for if we should adjust the text offset by
2MB or not, because the two go hand in hand.

Cc: Arnd Bergmann 
Signed-off-by: Stephen Boyd 
---
 arch/arm/Makefile  | 3 +--
 arch/arm/mach-qcom/Kconfig | 8 
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 2c2b28ee4811..999d523ac09f 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -148,8 +148,7 @@ textofs-$(CONFIG_PM_H1940)  := 0x00108000
 ifeq ($(CONFIG_ARCH_SA1100),y)
 textofs-$(CONFIG_SA) := 0x00208000
 endif
-textofs-$(CONFIG_ARCH_MSM8X60) := 0x00208000
-textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000
+textofs-$(CONFIG_HAVE_CLKSRC_QCOM) := 0x00208000
 textofs-$(CONFIG_ARCH_AXXIA) := 0x00308000
 
 # Machine directory name.  This list is sorted alphanumerically
diff --git a/arch/arm/mach-qcom/Kconfig b/arch/arm/mach-qcom/Kconfig
index 2256cd1e25d1..35a03967d9c2 100644
--- a/arch/arm/mach-qcom/Kconfig
+++ b/arch/arm/mach-qcom/Kconfig
@@ -10,6 +10,14 @@ menuconfig ARCH_QCOM
 
 if ARCH_QCOM
 
+config HAVE_CLKSRC_QCOM
+   bool "Support platforms with qcom clocksource"
+   default y
+   select CLKSRC_QCOM
+   help
+ Select this option if you want to support platforms
+ with the qcom clocksource such as MSM8660 and MSM8960.
+
 config ARCH_MSM8X60
bool "Enable support for MSM8X60"
select CLKSRC_QCOM
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] ARM: qcom: Drop ARCH_MSM* configs

[Stephen Boyd]

On 11/25/15 12:30, Arnd Bergmann wrote:
> On Wednesday 25 November 2015 11:34:47 Stephen Boyd wrote:
>> On 11/25, Arnd Bergmann wrote:
>>> On Wednesday 25 November 2015 13:27:55 Daniel Lezcano wrote:
 What about:

 textofs-$(CONFIG_ARCH_MSM8X60) := 0x00208000
 textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000

 in arch/arm/Makefile
>>> Good point, we need to do something about these still.
>>>
>> Yeah good catch! My brain must be shutting down due to the
>> holiday coming up.
>>
>> The nice thing is that CLKSRC_QCOM and this text offset stuff are
>> always used on the same SoCs, so we should be able to make one
>> config in mach-qcom/Kconfig that selects the qcom clksrc driver
>> and adjusts the text offset. So is the suggestion to move
>> CLKSRC_QCOM to mach-qcom/Kconfig, or to make a new config that
>> selects it?
> I was thinking of a new option that selects it, which I think is
> more in line with what Daniel wants.
>
>

Ok. Sounds good. Patch will follow soon after I boot test on all the
affected devices.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] ARM: qcom: Drop ARCH_MSM* configs

[Arnd Bergmann]

On Wednesday 25 November 2015 11:34:47 Stephen Boyd wrote:
> On 11/25, Arnd Bergmann wrote:
> > On Wednesday 25 November 2015 13:27:55 Daniel Lezcano wrote:
> > > 
> > > What about:
> > > 
> > > textofs-$(CONFIG_ARCH_MSM8X60) := 0x00208000
> > > textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000
> > > 
> > > in arch/arm/Makefile
> > 
> > Good point, we need to do something about these still.
> > 
> 
> Yeah good catch! My brain must be shutting down due to the
> holiday coming up.
> 
> The nice thing is that CLKSRC_QCOM and this text offset stuff are
> always used on the same SoCs, so we should be able to make one
> config in mach-qcom/Kconfig that selects the qcom clksrc driver
> and adjusts the text offset. So is the suggestion to move
> CLKSRC_QCOM to mach-qcom/Kconfig, or to make a new config that
> selects it?

I was thinking of a new option that selects it, which I think is
more in line with what Daniel wants.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC 17/27] drivers: cpu-pd: Record CPUs that are part of the domain

[Lina Iyer]

On Wed, Nov 25 2015 at 12:12 -0700, Stephen Boyd wrote:

On 11/25/15 06:13, Lina Iyer wrote:

On Tue, Nov 24 2015 at 14:00 -0700, Stephen Boyd wrote:

On 11/17, Lina Iyer wrote:

diff --git a/drivers/base/power/cpu-pd.c b/drivers/base/power/cpu-pd.c
index 9758b8d..617ce54 100644
--- a/drivers/base/power/cpu-pd.c
+++ b/drivers/base/power/cpu-pd.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 


What's this added for?


pm_qos_request(PM_QOS_CPU_DMA_LATENCY);
Getting the PM QoS for the CPUs.



Ok. That function call is not added in this patch though.


Ah, right. Will fix.


--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project


--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] ARM: qcom: Drop ARCH_MSM* configs

[Stephen Boyd]

On 11/25, Arnd Bergmann wrote:
> On Wednesday 25 November 2015 13:27:55 Daniel Lezcano wrote:
> > 
> > What about:
> > 
> > textofs-$(CONFIG_ARCH_MSM8X60) := 0x00208000
> > textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000
> > 
> > in arch/arm/Makefile
> 
> Good point, we need to do something about these still.
> 

Yeah good catch! My brain must be shutting down due to the
holiday coming up.

The nice thing is that CLKSRC_QCOM and this text offset stuff are
always used on the same SoCs, so we should be able to make one
config in mach-qcom/Kconfig that selects the qcom clksrc driver
and adjusts the text offset. So is the suggestion to move
CLKSRC_QCOM to mach-qcom/Kconfig, or to make a new config that
selects it?

> > and
> > 
> > CONFIG_ARCH_MSM8X60=y
> > CONFIG_ARCH_MSM8960=y
> > CONFIG_ARCH_MSM8974=y
> > 
> > in arch/arm/configs/qcom_defconfig and multi_v7_defconfig
> > 
> > ?
> 
> These should be removed, but they are harmless.

Yes I was planning to let those fall out of some defconfig update
patch later on.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC 17/27] drivers: cpu-pd: Record CPUs that are part of the domain

[Stephen Boyd]

On 11/25/15 06:13, Lina Iyer wrote:
> On Tue, Nov 24 2015 at 14:00 -0700, Stephen Boyd wrote:
>> On 11/17, Lina Iyer wrote:
>>> diff --git a/drivers/base/power/cpu-pd.c b/drivers/base/power/cpu-pd.c
>>> index 9758b8d..617ce54 100644
>>> --- a/drivers/base/power/cpu-pd.c
>>> +++ b/drivers/base/power/cpu-pd.c
>>> @@ -18,6 +18,7 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>
>> What's this added for?
>>
> pm_qos_request(PM_QOS_CPU_DMA_LATENCY);
> Getting the PM QoS for the CPUs.
>

Ok. That function call is not added in this patch though.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KVM on Snapdragon 810(arm64)

[sk.syed2]

> I don't think anyone tried.
>
> My only experience with QC hardware (Snapdragon 410) is that the (non
> replaceable) firmware drops you at EL1-NS, annihilating any chance of
> running KVM (or any other hypervisor) on this HW.
>
> I wish Snapdragon 810 was different, but I haven't seen any sign of
> that so far.

Yes, same thing with 810.

-syed
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC 17/27] drivers: cpu-pd: Record CPUs that are part of the domain

[Lina Iyer]

On Tue, Nov 24 2015 at 14:00 -0700, Stephen Boyd wrote:

On 11/17, Lina Iyer wrote:

diff --git a/drivers/base/power/cpu-pd.c b/drivers/base/power/cpu-pd.c
index 9758b8d..617ce54 100644
--- a/drivers/base/power/cpu-pd.c
+++ b/drivers/base/power/cpu-pd.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 


What's this added for?


pm_qos_request(PM_QOS_CPU_DMA_LATENCY);
Getting the PM QoS for the CPUs.

-- Lina


 #include 
 #include 


--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] clocksource: defbool CLKSRC_QCOM=y on ARCH_QCOM and make it visible

[Daniel Lezcano]

On 11/25/2015 01:49 PM, Arnd Bergmann wrote:

On Wednesday 25 November 2015 13:37:53 Daniel Lezcano wrote:

On 11/25/2015 11:17 AM, Arnd Bergmann wrote:

On Wednesday 25 November 2015 11:10:49 Daniel Lezcano wrote:

On 11/25/2015 02:08 AM, Stephen Boyd wrote:

We want to remove the ARCH_MSM* configs in mach-qcom/Kconfig
because they are mostly proxy configs for selecting the right
clocksource driver. Therefore, make CLKSRC_QCOM default to the
value of ARCH_QCOM, but also make it visible if ARCH_QCOM=y so
that we can turn it off when we don't want it.


I have been removing the ARCH dependencies in the Kconfig file.

Why do you have to turn it off manually ?


The background is that this is used only on some of the older
MSM SoCs, while the newer ones use the arch timer.

We decided to remove the SoC-specific top-level options from
mach-msm as they are becoming rather meaningless these days
and just a burden to maintain at the rate that new variants
get released, so being able to turn off this driver helps make
the kernel slightly smaller if you are building a kernel for
only the more recent models.


Ok, thanks for the clarification.

I don't really like this approach even if it is correct because it
breaks the current approach I am trying to make consistent across the
drivers.

I would like to have the COMPILE_TEST option available for all the
drivers and move this option under the menu config. This patch will
prevent to do this code factoring.


How about moving the option to arch/arm/mach-qcom/Kconfig then?

We could have a user-selectable "allow use of qcom clocksource"
option there, which would then select the driver.


Yes, why not.


On the other side, this option is supposed to have a slightly smaller
kernel when it is not used. But when does it happen ? When
ARCH_MSM8X60=n and ARCH_MSM8960=n. With this patchset, I don't see the
ability to turn these SoCs off as the options are removed. So the
associated code is not removed, right ?

So why allow to turn off the timer but disallow that for the entire SoC ?


The timer is the only code that is controlled by those two options at
the moment, all the other differences between SoCs are already handled
by enabling the respective device drivers.


Ok, I see.

Thanks.

  -- Daniel


--
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] ARM: qcom: Drop ARCH_MSM* configs

[Arnd Bergmann]

On Wednesday 25 November 2015 13:27:55 Daniel Lezcano wrote:
> 
> What about:
> 
> textofs-$(CONFIG_ARCH_MSM8X60) := 0x00208000
> textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000
> 
> in arch/arm/Makefile

Good point, we need to do something about these still.

> and
> 
> CONFIG_ARCH_MSM8X60=y
> CONFIG_ARCH_MSM8960=y
> CONFIG_ARCH_MSM8974=y
> 
> in arch/arm/configs/qcom_defconfig and multi_v7_defconfig
> 
> ?

These should be removed, but they are harmless.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] clocksource: defbool CLKSRC_QCOM=y on ARCH_QCOM and make it visible

[Arnd Bergmann]

On Wednesday 25 November 2015 13:37:53 Daniel Lezcano wrote:
> On 11/25/2015 11:17 AM, Arnd Bergmann wrote:
> > On Wednesday 25 November 2015 11:10:49 Daniel Lezcano wrote:
> >> On 11/25/2015 02:08 AM, Stephen Boyd wrote:
> >>> We want to remove the ARCH_MSM* configs in mach-qcom/Kconfig
> >>> because they are mostly proxy configs for selecting the right
> >>> clocksource driver. Therefore, make CLKSRC_QCOM default to the
> >>> value of ARCH_QCOM, but also make it visible if ARCH_QCOM=y so
> >>> that we can turn it off when we don't want it.
> >>
> >> I have been removing the ARCH dependencies in the Kconfig file.
> >>
> >> Why do you have to turn it off manually ?
> >
> > The background is that this is used only on some of the older
> > MSM SoCs, while the newer ones use the arch timer.
> >
> > We decided to remove the SoC-specific top-level options from
> > mach-msm as they are becoming rather meaningless these days
> > and just a burden to maintain at the rate that new variants
> > get released, so being able to turn off this driver helps make
> > the kernel slightly smaller if you are building a kernel for
> > only the more recent models.
> 
> Ok, thanks for the clarification.
> 
> I don't really like this approach even if it is correct because it 
> breaks the current approach I am trying to make consistent across the 
> drivers.
> 
> I would like to have the COMPILE_TEST option available for all the 
> drivers and move this option under the menu config. This patch will 
> prevent to do this code factoring.

How about moving the option to arch/arm/mach-qcom/Kconfig then?

We could have a user-selectable "allow use of qcom clocksource"
option there, which would then select the driver.

> On the other side, this option is supposed to have a slightly smaller 
> kernel when it is not used. But when does it happen ? When 
> ARCH_MSM8X60=n and ARCH_MSM8960=n. With this patchset, I don't see the 
> ability to turn these SoCs off as the options are removed. So the 
> associated code is not removed, right ?
> 
> So why allow to turn off the timer but disallow that for the entire SoC ?

The timer is the only code that is controlled by those two options at
the moment, all the other differences between SoCs are already handled
by enabling the respective device drivers.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] arm64: Support VDSO remapping

[Christopher Covington]

Some applications such as Checkpoint/Restore In Userspace (CRIU) remap and
unmap the VDSO. Add support for this to the AArch64 kernel by copying in
the PowerPC code with slight modifications.

Signed-off-by: Christopher Covington 
---
 arch/arm64/include/asm/Kbuild  |  1 -
 arch/arm64/include/asm/mm-arch-hooks.h | 28 
 arch/arm64/include/asm/mmu_context.h   | 23 ++-
 3 files changed, 50 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm64/include/asm/mm-arch-hooks.h

diff --git a/arch/arm64/include/asm/Kbuild b/arch/arm64/include/asm/Kbuild
index 70fd9ff..b112a39 100644
--- a/arch/arm64/include/asm/Kbuild
+++ b/arch/arm64/include/asm/Kbuild
@@ -25,7 +25,6 @@ generic-y += kvm_para.h
 generic-y += local.h
 generic-y += local64.h
 generic-y += mcs_spinlock.h
-generic-y += mm-arch-hooks.h
 generic-y += mman.h
 generic-y += msgbuf.h
 generic-y += msi.h
diff --git a/arch/arm64/include/asm/mm-arch-hooks.h 
b/arch/arm64/include/asm/mm-arch-hooks.h
new file mode 100644
index 000..e6923fb
--- /dev/null
+++ b/arch/arm64/include/asm/mm-arch-hooks.h
@@ -0,0 +1,28 @@
+/*
+ * Architecture specific mm hooks
+ *
+ * Copyright (C) 2015, IBM Corporation
+ * Author: Laurent Dufour 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __ASM_MM_ARCH_HOOKS_H
+#define __ASM_MM_ARCH_HOOKS_H
+
+static inline void arch_remap(struct mm_struct *mm,
+ unsigned long old_start, unsigned long old_end,
+ unsigned long new_start, unsigned long new_end)
+{
+   /*
+* mremap() doesn't allow moving multiple vmas so we can limit the
+* check to old_start == vdso_base.
+*/
+   if ((void *)old_start == mm->context.vdso)
+   mm->context.vdso = (void *)new_start;
+}
+#define arch_remap arch_remap
+
+#endif /* __ASM_MM_ARCH_HOOKS_H */
diff --git a/arch/arm64/include/asm/mmu_context.h 
b/arch/arm64/include/asm/mmu_context.h
index 2416578..9fe0773 100644
--- a/arch/arm64/include/asm/mmu_context.h
+++ b/arch/arm64/include/asm/mmu_context.h
@@ -24,7 +24,6 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
 
@@ -147,4 +146,26 @@ switch_mm(struct mm_struct *prev, struct mm_struct *next,
 #define deactivate_mm(tsk,mm)  do { } while (0)
 #define activate_mm(prev,next) switch_mm(prev, next, NULL)
 
+static inline void arch_dup_mmap(struct mm_struct *oldmm,
+ struct mm_struct *mm)
+{
+}
+
+static inline void arch_exit_mmap(struct mm_struct *mm)
+{
+}
+
+static inline void arch_unmap(struct mm_struct *mm,
+ struct vm_area_struct *vma,
+ unsigned long start, unsigned long end)
+{
+   if ((void *)start <= mm->context.vdso && mm->context.vdso < (void *)end)
+   mm->context.vdso = NULL;
+}
+
+static inline void arch_bprm_mm_init(struct mm_struct *mm,
+struct vm_area_struct *vma)
+{
+}
+
 #endif
-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] clocksource: defbool CLKSRC_QCOM=y on ARCH_QCOM and make it visible

[Daniel Lezcano]

On 11/25/2015 11:17 AM, Arnd Bergmann wrote:

On Wednesday 25 November 2015 11:10:49 Daniel Lezcano wrote:

On 11/25/2015 02:08 AM, Stephen Boyd wrote:

We want to remove the ARCH_MSM* configs in mach-qcom/Kconfig
because they are mostly proxy configs for selecting the right
clocksource driver. Therefore, make CLKSRC_QCOM default to the
value of ARCH_QCOM, but also make it visible if ARCH_QCOM=y so
that we can turn it off when we don't want it.


I have been removing the ARCH dependencies in the Kconfig file.

Why do you have to turn it off manually ?


The background is that this is used only on some of the older
MSM SoCs, while the newer ones use the arch timer.

We decided to remove the SoC-specific top-level options from
mach-msm as they are becoming rather meaningless these days
and just a burden to maintain at the rate that new variants
get released, so being able to turn off this driver helps make
the kernel slightly smaller if you are building a kernel for
only the more recent models.


Ok, thanks for the clarification.

I don't really like this approach even if it is correct because it 
breaks the current approach I am trying to make consistent across the 
drivers.


I would like to have the COMPILE_TEST option available for all the 
drivers and move this option under the menu config. This patch will 
prevent to do this code factoring.


On the other side, this option is supposed to have a slightly smaller 
kernel when it is not used. But when does it happen ? When 
ARCH_MSM8X60=n and ARCH_MSM8960=n. With this patchset, I don't see the 
ability to turn these SoCs off as the options are removed. So the 
associated code is not removed, right ?


So why allow to turn off the timer but disallow that for the entire SoC ?


--
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] ARM: qcom: Drop ARCH_MSM* configs

[Daniel Lezcano]

On 11/25/2015 02:08 AM, Stephen Boyd wrote:

Drop these configs now that we select the clocksources we need
via the defconfig.

Signed-off-by: Stephen Boyd 
---
  arch/arm/mach-qcom/Kconfig | 16 
  1 file changed, 16 deletions(-)

diff --git a/arch/arm/mach-qcom/Kconfig b/arch/arm/mach-qcom/Kconfig
index 2256cd1e25d1..37572fd79c87 100644
--- a/arch/arm/mach-qcom/Kconfig
+++ b/arch/arm/mach-qcom/Kconfig
@@ -7,19 +7,3 @@ menuconfig ARCH_QCOM
select QCOM_SCM if SMP
help
  Support for Qualcomm's devicetree based systems.
-
-if ARCH_QCOM
-
-config ARCH_MSM8X60
-   bool "Enable support for MSM8X60"
-   select CLKSRC_QCOM
-
-config ARCH_MSM8960
-   bool "Enable support for MSM8960"
-   select CLKSRC_QCOM
-
-config ARCH_MSM8974
-   bool "Enable support for MSM8974"
-   select HAVE_ARM_ARCH_TIMER
-
-endif



What about:

textofs-$(CONFIG_ARCH_MSM8X60) := 0x00208000
textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000

in arch/arm/Makefile

and

CONFIG_ARCH_MSM8X60=y
CONFIG_ARCH_MSM8960=y
CONFIG_ARCH_MSM8974=y

in arch/arm/configs/qcom_defconfig and multi_v7_defconfig

?

(perhaps you already did the changes and I am not looking at the right 
branch).


--
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] clocksource: defbool CLKSRC_QCOM=y on ARCH_QCOM and make it visible

[Arnd Bergmann]

On Wednesday 25 November 2015 11:10:49 Daniel Lezcano wrote:
> On 11/25/2015 02:08 AM, Stephen Boyd wrote:
> > We want to remove the ARCH_MSM* configs in mach-qcom/Kconfig
> > because they are mostly proxy configs for selecting the right
> > clocksource driver. Therefore, make CLKSRC_QCOM default to the
> > value of ARCH_QCOM, but also make it visible if ARCH_QCOM=y so
> > that we can turn it off when we don't want it.
> 
> I have been removing the ARCH dependencies in the Kconfig file.
> 
> Why do you have to turn it off manually ?

The background is that this is used only on some of the older
MSM SoCs, while the newer ones use the arch timer.

We decided to remove the SoC-specific top-level options from
mach-msm as they are becoming rather meaningless these days
and just a burden to maintain at the rate that new variants
get released, so being able to turn off this driver helps make
the kernel slightly smaller if you are building a kernel for
only the more recent models.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] clocksource: defbool CLKSRC_QCOM=y on ARCH_QCOM and make it visible

[Daniel Lezcano]

On 11/25/2015 02:08 AM, Stephen Boyd wrote:

We want to remove the ARCH_MSM* configs in mach-qcom/Kconfig
because they are mostly proxy configs for selecting the right
clocksource driver. Therefore, make CLKSRC_QCOM default to the
value of ARCH_QCOM, but also make it visible if ARCH_QCOM=y so
that we can turn it off when we don't want it.


I have been removing the ARCH dependencies in the Kconfig file.

Why do you have to turn it off manually ?


Suggested-by: Arnd Bergmann 
Signed-off-by: Stephen Boyd 
---
  drivers/clocksource/Kconfig | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index b423785d6afc..7a5ffaa3e490 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -279,9 +279,10 @@ config EM_TIMER_STI
  such as EMEV2 from former NEC Electronics.

  config CLKSRC_QCOM
-   bool "Qualcomm MSM timer" if COMPILE_TEST
+   bool "Qualcomm MSM timer" if ARCH_QCOM || COMPILE_TEST
depends on ARM
select CLKSRC_OF
+   defbool ARCH_QCOM
help
  This enables the clocksource and the per CPU clockevent driver for the
  Qualcomm SoCs.




--
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] clocksource: defbool CLKSRC_QCOM=y on ARCH_QCOM and make it visible

[Arnd Bergmann]

On Tuesday 24 November 2015 18:07:20 Stephen Boyd wrote:
> On 11/24/15 17:08, Stephen Boyd wrote:
> > We want to remove the ARCH_MSM* configs in mach-qcom/Kconfig
> > because they are mostly proxy configs for selecting the right
> > clocksource driver. Therefore, make CLKSRC_QCOM default to the
> > value of ARCH_QCOM, but also make it visible if ARCH_QCOM=y so
> > that we can turn it off when we don't want it.
> >
> > Suggested-by: Arnd Bergmann 
> > Signed-off-by: Stephen Boyd 
> > ---
> >  drivers/clocksource/Kconfig | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
> > index b423785d6afc..7a5ffaa3e490 100644
> > --- a/drivers/clocksource/Kconfig
> > +++ b/drivers/clocksource/Kconfig
> > @@ -279,9 +279,10 @@ config EM_TIMER_STI
> > such as EMEV2 from former NEC Electronics.
> >  
> >  config CLKSRC_QCOM
> > - bool "Qualcomm MSM timer" if COMPILE_TEST
> > + bool "Qualcomm MSM timer" if ARCH_QCOM || COMPILE_TEST
> >   depends on ARM
> >   select CLKSRC_OF
> > + defbool ARCH_QCOM
> 
> Urgh. This should be def_bool
> 
> 

With this fixed, the series looks good to me. If Daniel can Ack this,
I'd suggest we take the series through arm-soc.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KVM on Snapdragon 810(arm64)

[Marc Zyngier]

On Wed, 25 Nov 2015 02:01:57 +0530
"sk.syed2"  wrote:

> Hello
>Has anyone tried to run KVM on arm64/Snapdragon platform. I am
> trying to run KVM on snapdragon 810/msm8994 platform. What is the
> stable kernel release which supports this?
> Sorry couldn't  find this information from the archives.

I don't think anyone tried.

My only experience with QC hardware (Snapdragon 410) is that the (non
replaceable) firmware drops you at EL1-NS, annihilating any chance of
running KVM (or any other hypervisor) on this HW.

I wish Snapdragon 810 was different, but I haven't seen any sign of
that so far.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny.
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html