Re: [PATCH] mfd: qcom-spmi-pmic: Don't access non-existing registers

2016-01-06 Thread Stephen Boyd
On 11/17/15 16:06, Stephen Boyd wrote:
> From: "Ivan T. Ivanov" <ivan.iva...@linaro.org>
>
> Revision ID registers are available only on devices with
> Slave IDs that are even, so don't make access to unavailable
> registers.
>
> Signed-off-by: Ivan T. Ivanov <ivan.iva...@linaro.org>
> [sb...@codeaurora.org: Consider all slave ids that are even]
> Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
> ---

Ping?

>  drivers/mfd/qcom-spmi-pmic.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mfd/qcom-spmi-pmic.c b/drivers/mfd/qcom-spmi-pmic.c
> index af6ac1c4b45c..8653e8b9bb4f 100644
> --- a/drivers/mfd/qcom-spmi-pmic.c
> +++ b/drivers/mfd/qcom-spmi-pmic.c
> @@ -127,7 +127,9 @@ static int pmic_spmi_probe(struct spmi_device *sdev)
>   if (IS_ERR(regmap))
>   return PTR_ERR(regmap);
>  
> - pmic_spmi_show_revid(regmap, >dev);
> + /* Only the first slave id for a PMIC contains this information */
> + if (sdev->usid % 2 == 0)
> + pmic_spmi_show_revid(regmap, >dev);
>  
>   return of_platform_populate(root, NULL, NULL, >dev);
>  }

-- 
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/3] pinctrl: qcom: Use platform_irq_count() instead of of_irq_count()

2016-01-06 Thread Stephen Boyd
On 01/06/16 17:19, Bjorn Andersson wrote:
> On Wed, Jan 6, 2016 at 5:12 PM, Stephen Boyd <sb...@codeaurora.org> wrote:
>> of_irq_count() is not an exported symbol (and it shouldn't be
>> used by platform drivers anyway) so use platform_irq_count()
>> instead. This allows us to make the qcom pinctrl drivers modular
>> again.
>>
> [..]
>> diff --git a/drivers/pinctrl/qcom/pinctrl-ssbi-mpp.c 
>> b/drivers/pinctrl/qcom/pinctrl-ssbi-mpp.c
>> index 3ddb4cc38f1c..37ae6b72ea35 100644
>> --- a/drivers/pinctrl/qcom/pinctrl-ssbi-mpp.c
>> +++ b/drivers/pinctrl/qcom/pinctrl-ssbi-mpp.c
>> @@ -758,16 +758,19 @@ static int pm8xxx_mpp_probe(struct platform_device 
>> *pdev)
>> struct pinctrl_pin_desc *pins;
>> struct pm8xxx_mpp *pctrl;
>> int ret;
>> -   int i;
>> +   int i, npins;
>>
>> pctrl = devm_kzalloc(>dev, sizeof(*pctrl), GFP_KERNEL);
>> if (!pctrl)
>> return -ENOMEM;
>>
>> pctrl->dev = >dev;
>> -   pctrl->npins = of_irq_count(pdev->dev.of_node);
>> -   if (!pctrl->npins)
>> +   npins = of_irq_count(pdev->dev.of_node);
> platform_irq_count(pdev)

Ouch. So many duplicates the odds were against me.


-- 
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 v2 2/3] pinctrl: qcom: Use platform_irq_count() instead of of_irq_count()

2016-01-06 Thread Stephen Boyd
of_irq_count() is not an exported symbol (and it shouldn't be
used by platform drivers anyway) so use platform_irq_count()
instead. This allows us to make the qcom pinctrl drivers modular
again.

Cc: Rob Herring <robh...@kernel.org>
Cc: Andy Gross <andy.gr...@linaro.org>
Cc: Bjorn Andersson <bj...@kryo.se>
Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
---

Changes from v1:
 * Fixed one wrong of_irq_count() noticed by Bjorn

 drivers/pinctrl/qcom/pinctrl-spmi-gpio.c | 4 +++-
 drivers/pinctrl/qcom/pinctrl-spmi-mpp.c  | 4 +++-
 drivers/pinctrl/qcom/pinctrl-ssbi-gpio.c | 9 ++---
 drivers/pinctrl/qcom/pinctrl-ssbi-mpp.c  | 9 ++---
 4 files changed, 18 insertions(+), 8 deletions(-)

diff --git a/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c 
b/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
index f46dbbf7ff25..4e12ded3c773 100644
--- a/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
+++ b/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
@@ -697,9 +697,11 @@ static int pmic_gpio_probe(struct platform_device *pdev)
return ret;
}
 
-   npins = of_irq_count(dev->of_node);
+   npins = platform_irq_count(pdev);
if (!npins)
return -EINVAL;
+   if (npins < 0)
+   return npins;
 
BUG_ON(npins > ARRAY_SIZE(pmic_gpio_groups));
 
diff --git a/drivers/pinctrl/qcom/pinctrl-spmi-mpp.c 
b/drivers/pinctrl/qcom/pinctrl-spmi-mpp.c
index 5c7935012e3a..2f18323571a6 100644
--- a/drivers/pinctrl/qcom/pinctrl-spmi-mpp.c
+++ b/drivers/pinctrl/qcom/pinctrl-spmi-mpp.c
@@ -799,9 +799,11 @@ static int pmic_mpp_probe(struct platform_device *pdev)
return ret;
}
 
-   npins = of_irq_count(dev->of_node);
+   npins = platform_irq_count(pdev);
if (!npins)
return -EINVAL;
+   if (npins < 0)
+   return npins;
 
BUG_ON(npins > ARRAY_SIZE(pmic_mpp_groups));
 
diff --git a/drivers/pinctrl/qcom/pinctrl-ssbi-gpio.c 
b/drivers/pinctrl/qcom/pinctrl-ssbi-gpio.c
index f75e482073b7..cd8580d9741d 100644
--- a/drivers/pinctrl/qcom/pinctrl-ssbi-gpio.c
+++ b/drivers/pinctrl/qcom/pinctrl-ssbi-gpio.c
@@ -667,16 +667,19 @@ static int pm8xxx_gpio_probe(struct platform_device *pdev)
struct pinctrl_pin_desc *pins;
struct pm8xxx_gpio *pctrl;
int ret;
-   int i;
+   int i, npins;
 
pctrl = devm_kzalloc(>dev, sizeof(*pctrl), GFP_KERNEL);
if (!pctrl)
return -ENOMEM;
 
pctrl->dev = >dev;
-   pctrl->npins = of_irq_count(pdev->dev.of_node);
-   if (!pctrl->npins)
+   npins = platform_irq_count(pdev);
+   if (!npins)
return -EINVAL;
+   if (npins < 0)
+   return npins;
+   pctrl->npins = npins;
 
pctrl->regmap = dev_get_regmap(pdev->dev.parent, NULL);
if (!pctrl->regmap) {
diff --git a/drivers/pinctrl/qcom/pinctrl-ssbi-mpp.c 
b/drivers/pinctrl/qcom/pinctrl-ssbi-mpp.c
index 3e19c12a315a..54a5402a9079 100644
--- a/drivers/pinctrl/qcom/pinctrl-ssbi-mpp.c
+++ b/drivers/pinctrl/qcom/pinctrl-ssbi-mpp.c
@@ -758,16 +758,19 @@ static int pm8xxx_mpp_probe(struct platform_device *pdev)
struct pinctrl_pin_desc *pins;
struct pm8xxx_mpp *pctrl;
int ret;
-   int i;
+   int i, npins;
 
pctrl = devm_kzalloc(>dev, sizeof(*pctrl), GFP_KERNEL);
if (!pctrl)
return -ENOMEM;
 
pctrl->dev = >dev;
-   pctrl->npins = of_irq_count(pdev->dev.of_node);
-   if (!pctrl->npins)
+   npins = platform_irq_count(pdev);
+   if (!npins)
return -EINVAL;
+   if (npins < 0)
+   return npins;
+   pctrl->npins = npins;
 
pctrl->regmap = dev_get_regmap(pdev->dev.parent, NULL);
if (!pctrl->regmap) {
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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


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

2016-01-06 Thread Stephen Boyd
On 11/23/15 16:47, Stephen Boyd wrote:
> On 11/22, Rob Herring wrote:
>>
>> Much more reasonable now. I do find the '/' in it a bit strange though.
> I can remove the backslash if you like. Is a dash more preferred?
>
>> Acked-by: Rob Herring <r...@kernel.org>
>>
> and if so can I keep the ack? I'll resend with that change and
> add the ack.
>

I'll take no answer as "let's not change anything", so can someone
pickup this patch as is? Perhaps Andy can 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


[PATCH 1/3] driver-core: platform: Add platform_irq_count()

2016-01-06 Thread Stephen Boyd
A recent patch added calls to of_irq_count() in the qcom pinctrl
drivers and that caused module build failures because
of_irq_count() is not an exported symbol. We shouldn't export
of_irq_count() to modules because it's an internal OF API that
shouldn't be used by drivers. Platform drivers should use
platform device APIs instead. Therefore, add a platform_irq_count()
API that mirrors the of_irq_count() API so that platform drivers
can stay DT agnostic.

Cc: Rob Herring <robh...@kernel.org>
Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
Cc: Andy Gross <andy.gr...@linaro.org>
Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
---
 drivers/base/platform.c | 20 
 include/linux/platform_device.h |  1 +
 2 files changed, 21 insertions(+)

diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index d77ed0c946dd..8dcbb266643b 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -118,6 +118,26 @@ int platform_get_irq(struct platform_device *dev, unsigned 
int num)
 EXPORT_SYMBOL_GPL(platform_get_irq);
 
 /**
+ * platform_irq_count - Count the number of IRQs a platform device uses
+ * @dev: platform device
+ *
+ * Return: Number of IRQs a platform device uses or EPROBE_DEFER
+ */
+int platform_irq_count(struct platform_device *dev)
+{
+   int ret, nr = 0;
+
+   while ((ret = platform_get_irq(dev, nr)) >= 0)
+   nr++;
+
+   if (ret == -EPROBE_DEFER)
+   return ret;
+
+   return nr;
+}
+EXPORT_SYMBOL_GPL(platform_irq_count);
+
+/**
  * platform_get_resource_byname - get a resource for a device by name
  * @dev: platform device
  * @type: resource type
diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
index dba40b1c41dc..03b755521fd9 100644
--- a/include/linux/platform_device.h
+++ b/include/linux/platform_device.h
@@ -52,6 +52,7 @@ extern void arch_setup_pdev_archdata(struct platform_device 
*);
 extern struct resource *platform_get_resource(struct platform_device *,
  unsigned int, unsigned int);
 extern int platform_get_irq(struct platform_device *, unsigned int);
+extern int platform_irq_count(struct platform_device *);
 extern struct resource *platform_get_resource_byname(struct platform_device *,
 unsigned int,
 const char *);
-- 
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 2/3] pinctrl: qcom: Use platform_irq_count() instead of of_irq_count()

2016-01-06 Thread Stephen Boyd
of_irq_count() is not an exported symbol (and it shouldn't be
used by platform drivers anyway) so use platform_irq_count()
instead. This allows us to make the qcom pinctrl drivers modular
again.

Cc: Rob Herring <robh...@kernel.org>
Cc: Andy Gross <andy.gr...@linaro.org>
Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
---
 drivers/pinctrl/qcom/pinctrl-spmi-gpio.c | 4 +++-
 drivers/pinctrl/qcom/pinctrl-spmi-mpp.c  | 4 +++-
 drivers/pinctrl/qcom/pinctrl-ssbi-gpio.c | 9 ++---
 drivers/pinctrl/qcom/pinctrl-ssbi-mpp.c  | 9 ++---
 4 files changed, 18 insertions(+), 8 deletions(-)

diff --git a/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c 
b/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
index 60b922274879..9ed2b4eba1f8 100644
--- a/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
+++ b/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
@@ -702,9 +702,11 @@ static int pmic_gpio_probe(struct platform_device *pdev)
return ret;
}
 
-   npins = of_irq_count(dev->of_node);
+   npins = platform_irq_count(pdev);
if (!npins)
return -EINVAL;
+   if (npins < 0)
+   return npins;
 
BUG_ON(npins > ARRAY_SIZE(pmic_gpio_groups));
 
diff --git a/drivers/pinctrl/qcom/pinctrl-spmi-mpp.c 
b/drivers/pinctrl/qcom/pinctrl-spmi-mpp.c
index 5654287c382c..3fd04a6888a4 100644
--- a/drivers/pinctrl/qcom/pinctrl-spmi-mpp.c
+++ b/drivers/pinctrl/qcom/pinctrl-spmi-mpp.c
@@ -804,9 +804,11 @@ static int pmic_mpp_probe(struct platform_device *pdev)
return ret;
}
 
-   npins = of_irq_count(dev->of_node);
+   npins = platform_irq_count(pdev);
if (!npins)
return -EINVAL;
+   if (npins < 0)
+   return npins;
 
BUG_ON(npins > ARRAY_SIZE(pmic_mpp_groups));
 
diff --git a/drivers/pinctrl/qcom/pinctrl-ssbi-gpio.c 
b/drivers/pinctrl/qcom/pinctrl-ssbi-gpio.c
index df054e716dc0..bde2aa684dc1 100644
--- a/drivers/pinctrl/qcom/pinctrl-ssbi-gpio.c
+++ b/drivers/pinctrl/qcom/pinctrl-ssbi-gpio.c
@@ -667,16 +667,19 @@ static int pm8xxx_gpio_probe(struct platform_device *pdev)
struct pinctrl_pin_desc *pins;
struct pm8xxx_gpio *pctrl;
int ret;
-   int i;
+   int i, npins;
 
pctrl = devm_kzalloc(>dev, sizeof(*pctrl), GFP_KERNEL);
if (!pctrl)
return -ENOMEM;
 
pctrl->dev = >dev;
-   pctrl->npins = of_irq_count(pdev->dev.of_node);
-   if (!pctrl->npins)
+   npins = platform_irq_count(pdev);
+   if (!npins)
return -EINVAL;
+   if (npins < 0)
+   return npins;
+   pctrl->npins = npins;
 
pctrl->regmap = dev_get_regmap(pdev->dev.parent, NULL);
if (!pctrl->regmap) {
diff --git a/drivers/pinctrl/qcom/pinctrl-ssbi-mpp.c 
b/drivers/pinctrl/qcom/pinctrl-ssbi-mpp.c
index 3ddb4cc38f1c..37ae6b72ea35 100644
--- a/drivers/pinctrl/qcom/pinctrl-ssbi-mpp.c
+++ b/drivers/pinctrl/qcom/pinctrl-ssbi-mpp.c
@@ -758,16 +758,19 @@ static int pm8xxx_mpp_probe(struct platform_device *pdev)
struct pinctrl_pin_desc *pins;
struct pm8xxx_mpp *pctrl;
int ret;
-   int i;
+   int i, npins;
 
pctrl = devm_kzalloc(>dev, sizeof(*pctrl), GFP_KERNEL);
if (!pctrl)
return -ENOMEM;
 
pctrl->dev = >dev;
-   pctrl->npins = of_irq_count(pdev->dev.of_node);
-   if (!pctrl->npins)
+   npins = of_irq_count(pdev->dev.of_node);
+   if (!npins)
return -EINVAL;
+   if (npins < 0)
+   return npins;
+   pctrl->npins = npins;
 
pctrl->regmap = dev_get_regmap(pdev->dev.parent, NULL);
if (!pctrl->regmap) {
-- 
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] arm: dts: qcom: Add more board clocks

2016-01-06 Thread Stephen Boyd
These clocks are fixed rate board sources that should be in DT.
Add them.

Cc: Georgi Djakov <georgi.dja...@linaro.org>
Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
---

It seems that I never sent out the updated version of this patch
to cover all the SoCs we have. This is on top of linux-next.

 arch/arm/boot/dts/qcom-apq8084.dtsi | 14 ++
 arch/arm/boot/dts/qcom-ipq8064.dtsi | 12 
 arch/arm/boot/dts/qcom-msm8660.dtsi | 20 
 arch/arm/boot/dts/qcom-msm8974.dtsi | 14 ++
 4 files changed, 60 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-apq8084.dtsi 
b/arch/arm/boot/dts/qcom-apq8084.dtsi
index 08214cbae16d..a33a09f6821e 100644
--- a/arch/arm/boot/dts/qcom-apq8084.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8084.dtsi
@@ -91,6 +91,20 @@
interrupts = <1 7 0xf04>;
};
 
+   clocks {
+   xo_board {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <1920>;
+   };
+
+   sleep_clk {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <32768>;
+   };
+   };
+
timer {
compatible = "arm,armv7-timer";
interrupts = <1 2 0xf08>,
diff --git a/arch/arm/boot/dts/qcom-ipq8064.dtsi 
b/arch/arm/boot/dts/qcom-ipq8064.dtsi
index fa698635eea0..2601a907947b 100644
--- a/arch/arm/boot/dts/qcom-ipq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-ipq8064.dtsi
@@ -62,6 +62,18 @@
};
 
clocks {
+   cxo_board {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <1920>;
+   };
+
+   pxo_board {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <2700>;
+   };
+
sleep_clk: sleep_clk {
compatible = "fixed-clock";
clock-frequency = <32768>;
diff --git a/arch/arm/boot/dts/qcom-msm8660.dtsi 
b/arch/arm/boot/dts/qcom-msm8660.dtsi
index e5f7f33aa467..a4b184db21d0 100644
--- a/arch/arm/boot/dts/qcom-msm8660.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8660.dtsi
@@ -42,6 +42,26 @@
interrupts = <1 9 0x304>;
};
 
+   clocks {
+   cxo_board {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <1920>;
+   };
+
+   pxo_board {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <2700>;
+   };
+
+   sleep_clk {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <32768>;
+   };
+   };
+
soc: soc {
#address-cells = <1>;
#size-cells = <1>;
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi 
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index c72cbdca3d8e..c65d0d90eed3 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -137,6 +137,20 @@
interrupts = <1 7 0xf04>;
};
 
+   clocks {
+   xo_board {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <1920>;
+   };
+
+   sleep_clk {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <32768>;
+   };
+   };
+
timer {
compatible = "arm,armv7-timer";
interrupts = <1 2 0xf08>,
-- 
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] ARM: Runtime patch udiv/sdiv instructions into __aeabi_{u}idiv()

2016-01-04 Thread Stephen Boyd
On 12/11, Nicolas Pitre wrote:
> On Fri, 11 Dec 2015, Arnd Bergmann wrote:
> 
> > On Friday 11 December 2015 12:22:20 Nicolas Pitre wrote:
> > > Subject: [PATCH] ARM: Runtime patch udiv/sdiv instructions into 
> > > __aeabi_{u}idiv()
> > > 
> 
> Thanks.
> 
> > Before you put it in the patch tracker, I think it would be good to
> > give Stephen a chance to comment as well, since he did a lot of
> > work upfront and this obsoletes his original patch series.
> 
> Given he'll get back from vacation only after the new year, I'll put the 
> patch in the tracker now so it can go in before the next merge window.  
> 
> Stephen's series could still be relevant by extending what is done here, 
> and it requires what this patch is doing anyway for those call sites 
> that can't be substituted by a div instruction (like conditional 
> branches, tail call optimizations, etc.)
> 

I'm back from vacation now. Where have we left off on this topic?

I can update the patches to be based on this patch here and
handle the conditional branches and tail call optimization cases
by adding some safety checks like we have for the ftrace branch
patching. But I'd rather not do that work unless we all agree
that it's worthwhile pursuing it.

Is there still any concern about the benefit of patching each
call site vs. patching the functions? The micro benchmark seems
to show some theoretical improvement on cortex-a7 and I can run
it on Scorpion and Krait processors to look for any potential
benefits there, but I'm not sure of any good kernel benchmark for
this. If it will be rejected due to complexity vs. benefit
arguments I'd rather work on something else.

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


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

2015-12-02 Thread Stephen Boyd
On 11/23, Archit Taneja wrote:
> 
> 
> On 11/21/2015 1:29 AM, Rob Herring wrote:
> >+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.
> 
> We don't need specify byte_clk_src (and other xyz_clk_src clocks) via
> DT. There is a static link set up between byte_clk and byte_clk_src by
> our clock driver that never changes. We can retrieve it in the driver
> itself using clk_get_parent(byte_clk). This way we stick to only
> input clocks.
> 
> Stephen, does that sound okay?
> 

I guess so. From the DT perspective it's "correct" so sure.

It would be nice if we could use assigned-clock-parents though.
As far as I can recall that's hard because the clock tree looks
like a cyclic graph when we take a clock provider level view. The
display block consumes the byte_clk and provides the source of it
too. So if we used assigned parents we would need to wait for
both clocks to be registered with the framework before we can
reconfigure the parent of byte_clk_src to be the PLL that the
display clock outputs. Unfortunately, of_clk_set_defaults() is
called during device driver probe, which in the display driver
case would be before the PLL is registered.

My only thought there would be to make of_clk_set_defaults() wait
until both clocks are registered before it does any parent
setting. But only in the case where the assigned parents contains
a clock that is provided by the node being processed. I suppose
the simplest thing to do would be to skip it during the device
driver probe and handle it when the clk provider is registered.

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


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

2015-12-02 Thread Stephen Boyd
On 12/02, Stephen Boyd wrote:
> 
> My only thought there would be to make of_clk_set_defaults() wait
> until both clocks are registered before it does any parent
> setting. But only in the case where the assigned parents contains
> a clock that is provided by the node being processed. I suppose
> the simplest thing to do would be to skip it during the device
> driver probe and handle it when the clk provider is registered.
> 

Actually it looks like we already have the code for that.

if (clkspec.np == node && !clk_supplier)
return 0;

So assigned parents should "just work"?

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


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

2015-12-02 Thread Stephen Boyd
On 12/02, Archit Taneja wrote:
> On 12/02/2015 01:50 PM, Stephen Boyd wrote:
> >
> >My only thought there would be to make of_clk_set_defaults() wait
> >until both clocks are registered before it does any parent
> >setting. But only in the case where the assigned parents contains
> >a clock that is provided by the node being processed. I suppose
> >the simplest thing to do would be to skip it during the device
> >driver probe and handle it when the clk provider is registered.
> >
> 
> The assigned-clock-parents stuff you mentioned is needed to set a
> default link between the one of the DSI PLLs and the RCG, right? I
> just wanted to make clear if we were still discussing the same
> issue.

Yes.

> 
> From what I understand, we don't need the assigned-clock-parents stuff
> to establish a link between byte_clk_src(RCG clock) and
> byte_clk(branch clock). That's a fixed link set up by the clock
> structs provided in the gcc driver and doesn't need to be specially
> assigned, and just a
> clk_get_parent in the driver does the job there.

There's only one parent of the byte_clk and that's byte_clk_src.
So yes, there's no need to describe that in DT and
clk_get_parent() works fine.

> 
> About assigning a parent to the RCG, wouldn't that be xo by default, and
> changed by the drm/msm driver to one of the PLLs when the need arrives?
> I didn't get why we need to establish that beforehand in DT?
> 

Yes, it would be XO out of reset, but we have no idea what the
bootloader is doing. I thought the problem was that byte_clk_src
is not actually an input to the DSI device. The proposal was to
have DT specify byte_clk_src and byte_clk in the clocks array so
that byte_clk_src could be reparented to the PLL and the byte_clk
could be enabled/disabled. If we use DT to do the parent
configuring then the DSI node doesn't have the byte_clk_src in
its clocks array and thus DT is reflecting reality.

If we want to dynamically switch the parent of byte_clk_src to be
different PLLs at runtime, then yes we'll need to get the parent
of the byte_clk (which is byte_clk_src) and set the PLL as the
parent. Or we'll need to make clk_set_parent() on the byte_clk
transparently set the grand-parent to be the PLL. In that case we
may need to introduce some sort of flag like
CLK_SET_PARENT_GRANDPARENT to add this type of behavior.

I don't have a huge problem with

clk_set_parent(clk_get_parent(byte_clk), PLL)

except that this fails the abstraction test. It leaks information
about the clock tree into a driver that shouldn't need to know
that on this particular SoC there's a clock in between the PLL
and the byte_clk. Future designs may not have the intermediate
clock and then we'll need to update the driver to handle the
difference, when we could have added the flag and things would
work the same.

-- 
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] stmmac: ipq806x: Return error values instead of pointers

2015-12-02 Thread Stephen Boyd
Typically we return error pointers when we want to use those
pointers in the non-error case, but this function is just
returning error pointers or NULL for success. Change the style to
plain int to follow normal kernel coding styles.

Cc: Joachim Eastwood <manab...@gmail.com>
Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
---
 .../net/ethernet/stmicro/stmmac/dwmac-ipq806x.c| 24 ++
 1 file changed, 11 insertions(+), 13 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-ipq806x.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-ipq806x.c
index 82de68b1a452..36d3355f2fb0 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-ipq806x.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-ipq806x.c
@@ -198,19 +198,19 @@ static int ipq806x_gmac_set_speed(struct ipq806x_gmac 
*gmac, unsigned int speed)
return 0;
 }
 
-static void *ipq806x_gmac_of_parse(struct ipq806x_gmac *gmac)
+static int ipq806x_gmac_of_parse(struct ipq806x_gmac *gmac)
 {
struct device *dev = >pdev->dev;
 
gmac->phy_mode = of_get_phy_mode(dev->of_node);
if (gmac->phy_mode < 0) {
dev_err(dev, "missing phy mode property\n");
-   return ERR_PTR(-EINVAL);
+   return -EINVAL;
}
 
if (of_property_read_u32(dev->of_node, "qcom,id", >id) < 0) {
dev_err(dev, "missing qcom id property\n");
-   return ERR_PTR(-EINVAL);
+   return -EINVAL;
}
 
/* The GMACs are called 1 to 4 in the documentation, but to simplify the
@@ -219,13 +219,13 @@ static void *ipq806x_gmac_of_parse(struct ipq806x_gmac 
*gmac)
 */
if (gmac->id < 0 || gmac->id > 3) {
dev_err(dev, "invalid gmac id\n");
-   return ERR_PTR(-EINVAL);
+   return -EINVAL;
}
 
gmac->core_clk = devm_clk_get(dev, "stmmaceth");
if (IS_ERR(gmac->core_clk)) {
dev_err(dev, "missing stmmaceth clk property\n");
-   return gmac->core_clk;
+   return PTR_ERR(gmac->core_clk);
}
clk_set_rate(gmac->core_clk, 26600);
 
@@ -234,18 +234,16 @@ static void *ipq806x_gmac_of_parse(struct ipq806x_gmac 
*gmac)
   "qcom,nss-common");
if (IS_ERR(gmac->nss_common)) {
dev_err(dev, "missing nss-common node\n");
-   return gmac->nss_common;
+   return PTR_ERR(gmac->nss_common);
}
 
/* Setup the register map for the qsgmii csr registers */
gmac->qsgmii_csr = syscon_regmap_lookup_by_phandle(dev->of_node,
   "qcom,qsgmii-csr");
-   if (IS_ERR(gmac->qsgmii_csr)) {
+   if (IS_ERR(gmac->qsgmii_csr))
dev_err(dev, "missing qsgmii-csr node\n");
-   return gmac->qsgmii_csr;
-   }
 
-   return NULL;
+   return PTR_ERR_OR_ZERO(gmac->qsgmii_csr);
 }
 
 static void ipq806x_gmac_fix_mac_speed(void *priv, unsigned int speed)
