Re: [PATCH 2/4] usb: dwc3: qcom: Configure TCSR phy mux register

2015-11-20 Thread Felipe Balbi

Hi,

Andy Gross  writes:
> This patch adds automatic configuration of the TCSR phy mux register based on
> the syscon-tcsr devicetree entry.  This configuration is optional, as some
> platforms may not require the mux selection.
>
> Signed-off-by: Andy Gross 

just when I find a way to make a generic dwc3-of-simple.c glue layer :-p

I can, certainly drop my patches but I need more details on the syscon
usage below.

> ---
>  drivers/usb/dwc3/dwc3-qcom.c | 25 +
>  1 file changed, 25 insertions(+)
>
> diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
> index 0880260..fcf264c 100644
> --- a/drivers/usb/dwc3/dwc3-qcom.c
> +++ b/drivers/usb/dwc3/dwc3-qcom.c
> @@ -17,6 +17,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  
>  struct dwc3_qcom {
>   struct device   *dev;
> @@ -30,6 +32,9 @@ static int dwc3_qcom_probe(struct platform_device *pdev)
>  {
>   struct device_node *node = pdev->dev.of_node;
>   struct dwc3_qcom *qdwc;
> + struct regmap *regmap;
> + u32 mux_offset;
> + u32 mux_bit;
>   int ret;
>  
>   qdwc = devm_kzalloc(>dev, sizeof(*qdwc), GFP_KERNEL);
> @@ -58,6 +63,26 @@ static int dwc3_qcom_probe(struct platform_device *pdev)
>   qdwc->sleep_clk = NULL;
>   }
>  
> + /* look for tcsr and if present, provision it */
> + regmap = syscon_regmap_lookup_by_phandle(node, "syscon-tcsr");
> + if (!IS_ERR(regmap)) {
> + if (of_property_read_u32_index(node, "syscon-tcsr", 1,
> +_offset)) {
> + dev_err(qdwc->dev, "missing USB TCSR mux offset\n");
> + return -EINVAL;
> + }
> + if (of_property_read_u32_index(node, "syscon-tcsr", 2,
> +_bit)) {
> + dev_err(qdwc->dev, "missing USB TCSR mux bit\n");
> + return -EINVAL;
> + }
> +
> + regmap_update_bits(regmap, mux_offset, BIT(mux_bit),
> +BIT(mux_bit));

what is tcsr and what does it ? It also seems to be optional, why's that ?

-- 
balbi


signature.asc
Description: PGP signature


Re: [PATCH v2] soc: qcom: enable smsm/smp2p modular build

2015-11-20 Thread Andy Gross
On Fri, Nov 20, 2015 at 11:32:21AM +0100, Arnd Bergmann wrote:
> The newly added smp2p and smsm drivers cannot be loadable modules
> but depend on smem, which can be, and that causes a link error:
> 
> drivers/built-in.o: In function `qcom_smp2p_intr':
> :(.text+0xa6e68): undefined reference to `qcom_smem_get'
> drivers/built-in.o: In function `qcom_smp2p_probe':
> :(.text+0xa7320): undefined reference to `qcom_smem_alloc'
> :(.text+0xa736c): undefined reference to `qcom_smem_get'
> drivers/built-in.o: In function `qcom_smsm_probe':
> :(.text+0xa7b34): undefined reference to `qcom_smem_get'
> 
> This marks all the drivers as 'tristate' to make the Kconfig
> dependency resolution work properly.

Nice catch.  I'll add this on top of those.

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

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


Re: [PATCH 4/4] Documentation: usb: dwc3: qcom: Add TCSR mux usage

2015-11-20 Thread Felipe Balbi

Hi,

Andy Gross  writes:
> This patch adds documentation for the optional syscon-tcsr property in the
> Qualcomm DWC3 node.  The syscon-tcsr specifies the register and bit used to
> configure the TCSR USB phy mux register.
>
> Signed-off-by: Andy Gross 
> ---
>  Documentation/devicetree/bindings/usb/qcom,dwc3.txt | 11 +++
>  1 file changed, 11 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/usb/qcom,dwc3.txt 
> b/Documentation/devicetree/bindings/usb/qcom,dwc3.txt
> index ca164e7..dfa222d 100644
> --- a/Documentation/devicetree/bindings/usb/qcom,dwc3.txt
> +++ b/Documentation/devicetree/bindings/usb/qcom,dwc3.txt
> @@ -8,6 +8,10 @@ Required properties:
>"core" Master/Core clock, have to be >= 125 MHz for SS
>   operation and >= 60MHz for HS operation
>  
> +Optional properties:
> +- syscon-tcsrSpecifies TCSR handle, register offset, and bit 
> position for
> + configuring the phy mux setting.

oh, it's a PHY mux ? I don't think it should be part of any dwc3-* glue
layer then. By the time we reach dwc3, the mux should be properly
configured.

Kishon, any ideas ?

-- 
balbi


signature.asc
Description: PGP signature


Re: [PATCH 4/4] Documentation: usb: dwc3: qcom: Add TCSR mux usage

2015-11-20 Thread Rob Herring
On Fri, Nov 20, 2015 at 02:35:09AM -0600, Andy Gross wrote:
> This patch adds documentation for the optional syscon-tcsr property in the
> Qualcomm DWC3 node.  The syscon-tcsr specifies the register and bit used to
> configure the TCSR USB phy mux register.
> 
> Signed-off-by: Andy Gross 

Acked-by: Rob Herring 

> ---
>  Documentation/devicetree/bindings/usb/qcom,dwc3.txt | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/usb/qcom,dwc3.txt 
> b/Documentation/devicetree/bindings/usb/qcom,dwc3.txt
> index ca164e7..dfa222d 100644
> --- a/Documentation/devicetree/bindings/usb/qcom,dwc3.txt
> +++ b/Documentation/devicetree/bindings/usb/qcom,dwc3.txt
> @@ -8,6 +8,10 @@ Required properties:
>"core" Master/Core clock, have to be >= 125 MHz for SS
>   operation and >= 60MHz for HS operation
>  
> +Optional properties:
> +- syscon-tcsrSpecifies TCSR handle, register offset, and bit 
> position for
> + configuring the phy mux setting.
> +
>  Optional clocks:
>"iface"System bus AXI clock.  Not present on all platforms
>"sleep"Sleep clock, used when USB3 core goes into low
> @@ -22,6 +26,11 @@ Documentation/devicetree/bindings/phy/qcom,dwc3-usb-phy.txt
>  
>  Example device nodes:
>  
> + tcsr: syscon@1a40 {
> + compatible = "qcom,tcsr-ipq8064", "syscon";
> + reg = <0x1a40 0x100>;
> + };
> +
>   hs_phy: phy@100f8800 {
>   compatible = "qcom,dwc3-hs-usb-phy";
>   reg = <0x100f8800 0x30>;
> @@ -51,6 +60,8 @@ Example device nodes:
>  
>   ranges;
>  
> + syscon-tcsr = < 0xb0 0x1>;
> +
>   status = "ok";
>  
>   dwc3@1000 {
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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] drivers/built-in.o: In function `qcom_smp2p_intr':

2015-11-20 Thread Arnd Bergmann
On Friday 20 November 2015 10:43:00 Arnd Bergmann wrote:
> The newly added smp2p and smsm drivers cannot be loadable modules
> but depend on smem, which can be, and that causes a link error:
> 

Sorry, $SUBJECT is wrong, I'll resend.

Arnd

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


[PATCH] drivers/built-in.o: In function `qcom_smp2p_intr':

2015-11-20 Thread Arnd Bergmann
The newly added smp2p and smsm drivers cannot be loadable modules
but depend on smem, which can be, and that causes a link error:

:(.text+0xa6e68): undefined reference to `qcom_smem_get'
drivers/built-in.o: In function `qcom_smp2p_probe':
:(.text+0xa7320): undefined reference to `qcom_smem_alloc'
:(.text+0xa736c): undefined reference to `qcom_smem_get'
drivers/built-in.o: In function `qcom_smsm_probe':
:(.text+0xa7b34): undefined reference to `qcom_smem_get'

This marks all the drivers as 'tristate' to make the Kconfig
dependency resolution work properly.

Signed-off-by: Arnd Bergmann 
Fixes: dbb04bd7122f ("soc: qcom: smp2p: Qualcomm Shared Memory Point to Point")
Fixes: d7387fc6add4 ("soc: qcom: smsm: Add driver for Qualcomm SMSM")
---
This showed up on arm allmodconfig with linux-next today, please apply or fold
into the original patches.

diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index b57be7ab50b6..57b7145358e7 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -54,7 +54,7 @@ config QCOM_SMEM_STATE
bool
 
 config QCOM_SMP2P
-   bool "Qualcomm Shared Memory Point to Point support"
+   tristate "Qualcomm Shared Memory Point to Point support"
depends on QCOM_SMEM
select QCOM_SMEM_STATE
help
@@ -62,7 +62,7 @@ config QCOM_SMP2P
  protocol.
 
 config QCOM_SMSM
-   bool "Qualcomm Shared Memory State Machine"
+   tristate "Qualcomm Shared Memory State Machine"
depends on QCOM_SMEM
select QCOM_SMEM_STATE
help

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


[PATCH v2] soc: qcom: enable smsm/smp2p modular build

2015-11-20 Thread Arnd Bergmann
The newly added smp2p and smsm drivers cannot be loadable modules
but depend on smem, which can be, and that causes a link error:

drivers/built-in.o: In function `qcom_smp2p_intr':
:(.text+0xa6e68): undefined reference to `qcom_smem_get'
drivers/built-in.o: In function `qcom_smp2p_probe':
:(.text+0xa7320): undefined reference to `qcom_smem_alloc'
:(.text+0xa736c): undefined reference to `qcom_smem_get'
drivers/built-in.o: In function `qcom_smsm_probe':
:(.text+0xa7b34): undefined reference to `qcom_smem_get'

This marks all the drivers as 'tristate' to make the Kconfig
dependency resolution work properly.

Signed-off-by: Arnd Bergmann 
Fixes: dbb04bd7122f ("soc: qcom: smp2p: Qualcomm Shared Memory Point to Point")
Fixes: d7387fc6add4 ("soc: qcom: smsm: Add driver for Qualcomm SMSM")
---
v2: fixed subject line

diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index b57be7ab50b6..57b7145358e7 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -54,7 +54,7 @@ config QCOM_SMEM_STATE
bool
 
 config QCOM_SMP2P
-   bool "Qualcomm Shared Memory Point to Point support"
+   tristate "Qualcomm Shared Memory Point to Point support"
depends on QCOM_SMEM
select QCOM_SMEM_STATE
help
@@ -62,7 +62,7 @@ config QCOM_SMP2P
  protocol.
 
 config QCOM_SMSM
-   bool "Qualcomm Shared Memory State Machine"
+   tristate "Qualcomm Shared Memory State Machine"
depends on QCOM_SMEM
select QCOM_SMEM_STATE
help

--
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 4/4] Documentation: usb: dwc3: qcom: Add TCSR mux usage

2015-11-20 Thread Andy Gross
On Fri, Nov 20, 2015 at 09:08:46AM -0600, Felipe Balbi wrote:
> 
> Hi,
> 
> Andy Gross  writes:
> > This patch adds documentation for the optional syscon-tcsr property in the
> > Qualcomm DWC3 node.  The syscon-tcsr specifies the register and bit used to
> > configure the TCSR USB phy mux register.
> >
> > Signed-off-by: Andy Gross 
> > ---
> >  Documentation/devicetree/bindings/usb/qcom,dwc3.txt | 11 +++
> >  1 file changed, 11 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/usb/qcom,dwc3.txt 
> > b/Documentation/devicetree/bindings/usb/qcom,dwc3.txt
> > index ca164e7..dfa222d 100644
> > --- a/Documentation/devicetree/bindings/usb/qcom,dwc3.txt
> > +++ b/Documentation/devicetree/bindings/usb/qcom,dwc3.txt
> > @@ -8,6 +8,10 @@ Required properties:
> >"core"   Master/Core clock, have to be >= 125 MHz for SS
> > operation and >= 60MHz for HS operation
> >  
> > +Optional properties:
> > +- syscon-tcsr  Specifies TCSR handle, register offset, and bit 
> > position for
> > +   configuring the phy mux setting.
> 
> oh, it's a PHY mux ? I don't think it should be part of any dwc3-* glue
> layer then. By the time we reach dwc3, the mux should be properly
> configured.
> 
> Kishon, any ideas ?
> 
> -- 
> balbi

The only issue with putting it at the phy layer is that i'd have redundant
syscon entries for each pair of phys, unless i group them somehow in dt.  The
only other issue I can think of is that in the downstream kernels, they do this
before messing with the configuration of the dwc3.  So long as the phys do their
thing before the dwc3 (phys latched before config), we're ok.



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

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


Re: [PATCH RFC 15/27] PM / Domains: Add next_wakeup to device's timing data

2015-11-20 Thread Lina Iyer

On Thu, Nov 19 2015 at 15:19 -0700, Kevin Hilman wrote:

Lina Iyer  writes:


Allow devices that know when their next wakeup event is, to record save
it as part of timing data. A genpd governor may use this data to
determine if suspending the domain is going to affect the QoS of its
devices.

Signed-off-by: Lina Iyer 
---
 include/linux/pm_domain.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index f1329ea..9ac089d 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 

 /* Defines used for the flags field in the struct generic_pm_domain */
 #define GENPD_FLAG_PM_CLK  (1U << 0) /* PM domain uses PM clk */
@@ -104,6 +105,7 @@ struct gpd_timing_data {
s64 effective_constraint_ns;
bool constraint_changed;
bool cached_stop_ok;
+   ktime_t next_wakeup;
 };


The addition of a new field should be combined with the patch that uses
it (e.g. PATCH 16/27)


Okay. Will do.


Kevin

--
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 2/4] usb: dwc3: qcom: Configure TCSR phy mux register

