Re: [PATCH v3 0/3] ARM: OMAP2+: hwmod: RTC: Add lock and unlock hooks

2015-09-28 Thread Lokesh Vutla 
Hi Paul,

On Monday 28 September 2015 10:05 PM, Paul Walmsley wrote:
> On Thu, 24 Sep 2015, Lokesh Vutla wrote:
> 
>> On Thursday 27 August 2015 09:51 AM, Lokesh Vutla wrote:
>>> On Thursday 23 July 2015 06:55 PM, Lokesh Vutla wrote:
 This series implements lock and unlock functions for RTC and hooks
 the same to DRA7 and AMx3xx hwmod.
 This is dependent on the patch https://patchwork.kernel.org/patch/6578281/,
 which is queued recently by Paul.
>>> Gentle ping on this series.
>> Do you have any comments on this series?
> 
> Looks pretty good.  I'm slightly concerned about the latency jitter impact 
> on -rt kernels for that local_irq_disable() section.  Looks like it could 
> hold off interrupts for ~(50 udelay µs) + 50*((RTC register read time) + 
> 1).  But I'm not sure if preempt_enable/disable() is a good alternative 
> since a bunch of interrupt top halves could conceivably run after the RTC 
> goes non-busy and result in the RTC not being locked/unlocked. 
Agree.

> 
> Is there an RTC IP block register that the code can read, or a safe 
> sequence that the code can execute, after the RTC lock/unlock operation to 
> verify that the RTC has successfully been locked or unlocked?  If so then 
> it's probably worth converting the local_irq_disable/enable() to 
> preempt_disable/enable() and testing that, then retrying the lock/unlock 
> if it fails.
I am afraid there is no such register to verify lock or unlock. Also
these KICK registers are Write only registers so can't read back the
value. Even the driver implement the same api's for writing into registers.

One thing I can think of is that to write a known pattern to scratch pad
register and read back the value to confirm if it is locked/unlocked.
But don't think this is a good approach.

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 v3 0/3] ARM: OMAP2+: hwmod: RTC: Add lock and unlock hooks

2015-09-28 Thread Paul Walmsley 
On Thu, 24 Sep 2015, Lokesh Vutla wrote:

> On Thursday 27 August 2015 09:51 AM, Lokesh Vutla wrote:
> > On Thursday 23 July 2015 06:55 PM, Lokesh Vutla wrote:
> >> This series implements lock and unlock functions for RTC and hooks
> >> the same to DRA7 and AMx3xx hwmod.
> >> This is dependent on the patch https://patchwork.kernel.org/patch/6578281/,
> >> which is queued recently by Paul.
> > Gentle ping on this series.
> Do you have any comments on this series?

Looks pretty good.  I'm slightly concerned about the latency jitter impact 
on -rt kernels for that local_irq_disable() section.  Looks like it could 
hold off interrupts for ~(50 udelay µs) + 50*((RTC register read time) + 
1).  But I'm not sure if preempt_enable/disable() is a good alternative 
since a bunch of interrupt top halves could conceivably run after the RTC 
goes non-busy and result in the RTC not being locked/unlocked.  

Is there an RTC IP block register that the code can read, or a safe 
sequence that the code can execute, after the RTC lock/unlock operation to 
verify that the RTC has successfully been locked or unlocked?  If so then 
it's probably worth converting the local_irq_disable/enable() to 
preempt_disable/enable() and testing that, then retrying the lock/unlock 
if it fails.


- Paul

[PATCH] arm: omap2: timer: always define omap4_local_timer_init

2015-09-28 Thread Felipe Balbi 
omap4_local_timer_init() can be used by other
platforms as is. At least AM437x wants to use
it. Instead of making omap4-only and providing
a stub for builds without OMAP4, we can just
always define that function.

Reported-by: Nishanth Menon 
Signed-off-by: Felipe Balbi 
---
 arch/arm/mach-omap2/timer.c | 9 -
 1 file changed, 9 deletions(-)

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index a55655127ef2..f9028582e962 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -642,20 +642,11 @@ static OMAP_SYS_32K_TIMER_INIT(4, 1, "timer_32k_ck", 
"ti,timer-alwon",
   2, "sys_clkin_ck", NULL);
 #endif
 
-#ifdef CONFIG_ARCH_OMAP4
-#ifdef CONFIG_HAVE_ARM_TWD
 void __init omap4_local_timer_init(void)
 {
omap4_sync32k_timer_init();
clocksource_of_init();
 }
-#else
-void __init omap4_local_timer_init(void)
-{
-   omap4_sync32k_timer_init();
-}
-#endif /* CONFIG_HAVE_ARM_TWD */
-#endif /* CONFIG_ARCH_OMAP4 */
 
 #if defined(CONFIG_SOC_OMAP5) || defined(CONFIG_SOC_DRA7XX)
 void __init omap5_realtime_timer_init(void)
-- 
2.5.0.GIT

--
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 RFC] ASoC: simple-card: Update clocks binding for simple-card DAI subnodes

2015-09-28 Thread Jyri Sarha 

On 09/19/15 21:42, Mark Brown wrote:

On Fri, Sep 11, 2015 at 04:18:02PM +0300, Jyri Sarha wrote:


The updated binding provides a way to set clock-ID and direction
parameters for DAI drivers set_sysclk() call back.



I proposed something similar about a year ago, but Mark rejected that
at the time. This RFC is to start that discussion again. This time
before I do any code changes.


What's the use case again?  Can we address this by converting the
relevant drivers to the clock API (or improving their clock API
support)?



Sorry, I forgot to reply this earlier. The reason why we need this is 
the way McASP driver uses and provides clocks for different purposes. 
The most pressing need is to be able to select if we want to use some 
external clock pin as an input for McASP clock divider that produces the 
i2s bit-clock or if we want to use McASP's internal clock source.


There are several other things this binding would allow us, and others 
with flexible i2s HW, to do. Some TI codecs would also benefit from a 
flexible way of describing the used clock configuration, but Peter know 
that part better.


I tried to make the binding as flexible and generic as possible. But I 
do not currently see any immediate need for more than one set_sysclk() 
call per dai. I just did not see any reason to not allow it either.


Best regards,
Jyri
--
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/3] iio:adc: add iio driver for Palmas (twl6035/7) gpadc

2015-09-28 Thread H. Nikolaus Schaller 
Hi,

Am 27.09.2015 um 17:21 schrieb Jonathan Cameron :

> On 23/09/15 13:48, H. Nikolaus Schaller wrote:
>> This driver code was found as:
>> 
>> https://android.googlesource.com/kernel/tegra/+/aaabb2e045f31e5a970109ffdaae900dd403d17e/drivers/staging/iio/adc
>> 
>> Fixed various compilation issues and test this driver on omap5 evm.
>> 
>> Signed-off-by: Pradeep Goudagunta 
>> Signed-off-by: H. Nikolaus Schaller 
>> Signed-off-by: Marek Belisko 
> Various bits inline.

