Re: [PATCH 1/2] ARM: dts: omap4: Add elm node

[Tony Lindgren]

* Franklin S Cooper Jr  [151028 14:02]:
> Add device tree entry for the error location module.
> 
> Signed-off-by: Franklin S Cooper Jr 

Applying this one into omap-for-v4.5/dt thanks.

Tony


>  arch/arm/boot/dts/omap4.dtsi | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
> index 5a206c1..a40eb23 100644
> --- a/arch/arm/boot/dts/omap4.dtsi
> +++ b/arch/arm/boot/dts/omap4.dtsi
> @@ -348,6 +348,14 @@
>   #interrupt-cells = <2>;
>   };
>  
> + elm: elm@48078000 {
> + compatible = "ti,am3352-elm";
> + reg = <0x48078000 0x2000>;
> + interrupts = <4>;
> + ti,hwmods = "elm";
> + status = "disabled";
> + };
> +
>   gpmc: gpmc@5000 {
>   compatible = "ti,omap4430-gpmc";
>   reg = <0x5000 0x1000>;
> -- 
> 2.6.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 v4 4/5] ARM: dts: DRA7: add entry for qspi mmap region

[Tony Lindgren]

* Vignesh R  [151129 21:16]:
> Add qspi memory mapped region entries for DRA7xx based SoCs. Also,
> update the binding documents for the controller to document this change.
> 
> Acked-by: Rob Herring 
> Signed-off-by: Vignesh R 
> ---
> 
> v4: No changes.

OK I'll apply patches 4 and 5 of this series into omap-for-v4.5/dt thanks.
The rest should get merged via the MTD tree.

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

Re: [PATCH 02/18] ARM: am57xx: cl-som-am57x: dts: add RTC support

[Tony Lindgren]

* Dmitry Lifshitz  [151124 22:41]:
> + {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins_default>;
> + clock-frequency = <10>;
> +
> + rtc0: rtc@56 {
> + compatible = "emmicro,em3027";
> + reg = <0x56>;
> + };
> +};
> +
> +

Please check this series too to remove the extra lines at the end of the files
for each patch for the whitespace errors and unify the Subject to start
with "ARM: dts: ..." thanks.

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

Re: [PATCH] ARM: dts: dra72-evm: Mark uart1 rxd as wakeup capable

[Tony Lindgren]