2015-11-20 Thread Andy Gross
On Fri, Nov 20, 2015 at 09:06:33AM -0600, Felipe Balbi wrote:
> 
> Hi,
> 
> Andy Gross  writes:
> > This patch adds automatic configuration of the TCSR phy mux register based 
> > on
> > the syscon-tcsr devicetree entry.  This configuration is optional, as some
> > platforms may not require the mux selection.
> >
> > Signed-off-by: Andy Gross 
> 
> just when I find a way to make a generic dwc3-of-simple.c glue layer :-p
> 
> I can, certainly drop my patches but I need more details on the syscon
> usage below.
> 
> > ---
> >  drivers/usb/dwc3/dwc3-qcom.c | 25 +
> >  1 file changed, 25 insertions(+)
> >
> > diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
> > index 0880260..fcf264c 100644
> > --- a/drivers/usb/dwc3/dwc3-qcom.c
> > +++ b/drivers/usb/dwc3/dwc3-qcom.c
> > @@ -17,6 +17,8 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> > +#include 
> >  
> >  struct dwc3_qcom {
> > struct device   *dev;
> > @@ -30,6 +32,9 @@ static int dwc3_qcom_probe(struct platform_device *pdev)
> >  {
> > struct device_node *node = pdev->dev.of_node;
> > struct dwc3_qcom *qdwc;
> > +   struct regmap *regmap;
> > +   u32 mux_offset;
> > +   u32 mux_bit;
> > int ret;
> >  
> > qdwc = devm_kzalloc(>dev, sizeof(*qdwc), GFP_KERNEL);
> > @@ -58,6 +63,26 @@ static int dwc3_qcom_probe(struct platform_device *pdev)
> > qdwc->sleep_clk = NULL;
> > }
> >  
> > +   /* look for tcsr and if present, provision it */
> > +   regmap = syscon_regmap_lookup_by_phandle(node, "syscon-tcsr");
> > +   if (!IS_ERR(regmap)) {
> > +   if (of_property_read_u32_index(node, "syscon-tcsr", 1,
> > +  _offset)) {
> > +   dev_err(qdwc->dev, "missing USB TCSR mux offset\n");
> > +   return -EINVAL;
> > +   }
> > +   if (of_property_read_u32_index(node, "syscon-tcsr", 2,
> > +  _bit)) {
> > +   dev_err(qdwc->dev, "missing USB TCSR mux bit\n");
> > +   return -EINVAL;
> > +   }
> > +
> > +   regmap_update_bits(regmap, mux_offset, BIT(mux_bit),
> > +  BIT(mux_bit));
> 
> what is tcsr and what does it ? It also seems to be optional, why's that ?
> 
> -- 
> balbi

The syscon is to set the mux selection for the phys.  Our hardware has a
steering mux between hsic and dwc3 and setting this to 1 steers the phys to the
right controller.

It is optional because not all platforms appear to have this stupidity.


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

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


Re: [PATCH RFC 18/27] drivers: cpu-pd: Add PM Domain governor for CPUs

2015-11-20 Thread Lorenzo Pieralisi
On Thu, Nov 19, 2015 at 03:52:13PM -0800, Kevin Hilman wrote:
> Lorenzo Pieralisi  writes:
> 
> > On Tue, Nov 17, 2015 at 03:37:42PM -0700, Lina Iyer wrote:
> >> A PM domain comprising of CPUs may be powered off when all the CPUs in
> >> the domain are powered down. Powering down a CPU domain is generally a
> >> expensive operation and therefore the power performance trade offs
> >> should be considered. The time between the last CPU powering down and
> >> the first CPU powering up in a domain, is the time available for the
> >> domain to sleep. Ideally, the sleep time of the domain should fulfill
> >> the residency requirement of the domains' idle state.
> >> 
> >> To do this effectively, read the time before the wakeup of the cluster's
> >> CPUs and ensure that the domain's idle state sleep time guarantees the
> >> QoS requirements of each of the CPU, the PM QoS CPU_DMA_LATENCY and the
> >> state's residency.
> >
> > To me this information should be part of the CPUidle governor (it is
> > already there), we should not split the decision into multiple layers.
> >
> > The problem you are facing is that the CPUidle governor(s) do not take
> > cross cpus relationship into account, I do not think that adding another
> > decision layer in the power domain subsystem helps, you are doing that
> > just because adding it to the existing CPUidle governor(s) is invasive.
> >
> > Why can't we use the power domain work you put together to eg disable
> > idle states that share multiple cpus and make them "visible" only
> > when the power domain that encompass them is actually going down ?
> >
> > You could use the power domains information to detect states that
> > are shared between cpus.
> >
> > It is just an idea, what I am saying is that having another governor in
> > the power domain subsytem does not make much sense, you split the
> > decision in two layers while there is actually one, the existing
> > CPUidle governor and that's where the decision should be taken.
> 
> Hmm, considering "normal" devices in "normal" power domains, and
> following the same logic, the equivalent would be to say that the
> decision to gate the power domain belongs to the individual drivers
> in the domain instead of in the power domain layer.  I disagree.
> 
> IMO, there are different decision layers because there are different
> hardware layers.  Devices (including CPUs) are reponsible for handling
> device-local idle states, based on device-local conditions (e.g. local
> wakeups, timers, etc.)  and domains are responsible for handling
> decisions based on conditions of the whole domain.

After going through the series for the second time (it is quite complex and
should probably be split) I understood your point of view and I agree with
it, I will review it more in-depth to understand the details.

One thing that is not clear to me is how we would end up handling
cluster states in platform coordinated mode with this series (and
I am actually referring to the data we would add in the idle-states,
such as min-residency). I admit that data for cluster states at present
is not extremely well defined, because we have to add latencies for
the cluster state even if the state itself may be just a cpu one (by
definition a cluster state is entered only if all cpus in the cluster
enter it, otherwise FW or power controller demote them automatically).

I would like to take this series as an opportunity to improve the
current situation in a clean way (and without changing the bindings,
only augmenting them).

On a side note, I think we should give up the concept of cluster
entirely, to me they are just a group of cpus, I do not see any reason
why we should group cpus this way and I do not like the dependencies
of this series on the cpu-map either, I do not see the reason but I
will go through code again to make sure I am not missing anything.

To be clear, to me the cpumask should be created with all cpus belonging
in a given power domain, no cluster dependency (and yes the CPU PM
notifiers are not appropriate at present - eg on
cpu_cluster_pm_{enter/exit} we save and restore the GIC distributor state
even on multi-cluster systems, that's useless and has no connection with
the real power domain topology at all, so the concept of cluster as it
stands is shaky to say the least).

Thanks,
Lorenzo
--
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 v3 1/6] pinctrl: qcom: ipq4019: Add IPQ4019 pinctrl support

2015-11-20 Thread Rob Herring
On Thu, Nov 19, 2015 at 05:19:28PM -0600, Matthew McClintock wrote:
> From: Varadarajan Narayanan 
> 
> Add pinctrl driver support for IPQ4019 platform
> 
> Signed-off-by: Sricharan R 
> Signed-off-by: Mathieu Olivari 
> Signed-off-by: Varadarajan Narayanan 
> Signed-off-by: Matthew McClintock 
> ---
> 
> v3
> - update example with actual values from dts
> - add missing pins 71-99
> - drop many functions and stick to basic functionality
> 
> v2
> - add a note in the device tree binding about the TLMM block
> 
>  .../bindings/pinctrl/qcom,ipq4019-pinctrl.txt  |  74 

Acked-by: Rob Herring 

>  drivers/pinctrl/qcom/Kconfig   |   8 +
>  drivers/pinctrl/qcom/Makefile  |   1 +
>  drivers/pinctrl/qcom/pinctrl-ipq4019.c | 454 
> +
>  4 files changed, 537 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/pinctrl/qcom,ipq4019-pinctrl.txt
>  create mode 100644 drivers/pinctrl/qcom/pinctrl-ipq4019.c
> 
> diff --git 
> a/Documentation/devicetree/bindings/pinctrl/qcom,ipq4019-pinctrl.txt 
> b/Documentation/devicetree/bindings/pinctrl/qcom,ipq4019-pinctrl.txt
> new file mode 100644
> index 000..cfb8500
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pinctrl/qcom,ipq4019-pinctrl.txt
> @@ -0,0 +1,74 @@
> +Qualcomm Atheros IPQ4019 TLMM block
> +
> +This is the Top Level Mode Multiplexor block found on the Qualcomm IPQ8019
> +platform, it provides pinctrl, pinmux, pinconf, and gpiolib facilities.
> +
> +Required properties:
> +- compatible: "qcom,ipq4019-pinctrl"
> +- reg: Should be the base address and length of the TLMM block.
> +- interrupts: Should be the parent IRQ of the TLMM block.
> +- interrupt-controller: Marks the device node as an interrupt controller.
> +- #interrupt-cells: Should be two.
> +- gpio-controller: Marks the device node as a GPIO controller.
> +- #gpio-cells : Should be two.
> +The first cell is the gpio pin number and the
> +second cell is used for optional parameters.
> +
> +Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt 
> for
> +a general description of GPIO and interrupt bindings.
> +
> +Please refer to pinctrl-bindings.txt in this directory for details of the
> +common pinctrl bindings used by client devices, including the meaning of the
> +phrase "pin configuration node".
> +
> +The pin configuration nodes act as a container for an abitrary number of
> +subnodes. Each of these subnodes represents some desired configuration for a
> +pin, a group, or a list of pins or groups. This configuration can include the
> +mux function to select on those pin(s)/group(s), and various pin 
> configuration
> +parameters, such as pull-up, drive strength, etc.
> +
> +The name of each subnode is not important; all subnodes should be enumerated
> +and processed purely based on their content.
> +
> +Each subnode only affects those parameters that are explicitly listed. In
> +other words, a subnode that lists a mux function but no pin configuration
> +parameters implies no information about any pin configuration parameters.
> +Similarly, a pin subnode that describes a pullup parameter implies no
> +information about e.g. the mux function.
> +
> +
> +The following generic properties as defined in pinctrl-bindings.txt are valid
> +to specify in a pin configuration subnode:
> + pins, function, bias-disable, bias-pull-down, bias-pull,up, drive-strength.
> +
> +Non-empty subnodes must specify the 'pins' property.
> +Note that not all properties are valid for all pins.
> +
> +
> +Valid values for qcom,pins are:
> +  gpio0-gpio99
> +Supports mux, bias and drive-strength
> +
> +Valid values for qcom,function are:
> +gpio, blsp_uart1, blsp_i2c0, blsp_i2c1, blsp_uart0, blsp_spi1, blsp_spi0
> +
> +Example:
> +
> + tlmm: pinctrl@100 {
> + compatible = "qcom,ipq4019-pinctrl";
> + reg = <0x100 0x30>;
> +
> + gpio-controller;
> + #gpio-cells = <2>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + interrupts = <0 208 0>;
> +
> + serial_pins: serial_pinmux {
> + mux {
> + pins = "gpio60", "gpio61";
> + function = "blsp_uart0";
> + bias-disable;
> + };
> + };
> + };
> diff --git a/drivers/pinctrl/qcom/Kconfig b/drivers/pinctrl/qcom/Kconfig
> index 383263a..6b898ef 100644
> --- a/drivers/pinctrl/qcom/Kconfig
> +++ b/drivers/pinctrl/qcom/Kconfig
> @@ -23,6 +23,14 @@ config PINCTRL_APQ8084
> This is the pinctrl, pinmux, pinconf and gpiolib driver for the
> Qualcomm TLMM block found in the Qualcomm APQ8084 platform.
>  
> +config PINCTRL_IPQ4019
> 

Re: [PATCH RFC 18/27] drivers: cpu-pd: Add PM Domain governor for CPUs

2015-11-20 Thread Lina Iyer

On Fri, Nov 20 2015 at 09:20 -0700, Lorenzo Pieralisi wrote:

On Thu, Nov 19, 2015 at 03:52:13PM -0800, Kevin Hilman wrote:

Lorenzo Pieralisi  writes:

> On Tue, Nov 17, 2015 at 03:37:42PM -0700, Lina Iyer wrote:
>> A PM domain comprising of CPUs may be powered off when all the CPUs in
>> the domain are powered down. Powering down a CPU domain is generally a
>> expensive operation and therefore the power performance trade offs
>> should be considered. The time between the last CPU powering down and
>> the first CPU powering up in a domain, is the time available for the
>> domain to sleep. Ideally, the sleep time of the domain should fulfill
>> the residency requirement of the domains' idle state.
>>
>> To do this effectively, read the time before the wakeup of the cluster's
>> CPUs and ensure that the domain's idle state sleep time guarantees the
>> QoS requirements of each of the CPU, the PM QoS CPU_DMA_LATENCY and the
>> state's residency.
>
> To me this information should be part of the CPUidle governor (it is
> already there), we should not split the decision into multiple layers.
>
> The problem you are facing is that the CPUidle governor(s) do not take
> cross cpus relationship into account, I do not think that adding another
> decision layer in the power domain subsystem helps, you are doing that
> just because adding it to the existing CPUidle governor(s) is invasive.
>
> Why can't we use the power domain work you put together to eg disable
> idle states that share multiple cpus and make them "visible" only
> when the power domain that encompass them is actually going down ?
>
> You could use the power domains information to detect states that
> are shared between cpus.
>
> It is just an idea, what I am saying is that having another governor in
> the power domain subsytem does not make much sense, you split the
> decision in two layers while there is actually one, the existing
> CPUidle governor and that's where the decision should be taken.

Hmm, considering "normal" devices in "normal" power domains, and
following the same logic, the equivalent would be to say that the
decision to gate the power domain belongs to the individual drivers
in the domain instead of in the power domain layer.  I disagree.

IMO, there are different decision layers because there are different
hardware layers.  Devices (including CPUs) are reponsible for handling
device-local idle states, based on device-local conditions (e.g. local
wakeups, timers, etc.)  and domains are responsible for handling
decisions based on conditions of the whole domain.


After going through the series for the second time (it is quite complex and
should probably be split) I understood your point of view and I agree with
it, I will review it more in-depth to understand the details.


I have included patches from Axel and Marc, so as to get a complete
picture. My core changes are in genpd, cpu-pd and psci.c


One thing that is not clear to me is how we would end up handling
cluster states in platform coordinated mode with this series (and
I am actually referring to the data we would add in the idle-states,
such as min-residency).

From what I see, the platform coordinated mode, doesnt need any of this.

We are fine as it is today. CPUs vote for the cluster state they can
enter and the f/w determines based on these votes. It makes sense and
probably easier to flatten out the cluster states and attach them to
cpuidle for that.

I couldnt find a symmetry with OS initated. May be it deserves more
discussion and brain storming.


I admit that data for cluster states at present
is not extremely well defined, because we have to add latencies for
the cluster state even if the state itself may be just a cpu one (by
definition a cluster state is entered only if all cpus in the cluster
enter it, otherwise FW or power controller demote them automatically).




I would like to take this series as an opportunity to improve the
current situation in a clean way (and without changing the bindings,
only augmenting them).

On a side note, I think we should give up the concept of cluster
entirely, to me they are just a group of cpus, I do not see any reason
why we should group cpus this way and I do not like the dependencies
of this series on the cpu-map either, I do not see the reason but I
will go through code again to make sure I am not missing anything.


SoC's could have different organization of CPUs (clubbed as clusters)
and power domains the power thesee clusters. This information has to
come from the DT. Since there are no actual devices in linux for domain
management (with PSCI), I have added them to cpu-map, which already
builds up the cluster hierarchy. The only addition I had to make wa
allow these cluster nodes to be tell the kernel that they are domain
providers.


To be clear, to me the cpumask should be created with all cpus belonging
in a given power domain, no cluster dependency (and yes the CPU PM
notifiers are not 

Re: [PATCH RFC 16/27] ARM: cpuidle: Record the next wakeup event of the CPU

2015-11-20 Thread Lina Iyer

On Thu, Nov 19 2015 at 16:35 -0700, Kevin Hilman wrote:

Lina Iyer  writes:


Reading the next wakeup of the CPU can only be realiably done only from
that CPU. In the idle enter path record the next wake up of the CPU. The
information is useful to determine the sleep time left for the CPU.

Signed-off-by: Lina Iyer 
---
 drivers/cpuidle/cpuidle-arm.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/cpuidle/cpuidle-arm.c b/drivers/cpuidle/cpuidle-arm.c
index 8e72a23..b3133ef 100644
--- a/drivers/cpuidle/cpuidle-arm.c
+++ b/drivers/cpuidle/cpuidle-arm.c
@@ -18,9 +18,11 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
+#include 

 #include 

@@ -49,7 +51,9 @@ static int arm_enter_idle_state(struct cpuidle_device *dev,
ret = cpu_pm_enter();
if (!ret) {
struct device *cpu_dev = get_cpu_device(dev->cpu);
+   struct generic_pm_domain_data *gpd = dev_gpd_data(cpu_dev);

+   gpd->td.next_wakeup = tick_nohz_get_next_wakeup();
RCU_NONIDLE(pm_runtime_put_sync_suspend(cpu_dev));


Maybe set this back to zero atomicaly, after wakeup?

Checking for non-zero that might be another way for the domain goveror that 
there
haven't been any CPU wakeups since the CPUs have gone idle.


I set it to 0 below.

The reference counting by the GET_PUT tells the domain if a device is
suspended. I see that as a redudant information. May be I am not getting
your point.

-- Lina

Kevin

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


Re: [PATCH RFC 18/27] drivers: cpu-pd: Add PM Domain governor for CPUs

2015-11-20 Thread Lina Iyer

On Thu, Nov 19 2015 at 01:50 -0700, Marc Titinger wrote:

On 18/11/2015 19:42, Lorenzo Pieralisi wrote:

On Tue, Nov 17, 2015 at 03:37:42PM -0700, Lina Iyer wrote:

A PM domain comprising of CPUs may be powered off when all the CPUs in
the domain are powered down. Powering down a CPU domain is generally a
expensive operation and therefore the power performance trade offs
should be considered. The time between the last CPU powering down and
the first CPU powering up in a domain, is the time available for the
domain to sleep. Ideally, the sleep time of the domain should fulfill
the residency requirement of the domains' idle state.

To do this effectively, read the time before the wakeup of the cluster's
CPUs and ensure that the domain's idle state sleep time guarantees the
QoS requirements of each of the CPU, the PM QoS CPU_DMA_LATENCY and the
state's residency.


To me this information should be part of the CPUidle governor (it is
already there), we should not split the decision into multiple layers.

The problem you are facing is that the CPUidle governor(s) do not take
cross cpus relationship into account, I do not think that adding another
decision layer in the power domain subsystem helps, you are doing that
just because adding it to the existing CPUidle governor(s) is invasive.

Why can't we use the power domain work you put together to eg disable
idle states that share multiple cpus and make them "visible" only
when the power domain that encompass them is actually going down ?

You could use the power domains information to detect states that
are shared between cpus.

It is just an idea, what I am saying is that having another governor in
the power domain subsytem does not make much sense, you split the
decision in two layers while there is actually one, the existing
CPUidle governor and that's where the decision should be taken.

Thoughts appreciated.


Maybe this is silly and not thought-through, but I wonder if the 
responsibilities could be split or instance with an outer control loop 
that has the heuristic to compute the next tick time, and the required 
cpu-power needed during that time slot, and an inner control loop 
(genpd) that has a per-domain QoS and can optimize power consumption.



Not sure I understand everything you said, but the heuristics across a
bunch of CPUs can be very erratic. Its hard enough for menu governor to
determine heuristics on a per-cpu basis.

I governor in this patch already takes care of PM QoS, but does not do a
per-cpu QoS.

We should discuss this more.

-- Lina


Marc.



Lorenzo


Signed-off-by: Lina Iyer 
---
 drivers/base/power/cpu-pd.c | 83 -
 1 file changed, 82 insertions(+), 1 deletion(-)

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

 #define CPU_PD_NAME_MAX 36

@@ -66,6 +67,86 @@ static void get_cpus_in_domain(struct generic_pm_domain 
*genpd,
}
 }

+static bool cpu_pd_down_ok(struct dev_pm_domain *pd)
+{
+   struct generic_pm_domain *genpd = pd_to_genpd(pd);
+   struct cpu_pm_domain *cpu_pd = to_cpu_pd(genpd);
+   int qos = pm_qos_request(PM_QOS_CPU_DMA_LATENCY);
+   u64 sleep_ns = ~0;
+   ktime_t earliest;
+   int cpu;
+   int i;
+
+   /* Reset the last set genpd state, default to index 0 */
+   genpd->state_idx = 0;
+
+   /* We dont want to power down, if QoS is 0 */
+   if (!qos)
+   return false;
+
+   /*
+* Find the sleep time for the cluster.
+* The time between now and the first wake up of any CPU that
+* are in this domain hierarchy is the time available for the
+* domain to be idle.
+*/
+   earliest.tv64 = KTIME_MAX;
+   for_each_cpu_and(cpu, cpu_pd->cpus, cpu_online_mask) {
+   struct device *cpu_dev = get_cpu_device(cpu);
+   struct gpd_timing_data *td;
+
+   td = _gpd_data(cpu_dev)->td;
+
+   if (earliest.tv64 < td->next_wakeup.tv64)
+   earliest = td->next_wakeup;
+   }
+
+   sleep_ns = ktime_to_ns(ktime_sub(earliest, ktime_get()));
+   if (sleep_ns <= 0)
+   return false;
+
+   /*
+* Find the deepest sleep state that satisfies the residency
+* requirement and the QoS constraint
+*/
+   for (i = genpd->state_count - 1; i > 0; i--) {
+   u64 state_sleep_ns;
+
+   state_sleep_ns = genpd->states[i].power_off_latency_ns +
+   genpd->states[i].power_on_latency_ns +
+   genpd->states[i].residency_ns;
+
+   /*
+* If we cant sleep to save power in the state, move on
+* to the next lower idle state.
+*/
+   if (state_sleep_ns > 

Re: [RFC/PATCH] pinctrl: qcom: Add generic ssbi and spmi GPIO/MPP bindings

2015-11-20 Thread Stephen Boyd
On 11/19, Rob Herring wrote:
> On Tue, Nov 17, 2015 at 05:00:26PM -0800, Stephen Boyd wrote:
> > The drivers don't really need to know which PMIC they're for, so
> > make a generic binding for them. This alleviates us from updating
> > the drivers every time a new PMIC comes out. It's still
> > recommended that we update the binding with new PMIC models and
> > always specify the specific model for the MPPs and gpios before
> > the generic compatible string in devicetree, but this at least
> > cuts down on adding more and more compatible strings to the
> > drivers until we actually need them.
> > 
> > Cc: 
> > Cc: "Ivan T. Ivanov" 
> > Cc: Bjorn Andersson 
> > Signed-off-by: Stephen Boyd 
> > ---
> 
> Seems okay to me. I assume you are going to update all the dts files?

Yep, I'll send out patches to do that.

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


Re: [PATCH] clk: qcom: Specify LE device endianness

2015-11-20 Thread Tyler Baker
On 9 November 2015 at 14:30, Stephen Boyd <sb...@codeaurora.org> wrote:
> All these clock controllers are little endian devices, but so far
> we've been relying on the regmap mmio bus handling this for us
> without explicitly stating that fact. After commit 4a98da2164cf
> (regmap-mmio: Use native endianness for read/write, 2015-10-29),
> the regmap mmio bus will read/write with the __raw_*() IO
> accessors, instead of using the readl/writel() APIs that do
> proper byte swapping for little endian devices.
>
> So if we're running on a big endian processor and haven't
> specified the endianness explicitly in the regmap config or in
> DT, we're going to switch from doing little endian byte swapping
> to big endian accesses without byte swapping, leading to some
> confusing results. On my apq8074 dragonboard, this causes the
> device to fail to boot as we access the clock controller with
> big endian IO accesses even though the device is little endian.
>
> Specify the endianness explicitly so that the regmap core
> properly byte swaps the accesses for us.
>
> Reported-by: Kevin Hilman <khil...@linaro.org>
> Cc: Simon Arlott <si...@fire.lp0.eu>
> Cc: Mark Brown <broo...@kernel.org>
> Signed-off-by: Stephen Boyd <sb...@codeaurora.org>

Tested-by: Tyler Baker <tyler.ba...@linaro.org>

The kernelci.org bot also reported boot failures[1] for the
apq8016-sbc in next-20151120 with CONFIG_CPU_BIG_ENDIAN=y enabled.
I've bisected the failure down to the same offending remap-mmio patch
listed above. I've confirmed this patch applied on top of
next-20151120 fixes the boot issue for the apq8016-sbc as well.

Any updates or comments on this patch? I'd like to see this fix in
linux-next, as it has been broken for over a week and could be masking
new issues.

Cheers,

Tyler

[1] http://kernelci.org/boot/all/job/next/kernel/next-20151120/
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 10/10] dt-bindings: Add DSIv2 documentation

2015-11-20 Thread Rob Herring
+Stephen

On Wed, Nov 18, 2015 at 9:24 AM, Archit Taneja  wrote:
> Hi Rob,
>
> On 11/18/2015 6:48 PM, Rob Herring wrote:
>>
>> +dt list
>>
>> On Wed, Nov 18, 2015 at 4:55 AM, Archit Taneja 
>> wrote:
>>>
>>> Add additional property info needed for DSIv2 DT.
>>
>>
>> Please use get_maintainers.pl.
>
>
> Sorry about that, missed out doing that posting this time.
>
>>
>>> Signed-off-by: Archit Taneja 
>>> ---
>>>   Documentation/devicetree/bindings/display/msm/dsi.txt | 10 +-
>>>   1 file changed, 9 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt
>>> b/Documentation/devicetree/bindings/display/msm/dsi.txt
>>> index f344b9e..ca65a34 100644
>>> --- a/Documentation/devicetree/bindings/display/msm/dsi.txt
>>> +++ b/Documentation/devicetree/bindings/display/msm/dsi.txt
>>> @@ -13,18 +13,25 @@ Required properties:
>>>   - power-domains: Should be < MDSS_GDSC>.
>>>   - clocks: device clocks
>>> See Documentation/devicetree/bindings/clocks/clock-bindings.txt for
>>> details.
>>> -- clock-names: the following clocks are required:
>>> +- clock-names: these vary based on the DSI version. For DSI6G:
>>> * "bus_clk"
>>> * "byte_clk"
>>> +  * "byte_clk_src
>>
>>
>> This sounds like the parent of byte_clk. Is that really a clock within
>> the block?
>
>
> byte_clk_src isn't in the block, but byte_clk_src's parent is one of
> the PLLs in this block. We take this clock so that we can re-parent
> it to an appropriate PLL. The decision of what PLL to choose needs to
> be done by the DSI block's driver.

Seems like abuse to me. The list of clocks should match what are
inputs to the block, not what the driver happens to need. Without a
full understanding of the clock tree here, I don't have a suggestion.
Maybe Stephen does.

>>> * "core_clk"
>>> * "core_mmss_clk"
>>> * "iface_clk"
>>> * "mdp_core_clk"
>>> * "pixel_clk"
>>> +  * "pixel_clk_src"
>>> +  For DSIv2, we need a few more:
>>
>>
>> What is the overall order of clocks? As listed?
>
>
> Order in which the driver does clk_get? It uses the clock
> name to get each one individually, so the order doesn't matter
> as such.

The order in DT. You may use the names, but the order should still be specified.

Rob
--
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] clk: qcom: Specify LE device endianness

2015-11-20 Thread Stephen Boyd
On 11/20, Tyler Baker wrote:
> On 9 November 2015 at 14:30, Stephen Boyd <sb...@codeaurora.org> wrote:
> > All these clock controllers are little endian devices, but so far
> > we've been relying on the regmap mmio bus handling this for us
> > without explicitly stating that fact. After commit 4a98da2164cf
> > (regmap-mmio: Use native endianness for read/write, 2015-10-29),
> > the regmap mmio bus will read/write with the __raw_*() IO
> > accessors, instead of using the readl/writel() APIs that do
> > proper byte swapping for little endian devices.
> >
> > So if we're running on a big endian processor and haven't
> > specified the endianness explicitly in the regmap config or in
> > DT, we're going to switch from doing little endian byte swapping
> > to big endian accesses without byte swapping, leading to some
> > confusing results. On my apq8074 dragonboard, this causes the
> > device to fail to boot as we access the clock controller with
> > big endian IO accesses even though the device is little endian.
> >
> > Specify the endianness explicitly so that the regmap core
> > properly byte swaps the accesses for us.
> >
> > Reported-by: Kevin Hilman <khil...@linaro.org>
> > Cc: Simon Arlott <si...@fire.lp0.eu>
> > Cc: Mark Brown <broo...@kernel.org>
> > Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
> 
> Tested-by: Tyler Baker <tyler.ba...@linaro.org>
> 
> The kernelci.org bot also reported boot failures[1] for the
> apq8016-sbc in next-20151120 with CONFIG_CPU_BIG_ENDIAN=y enabled.
> I've bisected the failure down to the same offending remap-mmio patch
> listed above. I've confirmed this patch applied on top of
> next-20151120 fixes the boot issue for the apq8016-sbc as well.
> 
> Any updates or comments on this patch? I'd like to see this fix in
> linux-next, as it has been broken for over a week and could be masking
> new issues.

Yeah I've been lagging on applying patches. I need to send more
patches for other regmap-mmio users too. I'll cook those up right
now and send them off.

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


Re: [PATCH] clk: qcom: Specify LE device endianness

2015-11-20 Thread Stephen Boyd
On 11/09, Stephen Boyd wrote:
> All these clock controllers are little endian devices, but so far
> we've been relying on the regmap mmio bus handling this for us
> without explicitly stating that fact. After commit 4a98da2164cf
> (regmap-mmio: Use native endianness for read/write, 2015-10-29),
> the regmap mmio bus will read/write with the __raw_*() IO
> accessors, instead of using the readl/writel() APIs that do
> proper byte swapping for little endian devices.
> 
> So if we're running on a big endian processor and haven't
> specified the endianness explicitly in the regmap config or in
> DT, we're going to switch from doing little endian byte swapping
> to big endian accesses without byte swapping, leading to some
> confusing results. On my apq8074 dragonboard, this causes the
> device to fail to boot as we access the clock controller with
> big endian IO accesses even though the device is little endian.
> 
> Specify the endianness explicitly so that the regmap core
> properly byte swaps the accesses for us.
> 
> Reported-by: Kevin Hilman 
> Cc: Simon Arlott 
> Cc: Mark Brown 
> Signed-off-by: Stephen Boyd 
> ---

Applied to clk-next

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


[PATCH] nvmem: qfprom: Specify LE device endianness

2015-11-20 Thread Stephen Boyd
The qfprom is a little endian device, but so far we've been
relying on the regmap mmio bus handling this for us without
explicitly stating that fact. After commit 4a98da2164cf
(regmap-mmio: Use native endianness for read/write, 2015-10-29),
the regmap mmio bus will read/write with the __raw_*() IO
accessors, instead of using the readl/writel() APIs that do
proper byte swapping for little endian devices.

So if we're running on a big endian processor and haven't
specified the endianness explicitly in the regmap config or in
DT, we're going to switch from doing little endian byte swapping
to big endian accesses without byte swapping, leading to some
confusing results. Specify the endianness explicitly so that the
regmap core properly byte swaps the accesses for us.

Cc: Rajendra Nayak 
Cc: Kevin Hilman 
Cc: Tyler Baker 
Cc: Simon Arlott 
Cc: Mark Brown 
Signed-off-by: Stephen Boyd 
---
 drivers/nvmem/qfprom.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/nvmem/qfprom.c b/drivers/nvmem/qfprom.c
index afb67e74..3829e5fbf8c3 100644
--- a/drivers/nvmem/qfprom.c
+++ b/drivers/nvmem/qfprom.c
@@ -21,6 +21,7 @@ static struct regmap_config qfprom_regmap_config = {
.reg_bits = 32,
.val_bits = 8,
.reg_stride = 1,
+   .val_format_endian = REGMAP_ENDIAN_LITTLE,
 };
 
 static struct nvmem_config econfig = {
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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


[PATCH v4 3/3] usb: chipidea: register driver as a peripheral with the phy

2015-11-20 Thread Tim Bird
Register the chipidea driver with the phy, so that the phy
driver can kick the gadget driver when it resumes from low power.
The phy-msm-usb (Qualcomm) driver requires this in order to
recover gadget operation after you disconnect the USB cable
and reconnect it.

Signed-off-by: Tim Bird 
---
 drivers/usb/chipidea/udc.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index 8223fe7..06234cd 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -1890,6 +1890,12 @@ static int udc_start(struct ci_hdrc *ci)
 
ci->gadget.ep0 = >ep0in->ep;
 
+   if (ci->usb_phy) {
+   retval = otg_set_peripheral(ci->usb_phy->otg, >gadget);
+   if (retval)
+   goto destroy_eps;
+   }
+
retval = usb_add_gadget_udc(dev, >gadget);
if (retval)
goto destroy_eps;
-- 
1.8.2.2

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


[PATCH v4 2/3] usb: phy: msm: fix connect/disconnect bug for dragonboard OTG port

2015-11-20 Thread Tim Bird
Add support for async_irq to wake up driver from low power mode.
Without this, the power management code never calls resume.
Remove a spurious interrupt enable in the driver resume function.

Signed-off-by: Tim Bird 
---
 drivers/usb/phy/phy-msm-usb.c | 17 -
 include/linux/usb/msm_hsusb.h |  1 +
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
index e40a071..04fb056 100644
--- a/drivers/usb/phy/phy-msm-usb.c
+++ b/drivers/usb/phy/phy-msm-usb.c
@@ -648,7 +648,6 @@ skip_phy_resume:
if (motg->async_int) {
motg->async_int = 0;
pm_runtime_put(phy->dev);
-   enable_irq(motg->irq);
}
 
dev_info(phy->dev, "USB exited from low power mode\n");
@@ -1732,6 +1731,12 @@ static int msm_otg_probe(struct platform_device *pdev)
return motg->irq;
}
 
+   motg->async_irq = platform_get_irq_byname(pdev, "async");
+   if (motg->async_irq < 0) {
+   dev_err(>dev, "platform_get_irq for async irq failed\n");
+   motg->async_irq = 0;
+   }
+
regs[0].supply = "vddcx";
regs[1].supply = "v3p3";
regs[2].supply = "v1p8";
@@ -1781,6 +1786,16 @@ static int msm_otg_probe(struct platform_device *pdev)
goto disable_ldo;
}
 
+   if (motg->async_irq) {
+   ret = devm_request_irq(>dev, motg->async_irq,
+ msm_otg_irq, IRQF_TRIGGER_RISING,
+ "msm_otg", motg);
+   if (ret) {
+   dev_err(>dev, "request irq failed (ASYNC INT)\n");
+   goto disable_ldo;
+   }
+   }
+
phy->init = msm_phy_init;
phy->set_power = msm_otg_set_power;
phy->notify_disconnect = msm_phy_notify_disconnect;
diff --git a/include/linux/usb/msm_hsusb.h b/include/linux/usb/msm_hsusb.h
index 8c8f685..08c67a3 100644
--- a/include/linux/usb/msm_hsusb.h
+++ b/include/linux/usb/msm_hsusb.h
@@ -164,6 +164,7 @@ struct msm_otg {
struct usb_phy phy;
struct msm_otg_platform_data *pdata;
int irq;
+   int async_irq;
struct clk *clk;
struct clk *pclk;
struct clk *core_clk;
-- 
1.8.2.2

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


[PATCH v4 1/3] Documentation: dt-bindings: add async_irq to msm_hsusb

2015-11-20 Thread Tim Bird
Add optional async_irq to msm_hsusb binding doc.

Signed-off-by: Tim Bird 
---
 Documentation/devicetree/bindings/usb/msm-hsusb.txt | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/msm-hsusb.txt 
b/Documentation/devicetree/bindings/usb/msm-hsusb.txt
index 8654a3e..2d13c1c 100644
--- a/Documentation/devicetree/bindings/usb/msm-hsusb.txt
+++ b/Documentation/devicetree/bindings/usb/msm-hsusb.txt
@@ -23,7 +23,12 @@ Required properties:
   "qcom,usb-otg-snps" for chipsets with Synopsys 28nm PHY
 
 - regs: Offset and length of the register set in the memory map
-- interrupts:   interrupt-specifier for the OTG interrupt.
+- interrupts:   interrupt-specifier for the OTG interrupts
+
+- interrupt-names: Should contain the following:
+  "core"USB core interrupt
+  "async"   Asynchronous interrupt to wake up from low power mode
+(optional)
 
 - clocks:   A list of phandle + clock-specifier pairs for the
 clocks listed in clock-names
@@ -89,7 +94,8 @@ Example HSUSB OTG controller device node:
 usb@f9a55000 {
 compatible = "qcom,usb-otg-snps";
 reg = <0xf9a55000 0x400>;
-interrupts = <0 134 0>;
+interrupts = <0 134 0>, <0 140 0>;
+interrupt-names = "core", "async";
 dr_mode = "peripheral";
 
 clocks = < GCC_XO_CLK>, < GCC_USB_HS_SYSTEM_CLK>,
-- 
1.8.2.2

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


[PATCH 3/4] ARM: dts: qcom: Add DWC3 USB support on IPQ8064

2015-11-20 Thread Andy Gross
This patch adds Qualcomm DWC3 USB nodes to device tree to enable support for the
DWC3 controller found on IPQ8064/AP148 platforms.

Signed-off-by: Andy Gross 
---
 arch/arm/boot/dts/qcom-ipq8064-ap148.dts | 24 +
 arch/arm/boot/dts/qcom-ipq8064.dtsi  | 89 
 2 files changed, 113 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-ipq8064-ap148.dts 
b/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
index d501382..bf1638c 100644
--- a/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
+++ b/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
@@ -97,5 +97,29 @@
sata@2900 {
status = "ok";
};
+
+   phy@100f8800 {
+   status = "ok";
+   };
+
+   phy@100f8830 {
+   status = "ok";
+   };
+
+   usb30@0 {
+   status = "ok";
+   };
+
+   phy@110f8800 {
+   status = "ok";
+   };
+
+   phy@110f8830 {
+   status = "ok";
+   };
+
+   usb30@1 {
+   status = "ok";
+   };
};
 };
diff --git a/arch/arm/boot/dts/qcom-ipq8064.dtsi 
b/arch/arm/boot/dts/qcom-ipq8064.dtsi
index fa69863..b2dcd9d 100644
--- a/arch/arm/boot/dts/qcom-ipq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-ipq8064.dtsi
@@ -329,5 +329,94 @@
#reset-cells = <1>;
};
 
+   hs_phy_0: phy@100f8800 {
+   compatible = "qcom,dwc3-hs-usb-phy";
+   reg = <0x100f8800 0x30>;
+   clocks = < USB30_0_UTMI_CLK>;
+   clock-names = "ref";
+
+   #phy-cells = <0>;
+   status = "disabled";
+   };
+
+   ss_phy_0: phy@100f8830 {
+   compatible = "qcom,dwc3-ss-usb-phy";
+   reg = <0x100f8830 0x30>;
+
+   clocks = < USB30_0_MASTER_CLK>;
+   clock-names = "ref";
+
+   #phy-cells = <0>;
+   status = "disabled";
+   };
+
+   usb30@0 {
+   compatible = "qcom,dwc3";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   clocks = < USB30_0_MASTER_CLK>;
+   clock-names = "core";
+
+   syscon-tcsr = < 0xb0 1>;
+
+   ranges;
+
+   status = "disabled";
+
+   dwc3@1000 {
+   compatible = "snps,dwc3";
+   reg = <0x1000 0xcd00>;
+   interrupts = <0 205 0x4>;
+   phys = <_phy_0>, <_phy_0>;
+   phy-names = "usb2-phy", "usb3-phy";
+   tx-fifo-resize;
+   dr_mode = "host";
+   };
+   };
+
+   hs_phy_1: phy@110f8800 {
+   compatible = "qcom,dwc3-hs-usb-phy";
+   reg = <0x110f8800 0x30>;
+   clocks = < USB30_1_UTMI_CLK>;
+   clock-names = "ref";
+
+   #phy-cells = <0>;
+   status = "disabled";
+   };
+
+   ss_phy_1: phy@110f8830 {
+   compatible = "qcom,dwc3-ss-usb-phy";
+   reg = <0x110f8830 0x30>;
+
+   clocks = < USB30_1_MASTER_CLK>;
+   clock-names = "ref";
+
+   #phy-cells = <0>;
+   status = "disabled";
+   };
+
+   usb30@1 {
+   compatible = "qcom,dwc3";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   clocks = < USB30_1_MASTER_CLK>;
+   clock-names = "core";
+
+   syscon-tcsr = < 0xb0 0>;
+
+   ranges;
+
+   status = "disabled";
+
+   dwc3@1100 {
+   compatible = "snps,dwc3";
+   reg = <0x1100 0xcd00>;
+   interrupts = <0 110 0x4>;
+   phys = <_phy_1>, <_phy_1>;
+   phy-names = "usb2-phy", "usb3-phy";
+   tx-fifo-resize;
+   dr_mode = "host";
+   };
+   };
};
 };
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to 