thanks for the valuable comments!

Will work into V2.

Nikolaus

> 
> Jonathan
>> ---
>> drivers/iio/adc/Kconfig|   9 +
>> drivers/iio/adc/Makefile   |   1 +
>> drivers/iio/adc/palmas_gpadc.c | 797 
>> +
>> include/linux/mfd/palmas.h |  59 ++-
>> 4 files changed, 862 insertions(+), 4 deletions(-)
>> create mode 100644 drivers/iio/adc/palmas_gpadc.c
>> 
>> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
>> index eb0cd89..f6df9db 100644
>> --- a/drivers/iio/adc/Kconfig
>> +++ b/drivers/iio/adc/Kconfig
>> @@ -242,6 +242,15 @@ config NAU7802
>>To compile this driver as a module, choose M here: the
>>module will be called nau7802.
>> 
>> +config PALMAS_GPADC
>> +tristate "TI Palmas General Purpose ADC"
>> +depends on MFD_PALMAS
>> +help
>> +  Palmas series pmic chip by texas Instruments (twl6035/6037)
>> +  is used in smartphones and tablets and supports a 16 channel
>> +  general purpose ADC. Add iio driver to read different channel
>> +  of the GPADCs.
>> +
>> config QCOM_SPMI_IADC
>>  tristate "Qualcomm SPMI PMIC current ADC"
>>  depends on SPMI
>> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
>> index a096210..716f112 100644
>> --- a/drivers/iio/adc/Makefile
>> +++ b/drivers/iio/adc/Makefile
>> @@ -26,6 +26,7 @@ obj-$(CONFIG_MCP320X) += mcp320x.o
>> obj-$(CONFIG_MCP3422) += mcp3422.o
>> obj-$(CONFIG_MEN_Z188_ADC) += men_z188_adc.o
>> obj-$(CONFIG_NAU7802) += nau7802.o
>> +obj-$(CONFIG_PALMAS_GPADC) += palmas_gpadc.o
>> obj-$(CONFIG_QCOM_SPMI_IADC) += qcom-spmi-iadc.o
>> obj-$(CONFIG_QCOM_SPMI_VADC) += qcom-spmi-vadc.o
>> obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o
>> diff --git a/drivers/iio/adc/palmas_gpadc.c b/drivers/iio/adc/palmas_gpadc.c
>> new file mode 100644
>> index 000..17abb28
>> --- /dev/null
>> +++ b/drivers/iio/adc/palmas_gpadc.c
>> @@ -0,0 +1,797 @@
>> +/*
>> + * palmas-adc.c -- TI PALMAS GPADC.
>> + *
>> + * Copyright (c) 2013, NVIDIA Corporation. All rights reserved.
>> + *
>> + * Author: Pradeep Goudagunta 
>> + *
>> + * This program is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License as
>> + * published by the Free Software Foundation version 2.
>> + */
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define MOD_NAME "palmas-gpadc"
>> +#define ADC_CONVERSION_TIMEOUT  (msecs_to_jiffies(5000))
>> +#define TO_BE_CALCULATED 0
>> +
>> +struct palmas_gpadc_info {
>> +/* calibration codes and regs */
> Full docs on this would be appreciated.
>> +int x1;
>> +int x2;
>> +int v1;
>> +int v2;
>> +u8 trim1_reg;
>> +u8 trim2_reg;
>> +int gain;
>> +int offset;
>> +int gain_error;
>> +bool is_correct_code;
>> +};
>> +
>> +#define PALMAS_ADC_INFO(_chan, _x1, _x2, _v1, _v2, _t1, _t2, 
>> _is_correct_code)\
>> +[PALMAS_ADC_CH_##_chan] = { \
>> +.x1 = _x1,  \
>> +.x2 = _x2,  \
>> +.v1 = _v1,  \
>> +.v2 = _v2,  \
>> +.gain = TO_BE_CALCULATED,   \
>> +.offset = TO_BE_CALCULATED, \
>> +.gain_error = TO_BE_CALCULATED, \
>> +.trim1_reg = PALMAS_GPADC_TRIM##_t1,\
>> +.trim2_reg = PALMAS_GPADC_TRIM##_t2,\
>> +.is_correct_code = _is_correct_code \
>> +}
>> +
>> +static struct palmas_gpadc_info palmas_gpadc_info[] = {
>> +PALMAS_ADC_INFO(IN0, 2064, 3112, 630, 950, 1, 2, false),
>> +PALMAS_ADC_INFO(IN1, 2064, 3112, 630, 950, 1, 2, false),
>> +PALMAS_ADC_INFO(IN2, 2064, 3112, 1260, 1900, 3, 4, false),
>> +PALMAS_ADC_INFO(IN3, 2064, 3112, 630, 950, 1, 2, false),
>> +PALMAS_ADC_INFO(IN4, 2064, 3112, 630, 950, 1, 2, false),
>> +PALMAS_ADC_INFO(IN5, 2064, 3112, 630, 950, 1, 2, false),
>> +PALMAS_ADC_INFO(IN6, 2064, 3112, 2520, 3800, 5, 6,

Re: [PATCH] arm: omap2: timer: always define omap4_local_timer_init

2015-09-28 Thread Felipe Balbi 
On Mon, Sep 28, 2015 at 04:10:40PM -0500, Nishanth Menon wrote:
> On 09/28/2015 01:25 PM, Felipe Balbi wrote:
> > omap4_local_timer_init() can be used by other
> > platforms as is. At least AM437x wants to use
> > it. Instead of making omap4-only and providing
> > a stub for builds without OMAP4, we can just
> > always define that function.
> > 
> > Reported-by: Nishanth Menon 
> > Signed-off-by: Felipe Balbi 
> > ---
> >  arch/arm/mach-omap2/timer.c | 9 -
> >  1 file changed, 9 deletions(-)
> > 
> > diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
> > index a55655127ef2..f9028582e962 100644
> > --- a/arch/arm/mach-omap2/timer.c
> > +++ b/arch/arm/mach-omap2/timer.c
> > @@ -642,20 +642,11 @@ static OMAP_SYS_32K_TIMER_INIT(4, 1, "timer_32k_ck", 
> > "ti,timer-alwon",
> >2, "sys_clkin_ck", NULL);
> >  #endif
> >  
> > -#ifdef CONFIG_ARCH_OMAP4
> > -#ifdef CONFIG_HAVE_ARM_TWD
> >  void __init omap4_local_timer_init(void)
> >  {
> > omap4_sync32k_timer_init();
> > clocksource_of_init();
> >  }
> > -#else
> > -void __init omap4_local_timer_init(void)
> > -{
> > -   omap4_sync32k_timer_init();
> > -}
> > -#endif /* CONFIG_HAVE_ARM_TWD */
> > -#endif /* CONFIG_ARCH_OMAP4 */
> >  
> >  #if defined(CONFIG_SOC_OMAP5) || defined(CONFIG_SOC_DRA7XX)
> >  void __init omap5_realtime_timer_init(void)
> > 
> I am a little confused if this will build in a am437xx only build.
> 
> #define OMAP_SYS_32K_TIMER_INIT(name, clkev_nr, clkev_src, clkev_prop, \
> clksrc_nr, clksrc_src, clksrc_prop) \
> void __init omap##name##_sync32k_timer_init(void) \
> 
> Would you like to consider this for OMAP4 only build as well?
> 
> #if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5) || \
> 
> defined(CONFIG_SOC_DRA7XX)
> static OMAP_SYS_32K_TIMER_INIT(4, 1, "timer_32k_ck", "ti,timer-alwon",
>2, "sys_clkin_ck", NULL);
> #endif

heh, more of the ifdeferry to drop. Okay, I'll respin this

-- 
balbi


signature.asc
Description: PGP signature

[PATCHv2] arm: omap2: timer: always define omap4_local_timer_init

2015-09-28 Thread Felipe Balbi 
omap4_local_timer_init() can be used by other
platforms as is. At least AM437x wants to use
it. Instead of making omap4-only and providing
a stub for builds without OMAP4, we can just
always define that function.

Reported-by: Nishanth Menon 
Signed-off-by: Felipe Balbi 
---

changes since v1:
 - make sure result builds on AM43xx-only builds

 arch/arm/mach-omap2/timer.c | 14 ++
 1 file changed, 2 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index e4d8701f99f9..3cdd22251a0d 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -634,32 +634,22 @@ OMAP_SYS_32K_TIMER_INIT(3_secure, 12, "secure_32k_fck", 
"ti,timer-secure",
2, "timer_sys_ck", NULL);
 #endif /* CONFIG_ARCH_OMAP3 */
 
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM33XX) || \
-   defined(CONFIG_SOC_AM43XX)
+#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM33XX)
 OMAP_SYS_GP_TIMER_INIT(3, 2, "timer_sys_ck", NULL,
   1, "timer_sys_ck", "ti,timer-alwon");
 #endif
 
 #if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5) || \