@@ -262,7 +260,7 @@ static int ipq806x_gmac_probe(struct platform_device *pdev)
struct device *dev = >dev;
struct ipq806x_gmac *gmac;
int val;
-   void *err;
+   int err;
 
val = stmmac_get_platform_resources(pdev, _res);
if (val)
@@ -279,9 +277,9 @@ static int ipq806x_gmac_probe(struct platform_device *pdev)
gmac->pdev = pdev;
 
err = ipq806x_gmac_of_parse(gmac);
-   if (IS_ERR(err)) {
+   if (err) {
dev_err(dev, "device tree parsing error\n");
-   return PTR_ERR(err);
+   return err;
}
 
regmap_write(gmac->qsgmii_csr, QSGMII_PCS_CAL_LCKDT_CTL,
-- 
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 v8 11/13] clk: qcom: gdsc: Use PM clocks to control gdsc clocks

2015-12-01 Thread Stephen Boyd
On 11/27, Rajendra Nayak wrote:
> >
> > I'm lost. I was hoping we could just make up a clkspec on the
> > stack and pass it over to of_clk_get_from_provider() without
> > having to go through the np of the client device. The point being
> > to avoid forcing this code from knowing about the consumer
> > binding or connection name choice for each device. Instead, it
> > assumes that it's a #clock-cells=<1> binding and gets the clocks
> > by passing the 1 cell data without calling
> > of_parse_phandle_with_args().
> >
> > Now, one downside of that approach is that it's DT centric (also
> > of_clk_get_from_provider() is not an exported symbol yet). So I'm
> > really starting to lean towards exposing __clk_create_clk() (or
> > some better named "provider" function) that will allow clk
> > providers to turn their clk_hw structure into a struct clk
> > pointer. That avoids the DT centric design, and avoids binding
> > the provider to the connection ids too.
> 
> Stephen, I started to relook at these patches, avoiding the DT centric
> design and implementing a clk helper API as you suggested above.
> 
> While this would work for GDSCs with just one device, its hard to scale
> if we ever run into GDSCs with multiple devices (In which case you
> need to know which device within the GDSC needs which clocks)

Why? The GDSC should know which clocks it's forcing on and off
and it shouldn't need to care which devices are consuming those
clocks. The GDSC structure would have a bunch of clk_hw pointers
that it could convert into struct clk pointer to do clk consumer
API things as needed.

Maybe I'm missing something? If we're trying to take away clock
control from our device drivers and hide that in SoC glue code
(something we almost have to do so that the ordering of clocks
vs. GDSC enable isn't wrong), then that isn't a GDSC, but some
linux genpd concept. I imagine it would be a genpd per hw block
(or device driver really) and then those genpds would be children
of a larger GDSC genpd. For example, two hw blocks could have
separate genpds for their clock control so that we can hide the
clock on/off from the drivers, and then those are children of a
single GDSC backed genpd for the physical domain they both reside
in. If the GDSC domain and the sw domain need to control the same
clocks, everything will work because we reference count
appropriately.

The downside of this all is that we're putting a bunch of
knowledge about which drivers are using which clocks into the SoC
clock driver. But I don't know where else we would put this if we
want to hide these details from the driver authors. The only
other option is to do it with DT, and the whole DT ABI there
scares me enough to want to try and make it work in the SoC clock
driver for now.

> 
> Do you think its a fair limitation (one device per gdsc) to live with?
> because I can't seem to figure how a non DT centric design would otherwise
> work.

No. The SMMU use case on a-family has SMMU and the hw block
(video, gpu, display) that uses it within the same GDSC power
domain.

-- 
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 v3 0/3] Remove ARCH_MSM* configs

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

Changes from v2:
 * Renamed config in patch 1 to QCOM_ARCH_A_FAMILY to be less confusing

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

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

 arch/arm/Makefile   |  3 +--
 arch/arm/configs/qcom_defconfig |  1 +
 arch/arm/mach-qcom/Kconfig  | 17 +
 3 files changed, 11 insertions(+), 10 deletions(-)

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

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


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

2015-11-30 Thread Stephen Boyd
Enable this config in the defconfig so that we can delete the
selection logic surrounding it that exists in mach-qcom/Kconfig.

Acked-by: Arnd Bergmann <a...@arndb.de>
Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
---
 arch/arm/configs/qcom_defconfig | 1 +
 1 file changed, 1 insertion(+)

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

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


[PATCH v2 0/5] Add support for MSM8996 clock controllers

2015-11-30 Thread Stephen Boyd
These patches add support for the global and multimedia clock controllers
found on MSM8996 devices. The first patch allows us to implement a
"power of two" divider of different widths with a table based divider.
The second patch adds support for Alpha PLLs and the 3rd and 5th patches
add support for the two clock controllers. The fourth patch is
a new type of clock ops for the graphics clock that does some custom
ping-pong between different PLLs when switching graphics frequencies.

Changes from v1:
 * Added some missing clocks in gcc and mmcc drivers
 * Updated PLL settings in mmcc

Stephen Boyd (5):
  clk: divider: Cap table divider values to 'width' member
  clk: qcom: Add Alpha PLL support
  clk: qcom: Add MSM8996 Global Clock Control (GCC) driver
  clk: qcom: Add gfx3d ping-pong PLL frequency switching
  clk: qcom: Add MSM8996 Multimedia Clock Controller (MMCC) driver

 .../devicetree/bindings/clock/qcom,gcc.txt |1 +
 .../devicetree/bindings/clock/qcom,mmcc.txt|1 +
 drivers/clk/clk-divider.c  |9 +-
 drivers/clk/qcom/Kconfig   |   17 +
 drivers/clk/qcom/Makefile  |3 +
 drivers/clk/qcom/clk-alpha-pll.c   |  355 ++
 drivers/clk/qcom/clk-alpha-pll.h   |   57 +
 drivers/clk/qcom/clk-rcg.h |1 +
 drivers/clk/qcom/clk-rcg2.c|   87 +
 drivers/clk/qcom/gcc-msm8996.c | 3422 
 drivers/clk/qcom/mmcc-msm8996.c| 3217 ++
 include/dt-bindings/clock/qcom,gcc-msm8996.h   |  339 ++
 include/dt-bindings/clock/qcom,mmcc-msm8996.h  |  285 ++
 13 files changed, 7790 insertions(+), 4 deletions(-)
 create mode 100644 drivers/clk/qcom/clk-alpha-pll.c
 create mode 100644 drivers/clk/qcom/clk-alpha-pll.h
 create mode 100644 drivers/clk/qcom/gcc-msm8996.c
 create mode 100644 drivers/clk/qcom/mmcc-msm8996.c
 create mode 100644 include/dt-bindings/clock/qcom,gcc-msm8996.h
 create mode 100644 include/dt-bindings/clock/qcom,mmcc-msm8996.h

-- 
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] clk: qcom: Add MSM8996 Multimedia Clock Controller (MMCC) driver

2015-11-30 Thread Stephen Boyd
Add a driver for the multimedia clock controller found on MSM8996
based devices. This should allow most multimedia device drivers
to probe and control their clocks.

Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
---
 .../devicetree/bindings/clock/qcom,mmcc.txt|1 +
 drivers/clk/qcom/Kconfig   |9 +
 drivers/clk/qcom/Makefile  |1 +
 drivers/clk/qcom/mmcc-msm8996.c| 3217 
 include/dt-bindings/clock/qcom,mmcc-msm8996.h  |  285 ++
 5 files changed, 3513 insertions(+)
 create mode 100644 drivers/clk/qcom/mmcc-msm8996.c
 create mode 100644 include/dt-bindings/clock/qcom,mmcc-msm8996.h

diff --git a/Documentation/devicetree/bindings/clock/qcom,mmcc.txt 
b/Documentation/devicetree/bindings/clock/qcom,mmcc.txt
index 34e7614d5074..8b0f7841af8d 100644
--- a/Documentation/devicetree/bindings/clock/qcom,mmcc.txt
+++ b/Documentation/devicetree/bindings/clock/qcom,mmcc.txt
@@ -9,6 +9,7 @@ Required properties :
"qcom,mmcc-msm8660"
"qcom,mmcc-msm8960"
"qcom,mmcc-msm8974"
+   "qcom,mmcc-msm8996"
 
 - reg : shall contain base register location and length
 - #clock-cells : shall contain 1
diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
index fb2b499c647d..b552eceec2be 100644
--- a/drivers/clk/qcom/Kconfig
+++ b/drivers/clk/qcom/Kconfig
@@ -114,3 +114,12 @@ config MSM_GCC_8996
  Support for the global clock controller on msm8996 devices.
  Say Y if you want to use peripheral devices such as UART, SPI,
  i2c, USB, UFS, SD/eMMC, PCIe, etc.
+
+config MSM_MMCC_8996
+   tristate "MSM8996 Multimedia Clock Controller"
+   select MSM_GCC_8996
+   depends on COMMON_CLK_QCOM
+   help
+ Support for the multimedia clock controller on msm8996 devices.
+ Say Y if you want to support multimedia devices such as display,
+ graphics, video encode/decode, camera, etc.
diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index 42dca6799414..dc4280b85db1 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -24,3 +24,4 @@ obj-$(CONFIG_MSM_GCC_8974) += gcc-msm8974.o
 obj-$(CONFIG_MSM_GCC_8996) += gcc-msm8996.o
 obj-$(CONFIG_MSM_MMCC_8960) += mmcc-msm8960.o
 obj-$(CONFIG_MSM_MMCC_8974) += mmcc-msm8974.o
+obj-$(CONFIG_MSM_MMCC_8996) += mmcc-msm8996.o
diff --git a/drivers/clk/qcom/mmcc-msm8996.c b/drivers/clk/qcom/mmcc-msm8996.c
new file mode 100644
index ..064f3eaa39d0
--- /dev/null
+++ b/drivers/clk/qcom/mmcc-msm8996.c
@@ -0,0 +1,3217 @@
+/*x
+ * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "common.h"
+#include "clk-regmap.h"
+#include "clk-regmap-divider.h"
+#include "clk-alpha-pll.h"
+#include "clk-rcg.h"
+#include "clk-branch.h"
+#include "reset.h"
+
+#define F(f, s, h, m, n) { (f), (s), (2 * (h) - 1), (m), (n) }
+
+enum {
+   P_XO,
+   P_MMPLL0,
+   P_GPLL0,
+   P_GPLL0_DIV,
+   P_MMPLL1,
+   P_MMPLL9,
+   P_MMPLL2,
+   P_MMPLL8,
+   P_MMPLL3,
+   P_DSI0PLL,
+   P_DSI1PLL,
+   P_MMPLL5,
+   P_HDMIPLL,
+   P_DSI0PLL_BYTE,
+   P_DSI1PLL_BYTE,
+   P_MMPLL4,
+};
+
+static const struct parent_map mmss_xo_hdmi_map[] = {
+   { P_XO, 0 },
+   { P_HDMIPLL, 1 }
+};
+
+static const char * const mmss_xo_hdmi[] = {
+   "xo",
+   "hdmipll"
+};
+
+static const struct parent_map mmss_xo_dsi0pll_dsi1pll_map[] = {
+   { P_XO, 0 },
+   { P_DSI0PLL, 1 },
+   { P_DSI1PLL, 2 }
+};
+
+static const char * const mmss_xo_dsi0pll_dsi1pll[] = {
+   "xo",
+   "dsi0pll",
+   "dsi1pll"
+};
+
+static const struct parent_map mmss_xo_gpll0_gpll0_div_map[] = {
+   { P_XO, 0 },
+   { P_GPLL0, 5 },
+   { P_GPLL0_DIV, 6 }
+};
+
+static const char * const mmss_xo_gpll0_gpll0_div[] = {
+   "xo",
+   "gpll0",
+   "gpll0_div"
+};
+
+static const struct parent_map mmss_xo_dsibyte_map[] = {
+   { P_XO, 0 },
+   { P_DSI0PLL_BYTE, 1 },
+   { P_DSI1PLL_BYTE, 2 }
+};
+
+static const char * co

[PATCH v2 4/5] clk: qcom: Add gfx3d ping-pong PLL frequency switching

2015-11-30 Thread Stephen Boyd
The GPU clocks on msm8996 have three dedicated PLLs, MMPLL2,
MMPLL8, and MMPLL9. We leave MMPLL9 at the maximum speed (624
MHz), and we use MMPLL2 and MMPLL8 for the other frequencies. To
make switching frequencies faster, we ping-pong between MMPLL2
and MMPLL8 when we're switching between frequencies that aren't
the maximum. Implement custom rcg clk ops for this type of
frequency switching.

Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
---
 drivers/clk/qcom/clk-rcg.h  |  1 +
 drivers/clk/qcom/clk-rcg2.c | 87 +
 2 files changed, 88 insertions(+)

diff --git a/drivers/clk/qcom/clk-rcg.h b/drivers/clk/qcom/clk-rcg.h
index 4b1e94bdf29e..b904c335cda4 100644
--- a/drivers/clk/qcom/clk-rcg.h
+++ b/drivers/clk/qcom/clk-rcg.h
@@ -178,5 +178,6 @@ extern const struct clk_ops clk_edp_pixel_ops;
 extern const struct clk_ops clk_byte_ops;
 extern const struct clk_ops clk_byte2_ops;
 extern const struct clk_ops clk_pixel_ops;
+extern const struct clk_ops clk_gfx3d_ops;
 
 #endif
diff --git a/drivers/clk/qcom/clk-rcg2.c b/drivers/clk/qcom/clk-rcg2.c
index b544bb302f79..a071bba8018c 100644
--- a/drivers/clk/qcom/clk-rcg2.c
+++ b/drivers/clk/qcom/clk-rcg2.c
@@ -723,3 +723,90 @@ const struct clk_ops clk_pixel_ops = {
.determine_rate = clk_pixel_determine_rate,
 };
 EXPORT_SYMBOL_GPL(clk_pixel_ops);
+
+static int clk_gfx3d_determine_rate(struct clk_hw *hw,
+   struct clk_rate_request *req)
+{
+   struct clk_rate_request parent_req = { };
+   struct clk_hw *p2, *p8, *p9, *xo;
+   unsigned long p9_rate;
+   int ret;
+
+   xo = clk_hw_get_parent_by_index(hw, 0);
+   if (req->rate == clk_hw_get_rate(xo)) {
+   req->best_parent_hw = xo;
+   return 0;
+   }
+
+   p9 = clk_hw_get_parent_by_index(hw, 2);
+   p2 = clk_hw_get_parent_by_index(hw, 3);
+   p8 = clk_hw_get_parent_by_index(hw, 4);
+
+   /* PLL9 is a fixed rate PLL */
+   p9_rate = clk_hw_get_rate(p9);
+
+   parent_req.rate = req->rate = min(req->rate, p9_rate);
+   if (req->rate == p9_rate) {
+   req->rate = req->best_parent_rate = p9_rate;
+   req->best_parent_hw = p9;
+   return 0;
+   }
+
+   if (req->best_parent_hw == p9) {
+   /* Are we going back to a previously used rate? */
+   if (clk_hw_get_rate(p8) == req->rate)
+   req->best_parent_hw = p8;
+   else
+   req->best_parent_hw = p2;
+   } else if (req->best_parent_hw == p8) {
+   req->best_parent_hw = p2;
+   } else {
+   req->best_parent_hw = p8;
+   }
+
+   ret = __clk_determine_rate(req->best_parent_hw, _req);
+   if (ret)
+   return ret;
+
+   req->rate = req->best_parent_rate = parent_req.rate;
+
+   return 0;
+}
+
+static int clk_gfx3d_set_rate_and_parent(struct clk_hw *hw, unsigned long rate,
+   unsigned long parent_rate, u8 index)
+{
+   struct clk_rcg2 *rcg = to_clk_rcg2(hw);
+   u32 cfg;
+   int ret;
+
+   /* Just mux it, we don't use the division or m/n hardware */
+   cfg = rcg->parent_map[index].cfg << CFG_SRC_SEL_SHIFT;
+   ret = regmap_write(rcg->clkr.regmap, rcg->cmd_rcgr + CFG_REG, cfg);
+   if (ret)
+   return ret;
+
+   return update_config(rcg);
+}
+
+static int clk_gfx3d_set_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long parent_rate)
+{
+   /*
+* We should never get here; clk_gfx3d_determine_rate() should always
+* make us use a different parent than what we're currently using, so
+* clk_gfx3d_set_rate_and_parent() should always be called.
+*/
+   return 0;
+}
+
+const struct clk_ops clk_gfx3d_ops = {
+   .is_enabled = clk_rcg2_is_enabled,
+   .get_parent = clk_rcg2_get_parent,
+   .set_parent = clk_rcg2_set_parent,
+   .recalc_rate = clk_rcg2_recalc_rate,
+   .set_rate = clk_gfx3d_set_rate,
+   .set_rate_and_parent = clk_gfx3d_set_rate_and_parent,
+   .determine_rate = clk_gfx3d_determine_rate,
+};
+EXPORT_SYMBOL_GPL(clk_gfx3d_ops);
-- 
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 2/5] clk: qcom: Add Alpha PLL support

2015-11-30 Thread Stephen Boyd
Add support for configuring rates of, enabling, and disabling
Alpha PLLs. This is sufficient for the types of PLLs found in
the global and multimedia clock controllers.

Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
---
 drivers/clk/qcom/Makefile|   1 +
 drivers/clk/qcom/clk-alpha-pll.c | 355 +++
 drivers/clk/qcom/clk-alpha-pll.h |  57 +++
 3 files changed, 413 insertions(+)
 create mode 100644 drivers/clk/qcom/clk-alpha-pll.c
 create mode 100644 drivers/clk/qcom/clk-alpha-pll.h

diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index fe6252349e55..472200040788 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -2,6 +2,7 @@ obj-$(CONFIG_COMMON_CLK_QCOM) += clk-qcom.o
 
 clk-qcom-y += common.o
 clk-qcom-y += clk-regmap.o
+clk-qcom-y += clk-alpha-pll.o
 clk-qcom-y += clk-pll.o
 clk-qcom-y += clk-rcg.o
 clk-qcom-y += clk-rcg2.o
diff --git a/drivers/clk/qcom/clk-alpha-pll.c b/drivers/clk/qcom/clk-alpha-pll.c
new file mode 100644
index ..e6a03eaf7a93
--- /dev/null
+++ b/drivers/clk/qcom/clk-alpha-pll.c
@@ -0,0 +1,355 @@
+/*
+ * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "clk-alpha-pll.h"
+
+#define PLL_MODE   0x00
+# define PLL_OUTCTRL   BIT(0)
+# define PLL_BYPASSNL  BIT(1)
+# define PLL_RESET_N   BIT(2)
+# define PLL_LOCK_COUNT_SHIFT  8
+# define PLL_LOCK_COUNT_MASK   0x3f
+# define PLL_BIAS_COUNT_SHIFT  14
+# define PLL_BIAS_COUNT_MASK   0x3f
+# define PLL_VOTE_FSM_ENA  BIT(20)
+# define PLL_VOTE_FSM_RESETBIT(21)
+# define PLL_ACTIVE_FLAG   BIT(30)
+# define PLL_LOCK_DET  BIT(31)
+
+#define PLL_L_VAL  0x04
+#define PLL_ALPHA_VAL  0x08
+#define PLL_ALPHA_VAL_U0x0c
+
+#define PLL_USER_CTL   0x10
+# define PLL_POST_DIV_SHIFT8
+# define PLL_POST_DIV_MASK 0xf
+# define PLL_ALPHA_EN  BIT(24)
+# define PLL_VCO_SHIFT 20
+# define PLL_VCO_MASK  0x3
+
+#define PLL_USER_CTL_U 0x14
+
+#define PLL_CONFIG_CTL 0x18
+#define PLL_TEST_CTL   0x1c
+#define PLL_TEST_CTL_U 0x20
+#define PLL_STATUS 0x24
+
+/*
+ * Even though 40 bits are present, use only 32 for ease of calculation.
+ */
+#define ALPHA_REG_BITWIDTH 40
+#define ALPHA_BITWIDTH 32
+
+#define to_clk_alpha_pll(_hw) container_of(to_clk_regmap(_hw), \
+  struct clk_alpha_pll, clkr)
+
+#define to_clk_alpha_pll_postdiv(_hw) container_of(to_clk_regmap(_hw), \
+  struct clk_alpha_pll_postdiv, clkr)
+
+static int wait_for_pll(struct clk_alpha_pll *pll)
+{
+   u32 val, mask, off;
+   int count;
+   int ret;
+   const char *name = clk_hw_get_name(>clkr.hw);
+
+   off = pll->offset;
+   ret = regmap_read(pll->clkr.regmap, off + PLL_MODE, );
+   if (ret)
+   return ret;
+
+   if (val & PLL_VOTE_FSM_ENA)
+   mask = PLL_ACTIVE_FLAG;
+   else
+   mask = PLL_LOCK_DET;
+
+   /* Wait for pll to enable. */
+   for (count = 100; count > 0; count--) {
+   ret = regmap_read(pll->clkr.regmap, off + PLL_MODE, );
+   if (ret)
+   return ret;
+   if ((val & mask) == mask)
+   return 0;
+
+   udelay(1);
+   }
+
+   WARN(1, "%s didn't enable after voting for it!\n", name);
+   return -ETIMEDOUT;
+}
+
+static int clk_alpha_pll_enable(struct clk_hw *hw)
+{
+   int ret;
+   struct clk_alpha_pll *pll = to_clk_alpha_pll(hw);
+   u32 val, mask, off;
+
+   off = pll->offset;
+
+   mask = PLL_OUTCTRL | PLL_RESET_N | PLL_BYPASSNL;
+   ret = regmap_read(pll->clkr.regmap, off + PLL_MODE, );
+   if (ret)
+   return ret;
+
+   /* If in FSM mode, just vote for it */
+   if (val & PLL_VOTE_FSM_ENA) {
+   ret = clk_enable_regmap(hw);
+   if (ret)
+   return ret;
+   return wait_for_pll(pll);
+   }
+
+   /* Skip if already enabled */
+   if ((val & mask) == mask)
+   return 0;
+
+   ret = regmap_update_bits(pll->clkr.regmap, off + PLL_MODE,
+PLL_BYPASSNL, PLL_BYPASSNL);
+   if (ret)
+   

[PATCH v2 1/5] clk: divider: Cap table divider values to 'width' member

2015-11-30 Thread Stephen Boyd
When we use a clk divider with a divider table, we limit the
maximum divider value in divider_get_val() to the
div_mask(width), but when we calculate the divider in
divider_round_rate() we don't consider that the maximum divider
may be limited by the width. Pass the width along to
_get_table_maxdiv() so that we only return the maximum divider
that is valid. This is useful for clocks that want to share the
same divider table while limiting the available dividers to some
subset of the table depending on the width of the bitfield.

Cc: Rajendra Nayak <rna...@codeaurora.org>
Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
---
 drivers/clk/clk-divider.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index 3ace102a2a0a..ded3ff4b91b9 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -32,13 +32,14 @@
 
 #define div_mask(width)((1 << (width)) - 1)
 
-static unsigned int _get_table_maxdiv(const struct clk_div_table *table)
+static unsigned int _get_table_maxdiv(const struct clk_div_table *table,
+ u8 width)
 {
-   unsigned int maxdiv = 0;
+   unsigned int maxdiv = 0, mask = div_mask(width);
const struct clk_div_table *clkt;
 
for (clkt = table; clkt->div; clkt++)
-   if (clkt->div > maxdiv)
+   if (clkt->div > maxdiv && clkt->val <= mask)
maxdiv = clkt->div;
return maxdiv;
 }
@@ -62,7 +63,7 @@ static unsigned int _get_maxdiv(const struct clk_div_table 
*table, u8 width,
if (flags & CLK_DIVIDER_POWER_OF_TWO)
return 1 << div_mask(width);
if (table)
-   return _get_table_maxdiv(table);
+   return _get_table_maxdiv(table, width);
return div_mask(width) + 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


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

2015-11-30 Thread Stephen Boyd
On 11/26, Rajendra Nayak wrote:
> Some gdscs might be controlled via voting registers and might not
> really disable when the kernel intends to disable them (due to other
> votes keeping them enabled)
> Mark these gdscs with a flag for we do not check/wait on a disable
> status for these gdscs within the kernel disable callback.
> 
> Signed-off-by: Rajendra Nayak 
> ---
>  drivers/clk/qcom/gcc-msm8996.c  |  4 
>  drivers/clk/qcom/gdsc.c |  4 
>  drivers/clk/qcom/gdsc.h | 15 ---
>  drivers/clk/qcom/mmcc-msm8996.c |  3 +++
>  4 files changed, 19 insertions(+), 7 deletions(-)

We should have this patch before adding the gdscs that use it.
Prevents any bisect hole.

>  static struct gdsc usb30_gdsc = {
> diff --git a/drivers/clk/qcom/gdsc.c b/drivers/clk/qcom/gdsc.c
> index fb2e43c..984537f 100644
> --- a/drivers/clk/qcom/gdsc.c
> +++ b/drivers/clk/qcom/gdsc.c
> @@ -65,6 +65,10 @@ static int gdsc_toggle_logic(struct gdsc *sc, bool en)
>   if (ret)
>   return ret;
>  
> + /* If disabling votable gdscs, don't poll on status */
> + if ((sc->flags & VOTABLE) && !en)
> + return 0;
> +

There's an explicit delay of 100uS on the disable path for
votable gdscs in the downstream code. I don't see that here.

>   timeout = jiffies + usecs_to_jiffies(TIMEOUT_US);
>  
>   if (sc->gds_hw_ctrl) {
> diff --git a/drivers/clk/qcom/gdsc.h b/drivers/clk/qcom/gdsc.h
> index 66a43be..91cbb09 100644
> --- a/drivers/clk/qcom/gdsc.h
> +++ b/drivers/clk/qcom/gdsc.h
> @@ -20,13 +20,6 @@
>  struct regmap;
>  struct reset_controller_dev;
>  
> -/* Powerdomain allowable state bitfields */
> -#define PWRSTS_OFF   BIT(0)
> -#define PWRSTS_RET   BIT(1)
> -#define PWRSTS_ONBIT(2)
> -#define PWRSTS_OFF_ON(PWRSTS_OFF | PWRSTS_ON)
> -#define PWRSTS_RET_ON(PWRSTS_RET | PWRSTS_ON)
> -
>  /**
>   * struct gdsc - Globally Distributed Switch Controller
>   * @pd: generic power domain
> @@ -49,6 +42,14 @@ struct gdsc {
>   unsigned int*cxcs;
>   unsigned intcxc_count;
>   const u8pwrsts;
> +/* Powerdomain allowable state bitfields */
> +#define PWRSTS_OFF   BIT(0)
> +#define PWRSTS_RET   BIT(1)
> +#define PWRSTS_ONBIT(2)
> +#define PWRSTS_OFF_ON(PWRSTS_OFF | PWRSTS_ON)
> +#define PWRSTS_RET_ON(PWRSTS_RET | PWRSTS_ON)

Yes! We should have done this already. I guess I'm ok combining
it with this patch.

> + const u8flags;
> +#define VOTABLE  BIT(0)
>   struct reset_controller_dev *rcdev;
>   unsigned int*resets;
>   unsigned intreset_count;

-- 
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/6] clk: qcom: gdsc: Add support for gdscs with gds hw controller

2015-11-30 Thread Stephen Boyd
On 11/26, Rajendra Nayak wrote:
> @@ -58,30 +58,34 @@ static int gdsc_toggle_logic(struct gdsc *sc, bool en)
>  {
>   int ret;
>   u32 val = en ? 0 : SW_COLLAPSE_MASK;
> - u32 check = en ? PWR_ON_MASK : 0;
>   unsigned long timeout;
> + unsigned int status_reg = sc->gdscr;
>  
>   ret = regmap_update_bits(sc->regmap, sc->gdscr, SW_COLLAPSE_MASK, val);
>   if (ret)
>   return ret;
>  
>   timeout = jiffies + usecs_to_jiffies(TIMEOUT_US);
> - do {
> - ret = regmap_read(sc->regmap, sc->gdscr, );
> - if (ret)
> - return ret;
>  
> - if ((val & PWR_ON_MASK) == check)
> + if (sc->gds_hw_ctrl) {
> + status_reg = sc->gds_hw_ctrl;
> + /*
> +  * The gds hw controller asserts/de-asserts the status bit soon
> +  * after it receives a power on/off request from a master.
> +  * The controller then takes around 8 xo cycles to start its internal
> +  * state machine and update the status bit. During this time, the
> +  * status bit does not reflect the true status of the core.
> +  * Add a delay of 1 us between writing to the SW_COLLAPSE bit and
> +  * polling the status bit
> +  */

Please indent this correctly to the udelay indent level.

> + udelay(1);
> + }
> +
> + do {
> + if (gdsc_is_enabled(sc, status_reg) == en)
>   return 0;
>   } while (time_before(jiffies, timeout));
>  
> - ret = regmap_read(sc->regmap, sc->gdscr, );
> - if (ret)
> - return ret;
> -
> - if ((val & PWR_ON_MASK) == check)
> - return 0;
> -

This opens a bug where we timeout and then the status bit changes
after the timeout. One more check is good and should stay. We
could also change this to ktime instead of jiffies. That would be
a good improvement.

>   return -ETIMEDOUT;
>  }
>  
> @@ -165,6 +169,7 @@ static int gdsc_init(struct gdsc *sc)
>  {
>   u32 mask, val;
>   int on, ret;
> + unsigned int reg;
>  
>   /*
>* Disable HW trigger: collapse/restore occur based on registers writes.
> @@ -185,7 +190,8 @@ static int gdsc_init(struct gdsc *sc)
>   return ret;
>   }
>  
> - on = gdsc_is_enabled(sc);
> + reg = sc->gds_hw_ctrl ? sc->gds_hw_ctrl : sc->gdscr;
> + on = gdsc_is_enabled(sc, reg);

If the gdsc is voteable, then we need to make sure that the vote
is from us when we boot up. Otherwise the kernel may think that
the gdsc is enabled, but it gets turned off by some other master
later on. I don't know if this causes some sort of problem for
the power domain framework, but we can't rely on the status bit
unless we're sure that we've actually set the register to enable
it. In the normal enable/disable path we'll always know we set
the register, so this really only matters once when we boot up.

-- 
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 v3 1/3] ARM: qcom: Make an option for qcom 'a-family' platforms

2015-11-30 Thread Stephen Boyd
We want to remove the ARCH_MSM* configs in mach-qcom/Kconfig
because they are proxy configs for selecting the right
clocksource driver and adjusting the text offset and there is no
difference between ARCH_MSM8X60 and ARCH_MSM8960 anymore.
Furthermore, there aren't configs for all the SoCs supported by
the mainline kernel, leading to confusion about which SoCs are
supported.

So, add a new config that covers all the platforms that use the
qcom clocksource driver and need the 2MB text offset adjustment
and make it def_bool y so that the defconfigs keep working
properly.

Cc: Arnd Bergmann <a...@arndb.de>
Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
---
 arch/arm/Makefile  |  3 +--
 arch/arm/mach-qcom/Kconfig | 13 +
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 2c2b28ee4811..dd5799dbcf26 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -148,8 +148,7 @@ textofs-$(CONFIG_PM_H1940)  := 0x00108000
 ifeq ($(CONFIG_ARCH_SA1100),y)
 textofs-$(CONFIG_SA) := 0x00208000
 endif
-textofs-$(CONFIG_ARCH_MSM8X60) := 0x00208000
-textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000
+textofs-$(CONFIG_ARCH_QCOM_A_FAMILY) := 0x00208000
 textofs-$(CONFIG_ARCH_AXXIA) := 0x00308000
 
 # Machine directory name.  This list is sorted alphanumerically
diff --git a/arch/arm/mach-qcom/Kconfig b/arch/arm/mach-qcom/Kconfig
index 2256cd1e25d1..230c7e8a32fb 100644
--- a/arch/arm/mach-qcom/Kconfig
+++ b/arch/arm/mach-qcom/Kconfig
@@ -10,6 +10,19 @@ menuconfig ARCH_QCOM
 
 if ARCH_QCOM
 
+config ARCH_QCOM_A_FAMILY
+   bool "Support a-family chipsets (msm8660, msm8960, apq8064)"
+   default y
+   select CLKSRC_QCOM
+   help
+ Select this option if you want to support a-family platforms.
+
+ A-family includes all Snapdragon S1/S2/S3/S4 chips before 2013,
+ up to the MSM8x60 and APQ8064 SoCs.
+
+ B-family includes all Snapdragon 2xx/4xx/6xx/8xx models starting
+ in 2013 with the MSM8x74 SoC.
+
 config ARCH_MSM8X60
bool "Enable support for MSM8X60"
select CLKSRC_QCOM
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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


Re: arm64: dts: qcom: Add apq8096 dragonboard dts skeletons

2015-11-30 Thread Stephen Boyd
On 11/26, Rajendra Nayak wrote:
> Add new dtsi and dts files for the apq8096 dragonboards with just
> a serial device used as debug console
> 
> Signed-off-by: Rajendra Nayak 
> ---
> Patch applies on top of Stephens' patches to add msm8996 dtsi
> https://lkml.org/lkml/2015/11/17/955
> 
>  arch/arm64/boot/dts/qcom/Makefile |  2 +-
>  arch/arm64/boot/dts/qcom/apq8096-dragonboard.dts  | 21 
>  arch/arm64/boot/dts/qcom/apq8096-dragonboard.dtsi | 30 
> +++
>  3 files changed, 52 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm64/boot/dts/qcom/apq8096-dragonboard.dts
>  create mode 100644 arch/arm64/boot/dts/qcom/apq8096-dragonboard.dtsi
> 
> diff --git a/arch/arm64/boot/dts/qcom/Makefile 
> b/arch/arm64/boot/dts/qcom/Makefile
> index fa1f661..bd992ef 100644
> --- a/arch/arm64/boot/dts/qcom/Makefile
> +++ b/arch/arm64/boot/dts/qcom/Makefile
> @@ -1,5 +1,5 @@
>  dtb-$(CONFIG_ARCH_QCOM)  += apq8016-sbc.dtb msm8916-mtp.dtb
> -dtb-$(CONFIG_ARCH_QCOM)  += msm8996-mtp.dtb
> +dtb-$(CONFIG_ARCH_QCOM)  += msm8996-mtp.dtb apq8096-dragonboard.dtb

We should move to one dtb per line in this file. Other platforms
are doing the same thing.

-- 
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] ARM: defconfig: qcom: Enable SSBI drivers

2015-11-30 Thread Stephen Boyd
Enable some ssbi drivers present on msm8660, msm8960 and apq8064
devices so that we fully exercise the devices present in the dts
files.

Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
---
 arch/arm/configs/qcom_defconfig | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/configs/qcom_defconfig b/arch/arm/configs/qcom_defconfig
index 39e269088b34..195be8b9f172 100644
--- a/arch/arm/configs/qcom_defconfig
+++ b/arch/arm/configs/qcom_defconfig
@@ -80,10 +80,13 @@ CONFIG_USB_USBNET=y
 CONFIG_INPUT_EVDEV=y
 # CONFIG_KEYBOARD_ATKBD is not set
 CONFIG_KEYBOARD_GPIO=y
+CONFIG_KEYBOARD_PMIC8XXX=y
 # CONFIG_MOUSE_PS2 is not set
 CONFIG_INPUT_JOYSTICK=y
 CONFIG_INPUT_TOUCHSCREEN=y
 CONFIG_INPUT_MISC=y
+CONFIG_INPUT_PM8XXX_VIBRATOR=y
+CONFIG_INPUT_PMIC8XXX_PWRKEY=y
 CONFIG_INPUT_UINPUT=y
 CONFIG_SERIO_LIBPS2=y
 # CONFIG_LEGACY_PTYS is not set
@@ -110,6 +113,7 @@ CONFIG_CHARGER_QCOM_SMBB=y
 CONFIG_POWER_RESET=y
 CONFIG_POWER_RESET_MSM=y
 CONFIG_THERMAL=y
+CONFIG_MFD_PM8921_CORE=y
 CONFIG_MFD_QCOM_RPM=y
 CONFIG_MFD_SPMI_PMIC=y
 CONFIG_REGULATOR=y
@@ -142,6 +146,7 @@ CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_PLTFM=y
 CONFIG_MMC_SDHCI_MSM=y
 CONFIG_RTC_CLASS=y
+CONFIG_RTC_DRV_PM8XXX=y
 CONFIG_DMADEVICES=y
 CONFIG_QCOM_BAM_DMA=y
 CONFIG_STAGING=y
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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


Re: arm64: dts: qcom: Add apq8096 dragonboard dts skeletons

2015-11-30 Thread Stephen Boyd
On 12/01, Rajendra Nayak wrote:
> 
> On 12/01/2015 05:18 AM, Stephen Boyd wrote:
> > On 11/26, Rajendra Nayak wrote:
> >> Add new dtsi and dts files for the apq8096 dragonboards with just
> >> a serial device used as debug console
> >>
> >> Signed-off-by: Rajendra Nayak <rna...@codeaurora.org>
> >> ---
> >> Patch applies on top of Stephens' patches to add msm8996 dtsi
> >> https://lkml.org/lkml/2015/11/17/955
> >>
> >>  arch/arm64/boot/dts/qcom/Makefile |  2 +-
> >>  arch/arm64/boot/dts/qcom/apq8096-dragonboard.dts  | 21 
> >>  arch/arm64/boot/dts/qcom/apq8096-dragonboard.dtsi | 30 
> >> +++
> >>  3 files changed, 52 insertions(+), 1 deletion(-)
> >>  create mode 100644 arch/arm64/boot/dts/qcom/apq8096-dragonboard.dts
> >>  create mode 100644 arch/arm64/boot/dts/qcom/apq8096-dragonboard.dtsi
> >>
> >> diff --git a/arch/arm64/boot/dts/qcom/Makefile 
> >> b/arch/arm64/boot/dts/qcom/Makefile
> >> index fa1f661..bd992ef 100644
> >> --- a/arch/arm64/boot/dts/qcom/Makefile
> >> +++ b/arch/arm64/boot/dts/qcom/Makefile
> >> @@ -1,5 +1,5 @@
> >>  dtb-$(CONFIG_ARCH_QCOM)   += apq8016-sbc.dtb msm8916-mtp.dtb
> >> -dtb-$(CONFIG_ARCH_QCOM)   += msm8996-mtp.dtb
> >> +dtb-$(CONFIG_ARCH_QCOM)   += msm8996-mtp.dtb apq8096-dragonboard.dtb
> > 
> > We should move to one dtb per line in this file. Other platforms
> > are doing the same thing.
> 
> Sure, will repost with the change. I just saw the 8916/8016 ones were all in
> a single line so did the same.
> 

Yeah we should probably change the 8916 one too. Make everything
the same.

-- 
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/6] clk: qcom: gdsc: Add support for gdscs with gds hw controller

2015-11-30 Thread Stephen Boyd
On 12/01, Rajendra Nayak wrote:
> 
> On 12/01/2015 07:52 AM, Stephen Boyd wrote:
> > On 11/26, Rajendra Nayak wrote:
> > 
> >> +  udelay(1);
> >> +  }
> >> +
> >> +  do {
> >> +  if (gdsc_is_enabled(sc, status_reg) == en)
> >>return 0;
> >>} while (time_before(jiffies, timeout));
> >>  
> >> -  ret = regmap_read(sc->regmap, sc->gdscr, );
> >> -  if (ret)
> >> -  return ret;
> >> -
> >> -  if ((val & PWR_ON_MASK) == check)
> >> -  return 0;
> >> -
> > 
> > This opens a bug where we timeout and then the status bit changes
> > after the timeout. One more check is good and should stay. We
> > could also change this to ktime instead of jiffies. That would be
> > a good improvement.
> 
> If the status bit does change after timeout maybe the timeout isn't
> really enough and needs to be increased?

The problem is more that this isn't a tight loop with interrupts
disabled, so we may schedule the task away for quite some time
before we come back here and test the timeout against the jiffies
value. So it's best to always check the register one more time
after we bail out in case this occurs.

> 
> > 
> >>return -ETIMEDOUT;
> >>  }
> >>  
> >> @@ -165,6 +169,7 @@ static int gdsc_init(struct gdsc *sc)
> >>  {
> >>u32 mask, val;
> >>int on, ret;
> >> +  unsigned int reg;
> >>  
> >>/*
> >> * Disable HW trigger: collapse/restore occur based on registers writes.
> >> @@ -185,7 +190,8 @@ static int gdsc_init(struct gdsc *sc)
> >>return ret;
> >>}
> >>  
> >> -  on = gdsc_is_enabled(sc);
> >> +  reg = sc->gds_hw_ctrl ? sc->gds_hw_ctrl : sc->gdscr;
> >> +  on = gdsc_is_enabled(sc, reg);
> > 
> > If the gdsc is voteable, then we need to make sure that the vote
> > is from us when we boot up. Otherwise the kernel may think that
> > the gdsc is enabled, but it gets turned off by some other master
> > later on. I don't know if this causes some sort of problem for
> > the power domain framework, but we can't rely on the status bit
> > unless we're sure that we've actually set the register to enable
> > it. In the normal enable/disable path we'll always know we set
> > the register, so this really only matters once when we boot up.
> 
> right, thanks for catching this. However if we vote for a votable
> GDSC just because its ON at boot (due to someone else having voted)
> we won't ever remove the vote keeping it always enabled.
> 
> I think a safe way would be to consider all votable gdscs for which
> *we* haven't voted explicitly to be disabled at boot?
> 

Agreed, when we boot we should consider GDSCs that are indicating
they're enabled via the bit 31 status bit but without the sw
enable mask set as "disabled" even though they're actually
enabled by some other master in the SoC.

-- 
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 0/2] qcom: Remove size elements from pmic reg properties

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

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

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

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

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

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


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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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


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

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

Ok.

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

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

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

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

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


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

2015-11-25 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 <n...@fluxnic.net>
Cc: Arnd Bergmann <a...@arndb.de>
Cc: Steven Rostedt <rost...@goodmis.org>
Cc: Måns Rullgård <m...@mansr.com>
Cc: Michal Marek <mma...@suse.com>
Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
---
 scripts/Makefile   |   1 +
 scripts/Makefile.build |  17 +-
 scripts/recorduidiv.c  | 745 +
 3 files changed, 761 insertions(+), 2 deletions(-)
 create mode 100644 scripts/recorduidiv.c

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

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

2015-11-25 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 <n...@fluxnic.net>
Cc: Arnd Bergmann <a...@arndb.de>
Cc: Steven Rostedt <rost...@goodmis.org>
Cc: Måns Rullgård <m...@mansr.com>
Cc: Thomas Petazzoni <thomas.petazz...@free-electrons.com>
Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
---
 arch/arm/Kconfig   | 14 +
 arch/arm/include/asm/cputype.h |  8 -
 arch/arm/include/asm/setup.h   |  3 ++
 arch/arm/kernel/module.c   | 40 +
 arch/arm/kernel/setup.c| 68 ++
 arch/arm/kernel/vmlinux.lds.S  | 13 
 6 files changed, 145 insertions(+), 1 deletion(-)

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

[PATCH v2 0/3] Remove ARCH_MSM* configs

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

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

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

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

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

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


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

2015-11-25 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 using the same design. Looking back on the thread
it seems like Mans was thinking along the same lines, although it wasn't
obvious to me back then or even over the last few days when I wrote this.

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

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

Comments/feedback appreciated.

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

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

Cc: Nicolas Pitre <n...@fluxnic.net>
Cc: Arnd Bergmann <a...@arndb.de>
Cc: Steven Rostedt <rost...@goodmis.org>
Cc: Måns Rullgård <m...@mansr.com>
Cc: Thomas Petazzoni <thomas.petazz...@free-electrons.com>
Cc: Michal Marek <mma...@suse.com>
Cc: Russell King - ARM Linux <li...@arm.linux.org.uk>

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

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

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

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


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

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

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

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

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


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

2015-11-24 Thread Stephen Boyd
On 11/24, Arnd Bergmann wrote:
> On Monday 23 November 2015 15:13:52 Stephen Boyd wrote:
> > On 11/23, Arnd Bergmann wrote:
> > > 
> > > - PJ4/PJ4B (not PJ4B-MP) has a different custom opcode for udiv and sdiv
> > >   in ARM mode. We don't support that with true multiplatform kernels
> > >   because those opcodes work nowhere else, though with your proposed
> > >   series we could easily do that for dynamic patching.
> > 
> > Do you have the information on these custom opcodes? I can work
> > that into the patches assuming the MIDR is different.
> 
> Thomas Petazzoni said this in a private mail:
> 
> | According to the datasheet, the PJ4B has integer signed and unsigned
> | divide, similar to the sdiv and udiv ARM instructions. But the way to
> | access it is by doing a MRC instruction.
> |
> |MRC p6, 1, Rd , CRn , CRm, 4
> |
> |for PJ4B is the same as:
> |
> |SDIV Rd , Rn, Rm
> |
> | on ARM cores.
> |
> |And:
> |
> |MRC p6, 1, Rd , CRn , CRm, 0
> |
> |for PJ4B is the same as:
> |
> |UDIV Rd , Rn, Rm
> |
> |on ARM cores.
> |
> |This is documented in the "Extended instructions" section of the
> |PJ4B datasheet.
> 
> I assume what he meant was that this is true for both PJ4 and PJ4B
> but not for PJ4B-MP, which has the normal udiv/sdiv instructions.
> 
> IOW, anything with CPU implementer 0x56 part 0x581 should use those,
> while part 0x584 can use the sdiv/udiv that it reports correctly.
> 

It looks like we have some sort of function that mostly does
this, except it doesn't differentiate on that lower bit for 1 vs
4. I guess I'll write another one for that.

static inline int cpu_is_pj4(void)
{
unsigned int id;

id = read_cpuid_id();
if ((id & 0xff0fff00) == 0x560f5800)
return 1;

return 0;
}

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


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

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

Urgh. This should be def_bool

-- 
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 0/3] Remove ARCH_MSM* configs

2015-11-24 Thread Stephen Boyd
This patch series allows us to remove the ARCH_MSM* configs that live
in mach-qcom/Kconfig. They're mostly proxy configs for user selectable
clocksource configurations anyway. The first patch can go via Daniel,
while the other two can go via Andy.

Stephen Boyd (3):
  clocksource: defbool CLKSRC_QCOM=y on ARCH_QCOM and make it visible
  ARM: qcom_defconfig: Enable HAVE_ARM_ARCH_TIMER
  ARM: qcom: Drop ARCH_MSM* configs

 arch/arm/configs/qcom_defconfig |  1 +
 arch/arm/mach-qcom/Kconfig  | 16 
 drivers/clocksource/Kconfig |  3 ++-
 3 files changed, 3 insertions(+), 17 deletions(-)

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

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


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

2015-11-24 Thread Stephen Boyd
On 11/24, Arnd Bergmann wrote:
> The qcom spm driver uses cpu_resume_arm(), which is not included
> in the kernel in all configurations:
> 
> drivers/built-in.o: In function `qcom_cpu_spc':
> :(.text+0xbc022): undefined reference to `cpu_suspend'
> drivers/built-in.o: In function `qcom_cpuidle_init':
> :(.init.text+0x610c): undefined reference to `cpu_resume_arm'
> 
> This adds a 'select' Kconfig statement to ensure it's always
> enabled.
> 
> Signed-off-by: Arnd Bergmann <a...@arndb.de>
> ---

Reviewed-by: Stephen Boyd <sb...@codeaurora.org>

-- 
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 3/3] ARM: qcom: Drop ARCH_MSM* configs

2015-11-24 Thread Stephen Boyd
Drop these configs now that we select the clocksources we need
via the defconfig.

Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
---
 arch/arm/mach-qcom/Kconfig | 16 
 1 file changed, 16 deletions(-)

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

2015-11-24 Thread Stephen Boyd
Enable this config in the defconfig so that we can delete the
selection logic surrounding it that exists in mach-qcom/Kconfig.

Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
---
 arch/arm/configs/qcom_defconfig | 1 +
 1 file changed, 1 insertion(+)

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

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


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

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

Suggested-by: Arnd Bergmann <a...@arndb.de>
Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
---
 drivers/clocksource/Kconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index b423785d6afc..7a5ffaa3e490 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -279,9 +279,10 @@ config EM_TIMER_STI
  such as EMEV2 from former NEC Electronics.
 
 config CLKSRC_QCOM
-   bool "Qualcomm MSM timer" if COMPILE_TEST
+   bool "Qualcomm MSM timer" if ARCH_QCOM || COMPILE_TEST
depends on ARM
select CLKSRC_OF
+   defbool ARCH_QCOM
help
  This enables the clocksource and the per CPU clockevent driver for the
  Qualcomm SoCs.
-- 
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 10/27] drivers: power: Introduce PM domains for CPUs/clusters

2015-11-24 Thread Stephen Boyd
On 11/17, Lina Iyer wrote:
> diff --git a/Documentation/arm/cpu-domains.txt 
> b/Documentation/arm/cpu-domains.txt
> new file mode 100644
> index 000..ef5f215
> --- /dev/null
> +++ b/Documentation/arm/cpu-domains.txt
> @@ -0,0 +1,52 @@
> +CPU Clusters and PM domain
> +
> +Newer CPUs are grouped in a SoC as clusters. A cluster in addition to the
> +CPUs may have caches, GIC, VFP and architecture specific power controller to
> +power the cluster. A cluster may also be nested in another cluster, the
> +hierarchy of which is depicted in the device tree. CPUIdle frameworks enables

s/frameworks/framework/?

s/depicted/described/? Hopefully we aren't putting pictures or
art in DT for this sort of stuff.


> diff --git a/drivers/base/power/cpu-pd.c b/drivers/base/power/cpu-pd.c
> new file mode 100644
> index 000..9758b8d
> --- /dev/null
> +++ b/drivers/base/power/cpu-pd.c
> @@ -0,0 +1,231 @@
> +/*
> + * CPU Generic PM Domain.
> + *
> + * Copyright (C) 2015 Linaro Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#define DEBUG
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

Is this used?

> +#include 
> +#include 
> +
> +#define CPU_PD_NAME_MAX 36
> +
[...]
> +static int of_pm_domain_attach_cpus(struct device_node *dn)
> +{
> + int cpuid, ret;
> +
> + /* Find any CPU nodes with a phandle to this power domain */
> + for_each_possible_cpu(cpuid) {
> + struct device *cpu_dev;
> + struct device_node *cpu_pd;
> +
> + cpu_dev = get_cpu_device(cpuid);
> + if (!cpu_dev) {
> + pr_warn("%s: Unable to get device for CPU%d\n",
> + __func__, cpuid);
> + return -ENODEV;
> + }
> +
> + /* Only attach CPUs that are part of this domain */
> + cpu_pd = of_parse_phandle(cpu_dev->of_node, "power-domains", 0);
> + if (cpu_pd != dn)
> + continue;
> +
> + if (cpu_online(cpuid)) {

I guess we don't care if hotplug is running in parallel to this
code?

> + pm_runtime_set_active(cpu_dev);
> + /*
> +  * Execute the below on that 'cpu' to ensure that the
> +  * reference counting is correct. It's possible that
> +  * while this code is executing, the 'cpu' may be
> +  * powered down, but we may incorrectly increment the
> +  * usage. By executing the get_cpu on the 'cpu',
> +  * we can ensure that the 'cpu' and its usage count are
> +  * matched.
> +  */
> + smp_call_function_single(cpuid, run_cpu, NULL, true);
> + } else {
> + pm_runtime_set_suspended(cpu_dev);
> + }
> +
> + ret = genpd_dev_pm_attach(cpu_dev);
> + if (ret) {
> + dev_warn(cpu_dev,
> + "%s: Unable to attach to power-domain: %d\n",
> + __func__, ret);
> + } else {
> + pm_runtime_enable(cpu_dev);
> + dev_dbg(cpu_dev, "Attached CPU%d to domain\n", cpuid);
> + }
> + }
> +
> + return 0;
> +}
> +
> +int of_register_cpu_pm_domain(struct device_node *dn,

static?

> + struct cpu_pm_domain *pd)
> +{
> + int ret;
> +
> + if (!pd || !pd->genpd)
> + return -EINVAL;
> +
> + /*
> +  * The platform should not set up the genpd callbacks.
> +  * They should setup the pd->plat_ops instead.
> +  */
> + WARN_ON(pd->genpd->power_off);
> + WARN_ON(pd->genpd->power_on);
> +
> + pd->genpd->power_off = cpu_pd_power_off;
> + pd->genpd->power_on = cpu_pd_power_on;
> + pd->genpd->flags |= GENPD_FLAG_IRQ_SAFE;
> +
> + INIT_LIST_HEAD_RCU(>link);
> + spin_lock(_pd_list_lock);
> + list_add_rcu(>link, _cpu_pd_list);
> + spin_unlock(_pd_list_lock);
> + pd->dn = dn;
> +
> + /* Register the CPU genpd */
> + pr_debug("adding %s as CPU PM domain.\n", pd->genpd->name);
> + ret = of_pm_genpd_init(dn, pd->genpd, _qos_governor, false);
> + if (ret) {
> + pr_err("Unable to initialize domain %s\n", dn->full_name);
> + return ret;
> + }
> +
> + ret = of_genpd_add_provider_simple(dn, pd->genpd);
> + if (ret)
> + pr_warn("Unable to add genpd %s as provider\n",
> + pd->genpd->name);
> +
> + /* Attach the CPUs to the CPU PM domain */
> + ret = of_pm_domain_attach_cpus(dn);
> + if (ret)
> + of_genpd_del_provider(dn);
> +
> + return ret;
> +}
> +

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

2015-11-24 Thread Stephen Boyd
On 11/17, Lina Iyer wrote:
> diff --git a/drivers/base/power/cpu-pd.c b/drivers/base/power/cpu-pd.c
> index 9758b8d..617ce54 100644
> --- a/drivers/base/power/cpu-pd.c
> +++ b/drivers/base/power/cpu-pd.c
> @@ -18,6 +18,7 @@
>  #include 
>  #include 
>  #include 
> +#include 

What's this added for?

>  #include 
>  #include 

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


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

2015-11-24 Thread Stephen Boyd
On 11/24, Russell King - ARM Linux wrote:
> On Tue, Nov 24, 2015 at 12:53:49AM -0800, Stephen Boyd wrote:
> > 
> > And adding CPU_V7VE causes a cascade of changes to wherever
> > CPU_V7 is being used today. Here's the patch I currently have,
> > without the platform changes:

> > @@ -1069,7 +1075,7 @@ config ARM_ERRATA_411920
> >  
> >  config ARM_ERRATA_430973
> > bool "ARM errata: Stale prediction on replaced interworking branch"
> > -   depends on CPU_V7
> > +   depends on CPU_V7 || CPU_V7VE
> 
> NAK on all this.  The fact that you're having to add CPU_V7VE at all
> sites which have CPU_V7 shows that this is a totally broken way of
> approaching this.
> 
> Make CPU_V7VE be an _add-on_ to CPU_V7.  In other words, when CPU_V7VE
> is enabled, CPU_V7 should also be enabled, just like we do for CPU_V6K.
> 
> Note that v7M is different because that's not an add-on feature, it's
> a different CPU class from (what should be) v7A.
> 

Ok. Presumably the order of arch-$(CONFIG) lines in the Makefile
are done in an order to allow the build to degrade to the lowest
common denominator among architecture support. CPU_V7 selects
CPU_32v7 and we're using that config to select -march=armv7-a in
the Makefile. The patch currently uses CPU_32v7VE to select
-march=armv7ve. If CPU_V7VE selects CPU_V7 we'll never be able to
use -march=armv7ve because CPU_V7 will be selecting CPU_32v7 and
that will come after CPU_32v7VE in the Makefile.

My understanding is that we want to support CPU_V7VE without
CPU_V7 enabled so that it uses the idiv instructions in that
configuration. When V7VE and V7 are both enabled, we should
degrade to the aeabi functions, and the same is true for when
V7VE is disabled.

I suppose we can fix this by making CPU_V7 a hidden option? Or I
need some coffee because I'm missing something.

---8<
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index ccd0d5553d38..158ffb983387 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -626,7 +626,7 @@ config ARCH_SHMOBILE_LEGACY
select ARCH_SHMOBILE
select ARM_PATCH_PHYS_VIRT if MMU
select CLKDEV_LOOKUP
-   select CPU_V7
+   select CPU_V7_NOEXT
select GENERIC_CLOCKEVENTS
select HAVE_ARM_SCU if SMP
select HAVE_ARM_TWD if SMP
@@ -802,7 +802,7 @@ config ARCH_MULTI_V7
bool "ARMv7 based platforms (Cortex-A, PJ4, Scorpion, Krait)"
default y
select ARCH_MULTI_V6_V7
-   select CPU_V7
+   select CPU_V7_NOEXT
select HAVE_SMP
 
 config ARCH_MULTI_V7VE
diff --git a/arch/arm/mach-prima2/Kconfig b/arch/arm/mach-prima2/Kconfig
index 9ab8932403e5..7e1b36400e14 100644
--- a/arch/arm/mach-prima2/Kconfig
+++ b/arch/arm/mach-prima2/Kconfig
@@ -25,7 +25,7 @@ config ARCH_ATLAS7
bool "CSR SiRFSoC ATLAS7 ARM Cortex A7 Platform"
default y
select ARM_GIC
-   select CPU_V7
+   select CPU_V7_NOEXT
select HAVE_ARM_SCU if SMP
select HAVE_SMP
help
diff --git a/arch/arm/mach-realview/Kconfig b/arch/arm/mach-realview/Kconfig
index 565925f37dc5..7e084c34071c 100644
--- a/arch/arm/mach-realview/Kconfig
+++ b/arch/arm/mach-realview/Kconfig
@@ -24,7 +24,7 @@ config MACH_REALVIEW_EB
 config REALVIEW_EB_A9MP
bool "Support Multicore Cortex-A9 Tile"
depends on MACH_REALVIEW_EB
-   select CPU_V7
+   select CPU_V7_NOEXT
select HAVE_ARM_SCU if SMP
select HAVE_ARM_TWD if SMP
select HAVE_SMP
@@ -93,7 +93,7 @@ config REALVIEW_PB1176_SECURE_FLASH
 config MACH_REALVIEW_PBA8
bool "Support RealView(R) Platform Baseboard for Cortex(tm)-A8 platform"
select ARM_GIC
-   select CPU_V7
+   select CPU_V7_NOEXT
select HAVE_PATA_PLATFORM
help
  Include support for the ARM(R) RealView Platform Baseboard for
diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index e4ff161da98f..02a887235155 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -350,11 +350,11 @@ config CPU_FEROCEON_OLD_ID
 config CPU_PJ4
bool
select ARM_THUMBEE
-   select CPU_V7
+   select CPU_V7_NOEXT
 
 config CPU_PJ4B
bool
-   select CPU_V7
+   select CPU_V7_NOEXT
 
 # ARMv6
 config CPU_V6
@@ -383,11 +383,9 @@ config CPU_V6K
select CPU_PABRT_V6
select CPU_TLB_V6 if MMU
 
-# ARMv7
 config CPU_V7
-   bool "Support ARM V7 processor" if (!ARCH_MULTIPLATFORM || 
ARCH_MULTI_V7) && (ARCH_INTEGRATOR || MACH_REALVIEW_EB || MACH_REALVIEW_PBX)
+   bool
select CPU_32v6K
-   select CPU_32v7
select CPU_ABRT_EV7
select CPU_CACHE_V7
select CPU_CACHE_VIPT
@@ -398,6 +396,12 @@ config CPU_V7
select CPU_PABRT_V7
select CPU_TLB_V7 if MMU
 
+# ARMv7
+config CPU_V7_NOEXT
+   bool "Support ARM V7 processor" if (!ARCH_MULT

Re: [PATCH RFC 07/27] PM / Domains: Read domain residency from DT

2015-11-24 Thread Stephen Boyd
On 11/17, Lina Iyer wrote:
> diff --git a/Documentation/devicetree/bindings/power/power_domain.txt 
> b/Documentation/devicetree/bindings/power/power_domain.txt
> index ecfaf44..d71da29 100644
> --- a/Documentation/devicetree/bindings/power/power_domain.txt
> +++ b/Documentation/devicetree/bindings/power/power_domain.txt
> @@ -67,6 +67,13 @@ have the following properties -
>   If omitted, this is assumed to be equal to:
>   entry-latency-us + exit-latency-us
>  
> + - residency-us:
> + Usage: Optional
> + Value type: 

Is it an array or just a single u32? Some example would be good
to add.

-- 
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: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions

2015-11-23 Thread Stephen Boyd
On 11/23, Arnd Bergmann wrote:
> On Monday 23 November 2015 09:14:39 Christopher Covington wrote:
> > On 11/23/2015 03:15 AM, Arnd Bergmann wrote:
> > > On Sunday 22 November 2015 21:36:45 Nicolas Pitre wrote:
> > >> On Sun, 22 Nov 2015, Arnd Bergmann wrote:
> > > 
> > > Ok, thanks a lot! So the reporting in /proc/cpuinfo clearly matches
> > > the actual features, and we can just treat this as no LPAE / no IDIV
> > > for kernel compilation, as nobody ever seems to use THUMB2_KERNEL
> > > in practice.
> > > 
> > > PJ4-MP is like Cortex-A15/A7/A12/A17 and supports both IDIV and LPAE,
> > > which leaves the question whether Scorpion or Krait do the same as
> > > well, or whether they are outliers and need a special configuration.
> > 
> > LPAE is only supported in the Krait 450.
> > 
> > http://www.anandtech.com/show/7537/qualcomms-snapdragon-805-25ghz-128bit-memory-interface-d3d11class-graphics-more
> > 
> > I'm pretty sure idiv support came earlier, but I don't have the
> > specifics on hand.
> 
> I have seen that article, but didn't trust it as a canonical
> source of information here.
> 
> If you can confirm that it's right, that would mean that we
> don't support LPAE on mach-qcom, as the only SoC with Krait 450
> seems to be APQ8084, and mainline Linux doesn't run on that.

arch/arm/boot/dts/qcom-apq8084.dtsi exists in the mainline
kernel. We support more than what's in the Kconfig language
under mach-qcom. And yes LPAE is supported by apq8084 (as is
IDIV). Here's the /proc/cpuinfo on that device.

# cat /proc/cpuinfo
processor   : 0
model name  : ARMv7 Processor rev 1 (v7l)
BogoMIPS: 38.40
Features: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt 
vfpd32 lpae evtstrm
CPU implementer : 0x51
CPU architecture: 7
CPU variant : 0x3
CPU part: 0x06f
CPU revision: 1

processor   : 1
model name  : ARMv7 Processor rev 1 (v7l)
BogoMIPS: 38.40
Features: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt 
vfpd32 lpae evtstrm
CPU implementer : 0x51
CPU architecture: 7
CPU variant : 0x3
CPU part: 0x06f
CPU revision: 1

processor   : 2
model name  : ARMv7 Processor rev 1 (v7l)
BogoMIPS: 38.40
Features: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt 
vfpd32 lpae evtstrm
CPU implementer : 0x51
CPU architecture: 7
CPU variant : 0x3
CPU part: 0x06f
CPU revision: 1

processor   : 3
model name  : ARMv7 Processor rev 1 (v7l)
BogoMIPS: 38.40
Features: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt 
vfpd32 lpae evtstrm
CPU implementer : 0x51
CPU architecture: 7
CPU variant : 0x3
CPU part: 0x06f
CPU revision: 1

Hardware: Qualcomm (Flattened Device Tree)
Revision: 
Serial  : 

> 
> The ones we do support are MSM8x60 (Scorpion), MSM8960
> (Krait-without-number),and MSM7874 (Krait 400). Do those all
> support IDIV but not LPAE?
> 

Krait supports IDIV for all versions. Scorpion doesn't support
IDIV or lpae. Here's the output of /proc/cpuinfo on that device. 

# cat /proc/cpuinfo
processor   : 0
model name  : ARMv7 Processor rev 2 (v7l)
BogoMIPS: 13.50
Features: half thumb fastmult vfp edsp neon vfpv3 tls vfpd32
CPU implementer : 0x51
CPU architecture: 7
CPU variant : 0x0
CPU part: 0x02d
CPU revision: 2

processor   : 1
model name  : ARMv7 Processor rev 2 (v7l)
BogoMIPS: 13.50
Features: half thumb fastmult vfp edsp neon vfpv3 tls vfpd32
CPU implementer : 0x51
CPU architecture: 7
CPU variant : 0x0
CPU part: 0x02d
CPU revision: 2

Hardware: Qualcomm (Flattened Device Tree)
Revision: 
Serial  : 

-- 
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: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions

2015-11-23 Thread Stephen Boyd
On 11/23, Arnd Bergmann wrote:
> On Monday 23 November 2015 13:32:06 Stephen Boyd wrote:
> > On 11/23, Arnd Bergmann wrote:
> > > On Monday 23 November 2015 12:38:47 Stephen Boyd wrote:
> > 
> > It would be nice to drop the ARCH_MSM* configs entirely. If we
> > could select the right timers from kconfig without using selects
> > then we could drop them. Or we could just select both types of
> > timers when building qcom platforms.
> 
> Ok, dropping the specific Kconfig entries is actually an awesome
> idea, as it completely solves the other problem as well, more on
> that below.
> 
> In that case, don't worry about listing all the models, once
> we stop listing a subset of them, the confusion is already
> reduced by the fact that one has to look at the .dts files
> so see which models we support, and I assume there will be
> additional ones coming in for at least a few more years (before
> you stop caring about 32-bit MSM and compatibles).
> 
> Regarding the timers:
> HAVE_ARM_ARCH_TIMER is already user-selectable, so maybe something
> like

> 
> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
> index b251013eef0a..bad6343c34d5 100644
> --- a/drivers/clocksource/Kconfig
> +++ b/drivers/clocksource/Kconfig
> @@ -324,8 +324,9 @@ config EM_TIMER_STI
> such as EMEV2 from former NEC Electronics.
>  
>  config CLKSRC_QCOM
> - bool "Qualcomm MSM timer" if COMPILE_TEST
> + bool "Qualcomm MSM timer" if ARCH_QCOM || COMPILE_TEST
>   depends on ARM
> + default ARCH_QCOM
>   select CLKSRC_OF
>   help
> This enables the clocksource and the per CPU clockevent driver for the
> 
> would make both of them equally configurable and not clutter up
> the Kconfig file when ARCH_QCOM is not selected. I've added
> Daniel Lezcano to Cc, he probably has an opinion on this too.

Yeah I think that architected timers are an outlier. I recall
some words from John Stultz that platforms should select the
clocksources they use, but maybe things have changed. For this
kind of thing I wouldn't mind putting it in the defconfig though.
I'll put the patches on the list to get the discussion started.

> 
> > > > > The ones we do support are MSM8x60 (Scorpion), MSM8960
> > > > > (Krait-without-number),and MSM7874 (Krait 400). Do those all
> > > > > support IDIV but not LPAE?
> > > > > 
> > > > 
> > > > Krait supports IDIV for all versions. Scorpion doesn't support
> > > > IDIV or lpae. Here's the output of /proc/cpuinfo on that device. 
> > > > 
> > > > # cat /proc/cpuinfo
> > > > processor   : 0
> > > > model name  : ARMv7 Processor rev 2 (v7l)
> > > > BogoMIPS: 13.50
> > > > Features: half thumb fastmult vfp edsp neon vfpv3 tls vfpd32
> > > > CPU implementer : 0x51
> > > > CPU architecture: 7
> > > > CPU variant : 0x0
> > > > CPU part: 0x02d
> > > > CPU revision: 2
> > > 
> > > Ok, that leaves just one missing puzzle piece: can you confirm that
> > > no supported Krait variant other than Krait 450 / apq8084 has LPAE?
> > > 
> > 
> > Right, apq8084 is the only SoC with a Krait CPU that supports
> > LPAE.
> 
> Ok, thanks for the confirmation.
> 
> Summarizing what we've found, I think we can get away with just
> introducing two Kconfig symbols ARCH_MULTI_V7VE and CPU_V7VE.
> Most CPUs fall clearly into one category or the other, and then
> we can allow LPAE to be selected for V7VE-only build but not
> for plain V7, and we can unconditionally build the kernel with
> 
> arch-$(CONFIG_CPU_32v7VE)  = -D__LINUX_ARM_ARCH__=7 $(call 
> cc-option,-march=armv7ve,-march=armv7-a -mcpu=cortex-a15)
> 
> This works perfectly for Cortex-A5, -A8, -A9, -A12, -A15, -A17, Brahma-B15,
> PJ4B-MP, Scorpion and Krait-450, which all clearly fall into one of
> the two other categories.
> 
> The two exceptions that don't quite fit are still "good enough":
> 
> - PJ4/PJ4B (not PJ4B-MP) has a different custom opcode for udiv and sdiv
>   in ARM mode. We don't support that with true multiplatform kernels
>   because those opcodes work nowhere else, though with your proposed
>   series we could easily do that for dynamic patching.

Do you have the information on these custom opcodes? I can work
that into the patches assuming the MIDR is different.

> 
> - Krait (pre-450) won't run kernels with LPAE disabled, but if we only
>   have one global ARCH_QCOM option that can be enabled for both
>   ARCH_MULTI_V7VE and ARCH_MULTI_V7, we 

Re: [PATCH v4 4/5] clk: qcom: Add RPM clock controller driver

2015-11-23 Thread Stephen Boyd
On 11/21, Bjorn Andersson wrote:
> On Fri 20 Nov 16:39 PST 2015, Stephen Boyd wrote:
> 
> > On 11/19, Georgi Djakov wrote:
> > > diff --git a/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt 
> > > b/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt
> > > new file mode 100644
> > > index ..bd0fd0cd50dc
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt
> > > @@ -0,0 +1,35 @@
> > > +Qualcomm RPM Clock Controller Binding
> > > +
> > > +The RPM is a dedicated hardware engine for managing the shared
> > > +SoC resources in order to keep the lowest power profile. It
> > > +communicates with other hardware subsystems via shared memory
> > > +and accepts clock requests, aggregates the requests and turns
> > > +the clocks on/off or scales them on demand.
> > > +
> > > +Required properties :
> > > +- compatible : shall contain only one of the following:
> > > +
> > > + "qcom,rpmcc-msm8916"
> > 
> > We need to add qcom,rpmcc as a generic compatible as well.
> > 
> 
> The binding is generic and the clock defines global, so this should work
> fine on the dt side of things. But how do we implement this?
> 
> Which set of clocks does the generic rpmcc actually provide?
> 
> Do you foresee that there will be an implementation of the generic rpmcc
> or is it just a way to "standardize" the dt binding?
> 

I don't see any problem with implementing the RPM clock
controller as one file or two files (one for platform bus based
RPM modules and one for SMD bus RPM modules). The compatible can
be the same for both struct driver instances, while the bus will
pick the right driver. I suspect we'll need SoC specific
compatibles though to export the right set of clocks, so having
the generic compatible is mostly to find these rpm clock
controllers so that we know to skip registering the XO clock from
the GCC driver and not some generic implementation of the driver.

There's probably a subset of the clocks that's always the same
between devices, so if we had to we could match the generic
compatible and provide limited functionality.

-- 
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: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions

2015-11-23 Thread Stephen Boyd
On 11/23, Arnd Bergmann wrote:
> 
> Ok, thanks for the confirmation.
> 
> Summarizing what we've found, I think we can get away with just
> introducing two Kconfig symbols ARCH_MULTI_V7VE and CPU_V7VE.
> Most CPUs fall clearly into one category or the other, and then
> we can allow LPAE to be selected for V7VE-only build but not
> for plain V7, and we can unconditionally build the kernel with
> 
> arch-$(CONFIG_CPU_32v7VE)  = -D__LINUX_ARM_ARCH__=7 $(call 
> cc-option,-march=armv7ve,-march=armv7-a -mcpu=cortex-a15)
> 

This causes compiler spew for me:

  warning: switch -mcpu=cortex-a15 conflicts with -march=armv7-a switch

Removing -march=armv7-a from there makes it quiet.

Also, it's sort of feels wrong to have -mcpu in a place where
we're exclusively doing -march. Perhaps the fallback should be
bog standard -march=armv7-a? (or the fallback for that one
"-march=armv5t -Wa$(comma)-march=armv7-a")?

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


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

2015-11-23 Thread Stephen Boyd
On 11/22, Rob Herring wrote:
> On Fri, Nov 20, 2015 at 03:31:16PM -0800, Stephen Boyd wrote:
> > 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 <sb...@codeaurora.org>
> 
> Much more reasonable now. I do find the '/' in it a bit strange though.

I can remove the backslash if you like. Is a dash more preferred?

> 
> Acked-by: Rob Herring <r...@kernel.org>
> 

and if so can I keep the ack? I'll resend with that change and
add the ack.

-- 
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] nvmem: qfprom: Specify LE device endianness

2015-11-23 Thread Stephen Boyd
On 11/21, Srinivas Kandagatla wrote:
> Hi Stephen,
> 
> Thanks for the fix.
> 
> I will send it to Greg for next rc.

Thanks. The change in regmap core that causes the problem is only
in -next. I'm not sure if it's going to hit mainline this release
cycle, so if it doesn't you could queue this for the next
version. No rush.

-- 
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/4] arm64: dts: Add msm8996 SoC and MTP board support

2015-11-23 Thread Stephen Boyd
On 11/23, Rajendra Nayak wrote:
> 
> On 11/18/2015 06:42 AM, Stephen Boyd wrote:
> > Add initial device tree support for the Qualcomm MSM8996 SoC and
> > MTP8996 evaluation board.
> > 
> > Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
> > ---
> []...
> 
> > +
> > +   spmi_bus: qcom,spmi@400f000 {
> > +   compatible = "qcom,spmi-pmic-arb";
> > +   reg = <0x400f000 0x1000>,
> > + <0x440 0x80>,
> > + <0x4c0 0x80>,
> > + <0x580 0x20>,
> > + <0x400a000 0x002100>;
> > +   reg-names = "core", "chnls", "obsrvr", "intr", "cnfg";
> > +   interrupt-names = "periph_irq";
> > +   interrupts = ;
> > +   qcom,ee = <0>;
> > +   qcom,channel = <0>;
> > +   #address-cells = <2>;
> > +   #size-cells = <0>;
> > +   interrupt-controller;
> > +   #interrupt-cells = <4>;
> > +   };
> > +
> > +   mmcc: clock-controller@8c {
> > +   compatible = "qcom,mmcc-msm8996";
> > +   #clock-cells = <1>;
> > +   #reset-cells = <1>;
> > +   reg = <0x8c 0xc>;
> 
> I think the size here should be 0x4 and not 0xc
> 

Yes you're right.

-- 
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: [RFC/PATCH 2/3] recordmcount: Record locations of __aeabi_{u}idiv() calls on ARM

2015-11-23 Thread Stephen Boyd
On 11/23, Russell King - ARM Linux wrote:
> On Mon, Nov 23, 2015 at 01:16:01PM -0800, Stephen Boyd wrote:
> > Thanks. I don't see the prints on my system even with this config
> > on top of allyesconfig. Odd.
> 
> Hmm.
> 
> It could be because I use ccache in hardlink mode to avoid the disk
> overhead of having two copies and having to duplicate the file
> contents.
> 
> If the kernel build thinks it can modify an object file in place, it
> will lead to this, as it will end up modifying the stored ccache
> file unless it specifically breaks the hardlink.
> 

That sounds very possible. I'd have to get ccache setup with
hardlinks to test out your theory. 

Is it supported to use ccache with hardlinks to build the kernel?
The ccache documentation makes it sounds like it will confuse
make and isn't a good idea.

-- 
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: [RFC/PATCH 3/3] ARM: Replace calls to __aeabi_{u}idiv with udiv/sdiv instructions

2015-11-23 Thread Stephen Boyd
On 11/21, Måns Rullgård wrote:
> Stephen Boyd <sb...@codeaurora.org> writes:
> 
> > +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;
> > +}
> 
> [...]
> 
> > +static void __init patch_aeabi_uidiv(void)
> > +{
> > +   extern unsigned long *__start_udiv_loc[], *__stop_udiv_loc[];
> > +   extern unsigned long *__start_idiv_loc[], *__stop_idiv_loc[];
> > +   unsigned long **p;
> > +   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) {
> > +   for (p = __start_udiv_loc; p < __stop_udiv_loc; p++) {
> > +   unsigned long *inst = *p;
> > +   *inst = udiv_insn;
> > +   }
> > +   for (p = __start_idiv_loc; p < __stop_idiv_loc; p++) {
> > +   unsigned long *inst = *p;
> > +       *inst = sdiv_insn;
> > +   }
> > +   }
> > +}
> 
> These functions are rather similar.  Perhaps they could be combined
> somehow.
> 

Yes. I have this patch on top, just haven't folded it in because
it doesn't reduce the lines of code.

8<
From: Stephen Boyd <sb...@codeaurora.org>
Subject: [PATCH] consolidate with module code

Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
---
 arch/arm/include/asm/setup.h |  3 +++
 arch/arm/kernel/module.c | 16 +
 arch/arm/kernel/setup.c  | 54 +++-
 3 files changed, 42 insertions(+), 31 deletions(-)

diff --git a/arch/arm/include/asm/setup.h b/arch/arm/include/asm/setup.h
index e0adb9f1bf94..3f251cdb94ef 100644
--- a/arch/arm/include/asm/setup.h
+++ b/arch/arm/include/asm/setup.h
@@ -25,4 +25,7 @@ extern int arm_add_memory(u64 start, u64 size);
 extern void early_print(const char *str, ...);
 extern void dump_machine_table(void);
 
+extern void patch_uidiv(void *addr, size_t size);
+extern void patch_idiv(void *addr, size_t size);
+
 #endif
diff --git a/arch/arm/kernel/module.c b/arch/arm/kernel/module.c
index 064e6ae60e08..684a68f1085b 100644
--- a/arch/arm/kernel/module.c
+++ b/arch/arm/kernel/module.c
@@ -22,6 +22,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -58,24 +59,19 @@ 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;
+   unsigned int mask;
 
-   if (IS_ENABLED(CONFIG_THUMB2_KERNEL)) {
+   if (IS_ENABLED(CONFIG_THUMB2_KERNEL))
mask = HWCAP_IDIVT;
-   udiv_insn = __opcode_to_mem_thumb32(0xfbb0f0f1);
-   sdiv_insn = __opcode_to_mem_thumb32(0xfb90f0f1);
-   } else {
+   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;
+   patch_uidiv(, sizeof(loc));
   

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

2015-11-23 Thread Stephen Boyd
On 11/21, Russell King - ARM Linux wrote:
> On Fri, Nov 20, 2015 at 05:23:16PM -0800, Stephen Boyd wrote:
> > @@ -452,14 +631,14 @@ static char const *
> >  __has_rel_mcount(Elf_Shdr const *const relhdr,  /* is SHT_REL or SHT_RELA 
> > */
> >  Elf_Shdr const *const shdr0,
> >  char const *const shstrtab,
> > -char const *const fname)
> > +char const *const fname, const char *find)
> >  {
> > /* .sh_info depends on .sh_type == SHT_REL[,A] */
> > Elf_Shdr const *const txthdr = [w(relhdr->sh_info)];
> > char const *const txtname = [w(txthdr->sh_name)];
> >  
> > -   if (strcmp("__mcount_loc", txtname) == 0) {
> > -   fprintf(stderr, "warning: __mcount_loc already exists: %s\n",
> > +   if (strcmp(find, txtname) == 0) {
> > +   fprintf(stderr, "warning: %s already exists: %s\n", find,
> 
> Oh, it's this which has been spewing that silly
>   "warning: __mcount_loc already exists"
> 
> message thousands of times in my nightly kernel builds (so much so, that
> I've had to filter the thing out of the logs.)  Given that this is soo
> noisy, I think first we need to get to the bottom of why this program is
> soo noisy before we try to make it more functional.
> 

This comment in recordmcount.pl may tell us something.

#
# Somehow the make process can execute this script on an
# object twice. If it does, we would duplicate the mcount
# section and it will cause the function tracer self test
# to fail. Check if the mcount section exists, and if it does,
# warn and exit.
#
print STDERR "ERROR: $mcount_section already in $inputfile\n" .
"\tThis may be an indication that your build is corrupted.\n" .
"\tDelete $inputfile and try again. If the same object file\n" .
"\tstill causes an issue, then disable CONFIG_DYNAMIC_FTRACE.\n";
exit(-1);

I don't think there's much that can be done here besides making
it silent unless there's some verbose build flag set (-v?), but
it is interesting that you see it spew thousands of times. I've
never seen the error printed, but perhaps I'm not building the
kernel the same way you are. Care to share how you're building
and seeing these error messages?

-- 
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: [RFC/PATCH 2/3] recordmcount: Record locations of __aeabi_{u}idiv() calls on ARM

2015-11-23 Thread Stephen Boyd
On 11/23, Russell King - ARM Linux wrote:
> On Mon, Nov 23, 2015 at 12:53:35PM -0800, Stephen Boyd wrote:
> > On 11/21, Russell King - ARM Linux wrote:
> > > On Fri, Nov 20, 2015 at 05:23:16PM -0800, Stephen Boyd wrote:
> > > > @@ -452,14 +631,14 @@ static char const *
> > > >  __has_rel_mcount(Elf_Shdr const *const relhdr,  /* is SHT_REL or 
> > > > SHT_RELA */
> > > >  Elf_Shdr const *const shdr0,
> > > >  char const *const shstrtab,
> > > > -char const *const fname)
> > > > +char const *const fname, const char *find)
> > > >  {
> > > > /* .sh_info depends on .sh_type == SHT_REL[,A] */
> > > > Elf_Shdr const *const txthdr = [w(relhdr->sh_info)];
> > > > char const *const txtname = [w(txthdr->sh_name)];
> > > >  
> > > > -   if (strcmp("__mcount_loc", txtname) == 0) {
> > > > -   fprintf(stderr, "warning: __mcount_loc already exists: 
> > > > %s\n",
> > > > +   if (strcmp(find, txtname) == 0) {
> > > > +   fprintf(stderr, "warning: %s already exists: %s\n", 
> > > > find,
> > > 
> > > Oh, it's this which has been spewing that silly
> > >   "warning: __mcount_loc already exists"
> > > 
> > > message thousands of times in my nightly kernel builds (so much so, that
> > > I've had to filter the thing out of the logs.)  Given that this is soo
> > > noisy, I think first we need to get to the bottom of why this program is
> > > soo noisy before we try to make it more functional.
> > > 
> > 
> > This comment in recordmcount.pl may tell us something.
> > 
> > #
> > # Somehow the make process can execute this script on an
> > # object twice. If it does, we would duplicate the mcount
> > # section and it will cause the function tracer self test
> > # to fail. Check if the mcount section exists, and if it does,
> > # warn and exit.
> > #
> > print STDERR "ERROR: $mcount_section already in $inputfile\n" .
> > "\tThis may be an indication that your build is corrupted.\n" .
> > "\tDelete $inputfile and try again. If the same object file\n" .
> > "\tstill causes an issue, then disable CONFIG_DYNAMIC_FTRACE.\n";
> > exit(-1);
> > 
> > I don't think there's much that can be done here besides making
> > it silent unless there's some verbose build flag set (-v?), but
> > it is interesting that you see it spew thousands of times. I've
> > never seen the error printed, but perhaps I'm not building the
> > kernel the same way you are. Care to share how you're building
> > and seeing these error messages?
> 
> All I get is this:
> 
> warning: __mcount_loc already exists: arch/arm/mm/mmap.o
> 
> Not the "ERROR: ... already in ..." that the above would give.

That's because I copied from the perl version of recordmcount.
The C version of this tool doesn't have that nice comment.

> 
> Nothing special.  It's a seeded allyesconfig built with:
> 
> $ make -k -j2 zImage modules dtbs LOADADDR=0x60008000 
> CONFIG_DEBUG_SECTION_MISMATCH=y O=/path/to/build/dir
> 
> The seed being:
> 
> CONFIG_MODULES=y
> # CONFIG_LOCALVERSION_AUTO is not set
> CONFIG_LOG_BUF_SHIFT=19
> CONFIG_ZBOOT_ROM_TEXT=0x7000
> CONFIG_ZBOOT_ROM_BSS=0x6100
> CONFIG_CMDLINE="root=/dev/mmcblk0p1 rootdelay=2 ro"
> CONFIG_ARCH_VEXPRESS=y
> # Must not have XIP support enabled
> CONFIG_XIP_KERNEL=n
> # Our toolchain has no T2 support
> CONFIG_THUMB2_KERNEL=n
> # Disable samples - this needs linux/seccomp.h in our host environment
> CONFIG_SAMPLES=n
> # Disable debug info (stop the kernel getting too large)
> CONFIG_DEBUG_INFO=n
> # 30 Dec 2013: disable building wanxl firmware: we don't have as68k etc
> CONFIG_WANXL_BUILD_FIRMWARE=n
> # 14 Jan 2015: disable GCOV
> CONFIG_GCOV_KERNEL=n
> 

Thanks. I don't see the prints on my system even with this config
on top of allyesconfig. Odd.

-- 
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: [RFC/PATCH 3/3] ARM: Replace calls to __aeabi_{u}idiv with udiv/sdiv instructions

2015-11-23 Thread Stephen Boyd
On 11/23, Måns Rullgård wrote:
> Stephen Boyd <sb...@codeaurora.org> writes:
> 
> > On 11/21, Måns Rullgård wrote:
> >> 
> >> These functions are rather similar.  Perhaps they could be combined
> >> somehow.
> >> 
> >
> > Yes. I have this patch on top, just haven't folded it in because
> > it doesn't reduce the lines of code.
> 
> I don't see any reason to split it anyhow.  The end result isn't any
> harder to understand than the intermediate.

Yep.

> 
> > 8<
> > From: Stephen Boyd <sb...@codeaurora.org>
> > Subject: [PATCH] consolidate with module code
> >
> > Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
> > ---
> >  arch/arm/include/asm/setup.h |  3 +++
> >  arch/arm/kernel/module.c | 16 +
> >  arch/arm/kernel/setup.c  | 54 
> > +++-
> >  3 files changed, 42 insertions(+), 31 deletions(-)
> >
> > diff --git a/arch/arm/include/asm/setup.h b/arch/arm/include/asm/setup.h
> > index e0adb9f1bf94..3f251cdb94ef 100644
> > --- a/arch/arm/include/asm/setup.h
> > +++ b/arch/arm/include/asm/setup.h
> > @@ -25,4 +25,7 @@ extern int arm_add_memory(u64 start, u64 size);
> >  extern void early_print(const char *str, ...);
> >  extern void dump_machine_table(void);
> >
> > +extern void patch_uidiv(void *addr, size_t size);
> > +extern void patch_idiv(void *addr, size_t size);
> 
> Why not call things sdiv and udiv like the actual instructions?
> 

Sure. I'll fold this into v2.

-- 
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: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions

2015-11-23 Thread Stephen Boyd
On 11/23, Arnd Bergmann wrote:
> On Monday 23 November 2015 12:38:47 Stephen Boyd wrote:
> > On 11/23, Arnd Bergmann wrote:
> > > On Monday 23 November 2015 09:14:39 Christopher Covington wrote:
> > > > On 11/23/2015 03:15 AM, Arnd Bergmann wrote:
> > > > LPAE is only supported in the Krait 450.
> > > > 
> > > > http://www.anandtech.com/show/7537/qualcomms-snapdragon-805-25ghz-128bit-memory-interface-d3d11class-graphics-more
> > > > 
> > > > I'm pretty sure idiv support came earlier, but I don't have the
> > > > specifics on hand.
> > > 
> > > I have seen that article, but didn't trust it as a canonical
> > > source of information here.
> > > 
> > > If you can confirm that it's right, that would mean that we
> > > don't support LPAE on mach-qcom, as the only SoC with Krait 450
> > > seems to be APQ8084, and mainline Linux doesn't run on that.
> > 
> > arch/arm/boot/dts/qcom-apq8084.dtsi exists in the mainline
> > kernel. We support more than what's in the Kconfig language
> > under mach-qcom.
> 
> Ok, cool. I'm sometimes confused by the model numbers, could you
> do a separate patch to update the Kconfig help text?

What did you have in mind? I'm also confused by the model numbers
so I don't know how helpful I will be.

It would be nice to drop the ARCH_MSM* configs entirely. If we
could select the right timers from kconfig without using selects
then we could drop them. Or we could just select both types of
timers when building qcom platforms.

> 
> > > The ones we do support are MSM8x60 (Scorpion), MSM8960
> > > (Krait-without-number),and MSM7874 (Krait 400). Do those all
> > > support IDIV but not LPAE?
> > > 
> > 
> > Krait supports IDIV for all versions. Scorpion doesn't support
> > IDIV or lpae. Here's the output of /proc/cpuinfo on that device. 
> > 
> > # cat /proc/cpuinfo
> > processor   : 0
> > model name  : ARMv7 Processor rev 2 (v7l)
> > BogoMIPS: 13.50
> > Features: half thumb fastmult vfp edsp neon vfpv3 tls vfpd32
> > CPU implementer : 0x51
> > CPU architecture: 7
> > CPU variant : 0x0
> > CPU part: 0x02d
> > CPU revision: 2
> 
> Ok, that leaves just one missing puzzle piece: can you confirm that
> no supported Krait variant other than Krait 450 / apq8084 has LPAE?
> 

Right, apq8084 is the only SoC with a Krait CPU that supports
LPAE.

-- 
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: [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: <devicet...@vger.kernel.org>
> > Cc: "Ivan T. Ivanov" <iiva...@mm-sol.com>
> > Cc: Bjorn Andersson <bjorn.anders...@sonymobile.com>
> > Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
> > ---
> 
> 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 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 <khil...@linaro.org>
> Cc: Simon Arlott <si...@fire.lp0.eu>
> Cc: Mark Brown <broo...@kernel.org>
> Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
> ---

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 <rna...@codeaurora.org>
Cc: Kevin Hilman <khil...@linaro.org>
Cc: Tyler Baker <tyler.ba...@linaro.org>
Cc: Simon Arlott <si...@fire.lp0.eu>
Cc: Mark Brown <broo...@kernel.org>
Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
---
 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 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 <sb...@codeaurora.org>
---
 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 <sb...@codeaurora.org>
---
 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


[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 <sb...@codeaurora.org>
---
 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 <sb...@codeaurora.org>
---
 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 <sb...@codeaurora.org>
---
 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


[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 <kwest...@codeaurora.org>
Cc: Kevin Hilman <khil...@linaro.org>
Cc: Tyler Baker <tyler.ba...@linaro.org>
Cc: Simon Arlott <si...@fire.lp0.eu>
Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
---
 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


[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 <n...@fluxnic.net>
Cc: Arnd Bergmann <a...@arndb.de>
Cc: Steven Rostedt <rost...@goodmis.org>
Cc: Måns Rullgård <m...@mansr.com>
Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
---
 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;
+
+   shn

[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 <n...@fluxnic.net>
Cc: Arnd Bergmann <a...@arndb.de>
Cc: Steven Rostedt <rost...@goodmis.org>
Cc: Måns Rullgård <m...@mansr.com>

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 <n...@fluxnic.net>
Cc: Arnd Bergmann <a...@arndb.de>
Cc: Steven Rostedt <rost...@goodmis.org>
Cc: Måns Rullgård <m...@mansr.com>
Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
---
 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);

[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 <n...@fluxnic.net>
Cc: Arnd Bergmann <a...@arndb.de>
Cc: Steven Rostedt <rost...@goodmis.org>
Cc: Måns Rullgård <m...@mansr.com>
Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
---
 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;
}
 
dif

[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: <devicet...@vger.kernel.org>
Cc: "Ivan T. Ivanov" <iiva...@mm-sol.com>
Cc: Bjorn Andersson <bjorn.anders...@sonymobile.com>
Cc: Rob Herring <r...@kernel.org>
Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
---
 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] pinctrl: qcom: pmic-gpio/mpp: of_irq_count() == npins

2015-11-18 Thread Stephen Boyd
The number of interrupts is always equal to the number of pins
provided by the PMIC gpio and MPP hardware blocks. Count the
number of irqs to figure out the number of pins instead of adding
more compatible strings or doing math on the reg property. This
should make the code more generic and ease the number of changes
we have to make to the driver for each new pmic revision.

Cc: "Ivan T. Ivanov" <iiva...@mm-sol.com>
Cc: Bjorn Andersson <bjorn.anders...@sonymobile.com>
Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
---

Stephen Boyd wrote:
> We can also figure out the number of the pins from the number
> of interrupts, so we really don't need to even look at the size of the
> reg property or model number for the spmi and ssbi modules. I'll propose
> that change as well tomorrow.

And here's that change. It can be squashed together if desired.

 drivers/pinctrl/qcom/pinctrl-spmi-gpio.c | 12 ++--
 drivers/pinctrl/qcom/pinctrl-spmi-mpp.c  | 11 ++-
 drivers/pinctrl/qcom/pinctrl-ssbi-gpio.c | 16 ++--
 drivers/pinctrl/qcom/pinctrl-ssbi-mpp.c  | 16 ++--
 4 files changed, 32 insertions(+), 23 deletions(-)

diff --git a/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c 
b/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
index 9f9979903fcb..cceda6afe280 100644
--- a/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
+++ b/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -693,16 +694,15 @@ static int pmic_gpio_probe(struct platform_device *pdev)
struct pmic_gpio_pad *pad, *pads;
struct pmic_gpio_state *state;
int ret, npins, i;
-   u32 res[2];
+   u32 reg;
 
-   ret = of_property_read_u32_array(dev->of_node, "reg", res, 2);
+   ret = of_property_read_u32(dev->of_node, "reg", );
if (ret < 0) {
-   dev_err(dev, "missing base address and/or range");
+   dev_err(dev, "missing base address");
return ret;
}
 
-   npins = res[1] / PMIC_GPIO_ADDRESS_RANGE;
-
+   npins = of_irq_count(dev->of_node);
if (!npins)
return -EINVAL;
 
@@ -752,7 +752,7 @@ static int pmic_gpio_probe(struct platform_device *pdev)
if (pad->irq < 0)
return pad->irq;
 
-   pad->base = res[0] + i * PMIC_GPIO_ADDRESS_RANGE;
+   pad->base = reg + i * PMIC_GPIO_ADDRESS_RANGE;
 
ret = pmic_gpio_populate(state, pad);
if (ret < 0)
diff --git a/drivers/pinctrl/qcom/pinctrl-spmi-mpp.c 
b/drivers/pinctrl/qcom/pinctrl-spmi-mpp.c
index 5a4373dd9c61..b4512309 100644
--- a/drivers/pinctrl/qcom/pinctrl-spmi-mpp.c
+++ b/drivers/pinctrl/qcom/pinctrl-spmi-mpp.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -795,15 +796,15 @@ static int pmic_mpp_probe(struct platform_device *pdev)
struct pmic_mpp_pad *pad, *pads;
struct pmic_mpp_state *state;
int ret, npins, i;
-   u32 res[2];
+   u32 reg;
 
-   ret = of_property_read_u32_array(dev->of_node, "reg", res, 2);
+   ret = of_property_read_u32(dev->of_node, "reg", );
if (ret < 0) {
-   dev_err(dev, "missing base address and/or range");
+   dev_err(dev, "missing base address");
return ret;
}
 
-   npins = res[1] / PMIC_MPP_ADDRESS_RANGE;
+   npins = of_irq_count(dev->of_node);
if (!npins)
return -EINVAL;
 
@@ -854,7 +855,7 @@ static int pmic_mpp_probe(struct platform_device *pdev)
if (pad->irq < 0)
return pad->irq;
 
-   pad->base = res[0] + i * PMIC_MPP_ADDRESS_RANGE;
+   pad->base = reg + i * PMIC_MPP_ADDRESS_RANGE;
 
ret = pmic_mpp_populate(state, pad);
if (ret < 0)
diff --git a/drivers/pinctrl/qcom/pinctrl-ssbi-gpio.c 
b/drivers/pinctrl/qcom/pinctrl-ssbi-gpio.c
index d809c9eaa323..78fa2281116d 100644
--- a/drivers/pinctrl/qcom/pinctrl-ssbi-gpio.c
+++ b/drivers/pinctrl/qcom/pinctrl-ssbi-gpio.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -650,11 +651,12 @@ static int pm8xxx_pin_populate(struct pm8xxx_gpio *pctrl,
 }
 
 static const struct of_device_id pm8xxx_gpio_of_match[] = {
-   { .compatible = "qcom,pm8018-gpio", .data = (void *)6 },
-   { .compatible = "qcom,pm8038-gpio", .data = (void *)12 },
-   { .compatible = "qcom,pm8058-gpio", .data = (void *)40 },
-   { .compatible = "qcom,pm8917-gpio", .data = (void *)38 },
-   { .compatible = "qcom,pm8921-gpio", .data = (void *)44 },
+   { .compatible = "qcom,pm80

Re: [PATCH 2/4] arm64: dts: Add msm8996 SoC and MTP board support

2015-11-18 Thread Stephen Boyd
On 11/17/2015 09:06 PM, kbuild test robot wrote:
> Hi Stephen,
>
> [auto build test ERROR on robh/for-next]
> [also build test ERROR on v4.4-rc1 next-20151117]
>
> url:
> https://github.com/0day-ci/linux/commits/Stephen-Boyd/devicetree-bindings-Document-Kryo-cpu/20151118-091558
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux for-next
> config: arm64-allmodconfig (attached as .config)
> reproduce:
> wget 
> https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
>  -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=arm64 
>
> All errors (new ones prefixed by >>):
>
>In file included from arch/arm64/boot/dts/qcom/msm8996-mtp.dtsi:14:0,
> from arch/arm64/boot/dts/qcom/msm8996-mtp.dts:16:
>>> arch/arm64/boot/dts/qcom/msm8996.dtsi:14:48: fatal error: 
>>> dt-bindings/clock/qcom,gcc-msm8996.h: No such file or directory
> #include 
>^
>compilation terminated.
>

Yes. These patches depend on the clk patches that expose that header
file. We'll have to pull in the clock branch underneath the dts branch.

-- 
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 5/5] clk: qcom: Add MSM8996 Multimedia Clock Controller (MMCC) driver

2015-11-18 Thread Stephen Boyd
On 11/17, Stephen Boyd wrote:
> +static struct clk_alpha_pll mmpll0_early = {
> + .offset = 0x0,
> + .vco_table = mmpll_p_vco,
> + .num_vco = ARRAY_SIZE(mmpll_p_vco),
> + .clkr.hw.init = &(struct clk_init_data){
> + .name = "mmpll0_early",
> + .parent_names = (const char *[]){ "xo" },
> + .num_parents = 1,
> + .ops = _alpha_pll_ops,
> + },
> +};
> +
> +static struct clk_alpha_pll_postdiv mmpll0 = {
> + .offset = 0x0,
> + .width = 4,
> + .clkr.hw.init = &(struct clk_init_data){
> + .name = "mmpll0",
> + .parent_names = (const char *[]){ "mmpll0_early" },
> + .num_parents = 1,
> + .ops = _alpha_pll_postdiv_ops,
> + .flags = CLK_SET_RATE_PARENT,
> + },
> +};
> +
> +static struct clk_alpha_pll mmpll1_early = {
> + .offset = 0x30,
> + .vco_table = mmpll_p_vco,
> + .num_vco = ARRAY_SIZE(mmpll_p_vco),
> + .clkr.hw.init = &(struct clk_init_data){
> + .name = "mmpll1_early",
> + .parent_names = (const char *[]){ "xo" },
> + .num_parents = 1,
> + .ops = _alpha_pll_ops,
> + },
> +};
> +
> +static struct clk_alpha_pll_postdiv mmpll1 = {
> + .offset = 0x30,
> + .width = 4,
> + .clkr.hw.init = &(struct clk_init_data){
> + .name = "mmpll1",
> + .parent_names = (const char *[]){ "mmpll1_early" },
> + .num_parents = 1,
> + .ops = _alpha_pll_postdiv_ops,
> + .flags = CLK_SET_RATE_PARENT,
> + },
> +};

These are missing the .enable_reg and .enable_mask members to do
the proper FSM voting. I'll add that in v2.

-- 
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] mfd: qcom-spmi-pmic: Don't access non-existing registers

2015-11-17 Thread Stephen Boyd
From: "Ivan T. Ivanov" <ivan.iva...@linaro.org>

Revision ID registers are available only on devices with
Slave IDs that are even, so don't make access to unavailable
registers.

Signed-off-by: Ivan T. Ivanov <ivan.iva...@linaro.org>
[sb...@codeaurora.org: Consider all slave ids that are even]
Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
---
 drivers/mfd/qcom-spmi-pmic.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/mfd/qcom-spmi-pmic.c b/drivers/mfd/qcom-spmi-pmic.c
index af6ac1c4b45c..8653e8b9bb4f 100644
--- a/drivers/mfd/qcom-spmi-pmic.c
+++ b/drivers/mfd/qcom-spmi-pmic.c
@@ -127,7 +127,9 @@ static int pmic_spmi_probe(struct spmi_device *sdev)
if (IS_ERR(regmap))
return PTR_ERR(regmap);
 
-   pmic_spmi_show_revid(regmap, >dev);
+   /* Only the first slave id for a PMIC contains this information */
+   if (sdev->usid % 2 == 0)
+   pmic_spmi_show_revid(regmap, >dev);
 
return of_platform_populate(root, NULL, NULL, >dev);
 }
-- 
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] spmi: pmic-arb: Support more than 128 peripherals

2015-11-17 Thread Stephen Boyd
Add support for more than 128 peripherals by taking a lazy
caching approach to the mapping tables. Instead of reading and
caching the tables at boot given some fixed size, read them and
cache them on an as needed basis. We still assume a max size of
512 peripherals, trading off some space for simplicity.

Based on a patch by Gilad Avidov <gavi...@codeaurora.org> and
Sagar Dharia <sdha...@codeaurora.org>.

Cc: Gilad Avidov <gavi...@codeaurora.org>
Cc: Sagar Dharia <sdha...@codeaurora.org>
Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
---

Changes from v1:
 * Return error from offset search if can't find a mapping

 drivers/spmi/spmi-pmic-arb.c | 153 +++
 1 file changed, 111 insertions(+), 42 deletions(-)

diff --git a/drivers/spmi/spmi-pmic-arb.c b/drivers/spmi/spmi-pmic-arb.c
index be822f7a9ce6..aca282d45421 100644
--- a/drivers/spmi/spmi-pmic-arb.c
+++ b/drivers/spmi/spmi-pmic-arb.c
@@ -10,6 +10,7 @@
  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  * GNU General Public License for more details.
  */
+#include 
 #include 
 #include 
 #include 
@@ -47,9 +48,9 @@
 #define SPMI_MAPPING_BIT_IS_1_FLAG(X)  (((X) >> 8) & 0x1)
 #define SPMI_MAPPING_BIT_IS_1_RESULT(X)(((X) >> 0) & 0xFF)
 
-#define SPMI_MAPPING_TABLE_LEN 255
 #define SPMI_MAPPING_TABLE_TREE_DEPTH  16  /* Maximum of 16-bits */
-#define PPID_TO_CHAN_TABLE_SZ  BIT(12) /* PPID is 12bit chan is 1byte*/
+#define PMIC_ARB_MAX_PPID  BIT(12) /* PPID is 12bit */
+#define PMIC_ARB_CHAN_VALIDBIT(15)
 
 /* Ownership Table */
 #define SPMI_OWNERSHIP_TABLE_REG(N)(0x0700 + (4 * (N)))
@@ -85,9 +86,7 @@ enum pmic_arb_cmd_op_code {
 };
 
 /* Maximum number of support PMIC peripherals */
-#define PMIC_ARB_MAX_PERIPHS   256
-#define PMIC_ARB_MAX_CHNL  128
-#define PMIC_ARB_PERIPH_ID_VALID   (1 << 15)
+#define PMIC_ARB_MAX_PERIPHS   512
 #define PMIC_ARB_TIMEOUT_US100
 #define PMIC_ARB_MAX_TRANS_BYTES   (8)
 
@@ -125,18 +124,22 @@ struct spmi_pmic_arb_dev {
void __iomem*wr_base;
void __iomem*intr;
void __iomem*cnfg;
+   void __iomem*core;
+   resource_size_t core_size;
raw_spinlock_t  lock;
u8  channel;
int irq;
u8  ee;
-   u8  min_apid;
-   u8  max_apid;
-   u32 mapping_table[SPMI_MAPPING_TABLE_LEN];
+   u16 min_apid;
+   u16 max_apid;
+   u32 *mapping_table;
+   DECLARE_BITMAP(mapping_table_valid, PMIC_ARB_MAX_PERIPHS);
struct irq_domain   *domain;
struct spmi_controller  *spmic;
-   u16 apid_to_ppid[256];
+   u16 *apid_to_ppid;
const struct pmic_arb_ver_ops *ver_ops;
-   u8  *ppid_to_chan;
+   u16 *ppid_to_chan;
+   u16 last_channel;
 };
 
 /**
@@ -158,7 +161,8 @@ struct spmi_pmic_arb_dev {
  */
 struct pmic_arb_ver_ops {
/* spmi commands (read_cmd, write_cmd, cmd) functionality */
-   u32 (*offset)(struct spmi_pmic_arb_dev *dev, u8 sid, u16 addr);
+   int (*offset)(struct spmi_pmic_arb_dev *dev, u8 sid, u16 addr,
+ u32 *offset);
u32 (*fmt_cmd)(u8 opc, u8 sid, u16 addr, u8 bc);
int (*non_data_cmd)(struct spmi_controller *ctrl, u8 opc, u8 sid);
/* Interrupts controller functionality (offset of PIC registers) */
@@ -212,7 +216,14 @@ static int pmic_arb_wait_for_done(struct spmi_controller 
*ctrl,
struct spmi_pmic_arb_dev *dev = spmi_controller_get_drvdata(ctrl);
u32 status = 0;
u32 timeout = PMIC_ARB_TIMEOUT_US;
-   u32 offset = dev->ver_ops->offset(dev, sid, addr) + PMIC_ARB_STATUS;
+   u32 offset;
+   int rc;
+
+   rc = dev->ver_ops->offset(dev, sid, addr, );
+   if (rc)
+   return rc;
+
+   offset += PMIC_ARB_STATUS;
 
while (timeout--) {
status = readl_relaxed(base + offset);
@@ -257,7 +268,11 @@ pmic_arb_non_data_cmd_v1(struct spmi_controller *ctrl, u8 
opc, u8 sid)
unsigned long flags;
u32 cmd;
int rc;
-   u32 offset = pmic_arb->ver_ops->offset(pmic_arb, sid, 0);
+   u32 offset;
+
+   rc = pmic_arb->ver_ops->offset(pmic_arb, sid, 0, );
+   if (rc)
+   return rc;
 
cmd = ((opc | 0x40) << 27) | ((sid & 0xf) << 20);
 
@@ -297,7 +312,11 @@ static int pmic_arb_read_cmd(struct spmi_controller *ctrl, 
u8 opc, u8 sid,
u8 bc = len - 1;
u32 cmd;
int rc;
-   u32 offset = pmic_arb->ver_ops->offset(

[PATCH] pinctrl: qcom: Add msm8996 pinctrl driver

2015-11-17 Thread Stephen Boyd
From: Joonwoo Park <joonw...@codeaurora.org>

Add initial pinctrl driver to support pin configuration with
pinctrl framework for msm8996.

Cc: <devicet...@vger.kernel.org>
Cc: Bjorn Andersson <bjorn.anders...@sonymobile.com>
Signed-off-by: Joonwoo Park <joonw...@codeaurora.org>
[sb...@codeaurora.org: Remove duplicate entries and enums]
Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
---
 .../bindings/pinctrl/qcom,msm8996-pinctrl.txt  |  199 ++
 drivers/pinctrl/qcom/Kconfig   |8 +
 drivers/pinctrl/qcom/Makefile  |1 +
 drivers/pinctrl/qcom/pinctrl-msm8996.c | 1942 
 4 files changed, 2150 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/pinctrl/qcom,msm8996-pinctrl.txt
 create mode 100644 drivers/pinctrl/qcom/pinctrl-msm8996.c

diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8996-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/qcom,msm8996-pinctrl.txt
new file mode 100644
index ..e312a71b2f94
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8996-pinctrl.txt
@@ -0,0 +1,199 @@
+Qualcomm MSM8996 TLMM block
+
+This binding describes the Top Level Mode Multiplexer block found in the
+MSM8996 platform.
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: must be "qcom,msm8996-pinctrl"
+
+- reg:
+   Usage: required
+   Value type: 
+   Definition: the base address and size of the TLMM register space.
+
+- interrupts:
+   Usage: required
+   Value type: 
+   Definition: should specify the TLMM summary IRQ.
+
+- interrupt-controller:
+   Usage: required
+   Value type: 
+   Definition: identifies this node as an interrupt controller
+
+- #interrupt-cells:
+   Usage: required
+   Value type: 
+   Definition: must be 2. Specifying the pin number and flags, as defined
+   in 
+
+- gpio-controller:
+   Usage: required
+   Value type: 
+   Definition: identifies this node as a gpio controller
+
+- #gpio-cells:
+   Usage: required
+   Value type: 
+   Definition: must be 2. Specifying the pin number and flags, as defined
+   in 
+
+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 arbitrary 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.
+
+
+PIN CONFIGURATION NODES:
+
+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:
+   Usage: required
+   Value type: 
+   Definition: List of gpio pins affected by the properties specified in
+   this subnode.
+
+   Valid pins are:
+ gpio0-gpio149
+   Supports mux, bias and drive-strength
+
+ sdc1_clk, sdc1_cmd, sdc1_data sdc2_clk, sdc2_cmd,
+ sdc2_data sdc1_rclk
+   Supports bias and drive-strength
+
+- function:
+   Usage: required
+   Value type: 
+   Definition: Specify the alternative function to be configured for the
+   specified pins. Functions are only valid for gpio pins.
+   Valid values are:
+
+   blsp_uart1, blsp_spi1, blsp_i2c1, blsp_uim1, atest_tsens,
+   bimc_dte1, dac_calib0, blsp_spi8, blsp_uart8, blsp_uim8,
+   qdss_cti_trig_out_b, bimc_dte0, dac_calib1, 
qdss_cti_trig_in_b,
+   dac_calib2, atest_tsens2, atest_usb1, blsp_spi10, 
blsp_uart10,
+   blsp_uim10, atest_bbrx1, atest_usb13, atest_bbrx0, 
atest_usb12,
+   mdp_vsync, edp_lcd, blsp_i2c10, atest_gpsadc1, atest_usb11,
+   atest_gpsadc0, edp_hot, atest_usb10, m_voc, dac_gpio, 
atest_char,
+   cam_mclk, pll_bypassnl, qdss_stm7, blsp_i2c8, 
qdss_tra

[PATCH 2/2] pinctrl: qcom: spmi-mpp: Add pm8994 mpp support

2015-11-17 Thread Stephen Boyd
Update the driver and binding for pm8994-mpp devices.

Cc: <devicet...@vger.kernel.org>
Cc: "Ivan T. Ivanov" <iiva...@mm-sol.com>
Cc: Bjorn Andersson <bjorn.anders...@sonymobile.com>
Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
---
 Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.txt | 1 +
 drivers/pinctrl/qcom/pinctrl-spmi-mpp.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.txt 
b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.txt
index d7803a2a94e9..d74e631e10da 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.txt
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.txt
@@ -15,6 +15,7 @@ of PMIC's from Qualcomm.
"qcom,pm8917-mpp",
"qcom,pm8921-mpp",
"qcom,pm8941-mpp",
+   "qcom,pm8994-mpp",
"qcom,pma8084-mpp",
 
 - reg:
diff --git a/drivers/pinctrl/qcom/pinctrl-spmi-mpp.c 
b/drivers/pinctrl/qcom/pinctrl-spmi-mpp.c
index 9ce0e30e33e8..7b4136a22c5b 100644
--- a/drivers/pinctrl/qcom/pinctrl-spmi-mpp.c
+++ b/drivers/pinctrl/qcom/pinctrl-spmi-mpp.c
@@ -907,6 +907,7 @@ static const struct of_device_id pmic_mpp_of_match[] = {
{ .compatible = "qcom,pm8841-mpp" },/* 4 MPP's */
{ .compatible = "qcom,pm8916-mpp" },/* 4 MPP's */
{ .compatible = "qcom,pm8941-mpp" },/* 8 MPP's */
+   { .compatible = "qcom,pm8994-mpp" },/* 8 MPP's */
{ .compatible = "qcom,pma8084-mpp" },   /* 8 MPP's */
{ },
 };
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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


[PATCH 0/2] Add pm8994 gpio and mpp support

2015-11-17 Thread Stephen Boyd
This adds the support for pm8994 gpio and mpp modules. Given that there's
nothing besides a compatible string update, I'm going to send a separate
patch to add generic compatible strings for these sorts of things.

Stephen Boyd (2):
  pinctrl: qcom: spmi-gpio: Add pm8994 gpio support
  pinctrl: qcom: spmi-mpp: Add pm8994 mpp support

Cc: <devicet...@vger.kernel.org>
Cc: "Ivan T. Ivanov" <iiva...@mm-sol.com>
Cc: Bjorn Andersson <bjorn.anders...@sonymobile.com>

 Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt | 2 ++
 Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.txt  | 1 +
 drivers/pinctrl/qcom/pinctrl-spmi-gpio.c | 1 +
 drivers/pinctrl/qcom/pinctrl-spmi-mpp.c  | 1 +
 4 files changed, 5 insertions(+)

-- 
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 1/2] pinctrl: qcom: spmi-gpio: Add pm8994 gpio support

2015-11-17 Thread Stephen Boyd
Update the binding and driver for pm8994-gpio devices.

Cc: <devicet...@vger.kernel.org>
Cc: "Ivan T. Ivanov" <iiva...@mm-sol.com>
Cc: Bjorn Andersson <bjorn.anders...@sonymobile.com>
Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
---
 Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt | 2 ++
 drivers/pinctrl/qcom/pinctrl-spmi-gpio.c | 1 +
 2 files changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt 
b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt
index 1ae63c0acd40..a90c812ad642 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt
@@ -14,6 +14,7 @@ PMIC's from Qualcomm.
"qcom,pm8917-gpio"
"qcom,pm8921-gpio"
"qcom,pm8941-gpio"
+   "qcom,pm8994-gpio"
"qcom,pma8084-gpio"
 
 - reg:
@@ -79,6 +80,7 @@ to specify in a pin configuration subnode:
gpio1-gpio38 for pm8917
gpio1-gpio44 for pm8921
gpio1-gpio36 for pm8941
+   gpio1-gpio22 for pm8994
gpio1-gpio22 for pma8084
 
 - function:
diff --git a/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c 
b/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
index 6c42ca14d2fd..df4413023e21 100644
--- a/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
+++ b/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
@@ -804,6 +804,7 @@ static int pmic_gpio_remove(struct platform_device *pdev)
 static const struct of_device_id pmic_gpio_of_match[] = {
{ .compatible = "qcom,pm8916-gpio" },   /* 4 GPIO's */
{ .compatible = "qcom,pm8941-gpio" },   /* 36 GPIO's */
+   { .compatible = "qcom,pm8994-gpio" },   /* 22 GPIO's */
{ .compatible = "qcom,pma8084-gpio" },  /* 22 GPIO's */
{ },
 };
-- 
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] pinctrl: qcom: Add generic ssbi and spmi GPIO/MPP bindings

2015-11-17 Thread Stephen Boyd
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: <devicet...@vger.kernel.org>
Cc: "Ivan T. Ivanov" <iiva...@mm-sol.com>
Cc: Bjorn Andersson <bjorn.anders...@sonymobile.com>
Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
---

We can also figure out the number of the pins from the number
of interrupts, so we really don't need to even look at the size of the
reg property or model number for the spmi and ssbi modules. I'll propose
that change as well tomorrow.

 Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt | 5 -
 Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.txt  | 5 -
 drivers/pinctrl/qcom/pinctrl-spmi-gpio.c | 1 +
 drivers/pinctrl/qcom/pinctrl-spmi-mpp.c  | 1 +
 4 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt 
b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt
index a90c812ad642..f1e4643f4132 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt
@@ -17,6 +17,9 @@ PMIC's from Qualcomm.
"qcom,pm8994-gpio"
"qcom,pma8084-gpio"
 
+   And must contain either "qcom,spmi-gpio" or "qcom,ssbi-gpio"
+   if the device is on an spmi bus or an ssbi bus respectively
+
 - reg:
Usage: required
Value type: 
@@ -183,7 +186,7 @@ to specify in a pin configuration subnode:
 Example:
 
pm8921_gpio: gpio@150 {
-   compatible = "qcom,pm8921-gpio";
+   compatible = "qcom,pm8921-gpio", "qcom,ssbi-gpio";
reg = <0x150 0x160>;
interrupts = <192 1>, <193 1>, <194 1>,
 <195 1>, <196 1>, <197 1>,
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.txt 
b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.txt
index d74e631e10da..e28320b18ecb 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.txt
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.txt
@@ -18,6 +18,9 @@ of PMIC's from Qualcomm.
"qcom,pm8994-mpp",
"qcom,pma8084-mpp",
 
+   And must contain either "qcom,spmi-mpp" or "qcom,ssbi-mpp"
+   if the device is on an spmi bus or an ssbi bus respectively.
+
 - reg:
Usage: required
Value type: 
@@ -157,7 +160,7 @@ to specify in a pin configuration subnode:
 Example:
 
mpps@a000 {
-   compatible = "qcom,pm8841-mpp";
+   compatible = "qcom,pm8841-mpp", "qcom,spmi-mpp";
reg = <0xa000>;
gpio-controller;
#gpio-cells = <2>;
diff --git a/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c 
b/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
index df4413023e21..9f9979903fcb 100644
--- a/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
+++ b/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
@@ -806,6 +806,7 @@ static const struct of_device_id pmic_gpio_of_match[] = {
{ .compatible = "qcom,pm8941-gpio" },   /* 36 GPIO's */
{ .compatible = "qcom,pm8994-gpio" },   /* 22 GPIO's */
{ .compatible = "qcom,pma8084-gpio" },  /* 22 GPIO's */
+   { .compatible = "qcom,spmi-gpio" }, /* Generic */
{ },
 };
 
diff --git a/drivers/pinctrl/qcom/pinctrl-spmi-mpp.c 
b/drivers/pinctrl/qcom/pinctrl-spmi-mpp.c
index 7b4136a22c5b..5a4373dd9c61 100644
--- a/drivers/pinctrl/qcom/pinctrl-spmi-mpp.c
+++ b/drivers/pinctrl/qcom/pinctrl-spmi-mpp.c
@@ -909,6 +909,7 @@ static const struct of_device_id pmic_mpp_of_match[] = {
{ .compatible = "qcom,pm8941-mpp" },/* 8 MPP's */
{ .compatible = "qcom,pm8994-mpp" },/* 8 MPP's */
{ .compatible = "qcom,pma8084-mpp" },   /* 8 MPP's */
+   { .compatible = "qcom,spmi-mpp" },  /* Generic */
{ },
 };
 
-- 
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/5] clk: qcom: Add gfx3d ping-pong PLL frequency switching

2015-11-17 Thread Stephen Boyd
The GPU clocks on msm8996 have three dedicated PLLs, MMPLL2,
MMPLL8, and MMPLL9. We leave MMPLL9 at the maximum speed (624
MHz), and we use MMPLL2 and MMPLL8 for the other frequencies. To
make switching frequencies faster, we ping-pong between MMPLL2
and MMPLL8 when we're switching between frequencies that aren't
the maximum. Implement custom rcg clk ops for this type of
frequency switching.

Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
---
 drivers/clk/qcom/clk-rcg.h  |  1 +
 drivers/clk/qcom/clk-rcg2.c | 87 +
 2 files changed, 88 insertions(+)

diff --git a/drivers/clk/qcom/clk-rcg.h b/drivers/clk/qcom/clk-rcg.h
index 4b1e94bdf29e..b904c335cda4 100644
--- a/drivers/clk/qcom/clk-rcg.h
+++ b/drivers/clk/qcom/clk-rcg.h
@@ -178,5 +178,6 @@ extern const struct clk_ops clk_edp_pixel_ops;
 extern const struct clk_ops clk_byte_ops;
 extern const struct clk_ops clk_byte2_ops;
 extern const struct clk_ops clk_pixel_ops;
+extern const struct clk_ops clk_gfx3d_ops;
 
 #endif
diff --git a/drivers/clk/qcom/clk-rcg2.c b/drivers/clk/qcom/clk-rcg2.c
index b544bb302f79..a071bba8018c 100644
--- a/drivers/clk/qcom/clk-rcg2.c
+++ b/drivers/clk/qcom/clk-rcg2.c
@@ -723,3 +723,90 @@ const struct clk_ops clk_pixel_ops = {
.determine_rate = clk_pixel_determine_rate,
 };
 EXPORT_SYMBOL_GPL(clk_pixel_ops);
+
+static int clk_gfx3d_determine_rate(struct clk_hw *hw,
+   struct clk_rate_request *req)
+{
+   struct clk_rate_request parent_req = { };
+   struct clk_hw *p2, *p8, *p9, *xo;
+   unsigned long p9_rate;
+   int ret;
+
+   xo = clk_hw_get_parent_by_index(hw, 0);
+   if (req->rate == clk_hw_get_rate(xo)) {
+   req->best_parent_hw = xo;
+   return 0;
+   }
+
+   p9 = clk_hw_get_parent_by_index(hw, 2);
+   p2 = clk_hw_get_parent_by_index(hw, 3);
+   p8 = clk_hw_get_parent_by_index(hw, 4);
+
+   /* PLL9 is a fixed rate PLL */
+   p9_rate = clk_hw_get_rate(p9);
+
+   parent_req.rate = req->rate = min(req->rate, p9_rate);
+   if (req->rate == p9_rate) {
+   req->rate = req->best_parent_rate = p9_rate;
+   req->best_parent_hw = p9;
+   return 0;
+   }
+
+   if (req->best_parent_hw == p9) {
+   /* Are we going back to a previously used rate? */
+   if (clk_hw_get_rate(p8) == req->rate)
+   req->best_parent_hw = p8;
+   else
+   req->best_parent_hw = p2;
+   } else if (req->best_parent_hw == p8) {
+   req->best_parent_hw = p2;
+   } else {
+   req->best_parent_hw = p8;
+   }
+
+   ret = __clk_determine_rate(req->best_parent_hw, _req);
+   if (ret)
+   return ret;
+
+   req->rate = req->best_parent_rate = parent_req.rate;
+
+   return 0;
+}
+
+static int clk_gfx3d_set_rate_and_parent(struct clk_hw *hw, unsigned long rate,
+   unsigned long parent_rate, u8 index)
+{
+   struct clk_rcg2 *rcg = to_clk_rcg2(hw);
+   u32 cfg;
+   int ret;
+
+   /* Just mux it, we don't use the division or m/n hardware */
+   cfg = rcg->parent_map[index].cfg << CFG_SRC_SEL_SHIFT;
+   ret = regmap_write(rcg->clkr.regmap, rcg->cmd_rcgr + CFG_REG, cfg);
+   if (ret)
+   return ret;
+
+   return update_config(rcg);
+}
+
+static int clk_gfx3d_set_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long parent_rate)
+{
+   /*
+* We should never get here; clk_gfx3d_determine_rate() should always
+* make us use a different parent than what we're currently using, so
+* clk_gfx3d_set_rate_and_parent() should always be called.
+*/
+   return 0;
+}
+
+const struct clk_ops clk_gfx3d_ops = {
+   .is_enabled = clk_rcg2_is_enabled,
+   .get_parent = clk_rcg2_get_parent,
+   .set_parent = clk_rcg2_set_parent,
+   .recalc_rate = clk_rcg2_recalc_rate,
+   .set_rate = clk_gfx3d_set_rate,
+   .set_rate_and_parent = clk_gfx3d_set_rate_and_parent,
+   .determine_rate = clk_gfx3d_determine_rate,
+};
+EXPORT_SYMBOL_GPL(clk_gfx3d_ops);
-- 
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 1/5] clk: divider: Cap table divider values to 'width' member

2015-11-17 Thread Stephen Boyd
When we use a clk divider with a divider table, we limit the
maximum divider value in divider_get_val() to the
div_mask(width), but when we calculate the divider in
divider_round_rate() we don't consider that the maximum divider
may be limited by the width. Pass the width along to
_get_table_maxdiv() so that we only return the maximum divider
that is valid. This is useful for clocks that want to share the
same divider table while limiting the available dividers to some
subset of the table depending on the width of the bitfield.

Cc: Rajendra Nayak <rna...@codeaurora.com>
Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
---
 drivers/clk/clk-divider.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index 3ace102a2a0a..ded3ff4b91b9 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -32,13 +32,14 @@
 
 #define div_mask(width)((1 << (width)) - 1)
 
-static unsigned int _get_table_maxdiv(const struct clk_div_table *table)
+static unsigned int _get_table_maxdiv(const struct clk_div_table *table,
+ u8 width)
 {
-   unsigned int maxdiv = 0;
+   unsigned int maxdiv = 0, mask = div_mask(width);
const struct clk_div_table *clkt;
 
for (clkt = table; clkt->div; clkt++)
-   if (clkt->div > maxdiv)
+   if (clkt->div > maxdiv && clkt->val <= mask)
maxdiv = clkt->div;
return maxdiv;
 }
@@ -62,7 +63,7 @@ static unsigned int _get_maxdiv(const struct clk_div_table 
*table, u8 width,
if (flags & CLK_DIVIDER_POWER_OF_TWO)
return 1 << div_mask(width);
if (table)
-   return _get_table_maxdiv(table);
+   return _get_table_maxdiv(table, width);
return div_mask(width) + 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 2/5] clk: qcom: Add Alpha PLL support

2015-11-17 Thread Stephen Boyd
Add support for configuring rates of, enabling, and disabling
Alpha PLLs. This is sufficient for the types of PLLs found in
the global and multimedia clock controllers.

Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
---
 drivers/clk/qcom/Makefile|   1 +
 drivers/clk/qcom/clk-alpha-pll.c | 355 +++
 drivers/clk/qcom/clk-alpha-pll.h |  57 +++
 3 files changed, 413 insertions(+)
 create mode 100644 drivers/clk/qcom/clk-alpha-pll.c
 create mode 100644 drivers/clk/qcom/clk-alpha-pll.h

diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index fe6252349e55..472200040788 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -2,6 +2,7 @@ obj-$(CONFIG_COMMON_CLK_QCOM) += clk-qcom.o
 
 clk-qcom-y += common.o
 clk-qcom-y += clk-regmap.o
+clk-qcom-y += clk-alpha-pll.o
 clk-qcom-y += clk-pll.o
 clk-qcom-y += clk-rcg.o
 clk-qcom-y += clk-rcg2.o
diff --git a/drivers/clk/qcom/clk-alpha-pll.c b/drivers/clk/qcom/clk-alpha-pll.c
new file mode 100644
index ..e6a03eaf7a93
--- /dev/null
+++ b/drivers/clk/qcom/clk-alpha-pll.c
@@ -0,0 +1,355 @@
+/*
+ * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "clk-alpha-pll.h"
+
+#define PLL_MODE   0x00
+# define PLL_OUTCTRL   BIT(0)
+# define PLL_BYPASSNL  BIT(1)
+# define PLL_RESET_N   BIT(2)
+# define PLL_LOCK_COUNT_SHIFT  8
+# define PLL_LOCK_COUNT_MASK   0x3f
+# define PLL_BIAS_COUNT_SHIFT  14
+# define PLL_BIAS_COUNT_MASK   0x3f
+# define PLL_VOTE_FSM_ENA  BIT(20)
+# define PLL_VOTE_FSM_RESETBIT(21)
+# define PLL_ACTIVE_FLAG   BIT(30)
+# define PLL_LOCK_DET  BIT(31)
+
+#define PLL_L_VAL  0x04
+#define PLL_ALPHA_VAL  0x08
+#define PLL_ALPHA_VAL_U0x0c
+
+#define PLL_USER_CTL   0x10
+# define PLL_POST_DIV_SHIFT8
+# define PLL_POST_DIV_MASK 0xf
+# define PLL_ALPHA_EN  BIT(24)
+# define PLL_VCO_SHIFT 20
+# define PLL_VCO_MASK  0x3
+
+#define PLL_USER_CTL_U 0x14
+
+#define PLL_CONFIG_CTL 0x18
+#define PLL_TEST_CTL   0x1c
+#define PLL_TEST_CTL_U 0x20
+#define PLL_STATUS 0x24
+
+/*
+ * Even though 40 bits are present, use only 32 for ease of calculation.
+ */
+#define ALPHA_REG_BITWIDTH 40
+#define ALPHA_BITWIDTH 32
+
+#define to_clk_alpha_pll(_hw) container_of(to_clk_regmap(_hw), \
+  struct clk_alpha_pll, clkr)
+
+#define to_clk_alpha_pll_postdiv(_hw) container_of(to_clk_regmap(_hw), \
+  struct clk_alpha_pll_postdiv, clkr)
+
+static int wait_for_pll(struct clk_alpha_pll *pll)
+{
+   u32 val, mask, off;
+   int count;
+   int ret;
+   const char *name = clk_hw_get_name(>clkr.hw);
+
+   off = pll->offset;
+   ret = regmap_read(pll->clkr.regmap, off + PLL_MODE, );
+   if (ret)
+   return ret;
+
+   if (val & PLL_VOTE_FSM_ENA)
+   mask = PLL_ACTIVE_FLAG;
+   else
+   mask = PLL_LOCK_DET;
+
+   /* Wait for pll to enable. */
+   for (count = 100; count > 0; count--) {
+   ret = regmap_read(pll->clkr.regmap, off + PLL_MODE, );
+   if (ret)
+   return ret;
+   if ((val & mask) == mask)
+   return 0;
+
+   udelay(1);
+   }
+
+   WARN(1, "%s didn't enable after voting for it!\n", name);
+   return -ETIMEDOUT;
+}
+
+static int clk_alpha_pll_enable(struct clk_hw *hw)
+{
+   int ret;
+   struct clk_alpha_pll *pll = to_clk_alpha_pll(hw);
+   u32 val, mask, off;
+
+   off = pll->offset;
+
+   mask = PLL_OUTCTRL | PLL_RESET_N | PLL_BYPASSNL;
+   ret = regmap_read(pll->clkr.regmap, off + PLL_MODE, );
+   if (ret)
+   return ret;
+
+   /* If in FSM mode, just vote for it */
+   if (val & PLL_VOTE_FSM_ENA) {
+   ret = clk_enable_regmap(hw);
+   if (ret)
+   return ret;
+   return wait_for_pll(pll);
+   }
+
+   /* Skip if already enabled */
+   if ((val & mask) == mask)
+   return 0;
+
+   ret = regmap_update_bits(pll->clkr.regmap, off + PLL_MODE,
+PLL_BYPASSNL, PLL_BYPASSNL);
+   if (ret)
+   

[PATCH 4/4] arm64: dts: qcom: Add pm8994 gpios and MPPs

2015-11-17 Thread Stephen Boyd
Add the gpio and MPP devices to the pm8994 pmic dts.

Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
---
 arch/arm64/boot/dts/qcom/pm8994.dtsi | 43 
 1 file changed, 43 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/pm8994.dtsi 
b/arch/arm64/boot/dts/qcom/pm8994.dtsi
index e61b376f0b7c..1732f1d32f4c 100644
--- a/arch/arm64/boot/dts/qcom/pm8994.dtsi
+++ b/arch/arm64/boot/dts/qcom/pm8994.dtsi
@@ -8,6 +8,49 @@
reg = <0x0 SPMI_USID>;
#address-cells = <1>;
#size-cells = <0>;
+
+   pm8994_gpios: gpios@c000 {
+   compatible = "qcom,pm8994-gpio";
+   reg = <0xc000 0x1500>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   interrupts = <0 0xc0 0 IRQ_TYPE_NONE>,
+<0 0xc1 0 IRQ_TYPE_NONE>,
+<0 0xc2 0 IRQ_TYPE_NONE>,
+<0 0xc3 0 IRQ_TYPE_NONE>,
+<0 0xc4 0 IRQ_TYPE_NONE>,
+<0 0xc5 0 IRQ_TYPE_NONE>,
+<0 0xc6 0 IRQ_TYPE_NONE>,
+<0 0xc7 0 IRQ_TYPE_NONE>,
+<0 0xc8 0 IRQ_TYPE_NONE>,
+<0 0xc9 0 IRQ_TYPE_NONE>,
+<0 0xca 0 IRQ_TYPE_NONE>,
+<0 0xcb 0 IRQ_TYPE_NONE>,
+<0 0xcc 0 IRQ_TYPE_NONE>,
+<0 0xcd 0 IRQ_TYPE_NONE>,
+<0 0xce 0 IRQ_TYPE_NONE>,
+<0 0xd0 0 IRQ_TYPE_NONE>,
+<0 0xd1 0 IRQ_TYPE_NONE>,
+<0 0xd2 0 IRQ_TYPE_NONE>,
+<0 0xd3 0 IRQ_TYPE_NONE>,
+<0 0xd4 0 IRQ_TYPE_NONE>,
+<0 0xd5 0 IRQ_TYPE_NONE>;
+   };
+
+   pm8994_mpps: mpps@a000 {
+   compatible = "qcom,pm8994-mpp";
+   reg = <0xa000 0x700>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   interrupts = <0 0xa0 0 IRQ_TYPE_NONE>,
+<0 0xa1 0 IRQ_TYPE_NONE>,
+<0 0xa2 0 IRQ_TYPE_NONE>,
+<0 0xa3 0 IRQ_TYPE_NONE>,
+<0 0xa4 0 IRQ_TYPE_NONE>,
+<0 0xa5 0 IRQ_TYPE_NONE>,
+<0 0xa6 0 IRQ_TYPE_NONE>,
+<0 0xa7 0 IRQ_TYPE_NONE>;
+   };
};
 
pmic@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 5/5] clk: qcom: Add MSM8996 Multimedia Clock Controller (MMCC) driver

2015-11-17 Thread Stephen Boyd
Add a driver for the multimedia clock controller found on MSM8996
based devices. This should allow most multimedia device drivers
to probe and control their clocks.

Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
---
 .../devicetree/bindings/clock/qcom,mmcc.txt|1 +
 drivers/clk/qcom/Kconfig   |9 +
 drivers/clk/qcom/Makefile  |1 +
 drivers/clk/qcom/mmcc-msm8996.c| 3209 
 include/dt-bindings/clock/qcom,mmcc-msm8996.h  |  285 ++
 5 files changed, 3505 insertions(+)
 create mode 100644 drivers/clk/qcom/mmcc-msm8996.c
 create mode 100644 include/dt-bindings/clock/qcom,mmcc-msm8996.h

diff --git a/Documentation/devicetree/bindings/clock/qcom,mmcc.txt 
b/Documentation/devicetree/bindings/clock/qcom,mmcc.txt
index 34e7614d5074..8b0f7841af8d 100644
--- a/Documentation/devicetree/bindings/clock/qcom,mmcc.txt
+++ b/Documentation/devicetree/bindings/clock/qcom,mmcc.txt
@@ -9,6 +9,7 @@ Required properties :
"qcom,mmcc-msm8660"
"qcom,mmcc-msm8960"
"qcom,mmcc-msm8974"
+   "qcom,mmcc-msm8996"
 
 - reg : shall contain base register location and length
 - #clock-cells : shall contain 1
diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
index fb2b499c647d..b552eceec2be 100644
--- a/drivers/clk/qcom/Kconfig
+++ b/drivers/clk/qcom/Kconfig
@@ -114,3 +114,12 @@ config MSM_GCC_8996
  Support for the global clock controller on msm8996 devices.
  Say Y if you want to use peripheral devices such as UART, SPI,
  i2c, USB, UFS, SD/eMMC, PCIe, etc.
+
+config MSM_MMCC_8996
+   tristate "MSM8996 Multimedia Clock Controller"
+   select MSM_GCC_8996
+   depends on COMMON_CLK_QCOM
+   help
+ Support for the multimedia clock controller on msm8996 devices.
+ Say Y if you want to support multimedia devices such as display,
+ graphics, video encode/decode, camera, etc.
diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index 42dca6799414..dc4280b85db1 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -24,3 +24,4 @@ obj-$(CONFIG_MSM_GCC_8974) += gcc-msm8974.o
 obj-$(CONFIG_MSM_GCC_8996) += gcc-msm8996.o
 obj-$(CONFIG_MSM_MMCC_8960) += mmcc-msm8960.o
 obj-$(CONFIG_MSM_MMCC_8974) += mmcc-msm8974.o
+obj-$(CONFIG_MSM_MMCC_8996) += mmcc-msm8996.o
diff --git a/drivers/clk/qcom/mmcc-msm8996.c b/drivers/clk/qcom/mmcc-msm8996.c
new file mode 100644
index ..b2329096cd7c
--- /dev/null
+++ b/drivers/clk/qcom/mmcc-msm8996.c
@@ -0,0 +1,3209 @@
+/*x
+ * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "common.h"
+#include "clk-regmap.h"
+#include "clk-regmap-divider.h"
+#include "clk-alpha-pll.h"
+#include "clk-rcg.h"
+#include "clk-branch.h"
+#include "reset.h"
+
+#define F(f, s, h, m, n) { (f), (s), (2 * (h) - 1), (m), (n) }
+
+enum {
+   P_XO,
+   P_MMPLL0,
+   P_GPLL0,
+   P_GPLL0_DIV,
+   P_MMPLL1,
+   P_MMPLL9,
+   P_MMPLL2,
+   P_MMPLL8,
+   P_MMPLL3,
+   P_DSI0PLL,
+   P_DSI1PLL,
+   P_MMPLL5,
+   P_HDMIPLL,
+   P_DSI0PLL_BYTE,
+   P_DSI1PLL_BYTE,
+   P_MMPLL4,
+};
+
+static const struct parent_map mmss_xo_hdmi_map[] = {
+   { P_XO, 0 },
+   { P_HDMIPLL, 1 }
+};
+
+static const char * const mmss_xo_hdmi[] = {
+   "xo",
+   "hdmipll"
+};
+
+static const struct parent_map mmss_xo_dsi0pll_dsi1pll_map[] = {
+   { P_XO, 0 },
+   { P_DSI0PLL, 1 },
+   { P_DSI1PLL, 2 }
+};
+
+static const char * const mmss_xo_dsi0pll_dsi1pll[] = {
+   "xo",
+   "dsi0pll",
+   "dsi1pll"
+};
+
+static const struct parent_map mmss_xo_gpll0_gpll0_div_map[] = {
+   { P_XO, 0 },
+   { P_GPLL0, 5 },
+   { P_GPLL0_DIV, 6 }
+};
+
+static const char * const mmss_xo_gpll0_gpll0_div[] = {
+   "xo",
+   "gpll0",
+   "gpll0_div"
+};
+
+static const struct parent_map mmss_xo_dsibyte_map[] = {
+   { P_XO, 0 },
+   { P_DSI0PLL_BYTE, 1 },
+   { P_DSI1PLL_BYTE, 2 }
+};
+
+static const char * co

[PATCH 0/5] Add support for MSM8996 clock controllers

2015-11-17 Thread Stephen Boyd
These patches add support for the global and multimedia clock controllers
found on MSM8996 devices. The first patch allows us to implement a
"power of two" divider of different widths with a table based divider.
The second patch adds support for Alpha PLLs and the 3rd and 5th patches
add support for the two clock controllers. The fourth patch is
a new type of clock ops for the graphics clock that does some custom
ping-pong between different PLLs when switching graphics frequencies.

Some work is still pending, mostly adding GDSCs and configuring the
multimedia PLLs for FSM voting mode vs. manually enabling and
disabling them. So a v2 is probably going to come out after
some more testing is done.

Cc: Rajendra Nayak <rna...@codeaurora.com>

Stephen Boyd (5):
  clk: divider: Cap table divider values to 'width' member
  clk: qcom: Add Alpha PLL support
  clk: qcom: Add MSM8996 Global Clock Control (GCC) driver
  clk: qcom: Add gfx3d ping-pong PLL frequency switching
  clk: qcom: Add MSM8996 Multimedia Clock Controller (MMCC) driver

 .../devicetree/bindings/clock/qcom,gcc.txt |1 +
 .../devicetree/bindings/clock/qcom,mmcc.txt|1 +
 drivers/clk/clk-divider.c  |9 +-
 drivers/clk/qcom/Kconfig   |   17 +
 drivers/clk/qcom/Makefile  |3 +
 drivers/clk/qcom/clk-alpha-pll.c   |  355 +++
 drivers/clk/qcom/clk-alpha-pll.h   |   57 +
 drivers/clk/qcom/clk-rcg.h |1 +
 drivers/clk/qcom/clk-rcg2.c|   87 +
 drivers/clk/qcom/gcc-msm8996.c | 3332 
 drivers/clk/qcom/mmcc-msm8996.c| 3209 +++
 include/dt-bindings/clock/qcom,gcc-msm8996.h   |  333 ++
 include/dt-bindings/clock/qcom,mmcc-msm8996.h  |  285 ++
 13 files changed, 7686 insertions(+), 4 deletions(-)
 create mode 100644 drivers/clk/qcom/clk-alpha-pll.c
 create mode 100644 drivers/clk/qcom/clk-alpha-pll.h
 create mode 100644 drivers/clk/qcom/gcc-msm8996.c
 create mode 100644 drivers/clk/qcom/mmcc-msm8996.c
 create mode 100644 include/dt-bindings/clock/qcom,gcc-msm8996.h
 create mode 100644 include/dt-bindings/clock/qcom,mmcc-msm8996.h

-- 
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 2/4] arm64: dts: Add msm8996 SoC and MTP board support

2015-11-17 Thread Stephen Boyd
Add initial device tree support for the Qualcomm MSM8996 SoC and
MTP8996 evaluation board.

Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
---
 arch/arm64/boot/dts/qcom/Makefile |   1 +
 arch/arm64/boot/dts/qcom/msm8996-mtp.dts  |  21 +++
 arch/arm64/boot/dts/qcom/msm8996-mtp.dtsi |  30 
 arch/arm64/boot/dts/qcom/msm8996.dtsi | 267 ++
 4 files changed, 319 insertions(+)
 create mode 100644 arch/arm64/boot/dts/qcom/msm8996-mtp.dts
 create mode 100644 arch/arm64/boot/dts/qcom/msm8996-mtp.dtsi
 create mode 100644 arch/arm64/boot/dts/qcom/msm8996.dtsi

diff --git a/arch/arm64/boot/dts/qcom/Makefile 
b/arch/arm64/boot/dts/qcom/Makefile
index 8e94af64ee94..fa1f661f 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -1,4 +1,5 @@
 dtb-$(CONFIG_ARCH_QCOM)+= apq8016-sbc.dtb msm8916-mtp.dtb
+dtb-$(CONFIG_ARCH_QCOM)+= msm8996-mtp.dtb
 
 always := $(dtb-y)
 subdir-y   := $(dts-dirs)
diff --git a/arch/arm64/boot/dts/qcom/msm8996-mtp.dts 
b/arch/arm64/boot/dts/qcom/msm8996-mtp.dts
new file mode 100644
index ..619af44a595d
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/msm8996-mtp.dts
@@ -0,0 +1,21 @@
+/*
+ * Copyright (c) 2014-2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+/dts-v1/;
+
+#include "msm8996-mtp.dtsi"
+
+/ {
+   model = "Qualcomm Technologies, Inc. MSM 8996 MTP";
+   compatible = "qcom,msm8996-mtp";
+};
diff --git a/arch/arm64/boot/dts/qcom/msm8996-mtp.dtsi 
b/arch/arm64/boot/dts/qcom/msm8996-mtp.dtsi
new file mode 100644
index ..9bab5c011c07
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/msm8996-mtp.dtsi
@@ -0,0 +1,30 @@
+/*
+ * Copyright (c) 2014-2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include "msm8996.dtsi"
+
+/ {
+   aliases {
+   serial0 = _uart1;
+   };
+
+   chosen {
+   stdout-path = "serial0";
+   };
+
+   soc {
+   serial@75b {
+   status = "okay";
+   };
+   };
+};
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi 
b/arch/arm64/boot/dts/qcom/msm8996.dtsi
new file mode 100644
index ..cf5d361283de
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -0,0 +1,267 @@
+/* Copyright (c) 2014-2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+
+/ {
+   model = "Qualcomm Technologies, Inc. MSM8996";
+
+   interrupt-parent = <>;
+
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   chosen { };
+
+   memory {
+   device_type = "memory";
+   /* We expect the bootloader to fill in the reg */
+   reg = <0 0 0 0>;
+   };
+
+   cpus {
+   #address-cells = <2>;
+   #size-cells = <0>;
+
+   CPU0: cpu@0 {
+   device_type = "cpu";
+   compatible = "qcom,kryo";
+   reg = <0x0 0x0>;
+   enable-method = "psci";
+   next-level-cache = <_0>;
+   L2_0: l2-cache {
+ compatible = "cache";
+ cache-level = <2>;
+   };
+   };
+
+   CPU1: cpu@1 {
+   device_type = "cpu&qu

[PATCH 1/4] devicetree: bindings: Document Kryo cpu

2015-11-17 Thread Stephen Boyd
Document the compatible string for the Kryo family of qcom cpus.

Cc: <devicet...@vger.kernel.org>
Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
---
 Documentation/devicetree/bindings/arm/cpus.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/cpus.txt 
b/Documentation/devicetree/bindings/arm/cpus.txt
index 3a07a87fef20..6008b99ccb2b 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -177,6 +177,7 @@ nodes to be present and contain the properties described 
below.
"marvell,sheeva-v5"
"nvidia,tegra132-denver"
"qcom,krait"
+   "qcom,kryo"
"qcom,scorpion"
- enable-method
Value type: 
-- 
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 3/4] arm64: dts: qcom: Add pm8994, pmi8994, pm8004 PMIC skeletons

2015-11-17 Thread Stephen Boyd
Add the skeleton nodes for the PMICs found on msm8996-mtp
devices.

Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
---
 arch/arm64/boot/dts/qcom/pm8004.dtsi  | 19 +++
 arch/arm64/boot/dts/qcom/pm8994.dtsi  | 19 +++
 arch/arm64/boot/dts/qcom/pmi8994.dtsi | 19 +++
 3 files changed, 57 insertions(+)
 create mode 100644 arch/arm64/boot/dts/qcom/pm8004.dtsi
 create mode 100644 arch/arm64/boot/dts/qcom/pm8994.dtsi
 create mode 100644 arch/arm64/boot/dts/qcom/pmi8994.dtsi

diff --git a/arch/arm64/boot/dts/qcom/pm8004.dtsi 
b/arch/arm64/boot/dts/qcom/pm8004.dtsi
new file mode 100644
index ..ef2207afa86b
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/pm8004.dtsi
@@ -0,0 +1,19 @@
+#include 
+#include 
+
+_bus {
+
+   pmic@4 {
+   compatible = "qcom,pm8004", "qcom,spmi-pmic";
+   reg = <0x4 SPMI_USID>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
+
+   pmic@5 {
+   compatible = "qcom,pm8004", "qcom,spmi-pmic";
+   reg = <0x5 SPMI_USID>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
+};
diff --git a/arch/arm64/boot/dts/qcom/pm8994.dtsi 
b/arch/arm64/boot/dts/qcom/pm8994.dtsi
new file mode 100644
index ..e61b376f0b7c
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/pm8994.dtsi
@@ -0,0 +1,19 @@
+#include 
+#include 
+
+_bus {
+
+   pmic@0 {
+   compatible = "qcom,pm8994", "qcom,spmi-pmic";
+   reg = <0x0 SPMI_USID>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
+
+   pmic@1 {
+   compatible = "qcom,pm8994", "qcom,spmi-pmic";
+   reg = <0x1 SPMI_USID>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
+};
diff --git a/arch/arm64/boot/dts/qcom/pmi8994.dtsi 
b/arch/arm64/boot/dts/qcom/pmi8994.dtsi
new file mode 100644
index ..d3879a4e8076
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/pmi8994.dtsi
@@ -0,0 +1,19 @@
+#include 
+#include 
+
+_bus {
+
+   pmic@2 {
+   compatible = "qcom,pmi8994", "qcom,spmi-pmic";
+   reg = <0x2 SPMI_USID>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
+
+   pmic@3 {
+   compatible = "qcom,pmi8994", "qcom,spmi-pmic";
+   reg = <0x3 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 0/4] Add DTS for MSM8996 SoC and MTP

2015-11-17 Thread Stephen Boyd
These patches add the initial dts files for the MSM8996 SoC and
MTP evaluation board.

Stephen Boyd (4):
  devicetree: bindings: Document Kryo cpu
  arm64: dts: Add msm8996 SoC and MTP board support
  arm64: dts: qcom: Add pm8994, pmi8994, pm8004 PMIC skeletons
  arm64: dts: qcom: Add pm8994 gpios and MPPs

 Documentation/devicetree/bindings/arm/cpus.txt |   1 +
 arch/arm64/boot/dts/qcom/Makefile  |   1 +
 arch/arm64/boot/dts/qcom/msm8996-mtp.dts   |  21 ++
 arch/arm64/boot/dts/qcom/msm8996-mtp.dtsi  |  30 +++
 arch/arm64/boot/dts/qcom/msm8996.dtsi  | 267 +
 arch/arm64/boot/dts/qcom/pm8004.dtsi   |  19 ++
 arch/arm64/boot/dts/qcom/pm8994.dtsi   |  62 ++
 arch/arm64/boot/dts/qcom/pmi8994.dtsi  |  19 ++
 8 files changed, 420 insertions(+)
 create mode 100644 arch/arm64/boot/dts/qcom/msm8996-mtp.dts
 create mode 100644 arch/arm64/boot/dts/qcom/msm8996-mtp.dtsi
 create mode 100644 arch/arm64/boot/dts/qcom/msm8996.dtsi
 create mode 100644 arch/arm64/boot/dts/qcom/pm8004.dtsi
 create mode 100644 arch/arm64/boot/dts/qcom/pm8994.dtsi
 create mode 100644 arch/arm64/boot/dts/qcom/pmi8994.dtsi

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

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


Re: [PATCH v2] mmc: sdhci-msm: Boost controller core clock

2015-11-17 Thread Stephen Boyd
On 11/16, Ulf Hansson wrote:
> [...]
> 
> 
> >
> > In case you're wondering, the max frequency for sdc1 on 8974ac is
> > 400MHz. If it's just a plain 8974pro then the max frequency is
> > 200MHz. Otherwise, sdc2 maxes out at 200Mhz and sdc3 and sdc4 max
> > out at 100MHz.
> 
> When you say that sdc1 supports 400MHz, what does that mean? That it
> actually can cope with that clock rate when communicating with the MMC
> card?

I suspect there must be some internal divider in the sdc IP
itself so that it doesn't put out 400MHz on the bus, but I really
don't know. What I mean is that the clock going into the IP from
the clock controller is running at 400MHz, after it goes into the
IP it could be divided, etc. before exiting the SoC on some pin.

> 
> This makes me wonder how you deal with power management (DVFS).
> 
> For example when you have the possibility to gate this clock (at
> request inactivity) when the rate is set to 400 MHz and OPP is
> increased, how will then that clock gating affect the OPP?

Sorry I'm not really following the question here. The gate will
disable the clock in the clock controller, cutting the signal off
upstream of the sdc IP. When we do DVFS we'll stop considering
this clock as part of the overall power level for the voltage
associated with the frequency. When all other clocks that are
using the same voltage and are on and running at frequencies that
don't need that high of voltage we can reduce the voltage and
drop down to something lower.

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


  1   2   3   4   5   6   7   8   9   10   >