* Nishanth Menon  [151126 21:03]:
> On 11/26/2015 02:31 AM, Vignesh R wrote:
> > Uart1 rxd  is wakeup capable on DRA72 EVM. Hence, mark rxd line as
> > wakeup capable. This is similar to commit 66b0436977e2c ("ARM: dts:
> > dra7-evm: Mark uart1 rxd as wakeup capable") for DRA74 EVM.
> > 
> > Signed-off-by: Vignesh R 
> > ---
> >  arch/arm/boot/dts/dra72-evm.dts | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/dra72-evm.dts 
> > b/arch/arm/boot/dts/dra72-evm.dts
> > index d6104d5f0c01..8bf36b0b3c33 100644
> > --- a/arch/arm/boot/dts/dra72-evm.dts
> > +++ b/arch/arm/boot/dts/dra72-evm.dts
> > @@ -478,6 +478,8 @@
> >  
> >   {
> > status = "okay";
> > +   interrupts-extended = <_mpu GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>,
> > + <_pmx_core 0x3e0>;
> >  };
> >  
> >   {
> > 
> 
> Acked-by: Nishanth Menon 

Applying into omap-for-v4.5/dt thanks.

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

Re: [PATCH] ARM: OMAP: RX-51: fix a typo in log writing

[Tony Lindgren]

* Aaro Koskinen  [151123 13:33]:
> Fix a typo when registering HW RNG.

Applying into omap-for-v4.5/soc thanks.

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

Re: [PATCH 2/2] ARM: omap4: hwmod: Remove elm address space from hwmod data

[Tony Lindgren]

* Franklin S Cooper Jr  [151028 14:02]:
> ELM address information is provided by device tree. No longer need
> to include this information within hwmod.
> 
> This patch has only been boot tested.
> 
> Signed-off-by: Franklin S Cooper Jr 

And this one seems safe for me to apply into omap-for-v4.5/soc thanks.

Tony

> ---
>  arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 10 --
>  1 file changed, 10 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c 
> b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> index 43eebf2..8f13f4a 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> @@ -3915,21 +3915,11 @@ static struct omap_hwmod_ocp_if 
> omap44xx_l4_per__dss_venc = {
>   .user   = OCP_USER_MPU,
>  };
>  
> -static struct omap_hwmod_addr_space omap44xx_elm_addrs[] = {
> - {
> - .pa_start   = 0x48078000,
> - .pa_end = 0x48078fff,
> - .flags  = ADDR_TYPE_RT
> - },
> - { }
> -};
> -
>  /* l4_per -> elm */
>  static struct omap_hwmod_ocp_if omap44xx_l4_per__elm = {
>   .master = _l4_per_hwmod,
>   .slave  = _elm_hwmod,
>   .clk= "l4_div_ck",
> - .addr   = omap44xx_elm_addrs,
>   .user   = OCP_USER_MPU | OCP_USER_SDMA,
>  };
>  
> -- 
> 2.6.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 0/2] adding spi alias for qspi

[Tony Lindgren]

* Mugunthan V N  [151118 23:02]:
> Adding missed spi alias for qspi which helps probe the qspi
> device in U-Boot.
> 
> Mugunthan V N (2):
>   dts: dra7: add spi alias for qspi
>   arm: dts: am4372: add spi alias for qspi
> 
>  arch/arm/boot/dts/am4372.dtsi | 1 +
>  arch/arm/boot/dts/dra7.dtsi   | 1 +
>  2 files changed, 2 insertions(+)

Applying both into omap-for-v4.5/dt thanks.

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

Re: [PATCH v2] regulator: tps65217: remove tps65217.dtsi file

[Tony Lindgren]

* Rob Herring  [151112 06:02]:
> On Tue, Oct 27, 2015 at 01:36:36PM +0100, Heiko Schocher wrote:
> > remove tps65217.dtsi and adapt all boards, which
> > used it.
> > 
> > Signed-off-by: Heiko Schocher 
> > Tested-by: Keerthy 
> > Acked-by: Mark Brown 
> 
> Acked-by: Rob Herring 

Applying into omap-for-v4.5/dt thanks.

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

Re: [PATCH v2] arm, am335x: add support for the bosch shc board

[Tony Lindgren]

* Heiko Schocher  [151117 00:25]:
> --- /dev/null
> +++ b/arch/arm/boot/dts/am335x-shc.dts
> + {
> + compatible = "ti,tps65217";
> + ti,pmic-shutdown-controller;
> +
> + regulators {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + dcdc1_reg: regulator@0 {
> + reg = <0>;
> + regulator-name = "vdds_dpr";
> + regulator-compatible = "dcdc1";
> + regulator-min-microvolt = <130>;
> + regulator-max-microvolt = <145>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + dcdc2_reg: regulator@1 {
> + reg = <1>;
> + /*
> +  * VDD_MPU voltage limits 0.95V - 1.26V with
> +  * +/-4% tolerance
> +  */
> + regulator-compatible = "dcdc2";
> + regulator-name = "vdd_mpu";
> + regulator-min-microvolt = <925000>;
> + regulator-max-microvolt = <1375000>;
> + regulator-boot-on;
> + regulator-always-on;
> + regulator-ramp-delay = <7>;
> + };
> +
> + dcdc3_reg: regulator@2 {
> + reg = <2>;
> + /*
> +  * VDD_CORE voltage limits 0.95V - 1.1V with
> +  * +/-4% tolerance
> +  */
> + regulator-name = "vdd_core";
> + regulator-compatible = "dcdc3";
> + regulator-min-microvolt = <925000>;
> + regulator-max-microvolt = <1125000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + ldo1_reg: regulator@3 {
> + reg = <3>;
> + regulator-name = "vio,vrtc,vdds";
> + regulator-compatible = "ldo1";
> + regulator-min-microvolt = <100>;
> + regulator-max-microvolt = <180>;
> + regulator-always-on;
> + };
> +
> + ldo2_reg: regulator@4 {
> + reg = <4>;
> + regulator-name = "vdd_3v3aux";
> + regulator-compatible = "ldo2";
> + regulator-min-microvolt = <90>;
> + regulator-max-microvolt = <330>;
> + regulator-always-on;
> + };
> +
> + ldo3_reg: regulator@5 {
> + reg = <5>;
> + regulator-name = "vdd_1v8";
> + regulator-compatible = "ldo3";
> + regulator-min-microvolt = <90>;
> + regulator-max-microvolt = <180>;
> + regulator-always-on;
> + };
> +
> + ldo4_reg: regulator@6 {
> + reg = <6>;
> + regulator-name = "vdd_3v3a";
> + regulator-compatible = "ldo4";
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <330>;
> + regulator-always-on;
> + };
> + };
> +};

Applying this into omap-for-v4.5/dt.. But I'm getting concerned about this
"regulator-always-on" stuff and having multiple copies of the same thing.

I think we should have a common am33xx-tps65217.dtsi file that has the
regulators defined at one place and other then include it. And they are
controllable AFAIK..

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

Re: [PATCH 01/14] ARM: am437x: cm-t43: dts: add basic support for sbc-t43

[Tony Lindgren]

* Nikita Kiryanov  [151124 05:20]:
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins_default>;
> +};
> +

Please get rid of the extra line at the end of the file.. It will cause
whitespace warnings when applying and will also cause issues applying
other changes at the end of the file if they rely on the extra line.
And check the whole series, thanks :) It will make my life a bit easier.

And the Subject line should start with "ARM: dts: ..." for the unified
look.

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

Re: [PATCH v2 01/18] ARM: am57xx: cl-som-am57x: dts: add basic module support

[Tony Lindgren]

* Dmitry Lifshitz  [151130 06:27]:
> +++ b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
> + tps659038_pmic {
> + compatible = "ti,tps659038-pmic";
> +
> + regulators {
> + smps12_reg: smps12 {
> + /* VDD_MPU */
> + regulator-name = "smps12";
> + regulator-min-microvolt = < 85>;
> + regulator-max-microvolt = <125>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + smps3_reg: smps3 {
> + /* VDD_DDR */
> + regulator-name = "smps3";
> + regulator-min-microvolt = <150>;
> + regulator-max-microvolt = <150>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + smps45_reg: smps45 {
> + /* VDD_DSPEVE */
> + regulator-name = "smps45";
> + regulator-min-microvolt = < 85>;
> + regulator-max-microvolt = <125>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + smps6_reg: smps6 {
> + /* VDD_GPU */
> + regulator-name = "smps6";
> + regulator-min-microvolt = < 85>;
> + regulator-max-microvolt = <125>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + smps7_reg: smps7 {
> + /* VDD_CORE */
> + regulator-name = "smps7";
> + regulator-min-microvolt = < 85>;
> + regulator-max-microvolt = <116>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + smps8_reg: smps8 {
> + /* VDD_IVA */
> + regulator-name = "smps8";
> + regulator-min-microvolt = < 85>;
> + regulator-max-microvolt = <125>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + smps9_reg: smps9 {
> + /* PMIC_3V3 */
> + regulator-name = "smps9";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> +
> + ldo1_reg: ldo1 {
> + /* VDD_SD / VDDSHV8  */
> + regulator-name = "ldo1";
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <330>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + ldo2_reg: ldo2 {
> + /* VDD_1V8 */
> + regulator-name = "ldo2";
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <180>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + ldo3_reg: ldo3 {
> + /* VDDA_1V8_PHYA - supplies VDDA_SATA, 
> VDDA_USB1/2/3 */
> + regulator-name = "ldo3";
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <180>;
> +

Re: [PATCH V2] ARM: DRA7: hwmod: Enable DEBUG_LL for UART4

[Tony Lindgren]

* Nishanth Menon  [151022 19:49]:
> On 10/22/2015 08:01 PM, Praneeth wrote:
> > Hi Nishanth,
> > 
> > On 10/22/2015 07:24 PM, Praneeth Bajjuri wrote:
> >> From: "J.D. Schroeder" 
> >>
> >> UART4 low level debug support. This helps in debugging with UART4
> >> serial console output on DRA7 based platforms.
> >>
> >> Extending the following fix for UART4.
> >> commit 1c7e36bfc3e2 ("ARM: DRA7: hwmod: Fix boot crash with DEBUG_LL
> >> enabled on UART3")
> >>
> >> For using DEBUG_LL, enable CONFIG_DEBUG_OMAP4UART4 in menuconfig.
> >> On DRA7, UART4 hwmod doesn't have this flag enabled,
> >> failure observed when UART4 is used for low level debugging.
> >>
> >> Hence, Enable DEBUG_OMAP4UART4_FLAGS for UART4 hwmod.
> > Replying to your question from V1
> > 
> > we have DRA7 based platforms with UART1/UART3/UART4 for serial console.
> > 
> > 1,3 seems to be already fixed in mainline. Hence sending fix only for 4
> 
> Tony or others can comment. IMHO, 1c7e36bfc3e2 is an excellent example.
> it considered just UART3 as the missing thing. UART1 was already done.
> now, we have UART4, tomorrow, some other board will have UART2, how many
> patch on top of patch do we want to do for the same problem?
> 
> Phytech
> http://phytec.com/site/assets/files/2109/phytec_am57x-som_pb_release.pdf
> is a SOM module (page 2 - UART5,3 go to expansion connector).
> 
> And then you have
> http://www.compulab.co.il/products/computer-on-modules/cl-som-am57x-ti-am5728-am5718-system-on-module/#diagram
> 
> When we see issues like these that are probably symptoms, we might as
> well try and do as wide a solution as necessary.
> 
> if we stick with the rule that we will only enable DEBUG_LL only for
> those boards that are actually in upstream, then obviously, this patch
> should be dropped.
> 
> I do think, personally, that by introducing changes such as enabling
> DEBUG_LL for all ports, we are making the "evil vendor tree" less
> different from upstream and hence reduce cost of upstreaming - hopefully
> this might help motivate various product folks to actually provide
> upstream support for their products (N900 is still my favourite phone
> which actually works in upstream kernel- thanks to a lot of passionate
> community folks) - we really want to see more of those actual products
> function and be maintained with upstream kernel.

Yeah it's not a nice setup right now.. But I'll apply this anyways as
we're still very much depending on the DEBUG_LL for board bring up.

We should just move to moving CONFIG_SERIAL_EARLYCON with earlycon on
the cmdline or stdout-path = "serial3:115200n8" in the dts chosen.

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

[PATCH 1/2] ARM: OMAP2+: Initialize timers later with late_time_init

[Tony Lindgren]

We don't need timers right away and initializing them later gives us few
nice things like interrupts and kmalloc. As the timers have a dependency
to the clock framework, we're better off initializing things later rather
than early if things go wrong. And this allows us to make the mux clock
driver needed for system timers into early_platform drivers.

Note that smp_prepare_cpus() will get called later on during the init so
we just need to local_irq_enable/disable for clocksource_probe().

Cc: Felipe Balbi 
Cc: Grygorii Strashko 
Cc: Paul Walmsley 
Cc: Tero Kristo 
Signed-off-by: Tony Lindgren 
---
 arch/arm/mach-omap2/timer.c | 46 +++--
 1 file changed, 40 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index b18ebbe..68bf482 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -478,36 +478,56 @@ static void __init __omap_sync32k_timer_init(int 
clkev_nr, const char *clkev_src
omap2_gp_clockevent_init(clkev_nr, clkev_src, clkev_prop);
 
/* Enable the use of clocksource="gp_timer" kernel parameter */
+   local_irq_disable();
if (use_gptimer_clksrc || gptimer)
omap2_gptimer_clocksource_init(clksrc_nr, clksrc_src,
clksrc_prop);
else
omap2_sync32k_clocksource_init();
+   local_irq_enable();
 }
 
-void __init omap_init_time(void)
+static void __init omap_init_time_late(void)
 {
__omap_sync32k_timer_init(1, "timer_32k_ck", "ti,timer-alwon",
2, "timer_sys_ck", NULL, false);
 
-   if (of_have_populated_dt())
+   if (of_have_populated_dt()) {
+   local_irq_disable();
clocksource_probe();
+   local_irq_enable();
+   }
+}
+
+void __init omap_init_time(void)
+{
+   late_time_init = omap_init_time_late;
 }
 
 #if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM43XX)
-void __init omap3_secure_sync32k_timer_init(void)
+static void __init omap3_secure_sync32k_timer_late_init(void)
 {
__omap_sync32k_timer_init(12, "secure_32k_fck", "ti,timer-secure",
2, "timer_sys_ck", NULL, false);
 }
+
+void __init omap3_secure_sync32k_timer_init(void)
+{
+   late_time_init = omap3_secure_sync32k_timer_late_init;
+}
 #endif /* CONFIG_ARCH_OMAP3 */
 
 #if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM33XX)
-void __init omap3_gptimer_timer_init(void)
+static void __init omap3_gptimer_late_init(void)
 {
__omap_sync32k_timer_init(2, "timer_sys_ck", NULL,
1, "timer_sys_ck", "ti,timer-alwon", true);
 }
+
+void __init omap3_gptimer_timer_init(void)
+{
+   late_time_init = omap3_gptimer_late_init;
+}
 #endif
 
 #if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5) || \
@@ -518,10 +538,17 @@ static void __init omap4_sync32k_timer_init(void)
2, "sys_clkin_ck", NULL, false);
 }
 
-void __init omap4_local_timer_init(void)
+static void __init omap4_local_timer_late_init(void)
 {
omap4_sync32k_timer_init();
+   local_irq_disable();
clocksource_probe();
+   local_irq_enable();
+}
+
+void __init omap4_local_timer_init(void)
+{
+   late_time_init = omap4_local_timer_late_init;
 }
 #endif
 
@@ -640,12 +667,19 @@ sysclk1_based:
 #endif
 }
 
-void __init omap5_realtime_timer_init(void)
+static void __init omap5_realtime_timer_late_init(void)
 {
omap4_sync32k_timer_init();
realtime_counter_init();
 
+   local_irq_disable();
clocksource_probe();
+   local_irq_enable();
+}
+
+void __init omap5_realtime_timer_init(void)
+{
+   late_time_init = omap5_realtime_timer_late_init;
 }
 #endif /* CONFIG_SOC_OMAP5 || CONFIG_SOC_DRA7XX */
 
-- 
2.6.2

--
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+: Change core_initcall levels to postcore_initcall

[Tony Lindgren]

We want to be able to probe a few selected device drivers before hwmod
code populates the clocks in omap_hwmod_setup_all(). This allows us to
convert most of the clock drivers into regular device drivers.

We only need a few minimal clock drivers early for the system timers to
select between the 32KiHz clock and the high frequency oscillator.

With these changes, initializing the clock drivers can be just done at
core_initcall time with something like:

np = of_find_node_by_name(NULL, "plls");
if (np)
of_platform_populate(np, NULL, NULL, NULL);

And then these clocks will be available for the interconnect code to use.

Having most of the clock drivers being regular device drivers allows
us to use the nice things like devm_* functions and dev_err and dev_dbg.
As an extra bonus, this also allows us to develop the clock drivers for
new SoCs as loadable modules initially for cases where we can boot up
the system based on the bootloader configured clocks.

To do this, let's change the core_initcalls to postcore_initcall under
mach-omap2.

Cc: Felipe Balbi 
Cc: Grygorii Strashko 
Cc: Paul Walmsley 
Cc: Tero Kristo 
Signed-off-by: Tony Lindgren 
---
 arch/arm/mach-omap2/omap2-restart.c | 2 +-
 arch/arm/mach-omap2/omap_device.c   | 2 +-
 arch/arm/mach-omap2/omap_hwmod.c| 2 +-
 arch/arm/mach-omap2/serial.c| 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/omap2-restart.c 
b/arch/arm/mach-omap2/omap2-restart.c
index d937b2e..497269d 100644
--- a/arch/arm/mach-omap2/omap2-restart.c
+++ b/arch/arm/mach-omap2/omap2-restart.c
@@ -62,4 +62,4 @@ static int __init omap2xxx_common_look_up_clks_for_reset(void)
 
return 0;
 }
-omap_core_initcall(omap2xxx_common_look_up_clks_for_reset);
+omap_postcore_initcall(omap2xxx_common_look_up_clks_for_reset);
diff --git a/arch/arm/mach-omap2/omap_device.c 
b/arch/arm/mach-omap2/omap_device.c
index 72ebc4c..3750ed1 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -869,7 +869,7 @@ static int __init omap_device_init(void)
bus_register_notifier(_bus_type, _nb);
return 0;
 }
-omap_core_initcall(omap_device_init);
+omap_postcore_initcall(omap_device_init);
 
 /**
  * omap_device_late_idle - idle devices without drivers
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index cc8a987..49d5376 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -3307,7 +3307,7 @@ static int __init omap_hwmod_setup_all(void)
 
return 0;
 }
-omap_core_initcall(omap_hwmod_setup_all);
+omap_postcore_initcall(omap_hwmod_setup_all);
 
 /**
  * omap_hwmod_enable - enable an omap_hwmod
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 5fb50fe..f164c6b 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -213,7 +213,7 @@ static int __init omap_serial_early_init(void)
 
return 0;
 }
-omap_core_initcall(omap_serial_early_init);
+omap_postcore_initcall(omap_serial_early_init);
 
 /**
  * omap_serial_init_port() - initialize single serial port
-- 
2.6.2

--
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] Initcall changes for omaps

[Tony Lindgren]

Hi,

Here are some initcall changes to initialize things a bit later.
This make it easier to make timers into drivers and allows us
to make most of the clocks into regular device drivers.

Regards,

Tony


Tony Lindgren (2):
  ARM: OMAP2+: Initialize timers later with late_time_init
  ARM: OMAP2+: Change core_initcall levels to postcore_initcall

 arch/arm/mach-omap2/omap2-restart.c |  2 +-
 arch/arm/mach-omap2/omap_device.c   |  2 +-
 arch/arm/mach-omap2/omap_hwmod.c|  2 +-
 arch/arm/mach-omap2/serial.c|  2 +-
 arch/arm/mach-omap2/timer.c | 46 -
 5 files changed, 44 insertions(+), 10 deletions(-)

-- 
2.6.2

--
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: OMAP4: execute initcall to reserve SRAM for I688 only on OMAP4

[Lucas Stach]

Am Montag, den 16.11.2015, 14:24 +0200 schrieb Grygorii Strashko:
> On 11/16/2015 01:25 PM, Lucas Stach wrote:
> > omap_interconnect_sync() is the only user of the SRAM scratch area
> > allocated in the omap4_sram_init initcall. The interconnect sync is
> > used exclusively in the OMAP4 specific WFI implementation, so there
> > is no point in allocating the SRAM scratch on other SoC types.
> > 
> > Bail out of the initcall if the kernel is not running on OMAP4 to
> > avoid a confusing warning about being unable to allocate the SRAM
> > needed for I688 handling.
> > 
> > Signed-off-by: Lucas Stach 
> > Tested-by: Bastian Stender 
> > ---
> >   arch/arm/mach-omap2/omap4-common.c | 3 +++
> >   1 file changed, 3 insertions(+)
> > 
> > diff --git a/arch/arm/mach-omap2/omap4-common.c 
> > b/arch/arm/mach-omap2/omap4-common.c
> > index 949696b6f17b..6db393a30a28 100644
> > --- a/arch/arm/mach-omap2/omap4-common.c
> > +++ b/arch/arm/mach-omap2/omap4-common.c
> > @@ -131,6 +131,9 @@ static int __init omap4_sram_init(void)
> > struct device_node *np;
> > struct gen_pool *sram_pool;
> >   
> > +   if (!cpu_is_omap44xx())
> > +   return 0;
> 
> This one affects on am43xx also
> 
So you are saying this erratum is also present on AM43xx? I wasn't able
to deduce this from the information provided by Richard Woodruff.

> 
> > +
> > 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",
> 
> Since all OMAP4+ platforms are now DT based why can't we just return from 
> here silently?
> 
If we are unable to allocate the SRAM needed to work around I688 this is
a real error on platforms that expose this erratum, so silently bailing
out at this point may obscure a real issue.

Regards,
Lucas

-- 
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

--
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/17] ARM: OMAP2+: PRM: add support for reset controller

[Tony Lindgren]

* Tony Lindgren  [151006 05:12]:
> * Tero Kristo  [150924 07:30]:
> > PRM driver now supports reset controller for the defined reset lines.
> > Reset configurations are provided through device tree. Later, functionality
> > like hwmod and system reboot will be changed to use the generic framework.
> 
> This approach seems good to me in general. This should have the related
> reset driver documentation too for the binding though.

Also, with the initcall changes I just posted, it seems this can become
just a regular device driver that gets initialized at core_initcall level.

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

Re: [RFC PATCH] clocksource: ti-32k: convert to platform device

[Tony Lindgren]

* Grygorii Strashko  [151127 12:11]:
> Hi Felipe,
> 
> On 11/20/2015 08:21 PM, Felipe Balbi wrote:
> > Grygorii Strashko  writes:
> >> Since system clocksource is finally selected by Clocksource core at
> >> fs_initcall stage during boot there are no reasons to initialize
> >> ti_32k_timer at early boot stages. Hence, ti_32k_timer can be
> >> converted to use platform device/driver model and its PM can be
> >> implemented using PM runtime which is common for OMAP devices.
> >>
> >> Platform specific initialization code has to be disabled once as
> >> ti_32k_timer is converted to platform device - otherwise OMAP platform
> >> code will generate boot warnings.
> >>
> >> After this change, all counter_32k's platform code can be removed
> >> once all OMAP boards will be converted to DT.
> >>
> >> Cc: Tony Lindgren 
> >> Cc: Felipe Balbi 
> >> Signed-off-by: Grygorii Strashko 
> >> ---
> 
> [...]
> 
> >> +
> >> +static struct platform_driver ti_32k_driver __initdata = {
> >> +  .probe  = ti_32k_probe,
> >> +  .driver = {
> >> +  .name   = "ti_32k_timer",
> >> +  .of_match_table = of_match_ptr(ti_32k_of_table),
> >> +  }
> >> +};
> >> +
> >> +static int __init ti_32k_init(void)
> >> +{
> >> +  return platform_driver_register(_32k_driver);
> >>   }
> >> -CLOCKSOURCE_OF_DECLARE(ti_32k_timer, "ti,omap-counter32k",
> >> -  ti_32k_timer_init);
> >> +
> >> +subsys_initcall(ti_32k_init);
> >> +
> >> +MODULE_AUTHOR("Paul Mundt");
> >> +MODULE_AUTHOR("Juha Yrjölä");
> >> +MODULE_DESCRIPTION("OMAP2 32k Timer");
> >> +MODULE_ALIAS("platform:ti_32k_timer");
> >> +MODULE_LICENSE("GPL v2");
> > 
> > this will break clksource_of_init(), right ? Eventually, we want that to
> > be the only thing called by our .init_time method. I'll leave it to Tony
> > to decide, but IMO this is not a good path forward for timers.
> > 
> 
> Yeh :(.  I did additional tests, and, unfortunately, this can't be used as is.
> But not because of clocksource_of_init() which will just produce boot warning.
> It can't be done because of sched_clock_register() which is expected to be
> called during early boot time only and with disabled IRQs.
> 
> It was so tempting to try :)

We should be able to make this into an early_platform_device and just
have it depend on the source clock muxes. See the omap initcall changes
patches I just posted.

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

Re: [PATCH v2] arm, am335x: add support for the bosch shc board

[Tony Lindgren]

* Heiko Schocher  [151129 22:51]:
> Hello all,
> 
> Am 18.11.2015 um 09:24 schrieb Heiko Schocher:
> >Hello Dave,
> >
> >Am 17.11.2015 um 22:29 schrieb Dave Gerlach:
> >>Hi,
> >>On 11/17/2015 02:24 AM, Heiko Schocher wrote:
> >>>add support for the am335x based shc board.
> >>>
> >>>UART: 0-2 and 4
> >>>DRAM: 512 MiB
> >>>MMC:  OMAP SD/MMC: 0 @ 26 MHz
> >>>   OMAP SD/MMC: 1 @ 26 MHz
> >>>I2C:  at24 eeprom, pcf8563
> >>>USB:  USB1 (host)
> >>>
> >>>Signed-off-by: Heiko Schocher 
> >>>---
> >>>The following patches are needed to get all working
> >>>for the shc board:
> >>>- disable clkout on pcf8563
> >>>   accepted.
> >>>   http://www.spinics.net/lists/devicetree/msg98542.html
> >>>
> >>>- leds: leds-gpio: add shutdown function
> >>>   accepted.
> >>>   https://lkml.org/lkml/2015/10/13/169
> >>>
> >>>- net: phy: smsc: disable energy detect mode
> >>>   accepted
> >>>   [PATCH v2 2/2] net: phy: smsc: disable energy detect mode
> >>>   https://lkml.org/lkml/2015/10/17/2
> >>>   [PATCH v2 1/2] drivers: net: cpsw: add phy-handle parsing
> >>>   https://lkml.org/lkml/2015/10/17/4
> >>>
> >>>- ARM: OMAP2+: omap_hwmod: Introduce ti,no-init dt property
> >>>   
> >>> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/328204.html
> >>>   @Dave: What is the current state of this patch?
> >>>   I have the same problem here on this am335x based board
> >>>
> >>
> >>A different approach is being taken for resolving the issue of rtc hwmod on 
> >>am43x epos evm [1],
> >>which is what I was attempting to solve with the patch you have linked. We 
> >>decided to avoid changing
> >>omap_hwmod code and I haven't been pursuing the ti,no-init flag anymore.
> >
> >Maybe I overlook something, but I cannot see, how [1] solves the RTC
> >hwmod problem on am335x SoC based boards. Not all boards have this problem,
> >so the RTC hwmod cannot be disabled for all am335x boards ...
> >
> >It must be somehow configurable for boards ... I have am335x boards
> >which use the rtc from the SoC
> 
> gentle ping ...
> 
> No more comments on this patch? Is it Ok for mainline or are
> there more issues?

Looks OK to me, hoping to start applying the dts changes for v4.5 this
week.

Tony

> >>[1] http://www.spinics.net/lists/linux-omap/msg121987.html
--
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/39] pinctrl: Move am4372 and dra7 macros to the the SoC header files

[Tony Lindgren]

* Tony Lindgren  [151125 10:40]:
> Linus,
> 
> * Tony Lindgren  [151118 16:25]:
> > * Javier Martinez Canillas  [151117 05:51]:
> > > Hello Linus,
> > > 
> > > On 11/17/2015 10:47 AM, Linus Walleij wrote:
> > > > On Fri, Nov 13, 2015 at 5:53 AM, Javier Martinez Canillas
> > > >  wrote:
> > > > 
> > > >> The  header file defines a set of macros
> > > >> for different SoCs families that falls under the OMAP sub-arch, that
> > > >> allow to define the padconf register physical address instead of the
> > > >> register offset from the padconf base.
> > > >>
> > > >> But the am43xx and dra7xx SoCs families have their own pinctrl header
> > > >> file so the DTS using these SoCs aren't able to use the AM4372_IOPAD()
> > > >> and DRA7XX_CORE_IOPAD() macros since  is
> > > >> not included.
> > > >>
> > > >> Move the macros to the correct header files so can be used by the DTS.
> > > >>
> > > >> Signed-off-by: Javier Martinez Canillas 
> > > > 
> > > > I need Tony's ACK on this.
> > > >
> > > 
> > > OK, I believe he was waiting for yours to pick the series though ;)
> > 
> > Yeah probably best to keep this series together if you're OK with that.
> 
> Care to ack this one? I'd like to apply this series for v4.5 within next
> few days..

Applying this series today into omap-for-v4.5/dt.

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

Re: [PATCH 00/39] ARM: dts: Convert OMAP boards to use IOPAD pinmux macros

[Tony Lindgren]

* Andrew F. Davis  [151116 08:39]:
> On 11/13/2015 08:47 AM, Tony Lindgren wrote:
> >* Javier Martinez Canillas  [151112 20:55]:
> >>Hello Tony,
> >>
> >>This series converts all the remaining OMAP boards that didn't use the
> >>IOPAD macros to specify the padconf register addresses. The only board
> >>that I left was arch/arm/boot/dts/am335x-boneblack.dts because Andrew
> >>already posted a patch for that DTS [0].
> >>
> >>I built tested all the DTBs that are build by omap2plus_defconfig and
> >>the md5 checksum was the same before and after the patches so there's
> >>no functional change and is only to make the DTS more readable.
> >
> >Yes great. Being able to compare the register against the documentation
> >helps quite a bit. I plan on applying this series before anything else
> >after -rc1 as it may require other patches to be rebased.
> >
> >>Patch #1 should be acked by the pinctrl maintainer and picked through
> >>the linux-omap tree to maintain bisectability.
> >>
> >>[0]: https://lkml.org/lkml/2015/10/24/114
> >
> 
> v3 of my little contribution also out when you pull:
> https://lkml.org/lkml/2015/11/13/480

Applying that one too into omap-for-v4.5/dt thanks.

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

Re: [PATCH v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Tony Lindgren]

* Roger Quadros  [151023 00:09]:
> On 21/10/15 18:20, Tony Lindgren wrote:
> > * Roger Quadros  [151021 01:31]:
> >>
> >> I couldn't run randconfig beyond few iterations as it keeps failing
> >> everywhere. How do we limit the randconfig options to OMAP only
> >> platforms?
> > 
> > You can use Felipe's scripts from github.
> 
> Thanks. I used his scripts and ran 10 randconfigs per platform.
> Didn't find any issues with this series.
> 
> How can we proceed?
> Patches are on https://github.com/rogerq/linux/commits/for-v4.4/gpmc-v4

Sorry for the delay on this one. I suggest you get this series into
linux next and then we can merge it for v4.5 via arm-soc as long as
the pending comments are addressed. As far as I'm concerned, feel free
to add for the whole series:

Acked-by: Tony Lindgren 

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

Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry

[Nicolas Pitre]

On Mon, 30 Nov 2015, Pali Rohár wrote:

> On Monday 30 November 2015 07:23:53 Tony Lindgren wrote:
> > * Pali Rohár  [151129 16:16]:
> > > On Monday 30 November 2015 01:09:17 Nicolas Pitre wrote:
> > > > On Sun, 29 Nov 2015, Russell King - ARM Linux wrote:
> > > > > On Sat, Nov 28, 2015 at 12:34:23PM -0500, Nicolas Pitre wrote:
> > > > > > Good. And Arnd likes the idea too. So we might be converging at
> > > > > > last which is a good thing.
> > > > > 
> > > > > I disagree with the idea that there is convergence.  There might be
> > > > > convergence towards an idea, but... Here's a mail extract, from
> > > > > July 7th, from earlier in this very thread:
> > > > > 
> > > > > Pali:
> > > > > > Me:
> > > > > > > Are the ATAGs at a fixed address on the N900?
> > > > > > 
> > > > > > Yes, in board-rx51.c is:
> > > > > > 
> > > > > > .atag_offset= 0x100
> > > > > > 
> > > > > > and Nokia Bootloader (proprietary) store them to that address.
> > > > > > 
> > > > > > > Can that be handled in
> > > > > > > some kind of legacy file for the N900 which calls save_atags()
> > > > > > > on it, so we don't end up introducing yet more stuff that we
> > > > > > > have to maintain into the distant future?  If not, what about
> > > > > > > copying a known working atag structure into a legacy file for
> > > > > > > the N900?
> > > > > > 
> > > > > > I already asked question if it is possible to read ATAGs from DT
> > > > > > booted kernel. And somebody (do not remember who) wrote to ML,
> > > > > > that it is not possible and it can be done in that uncompress
> > > > > > code.
> > > > 
> > > > Who is that somebody? If ever it happened to be me then objection is
> > > > withdrawn. Otherwise that somebody should come forth and speak up
> > > > again.
> > > > 
> > > 
> > > ... do not remember ... this discussion were in more email threads and 
> > > takes more then one year... sorry but my memory is not excellent
> > 
> > Yes this certainly seems like the best solution. I think we got into
> > the atags-to-dt track as some of the atags are already being translated.
> > 
> > In this case there's no need to translate them AFAIK. You can just
> > parse them and have them available for the user space. So as long as
> > nothing trashes the atags at the atag_offset, you should be able to
> > call a function to parse them in the n900 specific init_machine.
> > 
> > Regards,
> > 
> > Tony
> 
> In arch/arm/kernel/setup.c is function setup_arch() and it calls:
> 
>   mdesc = setup_machine_fdt(__atags_pointer);
>   if (!mdesc)
>   mdesc = setup_machine_tags(__atags_pointer, __machine_arch_type);
> 
> So it looks like that on atags address is stored either atags structure
> or DT structure... so it is truth kernel uncompress code put DT blob to
> same offset where is expected atags structure?

No.  It doesn't put it anywhere. Those functions read DT/ATAGs from the 
passed address.  But you know this address won't be the one you want for 
the legacy ATAGs.

What you should do is to add a init_early hook to your mdesc structure 
and retrieve your ATAGs from there directly at PAGE_OFFSET + 0x100.

Now I suspect paging_init() marks the point where the ATAGs will be 
overwritten.  To prevent this, you might have to add an additional tweak 
in arm_mm_memblock_reserve() similar to the one already present for 
CONFIG_SA. Something like:

memblock_reserve(PHYS_OFFSET, PAGE_SIZE);

And later on you can return that page back to the system.


Nicolas

Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry

[Tony Lindgren]

* Pali Rohár  [151129 16:16]:
> On Monday 30 November 2015 01:09:17 Nicolas Pitre wrote:
> > On Sun, 29 Nov 2015, Russell King - ARM Linux wrote:
> > > On Sat, Nov 28, 2015 at 12:34:23PM -0500, Nicolas Pitre wrote:
> > > > Good. And Arnd likes the idea too. So we might be converging at
> > > > last which is a good thing.
> > > 
> > > I disagree with the idea that there is convergence.  There might be
> > > convergence towards an idea, but... Here's a mail extract, from
> > > July 7th, from earlier in this very thread:
> > > 
> > > Pali:
> > > > Me:
> > > > > Are the ATAGs at a fixed address on the N900?
> > > > 
> > > > Yes, in board-rx51.c is:
> > > > 
> > > > .atag_offset= 0x100
> > > > 
> > > > and Nokia Bootloader (proprietary) store them to that address.
> > > > 
> > > > > Can that be handled in
> > > > > some kind of legacy file for the N900 which calls save_atags()
> > > > > on it, so we don't end up introducing yet more stuff that we
> > > > > have to maintain into the distant future?  If not, what about
> > > > > copying a known working atag structure into a legacy file for
> > > > > the N900?
> > > > 
> > > > I already asked question if it is possible to read ATAGs from DT
> > > > booted kernel. And somebody (do not remember who) wrote to ML,
> > > > that it is not possible and it can be done in that uncompress
> > > > code.
> > 
> > Who is that somebody? If ever it happened to be me then objection is
> > withdrawn. Otherwise that somebody should come forth and speak up
> > again.
> > 
> 
> ... do not remember ... this discussion were in more email threads and 
> takes more then one year... sorry but my memory is not excellent

Yes this certainly seems like the best solution. I think we got into
the atags-to-dt track as some of the atags are already being translated.

In this case there's no need to translate them AFAIK. You can just
parse them and have them available for the user space. So as long as
nothing trashes the atags at the atag_offset, you should be able to
call a function to parse them in the n900 specific init_machine.

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

Re: [PATCH 01/14] ARM: am437x: cm-t43: dts: add basic support for sbc-t43

[Nikita Kiryanov]

On Wed, Nov 25, 2015 at 05:03:00PM -0600, Rob Herring wrote:
> On Tue, Nov 24, 2015 at 03:19:02PM +0200, Nikita Kiryanov wrote:
> > Add basic support for SBC-T43: a CM-T43 based single board computer.
> > CM-T43 is an AM437x based System-on-Module designed to serve as a building
> > block in embedded applications. SBC-T43 is composed of CM-T43 module on
> > top of the SB-SOM-T43 baseboard.
> > Basic support includes UART, GPIO, and I2C.
> > 
> > Signed-off-by: Nikita Kiryanov 
> > Cc: Tony Lindgren 
> > Cc: Igor Grinberg 
> > Cc: Dmitry Lifshitz 
> > Cc: Ian Campbell 
> 
> Some minor nits below, otherwise:
> 
> Acked-by: Rob Herring 
>

V2 coming up.
--
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] clk: ti: omap5+: dpll: implement errata i810

[Tero Kristo]

Errata i810 states that DPLL controller can get stuck while transitioning
to a power saving state, while its M/N ratio is being re-programmed.

As a workaround, before re-programming the M/N ratio, SW has to ensure
the DPLL cannot start an idle state transition. SW can disable DPLL
idling by setting the DPLL AUTO_DPLL_MODE=0 or keeping a clock request
active by setting a dependent clock domain in SW_WKUP.

This errata impacts OMAP5 and DRA7 chips, so enable the errata for these.

Signed-off-by: Tero Kristo 
---
 arch/arm/mach-omap2/clock.c |4 
 drivers/clk/ti/dpll3xxx.c   |   25 -
 include/linux/clk/ti.h  |1 +
 3 files changed, 29 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index acb60ed..d058125 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -225,5 +225,9 @@ void __init ti_clk_init_features(void)
if (omap_rev() == OMAP3430_REV_ES1_0)
features.flags |= TI_CLK_DPLL4_DENY_REPROGRAM;
 
+   /* Errata I810 for omap5 / dra7 */
+   if (soc_is_omap54xx() || soc_is_dra7xx())
+   features.flags |= TI_CLK_ERRATA_I810;
+
ti_clk_setup_features();
 }
diff --git a/drivers/clk/ti/dpll3xxx.c b/drivers/clk/ti/dpll3xxx.c
index f4dec00..1c30038 100644
--- a/drivers/clk/ti/dpll3xxx.c
+++ b/drivers/clk/ti/dpll3xxx.c
@@ -305,8 +305,9 @@ static void _lookup_sddiv(struct clk_hw_omap *clk, u8 
*sd_div, u16 m, u8 n)
 static int omap3_noncore_dpll_program(struct clk_hw_omap *clk, u16 freqsel)
 {
struct dpll_data *dd = clk->dpll_data;
-   u8 dco, sd_div;
+   u8 dco, sd_div, ai = 0;
u32 v;
+   bool errata_i810;
 
/* 3430 ES2 TRM: 4.7.6.9 DPLL Programming Sequence */
_omap3_noncore_dpll_bypass(clk);
@@ -350,6 +351,25 @@ static int omap3_noncore_dpll_program(struct clk_hw_omap 
*clk, u16 freqsel)
v |= sd_div << __ffs(dd->sddiv_mask);
}
 
+   /*
+* Errata i810 - DPLL controller can get stuck while transitioning
+* to a power saving state. Software must ensure the DPLL can not
+* transition to a low power state while changing M/N values.
+* Easiest way to accomplish this is to prevent DPLL autoidle
+* before doing the M/N re-program.
+*/
+   errata_i810 = ti_clk_get_features()->flags & TI_CLK_ERRATA_I810;
+
+   if (errata_i810) {
+   ai = omap3_dpll_autoidle_read(clk);
+   if (ai) {
+   omap3_dpll_deny_idle(clk);
+
+   /* OCP barrier */
+   omap3_dpll_autoidle_read(clk);
+   }
+   }
+
ti_clk_ll_ops->clk_writel(v, dd->mult_div1_reg);
 
/* Set 4X multiplier and low-power mode */
@@ -379,6 +399,9 @@ static int omap3_noncore_dpll_program(struct clk_hw_omap 
*clk, u16 freqsel)
 
_omap3_noncore_dpll_lock(clk);
 
+   if (errata_i810 && ai)
+   omap3_dpll_allow_idle(clk);
+
return 0;
 }
 
diff --git a/include/linux/clk/ti.h b/include/linux/clk/ti.h
index 223be69..75205df 100644
--- a/include/linux/clk/ti.h
+++ b/include/linux/clk/ti.h
@@ -286,6 +286,7 @@ struct ti_clk_features {
 #define TI_CLK_DPLL_HAS_FREQSELBIT(0)
 #define TI_CLK_DPLL4_DENY_REPROGRAMBIT(1)
 #define TI_CLK_DISABLE_CLKDM_CONTROL   BIT(2)
+#define TI_CLK_ERRATA_I810 BIT(3)
 
 void ti_clk_setup_features(struct ti_clk_features *features);
 const struct ti_clk_features *ti_clk_get_features(void);
-- 
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 v2 0/3] dmaengine: ti-dma-crossbar: channel reserving and edma3-tpcc support

[Vinod Koul]

On Fri, Oct 30, 2015 at 10:00:35AM +0200, Peter Ujfalusi wrote:
> Hi,
> 
> Changes since v1:
> - Fixed issue introduced by the bitops patch: wrong error check, also switch 
> to
>   use find_first_zero_bit() instead of find_next_zero_bit()
> 
> Cover letter:
> 
> This series depends on the eDMA work I have done, which has been now applied:
> https://lkml.org/lkml/2015/10/16/64
> 
> DRA7 family of chips have both sDMA and eDMA. Currently only sDMA can be used
> becasue the old driver stack for eDMA did not allowed integration w/o hacks.
> 
> Due to the nature of eDMA the crossbar needs to know which eDMA events it can
> use to map incoming events towards the eDMA. In eDMA a channel is wired to be
> used with one specific event. For example eDMA event 14 can only be handled by
> eDMA channel 14.
> The eDMA itself can be shared by different processors in the system (ARM, DSP,
> etc) and since ARM/Linux is the master we need to know which channels are used
> by other cores. Also we need to mask out channels used for memcpy from the
> events we use for HW triggers.

Applied, thanks

-- 
~Vinod
--
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 12/14] ARM: sb-som: dts: introduce SB-SOM baseboard

[Nikita Kiryanov]

On Wed, Nov 25, 2015 at 04:57:34PM -0600, Rob Herring wrote:
> On Tue, Nov 24, 2015 at 03:19:13PM +0200, Nikita Kiryanov wrote:
> > CompuLab SB-SOM baseboard is a carrier board for multiple arm-based SoMs.
> > It currently supports (with minor adjustments to assembly) CM-T43, CM-T54,
> > and CM-QS600 modules. It is a building block in the SBC-T43 single board
> > computer, which consists of cm-t43 on top of sb-som-t43.
> > 
> > Signed-off-by: Nikita Kiryanov 
> > Cc: Tony Lindgren 
> > Cc: Igor Grinberg 
> > Cc: Dmitry Lifshitz 
> > Cc: Ian Campbell 
> > ---
> >  .../devicetree/bindings/arm/compulab-boards.txt|  5 +++
> >  .../bindings/display/panel/startek,startek-kd050c  |  4 +++
> 
> .txt please.

Right, will V2..

> 
> >  .../devicetree/bindings/vendor-prefixes.txt|  1 +
> >  arch/arm/boot/dts/compulab-sb-som.dtsi | 42 
> > ++
> >  4 files changed, 52 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/arm/compulab-boards.txt
> >  create mode 100644 
> > Documentation/devicetree/bindings/display/panel/startek,startek-kd050c
> >  create mode 100644 arch/arm/boot/dts/compulab-sb-som.dtsi
> > 
> > diff --git a/Documentation/devicetree/bindings/arm/compulab-boards.txt 
> > b/Documentation/devicetree/bindings/arm/compulab-boards.txt
> > new file mode 100644
> > index 000..3e742a5
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/arm/compulab-boards.txt
> > @@ -0,0 +1,5 @@
> > +CompuLab SB-SOM is a multi-module baseboard capable of carrying CM-T43, 
> > CM-T54,
> > +and QS-600 modules with minor modifications to the SB-SOM assembly.
> 
> All these modules have compatible strings?

Yes, although they are currently undocumented. QS-600 should be CM-QS600
though.. Will fix in V2.

> 
> > +
> > +Required root node properties:
> > +- compatible = should be "compulab,sb-som"
> > diff --git 
> > a/Documentation/devicetree/bindings/display/panel/startek,startek-kd050c 
> > b/Documentation/devicetree/bindings/display/panel/startek,startek-kd050c
> > new file mode 100644
> > index 000..70cd8d1
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/panel/startek,startek-kd050c
> > @@ -0,0 +1,4 @@
> > +Startek Electronic Technology Co. KD050C 5.0" WVGA TFT LCD panel
> > +
> > +Required properties:
> > +- compatible: should be "startek,startek-kd050c"
> > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
> > b/Documentation/devicetree/bindings/vendor-prefixes.txt
> > index 55df1d4..409b134 100644
> > --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> > +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> > @@ -218,6 +218,7 @@ sonySony Corporation
> >  spansion   Spansion Inc.
> >  sprd   Spreadtrum Communications Inc.
> >  st STMicroelectronics
> > +startekStartek
> >  steST-Ericsson
> >  stericsson ST-Ericsson
> >  synology   Synology, Inc.
> > diff --git a/arch/arm/boot/dts/compulab-sb-som.dtsi 
> > b/arch/arm/boot/dts/compulab-sb-som.dtsi
> > new file mode 100644
> > index 000..402a143
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/compulab-sb-som.dtsi
> > @@ -0,0 +1,42 @@
> > +/*
> > + * Copyright (C) 2015 CompuLab, Ltd. - http://www.compulab.co.il/
> > + *
> > + * 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.
> > + */
> > +
> > +/ {
> > +   model = "CompuLab SB-SOM";
> > +   compatible = "compulab,sb-som";
> 
> I would expect this to have a more specific.

SB-SOM supports multiple modules. This device tree aggregates what is
common to all possible module-baseboard combinations, which is why the
compatible string is generic.

> 
> > +   lcd0: display {
> > +   compatible = "startek,startek-kd050c", "panel-dpi";
> > +   label = "lcd";
> 
> This isn't documented, nor do I think it is needed.

It is documented in 
Documentation/devicetree/bindings/display/panel/panel-dpi.txt
You're correct about it being optional though.

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

[4.4-rc][PATCH v2] ARM: dts: am4372: fix clock source for arm twd and global timers

[Grygorii Strashko]

ARM TWD and Global timer are clocked by PERIPHCLK which is MPU_CLK/2.
But now they are clocked by dpll_mpu_m2_ck == MPU_CLK and, as result.
Timekeeping core misbehaves. For example, execution of command
"sleep 5" will take 10 sec instead of 5.

Hence, fix it by adding mpu_periphclk ("fixed-factor-clock") and use
it for clocking ARM TWD and Global timer (same way as on OMAP4).

Cc: Tony Lindgren 
Cc: Felipe Balbi 
Cc: Tero Kristo 
Fixes:commit 8cbd4c2f6a99 ("arm: boot: dts: am4372: add ARM timers and SCU 
nodes")
Signed-off-by: Grygorii Strashko 
---
Changes in v2:
 - fix: mpu_periphclk should be clocked from dpll_mpu_m2_ck instead of
   dpll_mpu_ck.
link on v1:
 http://www.spinics.net/lists/arm-kernel/msg463898.html

 arch/arm/boot/dts/am4372.dtsi| 4 ++--
 arch/arm/boot/dts/am43xx-clocks.dtsi | 8 
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index d83ff9c..de8791a 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -74,7 +74,7 @@
reg = <0x48240200 0x100>;
interrupts = ;
interrupt-parent = <>;
-   clocks = <_mpu_m2_ck>;
+   clocks = <_periphclk>;
};
 
local_timer: timer@48240600 {
@@ -82,7 +82,7 @@
reg = <0x48240600 0x100>;
interrupts = ;
interrupt-parent = <>;
-   clocks = <_mpu_m2_ck>;
+   clocks = <_periphclk>;
};
 
l2-cache-controller@48242000 {
diff --git a/arch/arm/boot/dts/am43xx-clocks.dtsi 
b/arch/arm/boot/dts/am43xx-clocks.dtsi
index cc88728..a38af2b 100644
--- a/arch/arm/boot/dts/am43xx-clocks.dtsi
+++ b/arch/arm/boot/dts/am43xx-clocks.dtsi
@@ -259,6 +259,14 @@
ti,invert-autoidle-bit;
};
 
+   mpu_periphclk: mpu_periphclk {
+   #clock-cells = <0>;
+   compatible = "fixed-factor-clock";
+   clocks = <_mpu_m2_ck>;
+   clock-mult = <1>;
+   clock-div = <2>;
+   };
+
dpll_ddr_ck: dpll_ddr_ck {
#clock-cells = <0>;
compatible = "ti,am3-dpll-clock";
-- 
2.6.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 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry

[Pali Rohár]

On Monday 30 November 2015 07:23:53 Tony Lindgren wrote:
> * Pali Rohár  [151129 16:16]:
> > On Monday 30 November 2015 01:09:17 Nicolas Pitre wrote:
> > > On Sun, 29 Nov 2015, Russell King - ARM Linux wrote:
> > > > On Sat, Nov 28, 2015 at 12:34:23PM -0500, Nicolas Pitre wrote:
> > > > > Good. And Arnd likes the idea too. So we might be converging at
> > > > > last which is a good thing.
> > > > 
> > > > I disagree with the idea that there is convergence.  There might be
> > > > convergence towards an idea, but... Here's a mail extract, from
> > > > July 7th, from earlier in this very thread:
> > > > 
> > > > Pali:
> > > > > Me:
> > > > > > Are the ATAGs at a fixed address on the N900?
> > > > > 
> > > > > Yes, in board-rx51.c is:
> > > > > 
> > > > > .atag_offset= 0x100
> > > > > 
> > > > > and Nokia Bootloader (proprietary) store them to that address.
> > > > > 
> > > > > > Can that be handled in
> > > > > > some kind of legacy file for the N900 which calls save_atags()
> > > > > > on it, so we don't end up introducing yet more stuff that we
> > > > > > have to maintain into the distant future?  If not, what about
> > > > > > copying a known working atag structure into a legacy file for
> > > > > > the N900?
> > > > > 
> > > > > I already asked question if it is possible to read ATAGs from DT
> > > > > booted kernel. And somebody (do not remember who) wrote to ML,
> > > > > that it is not possible and it can be done in that uncompress
> > > > > code.
> > > 
> > > Who is that somebody? If ever it happened to be me then objection is
> > > withdrawn. Otherwise that somebody should come forth and speak up
> > > again.
> > > 
> > 
> > ... do not remember ... this discussion were in more email threads and 
> > takes more then one year... sorry but my memory is not excellent
> 
> Yes this certainly seems like the best solution. I think we got into
> the atags-to-dt track as some of the atags are already being translated.
> 
> In this case there's no need to translate them AFAIK. You can just
> parse them and have them available for the user space. So as long as
> nothing trashes the atags at the atag_offset, you should be able to
> call a function to parse them in the n900 specific init_machine.
> 
> Regards,
> 
> Tony

In arch/arm/kernel/setup.c is function setup_arch() and it calls:

  mdesc = setup_machine_fdt(__atags_pointer);
  if (!mdesc)
  mdesc = setup_machine_tags(__atags_pointer, __machine_arch_type);

So it looks like that on atags address is stored either atags structure
or DT structure... so it is truth kernel uncompress code put DT blob to
same offset where is expected atags structure? If yes, then this is
probably reason why atags cannot be read from booted DT kernel. Can
somebody with deep knowledge of DT/atags and uncompress code verify this?

-- 
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: [RFC v02 03/15] dmaengine: core: Introduce new, universal API to request a channel

[Tony Lindgren]

Hi,

* Peter Ujfalusi  [151130 05:49]:
> 
> For each dmaengine driver an array of DMA device, slave and the parameter
> for the filter function needs to be added:
> 
> static struct dma_filter_map da830_edma_map[] = {
>   DMA_FILTER_ENTRY("davinci-mcasp.0", "rx", EDMA_CTLR_CHAN(0, 0)),
>   DMA_FILTER_ENTRY("davinci-mcasp.0", "tx", EDMA_CTLR_CHAN(0, 1)),
>   DMA_FILTER_ENTRY("davinci-mcasp.1", "rx", EDMA_CTLR_CHAN(0, 2)),
>   DMA_FILTER_ENTRY("davinci-mcasp.1", "tx", EDMA_CTLR_CHAN(0, 3)),
>   DMA_FILTER_ENTRY("davinci-mcasp.2", "rx", EDMA_CTLR_CHAN(0, 4)),
>   DMA_FILTER_ENTRY("davinci-mcasp.2", "tx", EDMA_CTLR_CHAN(0, 5)),
>   DMA_FILTER_ENTRY("spi_davinci.0", "rx", EDMA_CTLR_CHAN(0, 14)),
>   DMA_FILTER_ENTRY("spi_davinci.0", "tx", EDMA_CTLR_CHAN(0, 15)),
>   DMA_FILTER_ENTRY("da830-mmc.0", "rx", EDMA_CTLR_CHAN(0, 16)),
>   DMA_FILTER_ENTRY("da830-mmc.0", "tx", EDMA_CTLR_CHAN(0, 17)),
>   DMA_FILTER_ENTRY("spi_davinci.1", "rx", EDMA_CTLR_CHAN(0, 18)),
>   DMA_FILTER_ENTRY("spi_davinci.1", "tx", EDMA_CTLR_CHAN(0, 19)),
> };

FYI, if the EDMA_CTRL_CHAN above is just the evtmux registers, those
can be handled with the pinctrl framework. It seems that would allow
leaving out some of the built-in look up data, and have the mux parts
handled by a proper device driver. Below is a sample from the dm81xx
platform for reference.

SoC dtsi file:

evtmux: pinmux@f90 {
compatible = "pinctrl-single";
reg = <0xf90 0x40>;
#address-cells = <1>;
#size-cells = <0>;
pinctrl-single,register-width = <8>;
pinctrl-single,function-mask = <0x1f>;
};

Board specific dts file:

 {
sd2_edma_pins: pinmux_sd2_edma_pins {
pinctrl-single,pins = <
8 1 /* use SDTXEVT1 for EDMA instead of MCASP0TX */
9 2 /* use SDRXEVT1 for EDMA instead of MCASP0RX */
>;
};
};

Dynamic muxing of these channels can be done too using the pinctrl
framework named modes, but probably is not a good idea in the case of
SD card and MaASP in case something goes wrong :)

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

Re: [PATCH 01/18] ARM: am57xx: cl-som-am57x: dts: add basic module support

[Rob Herring]

On Sun, Nov 29, 2015 at 02:10:01PM +0200, Dmitry Lifshitz wrote:
> Hi Nishanth,
> 
> Thank you for the provided feedback.
> 
> On 11/25/2015 11:36 PM, Nishanth Menon wrote:
> >On 11/25/2015 12:39 AM, Dmitry Lifshitz wrote:
> >[...]
> >
> >>diff --git a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts 
> >>b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
> >>new file mode 100644
> >>index 000..b11d7da
> >>--- /dev/null
> >>+++ b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
> >[...]
> >
> >>+/ {
> >>+   model = "CompuLab CL-SOM-AM57x";
> >>+   compatible = "compulab,cl-som-am57x", "ti,am5728", "ti,dra742", 
> >>"ti,dra74", "ti,dra7";
> >>+
> >>+   memory {
> >>+   device_type = "memory";
> >>+   reg = <0x8000 0x2000>; /* 512 MB - minimal 
> >>configuration */
> >
> >I think if you like to enable LPAE, the format might look a little
> >different..
> >
> 
> We would like to have a basic HW support in the mainline. It might be
> enhanced later, once we get to work on LPAE stuff.

I think what is meant here is the cell sizes should be 2 instead of 1. 
You can do that independent of LPAE support. I would expect the base SOC 
dtsi file to set the cell sizes correctly though.

Rob

--
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 3/3] arm: plat-omap: Add PWM dmtimer platform data quirks

[Tony Lindgren]

* Neil Armstrong  [151102 03:14]:
> In order to set the currently platform dependent dmtimer
> functions pointers as platform data for the pwm-omap-dmtimer
> platform driver, add it to plat-omap auxdata_lookup table.
> 
> Suggested-by: Tony Lindgren 
> Signed-off-by: Neil Armstrong 

Actually this one will need to wait for Thierry to merge the driver
first because of the dependency to the platform_data. Please resend
this one separately once the driver hits the mainline tree.

Regards,

Tony

> ---
>  arch/arm/mach-omap2/pdata-quirks.c | 23 +++
>  1 file changed, 23 insertions(+)
> 
> diff --git a/arch/arm/mach-omap2/pdata-quirks.c 
> b/arch/arm/mach-omap2/pdata-quirks.c
> index ea56397..647dec5 100644
> --- a/arch/arm/mach-omap2/pdata-quirks.c
> +++ b/arch/arm/mach-omap2/pdata-quirks.c
> @@ -23,6 +23,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
> 
>  #include 
>  #include 
> @@ -453,6 +455,24 @@ void omap_auxdata_legacy_init(struct device *dev)
>   dev->platform_data = _gpio_auxdata;
>  }
> 
> +/* Dual mode timer PWM callbacks platdata */
> +#if IS_ENABLED(CONFIG_OMAP_DM_TIMER)
> +struct pwm_omap_dmtimer_pdata pwm_dmtimer_pdata = {
> + .request_by_node = omap_dm_timer_request_by_node,
> + .free = omap_dm_timer_free,
> + .enable = omap_dm_timer_enable,
> + .disable = omap_dm_timer_disable,
> + .get_fclk = omap_dm_timer_get_fclk,
> + .start = omap_dm_timer_start,
> + .stop = omap_dm_timer_stop,
> + .set_load = omap_dm_timer_set_load,
> + .set_match = omap_dm_timer_set_match,
> + .set_pwm = omap_dm_timer_set_pwm,
> + .set_prescaler = omap_dm_timer_set_prescaler,
> + .write_counter = omap_dm_timer_write_counter,
> +};
> +#endif
> +
>  /*
>   * Few boards still need auxdata populated before we populate
>   * the dev entries in of_platform_populate().
> @@ -506,6 +526,9 @@ static struct of_dev_auxdata omap_auxdata_lookup[] 
> __initdata = {
>   OF_DEV_AUXDATA("ti,am4372-wkup-m3", 0x44d0, "44d0.wkup_m3",
>  _m3_data),
>  #endif
> +#if IS_ENABLED(CONFIG_OMAP_DM_TIMER)
> + OF_DEV_AUXDATA("ti,omap-dmtimer-pwm", 0, NULL, _dmtimer_pdata),
> +#endif
>  #if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5)
>   OF_DEV_AUXDATA("ti,omap4-iommu", 0x4a066000, "4a066000.mmu",
>  _iommu_pdata),
> -- 
> 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

Re: [PATCH v2 4/4] ARM: DRA7: hwmod: Add data for GPTimer 12

[Tony Lindgren]

* Suman Anna  [151005 16:35]:
> Add the hwmod data for GPTimer 12. GPTimer 12 is present in
> WKUPAON power domain and is clocked from a secure 32K clock.
> GPTimer 12 serves as a secure timer on HS devices, but is
> available for kernel on regular GP devices.
> 
> The hwmod link is registered only on GP devices. The hwmod data
> also reused the existing timer class instead of reintroducing
> the identical dra7xx_timer_secure_sysc class which was dropped
> in commit edec17863362 ("ARM: DRA7: hwmod: Fix the hwmod class
> for GPTimer4").
> 
> Signed-off-by: Suman Anna 

Paul should take a look at this one.

Regards,

Tony

> ---
>  arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 36 
> +--
>  1 file changed, 34 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c 
> b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> index 562247bced49..37a10f87fbcd 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> @@ -1929,6 +1929,20 @@ static struct omap_hwmod dra7xx_timer11_hwmod = {
>   },
>  };
>  
> +/* timer12 */
> +static struct omap_hwmod dra7xx_timer12_hwmod = {
> + .name   = "timer12",
> + .class  = _timer_hwmod_class,
> + .clkdm_name = "wkupaon_clkdm",
> + .main_clk   = "secure_32k_clk_src_ck",
> + .prcm = {
> + .omap4 = {
> + .clkctrl_offs = 
> DRA7XX_CM_WKUPAON_TIMER12_CLKCTRL_OFFSET,
> + .context_offs = 
> DRA7XX_RM_WKUPAON_TIMER12_CONTEXT_OFFSET,
> + },
> + },
> +};
> +
>  /* timer13 */
>  static struct omap_hwmod dra7xx_timer13_hwmod = {
>   .name   = "timer13",
> @@ -3135,6 +3149,14 @@ static struct omap_hwmod_ocp_if 
> dra7xx_l4_per1__timer11 = {
>   .user   = OCP_USER_MPU | OCP_USER_SDMA,
>  };
>  
> +/* l4_wkup -> timer12 */
> +static struct omap_hwmod_ocp_if dra7xx_l4_wkup__timer12 = {
> + .master = _l4_wkup_hwmod,
> + .slave  = _timer12_hwmod,
> + .clk= "wkupaon_iclk_mux",
> + .user   = OCP_USER_MPU | OCP_USER_SDMA,
> +};
> +
>  /* l4_per3 -> timer13 */
>  static struct omap_hwmod_ocp_if dra7xx_l4_per3__timer13 = {
>   .master = _l4_per3_hwmod,
> @@ -3429,6 +3451,13 @@ static struct omap_hwmod_ocp_if 
> *dra7xx_hwmod_ocp_ifs[] __initdata = {
>   NULL,
>  };
>  
> +/* GP-only hwmod links */
> +static struct omap_hwmod_ocp_if *dra7xx_gp_hwmod_ocp_ifs[] __initdata = {
> + _l4_wkup__timer12,
> + NULL,
> +};
> +
> +/* SoC variant specific hwmod links */
>  static struct omap_hwmod_ocp_if *dra74x_hwmod_ocp_ifs[] __initdata = {
>   _l4_per3__usb_otg_ss4,
>   NULL,
> @@ -3446,9 +3475,12 @@ int __init dra7xx_hwmod_init(void)
>   ret = omap_hwmod_register_links(dra7xx_hwmod_ocp_ifs);
>  
>   if (!ret && soc_is_dra74x())
> - return omap_hwmod_register_links(dra74x_hwmod_ocp_ifs);
> + ret = omap_hwmod_register_links(dra74x_hwmod_ocp_ifs);
>   else if (!ret && soc_is_dra72x())
> - return omap_hwmod_register_links(dra72x_hwmod_ocp_ifs);
> + ret = omap_hwmod_register_links(dra72x_hwmod_ocp_ifs);
> +
> + if (!ret && omap_type() == OMAP2_DEVICE_TYPE_GP)
> + ret = omap_hwmod_register_links(dra7xx_gp_hwmod_ocp_ifs);
>  
>   return ret;
>  }
> -- 
> 2.6.0
> 
--
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 v2 3/4] ARM: dts: DRA7: Add timer12 node

[Tony Lindgren]

* Suman Anna  [151006 09:06]:
> On 10/06/2015 02:52 AM, Tony Lindgren wrote:
> > * Felipe Balbi  [151005 17:51]:
> >>
> >> according to Tony we should avoid using status at all for in-SoC
> >> devices.
> >>
> >> Tony, can you confirm I understood you correctly ?
> > 
> > Yes. With status = "disabled" kernel completely ignores the
> > device and struct device is not created at all even with the
> > device being there. In general we're better off trying to
> > probe the device and idle it.
> > 
> > The only time we really want to mark something with
> > status = "disabled" is if some coprocessor firmware is
> > using that device and the kernel should not touch it at
> > all.
> 
> Not always, since some of the PM clocking logic depends on the state
> machine variables within the kernel.
> 
> We are also using this to deal with paper-spins (atleast in the DRA7
> case) and the DTS include model, wherein certain instances may not be
> present on all variations of the SoC, and enabled specifically on the
> instances that matter. Obviously, it could be done the other way too,
> but as far as what Nishanth mentioned sometime back, we are following
> the former for DRA7.
> 
> In anycase, the status property on the Timer12 node can be removed, it
> doesn't fall into the above category, and we are fixing it up properly
> on HS devices in the kernel.

Yeah please remove the status property, that can be set to disabled
in the HS board specific file.

Applying the first two patches into omap-for-v4.5/soc thanks.

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

Re: [PATCH v2 4/5] ARM: dts: am437x/am33xx/omap/dm816x: Add gpmc dma channel

[Tony Lindgren]

* Franklin S Cooper Jr  [151015 10:42]:
> Add dma channel information to the gpmc. Although not enabled by
> default this will allow prefetch-dma to be used.

Picking up this patch only out of the series into omap-for-v4.5/dt.
The documentation patch does not apply as it has a dependency to
another series for adding the documentation. Please resend that
one separately once the documentation hits the mainline kernel.

The others patches in this series should get merged via the MTD tree.

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

Re: [PATCH] ARM: OMAP4: execute initcall to reserve SRAM for I688 only on OMAP4

[Grygorii Strashko]

On 11/30/2015 07:27 PM, Lucas Stach wrote:
> Am Montag, den 16.11.2015, 14:24 +0200 schrieb Grygorii Strashko:
>> On 11/16/2015 01:25 PM, Lucas Stach wrote:
>>> omap_interconnect_sync() is the only user of the SRAM scratch area
>>> allocated in the omap4_sram_init initcall. The interconnect sync is
>>> used exclusively in the OMAP4 specific WFI implementation, so there
>>> is no point in allocating the SRAM scratch on other SoC types.
>>>
>>> Bail out of the initcall if the kernel is not running on OMAP4 to
>>> avoid a confusing warning about being unable to allocate the SRAM
>>> needed for I688 handling.
>>>
>>> Signed-off-by: Lucas Stach 
>>> Tested-by: Bastian Stender 
>>> ---
>>>arch/arm/mach-omap2/omap4-common.c | 3 +++
>>>1 file changed, 3 insertions(+)
>>>
>>> diff --git a/arch/arm/mach-omap2/omap4-common.c 
>>> b/arch/arm/mach-omap2/omap4-common.c
>>> index 949696b6f17b..6db393a30a28 100644
>>> --- a/arch/arm/mach-omap2/omap4-common.c
>>> +++ b/arch/arm/mach-omap2/omap4-common.c
>>> @@ -131,6 +131,9 @@ static int __init omap4_sram_init(void)
>>> struct device_node *np;
>>> struct gen_pool *sram_pool;
>>>
>>> +   if (!cpu_is_omap44xx())
>>> +   return 0;
>>
>> This one affects on am43xx also
>>
> So you are saying this erratum is also present on AM43xx? I wasn't able
> to deduce this from the information provided by Richard Woodruff.
> 

"..SOCs using similar chassis components of OMAP4430 time are impacted..."
"..But AM335x should be immune from this particular issue..."

Advisory 11 Asynchronous Bridge Corruption
http://www.ti.com/lit/er/sprz408b/sprz408b.pdf



>>
>>> +
>>> 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",
>>
>> Since all OMAP4+ platforms are now DT based why can't we just return from 
>> here silently?
>>
> If we are unable to allocate the SRAM needed to work around I688 this is
> a real error on platforms that expose this erratum, so silently bailing
> out at this point may obscure a real issue.
> 

SRAM is not allocated here - It's just check to understand do we need it or not
in case of multiplatform build where CONFIG_OMAP_INTERCONNECT_BARRIER will be 
selected most
probably.

And if "ti,omap4-mpu" was not found - it just means that this, particular, 
platform
is not affected by i688 errata.
If someone misses corresponding node in DT - we can't do nothing :)

-- 
regards,
-grygorii
--
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/3] pwm: Add PWM driver for OMAP using dual-mode timers

[Tony Lindgren]

* Neil Armstrong  [151102 03:14]:
> Adds support for using a OMAP dual-mode timer with PWM capability
> as a Linux PWM device. The driver controls the timer by using the
> dmtimer API.
> 
> Add a platform_data structure for each pwm-omap-dmtimer nodes containing
> the dmtimers functions in order to get driver not rely on platform
> specific functions.
> 
> Cc: Grant Erickson 
> Cc: NeilBrown 
> Cc: Joachim Eastwood 
> Suggested-by: Tony Lindgren 
> Signed-off-by: Neil Armstrong 

This looks good to me:

Acked-by: Tony Lindgren 

Thierry, seems you can pick this driver patch separately if no more
comments, I'll pick up the other two patches in this series.

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

Re: [PATCH 4/4] arm: omap2+: Add hwmod spinbox support for dm816x

[Tony Lindgren]

* Neil Armstrong  [151022 02:19]:
> Add dm81xx hwmod data entries for dm816x spinbox support.

Looks good to me, I'll apply patches 3 and 4 in this series into
omap-for-v4.5/soc thanks.

Tony

> Cc: Brian Hutchinson 
> Signed-off-by: Neil Armstrong 
> ---
>  arch/arm/mach-omap2/omap_hwmod_81xx_data.c | 35 
> ++
>  1 file changed, 35 insertions(+)
> 
> diff --git a/arch/arm/mach-omap2/omap_hwmod_81xx_data.c 
> b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
> index 6256052..275b16c 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
> @@ -1036,6 +1036,40 @@ static struct omap_hwmod_ocp_if dm81xx_l4_ls__mailbox 
> = {
>   .user   = OCP_USER_MPU,
>  };
> 
> +static struct omap_hwmod_class_sysconfig dm81xx_spinbox_sysc = {
> + .rev_offs   = 0x000,
> + .sysc_offs  = 0x010,
> + .syss_offs  = 0x014,
> + .sysc_flags = SYSC_HAS_CLOCKACTIVITY | SYSC_HAS_SIDLEMODE |
> + SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE,
> + .idlemodes  = SIDLE_FORCE | SIDLE_NO | SIDLE_SMART,
> + .sysc_fields= _hwmod_sysc_type1,
> +};
> +
> +static struct omap_hwmod_class dm81xx_spinbox_hwmod_class = {
> + .name = "spinbox",
> + .sysc = _spinbox_sysc,
> +};
> +
> +static struct omap_hwmod dm81xx_spinbox_hwmod = {
> + .name   = "spinbox",
> + .clkdm_name = "alwon_l3s_clkdm",
> + .class  = _spinbox_hwmod_class,
> + .main_clk   = "sysclk6_ck",
> + .prcm   = {
> + .omap4 = {
> + .clkctrl_offs = DM81XX_CM_ALWON_SPINBOX_CLKCTRL,
> + .modulemode = MODULEMODE_SWCTRL,
> + },
> + },
> +};
> +
> +static struct omap_hwmod_ocp_if dm81xx_l4_ls__spinbox = {
> + .master = _l4_ls_hwmod,
> + .slave  = _spinbox_hwmod,
> + .user   = OCP_USER_MPU,
> +};
> +
>  static struct omap_hwmod_class dm81xx_tpcc_hwmod_class = {
>   .name   = "tpcc",
>  };
> @@ -1298,6 +1332,7 @@ static struct omap_hwmod_ocp_if *dm816x_hwmod_ocp_ifs[] 
> __initdata = {
>   _l4_ls__timer7,
>   _l4_ls__mcspi1,
>   _l4_ls__mailbox,
> + _l4_ls__spinbox,
>   _l4_hs__emac0,
>   _emac0__mdio,
>   _l4_hs__emac1,
> -- 
> 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

Re: [PATCH v2 0/5] arm: dts: complete dm816x device tree

[Tony Lindgren]

* Neil Armstrong  [151113 01:30]:
> On 11/12/2015 06:47 PM, Tony Lindgren wrote:
> > * Neil Armstrong  [151112 06:08]:
> >> In order to fix support for the dm816x platform, add missing bits in
> >> the dm816x dtsi and cleanup OCP.
> > 
> > Which ones are needed as fixes for the v4.4-rc kernel?
> > 
> > Regards,
> > 
> > Tony
> > 
> >> The last patch adds support for the omap4-hwspinlock.
> >>
> >> v2: add ocp hwmod cleanup
> >>
> >> Neil Armstrong (5):
> >>   arm: dts: add dm816x missing #mbox-cells
> >>   arm: dts: add dm816x missing spi DT dma handles
> Tony,
> 
> The two first are fixes for v4.4-rc.

OK applying first two into omap-for-v4.4/fixes, the rest
into omap-for-v4.5/dt.

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

[PATCH v4] clocksource: arm_global_timer: fix suspend resume

[Grygorii Strashko]

Now the System stall is observed on TI AM437x based board
(am437x-gp-evm) during resuming from System suspend when ARM Global
timer is selected as clocksource device (CPUIdle not enabled) - SysRq are 
working,
but nothing else.

The reason of stall is that ARM Global timer loses its contexts during
System suspend:
   GT_CONTROL.TIMER_ENABLE = 0 (unbanked)
   GT_COUNTERx = 0

Hence, update ARM Global timer driver to reflect above behaviour
- re-enable ARM Global timer on resume (GT_CONTROL.TIMER_ENABLE = 1)
  if not enabled.

CC: Arnd Bergmann 
Cc: John Stultz 
Cc: Felipe Balbi 
Cc: Tony Lindgren 
Cc: Marc Zyngier 
Reviewed-by: Santosh Shilimkar 
Signed-off-by: Grygorii Strashko 
---
Changes in v4:
 - check current timer's state before enabling.
Changes in v3:
 - dropped all DT specific code
Changes in v2:
 - suspend/resume simplified: nothing is stored any more and
   ARM GT just re-enabled
Links on prev versions:
v3: https://lkml.org/lkml/2015/11/27/402
v2: https://lkml.org/lkml/2015/11/20/355
v1: https://lkml.org/lkml/2015/11/13/456

 drivers/clocksource/arm_global_timer.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/clocksource/arm_global_timer.c 
b/drivers/clocksource/arm_global_timer.c
index a2cb6fa..817a787 100644
--- a/drivers/clocksource/arm_global_timer.c
+++ b/drivers/clocksource/arm_global_timer.c
@@ -195,12 +195,23 @@ static cycle_t gt_clocksource_read(struct clocksource *cs)
return gt_counter_read();
 }
 
+static void gt_resume(struct clocksource *cs)
+{
+   unsigned long ctrl;
+
+   ctrl = readl(gt_base + GT_CONTROL);
+   if (!(ctrl & GT_CONTROL_TIMER_ENABLE))
+   /* re-enable timer on resume */
+   writel(GT_CONTROL_TIMER_ENABLE, gt_base + GT_CONTROL);
+}
+
 static struct clocksource gt_clocksource = {
.name   = "arm_global_timer",
.rating = 300,
.read   = gt_clocksource_read,
.mask   = CLOCKSOURCE_MASK(64),
.flags  = CLOCK_SOURCE_IS_CONTINUOUS,
+   .resume = gt_resume,
 };
 
 #ifdef CONFIG_CLKSRC_ARM_GLOBAL_TIMER_SCHED_CLOCK
-- 
2.6.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 0/4] Cleanup legacy OMAP IOMMU device creation

[Tony Lindgren]

* Suman Anna  [151022 10:16]:
> Hi Tony,
> 
> On 09/16/2015 06:48 PM, Suman Anna wrote:
> > Hi Tony,
> > 
> > The following series removes the legacy platform device creation
> > logic for OMAP IOMMU devices. I will cleanup the legacy support
> > from the OMAP IOMMU driver in a subsequent merge window after
> > this series makes it to mainline.
> > 
> > Patches are based on 4.3-rc1 + the OMAP3 ISP instantiation cleanup
> > patch [1]. All the patches need to be picked up sequentially,
> > otherwise a NULL pointer dereference crash might be seen on OMAP3
> > legacy boots as the dev attribute structure is deferenced directly
> > in mach-omap2/omap-iommu.c during platform data creation. Also, the
> > last patch removes the structure definition altogether, so will
> > cause build issues if picked separately from the hwmod cleanup
> > patches.
> > 
> > I do not have any boards where I can still perform a legacy-style
> > boot, so patches verified using DT-boot only.
> > 
> > regards
> > Suman
> > 
> > [1] https://patchwork.kernel.org/patch/6806891/
> > 
> > Suman Anna (4):
> >   ARM: OMAP2+: Remove legacy device instantiation of IOMMUs
> >   ARM: OMAP3: hwmod data: Remove legacy IOMMU data
> >   ARM: OMAP4: hwmod data: Remove legacy IOMMU attr and addrs
> >   ARM: OMAP2+: Remove omap_mmu_dev_attr structure
> 
> Ping on this series. You should be able to pick up atleast patch 1 if
> not picking all, now that the OMAP3 ISP cleanup patch is staged in your
> omap-for-4.4/cleanup branch.

Sorry for the delays, applying this series into omap-for-v4.5/soc.

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

Re: [PATCH] ARM: dts: Set VAUX1 and VAUX4 on Logic PD Torpedo

[Tony Lindgren]

* Adam Ford  [151026 05:53]:
> The schematic expects VAUX1 to be 3.0V attached to the debug port.
> The schematic expects VAUX4 to be 1.8V.
> VAUX4 powers VDDS_CSI2 on processor.

Applying all your six patches into omap-for-v4.4/dt finally thanks.

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

Re: [PATCH] clk: ti: omap5+: dpll: implement errata i810

[Stephen Boyd]

On 11/30, Tero Kristo wrote:
> Errata i810 states that DPLL controller can get stuck while transitioning
> to a power saving state, while its M/N ratio is being re-programmed.
> 
> As a workaround, before re-programming the M/N ratio, SW has to ensure
> the DPLL cannot start an idle state transition. SW can disable DPLL
> idling by setting the DPLL AUTO_DPLL_MODE=0 or keeping a clock request
> active by setting a dependent clock domain in SW_WKUP.
> 
> This errata impacts OMAP5 and DRA7 chips, so enable the errata for these.
> 
> Signed-off-by: Tero Kristo 
> ---

Acked-by: Stephen Boyd 

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-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 v2 1/6] ARM: OMAP2+: dts: cm-t335: add initial support

[Tony Lindgren]

* Uri Mashiach  [151124 06:03]:
> --- /dev/null
> +++ b/arch/arm/boot/dts/am335x-cm-t335.dts
...

> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> +
> + status = "okay";
> +};
> +

FYI, the extra line break at the end of the file causes whitespace
warnings when applying. And fixing that causes extra hassles with
applying the other patches in the series as the patches won't apply..
So for the next time, you may want to check that ;)

Also, the subject line should be "ARM: dts: ..." for the dts changes
so the git log loooks unified for all the ARM SoCs.

Anyways, I've fixed up those locally and applying into omap-for-v4.5/dt.

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

Re: [PATCH v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Brian Norris]

Hi Roger,

On Tue, Oct 27, 2015 at 11:37:03AM +0200, Roger Quadros wrote:
> On 26/10/15 23:23, Brian Norris wrote:
> > I'm not too familiar with OMAP platforms, and I might have missed out on
> > prior discussions/context, so please forgive if I'm asking silly or old
> > questions here.
> 
> No worries at all.
> 
> > 
> > On Fri, Sep 18, 2015 at 05:53:22PM +0300, Roger Quadros wrote:
> >> - Remove NAND IRQ handling from omap-gpmc driver, share the GPMC IRQ
> >> with the omap2-nand driver and handle NAND IRQ events in the NAND driver.
> >> This causes performance increase when using prefetch-irq mode.
> >> 30% increase in read, 17% increase in write in prefetch-irq mode.
> > 
> > Have you pinpointed the exact causes for the performance increase, or
> > can you give an educated guess? AIUI, you're reducing the number of
> > interrupts needed for NAND prefetch mode, but you're also removing a bit
> > of abstraction and implementing hooks that look awfully like the
> > existing abstractions:
> > 
> > +   int (*nand_irq_enable)(enum gpmc_nand_irq irq);
> > +   int (*nand_irq_disable)(enum gpmc_nand_irq irq);
> > +   void (*nand_irq_clear)(enum gpmc_nand_irq irq);
> > +   u32 (*nand_irq_status)(void);
> > 
> > That's not really a problem if there's a good reason for them (brcmnand
> > implements similar hooks because of quirks in the implementation of
> > interrupts across various BRCM SoCs, and it's not worth writing irqchip
> > drivers for those cases). I'm mainly curious for an explanation.
> 
> I have both implementations with me. My guess is that the 20% performance
> gain is due to absence of irqchip/irqdomain translation code.
> I haven't investigated further though.

I don't have much context for whether this makes sense or not. According
to your tests, you're getting ~800K interrupts over ~15 seconds. So
should you start noticing performance hits due to abstraction at 53K
interrupts per second?

But anyway, I'm not sure that completely answered my question. My
question was whether you were removing the irqchip code solely for
performance reasons, or are there others?

> Another concern I have is that I'm not using any locking around
> gpmc_nand_irq_enable/disable(). Could this pose problems in multiple NAND
> use cases? My understanding is that it should not as the controller access
> is serialized between multiple NAND chips.

Right, if you're touching just a NAND interrupt, and it's only used by a
single instance of this NAND controller, then the NAND controller
serialization code will handle this for you.

> However I do need to add some locking as the GPMC_IRQENABLE register is shared
> between NAND and GPMC driver.
> 
> NOTE: We are not using prefetch-irq mode for any of the OMAP boards because
> of lesser performance than prefetch-polled mode. So if the less performance
> for an unused mode is a lesser concern compared to cleaner code then
> I can resend this with the irqdomain implementation.
> 
> Below are performance logs of irqdomain vs hooks.
> 
> --
> cheers,
> -roger
> 
> test logs.

[snip]

Brian
--
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: [GIT PULL] clk: ti: fixes for 4.4-rc

[Stephen Boyd]

On 11/24, Tero Kristo wrote:
> Hi Michael, Stephen,
> 
> Here are some TI clock driver fixes for 4.4-rc.
> 
> -Tero
> 
> 
> 
> The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec:
> 
>   Linux 4.4-rc1 (2015-11-15 17:00:27 -0800)
> 
> are available in the git repository at:
> 
>   https://github.com/t-kristo/linux-pm.git for-4.4-rc/ti-clk-fixes
> 
> for you to fetch changes up to 167af5ef2cdba14ff14a13c91e5532ed479083d8:
> 
>   clk: ti: drop locking code from mux/divider drivers (2015-11-24
> 11:30:27 +0200)
> 

Thanks. Pulled into clk-fixes.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-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 v4 2/5] spi: spi-ti-qspi: add mmap mode read support

[Felipe Balbi]

Hi,

Vignesh R  writes:
> ti-qspi controller provides mmap port to read data from SPI flashes.
> mmap port is enabled in QSPI_SPI_SWITCH_REG. ctrl module register may
> also need to be accessed for some SoCs. The QSPI_SPI_SETUP_REGx needs to
> be populated with flash specific information like read opcode, read
> mode(quad, dual, normal), address width and dummy bytes. Once,
> controller is in mmap mode, the whole flash memory is available as a
> memory region at SoC specific address. This region can be accessed using
> normal memcpy() (or mem-to-mem dma copy). The ti-qspi controller hardware
> will internally communicate with SPI flash over SPI bus and get the
> requested data.
>
> Implement spi_flash_read() callback to support mmap read over SPI
> flash devices. With this, the read throughput increases from ~100kB/s to
> ~2.5 MB/s.
>
> Signed-off-by: Vignesh R 
> ---
>
>  drivers/spi/spi-ti-qspi.c | 101 
> ++
>  1 file changed, 94 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/spi/spi-ti-qspi.c b/drivers/spi/spi-ti-qspi.c
> index 64318fcfacf2..cd4e63f45e65 100644
> --- a/drivers/spi/spi-ti-qspi.c
> +++ b/drivers/spi/spi-ti-qspi.c
> @@ -56,6 +56,7 @@ struct ti_qspi {
>   u32 dc;
>  
>   bool ctrl_mod;
> + bool mmap_enabled;
>  };
>  
>  #define QSPI_PID (0x0)
> @@ -65,11 +66,8 @@ struct ti_qspi {
>  #define QSPI_SPI_CMD_REG (0x48)
>  #define QSPI_SPI_STATUS_REG  (0x4c)
>  #define QSPI_SPI_DATA_REG(0x50)
> -#define QSPI_SPI_SETUP0_REG  (0x54)
> +#define QSPI_SPI_SETUP_REG(n)((0x54 + 4 * n))
>  #define QSPI_SPI_SWITCH_REG  (0x64)
> -#define QSPI_SPI_SETUP1_REG  (0x58)
> -#define QSPI_SPI_SETUP2_REG  (0x5c)
> -#define QSPI_SPI_SETUP3_REG  (0x60)
>  #define QSPI_SPI_DATA_REG_1  (0x68)
>  #define QSPI_SPI_DATA_REG_2  (0x6c)
>  #define QSPI_SPI_DATA_REG_3  (0x70)
> @@ -109,6 +107,16 @@ struct ti_qspi {
>  
>  #define QSPI_AUTOSUSPEND_TIMEOUT 2000
>  
> +#define MEM_CS_EN(n) ((n + 1) << 8)
> +
> +#define MM_SWITCH0x1
> +
> +#define QSPI_SETUP_RD_NORMAL (0x0 << 12)
> +#define QSPI_SETUP_RD_DUAL   (0x1 << 12)
> +#define QSPI_SETUP_RD_QUAD   (0x3 << 12)
> +#define QSPI_SETUP_ADDR_SHIFT8
> +#define QSPI_SETUP_DUMMY_SHIFT   10
> +
>  static inline unsigned long ti_qspi_read(struct ti_qspi *qspi,
>   unsigned long reg)
>  {
> @@ -366,6 +374,78 @@ static int qspi_transfer_msg(struct ti_qspi *qspi, 
> struct spi_transfer *t)
>   return 0;
>  }
>  
> +static void ti_qspi_enable_memory_map(struct spi_device *spi)
> +{
> + struct ti_qspi  *qspi = spi_master_get_devdata(spi->master);
> + u32 val;
> +
> + ti_qspi_write(qspi, MM_SWITCH, QSPI_SPI_SWITCH_REG);
> + if (qspi->ctrl_mod) {
> + val = readl(qspi->ctrl_base);
> + val |= MEM_CS_EN(spi->chip_select);
> + writel(val, qspi->ctrl_base);
> + /* dummy readl to ensure bus sync */
> + readl(qspi->ctrl_base);
> + }
> + qspi->mmap_enabled = true;
> +}
> +
> +static void ti_qspi_disable_memory_map(struct spi_device *spi)
> +{
> + struct ti_qspi  *qspi = spi_master_get_devdata(spi->master);
> + u32 val;
> +
> + ti_qspi_write(qspi, 0, QSPI_SPI_SWITCH_REG);
> + if (qspi->ctrl_mod) {
> + val = readl(qspi->ctrl_base);
> + val &= ~MEM_CS_EN(spi->chip_select);
> + writel(val, qspi->ctrl_base);
> + }
> + qspi->mmap_enabled = false;
> +}
> +
> +static void ti_qspi_setup_mmap_read(struct spi_device *spi,
> + struct spi_flash_read_message *msg)
> +{
> + struct ti_qspi  *qspi = spi_master_get_devdata(spi->master);
> + u32 memval = msg->read_opcode;
> +
> + switch (msg->data_nbits) {
> + case SPI_NBITS_QUAD:
> + memval |= QSPI_SETUP_RD_QUAD;
> + break;
> + case SPI_NBITS_DUAL:
> + memval |= QSPI_SETUP_RD_DUAL;
> + break;
> + default:
> + memval |= QSPI_SETUP_RD_NORMAL;
> + break;
> + }
> + memval |= ((msg->addr_width - 1) << QSPI_SETUP_ADDR_SHIFT |
> +msg->dummy_bytes << QSPI_SETUP_DUMMY_SHIFT);
> + ti_qspi_write(qspi, memval,
> +   QSPI_SPI_SETUP_REG(spi->chip_select));
> +}
> +
> +static int ti_qspi_spi_flash_read(struct  spi_device *spi,
> +   struct spi_flash_read_message *msg)
> +{
> + struct ti_qspi *qspi = spi_master_get_devdata(spi->master);
> + int ret = 0;
> +
> + mutex_lock(>list_lock);
> +
> + if (!qspi->mmap_enabled)
> + ti_qspi_enable_memory_map(spi);
> + ti_qspi_setup_mmap_read(spi, msg);
> + memcpy_fromio(msg->buf, qspi->mmap_base + msg->from, msg->len);
> + 

Re: [PATCH v4 4/5] ARM: dts: DRA7: add entry for qspi mmap region

[Tony Lindgren]

* Tony Lindgren  [151130 14:03]:
> * Vignesh R  [151129 21:16]:
> > Add qspi memory mapped region entries for DRA7xx based SoCs. Also,
> > update the binding documents for the controller to document this change.
> > 
> > Acked-by: Rob Herring 
> > Signed-off-by: Vignesh R 
> > ---
> > 
> > v4: No changes.
> 
> OK I'll apply patches 4 and 5 of this series into omap-for-v4.5/dt thanks.
> The rest should get merged via the MTD tree.

Actually ddropping them after looking at the IO ranges like I commented.

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

Re: [PATCH v4 4/5] ARM: dts: DRA7: add entry for qspi mmap region

[Tony Lindgren]

* Vignesh R  [151129 21:16]:
> Add qspi memory mapped region entries for DRA7xx based SoCs. Also,
> update the binding documents for the controller to document this change.
> 
> Acked-by: Rob Herring 
> Signed-off-by: Vignesh R 
...
> --- a/Documentation/devicetree/bindings/spi/ti_qspi.txt
> +++ b/Documentation/devicetree/bindings/spi/ti_qspi.txt
> @@ -26,3 +26,17 @@ qspi: qspi@4b30 {
>   spi-max-frequency = <2500>;
>   ti,hwmods = "qspi";
>  };
> +
> +For dra7xx:
> +qspi: qspi@4b30 {
> + compatible = "ti,dra7xxx-qspi";
> + reg = <0x4b30 0x100>,
> +   <0x5c00 0x400>,
> +   <0x4a002558 0x4>;
> + reg-names = "qspi_base", "qspi_mmap",
> + "qspi_ctrlmod";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + spi-max-frequency = <4800>;
> + ti,hwmods = "qspi";
> +};

Actually none of the IO areas above are within the same interconnect target:

0x4b30  QSPI0 address space in L3 main interconnect
0x5c00  QSPI1 address space in L3 main interconnect
0x4a002558  CTRL_CORE_CONTROL_IO_2 in System Control Module (SCM) in L4_CFG

The first two address spaces should be two separate instances of this driver.
The CTRL_CORE_CONTROL_IO_2 needs seems like a shared clock register that
needs to be accessed using the clock framework most likely.

So not applying, this will be impossible to move to some real interconnect
driver until these issues are fixed.

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

[PATCH 4/7] ARM: iop13xx: make headers more local

[Arnd Bergmann]

Some header files are never included outside of a mach-iop13xx
directory and do not need to be made visible in include/mach,
so let's just move them all down one level.

Signed-off-by: Arnd Bergmann 
---
 arch/arm/mach-iop13xx/include/mach/pci.h   | 57 -
 arch/arm/mach-iop13xx/iq81340mc.c  |  2 +-
 arch/arm/mach-iop13xx/iq81340sc.c  |  2 +-
 arch/arm/mach-iop13xx/irq.c|  2 +-
 arch/arm/mach-iop13xx/{include/mach => }/msi.h |  0
 arch/arm/mach-iop13xx/pci.c|  2 +-
 arch/arm/mach-iop13xx/pci.h| 58 ++
 7 files changed, 62 insertions(+), 61 deletions(-)
 delete mode 100644 arch/arm/mach-iop13xx/include/mach/pci.h
 rename arch/arm/mach-iop13xx/{include/mach => }/msi.h (100%)

diff --git a/arch/arm/mach-iop13xx/include/mach/pci.h 
b/arch/arm/mach-iop13xx/include/mach/pci.h
deleted file mode 100644
index 59f42b535572..
--- a/arch/arm/mach-iop13xx/include/mach/pci.h
+++ /dev/null
@@ -1,57 +0,0 @@
-#ifndef _IOP13XX_PCI_H_
-#define _IOP13XX_PCI_H_
-#include 
-#include 
-
-struct pci_sys_data;
-struct hw_pci;
-int iop13xx_pci_setup(int nr, struct pci_sys_data *sys);
-struct pci_bus *iop13xx_scan_bus(int nr, struct pci_sys_data *);
-void iop13xx_atu_select(struct hw_pci *plat_pci);
-void iop13xx_pci_init(void);
-void iop13xx_map_pci_memory(void);
-
-#define IOP_PCI_STATUS_ERROR (PCI_STATUS_PARITY |   \
-  PCI_STATUS_SIG_TARGET_ABORT | \
-  PCI_STATUS_REC_TARGET_ABORT | \
-  PCI_STATUS_REC_TARGET_ABORT | \
-  PCI_STATUS_REC_MASTER_ABORT | \
-  PCI_STATUS_SIG_SYSTEM_ERROR | \
-  PCI_STATUS_DETECTED_PARITY)
-
-#define IOP13XX_ATUE_ATUISR_ERROR (IOP13XX_ATUE_STAT_HALT_ON_ERROR |  \
-   IOP13XX_ATUE_STAT_ROOT_SYS_ERR |   \
-   IOP13XX_ATUE_STAT_PCI_IFACE_ERR |  \
-   IOP13XX_ATUE_STAT_ERR_COR |\
-   IOP13XX_ATUE_STAT_ERR_UNCOR |  \
-   IOP13XX_ATUE_STAT_CRS |\
-   IOP13XX_ATUE_STAT_DET_PAR_ERR |\
-   IOP13XX_ATUE_STAT_EXT_REC_MABORT | \
-   IOP13XX_ATUE_STAT_SIG_TABORT | \
-   IOP13XX_ATUE_STAT_EXT_REC_TABORT | \
-   IOP13XX_ATUE_STAT_MASTER_DATA_PAR)
-
-#define IOP13XX_ATUX_ATUISR_ERROR (IOP13XX_ATUX_STAT_TX_SCEM |\
-   IOP13XX_ATUX_STAT_REC_SCEM |   \
-   IOP13XX_ATUX_STAT_TX_SERR |\
-   IOP13XX_ATUX_STAT_DET_PAR_ERR |\
-   IOP13XX_ATUX_STAT_INT_REC_MABORT | \
-   IOP13XX_ATUX_STAT_REC_SERR |   \
-   IOP13XX_ATUX_STAT_EXT_REC_MABORT | \
-   IOP13XX_ATUX_STAT_EXT_REC_TABORT | \
-   IOP13XX_ATUX_STAT_EXT_SIG_TABORT | \
-   IOP13XX_ATUX_STAT_MASTER_DATA_PAR)
-
-/* PCI interrupts
- */
-#define ATUX_INTA IRQ_IOP13XX_XINT0
-#define ATUX_INTB IRQ_IOP13XX_XINT1
-#define ATUX_INTC IRQ_IOP13XX_XINT2
-#define ATUX_INTD IRQ_IOP13XX_XINT3
-
-#define ATUE_INTA IRQ_IOP13XX_ATUE_IMA
-#define ATUE_INTB IRQ_IOP13XX_ATUE_IMB
-#define ATUE_INTC IRQ_IOP13XX_ATUE_IMC
-#define ATUE_INTD IRQ_IOP13XX_ATUE_IMD
-
-#endif /* _IOP13XX_PCI_H_ */
diff --git a/arch/arm/mach-iop13xx/iq81340mc.c 
b/arch/arm/mach-iop13xx/iq81340mc.c
index 9cd07d396093..d255ab5ad1a5 100644
--- a/arch/arm/mach-iop13xx/iq81340mc.c
+++ b/arch/arm/mach-iop13xx/iq81340mc.c
@@ -23,7 +23,7 @@
 #include 
 #include 
 #include 
-#include 
+#include "pci.h"
 #include 
 #include 
 
diff --git a/arch/arm/mach-iop13xx/iq81340sc.c 
b/arch/arm/mach-iop13xx/iq81340sc.c
index b3ec11cb707e..33eeaf1fa11d 100644
--- a/arch/arm/mach-iop13xx/iq81340sc.c
+++ b/arch/arm/mach-iop13xx/iq81340sc.c
@@ -23,7 +23,7 @@
 #include 
 #include 
 #include 
-#include 
+#include "pci.h"
 #include 
 #include 
 
diff --git a/arch/arm/mach-iop13xx/irq.c b/arch/arm/mach-iop13xx/irq.c
index 623d85a4af2d..c702cc4092de 100644
--- a/arch/arm/mach-iop13xx/irq.c
+++ b/arch/arm/mach-iop13xx/irq.c
@@ -25,7 +25,7 @@
 #include 
 #include 
 #include 
-#include 
+#include "msi.h"
 
 /* INTCTL0 CP6 R0 Page 4
  */
diff --git a/arch/arm/mach-iop13xx/include/mach/msi.h 
b/arch/arm/mach-iop13xx/msi.h
similarity index 100%
rename from arch/arm/mach-iop13xx/include/mach/msi.h
rename to arch/arm/mach-iop13xx/msi.h
diff --git a/arch/arm/mach-iop13xx/pci.c b/arch/arm/mach-iop13xx/pci.c
index 9082b84aeebb..204eb4460271 100644
--- 

[PATCH 3/7] ARM: davinci: make headers more local

[Arnd Bergmann]

Some header files are never included outside of a mach-davinci
directory and do not need to be made visible in include/mach,
so let's just move them all down one level.

Signed-off-by: Arnd Bergmann 
---
 arch/arm/mach-davinci/board-da830-evm.c| 2 +-
 arch/arm/mach-davinci/board-da850-evm.c| 4 ++--
 arch/arm/mach-davinci/board-mityomapl138.c | 2 +-
 arch/arm/mach-davinci/board-omapl138-hawk.c| 2 +-
 arch/arm/mach-davinci/clock.c  | 2 +-
 arch/arm/mach-davinci/cp_intc.c| 2 +-
 arch/arm/mach-davinci/{include/mach => }/cp_intc.h | 0
 arch/arm/mach-davinci/cpuidle.c| 4 ++--
 arch/arm/mach-davinci/{include/mach => }/cpuidle.h | 0
 arch/arm/mach-davinci/da830.c  | 2 +-
 arch/arm/mach-davinci/da850.c  | 2 +-
 arch/arm/mach-davinci/da8xx-dt.c   | 2 +-
 arch/arm/mach-davinci/{include/mach => }/ddr2.h| 0
 arch/arm/mach-davinci/devices-da8xx.c  | 4 ++--
 arch/arm/mach-davinci/dm355.c  | 2 +-
 arch/arm/mach-davinci/dm365.c  | 2 +-
 arch/arm/mach-davinci/dm644x.c | 2 +-
 arch/arm/mach-davinci/dm646x.c | 2 +-
 arch/arm/mach-davinci/pm.c | 2 +-
 arch/arm/mach-davinci/psc.c| 2 +-
 arch/arm/mach-davinci/{include/mach => }/psc.h | 0
 arch/arm/mach-davinci/sleep.S  | 4 ++--
 arch/arm/mach-davinci/sram.c   | 2 +-
 arch/arm/mach-davinci/{include/mach => }/sram.h| 0
 24 files changed, 23 insertions(+), 23 deletions(-)
 rename arch/arm/mach-davinci/{include/mach => }/cp_intc.h (100%)
 rename arch/arm/mach-davinci/{include/mach => }/cpuidle.h (100%)
 rename arch/arm/mach-davinci/{include/mach => }/ddr2.h (100%)
 rename arch/arm/mach-davinci/{include/mach => }/psc.h (100%)
 rename arch/arm/mach-davinci/{include/mach => }/sram.h (100%)

diff --git a/arch/arm/mach-davinci/board-da830-evm.c 
b/arch/arm/mach-davinci/board-da830-evm.c
index f8f62fbaa915..3d8cf8cbd98a 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -32,7 +32,7 @@
 #include 
 
 #include 
-#include 
+#include "cp_intc.h"
 #include 
 #include 
 
diff --git a/arch/arm/mach-davinci/board-da850-evm.c 
b/arch/arm/mach-davinci/board-da850-evm.c
index 9cc7b818fbf6..8e4539f69fdc 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -40,10 +40,10 @@
 #include 
 
 #include 
-#include 
+#include "cp_intc.h"
 #include 
 #include 
-#include 
+#include "sram.h"
 
 #include 
 #include 
diff --git a/arch/arm/mach-davinci/board-mityomapl138.c 
b/arch/arm/mach-davinci/board-mityomapl138.c
index 8cfbfe084535..de1316bf643a 100644
--- a/arch/arm/mach-davinci/board-mityomapl138.c
+++ b/arch/arm/mach-davinci/board-mityomapl138.c
@@ -26,7 +26,7 @@
 #include 
 #include 
 #include 
-#include 
+#include "cp_intc.h"
 #include 
 #include 
 #include 
diff --git a/arch/arm/mach-davinci/board-omapl138-hawk.c 
b/arch/arm/mach-davinci/board-omapl138-hawk.c
index 2aac51d0e853..ee624861ca66 100644
--- a/arch/arm/mach-davinci/board-omapl138-hawk.c
+++ b/arch/arm/mach-davinci/board-omapl138-hawk.c
@@ -19,7 +19,7 @@
 #include 
 
 #include 
-#include 
+#include "cp_intc.h"
 #include 
 #include 
 
diff --git a/arch/arm/mach-davinci/clock.c b/arch/arm/mach-davinci/clock.c
index 47281f5c12ea..a23e21aa0d8b 100644
--- a/arch/arm/mach-davinci/clock.c
+++ b/arch/arm/mach-davinci/clock.c
@@ -23,7 +23,7 @@
 #include 
 
 #include 
-#include 
+#include "psc.h"
 #include 
 #include "clock.h"
 
diff --git a/arch/arm/mach-davinci/cp_intc.c b/arch/arm/mach-davinci/cp_intc.c
index 507aad4b8dd9..1a68d2477de6 100644
--- a/arch/arm/mach-davinci/cp_intc.c
+++ b/arch/arm/mach-davinci/cp_intc.c
@@ -19,7 +19,7 @@
 #include 
 
 #include 
-#include 
+#include "cp_intc.h"
 
 static inline unsigned int cp_intc_read(unsigned offset)
 {
diff --git a/arch/arm/mach-davinci/include/mach/cp_intc.h 
b/arch/arm/mach-davinci/cp_intc.h
similarity index 100%
rename from arch/arm/mach-davinci/include/mach/cp_intc.h
rename to arch/arm/mach-davinci/cp_intc.h
diff --git a/arch/arm/mach-davinci/cpuidle.c b/arch/arm/mach-davinci/cpuidle.c
index 306ebc51599a..1b8f08532455 100644
--- a/arch/arm/mach-davinci/cpuidle.c
+++ b/arch/arm/mach-davinci/cpuidle.c
@@ -19,8 +19,8 @@
 #include 
 #include 
 
-#include 
-#include 
+#include "cpuidle.h"
+#include "ddr2.h"
 
 #define DAVINCI_CPUIDLE_MAX_STATES 2
 
diff --git a/arch/arm/mach-davinci/include/mach/cpuidle.h 
b/arch/arm/mach-davinci/cpuidle.h
similarity index 100%
rename from arch/arm/mach-davinci/include/mach/cpuidle.h
rename to arch/arm/mach-davinci/cpuidle.h
diff --git a/arch/arm/mach-davinci/da830.c b/arch/arm/mach-davinci/da830.c
index 115d5736da80..7187e7fc2822 100644
--- a/arch/arm/mach-davinci/da830.c
+++ b/arch/arm/mach-davinci/da830.c
@@ 

[PATCH 7/7] ARM: netx: remove unused mach/param.h

[Arnd Bergmann]

I could not find any users of this file, past or present, and
it contains only a comment, so let's remove it.

Signed-off-by: Arnd Bergmann 
---
 arch/arm/mach-netx/include/mach/param.h | 18 --
 1 file changed, 18 deletions(-)
 delete mode 100644 arch/arm/mach-netx/include/mach/param.h

diff --git a/arch/arm/mach-netx/include/mach/param.h 
b/arch/arm/mach-netx/include/mach/param.h
deleted file mode 100644
index a771459206aa..
--- a/arch/arm/mach-netx/include/mach/param.h
+++ /dev/null
@@ -1,18 +0,0 @@
-/*
- *  arch/arm/mach-netx/include/mach/param.h
- *
- * Copyright (C) 2005 Sascha Hauer , Pengutronix
- *
- * 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.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
- */
-- 
2.1.0.rc2

--
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 v2] ARM: omap2+: enable REGULATOR_FIXED_VOLTAGE

[Tony Lindgren]

* Grygorii Strashko  [151126 07:24]:
> Enable REGULATOR_FIXED_VOLTAGE for all OMAP2+ platforms
> otherwise system can't boot from SD-card when kernel is
> built for single SoC (for example, with CONFIG_SOC_DRA7XX=y only).
> 
> It's also required for almost all TI SoC's platforms.
> 
> Signed-off-by: Grygorii Strashko 

Applying into omap-for-v4.4/fixes thanks.

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

Re: [PATCH 1/7] ARM: omap1: make headers more local

[Tony Lindgren]

* Arnd Bergmann  [151130 15:02]:
> Some header files are never included outside of a mach-omap1
> directory and do not need to be made visible in include/mach,
> so let's just move them all down one level.
> 
> Signed-off-by: Arnd Bergmann 
> ---
>  arch/arm/mach-omap1/board-ams-delta.c  | 2 +-
>  arch/arm/mach-omap1/board-fsample.c| 2 +-
>  arch/arm/mach-omap1/board-h2.c | 2 +-
>  arch/arm/mach-omap1/board-h3.c | 2 +-
>  arch/arm/mach-omap1/board-innovator.c  | 2 +-
>  arch/arm/mach-omap1/board-osk.c| 2 +-
>  arch/arm/mach-omap1/board-palmte.c | 2 +-
>  arch/arm/mach-omap1/board-palmtt.c | 2 +-
>  arch/arm/mach-omap1/board-palmz71.c| 2 +-
>  arch/arm/mach-omap1/board-perseus2.c   | 2 +-
>  arch/arm/mach-omap1/board-sx1-mmc.c| 2 +-
>  arch/arm/mach-omap1/board-sx1.c| 4 ++--
>  arch/arm/mach-omap1/{include/mach => }/board-sx1.h | 0
>  arch/arm/mach-omap1/{include/mach => }/camera.h| 0
>  arch/arm/mach-omap1/devices.c  | 2 +-
>  arch/arm/mach-omap1/flash.c| 2 +-
>  arch/arm/mach-omap1/{include/mach => }/flash.h | 0
>  17 files changed, 15 insertions(+), 15 deletions(-)
>  rename arch/arm/mach-omap1/{include/mach => }/board-sx1.h (100%)
>  rename arch/arm/mach-omap1/{include/mach => }/camera.h (100%)
>  rename arch/arm/mach-omap1/{include/mach => }/flash.h (100%)

Looks good to me:

Acked-by: Tony Lindgren 
--
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: Incomplete DM814x support in 4.3

[Tony Lindgren]

Hi,

Adding linux-omap to Cc.

* Philipp Rosenberger  [151118 05:20]:
> Hi,
> 
> I have seen with pleasure that some support for DM814x was integrated to the 
> kernel. But it seems incomplete I get various errors when I try to boot the 
> kernel on a DM814x/AM387x based board.

Sorry for the delay in replying. Current dm8148 support is based on the
bootloader clocks right now so YMMW. I fixed up the basic support for
dm8148 on hp t410 and that is bootable to NFSroot with mainline.

I'll try to post some patches soon for adding the clock driver and more devices.
So far I have GPIOs, Ethernet, USB and MMC working.. Also on dm8148-evm.

I still need to clean up things a bit, hoping to be able to post this week at
some point.

> End in the end it panics with this:
> [0.379442] platform ocp: Cannot lookup hwmod 'l3_main'
> [0.387920] platform 48032000.gpio: Cannot lookup hwmod 'gpio1'
> [0.394638] omap_gpio 48032000.gpio: Could not get gpio dbck. Disable 
> debounce
> [0.402220] omap_gpio 48032000.gpio: _od_fail_runtime_resume: FIXME: 
> missing hwmod/omap_dev info
> [0.411448] Unhandled fault: external abort on non-linefetch (0x1028) at 
> 0xfa032034

Yup this is what I'm seeing too on dm8148-evm after I got one. It's because of
the missing clocks.

> I searched for 'l3_main' in the hwmods for dm814x but it is not defined in 
> there.

I think I have fixed up that one too.. Need to check :)

> I didn't find a driver in the tree which is compatible with "ti,dm814-pllss" 
> so no driver for pll handling.

I have an initial driver coming up for that.. Heh it also works as a loadable
module on hp t410 :)

> Is there some work in progress to bring the missing parts into the kernel?

Yes, best to coordinate the effort on linux-omap and linux-arm-kernel lists.

FYI, I have these pieces coming up this week:

- Few fixes for for the clock muxes for system timers

- Basic clock driver for dm8148 ADPLLs, still in read-only mode for the PLLs

- DTS + hwmod support for GPIOs, MMC and MUSB

- Minimal board support for j5eco-evm

Then the PWM support done for dm816x should also work on others, and I belive
people are working on getting the DSP supported but don't know the current
status. Maybe somebody can reply on that?

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

[PATCH 1/7] ARM: omap1: make headers more local

[Arnd Bergmann]

Some header files are never included outside of a mach-omap1
directory and do not need to be made visible in include/mach,
so let's just move them all down one level.

Signed-off-by: Arnd Bergmann 
---
 arch/arm/mach-omap1/board-ams-delta.c  | 2 +-
 arch/arm/mach-omap1/board-fsample.c| 2 +-
 arch/arm/mach-omap1/board-h2.c | 2 +-
 arch/arm/mach-omap1/board-h3.c | 2 +-
 arch/arm/mach-omap1/board-innovator.c  | 2 +-
 arch/arm/mach-omap1/board-osk.c| 2 +-
 arch/arm/mach-omap1/board-palmte.c | 2 +-
 arch/arm/mach-omap1/board-palmtt.c | 2 +-
 arch/arm/mach-omap1/board-palmz71.c| 2 +-
 arch/arm/mach-omap1/board-perseus2.c   | 2 +-
 arch/arm/mach-omap1/board-sx1-mmc.c| 2 +-
 arch/arm/mach-omap1/board-sx1.c| 4 ++--
 arch/arm/mach-omap1/{include/mach => }/board-sx1.h | 0
 arch/arm/mach-omap1/{include/mach => }/camera.h| 0
 arch/arm/mach-omap1/devices.c  | 2 +-
 arch/arm/mach-omap1/flash.c| 2 +-
 arch/arm/mach-omap1/{include/mach => }/flash.h | 0
 17 files changed, 15 insertions(+), 15 deletions(-)
 rename arch/arm/mach-omap1/{include/mach => }/board-sx1.h (100%)
 rename arch/arm/mach-omap1/{include/mach => }/camera.h (100%)
 rename arch/arm/mach-omap1/{include/mach => }/flash.h (100%)

diff --git a/arch/arm/mach-omap1/board-ams-delta.c 
b/arch/arm/mach-omap1/board-ams-delta.c
index a95499ea8706..9fc70978823b 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -41,7 +41,7 @@
 
 #include 
 #include 
-#include 
+#include "camera.h"
 #include 
 
 #include "iomap.h"
diff --git a/arch/arm/mach-omap1/board-fsample.c 
b/arch/arm/mach-omap1/board-fsample.c
index 0fb51d22c8b5..fad95b74bb65 100644
--- a/arch/arm/mach-omap1/board-fsample.c
+++ b/arch/arm/mach-omap1/board-fsample.c
@@ -29,7 +29,7 @@
 
 #include 
 #include 
-#include 
+#include "flash.h"
 #include 
 
 #include 
diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c
index 8340d684d8b6..cd146ed0538d 100644
--- a/arch/arm/mach-omap1/board-h2.c
+++ b/arch/arm/mach-omap1/board-h2.c
@@ -42,7 +42,7 @@
 #include 
 #include 
 #include 
-#include 
+#include "flash.h"
 
 #include 
 #include 
diff --git a/arch/arm/mach-omap1/board-h3.c b/arch/arm/mach-omap1/board-h3.c
index 086ff34e072b..f7c8c63dd532 100644
--- a/arch/arm/mach-omap1/board-h3.c
+++ b/arch/arm/mach-omap1/board-h3.c
@@ -44,7 +44,7 @@
 #include 
 #include 
 #include 
-#include 
+#include "flash.h"
 
 #include 
 #include 
diff --git a/arch/arm/mach-omap1/board-innovator.c 
b/arch/arm/mach-omap1/board-innovator.c
index ed4e045c2ad8..ae90bd02b3bf 100644
--- a/arch/arm/mach-omap1/board-innovator.c
+++ b/arch/arm/mach-omap1/board-innovator.c
@@ -32,7 +32,7 @@
 #include 
 
 #include 
-#include 
+#include "flash.h"
 #include 
 #include 
 
diff --git a/arch/arm/mach-omap1/board-osk.c b/arch/arm/mach-omap1/board-osk.c
index 0efd165b8227..209aecb0df68 100644
--- a/arch/arm/mach-omap1/board-osk.c
+++ b/arch/arm/mach-omap1/board-osk.c
@@ -46,7 +46,7 @@
 #include 
 #include 
 
-#include 
+#include "flash.h"
 #include 
 #include 
 
diff --git a/arch/arm/mach-omap1/board-palmte.c 
b/arch/arm/mach-omap1/board-palmte.c
index 1142ae431fe0..e5288cda1a6a 100644
--- a/arch/arm/mach-omap1/board-palmte.c
+++ b/arch/arm/mach-omap1/board-palmte.c
@@ -34,7 +34,7 @@
 #include 
 #include 
 
-#include 
+#include "flash.h"
 #include 
 #include 
 #include 
diff --git a/arch/arm/mach-omap1/board-palmtt.c 
b/arch/arm/mach-omap1/board-palmtt.c
index 54a547a96950..d672495f7441 100644
--- a/arch/arm/mach-omap1/board-palmtt.c
+++ b/arch/arm/mach-omap1/board-palmtt.c
@@ -34,7 +34,7 @@
 #include 
 #include 
 
-#include 
+#include "flash.h"
 #include 
 #include 
 #include 
diff --git a/arch/arm/mach-omap1/board-palmz71.c 
b/arch/arm/mach-omap1/board-palmz71.c
index 87ec04ae40dd..aaf741b0aff6 100644
--- a/arch/arm/mach-omap1/board-palmz71.c
+++ b/arch/arm/mach-omap1/board-palmz71.c
@@ -36,7 +36,7 @@
 #include 
 #include 
 
-#include 
+#include "flash.h"
 #include 
 #include 
 #include 
diff --git a/arch/arm/mach-omap1/board-perseus2.c 
b/arch/arm/mach-omap1/board-perseus2.c
index 3d76f05407f0..150b57ba42bf 100644
--- a/arch/arm/mach-omap1/board-perseus2.c
+++ b/arch/arm/mach-omap1/board-perseus2.c
@@ -30,7 +30,7 @@
 
 #include 
 #include 
-#include 
+#include "flash.h"
 
 #include 
 
diff --git a/arch/arm/mach-omap1/board-sx1-mmc.c 
b/arch/arm/mach-omap1/board-sx1-mmc.c
index 4fcf19c78a08..a9373570bbb1 100644
--- a/arch/arm/mach-omap1/board-sx1-mmc.c
+++ b/arch/arm/mach-omap1/board-sx1-mmc.c
@@ -16,7 +16,7 @@
 #include 
 
 #include 
-#include 
+#include "board-sx1.h"
 
 #include "mmc.h"
 
diff --git a/arch/arm/mach-omap1/board-sx1.c b/arch/arm/mach-omap1/board-sx1.c
index 939991ea33d5..6c482254b37c 100644
--- 

[PATCH 6/7] ARM: mvebu: remove unused mach/gpio.h

[Arnd Bergmann]

This file was left over from a cleanup of asm/gpio.h and has
not been used in a while. Let's just remove it now, so the
arch/arm/mach-mvebu/include/ directory can also disappear.

Signed-off-by: Arnd Bergmann 
---
 arch/arm/mach-mvebu/include/mach/gpio.h | 1 -
 1 file changed, 1 deletion(-)
 delete mode 100644 arch/arm/mach-mvebu/include/mach/gpio.h

diff --git a/arch/arm/mach-mvebu/include/mach/gpio.h 
b/arch/arm/mach-mvebu/include/mach/gpio.h
deleted file mode 100644
index 40a8c178f10d..
--- a/arch/arm/mach-mvebu/include/mach/gpio.h
+++ /dev/null
@@ -1 +0,0 @@
-/* empty */
-- 
2.1.0.rc2

--
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 5/7] ARM: w90x900: make headers more local