-   defined(CONFIG_SOC_DRA7XX)
+   defined(CONFIG_SOC_DRA7XX) || defined(CONFIG_SOC_AM43XX)
 static OMAP_SYS_32K_TIMER_INIT(4, 1, "timer_32k_ck", "ti,timer-alwon",
   2, "sys_clkin_ck", NULL);
 #endif
 
-#ifdef CONFIG_ARCH_OMAP4
-#ifdef CONFIG_HAVE_ARM_TWD
 void __init omap4_local_timer_init(void)
 {
omap4_sync32k_timer_init();
clocksource_of_init();
 }
-#else
-void __init omap4_local_timer_init(void)
-{
-   omap4_sync32k_timer_init();
-}
-#endif /* CONFIG_HAVE_ARM_TWD */
-#endif /* CONFIG_ARCH_OMAP4 */
 
 #if defined(CONFIG_SOC_OMAP5) || defined(CONFIG_SOC_DRA7XX)
 void __init omap5_realtime_timer_init(void)
-- 
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: [PATCHv2] arm: omap2: timer: always define omap4_local_timer_init

2015-09-28 Thread Nishanth Menon 

bit of nitpick on capitalization of $subject.. aside..

On 09/28/2015 04:23 PM, Felipe Balbi wrote:
> omap4_local_timer_init() can be used by other
> platforms as is. At least AM437x wants to use
> it. Instead of making omap4-only and providing
> a stub for builds without OMAP4, we can just
> always define that function.
> 
> Reported-by: Nishanth Menon 
> Signed-off-by: Felipe Balbi 
> ---
> 
> changes since v1:
>  - make sure result builds on AM43xx-only builds
> 
>  arch/arm/mach-omap2/timer.c | 14 ++
>  1 file changed, 2 insertions(+), 12 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
> index e4d8701f99f9..3cdd22251a0d 100644
> --- a/arch/arm/mach-omap2/timer.c
> +++ b/arch/arm/mach-omap2/timer.c
> @@ -634,32 +634,22 @@ OMAP_SYS_32K_TIMER_INIT(3_secure, 12, "secure_32k_fck", 
> "ti,timer-secure",
>   2, "timer_sys_ck", NULL);
>  #endif /* CONFIG_ARCH_OMAP3 */
>  
> -#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM33XX) || \
> - defined(CONFIG_SOC_AM43XX)
> +#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM33XX)
>  OMAP_SYS_GP_TIMER_INIT(3, 2, "timer_sys_ck", NULL,
>  1, "timer_sys_ck", "ti,timer-alwon");
>  #endif
>  
>  #if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5) || \
> - defined(CONFIG_SOC_DRA7XX)
> + defined(CONFIG_SOC_DRA7XX) || defined(CONFIG_SOC_AM43XX)
>  static OMAP_SYS_32K_TIMER_INIT(4, 1, "timer_32k_ck", "ti,timer-alwon",
>  2, "sys_clkin_ck", NULL);
>  #endif
>  
> -#ifdef CONFIG_ARCH_OMAP4
> -#ifdef CONFIG_HAVE_ARM_TWD

OK -> so we removed both of these..

>  void __init omap4_local_timer_init(void)
>  {
>   omap4_sync32k_timer_init();

but this only gets defined *if*
>  #if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5) || \
> - defined(CONFIG_SOC_DRA7XX)
> + defined(CONFIG_SOC_DRA7XX) || defined(CONFIG_SOC_AM43XX)

we should fail build on omap3 only, correct??

or am i missing something else?

>   clocksource_of_init();
>  }
> -#else
> -void __init omap4_local_timer_init(void)
> -{
> - omap4_sync32k_timer_init();
> -}
> -#endif /* CONFIG_HAVE_ARM_TWD */
> -#endif /* CONFIG_ARCH_OMAP4 */
>  
>  #if defined(CONFIG_SOC_OMAP5) || defined(CONFIG_SOC_DRA7XX)
>  void __init omap5_realtime_timer_init(void)
> 



-- 
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 07/17] ARM: dts: am4372: add reset data

2015-09-28 Thread Tero Kristo 

On 09/25/2015 03:57 PM, Lokesh Vutla wrote:

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.


Oops, nasty typo there. Thanks for catching.

-Tero



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

OMAP baseline test results for v4.3-rc3

2015-09-28 Thread Paul Walmsley 

Here are some basic OMAP test results for Linux v4.3-rc3.
Logs and other details at:

http://www.pwsan.com/omap/testlogs/test_v4.3-rc3/20150927222545/


Test summary


Build: uImage:
Pass ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only,
  omap1_defconfig_5912osk_only

