Re: [PATCH] ARM: dts: am57xx-beagle-x15: set VDD_SD to always-on

2015-09-25 Thread Nishanth Menon 
On 09/25/2015 08:02 AM, Tomi Valkeinen wrote:
> LDO1 regulator (VDD_SD) is connected to SoC's vddshv8. vddshv8 needs to
> be kept always powered (see commit 5a0f93c6576a ("ARM: dts: Add
> am57xx-beagle-x15"), but at the moment VDD_SD is enabled/disabled
> depending on whether an SD card is inserted or not.
> 
> This patch sets LDO1 regulator to always-on.
> 
> This patch has a side effect of fixing another issue, HDMI DDC not
> working when SD card is not inserted:
> 
> Why this happens is that the tpd12s015 (HDMI level shifter/ESD
> protection chip) has LS_OE GPIO input, which needs to be enabled for the
> HDMI DDC to work. LS_OE comes from gpio6_28. The pin that provides
> gpio6_28 is powered by vddshv8, and vddshv8 comes from VDD_SD.
> 
> So when SD card is not inserted, VDD_SD is disabled, and LS_OE stays
> off.
> 
> The proper fix for the HDMI DDC issue would be to maybe have the pinctrl
> framework manage the pin specific power.
> 
> Apparently this fixes also a third issue (copy paste from Kishon's
> patch):
> 
> ldo1_reg in addition to being connected to the io lines is also
> connected to the card detect line. On card removal, omap_hsmmc
> driver does a regulator_disable causing card detect line to be
> pulled down. This raises a card insertion interrupt and once the
> MMC core detects there is no card inserted, it does a
> regulator disable which again raises a card insertion interrupt.
> This happens in a loop causing infinite MMC interrupts.
> 
> Fixes: 5a0f93c6576a ("ARM: dts: Add am57xx-beagle-x15")
> Cc: Kishon Vijay Abraham I 
> Signed-off-by: Tomi Valkeinen 
> Reported-by: Louis McCarthy 

Acked-by: Nishanth Menon 

> ---
>  arch/arm/boot/dts/am57xx-beagle-x15.dts | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts 
> b/arch/arm/boot/dts/am57xx-beagle-x15.dts
> index 3a05b94f59ed..ba8ef66a16e0 100644
> --- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
> +++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
> @@ -415,11 +415,12 @@
>   /* SMPS9 unused */
>  
>   ldo1_reg: ldo1 {
> - /* VDD_SD  */
> + /* VDD_SD / VDDSHV8  */
>   regulator-name = "ldo1";
>   regulator-min-microvolt = <180>;
>   regulator-max-microvolt = <330>;
>   regulator-boot-on;
> + regulator-always-on;
>   };
>  
>   ldo2_reg: ldo2 {
> 


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

Re: [PATCH 2/2] arm: omap2+: PM: change trace_power_domain_target event format.

2015-09-25 Thread Marc Titinger 



On 25/09/2015 16:10, Steven Rostedt wrote:

On Fri, 25 Sep 2015 15:22:25 +0200
Marc Titinger  wrote:


From: Marc Titinger 

power_domain_target arg3 is now a string (event name) with generic power
domains. In the case of Omap, it is a hint to the prev/next switch op.
Incidentally this trace is now conditioned by CONFIG_PM_ADVANCED_DEBUG.

I'm curious to why the addition of this config option?

I meant to be consistent with Juno/generic-power-domains, so that this 
trace always (or never) requires this switch.

I think I will remove this condition for both actually.


Compiled for Omap2+ but not tested.

Signed-off-by: Marc Titinger 
---
  arch/arm/mach-omap2/powerdomain.c | 32 
  1 file changed, 20 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-omap2/powerdomain.c 
b/arch/arm/mach-omap2/powerdomain.c
index 78af6d8..cd77696 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -160,7 +160,7 @@ static void _update_logic_membank_counters(struct 
powerdomain *pwrdm)
  static int _pwrdm_state_switch(struct powerdomain *pwrdm, int flag)
  {
  
-	int prev, next, state, trace_state = 0;

+   int prev, state;
  
  	if (pwrdm == NULL)

return -EINVAL;
@@ -177,18 +177,25 @@ static int _pwrdm_state_switch(struct powerdomain *pwrdm, 
int flag)
pwrdm->state_counter[prev]++;
if (prev == PWRDM_POWER_RET)
_update_logic_membank_counters(pwrdm);
-   /*
-* If the power domain did not hit the desired state,
-* generate a trace event with both the desired and hit states
-*/
-   next = pwrdm_read_next_pwrst(pwrdm);
-   if (next != prev) {
-   trace_state = (PWRDM_TRACE_STATES_FLAG |
+
+#ifdef CONFIG_PM_ADVANCED_DEBUG

You do realize that you can add this to the block:


if (trace_power_domain_target_enabled()) {

Nope I didn't, but now I do ;) thanks.

Marc.



as it seems this code is only run to pass data to the tracepoint. The
above if statement will keep this block in the 'out-of-line' path when
tracing is not enabled via a static_key (jump-label).

-- Steve


+   {
+   /*
+* If the power domain did not hit the desired state,
+* generate a trace event with both the desired and hit
+* states */
+   int next = pwrdm_read_next_pwrst(pwrdm);
+
+   if (next != prev) {
+   int trace_state = (PWRDM_TRACE_STATES_FLAG |
   ((next & OMAP_POWERSTATE_MASK) << 8) |
   ((prev & OMAP_POWERSTATE_MASK) << 0));
-   trace_power_domain_target(pwrdm->name, trace_state,
- smp_processor_id());
+   trace_power_domain_target(pwrdm->name,
+   trace_state, "PWRDM_STATE_PREV");
+   }
}
+#endif
+
break;
default:
return -EINVAL;
@@ -522,9 +529,10 @@ int pwrdm_set_next_pwrst(struct powerdomain *pwrdm, u8 
pwrst)
 pwrdm->name, pwrst);
  
  	if (arch_pwrdm && arch_pwrdm->pwrdm_set_next_pwrst) {

+#ifdef CONFIG_PM_ADVANCED_DEBUG
/* Trace the pwrdm desired target state */
-   trace_power_domain_target(pwrdm->name, pwrst,
- smp_processor_id());
+   trace_power_domain_target(pwrdm->name, pwrst, "set_next_pwrst");
+#endif
/* Program the pwrdm desired target state */
ret = arch_pwrdm->pwrdm_set_next_pwrst(pwrdm, pwrst);
}


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

Re: [PATCH] ARM: dts: Add am335x-bonegreen

2015-09-25 Thread Robert Nelson 
On Fri, Sep 25, 2015 at 11:03 AM, Nishanth Menon  wrote:
> On 09/25/2015 10:10 AM, Robert Nelson wrote:
>> SeeedStudio BeagleBone Green (BBG) is clone of the BeagleBone Black (BBB) 
>> minus
>> the HDMI port and addition of two Grove connectors (i2c2 and usart2).
>>
>> This board can be identified by the 1A value after A335BNLT (BBB) in the 
>> at24 eeprom:
>> 1A: [aa 55 33 ee 41 33 33 35  42 4e 4c 54 1a 00 00 00 |.U3.A335BNLT|]
>>
>> http://beagleboard.org/green
>> http://www.seeedstudio.com/wiki/Beaglebone_green
>>
>> Signed-off-by: Robert Nelson 
>> CC: Tony Lindgren 
>> CC: Jason Kridner 
>> ---
>>  arch/arm/boot/dts/Makefile |  1 +
>>  arch/arm/boot/dts/am335x-bonegreen.dts | 53 
>> ++
>>  2 files changed, 54 insertions(+)
>>  create mode 100644 arch/arm/boot/dts/am335x-bonegreen.dts
>>
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index 233159d..e45d771 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -446,6 +446,7 @@ dtb-$(CONFIG_SOC_AM33XX) += \
>>   am335x-base0033.dtb \
>>   am335x-bone.dtb \
>>   am335x-boneblack.dtb \
>> + am335x-bonegreen.dtb \
>>   am335x-sl50.dtb \
>>   am335x-evm.dtb \
>>   am335x-evmsk.dtb \
>> diff --git a/arch/arm/boot/dts/am335x-bonegreen.dts 
>> b/arch/arm/boot/dts/am335x-bonegreen.dts
>> new file mode 100644
>> index 000..0f65bda
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/am335x-bonegreen.dts
>> @@ -0,0 +1,53 @@
>> +/*
>> + * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
>> + *
>> + * 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.
>> + */
>> +/dts-v1/;
>> +
>> +#include "am33xx.dtsi"
>> +#include "am335x-bone-common.dtsi"
>> +
>> +/ {
>> + model = "TI AM335x BeagleBone Green";
>> + compatible = "ti,am335x-bone-green", "ti,am335x-bone-black", 
>> "ti,am335x-bone", "ti,am33xx";
>> +};
>> +
>> +_reg {
>> + regulator-min-microvolt = <180>;
>> + regulator-max-microvolt = <180>;
>> + regulator-always-on;
>> +};
>> +
>> + {
>> + vmmc-supply = <_fixed>;
>> +};
>> +
>> + {
>> + vmmc-supply = <_fixed>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <_pins>;
>> + bus-width = <8>;
>> + status = "okay";
>> +};
>> +
>> +_pinmux {
>> + uart2_pins: uart2_pins {
>> + pinctrl-single,pins = <
>> + 0x150 (PIN_INPUT | MUX_MODE1)   /* spi0_sclk.uart2_rxd 
>> */
>> + 0x154 (PIN_OUTPUT | MUX_MODE1)  /* spi0_d0.uart2_txd */
>> + >;
>> + };
>> +};
>> +
>> + {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <_pins>;
>> + status = "okay";
>> +};
>> +
>> + {
>> + system-power-controller;
>> +};
>>
>
>
> Would still work when https://patchwork.kernel.org/patch/6394821/ gets in?

That will still work, but we need to extend the board identification
to "board-name" + "board-revision", as the Green choose the "A335BNLT"
board name in the eeprom to remain compatible with older 3.8.x images
from last year.. (most of the clones i've talked too want to support
the old image too)...

So with the 1st byte of the board-revision:
All BeagleBone Black's have: 0x30
Seeed's using 0x1A (with the potential to increment the A)

Regards,

-- 
Robert Nelson
https://rcn-ee.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" 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: Add am335x-bonegreen

2015-09-25 Thread Robert Nelson 
SeeedStudio BeagleBone Green (BBG) is clone of the BeagleBone Black (BBB) minus
the HDMI port and addition of two Grove connectors (i2c2 and usart2).

This board can be identified by the 1A value after A335BNLT (BBB) in the at24 
eeprom:
1A: [aa 55 33 ee 41 33 33 35  42 4e 4c 54 1a 00 00 00 |.U3.A335BNLT|]

http://beagleboard.org/green
http://www.seeedstudio.com/wiki/Beaglebone_green

Signed-off-by: Robert Nelson 
CC: Tony Lindgren 
CC: Jason Kridner 
---
 arch/arm/boot/dts/Makefile |  1 +
 arch/arm/boot/dts/am335x-bonegreen.dts | 53 ++
 2 files changed, 54 insertions(+)
 create mode 100644 arch/arm/boot/dts/am335x-bonegreen.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 233159d..e45d771 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -446,6 +446,7 @@ dtb-$(CONFIG_SOC_AM33XX) += \
am335x-base0033.dtb \
am335x-bone.dtb \
am335x-boneblack.dtb \
+   am335x-bonegreen.dtb \
am335x-sl50.dtb \
am335x-evm.dtb \
am335x-evmsk.dtb \
diff --git a/arch/arm/boot/dts/am335x-bonegreen.dts 
b/arch/arm/boot/dts/am335x-bonegreen.dts
new file mode 100644
index 000..0f65bda
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-bonegreen.dts
@@ -0,0 +1,53 @@
+/*
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * 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.
+ */
+/dts-v1/;
+
+#include "am33xx.dtsi"
+#include "am335x-bone-common.dtsi"
+
+/ {
+   model = "TI AM335x BeagleBone Green";
+   compatible = "ti,am335x-bone-green", "ti,am335x-bone-black", 
"ti,am335x-bone", "ti,am33xx";
+};
+
+_reg {
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   regulator-always-on;
+};
+
+ {
+   vmmc-supply = <_fixed>;
+};
+
+ {
+   vmmc-supply = <_fixed>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   bus-width = <8>;
+   status = "okay";
+};
+
+_pinmux {
+   uart2_pins: uart2_pins {
+   pinctrl-single,pins = <
+   0x150 (PIN_INPUT | MUX_MODE1)   /* spi0_sclk.uart2_rxd 
*/
+   0x154 (PIN_OUTPUT | MUX_MODE1)  /* spi0_d0.uart2_txd */
+   >;
+   };
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   status = "okay";
+};
+
+ {
+   system-power-controller;
+};
-- 
2.5.3

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

Re: [PATCH] ARM: dts: Add am335x-bonegreen

2015-09-25 Thread Nishanth Menon 
On 09/25/2015 10:10 AM, Robert Nelson wrote:
> SeeedStudio BeagleBone Green (BBG) is clone of the BeagleBone Black (BBB) 
> minus
> the HDMI port and addition of two Grove connectors (i2c2 and usart2).
> 
> This board can be identified by the 1A value after A335BNLT (BBB) in the at24 
> eeprom:
> 1A: [aa 55 33 ee 41 33 33 35  42 4e 4c 54 1a 00 00 00 |.U3.A335BNLT|]
> 
> http://beagleboard.org/green
> http://www.seeedstudio.com/wiki/Beaglebone_green
> 
> Signed-off-by: Robert Nelson 
> CC: Tony Lindgren 
> CC: Jason Kridner 
> ---
>  arch/arm/boot/dts/Makefile |  1 +
>  arch/arm/boot/dts/am335x-bonegreen.dts | 53 
> ++
>  2 files changed, 54 insertions(+)
>  create mode 100644 arch/arm/boot/dts/am335x-bonegreen.dts
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 233159d..e45d771 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -446,6 +446,7 @@ dtb-$(CONFIG_SOC_AM33XX) += \
>   am335x-base0033.dtb \
>   am335x-bone.dtb \
>   am335x-boneblack.dtb \
> + am335x-bonegreen.dtb \
>   am335x-sl50.dtb \
>   am335x-evm.dtb \
>   am335x-evmsk.dtb \
> diff --git a/arch/arm/boot/dts/am335x-bonegreen.dts 
> b/arch/arm/boot/dts/am335x-bonegreen.dts
> new file mode 100644
> index 000..0f65bda
> --- /dev/null
> +++ b/arch/arm/boot/dts/am335x-bonegreen.dts
> @@ -0,0 +1,53 @@
> +/*
> + * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
> + *
> + * 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.
> + */
> +/dts-v1/;
> +
> +#include "am33xx.dtsi"
> +#include "am335x-bone-common.dtsi"
> +
> +/ {
> + model = "TI AM335x BeagleBone Green";
> + compatible = "ti,am335x-bone-green", "ti,am335x-bone-black", 
> "ti,am335x-bone", "ti,am33xx";
> +};
> +
> +_reg {
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <180>;
> + regulator-always-on;
> +};
> +
> + {
> + vmmc-supply = <_fixed>;
> +};
> +
> + {
> + vmmc-supply = <_fixed>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> + bus-width = <8>;
> + status = "okay";
> +};
> +
> +_pinmux {
> + uart2_pins: uart2_pins {
> + pinctrl-single,pins = <
> + 0x150 (PIN_INPUT | MUX_MODE1)   /* spi0_sclk.uart2_rxd 
> */
> + 0x154 (PIN_OUTPUT | MUX_MODE1)  /* spi0_d0.uart2_txd */
> + >;
> + };
> +};
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> + status = "okay";
> +};
> +
> + {
> + system-power-controller;
> +};
> 


Would still work when https://patchwork.kernel.org/patch/6394821/ gets in?


-- 
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" 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: OMAP2: erratum I688 handling disabled for AM335x

2015-09-25 Thread Tony Lindgren 
* Bastian Stender  [150925 05:40]:
> Hi,
> 
> On 09/25/2015 02:08 PM, Russell King - ARM Linux wrote:
> >On Fri, Sep 25, 2015 at 12:01:13PM +0200, Bastian Stender wrote:
> >>Signed-off-by: Bastian Stender 
> >>---
> >>  arch/arm/mach-omap2/omap4-common.c | 6 ++
> >>  1 file changed, 6 insertions(+)
> >>
> >>diff --git a/arch/arm/mach-omap2/omap4-common.c 
> >>b/arch/arm/mach-omap2/omap4-common.c
> >>index 949696b..a3a0cd1 100644
> >>--- a/arch/arm/mach-omap2/omap4-common.c
> >>+++ b/arch/arm/mach-omap2/omap4-common.c
> >>@@ -131,6 +131,12 @@ static int __init omap4_sram_init(void)
> >>struct device_node *np;
> >>struct gen_pool *sram_pool;
> >>
> >>+   /* AM335x is OMAP2+, so no erratum I688 handling needed
> >>+* (see CONFIG_OMAP4_ERRATA_I688) needed
> >
> >This makes no sense.  OMAP4 is OMAP2+ as well, but it needs the erratum.
> >In fact, all code in mach-omap2 is "OMAP2+".
> >
> >So, AM335x being "OMAP2+" is no reason at all why I688 should be disabled.
> 
> So, the Device Tree for AM335x does need a compatible = "ti,omap4-mpu" node
> + sram property for I688 handling?

If the errata is interconnect related and applies for omap4+, then
the interconnects are the same also on dm81xx and am335x AFAIK.

If I688 is not needed on am335x, then it seems there are still some
mysteries remaining with this erratum to unravel. Something like
difference in the L3 implementation. Maybe somebody from TI
can investigate which SoCs this is really needed on?

Regards,

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

[GIT PULL] omap fixes for most mmc regressions and few other fixes

2015-09-25 Thread Tony Lindgren 
The following changes since commit 7168e947291f0ead07e5638b4599fb7845288b69:

  Merge branch 'fixes-rc1' into omap-for-v4.3/fixes (2015-09-14 13:42:11 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
tags/omap-for-v4.3/fixes-rc2

for you to fetch changes up to 9a5e3f27d1b8ca349b79e8b5fe1874db6f45:

  ARM: dts: fix omap2+ address translation for pbias (2015-09-24 16:28:32 -0700)


Fixes for omaps for v4.3-rc cycle:

- Two more patches to fix most of the MMC regressions with the
  PBIAS regulator changes. At least two MMC driver related issues
  still seems to remain for omap3 legacy booting and omap4 duovero.
  Note that the dts changes depend on a recent regulator fix, and
  are based on the regulator commit now in mainline kernel

- Enable autoidle for am43xx clocks to prevent clocks from staying
  always on

- Fix i2c5 pinctrl offsets for omap5-uevm

- Enable PCA953X as that's needed for HDMI to work on omap5

- Update phy supplies for beagle x15 beta board

- Use palmas-usb for on beagle x15 to start using the related
  driver that recently got merged
-


Dave Gerlach (1):
  ARM: OMAP2+: AM43XX: Enable autoidle for clks in am43xx_init_late

Grazvydas Ignotas (2):
  ARM: dts: omap5-uevm.dts: fix i2c5 pinctrl offsets
  ARM: omap2plus_defconfig: enable GPIO_PCA953X

Kishon Vijay Abraham I (2):
  regulator: pbias: program pbias register offset in pbias driver
  ARM: dts: fix omap2+ address translation for pbias

Nishanth Menon (1):
  ARM: dts: am57xx-beagle-x15: Update Phy supplies

Roger Quadros (1):
  ARM: dts: am57xx-beagle-x15: use palmas-usb for USB2

Tony Lindgren (1):
  Merge commit 'b8c93646fd5c' into omap-for-v4.3/fixes

 .../bindings/regulator/pbias-regulator.txt |  7 ++-
 arch/arm/boot/dts/am57xx-beagle-x15.dts| 42 ++--
 arch/arm/boot/dts/dra7.dtsi|  1 +
 arch/arm/boot/dts/omap2430.dtsi|  1 +
 arch/arm/boot/dts/omap3.dtsi   | 25 +-
 arch/arm/boot/dts/omap4.dtsi   |  1 +
 arch/arm/boot/dts/omap5-uevm.dts   |  4 +-
 arch/arm/boot/dts/omap5.dtsi   |  1 +
 arch/arm/configs/omap2plus_defconfig   |  1 +
 arch/arm/mach-omap2/io.c   |  1 +
 drivers/regulator/pbias-regulator.c| 56 +++---
 11 files changed, 104 insertions(+), 36 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" 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: OMAP2: erratum I688 handling disabled for AM335x

2015-09-25 Thread Nishanth Menon 
On 09/25/2015 09:35 AM, Tony Lindgren wrote:
> * Bastian Stender  [150925 05:40]:
>> Hi,
>>
>> On 09/25/2015 02:08 PM, Russell King - ARM Linux wrote:
>>> On Fri, Sep 25, 2015 at 12:01:13PM +0200, Bastian Stender wrote:
 Signed-off-by: Bastian Stender 
 ---
  arch/arm/mach-omap2/omap4-common.c | 6 ++
  1 file changed, 6 insertions(+)

 diff --git a/arch/arm/mach-omap2/omap4-common.c 
 b/arch/arm/mach-omap2/omap4-common.c
 index 949696b..a3a0cd1 100644
 --- a/arch/arm/mach-omap2/omap4-common.c
 +++ b/arch/arm/mach-omap2/omap4-common.c
 @@ -131,6 +131,12 @@ static int __init omap4_sram_init(void)
struct device_node *np;
struct gen_pool *sram_pool;

 +  /* AM335x is OMAP2+, so no erratum I688 handling needed
 +   * (see CONFIG_OMAP4_ERRATA_I688) needed
>>>
>>> This makes no sense.  OMAP4 is OMAP2+ as well, but it needs the erratum.
>>> In fact, all code in mach-omap2 is "OMAP2+".
>>>
>>> So, AM335x being "OMAP2+" is no reason at all why I688 should be disabled.
>>
>> So, the Device Tree for AM335x does need a compatible = "ti,omap4-mpu" node
>> + sram property for I688 handling?
> 
> If the errata is interconnect related and applies for omap4+, then
> the interconnects are the same also on dm81xx and am335x AFAIK.
> 
> If I688 is not needed on am335x, then it seems there are still some
> mysteries remaining with this erratum to unravel. Something like
> difference in the L3 implementation. Maybe somebody from TI
> can investigate which SoCs this is really needed on?
> 
> Regards,
> 
> Tony
> 

+ Richard who probably has the oldest history on the topic.

I suspect strongly that the erratum was discovered during A9 OMAP4 days,
but never percolated to older SoC erratum documentation. The need of
barrier logic was clarified with SoC folks to confirm the behavior though.

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

Re: [PATCH] ARM: dts: Add am335x-bonegreen

2015-09-25 Thread Robert Nelson 
>>
>> Would still work when https://patchwork.kernel.org/patch/6394821/ gets in?
>
> That will still work, but we need to extend the board identification
> to "board-name" + "board-revision", as the Green choose the "A335BNLT"
> board name in the eeprom to remain compatible with older 3.8.x images
> from last year.. (most of the clones i've talked too want to support
> the old image too)...
>
> So with the 1st byte of the board-revision:
> All BeagleBone Black's have: 0x30
> Seeed's using 0x1A (with the potential to increment the A)

I should add, we have an official-ish list at the top of (1), to help
keep track of this...

1: https://github.com/beagleboard/image-builder/blob/master/readme.md

Regards,

-- 
Robert Nelson
https://rcn-ee.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: omapdss: Division by zero in kernel

2015-09-25 Thread Pali Rohár 
On Thursday 17 September 2015 07:16:44 Pavel Machek wrote:
> 
> > > if (image->depth == 1) {
> > > if (p->fix.visual == FB_VISUAL_TRUECOLOR ||
> > > p->fix.visual == FB_VISUAL_DIRECTCOLOR) {
> > > fgcolor = 
> > > ((u32*)(p->pseudo_palette))[image->fg_color];
> > > bgcolor = 
> > > ((u32*)(p->pseudo_palette))[image->bg_color];
> > > } else {
> > > fgcolor = image->fg_color;
> > > bgcolor = image->bg_color;
> > > }
> > > 
> > > if (32 % bpp == 0 && !start_index && !pitch_index &&
> > > ((width & (32/bpp-1)) == 0) &&
> > > bpp >= 8 && bpp <= 32)
> > > fast_imageblit(image, p, dst1, fgcolor, bgcolor);
> > > else
> > > slow_imageblit(image, p, dst1, fgcolor, bgcolor,
> > > start_index, pitch_index);
> > > } else
> > > color_imageblit(image, p, dst1, start_index, pitch_i
> > > 
> > > 
> > > Notice that bpp is not checked for zero, and thus bpp==0 is totally
> > > feasible?   resulting in 32/bpp crashing the kernel?
> > > 
> > 
> > Hm... this could really be a problem! But how to patch it? Which branch
> > should be called (fast_ or slow_ function) if bpp is zero?
> > 
> > And is there some way to force kernel to dump backtrace into dmesg when
> > division by zero occur?
> 
> You can do WARN_ON(bpp==1) ... and should probably return in that
> case.
> 
>   Pavel

Does not make sense to call slow_ function? In that if condition check
also that bpp is nonzero...

-- 
Pali Rohár
pali.ro...@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2] convert to use generic irq handler

2015-09-25 Thread santosh.shilim...@oracle.com 

On 9/25/15 12:28 PM, Grygorii Strashko wrote:

This patch series contains patches which fixes wrong APIs usage in atomic
context on RT-kernel. The final goal is to make TI OMAP GPIO driver
compatible with -RT kernel as much as possible.

Patch 1: required to be compatible with -RT kernel, because PM runtime's
irq_safe mode is incompatible with -RT.
Patch 2: This patch converts TI OMAP GPIO driver to use generic irq
  handler instead of chained IRQ handler. This way OMAP GPIO driver will be
  compatible with RT-kernel where it will be forced thread IRQ handler
  while in non-RT kernel it still will be executed in HW IRQ context.

Boot, basic gpio functionality tested on:
  dra7-evm, BeagleBone(white), am43xx-gpevm, am437x-sk
Manually tested on dra7-evm including suspend/resume and wakeup.

Links on RFC:
  https://lkml.org/lkml/2015/8/18/161
  https://lkml.org/lkml/2015/8/18/162

Grygorii Strashko (2):
   gpio: omap: move pm runtime in irq_chip.irq_bus_lock/sync_unlock
   gpio: omap: convert to use generic irq handler


Acked-by: Santosh Shilimkar 
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" 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: OMAP2: erratum I688 handling disabled for AM335x

2015-09-25 Thread Woodruff, Richard 
> From: Menon, Nishanth
> Sent: Friday, September 25, 2015 9:44 AM

> > If I688 is not needed on am335x, then it seems there are still some
> > mysteries remaining with this erratum to unravel. Something like
> > difference in the L3 implementation. Maybe somebody from TI can
> > investigate which SoCs this is really needed on?

> + Richard who probably has the oldest history on the topic.
> 
> I suspect strongly that the erratum was discovered during A9 OMAP4 days,
> but never percolated to older SoC erratum documentation. The need of
> barrier logic was clarified with SoC folks to confirm the behavior though.

-0-
After looking up i688 in data base and reviewing AM335x SOC I do NOT think i688 
will exhibit for AM335x.
 - it appears not to be using pieces which have issues on path.

I688 could impact SOCs which use a DMM and the interconnect infrastructure 
which supports it.

I believe hang issues on path could be mapped to 3 sources:
- asyncbrige used from MPUSS to Arteris NOC to DMM
- Dual EMIF idle (ocp-connect/disconnect) policy on path
- PL310 idle signal usage on path

SOCs using similar chassis components of OMAP4430 time are impacted.  Errata 
aspect in generic bridge map to Aegis, J5E, ...

The hangs are brought out by enabling power management features which causes 
micro-idles on path which can trigger a lock up.

Later SOCs pulled in fixes in one or all areas.  Some SOCs are not using 
components.

-1-
Barrier side effects of the patch may be beneficial for other reasons.  But 
AM335x should be immune from this particular issue.

Regards,
Richard W.

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" 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] gpio: omap: move pm runtime in irq_chip.irq_bus_lock/sync_unlock

2015-09-25 Thread Grygorii Strashko 
The PM runtime API can't be used in atomic contex on -RT even if
it's configured as irqsafe. As result, below error report can
be seen when PM runtime API called from IRQ chip's callbacks
irq_startup/irq_shutdown/irq_set_type, because they are
protected by RAW spinlock:

BUG: sleeping function called from invalid context at 
kernel/locking/rtmutex.c:917
in_atomic(): 1, irqs_disabled(): 128, pid: 96, name: insmod
3 locks held by insmod/96:
 #0:  (>mutex){..}, at: [] __driver_attach+0x54/0xa0
 #1:  (>mutex){..}, at: [] __driver_attach+0x60/0xa0
 #2:  (class){..}, at: [] __irq_get_desc_lock+0x60/0xa4
irq event stamp: 1834
hardirqs last  enabled at (1833): [] 
_raw_spin_unlock_irqrestore+0x88/0x90
hardirqs last disabled at (1834): [] _raw_spin_lock_irqsave+0x2c/0x64
softirqs last  enabled at (0): [] copy_process.part.52+0x410/0x19d8
softirqs last disabled at (0): [<  (null)>]   (null)
Preemption disabled at:[<  (null)>]   (null)

CPU: 1 PID: 96 Comm: insmod Tainted: GW  O
4.1.3-rt3-00618-g57e2387-dirty #184
Hardware name: Generic DRA74X (Flattened Device Tree)
[] (unwind_backtrace) from [] (show_stack+0x20/0x24)
[] (show_stack) from [] (dump_stack+0x88/0xdc)
[] (dump_stack) from [] (___might_sleep+0x198/0x2a8)
[] (___might_sleep) from [] (rt_spin_lock+0x30/0x70)
[] (rt_spin_lock) from [] (__pm_runtime_resume+0x68/0xa4)
[] (__pm_runtime_resume) from [] 
(omap_gpio_irq_type+0x188/0x1d8)
[] (omap_gpio_irq_type) from [] 
(__irq_set_trigger+0x68/0x130)
[] (__irq_set_trigger) from [] (irq_set_irq_type+0x44/0x6c)
[] (irq_set_irq_type) from [] 
(irq_create_of_mapping+0x120/0x174)
[] (irq_create_of_mapping) from [] (of_irq_get+0x48/0x58)
[] (of_irq_get) from [] (i2c_device_probe+0x54/0x15c)
[] (i2c_device_probe) from [] 
(driver_probe_device+0x184/0x2c8)
[] (driver_probe_device) from [] (__driver_attach+0x9c/0xa0)
[] (__driver_attach) from [] (bus_for_each_dev+0x7c/0xb0)
[] (bus_for_each_dev) from [] (driver_attach+0x28/0x30)
[] (driver_attach) from [] (bus_add_driver+0x154/0x200)
[] (bus_add_driver) from [] (driver_register+0x88/0x108)
[] (driver_register) from [] (i2c_register_driver+0x3c/0x90)
[] (i2c_register_driver) from [] (pcf857x_init+0x18/0x24 
[gpio_pcf857x])
[] (pcf857x_init [gpio_pcf857x]) from [] 
(do_one_initcall+0x128/0x1e8)
[] (do_one_initcall) from [] (do_init_module+0x6c/0x1bc)
[] (do_init_module) from [] (load_module+0x18e8/0x21c4)
[] (load_module) from [] (SyS_init_module+0xfc/0x158)
[] (SyS_init_module) from [] (ret_fast_syscall+0x0/0x54)

The IRQ chip interface defines only two callbacks which are executed in
non-atomic contex - irq_bus_lock/irq_bus_sync_unlock, so lets move
PM runtime calls there.

Tested-by: Tony Lindgren 
Tested-by: Austin Schuh 
Signed-off-by: Grygorii Strashko 
---
 drivers/gpio/gpio-omap.c | 25 +++--
 1 file changed, 15 insertions(+), 10 deletions(-)

diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 5236db1..a254691 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -496,9 +496,6 @@ static int omap_gpio_irq_type(struct irq_data *d, unsigned 
type)
(type & (IRQ_TYPE_LEVEL_LOW|IRQ_TYPE_LEVEL_HIGH)))
return -EINVAL;
 
-   if (!BANK_USED(bank))
-   pm_runtime_get_sync(bank->dev);
-
raw_spin_lock_irqsave(>lock, flags);
retval = omap_set_gpio_triggering(bank, offset, type);
if (retval) {
@@ -521,8 +518,6 @@ static int omap_gpio_irq_type(struct irq_data *d, unsigned 
type)
return 0;
 
 error:
-   if (!BANK_USED(bank))
-   pm_runtime_put(bank->dev);
return retval;
 }
 
@@ -797,9 +792,6 @@ static unsigned int omap_gpio_irq_startup(struct irq_data 
*d)
unsigned long flags;
unsigned offset = d->hwirq;
 
-   if (!BANK_USED(bank))
-   pm_runtime_get_sync(bank->dev);
-
raw_spin_lock_irqsave(>lock, flags);
 
if (!LINE_USED(bank->mod_usage, offset))
@@ -815,8 +807,6 @@ static unsigned int omap_gpio_irq_startup(struct irq_data 
*d)
return 0;
 err:
raw_spin_unlock_irqrestore(>lock, flags);
-   if (!BANK_USED(bank))
-   pm_runtime_put(bank->dev);
return -EINVAL;
 }
 
@@ -835,6 +825,19 @@ static void omap_gpio_irq_shutdown(struct irq_data *d)
omap_clear_gpio_debounce(bank, offset);
omap_disable_gpio_module(bank, offset);
raw_spin_unlock_irqrestore(>lock, flags);
+}
+
+static void omap_gpio_irq_bus_lock(struct irq_data *data)
+{
+   struct gpio_bank *bank = omap_irq_data_get_bank(data);
+
+   if (!BANK_USED(bank))
+   pm_runtime_get_sync(bank->dev);
+}
+
+static void gpio_irq_bus_sync_unlock(struct irq_data *data)
+{
+   struct gpio_bank *bank = omap_irq_data_get_bank(data);
 
/*
 * If this is the last IRQ to be freed in the bank,
@@ -1183,6 +1186,8 @@ static int

[PATCH] gpio: omap: fix static checker warning

2015-09-25 Thread Grygorii Strashko 
This patch fixes below static checker warning by changing
type of irq field in struct gpio_bank from u16 to int.

drivers/gpio/gpio-omap.c:1191 omap_gpio_probe()
warn: assigning (-6) to unsigned variable 'bank->irq'

drivers/gpio/gpio-omap.c
  1188  bank->irq = platform_get_irq(pdev, 0);
  1189  if (bank->irq <= 0) {

bank->irq is u16.

  1190  if (!bank->irq)
  1191  bank->irq = -ENXIO;

Does not work.

  1192  if (bank->irq != -EPROBE_DEFER)

Does not work.

  1193  dev_err(dev,
  1194  "can't get irq resource ret=%d\n", 
bank->irq);
  1195  return bank->irq;
  1196  }

Fixes: commit 89d18e3af8b9: "gpio: omap: switch to use platform_get_irq"
Signed-off-by: Grygorii Strashko 
---
 drivers/gpio/gpio-omap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 376827f..56d2d02 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -51,7 +51,7 @@ struct gpio_regs {
 struct gpio_bank {
struct list_head node;
void __iomem *base;
-   u16 irq;
+   int irq;
u32 non_wakeup_gpios;
u32 enabled_non_wakeup_gpios;
struct gpio_regs context;
-- 
2.5.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" 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] gpio: omap: convert to use generic irq handler

2015-09-25 Thread Grygorii Strashko 
This patch converts TI OMAP GPIO driver to use generic irq handler
instead of chained IRQ handler. This way OMAP GPIO driver will be
compatible with RT kernel where it will be forced thread IRQ handler
while in non-RT kernel it still will be executed in HW IRQ context.
As part of this change the IRQ wakeup configuration is applied to
GPIO Bank IRQ as it now will be under control of IRQ PM Core during
suspend.

There are also additional benefits:
 - on-RT kernel there will be no complains any more about PM runtime usage
   in atomic context  "BUG: sleeping function called from invalid context";
 - GPIO bank IRQs will appear in /proc/interrupts and its usage statistic
will be  visible;
 - GPIO bank IRQs could be configured through IRQ proc_fs interface and,
   as result, could be a part of IRQ balancing process if needed;
 - GPIO bank IRQs will be under control of IRQ PM Core during
   suspend to RAM.

Disadvantage:
 - additional runtime overhed as call chain till
   omap_gpio_irq_handler() will be longer now
 - necessity to use wa_lock in omap_gpio_irq_handler() to W/A warning
   in handle_irq_event_percpu()
   WARNING: CPU: 1 PID: 35 at kernel/irq/handle.c:149 
handle_irq_event_percpu+0x51c/0x638()

This patch doesn't fully follows recommendations provided by Sebastian
Andrzej Siewior [1], because It's required to go through and check all
GPIO IRQ pin states as fast as possible and pass control to handle_level_irq
or handle_edge_irq. handle_level_irq or handle_edge_irq will perform actions
specific for IRQ triggering type and wakeup corresponding registered
threaded IRQ handler (at least it's expected to be threaded).
IRQs can be lost if handle_nested_irq() will be used, because excecution
time of some pin specific GPIO IRQ handler can be very significant and
require accessing ext. devices (I2C).

Idea of such kind reworking was also discussed in [2].

[1] http://www.spinics.net/lists/linux-omap/msg120665.html
[2] http://www.spinics.net/lists/linux-omap/msg119516.html

Tested-by: Tony Lindgren 
Tested-by: Austin Schuh 
Signed-off-by: Grygorii Strashko 
---
 drivers/gpio/gpio-omap.c | 55 
 1 file changed, 27 insertions(+), 28 deletions(-)

diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index a254691..376827f 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -59,6 +59,7 @@ struct gpio_bank {
u32 level_mask;
u32 toggle_mask;
raw_spinlock_t lock;
+   raw_spinlock_t wa_lock;
struct gpio_chip chip;
struct clk *dbck;
u32 mod_usage;
@@ -649,8 +650,13 @@ static int omap_gpio_wake_enable(struct irq_data *d, 
unsigned int enable)
 {
struct gpio_bank *bank = omap_irq_data_get_bank(d);
unsigned offset = d->hwirq;
+   int ret;
+
+   ret = omap_set_gpio_wakeup(bank, offset, enable);
+   if (!ret)
+   ret = irq_set_irq_wake(bank->irq, enable);
 
-   return omap_set_gpio_wakeup(bank, offset, enable);
+   return ret;
 }
 
 static int omap_gpio_request(struct gpio_chip *chip, unsigned offset)
@@ -704,26 +710,21 @@ static void omap_gpio_free(struct gpio_chip *chip, 
unsigned offset)
  * line's interrupt handler has been run, we may miss some nested
  * interrupts.
  */
-static void omap_gpio_irq_handler(struct irq_desc *desc)
+static irqreturn_t omap_gpio_irq_handler(int irq, void *gpiobank)
 {
void __iomem *isr_reg = NULL;
u32 isr;
unsigned int bit;
-   struct gpio_bank *bank;
-   int unmasked = 0;
-   struct irq_chip *irqchip = irq_desc_get_chip(desc);
-   struct gpio_chip *chip = irq_desc_get_handler_data(desc);
+   struct gpio_bank *bank = gpiobank;
+   unsigned long wa_lock_flags;
unsigned long lock_flags;
 
-   chained_irq_enter(irqchip, desc);
-
-   bank = container_of(chip, struct gpio_bank, chip);
isr_reg = bank->base + bank->regs->irqstatus;
-   pm_runtime_get_sync(bank->dev);
-
if (WARN_ON(!isr_reg))
goto exit;
 
+   pm_runtime_get_sync(bank->dev);
+
while (1) {
u32 isr_saved, level_mask = 0;
u32 enabled;
@@ -745,13 +746,6 @@ static void omap_gpio_irq_handler(struct irq_desc *desc)
 
raw_spin_unlock_irqrestore(>lock, lock_flags);
 
-   /* if there is only edge sensitive GPIO pin interrupts
-   configured, we could unmask GPIO bank interrupt immediately */
-   if (!level_mask && !unmasked) {
-   unmasked = 1;
-   chained_irq_exit(irqchip, desc);
-   }
-
if (!isr)
break;
 
@@ -772,18 +766,18 @@ static void omap_gpio_irq_handler(struct irq_desc *desc)
 
raw_spin_unlock_irqrestore(>lock, lock_flags);
 
+

[PATCH 0/2] convert to use generic irq handler

2015-09-25 Thread Grygorii Strashko 
This patch series contains patches which fixes wrong APIs usage in atomic
context on RT-kernel. The final goal is to make TI OMAP GPIO driver
compatible with -RT kernel as much as possible.

Patch 1: required to be compatible with -RT kernel, because PM runtime's
irq_safe mode is incompatible with -RT.
Patch 2: This patch converts TI OMAP GPIO driver to use generic irq
 handler instead of chained IRQ handler. This way OMAP GPIO driver will be
 compatible with RT-kernel where it will be forced thread IRQ handler
 while in non-RT kernel it still will be executed in HW IRQ context.

Boot, basic gpio functionality tested on:
 dra7-evm, BeagleBone(white), am43xx-gpevm, am437x-sk
Manually tested on dra7-evm including suspend/resume and wakeup.

Links on RFC:
 https://lkml.org/lkml/2015/8/18/161
 https://lkml.org/lkml/2015/8/18/162

Grygorii Strashko (2):
  gpio: omap: move pm runtime in irq_chip.irq_bus_lock/sync_unlock
  gpio: omap: convert to use generic irq handler

 drivers/gpio/gpio-omap.c | 80 +---
 1 file changed, 42 insertions(+), 38 deletions(-)

-- 
2.5.1

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

Re: All OMAP platforms: MMC is broken

2015-09-25 Thread Nishanth Menon 
On 09/24/2015 08:13 PM, Tony Lindgren wrote:
> * Tony Lindgren <t...@atomide.com> [150924 16:42]:
>> * Russell King - ARM Linux <li...@arm.linux.org.uk> [150924 02:04]:
>>> Nightly testing has revealed that both the OMAP3430 LDP and the OMAP4430
>>> SDP fail to boot due to lack of working MMC.  Both platforms fail to
>>> find their rootfs, which is on a SD card.
>>>
>>> The breakage occurred somewhere between trees of September 9th (commit
>>> 4e4adb2f4628) and September 12th (commit b0a1ea51bda4), so during the
>>> merge window.
>>
>> Yes sorry things got messed up in multiple ways :( I've summarized
>> the mess here earlier:
>>
>> http://article.gmane.org/gmane.linux.kernel.mmc/33911
>>
>> And today commit b9c93646fd5c ("regulator: pbias: program pbias register
>> offset in pbias driver") hit mainline so I'll send a pull request for
>> the related dts change.
> 
> Kishon, while testing I noticed there are still at least two
> issues remaining that seem to need fixing in the MMC driver:
> 
> 1. The legacy booting without device tree does not probe MMC at
>all on omap3
> 
> 2. I'm getting the regulator warning on omap4 duovero
> 
> Anyways, I'm sending a pull request for the fixes so far as that
> gets MMC working again for most platforms.
> 
> Regards,
> 
With 0925, i think the patches got merged. here is my testing status on
the boards I have access to:

https://github.com/nmenon/kernel-test-logs/tree/next-20150925

Looks like with omap2plus_defconfig, at least
https://github.com/nmenon/kernel-test-logs/blob/next-20150925/omap2plus_defconfig/am335x-evm.txt
somethign is broken there - dunno what yet.

There are a few more farm related failures in various locations, but not
too interesting.


-- 
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" 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: ti: clk-7xx: Remove hardwired ABE clock configuration

2015-09-25 Thread Tero Kristo 

On 09/25/2015 09:59 AM, Peter Ujfalusi wrote:

Tero,

On 09/16/2015 09:42 AM, Tero Kristo wrote:

On 09/14/2015 11:52 AM, Peter Ujfalusi wrote:

Hi Tero,

On 08/24/2015 10:35 AM, Peter Ujfalusi wrote:

The ABE related clocks should be configured via DT and not have it wired
inside of the kernel.


can you take a look at this patch? It will not cause any regression since we
do not have audio support mainline and the pending series does not need this
part anymore.


This patch looks okay to me. So, you are saying this doesn't depend on
anything? Isn't this causing any boot-time issues with the ABE DPLL left
dangling with boot setup, potentially blocking PM? I am just wondering if we
should group this patch with the rest of the audio support patches for dra7.


Without this patch the ABE DPLL will have frequency which is not going to be
correct to be used with the ATL. The ATL is disabled by default and only
enabled when we use the audio. Which is not the case w/o the other series.



Ok, queuing for 4.3-rc fixes.

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

Re: [PATCH 01/11 RESEND] ARM: OMAP: DRA7: hwmod: Add data for McASP3

2015-09-25 Thread Peter Ujfalusi 
Paul,

On 09/15/2015 05:10 PM, Peter Ujfalusi wrote:
> McASP3 is used by default on DRA7x based boards for audio.

Can you take a look at this patch? It would be great to have this one reviewed
so the audio support for the dra7 family could be applied by Tony.

Thanks,
Péter

> Signed-off-by: Peter Ujfalusi 
> ---
> Hi Paul,
> 
> this patch is part of my earlier series and as Tony suggested I'll resend the
> hwmod patch for you to review since I missed you from the TO in the series.
> 
> The original series:
> https://www.mail-archive.com/linux-omap@vger.kernel.org/msg119319.html
> 
> Regards,
> Peter
> 
>  arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 41 
> +++
>  1 file changed, 41 insertions(+)
> 
> diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c 
> b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> index 562247bced49..c38b7fa30c27 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> @@ -1298,6 +1298,38 @@ static struct omap_hwmod dra7xx_mcspi4_hwmod = {
>  };
>  
>  /*
> + * 'mcasp' class
> + *
> + */
> +static struct omap_hwmod_class_sysconfig dra7xx_mcasp_sysc = {
> + .sysc_offs  = 0x0004,
> + .sysc_flags = SYSC_HAS_SIDLEMODE,
> + .idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
> + .sysc_fields= _hwmod_sysc_type3,
> +};
> +
> +static struct omap_hwmod_class dra7xx_mcasp_hwmod_class = {
> + .name   = "mcasp",
> + .sysc   = _mcasp_sysc,
> +};
> +
> +/* mcasp3 */
> +static struct omap_hwmod dra7xx_mcasp3_hwmod = {
> + .name   = "mcasp3",
> + .class  = _mcasp_hwmod_class,
> + .clkdm_name = "l4per2_clkdm",
> + .main_clk   = "mcasp3_ahclkx_mux",
> + .flags  = HWMOD_SWSUP_SIDLE,
> + .prcm = {
> + .omap4 = {
> + .clkctrl_offs = DRA7XX_CM_L4PER2_MCASP3_CLKCTRL_OFFSET,
> + .context_offs = DRA7XX_RM_L4PER2_MCASP3_CONTEXT_OFFSET,
> + .modulemode   = MODULEMODE_SWCTRL,
> + },
> + },
> +};
> +
> +/*
>   * 'mmc' class
>   *
>   */
> @@ -2566,6 +2598,14 @@ static struct omap_hwmod_ocp_if dra7xx_l3_main_1__hdmi 
> = {
>   .user   = OCP_USER_MPU | OCP_USER_SDMA,
>  };
>  
> +/* l4_per2 -> mcasp3 */
> +static struct omap_hwmod_ocp_if dra7xx_l4_per2__mcasp3 = {
> + .master = _l4_per2_hwmod,
> + .slave  = _mcasp3_hwmod,
> + .clk= "l3_iclk_div",
> + .user   = OCP_USER_MPU | OCP_USER_SDMA,
> +};
> +
>  static struct omap_hwmod_addr_space dra7xx_elm_addrs[] = {
>   {
>   .pa_start   = 0x48078000,
> @@ -3338,6 +3378,7 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[] 
> __initdata = {
>   _l4_wkup__dcan1,
>   _l4_per2__dcan2,
>   _l4_per2__cpgmac0,
> + _l4_per2__mcasp3,
>   _gmac__mdio,
>   _l4_cfg__dma_system,
>   _l3_main_1__dss,
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" 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: ti: clk-7xx: Remove hardwired ABE clock configuration

2015-09-25 Thread Peter Ujfalusi 
Tero,

On 09/16/2015 09:42 AM, Tero Kristo wrote:
> On 09/14/2015 11:52 AM, Peter Ujfalusi wrote:
>> Hi Tero,
>>
>> On 08/24/2015 10:35 AM, Peter Ujfalusi wrote:
>>> The ABE related clocks should be configured via DT and not have it wired
>>> inside of the kernel.
>>
>> can you take a look at this patch? It will not cause any regression since we
>> do not have audio support mainline and the pending series does not need this
>> part anymore.
> 
> This patch looks okay to me. So, you are saying this doesn't depend on
> anything? Isn't this causing any boot-time issues with the ABE DPLL left
> dangling with boot setup, potentially blocking PM? I am just wondering if we
> should group this patch with the rest of the audio support patches for dra7.

Without this patch the ABE DPLL will have frequency which is not going to be
correct to be used with the ATL. The ATL is disabled by default and only
enabled when we use the audio. Which is not the case w/o the other series.

-- 
Péter

> 
> -Tero
> 
>>
>>> Signed-off-by: Peter Ujfalusi 
>>> ---
>>> Hi Tero,
>>>
>>> the ABE PLL configuration can, and will be done for dra7xx in DT with the
>>> assigned-clocks/rate/parent feature so no need to have this anymore.
>>>
>>> Regards,
>>> Peter
>>>
>>>   drivers/clk/ti/clk-7xx.c | 18 +-
>>>   1 file changed, 1 insertion(+), 17 deletions(-)
>>>
>>> diff --git a/drivers/clk/ti/clk-7xx.c b/drivers/clk/ti/clk-7xx.c
>>> index 9b5b289e6334..a911d7de3377 100644
>>> --- a/drivers/clk/ti/clk-7xx.c
>>> +++ b/drivers/clk/ti/clk-7xx.c
>>> @@ -18,7 +18,6 @@
>>>
>>>   #include "clock.h"
>>>
>>> -#define DRA7_DPLL_ABE_DEFFREQ180633600
>>>   #define DRA7_DPLL_GMAC_DEFFREQ10
>>>   #define DRA7_DPLL_USB_DEFFREQ96000
>>>
>>> @@ -313,27 +312,12 @@ static struct ti_dt_clk dra7xx_clks[] = {
>>>   int __init dra7xx_dt_clk_init(void)
>>>   {
>>>   int rc;
>>> -struct clk *abe_dpll_mux, *sys_clkin2, *dpll_ck, *hdcp_ck;
>>> +struct clk *dpll_ck, *hdcp_ck;
>>>
>>>   ti_dt_clocks_register(dra7xx_clks);
>>>
>>>   omap2_clk_disable_autoidle_all();
>>>
>>> -abe_dpll_mux = clk_get_sys(NULL, "abe_dpll_sys_clk_mux");
>>> -sys_clkin2 = clk_get_sys(NULL, "sys_clkin2");
>>> -dpll_ck = clk_get_sys(NULL, "dpll_abe_ck");
>>> -
>>> -rc = clk_set_parent(abe_dpll_mux, sys_clkin2);
>>> -if (!rc)
>>> -rc = clk_set_rate(dpll_ck, DRA7_DPLL_ABE_DEFFREQ);
>>> -if (rc)
>>> -pr_err("%s: failed to configure ABE DPLL!\n", __func__);
>>> -
>>> -dpll_ck = clk_get_sys(NULL, "dpll_abe_m2x2_ck");
>>> -rc = clk_set_rate(dpll_ck, DRA7_DPLL_ABE_DEFFREQ * 2);
>>> -if (rc)
>>> -pr_err("%s: failed to configure ABE DPLL m2x2!\n", __func__);
>>> -
>>>   dpll_ck = clk_get_sys(NULL, "dpll_gmac_ck");
>>>   rc = clk_set_rate(dpll_ck, DRA7_DPLL_GMAC_DEFFREQ);
>>>   if (rc)
>>>
>>
>>
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" 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: OMAP2: erratum I688 handling disabled for AM335x

2015-09-25 Thread Bastian Stender 

Hi,

On 09/25/2015 02:08 PM, Russell King - ARM Linux wrote:

On Fri, Sep 25, 2015 at 12:01:13PM +0200, Bastian Stender wrote:

Signed-off-by: Bastian Stender 
---
  arch/arm/mach-omap2/omap4-common.c | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/arch/arm/mach-omap2/omap4-common.c 
b/arch/arm/mach-omap2/omap4-common.c
index 949696b..a3a0cd1 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -131,6 +131,12 @@ static int __init omap4_sram_init(void)
struct device_node *np;
struct gen_pool *sram_pool;

+   /* AM335x is OMAP2+, so no erratum I688 handling needed
+* (see CONFIG_OMAP4_ERRATA_I688) needed


This makes no sense.  OMAP4 is OMAP2+ as well, but it needs the erratum.
In fact, all code in mach-omap2 is "OMAP2+".

So, AM335x being "OMAP2+" is no reason at all why I688 should be disabled.


So, the Device Tree for AM335x does need a compatible = "ti,omap4-mpu" 
node + sram property for I688 handling?



Please fix this comment.  Please also put something in the commit message
which explains fully why you are making this change.


If this is the case, the patch is probably useless.

Regards,
Bastian
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" 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: am57xx-beagle-x15: set VDD_SD to always-on

2015-09-25 Thread Tomi Valkeinen 
LDO1 regulator (VDD_SD) is connected to SoC's vddshv8. vddshv8 needs to
be kept always powered (see commit 5a0f93c6576a ("ARM: dts: Add
am57xx-beagle-x15"), but at the moment VDD_SD is enabled/disabled
depending on whether an SD card is inserted or not.

This patch sets LDO1 regulator to always-on.

This patch has a side effect of fixing another issue, HDMI DDC not
working when SD card is not inserted:

Why this happens is that the tpd12s015 (HDMI level shifter/ESD
protection chip) has LS_OE GPIO input, which needs to be enabled for the
HDMI DDC to work. LS_OE comes from gpio6_28. The pin that provides
gpio6_28 is powered by vddshv8, and vddshv8 comes from VDD_SD.

So when SD card is not inserted, VDD_SD is disabled, and LS_OE stays
off.

The proper fix for the HDMI DDC issue would be to maybe have the pinctrl
framework manage the pin specific power.

Apparently this fixes also a third issue (copy paste from Kishon's
patch):

ldo1_reg in addition to being connected to the io lines is also
connected to the card detect line. On card removal, omap_hsmmc
driver does a regulator_disable causing card detect line to be
pulled down. This raises a card insertion interrupt and once the
MMC core detects there is no card inserted, it does a
regulator disable which again raises a card insertion interrupt.
This happens in a loop causing infinite MMC interrupts.

Fixes: 5a0f93c6576a ("ARM: dts: Add am57xx-beagle-x15")
Cc: Kishon Vijay Abraham I 
Signed-off-by: Tomi Valkeinen 
Reported-by: Louis McCarthy 
---
 arch/arm/boot/dts/am57xx-beagle-x15.dts | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts 
b/arch/arm/boot/dts/am57xx-beagle-x15.dts
index 3a05b94f59ed..ba8ef66a16e0 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
@@ -415,11 +415,12 @@
/* SMPS9 unused */
 
ldo1_reg: ldo1 {
-   /* VDD_SD  */
+   /* VDD_SD / VDDSHV8  */
regulator-name = "ldo1";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <330>;
regulator-boot-on;
+   regulator-always-on;
};
 
ldo2_reg: ldo2 {
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" 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: OMAP2: erratum I688 handling disabled for AM335x

2015-09-25 Thread Russell King - ARM Linux 
On Fri, Sep 25, 2015 at 12:01:13PM +0200, Bastian Stender wrote:
> Signed-off-by: Bastian Stender 
> ---
>  arch/arm/mach-omap2/omap4-common.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/arch/arm/mach-omap2/omap4-common.c 
> b/arch/arm/mach-omap2/omap4-common.c
> index 949696b..a3a0cd1 100644
> --- a/arch/arm/mach-omap2/omap4-common.c
> +++ b/arch/arm/mach-omap2/omap4-common.c
> @@ -131,6 +131,12 @@ static int __init omap4_sram_init(void)
>   struct device_node *np;
>   struct gen_pool *sram_pool;
>  
> + /* AM335x is OMAP2+, so no erratum I688 handling needed
> +  * (see CONFIG_OMAP4_ERRATA_I688) needed

This makes no sense.  OMAP4 is OMAP2+ as well, but it needs the erratum.
In fact, all code in mach-omap2 is "OMAP2+".

So, AM335x being "OMAP2+" is no reason at all why I688 should be disabled.

Please fix this comment.  Please also put something in the commit message
which explains fully why you are making this change.

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

Re: [PATCH 07/17] ARM: dts: am4372: add reset data

2015-09-25 Thread Lokesh Vutla 
Hi Tero,

On Thursday 24 September 2015 07:56 PM, Tero Kristo wrote:
> Add reset data for pruss, gfx, wkup-m3 and system reset.
> 
> Signed-off-by: Tero Kristo 
> ---
>  arch/arm/boot/dts/am4372.dtsi |   24 
>  1 file changed, 24 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
> index 0447c04a..fcc8d31 100644
> --- a/arch/arm/boot/dts/am4372.dtsi
> +++ b/arch/arm/boot/dts/am4372.dtsi
> @@ -116,12 +116,15 @@
>   reg-names = "umem", "dmem";
>   ti,hwmods = "wkup_m3";
>   ti,pm-firmware = "am335x-pm-firmware.elf";
> + reset-names = "wkup_m3";
> + resets = < 0x2000 0x10 3 0x14 5>;
>   };
>  
>   prcm: prcm@1f {
>   compatible = "ti,am4-prcm";
>   reg = <0x1f 0x11000>;
>   interrupts = ;
> + #reset-cells = <5>;
>  
>   prcm_clocks: clocks {
>   #address-cells = <1>;
> @@ -130,6 +133,12 @@
>  
>   prcm_clockdomains: clockdomains {
>   };
> +
> + system_reset: system_reset {
> + compatible = "ti,system-reset";
> + reset-names = "system";
> + reset-cells = < 0x4000 0 0 4 0>;
This should be resets instead of reset-cells.
With this change, reboot is functional on AM437x GP evm.

Thanks and regards,
Lokesh
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] dmaengine: omap-dma: Enable packed accesses for cyclic transfers

2015-09-25 Thread Peter Ujfalusi 
Vinod,

On 09/14/2015 03:31 PM, Peter Ujfalusi wrote:
> From: Misael Lopez Cruz 
> 
> The L3 throughput can be higher than expected when packed access
> is not enabled.  The ratio depends on the number of bytes in a
> transaction and the EMIF interface width.

Can you take a look at this patch?

Thanks,
Péter

> The throughput was measured for the following settings/cases:
> 
> * Case 1: Burst size of 64 bytes, packed access disabled
> * Case 2: Burst size of 64 bytes, packed access enabled
> * Case 3: Burst disabled, packed access disabled
> 
> Throughput measurements were done during McASP-based audio
> playback on the Jacinto6 EVM using the omapconf tool [1]:
> $ omapconf trace bw -m sdma_rd
> 
>  -
>   Throughput (MB/s)
>   Audio parametersCase 1Case 2Case 3
>  -
>   44.1kHz, 16-bits, stereo  1.41  0.18  1.41
>   44.1kHz, 32-bits, stereo  1.41  0.35  1.41
>   44.1kHz, 16-bits, 4-chan  2.82  0.35  2.82
>   44.1kHz, 16-bits, 6-chan  4.23  0.53  4.23
>   44.1kHz, 16-bits, 8-chan  5.64  0.71  5.64
>  -
> 
> From above measurements, case 2 is the only one that delivers
> the expected throughput for the given audio parameters.  For
> that reason, the packed accesses are now enabled.
> 
> It's worth to mention that packed accesses cannot be enabled
> for all addressing modes. In cyclic transfers, it can be
> enabled in the source for MEM_TO_DEV and in dest for DEV_TO_MEM,
> as they use post-increment mode which supports packed accesses.
> 
> Peter Ujfalusi:
> From the TRM regarding to this:
> "NOTE: Except in the constant addressing mode, the source or
> destination must be specified as packed for burst transactions
> to occur."
> 
> So w/o the packed setting the burst on the MEM side was not
> enabled, this explains the numbers.
> 
> [1] https://github.com/omapconf/omapconf
> 
> Signed-off-by: Misael Lopez Cruz 
> Signed-off-by: Peter Ujfalusi 
> ---
>  drivers/dma/omap-dma.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
> index 249445c8a4c6..1dfc71c90123 100644
> --- a/drivers/dma/omap-dma.c
> +++ b/drivers/dma/omap-dma.c
> @@ -935,8 +935,12 @@ static struct dma_async_tx_descriptor 
> *omap_dma_prep_dma_cyclic(
>   else
>   d->ccr |= CCR_SYNC_ELEMENT;
>  
> - if (dir == DMA_DEV_TO_MEM)
> + if (dir == DMA_DEV_TO_MEM) {
>   d->ccr |= CCR_TRIGGER_SRC;
> + d->csdp |= CSDP_DST_PACKED;
> + } else {
> + d->csdp |= CSDP_SRC_PACKED;
> + }
>  
>   d->cicr |= CICR_MISALIGNED_ERR_IE | CICR_TRANS_ERR_IE;
>  
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" 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] Trace: PM: promote event 'power_domain_target' to generic power domains.

2015-09-25 Thread Marc Titinger 
- change arg3 to a state name string: we got the current CPU from the trace
backend already. This also prepares for multiple/named states in the power
domain.

- tested with Juno Dev Platform

-0 [000]42.395510: power_domain_target:  a53_pd index=0 
'cluster-sleep-0'
-0 [000]42.395528: cpu_idle: state=4294967295 cpu_id=0
-0 [000]42.395668: cpu_idle: state=2 cpu_id=0

- compiled for Omap2+

Depends on this patch set from Axel Haslam:

[v7,1/5] PM / Domains: prepare for multiple states
[v7,2/5] PM / Domains: core changes for multiple states
[v7,3/5] PM / Domains: make governor select deepest state
[v7,4/5] ARM: imx6: pm: declare pm domain latency on power_state struct.
[v7,5/5] PM / Domains: remove old power on/off latencies.


Marc Titinger (2):
  Trace: PM: promote event 'power_domain_target' to generic power
domains.
  arm: omap2+: PM: change trace_power_domain_target event format.

 arch/arm/mach-omap2/powerdomain.c | 32 
 drivers/base/power/domain.c   |  9 +
 include/trace/events/power.h  | 29 +++--
 3 files changed, 44 insertions(+), 26 deletions(-)

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" 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] Trace: PM: promote event 'power_domain_target' to generic power domains.

2015-09-25 Thread Marc Titinger 
From: Marc Titinger 

- change arg3 to a state name string: we got the current CPU rom the trace
backend already. This also prepares for multiple/named states in the power
domain, consistent with idle-states. states in the domain may match given
CPU states in this case, we will trace them by their name, and potentially
use arg2 as a link to their index for the cpuidle driver.

- tested with Juno DP

-0 [000]42.395510: power_domain_target:  a53_pd index=0 
'cluster-sleep-0'
-0 [000]42.395528: cpu_idle: state=4294967295 cpu_id=0
-0 [000]42.395668: cpu_idle: state=2 cpu_id=0

- compiled for Omap2+

Signed-off-by: Marc Titinger 
---
 drivers/base/power/domain.c  |  9 +
 include/trace/events/power.h | 29 +++--
 2 files changed, 24 insertions(+), 14 deletions(-)

diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 59ccd92..b9e2a37 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -21,6 +21,10 @@
 #include 
 #include 
 
+#ifdef CONFIG_PM_ADVANCED_DEBUG
+#include 
+#endif
+
 #define GENPD_RETRY_MAX_MS 250 /* Approximate */
 
 #define GENPD_DEV_CALLBACK(genpd, type, callback, dev) \
@@ -328,6 +332,11 @@ static int __pm_genpd_poweron(struct generic_pm_domain 
*genpd)
 
  out:
genpd->status = GPD_STATE_ACTIVE;
+
+#ifdef CONFIG_PM_ADVANCED_DEBUG
+   trace_power_domain_target(genpd->name, genpd->state_idx,
+   genpd->states[genpd->state_idx].name);
+#endif
return 0;
 
  err:
diff --git a/include/trace/events/power.h b/include/trace/events/power.h
index 284244e..8f93be6 100644
--- a/include/trace/events/power.h
+++ b/include/trace/events/power.h
@@ -237,9 +237,9 @@ DECLARE_EVENT_CLASS(clock,
TP_ARGS(name, state, cpu_id),
 
TP_STRUCT__entry(
-   __string(   name,   name)
-   __field(u64,state   )
-   __field(u64,cpu_id  )
+   __string(name, name)
+   __field(u64, state)
+   __field(u64, cpu_id)
),
 
TP_fast_assign(
@@ -278,31 +278,32 @@ DEFINE_EVENT(clock, clock_set_rate,
  */
 DECLARE_EVENT_CLASS(power_domain,
 
-   TP_PROTO(const char *name, unsigned int state, unsigned int cpu_id),
+   TP_PROTO(const char *name, unsigned int index, const char *state_name),
 
-   TP_ARGS(name, state, cpu_id),
+   TP_ARGS(name, index, state_name),
 
TP_STRUCT__entry(
-   __string(   name,   name)
-   __field(u64,state   )
-   __field(u64,cpu_id  )
+   __string(name, name)
+   __field(u64, index)
+   __string(state_name, state_name)
),
 
TP_fast_assign(
__assign_str(name, name);
-   __entry->state = state;
-   __entry->cpu_id = cpu_id;
+   __entry->index = index;
+   __assign_str(state_name, state_name);
 ),
 
-   TP_printk("%s state=%lu cpu_id=%lu", __get_str(name),
-   (unsigned long)__entry->state, (unsigned long)__entry->cpu_id)
+   TP_printk("%s index=%lu '%s'", __get_str(name),
+   (unsigned long)__entry->index,
+   __get_str(state_name))
 );
 
 DEFINE_EVENT(power_domain, power_domain_target,
 
-   TP_PROTO(const char *name, unsigned int state, unsigned int cpu_id),
+   TP_PROTO(const char *name, unsigned int index, const char *state_name),
 
-   TP_ARGS(name, state, cpu_id)
+   TP_ARGS(name, index, state_name)
 );
 
 /*
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" 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] arm: omap2+: PM: change trace_power_domain_target event format.

2015-09-25 Thread Marc Titinger 
From: Marc Titinger 

power_domain_target arg3 is now a string (event name) with generic power
domains. In the case of Omap, it is a hint to the prev/next switch op.
Incidentally this trace is now conditioned by CONFIG_PM_ADVANCED_DEBUG.

Compiled for Omap2+ but not tested.

Signed-off-by: Marc Titinger 
---
 arch/arm/mach-omap2/powerdomain.c | 32 
 1 file changed, 20 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-omap2/powerdomain.c 
b/arch/arm/mach-omap2/powerdomain.c
index 78af6d8..cd77696 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -160,7 +160,7 @@ static void _update_logic_membank_counters(struct 
powerdomain *pwrdm)
 static int _pwrdm_state_switch(struct powerdomain *pwrdm, int flag)
 {
 
-   int prev, next, state, trace_state = 0;
+   int prev, state;
 
if (pwrdm == NULL)
return -EINVAL;
@@ -177,18 +177,25 @@ static int _pwrdm_state_switch(struct powerdomain *pwrdm, 
int flag)
pwrdm->state_counter[prev]++;
if (prev == PWRDM_POWER_RET)
_update_logic_membank_counters(pwrdm);
-   /*
-* If the power domain did not hit the desired state,
-* generate a trace event with both the desired and hit states
-*/
-   next = pwrdm_read_next_pwrst(pwrdm);
-   if (next != prev) {
-   trace_state = (PWRDM_TRACE_STATES_FLAG |
+
+#ifdef CONFIG_PM_ADVANCED_DEBUG
+   {
+   /*
+* If the power domain did not hit the desired state,
+* generate a trace event with both the desired and hit
+* states */
+   int next = pwrdm_read_next_pwrst(pwrdm);
+
+   if (next != prev) {
+   int trace_state = (PWRDM_TRACE_STATES_FLAG |
   ((next & OMAP_POWERSTATE_MASK) << 8) |
   ((prev & OMAP_POWERSTATE_MASK) << 0));
-   trace_power_domain_target(pwrdm->name, trace_state,
- smp_processor_id());
+   trace_power_domain_target(pwrdm->name,
+   trace_state, "PWRDM_STATE_PREV");
+   }
}
+#endif
+
break;
default:
return -EINVAL;
@@ -522,9 +529,10 @@ int pwrdm_set_next_pwrst(struct powerdomain *pwrdm, u8 
pwrst)
 pwrdm->name, pwrst);
 
if (arch_pwrdm && arch_pwrdm->pwrdm_set_next_pwrst) {
+#ifdef CONFIG_PM_ADVANCED_DEBUG
/* Trace the pwrdm desired target state */
-   trace_power_domain_target(pwrdm->name, pwrst,
- smp_processor_id());
+   trace_power_domain_target(pwrdm->name, pwrst, "set_next_pwrst");
+#endif
/* Program the pwrdm desired target state */
ret = arch_pwrdm->pwrdm_set_next_pwrst(pwrdm, pwrst);
}
-- 
1.9.1

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

[PATCH] ARM: OMAP2: erratum I688 handling disabled for AM335x

2015-09-25 Thread Bastian Stender 
Signed-off-by: Bastian Stender 
---
 arch/arm/mach-omap2/omap4-common.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/mach-omap2/omap4-common.c 
b/arch/arm/mach-omap2/omap4-common.c
index 949696b..a3a0cd1 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -131,6 +131,12 @@ static int __init omap4_sram_init(void)
struct device_node *np;
struct gen_pool *sram_pool;
 
+   /* AM335x is OMAP2+, so no erratum I688 handling needed
+* (see CONFIG_OMAP4_ERRATA_I688) needed
+*/
+   if (soc_is_am335x())
+   return 0;
+
np = of_find_compatible_node(NULL, NULL, "ti,omap4-mpu");
if (!np)
pr_warn("%s:Unable to allocate sram needed to handle errata 
I688\n",
-- 
2.5.1

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

Re: [PATCH 1/2] Trace: PM: promote event 'power_domain_target' to generic power domains.

2015-09-25 Thread Steven Rostedt 
On Fri, 25 Sep 2015 15:22:24 +0200
Marc Titinger  wrote:

> From: Marc Titinger 
> 
> - change arg3 to a state name string: we got the current CPU rom the trace
> backend already. This also prepares for multiple/named states in the power
> domain, consistent with idle-states. states in the domain may match given
> CPU states in this case, we will trace them by their name, and potentially
> use arg2 as a link to their index for the cpuidle driver.
> 
> - tested with Juno DP
> 
> -0 [000]42.395510: power_domain_target:  a53_pd index=0 
> 'cluster-sleep-0'
> -0 [000]42.395528: cpu_idle: state=4294967295 
> cpu_id=0
> -0 [000]42.395668: cpu_idle: state=2 cpu_id=0
> 
> - compiled for Omap2+
> 
> Signed-off-by: Marc Titinger 
> ---
>  drivers/base/power/domain.c  |  9 +
>  include/trace/events/power.h | 29 +++--
>  2 files changed, 24 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> index 59ccd92..b9e2a37 100644
> --- a/drivers/base/power/domain.c
> +++ b/drivers/base/power/domain.c
> @@ -21,6 +21,10 @@
>  #include 
>  #include 
>  
> +#ifdef CONFIG_PM_ADVANCED_DEBUG
> +#include 
> +#endif

Are the events in events/power.h only available when PM_ADVANCED_DEBUG
is enabled? If so, this should probably be encapsulated in that header
file, with an "#else" that makes all the trace_power_*() calls into
static inlined nops. Then you can get rid of the ugly #ifdef in this
file.


> +
>  #define GENPD_RETRY_MAX_MS   250 /* Approximate */
>  
>  #define GENPD_DEV_CALLBACK(genpd, type, callback, dev)   \
> @@ -328,6 +332,11 @@ static int __pm_genpd_poweron(struct generic_pm_domain 
> *genpd)
>  
>   out:
>   genpd->status = GPD_STATE_ACTIVE;
> +
> +#ifdef CONFIG_PM_ADVANCED_DEBUG
> + trace_power_domain_target(genpd->name, genpd->state_idx,
> + genpd->states[genpd->state_idx].name);
> +#endif
>   return 0;
>  
>   err:
> diff --git a/include/trace/events/power.h b/include/trace/events/power.h
> index 284244e..8f93be6 100644
> --- a/include/trace/events/power.h
> +++ b/include/trace/events/power.h
> @@ -237,9 +237,9 @@ DECLARE_EVENT_CLASS(clock,
>   TP_ARGS(name, state, cpu_id),
>  
>   TP_STRUCT__entry(
> - __string(   name,   name)
> - __field(u64,state   )
> - __field(u64,cpu_id  )
> + __string(name, name)
> + __field(u64, state)
> + __field(u64, cpu_id)

Note, the standard formatting for the tracepoints is with the spaces.
Igonre checkpatch for that, tracepoints don't follow it.

-- Steve

>   ),
>  
>   TP_fast_assign(
> @@ -278,31 +278,32 @@ DEFINE_EVENT(clock, clock_set_rate,
>   */
>  DECLARE_EVENT_CLASS(power_domain,

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

Re: [PATCH 2/2] arm: omap2+: PM: change trace_power_domain_target event format.

2015-09-25 Thread Steven Rostedt 
On Fri, 25 Sep 2015 15:22:25 +0200
Marc Titinger  wrote:

> From: Marc Titinger 
> 
> power_domain_target arg3 is now a string (event name) with generic power
> domains. In the case of Omap, it is a hint to the prev/next switch op.
> Incidentally this trace is now conditioned by CONFIG_PM_ADVANCED_DEBUG.

I'm curious to why the addition of this config option?

> 
> Compiled for Omap2+ but not tested.
> 
> Signed-off-by: Marc Titinger 
> ---
>  arch/arm/mach-omap2/powerdomain.c | 32 
>  1 file changed, 20 insertions(+), 12 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/powerdomain.c 
> b/arch/arm/mach-omap2/powerdomain.c
> index 78af6d8..cd77696 100644
> --- a/arch/arm/mach-omap2/powerdomain.c
> +++ b/arch/arm/mach-omap2/powerdomain.c
> @@ -160,7 +160,7 @@ static void _update_logic_membank_counters(struct 
> powerdomain *pwrdm)
>  static int _pwrdm_state_switch(struct powerdomain *pwrdm, int flag)
>  {
>  
> - int prev, next, state, trace_state = 0;
> + int prev, state;
>  
>   if (pwrdm == NULL)
>   return -EINVAL;
> @@ -177,18 +177,25 @@ static int _pwrdm_state_switch(struct powerdomain 
> *pwrdm, int flag)
>   pwrdm->state_counter[prev]++;
>   if (prev == PWRDM_POWER_RET)
>   _update_logic_membank_counters(pwrdm);
> - /*
> -  * If the power domain did not hit the desired state,
> -  * generate a trace event with both the desired and hit states
> -  */
> - next = pwrdm_read_next_pwrst(pwrdm);
> - if (next != prev) {
> - trace_state = (PWRDM_TRACE_STATES_FLAG |
> +
> +#ifdef CONFIG_PM_ADVANCED_DEBUG

You do realize that you can add this to the block:


if (trace_power_domain_target_enabled()) {

as it seems this code is only run to pass data to the tracepoint. The
above if statement will keep this block in the 'out-of-line' path when
tracing is not enabled via a static_key (jump-label).

-- Steve

> + {
> + /*
> +  * If the power domain did not hit the desired state,
> +  * generate a trace event with both the desired and hit
> +  * states */
> + int next = pwrdm_read_next_pwrst(pwrdm);
> +
> + if (next != prev) {
> + int trace_state = (PWRDM_TRACE_STATES_FLAG |
>  ((next & OMAP_POWERSTATE_MASK) << 8) |
>  ((prev & OMAP_POWERSTATE_MASK) << 0));
> - trace_power_domain_target(pwrdm->name, trace_state,
> -   smp_processor_id());
> + trace_power_domain_target(pwrdm->name,
> + trace_state, "PWRDM_STATE_PREV");
> + }
>   }
> +#endif
> +
>   break;
>   default:
>   return -EINVAL;
> @@ -522,9 +529,10 @@ int pwrdm_set_next_pwrst(struct powerdomain *pwrdm, u8 
> pwrst)
>pwrdm->name, pwrst);
>  
>   if (arch_pwrdm && arch_pwrdm->pwrdm_set_next_pwrst) {
> +#ifdef CONFIG_PM_ADVANCED_DEBUG
>   /* Trace the pwrdm desired target state */
> - trace_power_domain_target(pwrdm->name, pwrst,
> -   smp_processor_id());
> + trace_power_domain_target(pwrdm->name, pwrst, "set_next_pwrst");
> +#endif
>   /* Program the pwrdm desired target state */
>   ret = arch_pwrdm->pwrdm_set_next_pwrst(pwrdm, pwrst);
>   }

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