[PATCH 0/2] Support ARM SMCC SoC vendor quirks

[Andy Gross]

At least one SoC vendor (Qualcomm) requires additional processing done
during ARM SMCCC calls.  As such, an additional parameter to the
arm_smccc_smc is required to be able to handle SoC specific quirks.

The Qualcomm quirk is necessary due to the fact that the scm call can
be interrupted on Qualcomm ARM64 platforms.  When this occurs, the
call must be restarted using information that was passed back during
the original smc call.

The first patch in this series adds a quirk structure and also adds a
quirk paramter to arm_smccc_smc calls.  All of the current users of
the call are modified to accomodate the new API parameter.

The second patch adds the Qualcomm quirk and also implements the
Qualcomm firmware changes required to handle the restarting of the
interrupted SMC call.

The original patch set for the SMCCC session ID is located at:
https://lkml.org/lkml/2016/8/20/7

Andy Gross (2):
  arm: kernel: Add SMC structure parameter
  firmware: qcom: scm: Fix interrupted SCM calls

 arch/arm/kernel/smccc-call.S |  3 ++-
 arch/arm/mach-artpec/board-artpec6.c |  2 +-
 arch/arm64/kernel/asm-offsets.c  |  7 +--
 arch/arm64/kernel/smccc-call.S   | 12 ++--
 drivers/clk/rockchip/clk-ddr.c   |  6 +++---
 drivers/devfreq/rk3399_dmc.c |  6 +++---
 drivers/firmware/meson/meson_sm.c|  2 +-
 drivers/firmware/psci.c  |  2 +-
 drivers/firmware/qcom_scm-64.c   | 13 ++---
 drivers/gpu/drm/mediatek/mtk_hdmi.c  |  2 +-
 include/linux/arm-smccc.h| 29 -
 11 files changed, 61 insertions(+), 23 deletions(-)

-- 
1.9.1

[PATCH 1/2] arm: kernel: Add SMC structure parameter

[Andy Gross]

This patch adds a quirk parameter to the arm_smccc_smc call.  The quirk
structure allows for specialized SMC operations due to SoC specific
requirements.

This patch also fixes up all the current users of the arm_smccc_smc API.

This patch and partial implementation was suggested by Will Deacon.

Signed-off-by: Andy Gross <andy.gr...@linaro.org>
---
 arch/arm/kernel/smccc-call.S |  3 ++-
 arch/arm/mach-artpec/board-artpec6.c |  2 +-
 arch/arm64/kernel/asm-offsets.c  |  7 +--
 arch/arm64/kernel/smccc-call.S   |  3 ++-
 drivers/clk/rockchip/clk-ddr.c   |  6 +++---
 drivers/devfreq/rk3399_dmc.c |  6 +++---
 drivers/firmware/meson/meson_sm.c|  2 +-
 drivers/firmware/psci.c  |  2 +-
 drivers/firmware/qcom_scm-64.c   |  4 ++--
 drivers/gpu/drm/mediatek/mtk_hdmi.c  |  2 +-
 include/linux/arm-smccc.h| 18 --
 11 files changed, 37 insertions(+), 18 deletions(-)

diff --git a/arch/arm/kernel/smccc-call.S b/arch/arm/kernel/smccc-call.S
index 37669e7..e77950a 100644
--- a/arch/arm/kernel/smccc-call.S
+++ b/arch/arm/kernel/smccc-call.S
@@ -47,7 +47,8 @@ UNWIND(   .fnend)
 /*
  * void smccc_smc(unsigned long a0, unsigned long a1, unsigned long a2,
  *   unsigned long a3, unsigned long a4, unsigned long a5,
- *   unsigned long a6, unsigned long a7, struct arm_smccc_res *res)
+ *   unsigned long a6, unsigned long a7, struct arm_smccc_res *res,
+ *   struct arm_smccc_quirk *quirk)
  */
 ENTRY(arm_smccc_smc)
SMCCC SMCCC_SMC
diff --git a/arch/arm/mach-artpec/board-artpec6.c 
b/arch/arm/mach-artpec/board-artpec6.c
index a0b1979..3a4d330 100644
--- a/arch/arm/mach-artpec/board-artpec6.c
+++ b/arch/arm/mach-artpec/board-artpec6.c
@@ -50,7 +50,7 @@ static void artpec6_l2c310_write_sec(unsigned long val, 
unsigned reg)
struct arm_smccc_res res;
 
arm_smccc_smc(SECURE_OP_L2C_WRITEREG, reg, val, 0,
- 0, 0, 0, 0, );
+ 0, 0, 0, 0, , NULL);
 
WARN_ON(res.a0);
 }
diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
index 4a2f0f0..c58ddf8 100644
--- a/arch/arm64/kernel/asm-offsets.c
+++ b/arch/arm64/kernel/asm-offsets.c
@@ -140,8 +140,11 @@ int main(void)
   DEFINE(SLEEP_STACK_DATA_SYSTEM_REGS, offsetof(struct sleep_stack_data, 
system_regs));
   DEFINE(SLEEP_STACK_DATA_CALLEE_REGS, offsetof(struct sleep_stack_data, 
callee_saved_regs));
 #endif
-  DEFINE(ARM_SMCCC_RES_X0_OFFS,offsetof(struct arm_smccc_res, a0));
-  DEFINE(ARM_SMCCC_RES_X2_OFFS,offsetof(struct arm_smccc_res, a2));
+  DEFINE(ARM_SMCCC_RES_X0_OFFS,offsetof(struct arm_smccc_res, 
a0));
+  DEFINE(ARM_SMCCC_RES_X2_OFFS,offsetof(struct arm_smccc_res, 
a2));
+  DEFINE(ARM_SMCCC_QUIRK_ID_OFFS,  offsetof(struct arm_smccc_quirk, id));
+  DEFINE(ARM_SMCCC_QUIRK_STATE_OFFS,   offsetof(struct arm_smccc_quirk, 
state));
+
   BLANK();
   DEFINE(HIBERN_PBE_ORIG,  offsetof(struct pbe, orig_address));
   DEFINE(HIBERN_PBE_ADDR,  offsetof(struct pbe, address));
diff --git a/arch/arm64/kernel/smccc-call.S b/arch/arm64/kernel/smccc-call.S
index ae0496f..7b0b3f6 100644
--- a/arch/arm64/kernel/smccc-call.S
+++ b/arch/arm64/kernel/smccc-call.S
@@ -27,7 +27,8 @@
 /*
  * void arm_smccc_smc(unsigned long a0, unsigned long a1, unsigned long a2,
  *   unsigned long a3, unsigned long a4, unsigned long a5,
- *   unsigned long a6, unsigned long a7, struct arm_smccc_res *res)
+ *   unsigned long a6, unsigned long a7, struct arm_smccc_res *res,
+ *   struct arm_smccc_quirk *quirk)
  */
 ENTRY(arm_smccc_smc)
SMCCC   smc
diff --git a/drivers/clk/rockchip/clk-ddr.c b/drivers/clk/rockchip/clk-ddr.c
index 8feba93..cbdc0f8 100644
--- a/drivers/clk/rockchip/clk-ddr.c
+++ b/drivers/clk/rockchip/clk-ddr.c
@@ -45,7 +45,7 @@ static int rockchip_ddrclk_sip_set_rate(struct clk_hw *hw, 
unsigned long drate,
spin_lock_irqsave(ddrclk->lock, flags);
arm_smccc_smc(ROCKCHIP_SIP_DRAM_FREQ, drate, 0,
  ROCKCHIP_SIP_CONFIG_DRAM_SET_RATE,
- 0, 0, 0, 0, );
+ 0, 0, 0, 0, , NULL);
spin_unlock_irqrestore(ddrclk->lock, flags);
 
return res.a0;
@@ -59,7 +59,7 @@ static int rockchip_ddrclk_sip_set_rate(struct clk_hw *hw, 
unsigned long drate,
 
arm_smccc_smc(ROCKCHIP_SIP_DRAM_FREQ, 0, 0,
  ROCKCHIP_SIP_CONFIG_DRAM_GET_RATE,
- 0, 0, 0, 0, );
+ 0, 0, 0, 0, , NULL);
 
return res.a0;
 }
@@ -72,7 +72,7 @@ static long rockchip_ddrclk_sip_round_rate(struct clk_hw *hw,
 
arm_smccc_smc(ROCKCHIP_SIP_DRAM_FREQ, rate, 0,
  ROCKCHIP_SIP_CONFIG_DRAM_ROUND_RATE,
- 0, 0, 0, 0, );
+ 0, 0, 0, 0, , NULL);
 
return res.a0;
 }
diff --git a/drivers/devfreq/rk

[PATCH 0/2] Support ARM SMCC SoC vendor quirks

[Andy Gross]

At least one SoC vendor (Qualcomm) requires additional processing done
during ARM SMCCC calls.  As such, an additional parameter to the
arm_smccc_smc is required to be able to handle SoC specific quirks.

The Qualcomm quirk is necessary due to the fact that the scm call can
be interrupted on Qualcomm ARM64 platforms.  When this occurs, the
call must be restarted using information that was passed back during
the original smc call.

The first patch in this series adds a quirk structure and also adds a
quirk paramter to arm_smccc_smc calls.  All of the current users of
the call are modified to accomodate the new API parameter.

The second patch adds the Qualcomm quirk and also implements the
Qualcomm firmware changes required to handle the restarting of the
interrupted SMC call.

The original patch set for the SMCCC session ID is located at:
https://lkml.org/lkml/2016/8/20/7

Andy Gross (2):
  arm: kernel: Add SMC structure parameter
  firmware: qcom: scm: Fix interrupted SCM calls

 arch/arm/kernel/smccc-call.S |  3 ++-
 arch/arm/mach-artpec/board-artpec6.c |  2 +-
 arch/arm64/kernel/asm-offsets.c  |  7 +--
 arch/arm64/kernel/smccc-call.S   | 12 ++--
 drivers/clk/rockchip/clk-ddr.c   |  6 +++---
 drivers/devfreq/rk3399_dmc.c |  6 +++---
 drivers/firmware/meson/meson_sm.c|  2 +-
 drivers/firmware/psci.c  |  2 +-
 drivers/firmware/qcom_scm-64.c   | 13 ++---
 drivers/gpu/drm/mediatek/mtk_hdmi.c  |  2 +-
 include/linux/arm-smccc.h| 29 -
 11 files changed, 61 insertions(+), 23 deletions(-)

-- 
1.9.1

[PATCH 1/2] arm: kernel: Add SMC structure parameter

[Andy Gross]

This patch adds a quirk parameter to the arm_smccc_smc call.  The quirk
structure allows for specialized SMC operations due to SoC specific
requirements.

This patch also fixes up all the current users of the arm_smccc_smc API.

This patch and partial implementation was suggested by Will Deacon.

Signed-off-by: Andy Gross 
---
 arch/arm/kernel/smccc-call.S |  3 ++-
 arch/arm/mach-artpec/board-artpec6.c |  2 +-
 arch/arm64/kernel/asm-offsets.c  |  7 +--
 arch/arm64/kernel/smccc-call.S   |  3 ++-
 drivers/clk/rockchip/clk-ddr.c   |  6 +++---
 drivers/devfreq/rk3399_dmc.c |  6 +++---
 drivers/firmware/meson/meson_sm.c|  2 +-
 drivers/firmware/psci.c  |  2 +-
 drivers/firmware/qcom_scm-64.c   |  4 ++--
 drivers/gpu/drm/mediatek/mtk_hdmi.c  |  2 +-
 include/linux/arm-smccc.h| 18 --
 11 files changed, 37 insertions(+), 18 deletions(-)

diff --git a/arch/arm/kernel/smccc-call.S b/arch/arm/kernel/smccc-call.S
index 37669e7..e77950a 100644
--- a/arch/arm/kernel/smccc-call.S
+++ b/arch/arm/kernel/smccc-call.S
@@ -47,7 +47,8 @@ UNWIND(   .fnend)
 /*
  * void smccc_smc(unsigned long a0, unsigned long a1, unsigned long a2,
  *   unsigned long a3, unsigned long a4, unsigned long a5,
- *   unsigned long a6, unsigned long a7, struct arm_smccc_res *res)
+ *   unsigned long a6, unsigned long a7, struct arm_smccc_res *res,
+ *   struct arm_smccc_quirk *quirk)
  */
 ENTRY(arm_smccc_smc)
SMCCC SMCCC_SMC
diff --git a/arch/arm/mach-artpec/board-artpec6.c 
b/arch/arm/mach-artpec/board-artpec6.c
index a0b1979..3a4d330 100644
--- a/arch/arm/mach-artpec/board-artpec6.c
+++ b/arch/arm/mach-artpec/board-artpec6.c
@@ -50,7 +50,7 @@ static void artpec6_l2c310_write_sec(unsigned long val, 
unsigned reg)
struct arm_smccc_res res;
 
arm_smccc_smc(SECURE_OP_L2C_WRITEREG, reg, val, 0,
- 0, 0, 0, 0, );
+ 0, 0, 0, 0, , NULL);
 
WARN_ON(res.a0);
 }
diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
index 4a2f0f0..c58ddf8 100644
--- a/arch/arm64/kernel/asm-offsets.c
+++ b/arch/arm64/kernel/asm-offsets.c
@@ -140,8 +140,11 @@ int main(void)
   DEFINE(SLEEP_STACK_DATA_SYSTEM_REGS, offsetof(struct sleep_stack_data, 
system_regs));
   DEFINE(SLEEP_STACK_DATA_CALLEE_REGS, offsetof(struct sleep_stack_data, 
callee_saved_regs));
 #endif
-  DEFINE(ARM_SMCCC_RES_X0_OFFS,offsetof(struct arm_smccc_res, a0));
-  DEFINE(ARM_SMCCC_RES_X2_OFFS,offsetof(struct arm_smccc_res, a2));
+  DEFINE(ARM_SMCCC_RES_X0_OFFS,offsetof(struct arm_smccc_res, 
a0));
+  DEFINE(ARM_SMCCC_RES_X2_OFFS,offsetof(struct arm_smccc_res, 
a2));
+  DEFINE(ARM_SMCCC_QUIRK_ID_OFFS,  offsetof(struct arm_smccc_quirk, id));
+  DEFINE(ARM_SMCCC_QUIRK_STATE_OFFS,   offsetof(struct arm_smccc_quirk, 
state));
+
   BLANK();
   DEFINE(HIBERN_PBE_ORIG,  offsetof(struct pbe, orig_address));
   DEFINE(HIBERN_PBE_ADDR,  offsetof(struct pbe, address));
diff --git a/arch/arm64/kernel/smccc-call.S b/arch/arm64/kernel/smccc-call.S
index ae0496f..7b0b3f6 100644
--- a/arch/arm64/kernel/smccc-call.S
+++ b/arch/arm64/kernel/smccc-call.S
@@ -27,7 +27,8 @@
 /*
  * void arm_smccc_smc(unsigned long a0, unsigned long a1, unsigned long a2,
  *   unsigned long a3, unsigned long a4, unsigned long a5,
- *   unsigned long a6, unsigned long a7, struct arm_smccc_res *res)
+ *   unsigned long a6, unsigned long a7, struct arm_smccc_res *res,
+ *   struct arm_smccc_quirk *quirk)
  */
 ENTRY(arm_smccc_smc)
SMCCC   smc
diff --git a/drivers/clk/rockchip/clk-ddr.c b/drivers/clk/rockchip/clk-ddr.c
index 8feba93..cbdc0f8 100644
--- a/drivers/clk/rockchip/clk-ddr.c
+++ b/drivers/clk/rockchip/clk-ddr.c
@@ -45,7 +45,7 @@ static int rockchip_ddrclk_sip_set_rate(struct clk_hw *hw, 
unsigned long drate,
spin_lock_irqsave(ddrclk->lock, flags);
arm_smccc_smc(ROCKCHIP_SIP_DRAM_FREQ, drate, 0,
  ROCKCHIP_SIP_CONFIG_DRAM_SET_RATE,
- 0, 0, 0, 0, );
+ 0, 0, 0, 0, , NULL);
spin_unlock_irqrestore(ddrclk->lock, flags);
 
return res.a0;
@@ -59,7 +59,7 @@ static int rockchip_ddrclk_sip_set_rate(struct clk_hw *hw, 
unsigned long drate,
 
arm_smccc_smc(ROCKCHIP_SIP_DRAM_FREQ, 0, 0,
  ROCKCHIP_SIP_CONFIG_DRAM_GET_RATE,
- 0, 0, 0, 0, );
+ 0, 0, 0, 0, , NULL);
 
return res.a0;
 }
@@ -72,7 +72,7 @@ static long rockchip_ddrclk_sip_round_rate(struct clk_hw *hw,
 
arm_smccc_smc(ROCKCHIP_SIP_DRAM_FREQ, rate, 0,
  ROCKCHIP_SIP_CONFIG_DRAM_ROUND_RATE,
- 0, 0, 0, 0, );
+ 0, 0, 0, 0, , NULL);
 
return res.a0;
 }
diff --git a/drivers/devfreq/rk3399_dmc.c b/drivers/d

Re: [PATCH v2] drivers: cpuidle: assign enter_freeze to same as enter callback function

[Andy Gross]

On 10 November 2016 at 08:24, Sudeep Holla <sudeep.ho...@arm.com> wrote:
> enter_freeze() callback is expected atleast to do the same as enter()
> but it has to guarantee that interrupts aren't enabled at any point
> in its execution, as the tick is frozen.
>
> CPUs execute ->enter_freeze with the local tick or entire timekeeping
> suspended, so it must not re-enable interrupts at any point (even
> temporarily) or attempt to change states of clock event devices.
>
> It will be called when the system goes to suspend-to-idle and will
> reduce power usage because CPUs won't be awaken for unnecessary IRQs
> (i.e. woken up only on IRQs from "wakeup sources")
>
> We can reuse the same code for both the enter() and enter_freeze()
> callbacks as along as they don't re-enable interrupts. Only "coupled"
> cpuidle mechanism enables interrupts and doing that with timekeeping
> suspended is generally not safe.
>
> Since this generic DT based idle driver doesn't support "coupled"
> states, it is safe to assume that the interrupts are not re-enabled.
>
> This patch assign enter_freeze to same as enter callback function which
> helps to save power without any intermittent spurious wakeups from
> suspend-to-idle.
>
> Cc: "Rafael J. Wysocki" <r...@rjwysocki.net>
> Signed-off-by: Sudeep Holla <sudeep.ho...@arm.com>

Tested this on a Qualcomm 410c dragonboard.  Worked great.  Thanks for
the patch!


Tested-by: Andy Gross <andy.gr...@linaro.org>

Re: [PATCH v2] drivers: cpuidle: assign enter_freeze to same as enter callback function

[Andy Gross]

On 10 November 2016 at 08:24, Sudeep Holla  wrote:
> enter_freeze() callback is expected atleast to do the same as enter()
> but it has to guarantee that interrupts aren't enabled at any point
> in its execution, as the tick is frozen.
>
> CPUs execute ->enter_freeze with the local tick or entire timekeeping
> suspended, so it must not re-enable interrupts at any point (even
> temporarily) or attempt to change states of clock event devices.
>
> It will be called when the system goes to suspend-to-idle and will
> reduce power usage because CPUs won't be awaken for unnecessary IRQs
> (i.e. woken up only on IRQs from "wakeup sources")
>
> We can reuse the same code for both the enter() and enter_freeze()
> callbacks as along as they don't re-enable interrupts. Only "coupled"
> cpuidle mechanism enables interrupts and doing that with timekeeping
> suspended is generally not safe.
>
> Since this generic DT based idle driver doesn't support "coupled"
> states, it is safe to assume that the interrupts are not re-enabled.
>
> This patch assign enter_freeze to same as enter callback function which
> helps to save power without any intermittent spurious wakeups from
> suspend-to-idle.
>
> Cc: "Rafael J. Wysocki" 
> Signed-off-by: Sudeep Holla 

Tested this on a Qualcomm 410c dragonboard.  Worked great.  Thanks for
the patch!


Tested-by: Andy Gross 

Re: [PATCH 2/2] soc: qcom: smem_state: Fix include for ERR_PTR()

[Andy Gross]