Build: uImage+dtb:
Pass (13/13): omap2plus_defconfig_am33xx_only/am335x-bone,
  omap2plus_defconfig/omap4-panda,
  omap2plus_defconfig/omap4-panda-es,
  omap2plus_defconfig/omap4-var-stk-om44,
  omap2plus_defconfig/omap3-evm-37xx,
  omap2plus_defconfig_n800_only_a/omap2420-n800,
  omap2plus_defconfig/omap2430-sdp,
  omap2plus_defconfig/am3517-evm,
  omap2plus_defconfig/omap3-beagle,
  omap2plus_defconfig/omap3-beagle-xm,
  omap2plus_defconfig/omap3-sbc-t3517,
  omap2plus_defconfig/omap5-uevm,
  omap2plus_defconfig/omap5-sbc-t54

Build: zImage:
Pass (17/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only,
  omap2plus_defconfig_n800_only_a,
  omap2plus_defconfig_n800_multi_omap2xxx,
  omap2plus_defconfig_2430sdp_only,
  omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm,
  omap2plus_defconfig_omap2_4_only,
  omap2plus_defconfig_omap3_4_only,
  omap2plus_defconfig_omap5_only,
  omap2plus_defconfig_dra7xx_only,
  omap2plus_defconfig_am43xx_only,
  rmk_omap3430_ldp_oldconfig,
  rmk_omap3430_ldp_allnoconfig,
  rmk_omap4430_sdp_oldconfig,
  rmk_omap4430_sdp_allnoconfig, multi_v7_defconfig

Build warnings from toolchain: uImage:
(none)

Build warnings from toolchain: uImage+dtb:
(none)

Build warnings from toolchain: zImage:
FAIL (10/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only,
  omap2plus_defconfig_2430sdp_only,
  omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm,
  omap2plus_defconfig_omap2_4_only,
  omap2plus_defconfig_omap3_4_only,
  omap2plus_defconfig_omap5_only,
  omap2plus_defconfig_dra7xx_only,
  omap2plus_defconfig_am43xx_only

Boot to userspace:
FAIL ( 1/17): 2430sdp
skip ( 3/17): 5912osk, 3517evm, 5430es2sbct54
Pass (13/17): am335xbonelt, am335xbone, 4430es2panda, 4460pandaes,
  4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle,
  3730beaglexm, 3730es12beaglexm, cmt3517, 5430es2uevm,
  2420n800

Kernel warnings during boot to userspace:
FAIL ( 3/17): 4430es2panda, 4460varsomom, cmt3517

PM: chip retention via suspend:
FAIL ( 6/11): am335xbonelt, 4430es2panda, 4460varsomom, 37xxevm,
  2430sdp, 5430es2uevm
Pass ( 5/11): 4460pandaes, 3530es3beagle, 3530es31beagle,
  3730beaglexm, 3730es12beaglexm

PM: chip retention via dynamic idle:
FAIL ( 6/11): am335xbonelt, 4430es2panda, 4460varsomom, 37xxevm,
  2430sdp, 5430es2uevm
Pass ( 5/11): 4460pandaes, 3530es3beagle, 3530es31beagle,
  3730beaglexm, 3730es12beaglexm

PM: chip off (except CORE, due to errata) via suspend:
Pass ( 1/ 1): 3730beaglexm

PM: chip off (except CORE, due to errata) via dynamic idle:
Pass ( 1/ 1): 3730beaglexm

PM: chip off via suspend:
FAIL ( 1/ 4): 37xxevm
Pass ( 3/ 4): 3530es3beagle, 3530es31beagle, 3730es12beaglexm

PM: chip off via dynamic idle:
FAIL ( 1/ 4): 37xxevm
Pass ( 3/ 4): 3530es3beagle, 3530es31beagle, 3730es12beaglexm

Kernel warnings during PM test:
FAIL ( 2/17): 4430es2panda, 4460varsomom

Obsolete Kconfig symbols:
FAIL ( 2/20): omap2plus_defconfig, multi_v7_defconfig


vmlinux object size
(delta in bytes from test_v4.3-rc2 (1f93e4a96c9109378204c147b3eec0d0e8100fde)):
   text data  bsstotal  kernel
  +134600+1346  omap1_defconfig
  +237000+2370  omap1_defconfig_1510innovator_only
  +134600+1346  omap1_defconfig_5912osk_only
  +2246 +256  -64+2438  multi_v7_defconfig
  +6742  +64 -128+6678  omap2plus_defconfig
  +2014  +96  -96+2014  omap2plus_defconfig_2430sdp_only
  +6710  +64 -128+6646  omap2plus_defconfig_am33xx_only
  +2614  +64 -128+2550  omap2plus_defconfig_am43xx_only
  +6742  +64 -128+6678  omap2plus_defconfig_cpupm
  +7498  +64 -128+7434  omap2plus_defconfig_dra7xx_only
  +5100  +64  -96+5068  omap2plus_defconfig_n800_multi_omap2xxx
  +458800+4588  omap2plus_defconfig_n800_only_a
  +6742  +64 -128+6678  omap2plus_defconfig_no_pm
  +2614  +64 -128+2550

Re: [PATCH RFC v4 3/8] ASoC: hdmi-codec: Add hdmi-codec for external HDMI-encoders

2015-09-28 Thread Russell King - ARM Linux 
On Mon, Sep 28, 2015 at 11:01:34AM +0200, Arnaud Pouliquen wrote:
> few questions/remarks
> BR,
> Arnaud
> 
> >+static void hdmi_codec_abort(struct device *dev)
> >+{
> >+struct hdmi_codec_priv *hcp = dev_get_drvdata(dev);
> >+
> >+dev_dbg(dev, "%s()\n", __func__);
> >+
> >+mutex_lock(>current_stream_lock);
> >+if (hcp->current_stream && hcp->current_stream->runtime &&
> >+snd_pcm_running(hcp->current_stream)) {
> >+dev_info(dev, "HDMI audio playback aborted\n");
> >+snd_pcm_stream_lock_irq(hcp->current_stream);
> >+snd_pcm_stop(hcp->current_stream, SNDRV_PCM_STATE_DISCONNECTED);
> >+snd_pcm_stream_unlock_irq(hcp->current_stream);
> >+}
> >+mutex_unlock(>current_stream_lock);
> >+}
> Does driver should stop the stream in case of unplug?
> This could generate unexpected behavior at application level.
> Perhaps should be better if this part is managed in DRM driver. if HDMI
> master, I2S bus should be maintained ON to consume the audio stream until
> application action.

If it does, that's really horrid.

Firstly, do you expect your video playback to stop just because you've
unplugged the TV?  Maybe you've got a dumb HDMI switch, and you've
switched from one input to another to momentarily check something on
another input - should the video playback suddenly end up with its
audio path being dumped on the floor because of that?

Also, as I've said before, there's hardware out there where the SPDIF
audio output is routed to more than just the HDMI interface, and the
capabilities of HDMI really don't apply in that situation - you may
have an AV receiver connected to the SPDIF output which is able to
accept much more than the basic audio that most TVs accept.  Having
stuff restricted to the union of the abilities is far too restrictive.
Stopping the audio output because the TV went away in this case is also
plain idiotic.

SPDIF is something that can be routed to multiple devices simultaneously,
and there's no capability or connection reporting involved in it.
Imposing the status of one "SPDIF listener" on the entire audio system is
unreasonable.

> >+
> >+static int hdmi_codec_hw_params(struct snd_pcm_substream *substream,
> >+struct snd_pcm_hw_params *params,
> >+struct snd_soc_dai *dai)
> >+{
> >+struct hdmi_codec_priv *hcp = snd_soc_dai_get_drvdata(dai);
> >+struct hdmi_codec_params hp = {
> >+.iec = {
> >+.status = { 0 },
> >+.subcode = { 0 },
> >+.pad = 0,
> >+.dig_subframe = { 0 },
> >+}
> >+};
> >+int ret;
> >+
> >+dev_dbg(dai->dev, "%s() width %d rate %d channels %d\n", __func__,
> >+params_width(params), params_rate(params),
> >+params_channels(params));
> >+
> >+ret = snd_pcm_create_iec958_consumer_hw_params(params, hp.iec.status,
> >+   sizeof(hp.iec.status));
> Tell me if i am wrong, but in case of SPDIF format, IEC status is managed by
> cpu_dai not by the codec.

Correct.  I2S needs the IEC958 status programmed into the HDMI interface
though, because HDMI is basically SPDIF.

-- 
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 RFC v4 3/8] ASoC: hdmi-codec: Add hdmi-codec for external HDMI-encoders

2015-09-28 Thread Jyri Sarha 

On 09/28/15 12:01, Arnaud Pouliquen wrote:

few questions/remarks
BR,
Arnaud


+static void hdmi_codec_abort(struct device *dev)
+{
+struct hdmi_codec_priv *hcp = dev_get_drvdata(dev);
+
+dev_dbg(dev, "%s()\n", __func__);
+
+mutex_lock(>current_stream_lock);
+if (hcp->current_stream && hcp->current_stream->runtime &&
+snd_pcm_running(hcp->current_stream)) {
+dev_info(dev, "HDMI audio playback aborted\n");
+snd_pcm_stream_lock_irq(hcp->current_stream);
+snd_pcm_stop(hcp->current_stream, SNDRV_PCM_STATE_DISCONNECTED);
+snd_pcm_stream_unlock_irq(hcp->current_stream);
+}
+mutex_unlock(>current_stream_lock);
+}

Does driver should stop the stream in case of unplug?
This could generate unexpected behavior at application level.
Perhaps should be better if this part is managed in DRM driver. if HDMI
master, I2S bus should be maintained ON to consume the audio stream
until application action.



The whole point of this abort callback is to provide the means for the 
video side to stop the audio playback in a clean way.


The abort callback is given to the video side in startup() callback 
(ASoC side calls video side). If the video side sees that the playback 
can not go on it can call the abort callback and the audio playback will 
abort in standard ALSA way and a properly written applications should 
not get confused.


Nothing is forcing the video side to call the callback ever, if so 
decided. But if for instance power management stops the i2s clocks when 
connector is unplugged, then the audio can not go on any more and it 
should be aborted (actually it would abort in a moment when ALSA 
realizes that the DMA is not running).



+
+static int hdmi_codec_hw_params(struct snd_pcm_substream *substream,
+struct snd_pcm_hw_params *params,
+struct snd_soc_dai *dai)
+{
+struct hdmi_codec_priv *hcp = snd_soc_dai_get_drvdata(dai);
+struct hdmi_codec_params hp = {
+.iec = {
+.status = { 0 },
+.subcode = { 0 },
+.pad = 0,
+.dig_subframe = { 0 },
+}
+};
+int ret;
+
+dev_dbg(dai->dev, "%s() width %d rate %d channels %d\n", __func__,
+params_width(params), params_rate(params),
+params_channels(params));
+
+ret = snd_pcm_create_iec958_consumer_hw_params(params,
hp.iec.status,
+   sizeof(hp.iec.status));

Tell me if i am wrong, but in case of SPDIF format, IEC status is
managed by cpu_dai not by the codec.
To manage IEC61937 a control should be needed to update IEC status bits...



AFAIK yes. However, the video side implementation is free to ignore 
status bits in the struct hdmi_codec_params and it should normally do so 
if the format is SPDIF. Of course I could save couple CPU cycles in the 
codec code if would not even produce the bits when the format is SPDIF.


Best regards,
Jyri


+if (ret < 0) {
+dev_err(dai->dev, "Creating IEC958 channel status failed %d\n",
+ret);
+return ret;
+}
+
+ret = hdmi_codec_new_stream(substream, dai);
+if (ret)
+return ret;
+
+hdmi_audio_infoframe_init();
+hp.cea.channels = params_channels(params);
+hp.cea.coding_type = HDMI_AUDIO_CODING_TYPE_STREAM;
+hp.cea.sample_size = HDMI_AUDIO_SAMPLE_SIZE_STREAM;
+hp.cea.sample_frequency = HDMI_AUDIO_SAMPLE_FREQUENCY_STREAM;
+
+hp.sample_width = params_width(params);
+hp.sample_rate = params_rate(params);
+hp.channels = params_channels(params);
+
+return hcp->hcd.ops->hw_params(dai->dev->parent,
>daifmt[dai->id],
+   );
+}
+


--
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 RFC v4 3/8] ASoC: hdmi-codec: Add hdmi-codec for external HDMI-encoders

2015-09-28 Thread Daniel Vetter 
On Mon, Sep 28, 2015 at 12:26:28PM +0100, Russell King - ARM Linux wrote:
> On Mon, Sep 28, 2015 at 11:01:34AM +0200, Arnaud Pouliquen wrote:
> > few questions/remarks
> > BR,
> > Arnaud
> > 
> > >+static void hdmi_codec_abort(struct device *dev)
> > >+{
> > >+struct hdmi_codec_priv *hcp = dev_get_drvdata(dev);
> > >+
> > >+dev_dbg(dev, "%s()\n", __func__);
> > >+
> > >+mutex_lock(>current_stream_lock);
> > >+if (hcp->current_stream && hcp->current_stream->runtime &&
> > >+snd_pcm_running(hcp->current_stream)) {
> > >+dev_info(dev, "HDMI audio playback aborted\n");
> > >+snd_pcm_stream_lock_irq(hcp->current_stream);
> > >+snd_pcm_stop(hcp->current_stream, SNDRV_PCM_STATE_DISCONNECTED);
> > >+snd_pcm_stream_unlock_irq(hcp->current_stream);
> > >+}
> > >+mutex_unlock(>current_stream_lock);
> > >+}
> > Does driver should stop the stream in case of unplug?
> > This could generate unexpected behavior at application level.
> > Perhaps should be better if this part is managed in DRM driver. if HDMI
> > master, I2S bus should be maintained ON to consume the audio stream until
> > application action.
> 
> If it does, that's really horrid.

Atm the rule for display outputs is that nothing gets yanked until
userspace approves, since otherwise compositors get stuck (or fall over
with an unexpected -EINVAL from the kernel). The exception is DP MST
because the current implementation is a complete hack for DP MST sink
lifetimes and that's why we need to synchronously nuke them (which means
shutting down everything). I'm surprised not a hole lot more people
complain about this ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
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 RFC v4 3/8] ASoC: hdmi-codec: Add hdmi-codec for external HDMI-encoders