[PATCH 2/4] usb: dwc3: qcom: Configure TCSR phy mux register

2015-11-20 Thread Andy Gross
This patch adds automatic configuration of the TCSR phy mux register based on
the syscon-tcsr devicetree entry.  This configuration is optional, as some
platforms may not require the mux selection.

Signed-off-by: Andy Gross 
---
 drivers/usb/dwc3/dwc3-qcom.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
index 0880260..fcf264c 100644
--- a/drivers/usb/dwc3/dwc3-qcom.c
+++ b/drivers/usb/dwc3/dwc3-qcom.c
@@ -17,6 +17,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 struct dwc3_qcom {
struct device   *dev;
@@ -30,6 +32,9 @@ static int dwc3_qcom_probe(struct platform_device *pdev)
 {
struct device_node *node = pdev->dev.of_node;
struct dwc3_qcom *qdwc;
+   struct regmap *regmap;
+   u32 mux_offset;
+   u32 mux_bit;
int ret;
 
qdwc = devm_kzalloc(>dev, sizeof(*qdwc), GFP_KERNEL);
@@ -58,6 +63,26 @@ static int dwc3_qcom_probe(struct platform_device *pdev)
qdwc->sleep_clk = NULL;
}
 
+   /* look for tcsr and if present, provision it */
+   regmap = syscon_regmap_lookup_by_phandle(node, "syscon-tcsr");
+   if (!IS_ERR(regmap)) {
+   if (of_property_read_u32_index(node, "syscon-tcsr", 1,
+  _offset)) {
+   dev_err(qdwc->dev, "missing USB TCSR mux offset\n");
+   return -EINVAL;
+   }
+   if (of_property_read_u32_index(node, "syscon-tcsr", 2,
+  _bit)) {
+   dev_err(qdwc->dev, "missing USB TCSR mux bit\n");
+   return -EINVAL;
+   }
+
+   regmap_update_bits(regmap, mux_offset, BIT(mux_bit),
+  BIT(mux_bit));
+   } else {
+   dev_info(qdwc->dev, "missing syscon tcsr entry\n");
+   }
+
ret = clk_prepare_enable(qdwc->core_clk);
if (ret) {
dev_err(qdwc->dev, "failed to enable core clock\n");
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

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


[PATCH v2 2/3] usb: phy: msm: fix connect/disconnect bug for dragonboard OTG port

2015-11-20 Thread Tim Bird
Add support for async_irq to wake up driver from low power mode.
Without this, the power management code never calls resume.
Remove a spurious interrupt enable in the driver resume function.

Signed-off-by: Tim Bird 
---
 drivers/usb/phy/phy-msm-usb.c | 17 -
 include/linux/usb/msm_hsusb.h |  1 +
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
index e40a071..db6297c 100644
--- a/drivers/usb/phy/phy-msm-usb.c
+++ b/drivers/usb/phy/phy-msm-usb.c
@@ -648,7 +648,6 @@ skip_phy_resume:
if (motg->async_int) {
motg->async_int = 0;
pm_runtime_put(phy->dev);
-   enable_irq(motg->irq);
}
 
dev_info(phy->dev, "USB exited from low power mode\n");
@@ -1732,6 +1731,12 @@ static int msm_otg_probe(struct platform_device *pdev)
return motg->irq;
}
 
+   motg->async_irq = platform_get_irq_byname(pdev, "async_irq");
+   if (motg->async_irq < 0) {
+   dev_err(>dev, "platform_get_irq for async_irq failed\n");
+   motg->async_irq = 0;
+   }
+
regs[0].supply = "vddcx";
regs[1].supply = "v3p3";
regs[2].supply = "v1p8";
@@ -1781,6 +1786,16 @@ static int msm_otg_probe(struct platform_device *pdev)
goto disable_ldo;
}
 