On 9 November 2016 at 12:02, Bjorn Andersson <bjorn.anders...@linaro.org> wrote:
> The correct include file for getting errno constants and ERR_PTR() is
> linux/err.h, rather than linux/errno.h, so fix the include.
>
> Fixes: e8b123e60084 ("soc: qcom: smem_state: Add stubs for disabled 
> smem_state")
> Signed-off-by: Bjorn Andersson <bjorn.anders...@linaro.org>
> ---
>
> Andy, I don't see anything else going into v4.10 for smem_state.h. So if you
> are okay I would like Kalle to pick this patch through his tree and be able to
> merge my wcn36xx patches for v4.10.
>
>  include/linux/soc/qcom/smem_state.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/soc/qcom/smem_state.h 
> b/include/linux/soc/qcom/smem_state.h
> index 7b88697929e9..b8478ee7a71f 100644
> --- a/include/linux/soc/qcom/smem_state.h
> +++ b/include/linux/soc/qcom/smem_state.h
> @@ -1,7 +1,7 @@
>  #ifndef __QCOM_SMEM_STATE__
>  #define __QCOM_SMEM_STATE__
>
> -#include 
> +#include 
>
>  struct device_node;
>  struct qcom_smem_state;
> --
> 2.5.0
>

This time with less html.

Acked-by: Andy Gross <andy.gr...@linaro.org>

Re: [PATCH 2/2] soc: qcom: smem_state: Fix include for ERR_PTR()

[Andy Gross]

On 9 November 2016 at 12:02, Bjorn Andersson  wrote:
> The correct include file for getting errno constants and ERR_PTR() is
> linux/err.h, rather than linux/errno.h, so fix the include.
>
> Fixes: e8b123e60084 ("soc: qcom: smem_state: Add stubs for disabled 
> smem_state")
> Signed-off-by: Bjorn Andersson 
> ---
>
> Andy, I don't see anything else going into v4.10 for smem_state.h. So if you
> are okay I would like Kalle to pick this patch through his tree and be able to
> merge my wcn36xx patches for v4.10.
>
>  include/linux/soc/qcom/smem_state.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/soc/qcom/smem_state.h 
> b/include/linux/soc/qcom/smem_state.h
> index 7b88697929e9..b8478ee7a71f 100644
> --- a/include/linux/soc/qcom/smem_state.h
> +++ b/include/linux/soc/qcom/smem_state.h
> @@ -1,7 +1,7 @@
>  #ifndef __QCOM_SMEM_STATE__
>  #define __QCOM_SMEM_STATE__
>
> -#include 
> +#include 
>
>  struct device_node;
>  struct qcom_smem_state;
> --
> 2.5.0
>

This time with less html.

Acked-by: Andy Gross 

Re: [PATCH/RESEND] thermal: qcom-spmi: Treat reg property as a single cell

[Andy Gross]

On Tue, Oct 18, 2016 at 04:40:19PM -0700, Stephen Boyd wrote:
> We only read the first element of the reg property to figure out
> the offset of the temperature sensor inside the PMIC.
> Furthermore, we want to remove the second element in DT, so just
> don't read the second element so that probe keeps working if we
> change the DT in the future.
> 
> Cc: Ivan T. Ivanov <iivanov...@gmail.com>
> Signed-off-by: Stephen Boyd <sb...@codeaurora.org>

Reviewed-by: Andy Gross <andy.gr...@linaro.org>

Re: [PATCH/RESEND] thermal: qcom-spmi: Treat reg property as a single cell

[Andy Gross]

On Tue, Oct 18, 2016 at 04:40:19PM -0700, Stephen Boyd wrote:
> We only read the first element of the reg property to figure out
> the offset of the temperature sensor inside the PMIC.
> Furthermore, we want to remove the second element in DT, so just
> don't read the second element so that probe keeps working if we
> change the DT in the future.
> 
> Cc: Ivan T. Ivanov 
> Signed-off-by: Stephen Boyd 

Reviewed-by: Andy Gross 

Re: [PATCH 1/2] pinctrl: pm8994: add pad voltage regulator defines

[Andy Gross]

On Sun, Sep 18, 2016 at 01:38:30PM +0200, Linus Walleij wrote:
> On Fri, Sep 16, 2016 at 7:41 PM, Srinivas Kandagatla
>  wrote:
> 
> > This patch adds defines for internal voltage regulators used
> > to switch voltage levels on gpio/mpp pads.
> >
> > Signed-off-by: Srinivas Kandagatla 
> 
> Acked-by: Linus Walleij 
> 
> Andy can merge this with the rest of the stuff to the Qualcomm SoC tree.

Yup.  Picked it up.  Thanks!


Andy

Re: [PATCH 1/2] pinctrl: pm8994: add pad voltage regulator defines

[Andy Gross]

On Sun, Sep 18, 2016 at 01:38:30PM +0200, Linus Walleij wrote:
> On Fri, Sep 16, 2016 at 7:41 PM, Srinivas Kandagatla
>  wrote:
> 
> > This patch adds defines for internal voltage regulators used
> > to switch voltage levels on gpio/mpp pads.
> >
> > Signed-off-by: Srinivas Kandagatla 
> 
> Acked-by: Linus Walleij 
> 
> Andy can merge this with the rest of the stuff to the Qualcomm SoC tree.

Yup.  Picked it up.  Thanks!


Andy

Re: [PATCH 1/4] arm64: dts: msm8996: Add SMEM reserve-memory node

[Andy Gross]

On Thu, Oct 20, 2016 at 02:16:41PM -0700, Sarangdhar Joshi wrote:
> On 10/20/2016 12:57 PM, Bjorn Andersson wrote:
> >On Thu 20 Oct 11:56 PDT 2016, Sarangdhar Joshi wrote:
> >
> >>Add DT node to carveout memory for shared memory region.
> >>
> >
> >Reviewed-by: Bjorn Andersson 
> 
> Thanks for reviewing.
> 

All of the patches looked good.  I do agree with Bjorn's comments on the other
patch.  When you resend these, please use a cover letter and a V2.  I'll then
pick them up for the next pull request.

Thanks for sending these!

Andy

Re: [PATCH 1/4] arm64: dts: msm8996: Add SMEM reserve-memory node

[Andy Gross]

On Thu, Oct 20, 2016 at 02:16:41PM -0700, Sarangdhar Joshi wrote:
> On 10/20/2016 12:57 PM, Bjorn Andersson wrote:
> >On Thu 20 Oct 11:56 PDT 2016, Sarangdhar Joshi wrote:
> >
> >>Add DT node to carveout memory for shared memory region.
> >>
> >
> >Reviewed-by: Bjorn Andersson 
> 
> Thanks for reviewing.
> 

All of the patches looked good.  I do agree with Bjorn's comments on the other
patch.  When you resend these, please use a cover letter and a V2.  I'll then
pick them up for the next pull request.

Thanks for sending these!

Andy

Re: [PATCH 3/4] arm64: dts: msm8996: Add SMEM DT nodes

[Andy Gross]

On Thu, Oct 20, 2016 at 02:18:33PM -0700, Sarangdhar Joshi wrote:
> On 10/20/2016 12:56 PM, Bjorn Andersson wrote:
> >On Thu 20 Oct 11:56 PDT 2016, Sarangdhar Joshi wrote:
> >
> >>From: Bjorn Andersson 
> >>
> >>Add SMEM and TCSR DT nodes on MSM8996.
> >>
> >>Signed-off-by: Bjorn Andersson 
> >>Signed-off-by: Sarangdhar Joshi 
> >>---
> >> arch/arm64/boot/dts/qcom/msm8996.dtsi | 19 +++
> >> 1 file changed, 19 insertions(+)
> >>
> >>diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi 
> >>b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> >>index 949b096..0a810f5 100644
> >>--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
> >>+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> >>@@ -169,12 +169,31 @@
> >>method = "smc";
> >>};
> >>
> >>+   smem {
> >>+   compatible = "qcom,smem";
> >>+
> >>+   memory-region = <_mem>;
> >>+
> >>+   hwlocks = <_mutex 3>;
> >>+   };
> >>+
> >>soc: soc {
> >>#address-cells = <1>;
> >>#size-cells = <1>;
> >>ranges = <0 0 0 0x>;
> >>compatible = "simple-bus";
> >>
> >>+   tcsr_mutex_regs: syscon@74 {
> >>+   compatible = "syscon";
> >>+   reg = <0x74 0x2>;
> >>+   };
> >>+
> >>+   tcsr_mutex: hwlock {
> >>+   compatible = "qcom,tcsr-mutex";
> >>+   syscon = <_mutex_regs 0 0x1000>;
> >>+   #hwlock-cells = <1>;
> >>+   };
> >
> >Sorry, I got this in the wrong place, the hwlock node should sit outside
> >of soc {} - looks like we got this wrong in msm8916 as well.
> 
> Thanks for reviewing the patch. Do you mean to move it under / {}; (i.e.
> root)?

Yes.  Any node that doesn't have reg properties should go under the root.


Andy

Re: [PATCH 3/4] arm64: dts: msm8996: Add SMEM DT nodes

[Andy Gross]

On Thu, Oct 20, 2016 at 02:18:33PM -0700, Sarangdhar Joshi wrote:
> On 10/20/2016 12:56 PM, Bjorn Andersson wrote:
> >On Thu 20 Oct 11:56 PDT 2016, Sarangdhar Joshi wrote:
> >
> >>From: Bjorn Andersson 
> >>
> >>Add SMEM and TCSR DT nodes on MSM8996.
> >>
> >>Signed-off-by: Bjorn Andersson 
> >>Signed-off-by: Sarangdhar Joshi 
> >>---
> >> arch/arm64/boot/dts/qcom/msm8996.dtsi | 19 +++
> >> 1 file changed, 19 insertions(+)
> >>
> >>diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi 
> >>b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> >>index 949b096..0a810f5 100644
> >>--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
> >>+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> >>@@ -169,12 +169,31 @@
> >>method = "smc";
> >>};
> >>
> >>+   smem {
> >>+   compatible = "qcom,smem";
> >>+
> >>+   memory-region = <_mem>;
> >>+
> >>+   hwlocks = <_mutex 3>;
> >>+   };
> >>+
> >>soc: soc {
> >>#address-cells = <1>;
> >>#size-cells = <1>;
> >>ranges = <0 0 0 0x>;
> >>compatible = "simple-bus";
> >>
> >>+   tcsr_mutex_regs: syscon@74 {
> >>+   compatible = "syscon";
> >>+   reg = <0x74 0x2>;
> >>+   };
> >>+
> >>+   tcsr_mutex: hwlock {
> >>+   compatible = "qcom,tcsr-mutex";
> >>+   syscon = <_mutex_regs 0 0x1000>;
> >>+   #hwlock-cells = <1>;
> >>+   };
> >
> >Sorry, I got this in the wrong place, the hwlock node should sit outside
> >of soc {} - looks like we got this wrong in msm8916 as well.
> 
> Thanks for reviewing the patch. Do you mean to move it under / {}; (i.e.
> root)?

Yes.  Any node that doesn't have reg properties should go under the root.


Andy

Re: [PATCH] soc: qcom: Add SoC info driver

[Andy Gross]

On Thu, Oct 20, 2016 at 07:36:22PM +0530, Imran Khan wrote:
> The SoC info driver provides information such as Chip ID,
> Chip family, serial number and other such details about
> Qualcomm SoCs.
> 
> Signed-off-by: Imran Khan 
> ---
>  .../devicetree/bindings/soc/qcom/qcom,socinfo.txt  |   18 +
>  drivers/soc/qcom/socinfo.c | 1173 
> 

1173 lines!!  To latch smem entry and read/process those contents?

>  include/linux/soc/qcom/socinfo.h   |  198 
>  3 files changed, 1389 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/soc/qcom/qcom,socinfo.txt
>  create mode 100644 drivers/soc/qcom/socinfo.c
>  create mode 100644 include/linux/soc/qcom/socinfo.h
> 
> diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,socinfo.txt 
> b/Documentation/devicetree/bindings/soc/qcom/qcom,socinfo.txt
> new file mode 100644
> index 000..1f26299
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,socinfo.txt
> @@ -0,0 +1,18 @@
> +Qualcomm SoC Information (socinfo) Driver binding
> +
> +This binding describes the Qualcomm SoC Information Driver, which provides
> +information such as chip id, chip family, serial number and other such
> +details about Qualcomm SoCs.
> +
> +- compatible:
> + Usage: required
> + Value type: 
> + Definition: must be "qcom,socinfo"
> +
> += EXAMPLE
> +
> +The following example represents a socinfo node.
> +
> + socinfo {
> + compatible = "qcom,socinfo";
> + };

Let's drop adding a new binding.  Let's roll this into the smem driver itself.

> diff --git a/drivers/soc/qcom/socinfo.c b/drivers/soc/qcom/socinfo.c
> new file mode 100644
> index 000..dc26028
> --- /dev/null
> +++ b/drivers/soc/qcom/socinfo.c
> @@ -0,0 +1,1173 @@
> +/*
> + * Copyright (c) 2009-2016, 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.
> + *
> + */
> +
> +/*
> + * SOC Info Routines
> + *
> + */
> +
> +#define pr_fmt(fmt) "%s: " fmt, __func__
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +
> +#define BUILD_ID_LENGTH 32

This needs to be more specific.  SMEM_SOCINFO_XXX

> +#define SMEM_IMAGE_VERSION_BLOCKS_COUNT 32
> +#define SMEM_IMAGE_VERSION_SINGLE_BLOCK_SIZE 128
> +#define SMEM_IMAGE_VERSION_SIZE 4096
> +#define SMEM_IMAGE_VERSION_NAME_SIZE 75
> +#define SMEM_IMAGE_VERSION_VARIANT_SIZE 20
> +#define SMEM_IMAGE_VERSION_VARIANT_OFFSET 75
> +#define SMEM_IMAGE_VERSION_OEM_SIZE 32
> +#define SMEM_IMAGE_VERSION_OEM_OFFSET 96
> +#define SMEM_IMAGE_VERSION_PARTITION_APPS 10
> +#define SMEM_ITEM_SIZE_ALIGN 8
> +/*
> + * Shared memory identifiers, used to acquire handles to respective memory
> + * region.
> + */
> +#define SMEM_IMAGE_VERSION_TABLE 469
> +#define SMEM_HW_SW_BUILD_ID  137
> +



> +static enum qcom_cpu cur_cpu;
> +static int current_image;
> +static uint32_t socinfo_format;
> +
> +static struct socinfo_v0_1 dummy_socinfo = {
> + .format = SOCINFO_VERSION(0, 1),
> + .version = 1,
> +};

Instead of having a dummy, can we just fail if we don't find a match?  And by
fail, I mean having an 'unknown' cpu?

> +
> +static char *socinfo_get_id_string(void)
> +{
> + return (socinfo) ? cpu_of_id[socinfo->v0_1.id].soc_id_string : NULL;
> +}
> +



> +uint32_t socinfo_get_id(void)
> +{
> + return (socinfo) ? socinfo->v0_1.id : 0;
> +}
> +EXPORT_SYMBOL_GPL(socinfo_get_id);

Why do we have EXPORTS at all?  Drivers should be using compatibles to figure
out what they are.



> +/* socinfo: sysfs functions */
> +
> +static ssize_t
> +qcom_get_vendor(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + return snprintf(buf, PAGE_SIZE, "Qualcomm\n");
> +}
> +
> +static ssize_t
> +qcom_get_raw_id(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + return snprintf(buf, PAGE_SIZE, "%u\n",
> + socinfo_get_raw_id());
> +}
> +



> +static void * __init setup_dummy_socinfo(void)
> +{
> + if (early_machine_is_apq8064()) {
> + dummy_socinfo.id = APQ_8064_ID;
> + strlcpy(dummy_socinfo.build_id, "apq8064",
> + sizeof(dummy_socinfo.build_id));
> + } else if (early_machine_is_apq8084()) {
> + dummy_socinfo.id = APQ_8084_ID;
> + 

Re: [PATCH] soc: qcom: Add SoC info driver

[Andy Gross]

On Thu, Oct 20, 2016 at 07:36:22PM +0530, Imran Khan wrote:
> The SoC info driver provides information such as Chip ID,
> Chip family, serial number and other such details about
> Qualcomm SoCs.
> 
> Signed-off-by: Imran Khan 
> ---
>  .../devicetree/bindings/soc/qcom/qcom,socinfo.txt  |   18 +
>  drivers/soc/qcom/socinfo.c | 1173 
> 

1173 lines!!  To latch smem entry and read/process those contents?

>  include/linux/soc/qcom/socinfo.h   |  198 
>  3 files changed, 1389 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/soc/qcom/qcom,socinfo.txt
>  create mode 100644 drivers/soc/qcom/socinfo.c
>  create mode 100644 include/linux/soc/qcom/socinfo.h
> 
> diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,socinfo.txt 
> b/Documentation/devicetree/bindings/soc/qcom/qcom,socinfo.txt
> new file mode 100644
> index 000..1f26299
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,socinfo.txt
> @@ -0,0 +1,18 @@
> +Qualcomm SoC Information (socinfo) Driver binding
> +
> +This binding describes the Qualcomm SoC Information Driver, which provides
> +information such as chip id, chip family, serial number and other such
> +details about Qualcomm SoCs.
> +
> +- compatible:
> + Usage: required
> + Value type: 
> + Definition: must be "qcom,socinfo"
> +
> += EXAMPLE
> +
> +The following example represents a socinfo node.
> +
> + socinfo {
> + compatible = "qcom,socinfo";
> + };

Let's drop adding a new binding.  Let's roll this into the smem driver itself.

> diff --git a/drivers/soc/qcom/socinfo.c b/drivers/soc/qcom/socinfo.c
> new file mode 100644
> index 000..dc26028
> --- /dev/null
> +++ b/drivers/soc/qcom/socinfo.c
> @@ -0,0 +1,1173 @@
> +/*
> + * Copyright (c) 2009-2016, 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.
> + *
> + */
> +
> +/*
> + * SOC Info Routines
> + *
> + */
> +
> +#define pr_fmt(fmt) "%s: " fmt, __func__
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +
> +#define BUILD_ID_LENGTH 32

This needs to be more specific.  SMEM_SOCINFO_XXX

> +#define SMEM_IMAGE_VERSION_BLOCKS_COUNT 32
> +#define SMEM_IMAGE_VERSION_SINGLE_BLOCK_SIZE 128
> +#define SMEM_IMAGE_VERSION_SIZE 4096
> +#define SMEM_IMAGE_VERSION_NAME_SIZE 75
> +#define SMEM_IMAGE_VERSION_VARIANT_SIZE 20
> +#define SMEM_IMAGE_VERSION_VARIANT_OFFSET 75
> +#define SMEM_IMAGE_VERSION_OEM_SIZE 32
> +#define SMEM_IMAGE_VERSION_OEM_OFFSET 96
> +#define SMEM_IMAGE_VERSION_PARTITION_APPS 10
> +#define SMEM_ITEM_SIZE_ALIGN 8
> +/*
> + * Shared memory identifiers, used to acquire handles to respective memory
> + * region.
> + */
> +#define SMEM_IMAGE_VERSION_TABLE 469
> +#define SMEM_HW_SW_BUILD_ID  137
> +



> +static enum qcom_cpu cur_cpu;
> +static int current_image;
> +static uint32_t socinfo_format;
> +
> +static struct socinfo_v0_1 dummy_socinfo = {
> + .format = SOCINFO_VERSION(0, 1),
> + .version = 1,
> +};

Instead of having a dummy, can we just fail if we don't find a match?  And by
fail, I mean having an 'unknown' cpu?

> +
> +static char *socinfo_get_id_string(void)
> +{
> + return (socinfo) ? cpu_of_id[socinfo->v0_1.id].soc_id_string : NULL;
> +}
> +



> +uint32_t socinfo_get_id(void)
> +{
> + return (socinfo) ? socinfo->v0_1.id : 0;
> +}
> +EXPORT_SYMBOL_GPL(socinfo_get_id);

Why do we have EXPORTS at all?  Drivers should be using compatibles to figure
out what they are.



> +/* socinfo: sysfs functions */
> +
> +static ssize_t
> +qcom_get_vendor(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + return snprintf(buf, PAGE_SIZE, "Qualcomm\n");
> +}
> +
> +static ssize_t
> +qcom_get_raw_id(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + return snprintf(buf, PAGE_SIZE, "%u\n",
> + socinfo_get_raw_id());
> +}
> +



> +static void * __init setup_dummy_socinfo(void)
> +{
> + if (early_machine_is_apq8064()) {
> + dummy_socinfo.id = APQ_8064_ID;
> + strlcpy(dummy_socinfo.build_id, "apq8064",
> + sizeof(dummy_socinfo.build_id));
> + } else if (early_machine_is_apq8084()) {
> + dummy_socinfo.id = APQ_8084_ID;
> + strlcpy(dummy_socinfo.build_id, "apq8084",
> 

Re: [PATCH] ARM: dts: msm8974: Add definitions for QCE & cryptobam

[Andy Gross]

On Fri, Sep 16, 2016 at 08:38:01PM +0300, Iaroslav Gridin wrote:
> On Thu, Sep 15, 2016 at 04:18:42PM -0500, Andy Gross wrote:
>  
> > Actually, on thinking about this more, the bam block itself only requires 
> > the
> > single clock.  The peripheral it is attached to has to keep its sanity 
> > during
> > the duration of the transfer (crypto).  The crypto requires 3 clocks, one of
> > which is the same clk the bam requires.
> > 
> > You can access the BAM registers with the bam_clk only, correct?
> 
> Not preparing bam_clk degrades QCE performance about 3x, though.

If the CE2_CLK is the only required clk, that makes it the "bam_clk".  I see the
crypto requires getting all three clocks: AXI (bus), AHB (iface), and CE2 (core)

If the crypto is active during DMA transfers, which it has to be, then the
performance shouldn't degrade due to the BAM not preparing the AHB.

Regards,

Andy

Re: [PATCH] ARM: dts: msm8974: Add definitions for QCE & cryptobam

[Andy Gross]

On Fri, Sep 16, 2016 at 08:38:01PM +0300, Iaroslav Gridin wrote:
> On Thu, Sep 15, 2016 at 04:18:42PM -0500, Andy Gross wrote:
>  
> > Actually, on thinking about this more, the bam block itself only requires 
> > the
> > single clock.  The peripheral it is attached to has to keep its sanity 
> > during
> > the duration of the transfer (crypto).  The crypto requires 3 clocks, one of
> > which is the same clk the bam requires.
> > 
> > You can access the BAM registers with the bam_clk only, correct?
> 
> Not preparing bam_clk degrades QCE performance about 3x, though.

If the CE2_CLK is the only required clk, that makes it the "bam_clk".  I see the
crypto requires getting all three clocks: AXI (bus), AHB (iface), and CE2 (core)

If the crypto is active during DMA transfers, which it has to be, then the
performance shouldn't degrade due to the BAM not preparing the AHB.

Regards,

Andy

Re: [PATCH] ARM: dts: msm8974: Add definitions for QCE & cryptobam

[Andy Gross]

On Tue, Aug 30, 2016 at 06:37:40PM +0300, Iaroslav Gridin wrote:
> From: Voker57 
> 
> Add device tree definitions for Qualcomm Cryptography engine and its BAM
> Signed-off-by: Iaroslav Gridin 
> ---
>  arch/arm/boot/dts/qcom-msm8974.dtsi | 42 
> +
>  1 file changed, 42 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi 
> b/arch/arm/boot/dts/qcom-msm8974.dtsi
> index 561d4d1..c0da739 100644
> --- a/arch/arm/boot/dts/qcom-msm8974.dtsi
> +++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
> @@ -287,6 +287,48 @@
>   reg = <0xf9011000 0x1000>;
>   };
>  
> + cryptobam: dma@fd444000 {
> + compatible = "qcom,bam-v1.4.0";
> + reg = <0xfd444000 0x15000>;
> + interrupts = <0 236 0>;
> + clocks = < GCC_CE2_AHB_CLK>,
> +  < GCC_CE2_AXI_CLK>,
> +  < GCC_CE2_CLK>;
> + clock-names = "bam_clk", "axi_clk", "core_clk";

Actually, on thinking about this more, the bam block itself only requires the
single clock.  The peripheral it is attached to has to keep its sanity during
the duration of the transfer (crypto).  The crypto requires 3 clocks, one of
which is the same clk the bam requires.

You can access the BAM registers with the bam_clk only, correct?


> + #dma-cells = <1>;
> + qcom,ee = <1>;
> + qcom,controlled-remotely;
> + };
> +
> + qcom,qcrypto@fd44 {
> + compatible = "qcom,crypto-v5.1";
> + reg = <0xfd45a000 0x6000>;
> + reg-names = "crypto-base";
> + interrupts = <0 236 0>;
> + qcom,bam-pipe-pair = <2>;
> + qcom,ce-hw-instance = <1>;
> + qcom,ce-device = <0>;
> + clocks = < GCC_CE2_CLK>,
> +  < GCC_CE2_AHB_CLK>,
> +  < GCC_CE2_AXI_CLK>,
> +  < CE2_CLK_SRC>;

The CLK_SRC is unnecessary.  Or should be at least.  That gets turned on by
getting the CE2_CLK.  I vaguely remember a parent issue that was fixed.

> +
> + dmas = < 2>, < 3>;
> + dma-names = "rx", "tx";
> + clock-names = "core", "iface", "bus", "core_src";
> + qcom,clk-mgmt-sus-res;
> + qcom,msm-bus,name = "qcrypto-noc";
> +
> + qcom,msm-bus,num-cases = <2>;
> + qcom,msm-bus,num-paths = <1>;
> + qcom,use-sw-aes-cbc-ecb-ctr-algo;
> + qcom,use-sw-aes-xts-algo;
> + qcom,use-sw-ahash-algo;
> + qcom,msm-bus,vectors-KBps = <56 512 0 0>,
> + <56 512 3936000 393600>;
> + };
> +
> +
>   timer@f902 {
>   #address-cells = <1>;
>   #size-cells = <1>;

Regards,

Andy

Re: [PATCH] ARM: dts: msm8974: Add definitions for QCE & cryptobam

[Andy Gross]

On Tue, Aug 30, 2016 at 06:37:40PM +0300, Iaroslav Gridin wrote:
> From: Voker57 
> 
> Add device tree definitions for Qualcomm Cryptography engine and its BAM
> Signed-off-by: Iaroslav Gridin 
> ---
>  arch/arm/boot/dts/qcom-msm8974.dtsi | 42 
> +
>  1 file changed, 42 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi 
> b/arch/arm/boot/dts/qcom-msm8974.dtsi
> index 561d4d1..c0da739 100644
> --- a/arch/arm/boot/dts/qcom-msm8974.dtsi
> +++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
> @@ -287,6 +287,48 @@
>   reg = <0xf9011000 0x1000>;
>   };
>  
> + cryptobam: dma@fd444000 {
> + compatible = "qcom,bam-v1.4.0";
> + reg = <0xfd444000 0x15000>;
> + interrupts = <0 236 0>;
> + clocks = < GCC_CE2_AHB_CLK>,
> +  < GCC_CE2_AXI_CLK>,
> +  < GCC_CE2_CLK>;
> + clock-names = "bam_clk", "axi_clk", "core_clk";

Actually, on thinking about this more, the bam block itself only requires the
single clock.  The peripheral it is attached to has to keep its sanity during
the duration of the transfer (crypto).  The crypto requires 3 clocks, one of
which is the same clk the bam requires.

You can access the BAM registers with the bam_clk only, correct?


> + #dma-cells = <1>;
> + qcom,ee = <1>;
> + qcom,controlled-remotely;
> + };
> +
> + qcom,qcrypto@fd44 {
> + compatible = "qcom,crypto-v5.1";
> + reg = <0xfd45a000 0x6000>;
> + reg-names = "crypto-base";
> + interrupts = <0 236 0>;
> + qcom,bam-pipe-pair = <2>;
> + qcom,ce-hw-instance = <1>;
> + qcom,ce-device = <0>;
> + clocks = < GCC_CE2_CLK>,
> +  < GCC_CE2_AHB_CLK>,
> +  < GCC_CE2_AXI_CLK>,
> +  < CE2_CLK_SRC>;

The CLK_SRC is unnecessary.  Or should be at least.  That gets turned on by
getting the CE2_CLK.  I vaguely remember a parent issue that was fixed.

> +
> + dmas = < 2>, < 3>;
> + dma-names = "rx", "tx";
> + clock-names = "core", "iface", "bus", "core_src";
> + qcom,clk-mgmt-sus-res;
> + qcom,msm-bus,name = "qcrypto-noc";
> +
> + qcom,msm-bus,num-cases = <2>;
> + qcom,msm-bus,num-paths = <1>;
> + qcom,use-sw-aes-cbc-ecb-ctr-algo;
> + qcom,use-sw-aes-xts-algo;
> + qcom,use-sw-ahash-algo;
> + qcom,msm-bus,vectors-KBps = <56 512 0 0>,
> + <56 512 3936000 393600>;
> + };
> +
> +
>   timer@f902 {
>   #address-cells = <1>;
>   #size-cells = <1>;

Regards,

Andy

Re: [PATCH] i2c: qup: skip qup_i2c_suspend if the device is already runtime suspended

[Andy Gross]

On Thu, Aug 25, 2016 at 12:23:39PM +0100, Sudeep Holla wrote:
> If the i2c device is already runtime suspended, if qup_i2c_suspend is
> executed during suspend-to-idle or suspend-to-ram it will result in the
> following splat:
> 

> 
> This patch fixes the issue by executing qup_i2c_pm_suspend_runtime
> conditionally in qup_i2c_suspend.
> 
> Cc: Andy Gross <andy.gr...@linaro.org>
> Cc: David Brown <david.br...@linaro.org>
> Cc: Wolfram Sang <w...@the-dreams.de>
> Signed-off-by: Sudeep Holla <sudeep.ho...@arm.com>

Reviewed-by: Andy Gross <andy.gr...@linro.org>

Re: [PATCH] i2c: qup: skip qup_i2c_suspend if the device is already runtime suspended

[Andy Gross]

On Thu, Aug 25, 2016 at 12:23:39PM +0100, Sudeep Holla wrote:
> If the i2c device is already runtime suspended, if qup_i2c_suspend is
> executed during suspend-to-idle or suspend-to-ram it will result in the
> following splat:
> 

> 
> This patch fixes the issue by executing qup_i2c_pm_suspend_runtime
> conditionally in qup_i2c_suspend.
> 
> Cc: Andy Gross 
> Cc: David Brown 
> Cc: Wolfram Sang 
> Signed-off-by: Sudeep Holla 

Reviewed-by: Andy Gross 

Re: [PATCH v4 2/4] wcn36xx: Transition driver to SMD client

[Andy Gross]

On Thu, Sep 08, 2016 at 09:21:59PM -0700, Bjorn Andersson wrote:
> On Thu 08 Sep 10:35 PDT 2016, Kalle Valo wrote:
> 
> > Bjorn Andersson  writes:
> > 
> > > On Thu, Sep 8, 2016 at 5:16 AM, Kalle Valo  wrote:
> > >> Bjorn Andersson  writes:
> > >>
> > >>> The wcn36xx wifi driver follows the life cycle of the WLAN_CTRL SMD
> > >>> channel, as such it should be a SMD client. This patch makes this
> > >>> transition, now that we have the necessary frameworks available.
> > >>>
> > >>> Signed-off-by: Bjorn Andersson 
> > >>> ---
> > >>>
> > >>> Changes since v3:
> > >>> - Made msg_header const in wcn36xx_smd_rsp_process()
> > >>>
> > >>> Changes since v2:
> > >>> - Correct the call to the new ieee80211_scan_completed()
> > >>>
> > >>>  drivers/net/wireless/ath/wcn36xx/dxe.c | 16 +++---
> > >>>  drivers/net/wireless/ath/wcn36xx/main.c| 79 
> > >>> --
> > >>>  drivers/net/wireless/ath/wcn36xx/smd.c | 31 +---
> > >>>  drivers/net/wireless/ath/wcn36xx/smd.h |  5 ++
> > >>>  drivers/net/wireless/ath/wcn36xx/wcn36xx.h | 21 +++-
> > >>>  5 files changed, 86 insertions(+), 66 deletions(-)
> > >>
> > >> This doesn't compile for me:
> > >>
> > >
> > > I thought I mentioned this in the mail, sorry for missing that.
> > 
> > Maybe you did and I just forgot, I have a tendency to do that :)
> > 
> > > There is a patch for this issue in linux-next already [1] which is
> > > part of [2], which was part of the pull request to arm-soc for
> > > inclusion in v4.9.
> > >
> > > [1] https://patchwork.kernel.org/patch/9272457/
> > > [2] 
> > > https://git.kernel.org/cgit/linux/kernel/git/agross/linux.git/tag/?h=qcom-drivers-for-4.9
> > 
> > So the commit in question is:
> > 
> > soc: qcom: smd: Correct compile stub prototypes
> > https://git.kernel.org/cgit/linux/kernel/git/agross/linux.git/commit/?h=qcom-drivers-for-4.9=3a1281848830fcb3202cfd7ffe62d19641471d05
> > 
> 
> Correct
> 
> > But that's not obviously in my tree yet, but I should have it after
> > 4.9-rc1 is released. I think it's easiest that I wait for that before
> > applying these. Do you agree?
> > 
> 
> Would be nice to have it land sooner rather than later, but I'm okay
> with this.

We could just treat the tag as immutable.  You can merge the tag in and arm-soc
can as well.  it'll just get nop'd the second time it is taken.  The only
downside is if arm-soc doesn't take my merge request.

Or we can wait till -rc1

Regards,

Andy

Re: [PATCH v4 2/4] wcn36xx: Transition driver to SMD client

[Andy Gross]

On Thu, Sep 08, 2016 at 09:21:59PM -0700, Bjorn Andersson wrote:
> On Thu 08 Sep 10:35 PDT 2016, Kalle Valo wrote:
> 
> > Bjorn Andersson  writes:
> > 
> > > On Thu, Sep 8, 2016 at 5:16 AM, Kalle Valo  wrote:
> > >> Bjorn Andersson  writes:
> > >>
> > >>> The wcn36xx wifi driver follows the life cycle of the WLAN_CTRL SMD
> > >>> channel, as such it should be a SMD client. This patch makes this
> > >>> transition, now that we have the necessary frameworks available.
> > >>>
> > >>> Signed-off-by: Bjorn Andersson 
> > >>> ---
> > >>>
> > >>> Changes since v3:
> > >>> - Made msg_header const in wcn36xx_smd_rsp_process()
> > >>>
> > >>> Changes since v2:
> > >>> - Correct the call to the new ieee80211_scan_completed()
> > >>>
> > >>>  drivers/net/wireless/ath/wcn36xx/dxe.c | 16 +++---
> > >>>  drivers/net/wireless/ath/wcn36xx/main.c| 79 
> > >>> --
> > >>>  drivers/net/wireless/ath/wcn36xx/smd.c | 31 +---
> > >>>  drivers/net/wireless/ath/wcn36xx/smd.h |  5 ++
> > >>>  drivers/net/wireless/ath/wcn36xx/wcn36xx.h | 21 +++-
> > >>>  5 files changed, 86 insertions(+), 66 deletions(-)
> > >>
> > >> This doesn't compile for me:
> > >>
> > >
> > > I thought I mentioned this in the mail, sorry for missing that.
> > 
> > Maybe you did and I just forgot, I have a tendency to do that :)
> > 
> > > There is a patch for this issue in linux-next already [1] which is
> > > part of [2], which was part of the pull request to arm-soc for
> > > inclusion in v4.9.
> > >
> > > [1] https://patchwork.kernel.org/patch/9272457/
> > > [2] 
> > > https://git.kernel.org/cgit/linux/kernel/git/agross/linux.git/tag/?h=qcom-drivers-for-4.9
> > 
> > So the commit in question is:
> > 
> > soc: qcom: smd: Correct compile stub prototypes
> > https://git.kernel.org/cgit/linux/kernel/git/agross/linux.git/commit/?h=qcom-drivers-for-4.9=3a1281848830fcb3202cfd7ffe62d19641471d05
> > 
> 
> Correct
> 
> > But that's not obviously in my tree yet, but I should have it after
> > 4.9-rc1 is released. I think it's easiest that I wait for that before
> > applying these. Do you agree?
> > 
> 
> Would be nice to have it land sooner rather than later, but I'm okay
> with this.

We could just treat the tag as immutable.  You can merge the tag in and arm-soc
can as well.  it'll just get nop'd the second time it is taken.  The only
downside is if arm-soc doesn't take my merge request.

Or we can wait till -rc1

Regards,

Andy

Re: [PATCH v4 1/4] soc: qcom: wcnss_ctrl: Stub wcnss_ctrl API

[Andy Gross]

On Tue, Sep 06, 2016 at 03:18:29PM -0700, Bjorn Andersson wrote:
> Stub the wcnss_ctrl API to allow compile testing wcnss function drivers.
> 
> Cc: Marcel Holtmann <mar...@holtmann.org>
> Signed-off-by: Bjorn Andersson <bjorn.anders...@linaro.org>
> ---
> 
> There are no other pending changes colliding with this, so if Andy is okay 
> with
> this it could be merged through Kalle's tree - together with the other 
> patches.
> 
> Marcel, with this applied we can drop the depends on QCOM_SMD from the
> btqcomsmd driver as well.
> 
> Changes since v3:
> - Added this patch to allow compile testing without SMD support after patch 2
> 
>  include/linux/soc/qcom/wcnss_ctrl.h | 13 +
>  1 file changed, 13 insertions(+)
> 

This is fine.

Acked-by: Andy Gross <andy.gr...@linaro.org>

Re: [PATCH v4 1/4] soc: qcom: wcnss_ctrl: Stub wcnss_ctrl API

[Andy Gross]

On Tue, Sep 06, 2016 at 03:18:29PM -0700, Bjorn Andersson wrote:
> Stub the wcnss_ctrl API to allow compile testing wcnss function drivers.
> 
> Cc: Marcel Holtmann 
> Signed-off-by: Bjorn Andersson 
> ---
> 
> There are no other pending changes colliding with this, so if Andy is okay 
> with
> this it could be merged through Kalle's tree - together with the other 
> patches.
> 
> Marcel, with this applied we can drop the depends on QCOM_SMD from the
> btqcomsmd driver as well.
> 
> Changes since v3:
> - Added this patch to allow compile testing without SMD support after patch 2
> 
>  include/linux/soc/qcom/wcnss_ctrl.h | 13 +
>  1 file changed, 13 insertions(+)
> 

This is fine.

Acked-by: Andy Gross 

Re: [PATCH 3/4] dt-binding: remoteproc: venus rproc dt binding document

[Andy Gross]

On Thu, Sep 01, 2016 at 05:58:17PM +0300, Stanimir Varbanov wrote:
> Hi,
> 
> Cc: Marek
> 
> On 08/30/2016 08:17 PM, Bjorn Andersson wrote:
> > On Mon 29 Aug 04:48 PDT 2016, Stanimir Varbanov wrote:
> > 
> > [..]
> >>> Trying to wrap my head around how the iommu part works here. The
> >>> downstream code seems to indicate that this is a "generic" secure iommu
> >>> interface - used by venus, camera and kgsl; likely for dealing with DRM
> >>> protected buffers.
> >>
> >> The secure iommu interface is for content protected buffers. But these
> >> secure iommu contexts aren't used by msm DRM nor Venus in mainline. In
> >> Venus case I use non-secure iommu context for data buffers.
> >>
> > 
> > We must consider the case when DRM, VFE and Venus handles protected
> > buffers.
> 
> That would be interesting topic.
> 
> > 
> >>>
> >>> As such the iommu tables are not part of the venus rproc; I believe they
> >>> should either be tied into the msm-iommu driver or perhaps exposed as
> >>> its own iommu(?).
> >>
> >> The page tables are in msm-iommu driver.
> >>
> > 
> > So, just to verify your answer, the msm-iommu driver will handle both
> > protected and unprotected?
> 
> yes, at least for Venus case, the secured buffers are tied to different
> iommu contexts (and stream IDs). But this needs to be verified more
> carefully.
> 
> > 
> >>>
> >>>
> >>> But I presume from your inclusion that you've concluded that the venus
> >>> firmware we have refuses to execute without these tables at least
> >>> initialized, is this correct?
> >>
> >> Yes, the SMC call for PAS memory-setup will fail if this page table is
> >> not initialized.
> >>
> > 
> > If the msm-iommu driver will handle the protected buffers (or if there
> > will be a separate iommu driver for protected buffers) it should issue
> > these calls, to not be dependant on the rproc-venus driver.
> 
> For msm8916 we don't have iommu driver in mainline, I don't know what is
> the status with msm8996.

The iommu v2 transparently handles this and removes the requirement for the
specific SCM page tbl init calls.  However, the memory still has to be
configured to be accessible from the remote processor.




Andy

Re: [PATCH 3/4] dt-binding: remoteproc: venus rproc dt binding document

[Andy Gross]

On Thu, Sep 01, 2016 at 05:58:17PM +0300, Stanimir Varbanov wrote:
> Hi,
> 
> Cc: Marek
> 
> On 08/30/2016 08:17 PM, Bjorn Andersson wrote:
> > On Mon 29 Aug 04:48 PDT 2016, Stanimir Varbanov wrote:
> > 
> > [..]
> >>> Trying to wrap my head around how the iommu part works here. The
> >>> downstream code seems to indicate that this is a "generic" secure iommu
> >>> interface - used by venus, camera and kgsl; likely for dealing with DRM
> >>> protected buffers.
> >>
> >> The secure iommu interface is for content protected buffers. But these
> >> secure iommu contexts aren't used by msm DRM nor Venus in mainline. In
> >> Venus case I use non-secure iommu context for data buffers.
> >>
> > 
> > We must consider the case when DRM, VFE and Venus handles protected
> > buffers.
> 
> That would be interesting topic.
> 
> > 
> >>>
> >>> As such the iommu tables are not part of the venus rproc; I believe they
> >>> should either be tied into the msm-iommu driver or perhaps exposed as
> >>> its own iommu(?).
> >>
> >> The page tables are in msm-iommu driver.
> >>
> > 
> > So, just to verify your answer, the msm-iommu driver will handle both
> > protected and unprotected?
> 
> yes, at least for Venus case, the secured buffers are tied to different
> iommu contexts (and stream IDs). But this needs to be verified more
> carefully.
> 
> > 
> >>>
> >>>
> >>> But I presume from your inclusion that you've concluded that the venus
> >>> firmware we have refuses to execute without these tables at least
> >>> initialized, is this correct?
> >>
> >> Yes, the SMC call for PAS memory-setup will fail if this page table is
> >> not initialized.
> >>
> > 
> > If the msm-iommu driver will handle the protected buffers (or if there
> > will be a separate iommu driver for protected buffers) it should issue
> > these calls, to not be dependant on the rproc-venus driver.
> 
> For msm8916 we don't have iommu driver in mainline, I don't know what is
> the status with msm8996.

The iommu v2 transparently handles this and removes the requirement for the
specific SCM page tbl init calls.  However, the memory still has to be
configured to be accessible from the remote processor.




Andy

Re: [PATCH 2/4] firmware: qcom: scm: add iommu scm calls for pg table

[Andy Gross]

On Wed, Aug 24, 2016 at 11:35:29AM -0700, Gupta, Puja wrote:
> On 8/19/2016 8:53 AM, Stanimir Varbanov wrote:
> >Those two scm calls are used to get the size of secure iommu
> >page table and to pass physical memory address for this page
> >table. The calls are used by remoteproc venus driver to load
> >the firmware.
> Do we really need these additional scm calls for venus? why can't we just
> reuse existing __qcom_scm_pas_mem_setup() call?

Keep in mind this is with the smmu-v1 on 8916.  It seems like the downstream
kernel has to do extra stuff when dealing with the older smmu.  The newer
platforms handle this quasi-transparently.

Regards,

Andy

Re: [PATCH 2/4] firmware: qcom: scm: add iommu scm calls for pg table

[Andy Gross]

On Wed, Aug 24, 2016 at 11:35:29AM -0700, Gupta, Puja wrote:
> On 8/19/2016 8:53 AM, Stanimir Varbanov wrote:
> >Those two scm calls are used to get the size of secure iommu
> >page table and to pass physical memory address for this page
> >table. The calls are used by remoteproc venus driver to load
> >the firmware.
> Do we really need these additional scm calls for venus? why can't we just
> reuse existing __qcom_scm_pas_mem_setup() call?

Keep in mind this is with the smmu-v1 on 8916.  It seems like the downstream
kernel has to do extra stuff when dealing with the older smmu.  The newer
platforms handle this quasi-transparently.

Regards,

Andy

Re: [PATCH 1/2] arm64: kernel: Add SMC Session ID to results

[Andy Gross]

On Tue, Aug 23, 2016 at 11:38:41AM +0100, Lorenzo Pieralisi wrote:
> On Mon, Aug 22, 2016 at 05:38:31PM -0700, Stephen Boyd wrote:
> 
> [...]
> 
> > This all comes about because the firmware generates a session id
> > for the SMC call and jams it in x6. The assembly on the
> > non-secure side is written with a tight loop around the smc
> > instruction so that when the return value indicates
> > "interrupted", x6 is kept intact and the non-secure OS can jump
> > back to the secure OS without register reloading. Perhaps
> > referring to x6 as result value is not correct because it's
> > really a session id that's irrelevant once the smc call
> > completes.
> 
> Sorry I missed this bit. The session id is _generated_ by secure
> firmware (probably only when the value passed in x6 == 0 (?))
> and actually returned to the caller so that subsequent (interrupted)
> calls can re-issue the same value, is that correct ?
> 
> If that's the case the value in x6 is a result value from an SMCCC
> perspective and your current FW is not SMCCC compliant.
> 

So is Will's solution to this ok?  If so I will respin with the minor change to
get it working and resend.  If not, do I roll my own smccc wrapper?

Regards,

Andy

Re: [PATCH 1/2] arm64: kernel: Add SMC Session ID to results

[Andy Gross]

On Tue, Aug 23, 2016 at 11:38:41AM +0100, Lorenzo Pieralisi wrote:
> On Mon, Aug 22, 2016 at 05:38:31PM -0700, Stephen Boyd wrote:
> 
> [...]
> 
> > This all comes about because the firmware generates a session id
> > for the SMC call and jams it in x6. The assembly on the
> > non-secure side is written with a tight loop around the smc
> > instruction so that when the return value indicates
> > "interrupted", x6 is kept intact and the non-secure OS can jump
> > back to the secure OS without register reloading. Perhaps
> > referring to x6 as result value is not correct because it's
> > really a session id that's irrelevant once the smc call
> > completes.
> 
> Sorry I missed this bit. The session id is _generated_ by secure
> firmware (probably only when the value passed in x6 == 0 (?))
> and actually returned to the caller so that subsequent (interrupted)
> calls can re-issue the same value, is that correct ?
> 
> If that's the case the value in x6 is a result value from an SMCCC
> perspective and your current FW is not SMCCC compliant.
> 

So is Will's solution to this ok?  If so I will respin with the minor change to
get it working and resend.  If not, do I roll my own smccc wrapper?

Regards,

Andy

Re: [PATCH] spi: qup: skip clk_disable_unprepare if the device is already runtime suspended

[Andy Gross]

On Thu, Aug 25, 2016 at 01:33:28PM +0100, Sudeep Holla wrote:
> If the spi device is already runtime suspended, if spi_qup_suspend is
> executed during suspend-to-idle or suspend-to-ram it will result in the
> following splat:
> 
> WARNING: CPU: 3 PID: 1593 at drivers/clk/clk.c:476 
> clk_core_unprepare+0x80/0x90
> Modules linked in:
> 



Thanks for fixing this.  I had noticed this yesterday when I was testing your
freeze patch but hadn't had time to dig in.


Tested-by: Andy Gross <andy.gr...@linaro.org>

Re: [PATCH] spi: qup: skip clk_disable_unprepare if the device is already runtime suspended

[Andy Gross]

On Thu, Aug 25, 2016 at 01:33:28PM +0100, Sudeep Holla wrote:
> If the spi device is already runtime suspended, if spi_qup_suspend is
> executed during suspend-to-idle or suspend-to-ram it will result in the
> following splat:
> 
> WARNING: CPU: 3 PID: 1593 at drivers/clk/clk.c:476 
> clk_core_unprepare+0x80/0x90
> Modules linked in:
> 



Thanks for fixing this.  I had noticed this yesterday when I was testing your
freeze patch but hadn't had time to dig in.


Tested-by: Andy Gross 

Re: [PATCH v3 0/5] dts patches for qcom tsens support

[Andy Gross]

On 24 August 2016 at 22:13, Bjorn Andersson <bjorn.anders...@linaro.org> wrote:
> On Wed 24 Aug 03:22 PDT 2016, Paolo Pisati wrote:
>
>> On Wed, Aug 17, 2016 at 02:33:40PM -0500, Andy Gross wrote:
>> > On Wed, Aug 17, 2016 at 10:48:43AM +0530, Rajendra Nayak wrote:
>> > > Hey Andy,
>> > >
>> > > This is a respin of v2 with some minor fixes pointed out by Rob.
>> > > Please pull these in for 4.9
>> > >
>> > > Thanks,
>> > > Rajendra
>> >
>> > I pulled these in.
>>
>> Did you try to read the content of the qfprom from userspace?
>>
>> $ uname -a
>> Linux dragon410c 4.8.0-rc1+ #6 SMP PREEMPT Wed Aug 24 11:11:02 CEST 2016 
>> aarch64
>> aarch64 aarch64 GNU/Linux
>> $ lsmod
>> Module  Size  Used by
>> nvmem_qfprom   16384  0
>> nvmem_core 24576  1 nvmem_qfprom
>> $ ls -la /sys/bus/nvmem/devices/
>> total 0
>> drwxr-xr-x 2 root root 0 Aug 24 10:17 .
>> drwxr-xr-x 4 root root 0 Aug 24 10:15 ..
>> lrwxrwxrwx 1 root root 0 Aug 24 10:17 qfprom0 ->
>> ../../../devices/platform/soc/5c000.qfprom/qfprom0
>> $ cat /sys/bus/nvmem/devices/qfprom0/nvmem
>>
>> [spontaneous reboot]
>>
>> This using agross's for-next tree as of today ("54ba896 Merge branch
>> 'arm64-defconfig-for-4.9' into all-for-4.8") and defconfig.
>
> This was reported in some other forum as well, after some investigation
> we concluded that it looks like one of the entries are locked down -
> probably from some security reason.
>
> I'm not aware of any way to query this configuration. But the main use
> case for the qfprom is in-kernel access to certain elements and that we
> do get from the driver as is...

Yeah this appears to be the case.  So I guess the response is 'don't
do that'.  At least don't cat or od the file.  You need to seek and
read.

Andy

Re: [PATCH v3 0/5] dts patches for qcom tsens support

[Andy Gross]

On 24 August 2016 at 22:13, Bjorn Andersson  wrote:
> On Wed 24 Aug 03:22 PDT 2016, Paolo Pisati wrote:
>
>> On Wed, Aug 17, 2016 at 02:33:40PM -0500, Andy Gross wrote:
>> > On Wed, Aug 17, 2016 at 10:48:43AM +0530, Rajendra Nayak wrote:
>> > > Hey Andy,
>> > >
>> > > This is a respin of v2 with some minor fixes pointed out by Rob.
>> > > Please pull these in for 4.9
>> > >
>> > > Thanks,
>> > > Rajendra
>> >
>> > I pulled these in.
>>
>> Did you try to read the content of the qfprom from userspace?
>>
>> $ uname -a
>> Linux dragon410c 4.8.0-rc1+ #6 SMP PREEMPT Wed Aug 24 11:11:02 CEST 2016 
>> aarch64
>> aarch64 aarch64 GNU/Linux
>> $ lsmod
>> Module  Size  Used by
>> nvmem_qfprom   16384  0
>> nvmem_core 24576  1 nvmem_qfprom
>> $ ls -la /sys/bus/nvmem/devices/
>> total 0
>> drwxr-xr-x 2 root root 0 Aug 24 10:17 .
>> drwxr-xr-x 4 root root 0 Aug 24 10:15 ..
>> lrwxrwxrwx 1 root root 0 Aug 24 10:17 qfprom0 ->
>> ../../../devices/platform/soc/5c000.qfprom/qfprom0
>> $ cat /sys/bus/nvmem/devices/qfprom0/nvmem
>>
>> [spontaneous reboot]
>>
>> This using agross's for-next tree as of today ("54ba896 Merge branch
>> 'arm64-defconfig-for-4.9' into all-for-4.8") and defconfig.
>
> This was reported in some other forum as well, after some investigation
> we concluded that it looks like one of the entries are locked down -
> probably from some security reason.
>
> I'm not aware of any way to query this configuration. But the main use
> case for the qfprom is in-kernel access to certain elements and that we
> do get from the driver as is...

Yeah this appears to be the case.  So I guess the response is 'don't
do that'.  At least don't cat or od the file.  You need to seek and
read.

Andy

Re: [PATCH] tty: serial: msm: Add runtime PM and system sleep support

[Andy Gross]

On 17 June 2016 at 05:16, Pramod Gurav  wrote:



> @@ -1635,6 +1732,7 @@ static int msm_serial_remove(struct platform_device 
> *pdev)
> struct uart_port *port = platform_get_drvdata(pdev);
>
> uart_remove_one_port(_uart_driver, port);
> +   pm_runtime_disable(>dev);
>
> return 0;
>  }
> @@ -1645,12 +1743,67 @@ static const struct of_device_id msm_match_table[] = {
> {}
>  };
>
> +#ifdef CONFIG_PM
> +static int msm_serial_runtime_suspend(struct device *dev)
> +{
> +   struct uart_port *port = dev_get_drvdata(dev);
> +   struct msm_port *msm_port = UART_TO_MSM(port);
> +
> +   if (msm_port->is_uartdm)
> +   clk_disable(msm_port->pclk);

You don't need to check, just clk_disable it.

> +
> +   return 0;
> +}
> +
> +static int msm_serial_runtime_resume(struct device *dev)
> +{
> +   struct uart_port *port = dev_get_drvdata(dev);
> +   struct msm_port *msm_port = UART_TO_MSM(port);
> +   int ret;
> +
> +   if (msm_port->is_uartdm) {
> +   ret = clk_enable(msm_port->pclk);

Ditto here.

> +   if (ret)
> +   return ret;
> +   }
> +
> +   return 0;
> +}
> +#endif
> +


Regards,

Andy

Re: [PATCH] tty: serial: msm: Add runtime PM and system sleep support

[Andy Gross]

On 17 June 2016 at 05:16, Pramod Gurav  wrote:



> @@ -1635,6 +1732,7 @@ static int msm_serial_remove(struct platform_device 
> *pdev)
> struct uart_port *port = platform_get_drvdata(pdev);
>
> uart_remove_one_port(_uart_driver, port);
> +   pm_runtime_disable(>dev);
>
> return 0;
>  }
> @@ -1645,12 +1743,67 @@ static const struct of_device_id msm_match_table[] = {
> {}
>  };
>
> +#ifdef CONFIG_PM
> +static int msm_serial_runtime_suspend(struct device *dev)
> +{
> +   struct uart_port *port = dev_get_drvdata(dev);
> +   struct msm_port *msm_port = UART_TO_MSM(port);
> +
> +   if (msm_port->is_uartdm)
> +   clk_disable(msm_port->pclk);

You don't need to check, just clk_disable it.

> +
> +   return 0;
> +}
> +
> +static int msm_serial_runtime_resume(struct device *dev)
> +{
> +   struct uart_port *port = dev_get_drvdata(dev);
> +   struct msm_port *msm_port = UART_TO_MSM(port);
> +   int ret;
> +
> +   if (msm_port->is_uartdm) {
> +   ret = clk_enable(msm_port->pclk);

Ditto here.

> +   if (ret)
> +   return ret;
> +   }
> +
> +   return 0;
> +}
> +#endif
> +


Regards,

Andy

Re: [PATCH v3 0/5] dts patches for qcom tsens support

[Andy Gross]

On 24 August 2016 at 07:18, Nayak, Rajendra <rna...@codeaurora.org> wrote:
>
> On 8/24/2016 3:52 PM, Paolo Pisati wrote:
>>
>> On Wed, Aug 17, 2016 at 02:33:40PM -0500, Andy Gross wrote:
>>>
>>> On Wed, Aug 17, 2016 at 10:48:43AM +0530, Rajendra Nayak wrote:
>>>>
>>>> Hey Andy,
>>>>
>>>> This is a respin of v2 with some minor fixes pointed out by Rob.
>>>> Please pull these in for 4.9
>>>>
>>>> Thanks,
>>>> Rajendra
>>>
>>>
>>> I pulled these in.
>>
>>
>> Did you try to read the content of the qfprom from userspace?
>
>
> Hi, no I haven't tried it, I can give it a try tomorrow when I
> have access to my board and see whats going wrong, but I did
> look at Andys for-next and the defconfig still does not have
> either nvmem or qcom-qfprom drivers enabled.
> Did you manually enable them? or are you seeing this with the drivers still
> disabled?

I merged my for-next with the current next and enabled the options.  I
reproduced Paolo's problem.  It feels like either an access issue,
alignment issue (i tried ioread32 which didnt work).  It fails
regardless of the TSENS being enabled.

>
>
>>
>> $ uname -a
>> Linux dragon410c 4.8.0-rc1+ #6 SMP PREEMPT Wed Aug 24 11:11:02 CEST 2016
>> aarch64
>> aarch64 aarch64 GNU/Linux
>> $ lsmod
>> Module  Size  Used by
>> nvmem_qfprom   16384  0
>> nvmem_core 24576  1 nvmem_qfprom
>> $ ls -la /sys/bus/nvmem/devices/
>> total 0
>> drwxr-xr-x 2 root root 0 Aug 24 10:17 .
>> drwxr-xr-x 4 root root 0 Aug 24 10:15 ..
>> lrwxrwxrwx 1 root root 0 Aug 24 10:17 qfprom0 ->
>> ../../../devices/platform/soc/5c000.qfprom/qfprom0
>> $ cat /sys/bus/nvmem/devices/qfprom0/nvmem
>>
>> [spontaneous reboot]
>>
>> This using agross's for-next tree as of today ("54ba896 Merge branch
>> 'arm64-defconfig-for-4.9' into all-for-4.8") and defconfig.
>>
>

Re: [PATCH v3 0/5] dts patches for qcom tsens support

[Andy Gross]

On 24 August 2016 at 07:18, Nayak, Rajendra  wrote:
>
> On 8/24/2016 3:52 PM, Paolo Pisati wrote:
>>
>> On Wed, Aug 17, 2016 at 02:33:40PM -0500, Andy Gross wrote:
>>>
>>> On Wed, Aug 17, 2016 at 10:48:43AM +0530, Rajendra Nayak wrote:
>>>>
>>>> Hey Andy,
>>>>
>>>> This is a respin of v2 with some minor fixes pointed out by Rob.
>>>> Please pull these in for 4.9
>>>>
>>>> Thanks,
>>>> Rajendra
>>>
>>>
>>> I pulled these in.
>>
>>
>> Did you try to read the content of the qfprom from userspace?
>
>
> Hi, no I haven't tried it, I can give it a try tomorrow when I
> have access to my board and see whats going wrong, but I did
> look at Andys for-next and the defconfig still does not have
> either nvmem or qcom-qfprom drivers enabled.
> Did you manually enable them? or are you seeing this with the drivers still
> disabled?

I merged my for-next with the current next and enabled the options.  I
reproduced Paolo's problem.  It feels like either an access issue,
alignment issue (i tried ioread32 which didnt work).  It fails
regardless of the TSENS being enabled.

>
>
>>
>> $ uname -a
>> Linux dragon410c 4.8.0-rc1+ #6 SMP PREEMPT Wed Aug 24 11:11:02 CEST 2016
>> aarch64
>> aarch64 aarch64 GNU/Linux
>> $ lsmod
>> Module  Size  Used by
>> nvmem_qfprom   16384  0
>> nvmem_core 24576  1 nvmem_qfprom
>> $ ls -la /sys/bus/nvmem/devices/
>> total 0
>> drwxr-xr-x 2 root root 0 Aug 24 10:17 .
>> drwxr-xr-x 4 root root 0 Aug 24 10:15 ..
>> lrwxrwxrwx 1 root root 0 Aug 24 10:17 qfprom0 ->
>> ../../../devices/platform/soc/5c000.qfprom/qfprom0
>> $ cat /sys/bus/nvmem/devices/qfprom0/nvmem
>>
>> [spontaneous reboot]
>>
>> This using agross's for-next tree as of today ("54ba896 Merge branch
>> 'arm64-defconfig-for-4.9' into all-for-4.8") and defconfig.
>>
>

Re: [PATCH v3] PM / sleep: enable suspend-to-idle even without registered suspend_ops

[Andy Gross]

On 19 August 2016 at 08:41, Sudeep Holla <sudeep.ho...@arm.com> wrote:
> Suspend-to-idle (aka the "freeze" sleep state) is a system sleep state
> in which all of the processors enter deepest possible idle state and
> wait for interrupts right after suspending all the devices.
>
> There is no hard requirement for a platform to support and register
> platform specific suspend_ops to enter suspend-to-idle/freeze state.
> Only deeper system sleep states like PM_SUSPEND_STANDBY and
> PM_SUSPEND_MEM rely on such low level support/implementation.
>
> suspend-to-idle can be entered as along as all the devices can be
> suspended. This patch enables the support for suspend-to-idle even on
> systems that don't have any low level support for deeper system sleep
> states and/or don't register any platform specific suspend_ops.
>
> Cc: "Rafael J. Wysocki" <r...@rjwysocki.net>
> Signed-off-by: Sudeep Holla <sudeep.ho...@arm.com>

I tested this patch on the Qualcomm 410c platform.  It worked like a
charm.  Thanks for working on this!

Tested-by: Andy Gross <andy.gr...@linaro.org>

Re: [PATCH v3] PM / sleep: enable suspend-to-idle even without registered suspend_ops

[Andy Gross]

On 19 August 2016 at 08:41, Sudeep Holla  wrote:
> Suspend-to-idle (aka the "freeze" sleep state) is a system sleep state
> in which all of the processors enter deepest possible idle state and
> wait for interrupts right after suspending all the devices.
>
> There is no hard requirement for a platform to support and register
> platform specific suspend_ops to enter suspend-to-idle/freeze state.
> Only deeper system sleep states like PM_SUSPEND_STANDBY and
> PM_SUSPEND_MEM rely on such low level support/implementation.
>
> suspend-to-idle can be entered as along as all the devices can be
> suspended. This patch enables the support for suspend-to-idle even on
> systems that don't have any low level support for deeper system sleep
> states and/or don't register any platform specific suspend_ops.
>
> Cc: "Rafael J. Wysocki" 
> Signed-off-by: Sudeep Holla 

I tested this patch on the Qualcomm 410c platform.  It worked like a
charm.  Thanks for working on this!

Tested-by: Andy Gross 

Re: [PATCH] arm64: defconfig: Enable QDF2432 config options

[Andy Gross]

On Fri, Jul 01, 2016 at 10:11:00AM -0500, Timur Tabi wrote:
> Christopher Covington wrote:
> >Due to distribution differences [1][2], I see =y built-in as the default
> >on mobile platforms and =m modular as the default on server platforms.
> 
> I don't think we should mix "server" defconfing entries with "mobile"
> defconfig entries.  It's a arm64 defconfig, neither server nor mobile. The
> other entries are =y, so these should be =y
> 
> No one uses this defconfig as-is for any platform.
> 
> >But thinking about it, we could get a poweroff, reset, over-temperature,
> >or other interrupt before we get to the initramfs. So the pin controller
> >driver should be =y built-in.
> >
> >One might make rootfs media =y built-in to make testing easier, but I
> >prefer to put my rootfs on SATA, as SD/MMC is much slower and smaller by
> >comparison.
> 
> Let's not overthink things, and just make *everything* =y by default.

Do you guys want me to fix this up so it can hit this window?  I can just change
the m to y before I send it off.


Andy

Re: [PATCH] arm64: defconfig: Enable QDF2432 config options

[Andy Gross]

On Fri, Jul 01, 2016 at 10:11:00AM -0500, Timur Tabi wrote:
> Christopher Covington wrote:
> >Due to distribution differences [1][2], I see =y built-in as the default
> >on mobile platforms and =m modular as the default on server platforms.
> 
> I don't think we should mix "server" defconfing entries with "mobile"
> defconfig entries.  It's a arm64 defconfig, neither server nor mobile. The
> other entries are =y, so these should be =y
> 
> No one uses this defconfig as-is for any platform.
> 
> >But thinking about it, we could get a poweroff, reset, over-temperature,
> >or other interrupt before we get to the initramfs. So the pin controller
> >driver should be =y built-in.
> >
> >One might make rootfs media =y built-in to make testing easier, but I
> >prefer to put my rootfs on SATA, as SD/MMC is much slower and smaller by
> >comparison.
> 
> Let's not overthink things, and just make *everything* =y by default.

Do you guys want me to fix this up so it can hit this window?  I can just change
the m to y before I send it off.


Andy

Re: [PATCH 1/2] arm64: kernel: Add SMC Session ID to results

[Andy Gross]

On Mon, Aug 22, 2016 at 10:16:40AM -0500, Andy Gross wrote:
> On Mon, Aug 22, 2016 at 03:53:26PM +0100, Will Deacon wrote:
> > On Mon, Aug 22, 2016 at 09:02:46AM -0500, Andy Gross wrote:
> > > On Mon, Aug 22, 2016 at 02:43:14PM +0100, Will Deacon wrote:
> > > > On Sat, Aug 20, 2016 at 12:51:13AM -0500, Andy Gross wrote:



> > > 
> > > In the case of Qualcomm's implementation, they return a value in register 
> > > 6 that
> > > may or may not be used in subsequent calls.  If I want to leverage the 
> > > arm_smccc
> > > functions, then I need to extend them to include the optional return 
> > > value.  The
> > > downside to this is that everyone who uses this is exposed to it.
> > 
> > Yes, I'm not keen on forcing this behaviour for everybody, as you never
> > know what other firmware might do with unexpected a6 values. Could we
> > perhaps quirk it, along the lines of the completely untested patch below?
> 
> A quirk would work fine.  I'll try this out and get back to you.

Update:  Aside from a minor change with either the id type or using w9 register
for the id load, this works just fine.

> > --->8
> > 
> > diff --git a/arch/arm64/kernel/asm-offsets.c 
> > b/arch/arm64/kernel/asm-offsets.c
> > index 05070b72fc28..1895e87d0240 100644
> > --- a/arch/arm64/kernel/asm-offsets.c
> > +++ b/arch/arm64/kernel/asm-offsets.c
> > @@ -141,6 +141,8 @@ int main(void)
> >  #endif
> >DEFINE(ARM_SMCCC_RES_X0_OFFS,offsetof(struct arm_smccc_res, a0));
> >DEFINE(ARM_SMCCC_RES_X2_OFFS,offsetof(struct arm_smccc_res, a2));
> > +  DEFINE(ARM_SMCCC_RES_QUIRK_ID_OFFS,  offsetof(struct 
> > arm_smccc_res, quirk.id));
> > +  DEFINE(ARM_SMCCC_RES_QUIRK_STATE_OFFS,   offsetof(struct arm_smccc_res, 
> > quirk.state));
> >BLANK();
> >DEFINE(HIBERN_PBE_ORIG,  offsetof(struct pbe, orig_address));
> >DEFINE(HIBERN_PBE_ADDR,  offsetof(struct pbe, address));
> > diff --git a/arch/arm64/kernel/smccc-call.S b/arch/arm64/kernel/smccc-call.S
> > index ae0496fa4235..3c6c976eaf5c 100644
> > --- a/arch/arm64/kernel/smccc-call.S
> > +++ b/arch/arm64/kernel/smccc-call.S
> > @@ -12,6 +12,7 @@
> >   *
> >   */
> >  #include 
> > +#include 
> >  #include 
> >  
> > .macro SMCCC instr
> > @@ -20,7 +21,12 @@
> > ldr x4, [sp]
> > stp x0, x1, [x4, #ARM_SMCCC_RES_X0_OFFS]
> > stp x2, x3, [x4, #ARM_SMCCC_RES_X2_OFFS]
> > -   ret
> > +   ldr x9, [x4, #ARM_SMCCC_RES_QUIRK_ID_OFFS]
> > +   cbz x9, 1f /* ARM_SMCCC_QUIRK_NONE */
> > +   cmp x9, #ARM_SMCCC_QUIRK_QCOM_A6
> > +   b.ne1f
> > +   str x6, [x4, ARM_SMCCC_RES_QUIRK_STATE_OFFS]
> > +1: ret
> > .cfi_endproc
> > .endm
> >  
> > diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
> > index b5abfda80465..a3a6e291feb6 100644
> > --- a/include/linux/arm-smccc.h
> > +++ b/include/linux/arm-smccc.h
> > @@ -14,9 +14,6 @@
> >  #ifndef __LINUX_ARM_SMCCC_H
> >  #define __LINUX_ARM_SMCCC_H
> >  
> > -#include 
> > -#include 
> > -
> >  /*
> >   * This file provides common defines for ARM SMC Calling Convention as
> >   * specified in
> > @@ -60,6 +57,21 @@
> >  #define ARM_SMCCC_OWNER_TRUSTED_OS 50
> >  #define ARM_SMCCC_OWNER_TRUSTED_OS_END 63
> >  
> > +#define ARM_SMCCC_QUIRK_NONE   0
> > +#define ARM_SMCCC_QUIRK_QCOM_A61 /* Save/restore register a6 */
> > +
> > +#ifndef __ASSEMBLY__
> > +
> > +#include 
> > +#include 
> > +
> > +struct arm_smccc_quirk {
> > +   int id;
> > +   union {
> > +   unsigned long a6;
> > +   } state;
> > +};
> > +
> >  /**
> >   * struct arm_smccc_res - Result from SMC/HVC call
> >   * @a0-a3 result values from registers 0 to 3
> > @@ -69,6 +81,7 @@ struct arm_smccc_res {
> > unsigned long a1;
> > unsigned long a2;
> > unsigned long a3;
> > +   struct arm_smccc_quirk quirk;
> >  };
> >  
> >  /**
> > @@ -101,4 +114,5 @@ asmlinkage void arm_smccc_hvc(unsigned long a0, 
> > unsigned long a1,
> > unsigned long a5, unsigned long a6, unsigned long a7,
> > struct arm_smccc_res *res);
> >  
> > +#endif /* !__ASSEMBLY__ */
> >  #endif /*__LINUX_ARM_SMCCC_H*/
> > --
> > 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/2] arm64: kernel: Add SMC Session ID to results

[Andy Gross]

On Mon, Aug 22, 2016 at 10:16:40AM -0500, Andy Gross wrote:
> On Mon, Aug 22, 2016 at 03:53:26PM +0100, Will Deacon wrote:
> > On Mon, Aug 22, 2016 at 09:02:46AM -0500, Andy Gross wrote:
> > > On Mon, Aug 22, 2016 at 02:43:14PM +0100, Will Deacon wrote:
> > > > On Sat, Aug 20, 2016 at 12:51:13AM -0500, Andy Gross wrote:



> > > 
> > > In the case of Qualcomm's implementation, they return a value in register 
> > > 6 that
> > > may or may not be used in subsequent calls.  If I want to leverage the 
> > > arm_smccc
> > > functions, then I need to extend them to include the optional return 
> > > value.  The
> > > downside to this is that everyone who uses this is exposed to it.
> > 
> > Yes, I'm not keen on forcing this behaviour for everybody, as you never
> > know what other firmware might do with unexpected a6 values. Could we
> > perhaps quirk it, along the lines of the completely untested patch below?
> 
> A quirk would work fine.  I'll try this out and get back to you.

Update:  Aside from a minor change with either the id type or using w9 register
for the id load, this works just fine.

> > --->8
> > 
> > diff --git a/arch/arm64/kernel/asm-offsets.c 
> > b/arch/arm64/kernel/asm-offsets.c
> > index 05070b72fc28..1895e87d0240 100644
> > --- a/arch/arm64/kernel/asm-offsets.c
> > +++ b/arch/arm64/kernel/asm-offsets.c
> > @@ -141,6 +141,8 @@ int main(void)
> >  #endif
> >DEFINE(ARM_SMCCC_RES_X0_OFFS,offsetof(struct arm_smccc_res, a0));
> >DEFINE(ARM_SMCCC_RES_X2_OFFS,offsetof(struct arm_smccc_res, a2));
> > +  DEFINE(ARM_SMCCC_RES_QUIRK_ID_OFFS,  offsetof(struct 
> > arm_smccc_res, quirk.id));
> > +  DEFINE(ARM_SMCCC_RES_QUIRK_STATE_OFFS,   offsetof(struct arm_smccc_res, 
> > quirk.state));
> >BLANK();
> >DEFINE(HIBERN_PBE_ORIG,  offsetof(struct pbe, orig_address));
> >DEFINE(HIBERN_PBE_ADDR,  offsetof(struct pbe, address));
> > diff --git a/arch/arm64/kernel/smccc-call.S b/arch/arm64/kernel/smccc-call.S
> > index ae0496fa4235..3c6c976eaf5c 100644
> > --- a/arch/arm64/kernel/smccc-call.S
> > +++ b/arch/arm64/kernel/smccc-call.S
> > @@ -12,6 +12,7 @@
> >   *
> >   */
> >  #include 
> > +#include 
> >  #include 
> >  
> > .macro SMCCC instr
> > @@ -20,7 +21,12 @@
> > ldr x4, [sp]
> > stp x0, x1, [x4, #ARM_SMCCC_RES_X0_OFFS]
> > stp x2, x3, [x4, #ARM_SMCCC_RES_X2_OFFS]
> > -   ret
> > +   ldr x9, [x4, #ARM_SMCCC_RES_QUIRK_ID_OFFS]
> > +   cbz x9, 1f /* ARM_SMCCC_QUIRK_NONE */
> > +   cmp x9, #ARM_SMCCC_QUIRK_QCOM_A6
> > +   b.ne1f
> > +   str x6, [x4, ARM_SMCCC_RES_QUIRK_STATE_OFFS]
> > +1: ret
> > .cfi_endproc
> > .endm
> >  
> > diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
> > index b5abfda80465..a3a6e291feb6 100644
> > --- a/include/linux/arm-smccc.h
> > +++ b/include/linux/arm-smccc.h
> > @@ -14,9 +14,6 @@
> >  #ifndef __LINUX_ARM_SMCCC_H
> >  #define __LINUX_ARM_SMCCC_H
> >  
> > -#include 
> > -#include 
> > -
> >  /*
> >   * This file provides common defines for ARM SMC Calling Convention as
> >   * specified in
> > @@ -60,6 +57,21 @@
> >  #define ARM_SMCCC_OWNER_TRUSTED_OS 50
> >  #define ARM_SMCCC_OWNER_TRUSTED_OS_END 63
> >  
> > +#define ARM_SMCCC_QUIRK_NONE   0
> > +#define ARM_SMCCC_QUIRK_QCOM_A61 /* Save/restore register a6 */
> > +
> > +#ifndef __ASSEMBLY__
> > +
> > +#include 
> > +#include 
> > +
> > +struct arm_smccc_quirk {
> > +   int id;
> > +   union {
> > +   unsigned long a6;
> > +   } state;
> > +};
> > +
> >  /**
> >   * struct arm_smccc_res - Result from SMC/HVC call
> >   * @a0-a3 result values from registers 0 to 3
> > @@ -69,6 +81,7 @@ struct arm_smccc_res {
> > unsigned long a1;
> > unsigned long a2;
> > unsigned long a3;
> > +   struct arm_smccc_quirk quirk;
> >  };
> >  
> >  /**
> > @@ -101,4 +114,5 @@ asmlinkage void arm_smccc_hvc(unsigned long a0, 
> > unsigned long a1,
> > unsigned long a5, unsigned long a6, unsigned long a7,
> > struct arm_smccc_res *res);
> >  
> > +#endif /* !__ASSEMBLY__ */
> >  #endif /*__LINUX_ARM_SMCCC_H*/
> > --
> > 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/2] arm64: kernel: Add SMC Session ID to results

[Andy Gross]

On Tue, Aug 23, 2016 at 11:38:41AM +0100, Lorenzo Pieralisi wrote:
> On Mon, Aug 22, 2016 at 05:38:31PM -0700, Stephen Boyd wrote:
> 
> [...]
> 
> > This all comes about because the firmware generates a session id
> > for the SMC call and jams it in x6. The assembly on the
> > non-secure side is written with a tight loop around the smc
> > instruction so that when the return value indicates
> > "interrupted", x6 is kept intact and the non-secure OS can jump
> > back to the secure OS without register reloading. Perhaps
> > referring to x6 as result value is not correct because it's
> > really a session id that's irrelevant once the smc call
> > completes.
> 
> Sorry I missed this bit. The session id is _generated_ by secure
> firmware (probably only when the value passed in x6 == 0 (?))
> and actually returned to the caller so that subsequent (interrupted)
> calls can re-issue the same value, is that correct ?

Yes, that is exactly what is going on.  You always pass in 0 for the first call.
If the call is interrupted and needs to be re-executed, you will get a specific
result in a0 that tells you to redo the call using x6 as your session ID.

> 
> If that's the case the value in x6 is a result value from an SMCCC
> perspective and your current FW is not SMCCC compliant.

Should we then write our own ASM snippet to do exactly what we want?  It'd be
the same as the arm_smccc except with the extra str.  I'm ok with that, I was
just hoping to leverage the existing smccc code.  The quirk also works well,
except it costs everyone else 1 load and compare.

Regards,

Andy

Re: [PATCH 1/2] arm64: kernel: Add SMC Session ID to results

[Andy Gross]

On Tue, Aug 23, 2016 at 11:38:41AM +0100, Lorenzo Pieralisi wrote:
> On Mon, Aug 22, 2016 at 05:38:31PM -0700, Stephen Boyd wrote:
> 
> [...]
> 
> > This all comes about because the firmware generates a session id
> > for the SMC call and jams it in x6. The assembly on the
> > non-secure side is written with a tight loop around the smc
> > instruction so that when the return value indicates
> > "interrupted", x6 is kept intact and the non-secure OS can jump
> > back to the secure OS without register reloading. Perhaps
> > referring to x6 as result value is not correct because it's
> > really a session id that's irrelevant once the smc call
> > completes.
> 
> Sorry I missed this bit. The session id is _generated_ by secure
> firmware (probably only when the value passed in x6 == 0 (?))
> and actually returned to the caller so that subsequent (interrupted)
> calls can re-issue the same value, is that correct ?

Yes, that is exactly what is going on.  You always pass in 0 for the first call.
If the call is interrupted and needs to be re-executed, you will get a specific
result in a0 that tells you to redo the call using x6 as your session ID.

> 
> If that's the case the value in x6 is a result value from an SMCCC
> perspective and your current FW is not SMCCC compliant.

Should we then write our own ASM snippet to do exactly what we want?  It'd be
the same as the arm_smccc except with the extra str.  I'm ok with that, I was
just hoping to leverage the existing smccc code.  The quirk also works well,
except it costs everyone else 1 load and compare.

Regards,

Andy

Re: [PATCH 1/2] arm64: kernel: Add SMC Session ID to results

[Andy Gross]

On Mon, Aug 22, 2016 at 03:53:26PM +0100, Will Deacon wrote:
> On Mon, Aug 22, 2016 at 09:02:46AM -0500, Andy Gross wrote:
> > On Mon, Aug 22, 2016 at 02:43:14PM +0100, Will Deacon wrote:
> > > On Sat, Aug 20, 2016 at 12:51:13AM -0500, Andy Gross wrote:
> > > > This patch adds the SMC Session ID to the results passed back from SMC
> > > > calls.  The Qualcomm SMC implementation provides for interrupted SMC
> > > > functions.  When this occurs, the SMC call will return a session ID that
> > > > is required to be used when resuming the interrupted SMC call.
> > > > 
> > > > Signed-off-by: Andy Gross <andy.gr...@linaro.org>
> > > > ---
> > > >  arch/arm64/kernel/asm-offsets.c | 1 +
> > > >  arch/arm64/kernel/smccc-call.S  | 1 +
> > > >  include/linux/arm-smccc.h   | 4 +++-
> > > >  3 files changed, 5 insertions(+), 1 deletion(-)
> > > 
> > > [...]
> > > 
> > > > diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
> > > > index b5abfda..82d919f 100644
> > > > --- a/include/linux/arm-smccc.h
> > > > +++ b/include/linux/arm-smccc.h
> > > > @@ -63,18 +63,20 @@
> > > >  /**
> > > >   * struct arm_smccc_res - Result from SMC/HVC call
> > > >   * @a0-a3 result values from registers 0 to 3
> > > > + * @a6 Session ID register (optional)
> > > >   */
> > > >  struct arm_smccc_res {
> > > > unsigned long a0;
> > > > unsigned long a1;
> > > > unsigned long a2;
> > > > unsigned long a3;
> > > > +   unsigned long a6;
> > > >  };
> > > >  
> > > >  /**
> > > >   * arm_smccc_smc() - make SMC calls
> > > >   * @a0-a7: arguments passed in registers 0 to 7
> > > > - * @res: result values from registers 0 to 3
> > > > + * @res: result values from registers 0 to 3 and optional register 6
> > > 
> > > AFAICT from reading the SMCCC spec, parameter register 6 is 
> > > "Unpredictable,
> > > Scratch registers" in return state, so I don't think this is correct.
> > > 
> > > What am I missing?
> > 
> > In the case of Qualcomm's implementation, they return a value in register 6 
> > that
> > may or may not be used in subsequent calls.  If I want to leverage the 
> > arm_smccc
> > functions, then I need to extend them to include the optional return value. 
> >  The
> > downside to this is that everyone who uses this is exposed to it.
> 
> Yes, I'm not keen on forcing this behaviour for everybody, as you never
> know what other firmware might do with unexpected a6 values. Could we
> perhaps quirk it, along the lines of the completely untested patch below?

A quirk would work fine.  I'll try this out and get back to you.

Thanks,

Andy


> --->8
> 
> diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
> index 05070b72fc28..1895e87d0240 100644
> --- a/arch/arm64/kernel/asm-offsets.c
> +++ b/arch/arm64/kernel/asm-offsets.c
> @@ -141,6 +141,8 @@ int main(void)
>  #endif
>DEFINE(ARM_SMCCC_RES_X0_OFFS,  offsetof(struct arm_smccc_res, a0));
>DEFINE(ARM_SMCCC_RES_X2_OFFS,  offsetof(struct arm_smccc_res, a2));
> +  DEFINE(ARM_SMCCC_RES_QUIRK_ID_OFFS,offsetof(struct 
> arm_smccc_res, quirk.id));
> +  DEFINE(ARM_SMCCC_RES_QUIRK_STATE_OFFS, offsetof(struct arm_smccc_res, 
> quirk.state));
>BLANK();
>DEFINE(HIBERN_PBE_ORIG,offsetof(struct pbe, orig_address));
>DEFINE(HIBERN_PBE_ADDR,offsetof(struct pbe, address));
> diff --git a/arch/arm64/kernel/smccc-call.S b/arch/arm64/kernel/smccc-call.S
> index ae0496fa4235..3c6c976eaf5c 100644
> --- a/arch/arm64/kernel/smccc-call.S
> +++ b/arch/arm64/kernel/smccc-call.S
> @@ -12,6 +12,7 @@
>   *
>   */
>  #include 
> +#include 
>  #include 
>  
>   .macro SMCCC instr
> @@ -20,7 +21,12 @@
>   ldr x4, [sp]
>   stp x0, x1, [x4, #ARM_SMCCC_RES_X0_OFFS]
>   stp x2, x3, [x4, #ARM_SMCCC_RES_X2_OFFS]
> - ret
> + ldr x9, [x4, #ARM_SMCCC_RES_QUIRK_ID_OFFS]
> + cbz x9, 1f /* ARM_SMCCC_QUIRK_NONE */
> + cmp x9, #ARM_SMCCC_QUIRK_QCOM_A6
> + b.ne1f
> + str x6, [x4, ARM_SMCCC_RES_QUIRK_STATE_OFFS]
> +1:   ret
>   .cfi_endproc
>   .endm
>  
> diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
> index b5abfda80465..a3a6e291feb6 100644
> --- a/include/linux/arm-smccc.h
> +++ b/include

Re: [PATCH 1/2] arm64: kernel: Add SMC Session ID to results

[Andy Gross]

On Mon, Aug 22, 2016 at 03:53:26PM +0100, Will Deacon wrote:
> On Mon, Aug 22, 2016 at 09:02:46AM -0500, Andy Gross wrote:
> > On Mon, Aug 22, 2016 at 02:43:14PM +0100, Will Deacon wrote:
> > > On Sat, Aug 20, 2016 at 12:51:13AM -0500, Andy Gross wrote:
> > > > This patch adds the SMC Session ID to the results passed back from SMC
> > > > calls.  The Qualcomm SMC implementation provides for interrupted SMC
> > > > functions.  When this occurs, the SMC call will return a session ID that
> > > > is required to be used when resuming the interrupted SMC call.
> > > > 
> > > > Signed-off-by: Andy Gross 
> > > > ---
> > > >  arch/arm64/kernel/asm-offsets.c | 1 +
> > > >  arch/arm64/kernel/smccc-call.S  | 1 +
> > > >  include/linux/arm-smccc.h   | 4 +++-
> > > >  3 files changed, 5 insertions(+), 1 deletion(-)
> > > 
> > > [...]
> > > 
> > > > diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
> > > > index b5abfda..82d919f 100644
> > > > --- a/include/linux/arm-smccc.h
> > > > +++ b/include/linux/arm-smccc.h
> > > > @@ -63,18 +63,20 @@
> > > >  /**
> > > >   * struct arm_smccc_res - Result from SMC/HVC call
> > > >   * @a0-a3 result values from registers 0 to 3
> > > > + * @a6 Session ID register (optional)
> > > >   */
> > > >  struct arm_smccc_res {
> > > > unsigned long a0;
> > > > unsigned long a1;
> > > > unsigned long a2;
> > > > unsigned long a3;
> > > > +   unsigned long a6;
> > > >  };
> > > >  
> > > >  /**
> > > >   * arm_smccc_smc() - make SMC calls
> > > >   * @a0-a7: arguments passed in registers 0 to 7
> > > > - * @res: result values from registers 0 to 3
> > > > + * @res: result values from registers 0 to 3 and optional register 6
> > > 
> > > AFAICT from reading the SMCCC spec, parameter register 6 is 
> > > "Unpredictable,
> > > Scratch registers" in return state, so I don't think this is correct.
> > > 
> > > What am I missing?
> > 
> > In the case of Qualcomm's implementation, they return a value in register 6 
> > that
> > may or may not be used in subsequent calls.  If I want to leverage the 
> > arm_smccc
> > functions, then I need to extend them to include the optional return value. 
> >  The
> > downside to this is that everyone who uses this is exposed to it.
> 
> Yes, I'm not keen on forcing this behaviour for everybody, as you never
> know what other firmware might do with unexpected a6 values. Could we
> perhaps quirk it, along the lines of the completely untested patch below?

A quirk would work fine.  I'll try this out and get back to you.

Thanks,

Andy


> --->8
> 
> diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
> index 05070b72fc28..1895e87d0240 100644
> --- a/arch/arm64/kernel/asm-offsets.c
> +++ b/arch/arm64/kernel/asm-offsets.c
> @@ -141,6 +141,8 @@ int main(void)
>  #endif
>DEFINE(ARM_SMCCC_RES_X0_OFFS,  offsetof(struct arm_smccc_res, a0));
>DEFINE(ARM_SMCCC_RES_X2_OFFS,  offsetof(struct arm_smccc_res, a2));
> +  DEFINE(ARM_SMCCC_RES_QUIRK_ID_OFFS,offsetof(struct 
> arm_smccc_res, quirk.id));
> +  DEFINE(ARM_SMCCC_RES_QUIRK_STATE_OFFS, offsetof(struct arm_smccc_res, 
> quirk.state));
>BLANK();
>DEFINE(HIBERN_PBE_ORIG,offsetof(struct pbe, orig_address));
>DEFINE(HIBERN_PBE_ADDR,offsetof(struct pbe, address));
> diff --git a/arch/arm64/kernel/smccc-call.S b/arch/arm64/kernel/smccc-call.S
> index ae0496fa4235..3c6c976eaf5c 100644
> --- a/arch/arm64/kernel/smccc-call.S
> +++ b/arch/arm64/kernel/smccc-call.S
> @@ -12,6 +12,7 @@
>   *
>   */
>  #include 
> +#include 
>  #include 
>  
>   .macro SMCCC instr
> @@ -20,7 +21,12 @@
>   ldr x4, [sp]
>   stp x0, x1, [x4, #ARM_SMCCC_RES_X0_OFFS]
>   stp x2, x3, [x4, #ARM_SMCCC_RES_X2_OFFS]
> - ret
> + ldr x9, [x4, #ARM_SMCCC_RES_QUIRK_ID_OFFS]
> + cbz x9, 1f /* ARM_SMCCC_QUIRK_NONE */
> + cmp x9, #ARM_SMCCC_QUIRK_QCOM_A6
> + b.ne1f
> + str x6, [x4, ARM_SMCCC_RES_QUIRK_STATE_OFFS]
> +1:   ret
>   .cfi_endproc
>   .endm
>  
> diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
> index b5abfda80465..a3a6e291feb6 100644
> --- a/include/linux/arm-smccc.h
> +++ b/include/linux/arm-smccc.h
> @@ -14

Re: [PATCH 1/2] arm64: kernel: Add SMC Session ID to results

[Andy Gross]

On Mon, Aug 22, 2016 at 02:43:14PM +0100, Will Deacon wrote:
> On Sat, Aug 20, 2016 at 12:51:13AM -0500, Andy Gross wrote:
> > This patch adds the SMC Session ID to the results passed back from SMC
> > calls.  The Qualcomm SMC implementation provides for interrupted SMC
> > functions.  When this occurs, the SMC call will return a session ID that
> > is required to be used when resuming the interrupted SMC call.
> > 
> > Signed-off-by: Andy Gross <andy.gr...@linaro.org>
> > ---
> >  arch/arm64/kernel/asm-offsets.c | 1 +
> >  arch/arm64/kernel/smccc-call.S  | 1 +
> >  include/linux/arm-smccc.h   | 4 +++-
> >  3 files changed, 5 insertions(+), 1 deletion(-)
> 
> [...]
> 
> > diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
> > index b5abfda..82d919f 100644
> > --- a/include/linux/arm-smccc.h
> > +++ b/include/linux/arm-smccc.h
> > @@ -63,18 +63,20 @@
> >  /**
> >   * struct arm_smccc_res - Result from SMC/HVC call
> >   * @a0-a3 result values from registers 0 to 3
> > + * @a6 Session ID register (optional)
> >   */
> >  struct arm_smccc_res {
> > unsigned long a0;
> > unsigned long a1;
> > unsigned long a2;
> > unsigned long a3;
> > +   unsigned long a6;
> >  };
> >  
> >  /**
> >   * arm_smccc_smc() - make SMC calls
> >   * @a0-a7: arguments passed in registers 0 to 7
> > - * @res: result values from registers 0 to 3
> > + * @res: result values from registers 0 to 3 and optional register 6
> 
> AFAICT from reading the SMCCC spec, parameter register 6 is "Unpredictable,
> Scratch registers" in return state, so I don't think this is correct.
> 
> What am I missing?

In the case of Qualcomm's implementation, they return a value in register 6 that
may or may not be used in subsequent calls.  If I want to leverage the arm_smccc
functions, then I need to extend them to include the optional return value.  The
downside to this is that everyone who uses this is exposed to it.

Regards,

Andy

Re: [PATCH 1/2] arm64: kernel: Add SMC Session ID to results

[Andy Gross]

On Mon, Aug 22, 2016 at 02:43:14PM +0100, Will Deacon wrote:
> On Sat, Aug 20, 2016 at 12:51:13AM -0500, Andy Gross wrote:
> > This patch adds the SMC Session ID to the results passed back from SMC
> > calls.  The Qualcomm SMC implementation provides for interrupted SMC
> > functions.  When this occurs, the SMC call will return a session ID that
> > is required to be used when resuming the interrupted SMC call.
> > 
> > Signed-off-by: Andy Gross 
> > ---
> >  arch/arm64/kernel/asm-offsets.c | 1 +
> >  arch/arm64/kernel/smccc-call.S  | 1 +
> >  include/linux/arm-smccc.h   | 4 +++-
> >  3 files changed, 5 insertions(+), 1 deletion(-)
> 
> [...]
> 
> > diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
> > index b5abfda..82d919f 100644
> > --- a/include/linux/arm-smccc.h
> > +++ b/include/linux/arm-smccc.h
> > @@ -63,18 +63,20 @@
> >  /**
> >   * struct arm_smccc_res - Result from SMC/HVC call
> >   * @a0-a3 result values from registers 0 to 3
> > + * @a6 Session ID register (optional)
> >   */
> >  struct arm_smccc_res {
> > unsigned long a0;
> > unsigned long a1;
> > unsigned long a2;
> > unsigned long a3;
> > +   unsigned long a6;
> >  };
> >  
> >  /**
> >   * arm_smccc_smc() - make SMC calls
> >   * @a0-a7: arguments passed in registers 0 to 7
> > - * @res: result values from registers 0 to 3
> > + * @res: result values from registers 0 to 3 and optional register 6
> 
> AFAICT from reading the SMCCC spec, parameter register 6 is "Unpredictable,
> Scratch registers" in return state, so I don't think this is correct.
> 
> What am I missing?

In the case of Qualcomm's implementation, they return a value in register 6 that
may or may not be used in subsequent calls.  If I want to leverage the arm_smccc
functions, then I need to extend them to include the optional return value.  The
downside to this is that everyone who uses this is exposed to it.

Regards,

Andy

[PATCH] ARM: cacheflush: Remove unused secure_flush_area API

[Andy Gross]

This patch removes the unused secure_flush_area function.  The only
consumer of this function has moved to using the streaming DMA APIs.

Signed-off-by: Andy Gross <andy.gr...@linaro.org>
---
 arch/arm/include/asm/cacheflush.h | 17 -
 1 file changed, 17 deletions(-)

diff --git a/arch/arm/include/asm/cacheflush.h 
b/arch/arm/include/asm/cacheflush.h
index 9156fc3..bdd283b 100644
--- a/arch/arm/include/asm/cacheflush.h
+++ b/arch/arm/include/asm/cacheflush.h
@@ -501,21 +501,4 @@ static inline void set_kernel_text_ro(void) { }
 void flush_uprobe_xol_access(struct page *page, unsigned long uaddr,
 void *kaddr, unsigned long len);
 
-/**
- * secure_flush_area - ensure coherency across the secure boundary
- * @addr: virtual address
- * @size: size of region
- *
- * Ensure that the specified area of memory is coherent across the secure
- * boundary from the non-secure side.  This is used when calling secure
- * firmware where the secure firmware does not ensure coherency.
- */
-static inline void secure_flush_area(const void *addr, size_t size)
-{
-   phys_addr_t phys = __pa(addr);
-
-   __cpuc_flush_dcache_area((void *)addr, size);
-   outer_flush_range(phys, phys + size);
-}
-
 #endif
-- 
1.9.1

[PATCH] ARM: cacheflush: Remove unused secure_flush_area API

[Andy Gross]

This patch removes the unused secure_flush_area function.  The only
consumer of this function has moved to using the streaming DMA APIs.

Signed-off-by: Andy Gross 
---
 arch/arm/include/asm/cacheflush.h | 17 -
 1 file changed, 17 deletions(-)

diff --git a/arch/arm/include/asm/cacheflush.h 
b/arch/arm/include/asm/cacheflush.h
index 9156fc3..bdd283b 100644
--- a/arch/arm/include/asm/cacheflush.h
+++ b/arch/arm/include/asm/cacheflush.h
@@ -501,21 +501,4 @@ static inline void set_kernel_text_ro(void) { }
 void flush_uprobe_xol_access(struct page *page, unsigned long uaddr,
 void *kaddr, unsigned long len);
 
-/**
- * secure_flush_area - ensure coherency across the secure boundary
- * @addr: virtual address
- * @size: size of region
- *
- * Ensure that the specified area of memory is coherent across the secure
- * boundary from the non-secure side.  This is used when calling secure
- * firmware where the secure firmware does not ensure coherency.
- */
-static inline void secure_flush_area(const void *addr, size_t size)
-{
-   phys_addr_t phys = __pa(addr);
-
-   __cpuc_flush_dcache_area((void *)addr, size);
-   outer_flush_range(phys, phys + size);
-}
-
 #endif
-- 
1.9.1

[PATCH 1/2] arm64: kernel: Add SMC Session ID to results

[Andy Gross]

This patch adds the SMC Session ID to the results passed back from SMC
calls.  The Qualcomm SMC implementation provides for interrupted SMC
functions.  When this occurs, the SMC call will return a session ID that
is required to be used when resuming the interrupted SMC call.

Signed-off-by: Andy Gross <andy.gr...@linaro.org>
---
 arch/arm64/kernel/asm-offsets.c | 1 +
 arch/arm64/kernel/smccc-call.S  | 1 +
 include/linux/arm-smccc.h   | 4 +++-
 3 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
index 05070b7..ff38c58 100644
--- a/arch/arm64/kernel/asm-offsets.c
+++ b/arch/arm64/kernel/asm-offsets.c
@@ -141,6 +141,7 @@ int main(void)
 #endif
   DEFINE(ARM_SMCCC_RES_X0_OFFS,offsetof(struct arm_smccc_res, a0));
   DEFINE(ARM_SMCCC_RES_X2_OFFS,offsetof(struct arm_smccc_res, a2));
+  DEFINE(ARM_SMCCC_RES_X6_OFFS,offsetof(struct arm_smccc_res, a6));
   BLANK();
   DEFINE(HIBERN_PBE_ORIG,  offsetof(struct pbe, orig_address));
   DEFINE(HIBERN_PBE_ADDR,  offsetof(struct pbe, address));
diff --git a/arch/arm64/kernel/smccc-call.S b/arch/arm64/kernel/smccc-call.S
index ae0496f..278dc9a 100644
--- a/arch/arm64/kernel/smccc-call.S
+++ b/arch/arm64/kernel/smccc-call.S
@@ -20,6 +20,7 @@
ldr x4, [sp]
stp x0, x1, [x4, #ARM_SMCCC_RES_X0_OFFS]
stp x2, x3, [x4, #ARM_SMCCC_RES_X2_OFFS]
+   str x6, [x4, #ARM_SMCCC_RES_X6_OFFS]
ret
.cfi_endproc
.endm
diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
index b5abfda..82d919f 100644
--- a/include/linux/arm-smccc.h
+++ b/include/linux/arm-smccc.h
@@ -63,18 +63,20 @@
 /**
  * struct arm_smccc_res - Result from SMC/HVC call
  * @a0-a3 result values from registers 0 to 3
+ * @a6 Session ID register (optional)
  */
 struct arm_smccc_res {
unsigned long a0;
unsigned long a1;
unsigned long a2;
unsigned long a3;
+   unsigned long a6;
 };
 
 /**
  * arm_smccc_smc() - make SMC calls
  * @a0-a7: arguments passed in registers 0 to 7
- * @res: result values from registers 0 to 3
+ * @res: result values from registers 0 to 3 and optional register 6
  *
  * This function is used to make SMC calls following SMC Calling Convention.
  * The content of the supplied param are copied to registers 0 to 7 prior
-- 
1.9.1

[PATCH 2/2] firmware: qcom: scm: Fix interrupted SCM calls

[Andy Gross]

This patch fixes an issue with the SCM64 calls.  Sometimes SCM calls can
be interrupted and return early.  When this happens, the contents of
register 6 will contain a session ID that is required when resuming the
SCM call.

Signed-off-by: Andy Gross <andy.gr...@linaro.org>
---
 drivers/firmware/qcom_scm-64.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/firmware/qcom_scm-64.c b/drivers/firmware/qcom_scm-64.c
index 4a0f5ea..1851294 100644
--- a/drivers/firmware/qcom_scm-64.c
+++ b/drivers/firmware/qcom_scm-64.c
@@ -131,10 +131,12 @@ static int qcom_scm_call(struct device *dev, u32 svc_id, 
u32 cmd_id,
 qcom_smccc_convention,
 ARM_SMCCC_OWNER_SIP, fn_id);
 
+   res->a6 = 0;
+
do {
arm_smccc_smc(cmd, desc->arginfo, desc->args[0],
- desc->args[1], desc->args[2], x5, 0, 0,
- res);
+ desc->args[1], desc->args[2], x5, res->a6,
+ 0, res);
} while (res->a0 == QCOM_SCM_INTERRUPTED);
 
mutex_unlock(_scm_lock);
-- 
1.9.1

[PATCH 0/2] Qualcomm SMCCC Session ID Support

[Andy Gross]

This set of patches fixes a problem with the recent adoption of the ARM
SMCCC in the Qualcomm SCM firmware.  Qualcomm actually uses the optional
Trusted OS Session ID parameter.  When SCM calls are interrupted, the
session ID field is populated with a value that must be used when the
SCM call is resumed.

The first patch extends the arm_smccc_res structure to contain the
additional a6 result field and modifies the SMCCC ASM macro to store
register 6 in the additional field.  The second patch modifies the
Qualcomm SCM code to use the new result field.

Andy Gross (2):
  arm64: kernel: Add SMC Session ID to results
  firmware: qcom: scm: Fix interrupted SCM calls

 arch/arm64/kernel/asm-offsets.c | 1 +
 arch/arm64/kernel/smccc-call.S  | 1 +
 drivers/firmware/qcom_scm-64.c  | 6 --
 include/linux/arm-smccc.h   | 4 +++-
 4 files changed, 9 insertions(+), 3 deletions(-)

-- 
1.9.1

[PATCH 1/2] arm64: kernel: Add SMC Session ID to results

[Andy Gross]

This patch adds the SMC Session ID to the results passed back from SMC
calls.  The Qualcomm SMC implementation provides for interrupted SMC
functions.  When this occurs, the SMC call will return a session ID that
is required to be used when resuming the interrupted SMC call.

Signed-off-by: Andy Gross 
---
 arch/arm64/kernel/asm-offsets.c | 1 +
 arch/arm64/kernel/smccc-call.S  | 1 +
 include/linux/arm-smccc.h   | 4 +++-
 3 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
index 05070b7..ff38c58 100644
--- a/arch/arm64/kernel/asm-offsets.c
+++ b/arch/arm64/kernel/asm-offsets.c
@@ -141,6 +141,7 @@ int main(void)
 #endif
   DEFINE(ARM_SMCCC_RES_X0_OFFS,offsetof(struct arm_smccc_res, a0));
   DEFINE(ARM_SMCCC_RES_X2_OFFS,offsetof(struct arm_smccc_res, a2));
+  DEFINE(ARM_SMCCC_RES_X6_OFFS,offsetof(struct arm_smccc_res, a6));
   BLANK();
   DEFINE(HIBERN_PBE_ORIG,  offsetof(struct pbe, orig_address));
   DEFINE(HIBERN_PBE_ADDR,  offsetof(struct pbe, address));
diff --git a/arch/arm64/kernel/smccc-call.S b/arch/arm64/kernel/smccc-call.S
index ae0496f..278dc9a 100644
--- a/arch/arm64/kernel/smccc-call.S
+++ b/arch/arm64/kernel/smccc-call.S
@@ -20,6 +20,7 @@
ldr x4, [sp]
stp x0, x1, [x4, #ARM_SMCCC_RES_X0_OFFS]
stp x2, x3, [x4, #ARM_SMCCC_RES_X2_OFFS]
+   str x6, [x4, #ARM_SMCCC_RES_X6_OFFS]
ret
.cfi_endproc
.endm
diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
index b5abfda..82d919f 100644
--- a/include/linux/arm-smccc.h
+++ b/include/linux/arm-smccc.h
@@ -63,18 +63,20 @@
 /**
  * struct arm_smccc_res - Result from SMC/HVC call
  * @a0-a3 result values from registers 0 to 3
+ * @a6 Session ID register (optional)
  */
 struct arm_smccc_res {
unsigned long a0;
unsigned long a1;
unsigned long a2;
unsigned long a3;
+   unsigned long a6;
 };
 
 /**
  * arm_smccc_smc() - make SMC calls
  * @a0-a7: arguments passed in registers 0 to 7
- * @res: result values from registers 0 to 3
+ * @res: result values from registers 0 to 3 and optional register 6
  *
  * This function is used to make SMC calls following SMC Calling Convention.
  * The content of the supplied param are copied to registers 0 to 7 prior
-- 
1.9.1

[PATCH 2/2] firmware: qcom: scm: Fix interrupted SCM calls

[Andy Gross]

This patch fixes an issue with the SCM64 calls.  Sometimes SCM calls can
be interrupted and return early.  When this happens, the contents of
register 6 will contain a session ID that is required when resuming the
SCM call.

Signed-off-by: Andy Gross 
---
 drivers/firmware/qcom_scm-64.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/firmware/qcom_scm-64.c b/drivers/firmware/qcom_scm-64.c
index 4a0f5ea..1851294 100644
--- a/drivers/firmware/qcom_scm-64.c
+++ b/drivers/firmware/qcom_scm-64.c
@@ -131,10 +131,12 @@ static int qcom_scm_call(struct device *dev, u32 svc_id, 
u32 cmd_id,
 qcom_smccc_convention,
 ARM_SMCCC_OWNER_SIP, fn_id);
 
+   res->a6 = 0;
+
do {
arm_smccc_smc(cmd, desc->arginfo, desc->args[0],
- desc->args[1], desc->args[2], x5, 0, 0,
- res);
+ desc->args[1], desc->args[2], x5, res->a6,
+ 0, res);
} while (res->a0 == QCOM_SCM_INTERRUPTED);
 
mutex_unlock(_scm_lock);
-- 
1.9.1

[PATCH 0/2] Qualcomm SMCCC Session ID Support

[Andy Gross]

This set of patches fixes a problem with the recent adoption of the ARM
SMCCC in the Qualcomm SCM firmware.  Qualcomm actually uses the optional
Trusted OS Session ID parameter.  When SCM calls are interrupted, the
session ID field is populated with a value that must be used when the
SCM call is resumed.

The first patch extends the arm_smccc_res structure to contain the
additional a6 result field and modifies the SMCCC ASM macro to store
register 6 in the additional field.  The second patch modifies the
Qualcomm SCM code to use the new result field.

Andy Gross (2):
  arm64: kernel: Add SMC Session ID to results
  firmware: qcom: scm: Fix interrupted SCM calls

 arch/arm64/kernel/asm-offsets.c | 1 +
 arch/arm64/kernel/smccc-call.S  | 1 +
 drivers/firmware/qcom_scm-64.c  | 6 --
 include/linux/arm-smccc.h   | 4 +++-
 4 files changed, 9 insertions(+), 3 deletions(-)

-- 
1.9.1

Re: [PATCH v3 0/5] dts patches for qcom tsens support

[Andy Gross]

On Wed, Aug 17, 2016 at 10:48:43AM +0530, Rajendra Nayak wrote:
> Hey Andy,
> 
> This is a respin of v2 with some minor fixes pointed out by Rob.
> Please pull these in for 4.9
> 
> Thanks,
> Rajendra

I pulled these in.

Andy

Re: [PATCH v3 0/5] dts patches for qcom tsens support

[Andy Gross]

On Wed, Aug 17, 2016 at 10:48:43AM +0530, Rajendra Nayak wrote:
> Hey Andy,
> 
> This is a respin of v2 with some minor fixes pointed out by Rob.
> Please pull these in for 4.9
> 
> Thanks,
> Rajendra

I pulled these in.

Andy

[PATCH] ARM: qcom: Cleanup/Remove unnecessary board file

[Andy Gross]

This patch removes the unnecessary board file.  The generic machine
definition is sufficient for the Qualcomm platforms.

Signed-off-by: Andy Gross <andy.gr...@linaro.org>
---
 arch/arm/mach-qcom/Makefile |  1 -
 arch/arm/mach-qcom/board.c  | 31 ---
 2 files changed, 32 deletions(-)
 delete mode 100644 arch/arm/mach-qcom/board.c

diff --git a/arch/arm/mach-qcom/Makefile b/arch/arm/mach-qcom/Makefile
index e324375..12878e9 100644
--- a/arch/arm/mach-qcom/Makefile
+++ b/arch/arm/mach-qcom/Makefile
@@ -1,2 +1 @@
-obj-y  := board.o
 obj-$(CONFIG_SMP)  += platsmp.o
diff --git a/arch/arm/mach-qcom/board.c b/arch/arm/mach-qcom/board.c
deleted file mode 100644
index d8060df..000
--- a/arch/arm/mach-qcom/board.c
+++ /dev/null
@@ -1,31 +0,0 @@
-/* Copyright (c) 2010-2014 The Linux Foundation. All rights reserved.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 and
- * only version 2 as published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- */
-
-#include 
-
-#include 
-
-static const char * const qcom_dt_match[] __initconst = {
-   "qcom,apq8064",
-   "qcom,apq8074-dragonboard",
-   "qcom,apq8084",
-   "qcom,ipq8062",
-   "qcom,ipq8064",
-   "qcom,msm8660-surf",
-   "qcom,msm8960-cdp",
-   "qcom,mdm9615",
-   NULL
-};
-
-DT_MACHINE_START(QCOM_DT, "Qualcomm (Flattened Device Tree)")
-   .dt_compat = qcom_dt_match,
-MACHINE_END
-- 
1.9.1

[PATCH] ARM: qcom: Cleanup/Remove unnecessary board file

[Andy Gross]

This patch removes the unnecessary board file.  The generic machine
definition is sufficient for the Qualcomm platforms.

Signed-off-by: Andy Gross 
---
 arch/arm/mach-qcom/Makefile |  1 -
 arch/arm/mach-qcom/board.c  | 31 ---
 2 files changed, 32 deletions(-)
 delete mode 100644 arch/arm/mach-qcom/board.c

diff --git a/arch/arm/mach-qcom/Makefile b/arch/arm/mach-qcom/Makefile
index e324375..12878e9 100644
--- a/arch/arm/mach-qcom/Makefile
+++ b/arch/arm/mach-qcom/Makefile
@@ -1,2 +1 @@
-obj-y  := board.o
 obj-$(CONFIG_SMP)  += platsmp.o
diff --git a/arch/arm/mach-qcom/board.c b/arch/arm/mach-qcom/board.c
deleted file mode 100644
index d8060df..000
--- a/arch/arm/mach-qcom/board.c
+++ /dev/null
@@ -1,31 +0,0 @@
-/* Copyright (c) 2010-2014 The Linux Foundation. All rights reserved.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 and
- * only version 2 as published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- */
-
-#include 
-
-#include 
-
-static const char * const qcom_dt_match[] __initconst = {
-   "qcom,apq8064",
-   "qcom,apq8074-dragonboard",
-   "qcom,apq8084",
-   "qcom,ipq8062",
-   "qcom,ipq8064",
-   "qcom,msm8660-surf",
-   "qcom,msm8960-cdp",
-   "qcom,mdm9615",
-   NULL
-};
-
-DT_MACHINE_START(QCOM_DT, "Qualcomm (Flattened Device Tree)")
-   .dt_compat = qcom_dt_match,
-MACHINE_END
-- 
1.9.1

Re: [PATCH] soc: qcom: smd: Correct compile stub prototypes

[Andy Gross]

On Tue, Aug 09, 2016 at 05:36:02PM -0700, Bjorn Andersson wrote:
> The prototypes for the compile stubs was not properly marked as static
> inline, this patch corrects this.
> 
> Fixes: f79a917e69e1 ("Merge tag 'qcom-soc-for-4.7-2' into net-next")
> Signed-off-by: Bjorn Andersson 
> ---

Ok.  Looks fine to me.


Andy

Re: [PATCH] soc: qcom: smd: Correct compile stub prototypes

[Andy Gross]

On Tue, Aug 09, 2016 at 05:36:02PM -0700, Bjorn Andersson wrote:
> The prototypes for the compile stubs was not properly marked as static
> inline, this patch corrects this.
> 
> Fixes: f79a917e69e1 ("Merge tag 'qcom-soc-for-4.7-2' into net-next")
> Signed-off-by: Bjorn Andersson 
> ---

Ok.  Looks fine to me.


Andy

Re: [PATCH v2 0/5] dts patches for qcom tsens support

[Andy Gross]

On Wed, Aug 10, 2016 at 12:13:54PM +0530, Rajendra Nayak wrote:
> Hey Andy,
> 
> Tsens driver patches are pulled in by Eduardo [1]
> but looks like they missed the 4.8 merge window.
> Nevertheless, these are dts changes for the various platforms
> supported by the driver, which are acked by Eduardo.
> Can you please pull these in for 4.9? (I am hoping the driver
> would be merged in in 4.9 as well)

Ok, I'll look to pull these in.  If I see any issues I'll let you know.


regards,

Andy

Re: [PATCH v2 0/5] dts patches for qcom tsens support

[Andy Gross]

On Wed, Aug 10, 2016 at 12:13:54PM +0530, Rajendra Nayak wrote:
> Hey Andy,
> 
> Tsens driver patches are pulled in by Eduardo [1]
> but looks like they missed the 4.8 merge window.
> Nevertheless, these are dts changes for the various platforms
> supported by the driver, which are acked by Eduardo.
> Can you please pull these in for 4.9? (I am hoping the driver
> would be merged in in 4.9 as well)

Ok, I'll look to pull these in.  If I see any issues I'll let you know.


regards,

Andy

Re: [PATCH 2/3] regulator: qcom_smd: Fix voltage ranges for pma8084 ftsmps and pldo

[Andy Gross]

On Thu, Aug 04, 2016 at 05:57:48PM -0700, Stephen Boyd wrote:
> On 07/11, Andy Gross wrote:
> > On Mon, Jul 11, 2016 at 02:50:08PM -0700, Stephen Boyd wrote:
> > > The voltage ranges listed here are wrong. The pma8084 pldo
> > > supports three different overlapping voltage ranges with
> > > differing step sizes and the pma8084 ftsmps supports two. These
> > > ranges can be seen in the "native" spmi regulator driver
> > > (qcom_spmi-regulator.c) at pldo_ranges[] and ftsmps_ranges[]
> > > respectively. Port these ranges over to the RPM SMD regulator
> > > driver so that we list the appropriate set of supported voltages
> > > on these types of regulators.
> > > 
> > > Cc: Andy Gross <andy.gr...@linaro.org>
> > > Cc: Bjorn Andersson <bjorn.anders...@linaro.org>
> > > Fixes: ee01d0c91ef1 ("regulator: qcom-smd: Add support for PMA8084")
> > > Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
> > 
> > 
> > 
> > >  static const struct regulator_desc pma8084_pldo = {
> > >   .linear_ranges = (struct regulator_linear_range[]) {
> > > - REGULATOR_LINEAR_RANGE(75,  0,  30, 25000),
> > > - REGULATOR_LINEAR_RANGE(150, 31, 99, 5),
> > > + REGULATOR_LINEAR_RANGE( 75,  0,  63, 12500),
> > 
> > It was my understanding that the PMOS ldos only support 25mV and 50mV
> > incremements.
> > 
> 
> Unfortunately that isn't true. It also supports 12.5mV steps for
> the lower voltage ranges.

Ok. with that resolved:

Reviewed-by: Andy Gross <andy.gr...@linaro.org>

Re: [PATCH 1/3] regulator: qcom_smd: Fix voltage ranges for pm8x41

[Andy Gross]

On Thu, Aug 04, 2016 at 05:58:26PM -0700, Stephen Boyd wrote:
> On 07/11, Andy Gross wrote:
> > On Mon, Jul 11, 2016 at 02:50:07PM -0700, Stephen Boyd wrote:
> > 
> > >  static const struct regulator_desc pm8941_pldo = {
> > >   .linear_ranges = (struct regulator_linear_range[]) {
> > > - REGULATOR_LINEAR_RANGE( 75,  0,  30, 25000),
> > > - REGULATOR_LINEAR_RANGE(150, 31, 99, 5),
> > > + REGULATOR_LINEAR_RANGE( 75,  0,  63, 12500),
> > > + REGULATOR_LINEAR_RANGE(155, 64, 126, 25000),
> > > + REGULATOR_LINEAR_RANGE(310, 127, 163, 5),
> > >   },
> > > - .n_linear_ranges = 2,
> > > - .n_voltages = 100,
> > > + .n_linear_ranges = 3,
> > > + .n_voltages = 164,
> > >   .ops = _smps_ldo_ops,
> > >  };
> > 
> > Still a little confused on if the 12.5mV is allowed on pmos ldo.  It seems 
> > like the
> > nmos has 1 range of 5mV steps.  The PMOS has 2 ranges, using 25mV and 50mV
> > 
> 
> The values I've put in these patches are the correct ranges.

Ok.  As with the other patch:

Reviewed-by: Andy Gross <andy.gr...@linaro.org>

Re: [PATCH 2/3] regulator: qcom_smd: Fix voltage ranges for pma8084 ftsmps and pldo

[Andy Gross]

On Thu, Aug 04, 2016 at 05:57:48PM -0700, Stephen Boyd wrote:
> On 07/11, Andy Gross wrote:
> > On Mon, Jul 11, 2016 at 02:50:08PM -0700, Stephen Boyd wrote:
> > > The voltage ranges listed here are wrong. The pma8084 pldo
> > > supports three different overlapping voltage ranges with
> > > differing step sizes and the pma8084 ftsmps supports two. These
> > > ranges can be seen in the "native" spmi regulator driver
> > > (qcom_spmi-regulator.c) at pldo_ranges[] and ftsmps_ranges[]
> > > respectively. Port these ranges over to the RPM SMD regulator
> > > driver so that we list the appropriate set of supported voltages
> > > on these types of regulators.
> > > 
> > > Cc: Andy Gross 
> > > Cc: Bjorn Andersson 
> > > Fixes: ee01d0c91ef1 ("regulator: qcom-smd: Add support for PMA8084")
> > > Signed-off-by: Stephen Boyd 
> > 
> > 
> > 
> > >  static const struct regulator_desc pma8084_pldo = {
> > >   .linear_ranges = (struct regulator_linear_range[]) {
> > > - REGULATOR_LINEAR_RANGE(75,  0,  30, 25000),
> > > - REGULATOR_LINEAR_RANGE(150, 31, 99, 5),
> > > + REGULATOR_LINEAR_RANGE( 75,  0,  63, 12500),
> > 
> > It was my understanding that the PMOS ldos only support 25mV and 50mV
> > incremements.
> > 
> 
> Unfortunately that isn't true. It also supports 12.5mV steps for
> the lower voltage ranges.

Ok. with that resolved:

Reviewed-by: Andy Gross 

Re: [PATCH 1/3] regulator: qcom_smd: Fix voltage ranges for pm8x41

[Andy Gross]

On Thu, Aug 04, 2016 at 05:58:26PM -0700, Stephen Boyd wrote:
> On 07/11, Andy Gross wrote:
> > On Mon, Jul 11, 2016 at 02:50:07PM -0700, Stephen Boyd wrote:
> > 
> > >  static const struct regulator_desc pm8941_pldo = {
> > >   .linear_ranges = (struct regulator_linear_range[]) {
> > > - REGULATOR_LINEAR_RANGE( 75,  0,  30, 25000),
> > > - REGULATOR_LINEAR_RANGE(150, 31, 99, 5),
> > > + REGULATOR_LINEAR_RANGE( 75,  0,  63, 12500),
> > > + REGULATOR_LINEAR_RANGE(155, 64, 126, 25000),
> > > + REGULATOR_LINEAR_RANGE(310, 127, 163, 5),
> > >   },
> > > - .n_linear_ranges = 2,
> > > - .n_voltages = 100,
> > > + .n_linear_ranges = 3,
> > > + .n_voltages = 164,
> > >   .ops = _smps_ldo_ops,
> > >  };
> > 
> > Still a little confused on if the 12.5mV is allowed on pmos ldo.  It seems 
> > like the
> > nmos has 1 range of 5mV steps.  The PMOS has 2 ranges, using 25mV and 50mV
> > 
> 
> The values I've put in these patches are the correct ranges.

Ok.  As with the other patch:

Reviewed-by: Andy Gross 

Re: SOC-specific action for irq_set_wake

[Andy Gross]

On Wed, Jul 20, 2016 at 06:16:06AM -0700, Sören Brinkmann wrote:
> Hi Marc,
> 
> On Wed, 2016-07-20 at 09:17:16 +0100, Marc Zyngier wrote:
> > On 20/07/16 00:34, Sören Brinkmann wrote:
> > > Hi Andy,
> > > 
> > > On Tue, 2016-07-19 at 17:47:13 -0500, Andy Gross wrote:
> > >> On Tue, Jul 19, 2016 at 11:18:04AM -0700, Sören Brinkmann wrote:
> > >>> Hi,
> > >>>
> > >>> we are working on the PM solution for Zynq MPSOC and ran into some
> > >>> problem when setting the wake source.
> > >>>
> > >>> The situation is that when the A53 is in suspend, the GIC(v2) may be
> > >>> powered down. In that state a companion core is handling wake
> > >>> events/IRQs, but we expect the OS/Linux to notify the companion core
> > >>> about what device/IRQ is a wake up source. Hence, my idea was to capture
> > >>> enabling/disabling wake IRQs in our platform PM code and then
> > >>> communicate with the FW as needed during suspend operations. The problem
> > >>> is: I don't see a good way to notify the platform code about these
> > >>> events.
> > >>
> > >> On Qualcomm platforms there is something similar.  When the system is 
> > >> power
> > >> collapsed, the GIC loses context and can no longer handle/generate IRQs. 
> > >>  There
> > >> is a separate block called the MPM that provides some registers that the 
> > >> user
> > >> can program.  These registers allow for up to 64 wake IRQs, each of 
> > >> which can
> > >> map to either a GPIO pin or an GIC IRQ.  The MPM also has a timer that 
> > >> can
> > >> generate a wake IRQ so that the system can wake up and maintain the time.
> > > 
> > > We have a full companion core running firmware. As in your case,
> > > we can use any IRQ source and some additional IOs as wake event. So,
> > > it's fundamentally very similar. Main difference is probably the
> > > interface. In our case, we have some platform-specific FW interfaces
> > > that we need to call. Basically, Linux doing an SMC call and then the
> > > secure monitor handling the rest. And for that we may also have to do
> > > some additional mapping of the IRQ number to something the FW interface
> > > understands.
> > > 
> > >>
> > >>>
> > >>> My ideas were:
> > >>> 1. Use the irq_chip irq_set_wake function
> > >>>   My thought was to implement the irq_set_wake function in a
> > >>>   SOC-specific way (could even be generic and call some notifier chain 
> > >>> or
> > >>>   similar) to notify the platform PM code when a device/IRQ is
> > >>>   enabled/disabled as wake up source.
> > >>>   My problem is that the SKIP_IRQ_SET_WAKE flag is set in the generic
> > >>>   driver (drivers/irqchip/irq-gic.c) and platforms cannot implement
> > >>>   irq_set_wake without changes in the common code.
> > >>
> > >> So not too long ago there were irq extensions that you could add in to 
> > >> an irq
> > >> controller that would allow for intercepting the set wake calls.  This 
> > >> went away
> > >> and was replaced by the hierarchical irq design.
> > > 
> > > Yeah, I though I remembered that and wanted to use it now and was slightly
> > > disappointed when I couldn't find the code anymore.
> > 
> > It was slaughtered for a good reason: It was unmaintainable, had
> > horrible performance issues, wasn't described in any of DT or ACPI, and
> > didn't fit any of the core code idioms. It has been replaced by
> > something we that is supported in the code code and that is working for
> > all current users of the GIC that have similar requirements to yours.
> > 
> > >> The way I am currently implementing the MPM for Qualcomm, I am defining 
> > >> the MPM
> > >> as a IRQ controller and creating relationships between the MPM and the 
> > >> GPIO
> > >> controller (source of irqs) and the GIC.  As irqs are set wake and 
> > >> cleared the
> > >> calls go up through the hierarchy and they call each irqchips functions 
> > >> (if you
> > >> have it setup to do that).
> > > 
> > > I suspected that some sort of dummy interrupt controller might be one
> > > way to do it. I was hoping to find a simpler way, but maybe this is the

Re: SOC-specific action for irq_set_wake

[Andy Gross]

On Wed, Jul 20, 2016 at 06:16:06AM -0700, Sören Brinkmann wrote:
> Hi Marc,
> 
> On Wed, 2016-07-20 at 09:17:16 +0100, Marc Zyngier wrote:
> > On 20/07/16 00:34, Sören Brinkmann wrote:
> > > Hi Andy,
> > > 
> > > On Tue, 2016-07-19 at 17:47:13 -0500, Andy Gross wrote:
> > >> On Tue, Jul 19, 2016 at 11:18:04AM -0700, Sören Brinkmann wrote:
> > >>> Hi,
> > >>>
> > >>> we are working on the PM solution for Zynq MPSOC and ran into some
> > >>> problem when setting the wake source.
> > >>>
> > >>> The situation is that when the A53 is in suspend, the GIC(v2) may be
> > >>> powered down. In that state a companion core is handling wake
> > >>> events/IRQs, but we expect the OS/Linux to notify the companion core
> > >>> about what device/IRQ is a wake up source. Hence, my idea was to capture
> > >>> enabling/disabling wake IRQs in our platform PM code and then
> > >>> communicate with the FW as needed during suspend operations. The problem
> > >>> is: I don't see a good way to notify the platform code about these
> > >>> events.
> > >>
> > >> On Qualcomm platforms there is something similar.  When the system is 
> > >> power
> > >> collapsed, the GIC loses context and can no longer handle/generate IRQs. 
> > >>  There
> > >> is a separate block called the MPM that provides some registers that the 
> > >> user
> > >> can program.  These registers allow for up to 64 wake IRQs, each of 
> > >> which can
> > >> map to either a GPIO pin or an GIC IRQ.  The MPM also has a timer that 
> > >> can
> > >> generate a wake IRQ so that the system can wake up and maintain the time.
> > > 
> > > We have a full companion core running firmware. As in your case,
> > > we can use any IRQ source and some additional IOs as wake event. So,
> > > it's fundamentally very similar. Main difference is probably the
> > > interface. In our case, we have some platform-specific FW interfaces
> > > that we need to call. Basically, Linux doing an SMC call and then the
> > > secure monitor handling the rest. And for that we may also have to do
> > > some additional mapping of the IRQ number to something the FW interface
> > > understands.
> > > 
> > >>
> > >>>
> > >>> My ideas were:
> > >>> 1. Use the irq_chip irq_set_wake function
> > >>>   My thought was to implement the irq_set_wake function in a
> > >>>   SOC-specific way (could even be generic and call some notifier chain 
> > >>> or
> > >>>   similar) to notify the platform PM code when a device/IRQ is
> > >>>   enabled/disabled as wake up source.
> > >>>   My problem is that the SKIP_IRQ_SET_WAKE flag is set in the generic
> > >>>   driver (drivers/irqchip/irq-gic.c) and platforms cannot implement
> > >>>   irq_set_wake without changes in the common code.
> > >>
> > >> So not too long ago there were irq extensions that you could add in to 
> > >> an irq
> > >> controller that would allow for intercepting the set wake calls.  This 
> > >> went away
> > >> and was replaced by the hierarchical irq design.
> > > 
> > > Yeah, I though I remembered that and wanted to use it now and was slightly
> > > disappointed when I couldn't find the code anymore.
> > 
> > It was slaughtered for a good reason: It was unmaintainable, had
> > horrible performance issues, wasn't described in any of DT or ACPI, and
> > didn't fit any of the core code idioms. It has been replaced by
> > something we that is supported in the code code and that is working for
> > all current users of the GIC that have similar requirements to yours.
> > 
> > >> The way I am currently implementing the MPM for Qualcomm, I am defining 
> > >> the MPM
> > >> as a IRQ controller and creating relationships between the MPM and the 
> > >> GPIO
> > >> controller (source of irqs) and the GIC.  As irqs are set wake and 
> > >> cleared the
> > >> calls go up through the hierarchy and they call each irqchips functions 
> > >> (if you
> > >> have it setup to do that).
> > > 
> > > I suspected that some sort of dummy interrupt controller might be one
> > > way to do it. I was hoping to find a simpler way, but maybe this is the

Re: SOC-specific action for irq_set_wake

[Andy Gross]

On Tue, Jul 19, 2016 at 11:18:04AM -0700, Sören Brinkmann wrote:
> Hi,
> 
> we are working on the PM solution for Zynq MPSOC and ran into some
> problem when setting the wake source.
> 
> The situation is that when the A53 is in suspend, the GIC(v2) may be
> powered down. In that state a companion core is handling wake
> events/IRQs, but we expect the OS/Linux to notify the companion core
> about what device/IRQ is a wake up source. Hence, my idea was to capture
> enabling/disabling wake IRQs in our platform PM code and then
> communicate with the FW as needed during suspend operations. The problem
> is: I don't see a good way to notify the platform code about these
> events.

On Qualcomm platforms there is something similar.  When the system is power
collapsed, the GIC loses context and can no longer handle/generate IRQs.  There
is a separate block called the MPM that provides some registers that the user
can program.  These registers allow for up to 64 wake IRQs, each of which can
map to either a GPIO pin or an GIC IRQ.  The MPM also has a timer that can
generate a wake IRQ so that the system can wake up and maintain the time.

> 
> My ideas were:
> 1. Use the irq_chip irq_set_wake function
>   My thought was to implement the irq_set_wake function in a
>   SOC-specific way (could even be generic and call some notifier chain or
>   similar) to notify the platform PM code when a device/IRQ is
>   enabled/disabled as wake up source.
>   My problem is that the SKIP_IRQ_SET_WAKE flag is set in the generic
>   driver (drivers/irqchip/irq-gic.c) and platforms cannot implement
>   irq_set_wake without changes in the common code.

So not too long ago there were irq extensions that you could add in to an irq
controller that would allow for intercepting the set wake calls.  This went away
and was replaced by the hierarchical irq design.

The way I am currently implementing the MPM for Qualcomm, I am defining the MPM
as a IRQ controller and creating relationships between the MPM and the GPIO
controller (source of irqs) and the GIC.  As irqs are set wake and cleared the
calls go up through the hierarchy and they call each irqchips functions (if you
have it setup to do that).


> 2. Stuff things into the secure monitor
>   I guess we could read the GIC registers once we enter the secure
>   monitor and do the communication with the companion core from there by
>   identifying unmasked IRQs as wake IRQs. My concern here is that it
>   might introduce additional hardcoded mappings that are much more
>   dynamic in Linux thanks to the DT description.

This could work, but you'd have to have control of the secure monitor code.  In
Qualcomm's case, that wouldn't work or couldn't because they won't change that
code.  And you'd have to have calls into the monitor to turn on/off the lines.

> 
> Does anybody have similar problems and probably already solved it?
> Any other suggestions for approaching the problem? Any preferred
> solution?

I think we have the same problem.  Can you provide more detail on the hardware
implementation of your wake irq controller?  I presume you have some set of
registers, an irq maybe, and some other stuff?  And how does it fit into the
overall architecture from a hardware perspective?

Regards,

Andy Gross

Re: SOC-specific action for irq_set_wake

[Andy Gross]

On Tue, Jul 19, 2016 at 11:18:04AM -0700, Sören Brinkmann wrote:
> Hi,
> 
> we are working on the PM solution for Zynq MPSOC and ran into some
> problem when setting the wake source.
> 
> The situation is that when the A53 is in suspend, the GIC(v2) may be
> powered down. In that state a companion core is handling wake
> events/IRQs, but we expect the OS/Linux to notify the companion core
> about what device/IRQ is a wake up source. Hence, my idea was to capture
> enabling/disabling wake IRQs in our platform PM code and then
> communicate with the FW as needed during suspend operations. The problem
> is: I don't see a good way to notify the platform code about these
> events.

On Qualcomm platforms there is something similar.  When the system is power
collapsed, the GIC loses context and can no longer handle/generate IRQs.  There
is a separate block called the MPM that provides some registers that the user
can program.  These registers allow for up to 64 wake IRQs, each of which can
map to either a GPIO pin or an GIC IRQ.  The MPM also has a timer that can
generate a wake IRQ so that the system can wake up and maintain the time.

> 
> My ideas were:
> 1. Use the irq_chip irq_set_wake function
>   My thought was to implement the irq_set_wake function in a
>   SOC-specific way (could even be generic and call some notifier chain or
>   similar) to notify the platform PM code when a device/IRQ is
>   enabled/disabled as wake up source.
>   My problem is that the SKIP_IRQ_SET_WAKE flag is set in the generic
>   driver (drivers/irqchip/irq-gic.c) and platforms cannot implement
>   irq_set_wake without changes in the common code.

So not too long ago there were irq extensions that you could add in to an irq
controller that would allow for intercepting the set wake calls.  This went away
and was replaced by the hierarchical irq design.

The way I am currently implementing the MPM for Qualcomm, I am defining the MPM
as a IRQ controller and creating relationships between the MPM and the GPIO
controller (source of irqs) and the GIC.  As irqs are set wake and cleared the
calls go up through the hierarchy and they call each irqchips functions (if you
have it setup to do that).


> 2. Stuff things into the secure monitor
>   I guess we could read the GIC registers once we enter the secure
>   monitor and do the communication with the companion core from there by
>   identifying unmasked IRQs as wake IRQs. My concern here is that it
>   might introduce additional hardcoded mappings that are much more
>   dynamic in Linux thanks to the DT description.

This could work, but you'd have to have control of the secure monitor code.  In
Qualcomm's case, that wouldn't work or couldn't because they won't change that
code.  And you'd have to have calls into the monitor to turn on/off the lines.

> 
> Does anybody have similar problems and probably already solved it?
> Any other suggestions for approaching the problem? Any preferred
> solution?

I think we have the same problem.  Can you provide more detail on the hardware
implementation of your wake irq controller?  I presume you have some set of
registers, an irq maybe, and some other stuff?  And how does it fit into the
overall architecture from a hardware perspective?

Regards,

Andy Gross

Re: [PATCH 3/4] qcom: ipq4019: ASoC tlmm/pinctrl support

[Andy Gross]

On Fri, Jul 15, 2016 at 12:37:05PM +0530, njaig...@codeaurora.org wrote:
> From: Jaiganesh Narayanan 
> 
> This patch adds the tlmm/pinctrl support for IPQ4019 ASoC.
> 
> Signed-off-by: Jaiganesh Narayanan 
> ---
>  drivers/pinctrl/qcom/pinctrl-ipq4019.c | 116 
> +
>  1 file changed, 88 insertions(+), 28 deletions(-)
> 
> diff --git a/drivers/pinctrl/qcom/pinctrl-ipq4019.c 
> b/drivers/pinctrl/qcom/pinctrl-ipq4019.c
> index b68ae42..bc22597 100644
> --- a/drivers/pinctrl/qcom/pinctrl-ipq4019.c
> +++ b/drivers/pinctrl/qcom/pinctrl-ipq4019.c
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 2015, The Linux Foundation. All rights reserved.
> + * Copyright (c) 2015-2016, 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
> @@ -283,6 +283,18 @@ enum ipq4019_functions {
>   qca_mux_blsp_uart0,
>   qca_mux_blsp_spi1,
>   qca_mux_blsp_spi0,
> + qca_mux_i2s_rx_mclk,
> + qca_mux_i2s_rx_bclk,
> + qca_mux_i2s_rx_fsync,
> + qca_mux_i2s_rxd,
> + qca_mux_i2s_tx_mclk,
> + qca_mux_i2s_tx_bclk,
> + qca_mux_i2s_tx_fsync,
> + qca_mux_i2s_txd1,
> + qca_mux_i2s_txd2,
> + qca_mux_i2s_txd3,
> + qca_mux_i2s_spdif_out,
> + qca_mux_i2s_spdif_in,

You'll also need to add all of these to the
Documentation/devicetree/bindings/pinctrl/qcom,ipq4019-pinctrl.txt

I was also going to suggest just using qca_i2s and having a single function, but
it seems like there is at least 1 pin that supports more than one i2s mode.

Regards,
Andy

Re: [PATCH 3/4] qcom: ipq4019: ASoC tlmm/pinctrl support

[Andy Gross]

On Fri, Jul 15, 2016 at 12:37:05PM +0530, njaig...@codeaurora.org wrote:
> From: Jaiganesh Narayanan 
> 
> This patch adds the tlmm/pinctrl support for IPQ4019 ASoC.
> 
> Signed-off-by: Jaiganesh Narayanan 
> ---
>  drivers/pinctrl/qcom/pinctrl-ipq4019.c | 116 
> +
>  1 file changed, 88 insertions(+), 28 deletions(-)
> 
> diff --git a/drivers/pinctrl/qcom/pinctrl-ipq4019.c 
> b/drivers/pinctrl/qcom/pinctrl-ipq4019.c
> index b68ae42..bc22597 100644
> --- a/drivers/pinctrl/qcom/pinctrl-ipq4019.c
> +++ b/drivers/pinctrl/qcom/pinctrl-ipq4019.c
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 2015, The Linux Foundation. All rights reserved.
> + * Copyright (c) 2015-2016, 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
> @@ -283,6 +283,18 @@ enum ipq4019_functions {
>   qca_mux_blsp_uart0,
>   qca_mux_blsp_spi1,
>   qca_mux_blsp_spi0,
> + qca_mux_i2s_rx_mclk,
> + qca_mux_i2s_rx_bclk,
> + qca_mux_i2s_rx_fsync,
> + qca_mux_i2s_rxd,
> + qca_mux_i2s_tx_mclk,
> + qca_mux_i2s_tx_bclk,
> + qca_mux_i2s_tx_fsync,
> + qca_mux_i2s_txd1,
> + qca_mux_i2s_txd2,
> + qca_mux_i2s_txd3,
> + qca_mux_i2s_spdif_out,
> + qca_mux_i2s_spdif_in,

You'll also need to add all of these to the
Documentation/devicetree/bindings/pinctrl/qcom,ipq4019-pinctrl.txt

I was also going to suggest just using qca_i2s and having a single function, but
it seems like there is at least 1 pin that supports more than one i2s mode.

Regards,
Andy

Re: [PATCH 1/3] regulator: qcom_smd: Fix voltage ranges for pm8x41

[Andy Gross]

On Mon, Jul 11, 2016 at 02:50:07PM -0700, Stephen Boyd wrote:
> The voltage ranges listed here are wrong. The correct ranges can
> be seen in the "native" spmi regulator driver
> qcom_spmi-regulator.c at pldo_ranges[], ftsmps_ranges[] and
> boost_ranges[] for the pldo, ftsmps, and boost type regulators.
> Port these ranges over to the RPM SMD regulator driver so that we
> list the appropriate set of supported voltages on pldos.
> 
> Doing this allows us to specify a voltage like 3075000 for l24,
> whereas before that wasn't a supported voltage.
> 
> Cc: Andy Gross <andy.gr...@linaro.org>
> Cc: Bjorn Andersson <bjorn.anders...@linaro.org>
> Fixes: da65e367b67e ("regulator: Regulator driver for the Qualcomm RPM")
> Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
> ---



>  static const struct regulator_desc pm8941_pldo = {
>   .linear_ranges = (struct regulator_linear_range[]) {
> - REGULATOR_LINEAR_RANGE( 75,  0,  30, 25000),
> - REGULATOR_LINEAR_RANGE(150, 31, 99, 5),
> + REGULATOR_LINEAR_RANGE( 75,  0,  63, 12500),
> + REGULATOR_LINEAR_RANGE(155, 64, 126, 25000),
> + REGULATOR_LINEAR_RANGE(310, 127, 163, 5),
>   },
> - .n_linear_ranges = 2,
> - .n_voltages = 100,
> + .n_linear_ranges = 3,
> + .n_voltages = 164,
>   .ops = _smps_ldo_ops,
>  };

Still a little confused on if the 12.5mV is allowed on pmos ldo.  It seems like 
the
nmos has 1 range of 5mV steps.  The PMOS has 2 ranges, using 25mV and 50mV


Regards,

Andy

Re: [PATCH 1/3] regulator: qcom_smd: Fix voltage ranges for pm8x41

[Andy Gross]

On Mon, Jul 11, 2016 at 02:50:07PM -0700, Stephen Boyd wrote:
> The voltage ranges listed here are wrong. The correct ranges can
> be seen in the "native" spmi regulator driver
> qcom_spmi-regulator.c at pldo_ranges[], ftsmps_ranges[] and
> boost_ranges[] for the pldo, ftsmps, and boost type regulators.
> Port these ranges over to the RPM SMD regulator driver so that we
> list the appropriate set of supported voltages on pldos.
> 
> Doing this allows us to specify a voltage like 3075000 for l24,
> whereas before that wasn't a supported voltage.
> 
> Cc: Andy Gross 
> Cc: Bjorn Andersson 
> Fixes: da65e367b67e ("regulator: Regulator driver for the Qualcomm RPM")
> Signed-off-by: Stephen Boyd 
> ---



>  static const struct regulator_desc pm8941_pldo = {
>   .linear_ranges = (struct regulator_linear_range[]) {
> - REGULATOR_LINEAR_RANGE( 75,  0,  30, 25000),
> - REGULATOR_LINEAR_RANGE(150, 31, 99, 5),
> + REGULATOR_LINEAR_RANGE( 75,  0,  63, 12500),
> + REGULATOR_LINEAR_RANGE(155, 64, 126, 25000),
> + REGULATOR_LINEAR_RANGE(310, 127, 163, 5),
>   },
> - .n_linear_ranges = 2,
> - .n_voltages = 100,
> + .n_linear_ranges = 3,
> + .n_voltages = 164,
>   .ops = _smps_ldo_ops,
>  };

Still a little confused on if the 12.5mV is allowed on pmos ldo.  It seems like 
the
nmos has 1 range of 5mV steps.  The PMOS has 2 ranges, using 25mV and 50mV


Regards,

Andy

Re: [PATCH 3/3] regulator: qcom_smd: Avoid overlapping linear voltage ranges

[Andy Gross]

On Mon, Jul 11, 2016 at 02:50:09PM -0700, Stephen Boyd wrote:
> The pm8x41_hfsmps ranges overlap. The first range is from 375000
> to 1562500:
> 
>  375000 + (95 * 12500) == 1562500
> 
> and the second range starts at 155. Interestingly, the second
> range ends at the correct value when it's set to be the
> appropriate start value, 1575000:
> 
>  1575000 + ((158 - 96) * 25000) == 3125000
> 
> Cc: Andy Gross <andy.gr...@linaro.org>
> Cc: Bjorn Andersson <bjorn.anders...@linaro.org>
> Fixes: da65e367b67e ("regulator: Regulator driver for the Qualcomm RPM")
> Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
> ---

Reviewed-by: Andy Gross <andy.gr...@linaro.org>

Re: [PATCH 3/3] regulator: qcom_smd: Avoid overlapping linear voltage ranges

[Andy Gross]

On Mon, Jul 11, 2016 at 02:50:09PM -0700, Stephen Boyd wrote:
> The pm8x41_hfsmps ranges overlap. The first range is from 375000
> to 1562500:
> 
>  375000 + (95 * 12500) == 1562500
> 
> and the second range starts at 155. Interestingly, the second
> range ends at the correct value when it's set to be the
> appropriate start value, 1575000:
> 
>  1575000 + ((158 - 96) * 25000) == 3125000
> 
> Cc: Andy Gross 
> Cc: Bjorn Andersson 
> Fixes: da65e367b67e ("regulator: Regulator driver for the Qualcomm RPM")
> Signed-off-by: Stephen Boyd 
> ---

Reviewed-by: Andy Gross 

Re: [PATCH 2/3] regulator: qcom_smd: Fix voltage ranges for pma8084 ftsmps and pldo

[Andy Gross]

On Mon, Jul 11, 2016 at 02:50:08PM -0700, Stephen Boyd wrote:
> The voltage ranges listed here are wrong. The pma8084 pldo
> supports three different overlapping voltage ranges with
> differing step sizes and the pma8084 ftsmps supports two. These
> ranges can be seen in the "native" spmi regulator driver
> (qcom_spmi-regulator.c) at pldo_ranges[] and ftsmps_ranges[]
> respectively. Port these ranges over to the RPM SMD regulator
> driver so that we list the appropriate set of supported voltages
> on these types of regulators.
> 
> Cc: Andy Gross <andy.gr...@linaro.org>
> Cc: Bjorn Andersson <bjorn.anders...@linaro.org>
> Fixes: ee01d0c91ef1 ("regulator: qcom-smd: Add support for PMA8084")
> Signed-off-by: Stephen Boyd <sb...@codeaurora.org>



>  static const struct regulator_desc pma8084_pldo = {
>   .linear_ranges = (struct regulator_linear_range[]) {
> - REGULATOR_LINEAR_RANGE(75,  0,  30, 25000),
> - REGULATOR_LINEAR_RANGE(150, 31, 99, 5),
> + REGULATOR_LINEAR_RANGE( 75,  0,  63, 12500),

It was my understanding that the PMOS ldos only support 25mV and 50mV
incremements.

> + REGULATOR_LINEAR_RANGE(155, 64, 126, 25000),
> + REGULATOR_LINEAR_RANGE(310, 127, 163, 5),
>   },
> - .n_linear_ranges = 2,
> - .n_voltages = 100,
> + .n_linear_ranges = 3,
> + .n_voltages = 164,
>   .ops = _smps_ldo_ops,

Regards,

Andy

Re: [PATCH 2/3] regulator: qcom_smd: Fix voltage ranges for pma8084 ftsmps and pldo

[Andy Gross]

On Mon, Jul 11, 2016 at 02:50:08PM -0700, Stephen Boyd wrote:
> The voltage ranges listed here are wrong. The pma8084 pldo
> supports three different overlapping voltage ranges with
> differing step sizes and the pma8084 ftsmps supports two. These
> ranges can be seen in the "native" spmi regulator driver
> (qcom_spmi-regulator.c) at pldo_ranges[] and ftsmps_ranges[]
> respectively. Port these ranges over to the RPM SMD regulator
> driver so that we list the appropriate set of supported voltages
> on these types of regulators.
> 
> Cc: Andy Gross 
> Cc: Bjorn Andersson 
> Fixes: ee01d0c91ef1 ("regulator: qcom-smd: Add support for PMA8084")
> Signed-off-by: Stephen Boyd 



>  static const struct regulator_desc pma8084_pldo = {
>   .linear_ranges = (struct regulator_linear_range[]) {
> - REGULATOR_LINEAR_RANGE(75,  0,  30, 25000),
> - REGULATOR_LINEAR_RANGE(150, 31, 99, 5),
> + REGULATOR_LINEAR_RANGE( 75,  0,  63, 12500),

It was my understanding that the PMOS ldos only support 25mV and 50mV
incremements.

> + REGULATOR_LINEAR_RANGE(155, 64, 126, 25000),
> + REGULATOR_LINEAR_RANGE(310, 127, 163, 5),
>   },
> - .n_linear_ranges = 2,
> - .n_voltages = 100,
> + .n_linear_ranges = 3,
> + .n_voltages = 164,
>   .ops = _smps_ldo_ops,

Regards,

Andy

[PATCH] firmware: qcom: scm: Change initcall to subsys

[Andy Gross]

The patch changes the initcall for SCM to use subsys_initcall
instead of arch_initcall.  This corrects the order so that we don't
probe defer when trying to get clks which causes issues later when
the spm driver makes calls to qcom_set_warm_boot_addr().

The order became an issue due to the changes to use arch_initcall_sync
for of_platform_default_populate_init().

Signed-off-by: Andy Gross <andy.gr...@linaro.org>
---
 drivers/firmware/qcom_scm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
index 89c3775..e64a501 100644
--- a/drivers/firmware/qcom_scm.c
+++ b/drivers/firmware/qcom_scm.c
@@ -415,7 +415,7 @@ static int __init qcom_scm_init(void)
return platform_driver_register(_scm_driver);
 }
 
-arch_initcall(qcom_scm_init);
+subsys_initcall(qcom_scm_init);
 
 static void __exit qcom_scm_exit(void)
 {
-- 
1.9.1

[PATCH] firmware: qcom: scm: Change initcall to subsys

[Andy Gross]

The patch changes the initcall for SCM to use subsys_initcall
instead of arch_initcall.  This corrects the order so that we don't
probe defer when trying to get clks which causes issues later when
the spm driver makes calls to qcom_set_warm_boot_addr().

The order became an issue due to the changes to use arch_initcall_sync
for of_platform_default_populate_init().

Signed-off-by: Andy Gross 
---
 drivers/firmware/qcom_scm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
index 89c3775..e64a501 100644
--- a/drivers/firmware/qcom_scm.c
+++ b/drivers/firmware/qcom_scm.c
@@ -415,7 +415,7 @@ static int __init qcom_scm_init(void)
return platform_driver_register(_scm_driver);
 }
 
-arch_initcall(qcom_scm_init);
+subsys_initcall(qcom_scm_init);
 
 static void __exit qcom_scm_exit(void)
 {
-- 
1.9.1

Re: [PATCH] soc: qcom: smem: Silence probe defer error

[Andy Gross]

On Fri, Jul 01, 2016 at 02:18:59PM -0700, Stephen Boyd wrote:
> If we fail to get the hwspinlock due to probe defer, we shouldn't
> print an error message. Just be silent in this case.
> 
> Cc: Bjorn Andersson 
> Signed-off-by: Stephen Boyd 

Looks good to me.  This has needed to be fixed for a while.  Thanks!


Andy

Re: [PATCH] soc: qcom: smem: Silence probe defer error

[Andy Gross]

On Fri, Jul 01, 2016 at 02:18:59PM -0700, Stephen Boyd wrote:
> If we fail to get the hwspinlock due to probe defer, we shouldn't
> print an error message. Just be silent in this case.
> 
> Cc: Bjorn Andersson 
> Signed-off-by: Stephen Boyd 

Looks good to me.  This has needed to be fixed for a while.  Thanks!


Andy

[PATCH] firmware: qcom_scm: Add missing is_available API

[Andy Gross]

Add back function that was dropped when reworking the SCM code.

Signed-off-by: Andy Gross <andy.gr...@linaro.org>
---
 drivers/firmware/qcom_scm.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
index 84330c5..89c3775 100644
--- a/drivers/firmware/qcom_scm.c
+++ b/drivers/firmware/qcom_scm.c
@@ -308,6 +308,14 @@ static const struct reset_control_ops 
qcom_scm_pas_reset_ops = {
.deassert = qcom_scm_pas_reset_deassert,
 };
 
+/**
+ * qcom_scm_is_available() - Checks if SCM is available
+ */
+bool qcom_scm_is_available(void)
+{
+   return !!__scm;
+}
+EXPORT_SYMBOL(qcom_scm_is_available);
 
 static int qcom_scm_probe(struct platform_device *pdev)
 {
-- 
1.9.1

[PATCH] firmware: qcom_scm: Add missing is_available API

[Andy Gross]

Add back function that was dropped when reworking the SCM code.

Signed-off-by: Andy Gross 
---
 drivers/firmware/qcom_scm.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
index 84330c5..89c3775 100644
--- a/drivers/firmware/qcom_scm.c
+++ b/drivers/firmware/qcom_scm.c
@@ -308,6 +308,14 @@ static const struct reset_control_ops 
qcom_scm_pas_reset_ops = {
.deassert = qcom_scm_pas_reset_deassert,
 };
 
+/**
+ * qcom_scm_is_available() - Checks if SCM is available
+ */
+bool qcom_scm_is_available(void)
+{
+   return !!__scm;
+}
+EXPORT_SYMBOL(qcom_scm_is_available);
 
 static int qcom_scm_probe(struct platform_device *pdev)
 {
-- 
1.9.1

Re: [PATCH 15/16] arm64: dts: msm8996: add sdc2 pinctrl

[Andy Gross]

On Fri, Jun 17, 2016 at 04:14:12PM +0100, Srinivas Kandagatla wrote:
> This patch adds pinctrl required for sdhci for external sd card
> controller.
> 
> Signed-off-by: Srinivas Kandagatla 
> ---

I presume this is the right patch 15?  As it matches the subject in your cover
letter?

Andy

Re: [PATCH 15/16] arm64: dts: msm8996: add sdc2 pinctrl

[Andy Gross]

On Fri, Jun 17, 2016 at 04:14:12PM +0100, Srinivas Kandagatla wrote:
> This patch adds pinctrl required for sdhci for external sd card
> controller.
> 
> Signed-off-by: Srinivas Kandagatla 
> ---

I presume this is the right patch 15?  As it matches the subject in your cover
letter?

Andy

Re: [PATCH v2 16/16] arm64: dts: msm8996: add sdc2 support

[Andy Gross]

On Tue, Jun 21, 2016 at 06:39:53PM +0100, Srinivas Kandagatla wrote:
> This patch adds support to sdc2 sdhci controller, which is used on some
> of the boards.
> 
> Signed-off-by: Srinivas Kandagatla 
> ---
> Hi Andy, 
> 
> Am resending just this one patch, as It does not make sense
> to resend entire series for such a small change.

Got it.  Thanks for the clarification.


Andy

Re: [PATCH v2 16/16] arm64: dts: msm8996: add sdc2 support

[Andy Gross]

On Tue, Jun 21, 2016 at 06:39:53PM +0100, Srinivas Kandagatla wrote:
> This patch adds support to sdc2 sdhci controller, which is used on some
> of the boards.
> 
> Signed-off-by: Srinivas Kandagatla 
> ---
> Hi Andy, 
> 
> Am resending just this one patch, as It does not make sense
> to resend entire series for such a small change.

Got it.  Thanks for the clarification.


Andy

Re: [PATCH] arm64: defconfig: Enable qcom msm8996 clk drivers

[Andy Gross]

On Wed, Jun 15, 2016 at 06:07:51PM -0700, Stephen Boyd wrote:
> Enable the clk drivers on msm8996. This allows us to boot and
> test most device drivers on this SoC.
> 
> Signed-off-by: Stephen Boyd 


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

Thanks,

Andy

Re: [PATCH] arm64: defconfig: Enable qcom msm8996 clk drivers

[Andy Gross]

On Wed, Jun 15, 2016 at 06:07:51PM -0700, Stephen Boyd wrote:
> Enable the clk drivers on msm8996. This allows us to boot and
> test most device drivers on this SoC.
> 
> Signed-off-by: Stephen Boyd 


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

Thanks,

Andy

[PATCH] arm: dts: qcom: Update smem state cells usage

[Andy Gross]

This patch updates the qcom,state-cells to qcom,smem-state-cells to
match recent changes to the binding.

Signed-off-by: Andy Gross <andy.gr...@linaro.org>
---
 arch/arm/boot/dts/qcom-apq8064.dtsi | 2 +-
 arch/arm/boot/dts/qcom-msm8974.dtsi | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi 
b/arch/arm/boot/dts/qcom-apq8064.dtsi
index df96ccd..e4437e4 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -177,7 +177,7 @@
 
apps_smsm: apps@0 {
reg = <0>;
-   #qcom,state-cells = <1>;
+   #qcom,smem-state-cells = <1>;
};
 
modem_smsm: modem@1 {
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi 
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index 6f16426..3a79d3c 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -182,7 +182,7 @@
 
modem_smp2p_out: master-kernel {
qcom,entry-name = "master-kernel";
-   #qcom,state-cells = <1>;
+   #qcom,smem-state-cells = <1>;
};
 
modem_smp2p_in: slave-kernel {
@@ -208,7 +208,7 @@
wcnss_smp2p_out: master-kernel {
qcom,entry-name = "master-kernel";
 
-   #qcom,state-cells = <1>;
+   #qcom,smem-state-cells = <1>;
};
 
wcnss_smp2p_in: slave-kernel {
@@ -232,7 +232,7 @@
apps_smsm: apps@0 {
reg = <0>;
 
-   #qcom,state-cells = <1>;
+   #qcom,smem-state-cells = <1>;
};
 
modem_smsm: modem@1 {
-- 
1.9.1

[PATCH] arm: dts: qcom: Update smem state cells usage

[Andy Gross]

This patch updates the qcom,state-cells to qcom,smem-state-cells to
match recent changes to the binding.

Signed-off-by: Andy Gross 
---
 arch/arm/boot/dts/qcom-apq8064.dtsi | 2 +-
 arch/arm/boot/dts/qcom-msm8974.dtsi | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi 
b/arch/arm/boot/dts/qcom-apq8064.dtsi
index df96ccd..e4437e4 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -177,7 +177,7 @@
 
apps_smsm: apps@0 {
reg = <0>;
-   #qcom,state-cells = <1>;
+   #qcom,smem-state-cells = <1>;
};
 
modem_smsm: modem@1 {
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi 
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index 6f16426..3a79d3c 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -182,7 +182,7 @@
 
modem_smp2p_out: master-kernel {
qcom,entry-name = "master-kernel";
-   #qcom,state-cells = <1>;
+   #qcom,smem-state-cells = <1>;
};
 
modem_smp2p_in: slave-kernel {
@@ -208,7 +208,7 @@
wcnss_smp2p_out: master-kernel {
qcom,entry-name = "master-kernel";
 
-   #qcom,state-cells = <1>;
+   #qcom,smem-state-cells = <1>;
};
 
wcnss_smp2p_in: slave-kernel {
@@ -232,7 +232,7 @@
apps_smsm: apps@0 {
reg = <0>;
 
-   #qcom,state-cells = <1>;
+   #qcom,smem-state-cells = <1>;
};
 
modem_smsm: modem@1 {
-- 
1.9.1