2015-09-28 Thread Arnaud Pouliquen 

few questions/remarks
BR,
Arnaud


+static void hdmi_codec_abort(struct device *dev)
+{
+struct hdmi_codec_priv *hcp = dev_get_drvdata(dev);
+
+dev_dbg(dev, "%s()\n", __func__);
+
+mutex_lock(>current_stream_lock);
+if (hcp->current_stream && hcp->current_stream->runtime &&
+snd_pcm_running(hcp->current_stream)) {
+dev_info(dev, "HDMI audio playback aborted\n");
+snd_pcm_stream_lock_irq(hcp->current_stream);
+snd_pcm_stop(hcp->current_stream, SNDRV_PCM_STATE_DISCONNECTED);
+snd_pcm_stream_unlock_irq(hcp->current_stream);
+}
+mutex_unlock(>current_stream_lock);
+}

Does driver should stop the stream in case of unplug?
This could generate unexpected behavior at application level.
Perhaps should be better if this part is managed in DRM driver. if HDMI 
master, I2S bus should be maintained ON to consume the audio stream 
until application action.



+
+static int hdmi_codec_hw_params(struct snd_pcm_substream *substream,
+struct snd_pcm_hw_params *params,
+struct snd_soc_dai *dai)
+{
+struct hdmi_codec_priv *hcp = snd_soc_dai_get_drvdata(dai);
+struct hdmi_codec_params hp = {
+.iec = {
+.status = { 0 },
+.subcode = { 0 },
+.pad = 0,
+.dig_subframe = { 0 },
+}
+};
+int ret;
+
+dev_dbg(dai->dev, "%s() width %d rate %d channels %d\n", __func__,
+params_width(params), params_rate(params),
+params_channels(params));
+
+ret = snd_pcm_create_iec958_consumer_hw_params(params, hp.iec.status,
+   sizeof(hp.iec.status));
Tell me if i am wrong, but in case of SPDIF format, IEC status is 
managed by cpu_dai not by the codec.

To manage IEC61937 a control should be needed to update IEC status bits...


+if (ret < 0) {
+dev_err(dai->dev, "Creating IEC958 channel status failed %d\n",
+ret);
+return ret;
+}
+
+ret = hdmi_codec_new_stream(substream, dai);
+if (ret)
+return ret;
+
+hdmi_audio_infoframe_init();
+hp.cea.channels = params_channels(params);
+hp.cea.coding_type = HDMI_AUDIO_CODING_TYPE_STREAM;
+hp.cea.sample_size = HDMI_AUDIO_SAMPLE_SIZE_STREAM;
+hp.cea.sample_frequency = HDMI_AUDIO_SAMPLE_FREQUENCY_STREAM;
+
+hp.sample_width = params_width(params);
+hp.sample_rate = params_rate(params);
+hp.channels = params_channels(params);
+
+return hcp->hcd.ops->hw_params(dai->dev->parent,
>daifmt[dai->id],
+   );
+}
+