[Arnd Bergmann]

Some header files are never included outside of a mach-w90x900
directory and do not need to be made visible in include/mach,
so let's just move them all down one level.

Signed-off-by: Arnd Bergmann 
---
 arch/arm/mach-w90x900/cpu.c   | 4 ++--
 arch/arm/mach-w90x900/{include/mach => }/regs-ebi.h   | 0
 arch/arm/mach-w90x900/{include/mach => }/regs-gcr.h   | 0
 arch/arm/mach-w90x900/{include/mach => }/regs-timer.h | 0
 arch/arm/mach-w90x900/{include/mach => }/regs-usb.h   | 0
 arch/arm/mach-w90x900/time.c  | 2 +-
 6 files changed, 3 insertions(+), 3 deletions(-)
 rename arch/arm/mach-w90x900/{include/mach => }/regs-ebi.h (100%)
 rename arch/arm/mach-w90x900/{include/mach => }/regs-gcr.h (100%)
 rename arch/arm/mach-w90x900/{include/mach => }/regs-timer.h (100%)
 rename arch/arm/mach-w90x900/{include/mach => }/regs-usb.h (100%)

diff --git a/arch/arm/mach-w90x900/cpu.c b/arch/arm/mach-w90x900/cpu.c
index 213230ee57d1..ca763251ffe0 100644
--- a/arch/arm/mach-w90x900/cpu.c
+++ b/arch/arm/mach-w90x900/cpu.c
@@ -33,8 +33,8 @@
 #include 
 #include 
 #include 