+   if (motg->async_irq) {
+   ret = devm_request_irq(>dev, motg->async_irq,
+ msm_otg_irq, IRQF_TRIGGER_RISING,
+ "msm_otg", motg);
+   if (ret) {
+   dev_err(>dev, "request irq failed (ASYNC INT)\n");
+   goto disable_ldo;
+   }
+   }
+
phy->init = msm_phy_init;
phy->set_power = msm_otg_set_power;
phy->notify_disconnect = msm_phy_notify_disconnect;
diff --git a/include/linux/usb/msm_hsusb.h b/include/linux/usb/msm_hsusb.h
index 8c8f685..08c67a3 100644
--- a/include/linux/usb/msm_hsusb.h
+++ b/include/linux/usb/msm_hsusb.h
@@ -164,6 +164,7 @@ struct msm_otg {
struct usb_phy phy;
struct msm_otg_platform_data *pdata;
int irq;
+   int async_irq;
struct clk *clk;
struct clk *pclk;
struct clk *core_clk;
-- 
1.8.2.2

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


[PATCH v2 1/3] Documentation: dt-bindings: add async_irq to msm_hsusb

2015-11-20 Thread Tim Bird
Add optional async_irq to msm_hsusb binding doc.

Signed-off-by: Tim Bird 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/usb/msm-hsusb.txt | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/msm-hsusb.txt 
b/Documentation/devicetree/bindings/usb/msm-hsusb.txt
index 8654a3e..7ba1dff 100644
--- a/Documentation/devicetree/bindings/usb/msm-hsusb.txt
+++ b/Documentation/devicetree/bindings/usb/msm-hsusb.txt
@@ -23,7 +23,12 @@ Required properties:
   "qcom,usb-otg-snps" for chipsets with Synopsys 28nm PHY
 
 - regs: Offset and length of the register set in the memory map
-- interrupts:   interrupt-specifier for the OTG interrupt.
+- interrupts:   interrupt-specifier for the OTG interrupts
+
+- interrupt-names: Should contain the following:
+  "core_irq"USB core interrupt
+  "async_irq"   Asynchronous interrupt to wake up from low power mode
+(optional)
 
 - clocks:   A list of phandle + clock-specifier pairs for the
 clocks listed in clock-names
@@ -89,7 +94,8 @@ Example HSUSB OTG controller device node:
 usb@f9a55000 {
 compatible = "qcom,usb-otg-snps";
 reg = <0xf9a55000 0x400>;
-interrupts = <0 134 0>;
+interrupts = <0 134 0>, <0 140 0>;
+interrupt-names = "core_irq", "async_irq";
 dr_mode = "peripheral";
 
 clocks = < GCC_XO_CLK>, < GCC_USB_HS_SYSTEM_CLK>,
-- 
1.8.2.2

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


[PATCH v2 3/3] usb: chipidea: register driver as a peripheral with the phy

2015-11-20 Thread Tim Bird
Register the chipidea driver with the phy, so that the phy
driver can kick the gadget driver when it resumes from low power.
The phy-msm-usb (Qualcomm) driver requires this in order to
recover gadget operation after you disconnect the USB cable
and reconnect it.

Signed-off-by: Tim Bird 
---
 drivers/usb/chipidea/udc.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index 8223fe7..06234cd 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -1890,6 +1890,12 @@ static int udc_start(struct ci_hdrc *ci)
 
ci->gadget.ep0 = >ep0in->ep;
 
+   if (ci->usb_phy) {
+   retval = otg_set_peripheral(ci->usb_phy->otg, >gadget);
+   if (retval)
+   goto destroy_eps;
+   }
+
retval = usb_add_gadget_udc(dev, >gadget);
if (retval)
goto destroy_eps;
-- 
1.8.2.2

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


[PATCH v2 4/5] arm64: dts: qcom: Alias pm8916 on msm8916 devices

2015-11-20 Thread Stephen Boyd
Add an alias for pm8916 on msm8916 based SoCs so that the newly
updated dtbTool can find the pmic compatible string and add the
pmic-id element to the QCDT header.

Signed-off-by: Stephen Boyd 
---
 arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi | 1 +
 arch/arm64/boot/dts/qcom/msm8916-mtp.dtsi | 1 +
 arch/arm64/boot/dts/qcom/pm8916.dtsi  | 6 +++---
 3 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi 
b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
index 6b8abbe68746..46bfcb9b2e84 100644
--- a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
+++ b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
@@ -20,6 +20,7 @@
aliases {
serial0 = _uart2;
serial1 = _uart1;
+   usid0 = _0;
};
 
chosen {
diff --git a/arch/arm64/boot/dts/qcom/msm8916-mtp.dtsi 
b/arch/arm64/boot/dts/qcom/msm8916-mtp.dtsi
index a1aa0b201e92..ceeb8a6feed6 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-mtp.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916-mtp.dtsi
@@ -17,6 +17,7 @@
 / {
aliases {
serial0 = _uart2;
+   usid0 = _0;
};
 
chosen {
diff --git a/arch/arm64/boot/dts/qcom/pm8916.dtsi 
b/arch/arm64/boot/dts/qcom/pm8916.dtsi
index b222ece7e3d2..37432451ee4c 100644
--- a/arch/arm64/boot/dts/qcom/pm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/pm8916.dtsi
@@ -4,8 +4,8 @@
 
 _bus {
 
-   usid0: pm8916@0 {
-   compatible = "qcom,spmi-pmic";
+   pm8916_0: pm8916@0 {
+   compatible = "qcom,pm8916", "qcom,spmi-pmic";
reg = <0x0 SPMI_USID>;
#address-cells = <1>;
#size-cells = <0>;
@@ -90,7 +90,7 @@
};
};
 
-   usid1: pm8916@1 {
+   pm8916_1: pm8916@1 {
compatible = "qcom,spmi-pmic";
reg = <0x1 SPMI_USID>;
#address-cells = <1>;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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


[PATCH v2 3/5] arm: dts: qcom: Update ifc6540 compat for qcom boot format

2015-11-20 Thread Stephen Boyd
The ifc6540 is an sbc (single board computer) board, so update
the compatible field accordingly.

Signed-off-by: Stephen Boyd 
---
 arch/arm/boot/dts/qcom-apq8084-ifc6540.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/qcom-apq8084-ifc6540.dts 
b/arch/arm/boot/dts/qcom-apq8084-ifc6540.dts
index c9c2b769554f..32aaa9d45228 100644
--- a/arch/arm/boot/dts/qcom-apq8084-ifc6540.dts
+++ b/arch/arm/boot/dts/qcom-apq8084-ifc6540.dts
@@ -3,7 +3,7 @@
 
 / {
model = "Qualcomm APQ8084/IFC6540";
-   compatible = "qcom,apq8084-ifc6540", "qcom,apq8084";
+   compatible = "qcom,apq8084-sbc", "qcom,apq8084";
 
aliases {
serial0 = _uart2;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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


Re: [PATCH v3 1/3] Documentation: dt-bindings: add async_irq to msm_hsusb

2015-11-20 Thread Arnd Bergmann
On Friday 20 November 2015 15:20:39 Tim Bird wrote:
> +- interrupt-names: Should contain the following:
> +  "core"USB core interrupt
> +  "async"   Asynchronous interrupt to wake up from low power mode
> +(optional)
>  
>  - clocks:   A list of phandle + clock-specifier pairs for the
>  clocks listed in clock-names
> @@ -89,7 +94,8 @@ Example HSUSB OTG controller device node:
>  usb@f9a55000 {
>  compatible = "qcom,usb-otg-snps";
>  reg = <0xf9a55000 0x400>;
> -interrupts = <0 134 0>;
> +interrupts = <0 134 0>, <0 140 0>;
> +interrupt-names = "core_irq", "async_irq";
>  dr_mode = "peripheral";
>  
> 

Now the example doesn't match the documentation any more.

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


[PATCH v3 2/3] usb: phy: msm: fix connect/disconnect bug for dragonboard OTG port

2015-11-20 Thread Tim Bird
Add support for async_irq to wake up driver from low power mode.
Without this, the power management code never calls resume.
Remove a spurious interrupt enable in the driver resume function.

Signed-off-by: Tim Bird 
---
 drivers/usb/phy/phy-msm-usb.c | 17 -
 include/linux/usb/msm_hsusb.h |  1 +
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
index e40a071..04fb056 100644
--- a/drivers/usb/phy/phy-msm-usb.c
+++ b/drivers/usb/phy/phy-msm-usb.c
@@ -648,7 +648,6 @@ skip_phy_resume:
if (motg->async_int) {
motg->async_int = 0;
pm_runtime_put(phy->dev);
-   enable_irq(motg->irq);
}
 
dev_info(phy->dev, "USB exited from low power mode\n");
@@ -1732,6 +1731,12 @@ static int msm_otg_probe(struct platform_device *pdev)
return motg->irq;
}
 
+   motg->async_irq = platform_get_irq_byname(pdev, "async");
+   if (motg->async_irq < 0) {
+   dev_err(>dev, "platform_get_irq for async irq failed\n");
+   motg->async_irq = 0;
+   }
+
regs[0].supply = "vddcx";
regs[1].supply = "v3p3";
regs[2].supply = "v1p8";
@@ -1781,6 +1786,16 @@ static int msm_otg_probe(struct platform_device *pdev)
goto disable_ldo;
}
 
+   if (motg->async_irq) {
+   ret = devm_request_irq(>dev, motg->async_irq,
+ msm_otg_irq, IRQF_TRIGGER_RISING,
+ "msm_otg", motg);
+   if (ret) {
+   dev_err(>dev, "request irq failed (ASYNC INT)\n");
+   goto disable_ldo;
+   }
+   }
+
phy->init = msm_phy_init;
phy->set_power = msm_otg_set_power;
phy->notify_disconnect = msm_phy_notify_disconnect;
diff --git a/include/linux/usb/msm_hsusb.h b/include/linux/usb/msm_hsusb.h
index 8c8f685..08c67a3 100644
--- a/include/linux/usb/msm_hsusb.h
+++ b/include/linux/usb/msm_hsusb.h
@@ -164,6 +164,7 @@ struct msm_otg {
struct usb_phy phy;
struct msm_otg_platform_data *pdata;
int irq;
+   int async_irq;
struct clk *clk;
struct clk *pclk;
struct clk *core_clk;
-- 
1.8.2.2

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


[PATCH v2 2/5] arm64: dts: qcom: Make msm8916-mtp compatible string compliant

2015-11-20 Thread Stephen Boyd
This compatible string isn't compliant with the format for
subtypes. Replace it with a compliant compatible type.

Signed-off-by: Stephen Boyd 
---
 arch/arm64/boot/dts/qcom/msm8916-mtp.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/msm8916-mtp.dts 
b/arch/arm64/boot/dts/qcom/msm8916-mtp.dts
index fced77f0fd3a..b0a064d3806b 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-mtp.dts
+++ b/arch/arm64/boot/dts/qcom/msm8916-mtp.dts
@@ -17,6 +17,6 @@
 
 / {
model = "Qualcomm Technologies, Inc. MSM 8916 MTP";
-   compatible = "qcom,msm8916-mtp", "qcom,msm8916-mtp-smb1360",
+   compatible = "qcom,msm8916-mtp", "qcom,msm8916-mtp/1",
"qcom,msm8916", "qcom,mtp";
 };
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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


[PATCH v2 5/5] arm: dts: qcom: Add aliases for PMICs

2015-11-20 Thread Stephen Boyd
Add an alias for the PMICs found on qcom based SoCs so that the
newly updated dtbTool can find the PMIC compatible string and add
the pmic-id element to the QCDT header.

Signed-off-by: Stephen Boyd 
---
 arch/arm/boot/dts/qcom-apq8074-dragonboard.dts | 2 ++
 arch/arm/boot/dts/qcom-apq8084-ifc6540.dts | 1 +
 arch/arm/boot/dts/qcom-apq8084-mtp.dts | 1 +
 arch/arm/boot/dts/qcom-pm8841.dtsi | 8 
 arch/arm/boot/dts/qcom-pm8941.dtsi | 8 
 arch/arm/boot/dts/qcom-pma8084.dtsi| 8 
 6 files changed, 16 insertions(+), 12 deletions(-)

diff --git a/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts 
b/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
index 835bdc71c5ba..c0e205315042 100644
--- a/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
+++ b/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
@@ -8,6 +8,8 @@
 
aliases {
serial0 = _uart2;
+   usid0 = _0;
+   usid4 = _0;
};
 
chosen {
diff --git a/arch/arm/boot/dts/qcom-apq8084-ifc6540.dts 
b/arch/arm/boot/dts/qcom-apq8084-ifc6540.dts
index 32aaa9d45228..2052b84a77c6 100644
--- a/arch/arm/boot/dts/qcom-apq8084-ifc6540.dts
+++ b/arch/arm/boot/dts/qcom-apq8084-ifc6540.dts
@@ -7,6 +7,7 @@
 
aliases {
serial0 = _uart2;
+   usid0 = _0;
};
 
chosen {
diff --git a/arch/arm/boot/dts/qcom-apq8084-mtp.dts 
b/arch/arm/boot/dts/qcom-apq8084-mtp.dts
index 3016c7048d44..d174d15bcf70 100644
--- a/arch/arm/boot/dts/qcom-apq8084-mtp.dts
+++ b/arch/arm/boot/dts/qcom-apq8084-mtp.dts
@@ -7,6 +7,7 @@
 
aliases {
serial0 = _uart2;
+   usid0 = _0;
};
 
chosen {
diff --git a/arch/arm/boot/dts/qcom-pm8841.dtsi 
b/arch/arm/boot/dts/qcom-pm8841.dtsi
index 8f1a0b162017..523bee959f98 100644
--- a/arch/arm/boot/dts/qcom-pm8841.dtsi
+++ b/arch/arm/boot/dts/qcom-pm8841.dtsi
@@ -3,8 +3,8 @@
 
 _bus {
 
-   usid4: pm8841@4 {
-   compatible = "qcom,spmi-pmic";
+   pm8841_0: pm8841@4 {
+   compatible = "qcom,pm8841", "qcom,spmi-pmic";
reg = <0x4 SPMI_USID>;
#address-cells = <1>;
#size-cells = <0>;
@@ -27,8 +27,8 @@
};
};
 
-   usid5: pm8841@5 {
-   compatible = "qcom,spmi-pmic";
+   pm8841_1: pm8841@5 {
+   compatible = "qcom,pm8841", "qcom,spmi-pmic";
reg = <0x5 SPMI_USID>;
#address-cells = <1>;
#size-cells = <0>;
diff --git a/arch/arm/boot/dts/qcom-pm8941.dtsi 
b/arch/arm/boot/dts/qcom-pm8941.dtsi
index c19a48732b2d..12c1202ba2ca 100644
--- a/arch/arm/boot/dts/qcom-pm8941.dtsi
+++ b/arch/arm/boot/dts/qcom-pm8941.dtsi
@@ -4,8 +4,8 @@
 
 _bus {
 
-   usid0: pm8941@0 {
-   compatible ="qcom,spmi-pmic";
+   pm8941_0: pm8941@0 {
+   compatible = "qcom,pm8941", "qcom,spmi-pmic";
reg = <0x0 SPMI_USID>;
#address-cells = <1>;
#size-cells = <0>;
@@ -153,8 +153,8 @@
};
};
 
-   usid1: pm8941@1 {
-   compatible = "qcom,spmi-pmic";
+   pm8941_1: pm8941@1 {
+   compatible = "qcom,pm8941", "qcom,spmi-pmic";
reg = <0x1 SPMI_USID>;
#address-cells = <1>;
#size-cells = <0>;
diff --git a/arch/arm/boot/dts/qcom-pma8084.dtsi 
b/arch/arm/boot/dts/qcom-pma8084.dtsi
index 5e240ccc08b7..10b8f9e6d60b 100644
--- a/arch/arm/boot/dts/qcom-pma8084.dtsi
+++ b/arch/arm/boot/dts/qcom-pma8084.dtsi
@@ -4,8 +4,8 @@
 
 _bus {
 
-   usid0: pma8084@0 {
-   compatible = "qcom,spmi-pmic";
+   pma8084_0: pma8084@0 {
+   compatible = "qcom,pma8084", "qcom,spmi-pmic";
reg = <0x0 SPMI_USID>;
#address-cells = <1>;
#size-cells = <0>;
@@ -101,8 +101,8 @@
};
};
 
-   usid1: pma8084@1 {
-   compatible = "qcom,spmi-pmic";
+   pma8084_1: pma8084@1 {
+   compatible = "qcom,pma8084", "qcom,spmi-pmic";
reg = <0x1 SPMI_USID>;
#address-cells = <1>;
#size-cells = <0>;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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


[PATCH v2 1/5] devicetree: bindings: Document qcom board compatible format

2015-11-20 Thread Stephen Boyd
Some qcom based bootloaders identify the dtb blob based on a set
of device properties like SoC, platform, PMIC, and revisions of
those components. In downstream kernels, these values are added
to the different component dtsi files (i.e. pmic dtsi file, SoC
dtsi file, board dtsi file, etc.) via qcom specific DT
properties. The dtb files are parsed by a program called dtbTool
that picks out these properties and creates a table of contents
binary blob with the property information and some offsets into
the concatenation of all the dtbs (termed a QCDT image).

The suggestion is to do this via the board compatible string
instead, because these qcom specific properties are never used by
the kernel. Add a document describing the format of the
compatible string that encodes all this information that's
currently encoded in the qcom,{msm-id,board-id,pmic-id}
properties in downstream devicetrees. Future bootloaders may be
updated to look at the compatible field instead of looking for
the table of contents image. For non-updateable bootloaders, a
new dtbTool program will parse the compatible string and generate
a QCDT image from it.

Signed-off-by: Stephen Boyd 
---
 Documentation/devicetree/bindings/arm/qcom.txt | 51 ++
 1 file changed, 51 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/qcom.txt

diff --git a/Documentation/devicetree/bindings/arm/qcom.txt 
b/Documentation/devicetree/bindings/arm/qcom.txt
new file mode 100644
index ..3e24518c6678
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/qcom.txt
@@ -0,0 +1,51 @@
+QCOM device tree bindings
+-
+
+Some qcom based bootloaders identify the dtb blob based on a set of
+device properties like SoC and platform and revisions of those components.
+To support this scheme, we encode this information into the board compatible
+string.
+
+Each board must specify a top-level board compatible string with the following
+format:
+
+   compatible = 
"qcom,[-][-]-[/][-]"
+
+The 'SoC' and 'board' elements are required. All other elements are optional.
+
+The 'SoC' element must be one of the following strings:
+
+   apq8016
+   apq8074
+   apq8084
+   apq8096
+   msm8916
+   msm8974
+   msm8996
+
+The 'board' element must be one of the following strings:
+
+   cdp
+   liquid
+   dragonboard
+   mtp
+   sbc
+
+The 'soc_version' and 'board_version' elements take the form of 
v.
+where the minor number may be omitted when it's zero, i.e.  v1.0 is the same
+as v1. If all versions of the 'board_version' elements match, then a
+wildcard '*' should be used, e.g. 'v*'.
+
+The 'foundry_id' and 'subtype' elements are one or more digits from 0 to 9.
+
+Examples:
+
+   "qcom,msm8916-v1-cdp-pm8916-v2.1"
+
+A CDP board with an msm8916 SoC, version 1 paired with a pm8916 PMIC of version
+2.1.
+
+   "qcom,apq8074-v2.0-2-dragonboard/1-v0.1"
+
+A dragonboard board v0.1 of subtype 1 with an apq8074 SoC version 2, made in
+foundry 2.
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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


[PATCH v2 0/5] Remove the need for qcom,{msm-id,board-id,pmic-id}

2015-11-20 Thread Stephen Boyd
This patchset documents a compatible string format that encodes
all the information that was being encoded in qcom specific DT
properties in downstream msm kernels. The goal being to come
up with a format that will allow us to express the information
we want to express without requiring the use of vendor specific
properties. An updated dtbTool will be released after these new
bindings are accepted so that users can work with non-updateable
bootloaders.

This is an attempt to resolve a discussion around March of this year[1]
where the arm-soc maintainers suggested we express this information
through the board's compatible string.

Changes from v1:
 * Remove unused elements (mb, panel, boot device)
 * Remove PMICs from board compatible
 * Add patches to allow us to parse PMIC compatibles with aliases

[1] 
http://lkml.kernel.org/g/1425503602-24916-1-git-send-email-ga...@codeaurora.org

Stephen Boyd (5):
  devicetree: bindings: Document qcom board compatible format
  arm64: dts: qcom: Make msm8916-mtp compatible string compliant
  arm: dts: qcom: Update ifc6540 compat for qcom boot format
  arm64: dts: qcom: Alias pm8916 on msm8916 devices
  arm: dts: qcom: Add aliases for PMICs

 Documentation/devicetree/bindings/arm/qcom.txt | 51 ++
 arch/arm/boot/dts/qcom-apq8074-dragonboard.dts |  2 +
 arch/arm/boot/dts/qcom-apq8084-ifc6540.dts |  3 +-
 arch/arm/boot/dts/qcom-apq8084-mtp.dts |  1 +
 arch/arm/boot/dts/qcom-pm8841.dtsi |  8 ++--
 arch/arm/boot/dts/qcom-pm8941.dtsi |  8 ++--
 arch/arm/boot/dts/qcom-pma8084.dtsi|  8 ++--
 arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi  |  1 +
 arch/arm64/boot/dts/qcom/msm8916-mtp.dts   |  2 +-
 arch/arm64/boot/dts/qcom/msm8916-mtp.dtsi  |  1 +
 arch/arm64/boot/dts/qcom/pm8916.dtsi   |  6 +--
 11 files changed, 74 insertions(+), 17 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/qcom.txt

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

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


Re: [PATCH 2/2] usb: phy: msm: fix connect/disconnect bug for dragonboard OTG port

2015-11-20 Thread Tim Bird


On 11/16/2015 09:21 AM, Felipe Balbi wrote:
> 
> Hi,
> 
> Peter Chen  writes:
>> On Wed, Nov 11, 2015 at 09:48:00AM -0800, Tim Bird wrote:
>>>
>>>
>>> On 11/10/2015 07:14 PM, Peter Chen wrote:
 On Tue, Nov 10, 2015 at 04:46:51PM -0800, Tim Bird wrote:
> This fixes a bug where if you disconnect and re-connect the USB cable,
> the gadget driver stops working.
>
> Add support for async_irq to wake up driver from low power mode.
> Without this, the power management code never calls resume.
> Also, have the phy driver kick the gadget driver (chipidea otg)
> by having the chipidea driver register with it, for vbus connect
> notifications.
>
> Signed-off-by: Tim Bird 
> ---
>  drivers/usb/chipidea/udc.c|  6 ++
>  drivers/usb/phy/phy-msm-usb.c | 16 
>  include/linux/usb/msm_hsusb.h |  1 +
>  3 files changed, 23 insertions(+)
> 
> I just wanna know how you guys want this to be handled ? Through my tree
> or chipidea's ? Or do we break the dependencies between the changes ?

I'm fine with splitting it up.  I'm sending a new series with 3 patches
right after this message.  Do both trees go to linux-next?
 -- Tim

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


Re: [PATCH v2 1/3] Documentation: dt-bindings: add async_irq to msm_hsusb

2015-11-20 Thread Sergei Shtylyov

Hello.

On 11/21/2015 01:37 AM, Tim Bird wrote:


Add optional async_irq to msm_hsusb binding doc.

Signed-off-by: Tim Bird 
Acked-by: Rob Herring 
---
  Documentation/devicetree/bindings/usb/msm-hsusb.txt | 10 --
  1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/msm-hsusb.txt 
b/Documentation/devicetree/bindings/usb/msm-hsusb.txt
index 8654a3e..7ba1dff 100644
--- a/Documentation/devicetree/bindings/usb/msm-hsusb.txt
+++ b/Documentation/devicetree/bindings/usb/msm-hsusb.txt
@@ -23,7 +23,12 @@ Required properties:
"qcom,usb-otg-snps" for chipsets with Synopsys 28nm PHY

  - regs: Offset and length of the register set in the memory map
-- interrupts:   interrupt-specifier for the OTG interrupt.
+- interrupts:   interrupt-specifier for the OTG interrupts
+
+- interrupt-names: Should contain the following:
+  "core_irq"USB core interrupt
+  "async_irq"   Asynchronous interrupt to wake up from low power mode


   I think the "_irq" part can be dropped...

[...]

MBR, Sergei

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


Re: [PATCH v2 1/3] Documentation: dt-bindings: add async_irq to msm_hsusb

2015-11-20 Thread Arnd Bergmann
On Friday 20 November 2015 14:37:16 Tim Bird wrote:
> +- interrupt-names: Should contain the following:
> +  "core_irq"USB core interrupt
> +  "async_irq"   Asynchronous interrupt to wake up from low power mode
> +(optional)
>  
> 

Sorry for the bike-shedding but how about just naming them "core" and "async"?

The redundant "_irq" postfix seems a little redundant.

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


Re: [PATCH v2 1/3] Documentation: dt-bindings: add async_irq to msm_hsusb

2015-11-20 Thread Tim Bird


On 11/20/2015 02:44 PM, Arnd Bergmann wrote:
> On Friday 20 November 2015 14:37:16 Tim Bird wrote:
>> +- interrupt-names: Should contain the following:
>> +  "core_irq"USB core interrupt
>> +  "async_irq"   Asynchronous interrupt to wake up from low power mode
>> +(optional)
>>  
>>
> 
> Sorry for the bike-shedding but how about just naming them "core" and "async"?
> 
> The redundant "_irq" postfix seems a little redundant.
OK - look for v3 RSN(tm)  (Real Soon Now)
 -- Tim

P.S. This is a cynical ploy to get me to automate my patch release process, 
isn't it? :-)

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


[PATCH v3 1/3] Documentation: dt-bindings: add async_irq to msm_hsusb

2015-11-20 Thread Tim Bird
Add optional async_irq to msm_hsusb binding doc.

Signed-off-by: Tim Bird 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/usb/msm-hsusb.txt | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/msm-hsusb.txt 
b/Documentation/devicetree/bindings/usb/msm-hsusb.txt
index 8654a3e..bb2b304 100644
--- a/Documentation/devicetree/bindings/usb/msm-hsusb.txt
+++ b/Documentation/devicetree/bindings/usb/msm-hsusb.txt
@@ -23,7 +23,12 @@ Required properties:
   "qcom,usb-otg-snps" for chipsets with Synopsys 28nm PHY
 
 - regs: Offset and length of the register set in the memory map
-- interrupts:   interrupt-specifier for the OTG interrupt.
+- interrupts:   interrupt-specifier for the OTG interrupts
+
+- interrupt-names: Should contain the following:
+  "core"USB core interrupt
+  "async"   Asynchronous interrupt to wake up from low power mode
+(optional)
 
 - clocks:   A list of phandle + clock-specifier pairs for the
 clocks listed in clock-names
@@ -89,7 +94,8 @@ Example HSUSB OTG controller device node:
 usb@f9a55000 {
 compatible = "qcom,usb-otg-snps";
 reg = <0xf9a55000 0x400>;
-interrupts = <0 134 0>;
+interrupts = <0 134 0>, <0 140 0>;
+interrupt-names = "core_irq", "async_irq";
 dr_mode = "peripheral";
 
 clocks = < GCC_XO_CLK>, < GCC_USB_HS_SYSTEM_CLK>,
-- 
1.8.2.2

--
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 v3 1/3] Documentation: dt-bindings: add async_irq to msm_hsusb

2015-11-20 Thread Tim Bird


On 11/20/2015 03:20 PM, Tim Bird wrote:
> Add optional async_irq to msm_hsusb binding doc.
> 
> Signed-off-by: Tim Bird 
> Acked-by: Rob Herring 

I probably should have taken this Acked-by by Rob off.  Sorry about that.
  -- Tim

> ---
>  Documentation/devicetree/bindings/usb/msm-hsusb.txt | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/usb/msm-hsusb.txt 
> b/Documentation/devicetree/bindings/usb/msm-hsusb.txt
> index 8654a3e..bb2b304 100644
> --- a/Documentation/devicetree/bindings/usb/msm-hsusb.txt
> +++ b/Documentation/devicetree/bindings/usb/msm-hsusb.txt
> @@ -23,7 +23,12 @@ Required properties:
>"qcom,usb-otg-snps" for chipsets with Synopsys 28nm PHY
>  
>  - regs: Offset and length of the register set in the memory map
> -- interrupts:   interrupt-specifier for the OTG interrupt.
> +- interrupts:   interrupt-specifier for the OTG interrupts
> +
> +- interrupt-names: Should contain the following:
> +  "core"USB core interrupt
> +  "async"   Asynchronous interrupt to wake up from low power mode
> +(optional)
>  
>  - clocks:   A list of phandle + clock-specifier pairs for the
>  clocks listed in clock-names
> @@ -89,7 +94,8 @@ Example HSUSB OTG controller device node:
>  usb@f9a55000 {
>  compatible = "qcom,usb-otg-snps";
>  reg = <0xf9a55000 0x400>;
> -interrupts = <0 134 0>;
> +interrupts = <0 134 0>, <0 140 0>;
> +interrupt-names = "core_irq", "async_irq";
>  dr_mode = "peripheral";
>  
>  clocks = < GCC_XO_CLK>, < GCC_USB_HS_SYSTEM_CLK>,
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v3 3/3] usb: chipidea: register driver as a peripheral with the phy

2015-11-20 Thread Tim Bird
Register the chipidea driver with the phy, so that the phy
driver can kick the gadget driver when it resumes from low power.
The phy-msm-usb (Qualcomm) driver requires this in order to
recover gadget operation after you disconnect the USB cable
and reconnect it.

Signed-off-by: Tim Bird 
---
 drivers/usb/chipidea/udc.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index 8223fe7..06234cd 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -1890,6 +1890,12 @@ static int udc_start(struct ci_hdrc *ci)
 
ci->gadget.ep0 = >ep0in->ep;
 
+   if (ci->usb_phy) {
+   retval = otg_set_peripheral(ci->usb_phy->otg, >gadget);
+   if (retval)
+   goto destroy_eps;
+   }
+
retval = usb_add_gadget_udc(dev, >gadget);
if (retval)
goto destroy_eps;
-- 
1.8.2.2

--
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 v3 1/3] Documentation: dt-bindings: add async_irq to msm_hsusb

2015-11-20 Thread Tim Bird


On 11/20/2015 03:22 PM, Arnd Bergmann wrote:
> On Friday 20 November 2015 15:20:39 Tim Bird wrote:
>> +- interrupt-names: Should contain the following:
>> +  "core"USB core interrupt
>> +  "async"   Asynchronous interrupt to wake up from low power mode
>> +(optional)
>>  
>>  - clocks:   A list of phandle + clock-specifier pairs for the
>>  clocks listed in clock-names
>> @@ -89,7 +94,8 @@ Example HSUSB OTG controller device node:
>>  usb@f9a55000 {
>>  compatible = "qcom,usb-otg-snps";
>>  reg = <0xf9a55000 0x400>;
>> -interrupts = <0 134 0>;
>> +interrupts = <0 134 0>, <0 140 0>;
>> +interrupt-names = "core_irq", "async_irq";
>>  dr_mode = "peripheral";
>>  
>>
> 
> Now the example doesn't match the documentation any more.
Arrgh.  I'm an idiot.  V4 coming RSN.
 -- Tim

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


[PATCH] ASoC: qcom: Specify LE device endianness

2015-11-20 Thread Stephen Boyd
This is a little endian device, but so far we've been relying on
the regmap mmio bus handling this for us without explicitly
stating that fact. After commit 4a98da2164cf (regmap-mmio: Use
native endianness for read/write, 2015-10-29), the regmap mmio
bus will read/write with the __raw_*() IO accessors, instead of
using the readl/writel() APIs that do proper byte swapping for
little endian devices.

So if we're running on a big endian processor and haven't
specified the endianness explicitly in the regmap config or in
DT, we're going to switch from doing little endian byte swapping
to big endian accesses without byte swapping, leading to some
confusing results. Specify the endianness explicitly so that the
regmap core properly byte swaps the accesses for us.

Cc: Kenneth Westfield 
Cc: Kevin Hilman 
Cc: Tyler Baker 
Cc: Simon Arlott 
Signed-off-by: Stephen Boyd 
---
 sound/soc/qcom/lpass-cpu.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/soc/qcom/lpass-cpu.c b/sound/soc/qcom/lpass-cpu.c
index e5101e0d2d37..00b6c9d039cf 100644
--- a/sound/soc/qcom/lpass-cpu.c
+++ b/sound/soc/qcom/lpass-cpu.c
@@ -355,6 +355,7 @@ static struct regmap_config lpass_cpu_regmap_config = {
.readable_reg = lpass_cpu_regmap_readable,
.volatile_reg = lpass_cpu_regmap_volatile,
.cache_type = REGCACHE_FLAT,
+   .val_format_endian = REGMAP_ENDIAN_LITTLE,
 };
 
 int asoc_qcom_lpass_cpu_platform_probe(struct platform_device *pdev)
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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


Re: [PATCH v4 1/5] clk: qcom: msm8916: Move xo and sleep clocks into DT

2015-11-20 Thread Stephen Boyd
On 11/19, Georgi Djakov wrote:
> Move the xo and sleep clocks to device-tree, instead of hard-coding
> them in the driver. This allows us to insert the RPM clocks (if they
> are enabled) in between the on-board oscillators and the actual clock.
> 
> Signed-off-by: Georgi Djakov 
> ---

Applied to clk-next

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


Re: [PATCH v4 2/5] arm64: dts: qcom: msm8916: Add fixed rate on-board oscillator

2015-11-20 Thread Stephen Boyd
On 11/19, Georgi Djakov wrote:
> Currently the rates of the xo and sleep clocks are hard-coded in the
> GCC driver, but this is a board layout description that actually should
> be in the DT. Moving them into DT also allows us to insert the RPM
> controlled clocks between the DT and GCC clocks.
> 
> Signed-off-by: Georgi Djakov 
> ---

I'll leave this one to Andy.

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


Re: [PATCH 2/2] usb: phy: msm: fix connect/disconnect bug for dragonboard OTG port

2015-11-20 Thread Felipe Balbi

Hi,

Tim Bird  writes:
> On 11/16/2015 09:21 AM, Felipe Balbi wrote:
>> 
>> Hi,
>> 
>> Peter Chen  writes:
>>> On Wed, Nov 11, 2015 at 09:48:00AM -0800, Tim Bird wrote:


 On 11/10/2015 07:14 PM, Peter Chen wrote:
> On Tue, Nov 10, 2015 at 04:46:51PM -0800, Tim Bird wrote:
>> This fixes a bug where if you disconnect and re-connect the USB cable,
>> the gadget driver stops working.
>>
>> Add support for async_irq to wake up driver from low power mode.
>> Without this, the power management code never calls resume.
>> Also, have the phy driver kick the gadget driver (chipidea otg)
>> by having the chipidea driver register with it, for vbus connect
>> notifications.
>>
>> Signed-off-by: Tim Bird 
>> ---
>>  drivers/usb/chipidea/udc.c|  6 ++
>>  drivers/usb/phy/phy-msm-usb.c | 16 
>>  include/linux/usb/msm_hsusb.h |  1 +
>>  3 files changed, 23 insertions(+)
>> 
>> I just wanna know how you guys want this to be handled ? Through my tree
>> or chipidea's ? Or do we break the dependencies between the changes ?
>
> I'm fine with splitting it up.  I'm sending a new series with 3 patches
> right after this message.  Do both trees go to linux-next?

I have my fixes and next branches both on next. Not sure about chipidea.

-- 
balbi


signature.asc
Description: PGP signature


[RFC/PATCH 2/3] recordmcount: Record locations of __aeabi_{u}idiv() calls on ARM

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

Cc: Nicolas Pitre 
Cc: Arnd Bergmann 
Cc: Steven Rostedt 
Cc: Måns Rullgård 
Signed-off-by: Stephen Boyd 
---
 scripts/recordmcount.h | 335 +++--
 1 file changed, 269 insertions(+), 66 deletions(-)

diff --git a/scripts/recordmcount.h b/scripts/recordmcount.h
index 6e196dba748d..cab91ffc82a6 100644
--- a/scripts/recordmcount.h
+++ b/scripts/recordmcount.h
@@ -18,11 +18,13 @@
  *
  * Licensed under the GNU General Public License, version 2 (GPLv2).
  */
+#undef append_section
 #undef append_func
 #undef is_fake_mcount
 #undef fn_is_fake_mcount
 #undef MIPS_is_fake_mcount
 #undef mcount_adjust
+#undef add_relocation
 #undef sift_rel_mcount
 #undef nop_mcount
 #undef find_secsym_ndx
@@ -30,6 +32,7 @@
 #undef has_rel_mcount
 #undef tot_relsize
 #undef get_mcountsym
+#undef get_arm_sym
 #undef get_sym_str_and_relp
 #undef do_func
 #undef Elf_Addr
@@ -52,7 +55,9 @@
 #undef _size
 
 #ifdef RECORD_MCOUNT_64
+# define append_sectionappend_section64
 # define append_func   append64
+# define add_relocationadd_relocation_64
 # define sift_rel_mcount   sift64_rel_mcount
 # define nop_mcountnop_mcount_64
 # define find_secsym_ndx   find64_secsym_ndx
@@ -62,6 +67,7 @@
 # define get_sym_str_and_relp  get_sym_str_and_relp_64
 # define do_func   do64
 # define get_mcountsym get_mcountsym_64
+# define get_arm_sym   get_arm_sym_64
 # define is_fake_mcountis_fake_mcount64
 # define fn_is_fake_mcount fn_is_fake_mcount64
 # define MIPS_is_fake_mcount   MIPS64_is_fake_mcount
@@ -85,7 +91,9 @@
 # define _align7u
 # define _size 8
 #else
+# define append_sectionappend_section32
 # define append_func   append32
+# define add_relocationadd_relocation_32
 # define sift_rel_mcount   sift32_rel_mcount
 # define nop_mcountnop_mcount_32
 # define find_secsym_ndx   find32_secsym_ndx
@@ -95,6 +103,7 @@
 # define get_sym_str_and_relp  get_sym_str_and_relp_32
 # define do_func   do32
 # define get_mcountsym get_mcountsym_32
+# define get_arm_sym   get_arm_sym_32
 # define is_fake_mcountis_fake_mcount32
 # define fn_is_fake_mcount fn_is_fake_mcount32
 # define MIPS_is_fake_mcount   MIPS32_is_fake_mcount
@@ -174,6 +183,62 @@ static int MIPS_is_fake_mcount(Elf_Rel const *rp)
return is_fake;
 }
 
+static void append_section(uint_t const *const mloc0,
+  uint_t const *const mlocp,
+  Elf_Rel const *const mrel0,
+  Elf_Rel const *const mrelp,
+  char const *name,
+  unsigned int const rel_entsize,
+  unsigned int const symsec_sh_link,
+  uint_t *name_offp,
+  uint_t *tp,
+  unsigned *shnump
+   )
+{
+   Elf_Shdr mcsec;
+   uint_t name_off = *name_offp;
+   uint_t t = *tp;
+   uint_t loc_diff = (void *)mlocp - (void *)mloc0;
+   uint_t rel_diff = (void *)mrelp - (void *)mrel0;
+   unsigned shnum = *shnump;
+
+   mcsec.sh_name = w((sizeof(Elf_Rela) == rel_entsize) + strlen(".rel")
+   + name_off);
+   mcsec.sh_type = w(SHT_PROGBITS);
+   mcsec.sh_flags = _w(SHF_ALLOC);
+   mcsec.sh_addr = 0;
+   mcsec.sh_offset = _w(t);
+   mcsec.sh_size = _w(loc_diff);
+   mcsec.sh_link = 0;
+   mcsec.sh_info = 0;
+   mcsec.sh_addralign = _w(_size);
+   mcsec.sh_entsize = _w(_size);
+   uwrite(fd_map, , sizeof(mcsec));
+   t += loc_diff;
+
+   mcsec.sh_name = w(name_off);
+   mcsec.sh_type = (sizeof(Elf_Rela) == rel_entsize)
+   ? w(SHT_RELA)
+   : w(SHT_REL);
+   mcsec.sh_flags = 0;
+   mcsec.sh_addr = 0;
+   mcsec.sh_offset = _w(t);
+   mcsec.sh_size   = _w(rel_diff);
+   mcsec.sh_link = w(symsec_sh_link);
+   mcsec.sh_info = w(shnum);
+   mcsec.sh_addralign = _w(_size);
+   mcsec.sh_entsize = _w(rel_entsize);
+   uwrite(fd_map, , sizeof(mcsec));
+   t += rel_diff;
+
+   shnum += 2;
+   name_off += strlen(name) + 

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

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

This series extends recordmcount to record the locations of the calls
to the library functions on ARM builds, and puts those locations into a
table that we use to patch instructions at boot. The first two patches
are the recordmcount changes, while the last patch implements the runtime
patching for modules and kernel code. The module part also hooks into the
relocation patching code we already have.

The RFC tag is because I'm thinking of splitting the recordmcount changes
into a new program based on recordmcount so that we don't drag in a lot
of corner cases and stuff when we don't need to. I suspect it will be
cleaner that way too. Does anyone prefer one way or the other?

Comments/feedback appreciated.

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

Cc: Nicolas Pitre 
Cc: Arnd Bergmann 
Cc: Steven Rostedt 
Cc: Måns Rullgård 

Stephen Boyd (3):
  scripts: Allow recordmcount to be used without tracing enabled
  recordmcount: Record locations of __aeabi_{u}idiv() calls on ARM
  ARM: Replace calls to __aeabi_{u}idiv with udiv/sdiv instructions

 Makefile  |   7 +
 arch/arm/Kconfig  |  14 ++
 arch/arm/kernel/module.c  |  44 ++
 arch/arm/kernel/setup.c   |  34 +
 arch/arm/kernel/vmlinux.lds.S |  13 ++
 kernel/trace/Kconfig  |   4 +
 scripts/Makefile.build|  15 +-
 scripts/recordmcount.c|  10 +-
 scripts/recordmcount.h| 337 +-
 scripts/recordmcount.pl   |  11 +-
 10 files changed, 406 insertions(+), 83 deletions(-)

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

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


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

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

Cc: Nicolas Pitre 
Cc: Arnd Bergmann 
Cc: Steven Rostedt 
Cc: Måns Rullgård 
Signed-off-by: Stephen Boyd 
---
 Makefile  |  7 +++
 arch/arm/Kconfig  | 14 ++
 arch/arm/kernel/module.c  | 44 +++
 arch/arm/kernel/setup.c   | 34 +
 arch/arm/kernel/vmlinux.lds.S | 13 +
 kernel/trace/Kconfig  |  2 +-
 6 files changed, 113 insertions(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 69be581e7c7a..9efc8274eba9 100644
--- a/Makefile
+++ b/Makefile
@@ -737,6 +737,13 @@ ifdef CONFIG_DYNAMIC_FTRACE
 endif
 endif
 
+ifdef CONFIG_ARM_PATCH_UIDIV
+   ifndef BUILD_C_RECORDMCOUNT
+   BUILD_C_RECORDMCOUNT := y
+   export BUILD_C_RECORDMCOUNT
+   endif
+endif
+
 # We trigger additional mismatches with less inlining
 ifdef CONFIG_DEBUG_SECTION_MISMATCH
 KBUILD_CFLAGS += $(call cc-option, -fno-inline-functions-called-once)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 9246bd7cc3cf..9e2d2adcc85b 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1640,6 +1640,20 @@ config AEABI
 
  To use this you need GCC version 4.0.0 or later.
 
+config ARM_PATCH_UIDIV
+   bool "Runtime patch calls to __aeabi_{u}idiv() with udiv/sdiv"
+   depends on CPU_V7 && !XIP_KERNEL && AEABI
+   help
+ Some v7 CPUs have support for the udiv and sdiv instructions
+ that can be used in place of calls to __aeabi_uidiv and __aeabi_idiv
+ functions provided by the ARM runtime ABI.
+
+ Enabling this option allows the kernel to modify itself to replace
+ branches to these library functions with the udiv and sdiv
+ instructions themselves. Typically this will be faster and less
+ power intensive than running the library support code to do
+ integer division.
+
 config OABI_COMPAT
bool "Allow old ABI binaries to run with this kernel (EXPERIMENTAL)"
depends on AEABI && !THUMB2_KERNEL
diff --git a/arch/arm/kernel/module.c b/arch/arm/kernel/module.c
index efdddcb97dd1..064e6ae60e08 100644
--- a/arch/arm/kernel/module.c
+++ b/arch/arm/kernel/module.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 #include 
@@ -51,6 +52,43 @@ void *module_alloc(unsigned long size)
 }
 #endif
 
+#ifdef CONFIG_ARM_PATCH_UIDIV
+static int module_patch_aeabi_uidiv(unsigned long loc, const Elf32_Sym *sym)
+{
+   extern char __aeabi_uidiv[], __aeabi_idiv[];
+   unsigned long udiv_addr = (unsigned long)__aeabi_uidiv;
+   unsigned long sdiv_addr = (unsigned long)__aeabi_idiv;
+   unsigned int udiv_insn, sdiv_insn, mask;
+
+   if (IS_ENABLED(CONFIG_THUMB2_KERNEL)) {
+   mask = HWCAP_IDIVT;
+   udiv_insn = __opcode_to_mem_thumb32(0xfbb0f0f1);
+   sdiv_insn = __opcode_to_mem_thumb32(0xfb90f0f1);
+   } else {
+   mask = HWCAP_IDIVA;
+   udiv_insn = __opcode_to_mem_arm(0xe730f110);
+   sdiv_insn = __opcode_to_mem_arm(0xe710f110);
+   }
+
+   if (elf_hwcap & mask) {
+   if (sym->st_value == udiv_addr) {
+   *(u32 *)loc = udiv_insn;
+   return 1;
+   } else if (sym->st_value == sdiv_addr) {
+   *(u32 *)loc = sdiv_insn;
+   return 1;
+   }
+   }
+
+   return 0;
+}
+#else
+static int module_patch_aeabi_uidiv(unsigned long loc, const Elf32_Sym *sym)
+{
+   return 0;
+}
+#endif
+
 int
 apply_relocate(Elf32_Shdr *sechdrs, const char *strtab, unsigned int symindex,
   unsigned int relindex, struct module *module)
@@ -109,6 +147,9 @@ apply_relocate(Elf32_Shdr *sechdrs, const char *strtab, 
unsigned int symindex,
return -ENOEXEC;
}
 
+   if (module_patch_aeabi_uidiv(loc, sym))
+   break;
+
offset = __mem_to_opcode_arm(*(u32 *)loc);
offset = (offset & 0x00ff) << 2;
if (offset & 

[RFC/PATCH 1/3] scripts: Allow recordmcount to be used without tracing enabled

2015-11-20 Thread Stephen Boyd
In the next patch we're going to modify recordmcount to also
record locations of calls to __aeabi_{u}idiv(). Lay the
groundwork for this by adding a flag to recordmcount that
indicates if we're expected to find calls to mcount or not.

Cc: Nicolas Pitre 
Cc: Arnd Bergmann 
Cc: Steven Rostedt 
Cc: Måns Rullgård 
Signed-off-by: Stephen Boyd 
---
 kernel/trace/Kconfig|  4 
 scripts/Makefile.build  | 15 +--
 scripts/recordmcount.c  | 10 +++---
 scripts/recordmcount.h  |  2 +-
 scripts/recordmcount.pl | 11 ---
 5 files changed, 25 insertions(+), 17 deletions(-)

diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
index 8d6363f42169..578b666ed7d9 100644
--- a/kernel/trace/Kconfig
+++ b/kernel/trace/Kconfig
@@ -57,6 +57,10 @@ config HAVE_C_RECORDMCOUNT
help
  C version of recordmcount available?
 
+config RUN_RECORDMCOUNT
+   def_bool y
+   depends on DYNAMIC_FTRACE && HAVE_FTRACE_MCOUNT_RECORD
+
 config TRACER_MAX_TRACE
bool
 
diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index 01df30af4d4a..22f2eb10d434 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -210,7 +210,7 @@ cmd_modversions =   
\
fi;
 endif
 
-ifdef CONFIG_FTRACE_MCOUNT_RECORD
+ifdef CONFIG_RUN_RECORDMCOUNT
 ifdef BUILD_C_RECORDMCOUNT
 ifeq ("$(origin RECORDMCOUNT_WARN)", "command line")
   RECORDMCOUNT_FLAGS = -w
@@ -219,26 +219,21 @@ endif
 # The empty.o file is created in the make process in order to determine
 #  the target endianness and word size. It is made before all other C
 #  files, including recordmcount.
-sub_cmd_record_mcount =\
+cmd_record_mcount =\
if [ $(@) != "scripts/mod/empty.o" ]; then  \
-   $(objtree)/scripts/recordmcount $(RECORDMCOUNT_FLAGS) "$(@)";   
\
+   $(objtree)/scripts/recordmcount $(RECORDMCOUNT_FLAGS) $(if 
$(findstring $(CC_FLAGS_FTRACE),$(_c_flags)),-t,) "$(@)";\
fi;
 recordmcount_source := $(srctree)/scripts/recordmcount.c \
$(srctree)/scripts/recordmcount.h
 else
-sub_cmd_record_mcount = set -e ; perl $(srctree)/scripts/recordmcount.pl 
"$(ARCH)" \
+cmd_record_mcount = set -e ; perl $(srctree)/scripts/recordmcount.pl "$(ARCH)" 
\
"$(if $(CONFIG_CPU_BIG_ENDIAN),big,little)" \
"$(if $(CONFIG_64BIT),64,32)" \
"$(OBJDUMP)" "$(OBJCOPY)" "$(CC) $(KBUILD_CFLAGS)" \
"$(LD)" "$(NM)" "$(RM)" "$(MV)" \
-   "$(if $(part-of-module),1,0)" "$(@)";
+   "$(if $(part-of-module),1,0)" "$(if $(findstring 
$(CC_FLAGS_FTRACE),$(_c_flags)),1,0)" "$(@)";
 recordmcount_source := $(srctree)/scripts/recordmcount.pl
 endif
-cmd_record_mcount =\
-   if [ "$(findstring $(CC_FLAGS_FTRACE),$(_c_flags))" =   \
-"$(CC_FLAGS_FTRACE)" ]; then   \
-   $(sub_cmd_record_mcount)\
-   fi;
 endif
 
 define rule_cc_o_c
diff --git a/scripts/recordmcount.c b/scripts/recordmcount.c
index 698768bdc581..b6b4a5df647a 100644
--- a/scripts/recordmcount.c
+++ b/scripts/recordmcount.c
@@ -54,6 +54,7 @@ static struct stat sb;/* Remember .st_size, etc. */
 static jmp_buf jmpenv; /* setjmp/longjmp per-file error escape */
 static const char *altmcount;  /* alternate mcount symbol name */
 static int warn_on_notrace_sect; /* warn when section has mcount not being 
recorded */
+static int trace_mcount; /* Record mcount callers */
 
 /* setjmp() return values */
 enum {
@@ -453,19 +454,22 @@ main(int argc, char *argv[])
int c;
int i;
 
-   while ((c = getopt(argc, argv, "w")) >= 0) {
+   while ((c = getopt(argc, argv, "wt")) >= 0) {
switch (c) {
case 'w':
warn_on_notrace_sect = 1;
break;
+   case 't':
+   trace_mcount = 1;
+   break;
default:
-   fprintf(stderr, "usage: recordmcount [-w] file.o...\n");
+   fprintf(stderr, "usage: recordmcount [-wt] 
file.o...\n");
return 0;
}
}
 
if ((argc - optind) < 1) {
-   fprintf(stderr, "usage: recordmcount [-w] file.o...\n");
+   fprintf(stderr, "usage: recordmcount [-wt] file.o...\n");
return 0;
}
 
diff --git a/scripts/recordmcount.h b/scripts/recordmcount.h
index b9897e2be404..6e196dba748d 100644
--- a/scripts/recordmcount.h
+++ b/scripts/recordmcount.h
@@ -323,7 +323,7 @@ static uint_t *sift_rel_mcount(uint_t *mlocp,
get_sym_str_and_relp(relhdr, ehdr, , , );
 
for (t = nrel; t; --t) {
-   if (!mcountsym)
+   if 

[PATCH] arm: dts: qcom: Add generic PMIC gpio/MPP compat strings

2015-11-20 Thread Stephen Boyd
Add the generic compatible strings for the PMIC gpio and MPP
modules found on qcom based PMICs.

Cc: 
Cc: "Ivan T. Ivanov" 
Cc: Bjorn Andersson 
Cc: Rob Herring 
Signed-off-by: Stephen Boyd 
---
 arch/arm/boot/dts/qcom-apq8064.dtsi | 6 --
 arch/arm/boot/dts/qcom-pm8841.dtsi  | 2 +-
 arch/arm/boot/dts/qcom-pm8941.dtsi  | 4 ++--
 arch/arm/boot/dts/qcom-pma8084.dtsi | 4 ++--
 4 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi 
b/arch/arm/boot/dts/qcom-apq8064.dtsi
index 11aca7fb1793..d0670d0ee08c 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -430,7 +430,8 @@
 
pm8921_gpio: gpio@150 {
 
-   compatible = "qcom,pm8921-gpio";
+   compatible = "qcom,pm8921-gpio",
+"qcom,ssbi-gpio";
reg = <0x150>;
interrupts = <192 1>, <193 1>, <194 1>,
 <195 1>, <196 1>, <197 1>,
@@ -454,7 +455,8 @@
};
 
pm8921_mpps: mpps@50 {
-   compatible = "qcom,pm8921-mpp";
+   compatible = "qcom,pm8921-mpp",
+"qcom,ssbi-mpp";
reg = <0x50>;
gpio-controller;
#gpio-cells = <2>;
diff --git a/arch/arm/boot/dts/qcom-pm8841.dtsi 
b/arch/arm/boot/dts/qcom-pm8841.dtsi
index 523bee959f98..9f357f68713c 100644
--- a/arch/arm/boot/dts/qcom-pm8841.dtsi
+++ b/arch/arm/boot/dts/qcom-pm8841.dtsi
@@ -10,7 +10,7 @@
#size-cells = <0>;
 
pm8841_mpps: mpps@a000 {
-   compatible = "qcom,pm8841-mpp";
+   compatible = "qcom,pm8841-mpp", "qcom,spmi-mpp";
reg = <0xa000 0x400>;
gpio-controller;
#gpio-cells = <2>;
diff --git a/arch/arm/boot/dts/qcom-pm8941.dtsi 
b/arch/arm/boot/dts/qcom-pm8941.dtsi
index 12c1202ba2ca..64622bd251d1 100644
--- a/arch/arm/boot/dts/qcom-pm8941.dtsi
+++ b/arch/arm/boot/dts/qcom-pm8941.dtsi
@@ -48,7 +48,7 @@
};
 
pm8941_gpios: gpios@c000 {
-   compatible = "qcom,pm8941-gpio";
+   compatible = "qcom,pm8941-gpio", "qcom,spmi-gpio";
reg = <0xc000 0x2400>;
gpio-controller;
#gpio-cells = <2>;
@@ -91,7 +91,7 @@
};
 
pm8941_mpps: mpps@a000 {
-   compatible = "qcom,pm8941-mpp";
+   compatible = "qcom,pm8941-mpp", "qcom,spmi-mpp";
reg = <0xa000 0x800>;
gpio-controller;
#gpio-cells = <2>;
diff --git a/arch/arm/boot/dts/qcom-pma8084.dtsi 
b/arch/arm/boot/dts/qcom-pma8084.dtsi
index 10b8f9e6d60b..4e9bd3f88473 100644
--- a/arch/arm/boot/dts/qcom-pma8084.dtsi
+++ b/arch/arm/boot/dts/qcom-pma8084.dtsi
@@ -19,7 +19,7 @@
};
 
pma8084_gpios: gpios@c000 {
-   compatible = "qcom,pma8084-gpio";
+   compatible = "qcom,pma8084-gpio", "qcom,spmi-gpio";
reg = <0xc000 0x1600>;
gpio-controller;
#gpio-cells = <2>;
@@ -48,7 +48,7 @@
};
 
pma8084_mpps: mpps@a000 {
-   compatible = "qcom,pma8084-mpp";
+   compatible = "qcom,pma8084-mpp", "qcom,spmi-mpp";
reg = <0xa000 0x800>;
gpio-controller;
#gpio-cells = <2>;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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


[PATCH 4/4] Documentation: usb: dwc3: qcom: Add TCSR mux usage

2015-11-20 Thread Andy Gross
This patch adds documentation for the optional syscon-tcsr property in the
Qualcomm DWC3 node.  The syscon-tcsr specifies the register and bit used to
configure the TCSR USB phy mux register.

Signed-off-by: Andy Gross 
---
 Documentation/devicetree/bindings/usb/qcom,dwc3.txt | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/qcom,dwc3.txt 
b/Documentation/devicetree/bindings/usb/qcom,dwc3.txt
index ca164e7..dfa222d 100644
--- a/Documentation/devicetree/bindings/usb/qcom,dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/qcom,dwc3.txt
@@ -8,6 +8,10 @@ Required properties:
   "core"   Master/Core clock, have to be >= 125 MHz for SS
operation and >= 60MHz for HS operation
 
+Optional properties:
+- syscon-tcsr  Specifies TCSR handle, register offset, and bit position for
+   configuring the phy mux setting.
+
 Optional clocks:
   "iface"  System bus AXI clock.  Not present on all platforms
   "sleep"  Sleep clock, used when USB3 core goes into low
@@ -22,6 +26,11 @@ Documentation/devicetree/bindings/phy/qcom,dwc3-usb-phy.txt
 
 Example device nodes:
 
+   tcsr: syscon@1a40 {
+   compatible = "qcom,tcsr-ipq8064", "syscon";
+   reg = <0x1a40 0x100>;
+   };
+
hs_phy: phy@100f8800 {
compatible = "qcom,dwc3-hs-usb-phy";
reg = <0x100f8800 0x30>;
@@ -51,6 +60,8 @@ Example device nodes:
 
ranges;
 
+   syscon-tcsr = < 0xb0 0x1>;
+
status = "ok";
 
dwc3@1000 {
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

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