--
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 v2 2/2] arm: omap2+: PM: change trace_power_domain_target event format.

2015-09-28 Thread 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.

Compiled for Omap2+ but not tested.

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

diff --git a/arch/arm/mach-omap2/powerdomain.c 
b/arch/arm/mach-omap2/powerdomain.c
index 78af6d8..02167c2 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,17 +177,21 @@ 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 |
+
+   if (trace_power_domain_target_enabled()) {
+   /*
+* 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");
+   }
}
break;
default:
@@ -523,8 +527,7 @@ int pwrdm_set_next_pwrst(struct powerdomain *pwrdm, u8 
pwrst)
 
if (arch_pwrdm && arch_pwrdm->pwrdm_set_next_pwrst) {
/* 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");
/* 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 v2 1/2] Trace: PM: promote event 'power_domain_target' to generic power domains.

2015-09-28 Thread 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  |  5 +
 include/trace/events/power.h | 21 +++--
 2 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 59ccd92..017c151 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -21,6 +21,8 @@
 #include 
 #include 
 
+#include 
+
 #define GENPD_RETRY_MAX_MS 250 /* Approximate */
 
 #define GENPD_DEV_CALLBACK(genpd, type, callback, dev) \
@@ -328,6 +330,9 @@ static int __pm_genpd_poweron(struct generic_pm_domain 
*genpd)
 
  out:
genpd->status = GPD_STATE_ACTIVE;
+
+   trace_power_domain_target(genpd->name, genpd->state_idx,
+   genpd->states[genpd->state_idx].name);
return 0;
 
  err:
diff --git a/include/trace/events/power.h b/include/trace/events/power.h
index 284244e..8172d93 100644
--- a/include/trace/events/power.h
+++ b/include/trace/events/power.h
@@ -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  )
+   __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 v3 1/2] Trace: PM: promote event 'power_domain_target' to generic power domains.

2015-09-28 Thread 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 
---

 v3: make this patch set applicable to current HEAD, since there is no
 dependency.

 drivers/base/power/domain.c  |  5 +
 include/trace/events/power.h | 21 +++--
 2 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 16550c6..6661a80 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -20,6 +20,8 @@
 #include 
 #include 
 
+#include 
+
 #define GENPD_RETRY_MAX_MS 250 /* Approximate */
 
 #define GENPD_DEV_CALLBACK(genpd, type, callback, dev) \
@@ -268,6 +270,9 @@ static int __pm_genpd_poweron(struct generic_pm_domain 
*genpd)
 
  out:
genpd->status = GPD_STATE_ACTIVE;
+
+   trace_power_domain_target(genpd->name, genpd->state_idx,
+   genpd->states[genpd->state_idx].name);
return 0;
 
  err:
diff --git a/include/trace/events/power.h b/include/trace/events/power.h
index 284244e..8172d93 100644
--- a/include/trace/events/power.h
+++ b/include/trace/events/power.h
@@ -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  )
+   __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 v3 2/2] arm: omap2+: PM: change trace_power_domain_target event format.

2015-09-28 Thread 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.

Compiled for Omap2+ but not tested.

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