-#include 
-#include 
+#include "regs-ebi.h"
+#include "regs-timer.h"
 
 #include "cpu.h"
 #include "clock.h"
diff --git a/arch/arm/mach-w90x900/include/mach/regs-ebi.h 
b/arch/arm/mach-w90x900/regs-ebi.h
similarity index 100%
rename from arch/arm/mach-w90x900/include/mach/regs-ebi.h
rename to arch/arm/mach-w90x900/regs-ebi.h
diff --git a/arch/arm/mach-w90x900/include/mach/regs-gcr.h 
b/arch/arm/mach-w90x900/regs-gcr.h
similarity index 100%
rename from arch/arm/mach-w90x900/include/mach/regs-gcr.h
rename to arch/arm/mach-w90x900/regs-gcr.h
diff --git a/arch/arm/mach-w90x900/include/mach/regs-timer.h 
b/arch/arm/mach-w90x900/regs-timer.h
similarity index 100%
rename from arch/arm/mach-w90x900/include/mach/regs-timer.h
rename to arch/arm/mach-w90x900/regs-timer.h
diff --git a/arch/arm/mach-w90x900/include/mach/regs-usb.h 
b/arch/arm/mach-w90x900/regs-usb.h
similarity index 100%
rename from arch/arm/mach-w90x900/include/mach/regs-usb.h
rename to arch/arm/mach-w90x900/regs-usb.h
diff --git a/arch/arm/mach-w90x900/time.c b/arch/arm/mach-w90x900/time.c
index cd1966ec9143..cda085245e34 100644
--- a/arch/arm/mach-w90x900/time.c
+++ b/arch/arm/mach-w90x900/time.c
@@ -31,7 +31,7 @@
 #include 
 
 #include 
-#include 
+#include "regs-timer.h"
 
 #include "nuc9xx.h"
 
-- 
2.1.0.rc2

--
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/7] ARM: ks8695: make headers more local

[Arnd Bergmann]

Some header files are never included outside of a mach-ks8695
directory and do not need to be made visible in include/mach,
so let's just move them all down one level.

Signed-off-by: Arnd Bergmann 
---
 arch/arm/mach-ks8695/board-acs5k.c  | 2 +-
 arch/arm/mach-ks8695/board-dsm320.c | 2 +-
 arch/arm/mach-ks8695/board-micrel.c | 2 +-
 arch/arm/mach-ks8695/board-og.c | 2 +-
 arch/arm/mach-ks8695/board-sg.c | 2 +-
 arch/arm/mach-ks8695/cpu.c  | 2 +-
 arch/arm/mach-ks8695/devices.c  | 6 +++---
 arch/arm/mach-ks8695/{include/mach => }/devices.h   | 0
 arch/arm/mach-ks8695/pci.c  | 4 ++--
 arch/arm/mach-ks8695/{include/mach => }/regs-hpna.h | 0
 arch/arm/mach-ks8695/{include/mach => }/regs-lan.h  | 0
 arch/arm/mach-ks8695/{include/mach => }/regs-mem.h  | 0
 arch/arm/mach-ks8695/{include/mach => }/regs-pci.h  | 0
 arch/arm/mach-ks8695/{include/mach => }/regs-sys.h  | 0
 arch/arm/mach-ks8695/{include/mach => }/regs-wan.h  | 0
 15 files changed, 11 insertions(+), 11 deletions(-)
 rename arch/arm/mach-ks8695/{include/mach => }/devices.h (100%)
 rename arch/arm/mach-ks8695/{include/mach => }/regs-hpna.h (100%)
 rename arch/arm/mach-ks8695/{include/mach => }/regs-lan.h (100%)
 rename arch/arm/mach-ks8695/{include/mach => }/regs-mem.h (100%)
 rename arch/arm/mach-ks8695/{include/mach => }/regs-pci.h (100%)
 rename arch/arm/mach-ks8695/{include/mach => }/regs-sys.h (100%)
 rename arch/arm/mach-ks8695/{include/mach => }/regs-wan.h (100%)

diff --git a/arch/arm/mach-ks8695/board-acs5k.c 
b/arch/arm/mach-ks8695/board-acs5k.c
index 9f9c0441a917..e4d709c8ed32 100644
--- a/arch/arm/mach-ks8695/board-acs5k.c
+++ b/arch/arm/mach-ks8695/board-acs5k.c
@@ -33,7 +33,7 @@
 #include 
 #include 
 
-#include 
+#include "devices.h"
 #include 
 
 #include "generic.h"
diff --git a/arch/arm/mach-ks8695/board-dsm320.c 
b/arch/arm/mach-ks8695/board-dsm320.c
index d37c218c3584..13537e9c5485 100644
--- a/arch/arm/mach-ks8695/board-dsm320.c
+++ b/arch/arm/mach-ks8695/board-dsm320.c
@@ -28,7 +28,7 @@
 #include 
 #include 
 
-#include 
+#include "devices.h"
 #include 
 
 #include "generic.h"
diff --git a/arch/arm/mach-ks8695/board-micrel.c 
b/arch/arm/mach-ks8695/board-micrel.c
index 3acbdfd31391..69cfb9935fc1 100644
--- a/arch/arm/mach-ks8695/board-micrel.c
+++ b/arch/arm/mach-ks8695/board-micrel.c
@@ -19,7 +19,7 @@
 #include 
 
 #include 
-#include 
+#include "devices.h"
 
 #include "generic.h"
 
diff --git a/arch/arm/mach-ks8695/board-og.c b/arch/arm/mach-ks8695/board-og.c
index f2658168eeff..1f4f2f4f25bb 100644
--- a/arch/arm/mach-ks8695/board-og.c
+++ b/arch/arm/mach-ks8695/board-og.c
@@ -18,7 +18,7 @@
 #include 
 #include 
 #include 
-#include 
+#include "devices.h"
 #include 
 #include 
 #include "generic.h"
diff --git a/arch/arm/mach-ks8695/board-sg.c b/arch/arm/mach-ks8695/board-sg.c
index fdf2352d2cf8..46e455c3821b 100644
--- a/arch/arm/mach-ks8695/board-sg.c
+++ b/arch/arm/mach-ks8695/board-sg.c
@@ -16,7 +16,7 @@
 #include 
 #include 
 #include 
-#include 
+#include "devices.h"
 #include "generic.h"
 
 /*
diff --git a/arch/arm/mach-ks8695/cpu.c b/arch/arm/mach-ks8695/cpu.c
index ddb24222918e..474a050da85b 100644
--- a/arch/arm/mach-ks8695/cpu.c
+++ b/arch/arm/mach-ks8695/cpu.c
@@ -30,7 +30,7 @@
 #include 
 #include 
 
-#include 
+#include "regs-sys.h"
 #include 
 
 
diff --git a/arch/arm/mach-ks8695/devices.c b/arch/arm/mach-ks8695/devices.c
index 47399bc3c024..61cf20beb45f 100644
--- a/arch/arm/mach-ks8695/devices.c
+++ b/arch/arm/mach-ks8695/devices.c
@@ -24,9 +24,9 @@
 #include 
 
 #include 
-#include 
-#include 
-#include 
+#include "regs-wan.h"
+#include "regs-lan.h"
+#include "regs-hpna.h"
 #include 
 #include 
 
diff --git a/arch/arm/mach-ks8695/include/mach/devices.h 
b/arch/arm/mach-ks8695/devices.h
similarity index 100%
rename from arch/arm/mach-ks8695/include/mach/devices.h
rename to arch/arm/mach-ks8695/devices.h
diff --git a/arch/arm/mach-ks8695/pci.c b/arch/arm/mach-ks8695/pci.c
index c1bc4c3716ed..577a35f75c8a 100644
--- a/arch/arm/mach-ks8695/pci.c
+++ b/arch/arm/mach-ks8695/pci.c
@@ -33,8 +33,8 @@
 #include 
 #include 
 
-#include 
-#include 
+#include "devices.h"
+#include "regs-pci.h"
 
 
 static int pci_dbg;
diff --git a/arch/arm/mach-ks8695/include/mach/regs-hpna.h 
b/arch/arm/mach-ks8695/regs-hpna.h
similarity index 100%
rename from arch/arm/mach-ks8695/include/mach/regs-hpna.h
rename to arch/arm/mach-ks8695/regs-hpna.h
diff --git a/arch/arm/mach-ks8695/include/mach/regs-lan.h 
b/arch/arm/mach-ks8695/regs-lan.h
similarity index 100%
rename from arch/arm/mach-ks8695/include/mach/regs-lan.h
rename to arch/arm/mach-ks8695/regs-lan.h
diff --git a/arch/arm/mach-ks8695/include/mach/regs-mem.h 
b/arch/arm/mach-ks8695/regs-mem.h
similarity index 100%
rename from arch/arm/mach-ks8695/include/mach/regs-mem.h
rename to arch/arm/mach-ks8695/regs-mem.h
diff 

[PATCH 0/7] ARM: make mach/*.h headers more local

[Arnd Bergmann]

I've already posted the mach-pxa cleanup along the same lines,
here is another bunch of patches. I'd like to put them into
the next/multiplatform branch in arm-soc.

They come from an old script of mine to look for headers that
are not used by drivers, and I've done thousands of randconfig
builds with them applied, so I'm rather sure that they are all
harmless.

Arnd Bergmann (7):
  ARM: omap1: make headers more local
  ARM: ks8695: make headers more local
  ARM: davinci: make headers more local
  ARM: iop13xx: make headers more local
  ARM: w90x900: make headers more local
  ARM: mvebu: remove unused mach/gpio.h
  ARM: netx: remove unused mach/param.h

 arch/arm/mach-davinci/board-da830-evm.c|  2 +-
 arch/arm/mach-davinci/board-da850-evm.c|  4 +-
 arch/arm/mach-davinci/board-mityomapl138.c |  2 +-
 arch/arm/mach-davinci/board-omapl138-hawk.c|  2 +-
 arch/arm/mach-davinci/clock.c  |  2 +-
 arch/arm/mach-davinci/cp_intc.c|  2 +-
 arch/arm/mach-davinci/{include/mach => }/cp_intc.h |  0
 arch/arm/mach-davinci/cpuidle.c|  4 +-
 arch/arm/mach-davinci/{include/mach => }/cpuidle.h |  0
 arch/arm/mach-davinci/da830.c  |  2 +-
 arch/arm/mach-davinci/da850.c  |  2 +-
 arch/arm/mach-davinci/da8xx-dt.c   |  2 +-
 arch/arm/mach-davinci/{include/mach => }/ddr2.h|  0
 arch/arm/mach-davinci/devices-da8xx.c  |  4 +-
 arch/arm/mach-davinci/dm355.c  |  2 +-
 arch/arm/mach-davinci/dm365.c  |  2 +-
 arch/arm/mach-davinci/dm644x.c |  2 +-
 arch/arm/mach-davinci/dm646x.c |  2 +-
 arch/arm/mach-davinci/pm.c |  2 +-
 arch/arm/mach-davinci/psc.c|  2 +-
 arch/arm/mach-davinci/{include/mach => }/psc.h |  0
 arch/arm/mach-davinci/sleep.S  |  4 +-
 arch/arm/mach-davinci/sram.c   |  2 +-
 arch/arm/mach-davinci/{include/mach => }/sram.h|  0
 arch/arm/mach-iop13xx/include/mach/pci.h   | 57 -
 arch/arm/mach-iop13xx/iq81340mc.c  |  2 +-
 arch/arm/mach-iop13xx/iq81340sc.c  |  2 +-
 arch/arm/mach-iop13xx/irq.c|  2 +-
 arch/arm/mach-iop13xx/{include/mach => }/msi.h |  0
 arch/arm/mach-iop13xx/pci.c|  2 +-
 arch/arm/mach-iop13xx/pci.h| 58 ++
 arch/arm/mach-ks8695/board-acs5k.c |  2 +-
 arch/arm/mach-ks8695/board-dsm320.c|  2 +-
 arch/arm/mach-ks8695/board-micrel.c|  2 +-
 arch/arm/mach-ks8695/board-og.c|  2 +-
 arch/arm/mach-ks8695/board-sg.c|  2 +-
 arch/arm/mach-ks8695/cpu.c |  2 +-
 arch/arm/mach-ks8695/devices.c |  6 +--
 arch/arm/mach-ks8695/{include/mach => }/devices.h  |  0
 arch/arm/mach-ks8695/pci.c |  4 +-
 .../arm/mach-ks8695/{include/mach => }/regs-hpna.h |  0
 arch/arm/mach-ks8695/{include/mach => }/regs-lan.h |  0
 arch/arm/mach-ks8695/{include/mach => }/regs-mem.h |  0
 arch/arm/mach-ks8695/{include/mach => }/regs-pci.h |  0
 arch/arm/mach-ks8695/{include/mach => }/regs-sys.h |  0
 arch/arm/mach-ks8695/{include/mach => }/regs-wan.h |  0
 arch/arm/mach-mvebu/include/mach/gpio.h|  1 -
 arch/arm/mach-netx/include/mach/param.h| 18 ---
 arch/arm/mach-omap1/board-ams-delta.c  |  2 +-
 arch/arm/mach-omap1/board-fsample.c|  2 +-
 arch/arm/mach-omap1/board-h2.c |  2 +-
 arch/arm/mach-omap1/board-h3.c |  2 +-
 arch/arm/mach-omap1/board-innovator.c  |  2 +-
 arch/arm/mach-omap1/board-osk.c|  2 +-
 arch/arm/mach-omap1/board-palmte.c |  2 +-
 arch/arm/mach-omap1/board-palmtt.c |  2 +-
 arch/arm/mach-omap1/board-palmz71.c|  2 +-
 arch/arm/mach-omap1/board-perseus2.c   |  2 +-
 arch/arm/mach-omap1/board-sx1-mmc.c|  2 +-
 arch/arm/mach-omap1/board-sx1.c|  4 +-
 arch/arm/mach-omap1/{include/mach => }/board-sx1.h |  0
 arch/arm/mach-omap1/{include/mach => }/camera.h|  0
 arch/arm/mach-omap1/devices.c  |  2 +-
 arch/arm/mach-omap1/flash.c|  2 +-
 arch/arm/mach-omap1/{include/mach => }/flash.h |  0
 arch/arm/mach-w90x900/cpu.c|  4 +-
 .../arm/mach-w90x900/{include/mach => }/regs-ebi.h |  0
 .../arm/mach-w90x900/{include/mach => }/regs-gcr.h |  0
 .../mach-w90x900/{include/mach => }/regs-timer.h   |  0
 .../arm/mach-w90x900/{include/mach => }/regs-usb.h |  0
 arch/arm/mach-w90x900/time.c   |  2 +-
 71 files changed, 114 insertions(+), 132 deletions(-)
 rename 

Re: [PATCH 2/7] ARM: ks8695: make headers more local

[Greg Ungerer]

Hi Arnd,

On 01/12/15 09:00, Arnd Bergmann wrote:
> Some header files are never included outside of a mach-ks8695
> directory and do not need to be made visible in include/mach,
> so let's just move them all down one level.
> 
> Signed-off-by: Arnd Bergmann 

Looks good, thanks.

Acked-by: Greg Ungerer 

Regards
Greg



> ---
>  arch/arm/mach-ks8695/board-acs5k.c  | 2 +-
>  arch/arm/mach-ks8695/board-dsm320.c | 2 +-
>  arch/arm/mach-ks8695/board-micrel.c | 2 +-
>  arch/arm/mach-ks8695/board-og.c | 2 +-
>  arch/arm/mach-ks8695/board-sg.c | 2 +-
>  arch/arm/mach-ks8695/cpu.c  | 2 +-
>  arch/arm/mach-ks8695/devices.c  | 6 +++---
>  arch/arm/mach-ks8695/{include/mach => }/devices.h   | 0
>  arch/arm/mach-ks8695/pci.c  | 4 ++--
>  arch/arm/mach-ks8695/{include/mach => }/regs-hpna.h | 0
>  arch/arm/mach-ks8695/{include/mach => }/regs-lan.h  | 0
>  arch/arm/mach-ks8695/{include/mach => }/regs-mem.h  | 0
>  arch/arm/mach-ks8695/{include/mach => }/regs-pci.h  | 0
>  arch/arm/mach-ks8695/{include/mach => }/regs-sys.h  | 0
>  arch/arm/mach-ks8695/{include/mach => }/regs-wan.h  | 0
>  15 files changed, 11 insertions(+), 11 deletions(-)
>  rename arch/arm/mach-ks8695/{include/mach => }/devices.h (100%)
>  rename arch/arm/mach-ks8695/{include/mach => }/regs-hpna.h (100%)
>  rename arch/arm/mach-ks8695/{include/mach => }/regs-lan.h (100%)
>  rename arch/arm/mach-ks8695/{include/mach => }/regs-mem.h (100%)
>  rename arch/arm/mach-ks8695/{include/mach => }/regs-pci.h (100%)
>  rename arch/arm/mach-ks8695/{include/mach => }/regs-sys.h (100%)
>  rename arch/arm/mach-ks8695/{include/mach => }/regs-wan.h (100%)
> 
> diff --git a/arch/arm/mach-ks8695/board-acs5k.c 
> b/arch/arm/mach-ks8695/board-acs5k.c
> index 9f9c0441a917..e4d709c8ed32 100644
> --- a/arch/arm/mach-ks8695/board-acs5k.c
> +++ b/arch/arm/mach-ks8695/board-acs5k.c
> @@ -33,7 +33,7 @@
>  #include 
>  #include 
>  
> -#include 
> +#include "devices.h"
>  #include 
>  
>  #include "generic.h"
> diff --git a/arch/arm/mach-ks8695/board-dsm320.c 
> b/arch/arm/mach-ks8695/board-dsm320.c
> index d37c218c3584..13537e9c5485 100644
> --- a/arch/arm/mach-ks8695/board-dsm320.c
> +++ b/arch/arm/mach-ks8695/board-dsm320.c
> @@ -28,7 +28,7 @@
>  #include 
>  #include 
>  
> -#include 
> +#include "devices.h"
>  #include 
>  
>  #include "generic.h"
> diff --git a/arch/arm/mach-ks8695/board-micrel.c 
> b/arch/arm/mach-ks8695/board-micrel.c
> index 3acbdfd31391..69cfb9935fc1 100644
> --- a/arch/arm/mach-ks8695/board-micrel.c
> +++ b/arch/arm/mach-ks8695/board-micrel.c
> @@ -19,7 +19,7 @@
>  #include 
>  
>  #include 
> -#include 
> +#include "devices.h"
>  
>  #include "generic.h"
>  
> diff --git a/arch/arm/mach-ks8695/board-og.c b/arch/arm/mach-ks8695/board-og.c
> index f2658168eeff..1f4f2f4f25bb 100644
> --- a/arch/arm/mach-ks8695/board-og.c
> +++ b/arch/arm/mach-ks8695/board-og.c
> @@ -18,7 +18,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include "devices.h"
>  #include 
>  #include 
>  #include "generic.h"
> diff --git a/arch/arm/mach-ks8695/board-sg.c b/arch/arm/mach-ks8695/board-sg.c
> index fdf2352d2cf8..46e455c3821b 100644
> --- a/arch/arm/mach-ks8695/board-sg.c
> +++ b/arch/arm/mach-ks8695/board-sg.c
> @@ -16,7 +16,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include "devices.h"
>  #include "generic.h"
>  
>  /*
> diff --git a/arch/arm/mach-ks8695/cpu.c b/arch/arm/mach-ks8695/cpu.c
> index ddb24222918e..474a050da85b 100644
> --- a/arch/arm/mach-ks8695/cpu.c
> +++ b/arch/arm/mach-ks8695/cpu.c
> @@ -30,7 +30,7 @@
>  #include 
>  #include 
>  
> -#include 
> +#include "regs-sys.h"
>  #include 
>  
>  
> diff --git a/arch/arm/mach-ks8695/devices.c b/arch/arm/mach-ks8695/devices.c
> index 47399bc3c024..61cf20beb45f 100644
> --- a/arch/arm/mach-ks8695/devices.c
> +++ b/arch/arm/mach-ks8695/devices.c
> @@ -24,9 +24,9 @@
>  #include 
>  
>  #include 
> -#include 
> -#include 
> -#include 
> +#include "regs-wan.h"
> +#include "regs-lan.h"
> +#include "regs-hpna.h"
>  #include 
>  #include 
>  
> diff --git a/arch/arm/mach-ks8695/include/mach/devices.h 
> b/arch/arm/mach-ks8695/devices.h
> similarity index 100%
> rename from arch/arm/mach-ks8695/include/mach/devices.h
> rename to arch/arm/mach-ks8695/devices.h
> diff --git a/arch/arm/mach-ks8695/pci.c b/arch/arm/mach-ks8695/pci.c
> index c1bc4c3716ed..577a35f75c8a 100644
> --- a/arch/arm/mach-ks8695/pci.c
> +++ b/arch/arm/mach-ks8695/pci.c
> @@ -33,8 +33,8 @@
>  #include 
>  #include 
>  
> -#include 
> -#include 
> +#include "devices.h"
> +#include "regs-pci.h"
>  
>  
>  static int pci_dbg;
> diff --git a/arch/arm/mach-ks8695/include/mach/regs-hpna.h 
> b/arch/arm/mach-ks8695/regs-hpna.h
> similarity index 100%
> rename from arch/arm/mach-ks8695/include/mach/regs-hpna.h
> rename to 

[PATCH] hwmon: (tmp102) Force wait for conversion time for the first valid data

[Nishanth Menon]

TMP102 works based on conversions done periodically. However, as per
the TMP102 data sheet[1] the first conversion is triggered immediately
after we program the configuration register. The temperature data
registers do not reflect proper data until the first conversion is
complete (in our case HZ/4).

The driver currently sets the last_update to be jiffies - HZ, just
after the configuration is complete. When tmp102 driver registers
with the thermal framework, it immediately tries to read the sensor
temperature data. This takes place even before the conversion on the
TMP102 is complete and results in an invalid temperature read.

Depending on the value read, this may cause thermal framework to
assume that a critical temperature event has occurred and attempts to
shutdown the system.

Instead of causing an invalid mid-conversion value to be read
erroneously, we mark the last_update to be in-line with the current
jiffies. This allows the tmp102_update_device function to skip update
until the required conversion time is complete. Further, we ensure to
return -EAGAIN result instead of returning spurious temperature (such
as 0C) values to the caller to prevent any wrong decisions made with
such values.

A simpler alternative approach could be to sleep in the probe for the
duration required, but that will result in latency that is undesirable
that can delay boot sequence un-necessarily.

[1] http://www.ti.com/lit/ds/symlink/tmp102.pdf

Cc: Eduardo Valentin 
Reported-by: Aparna Balasubramanian 
Reported-by: Elvita Lobo 
Reported-by: Yan Liu 
Signed-off-by: Nishanth Menon 
---

Example case (from Beagleboard-x15 using an older kernel revision):
http://pastebin.ubuntu.com/13591711/
Notice the thermal shutdown trigger:
thermal thermal_zone3: critical temperature reached(108 C),shutting down

 drivers/hwmon/tmp102.c | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c
index 65482624ea2c..145f69108f23 100644
--- a/drivers/hwmon/tmp102.c
+++ b/drivers/hwmon/tmp102.c
@@ -50,6 +50,9 @@
 #defineTMP102_TLOW_REG 0x02
 #defineTMP102_THIGH_REG0x03
 
+/* TMP102 range is -55 to 150C -> we use -128 as a default invalid value */
+#define TMP102_NOTREADY-128
+
 struct tmp102 {
struct i2c_client *client;
struct device *hwmon_dev;
@@ -102,6 +105,12 @@ static int tmp102_read_temp(void *dev, int *temp)
 {
struct tmp102 *tmp102 = tmp102_update_device(dev);
 
+   /* Is it too early even to return a conversion? */
+   if (tmp102->temp[0] == TMP102_NOTREADY) {
+   dev_dbg(dev, "%s: Conversion not ready yet..\n", __func__);
+   return -EAGAIN;
+   }
+
*temp = tmp102->temp[0];
 
return 0;
@@ -114,6 +123,10 @@ static ssize_t tmp102_show_temp(struct device *dev,
struct sensor_device_attribute *sda = to_sensor_dev_attr(attr);
struct tmp102 *tmp102 = tmp102_update_device(dev);
 
+   /* Is it too early even to return a read? */
+   if (tmp102->temp[sda->index] == TMP102_NOTREADY)
+   return -EAGAIN;
+
return sprintf(buf, "%d\n", tmp102->temp[sda->index]);
 }
 
@@ -207,7 +220,11 @@ static int tmp102_probe(struct i2c_client *client,
status = -ENODEV;
goto fail_restore_config;
}
-   tmp102->last_update = jiffies - HZ;
+   tmp102->last_update = jiffies;
+   /* Mark that we are not ready with data until conversion is complete */
+   tmp102->temp[0] = TMP102_NOTREADY;
+   tmp102->temp[1] = TMP102_NOTREADY;
+   tmp102->temp[2] = TMP102_NOTREADY;
mutex_init(>lock);
 
hwmon_dev = hwmon_device_register_with_groups(dev, client->name,
-- 
2.6.2.402.g2635c2b

--
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 v2] arm, am335x: add support for the bosch shc board

[Heiko Schocher]

Hello Tony,

Am 30.11.2015 um 22:41 schrieb Tony Lindgren:

* Heiko Schocher  [151117 00:25]:

--- /dev/null
+++ b/arch/arm/boot/dts/am335x-shc.dts
+ {
+   compatible = "ti,tps65217";
+   ti,pmic-shutdown-controller;
+
+   regulators {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   dcdc1_reg: regulator@0 {
+   reg = <0>;
+   regulator-name = "vdds_dpr";
+   regulator-compatible = "dcdc1";
+   regulator-min-microvolt = <130>;
+   regulator-max-microvolt = <145>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+
+   dcdc2_reg: regulator@1 {
+   reg = <1>;
+   /*
+* VDD_MPU voltage limits 0.95V - 1.26V with
+* +/-4% tolerance
+*/
+   regulator-compatible = "dcdc2";
+   regulator-name = "vdd_mpu";
+   regulator-min-microvolt = <925000>;
+   regulator-max-microvolt = <1375000>;
+   regulator-boot-on;
+   regulator-always-on;
+   regulator-ramp-delay = <7>;
+   };
+
+   dcdc3_reg: regulator@2 {
+   reg = <2>;
+   /*
+* VDD_CORE voltage limits 0.95V - 1.1V with
+* +/-4% tolerance
+*/
+   regulator-name = "vdd_core";
+   regulator-compatible = "dcdc3";
+   regulator-min-microvolt = <925000>;
+   regulator-max-microvolt = <1125000>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+
+   ldo1_reg: regulator@3 {
+   reg = <3>;
+   regulator-name = "vio,vrtc,vdds";
+   regulator-compatible = "ldo1";
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <180>;
+   regulator-always-on;
+   };
+
+   ldo2_reg: regulator@4 {
+   reg = <4>;
+   regulator-name = "vdd_3v3aux";
+   regulator-compatible = "ldo2";
+   regulator-min-microvolt = <90>;
+   regulator-max-microvolt = <330>;
+   regulator-always-on;
+   };
+
+   ldo3_reg: regulator@5 {
+   reg = <5>;
+   regulator-name = "vdd_1v8";
+   regulator-compatible = "ldo3";
+   regulator-min-microvolt = <90>;
+   regulator-max-microvolt = <180>;
+   regulator-always-on;
+   };
+
+   ldo4_reg: regulator@6 {
+   reg = <6>;
+   regulator-name = "vdd_3v3a";
+   regulator-compatible = "ldo4";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <330>;
+   regulator-always-on;
+   };
+   };
+};


Applying this into omap-for-v4.5/dt.. But I'm getting concerned about this
"regulator-always-on" stuff and having multiple copies of the same thing.

I think we should have a common am33xx-tps65217.dtsi file that has the
regulators defined at one place and other then include it. And they are
controllable AFAIK..


Hmm... Mark Brown (added to Cc) suggested to move this regulator nodes
into the board DT file and remove such files [1].

bye,
Heiko

[1] https://lkml.org/lkml/2015/10/21/581
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
--
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] usb: musb: core: Fix handling of the phy notifications

[Tony Lindgren]

We currently can't unload omap2430 MUSB platform glue driver module and
this cause issues for fixing the MUSB code further. The reason we can't
remove omap2430 is because it uses the PHY functions and also exports the
omap_musb_mailbox function that some PHY drivers are using.

Let's fix the issue by exporting a more generic musb_mailbox function
from the MUSB core and allow platform glue layers to register phy_callback
function as needed.

And now we can now also get rid of the include/linux/musb-omap.h.

Cc: Bin Liu 
Cc: Felipe Balbi 
Cc: Kishon Vijay Abraham I 
Cc: NeilBrown 
Signed-off-by: Tony Lindgren 

---

Probably best that Felipe merges this patch via the USB tree after
comments if that works for Kishon? I have another two fixes for the
phy-twl4030-usb.c coming after this series but they can be merged
separately and won't conflict with this patch.

---
 drivers/phy/phy-twl4030-usb.c | 32 
 drivers/usb/musb/musb_core.c  | 21 +
 drivers/usb/musb/musb_core.h  |  2 ++
 drivers/usb/musb/omap2430.c   | 27 ++-
 drivers/usb/phy/phy-twl6030-usb.c | 30 +++---
 include/linux/usb/musb-omap.h | 30 --
 include/linux/usb/musb.h  | 15 +++
 7 files changed, 83 insertions(+), 74 deletions(-)
 delete mode 100644 include/linux/usb/musb-omap.h

diff --git a/drivers/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c
index 3a707dd..4a3fc6e 100644
--- a/drivers/phy/phy-twl4030-usb.c
+++ b/drivers/phy/phy-twl4030-usb.c
@@ -34,7 +34,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -148,10 +148,10 @@
  * If VBUS is valid or ID is ground, then we know a
  * cable is present and we need to be runtime-enabled
  */
-static inline bool cable_present(enum omap_musb_vbus_id_status stat)
+static inline bool cable_present(enum musb_vbus_id_status stat)
 {
-   return stat == OMAP_MUSB_VBUS_VALID ||
-   stat == OMAP_MUSB_ID_GROUND;
+   return stat == MUSB_VBUS_VALID ||
+   stat == MUSB_ID_GROUND;
 }
 
 struct twl4030_usb {
@@ -170,7 +170,7 @@ struct twl4030_usb {
enum twl4030_usb_mode   usb_mode;
 
int irq;
-   enum omap_musb_vbus_id_status linkstat;
+   enum musb_vbus_id_status linkstat;
boolvbus_supplied;
 
struct delayed_work id_workaround_work;
@@ -276,11 +276,11 @@ static bool twl4030_is_driving_vbus(struct twl4030_usb 
*twl)
return (ret & (ULPI_OTG_DRVVBUS | ULPI_OTG_CHRGVBUS)) ? true : false;
 }
 
-static enum omap_musb_vbus_id_status
+static enum musb_vbus_id_status
twl4030_usb_linkstat(struct twl4030_usb *twl)
 {
int status;
-   enum omap_musb_vbus_id_status linkstat = OMAP_MUSB_UNKNOWN;
+   enum musb_vbus_id_status linkstat = MUSB_UNKNOWN;
 
twl->vbus_supplied = false;
 
@@ -306,14 +306,14 @@ static enum omap_musb_vbus_id_status
}
 
if (status & BIT(2))
-   linkstat = OMAP_MUSB_ID_GROUND;
+   linkstat = MUSB_ID_GROUND;
else if (status & BIT(7))
-   linkstat = OMAP_MUSB_VBUS_VALID;
+   linkstat = MUSB_VBUS_VALID;
else
-   linkstat = OMAP_MUSB_VBUS_OFF;
+   linkstat = MUSB_VBUS_OFF;
} else {
-   if (twl->linkstat != OMAP_MUSB_UNKNOWN)
-   linkstat = OMAP_MUSB_VBUS_OFF;
+   if (twl->linkstat != MUSB_UNKNOWN)
+   linkstat = MUSB_VBUS_OFF;
}
 
dev_dbg(twl->dev, "HW_CONDITIONS 0x%02x/%d; link %d\n",
@@ -535,7 +535,7 @@ static DEVICE_ATTR(vbus, 0444, twl4030_usb_vbus_show, NULL);
 static irqreturn_t twl4030_usb_irq(int irq, void *_twl)
 {
struct twl4030_usb *twl = _twl;
-   enum omap_musb_vbus_id_status status;
+   enum musb_vbus_id_status status;
bool status_changed = false;
 
status = twl4030_usb_linkstat(twl);
@@ -567,11 +567,11 @@ static irqreturn_t twl4030_usb_irq(int irq, void *_twl)
pm_runtime_mark_last_busy(twl->dev);
pm_runtime_put_autosuspend(twl->dev);
}
-   omap_musb_mailbox(status);
+   musb_mailbox(status);
}
 
/* don't schedule during sleep - irq works right then */
-   if (status == OMAP_MUSB_ID_GROUND && pm_runtime_active(twl->dev)) {
+   if (status == MUSB_ID_GROUND && pm_runtime_active(twl->dev)) {
cancel_delayed_work(>id_workaround_work);
schedule_delayed_work(>id_workaround_work, HZ);
}
@@ -670,7 +670,7 @@ static int twl4030_usb_probe(struct platform_device *pdev)
twl->dev= >dev;

[PATCH 0/2] Fix rmmod for musb omap2430 glue layer

[Tony Lindgren]

Hi,

Here are two patches to fix rmmod for musb omap2430. This makes any
further work on this driver a bit easier.

Regards,

Tony


Tony Lindgren (2):
  usb: musb: core: Fix handling of the phy notifications
  usb: musb: Fix unbalanced pm_runtime_enable

 drivers/phy/phy-twl4030-usb.c | 32 
 drivers/usb/musb/musb_core.c  | 21 +
 drivers/usb/musb/musb_core.h  |  2 ++
 drivers/usb/musb/omap2430.c   | 30 +-
 drivers/usb/phy/phy-twl6030-usb.c | 30 +++---
 include/linux/usb/musb-omap.h | 30 --
 include/linux/usb/musb.h  | 15 +++
 7 files changed, 86 insertions(+), 74 deletions(-)
 delete mode 100644 include/linux/usb/musb-omap.h

-- 
2.6.2

--
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] usb: musb: Fix unbalanced pm_runtime_enable

[Tony Lindgren]

When reloading omap2430 kernel module we get a warning about
unbalanced pm_runtime_enable. Let's fix this. Note that we
need to do this after the child musb-core platform_device is
removed because of pm_runtime_irq_safe being set at the child.

Cc: Bin Liu 
Cc: Felipe Balbi 
Cc: Kishon Vijay Abraham I 
Cc: NeilBrown 
Signed-off-by: Tony Lindgren 
---
 drivers/usb/musb/omap2430.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index bf05f80..c84e0322 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -664,8 +664,11 @@ static int omap2430_remove(struct platform_device *pdev)
 {
struct omap2430_glue*glue = platform_get_drvdata(pdev);
 
+   pm_runtime_get_sync(glue->dev);
cancel_work_sync(>omap_musb_mailbox_work);
platform_device_unregister(glue->musb);
+   pm_runtime_put_sync(glue->dev);
+   pm_runtime_disable(glue->dev);
 
return 0;
 }
-- 
2.6.2

--
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] hwmon: (tmp102) Force wait for conversion time for the first valid data

[Guenter Roeck]

On 11/30/2015 08:25 PM, Nishanth Menon wrote:

TMP102 works based on conversions done periodically. However, as per
the TMP102 data sheet[1] the first conversion is triggered immediately
after we program the configuration register. The temperature data
registers do not reflect proper data until the first conversion is
complete (in our case HZ/4).

The driver currently sets the last_update to be jiffies - HZ, just
after the configuration is complete. When tmp102 driver registers
with the thermal framework, it immediately tries to read the sensor
temperature data. This takes place even before the conversion on the
TMP102 is complete and results in an invalid temperature read.

Depending on the value read, this may cause thermal framework to
assume that a critical temperature event has occurred and attempts to
shutdown the system.

Instead of causing an invalid mid-conversion value to be read
erroneously, we mark the last_update to be in-line with the current
jiffies. This allows the tmp102_update_device function to skip update
until the required conversion time is complete. Further, we ensure to
return -EAGAIN result instead of returning spurious temperature (such
as 0C) values to the caller to prevent any wrong decisions made with
such values.

A simpler alternative approach could be to sleep in the probe for the
duration required, but that will result in latency that is undesirable
that can delay boot sequence un-necessarily.


A really simpler solution would be to mark when the device is ready
to be accessed in the probe function, and go to sleep for the remaining time
in the update function if necessary. This would not affect the probe function,
avoid the somewhat awkward -EAGAIN, avoid overloading the value cache, and only
sleep if necessary and as long as needed.


[1] http://www.ti.com/lit/ds/symlink/tmp102.pdf

Cc: Eduardo Valentin 
Reported-by: Aparna Balasubramanian 
Reported-by: Elvita Lobo 
Reported-by: Yan Liu 
Signed-off-by: Nishanth Menon 
---

Example case (from Beagleboard-x15 using an older kernel revision):
http://pastebin.ubuntu.com/13591711/
Notice the thermal shutdown trigger:
thermal thermal_zone3: critical temperature reached(108 C),shutting down

  drivers/hwmon/tmp102.c | 19 ++-
  1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c
index 65482624ea2c..145f69108f23 100644
--- a/drivers/hwmon/tmp102.c
+++ b/drivers/hwmon/tmp102.c
@@ -50,6 +50,9 @@
  #define   TMP102_TLOW_REG 0x02
  #define   TMP102_THIGH_REG0x03

+/* TMP102 range is -55 to 150C -> we use -128 as a default invalid value */
+#define TMP102_NOTREADY-128
+


This is a bit misleading, and also not correct, since the temperature is stored 
in
milli-degrees C, so a value of -128 reflects -0.128 degreees C. While that value
will not be seen in practice, it is still not a good idea to use it for this 
purpose.

Even though the chip temperature range is -55 .. 150 C, that doesn't mean
it never returns a value outside that range, for example if nothing is connected
to an external sensor or if something is broken.

You should use a value outside the value range, ie outside
[-128,000 .. 127,999 ] to detect the "not ready" condition.


  struct tmp102 {
struct i2c_client *client;
struct device *hwmon_dev;
@@ -102,6 +105,12 @@ static int tmp102_read_temp(void *dev, int *temp)
  {
struct tmp102 *tmp102 = tmp102_update_device(dev);

+   /* Is it too early even to return a conversion? */
+   if (tmp102->temp[0] == TMP102_NOTREADY) {
+   dev_dbg(dev, "%s: Conversion not ready yet..\n", __func__);
+   return -EAGAIN;


Does this cause a hard loop in the calling code, or will the thermal code
delay before it reads again ?

If it causes a hard loop, it may be better to go to sleep if needed
when reading the data, as suggested above.


+   }
+
*temp = tmp102->temp[0];

return 0;
@@ -114,6 +123,10 @@ static ssize_t tmp102_show_temp(struct device *dev,
struct sensor_device_attribute *sda = to_sensor_dev_attr(attr);
struct tmp102 *tmp102 = tmp102_update_device(dev);

+   /* Is it too early even to return a read? */
+   if (tmp102->temp[sda->index] == TMP102_NOTREADY)
+   return -EAGAIN;
+
return sprintf(buf, "%d\n", tmp102->temp[sda->index]);
  }

@@ -207,7 +220,11 @@ static int tmp102_probe(struct i2c_client *client,
status = -ENODEV;
goto fail_restore_config;
}
-   tmp102->last_update = jiffies - HZ;
+   tmp102->last_update = jiffies;
+   /* Mark that we are not ready with data until conversion is complete */
+   tmp102->temp[0] = TMP102_NOTREADY;
+   tmp102->temp[1] = TMP102_NOTREADY;
+   tmp102->temp[2] = TMP102_NOTREADY;
 

[PATCH 2/2] phy: twl4030-usb: Fix unbalanced pm_runtime_enable on module reload

[Tony Lindgren]

If we reload phy-twl4030-usb, we get a warning about unbalanced
pm_runtime_enable. Let's fix the issue and also fix idling of the
device on unload before we attempt to shut it down.

If we don't properly idle the PHY before shutting it down on removal,
the twl4030 ends up consuming about 62mW of extra power compared to
running idle with the module loaded.

Cc: Bin Liu 
Cc: Felipe Balbi 
Cc: Kishon Vijay Abraham I 
Cc: NeilBrown 
Signed-off-by: Tony Lindgren 
---
 drivers/phy/phy-twl4030-usb.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c
index 79870c4..f96065a 100644
--- a/drivers/phy/phy-twl4030-usb.c
+++ b/drivers/phy/phy-twl4030-usb.c
@@ -715,6 +715,7 @@ static int twl4030_usb_probe(struct platform_device *pdev)
pm_runtime_use_autosuspend(>dev);
pm_runtime_set_autosuspend_delay(>dev, 2000);
pm_runtime_enable(>dev);
+   pm_runtime_get_sync(>dev);
 
/* Our job is to use irqs and status from the power module
 * to keep the transceiver disabled when nothing's connected.
@@ -758,6 +759,13 @@ static int twl4030_usb_remove(struct platform_device *pdev)
/* set transceiver mode to power on defaults */
twl4030_usb_set_mode(twl, -1);
 
+   /* idle ulpi before powering off */
+   if (cable_present(twl->linkstat))
+   pm_runtime_put_noidle(twl->dev);
+   pm_runtime_mark_last_busy(twl->dev);
+   pm_runtime_put_sync_suspend(twl->dev);
+   pm_runtime_disable(twl->dev);
+
/* autogate 60MHz ULPI clock,
 * clear dpll clock request for i2c access,
 * disable 32KHz
@@ -772,11 +780,6 @@ static int twl4030_usb_remove(struct platform_device *pdev)
/* disable complete OTG block */
twl4030_usb_clear_bits(twl, POWER_CTRL, POWER_CTRL_OTG_ENAB);
 
-   if (cable_present(twl->linkstat))
-   pm_runtime_put_noidle(twl->dev);
-   pm_runtime_mark_last_busy(twl->dev);
-   pm_runtime_put(twl->dev);
-
return 0;
 }
 
-- 
2.6.2

--
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] phy: twl4030-usb: Relase usb phy on unload

[Tony Lindgren]

Otherwise rmmod omap2430; rmmod phy-twl4030-usb; modprobe omap2430
will try to use a non-existing phy and oops:

Unable to handle kernel paging request at virtual address b6f7c1f0
...
[] (devm_usb_get_phy_by_node) from []
(omap2430_musb_init+0x44/0x2b4 [omap2430])
[] (omap2430_musb_init [omap2430]) from []
(musb_init_controller+0x194/0x878 [musb_hdrc])

Cc: Bin Liu 
Cc: Felipe Balbi 
Cc: Kishon Vijay Abraham I 
Cc: NeilBrown 
Signed-off-by: Tony Lindgren 
---
 drivers/phy/phy-twl4030-usb.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c
index 3a707dd..79870c4 100644
--- a/drivers/phy/phy-twl4030-usb.c
+++ b/drivers/phy/phy-twl4030-usb.c
@@ -750,6 +750,7 @@ static int twl4030_usb_remove(struct platform_device *pdev)
struct twl4030_usb *twl = platform_get_drvdata(pdev);
int val;
 
+   usb_remove_phy(>phy);
pm_runtime_get_sync(twl->dev);
cancel_delayed_work(>id_workaround_work);
device_remove_file(twl->dev, _attr_vbus);
-- 
2.6.2

--
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 v4 4/5] ARM: dts: DRA7: add entry for qspi mmap region

[Vignesh R]

On 12/01/2015 04:04 AM, Tony Lindgren wrote:
> * Vignesh R  [151129 21:16]:
>> Add qspi memory mapped region entries for DRA7xx based SoCs. Also,
>> update the binding documents for the controller to document this change.
>>
>> Acked-by: Rob Herring 
>> Signed-off-by: Vignesh R 
> ...
>> --- a/Documentation/devicetree/bindings/spi/ti_qspi.txt
>> +++ b/Documentation/devicetree/bindings/spi/ti_qspi.txt
>> @@ -26,3 +26,17 @@ qspi: qspi@4b30 {
>>  spi-max-frequency = <2500>;
>>  ti,hwmods = "qspi";
>>  };
>> +
>> +For dra7xx:
>> +qspi: qspi@4b30 {
>> +compatible = "ti,dra7xxx-qspi";
>> +reg = <0x4b30 0x100>,
>> +  <0x5c00 0x400>,
>> +  <0x4a002558 0x4>;
>> +reg-names = "qspi_base", "qspi_mmap",
>> +"qspi_ctrlmod";
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +spi-max-frequency = <4800>;
>> +ti,hwmods = "qspi";
>> +};
> 
> Actually none of the IO areas above are within the same interconnect target:
> 
> 0x4b30  QSPI0 address space in L3 main interconnect
> 0x5c00  QSPI1 address space in L3 main interconnect


First address range (configuration port: 0x4b30) corresponds to QSPI
registers space. These registers alone are sufficient for generic SPI
communication (serial flash as well as non-flash SPI devices).

In order to speed up SPI flash reads SFI_MM_IF(SPI memory mapped
interface) is provided by QSPI IP. This _cannot_ be used with non-flash
devices.
The second address range (0x5c00) corresponds to memory-mapped
region of SFI_MM_IF, through which SPI flash memories can be read as if
though they were RAM addresses (i.e using readl/memcpy). The SFI_MM_IF
block that takes care of communicating over SPI bus and getting the data
from flash device.
But SFI_MM_IF block needs to know some flash specific information(such
as read opcode, address bytes, dummy bytes, mode). This information must
first be populated in QSPI_SPI_SETUP*_REG(0x4B300054-60) before
accessing SFI_MM_IF address range via readl.
Both addresses space belong to same instance of the driver, one
corresponds to register space and other is memory-mapped region.
Therefore both regions are claimed by the same driver.

> 0x4a002558  CTRL_CORE_CONTROL_IO_2 in System Control Module (SCM) in L4_CFG
> 
> The first two address spaces should be two separate instances of this driver.

Not actually two instances.

> The CTRL_CORE_CONTROL_IO_2 needs seems like a shared clock register that
> needs to be accessed using the clock framework most likely.
> 

Not shared clock.
The CTRL_CORE_CONTROL_IO_2[10:8] QSPI_MEMMAPPED_CS bit fields provides a
functionality for remapping the previously described address space which
starts at 0x5C00 L3_MAIN address to one of the four supported chip
selects.
How about using syscon to access CTRL_CORE_CONTROL_IO_2?

-- 
Regards
Vignesh
--
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] Two phy-twl4030-usb fixes for unloading the module