diff --git a/arch/arm/mach-omap2/powerdomain.c 
b/arch/arm/mach-omap2/powerdomain.c
index 78af6d8..02167c2 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,17 +177,21 @@ 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 |
+
+   if (trace_power_domain_target_enabled()) {
+   /*
+* 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");
+   }
}
break;
default:
@@ -523,8 +527,7 @@ int pwrdm_set_next_pwrst(struct powerdomain *pwrdm, u8 
pwrst)
 
if (arch_pwrdm && arch_pwrdm->pwrdm_set_next_pwrst) {
/* 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");
/* 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

[RFC PATCH 1/2] pci: host: pci-dra7xx: use "num-lanes" property to find phy count

2015-09-28 Thread Kishon Vijay Abraham I 
use "num-lanes" property to find phy count instead of the number
phy-names property.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/pci/host/pci-dra7xx.c |   23 +++
 1 file changed, 11 insertions(+), 12 deletions(-)

diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
index 199e29a..e15b2e2 100644
--- a/drivers/pci/host/pci-dra7xx.c
+++ b/drivers/pci/host/pci-dra7xx.c
@@ -66,7 +66,7 @@
 struct dra7xx_pcie {
void __iomem*base;
struct phy  **phy;
-   int phy_count;
+   int lanes;
struct device   *dev;
struct pcie_portpp;
 };
@@ -328,7 +328,7 @@ static int __init dra7xx_pcie_probe(struct platform_device 
*pdev)
int ret;
int irq;
int i;
-   int phy_count;
+   u32 lanes;
struct phy **phy;
void __iomem *base;
struct resource *res;
@@ -362,17 +362,16 @@ static int __init dra7xx_pcie_probe(struct 
platform_device *pdev)
if (!base)
return -ENOMEM;
 
-   phy_count = of_property_count_strings(np, "phy-names");
-   if (phy_count < 0) {
-   dev_err(dev, "unable to find the strings\n");
-   return phy_count;
+   if (of_property_read_u32(np, "num-lanes", )) {
+   dev_err(dev, "Failed to parse the number of lanes\n");
+   return -EINVAL;
}
 
-   phy = devm_kzalloc(dev, sizeof(*phy) * phy_count, GFP_KERNEL);
+   phy = devm_kzalloc(dev, sizeof(*phy) * lanes, GFP_KERNEL);
if (!phy)
return -ENOMEM;
 
-   for (i = 0; i < phy_count; i++) {
+   for (i = 0; i < lanes; i++) {
snprintf(name, sizeof(name), "pcie-phy%d", i);
phy[i] = devm_phy_get(dev, name);
if (IS_ERR(phy[i]))
@@ -392,7 +391,7 @@ static int __init dra7xx_pcie_probe(struct platform_device 
*pdev)
dra7xx->base = base;
dra7xx->phy = phy;
dra7xx->dev = dev;
-   dra7xx->phy_count = phy_count;
+   dra7xx->lanes = lanes;
 
pm_runtime_enable(dev);
ret = pm_runtime_get_sync(dev);
@@ -449,7 +448,7 @@ static int __exit dra7xx_pcie_remove(struct platform_device 
*pdev)
struct dra7xx_pcie *dra7xx = platform_get_drvdata(pdev);
struct pcie_port *pp = >pp;
struct device *dev = >dev;
-   int count = dra7xx->phy_count;
+   int count = dra7xx->lanes;
 
if (pp->irq_domain)
irq_domain_remove(pp->irq_domain);
@@ -495,7 +494,7 @@ static int dra7xx_pcie_resume(struct device *dev)
 static int dra7xx_pcie_suspend_noirq(struct device *dev)
 {
struct dra7xx_pcie *dra7xx = dev_get_drvdata(dev);
-   int count = dra7xx->phy_count;
+   int count = dra7xx->lanes;
 
while (count--) {
phy_power_off(dra7xx->phy[count]);
@@ -508,7 +507,7 @@ static int dra7xx_pcie_suspend_noirq(struct device *dev)
 static int dra7xx_pcie_resume_noirq(struct device *dev)
 {
struct dra7xx_pcie *dra7xx = dev_get_drvdata(dev);
-   int phy_count = dra7xx->phy_count;
+   int phy_count = dra7xx->lanes;
int ret;
int i;
 
-- 
1.7.9.5

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

[RFC PATCH 2/2] pci: host: pci-dra7xx: Enable x2 mode support

2015-09-28 Thread Kishon Vijay Abraham I 
Perform syscon configurations to get x2 mode to working in DRA74x and
DRA72x. Also add a new compatible string to dfferentiate
DRA72x and DRA74x, since b1c0 mask is different for both these platforms.

Signed-off-by: Kishon Vijay Abraham I 
---
 Documentation/devicetree/bindings/pci/ti-pci.txt |7 +-
 drivers/pci/host/pci-dra7xx.c|   81 +-
 2 files changed, 86 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/ti-pci.txt 
b/Documentation/devicetree/bindings/pci/ti-pci.txt
index 60e2516..1ae1705 100644
--- a/Documentation/devicetree/bindings/pci/ti-pci.txt
+++ b/Documentation/devicetree/bindings/pci/ti-pci.txt
@@ -1,7 +1,8 @@
 TI PCI Controllers
 
 PCIe Designware Controller
- - compatible: Should be "ti,dra7-pcie""
+ - compatible: Should be "ti,dra7-pcie" for DRA74x
+  Should be "ti,dra72-pcie" for DRA72x
  - reg : Two register ranges as listed in the reg-names property
  - reg-names : The first entry must be "ti-conf" for the TI specific registers
   The second entry must be "rc-dbics" for the designware pcie
@@ -14,6 +15,10 @@ PCIe Designware Controller
   where  is the instance number of the pcie from the HW spec.
  - interrupts : Two interrupt entries must be specified. The first one is for
main interrupt line and the second for MSI interrupt line.
+ - syscon-lane-conf : phandle/offset pair. Phandle to the system control 
module and the
+   register offset to specify 1 lane or 2 lane.
+ - syscon-lane-sel : phandle/offset pair. Phandle to the system control module 
and the
+   register offset to specify lane selection.
  - #address-cells,
#size-cells,
#interrupt-cells,
diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
index e15b2e2..fb23a58 100644
--- a/drivers/pci/host/pci-dra7xx.c
+++ b/drivers/pci/host/pci-dra7xx.c
@@ -22,8 +22,11 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
+#include 
 
 #include "pcie-designware.h"
 
@@ -63,14 +66,22 @@
 #definePCIECTRL_DRA7XX_CONF_PHY_CS 0x010C
 #defineLINK_UP BIT(16)
 
+#define PCIE_1LANE_2LANE_SELECTION BIT(13)
+#define PCIE_B1C0_MODE_SEL BIT(2)
+
 struct dra7xx_pcie {
void __iomem*base;
+   u32 *b1c0_mask;
struct phy  **phy;
int lanes;
struct device   *dev;
struct pcie_portpp;
 };
 
+struct dra7xx_pcie_data {
+   u32 b1co_mode_sel_mask;
+};
+
 #define to_dra7xx_pcie(x)  container_of((x), struct dra7xx_pcie, pp)
 
 static inline u32 dra7xx_pcie_readl(struct dra7xx_pcie *pcie, u32 offset)
@@ -322,6 +333,57 @@ static int __init dra7xx_add_pcie_port(struct dra7xx_pcie 
*dra7xx,
return 0;
 }
 
+static const struct of_device_id of_dra7xx_pcie_match[];
+
+static int dra7xx_pcie_configure_two_lane(struct device *dev)
+{
+   struct device_node *np = dev->of_node;
+   struct regmap *pcie_syscon;
+   unsigned int pcie_reg;
+   struct dra7xx_pcie_data *data;
+   const struct of_device_id *match;
+
+   match = of_match_device(of_dra7xx_pcie_match, dev);
+   if (!match)
+   return -EINVAL;
+
+   data = (struct dra7xx_pcie_data *)match->data;
+   if (!data) {
+   dev_err(dev, "no b1c0 mask data\n");
+   return -EINVAL;
+   }
+
+   pcie_syscon = syscon_regmap_lookup_by_phandle(np, "syscon-lane-conf");
+   if (IS_ERR(pcie_syscon)) {
+   dev_err(dev, "unable to get syscon-lane-conf\n");
+   return -EINVAL;
+   }
+
+   if (of_property_read_u32_index(np, "syscon-lane-conf", 1, _reg)) {
+   dev_err(dev, "couldn't get lane configuration reg offset\n");
+   return -EINVAL;
+   }
+
+   regmap_update_bits(pcie_syscon, pcie_reg, PCIE_1LANE_2LANE_SELECTION,
+  PCIE_1LANE_2LANE_SELECTION);
+
+   pcie_syscon = syscon_regmap_lookup_by_phandle(np, "syscon-lane-sel");
+   if (IS_ERR(pcie_syscon)) {
+   dev_err(dev, "unable to get syscon-lane-sel\n");
+   return -EINVAL;
+   }
+
+   if (of_property_read_u32_index(np, "syscon-lane-sel", 1, _reg)) {
+   dev_err(dev, "couldn't get lane selection reg offset\n");
+   return -EINVAL;
+   }
+
+   regmap_update_bits(pcie_syscon, pcie_reg, data->b1co_mode_sel_mask,
+  PCIE_B1C0_MODE_SEL);
+
+   return 0;
+}
+
 static int __init dra7xx_pcie_probe(struct platform_device *pdev)
 {
u32 reg;
@@ -386,6 +448,14 @@ static int __init dra7xx_pcie_probe(struct platform_device 
*pdev)
phy_exit(phy[i]);
goto err_phy;
}
+
+   if (i == 1) {
+

[RFC PATCH 0/2] DRA72/DRA74: Add 2 lane support

2015-09-28 Thread Kishon Vijay Abraham I 
Add driver modifications in pci-dra7xx to get x2 mode working in
DRA72 and DRA74. Certain modifications is needed in PHY driver also
which I'll send as a separate series.

Kishon Vijay Abraham I (2):
  pci: host: pci-dra7xx: use "num-lanes" property to find phy count
  pci: host: pci-dra7xx: Enable x2 mode support

 Documentation/devicetree/bindings/pci/ti-pci.txt |7 +-
 drivers/pci/host/pci-dra7xx.c|  104 +++---
 2 files changed, 97 insertions(+), 14 deletions(-)

-- 
1.7.9.5

--
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: timer: always define omap4_local_timer_init

2015-09-28 Thread Nishanth Menon 
On 09/28/2015 01:25 PM, Felipe Balbi wrote:
> omap4_local_timer_init() can be used by other
> platforms as is. At least AM437x wants to use
> it. Instead of making omap4-only and providing
> a stub for builds without OMAP4, we can just
> always define that function.
> 
> Reported-by: Nishanth Menon 
> Signed-off-by: Felipe Balbi 
> ---
>  arch/arm/mach-omap2/timer.c | 9 -
>  1 file changed, 9 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
> index a55655127ef2..f9028582e962 100644
> --- a/arch/arm/mach-omap2/timer.c
> +++ b/arch/arm/mach-omap2/timer.c
> @@ -642,20 +642,11 @@ static OMAP_SYS_32K_TIMER_INIT(4, 1, "timer_32k_ck", 
> "ti,timer-alwon",
>  2, "sys_clkin_ck", NULL);
>  #endif
>  
> -#ifdef CONFIG_ARCH_OMAP4
> -#ifdef CONFIG_HAVE_ARM_TWD
>  void __init omap4_local_timer_init(void)
>  {
>   omap4_sync32k_timer_init();
>   clocksource_of_init();
>  }
> -#else
> -void __init omap4_local_timer_init(void)
> -{
> - omap4_sync32k_timer_init();
> -}
> -#endif /* CONFIG_HAVE_ARM_TWD */
> -#endif /* CONFIG_ARCH_OMAP4 */
>  
>  #if defined(CONFIG_SOC_OMAP5) || defined(CONFIG_SOC_DRA7XX)
>  void __init omap5_realtime_timer_init(void)
> 
I am a little confused if this will build in a am437xx only build.

#define OMAP_SYS_32K_TIMER_INIT(name, clkev_nr, clkev_src, clkev_prop, \
clksrc_nr, clksrc_src, clksrc_prop) \
void __init omap##name##_sync32k_timer_init(void) \

Would you like to consider this for OMAP4 only build as well?

#if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5) || \

defined(CONFIG_SOC_DRA7XX)
static OMAP_SYS_32K_TIMER_INIT(4, 1, "timer_32k_ck", "ti,timer-alwon",
   2, "sys_clkin_ck", NULL);
#endif


-- 
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 v3 1/2] Trace: PM: promote event 'power_domain_target' to generic power domains.

2015-09-28 Thread kbuild test robot 
Hi Marc,

[auto build test results on v4.3-rc3 -- if it's inappropriate base, please 
ignore]

config: i386-allmodconfig (attached as .config)
reproduce:
  git checkout cc6f7469844987395d46013269b2d2f4e1ad735c
  # save the attached .config to linux build tree
  make ARCH=i386 

All error/warnings (new ones prefixed by >>):

   drivers/base/power/domain.c: In function '__pm_genpd_poweron':
>> drivers/base/power/domain.c:274:46: error: 'struct generic_pm_domain' has no 
>> member named 'state_idx'
 trace_power_domain_target(genpd->name, genpd->state_idx,
 ^
>> drivers/base/power/domain.c:275:10: error: 'struct generic_pm_domain' has no 
>> member named 'states'
genpd->states[genpd->state_idx].name);
 ^
   drivers/base/power/domain.c:275:24: error: 'struct generic_pm_domain' has no 
member named 'state_idx'
genpd->states[genpd->state_idx].name);
   ^

vim +274 drivers/base/power/domain.c

   268  if (ret)
   269  goto err;
   270  
   271   out:
   272  genpd->status = GPD_STATE_ACTIVE;
   273  
 > 274  trace_power_domain_target(genpd->name, genpd->state_idx,
 > 275  genpd->states[genpd->state_idx].name);
   276  return 0;
   277  
   278   err:

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data