[Tony Lindgren]

Hi,

Here are two fixes for rmmod and PM. These can be merged separately after
the review from the MUSB related changes.

Regards,

Tony


Tony Lindgren (2):
  phy: twl4030-usb: Relase usb phy on unload
  phy: twl4030-usb: Fix unbalanced pm_runtime_enable on module reload

 drivers/phy/phy-twl4030-usb.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

-- 
2.6.2

--
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 v2] arm, am335x: add support for the bosch shc board

[Tony Lindgren]

* Heiko Schocher  [151130 21:21]:
> Hello Tony,
> 
> Am 30.11.2015 um 22:41 schrieb Tony Lindgren:
> >* Heiko Schocher  [151117 00:25]:
> >>--- /dev/null
> >>+++ b/arch/arm/boot/dts/am335x-shc.dts
> >>+ {
> >>+   compatible = "ti,tps65217";
> >>+   ti,pmic-shutdown-controller;
> >>+
> >>+   regulators {
> >>+   #address-cells = <1>;
> >>+   #size-cells = <0>;
> >>+
> >>+   dcdc1_reg: regulator@0 {
> >>+   reg = <0>;
> >>+   regulator-name = "vdds_dpr";
> >>+   regulator-compatible = "dcdc1";
> >>+   regulator-min-microvolt = <130>;
> >>+   regulator-max-microvolt = <145>;
> >>+   regulator-boot-on;
> >>+   regulator-always-on;
> >>+   };
> >>+
> >>+   dcdc2_reg: regulator@1 {
> >>+   reg = <1>;
> >>+   /*
> >>+* VDD_MPU voltage limits 0.95V - 1.26V with
> >>+* +/-4% tolerance
> >>+*/
> >>+   regulator-compatible = "dcdc2";
> >>+   regulator-name = "vdd_mpu";
> >>+   regulator-min-microvolt = <925000>;
> >>+   regulator-max-microvolt = <1375000>;
> >>+   regulator-boot-on;
> >>+   regulator-always-on;
> >>+   regulator-ramp-delay = <7>;
> >>+   };
> >>+
> >>+   dcdc3_reg: regulator@2 {
> >>+   reg = <2>;
> >>+   /*
> >>+* VDD_CORE voltage limits 0.95V - 1.1V with
> >>+* +/-4% tolerance
> >>+*/
> >>+   regulator-name = "vdd_core";
> >>+   regulator-compatible = "dcdc3";
> >>+   regulator-min-microvolt = <925000>;
> >>+   regulator-max-microvolt = <1125000>;
> >>+   regulator-boot-on;
> >>+   regulator-always-on;
> >>+   };
> >>+
> >>+   ldo1_reg: regulator@3 {
> >>+   reg = <3>;
> >>+   regulator-name = "vio,vrtc,vdds";
> >>+   regulator-compatible = "ldo1";
> >>+   regulator-min-microvolt = <100>;
> >>+   regulator-max-microvolt = <180>;
> >>+   regulator-always-on;
> >>+   };
> >>+
> >>+   ldo2_reg: regulator@4 {
> >>+   reg = <4>;
> >>+   regulator-name = "vdd_3v3aux";
> >>+   regulator-compatible = "ldo2";
> >>+   regulator-min-microvolt = <90>;
> >>+   regulator-max-microvolt = <330>;
> >>+   regulator-always-on;
> >>+   };
> >>+
> >>+   ldo3_reg: regulator@5 {
> >>+   reg = <5>;
> >>+   regulator-name = "vdd_1v8";
> >>+   regulator-compatible = "ldo3";
> >>+   regulator-min-microvolt = <90>;
> >>+   regulator-max-microvolt = <180>;
> >>+   regulator-always-on;
> >>+   };
> >>+
> >>+   ldo4_reg: regulator@6 {
> >>+   reg = <6>;
> >>+   regulator-name = "vdd_3v3a";
> >>+   regulator-compatible = "ldo4";
> >>+   regulator-min-microvolt = <180>;
> >>+   regulator-max-microvolt = <330>;
> >>+   regulator-always-on;
> >>+   };
> >>+   };
> >>+};
> >
> >Applying this into omap-for-v4.5/dt.. But I'm getting concerned about this
> >"regulator-always-on" stuff and having multiple copies of the same thing.
> >
> >I think we should have a common am33xx-tps65217.dtsi file that has the
> >regulators defined at one place and other then include it. And they are
> >controllable AFAIK..
> 
> Hmm... Mark Brown (added to Cc) suggested to move this regulator nodes
> into the board DT file and remove such files [1].

Hmm it was probably the name of that file causing confusion as it was not
am33xx specific. If we have many board variants using almost the same exact
regulators and configuration it totally makes sense to have a shared dtsi
file for them :)

It may actually be better to have it as am33xx-common.dtsi and I bet that
covers quite a few am33xx boards for the basic shared functionality.

Regards,

Tony


> [1] https://lkml.org/lkml/2015/10/21/581

--
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 v2] arm, am335x: add support for the bosch shc board

[Heiko Schocher]

Hello Tony,

Am 01.12.2015 um 06:53 schrieb Tony Lindgren:

* Heiko Schocher  [151130 21:21]:

Hello Tony,

Am 30.11.2015 um 22:41 schrieb Tony Lindgren:

* Heiko Schocher  [151117 00:25]:

--- /dev/null
+++ b/arch/arm/boot/dts/am335x-shc.dts
+ {
+   compatible = "ti,tps65217";
+   ti,pmic-shutdown-controller;
+
+   regulators {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   dcdc1_reg: regulator@0 {
+   reg = <0>;
+   regulator-name = "vdds_dpr";
+   regulator-compatible = "dcdc1";
+   regulator-min-microvolt = <130>;
+   regulator-max-microvolt = <145>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+
+   dcdc2_reg: regulator@1 {
+   reg = <1>;
+   /*
+* VDD_MPU voltage limits 0.95V - 1.26V with
+* +/-4% tolerance
+*/
+   regulator-compatible = "dcdc2";
+   regulator-name = "vdd_mpu";
+   regulator-min-microvolt = <925000>;
+   regulator-max-microvolt = <1375000>;
+   regulator-boot-on;
+   regulator-always-on;
+   regulator-ramp-delay = <7>;
+   };
+
+   dcdc3_reg: regulator@2 {
+   reg = <2>;
+   /*
+* VDD_CORE voltage limits 0.95V - 1.1V with
+* +/-4% tolerance
+*/
+   regulator-name = "vdd_core";
+   regulator-compatible = "dcdc3";
+   regulator-min-microvolt = <925000>;
+   regulator-max-microvolt = <1125000>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+
+   ldo1_reg: regulator@3 {
+   reg = <3>;
+   regulator-name = "vio,vrtc,vdds";
+   regulator-compatible = "ldo1";
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <180>;
+   regulator-always-on;
+   };
+
+   ldo2_reg: regulator@4 {
+   reg = <4>;
+   regulator-name = "vdd_3v3aux";
+   regulator-compatible = "ldo2";
+   regulator-min-microvolt = <90>;
+   regulator-max-microvolt = <330>;
+   regulator-always-on;
+   };
+
+   ldo3_reg: regulator@5 {
+   reg = <5>;
+   regulator-name = "vdd_1v8";
+   regulator-compatible = "ldo3";
+   regulator-min-microvolt = <90>;
+   regulator-max-microvolt = <180>;
+   regulator-always-on;
+   };
+
+   ldo4_reg: regulator@6 {
+   reg = <6>;
+   regulator-name = "vdd_3v3a";
+   regulator-compatible = "ldo4";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <330>;
+   regulator-always-on;
+   };
+   };
+};


Applying this into omap-for-v4.5/dt.. But I'm getting concerned about this
"regulator-always-on" stuff and having multiple copies of the same thing.

I think we should have a common am33xx-tps65217.dtsi file that has the
regulators defined at one place and other then include it. And they are
controllable AFAIK..


Hmm... Mark Brown (added to Cc) suggested to move this regulator nodes
into the board DT file and remove such files [1].


Hmm it was probably the name of that file causing confusion as it was not
am33xx specific. If we have many board variants using almost the same exact
regulators and configuration it totally makes sense to have a shared dtsi
file for them :)


Ack.


It may actually be better to have it as am33xx-common.dtsi and I bet that
covers quite a few am33xx boards for the basic shared functionality.


I try to find some time to make such a patch...

bye,
Heiko


Regards,

Tony



[1] https://lkml.org/lkml/2015/10/21/581




--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
--
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 v4 2/5] spi: spi-ti-qspi: add mmap mode read support

[Vignesh R]

Hi Felipe,

On 12/01/2015 04:05 AM, Balbi, Felipe wrote:
> 
> Hi,
> 
> Vignesh R  writes:
[...]
>> +}
>> +
>> +static int ti_qspi_spi_flash_read(struct  spi_device *spi,
>> +  struct spi_flash_read_message *msg)
>> +{
>> +struct ti_qspi *qspi = spi_master_get_devdata(spi->master);
>> +int ret = 0;
>> +
>> +mutex_lock(>list_lock);
>> +
>> +if (!qspi->mmap_enabled)
>> +ti_qspi_enable_memory_map(spi);
>> +ti_qspi_setup_mmap_read(spi, msg);
>> +memcpy_fromio(msg->buf, qspi->mmap_base + msg->from, msg->len);
>> +msg->retlen = msg->len;
> 
> the way I have always expected this to work was that spi controller
> would setup the mmap region (using ranges?) and pass the base address to
> the SPI NOR flash instead, so that could call standard
> write[bwl]/read[bwl] functions.
> 
> I mean, when we're dealing with AXI, AHB, PCI, OCP, whatever we
> completely ignore these details, why should SPI be different ? If it's
> memory mapped, the SW view of the thing is a piece of memory and that
> should be accessible with standard {read,write}[bwl]() calls.
> 

This is just an acceleration provided to improve flash read speeds.
Whenever there is an access to QSPI memory map region, there is a
SFI_MM_IF block in QSPI IP that generates SPI bus signals in order fetch
the data from flash. This SFI_MM_IF must first be configured with flash
specific information like read opcode, read mode, dummy bytes etc (which
may vary from flash to flash), by writing to QSPI_SPI_SETUP*_REG also,
SFI_MM_IF needs to be selected by writing to QSPI_SPI_SWITCH_REG.
IMO, there has to be a call from spi-nor to ti-qspi before using
standard {read,write}[bwl]() calls for populating flash info, power mgmt
and locking SPI bus.

> I really think $subject is not a good way forward because it gives too
> much responsibility to the SPI controller driver; note that this driver
> is the one actually accessing the memory map region, instead of simply
> setting it up and passing it along.
> 

How would you propose to setup mmap transfers while taking care of SPI
bus locking and passing of flash info to ti-qspi?


> So the way I see it, the DTS should be like so:
> 
> qspi@XYZ {
>  reg = ;
>  [...]
>  ranges = <0 0 0x3000 $size>;
> 
>  flash@0,0 {
>compatible = "mp2580";
>reg = <0 0 $flash_size>;
>  };
> };
> 
> 
> if you have more than one device sitting on this SPI bus using different
> chip selects, that's easy too, just change your ranges property:
> 
> qspi@XYZ {
>  reg = ;
>  [...]
>  ranges = <0 0 0x3000 0x1000
>1 0 0x30001000 0x1000
>2 0 0x30002000 0x1000>;
> 
>  flash@0,0 {
>  [...]
>  };
> 
>  flash@1,0 {
>[...]
>  };
> 
>  flash@2,0 {
>[...]
>   };
> };
> 

No, even if there are multiple slaves, all slaves map to the same start
address (0x3000 in above example). Based on the chip-select line
that is asserted (selected by writing to a particular CTRL_MODULE
register field), the corresponding slave responds. Different slaves
cannot be mapped to different address ranges inside mmap address space.
The ranges property will always be the same for all slaves and all
chip-selects.

> and so on. From ti-qspi perspective, you should just setup the memory
> map and from mp25p80 you would check if your reg property pointed to an
> address that looks like memory, then ioremap it and use tradicional
> {read,write}[bwl]() accessors. Any reasons why that wasn't done the way
> pointed out above ?
> 

There might be a SPI controller that provides accelerated interface for
SPI flash read not as a memory mapping but some-other way. Brian Norris
has pointed out that there is at least one other controller which
provides such acceleration w/o memory mapping[1] May be Brian can
explain that better?


[1]https://lkml.org/lkml/2015/11/10/618

-- 
Regards
Vignesh
--
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: [4.4-rc][PATCH] ARM: dts: am4372: fix clock source for arm twd and global timers

[Tero Kristo]

On 11/27/2015 09:44 PM, Grygorii Strashko wrote:

ARM TWD and Global timer are clocked by PERIPHCLK which is MPU_CLK/2.
But now they are clocked by dpll_mpu_m2_ck == MPU_CLK and, as result.
Timekeeping core misbehaves. For example, execution of command
"sleep 5" will take 10 sec instead of 5.

Hence, fix it by adding mpu_periphclk ("fixed-factor-clock") and use
it for clocking ARM TWD and Global timer (same way as on OMAP4).

Cc: Tony Lindgren 
Cc: Felipe Balbi 
Cc: Tero Kristo 
Fixes:commit 8cbd4c2f6a99 ("arm: boot: dts: am4372: add ARM timers and SCU 
nodes")
Signed-off-by: Grygorii Strashko 
---
  arch/arm/boot/dts/am4372.dtsi| 4 ++--
  arch/arm/boot/dts/am43xx-clocks.dtsi | 8 
  2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index d83ff9c..de8791a 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -74,7 +74,7 @@
reg = <0x48240200 0x100>;
interrupts = ;
interrupt-parent = <>;
-   clocks = <_mpu_m2_ck>;
+   clocks = <_periphclk>;
};

local_timer: timer@48240600 {
@@ -82,7 +82,7 @@
reg = <0x48240600 0x100>;
interrupts = ;
interrupt-parent = <>;
-   clocks = <_mpu_m2_ck>;
+   clocks = <_periphclk>;
};

l2-cache-controller@48242000 {
diff --git a/arch/arm/boot/dts/am43xx-clocks.dtsi 
b/arch/arm/boot/dts/am43xx-clocks.dtsi
index cc88728..2ff58b1 100644
--- a/arch/arm/boot/dts/am43xx-clocks.dtsi
+++ b/arch/arm/boot/dts/am43xx-clocks.dtsi
@@ -259,6 +259,14 @@
ti,invert-autoidle-bit;
};

+   mpu_periphclk: mpu_periphclk {
+   #clock-cells = <0>;
+   compatible = "fixed-factor-clock";
+   clocks = <_mpu_ck>;


I don't think this is correct, ARM core is fed dpll_mpu_m2_ck, where the 
divisor value can potentially differ from 1. If you feed this clock 
directly from dpll_mpu_ck, you bypass this divisor.


Did you check what is the impact of cpufreq on the ARM TWD/timers?

-Tero


+   clock-mult = <1>;
+   clock-div = <2>;
+   };
+
dpll_ddr_ck: dpll_ddr_ck {
#clock-cells = <0>;
compatible = "ti,am3-dpll-clock";



--
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] clocksource: arm_global_timer: fix suspend resume

[Grygorii Strashko]

On 11/30/2015 02:29 AM, santosh.shilim...@oracle.com wrote:

On 11/27/15 11:47 AM, Grygorii Strashko wrote:

Now the System stall is observed on TI AM437x based board
(am437x-gp-evm) during resuming from System suspend when ARM Global
timer is selected as clocksource device (CPUIdle not enabled) - SysRq
are working,
but nothing else.

The reason of stall is that ARM Global timer loses its contexts during
System suspend:
GT_CONTROL.TIMER_ENABLE = 0 (unbanked)
GT_COUNTERx = 0

Hence, update ARM Global timer driver to reflect above behaviour
- re-enable ARM Global timer on resume GT_CONTROL.TIMER_ENABLE = 1.

CC: Arnd Bergmann 
Cc: John Stultz 
Cc: Felipe Balbi 
Cc: Tony Lindgren 
Cc: Santosh Shilimkar 
Cc: Marc Zyngier 
Signed-off-by: Grygorii Strashko 
---
Changes in v3:
  - dropped all DT specific code
Changes in v2:
  - suspend/resume simplified: nothing is stored any more and
ARM GT just re-enabled
Link on v2:
  https://lkml.org/lkml/2015/11/20/355
Link on v1:
  https://lkml.org/lkml/2015/11/13/456


Looks reasonable to me.

  drivers/clocksource/arm_global_timer.c | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/drivers/clocksource/arm_global_timer.c
b/drivers/clocksource/arm_global_timer.c
index a2cb6fa..10d1417 100644
--- a/drivers/clocksource/arm_global_timer.c
+++ b/drivers/clocksource/arm_global_timer.c
@@ -195,12 +195,19 @@ static cycle_t gt_clocksource_read(struct
clocksource *cs)
  return gt_counter_read();
  }

+static void gt_resume(struct clocksource *cs)
+{
+/* re-enable timer on resume */
+writel(GT_CONTROL_TIMER_ENABLE, gt_base + GT_CONTROL);


Check if its disabled before enabling it.
Other than that,
Reviewed-by: Santosh Shilimkar 


Sure, I'll update.

Thanks.
--
regards,
-grygorii
--
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: [4.4-rc][PATCH] ARM: dts: am4372: fix clock source for arm twd and global timers

[Grygorii Strashko]

On 11/30/2015 10:25 AM, Tero Kristo wrote:

On 11/27/2015 09:44 PM, Grygorii Strashko wrote:

ARM TWD and Global timer are clocked by PERIPHCLK which is MPU_CLK/2.
But now they are clocked by dpll_mpu_m2_ck == MPU_CLK and, as result.
Timekeeping core misbehaves. For example, execution of command
"sleep 5" will take 10 sec instead of 5.

Hence, fix it by adding mpu_periphclk ("fixed-factor-clock") and use
it for clocking ARM TWD and Global timer (same way as on OMAP4).

Cc: Tony Lindgren 
Cc: Felipe Balbi 
Cc: Tero Kristo 
Fixes:commit 8cbd4c2f6a99 ("arm: boot: dts: am4372: add ARM timers and
SCU nodes")
Signed-off-by: Grygorii Strashko 
---
  arch/arm/boot/dts/am4372.dtsi| 4 ++--
  arch/arm/boot/dts/am43xx-clocks.dtsi | 8 
  2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/am4372.dtsi
b/arch/arm/boot/dts/am4372.dtsi
index d83ff9c..de8791a 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -74,7 +74,7 @@
  reg = <0x48240200 0x100>;
  interrupts = ;
  interrupt-parent = <>;
-clocks = <_mpu_m2_ck>;
+clocks = <_periphclk>;
  };

  local_timer: timer@48240600 {
@@ -82,7 +82,7 @@
  reg = <0x48240600 0x100>;
  interrupts = ;
  interrupt-parent = <>;
-clocks = <_mpu_m2_ck>;
+clocks = <_periphclk>;
  };

  l2-cache-controller@48242000 {
diff --git a/arch/arm/boot/dts/am43xx-clocks.dtsi
b/arch/arm/boot/dts/am43xx-clocks.dtsi
index cc88728..2ff58b1 100644
--- a/arch/arm/boot/dts/am43xx-clocks.dtsi
+++ b/arch/arm/boot/dts/am43xx-clocks.dtsi
@@ -259,6 +259,14 @@
  ti,invert-autoidle-bit;
  };

+mpu_periphclk: mpu_periphclk {
+#clock-cells = <0>;
+compatible = "fixed-factor-clock";
+clocks = <_mpu_ck>;


I don't think this is correct, ARM core is fed dpll_mpu_m2_ck, where the
divisor value can potentially differ from 1. If you feed this clock
directly from dpll_mpu_ck, you bypass this divisor.


Sry. My mistake. I'll update it to use dpll_mpu_m2_ck.



Did you check what is the impact of cpufreq on the ARM TWD/timers?


TWD is cpufreq friendly, ARM GT is not.



+clock-mult = <1>;
+clock-div = <2>;
+};
+
  dpll_ddr_ck: dpll_ddr_ck {
  #clock-cells = <0>;
  compatible = "ti,am3-dpll-clock";






--
regards,
-grygorii
--
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 v02 12/15] ARM: davinci: devices-da8xx: Remove DMA resources for MMC and SPI

[Peter Ujfalusi]

The drivers are now converted to not use the DMA resource.

Signed-off-by: Peter Ujfalusi 
---
 arch/arm/mach-davinci/devices-da8xx.c | 49 ---
 1 file changed, 49 deletions(-)

diff --git a/arch/arm/mach-davinci/devices-da8xx.c 
b/arch/arm/mach-davinci/devices-da8xx.c
index 3327cb22e0b5..5d96d8728c58 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -57,15 +57,6 @@
 #define DA8XX_EMAC_RAM_OFFSET  0x
 #define DA8XX_EMAC_CTRL_RAM_SIZE   SZ_8K
 
-#define DA8XX_DMA_SPI0_RX  EDMA_CTLR_CHAN(0, 14)
-#define DA8XX_DMA_SPI0_TX  EDMA_CTLR_CHAN(0, 15)
-#define DA8XX_DMA_MMCSD0_RXEDMA_CTLR_CHAN(0, 16)
-#define DA8XX_DMA_MMCSD0_TXEDMA_CTLR_CHAN(0, 17)
-#define DA8XX_DMA_SPI1_RX  EDMA_CTLR_CHAN(0, 18)
-#define DA8XX_DMA_SPI1_TX  EDMA_CTLR_CHAN(0, 19)
-#define DA850_DMA_MMCSD1_RXEDMA_CTLR_CHAN(1, 28)
-#define DA850_DMA_MMCSD1_TXEDMA_CTLR_CHAN(1, 29)
-
 void __iomem *da8xx_syscfg0_base;
 void __iomem *da8xx_syscfg1_base;
 
@@ -751,16 +742,6 @@ static struct resource da8xx_mmcsd0_resources[] = {
.end= IRQ_DA8XX_MMCSDINT0,
.flags  = IORESOURCE_IRQ,
},
-   {   /* DMA RX */
-   .start  = DA8XX_DMA_MMCSD0_RX,
-   .end= DA8XX_DMA_MMCSD0_RX,
-   .flags  = IORESOURCE_DMA,
-   },
-   {   /* DMA TX */
-   .start  = DA8XX_DMA_MMCSD0_TX,
-   .end= DA8XX_DMA_MMCSD0_TX,
-   .flags  = IORESOURCE_DMA,
-   },
 };
 
 static struct platform_device da8xx_mmcsd0_device = {
@@ -788,16 +769,6 @@ static struct resource da850_mmcsd1_resources[] = {
.end= IRQ_DA850_MMCSDINT0_1,
.flags  = IORESOURCE_IRQ,
},
-   {   /* DMA RX */
-   .start  = DA850_DMA_MMCSD1_RX,
-   .end= DA850_DMA_MMCSD1_RX,
-   .flags  = IORESOURCE_DMA,
-   },
-   {   /* DMA TX */
-   .start  = DA850_DMA_MMCSD1_TX,
-   .end= DA850_DMA_MMCSD1_TX,
-   .flags  = IORESOURCE_DMA,
-   },
 };
 
 static struct platform_device da850_mmcsd1_device = {
@@ -984,16 +955,6 @@ static struct resource da8xx_spi0_resources[] = {
.end= IRQ_DA8XX_SPINT0,
.flags  = IORESOURCE_IRQ,
},
-   [2] = {
-   .start  = DA8XX_DMA_SPI0_RX,
-   .end= DA8XX_DMA_SPI0_RX,
-   .flags  = IORESOURCE_DMA,
-   },
-   [3] = {
-   .start  = DA8XX_DMA_SPI0_TX,
-   .end= DA8XX_DMA_SPI0_TX,
-   .flags  = IORESOURCE_DMA,
-   },
 };
 
 static struct resource da8xx_spi1_resources[] = {
@@ -1007,16 +968,6 @@ static struct resource da8xx_spi1_resources[] = {
.end= IRQ_DA8XX_SPINT1,
.flags  = IORESOURCE_IRQ,
},
-   [2] = {
-   .start  = DA8XX_DMA_SPI1_RX,
-   .end= DA8XX_DMA_SPI1_RX,
-   .flags  = IORESOURCE_DMA,
-   },
-   [3] = {
-   .start  = DA8XX_DMA_SPI1_TX,
-   .end= DA8XX_DMA_SPI1_TX,
-   .flags  = IORESOURCE_DMA,
-   },
 };
 
 static struct davinci_spi_platform_data da8xx_spi_pdata[] = {
-- 
2.6.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

[RFC v02 13/15] ARM: davinci: devices: Remove DMA resources for MMC

[Peter Ujfalusi]

The driver is converted to not use the DMA resource.

Signed-off-by: Peter Ujfalusi 
---
 arch/arm/mach-davinci/devices.c | 19 ---
 1 file changed, 19 deletions(-)

diff --git a/arch/arm/mach-davinci/devices.c b/arch/arm/mach-davinci/devices.c
index 6257aa452568..3ae70f2909b0 100644
--- a/arch/arm/mach-davinci/devices.c
+++ b/arch/arm/mach-davinci/devices.c
@@ -36,9 +36,6 @@
 #define DM365_MMCSD0_BASE   0x01D11000
 #define DM365_MMCSD1_BASE   0x01D0
 
-#define DAVINCI_DMA_MMCRXEVT   26
-#define DAVINCI_DMA_MMCTXEVT   27
-
 void __iomem  *davinci_sysmod_base;
 
 void davinci_map_sysmod(void)
@@ -144,14 +141,6 @@ static struct resource mmcsd0_resources[] = {
.start = IRQ_SDIOINT,
.flags = IORESOURCE_IRQ,
},
-   /* DMA channels: RX, then TX */
-   {
-   .start = EDMA_CTLR_CHAN(0, DAVINCI_DMA_MMCRXEVT),
-   .flags = IORESOURCE_DMA,
-   }, {
-   .start = EDMA_CTLR_CHAN(0, DAVINCI_DMA_MMCTXEVT),
-   .flags = IORESOURCE_DMA,
-   },
 };
 
 static struct platform_device davinci_mmcsd0_device = {
@@ -181,14 +170,6 @@ static struct resource mmcsd1_resources[] = {
.start = IRQ_DM355_SDIOINT1,
.flags = IORESOURCE_IRQ,
},
-   /* DMA channels: RX, then TX */
-   {
-   .start = EDMA_CTLR_CHAN(0, 30), /* rx */
-   .flags = IORESOURCE_DMA,
-   }, {
-   .start = EDMA_CTLR_CHAN(0, 31), /* tx */
-   .flags = IORESOURCE_DMA,
-   },
 };
 
 static struct platform_device davinci_mmcsd1_device = {
-- 
2.6.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

[RFC v02 15/15] ARM: davinci: dm365: Remove DMA resources for SPI

[Peter Ujfalusi]

The driver is converted to not use the DMA resource.

Signed-off-by: Peter Ujfalusi 
---
 arch/arm/mach-davinci/dm365.c | 8 
 1 file changed, 8 deletions(-)

diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 3dfcf7c9aa20..fe98e5f55634 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -660,14 +660,6 @@ static struct resource dm365_spi0_resources[] = {
.start = IRQ_DM365_SPIINT0_0,
.flags = IORESOURCE_IRQ,
},
-   {
-   .start = 17,
-   .flags = IORESOURCE_DMA,
-   },
-   {
-   .start = 16,
-   .flags = IORESOURCE_DMA,
-   },
 };
 
 static struct platform_device dm365_spi0_device = {
-- 
2.6.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

[RFC v02 14/15] ARM: davinci: dm355: Remove DMA resources for SPI

[Peter Ujfalusi]

The driver is converted to not use the DMA resource.

Signed-off-by: Peter Ujfalusi 
---
 arch/arm/mach-davinci/dm355.c | 8 
 1 file changed, 8 deletions(-)

diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index dc8d7ccf69f4..7c6ab2d16e3e 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -397,14 +397,6 @@ static struct resource dm355_spi0_resources[] = {
.start = IRQ_DM355_SPINT0_0,
.flags = IORESOURCE_IRQ,
},
-   {
-   .start = 17,
-   .flags = IORESOURCE_DMA,
-   },
-   {
-   .start = 16,
-   .flags = IORESOURCE_DMA,
-   },
 };
 
 static struct davinci_spi_platform_data dm355_spi0_pdata = {
-- 
2.6.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

[RFC v02 11/15] spi: davinci: Use dma_request_chan() to requesting DMA channel

[Peter Ujfalusi]

With the new dma_request_chan() the clinet driver does not need to look for
the DMA resource and it does not need to pass filter_fn anymore.
By switching to the new API the davinci_mmc driver can now support deferred
probing against DMA.

Signed-off-by: Peter Ujfalusi 
---
 drivers/spi/spi-davinci.c | 76 +++
 1 file changed, 24 insertions(+), 52 deletions(-)

diff --git a/drivers/spi/spi-davinci.c b/drivers/spi/spi-davinci.c
index 7d3af3eacf57..540fc8754085 100644
--- a/drivers/spi/spi-davinci.c
+++ b/drivers/spi/spi-davinci.c
@@ -23,7 +23,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -33,8 +32,6 @@
 
 #include 
 
-#define SPI_NO_RESOURCE((resource_size_t)-1)
-
 #define CS_DEFAULT 0xFF
 
 #define SPIFMT_PHASE_MASK  BIT(16)
@@ -130,8 +127,6 @@ struct davinci_spi {
 
struct dma_chan *dma_rx;
struct dma_chan *dma_tx;
-   int dma_rx_chnum;
-   int dma_tx_chnum;
 
struct davinci_spi_platform_data pdata;
 
@@ -796,35 +791,19 @@ static irqreturn_t davinci_spi_irq(s32 irq, void *data)
 
 static int davinci_spi_request_dma(struct davinci_spi *dspi)
 {
-   dma_cap_mask_t mask;
struct device *sdev = dspi->bitbang.master->dev.parent;
-   int r;
-
-   dma_cap_zero(mask);
-   dma_cap_set(DMA_SLAVE, mask);
 
-   dspi->dma_rx = dma_request_channel(mask, edma_filter_fn,
-  >dma_rx_chnum);
-   if (!dspi->dma_rx) {
-   dev_err(sdev, "request RX DMA channel failed\n");
-   r = -ENODEV;
-   goto rx_dma_failed;
-   }
+   dspi->dma_rx = dma_request_chan(sdev, "rx");
+   if (IS_ERR(dspi->dma_rx))
+   return PTR_ERR(dspi->dma_rx);
 
-   dspi->dma_tx = dma_request_channel(mask, edma_filter_fn,
-  >dma_tx_chnum);
-   if (!dspi->dma_tx) {
-   dev_err(sdev, "request TX DMA channel failed\n");
-   r = -ENODEV;
-   goto tx_dma_failed;
+   dspi->dma_tx = dma_request_chan(sdev, "tx");
+   if (IS_ERR(dspi->dma_tx)) {
+   dma_release_channel(dspi->dma_rx);
+   return PTR_ERR(dspi->dma_tx);
}
 
return 0;
-
-tx_dma_failed:
-   dma_release_channel(dspi->dma_rx);
-rx_dma_failed:
-   return r;
 }
 
 #if defined(CONFIG_OF)
@@ -935,8 +914,6 @@ static int davinci_spi_probe(struct platform_device *pdev)
struct davinci_spi *dspi;
struct davinci_spi_platform_data *pdata;
struct resource *r;
-   resource_size_t dma_rx_chan = SPI_NO_RESOURCE;
-   resource_size_t dma_tx_chan = SPI_NO_RESOURCE;
int ret = 0;
u32 spipc0;
 
@@ -1043,27 +1020,15 @@ static int davinci_spi_probe(struct platform_device 
*pdev)
}
}
 
-   r = platform_get_resource(pdev, IORESOURCE_DMA, 0);
-   if (r)
-   dma_rx_chan = r->start;
-   r = platform_get_resource(pdev, IORESOURCE_DMA, 1);
-   if (r)
-   dma_tx_chan = r->start;
-
dspi->bitbang.txrx_bufs = davinci_spi_bufs;
-   if (dma_rx_chan != SPI_NO_RESOURCE &&
-   dma_tx_chan != SPI_NO_RESOURCE) {
-   dspi->dma_rx_chnum = dma_rx_chan;
-   dspi->dma_tx_chnum = dma_tx_chan;
-
-   ret = davinci_spi_request_dma(dspi);
-   if (ret)
-   goto free_clk;
-
-   dev_info(>dev, "DMA: supported\n");
-   dev_info(>dev, "DMA: RX channel: %pa, TX channel: %pa, 
event queue: %d\n",
-   _rx_chan, _tx_chan,
-   pdata->dma_event_q);
+
+   ret = davinci_spi_request_dma(dspi);
+   if (ret == -EPROBE_DEFER) {
+   goto free_clk;
+   } else if (ret) {
+   dev_info(>dev, "DMA is not supported (%d)\n", ret);
+   dspi->dma_rx = NULL;
+   dspi->dma_tx = NULL;
}
 
dspi->get_rx = davinci_spi_rx_buf_u8;
@@ -1101,8 +1066,10 @@ static int davinci_spi_probe(struct platform_device 
*pdev)
return ret;
 
 free_dma:
-   dma_release_channel(dspi->dma_rx);
-   dma_release_channel(dspi->dma_tx);
+   if (dspi->dma_rx) {
+   dma_release_channel(dspi->dma_rx);
+   dma_release_channel(dspi->dma_tx);
+   }
 free_clk:
clk_disable_unprepare(dspi->clk);
 free_master:
@@ -1133,6 +1100,11 @@ static int davinci_spi_remove(struct platform_device 
*pdev)
clk_disable_unprepare(dspi->clk);
spi_master_put(master);
 
+   if (dspi->dma_rx) {
+   dma_release_channel(dspi->dma_rx);
+   dma_release_channel(dspi->dma_tx);
+   }
+
return 0;
 }
 
-- 
2.6.3

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

[RFC v02 08/15] ARM: davinci: dm644x: Add dma_filter_map to edma

[Peter Ujfalusi]

Provide the dma_filter_map to edma which will allow us to move the drivers
to the new, simpler dmaengine API and we can remove the DMA resources also
for the devices.

Signed-off-by: Peter Ujfalusi 
---
 arch/arm/mach-davinci/dm644x.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index d38f5049d56e..3550488b5bfd 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -505,9 +506,20 @@ static s8 queue_priority_mapping[][2] = {
{-1, -1},
 };
 
+static struct dma_filter_map da644x_edma_map[] = {
+   DMA_FILTER_ENTRY("davinci-mcbsp", "tx", EDMA_CTLR_CHAN(0, 2)),
+   DMA_FILTER_ENTRY("davinci-mcbsp", "rx", EDMA_CTLR_CHAN(0, 3)),
+   DMA_FILTER_ENTRY("spi_davinci", "tx", EDMA_CTLR_CHAN(0, 16)),
+   DMA_FILTER_ENTRY("spi_davinci", "rx", EDMA_CTLR_CHAN(0, 17)),
+   DMA_FILTER_ENTRY("dm6441-mmc.0", "rx", EDMA_CTLR_CHAN(0, 26)),
+   DMA_FILTER_ENTRY("dm6441-mmc.0", "tx", EDMA_CTLR_CHAN(0, 27)),
+};
+
 static struct edma_soc_info dm644x_edma_pdata = {
.queue_priority_mapping = queue_priority_mapping,
.default_queue  = EVENTQ_1,
+   .filter_map = da644x_edma_map,
+   .filtercnt  = ARRAY_SIZE(da644x_edma_map),
 };
 
 static struct resource edma_resources[] = {
-- 
2.6.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

[RFC v02 10/15] mmc: davinci_mmc: Use dma_request_chan() to requesting DMA channel

[Peter Ujfalusi]

With the new dma_request_chan() the clinet driver does not need to look for
the DMA resource and it does not need to pass filter_fn anymore.
By switching to the new API the davinci_mmc driver can now support deferred
probing against DMA.

Signed-off-by: Peter Ujfalusi 
---
 drivers/mmc/host/davinci_mmc.c | 52 --
 1 file changed, 14 insertions(+), 38 deletions(-)

diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c
index ea2a2ebc6b91..8a0a2c291e0c 100644
--- a/drivers/mmc/host/davinci_mmc.c
+++ b/drivers/mmc/host/davinci_mmc.c
@@ -32,12 +32,10 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
 
-#include 
 #include 
 
 /*
@@ -517,35 +515,20 @@ davinci_release_dma_channels(struct mmc_davinci_host 
*host)
 
 static int __init davinci_acquire_dma_channels(struct mmc_davinci_host *host)
 {
-   int r;
-   dma_cap_mask_t mask;
-
-   dma_cap_zero(mask);
-   dma_cap_set(DMA_SLAVE, mask);
-
-   host->dma_tx =
-   dma_request_slave_channel_compat(mask, edma_filter_fn,
-   >txdma, mmc_dev(host->mmc), "tx");
-   if (!host->dma_tx) {
+   host->dma_tx = dma_request_chan(mmc_dev(host->mmc), "tx");
+   if (IS_ERR(host->dma_tx)) {
dev_err(mmc_dev(host->mmc), "Can't get dma_tx channel\n");
-   return -ENODEV;
+   return PTR_ERR(host->dma_tx);
}
 
-   host->dma_rx =
-   dma_request_slave_channel_compat(mask, edma_filter_fn,
-   >rxdma, mmc_dev(host->mmc), "rx");
-   if (!host->dma_rx) {
+   host->dma_rx = dma_request_chan(mmc_dev(host->mmc), "rx");
+   if (IS_ERR(host->dma_rx)) {
dev_err(mmc_dev(host->mmc), "Can't get dma_rx channel\n");
-   r = -ENODEV;
-   goto free_master_write;
+   dma_release_channel(host->dma_tx);
+   return PTR_ERR(host->dma_rx);
}
 
return 0;
-
-free_master_write:
-   dma_release_channel(host->dma_tx);
-
-   return r;
 }
 
 /*--*/
@@ -1262,18 +1245,6 @@ static int __init davinci_mmcsd_probe(struct 
platform_device *pdev)
host = mmc_priv(mmc);
host->mmc = mmc;/* Important */
 
-   r = platform_get_resource(pdev, IORESOURCE_DMA, 0);
-   if (!r)
-   dev_warn(>dev, "RX DMA resource not specified\n");
-   else
-   host->rxdma = r->start;
-
-   r = platform_get_resource(pdev, IORESOURCE_DMA, 1);
-   if (!r)
-   dev_warn(>dev, "TX DMA resource not specified\n");
-   else
-   host->txdma = r->start;
-
host->mem_res = mem;
host->base = ioremap(mem->start, mem_size);
if (!host->base)
@@ -1300,8 +1271,13 @@ static int __init davinci_mmcsd_probe(struct 
platform_device *pdev)
host->mmc_irq = irq;
host->sdio_irq = platform_get_irq(pdev, 1);
 
-   if (host->use_dma && davinci_acquire_dma_channels(host) != 0)
-   host->use_dma = 0;
+   if (host->use_dma) {
+   ret = davinci_acquire_dma_channels(host);
+   if (ret == -EPROBE_DEFER)
+   goto out;
+   else if (ret)
+   host->use_dma = 0;
+   }
 
/* REVISIT:  someday, support IRQ-driven card detection.  */
mmc->caps |= MMC_CAP_NEEDS_POLL;
-- 
2.6.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: [4.4-rc][PATCH] ARM: dts: am4372: fix clock source for arm twd and global timers

[Grygorii Strashko]

On 11/30/2015 03:32 PM, Tero Kristo wrote:
> On 11/30/2015 01:53 PM, Grygorii Strashko wrote:
>> On 11/30/2015 10:25 AM, Tero Kristo wrote:
>>> On 11/27/2015 09:44 PM, Grygorii Strashko wrote:
 ARM TWD and Global timer are clocked by PERIPHCLK which is MPU_CLK/2.
 But now they are clocked by dpll_mpu_m2_ck == MPU_CLK and, as result.
 Timekeeping core misbehaves. For example, execution of command
 "sleep 5" will take 10 sec instead of 5.

 Hence, fix it by adding mpu_periphclk ("fixed-factor-clock") and use
 it for clocking ARM TWD and Global timer (same way as on OMAP4).

 Cc: Tony Lindgren 
 Cc: Felipe Balbi 
 Cc: Tero Kristo 
 Fixes:commit 8cbd4c2f6a99 ("arm: boot: dts: am4372: add ARM timers and
 SCU nodes")
 Signed-off-by: Grygorii Strashko 
 ---
   arch/arm/boot/dts/am4372.dtsi| 4 ++--
   arch/arm/boot/dts/am43xx-clocks.dtsi | 8 
   2 files changed, 10 insertions(+), 2 deletions(-)

 diff --git a/arch/arm/boot/dts/am4372.dtsi
 b/arch/arm/boot/dts/am4372.dtsi
 index d83ff9c..de8791a 100644
 --- a/arch/arm/boot/dts/am4372.dtsi
 +++ b/arch/arm/boot/dts/am4372.dtsi
 @@ -74,7 +74,7 @@
   reg = <0x48240200 0x100>;
   interrupts = ;
   interrupt-parent = <>;
 -clocks = <_mpu_m2_ck>;
 +clocks = <_periphclk>;
   };

   local_timer: timer@48240600 {
 @@ -82,7 +82,7 @@
   reg = <0x48240600 0x100>;
   interrupts = ;
   interrupt-parent = <>;
 -clocks = <_mpu_m2_ck>;
 +clocks = <_periphclk>;
   };

   l2-cache-controller@48242000 {
 diff --git a/arch/arm/boot/dts/am43xx-clocks.dtsi
 b/arch/arm/boot/dts/am43xx-clocks.dtsi
 index cc88728..2ff58b1 100644
 --- a/arch/arm/boot/dts/am43xx-clocks.dtsi
 +++ b/arch/arm/boot/dts/am43xx-clocks.dtsi
 @@ -259,6 +259,14 @@
   ti,invert-autoidle-bit;
   };

 +mpu_periphclk: mpu_periphclk {
 +#clock-cells = <0>;
 +compatible = "fixed-factor-clock";
 +clocks = <_mpu_ck>;
>>>
>>> I don't think this is correct, ARM core is fed dpll_mpu_m2_ck, where the
>>> divisor value can potentially differ from 1. If you feed this clock
>>> directly from dpll_mpu_ck, you bypass this divisor.
>>
>> Sry. My mistake. I'll update it to use dpll_mpu_m2_ck.
>>
>>>
>>> Did you check what is the impact of cpufreq on the ARM TWD/timers?
>>
>> TWD is cpufreq friendly, ARM GT is not.
> 
> I think the TWD kick period changes with cpufreq also right?

linux/arch/arm/kernel/smp_twd.c has code to handle cpufreq.

> 
> How are the clocks handled with cpufreq? The user just needs to 
> understand that the timers will be screwed if he uses ARM GT? Should we 
> add some sort of dependency to disable the ARM GT if cpufreq is enabled?

Yep. May be, but very good question is how to do that in case of
OMAP multiplatform build which enables most of all config options at once.

There two threads related to this:
[1] http://www.spinics.net/lists/arm-kernel/msg459649.html
[2] http://www.spinics.net/lists/arm-kernel/msg461141.html

Personally, I've do not see better way than [2] right now.


 +clock-mult = <1>;
 +clock-div = <2>;
 +};
 +
   dpll_ddr_ck: dpll_ddr_ck {
   #clock-cells = <0>;
   compatible = "ti,am3-dpll-clock";


By the way, does this patch is still correct taking into account dependency
from cpufreq?
Does it make sense update it to use dpll_mpu_ck and resend?

-- 
regards,
-grygorii
--
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 v02 09/15] ARM: davinci: dm646x: Add dma_filter_map to edma

[Peter Ujfalusi]

Provide the dma_filter_map to edma which will allow us to move the drivers
to the new, simpler dmaengine API and we can remove the DMA resources also
for the devices.

Signed-off-by: Peter Ujfalusi 
---
 arch/arm/mach-davinci/dm646x.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index 70eb42725eec..560841a0c4fa 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -9,6 +9,7 @@
  * or implied.
  */
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -540,9 +541,19 @@ static s8 dm646x_queue_priority_mapping[][2] = {
{-1, -1},
 };
 
+static struct dma_filter_map da646x_edma_map[] = {
+   DMA_FILTER_ENTRY("davinci-mcasp.0", "tx", EDMA_CTLR_CHAN(0, 6)),
+   DMA_FILTER_ENTRY("davinci-mcasp.0", "rx", EDMA_CTLR_CHAN(0, 9)),
+   DMA_FILTER_ENTRY("davinci-mcasp.1", "tx", EDMA_CTLR_CHAN(0, 12)),
+   DMA_FILTER_ENTRY("spi_davinci", "tx", EDMA_CTLR_CHAN(0, 16)),
+   DMA_FILTER_ENTRY("spi_davinci", "rx", EDMA_CTLR_CHAN(0, 17)),
+};
+
 static struct edma_soc_info dm646x_edma_pdata = {
.queue_priority_mapping = dm646x_queue_priority_mapping,
.default_queue  = EVENTQ_1,
+   .filter_map = da646x_edma_map,
+   .filtercnt  = ARRAY_SIZE(da646x_edma_map),
 };
 
 static struct resource edma_resources[] = {
-- 
2.6.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

[RFC v02 07/15] ARM: davinci: dm365: Add dma_filter_map to edma

[Peter Ujfalusi]

Provide the dma_filter_map to edma which will allow us to move the drivers
to the new, simpler dmaengine API and we can remove the DMA resources also
for the devices.

Signed-off-by: Peter Ujfalusi 
---
 arch/arm/mach-davinci/dm365.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 2068cbeaeb03..3dfcf7c9aa20 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -862,9 +863,30 @@ static s8 dm365_queue_priority_mapping[][2] = {
{-1, -1},
 };
 
+static struct dma_filter_map da365_edma_map[] = {
+   DMA_FILTER_ENTRY("davinci-mcbsp.0", "tx", EDMA_CTLR_CHAN(0, 2)),
+   DMA_FILTER_ENTRY("davinci-mcbsp.0", "rx", EDMA_CTLR_CHAN(0, 3)),
+   DMA_FILTER_ENTRY("davinci_voicecodec", "tx", EDMA_CTLR_CHAN(0, 2)),
+   DMA_FILTER_ENTRY("davinci_voicecodec", "rx", EDMA_CTLR_CHAN(0, 3)),
+   DMA_FILTER_ENTRY("spi_davinci.2", "tx", EDMA_CTLR_CHAN(0, 10)),
+   DMA_FILTER_ENTRY("spi_davinci.2", "rx", EDMA_CTLR_CHAN(0, 11)),
+   DMA_FILTER_ENTRY("spi_davinci.1", "tx", EDMA_CTLR_CHAN(0, 14)),
+   DMA_FILTER_ENTRY("spi_davinci.1", "rx", EDMA_CTLR_CHAN(0, 15)),
+   DMA_FILTER_ENTRY("spi_davinci.0", "tx", EDMA_CTLR_CHAN(0, 16)),
+   DMA_FILTER_ENTRY("spi_davinci.0", "rx", EDMA_CTLR_CHAN(0, 17)),
+   DMA_FILTER_ENTRY("spi_davinci.3", "tx", EDMA_CTLR_CHAN(0, 18)),
+   DMA_FILTER_ENTRY("spi_davinci.3", "rx", EDMA_CTLR_CHAN(0, 19)),
+   DMA_FILTER_ENTRY("dm6441-mmc.0", "rx", EDMA_CTLR_CHAN(0, 26)),
+   DMA_FILTER_ENTRY("dm6441-mmc.0", "tx", EDMA_CTLR_CHAN(0, 27)),
+   DMA_FILTER_ENTRY("dm6441-mmc.1", "rx", EDMA_CTLR_CHAN(0, 30)),
+   DMA_FILTER_ENTRY("dm6441-mmc.1", "tx", EDMA_CTLR_CHAN(0, 31)),
+};
+
 static struct edma_soc_info dm365_edma_pdata = {
.queue_priority_mapping = dm365_queue_priority_mapping,
.default_queue  = EVENTQ_3,
+   .filter_map = da365_edma_map,
+   .filtercnt  = ARRAY_SIZE(da365_edma_map),
 };
 
 static struct resource edma_resources[] = {
-- 
2.6.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

[RFC v02 04/15] dmaengine: edma: Add support for DMA filter mapping to slave devices

[Peter Ujfalusi]

Add support for providing device to filter_fn mapping so client drivers
can switch to use the dma_request_chan() API.

Signed-off-by: Peter Ujfalusi 
---
 drivers/dma/edma.c | 24 
 include/linux/platform_data/edma.h |  5 +
 2 files changed, 29 insertions(+)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 0675e268d577..386f8c9bd606 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -2098,6 +2098,8 @@ static struct dma_chan *of_edma_xlate(struct 
of_phandle_args *dma_spec,
 }
 #endif
 
+static bool edma_filter_for_map(struct dma_chan *chan, void *param);
+
 static int edma_probe(struct platform_device *pdev)
 {
struct edma_soc_info*info = pdev->dev.platform_data;
@@ -2297,6 +2299,12 @@ static int edma_probe(struct platform_device *pdev)
edma_set_chmap(>slave_chans[i], ecc->dummy_slot);
}
 
+   if (info->filter_map) {
+   ecc->dma_slave.filter_map.map = info->filter_map;
+   ecc->dma_slave.filter_map.mapcnt = info->filtercnt;
+   ecc->dma_slave.filter_map.filter_fn = edma_filter_for_map;
+   }
+
ret = dma_async_device_register(>dma_slave);
if (ret) {
dev_err(dev, "slave ddev registration failed (%d)\n", ret);
@@ -2428,6 +2436,22 @@ bool edma_filter_fn(struct dma_chan *chan, void *param)
 }
 EXPORT_SYMBOL(edma_filter_fn);
 
+static bool edma_filter_for_map(struct dma_chan *chan, void *param)
+{
+   bool match = false;
+
+   if (chan->device->dev->driver == _driver.driver) {
+   struct edma_chan *echan = to_edma_chan(chan);
+   unsigned ch_req = (unsigned)param;
+   if (ch_req == echan->ch_num) {
+   /* The channel is going to be used as HW synchronized */
+   echan->hw_triggered = true;
+   match = true;
+   }
+   }
+   return match;
+}
+
 static int edma_init(void)
 {
int ret;
diff --git a/include/linux/platform_data/edma.h 
b/include/linux/platform_data/edma.h
index e2878baeb90e..117a36d63840 100644
--- a/include/linux/platform_data/edma.h
+++ b/include/linux/platform_data/edma.h
@@ -59,6 +59,8 @@ struct edma_rsv_info {
const s16   (*rsv_slots)[2];
 };
 
+struct dma_filter_map;
+
 /* platform_data for EDMA driver */
 struct edma_soc_info {
/*
@@ -76,6 +78,9 @@ struct edma_soc_info {
 
s8  (*queue_priority_mapping)[2];
const s16   (*xbar_chans)[2];
+
+   struct dma_filter_map *filter_map;
+   int filtercnt;
 };
 
 #endif
-- 
2.6.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

[RFC v02 05/15] ARM: davinci: devices-da8xx: Add dma_filter_map to edma

[Peter Ujfalusi]

Provide the dma_filter_map to edma which will allow us to move the drivers
to the new, simpler dmaengine API and we can remove the DMA resources also
for the devices.

Signed-off-by: Peter Ujfalusi 
---
 arch/arm/mach-davinci/devices-da8xx.c | 46 +++
 1 file changed, 46 insertions(+)

diff --git a/arch/arm/mach-davinci/devices-da8xx.c 
b/arch/arm/mach-davinci/devices-da8xx.c
index 28c90bc372bd..3327cb22e0b5 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -233,16 +234,54 @@ static const struct platform_device_info 
da850_edma1_device __initconst = {
.size_data  = sizeof(da850_edma1_pdata),
 };
 
+static struct dma_filter_map da830_edma_map[] = {
+   DMA_FILTER_ENTRY("davinci-mcasp.0", "rx", EDMA_CTLR_CHAN(0, 0)),
+   DMA_FILTER_ENTRY("davinci-mcasp.0", "tx", EDMA_CTLR_CHAN(0, 1)),
+   DMA_FILTER_ENTRY("davinci-mcasp.1", "rx", EDMA_CTLR_CHAN(0, 2)),
+   DMA_FILTER_ENTRY("davinci-mcasp.1", "tx", EDMA_CTLR_CHAN(0, 3)),
+   DMA_FILTER_ENTRY("davinci-mcasp.2", "rx", EDMA_CTLR_CHAN(0, 4)),
+   DMA_FILTER_ENTRY("davinci-mcasp.2", "tx", EDMA_CTLR_CHAN(0, 5)),
+   DMA_FILTER_ENTRY("spi_davinci.0", "rx", EDMA_CTLR_CHAN(0, 14)),
+   DMA_FILTER_ENTRY("spi_davinci.0", "tx", EDMA_CTLR_CHAN(0, 15)),
+   DMA_FILTER_ENTRY("da830-mmc.0", "rx", EDMA_CTLR_CHAN(0, 16)),
+   DMA_FILTER_ENTRY("da830-mmc.0", "tx", EDMA_CTLR_CHAN(0, 17)),
+   DMA_FILTER_ENTRY("spi_davinci.1", "rx", EDMA_CTLR_CHAN(0, 18)),
+   DMA_FILTER_ENTRY("spi_davinci.1", "tx", EDMA_CTLR_CHAN(0, 19)),
+};
+
 int __init da830_register_edma(struct edma_rsv_info *rsv)
 {
struct platform_device *edma_pdev;
 
da8xx_edma0_pdata.rsv = rsv;
 
+   da8xx_edma0_pdata.filter_map = da830_edma_map;
+   da8xx_edma0_pdata.filtercnt = ARRAY_SIZE(da830_edma_map);
+
edma_pdev = platform_device_register_full(_edma0_device);
return IS_ERR(edma_pdev) ? PTR_ERR(edma_pdev) : 0;
 }
 
+static struct dma_filter_map da850_edma0_map[] = {
+   DMA_FILTER_ENTRY("davinci-mcasp.0", "rx", EDMA_CTLR_CHAN(0, 0)),
+   DMA_FILTER_ENTRY("davinci-mcasp.0", "tx", EDMA_CTLR_CHAN(0, 1)),
+   DMA_FILTER_ENTRY("davinci-mcbsp.0", "rx", EDMA_CTLR_CHAN(0, 2)),
+   DMA_FILTER_ENTRY("davinci-mcbsp.0", "tx", EDMA_CTLR_CHAN(0, 3)),
+   DMA_FILTER_ENTRY("davinci-mcbsp.1", "rx", EDMA_CTLR_CHAN(0, 4)),
+   DMA_FILTER_ENTRY("davinci-mcbsp.1", "tx", EDMA_CTLR_CHAN(0, 5)),
+   DMA_FILTER_ENTRY("spi_davinci.0", "rx", EDMA_CTLR_CHAN(0, 14)),
+   DMA_FILTER_ENTRY("spi_davinci.0", "tx", EDMA_CTLR_CHAN(0, 15)),
+   DMA_FILTER_ENTRY("da830-mmc.0", "rx", EDMA_CTLR_CHAN(0, 16)),
+   DMA_FILTER_ENTRY("da830-mmc.0", "tx", EDMA_CTLR_CHAN(0, 17)),
+   DMA_FILTER_ENTRY("spi_davinci.1", "rx", EDMA_CTLR_CHAN(0, 18)),
+   DMA_FILTER_ENTRY("spi_davinci.1", "tx", EDMA_CTLR_CHAN(0, 19)),
+};
+
+static struct dma_filter_map da850_edma1_map[] = {
+   DMA_FILTER_ENTRY("da830-mmc.1", "tx", EDMA_CTLR_CHAN(0, 28)),
+   DMA_FILTER_ENTRY("da830-mmc.1", "rx", EDMA_CTLR_CHAN(0, 29)),
+};
+
 int __init da850_register_edma(struct edma_rsv_info *rsv[2])
 {
struct platform_device *edma_pdev;
@@ -252,11 +291,18 @@ int __init da850_register_edma(struct edma_rsv_info 
*rsv[2])
da850_edma1_pdata.rsv = rsv[1];
}
 
+   da8xx_edma0_pdata.filter_map = da850_edma0_map;
+   da8xx_edma0_pdata.filtercnt = ARRAY_SIZE(da850_edma0_map);
+
edma_pdev = platform_device_register_full(_edma0_device);
if (IS_ERR(edma_pdev)) {
pr_warn("%s: Failed to register eDMA0\n", __func__);
return PTR_ERR(edma_pdev);
}
+
+   da850_edma1_pdata.filter_map = da850_edma1_map;
+   da850_edma1_pdata.filtercnt = ARRAY_SIZE(da850_edma1_map);
+
edma_pdev = platform_device_register_full(_edma1_device);
return IS_ERR(edma_pdev) ? PTR_ERR(edma_pdev) : 0;
 }
-- 
2.6.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

[RFC v02 06/15] ARM: davinci: dm355: Add dma_filter_map to edma

[Peter Ujfalusi]

Provide the dma_filter_map to edma which will allow us to move the drivers
to the new, simpler dmaengine API and we can remove the DMA resources also
for the devices.

Signed-off-by: Peter Ujfalusi 
---
 arch/arm/mach-davinci/dm355.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index 609950b8c191..dc8d7ccf69f4 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -576,9 +577,28 @@ static s8 queue_priority_mapping[][2] = {
{-1, -1},
 };
 
+static struct dma_filter_map da355_edma_map[] = {
+   DMA_FILTER_ENTRY("davinci-mcbsp.0", "tx", EDMA_CTLR_CHAN(0, 2)),
+   DMA_FILTER_ENTRY("davinci-mcbsp.0", "rx", EDMA_CTLR_CHAN(0, 3)),
+   DMA_FILTER_ENTRY("davinci-mcbsp.1", "tx", EDMA_CTLR_CHAN(0, 8)),
+   DMA_FILTER_ENTRY("davinci-mcbsp.1", "rx", EDMA_CTLR_CHAN(0, 9)),
+   DMA_FILTER_ENTRY("spi_davinci.2", "tx", EDMA_CTLR_CHAN(0, 10)),
+   DMA_FILTER_ENTRY("spi_davinci.2", "rx", EDMA_CTLR_CHAN(0, 11)),
+   DMA_FILTER_ENTRY("spi_davinci.1", "tx", EDMA_CTLR_CHAN(0, 14)),
+   DMA_FILTER_ENTRY("spi_davinci.1", "rx", EDMA_CTLR_CHAN(0, 15)),
+   DMA_FILTER_ENTRY("spi_davinci.0", "tx", EDMA_CTLR_CHAN(0, 16)),
+   DMA_FILTER_ENTRY("spi_davinci.0", "rx", EDMA_CTLR_CHAN(0, 17)),
+   DMA_FILTER_ENTRY("dm6441-mmc.0", "rx", EDMA_CTLR_CHAN(0, 26)),
+   DMA_FILTER_ENTRY("dm6441-mmc.0", "tx", EDMA_CTLR_CHAN(0, 27)),
+   DMA_FILTER_ENTRY("dm6441-mmc.1", "rx", EDMA_CTLR_CHAN(0, 30)),
+   DMA_FILTER_ENTRY("dm6441-mmc.1", "tx", EDMA_CTLR_CHAN(0, 31)),
+};
+
 static struct edma_soc_info dm355_edma_pdata = {
.queue_priority_mapping = queue_priority_mapping,
.default_queue  = EVENTQ_1,
+   .filter_map = da355_edma_map,
+   .filtercnt  = ARRAY_SIZE(da355_edma_map),
 };
 
 static struct resource edma_resources[] = {
-- 
2.6.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

[RFC v02 02/15] dmaengine: core: Move and merge the code paths using private_candidate

[Peter Ujfalusi]

Channel matching with private_candidate() is used in two paths, the error
checking is slightly different in them and they are duplicating code also.
Move the code under dma_get_channel() to provide consistent execution and
going to allow us to reuse this mode of channel lookup later.

Signed-off-by: Peter Ujfalusi 
---
 drivers/dma/dmaengine.c | 81 +
 1 file changed, 42 insertions(+), 39 deletions(-)

diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index 52c3eee48e2e..1249165fb4b2 100644
--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c
@@ -549,6 +549,42 @@ static struct dma_chan *private_candidate(const 
dma_cap_mask_t *mask,
return NULL;
 }
 
+static struct dma_chan *dma_get_channel(struct dma_device *device,
+   const dma_cap_mask_t *mask,
+   dma_filter_fn fn, void *fn_param)
+{
+   struct dma_chan *chan = private_candidate(mask, device, fn, fn_param);
+   int err;
+
+   if (chan) {
+   /* Found a suitable channel, try to grab, prep, and return it.
+* We first set DMA_PRIVATE to disable balance_ref_count as this
+* channel will not be published in the general-purpose
+* allocator
+*/
+   dma_cap_set(DMA_PRIVATE, device->cap_mask);
+   device->privatecnt++;
+   err = dma_chan_get(chan);
+
+   if (err) {
+   if (err == -ENODEV) {
+   pr_debug("%s: %s module removed\n", __func__,
+dma_chan_name(chan));
+   list_del_rcu(>global_node);
+   } else
+   pr_debug("%s: failed to get %s: (%d)\n",
+__func__, dma_chan_name(chan), err);
+
+   if (--device->privatecnt == 0)
+   dma_cap_clear(DMA_PRIVATE, device->cap_mask);
+
+   chan = ERR_PTR(err);
+   }
+   }
+
+   return chan ? chan : ERR_PTR(-EPROBE_DEFER);
+}
+
 /**
  * dma_get_slave_channel - try to get specific channel exclusively
  * @chan: target channel
@@ -587,7 +623,6 @@ struct dma_chan *dma_get_any_slave_channel(struct 
dma_device *device)
 {
dma_cap_mask_t mask;
struct dma_chan *chan;
-   int err;
 
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
@@ -595,23 +630,11 @@ struct dma_chan *dma_get_any_slave_channel(struct 
dma_device *device)
/* lock against __dma_request_channel */
mutex_lock(_list_mutex);
 
-   chan = private_candidate(, device, NULL, NULL);
-   if (chan) {
-   dma_cap_set(DMA_PRIVATE, device->cap_mask);
-   device->privatecnt++;
-   err = dma_chan_get(chan);
-   if (err) {
-   pr_debug("%s: failed to get %s: (%d)\n",
-   __func__, dma_chan_name(chan), err);
-   chan = NULL;
-   if (--device->privatecnt == 0)
-   dma_cap_clear(DMA_PRIVATE, device->cap_mask);
-   }
-   }
+   chan = dma_get_channel(device, , NULL, NULL);
 
mutex_unlock(_list_mutex);
 
-   return chan;
+   return IS_ERR(chan) ? NULL : chan;
 }
 EXPORT_SYMBOL_GPL(dma_get_any_slave_channel);
 
@@ -628,35 +651,15 @@ struct dma_chan *__dma_request_channel(const 
dma_cap_mask_t *mask,
 {
struct dma_device *device, *_d;
struct dma_chan *chan = NULL;
-   int err;
 
/* Find a channel */
mutex_lock(_list_mutex);
list_for_each_entry_safe(device, _d, _device_list, global_node) {
-   chan = private_candidate(mask, device, fn, fn_param);
-   if (chan) {
-   /* Found a suitable channel, try to grab, prep, and
-* return it.  We first set DMA_PRIVATE to disable
-* balance_ref_count as this channel will not be
-* published in the general-purpose allocator
-*/
-   dma_cap_set(DMA_PRIVATE, device->cap_mask);
-   device->privatecnt++;
-   err = dma_chan_get(chan);
+   chan = dma_get_channel(device, mask, fn, fn_param);
+   if (!IS_ERR(chan))
+   break;
 
-   if (err == -ENODEV) {
-   pr_debug("%s: %s module removed\n",
-__func__, dma_chan_name(chan));
-   list_del_rcu(>global_node);
-   } else if (err)
-   pr_debug("%s: failed to get %s: (%d)\n",
-__func__, 

[RFC v02 00/15] dmaengine: New 'universal' API for requesting channel

[Peter Ujfalusi]

Hi,

Changes since RFC v01:
- dma_request_chan(); lost the mask parameter
- The new API does not rely on RESOURCE_DMA, instead the dma_filter_map table
  will be used to provide the needed information to the filter function in
  legacy mode
- Extended the example patches to convert most of daVinci to use the new API to
  request the DMA channels.

TODO: Documentation update ;)

As it has been discussed in the following thread:
http://www.gossamer-threads.com/lists/linux/kernel/2181487#2181487

Andy: I did looked at the unified device properties, but I decided to not to use
it as I don't see it to fit well and most of the legacy board files are using
resources to specify at least their memory regions so adding the DMA resource
to them would be more inline with the rest of the code.

The ARM, mmc and spi patches are converting daVinci drivers board files to use
the new method of requesting DMA channel.

With this series I have taken a path which would result two new API, which can
be used to convert most of the current users already and with some work all
users might be able to move to this set.
With this set the filter_fn used for legacy (non DT/ACPI) channel request is no
longer needed to be exported to client drivers since the selection of the
correct filter_fn will be done in the core.

So, the first proposal is to have:

struct dma_chan *dma_request_chan(struct device *dev, const char *name);
struct dma_chan *dma_request_chan_by_mask(const dma_cap_mask_t *mask);

The dma_request_chan_by_mask() is to request any channel matching with the
requested capabilities, can be used to request channel for memcpy, memset, xor,
etc where no hardware synchronization is needed.

The dma_request_chan() is to request a slave channel. The dma_request_chan() 
will try to find the
channel via DT, ACPI or in case if the kernel booted in non DT/ACPI mode
it will use a filter lookup table and retrieves the needed information from
the dma_filter_map provided by the DMA drivers.
This legacy mode needs changes in platform code, in dmaengine drivers and
finally the dmaengine user drivers can be converted:

For each dmaengine driver an array of DMA device, slave and the parameter
for the filter function needs to be added:

static struct dma_filter_map da830_edma_map[] = {
DMA_FILTER_ENTRY("davinci-mcasp.0", "rx", EDMA_CTLR_CHAN(0, 0)),
DMA_FILTER_ENTRY("davinci-mcasp.0", "tx", EDMA_CTLR_CHAN(0, 1)),
DMA_FILTER_ENTRY("davinci-mcasp.1", "rx", EDMA_CTLR_CHAN(0, 2)),
DMA_FILTER_ENTRY("davinci-mcasp.1", "tx", EDMA_CTLR_CHAN(0, 3)),
DMA_FILTER_ENTRY("davinci-mcasp.2", "rx", EDMA_CTLR_CHAN(0, 4)),
DMA_FILTER_ENTRY("davinci-mcasp.2", "tx", EDMA_CTLR_CHAN(0, 5)),
DMA_FILTER_ENTRY("spi_davinci.0", "rx", EDMA_CTLR_CHAN(0, 14)),
DMA_FILTER_ENTRY("spi_davinci.0", "tx", EDMA_CTLR_CHAN(0, 15)),
DMA_FILTER_ENTRY("da830-mmc.0", "rx", EDMA_CTLR_CHAN(0, 16)),
DMA_FILTER_ENTRY("da830-mmc.0", "tx", EDMA_CTLR_CHAN(0, 17)),
DMA_FILTER_ENTRY("spi_davinci.1", "rx", EDMA_CTLR_CHAN(0, 18)),
DMA_FILTER_ENTRY("spi_davinci.1", "tx", EDMA_CTLR_CHAN(0, 19)),
};

This information is going to be needed by the dmaengine driver, so
modification to the platform_data is needed, and the driver map should be
added to the pdata of the DMA driver:

da8xx_edma0_pdata.filter_map = da830_edma_map;
da8xx_edma0_pdata.filtercnt = ARRAY_SIZE(da830_edma_map);

The DMA driver then needs to convigure the needed device -> filter_fn
mapping before it registers with dma_async_device_register() :

if (info->filter_map) {
ecc->dma_slave.filter_map.map = info->filter_map;
ecc->dma_slave.filter_map.mapcnt = info->filtercnt;
ecc->dma_slave.filter_map.filter_fn = edma_filter_for_map;
}

When neither DT or ACPI lookup is available the dma_request_chan() will
try to match the requester's device name with the filter_map's list of
device names, when a match found it will use the information from the
dma_filter_map to get the channel with the dma_get_channel() internal
function.

Regards,
Peter
---
Peter Ujfalusi (15):
  dmaengine: core: Allow NULL mask pointer in
__dma_device_satisfies_mask()
  dmaengine: core: Move and merge the code paths using private_candidate
  dmaengine: core: Introduce new, universal API to request a channel
  dmaengine: edma: Add support for DMA filter mapping to slave devices
  ARM: davinci: devices-da8xx: Add dma_filter_map to edma
  ARM: davinci: dm355: Add dma_filter_map to edma
  ARM: davinci: dm365: Add dma_filter_map to edma
  ARM: davinci: dm644x: Add dma_filter_map to edma
  ARM: davinci: dm646x: Add dma_filter_map to edma
  mmc: davinci_mmc: Use dma_request_chan() to requesting DMA channel
  spi: davinci: Use dma_request_chan() to requesting DMA channel
  ARM: davinci: devices-da8xx: Remove DMA resources for MMC and SPI
  ARM: davinci: devices: Remove DMA resources for MMC
  ARM: davinci: dm355: Remove DMA resources for SPI
  ARM: 

[RFC v02 03/15] dmaengine: core: Introduce new, universal API to request a channel

[Peter Ujfalusi]

The two API function can cover most, if not all current APIs used to
request a channel. With minimal effort dmaengine drivers, platforms and
dmaengine user drivers can be converted to use the two function.

struct dma_chan *dma_request_chan_by_mask(const dma_cap_mask_t *mask);

To request any channel matching with the requested capabilities, can be
used to request channel for memcpy, memset, xor, etc where no hardware
synchronization is needed.

struct dma_chan *dma_request_chan(struct device *dev, const char *name);
To request a slave channel. The dma_request_chan() will try to find the
channel via DT, ACPI or in case if the kernel booted in non DT/ACPI mode
it will use a filter lookup table and retrieves the needed information from
the dma_filter_map provided by the DMA drivers.
This legacy mode needs changes in platform code, in dmaengine drivers and
finally the dmaengine user drivers can be converted:

For each dmaengine driver an array of DMA device, slave and the parameter
for the filter function needs to be added:

static struct dma_filter_map da830_edma_map[] = {
DMA_FILTER_ENTRY("davinci-mcasp.0", "rx", EDMA_CTLR_CHAN(0, 0)),
DMA_FILTER_ENTRY("davinci-mcasp.0", "tx", EDMA_CTLR_CHAN(0, 1)),
DMA_FILTER_ENTRY("davinci-mcasp.1", "rx", EDMA_CTLR_CHAN(0, 2)),
DMA_FILTER_ENTRY("davinci-mcasp.1", "tx", EDMA_CTLR_CHAN(0, 3)),
DMA_FILTER_ENTRY("davinci-mcasp.2", "rx", EDMA_CTLR_CHAN(0, 4)),
DMA_FILTER_ENTRY("davinci-mcasp.2", "tx", EDMA_CTLR_CHAN(0, 5)),
DMA_FILTER_ENTRY("spi_davinci.0", "rx", EDMA_CTLR_CHAN(0, 14)),
DMA_FILTER_ENTRY("spi_davinci.0", "tx", EDMA_CTLR_CHAN(0, 15)),
DMA_FILTER_ENTRY("da830-mmc.0", "rx", EDMA_CTLR_CHAN(0, 16)),
DMA_FILTER_ENTRY("da830-mmc.0", "tx", EDMA_CTLR_CHAN(0, 17)),
DMA_FILTER_ENTRY("spi_davinci.1", "rx", EDMA_CTLR_CHAN(0, 18)),
DMA_FILTER_ENTRY("spi_davinci.1", "tx", EDMA_CTLR_CHAN(0, 19)),
};

This information is going to be needed by the dmaengine driver, so
modification to the platform_data is needed, and the driver map should be
added to the pdata of the DMA driver:

da8xx_edma0_pdata.filter_map = da830_edma_map;
da8xx_edma0_pdata.filtercnt = ARRAY_SIZE(da830_edma_map);

The DMA driver then needs to convigure the needed device -> filter_fn
mapping before it registers with dma_async_device_register() :

if (info->filter_map) {
ecc->dma_slave.filter_map.map = info->filter_map;
ecc->dma_slave.filter_map.mapcnt = info->filtercnt;
ecc->dma_slave.filter_map.filter_fn = edma_filter_for_map;
}

When neither DT or ACPI lookup is available the dma_request_chan() will
try to match the requester's device name with the filter_map's list of
device names, when a match found it will use the information from the
dma_filter_map to get the channel with the dma_get_channel() internal
function.

Signed-off-by: Peter Ujfalusi 
---
 drivers/dma/dmaengine.c   | 76 +++
 include/linux/dmaengine.h | 31 +++
 2 files changed, 107 insertions(+)

diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index 1249165fb4b2..bd774adff697 100644
--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c
@@ -43,6 +43,7 @@
 
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
 
+#include 
 #include 
 #include 
 #include 
@@ -715,6 +716,81 @@ struct dma_chan *dma_request_slave_channel(struct device 
*dev,
 }
 EXPORT_SYMBOL_GPL(dma_request_slave_channel);
 
+static struct dma_filter_map *dma_filter_match(struct dma_device *device,
+  const char *name,
+  struct device *dev)
+{
+   struct dma_filter_map *map_found = NULL;
+   int i;
+
+   if (!device->filter_map.mapcnt)
+   return NULL;
+
+   for (i = 0; i < device->filter_map.mapcnt; i++) {
+   struct dma_filter_map *map = >filter_map.map[i];
+
+   if (!strcmp(map->devname, dev_name(dev)) &&
+   !strcmp(map->slave, name)) {
+   map_found = map;
+   break;
+   }
+   }
+
+   return map_found;
+}
+
+struct dma_chan *dma_request_chan(struct device *dev, const char *name)
+{
+   struct dma_device *device, *_d;
+   struct dma_chan *chan = NULL;
+
+   /* If device-tree is present get slave info from here */
+   if (dev->of_node)
+   chan = of_dma_request_slave_channel(dev->of_node, name);
+
+   /* If device was enumerated by ACPI get slave info from here */
+   if (ACPI_HANDLE(dev) && !chan)
+   chan = acpi_dma_request_slave_chan_by_name(dev, name);
+
+   if (chan)
+   return chan;
+
+   /* Try to find the channel via the DMA filter map(s) */
+   mutex_lock(_list_mutex);
+   list_for_each_entry_safe(device, _d, _device_list, global_node) {
+   struct 

[RFC v02 01/15] dmaengine: core: Allow NULL mask pointer in __dma_device_satisfies_mask()

[Peter Ujfalusi]

Treat as true condition the case when the mask is NULL.

Signed-off-by: Peter Ujfalusi 
---
 drivers/dma/dmaengine.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index daf54a39bcc7..52c3eee48e2e 100644
--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c
@@ -184,6 +184,9 @@ __dma_device_satisfies_mask(struct dma_device *device,
 {
dma_cap_mask_t has;
 
+   if (!want)
+   return true;
+
bitmap_and(has.bits, want->bits, device->cap_mask.bits,
DMA_TX_TYPE_END);
return bitmap_equal(want->bits, has.bits, DMA_TX_TYPE_END);
-- 
2.6.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: [4.4-rc][PATCH] ARM: dts: am4372: fix clock source for arm twd and global timers

[Tero Kristo]

On 11/30/2015 03:49 PM, Grygorii Strashko wrote:

On 11/30/2015 03:32 PM, Tero Kristo wrote:

On 11/30/2015 01:53 PM, Grygorii Strashko wrote:

On 11/30/2015 10:25 AM, Tero Kristo wrote:

On 11/27/2015 09:44 PM, Grygorii Strashko wrote:

ARM TWD and Global timer are clocked by PERIPHCLK which is MPU_CLK/2.
But now they are clocked by dpll_mpu_m2_ck == MPU_CLK and, as result.
Timekeeping core misbehaves. For example, execution of command
"sleep 5" will take 10 sec instead of 5.

Hence, fix it by adding mpu_periphclk ("fixed-factor-clock") and use
it for clocking ARM TWD and Global timer (same way as on OMAP4).

Cc: Tony Lindgren 
Cc: Felipe Balbi 
Cc: Tero Kristo 
Fixes:commit 8cbd4c2f6a99 ("arm: boot: dts: am4372: add ARM timers and
SCU nodes")
Signed-off-by: Grygorii Strashko 
---
   arch/arm/boot/dts/am4372.dtsi| 4 ++--
   arch/arm/boot/dts/am43xx-clocks.dtsi | 8 
   2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/am4372.dtsi
b/arch/arm/boot/dts/am4372.dtsi
index d83ff9c..de8791a 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -74,7 +74,7 @@
   reg = <0x48240200 0x100>;
   interrupts = ;
   interrupt-parent = <>;
-clocks = <_mpu_m2_ck>;
+clocks = <_periphclk>;
   };

   local_timer: timer@48240600 {
@@ -82,7 +82,7 @@
   reg = <0x48240600 0x100>;
   interrupts = ;
   interrupt-parent = <>;
-clocks = <_mpu_m2_ck>;
+clocks = <_periphclk>;
   };

   l2-cache-controller@48242000 {
diff --git a/arch/arm/boot/dts/am43xx-clocks.dtsi
b/arch/arm/boot/dts/am43xx-clocks.dtsi
index cc88728..2ff58b1 100644
--- a/arch/arm/boot/dts/am43xx-clocks.dtsi
+++ b/arch/arm/boot/dts/am43xx-clocks.dtsi
@@ -259,6 +259,14 @@
   ti,invert-autoidle-bit;
   };

+mpu_periphclk: mpu_periphclk {
+#clock-cells = <0>;
+compatible = "fixed-factor-clock";
+clocks = <_mpu_ck>;


I don't think this is correct, ARM core is fed dpll_mpu_m2_ck, where the
divisor value can potentially differ from 1. If you feed this clock
directly from dpll_mpu_ck, you bypass this divisor.


Sry. My mistake. I'll update it to use dpll_mpu_m2_ck.



Did you check what is the impact of cpufreq on the ARM TWD/timers?


TWD is cpufreq friendly, ARM GT is not.


I think the TWD kick period changes with cpufreq also right?


linux/arch/arm/kernel/smp_twd.c has code to handle cpufreq.



How are the clocks handled with cpufreq? The user just needs to
understand that the timers will be screwed if he uses ARM GT? Should we
add some sort of dependency to disable the ARM GT if cpufreq is enabled?


Yep. May be, but very good question is how to do that in case of
OMAP multiplatform build which enables most of all config options at once.

There two threads related to this:
[1] http://www.spinics.net/lists/arm-kernel/msg459649.html
[2] http://www.spinics.net/lists/arm-kernel/msg461141.html

Personally, I've do not see better way than [2] right now.


Yeah, [2] seems the way to go.





+clock-mult = <1>;
+clock-div = <2>;
+};
+
   dpll_ddr_ck: dpll_ddr_ck {
   #clock-cells = <0>;
   compatible = "ti,am3-dpll-clock";



By the way, does this patch is still correct taking into account dependency
from cpufreq?
Does it make sense update it to use dpll_mpu_ck and resend?



Well, this patch is still valid, as the selection of the clocksource 
should be done elsewhere, and this patch should not care about that.


-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: [RFC v02 03/15] dmaengine: core: Introduce new, universal API to request a channel

[Arnd Bergmann]

On Monday 30 November 2015 15:45:33 Peter Ujfalusi wrote:
>   const char *name);
>  struct dma_chan *dma_request_slave_channel(struct device *dev, const char 
> *name);
> +
> +struct dma_chan *dma_request_chan(struct device *dev, const char *name);
> +struct dma_chan *dma_request_chan_by_mask(const dma_cap_mask_t *mask);
> +
>  void dma_release_channel(struct dma_chan *chan);
>  int dma_get_slave_caps(struct dma_chan *chan, struct dma_slave_caps *caps);
>  #else
> @@ -1268,6 +1291,14 @@ static inline struct dma_chan 
> *dma_request_slave_channel(struct device *dev,
>  {
> return NULL;
>  }
> +static inline struct dma_chan *dma_request_chan(struct device *dev)
> +{
> +   return ERR_PTR(-ENODEV);
> +}
> 

The prototypes for dma_request_chan() don't match, otherwise looks good.

Arnd
--
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: [RFC v02 04/15] dmaengine: edma: Add support for DMA filter mapping to slave devices

[Arnd Bergmann]

On Monday 30 November 2015 15:45:34 Peter Ujfalusi wrote:
> @@ -2428,6 +2436,22 @@ bool edma_filter_fn(struct dma_chan *chan, void *param)
>  }
>  EXPORT_SYMBOL(edma_filter_fn);
>  
> +static bool edma_filter_for_map(struct dma_chan *chan, void *param)
> +{
> +   bool match = false;
> +
> +   if (chan->device->dev->driver == _driver.driver) {
> +   struct edma_chan *echan = to_edma_chan(chan);
> +   unsigned ch_req = (unsigned)param;
> +   if (ch_req == echan->ch_num) {
> +   /* The channel is going to be used as HW synchronized 
> */
> +   echan->hw_triggered = true;
> +   match = true;
> +   }
> +   }
> +   return match;
> +}
> +
>  static int edma_init(void)
> 

I don't see the difference between edma_filter_fn and edma_filter_for_map.
Why do you need both?

Arnd
--
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: [4.4-rc][PATCH] gpio: omap: drop omap1 mpuio specific irq_mask/unmask callbacks

[Linus Walleij]

On Fri, Nov 20, 2015 at 2:35 PM, Grygorii Strashko
 wrote:

> Originally OMAP MPUIO GPIO irqchip was implemented using Generic irq
> chip, but after set of reworks Generic irq chip code was replaced by
> common OMAP GPIO implementation and finally removed by
> commit d2d05c65c40e ("gpio: omap: Fix regression for MPUIO interrupts").
> Unfortunately, above commit left .irq_mask/unmask callbacks assigned
> as below for MPUIO GPIO case:
> irqc->irq_mask = irq_gc_mask_set_bit;
> irqc->irq_unmask = irq_gc_mask_clr_bit;
>
> This now causes boot failure on OMAP1 platforms, after
> commit 450fa54cfd66 ("gpio: omap: convert to use generic irq handler")
> which forces these callbacks to be called during GPIO IRQs mapping
> from gpiochip_irq_map:
>
> Unable to handle kernel NULL pointer dereference at virtual address 
> pgd = c0004000
> [] *pgd=
> Internal error: Oops: 75 [#1] ARM
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper Not tainted 
> 4.4.0-rc1-e3-los_afe0c+-2-g25379c0-dirty #1
> Hardware name: Amstrad E3 (Delta)
> task: c1836000 ti: c1838000 task.ti: c1838000
> PC is at irq_gc_mask_set_bit+0x1c/0x60
> LR is at __irq_do_set_handler+0x118/0x15c
> pc : []lr : []psr: 60d3
> sp : c1839c90  ip : c1862c64  fp : c1839c9c
> r10:   r9 : c0411950  r8 : c0411bbc
> r7 :   r6 : c185c310  r5 : c00444e8  r4 : c185c300
> r3 : c1854b50  r2 :   r1 :   r0 : c185c310
> Flags: nZCv  IRQs off  FIQs off  Mode SVC_32  ISA ARM  Segment kernel
> Control: 317f  Table: 10004000  DAC: 0057
> Process swapper (pid: 1, stack limit = 0xc1838190)
> Stack: (0xc1839c90 to 0xc183a000)
>
> [...]
>
> Backtrace:
> [] (irq_gc_mask_set_bit) from [] 
> (__irq_do_set_handler+0x118/0x15c)
> [] (__irq_do_set_handler) from [] 
> (__irq_set_handler+0x44/0x5c)
>  r6: r5:c00444e8 r4:c185c300
> [] (__irq_set_handler) from [] 
> (irq_set_chip_and_handler_name+0x30/0x34)
>  r7:0050 r6: r5:c00444e8 r4:0050
> [] (irq_set_chip_and_handler_name) from [] 
> (gpiochip_irq_map+0x3c/0x8c)
>  r7:0050 r6: r5:0050 r4:c1862c64
> [] (gpiochip_irq_map) from [] 
> (irq_domain_associate+0x7c/0x1c4)
>  r5:c185c310 r4:c185cb00
> [] (irq_domain_associate) from [] 
> (irq_domain_add_simple+0x98/0xc0)
>  r8:c0411bbc r7:c185cb00 r6:0050 r5:0010 r4:0001
> [] (irq_domain_add_simple) from [] 
> (_gpiochip_irqchip_add+0x64/0x10c)
>  r7:c1862c64 r6:c0419280 r5:c1862c64 r4:c1854b50
> [] (_gpiochip_irqchip_add) from [] 
> (omap_gpio_probe+0x2fc/0x63c)
>  r5:c1854b50 r4:c1862c10
> [] (omap_gpio_probe) from [] 
> (platform_drv_probe+0x2c/0x64)
>  r10: r9:c03e45e8 r8: r7:c0419294 r6:c0411984 r5:c0419294
>  r4:c0411950
> [] (platform_drv_probe) from [] (really_probe+0x160/0x29c)
>
> Hence, fix it by remove obsolete callbacks assignment. After this
> change  omap_gpio_mask_irq()/omap_gpio_unmask_irq() will be used
> for MPUIO IRQs masking, but this now happens anyway from
> omap_gpio_irq_startup/shutdown().
>
> Cc: Tony Lindgren 
> Fixes: commit d2d05c65c40e ("gpio: omap: Fix regression for MPUIO interrupts")
> Reported-by: Aaro Koskinen 
> Signed-off-by: Grygorii Strashko 

Patch applied for fixes.

Yours,
Linus Walleij
--
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/18] ARM: am57xx: cl-som-am57x: dts: add basic module support

[Nishanth Menon]

On 11/30/2015 07:29 AM, Dmitry Lifshitz wrote:
> On 11/29/2015 07:06 PM, Nishanth Menon wrote:
>> On 11/29/2015 06:10 AM, Dmitry Lifshitz wrote:
[...]
>>
>> You might want to ask your TI support contact for IODelay
>> recommendations. TRM mentions that pinmuxing must be performed under IO
>> isolation. There are silicon constraints in DRA7/AM57xx family, which
>> were not present previously.
>>
> 
> Ok. I understand. This might take time...
> Since we'd like to have this in for 4.5, what would you recommend?
> Should I drop the muxes from this patch set? All the muxes?
> Or should we merge this (as it works correctly) in our tests and check
> on this later after investigation with TI?
> 
> Also, in theory, there might be pins shared between two or more
> different functionalities and remuxed during runtime.
> Can this kind of thing be supported on AM57x?

This is why I suggested to talk and confirm with TI support contact on
this. I understand the motivation of SoM concept, but this requires some
careful designing around.


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