Re: [4.4-rc][PATCH] gpio: omap: drop omap1 mpuio specific irq_mask/unmask callbacks

[santosh shilimkar]

On 11/20/2015 5:35 AM, 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 <t...@atomide.com>
Fixes: commit d2d05c65c40e ("gpio: omap: Fix regression for MPUIO interrupts")
Reported-by: Aaro Koskinen <aaro.koski...@iki.fi>
Signed-off-by: Grygorii Strashko <grygorii.stras...@ti.com>
---

Acked-by: Santosh Shilimkar <ssant...@kernel.org>
--
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] clocksource: arm_global_timer: fix suspend resume

[santosh shilimkar]

+ Thomas, Marc

On 11/20/2015 5:57 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 - SysRq are working, but
nothing else. The reason of stall is that ARM Global timer loses its
contexts.

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
- ensure clocksource and clockevent devices have coresponding flags
   (CLOCK_SOURCE_SUSPEND_NONSTOP and CLOCK_EVT_FEAT_C3STOP) set
   depending on presence of "always-on" DT property.


Something which loses context in low power states can't be
called "always-on"

Also if the clock-soucre can't tick in the low power states
then that device shouldn't be used as a clock-source.


CC: Arnd Bergmann <a...@arndb.de>
Cc: John Stultz <john.stu...@linaro.org>
Cc: Felipe Balbi <ba...@ti.com>
Cc: Tony Lindgren <t...@atomide.com>
Cc: Santosh Shilimkar <ssant...@kernel.org>
Signed-off-by: Grygorii Strashko <grygorii.stras...@ti.com>
---
Changes in v2:
  - suspend/resume simplified: nothing is stored any more and
ARM GT just re-enabled
Link on v1:
  https://lkml.org/lkml/2015/11/13/456

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

diff --git a/drivers/clocksource/arm_global_timer.c 
b/drivers/clocksource/arm_global_timer.c
index a2cb6fa..867e546 100644
--- a/drivers/clocksource/arm_global_timer.c
+++ b/drivers/clocksource/arm_global_timer.c
@@ -51,6 +51,7 @@ static void __iomem *gt_base;
  static unsigned long gt_clk_rate;
  static int gt_ppi;
  static struct clock_event_device __percpu *gt_evt;
+static bool gt_always_on;

  /*
   * To get the value from the Global Timer Counter register proceed as follows:
@@ -168,6 +169,9 @@ static int gt_clockevents_init(struct clock_event_device 
*clk)
  {
int cpu = smp_processor_id();

+   if (!gt_always_on)
+   clk->features |= CLOCK_EVT_FEAT_C3STOP;
+
clk->name = "arm_global_timer";
clk->features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT |
CLOCK_EVT_FEAT_PERCPU;
@@ -195,12 +199,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);
+}
+
  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
@@ -218,6 +229,9 @@ static void __init gt_clocksource_init(void)
/* enables timer on all the cores */
writel(GT_CONTROL_TIMER_ENABLE, gt_base + GT_CONTROL);

+   if (gt_always_on)
+   gt_clocksource.flags |= CLOCK_SOURCE_SUSPEND_NONSTOP;
+
  #ifdef CONFIG_CLKSRC_ARM_GLOBAL_TIMER_SCHED_CLOCK
sched_clock_register(gt_sched_clock_read, 64, gt_clk_rate);
  #endif
@@ -289,6 +303,8 @@ static void __init global_timer_of_register(struct 
device_node *np)
goto out_clk;
}

+   gt_always_on = of_property_read_bool(np, "always-on");
+
err = request_percpu_irq(gt_ppi, gt_clockevent_interrupt,
 "gt", gt_evt);
if (err) {


Am really confused with this patch. Because 'C3STOP' is a clock-event
flag which we use for cases where we have back-up broadcast timer which
continue to tick in low power states.

If the ARM global timer is considered as that device which actually
doesn't tick then we are doomed. Clocksource device must be *CONTINUOUS*
and if it is not then its not a viable device to be used as clock-source.

May be am missing the context but this whole patch doesn't make sense
to me.

Regards,
Santosh


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

[santosh shilimkar]

On 11/20/2015 10:46 AM, Marc Zyngier wrote:

On 20/11/15 18:35, Grygorii Strashko wrote:

Hi Santosh,

On 11/20/2015 07:23 PM, santosh shilimkar wrote:

+ Thomas, Marc

On 11/20/2015 5:57 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 - SysRq are working, but
nothing else. The reason of stall is that ARM Global timer loses its
contexts.

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
- ensure clocksource and clockevent devices have coresponding flags
(CLOCK_SOURCE_SUSPEND_NONSTOP and CLOCK_EVT_FEAT_C3STOP) set
depending on presence of "always-on" DT property.


Something which loses context in low power states can't be
called "always-on"


Sry, it's kinda new area for me and I could make mistakes.

While working on this patch I've:
  - re-used implementation from ARM arch timer
commit 82a5619410d4c4df65c04272db198eca5a867c18
Author: Lorenzo Pieralisi <lorenzo.pieral...@arm.com>
Date:   Tue Apr 8 10:04:32 2014 +0100

 clocksource: arch_arm_timer: Fix age-old arch timer C3STOP detection issue


[...]

This patch has a very specific purpose: instructing the core code that
this timer will never stop ticking, ever. It is really targeted at
virtual machines, whose timer is backed by the host timer, even when the
VM is not running.

Using it on actual hardware is may not be the best idea, specially in
the presence of PM.


Exactly. Thanks for clarifying the commit Marc.

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

Re: [PATCH] arm: omap2: Kconfig: select TWD and global timer on AM43xx devices

[santosh shilimkar]

On 11/18/2015 6:33 AM, Grygorii Strashko wrote:

On 11/13/2015 06:39 PM, santosh shilimkar wrote:

On 11/13/2015 5:07 AM, Mason wrote:

On 13/11/2015 13:48, Grygorii Strashko wrote:

On 11/12/2015 08:06 PM, Felipe Balbi wrote:

Make sure to tell the kernel that AM437x has
TWD and global timers.

Signed-off-by: Felipe Balbi <ba...@ti.com>
---

Hi Tony,

now that all dependencies are in place, we can
finally enable twd and global_timer for AM437x.


Is AM437x SMP SOC ?


No. But it has ARM TWD and GT


Is TWD on AM437x works in low power states ?


No. But TWD, seems, is not a problem here if omap gp timer
can be used as broadcast device.


Probably I haven't followed the recent updates, but does
the TWD supports C3STOP on UP systems ? The broadcast
code was SMP only in past, and TWD use to die in
low power state on past OMAP SOCs.

If either of these are still the issue then
TWD shouldn't be used.



Yep. I see the problem with ARM Global timer here if
CPUIdle is enabled and ARM Global timer is selected as
clocksource device.


Its expected and well known limitation.


I think, it will be right thing to disable "global_timer"
and "local_timer" nodes in am437x.dtsi by default - if
someone would like to use them then those nodes have
to be enabled explicitly in board file.
(TWD timer will be enabled on OMAP multi SoC build
  irrespectively of HAVE_ARM_TWD is selected for am437x or not,
  because it will be selected for omap4).
I've just sent corresponding patch:
  http://www.spinics.net/lists/arm-kernel/msg461141.html

Also, probably, it could be reasonable to:
- make ARM_GLOBAL_TIMER fully selectable option and allow select it from 
defconfig.

- or - update this patch as below
-   select ARM_GLOBAL_TIMER
-   select CLKSRC_ARM_GLOBAL_TIMER_SCHED_CLOCK
+   select ARM_GLOBAL_TIMER if !CPU_IDLE
+   select CLKSRC_ARM_GLOBAL_TIMER_SCHED_CLOCK if ARM_GLOBAL_TIMER



+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] arm: omap2: Kconfig: select TWD and global timer on AM43xx devices

[santosh shilimkar]

On 11/13/2015 5:07 AM, Mason wrote:

On 13/11/2015 13:48, Grygorii Strashko wrote:

On 11/12/2015 08:06 PM, Felipe Balbi wrote:

Make sure to tell the kernel that AM437x has
TWD and global timers.

Signed-off-by: Felipe Balbi 
---

Hi Tony,

now that all dependencies are in place, we can
finally enable twd and global_timer for AM437x.


Is AM437x SMP SOC ? Is TWD on AM437x works in low
power states ?
Probably I haven't followed the recent updates, but does
the TWD supports C3STOP on UP systems ? The broadcast
code was SMP only in past, and TWD use to die in
low power state on past OMAP SOCs.

If either of these are still the issue then
TWD shouldn't be used.

Regards,
Santosh


--
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] gpio: omap: fix debounce time calculation

[santosh shilimkar]

On 11/12/2015 11:33 AM, Felipe Balbi wrote:


Hi,

Grygorii Strashko  writes:

On 11/12/2015 08:09 PM, Felipe Balbi wrote:


Hi,

Grygorii Strashko  writes:

On 11/12/2015 07:50 PM, Felipe Balbi wrote:

According to TRM, debounce is measured in periods of
the functional clock of the GPIO IP. This means that



What TRM? link pls.

http://www.ti.com/lit/ug/spruhl7d/spruhl7d.pdf

28.4.1.24 GPIO_DEBOUNCINGTIME Register (offset = 154h) [reset = 0h]

The GPIO_DEBOUNCINGTIME register controls debouncing time (the value is
global for all ports). The debouncing cell is running with the
debouncing clock (32 kHz), this register represents the number of the
clock cycle(s) (31 s long) to be used.

Debouncing Value in 31 microsecond steps.
Debouncing Value = (DEBOUNCETIME + 1) * 31 microseconds.


DRA7xx:

"
8-bit values specifying the debouncing time. It is n-
periods of the muxed clock, which can come from either
a true 32k oscillator/pad of from the system clock. It
depends on which boot mode is selected. For more
information see Chapter 32, Initialization.
"



See
http://www.ti.com/lit/ug/spruhz6d/spruhz6d.pdf
27.4.3 General-Purpose Interface Clock Configuration
27.4.3.1 Clocking

This completely unclear. Sry, I think this patch can't be used as is,
first of all because of backward compatibility issues.


yeah, might be. No issues, I'll just go dig older TRMs and trying to
figure this one out. Meanwhile, let's let's keep it as is.


Just to be clear, being a common GPIO driver, it can't break
backward compatibility. So NAK for current patch.
If needed, please setup different debounce functions based
on GPIO IP numbers if it makes is efficient/accurate.

Regards,
Santosh

--
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] gpio: omap: Fix gpiochip_add() handling for deferred probe

[santosh shilimkar]

8/28/2015 11:44 AM, Tony Lindgren wrote:

Currently we gpio-omap breaks if gpiochip_add() returns -EPROBE_DEFER:

[0.57] gpiochip_add: GPIOs 0..31 (gpio) failed to register
[0.57] omap_gpio 4831.gpio: Could not register gpio chip -517
...
[3.67] omap_gpio 4831.gpio: Unbalanced pm_runtime_enable!

Let's fix the issue by adding the missing pm_runtime_put() on error.

Cc: Grygorii Strashko grygorii.stras...@ti.com
Cc: Javier Martinez Canillas jav...@dowhile0.org
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Santosh Shilimkar ssant...@kernel.org
Signed-off-by: Tony Lindgren t...@atomide.com
---
  drivers/gpio/gpio-omap.c | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)


Acked-by: Santosh Shilimkar ssant...@kernel.org
--
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/7] gpio: omap: fixes and improvements

[santosh shilimkar]

On 8/18/2015 4:10 AM, Grygorii Strashko wrote:

Hi,

This patch series contains set of trivial fixes and improvements, and also
patches which fixes wrong APIs usage in atomic context as for -RT as for
non-RT kernel. The final goal of this series is to make TI OMAP GPIO
driver compatible with -RT kernel as much as possible.

Patch 1-4: trivial fixes and improvements
Patch 5: fixes wrong CLK clk_prepare/unprepare APIs usage in atomic contexet
Patch 6(rfc): required to be compatible with -RT kernel, because PM runtime
  can't be used in atimic context on -RT.
Patch 7(rfc): This patch converts TI OMAP GPIO driver to use generic irq
  handler instead of chained IRQ handler. This way OMAP GPIO driver will be
  compatible with RT kernel where it will be forced thread IRQ handler
  while in non-RT kernel it still will be executed in HW IRQ context.

Based on
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git
branch: devel
commit: 929550b gpio: mxc: fix section mismatch warning

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

Grygorii Strashko (7):
   gpio: omap: remove wrong irq_domain_remove usage in probe
   gpio: omap: switch to use platform_get_irq
   gpio: omap: fix omap2_set_gpio_debounce
   gpio: omap: protect regs access in omap_gpio_irq_handler
   gpio: omap: fix clk_prepare/unprepare usage
   gpio: omap: move pm runtime in irq_chip.irq_bus_lock/sync_unlock
   gpio: omap: convert to use generic irq handler

  drivers/gpio/gpio-omap.c | 146 +++
  1 file changed, 85 insertions(+), 61 deletions(-)


Patch 1 to 5 looks fine to me. You can have that one as a series.
Am not convinced about 6 and 7. Will look at it again in detail.

For 1 to 5,
Acked-by: Santosh Shilimkar ssant...@kernel.org
--
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 REPOST] gpio: omap: use raw locks for locking

[santosh shilimkar]

On 6/19/2015 10:06 AM, Sebastian Andrzej Siewior wrote:

This patch converts gpio_bank.lock from a spin_lock into a
raw_spin_lock. The call path is to access this lock is always under a
raw_spin_lock, for instance
- __setup_irq() holds desc-lock with irq off
   + __irq_set_trigger()
+ omap_gpio_irq_type()

- handle_level_irq() (runs with irqs off therefore raw locks)
   + mask_ack_irq()
+ omap_gpio_mask_irq()

This fixes the obvious backtrace on -RT. However the locking vs context
is not and this is not limited to -RT:
- omap_gpio_irq_type() is called with IRQ off and has an conditional
   call to pm_runtime_get_sync() which may sleep. Either it may happen or
   it may not happen but pm_runtime_get_sync() should not be called with
   irqs off.

- omap_gpio_debounce() is holding the lock with IRQs off.
   + omap2_set_gpio_debounce()
+ clk_prepare_enable()
 + clk_prepare() this one might sleep.
   The number of users of gpiod_set_debounce() / gpio_set_debounce()
   looks low but still this is not good.

Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---

Should be safe to do it.
Acked-by: Santosh Shilimkar ssant...@kernel.org

--
To unsubscribe from this list: send the line unsubscribe linux-omap in

Re: [RFC/RFT PATCH 0/7] gpio: omap: rework and fixes

[santosh shilimkar]

On 6/1/2015 6:15 AM, Linus Walleij wrote:

On Fri, May 22, 2015 at 9:03 PM, Tony Lindgren t...@atomide.com wrote:

* Grygorii Strashko grygorii.stras...@linaro.org [150522 07:37]:



Patches 1-5 seem to work for me, patch 6 does not.
So for patches 1-5, please feel free to add:

Tested-by: Tony Lindgren t...@atomide.com


OK I take this as an excuse to apply patches 1-5 with
Tony's test tag.

The maintainers can cheer in if they want, I will
anyway take the OMAP maintainers test tag as
a good quality indication.


Cheers for patch 1-5 ;-)

Acked-by: Santosh Shilimkar ssant...@kernel.org
--
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/3] Introduce SET_NOIRQ_SYSTEM_SLEEP_PM_OPS and use it

[santosh shilimkar]

On 4/27/2015 11:24 AM, grygorii.stras...@linaro.org wrote:

From: Grygorii Strashko grygorii.stras...@linaro.org

While working on suspend-to-disk functionality on TI dra7-evm (DRA7xx SoC)
i've found that the most common problem I have to dial with is absence
of corresponding PM callbacks in drivers and, in particular, noirq callbacks.
So, I've fixed one driver first
commit 6248015d6867 ARM: omap-device: add missed callback for suspend-to-disk
but then found another one which need to be fixed too (omap_l3_noc.c).
At this moment I decided to make my life easier and added new macro
SET_NOIRQ_SYSTEM_SLEEP_PM_OPS using the same approach as for the existing
SET_SYSTEM_SLEEP_PM_OPS macro.

SET_NOIRQ_SYSTEM_SLEEP_PM_OPS: defined for CONFIG_PM_SLEEP and
assigns -suspend_noirq, -freeze_noirq and -poweroff_noirq to the same
function. Vice versa happens for -resume_noirq, -thaw_noirq and
-restore_noirq.

Further two patches reuse this newly introduced macro.

SET_NOIRQ_SYSTEM_SLEEP_PM_OPS, defined for CONFIG_PM_SLEEP, will
 point -suspend_noirq, -freeze_noirq and -poweroff_noirq to the same
 function. Vice versa happens for -resume_noirq, -thaw_noirq and
 -restore_noirq.


[...]



Grygorii Strashko (3):
   PM / Sleep: Add macro to define common noirq system PM callbacks
   bus: omap_l3_noc: add missed callbacks for suspend-to-disk
   ARM: omap-device: use SET_NOIRQ_SYSTEM_SLEEP_PM_OPS

  arch/arm/mach-omap2/omap_device.c |  7 ++-
  drivers/bus/omap_l3_noc.c |  4 ++--
  include/linux/pm.h| 12 
  3 files changed, 16 insertions(+), 7 deletions(-)


Looks fine to me.
Acked-by: Santosh Shilimkar ssant...@kernel.org
--
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] gpio: omap: Allow building as a loadable module

[santosh shilimkar]

On 4/23/2015 4:56 PM, Tony Lindgren wrote:

We currently get all kinds of errors building the omap gpio driver
as a module starting with:

undefined reference to `omap2_gpio_resume_after_idle'
undefined reference to `omap2_gpio_prepare_for_idle'
...

Let's fix the issue by adding inline functions to the header.
Note that we can now also remove the two unused functions for
omap_set_gpio_debounce and omap_set_gpio_debounce_time.

Then doing rmmod on the module produces further warnings
because of missing exit related functions. Let's add those.

And finally, we can make the Kconfig entry just a tristate
option that's selected for omaps.

Cc: Felipe Balbi ba...@ti.com
Cc: Javier Martinez Canillas jav...@dowhile0.org
Cc: Grygorii Strashko grygorii.stras...@linaro.org
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Nishanth Menon n...@ti.com
Cc: Santosh Shilimkar ssant...@kernel.org
Signed-off-by: Tony Lindgren t...@atomide.com
---
  drivers/gpio/Kconfig|  2 +-
  drivers/gpio/gpio-omap.c| 24 
  include/linux/platform_data/gpio-omap.h | 12 ++--
  3 files changed, 35 insertions(+), 3 deletions(-)


That platform header needs serious clean-up and we now
add two more inlines there.

But, being able to use gpio as loadable module
might be good enough reason to take this one.

Acked-by: Santosh Shilimkar ssant...@kernel.org

--
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] gpio: omap: Fix regression for MPUIO interrupts

[santosh shilimkar]

On 4/23/2015 4:54 PM, Tony Lindgren wrote:

At some point with all the GPIO clean-up we've broken the
MPUIO interrupts. Those are just a little bit different from
the GPIO interrupts, so we can fix it up just by setting
different irqchip functions for it. And then we can just
remove all old code trying to do the same.

Cc: Aaro Koskinen aaro.koski...@iki.fi
Cc: Felipe Balbi ba...@ti.com
Cc: Javier Martinez Canillas jav...@dowhile0.org
Cc: Grygorii Strashko grygorii.stras...@linaro.org
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Nishanth Menon n...@ti.com
Cc: Santosh Shilimkar ssant...@kernel.org
Signed-off-by: Tony Lindgren t...@atomide.com
---

Acked-by: Santosh Shilimkar ssant...@kernel.org
--
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/5] PM / clock_ops: provide default runtime ops and cleanup users

[santosh shilimkar]

On 4/24/2015 7:41 AM, Rafael J. Wysocki wrote:

On Thursday, April 23, 2015 02:03:08 PM Rajendra Nayak wrote:

Most users of PM clocks do the exact same thing in runtime callbacks.
Provide default callbacks and cleanup the existing users (keystone/davinci
/omap1/sh)

Rajendra Nayak (5):
   PM / clock_ops: Provide default runtime ops to users
   arm: keystone: remove boilerplate code and use USE_PM_CLK_RUNTIME_OPS
   arm: omap1: remove boilerplate code and use USE_PM_CLK_RUNTIME_OPS
   arm: davinci: remove boilerplate code and use USE_PM_CLK_RUNTIME_OPS
   drivers: sh: remove boilerplate code and use USE_PM_CLK_RUNTIME_OPS

  arch/arm/mach-davinci/pm_domain.c  | 32 +-
  arch/arm/mach-keystone/pm_domain.c | 33 +-
  arch/arm/mach-omap1/pm_bus.c   | 37 ++
  drivers/base/power/clock_ops.c | 38 ++
  drivers/sh/pm_runtime.c| 47 ++
  include/linux/pm_clock.h   | 10 
  6 files changed, 54 insertions(+), 143 deletions(-)


It is not particularly clear to me who is supposed to apply this series, but
I can do that if people don't have problems with that.



I am fine by that given dependency with first patch.
Another way is, you pick up the first patch and give us an
immutable branch.

Either way is fine by me.


Regards,
Santosh
--
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 0/5] PM / clock_ops: provide default runtime ops and cleanup users

[santosh shilimkar]

On 4/20/2015 4:21 PM, Kevin Hilman wrote:

Rajendra Nayak rna...@codeaurora.org writes:


Most users of PM clocks do the exact same thing in runtime callbacks.


Probably because they were all copied from mach-davinci. ;)


Yep. ;-)


Provide default callbacks and cleanup the existing users 
(keystone/davinci/omap1/sh)


Very nice cleanup, Thanks!


Indeed !!
I can't test it out but from the series, I don't expect anything
to break. So looks good to me as well.


For the series:

Reviewed-by: Kevin Hilman khil...@linaro.org


Acked-by: Santosh Shilimkar ssant...@kernel.org
--
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: remove dead kconfig option OMAP4_ERRATA_I688

[santosh shilimkar]

On 3/16/2015 4:30 PM, Tony Lindgren wrote:

* Stefan Hengelein stefan.hengel...@fau.de [150225 10:48]:

The Kconfig-Option OMAP4_ERRATA_I688 is never visible due to a
contradiction in it's dependencies.
The option requires ARCH_MULTIPLATFORM to be 'disabled'. However, an
enclosing menu requires either ARCH_MULTI_V6 or ARCH_MULTI_V7 to be
enabled. These options inherit a dependency from an enclosing menu,
that requires ARCH_MULTIPLATFORM to be 'enabled'.
This is a contradiction and made this option also unavailable for
non-multiplatform configurations.

Since there are no selects on OMAP4_ERRATA_I688, which would ignore
dependencies, the code related to that option is dead and can be
removed.

This (logical) defect has been found with the undertaker tool.
(https://undertaker.cs.fau.de)

Signed-off-by: Stefan Hengelein stefan.hengel...@fau.de

---
Tony Lindgren suggested to remove the code since nobody complained for
a few years and Santosh Shilimkar agreed.
https://lkml.org/lkml/2015/2/25/449
---
As far as I see, this should remove all the code related to
OMAP4_ERRATA_I688, I hope I didn't remove too much.


Seems to boot fine, so applying into omap-for-v4.1/fixes-not-urgent.


Acked-by: Santosh Shilimkar ssant...@kernel.org
--
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: Dead Kconfig Option OMAP4_ERRATA_I688

[santosh shilimkar]

On 2/25/2015 9:14 AM, Tony Lindgren wrote:

Hi,

Adding Santosh to Cc on this one.

* Stefan Hengelein stefan.hengel...@fau.de [150225 09:13]:

During the research for my masters thesis i came across the
OMAP4_ERRATA_I688 option and realized, it is never possible to enable
this option.

The a62a6e98 commit added the  !ARCH_MULTIPLATFORM dependency to
disable this option for multiplatforms. However, because of enclosing
dependencies, this option isn't available for non-MULTIPLATFORM
configurations either.


Yes there is no clean way currently to enable this errata for
multiplatform.


Right.To fix this, the barrier code needs to be run-time patched.


CONFIG_OMAP4_ERRATA_I688 is defined in the menu TI OMAP/AM/DM/DRA
Family which depends on ARCH_MULTI_V6 || ARCH_MULTI_V7. (in
arch/arm/mach-omap2/Kconfig)

ARCH_MULTI_V6 and ARCH_MULTI_V7 however are defined in the menu
Multiple platform selection which depends on ARCH_MULTIPLATFORM (in
arch/arm/Kconfig)

Which is a contradiction.

There are no selects on OMAP4_ERRATA_I688, which would ignore
dependencies, either.

The question is:
Was disabling this option for non-MULTIPLATFORM configurations also intentional?

i have added a minimal example of the problem.


 From what I remember the plan was to try to come up with a
multiplatform friendly way of doing this errata. Santosh,
any suggestions here? Should we just remove the code as it
seems nobody has complained about it for a few years now?


I have to agree to with you on this.

Regards,
Santosh
--
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 v5 0/7] irqchip: Move OMAP{4,5}/DRA7 to use stacked domains

[santosh shilimkar]

On 2/23/2015 9:44 AM, Marc Zyngier wrote:

This series is extracted from [4], which is trying to remove all
traces of gic_arch_extn from the tree. As some maintainers are more
responsive than others (understatement of the year...), I've decided
to split it per sub-arch, and get it moving, at least partially.

This series addresses OMAP{4,5} by converting the WUGEN to stacked
domains. The DRA7 crossbar gets the same treatment.

It is worth realizing that:

- I haven't been able to test this as much as I would have wanted to
   (it's only been tested on omap4 and omap5).

- This actively *breaks* existing setups. Once you boot a new kernel
   with an old DT, suspend/resume *will* be broken. Old kernels on a
   new DT won't even boot! You've been warned. This really outline the
   necessity of actually describing the HW in device trees...

Based on 4.0-rc1.

* From v4: [4]
- Extracted from the full series
- Rebased on 4.0-rc1

* From v3 [3]:
- Rebased on top of the patch working around hardcoded IRQ on OMAP4/5 [4]
- Fixed more iMX6 DTs (Stephan)
- Fixed Exynos4/5 DTs

* From v2 [2]:
- Addressed numerous comments from Thierry
- Merged bug fixes from Nishanth
- Merged bug fix from Stefan

* From v1 [1]:
- Rebased on 3.19-rc3
- Fixed a number of additional platforms
- Added crossbar conversion to stacked domains
- Merged bug fixes from Nishanth

[4]: 
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/317531.html
[3]: 
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/315385.html
[2]: 
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/314041.html
[1]: 
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/307338.html

Marc Zyngier (7):
   genirq: Add irqchip_set_wake_parent
   irqchip: crossbar: convert dra7 crossbar to stacked domains
   DT: update ti,irq-crossbar binding
   irqchip: GIC: get rid of routable domain
   DT: arm,gic: kill arm,routable-irqs
   DT: omap4/5: add binding for the wake-up generator
   ARM: omap: convert wakeupgen to stacked domains


Acked-by: Santosh Shilimkar ssant...@kernel.org
--
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 13/21] ARM: omap: convert wakeupgen to stacked domains

[santosh shilimkar]

On 1/21/2015 10:36 AM, Tony Lindgren wrote:

* Marc Zyngier marc.zyng...@arm.com [150121 09:25]:

On 21/01/15 16:30, Tony Lindgren wrote:


I gave this a quick boot test on am437x-gp-evm and the
interrupts look OK with the fix also applied:

# cat /proc/interrupts
 CPU0
  16:657 WUGEN  68  gp_timer
  18:  0 WUGEN   9  l3-dbg-irq
  19:  0 WUGEN  10  l3-app-irq
  20:  5 WUGEN  12  edma
  22:  0 WUGEN  14  edma_error
  23: 96 WUGEN  72  OMAP UART0
  33:  0  44e07000.gpio   6  mmc0
158: 52 WUGEN  70  44e0b000.i2c
159:  0 WUGEN  71  4802a000.i2c
160: 35 WUGEN  64  mmc0
161:  0 WUGEN  40  4a10.ethernet
162:   7739 WUGEN  41  4a10.ethernet
163:   7608 WUGEN  42  4a10.ethernet
164:  0 WUGEN  43  4a10.ethernet
170:  0 WUGEN 100  gpmc
180:  0 WUGEN   7  tps65218
IPI0:  0  CPU wakeup interrupts
IPI1:  0  Timer broadcast interrupts
IPI2:  0  Rescheduling interrupts
IPI3:  0  Function call interrupts
IPI4:  0  Single function call interrupts
IPI5:  0  CPU stop interrupts
IPI6:  0  IRQ work interrupts
IPI7:  0  completion interrupts
Err:  0


Interesting. No TWD timer on this one?


Good question, adding Felipe to cc. It eems to be there in
the TRM in Table 2-3.  L4_PER Peripheral Memory Map as
MPU_PRV_TIMERS. Also seems to actually work with the
attached patch:


TWD is useless on this machine since single core and TWD
as know die in low power states. All the broadcast stuff
is for SMP machines.

Above is expected and correct and no patching is needed.

Regards,
Santosh
--
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 13/21] ARM: omap: convert wakeupgen to stacked domains

[santosh shilimkar]

On 1/21/2015 12:43 PM, Tony Lindgren wrote:

* santosh shilimkar santosh.shilim...@oracle.com [150121 12:16]:

On 1/21/2015 10:36 AM, Tony Lindgren wrote:

* Marc Zyngier marc.zyng...@arm.com [150121 09:25]:

On 21/01/15 16:30, Tony Lindgren wrote:


I gave this a quick boot test on am437x-gp-evm and the
interrupts look OK with the fix also applied:

# cat /proc/interrupts
 CPU0
  16:657 WUGEN  68  gp_timer
  18:  0 WUGEN   9  l3-dbg-irq
  19:  0 WUGEN  10  l3-app-irq
  20:  5 WUGEN  12  edma
  22:  0 WUGEN  14  edma_error
  23: 96 WUGEN  72  OMAP UART0
  33:  0  44e07000.gpio   6  mmc0
158: 52 WUGEN  70  44e0b000.i2c
159:  0 WUGEN  71  4802a000.i2c
160: 35 WUGEN  64  mmc0
161:  0 WUGEN  40  4a10.ethernet
162:   7739 WUGEN  41  4a10.ethernet
163:   7608 WUGEN  42  4a10.ethernet
164:  0 WUGEN  43  4a10.ethernet
170:  0 WUGEN 100  gpmc
180:  0 WUGEN   7  tps65218
IPI0:  0  CPU wakeup interrupts
IPI1:  0  Timer broadcast interrupts
IPI2:  0  Rescheduling interrupts
IPI3:  0  Function call interrupts
IPI4:  0  Single function call interrupts
IPI5:  0  CPU stop interrupts
IPI6:  0  IRQ work interrupts
IPI7:  0  completion interrupts
Err:  0


Interesting. No TWD timer on this one?


Good question, adding Felipe to cc. It eems to be there in
the TRM in Table 2-3.  L4_PER Peripheral Memory Map as
MPU_PRV_TIMERS. Also seems to actually work with the
attached patch:


TWD is useless on this machine since single core and TWD
as know die in low power states. All the broadcast stuff
is for SMP machines.


Hmm it seems we should still use TWD during runtime and
swich over to the gptimer for idle states for wake-up
events.


Well timer wheel code don't support it so if you are serious,
some one needs to do that. For me, it is not worth at all.
You will have more to loose than gain with these time switching
schemes since you have to keep 2 times alive, do switching, loose
the idle time.

All of that is to save few CPU cycles since TWD is closer
compared to other SOC timer.

Anyways I will let you fight it out but IIRC, I had a
discussion a while back with tglx in one of the conference
and the conclusion was it not worth doing.
Rather TWD hardware on SOC should be made wakeup capable
and then everything is good.

Till you have support, using TWD on AM43XX will break CPUIDLE.
Not sure if it is supported or some one cares about it. Just
keep that aspect in mind.

Regards,
Santosh
--
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/1] gpio: omap: Fix bad device access with setup_irq()

[santosh shilimkar]

On 1/16/2015 2:50 PM, Tony Lindgren wrote:

Similar to omap_gpio_irq_type() let's make sure that the GPIO
is usable as an interrupt if the platform init code did not
call gpio_request(). Otherwise we can get invalid device access
after setup_irq():


I let Linus W comment on it but IIRC we chewed this issue last
time and the conclusion was the gpio_request() must have to be called
directly or indirectly in case of irq line.

One old thread on possibly similar issue is here[1]



WARNING: CPU: 0 PID: 1 at drivers/bus/omap_l3_noc.c:147 
l3_interrupt_handler+0x214/0x340()
4400.ocp:L3 Custom Error: MASTER MPU TARGET L4CFG (Idle): Data Access in 
Supervisor mode during Functional access
...
[c05f21e4] (__irq_svc) from [c05f1974] 
(_raw_spin_unlock_irqrestore+0x34/0x44)
[c05f1974] (_raw_spin_unlock_irqrestore) from [c00914a8] 
(__setup_irq+0x244/0x530)
[c00914a8] (__setup_irq) from [c00917d4] (setup_irq+0x40/0x8c)
[c00917d4] (setup_irq) from [c0039c8c] (omap_system_dma_probe+0x1d4/0x2b4)
[c0039c8c] (omap_system_dma_probe) from [c03b2200] 
(platform_drv_probe+0x44/0xa4)
...

We can fix this the same way omap_gpio_irq_type() is handling it.

Note that the long term solution is to change the gpio-omap driver
to handle the banks as separate driver instances. This will allow
us to rely on just runtime PM for tracking the bank specific state.

Reported-by: Russell King rmk+ker...@arm.linux.org.uk
Cc: Felipe Balbi ba...@ti.com
Cc: Javier Martinez Canillas jav...@dowhile0.org
Cc: Kevin Hilman khil...@kernel.org
Cc: Linus Walleij linus.wall...@linaro.org
Cc: Russell King - ARM Linux li...@arm.linux.org.uk
Cc: Santosh Shilimkar ssant...@kernel.org
Signed-off-by: Tony Lindgren t...@atomide.com
---
  drivers/gpio/gpio-omap.c | 39 +--
  1 file changed, 33 insertions(+), 6 deletions(-)

Is it really OMAP specific issue ? On OMAP, clocks needs to enabled for 
GPIO's to work which is what the init is doing but I believe the same

should apply to other GPIO controllers as well.

regards,
Santosh

[1] https://lkml.org/lkml/2013/8/27/509

--
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 00/21] irqchip: gic: killing gic_arch_extn and co, slowly

[santosh shilimkar]

Marc,

On 1/7/2015 9:42 AM, Marc Zyngier wrote:

The gic_arch_extn hack that a number of platform use has been nagging
me for too long. It is only there for the benefit of a few platform,
and yet it impacts all GIC users. Moreover, it gives people the wrong
idea (let's use it to put some new custom hack in there...).

But now that stacked irq domains have landed in -next, the time has
come for gic_arch_extn to meet the Big Bit Bucket.

This patch series takes several steps towards the elimination of
gic_arch_extn:

- moves Tegra's legacy interrupt controller support to
   drivers/irqchip, implementing a stacked domain on top of the
   standard GIC.

- OMAP, imx6 and exynos are also converted to stacked domains, but
   their implementation is left in place (the code is far too
   intricately mixed with other details of the platform for me to even
   try to move it). Some OMAP variants get a special treatment as we
   also kill the crossbar horror (more on that below).

- shmobile, ux500 and zynq are only slightly modified.

- The GIC itself is cleaned up, and some other bits and bobs are
   adjusted for a good measure.

About the TI crossbar:

- The allocation of interrupts in this domain is fairly similar to
   what we do for MSI (see the GICv2m driver), and stacked domains have
   proved to be a fitting solution.

- The current description in DT is currently entierely inaccurate, and
   as we already broke it for the OMAP WUGEN block, we might as well do
   it again for the TI crossbar.

- The way crossbar, WUGEN and GIC interract is quite complex (this is
   effectively a stack of three interrupt controllers with interesting
   exceptions and braindead routing), and stacked domains are the right
   abstraction for that.

- Other platforms (Freescale Vybrid) are starting to come up with the
   same type of things, and it'd be good to avoid them following the
   same broken model.

- It removes a few lines from the code base so it can't completely be
   a bad idea!

So this patch series does exactly that: make the crossbar a stacked
interrupt controller that only takes care of setting up the routing,
fix the DTs to represent the actual HW, and remove a bit of the
craziness from the GIC code.

It is worth realizing that:

- I haven't been able to test this as much as I would have wanted to
   (it's only been tested on tegra2 and omap5).

- I've created DT bindings when needed, updated existing ones, but I
   haven't created a binding for platforms that already used an
   undocumented one (imx6, I'm looking at you).

- I've relaxed quite a bit of the locking in the GIC code. I believe
   this is safe, but someone else should give it a long hard look.

- This actively *breaks* existing setups. Once you boot a new kernel
   with an old DT, suspend/resume *will* be broken. Old kernels on a
   new DT won't even boot! You've been warned. This really outline the
   necessity of actually describing the HW in device trees...

As for the patches, they are on top of 3.19-rc3.

I've pushed the code to:
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git 
irq/die-gic-arch-extn-die-die-die

Comments welcome,

 M.

Marc Zyngier (21):
   ARM: tegra: irq: nuke leftovers from non-DT support
   irqchip: tegra: add DT-based support for legacy interrupt controller
   ARM: tegra: skip gic_arch_extn setup if DT has a LIC node
   ARM: tegra: update DTs to expose legacy interrupt controller
   DT: tegra: add binding for the legacy interrupt controller
   ARM: tegra: remove old LIC support
   genirq: Add irqchip_set_wake_parent
   irqchip: crossbar: convert dra7 crossbar to stacked domains
   DT: update ti,irq-crossbar binding
   irqchip: GIC: get rid of routable domain
   DT: arm,gic: kill arm,routable-irqs
   ARM: omap: convert wakeupgen to stacked domains
   DT: omap4/5: add binding for the wake-up generator
   ARM: imx6: convert GPC to stacked domains
   ARM: exynos4/5: convert pmu wakeup to stacked domains
   DT: exynos: update PMU binding
   irqchip: gic: add an entry point to set up irqchip flags
   ARM: shmobile: remove use of gic_arch_extn.irq_set_wake
   ARM: ux500: switch from gic_arch_extn to gic_set_irqchip_flags
   ARM: zynq: switch from gic_arch_extn to gic_set_irqchip_flags
   irqchip: gic: Drop support for gic_arch_extn


Thanks a lot for killing those gic_arch_extn and cross-bar with
newly added stacked domains. It cleans up the GIC code for better.
Feel free to add my ack if you need one.

Acked-by: Santosh Shilimkar ssant...@kernel.org

Regards,
Snatosh
--
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 / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM

[santosh shilimkar]

On 12/5/2014 6:50 PM, Rafael J. Wysocki wrote:

From: Rafael J. Wysocki rafael.j.wyso...@intel.com

After commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is
selected) PM_RUNTIME is always set if PM is set, so #ifdef blocks
depending on CONFIG_PM_RUNTIME may now be changed to depend on
CONFIG_PM.

Replace CONFIG_PM_RUNTIME with CONFIG_PM everywhere in the code under
arch/arm/ (the defconfig files will be modified later).

Signed-off-by: Rafael J. Wysocki rafael.j.wyso...@intel.com
---

Note: This depends on commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if
PM_SLEEP is selected) which is only in linux-next at the moment (via the
linux-pm tree).

Please let me know if it is OK to take this one into linux-pm.

---



  arch/arm/mach-keystone/pm_domain.c |2 +-


Looks fine to me. For keystone parts.

Acked-by: Santosh Shilimkar ssant...@kernel.org
--
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/7] ARM: OMAP4+: powerdomain fixes

[Santosh Shilimkar]

On Friday 22 August 2014 09:49 AM, Nishanth Menon wrote:
 Hi,
 
 The following series are various fixes and improvements for
 powerdomain support in OMAP4+.
 
 This is part 1/6 series which eventually enables framework for
 suspend-to-ram and cpuidle for OMAP5 and DRA7
 
 Each of series is based on v3.17-rc1 and this specific series is available:
 weblink: 
 https://github.com/nmenon/linux-2.6-playground/commits/push/v3.17/powerdomain-fixes

Series looks good to me. The achievable power state doesn't apeal much but with 
so many
variations of SOCs, descopes etc, it probably makes sense.

Once you update Kevin's BUG() comments, feel free to add my ack.

Regards,
Santosh
 

--
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/6] ARM: OMAP3+: PRM: fix up prm_handling

[Santosh Shilimkar]

On Friday 22 August 2014 09:51 AM, Nishanth Menon wrote:
 The following series are various fixes and improvements for
 PRM for I/O Daisy chain support in OMAP4+ with device tree.
 
 This is part 2/6 series which eventually enables framework for
 suspend-to-ram and cpuidle for OMAP5 and DRA7
 
 Each of series is based on v3.17-rc1 and this specific series is available:
 weblink: 
 https://github.com/nmenon/linux-2.6-playground/commits/push/v3.17/prm-fixes
 

Series also looks reasonable.
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com

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

Re: [PATCH 07/10] ARM: OMAP5 / DRA7: Enable CPU RET on suspend

[Santosh Shilimkar]

On Wednesday 27 August 2014 03:41 PM, Tony Lindgren wrote:
 * Nishanth Menon n...@ti.com [140827 12:05]:
 On 08/27/2014 01:58 PM, Kevin Hilman wrote:
 Nishanth Menon n...@ti.com writes:

 From: Rajendra Nayak rna...@ti.com

 On OMAP5 / DRA7, prevent a CPU powerdomain OFF and resulting MPU OSWR
 and instead attempt a CPU RET and side effect, MPU RET in suspend.

 Signed-off-by: Rajendra Nayak rna...@ti.com
 [n...@ti.com: update to do save_state only on DRA7]
 Signed-off-by: Nishanth Menon n...@ti.com
 ---
  arch/arm/mach-omap2/omap-mpuss-lowpower.c |4 
  arch/arm/mach-omap2/omap-wakeupgen.c  |2 +-
  arch/arm/mach-omap2/pm44xx.c  |9 +++--
  3 files changed, 12 insertions(+), 3 deletions(-)

 diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c 
 b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
 index 207fce2..0d640eb 100644
 --- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
 +++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
 @@ -242,6 +242,10 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned 
 int power_state)
save_state = 1;
break;
case PWRDM_POWER_RET:
 +  if (soc_is_omap54xx() || soc_is_dra7xx()) {

 Aren't we trying to get away from these soc_* checks for anything other
 than init code?

 I would expect that to take place in stages as part of which the next
 level of cleanup is to move PRM into drivers. Currently our wakeupgen,
 prm code does have quiet a few needs of dealing with soc_is checks
 primarily from having to re-architect code in two different directions
 - we want to move into just one direction eventually - to prm drivers
 and as less code in mach-omap2 which is already in the works.
 
 Why don't you just set some flag at init time based on the
 soc_is check and then test that here? That limits the use of
 soc_is to init code only which makes it easier to phase it
 out completely eventually.
 
Indeed. Infact the version of the code I tried posting last year was
using a flag which was initialised during init. Same can be
done her.

Regards,
Santosh

--
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] gpio: omap: Fix interrupt names

[Santosh Shilimkar]

On Thursday 21 August 2014 09:19 AM, Nishanth Menon wrote:
 When viewing the /proc/interrupts, there is no information about which
 GPIO bank a specific gpio interrupt is hooked on to. This is more than a
 bit irritating as such information can esily be provided back to the
 user and at times, can be crucial for debug.
 
 So, instead of displaying something like:
 31:   0   0  GPIO   0  palmas
 32:   0   0  GPIO  27  mmc0
 
 Display the following with appropriate device name:
 31:   0   0  4ae1.gpio   0  palmas
 32:   0   0  4805d000.gpio  27  mmc0
 
 This requires that we create irq_chip instance specific for each GPIO
 bank which is trivial to achieve.
 
 Signed-off-by: Nishanth Menon n...@ti.com
 ---
 based on v3.17-rc1
Looks good..
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com

  drivers/gpio/gpio-omap.c |   31 +--
  1 file changed, 17 insertions(+), 14 deletions(-)
 
 diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
 index 1749321..aee25fa 100644
 --- a/drivers/gpio/gpio-omap.c
 +++ b/drivers/gpio/gpio-omap.c
 @@ -857,16 +857,6 @@ static void omap_gpio_unmask_irq(struct irq_data *d)
   spin_unlock_irqrestore(bank-lock, flags);
  }
  
 -static struct irq_chip gpio_irq_chip = {
 - .name   = GPIO,
 - .irq_shutdown   = omap_gpio_irq_shutdown,
 - .irq_ack= omap_gpio_ack_irq,
 - .irq_mask   = omap_gpio_mask_irq,
 - .irq_unmask = omap_gpio_unmask_irq,
 - .irq_set_type   = omap_gpio_irq_type,
 - .irq_set_wake   = omap_gpio_wake_enable,
 -};
 -
  /*-*/
  
  static int omap_mpuio_suspend_noirq(struct device *dev)
 @@ -1088,7 +1078,7 @@ omap_mpuio_alloc_gc(struct gpio_bank *bank, unsigned 
 int irq_start,
  IRQ_NOREQUEST | IRQ_NOPROBE, 0);
  }
  
 -static int omap_gpio_chip_init(struct gpio_bank *bank)
 +static int omap_gpio_chip_init(struct gpio_bank *bank, struct irq_chip *irqc)
  {
   int j;
   static int gpio;
 @@ -1137,7 +1127,7 @@ static int omap_gpio_chip_init(struct gpio_bank *bank)
   }
  #endif
  
 - ret = gpiochip_irqchip_add(bank-chip, gpio_irq_chip,
 + ret = gpiochip_irqchip_add(bank-chip, irqc,
  irq_base, omap_gpio_irq_handler,
  IRQ_TYPE_NONE);
  
 @@ -1147,7 +1137,7 @@ static int omap_gpio_chip_init(struct gpio_bank *bank)
   return -ENODEV;
   }
  
 - gpiochip_set_chained_irqchip(bank-chip, gpio_irq_chip,
 + gpiochip_set_chained_irqchip(bank-chip, irqc,
bank-irq, omap_gpio_irq_handler);
  
   for (j = 0; j  bank-width; j++) {
 @@ -1172,6 +1162,7 @@ static int omap_gpio_probe(struct platform_device *pdev)
   const struct omap_gpio_platform_data *pdata;
   struct resource *res;
   struct gpio_bank *bank;
 + struct irq_chip *irqc;
   int ret;
  
   match = of_match_device(of_match_ptr(omap_gpio_match), dev);
 @@ -1186,6 +1177,18 @@ static int omap_gpio_probe(struct platform_device 
 *pdev)
   return -ENOMEM;
   }
  
 + irqc = devm_kzalloc(dev, sizeof(*irqc), GFP_KERNEL);
 + if (!irqc)
 + return -ENOMEM;
 +
 + irqc-irq_shutdown = omap_gpio_irq_shutdown,
 + irqc-irq_ack = omap_gpio_ack_irq,
 + irqc-irq_mask = omap_gpio_mask_irq,
 + irqc-irq_unmask = omap_gpio_unmask_irq,
 + irqc-irq_set_type = omap_gpio_irq_type,
 + irqc-irq_set_wake = omap_gpio_wake_enable,
 + irqc-name = dev_name(pdev-dev);
 +
   res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
   if (unlikely(!res)) {
   dev_err(dev, Invalid IRQ resource\n);
 @@ -1241,7 +1244,7 @@ static int omap_gpio_probe(struct platform_device *pdev)
  
   omap_gpio_mod_init(bank);
  
 - ret = omap_gpio_chip_init(bank);
 + ret = omap_gpio_chip_init(bank, irqc);
   if (ret)
   return ret;
  
 

--
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+: l2c: squelch warning dump on power control setting

[Santosh Shilimkar]

On Monday 14 July 2014 09:13 AM, Sekhar Nori wrote:
 On OMAP SOCs using PL310 controllers, power_ctrl register is not
 accessible from non-secure software even on PL310 versions which
 support it. The secure code takes care of setting it up correctly
 and power transitions are proven on these devices.
 
 For example, AM437x has L2C-310 version r3p3 and ROM code on that
 device does not support writing to L2C-310 power control register.
 The L2C driver, however, tries writing to this register for all
 revisions = r3p0.
 
 This leads to a warning dump on boot which leads most users to believe
 that L2 cache is non-functional.
 
 Since the problem is understood, and cannot be addressed through
 software, replace the warning with a pr_info() while maintaining the
 WARN_ON() for other truly unexpected scenarios.
 
 Reported-by: Nishanth Menon n...@ti.com
 Tested-by: Felipe Balbi ba...@ti.com
 Signed-off-by: Sekhar Nori nsek...@ti.com
 ---
 Only description updated since v1
 
Thanks for update.
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com


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

Re: [PATCH v4 03/11] ARM: OMAP2+: timer: Add suspend-resume callbacks for clkevent device

[Santosh Shilimkar]

On Monday 14 July 2014 07:15 AM, Tony Lindgren wrote:
 * Dave Gerlach d-gerl...@ti.com [140710 19:59]:
 From: Vaibhav Bedia vaibhav.be...@ti.com

 OMAP timer code registers two timers - one as clocksource
 and one as clockevent. Since AM33XX has only one usable timer
 in the WKUP domain one of the timers needs suspend-resume
 support to restore the configuration to pre-suspend state.

 commit adc78e6 (timekeeping: Add suspend and resume
 of clock event devices) introduced .suspend and .resume
 callbacks for clock event devices. Leverages these
 callbacks to have AM33XX clockevent timer which is
 in not in WKUP domain to behave properly across system
 suspend.

 Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
 Signed-off-by: Dave Gerlach d-gerl...@ti.com
 ---
 v3-v4:
  Only use for am33xx soc now.

  arch/arm/mach-omap2/timer.c | 28 
  1 file changed, 28 insertions(+)

 diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
 index 43d03fb..6fc1748 100644
 --- a/arch/arm/mach-omap2/timer.c
 +++ b/arch/arm/mach-omap2/timer.c
 @@ -128,6 +128,29 @@ static void omap2_gp_timer_set_mode(enum 
 clock_event_mode mode,
  }
  }
  
 +static void omap_clkevt_suspend(struct clock_event_device *unused)
 +{
 +struct omap_hwmod *oh;
 +
 +oh = omap_hwmod_lookup(clockevent_gpt.name);
 +if (!oh)
 +return;
 +
 +omap_hwmod_idle(oh);
 +}
 +
 +static void omap_clkevt_resume(struct clock_event_device *unused)
 +{
 +struct omap_hwmod *oh;
 +
 +oh = omap_hwmod_lookup(clockevent_gpt.name);
 +if (!oh)
 +return;
 +
 +omap_hwmod_enable(oh);
 +__omap_dm_timer_int_enable(clkev, OMAP_TIMER_INT_OVERFLOW);
 +}
 +
 
 This is going to make moving the timer code into drivers one step
 tougher to do. And you don't need to look up the hwmod entry every
 time, just initialize it during the init.
 
 +if (soc_is_am33xx()) {
 +clockevent_gpt.suspend = omap_clkevt_suspend;
 +clockevent_gpt.resume = omap_clkevt_resume;
 +}
 +
 
 Maybe try to set up things so we initialize the SoC specific
 timer suspend and resume functions in mach-omap2/timer.c
 in a way where eventually the device driver can easily use
 them?
 
+1. I had similar comments on the previous version too.

Regards,
Santosh

--
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 05/11] Documentation: dt: add ti,am3353_wkup_m3 bindings

[Santosh Shilimkar]

On Thursday 10 July 2014 10:55 PM, Dave Gerlach wrote:
 Add the device tree bindings document for am3353 wkup_m3.
 
 Signed-off-by: Dave Gerlach d-gerl...@ti.com
 CC: Ohad Ben-Cohen o...@wizery.com
 CC: Benoit Cousson bcous...@baylibre.com
 ---
Looks like you missed to copy device tree list and maintainers.
As Tony suggested, split up the series and send the wkup_m3 related
patches separately along with bindings and mark the DT folks on email.

  .../bindings/remoteproc/wkup_m3_rproc.txt  | 46 
 ++
  1 file changed, 46 insertions(+)
  create mode 100644 
 Documentation/devicetree/bindings/remoteproc/wkup_m3_rproc.txt
 
 diff --git a/Documentation/devicetree/bindings/remoteproc/wkup_m3_rproc.txt 
 b/Documentation/devicetree/bindings/remoteproc/wkup_m3_rproc.txt
 new file mode 100644
 index 000..e9dd909
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/remoteproc/wkup_m3_rproc.txt
 @@ -0,0 +1,46 @@
 +Wakeup M3 Remote Proc Driver
 +=
 +
 +TI AMx3 Family devices use a Cortex M3 co-processor to help with various
 +low power tasks that cannot be controlled from the MPU. The CM3 requires
 +a firmware binary to accomplish this and communicates with the MPU through
 +IPC registers present in the SoCs control module. The wkup_m3 remoteproc
 +driver handles the loading of the firmware and exposes an API to
 +communicate with the wkup_m3 through the use of the IPC registers and a
 +mailbox.
 +
 +Wkup M3 Device Node:
 +
 +A wkup_m3 device node is used to represent a wakeup M3 IP instance within
 +a SoC. The sub-mailboxes are represented as child node of this parent node.
 +
 +Required properties:
 +
 +- compatible:Should be ti,am3353-wkup-m3 for AM33xx SoCs
 +- reg:   Contains the wkup_m3 register address ranges for
 + umem, dmem, and ipc-regs.
 +- reg-names: Names for reg addresses given above
 +- interrupts:Contains the interrupt information for the 
 wkup_m3
 + interrupt that signals the MPU.
 +- ti,hwmods: Name of the hwmod associated with the mailbox
 +- ti,no-reset-on-init:   Reset is handled after fw has been loaded, not 
 at
 + init of hwmod.
 +- mbox-names:Name of the mbox channel for the IPC framework
 +- mbox:  Phandle used by IPC framework to get correct 
 mbox
 + channel for communication.
 +
 +Example:
 +
 +/* AM33xx */
 +wkup_m3: wkup_m3@44d0 {
 + compatible = ti,am3353-wkup-m3;
 + reg = 0x44d0 0x4000
 +0x44d8 0x2000
 +0x44e11324 0x0024;
 + reg-names = m3_umem, m3_dmem, ipc_regs;
 + interrupts = 78;
 + ti,hwmods = wkup_m3;
 + ti,no-reset-on-init;
 + mbox-names = wkup_m3;
 + mbox = mailbox mbox_wkupm3;
 +};
 

--
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 06/11] remoteproc: wkup_m3: Add wkup_m3 remote proc driver

[Santosh Shilimkar]

On Thursday 10 July 2014 10:55 PM, Dave Gerlach wrote:
 Add a remoteproc driver to load the firmware for and boot the wkup_m3
 present on am33xx. The wkup_m3 is an integrated Cortex M3 that allows
 the SoC to enter the lowest possible power state by taking control from
 the MPU after it has gone into its own low power state and shutting off
 any additional peripherals.
 
 Communication between the MPU and CM3 is handled by several IPC
 registers in the control module and a mailbox. An API is exposed for
 programming the aforementioned IPC registers and notifying the wkup_m3
 of pending data using the mailbox. The wkup_m3 has the ability to
 trigger an interrupt back to the MPU to allow for bidirectional
 communication through these registers.
 
 Two callbacks are provided. rproc_ready allows code to hook into the
 driver to see when firmware has been loaded and execute other code and
 txev_handler allows external code to run when the wkup_m3 triggers an
 interrupt back to the m3.
 
 The driver expects a resource table to be present in the wkup_m3 to
 define the required memory resources needed by wkup_m3, at least the
 data memory so that the firmware can be copied for the proper place for
 execution.
 
 Signed-off-by: Dave Gerlach d-gerl...@ti.com
 CC: Ohad Ben-Cohen o...@wizery.com
 ---
  drivers/remoteproc/Kconfig |  15 ++
  drivers/remoteproc/Makefile|   1 +
  drivers/remoteproc/wkup_m3_rproc.c | 512 
 +
  include/linux/wkup_m3.h|  71 +
  4 files changed, 599 insertions(+)
  create mode 100644 drivers/remoteproc/wkup_m3_rproc.c
  create mode 100644 include/linux/wkup_m3.h
 
 diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
 index 5e343ba..4b00c21 100644
 --- a/drivers/remoteproc/Kconfig
 +++ b/drivers/remoteproc/Kconfig
 @@ -41,6 +41,21 @@ config STE_MODEM_RPROC
 This can be either built-in or a loadable module.
 If unsure say N.
  
 +config WKUP_M3_RPROC
 + bool AM33xx wkup-m3 remoteproc support
 +depends on SOC_AM33XX
 +select REMOTEPROC
 + select MAILBOX
 + select OMAP2PLUS_MBOX
Please fix the indentation.

 + default n
Default is always 'n' so drop above.
 + help
 +   Say y here to support AM33xx wkup-m3.
 +
 +   Required for Suspend-to-ram and CPUIdle on AM33xx. Allows for
 +   loading of firmware and communication with CM3 PM coproccesor
 +   that is present on AM33xx family of SoCs
 +   If unsure say N.
 +
  config DA8XX_REMOTEPROC
   tristate DA8xx/OMAP-L13x remoteproc support
   depends on ARCH_DAVINCI_DA8XX
 diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
 index ac2ff75..81b04d1 100644
 --- a/drivers/remoteproc/Makefile
 +++ b/drivers/remoteproc/Makefile
 @@ -9,4 +9,5 @@ remoteproc-y  += remoteproc_virtio.o
  remoteproc-y += remoteproc_elf_loader.o
  obj-$(CONFIG_OMAP_REMOTEPROC)+= omap_remoteproc.o
  obj-$(CONFIG_STE_MODEM_RPROC)+= ste_modem_rproc.o
 +obj-$(CONFIG_WKUP_M3_RPROC)  += wkup_m3_rproc.o
  obj-$(CONFIG_DA8XX_REMOTEPROC)   += da8xx_remoteproc.o
 diff --git a/drivers/remoteproc/wkup_m3_rproc.c 
 b/drivers/remoteproc/wkup_m3_rproc.c
 new file mode 100644
 index 000..58aeaf2
 --- /dev/null
 +++ b/drivers/remoteproc/wkup_m3_rproc.c
 @@ -0,0 +1,512 @@
 +/*
 + * AMx3 Wkup M3 Remote Processor driver
 + *
 + * Copyright (C) 2014 Texas Instruments, Inc.
 + *
 + * Dave Gerlach d-gerl...@ti.com
 + *
 + * This program is free software; you can redistribute it and/or
 + * modify it under the terms of the GNU General Public License
 + * version 2 as published by the Free Software Foundation.
 + *
 + * This program is distributed in the hope that it will be useful,
 + * but WITHOUT ANY WARRANTY; without even the implied warranty of
 + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 + * GNU General Public License for more details.
 + */
 +
 +#include linux/kernel.h
 +#include linux/module.h
 +#include linux/err.h
 +#include linux/platform_device.h
 +#include linux/irq.h
 +#include linux/interrupt.h
 +#include linux/elf.h
 +#include linux/pm_runtime.h
 +#include linux/firmware.h
 +#include linux/remoteproc.h
 +#include linux/omap-mailbox.h
 +#include linux/mailbox_client.h
 +#include linux/wkup_m3.h
 +#include linux/kthread.h
 +#include remoteproc_internal.h
 +
 +#include linux/platform_data/wkup_m3.h
 +
 +#define WKUP_M3_WAKE_SRC_MASK0xFF
 +
 +#define WKUP_M3_STATUS_RESP_SHIFT16
 +#define WKUP_M3_STATUS_RESP_MASK (0x  16)
 +
 +#define WKUP_M3_FW_VERSION_SHIFT 0
 +#define WKUP_M3_FW_VERSION_MASK  0x
 +
 +/* AM33XX M3_TXEV_EOI register */
 +#define AM33XX_CONTROL_M3_TXEV_EOI   0x00
 +
 +#define AM33XX_M3_TXEV_ACK   (0x1  0)
 +#define AM33XX_M3_TXEV_ENABLE(0x0  0)
 +
 +/* AM33XX IPC message registers */
 +#define 

Re: [PATCH 07/14] cpufreq: cpu0: OPPs can be populated at runtime

[Santosh Shilimkar]

On Thursday 10 July 2014 08:39 AM, Nishanth Menon wrote:
 On Thu, Jul 10, 2014 at 6:19 AM, Viresh Kumar viresh.ku...@linaro.org wrote:
 On 9 July 2014 20:14, Santosh Shilimkar santosh.shilim...@ti.com wrote:
 Assuming you are updating bidnings as suggested by Stephen,
 patch looks good to me.
 Acked-by: Santosh Shilimkar santosh.shilim...@ti.com

 Why do you still have a separate cpufreq driver for omap?
 Would this patch help getting that out?

 I see this for omap:

 static inline void omap_init_cpufreq(void)
 {
 struct platform_device_info devinfo = { };

 if (!of_have_populated_dt())
 devinfo.name = omap-cpufreq;
 else
 devinfo.name = cpufreq-generic;
 platform_device_register_full(devinfo);
 }

 and it makes me believe that you were just waiting for this patch?
 
 Sorry, am away on vacation and slow on emails. The plan was to kill
 omap cpufreq once all platforms convert to device tree only boot. Only
 platform left is OMAP3 based platforms - though the date for removing
 non-dt support has changed a couple of kernel revisions - but we
 should be able to remove that entire file with this change.
 
 We will need this support to go with the solution recommended for opp
 modifier series[1] - where platform code will populate or add OPPs
 based on speed grade sample detection.

Yep. Last time I blocked the series because all the DT conversions
were not done. Considering now the cpufreq-generic can work on non
DT platforms, I am ok to remove the omap-cpufreq.

Regards,
Santosh

 

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

Re: [PATCH] ARM: OMAP2+: l2c: squelch warning dump on power control setting

[Santosh Shilimkar]

On Monday 07 July 2014 09:40 AM, Russell King - ARM Linux wrote:
 On Mon, Jul 07, 2014 at 05:39:26AM -0700, Tony Lindgren wrote:
 * Russell King - ARM Linux li...@arm.linux.org.uk [140707 05:17]:
 On Mon, Jul 07, 2014 at 05:20:27PM +0530, Sekhar Nori wrote:
 OMAP4430 had L2 cache controller version r2p0 (per the public TRM) which
 does not have this register. So unless there is a ROM API that was
 introduced after OMAP4430, this would not be there even for other
 OMAP4s. Public TRM of OMAP4470 does not indicate an API for this.

 Before creating the patch, I checked with ROM team handling AM437x and
 they denied an API to write to this register was present in AM437x ROM.

 Okay, so why are we trying to write to this register then...

 Ah, we have a bug in cache-l2x0.c:

 #define L2X0_CACHE_ID_PART_MASK (0xf  6)
 #define L2X0_CACHE_ID_RTL_MASK  0x3f
 #define L310_CACHE_ID_RTL_R3P0  0x05

 unsigned rev = readl_relaxed(base + L2X0_CACHE_ID)  
 L2X0_CACHE_ID_PART_MASK;

 if (rev = L310_CACHE_ID_RTL_R2P0) {
 ...
 if (rev = L310_CACHE_ID_RTL_R3P0) {
 l2c_write_sec(L310_DYNAMIC_CLK_GATING_EN | 
 L310_STNDBY_MODE_EN,
   base, L310_POWER_CTRL);

 So, because we're masking the wrong bits, we end up with these tests
 always succeeding.

 So that's a NACK for the original patch, it's the wrong fix.  The
 right fix is to avoid writing this register by fixing the RTL masking.

 Okie dokie, dropping the omap specific fix.
 
 Here's the revision mask fix - with the existing code, the revision checks
 are all useless since they would all pass irrespective of the actual
 revision.  (Had the L2C series been better tested rather than being largely
 ignored, this may have been noticed before it was merged...)  Anyway, what
 isn't clear from Sekhar's message is which revision L2C310 is in the AM437x.
 
Sorry for joining late on the thread. Yes the power control register API
isn't provided and write should be avoiding. 

 From: Russell King rmk+ker...@arm.linux.org.uk
 Cc: linux-arm-ker...@lists.infradead.org
 Subject: [PATCH] ARM: l2c: fix revision checking
 
 The revision checking in l2c310_enable() was not correct; we were
 masking the part number rather than the revision number.  Fix this
 to use the correct macro.
 
 Fixes: 4374d64933b1 (ARM: l2c: add automatic enable of early BRESP)
 Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
 ---
Right. Feel free add my ack if you need one.
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com

  arch/arm/mm/cache-l2x0.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
 index 948f12cf6180..0b5068256baf 100644
 --- a/arch/arm/mm/cache-l2x0.c
 +++ b/arch/arm/mm/cache-l2x0.c
 @@ -732,7 +732,7 @@ static int l2c310_cpu_enable_flz(struct notifier_block 
 *nb, unsigned long act, v
  
  static void __init l2c310_enable(void __iomem *base, u32 aux, unsigned 
 num_lock)
  {
 - unsigned rev = readl_relaxed(base + L2X0_CACHE_ID)  
 L2X0_CACHE_ID_PART_MASK;
 + unsigned rev = readl_relaxed(base + L2X0_CACHE_ID)  
 L2X0_CACHE_ID_RTL_MASK;
   bool cortex_a9 = read_cpuid_part() == ARM_CPU_PART_CORTEX_A9;
  
   if (rev = L310_CACHE_ID_RTL_R2P0) {
 

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

Re: [PATCH] ARM: OMAP2+: l2c: squelch warning dump on power control setting

[Santosh Shilimkar]

On Wednesday 09 July 2014 08:39 AM, Russell King - ARM Linux wrote:
 On Wed, Jul 09, 2014 at 05:56:37PM +0530, Sekhar Nori wrote:
 On Wednesday 09 July 2014 02:55 PM, Tony Lindgren wrote:
 I guess no more comments. Took a look at the patch again, Sekhar, can
 you please update the description with what has been discovered in this
 thread and repost?

 How does the following sound:

 ---
 AM437x has L2C-310 version r3p2 and ROM code on that device does not
 support writing to L2C-310 power control register. The L2C driver,
 however, tries writing to this register for all revisions = r3p0.

 This leads to a warning dump on boot which leads most users to believe
 that L2 cache is non-functional.

Power controller register setting doesn't make cache controller
functional but it is for really clock gating and standby.
So please reword, the above statement accordingly.

 Since the problem is understood, and cannot be addressed through
 software, replace the warning with a pr_info() while maintaining the
 WARN_ON() for other truly unexpected scenarios.

Instead of being vague here and below, I will just make it very simple as
below.

On OMAP SOCs using PL310 controllers, Power_ctrl register is not
accessible from non-secure software on PL310 versions which supports
it. The secure code takes care of setting it up correctly and the
power transitions are proven on these devices.

So lets add the ignore write check for PL310 Power_ctrl register
write.

 From the public TRM available for OMAP4470, even on that device, ROM
 does not support writing to this register even though it uses a version
 of L2C-310 which has the register implemented. So this patch should take
 care of all variants of existing OMAPs.
 ---
 
 That sounds perfect, and explains why the change has to exist, and why
 it can't be fixed elsewhere.  Thanks for providing the full reasoning in
 the commit message.
 

--
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/16] irqchip: crossbar: driver fixes

[Santosh Shilimkar]

Sricharan,

On Monday 16 June 2014 07:23 AM, Sricharan R wrote:
 This series does some cleanups, fixes for handling two interrupts
 getting mapped twice to same crossbar and provides support for
 hardwired IRQ and crossbar definitions.
 
 On certain platforms such as DRA7, SPIs 0, 1, 2, 3, 5, 6, 10,
 131, 132, 133 are direct wired to hardware blocks bypassing
 crossbar. This quirky implementation is *NOT* supposed to be the
 expectation of crossbar hardware usage. This series adds support
 to represent such hard-wired irqs through DT and avoid generic
 allocation/programming of crossbar in the driver.
 
 This way of supporting hard-wired irqs was a result of
 the below discussions.
 http://www.spinics.net/lists/arm-kernel/msg329946.html
 
 Based on 3.15 mainline.
 
 All the patches are available here
  g...@github.com:Sricharanti/sricharan.git crossbar_updates
 
 The fixes series[1] earlier posted is merged in to this.
 [1] http://www.spinics.net/lists/arm-kernel/msg328273.html
 
 [V2] Merged the above series and rebased on 3.15 mainline
 
 [V3] Modified patch#3 to get irqs-skip properties from DT,
  merged path#8 for checkpatch warning to other relevant
  patches and fixed comments for other patches.

I scanned entire series again including your updates on Jason's
comments. All look good to my eyes.

Hopefully after this series now, we can actually enable the crossbar
support on those machines.

FWIW,
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 03/19] irqchip: crossbar: Skip some irqs from getting mapped to crossbar

[Santosh Shilimkar]

On Friday 13 June 2014 09:10 AM, Jason Cooper wrote:
 On Fri, Jun 13, 2014 at 12:26:10PM +0530, Sricharan R wrote:
 On Thursday 12 June 2014 07:35 PM, Jason Cooper wrote:
 ...
 Do you have other changes outside of irqchip depending on this series?
 If so, I can set up a topic branch for you guys to base off of.
 Otherwise, I'll just apply them to irqchip/core when they're ready.

  There are dts changes which are dependent upon this series.

   http://www.spinics.net/lists/linux-omap/msg108116.html
 
 In general, dts changes shouldn't depend on code changes or vice-versa.
 If they do, that's an indicator that we're breaking compatibility with
 older dtbs.

Thats true. The case with cross-bar though is the feature wasn't
completly supported so far before this series. Perhaps the the initial
bindings should have been marked unstable. 
 
 Looking at the dra7.dtsi changes, we're redefining the interrupt
 property, which can't be good. :(

 Perhaps a better solution would be to add a property, say 'ti,cross-irq'
 that is the exact same format as 'interrupts', but is used by the
 crossbar driver?

We have gone over those earlier and it was agreed to re-use interrupt
properties and for special cases, define a cross-bar property to describe
it.
 
 I'm not convinced of this yet, I suspect we may not actually have a
 dependency between the dtsi changes and the code changes.  We would have
 the ugly if you have the crossbar node, 'interrupts' means X, if not it
 means Y in the binding docs.  But the absence of the node prevents the
 crossbar driver from re-interpreting the interrupts property.
 
In ideal cross-bar hardware you don't need the assumption if you have the
crossbar node, 'interrupts' means X, if not it means Y

It is purely because the cross-bar irq router hardware has few nasty
bugs which needs those special handling. And thats the reason, the
property was added.

 Have you tried booting all the different scenarios?  eg:
 
   old dtb, new driver
   new dtb, old driver
   old dtb, old driver
   new dtb, new driver
 
Old driver wasn't complete as mentioned and hence the above
combinations becomes bit irrelevant.

Regards,
Santosh


--
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: Fix the boot regression with CPU_IDLE enabled

[Santosh Shilimkar]

On Tuesday 27 May 2014 04:34 PM, Tony Lindgren wrote:
 * Daniel Lezcano daniel.lezc...@linaro.org [140523 13:53]:
 On 23 May 2014 20:32, Tony Lindgren t...@atomide.com wrote:

 * Tony Lindgren t...@atomide.com [140523 07:45]:
 * Tobias Jakobi tjak...@math.uni-bielefeld.de [140519 14:19]:

 But even if I don't connect via WiFi at all, just boot and let me
 system
 run with serial console connected, after some time I get a kernel
 'WARNING':
 http://www.math.uni-bielefeld.de/~tjakobi/archive/dmesg.1.log

 BTW, care to update the bugzilla page with the second warning
 in this log?

 That's the WARNING: CPU: 1 PID: 0 at kernel/timer.c:1147 that's
 at 238 seconds.

 Also, with Santosh's fix applied, can you also try disabling one
 or more of the idle states for cpuidle and see if that helps?

 Something like this patch below. If that helps with the WARNING
 above you're getting it narrows down the problem down quite a bit.

 Regards,

 Tony

 --- a/arch/arm/mach-omap2/cpuidle44xx.c
 +++ b/arch/arm/mach-omap2/cpuidle44xx.c
 @@ -44,11 +44,13 @@ static struct idle_statedata omap4_idle_data[] = {
 .mpu_state = PWRDM_POWER_RET,
 .mpu_logic_state = PWRDM_POWER_RET,
 },
 +#if 0
 {
 .cpu_state = PWRDM_POWER_OFF,
 .mpu_state = PWRDM_POWER_RET,
 .mpu_logic_state = PWRDM_POWER_OFF,
 },
 +#endif


 Hmm, I am afraid that will lead to a fault. Safer to set the state_count =
 2 instead.
 
 Hmm don't we have state_count = ARRAY_SIZE(omap4_idle_data) or am I
 missing something?
 
I don't think you are missing anything. The change should work.

--
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: RCU stall on panda

[Santosh Shilimkar]

On Thursday 22 May 2014 04:59 AM, Alex Shi wrote:
 On 05/16/2014 09:37 PM, Santosh Shilimkar wrote:
 On Friday 16 May 2014 03:41 AM, Alex Shi wrote:
 On 05/16/2014 02:36 AM, Santosh Shilimkar wrote:
 yes.
 My board is panda ES. without this revert, it works.

 Care to specify what linux version you are testing against?

 Does it hang in idle always immediately on booting?

 Or does the serial console first hang with sysrq still
 working (ctrl-a h in minicom for help) with device
 eventually locking up hard?

 I just posted an updated patch Alex on other thread.
 Attaching here again for your reference. Please try
 it out and see if the you still get a hang.

 it does not hang this time.

 This is good news and exactly what I expected.
  
 but I am not sure it can solve my problem, since RCU stall is not easy
 to reproduce in short time.

 You may want to run the system longer if you can. I suspect the RCU stall
 was also side effect of missing interrupts.
 
 Sure. it do remove the RCU stall on my panda board.
 
Thanks for confirming. Tony already send fix upstream so it should
show up in next rc mostly

--
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: Fix the boot regression with CPU_IDLE enabled

[Santosh Shilimkar]

On Monday 19 May 2014 01:23 PM, Tony Lindgren wrote:
 * Daniel Lezcano daniel.lezc...@linaro.org [140519 09:46]:
 On 05/16/2014 11:29 PM, Tony Lindgren wrote:

 And just to recap, this problem can be reproduced with current
 Linux next with omap2plus_defconfig with CONFIG_CPU_IDLE enabled. The
 system should hang during the boot at some point.

 I can take the time to investigate a bit more but not right now. What is
 your deadline before committing the reverts ?
 
 Well we do have several automated build and boot systems failing
 because of this with multi_v7_defconfig. And users are complaining,
 see this report from Tobias Jakobi:
 
 https://bugzilla.kernel.org/show_bug.cgi?id=75421
 
 It seems that doing the revert is not enough based on the
 page above.

Thats not true. The above link used the half patch and not the
updated patch. Updated patch worked for Alex also. As you can
see they saw RCU stalls and they go away after the updated patch.

Can you please point them to try out the updated patch ?
 
 I'd prefer we'd fix this issue properly for sure, it seems that
 we're not quite understanding what's going on. And this might
 hit other platforms too when they start implementing deeper
 PM idle states in the mainline kernel.
 
I am certain that the updated patch fixed the regression
for sure. The issue is really not generic enough since its related
an OMAP ROM errata which needs that special handling of
interrupt re-trigger etc. You don't need that for other platforms
so they are not likely get affected.

 
--
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: Fix the boot regression with CPU_IDLE enabled

[Santosh Shilimkar]

On Monday 19 May 2014 03:36 PM, Tony Lindgren wrote:
 * Daniel Lezcano daniel.lezc...@linaro.org [140519 11:07]:
 On 05/19/2014 07:51 PM, Tony Lindgren wrote:
 * Santosh Shilimkar santosh.shilim...@ti.com [140519 10:35]:
 On Monday 19 May 2014 01:23 PM, Tony Lindgren wrote:
 * Daniel Lezcano daniel.lezc...@linaro.org [140519 09:46]:
 On 05/16/2014 11:29 PM, Tony Lindgren wrote:

 And just to recap, this problem can be reproduced with current
 Linux next with omap2plus_defconfig with CONFIG_CPU_IDLE enabled. The
 system should hang during the boot at some point.

 I can take the time to investigate a bit more but not right now. What is
 your deadline before committing the reverts ?

 Well we do have several automated build and boot systems failing
 because of this with multi_v7_defconfig. And users are complaining,
 see this report from Tobias Jakobi:

 https://bugzilla.kernel.org/show_bug.cgi?id=75421

 It seems that doing the revert is not enough based on the
 page above.

 Thats not true. The above link used the half patch and not the
 updated patch. Updated patch worked for Alex also. As you can
 see they saw RCU stalls and they go away after the updated patch.

 Can you please point them to try out the updated patch ?

 OK good point. I added a link to the updated patch in
 bugzilla.

 I'd prefer we'd fix this issue properly for sure, it seems that
 we're not quite understanding what's going on. And this might
 hit other platforms too when they start implementing deeper
 PM idle states in the mainline kernel.

 I am certain that the updated patch fixed the regression
 for sure. The issue is really not generic enough since its related
 an OMAP ROM errata which needs that special handling of
 interrupt re-trigger etc. You don't need that for other platforms
 so they are not likely get affected.

 OK makes sense to me considering the ROM code. Daniel, are you OK
 with that or do you still want to investigate further?

 For the moment I am a bit short in time for some other tasks. So feel free
 to apply the revert and I will look for a proper fix when I will have time.
 
 Added Tobias to Cc. At the bugzilla link Tobias is saying
 he used the right patch from Santosh to test and it still 
 fails.
 
The link of the patch in bugzilla shows that it was not the updated
patch and that was my reference point. The other bugzilla issue seems to
be different and mostly not related to cpuidle. I could be wrong.

--

dmesg | grep idle:
cpuidle: using governor ladder
cpuidle: using governor menu

grep . /sys/devices/system/cpu/cpu*/cpuidle/*/*:
(now attached as 'cpuidle states')

The 'BUG' looks like this:
BUG: scheduling while atomic: swapper/1/0/0x
Modules linked in: ctr ccm btrfs xor xor_neon zlib_inflate zlib_deflate omapfb 
cfbfillrect cfbimgblt cfbcopyarea raid6_pq arc4 wl12xx wlcore mac80211 cfg80211 
rfkill usb_storage snd_soc_omap_hdmi snd_soc_omap_hdmi_card wlcore_sdio
CPU: 1 PID: 0 Comm: swapper/1 Tainted: GW 3.15.0-rc5+ #1
Backtrace: 
[c001152c] (dump_backtrace) from [c00116c8] (show_stack+0x18/0x1c)
 r6:eb894000 r5:0001 r4: r3:
[c00116b0] (show_stack) from [c0430a94] (dump_stack+0x7c/0x98)
[c0430a18] (dump_stack) from [c042ec10] (__schedule_bug+0x48/0x60)
 r4: r3:0153
[c042ebc8] (__schedule_bug) from [c0432248] (__schedule+0x41c/0x4b4)
 r4:2b9fe000 r3:
[c0431e2c] (__schedule) from [c04323d4] (schedule+0x38/0x88)
 r10:eb894000 r9:eb894000 r8: r7:eb894000 r6:c05b0450 r5:c05b04a0
 r4:eb894000
[c043239c] (schedule) from [c04326fc] (schedule_preempt_disabled+0x10/0x14)
[c04326ec] (schedule_preempt_disabled) from [c006d8f0] 
(cpu_startup_entry+0xec/0x22c)
[c006d804] (cpu_startup_entry) from [c00131a4] 
(secondary_start_kernel+0xe8/0x100)
 r7:c05de240
[c00130bc] (secondary_start_kernel) from [80008664] (0x80008664)
 r4:ab87c06a r3:c000864c
--


--
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: RCU stall on panda

[Santosh Shilimkar]

On Friday 16 May 2014 03:41 AM, Alex Shi wrote:
 On 05/16/2014 02:36 AM, Santosh Shilimkar wrote:
 yes.
 My board is panda ES. without this revert, it works.

 Care to specify what linux version you are testing against?

 Does it hang in idle always immediately on booting?

 Or does the serial console first hang with sysrq still
 working (ctrl-a h in minicom for help) with device
 eventually locking up hard?

 I just posted an updated patch Alex on other thread.
 Attaching here again for your reference. Please try
 it out and see if the you still get a hang.
 
 it does not hang this time.

This is good news and exactly what I expected.
 
 but I am not sure it can solve my problem, since RCU stall is not easy
 to reproduce in short time.
 
You may want to run the system longer if you can. I suspect the RCU stall
was also side effect of missing interrupts.

Regards,
Santosh
--
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: Fix the boot regression with CPU_IDLE enabled

[Santosh Shilimkar]

Tony,

On Thursday 15 May 2014 02:29 PM, Santosh Shilimkar wrote:
 On Thursday 15 May 2014 01:54 PM, Santosh Shilimkar wrote:
 On Thursday 15 May 2014 01:50 PM, Daniel Lezcano wrote:
 On 05/15/2014 07:03 PM, Santosh Shilimkar wrote:
 
 [..]
 
 With above mentioned change, it should work. Other alternatives is OMAP4 
 driver does
 its won registration where it can start the timer. The way it was before 
 the
 consolidation.

 Ofcourse if you have better fix, then great.

 What is your suggestion. We *must* fix the regression asap. I think
 $subject patch with an update to bctimer start under CPUIDLE_FLAG_COUPLED
 seems a good way forward.

 Do let me know.

 Did you see Alex Shi's email [cc'ed] ? Reverting this change makes the 
 panda ES to hang.

 The hang is definitely due to the bctimer not started. As I said, I assumed 
 it was and
 then you corrected saying it is under the flag.

 I am not convinced the culprit is this code you are trying to revert.

 fair enough. Thats why I said if you have an alternative fix thats great.

 For record, below is updated patch with bctimer started which
 was missed in earlier version. I haven't tested it though.
 
 Alex,
 Please give a try with your test-case and see if you still see the hang.
 Am just curious about your issue and hence the request..
 
Alex tested below patch and he don't see the hang so the patch is
addressing the issue.

If Daniel works out an alternate fix to avoid reverts, that will be great
but if not, we should merge the below patch. I let you take call on it.

 
 
 From bb3b82cc5645b83bedf1343d03cc956f27f6fc83 Mon Sep 17 00:00:00 2001
 From: Santosh Shilimkar santosh.shilim...@ti.com
 Date: Mon, 12 May 2014 17:37:59 -0400
 Subject: [PATCH] ARM: OMAP4: Fix the boot regression with CPU_IDLE enabled
 
 On OMAP4 panda board, there have been several bug reports about boot
 hang and lock-ups with CPU_IDLE enabled. The root cause of the issue
 is missing interrupts while in idle state. Commit cb7094e8 {cpuidle / omap4 :
 use CPUIDLE_FLAG_TIMER_STOP flag} moved the broadcast notifiers to common
 code for right reasons but on OMAP4 which suffers from a nasty ROM code
 bug with GIC, commit ff999b8a {ARM: OMAP4460: Workaround for ROM bug ..},
 we loose interrupts which leads to issues like lock-up, hangs etc.
 
 Patch reverts commit cb7094 {cpuidle / omap4 : use CPUIDLE_FLAG_TIMER_STOP
 flag} and 54769d6 {cpuidle: OMAP4: remove timer broadcast initialization} to
 avoid the issue. With this change, OMAP4 panda boards, the mentioned
 issues are getting fixed. We no longer loose interrupts which was the cause
 of the regression.
 
 Cc: Roger Quadros rog...@ti.com
 Cc: Kevin Hilman khil...@linaro.org
 Cc: Tony Lindgren t...@atomide.com
 Cc: Daniel Lezcano daniel.lezc...@linaro.org
 Reported-tested-by: Roger Quadros rog...@ti.com
 Reported-tested-by: Kevin Hilman khil...@linaro.org
 Tested-by: Tony Lindgren t...@atomide.com
 Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
 ---
  arch/arm/mach-omap2/cpuidle44xx.c |   25 +
  1 file changed, 21 insertions(+), 4 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/cpuidle44xx.c 
 b/arch/arm/mach-omap2/cpuidle44xx.c
 index 01fc710..2498ab0 100644
 --- a/arch/arm/mach-omap2/cpuidle44xx.c
 +++ b/arch/arm/mach-omap2/cpuidle44xx.c
 @@ -14,6 +14,7 @@
  #include linux/cpuidle.h
  #include linux/cpu_pm.h
  #include linux/export.h
 +#include linux/clockchips.h
  
  #include asm/cpuidle.h
  #include asm/proc-fns.h
 @@ -83,6 +84,7 @@ static int omap_enter_idle_coupled(struct cpuidle_device 
 *dev,
  {
   struct idle_statedata *cx = state_ptr + index;
   u32 mpuss_can_lose_context = 0;
 + int cpu_id = smp_processor_id();
  
   /*
* CPU0 has to wait and stay ON until CPU1 is OFF state.
 @@ -110,6 +112,8 @@ static int omap_enter_idle_coupled(struct cpuidle_device 
 *dev,
   mpuss_can_lose_context = (cx-mpu_state == PWRDM_POWER_RET) 
(cx-mpu_logic_state == PWRDM_POWER_OFF);
  
 + clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, cpu_id);
 +
   /*
* Call idle CPU PM enter notifier chain so that
* VFP and per CPU interrupt context is saved.
 @@ -165,6 +169,8 @@ static int omap_enter_idle_coupled(struct cpuidle_device 
 *dev,
   if (dev-cpu == 0  mpuss_can_lose_context)
   cpu_cluster_pm_exit();
  
 + clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, cpu_id);
 +
  fail:
   cpuidle_coupled_parallel_barrier(dev, abort_barrier);
   cpu_done[dev-cpu] = false;
 @@ -172,6 +178,16 @@ fail:
   return index;
  }
  
 +/*
 + * For each cpu, setup the broadcast timer because local timers
 + * stops for the states above C1.
 + */
 +static void omap_setup_broadcast_timer(void *arg)
 +{
 + int cpu = smp_processor_id();
 + clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ON, cpu);
 +}
 +
  static struct cpuidle_driver omap4_idle_driver = {
   .name   = omap4_idle

Re: [PATCH] ARM: OMAP4: Fix the boot regression with CPU_IDLE enabled

[Santosh Shilimkar]

Daniel,

On Wednesday 14 May 2014 05:18 PM, Santosh Shilimkar wrote:
 On Wednesday 14 May 2014 04:02 PM, Daniel Lezcano wrote:
 On 05/14/2014 09:50 PM, Santosh Shilimkar wrote:
 On Wednesday 14 May 2014 03:44 PM, Daniel Lezcano wrote:
 On 05/13/2014 04:39 PM, Santosh Shilimkar wrote:
 On OMAP4 panda board, there have been several bug reports about boot
 hang and lock-ups with CPU_IDLE enabled. The root cause of the issue
 is missing interrupts while in idle state. Commit cb7094e8 {cpuidle / 
 omap4 :
 use CPUIDLE_FLAG_TIMER_STOP flag} moved the broadcast notifiers to common
 code for right reasons but on OMAP4 which suffers from a nasty ROM code
 bug with GIC, commit ff999b8a {ARM: OMAP4460: Workaround for ROM bug ..},
 we loose interrupts which leads to issues like lock-up, hangs etc.

 Patch reverts commit cb7094 {cpuidle / omap4 : use CPUIDLE_FLAG_TIMER_STOP
 flag} to avoid the issue. With this change, OMAP4 panda boards, the 
 mentioned
 issues are getting fixed. We no longer loose interrupts which was the 
 cause
 of the regression.

 Cc: Roger Quadros rog...@ti.com
 Cc: Kevin Hilman khil...@linaro.org
 Cc: Tony Lindgren t...@atomide.com
 Cc: Daniel Lezcano daniel.lezc...@linaro.org
 Reported-tested-by: Roger Quadros rog...@ti.com
 Reported-tested-by: Kevin Hilman khil...@linaro.org
 Tested-by: Tony Lindgren t...@atomide.com
 Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
 ---

 [ ... ]


 +clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, cpu_id);
 +
/*
 * Call idle CPU PM enter notifier chain so that
 * VFP and per CPU interrupt context is saved.
 @@ -165,6 +169,8 @@ static int omap_enter_idle_coupled(struct 
 cpuidle_device *dev,
if (dev-cpu == 0  mpuss_can_lose_context)
cpu_cluster_pm_exit();

 +clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, cpu_id);

 [ ... ]


 Shouldn't the broadcast timer to be setup with 
 CLOCK_EVT_NOTIFY_BROADCAST_ON also ?

 Which is already taken care by __cpuidle_register_driver(). Note that setup 
 code
 is still used from generic code...

 Nope, if the flag CPUIDLE_FLAG_TIMER_STOP is not set, the cpuidle framework 
 won't setup the timer.

 I see. I assumed it was taken care. So we might have setup the timer too.
 
 static void __cpuidle_driver_init(struct cpuidle_driver *drv)
 {

 ...

 for (i = drv-state_count - 1; i = 0 ; i--) {
 if (drv-states[i].flags  CPUIDLE_FLAG_TIMER_STOP) {
 May be you should start the bc timer in case 'CPUIDLE_FLAG_TIMER_STOP'
 or 'CPUIDLE_FLAG_COUPLED'
 drv-bctimer = 1;
 break;
 }
 }

 ...

 }

 static int __cpuidle_register_driver(struct cpuidle_driver *drv)
 {
 ...

 if (drv-bctimer)
 on_each_cpu_mask(drv-cpumask,
 cpuidle_setup_broadcast_timer,
  (void *)CLOCK_EVT_NOTIFY_BROADCAST_ON, 1);

 ...
 }

 So the broadcast timer does not operate with this revert. Moreover, I am not 
 sure reverting this patch is the right solution.

 With above mentioned change, it should work. Other alternatives is OMAP4 
 driver does
 its won registration where it can start the timer. The way it was before the
 consolidation.
 
 Ofcourse if you have better fix, then great. 
 
What is your suggestion. We *must* fix the regression asap. I think 
$subject patch with an update to bctimer start under CPUIDLE_FLAG_COUPLED
seems a good way forward.

Do let me know.

Regards,
Santosh
--
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: Fix the boot regression with CPU_IDLE enabled

[Santosh Shilimkar]

On Thursday 15 May 2014 01:50 PM, Daniel Lezcano wrote:
 On 05/15/2014 07:03 PM, Santosh Shilimkar wrote:
 Daniel,

 On Wednesday 14 May 2014 05:18 PM, Santosh Shilimkar wrote:
 On Wednesday 14 May 2014 04:02 PM, Daniel Lezcano wrote:
 On 05/14/2014 09:50 PM, Santosh Shilimkar wrote:
 On Wednesday 14 May 2014 03:44 PM, Daniel Lezcano wrote:
 On 05/13/2014 04:39 PM, Santosh Shilimkar wrote:
 On OMAP4 panda board, there have been several bug reports about boot
 hang and lock-ups with CPU_IDLE enabled. The root cause of the issue
 is missing interrupts while in idle state. Commit cb7094e8 {cpuidle / 
 omap4 :
 use CPUIDLE_FLAG_TIMER_STOP flag} moved the broadcast notifiers to 
 common
 code for right reasons but on OMAP4 which suffers from a nasty ROM code
 bug with GIC, commit ff999b8a {ARM: OMAP4460: Workaround for ROM bug 
 ..},
 we loose interrupts which leads to issues like lock-up, hangs etc.

 Patch reverts commit cb7094 {cpuidle / omap4 : use 
 CPUIDLE_FLAG_TIMER_STOP
 flag} to avoid the issue. With this change, OMAP4 panda boards, the 
 mentioned
 issues are getting fixed. We no longer loose interrupts which was the 
 cause
 of the regression.

 Cc: Roger Quadros rog...@ti.com
 Cc: Kevin Hilman khil...@linaro.org
 Cc: Tony Lindgren t...@atomide.com
 Cc: Daniel Lezcano daniel.lezc...@linaro.org
 Reported-tested-by: Roger Quadros rog...@ti.com
 Reported-tested-by: Kevin Hilman khil...@linaro.org
 Tested-by: Tony Lindgren t...@atomide.com
 Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
 ---

 [ ... ]


 +clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, cpu_id);
 +
 /*
  * Call idle CPU PM enter notifier chain so that
  * VFP and per CPU interrupt context is saved.
 @@ -165,6 +169,8 @@ static int omap_enter_idle_coupled(struct 
 cpuidle_device *dev,
 if (dev-cpu == 0  mpuss_can_lose_context)
 cpu_cluster_pm_exit();

 +clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, cpu_id);

 [ ... ]


 Shouldn't the broadcast timer to be setup with 
 CLOCK_EVT_NOTIFY_BROADCAST_ON also ?

 Which is already taken care by __cpuidle_register_driver(). Note that 
 setup code
 is still used from generic code...

 Nope, if the flag CPUIDLE_FLAG_TIMER_STOP is not set, the cpuidle 
 framework won't setup the timer.

 I see. I assumed it was taken care. So we might have setup the timer too.

 static void __cpuidle_driver_init(struct cpuidle_driver *drv)
 {

  ...

  for (i = drv-state_count - 1; i = 0 ; i--) {
  if (drv-states[i].flags  CPUIDLE_FLAG_TIMER_STOP) {
 May be you should start the bc timer in case 'CPUIDLE_FLAG_TIMER_STOP'
 or 'CPUIDLE_FLAG_COUPLED'
  drv-bctimer = 1;
  break;
  }
  }

  ...

 }

 static int __cpuidle_register_driver(struct cpuidle_driver *drv)
 {
  ...

  if (drv-bctimer)
  on_each_cpu_mask(drv-cpumask,
  cpuidle_setup_broadcast_timer,
   (void *)CLOCK_EVT_NOTIFY_BROADCAST_ON, 1);

  ...
 }

 So the broadcast timer does not operate with this revert. Moreover, I am 
 not sure reverting this patch is the right solution.

 With above mentioned change, it should work. Other alternatives is OMAP4 
 driver does
 its won registration where it can start the timer. The way it was before the
 consolidation.

 Ofcourse if you have better fix, then great.

 What is your suggestion. We *must* fix the regression asap. I think
 $subject patch with an update to bctimer start under CPUIDLE_FLAG_COUPLED
 seems a good way forward.

 Do let me know.
 
 Did you see Alex Shi's email [cc'ed] ? Reverting this change makes the panda 
 ES to hang.
 
The hang is definitely due to the bctimer not started. As I said, I assumed it 
was and
then you corrected saying it is under the flag.

 I am not convinced the culprit is this code you are trying to revert.
 
fair enough. Thats why I said if you have an alternative fix thats great.

 I will try to reproduce the bug on my board.
 
Sure...
--
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: Fix the boot regression with CPU_IDLE enabled

[Santosh Shilimkar]

On Thursday 15 May 2014 01:54 PM, Santosh Shilimkar wrote:
 On Thursday 15 May 2014 01:50 PM, Daniel Lezcano wrote:
 On 05/15/2014 07:03 PM, Santosh Shilimkar wrote:

[..]

 With above mentioned change, it should work. Other alternatives is OMAP4 
 driver does
 its won registration where it can start the timer. The way it was before 
 the
 consolidation.

 Ofcourse if you have better fix, then great.

 What is your suggestion. We *must* fix the regression asap. I think
 $subject patch with an update to bctimer start under CPUIDLE_FLAG_COUPLED
 seems a good way forward.

 Do let me know.

 Did you see Alex Shi's email [cc'ed] ? Reverting this change makes the panda 
 ES to hang.

 The hang is definitely due to the bctimer not started. As I said, I assumed 
 it was and
 then you corrected saying it is under the flag.
 
 I am not convinced the culprit is this code you are trying to revert.

 fair enough. Thats why I said if you have an alternative fix thats great.
 
For record, below is updated patch with bctimer started which
was missed in earlier version. I haven't tested it though.

Alex,
Please give a try with your test-case and see if you still see the hang.
Am just curious about your issue and hence the request..

Regards,
Santosh


From bb3b82cc5645b83bedf1343d03cc956f27f6fc83 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Mon, 12 May 2014 17:37:59 -0400
Subject: [PATCH] ARM: OMAP4: Fix the boot regression with CPU_IDLE enabled

On OMAP4 panda board, there have been several bug reports about boot
hang and lock-ups with CPU_IDLE enabled. The root cause of the issue
is missing interrupts while in idle state. Commit cb7094e8 {cpuidle / omap4 :
use CPUIDLE_FLAG_TIMER_STOP flag} moved the broadcast notifiers to common
code for right reasons but on OMAP4 which suffers from a nasty ROM code
bug with GIC, commit ff999b8a {ARM: OMAP4460: Workaround for ROM bug ..},
we loose interrupts which leads to issues like lock-up, hangs etc.

Patch reverts commit cb7094 {cpuidle / omap4 : use CPUIDLE_FLAG_TIMER_STOP
flag} and 54769d6 {cpuidle: OMAP4: remove timer broadcast initialization} to
avoid the issue. With this change, OMAP4 panda boards, the mentioned
issues are getting fixed. We no longer loose interrupts which was the cause
of the regression.

Cc: Roger Quadros rog...@ti.com
Cc: Kevin Hilman khil...@linaro.org
Cc: Tony Lindgren t...@atomide.com
Cc: Daniel Lezcano daniel.lezc...@linaro.org
Reported-tested-by: Roger Quadros rog...@ti.com
Reported-tested-by: Kevin Hilman khil...@linaro.org
Tested-by: Tony Lindgren t...@atomide.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
 arch/arm/mach-omap2/cpuidle44xx.c |   25 +
 1 file changed, 21 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/cpuidle44xx.c 
b/arch/arm/mach-omap2/cpuidle44xx.c
index 01fc710..2498ab0 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -14,6 +14,7 @@
 #include linux/cpuidle.h
 #include linux/cpu_pm.h
 #include linux/export.h
+#include linux/clockchips.h
 
 #include asm/cpuidle.h
 #include asm/proc-fns.h
@@ -83,6 +84,7 @@ static int omap_enter_idle_coupled(struct cpuidle_device *dev,
 {
struct idle_statedata *cx = state_ptr + index;
u32 mpuss_can_lose_context = 0;
+   int cpu_id = smp_processor_id();
 
/*
 * CPU0 has to wait and stay ON until CPU1 is OFF state.
@@ -110,6 +112,8 @@ static int omap_enter_idle_coupled(struct cpuidle_device 
*dev,
mpuss_can_lose_context = (cx-mpu_state == PWRDM_POWER_RET) 
 (cx-mpu_logic_state == PWRDM_POWER_OFF);
 
+   clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, cpu_id);
+
/*
 * Call idle CPU PM enter notifier chain so that
 * VFP and per CPU interrupt context is saved.
@@ -165,6 +169,8 @@ static int omap_enter_idle_coupled(struct cpuidle_device 
*dev,
if (dev-cpu == 0  mpuss_can_lose_context)
cpu_cluster_pm_exit();
 
+   clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, cpu_id);
+
 fail:
cpuidle_coupled_parallel_barrier(dev, abort_barrier);
cpu_done[dev-cpu] = false;
@@ -172,6 +178,16 @@ fail:
return index;
 }
 
+/*
+ * For each cpu, setup the broadcast timer because local timers
+ * stops for the states above C1.
+ */
+static void omap_setup_broadcast_timer(void *arg)
+{
+   int cpu = smp_processor_id();
+   clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ON, cpu);
+}
+
 static struct cpuidle_driver omap4_idle_driver = {
.name   = omap4_idle,
.owner  = THIS_MODULE,
@@ -189,8 +205,7 @@ static struct cpuidle_driver omap4_idle_driver = {
/* C2 - CPU0 OFF + CPU1 OFF + MPU CSWR */
.exit_latency = 328 + 440,
.target_residency = 960,
-   .flags

Re: RCU stall on panda

[Santosh Shilimkar]

On Thursday 15 May 2014 02:32 PM, Tony Lindgren wrote:
 * Alex Shi alex@linaro.org [140515 06:27]:
 On 05/15/2014 05:05 PM, Daniel Lezcano wrote:


 After enable this patch, system maybe hang in idle. :(

 Hi Alex,

 do you mean even with this revert applied, the board hangs in idle ?


 yes.
 My board is panda ES. without this revert, it works.
 
 Care to specify what linux version you are testing against?
 
 Does it hang in idle always immediately on booting?
 
 Or does the serial console first hang with sysrq still
 working (ctrl-a h in minicom for help) with device
 eventually locking up hard?

I just posted an updated patch Alex on other thread.
Attaching here again for your reference. Please try
it out and see if the you still get a hang.

Regards,
Santosh

From bb3b82cc5645b83bedf1343d03cc956f27f6fc83 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Mon, 12 May 2014 17:37:59 -0400
Subject: [PATCH] ARM: OMAP4: Fix the boot regression with CPU_IDLE enabled

On OMAP4 panda board, there have been several bug reports about boot
hang and lock-ups with CPU_IDLE enabled. The root cause of the issue
is missing interrupts while in idle state. Commit cb7094e8 {cpuidle / omap4 :
use CPUIDLE_FLAG_TIMER_STOP flag} moved the broadcast notifiers to common
code for right reasons but on OMAP4 which suffers from a nasty ROM code
bug with GIC, commit ff999b8a {ARM: OMAP4460: Workaround for ROM bug ..},
we loose interrupts which leads to issues like lock-up, hangs etc.

Patch reverts commit cb7094 {cpuidle / omap4 : use CPUIDLE_FLAG_TIMER_STOP
flag} and 54769d6 {cpuidle: OMAP4: remove timer broadcast initialization} to
avoid the issue. With this change, OMAP4 panda boards, the mentioned
issues are getting fixed. We no longer loose interrupts which was the cause
of the regression.

Cc: Roger Quadros rog...@ti.com
Cc: Kevin Hilman khil...@linaro.org
Cc: Tony Lindgren t...@atomide.com
Cc: Daniel Lezcano daniel.lezc...@linaro.org
Reported-tested-by: Roger Quadros rog...@ti.com
Reported-tested-by: Kevin Hilman khil...@linaro.org
Tested-by: Tony Lindgren t...@atomide.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
 arch/arm/mach-omap2/cpuidle44xx.c |   25 +
 1 file changed, 21 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/cpuidle44xx.c 
b/arch/arm/mach-omap2/cpuidle44xx.c
index 01fc710..2498ab0 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -14,6 +14,7 @@
 #include linux/cpuidle.h
 #include linux/cpu_pm.h
 #include linux/export.h
+#include linux/clockchips.h
 
 #include asm/cpuidle.h
 #include asm/proc-fns.h
@@ -83,6 +84,7 @@ static int omap_enter_idle_coupled(struct cpuidle_device *dev,
 {
struct idle_statedata *cx = state_ptr + index;
u32 mpuss_can_lose_context = 0;
+   int cpu_id = smp_processor_id();
 
/*
 * CPU0 has to wait and stay ON until CPU1 is OFF state.
@@ -110,6 +112,8 @@ static int omap_enter_idle_coupled(struct cpuidle_device 
*dev,
mpuss_can_lose_context = (cx-mpu_state == PWRDM_POWER_RET) 
 (cx-mpu_logic_state == PWRDM_POWER_OFF);
 
+   clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, cpu_id);
+
/*
 * Call idle CPU PM enter notifier chain so that
 * VFP and per CPU interrupt context is saved.
@@ -165,6 +169,8 @@ static int omap_enter_idle_coupled(struct cpuidle_device 
*dev,
if (dev-cpu == 0  mpuss_can_lose_context)
cpu_cluster_pm_exit();
 
+   clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, cpu_id);
+
 fail:
cpuidle_coupled_parallel_barrier(dev, abort_barrier);
cpu_done[dev-cpu] = false;
@@ -172,6 +178,16 @@ fail:
return index;
 }
 
+/*
+ * For each cpu, setup the broadcast timer because local timers
+ * stops for the states above C1.
+ */
+static void omap_setup_broadcast_timer(void *arg)
+{
+   int cpu = smp_processor_id();
+   clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ON, cpu);
+}
+
 static struct cpuidle_driver omap4_idle_driver = {
.name   = omap4_idle,
.owner  = THIS_MODULE,
@@ -189,8 +205,7 @@ static struct cpuidle_driver omap4_idle_driver = {
/* C2 - CPU0 OFF + CPU1 OFF + MPU CSWR */
.exit_latency = 328 + 440,
.target_residency = 960,
-   .flags = CPUIDLE_FLAG_TIME_VALID | CPUIDLE_FLAG_COUPLED 
|
-CPUIDLE_FLAG_TIMER_STOP,
+   .flags = CPUIDLE_FLAG_TIME_VALID | CPUIDLE_FLAG_COUPLED,
.enter = omap_enter_idle_coupled,
.name = C2,
.desc = CPUx OFF, MPUSS CSWR,
@@ -199,8 +214,7 @@ static struct cpuidle_driver omap4_idle_driver = {
/* C3 - CPU0 OFF + CPU1 OFF + MPU OSWR

Re: [PATCH] ARM: OMAP4: Fix the boot regression with CPU_IDLE enabled

[Santosh Shilimkar]

On Wednesday 14 May 2014 03:44 PM, Daniel Lezcano wrote:
 On 05/13/2014 04:39 PM, Santosh Shilimkar wrote:
 On OMAP4 panda board, there have been several bug reports about boot
 hang and lock-ups with CPU_IDLE enabled. The root cause of the issue
 is missing interrupts while in idle state. Commit cb7094e8 {cpuidle / omap4 :
 use CPUIDLE_FLAG_TIMER_STOP flag} moved the broadcast notifiers to common
 code for right reasons but on OMAP4 which suffers from a nasty ROM code
 bug with GIC, commit ff999b8a {ARM: OMAP4460: Workaround for ROM bug ..},
 we loose interrupts which leads to issues like lock-up, hangs etc.

 Patch reverts commit cb7094 {cpuidle / omap4 : use CPUIDLE_FLAG_TIMER_STOP
 flag} to avoid the issue. With this change, OMAP4 panda boards, the mentioned
 issues are getting fixed. We no longer loose interrupts which was the cause
 of the regression.

 Cc: Roger Quadros rog...@ti.com
 Cc: Kevin Hilman khil...@linaro.org
 Cc: Tony Lindgren t...@atomide.com
 Cc: Daniel Lezcano daniel.lezc...@linaro.org
 Reported-tested-by: Roger Quadros rog...@ti.com
 Reported-tested-by: Kevin Hilman khil...@linaro.org
 Tested-by: Tony Lindgren t...@atomide.com
 Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
 ---
   arch/arm/mach-omap2/cpuidle44xx.c |   12 
   1 file changed, 8 insertions(+), 4 deletions(-)

 diff --git a/arch/arm/mach-omap2/cpuidle44xx.c 
 b/arch/arm/mach-omap2/cpuidle44xx.c
 index 01fc710..3e169d9 100644
 --- a/arch/arm/mach-omap2/cpuidle44xx.c
 +++ b/arch/arm/mach-omap2/cpuidle44xx.c
 @@ -14,6 +14,7 @@
   #include linux/cpuidle.h
   #include linux/cpu_pm.h
   #include linux/export.h
 +#include linux/clockchips.h

   #include asm/cpuidle.h
   #include asm/proc-fns.h
 @@ -83,6 +84,7 @@ static int omap_enter_idle_coupled(struct cpuidle_device 
 *dev,
   {
   struct idle_statedata *cx = state_ptr + index;
   u32 mpuss_can_lose_context = 0;
 +int cpu_id = smp_processor_id();

   /*
* CPU0 has to wait and stay ON until CPU1 is OFF state.
 @@ -110,6 +112,8 @@ static int omap_enter_idle_coupled(struct cpuidle_device 
 *dev,
   mpuss_can_lose_context = (cx-mpu_state == PWRDM_POWER_RET) 
(cx-mpu_logic_state == PWRDM_POWER_OFF);

 +clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, cpu_id);
 +
   /*
* Call idle CPU PM enter notifier chain so that
* VFP and per CPU interrupt context is saved.
 @@ -165,6 +169,8 @@ static int omap_enter_idle_coupled(struct cpuidle_device 
 *dev,
   if (dev-cpu == 0  mpuss_can_lose_context)
   cpu_cluster_pm_exit();

 +clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, cpu_id);
 +
   fail:
   cpuidle_coupled_parallel_barrier(dev, abort_barrier);
   cpu_done[dev-cpu] = false;
 @@ -189,8 +195,7 @@ static struct cpuidle_driver omap4_idle_driver = {
   /* C2 - CPU0 OFF + CPU1 OFF + MPU CSWR */
   .exit_latency = 328 + 440,
   .target_residency = 960,
 -.flags = CPUIDLE_FLAG_TIME_VALID | CPUIDLE_FLAG_COUPLED |
 - CPUIDLE_FLAG_TIMER_STOP,
 +.flags = CPUIDLE_FLAG_TIME_VALID | CPUIDLE_FLAG_COUPLED,
   .enter = omap_enter_idle_coupled,
   .name = C2,
   .desc = CPUx OFF, MPUSS CSWR,
 @@ -199,8 +204,7 @@ static struct cpuidle_driver omap4_idle_driver = {
   /* C3 - CPU0 OFF + CPU1 OFF + MPU OSWR */
   .exit_latency = 460 + 518,
   .target_residency = 1100,
 -.flags = CPUIDLE_FLAG_TIME_VALID | CPUIDLE_FLAG_COUPLED |
 - CPUIDLE_FLAG_TIMER_STOP,
 +.flags = CPUIDLE_FLAG_TIME_VALID | CPUIDLE_FLAG_COUPLED,
   .enter = omap_enter_idle_coupled,
   .name = C3,
   .desc = CPUx OFF, MPUSS OSWR,
 
 Shouldn't the broadcast timer to be setup with CLOCK_EVT_NOTIFY_BROADCAST_ON 
 also ?
 
Which is already taken care by __cpuidle_register_driver(). Note that setup code
is still used from generic code...

--
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: Fix the boot regression with CPU_IDLE enabled

[Santosh Shilimkar]

On Wednesday 14 May 2014 04:02 PM, Daniel Lezcano wrote:
 On 05/14/2014 09:50 PM, Santosh Shilimkar wrote:
 On Wednesday 14 May 2014 03:44 PM, Daniel Lezcano wrote:
 On 05/13/2014 04:39 PM, Santosh Shilimkar wrote:
 On OMAP4 panda board, there have been several bug reports about boot
 hang and lock-ups with CPU_IDLE enabled. The root cause of the issue
 is missing interrupts while in idle state. Commit cb7094e8 {cpuidle / 
 omap4 :
 use CPUIDLE_FLAG_TIMER_STOP flag} moved the broadcast notifiers to common
 code for right reasons but on OMAP4 which suffers from a nasty ROM code
 bug with GIC, commit ff999b8a {ARM: OMAP4460: Workaround for ROM bug ..},
 we loose interrupts which leads to issues like lock-up, hangs etc.

 Patch reverts commit cb7094 {cpuidle / omap4 : use CPUIDLE_FLAG_TIMER_STOP
 flag} to avoid the issue. With this change, OMAP4 panda boards, the 
 mentioned
 issues are getting fixed. We no longer loose interrupts which was the cause
 of the regression.

 Cc: Roger Quadros rog...@ti.com
 Cc: Kevin Hilman khil...@linaro.org
 Cc: Tony Lindgren t...@atomide.com
 Cc: Daniel Lezcano daniel.lezc...@linaro.org
 Reported-tested-by: Roger Quadros rog...@ti.com
 Reported-tested-by: Kevin Hilman khil...@linaro.org
 Tested-by: Tony Lindgren t...@atomide.com
 Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
 ---
 
 [ ... ]
 

 +clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, cpu_id);
 +
/*
 * Call idle CPU PM enter notifier chain so that
 * VFP and per CPU interrupt context is saved.
 @@ -165,6 +169,8 @@ static int omap_enter_idle_coupled(struct 
 cpuidle_device *dev,
if (dev-cpu == 0  mpuss_can_lose_context)
cpu_cluster_pm_exit();

 +clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, cpu_id);
 
 [ ... ]
 

 Shouldn't the broadcast timer to be setup with 
 CLOCK_EVT_NOTIFY_BROADCAST_ON also ?

 Which is already taken care by __cpuidle_register_driver(). Note that setup 
 code
 is still used from generic code...
 
 Nope, if the flag CPUIDLE_FLAG_TIMER_STOP is not set, the cpuidle framework 
 won't setup the timer.
 
I see. I assumed it was taken care. So we might have setup the timer too.

 static void __cpuidle_driver_init(struct cpuidle_driver *drv)
 {
 
 ...
 
 for (i = drv-state_count - 1; i = 0 ; i--) {
 if (drv-states[i].flags  CPUIDLE_FLAG_TIMER_STOP) {
May be you should start the bc timer in case 'CPUIDLE_FLAG_TIMER_STOP'
or 'CPUIDLE_FLAG_COUPLED'
 drv-bctimer = 1;
 break;
 }
 }
 
 ...
 
 }
 
 static int __cpuidle_register_driver(struct cpuidle_driver *drv)
 {
 ...
 
 if (drv-bctimer)
 on_each_cpu_mask(drv-cpumask,
 cpuidle_setup_broadcast_timer,
  (void *)CLOCK_EVT_NOTIFY_BROADCAST_ON, 1);
 
 ...
 }
 
 So the broadcast timer does not operate with this revert. Moreover, I am not 
 sure reverting this patch is the right solution.
 
With above mentioned change, it should work. Other alternatives is OMAP4 driver 
does
its won registration where it can start the timer. The way it was before the
consolidation.

Ofcourse if you have better fix, then great. 
--
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: omap4-panda-es boot issues with v3.15-rc4

[Santosh Shilimkar]

On Tuesday 13 May 2014 04:10 AM, Roger Quadros wrote:
 On 05/13/2014 01:07 AM, Tony Lindgren wrote:
 * Santosh Shilimkar santosh.shilim...@ti.com [140512 14:41]:
 On Sunday 11 May 2014 11:55 AM, Tony Lindgren wrote:
 * Kevin Hilman khil...@linaro.org [140509 16:46]:
 Roger Quadros rog...@ti.com writes:

 Kevin,

 On 05/09/2014 01:15 AM, Kevin Hilman wrote:
 Tony Lindgren t...@atomide.com writes:

 [...]

 ..but I think I found the cause for recent hangs on panda, just a wild
 guess based on looking at the recent cpuidle patches after v3.14.

 Looks like reverting 0b89e9aa2856 (cpuidle: delay enabling interrupts
 until all coupled CPUs leave idle) makes booting work reliably again
 on panda.

 Can you guys confirm, so far no issues here after few boot tests,
 but it might be too early to tell.

 Reverting that makes things a bit more stable, but it still eventually
 fails in the same way.  For me it took 8 boots for it to eventually
 fail.

 However, if I build with CONFIG_CPU_IDLE=n, it becomes much more stable
 (20+ boots in a row and still going.)


 Can you please test with CPU_IDLE enabled but C3 disabled as in below 
 patch?
 It worked for me 10/10 boots.

 Yup, it worked for me too for 10/10 boots in a row.

 But what has caused this regression, does it work reliably with let's
 say v3.13 or v3.12?

 IIRC things were stable till some CPUIDLE code consolidation happened.
 I don't recall exactly but some one did discuss about it a while back.

 OK that's good to hear.
  
 Can you re-run your test-cases with patch at end of the email. This
 is just a hunch so don't blame me if I waste your time testing the
 patch.

 Seems to work after adding #include linux/clockchips.h. I did about 10
 reboots and they all succeeded for me. Without your revert, I'm getting
 a hang (with sysrq not working) about 1/3 of the boots.

 Kevin, Roger, does the revert from Santosh work for you too?

 
 next-20140508 worked for me 10/10 times with Santosh's patch.
 The heartbeat LED behaves normally as well. So I like it :).
 
Great. Will post the patch with change log updated and cc
you guys.

Regards,
Santosh

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

[PATCH] ARM: OMAP4: Fix the boot regression with CPU_IDLE enabled

[Santosh Shilimkar]

On OMAP4 panda board, there have been several bug reports about boot
hang and lock-ups with CPU_IDLE enabled. The root cause of the issue
is missing interrupts while in idle state. Commit cb7094e8 {cpuidle / omap4 :
use CPUIDLE_FLAG_TIMER_STOP flag} moved the broadcast notifiers to common
code for right reasons but on OMAP4 which suffers from a nasty ROM code
bug with GIC, commit ff999b8a {ARM: OMAP4460: Workaround for ROM bug ..},
we loose interrupts which leads to issues like lock-up, hangs etc.

Patch reverts commit cb7094 {cpuidle / omap4 : use CPUIDLE_FLAG_TIMER_STOP
flag} to avoid the issue. With this change, OMAP4 panda boards, the mentioned
issues are getting fixed. We no longer loose interrupts which was the cause
of the regression.

Cc: Roger Quadros rog...@ti.com
Cc: Kevin Hilman khil...@linaro.org
Cc: Tony Lindgren t...@atomide.com
Cc: Daniel Lezcano daniel.lezc...@linaro.org
Reported-tested-by: Roger Quadros rog...@ti.com
Reported-tested-by: Kevin Hilman khil...@linaro.org
Tested-by: Tony Lindgren t...@atomide.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
 arch/arm/mach-omap2/cpuidle44xx.c |   12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/cpuidle44xx.c 
b/arch/arm/mach-omap2/cpuidle44xx.c
index 01fc710..3e169d9 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -14,6 +14,7 @@
 #include linux/cpuidle.h
 #include linux/cpu_pm.h
 #include linux/export.h
+#include linux/clockchips.h
 
 #include asm/cpuidle.h
 #include asm/proc-fns.h
@@ -83,6 +84,7 @@ static int omap_enter_idle_coupled(struct cpuidle_device *dev,
 {
struct idle_statedata *cx = state_ptr + index;
u32 mpuss_can_lose_context = 0;
+   int cpu_id = smp_processor_id();
 
/*
 * CPU0 has to wait and stay ON until CPU1 is OFF state.
@@ -110,6 +112,8 @@ static int omap_enter_idle_coupled(struct cpuidle_device 
*dev,
mpuss_can_lose_context = (cx-mpu_state == PWRDM_POWER_RET) 
 (cx-mpu_logic_state == PWRDM_POWER_OFF);
 
+   clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, cpu_id);
+
/*
 * Call idle CPU PM enter notifier chain so that
 * VFP and per CPU interrupt context is saved.
@@ -165,6 +169,8 @@ static int omap_enter_idle_coupled(struct cpuidle_device 
*dev,
if (dev-cpu == 0  mpuss_can_lose_context)
cpu_cluster_pm_exit();
 
+   clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, cpu_id);
+
 fail:
cpuidle_coupled_parallel_barrier(dev, abort_barrier);
cpu_done[dev-cpu] = false;
@@ -189,8 +195,7 @@ static struct cpuidle_driver omap4_idle_driver = {
/* C2 - CPU0 OFF + CPU1 OFF + MPU CSWR */
.exit_latency = 328 + 440,
.target_residency = 960,
-   .flags = CPUIDLE_FLAG_TIME_VALID | CPUIDLE_FLAG_COUPLED 
|
-CPUIDLE_FLAG_TIMER_STOP,
+   .flags = CPUIDLE_FLAG_TIME_VALID | CPUIDLE_FLAG_COUPLED,
.enter = omap_enter_idle_coupled,
.name = C2,
.desc = CPUx OFF, MPUSS CSWR,
@@ -199,8 +204,7 @@ static struct cpuidle_driver omap4_idle_driver = {
/* C3 - CPU0 OFF + CPU1 OFF + MPU OSWR */
.exit_latency = 460 + 518,
.target_residency = 1100,
-   .flags = CPUIDLE_FLAG_TIME_VALID | CPUIDLE_FLAG_COUPLED 
|
-CPUIDLE_FLAG_TIMER_STOP,
+   .flags = CPUIDLE_FLAG_TIME_VALID | CPUIDLE_FLAG_COUPLED,
.enter = omap_enter_idle_coupled,
.name = C3,
.desc = CPUx OFF, MPUSS OSWR,
-- 
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: omap4-panda-es boot issues with v3.15-rc4

[Santosh Shilimkar]

On Sunday 11 May 2014 11:55 AM, Tony Lindgren wrote:
 * Kevin Hilman khil...@linaro.org [140509 16:46]:
 Roger Quadros rog...@ti.com writes:

 Kevin,

 On 05/09/2014 01:15 AM, Kevin Hilman wrote:
 Tony Lindgren t...@atomide.com writes:

 [...]

 ..but I think I found the cause for recent hangs on panda, just a wild
 guess based on looking at the recent cpuidle patches after v3.14.

 Looks like reverting 0b89e9aa2856 (cpuidle: delay enabling interrupts
 until all coupled CPUs leave idle) makes booting work reliably again
 on panda.

 Can you guys confirm, so far no issues here after few boot tests,
 but it might be too early to tell.

 Reverting that makes things a bit more stable, but it still eventually
 fails in the same way.  For me it took 8 boots for it to eventually
 fail.

 However, if I build with CONFIG_CPU_IDLE=n, it becomes much more stable
 (20+ boots in a row and still going.)


 Can you please test with CPU_IDLE enabled but C3 disabled as in below patch?
 It worked for me 10/10 boots.

 Yup, it worked for me too for 10/10 boots in a row.
 
 But what has caused this regression, does it work reliably with let's
 say v3.13 or v3.12?
 
IIRC things were stable till some CPUIDLE code consolidation happened.
I don't recall exactly but some one did discuss about it a while back.

Can you re-run your test-cases with patch at end of the email. This
is just a hunch so don't blame me if I waste your time testing the
patch.

regards,
Santosh

From bdd30d68f8fa659aa0e3ce436f94029a7719036b Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Mon, 12 May 2014 17:37:59 -0400
Subject: [PATCH] Revert cpuidle / omap4 : use CPUIDLE_FLAG_TIMER_STOP flag

This reverts commit cb7094e848f7bcaa0a4cda3db4b232f08dbf5b78.

Conflicts:

arch/arm/mach-omap2/cpuidle44xx.c
---
 arch/arm/mach-omap2/cpuidle44xx.c |   11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/cpuidle44xx.c 
b/arch/arm/mach-omap2/cpuidle44xx.c
index 01fc710..aae3606 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -83,6 +83,7 @@ static int omap_enter_idle_coupled(struct cpuidle_device *dev,
 {
struct idle_statedata *cx = state_ptr + index;
u32 mpuss_can_lose_context = 0;
+   int cpu_id = smp_processor_id();
 
/*
 * CPU0 has to wait and stay ON until CPU1 is OFF state.
@@ -110,6 +111,8 @@ static int omap_enter_idle_coupled(struct cpuidle_device 
*dev,
mpuss_can_lose_context = (cx-mpu_state == PWRDM_POWER_RET) 
 (cx-mpu_logic_state == PWRDM_POWER_OFF);
 
+   clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, cpu_id);
+
/*
 * Call idle CPU PM enter notifier chain so that
 * VFP and per CPU interrupt context is saved.
@@ -165,6 +168,8 @@ static int omap_enter_idle_coupled(struct cpuidle_device 
*dev,
if (dev-cpu == 0  mpuss_can_lose_context)
cpu_cluster_pm_exit();
 
+   clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, cpu_id);
+
 fail:
cpuidle_coupled_parallel_barrier(dev, abort_barrier);
cpu_done[dev-cpu] = false;
@@ -189,8 +194,7 @@ static struct cpuidle_driver omap4_idle_driver = {
/* C2 - CPU0 OFF + CPU1 OFF + MPU CSWR */
.exit_latency = 328 + 440,
.target_residency = 960,
-   .flags = CPUIDLE_FLAG_TIME_VALID | CPUIDLE_FLAG_COUPLED 
|
-CPUIDLE_FLAG_TIMER_STOP,
+   .flags = CPUIDLE_FLAG_TIME_VALID | CPUIDLE_FLAG_COUPLED,
.enter = omap_enter_idle_coupled,
.name = C2,
.desc = CPUx OFF, MPUSS CSWR,
@@ -199,8 +203,7 @@ static struct cpuidle_driver omap4_idle_driver = {
/* C3 - CPU0 OFF + CPU1 OFF + MPU OSWR */
.exit_latency = 460 + 518,
.target_residency = 1100,
-   .flags = CPUIDLE_FLAG_TIME_VALID | CPUIDLE_FLAG_COUPLED 
|
-CPUIDLE_FLAG_TIMER_STOP,
+   .flags = CPUIDLE_FLAG_TIME_VALID | CPUIDLE_FLAG_COUPLED,
.enter = omap_enter_idle_coupled,
.name = C3,
.desc = CPUx OFF, MPUSS OSWR,
-- 
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 3/5] irqchip: crossbar: Skip some irqs from getting mapped to crossbar

[Santosh Shilimkar]

On Friday 09 May 2014 08:54 AM, Nishanth Menon wrote:
 On 05/08/2014 11:22 PM, Joel Fernandes wrote:
 On Thu, May 8, 2014 at 7:25 PM, Santosh Shilimkar
 santosh.shilim...@ti.com wrote:
 [...]
 Ok, thanks for pointing to the post.

 
 
 Yep - thanks Santosh for clarifying this. Now, we still have the
 issues that I pointed out in [1] - without resolving which, we should
 not enable crossbar for dra74x/72x.
 
 A. taking example of PMU
   interrupts = GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH
 this wont work. instead the crossbar driver needs some sort of a hint
 to know that it should not map these on crossbar register instead
 assign GIC mapping directly.
 
 I propose doing the following
 #define GIC_CROSSBAR_PASSTHROUGH(irq_no) ((irq_no) | (0x1  31))
 
 and dts will define the following:
 interrupts = GIC_SPI GIC_CROSSBAR_PASSTHROUGH(131) IRQ_TYPE_LEVEL_HIGH
 
 This will also work for the other cases (B.2, B.3)
 
 For B.2: L3_APP_IRQ:
 instead of:
 interrupts = GIC_SPI  5 IRQ_TYPE_LEVEL_HIGH
 we do:
 interrupts = GIC_SPI GIC_CROSSBAR_PASSTHROUGH(10) IRQ_TYPE_LEVEL_HIGH
 
 For B.3: NMI
 interrupts = GIC_SPI GIC_CROSSBAR_PASSTHROUGH(133) IRQ_TYPE_LEVEL_HIGH
 
We can't do add a flag to generic interrupt controller flags since its
very specific to cross-bar.

 xlate is easy -
 
 diff --git a/drivers/irqchip/irq-crossbar.c
 b/drivers/irqchip/irq-crossbar.c
 index de021638..fd09ab4 100644
 --- a/drivers/irqchip/irq-crossbar.c
 +++ b/drivers/irqchip/irq-crossbar.c
 @@ -112,6 +112,10 @@ static int crossbar_domain_xlate(struct
 irq_domain *d,
  {
 unsigned long ret;
 
 +   /* Check to see if direct GIC mapping is required */
 +   if (intspec[1]  BIT(31))
 +   return intspec[1]  ~BIT[31];
 +
 ret = get_prev_map_irq(intspec[1]);
 if (!IS_ERR_VALUE(ret))
 goto found;
 
 But then, crossbar_domain_map and crossbar_domain_unmap need hints as
 well to know that there is no corresponding crossbar registers.
 Have'nt thought through that yet. Looking to hear about opinions here.
 
 
May be we need additional property like reserved to take care of 1:1
map.

ti,irqs-direct-map = 131 132;

--
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/5] irqchip: crossbar: Skip some irqs from getting mapped to crossbar

[Santosh Shilimkar]

On Friday 09 May 2014 09:36 AM, Nishanth Menon wrote:
 On 05/09/2014 08:27 AM, Santosh Shilimkar wrote:
 On Friday 09 May 2014 08:54 AM, Nishanth Menon wrote:
 On 05/08/2014 11:22 PM, Joel Fernandes wrote:
 On Thu, May 8, 2014 at 7:25 PM, Santosh Shilimkar
 santosh.shilim...@ti.com wrote:
 [...]
 Ok, thanks for pointing to the post.



 Yep - thanks Santosh for clarifying this. Now, we still have the
 issues that I pointed out in [1] - without resolving which, we should
 not enable crossbar for dra74x/72x.

 A. taking example of PMU
 interrupts = GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH
 this wont work. instead the crossbar driver needs some sort of a hint
 to know that it should not map these on crossbar register instead
 assign GIC mapping directly.

 I propose doing the following
 #define GIC_CROSSBAR_PASSTHROUGH(irq_no) ((irq_no) | (0x1  31))

 and dts will define the following:
 interrupts = GIC_SPI GIC_CROSSBAR_PASSTHROUGH(131) IRQ_TYPE_LEVEL_HIGH

 This will also work for the other cases (B.2, B.3)

 For B.2: L3_APP_IRQ:
 instead of:
 interrupts = GIC_SPI  5 IRQ_TYPE_LEVEL_HIGH
 we do:
 interrupts = GIC_SPI GIC_CROSSBAR_PASSTHROUGH(10) IRQ_TYPE_LEVEL_HIGH

 For B.3: NMI
 interrupts = GIC_SPI GIC_CROSSBAR_PASSTHROUGH(133) IRQ_TYPE_LEVEL_HIGH

 We can't do add a flag to generic interrupt controller flags since its
 very specific to cross-bar.

 xlate is easy -

 diff --git a/drivers/irqchip/irq-crossbar.c
 b/drivers/irqchip/irq-crossbar.c
 index de021638..fd09ab4 100644
 --- a/drivers/irqchip/irq-crossbar.c
 +++ b/drivers/irqchip/irq-crossbar.c
 @@ -112,6 +112,10 @@ static int crossbar_domain_xlate(struct
 irq_domain *d,
  {
 unsigned long ret;

 +   /* Check to see if direct GIC mapping is required */
 +   if (intspec[1]  BIT(31))
 +   return intspec[1]  ~BIT[31];
 +
 ret = get_prev_map_irq(intspec[1]);
 if (!IS_ERR_VALUE(ret))
 goto found;

 But then, crossbar_domain_map and crossbar_domain_unmap need hints as
 well to know that there is no corresponding crossbar registers.
 Have'nt thought through that yet. Looking to hear about opinions here.


 May be we need additional property like reserved to take care of 1:1
 map.

 ti,irqs-direct-map = 131 132;

 We already have equivalents for these - reserved and skip. Problem is
 how does crossbar driver know the difference between direct maps and
 crossbar value?
 
 6 is one of those reserved ones. dts for a device says:
 interrupts = GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH
 
 
 Now, xlate gets intspec[1] = 6.  6 is valid crossbar number
 PRM_IRQ_MPU, however GIC 6 is mapped to WD_TIMER_MPU_C1_IRQ_WARN -
 you need to be able to get a hint that this is direct mapping dts
 intended.
 
 in the 6 example:
 
 How do i get PRM_IRQ_MPU?
 interrupts = GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH
 
 How do I get WD_TIMER_MPU_C1_IRQ_WARN?
 interrupts = GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH ? - that wont work as
 crossbar driver thinks it is crossbar 6 (PRM_IRQ_MPU)
 
Looks like I am missing something. Is the issue because of SPI offset (32)
which makes above confusion ?


--
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/5] irqchip: crossbar: Skip some irqs from getting mapped to crossbar

[Santosh Shilimkar]

On Friday 09 May 2014 10:00 AM, Nishanth Menon wrote:
 On 05/09/2014 08:45 AM, Santosh Shilimkar wrote:
 On Friday 09 May 2014 09:36 AM, Nishanth Menon wrote:
[..]

 Looks like I am missing something. Is the issue because of SPI offset (32)
 which makes above confusion ?
 
 The way we modelled crossbar is that the irqchip is GIC and routable
 mapper is crossbar - which makes sense. now for every interrupts
 description we try to find a map using the crossbar driver as the irq
 framework rightly identifies that peripheral interrupts are routable
 and crossbar driver is the guy who knows how to map these to a proper
 GIC interrupt number. So far, we are good.
 
 Now the trouble starts when our hardware description in dts assumes
 that every peripheral interrupt is a routable interrupt - as this
 thread describes - that is NOT the case.
 
 Now the question is how do you differentiate?
 
 interrupts = GIC_SPI Number Level
 
 GIC_SPI is correct since we are attempting to describe the SPI
 interrupt (offset what ever it is, is a NOP from conceptual discussion).
 
 Level is fine as well.
 
 Number: what does this indicate? crossbar number is what we have
 assumed so far. however, then you loose the ability to describe
 interrupts on GIC SPI which dont have crossbar interrupts.
 
 Question is how do we differentiate between the two?
 
Updating the thread about an off-list discussion on $subject.
Nishant understood the how he was indirectly changing the meaning
of IRQ bindings and why its a bad idea. The point which
didn't came out clearly on the list was also the limited set
of route-able IRQ registers at cross-bar which is utter non-sense
and broken hardware. And since we are patching up the cross-bar
hardware bugs, it should be done such a way that the cross-bar
device tree bindings reflect that.

Here is the way forward we decided...
Add additional/optional properties to cross-bar binding
so that you can represent IRQs which can't be routed by
cross-bar. Something like 'MAX_ROUTABLE_IRQS'.

Then on the cleint modules which has the shortcoming, you just
add MAX_ROUTABLE_IRQS to those IRQs. That way cross-bar
driver fails to route them and just returns the offset
IRQline thinking it is already hard wired.

As a proof of concept I suggest you to just create a bidnig
patch with example usage of such case in the Documentation
and send it for review.

Copy Device Tree folks and Thomas to see if they are ok with it
or can suggest some better way to deal with the issue.

Thanks for the patience and explaining the issue repeatedly.

regards,
Santosh





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

Re: [PATCH 1/2] gpio: omap: prepare and unprepare the debounce clock

[Santosh Shilimkar]

On Wednesday 23 April 2014 02:11 AM, Rajendra Nayak wrote:
 Replace the clk_enable()s with a clk_prepare_enable() and
 the clk_disables()s with a clk_disable_unprepare()
 
 This never showed issues due to the OMAP platform code (hwmod)
 leaving these clocks in clk_prepare()ed state by default.
 
 Reported-by: Kishon Vijay Abraham I kis...@ti.com
 Signed-off-by: Rajendra Nayak rna...@ti.com
 Cc: linux-g...@vger.kernel.org
 Cc: Santosh Shilimkar santosh.shilim...@ti.com
 Cc: Kevin Hilman khil...@deeprootsystems.com
 ---
  drivers/gpio/gpio-omap.c |   10 +-
  1 file changed, 5 insertions(+), 5 deletions(-)
 
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com

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

Re: [PATCH 1/2] gpio: omap: prepare and unprepare the debounce clock

[Santosh Shilimkar]

On Wednesday 23 April 2014 02:11 AM, Rajendra Nayak wrote:
 Replace the clk_enable()s with a clk_prepare_enable() and
 the clk_disables()s with a clk_disable_unprepare()
 
 This never showed issues due to the OMAP platform code (hwmod)
 leaving these clocks in clk_prepare()ed state by default.
 
 Reported-by: Kishon Vijay Abraham I kis...@ti.com
 Signed-off-by: Rajendra Nayak rna...@ti.com
 Cc: linux-g...@vger.kernel.org
 Cc: Santosh Shilimkar santosh.shilim...@ti.com
 Cc: Kevin Hilman khil...@deeprootsystems.com
 ---
$subject patch looks fine but I don't see patch 2/2 assuming this
is series of two patches.

Acked-by: Santosh Shilimkar santosh.shilim...@ti.com


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

Re: [PATCH 3/5] irqchip: crossbar: Skip some irqs from getting mapped to crossbar

[Santosh Shilimkar]

On Thursday 08 May 2014 06:43 PM, Joel Fernandes wrote:
 On Thu, May 8, 2014 at 3:37 PM, Nishanth Menon n...@ti.com wrote:
 On 14:24-20140508, Joel Fernandes wrote:
 On 05/05/2014 09:18 AM, Sricharan R wrote:
 From: Nishanth Menon n...@ti.com

 When, in the system due to varied reasons, interrupts might be unusable
 due to hardware behavior, but register maps do exist, then those interrupts
 should be skipped while mapping irq to crossbars.


 Just wondering, instead of hardcoding this data in the code, and
 introducing additional flags (IRQ_SKIP), why not just put these GIC IRQs
 in the ti,irq-reserved property in DTS for platforms where such IRQs are
 not usable. That way you're skipping these IRQs anyway.

 Also that would avoid adding more hard coded data for future SoCs into
 the source for such IRQs that must be skipped, and also reduces LOC.


 Good question - lets try to explain the hardware a little here -
 obviously a driver that cannot use the hardware is useless compared to
 reducing LOC count ;).. and apologies about the long reply..

 Basic understanding:
 GIC has 160 SPIs and number of hardware block interrupt sources is around or
 more than 400. So, in comes crossbar - which is basically a mapper by
 allowing us to select an hardware block interrupt source (identified as
 crossbar_number or cb_no in code). So all we have to do is to write to a
 register in crossbar corresponding to GIC and viola, we now routed the
 interrupt source to a GIC interrupt of our choice. At least the
 Specification reads so until you drill down to the details.
 
 Thanks for the long explanation and the diagrams!
 
 Yes, I feel there is no other way and with so many HW bugs, I think it
 makes sense to make it a real irqchip driver.

It doesn't because its not an irqchip. 
 
 Further since not everything goes through the crossbar and some are
 direct mapped like your diagram, the correct fix is probably making it
 an irqchip and doing the interrupt controller parenting correctly in
 DT.
 
 That would take care of A), because users of such direct mapped
 interrupts will go through the GIC interrupt controller directly.
 
 It will also take care of B), because if writing to cross bar has no
 effect for a particular IRQ, or if those IRQs are hard-wired to
 something, as you said, then that something should go through the GIC
 directly.
 
 I can try to whip up something like this if it makes sense, let me know...
 
I have been ignoring this series considering they were just fixes
but you comments are like re-inventing wheel. Please read all
the old threads and comments from Thomas and me on why we took
approach and why it is not an irqchip. There is no need to complicate
it further.


Regards,
Santosh

--
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/5] irqchip: crossbar: Skip some irqs from getting mapped to crossbar

[Santosh Shilimkar]

On Thursday 08 May 2014 08:13 PM, Joel Fernandes wrote:
 On Thu, May 8, 2014 at 6:05 PM, Santosh Shilimkar
 santosh.shilim...@ti.com wrote:
 [..]
 Further since not everything goes through the crossbar and some are
 direct mapped like your diagram, the correct fix is probably making it
 an irqchip and doing the interrupt controller parenting correctly in
 DT.

 That would take care of A), because users of such direct mapped
 interrupts will go through the GIC interrupt controller directly.

 It will also take care of B), because if writing to cross bar has no
 effect for a particular IRQ, or if those IRQs are hard-wired to
 something, as you said, then that something should go through the GIC
 directly.

 I can try to whip up something like this if it makes sense, let me know...

 I have been ignoring this series considering they were just fixes
 but you comments are like re-inventing wheel. Please read all
 the old threads and comments from Thomas and me on why we took
 approach and why it is not an irqchip. There is no need to complicate
 it further.
 
 Are you talking about the discussion on this thread?
 http://lists.infradead.org/pipermail/linux-arm-kernel/2013-August/194318.html
 
 I didn't really get a sense that there was a common agreement that
 irqchip is not the way to go there. I can stand corrected if there was
 a common consensus that irqchip is not the right solution (with any
 specific comments why). There was a concern in the thread that making
 it irqchip doesn't help dma reuse the infrastructure, but that concern
 seems moot now that the driver is proposed to live in drivers/irqchip.
 
Obviously you haven't read all the threads... Please read [1]. There
was a reason I said read *all* the threads. Because anyone who looks
at this hardware IP block thinks it can be irqchip. You are not the
first one who said that.

The concern was really not where the code resides but what the actual
hardware is and how can it fit into Linux. The whole reason I was
actually against irqhcip from beginning of crossbar series was the
hardware is not irqchip rather just a router. Thomas the formally
NAKed that approach on thread [1]. If there are bugs, doesn't mean
we can make fit the hardware into some subsystem where it can't be
described.

Regards,
Santosh
[1] https://lkml.org/lkml/2013/9/13/413

--
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] gpio: omap: implement get_direction

[Santosh Shilimkar]

On Thursday 24 April 2014 09:13 AM, Linus Walleij wrote:
 On Thu, Apr 24, 2014 at 8:57 AM,  yegorsli...@googlemail.com wrote:
 
 From: Yegor Yefremov yegorsli...@googlemail.com

 This patch implements gpio_chip's get_direction() routine, that
 lets other drivers get particular GPIOs direction using
 struct gpio_desc.

 Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com
 Acked-by: Javier Martinez Canillas jav...@dowhile0.org
 ---
 Changes:
 v3: get rid of _get_gpio_direction() (Linus Walleij)
 v2: rework return value calculation
 
 Looks good to me, Kevin, Santosh?
 
Looks fine to me as well.
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com

 Part of me wants to list Javier as maintainer for this driver.
 
Am ok with it as well.

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

Re: [PATCH v3 0/3] ARM: OMAP2+: AM437x: L2 cache support

[Santosh Shilimkar]

On Tuesday 22 April 2014 04:28 AM, Sekhar Nori wrote:
 This patch series adds L2 cache support for AM437x
 and does some clean-ups for existing OMAP4 support
 along the way (no functional changes). On OMAP4 Panda,
 the Aux control value remains 0x7e47 before and
 after the series.
 
 Tested on OMAP4 Panda and AM437x EPOS EVMs.
 
 It is based on RMK's 75 patch series titled l2c series +
 the patch contained in 
 https://www.mail-archive.com/linux-omap@vger.kernel.org/msg103439.html
 
 Sekhar Nori (3):
   ARM: OMAP2+: L2 cache: get rid of init call
   ARM: OMAP2+: L2 cache: git rid of redundant cache replacement policy
 setting
   ARM: OMAP2+: AM43x: L2 cache support
 
For the whole series,
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com

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

Re: [PATCH] ARM: OMAP5: Switch to THUMB mode if needed on secondary CPU

[Santosh Shilimkar]

On Tuesday 22 April 2014 02:31 PM, Joel Fernandes wrote:
 On my DRA7 system, when the kernel is built in THUMB mode, the secondary CPU
 (Cortex A15) fails to come up causing SMP boot on second CPU to timeout. This
 seems to be because the CPU is in ARM mode once the ROM hands over control to
 the kernel.  Switch to THUMB mode if required once the kernel is control of
 secondary CPU. On OMAP4 on the other hand, it appears to be in THUMB mode on
 entry so this is not required and SMP boot works as is.
 
 Cc: Santosh Shilimkar santosh.shilim...@ti.com
 Cc: Russell King li...@arm.linux.org.uk
 Cc: Nishanth Menon n...@ti.com
 Cc: Tony Lindgren t...@atomide.com
 Signed-off-by: Joel Fernandes jo...@ti.com
 ---
  arch/arm/mach-omap2/omap-headsmp.S |8 ++--
  1 file changed, 6 insertions(+), 2 deletions(-)
 
Looks fine to me ..
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com


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

Re: [PATCH V2 01/19] bus: omap_l3_noc: Fix copyright information

[Santosh Shilimkar]

On Thursday 17 April 2014 04:49 PM, Nishanth Menon wrote:
 This is an embarrassing patch :(.
 
 Texas Corporation does not make OMAP. Texas Instruments Inc does.
 
Yeah..

 For that matter I dont seem to be able to find a Texas Corporation on
 the internet either.

:D
 
 While at it, update coverage to the current year and update the template
 to remove redundant information and use the standard boiler plate
 licensing.
 
 Signed-off-by: Nishanth Menon n...@ti.com
 ---
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com

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

Re: [PATCH V2 02/19] bus: omap_l3_noc: rename functions and data to omap_l3

[Santosh Shilimkar]

On Thursday 17 April 2014 04:49 PM, Nishanth Menon wrote:
 From: Sricharan R r.sricha...@ti.com
 
 Since omap_l3_noc driver is now being used for OMAP5 and reusable with
 DRA7 and AM437x, using omap4 specific naming is misleading.
 
 Signed-off-by: Sricharan R r.sricha...@ti.com
 Signed-off-by: Nishanth Menon n...@ti.com
 ---
 
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com

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

Re: [PATCH V2 03/19] bus: omap_l3_noc: remove iclk from omap_l3 struct

[Santosh Shilimkar]

On Thursday 17 April 2014 04:49 PM, Nishanth Menon wrote:
 we do not use iclk directly anymore. And, even if we had to, we
 should be using pm_runtime APIs to do the same to be completely SoC
 independent.
 
 Signed-off-by: Nishanth Menon n...@ti.com
 ---
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com

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

Re: [PATCH V2 00/19] bus: omap_l3_noc: driver cleanups and support for DRA7/AM4372

[Santosh Shilimkar]

Nishant,

On Thursday 17 April 2014 04:49 PM, Nishanth Menon wrote:
 The following V2 of the series is based on v3.15-rc1 + peter's patch series:
   patch #1: https://patchwork.kernel.org/patch/3923141/
   (drivers: bus: omap_l3: Convert to use devm_kzalloc)
 
   patch #2: https://patchwork.kernel.org/patch/3923061/
   (drivers: bus: omap_l3: Convert to use devm_ioremap_resource() )
 
   patch #3: https://patchwork.kernel.org/patch/3923101/
   (drivers: bus: omap_l3: Convert to use devm_request_irq())
 
   patch #4: https://patchwork.kernel.org/patch/3923081/
   (drivers: bus: omap_l3: Remove the platform driver's remove function)
 
   patch #5: https://patchwork.kernel.org/patch/3923121/
   (drivers: bus: omap_l3: Change pr_crit() to dev_err() when IRQ request
   fails)
 
 V1 was originally posted here: 
 http://marc.info/?l=linux-omapm=139749383932575w=2
 
 V2 introduces the following changes:
   - Additional bug fix detected during additional testing (all tests 
 complete now). patch #12
   - reordering of patches to order logical changes and reduce code churn.
   - interrupt handler split up and additional information now provided in 
 log to aid debug when error occur
   - patches are marked where new (12,14,15,16).
   - DRA7 updated from master document for all DRA7 variants.
 
 This series cleansup omap_l3_noc driver and adds data to support DRA7
 and AM437x SoCs.
 
I looked at the series and its looks pretty good. Thanks for fixups, updates.
For whole series,
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com

 Patches(including Peter's) is available here:
 https://github.com/nmenon/linux-2.6-playground/commits/l3noc/driver-fixes-v2
 
Can Tony pull this branch for 3.16 then which includes Peter's series as well ?

Tony, Will you be able to line these up via arm-soc tree ?

Regards,
Santosh

--
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 05/19] bus: omap_l3_noc: switch over to relaxed variants of readl/writel

[Santosh Shilimkar]

On Thursday 17 April 2014 05:52 PM, Felipe Balbi wrote:
 Hi,
 
 On Thu, Apr 17, 2014 at 03:49:21PM -0500, Nishanth Menon wrote:
 Currently we use __raw_readl and writel in this driver, however, there
 
 __raw_* and *_relaxed variants are the same, just have a look asm/io.h
 
Except the relaxed version can take care of endian conversion if
needed. :-)

 297 #define readb_relaxed(c) ({ u8  __r = __raw_readb(c); __r; })
 298 #define readw_relaxed(c) ({ u16 __r = le16_to_cpu((__force __le16) \
 299 __raw_readw(c)); __r; })
 300 #define readl_relaxed(c) ({ u32 __r = le32_to_cpu((__force __le32) \
 301 __raw_readl(c)); __r; })
 302 
 303 #define writeb_relaxed(v,c) __raw_writeb(v,c)
 304 #define writew_relaxed(v,c) __raw_writew((__force u16) 
 cpu_to_le16(v),c)
 305 #define writel_relaxed(v,c) __raw_writel((__force u32) 
 cpu_to_le32(v),c)
 

--
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: L3 custom error on OMAP4460

[Santosh Shilimkar]

On Saturday 12 April 2014 05:06 PM, Joachim Eastwood wrote:
 Hi,
 
 I getting the following error on Linus master right now.
 
 [ 2.166320] WARNING: CPU: 0 PID: 0 at drivers/bus/omap_l3_noc.c:113
 l3_interrupt_handler+0xf4/0x154()
 [ 2.166320] L3 custom error: MASTER:MPU TARGET:L4 PER2
 [ 2.166320] Modules linked in:
 [ 2.166351] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
 3.14.0-12542-gfb5ce8367c24 #11
 [ 2.166381] [c0014ea8] (unwind_backtrace) from [c0011b8c]
 (show_stack+0x10/0x14)
 [ 2.166381] [c0011b8c] (show_stack) from [c05a9580] (dump_stack+0x84/0x94)
 [ 2.166412] [c05a9580] (dump_stack) from [c0036b08]
 (warn_slowpath_common+0x70/0x8c)
 [ 2.166412] [c0036b08] (warn_slowpath_common) from [c0036b54]
 (warn_slowpath_fmt+0x30/0x40)
 [ 2.166412] [c0036b54] (warn_slowpath_fmt) from [c02876f0]
 (l3_interrupt_handler+0xf4/0x154)
 [ 2.166442] [c02876f0] (l3_interrupt_handler) from [c0085c7c]
 (handle_irq_event_percpu+0x54/0x1cc)
 [ 2.166473] [c0085c7c] (handle_irq_event_percpu) from [c0085e30]
 (handle_irq_event+0x3c/0x5c)
 [ 2.166473] [c0085e30] (handle_irq_event) from [c0088e30]
 (handle_fasteoi_irq+0xac/0x1a0)
 [ 2.166473] [c0088e30] (handle_fasteoi_irq) from [c008535c]
 (generic_handle_irq+0x2c/0x3c)
 [ 2.166503] [c008535c] (generic_handle_irq) from [c000ea80]
 (handle_IRQ+0x40/0x90)
 [ 2.166503] [c000ea80] (handle_IRQ) from [c0008594]
 (gic_handle_irq+0x2c/0x5c)
 [ 2.166534] [c0008594] (gic_handle_irq) from [c05b0bc4]
 (__irq_svc+0x44/0x58)
 [ 2.166534] Exception stack(0xc087bf58 to 0xc087bfa0)
 [ 2.166534] bf40: 0001 0001
 [ 2.166534] bf60:  c08856f8 c087a000 c087a000 c08d9544
 c0882548 c087a000 ee7ffc40
 [ 2.166564] bf80: c08824e0 c05b9cec  c087bfa0 c007a0f0
 c000eda8 2113 
 [ 2.166564] [c05b0bc4] (__irq_svc) from [c000eda8] 
 (arch_cpu_idle+0x24/0x30)
 [ 2.166595] [c000eda8] (arch_cpu_idle) from [c00718b0]
 (cpu_startup_entry+0x138/0x204)
 [ 2.166595] [c00718b0] (cpu_startup_entry) from [c0814b10]
 (start_kernel+0x370/0x37c)
 [ 2.166625] [c0814b10] (start_kernel) from [80008074] (0x80008074)
 
 Not sure what to make of it. Anyone got any idea?
 
 Right before the L3 custom WARN I also get these messages from the
 des/aes crypot drivers. Might be unrelated, though.
 [ 2.134643] omap-aes 4b501000.aes: _od_fail_runtime_resume: FIXME:
 missing hwmod/omap_dev info
 [ 2.143737] omap-aes 4b501000.aes: omap_aes_probe: failed to get_sync(-19)
 [ 2.151000] omap-aes 4b501000.aes: initialization failed.
 [ 2.157196] omap-des 480a5000.des: _od_fail_runtime_resume: FIXME:
 missing hwmod/omap_dev info
 [ 2.166290] omap-des 480a5000.des: OMAP DES hw accel rev: 0.0
 
 The hardware is a VAR-STK-OM44 dev kit. I got one patch on top of
 Linus master which is the DT support patch which I posted a couple of
 hours ago.
 
Have you tried removing AES from the build ? Probably worth a
try.

Regards,
Santosh

--
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/5] gpio: omap: convert to use irq_domain_add_simple()

[Santosh Shilimkar]

On Sunday 06 April 2014 10:58 AM, Javier Martinez Canillas wrote:
 The GPIO OMAP driver supports different OMAP SoC families and
 not all of them have the needed support to use the linear IRQ
 domain mapping like OMAP1 that use the legacy domain mapping.
 
 But this special check is not necessary since the simple IRQ
 domain mapping is able to handle both cases. Having a zero
 IRQ offset will be interpreted as a linear domain case while
 a non-zero value will be interpreted as a legacy domain case.
 
 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 ---
  drivers/gpio/gpio-omap.c | 15 ---
  1 file changed, 4 insertions(+), 11 deletions(-)
 
 diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
 index 19b886c..3ee9b8d 100644
 --- a/drivers/gpio/gpio-omap.c
 +++ b/drivers/gpio/gpio-omap.c
 @@ -1138,9 +1138,7 @@ static int omap_gpio_probe(struct platform_device *pdev)
   const struct omap_gpio_platform_data *pdata;
   struct resource *res;
   struct gpio_bank *bank;
 -#ifdef CONFIG_ARCH_OMAP1
 - int irq_base;
 -#endif
 + int irq_base = 0;
  
   match = of_match_device(of_match_ptr(omap_gpio_match), dev);
  
 @@ -1185,21 +1183,16 @@ static int omap_gpio_probe(struct platform_device 
 *pdev)
  #ifdef CONFIG_ARCH_OMAP1
   /*
* REVISIT: Once we have OMAP1 supporting SPARSE_IRQ, we can drop
 -  * irq_alloc_descs() and irq_domain_add_legacy() and just use a
 -  * linear IRQ domain mapping for all OMAP platforms.
 +  * irq_alloc_descs() since a base IRQ offset will no longer be needed.
*/
   irq_base = irq_alloc_descs(-1, 0, bank-width, 0);
   if (irq_base  0) {
   dev_err(dev, Couldn't allocate IRQ numbers\n);
   return -ENODEV;
   }
 -
 - bank-domain = irq_domain_add_legacy(node, bank-width, irq_base,
 -  0, irq_domain_simple_ops, NULL);
 -#else
 - bank-domain = irq_domain_add_linear(node, bank-width,
 -  irq_domain_simple_ops, NULL);
  #endif
 + bank-domain = irq_domain_add_simple(node, bank-width, irq_base,
 +  irq_domain_simple_ops, NULL);
   if (!bank-domain) {
   dev_err(dev, Couldn't register an IRQ domain\n);
   return -ENODEV;
 
Looks good.
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com

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

Re: [PATCH 2/5] gpio: omap: check gpiochip_add() return value

[Santosh Shilimkar]

On Sunday 06 April 2014 10:58 AM, Javier Martinez Canillas wrote:
 The gpiochip_add() function can fail if the chip cannot
 be registered so the return value has to be checked and
 the error propagated in case it happens.
 
 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 ---
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com


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

Re: [PATCH 3/5] gpio: omap: add a GPIO_OMAP option instead of using ARCH_OMAP

[Santosh Shilimkar]

On Sunday 06 April 2014 10:58 AM, Javier Martinez Canillas wrote:
 The ARCH_OMAP config option was used to built the GPIO OMAP
 driver but this is not consistent with the rest of the GPIO
 drivers that have their own Kconfig option.
 
 Also, this make it harder to add dependencies or reverse
 dependencies (i.e: select) since that would mean touching the
 sub-arch config option.
 
 So is better to add a boolean Kconfig option for this driver
 that defaults to true if ARCH_OMAP is enabled.
 
 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 ---
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com


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

Re: [PATCH 4/5] gpio: omap: convert driver to use gpiolib irqchip

[Santosh Shilimkar]

On Sunday 06 April 2014 10:58 AM, Javier Martinez Canillas wrote:
 Converts the GPIO OMAP driver to register its chained irq
 handler and irqchip using the helpers in the gpiolib core.
 
 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 ---
  drivers/gpio/Kconfig |   1 +
  drivers/gpio/gpio-omap.c | 107 
 ++-
  2 files changed, 52 insertions(+), 56 deletions(-)
 
 diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
 index bfe5cf0..2092b1d 100644
 --- a/drivers/gpio/Kconfig
 +++ b/drivers/gpio/Kconfig
 @@ -247,6 +247,7 @@ config GPIO_OMAP
   bool TI OMAP GPIO support
   default y if ARCH_OMAP
   depends on ARM  ARCH_OMAP
 + select GPIOLIB_IRQCHIP
   help
 Say yes here to enable GPIO support for TI OMAP SoCs.
  
 diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
 index e717888..8cc9e91 100644
 --- a/drivers/gpio/gpio-omap.c
 +++ b/drivers/gpio/gpio-omap.c
 @@ -24,7 +24,6 @@
  #include linux/pm.h
  #include linux/of.h
  #include linux/of_device.h
 -#include linux/irqdomain.h
  #include linux/irqchip/chained_irq.h
  #include linux/gpio.h
  #include linux/platform_data/gpio-omap.h
 @@ -52,7 +51,6 @@ struct gpio_bank {
   struct list_head node;
   void __iomem *base;
   u16 irq;
 - struct irq_domain *domain;
   u32 non_wakeup_gpios;
   u32 enabled_non_wakeup_gpios;
   struct gpio_regs context;
 @@ -95,11 +93,10 @@ static int irq_to_gpio(struct gpio_bank *bank, unsigned 
 int gpio_irq)
   return bank-chip.base + gpio_irq;
  }
  
 -static int omap_gpio_to_irq(struct gpio_chip *chip, unsigned offset)
 +static inline struct gpio_bank *_irq_data_get_bank(struct irq_data *d)
  {
 - struct gpio_bank *bank = container_of(chip, struct gpio_bank, chip);
 -
 - return irq_find_mapping(bank-domain, offset);
 + struct gpio_chip *chip = irq_data_get_irq_chip_data(d);
 + return container_of(chip, struct gpio_bank, chip);
  }
  
  static void _set_gpio_direction(struct gpio_bank *bank, int gpio, int 
 is_input)
 @@ -479,7 +476,7 @@ static int gpio_is_input(struct gpio_bank *bank, int mask)
  
  static int gpio_irq_type(struct irq_data *d, unsigned type)
  {
 - struct gpio_bank *bank = irq_data_get_irq_chip_data(d);
 + struct gpio_bank *bank = _irq_data_get_bank(d);
   unsigned gpio = 0;
   int retval;
   unsigned long flags;
 @@ -514,14 +511,6 @@ static int gpio_irq_type(struct irq_data *d, unsigned 
 type)
   return -EINVAL;
   }
  
 - retval = gpio_lock_as_irq(bank-chip, offset);
 - if (retval) {
 - dev_err(bank-dev, unable to lock offset %d for IRQ\n,
 - offset);
 - spin_unlock_irqrestore(bank-lock, flags);
 - return retval;
 - }
 -
   bank-irq_usage |= 1  GPIO_INDEX(bank, gpio);
   spin_unlock_irqrestore(bank-lock, flags);
  
 @@ -664,7 +653,7 @@ static void _reset_gpio(struct gpio_bank *bank, int gpio)
  /* Use disable_irq_wake() and enable_irq_wake() functions from drivers */
  static int gpio_wake_enable(struct irq_data *d, unsigned int enable)
  {
 - struct gpio_bank *bank = irq_data_get_irq_chip_data(d);
 + struct gpio_bank *bank = _irq_data_get_bank(d);
   unsigned int gpio = irq_to_gpio(bank, d-hwirq);
  
   return _set_gpio_wakeup(bank, gpio, enable);
 @@ -732,11 +721,12 @@ static void gpio_irq_handler(unsigned int irq, struct 
 irq_desc *desc)
   unsigned int bit;
   struct gpio_bank *bank;
   int unmasked = 0;
 - struct irq_chip *chip = irq_desc_get_chip(desc);
 + struct irq_chip *irqchip = irq_desc_get_chip(desc);
 + struct gpio_chip *chip = irq_get_handler_data(irq);
  
 - chained_irq_enter(chip, desc);
 + chained_irq_enter(irqchip, desc);
  
 - bank = irq_get_handler_data(irq);
 + bank = container_of(chip, struct gpio_bank, chip);
   isr_reg = bank-base + bank-regs-irqstatus;
   pm_runtime_get_sync(bank-dev);
  
 @@ -764,7 +754,7 @@ static void gpio_irq_handler(unsigned int irq, struct 
 irq_desc *desc)
   configured, we could unmask GPIO bank interrupt immediately */
   if (!level_mask  !unmasked) {
   unmasked = 1;
 - chained_irq_exit(chip, desc);
 + chained_irq_exit(irqchip, desc);
   }
  
   if (!isr)
 @@ -784,7 +774,8 @@ static void gpio_irq_handler(unsigned int irq, struct 
 irq_desc *desc)
   if (bank-toggle_mask  (1  bit))
   _toggle_gpio_edge_triggering(bank, bit);
  
 - generic_handle_irq(irq_find_mapping(bank-domain, bit));
 + 
 generic_handle_irq(irq_find_mapping(bank-chip.irqdomain,
 + bit));
   }
   }
   /* if bank has any level sensitive GPIO pin interrupt
 @@ -793,13 +784,13 @@ static void 

Re: [PATCH v2 3/3] ARM: OMAP2+: AM43x: L2 cache support

[Santosh Shilimkar]

On Wednesday 09 April 2014 12:33 PM, Russell King - ARM Linux wrote:
 On Tue, Apr 08, 2014 at 11:17:17AM -0400, Santosh Shilimkar wrote:
 On Tuesday 08 April 2014 10:53 AM, Sekhar Nori wrote:
 On Friday 04 April 2014 03:48 PM, Russell King - ARM Linux wrote:
 On Fri, Apr 04, 2014 at 03:40:29PM +0530, Sekhar Nori wrote:
 diff --git a/arch/arm/mach-omap2/omap4-common.c 
 b/arch/arm/mach-omap2/omap4-common.c
 index f8b8dac..6b2a056 100644
 --- a/arch/arm/mach-omap2/omap4-common.c
 +++ b/arch/arm/mach-omap2/omap4-common.c
 @@ -224,6 +224,14 @@ int __init omap4_l2_cache_init(void)
  
   return omap_l2_cache_init(aux_ctrl, 0xc19f);
  }
 +
 +int __init am43xx_l2_cache_init(void)
 +{
 + u32 aux_ctrl = L310_AUX_CTRL_DATA_PREFETCH |
 +L310_AUX_CTRL_INSTR_PREFETCH;

 It would be good to documenting the difference between this and OMAP4,
 and why you have chosen different values.

 There are two main differences:

 1) OMAP4 sets Shared attribute override enable bit. TBH, I think this is
 not needed even in OMAP4 with latest kernel, but I am not sure if I can
 do this safely without breaking any usecase currently working with OMAP4.

 Wrong. Shared bit is mandatory for the OMAP4. Its a SMP system
 which needs that.
 
 Errr.  This bit affects the L2 cache behaviour for Normal memory, outer
 non-cacheable accesses - in other words, those performed to memory mapped
 via dma_alloc_coherent() or dma_alloc_writecombine().  It does not affect
 other types of mappings (other access types ignore the sharable attribute).
 
 When this bit is clear, accesses to such memory are:
 
 - read: cacheable, no allocate
 - write: write through, no write allocate
 
 what this means is that if there are no cache lines in the L2 cache
 corresponding with the physical address, then none will be allocated.
 However, if there are cache lines present, then they will be hit,
 read or updated as appropriate.
 
 This may matter before CMA where we had the memory returned by
 dma_alloc_coherent() and friends mapped as normal, cacheable mappings
 which could be speculatively prefetched, and therefore cache lines
 dragged into the L2 cache for these physical addresses.
 
 However, now that we're using CMA, this does not apply as we no longer
 have this aliasing mapping.
 
 So, with CMA enabled, it should be safe not to set this bit.
 
Agree. That should be safe now.

 However, the shared bit in the page tables must be set for SMP systems.
 Are you sure you're not confusing the shared bit in the page tables
 with the shared override bit in the L2 cache controller?

No i didn't confuse with page table bits. But the SMP remark wasn't
relevant which might have indicated that.
 
 2) OMAP4 sets NS lockdown and NS interrupt access control bits. I
 searched through the commit history of L2 cache support on OMAP4 but
 there is no mention of why this was needed on OMAP4. I am checking
 internally on the history behind this.

 These have also come from the aligned settings with hardware folks.
 
 Again, this doesn't have much to do with hardware, it's secure/non-secure
 access rights configuration to the L2 cache controller.
 
The settings were aligned by hardware team after consulting security
team and those couple of bit settings came from them. The folks
are no longer working for TI so I can't go back and check the reasons.
We just just leave them as is.

Regards,
Santosh

--
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/3] ARM: OMAP2+: AM43x: L2 cache support

[Santosh Shilimkar]

On Tuesday 08 April 2014 10:53 AM, Sekhar Nori wrote:
 On Friday 04 April 2014 03:48 PM, Russell King - ARM Linux wrote:
 On Fri, Apr 04, 2014 at 03:40:29PM +0530, Sekhar Nori wrote:
 diff --git a/arch/arm/mach-omap2/omap4-common.c 
 b/arch/arm/mach-omap2/omap4-common.c
 index f8b8dac..6b2a056 100644
 --- a/arch/arm/mach-omap2/omap4-common.c
 +++ b/arch/arm/mach-omap2/omap4-common.c
 @@ -224,6 +224,14 @@ int __init omap4_l2_cache_init(void)
  
 return omap_l2_cache_init(aux_ctrl, 0xc19f);
  }
 +
 +int __init am43xx_l2_cache_init(void)
 +{
 +   u32 aux_ctrl = L310_AUX_CTRL_DATA_PREFETCH |
 +  L310_AUX_CTRL_INSTR_PREFETCH;

 It would be good to documenting the difference between this and OMAP4,
 and why you have chosen different values.
 
 There are two main differences:
 
 1) OMAP4 sets Shared attribute override enable bit. TBH, I think this is
 not needed even in OMAP4 with latest kernel, but I am not sure if I can
 do this safely without breaking any usecase currently working with OMAP4.
 
Wrong. Shared bit is mandatory for the OMAP4. Its a SMP system
which needs that.

 2) OMAP4 sets NS lockdown and NS interrupt access control bits. I
 searched through the commit history of L2 cache support on OMAP4 but
 there is no mention of why this was needed on OMAP4. I am checking
 internally on the history behind this.

These have also come from the aligned settings with hardware folks.
 
 3) OMAP4 sets cache replacement policy to RR which is not a big deal
 since thats the default anyway. We can probably drop this setting even
 from OMAP4.
 
Don't change anything on OMAP4 since these settings have come up from
multiple alignments.

In my view, Aegis can use exact same setting as OMAP4. Things like
shared bit etc would not make much difference because of UP config,
keeping that doesn't hurt either.

Why don't you just re-use that as is ? Sorry if I have missed any
other discussion on the thread.

Regards,
Santosh

--
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/5] iommu/omap: Use the cache cleaning API

[Santosh Shilimkar]

On Friday 14 March 2014 09:49 PM, Suman Anna wrote:
 Hi Santosh, Laurent, Russell, Arnd,
 
 On 03/14/2014 12:51 PM, Santosh Shilimkar wrote:
 On Friday 14 March 2014 12:38 PM, Laurent Pinchart wrote:
 Hi Santosh,

 On Friday 14 March 2014 12:15:11 Santosh Shilimkar wrote:
 + Russell, Arnd

 On Thursday 13 March 2014 10:47 PM, Anna, Suman wrote:
 On 03/07/2014 06:46 PM, Laurent Pinchart wrote:
 The page table entries must be cleaned from the cache before being
 accessed by the IOMMU. Instead of implementing cache management manually
 (and ignoring L2 cache), use clean_dcache_area() to make sure the
 entries are visible to the device.

 Thanks for fixing this, this has been long pending. There have been some
 previous attempts at this as well by Ramesh Gupta, with the last thread
 (a long time now) being
 http://marc.info/?t=13475203541r=1w=2

 Santosh,
 Can you please take a look at this patch and provide your comments?

 regards
 Suman

 Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
 ---

drivers/iommu/omap-iommu.c | 41 
 ++-
1 file changed, 10 insertions(+), 31 deletions(-)

 diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
 index a893eca..bb605c9 100644
 --- a/drivers/iommu/omap-iommu.c
 +++ b/drivers/iommu/omap-iommu.c
 @@ -500,24 +500,9 @@ EXPORT_SYMBOL_GPL(omap_foreach_iommu_device);
/*
 *H/W pagetable operations
 */
 -static void flush_iopgd_range(u32 *first, u32 *last)
 +static void flush_pgtable(void *addr, size_t size)
{
 -/* FIXME: L2 cache should be taken care of if it exists */
 -do {
 -asm(mcrp15, 0, %0, c7, c10, 1 @ flush_pgd
 -: : r (first));
 -first += L1_CACHE_BYTES / sizeof(*first);
 -} while (first = last);
 -}
 -
 -static void flush_iopte_range(u32 *first, u32 *last)
 -{
 -/* FIXME: L2 cache should be taken care of if it exists */
 -do {
 -asm(mcrp15, 0, %0, c7, c10, 1 @ flush_pte
 -: : r (first));
 -first += L1_CACHE_BYTES / sizeof(*first);
 -} while (first = last);
 +clean_dcache_area(addr, size);

 I remember NAKing this approach in past and my stand remains same.
 The cache APIs which you are trying to use here are not suppose
 to be used outside.
 
 So this particular change has a long history (have to dig through to educate 
 myself). I have not seen clean_dcache_area attempted before, and I wasn't 
 sure myself it it can be used here. Ramesh and Fernando definitely did start 
 out with dmac_flush_range and outer_flush_range which was definitely nacked 
 [1].
 
OK. Please wrap the lines appropriately while replying.


 Please note that the omap-iommu driver already uses clean_dcache_area().
 That's where I got the idea :-)

 So that fall through the cracks then ;-)

 I think the right way to fix this is to make use of streaming APIs.
 If needed, IOMMU can have its own dma_ops for special case
 handling if any.

 I can replace clean_dcache_area() with dma_map_page() as done by the 
 arm-smmu
 driver. If that's fine I'll modify this patch accordingly in v2.

 
 Ramesh had also attempted to use dma_page_single() previously [2], and 
 Russell has instead suggested to extend the cpu cache operations [3].
 Ramesh had worked based on this suggestion and the series reached v6 [4] 
 (same as link I mentioned above) and this is the last attempt on this, but 
 the thread went silent.
 
 I am wondering if that is still valid and is the right way to go, as this 
 seems to be a common problem. I do see dmac_flush_range being used for 
 similar purposes in msm_iommu.c and exynos-iommu.c, so looks like they also 
 fell through the cracks.
 
Thanks for the links. I think you should revive the v6 series unless and until
RMK has some other suggestion. This can also help to remove the wrong usages
from other IOMMU drivers as you pointed out.

 Laurent,
 Can you drop this patch out from v2 so that it is not clubbed with the small 
 cleanup patches, and we can track this separately?
 
Agree

Regards,
Santosh

 
 [1] http://marc.info/?l=linux-omapm=129907009019355w=2
 [2] http://marc.info/?t=13028180495r=1w=2
 [3] http://marc.info/?l=linux-omapm=131310179423214w=2
 [4] http://marc.info/?t=13475203541r=1w=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 1/5] iommu/omap: Use the cache cleaning API

[Santosh Shilimkar]

+ Russell, Arnd

On Thursday 13 March 2014 10:47 PM, Anna, Suman wrote:
 Hi Laurent,
 
 On 03/07/2014 06:46 PM, Laurent Pinchart wrote:
 The page table entries must be cleaned from the cache before being
 accessed by the IOMMU. Instead of implementing cache management manually
 (and ignoring L2 cache), use clean_dcache_area() to make sure the
 entries are visible to the device.
 
 Thanks for fixing this, this has been long pending. There have been some 
 previous attempts at this as well by Ramesh Gupta, with the last thread 
 (a long time now) being
 http://marc.info/?t=13475203541r=1w=2
 
 Santosh,
 Can you please take a look at this patch and provide your comments?
 
 regards
 Suman
 

 Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
 ---
   drivers/iommu/omap-iommu.c | 41 ++---
   1 file changed, 10 insertions(+), 31 deletions(-)

 diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
 index a893eca..bb605c9 100644
 --- a/drivers/iommu/omap-iommu.c
 +++ b/drivers/iommu/omap-iommu.c
 @@ -500,24 +500,9 @@ EXPORT_SYMBOL_GPL(omap_foreach_iommu_device);
   /*
* H/W pagetable operations
*/
 -static void flush_iopgd_range(u32 *first, u32 *last)
 +static void flush_pgtable(void *addr, size_t size)
   {
 -/* FIXME: L2 cache should be taken care of if it exists */
 -do {
 -asm(mcrp15, 0, %0, c7, c10, 1 @ flush_pgd
 -: : r (first));
 -first += L1_CACHE_BYTES / sizeof(*first);
 -} while (first = last);
 -}
 -
 -static void flush_iopte_range(u32 *first, u32 *last)
 -{
 -/* FIXME: L2 cache should be taken care of if it exists */
 -do {
 -asm(mcrp15, 0, %0, c7, c10, 1 @ flush_pte
 -: : r (first));
 -first += L1_CACHE_BYTES / sizeof(*first);
 -} while (first = last);
 +clean_dcache_area(addr, size);
I remember NAKing this approach in past and my stand remains same.
The cache APIs which you are trying to use here are not suppose
to be used outside.

I think the right way to fix this is to make use of streaming APIs.
If needed, IOMMU can have its own dma_ops for special case
handling if any.

Russell, Arnd might have more ideas.

   }

   static void iopte_free(u32 *iopte)
 @@ -546,7 +531,7 @@ static u32 *iopte_alloc(struct omap_iommu *obj, u32 
 *iopgd, u32 da)
  return ERR_PTR(-ENOMEM);

  *iopgd = virt_to_phys(iopte) | IOPGD_TABLE;
 -flush_iopgd_range(iopgd, iopgd);
 +flush_pgtable(iopgd, sizeof(*iopgd));

  dev_vdbg(obj-dev, %s: a new pte:%p\n, __func__, iopte);
  } else {
 @@ -575,7 +560,7 @@ static int iopgd_alloc_section(struct omap_iommu *obj, 
 u32 da, u32 pa, u32 prot)
  }

  *iopgd = (pa  IOSECTION_MASK) | prot | IOPGD_SECTION;
 -flush_iopgd_range(iopgd, iopgd);
 +flush_pgtable(iopgd, sizeof(*iopgd));
  return 0;
   }

 @@ -592,7 +577,7 @@ static int iopgd_alloc_super(struct omap_iommu *obj, u32 
 da, u32 pa, u32 prot)

  for (i = 0; i  16; i++)
  *(iopgd + i) = (pa  IOSUPER_MASK) | prot | IOPGD_SUPER;
 -flush_iopgd_range(iopgd, iopgd + 15);
 +flush_pgtable(iopgd, sizeof(*iopgd) * 16);
  return 0;
   }

 @@ -605,7 +590,7 @@ static int iopte_alloc_page(struct omap_iommu *obj, u32 
 da, u32 pa, u32 prot)
  return PTR_ERR(iopte);

  *iopte = (pa  IOPAGE_MASK) | prot | IOPTE_SMALL;
 -flush_iopte_range(iopte, iopte);
 +flush_pgtable(iopte, sizeof(*iopte));

  dev_vdbg(obj-dev, %s: da:%08x pa:%08x pte:%p *pte:%08x\n,
   __func__, da, pa, iopte, *iopte);
 @@ -619,18 +604,12 @@ static int iopte_alloc_large(struct omap_iommu *obj, 
 u32 da, u32 pa, u32 prot)
  u32 *iopte = iopte_alloc(obj, iopgd, da);
  int i;

 -if ((da | pa)  ~IOLARGE_MASK) {
 -dev_err(obj-dev, %s: %08x:%08x should aligned on %08lx\n,
 -__func__, da, pa, IOLARGE_SIZE);
 -return -EINVAL;
 -}
 -
  if (IS_ERR(iopte))
  return PTR_ERR(iopte);

  for (i = 0; i  16; i++)
  *(iopte + i) = (pa  IOLARGE_MASK) | prot | IOPTE_LARGE;
 -flush_iopte_range(iopte, iopte + 15);
 +flush_pgtable(iopte, sizeof(*iopte) * 16);
  return 0;
   }

 @@ -733,7 +712,7 @@ static size_t iopgtable_clear_entry_core(struct 
 omap_iommu *obj, u32 da)
  }
  bytes *= nent;
  memset(iopte, 0, nent * sizeof(*iopte));
 -flush_iopte_range(iopte, iopte + (nent - 1) * sizeof(*iopte));
 +flush_pgtable(iopte, sizeof(*iopte) * nent);

  /*
   * do table walk to check if this table is necessary or not
 @@ -755,7 +734,7 @@ static size_t iopgtable_clear_entry_core(struct 
 omap_iommu *obj, u32 da)
  bytes *= nent;
  }
  memset(iopgd, 0, nent * sizeof(*iopgd));
 -flush_iopgd_range(iopgd, iopgd + (nent - 1) * sizeof(*iopgd));
 +

Re: [PATCH 1/5] iommu/omap: Use the cache cleaning API

[Santosh Shilimkar]

On Friday 14 March 2014 12:38 PM, Laurent Pinchart wrote:
 Hi Santosh,
 
 On Friday 14 March 2014 12:15:11 Santosh Shilimkar wrote:
 + Russell, Arnd

 On Thursday 13 March 2014 10:47 PM, Anna, Suman wrote:
 On 03/07/2014 06:46 PM, Laurent Pinchart wrote:
 The page table entries must be cleaned from the cache before being
 accessed by the IOMMU. Instead of implementing cache management manually
 (and ignoring L2 cache), use clean_dcache_area() to make sure the
 entries are visible to the device.

 Thanks for fixing this, this has been long pending. There have been some
 previous attempts at this as well by Ramesh Gupta, with the last thread
 (a long time now) being
 http://marc.info/?t=13475203541r=1w=2

 Santosh,
 Can you please take a look at this patch and provide your comments?

 regards
 Suman

 Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
 ---

   drivers/iommu/omap-iommu.c | 41 ++-
   1 file changed, 10 insertions(+), 31 deletions(-)

 diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
 index a893eca..bb605c9 100644
 --- a/drivers/iommu/omap-iommu.c
 +++ b/drivers/iommu/omap-iommu.c
 @@ -500,24 +500,9 @@ EXPORT_SYMBOL_GPL(omap_foreach_iommu_device);
   /*
*   H/W pagetable operations
*/
 -static void flush_iopgd_range(u32 *first, u32 *last)
 +static void flush_pgtable(void *addr, size_t size)
   {
 -  /* FIXME: L2 cache should be taken care of if it exists */
 -  do {
 -  asm(mcrp15, 0, %0, c7, c10, 1 @ flush_pgd
 -  : : r (first));
 -  first += L1_CACHE_BYTES / sizeof(*first);
 -  } while (first = last);
 -}
 -
 -static void flush_iopte_range(u32 *first, u32 *last)
 -{
 -  /* FIXME: L2 cache should be taken care of if it exists */
 -  do {
 -  asm(mcrp15, 0, %0, c7, c10, 1 @ flush_pte
 -  : : r (first));
 -  first += L1_CACHE_BYTES / sizeof(*first);
 -  } while (first = last);
 +  clean_dcache_area(addr, size);

 I remember NAKing this approach in past and my stand remains same.
 The cache APIs which you are trying to use here are not suppose
 to be used outside.
 
 Please note that the omap-iommu driver already uses clean_dcache_area(). 
 That's where I got the idea :-)
 
So that fall through the cracks then ;-)

 I think the right way to fix this is to make use of streaming APIs.
 If needed, IOMMU can have its own dma_ops for special case
 handling if any.
 
 I can replace clean_dcache_area() with dma_map_page() as done by the arm-smmu 
 driver. If that's fine I'll modify this patch accordingly in v2.
 
That will be definitely a better option than the APIs used. Those streaming
APIs will take care of L2 cache as well if present.

Regards,
Santosh

--
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/5] iommu/omap: Use the cache cleaning API

[Santosh Shilimkar]

On Friday 14 March 2014 12:57 PM, Arnd Bergmann wrote:
 On Friday 14 March 2014, Santosh Shilimkar wrote:
 I remember NAKing this approach in past and my stand remains same.
 The cache APIs which you are trying to use here are not suppose
 to be used outside.

 I think the right way to fix this is to make use of streaming APIs.
 If needed, IOMMU can have its own dma_ops for special case
 handling if any.

 Russell, Arnd might have more ideas.
 
 I have a bad feeling about using the dma-mapping API within the
 IOMMU code, because that driver is also used to implement the
 dma-mapping API for devices attached to the IOMMU. It's possible
 that it just works.
 
Thats a good point.

 Is the IOMMU actually designed to have page tables in noncoherent
 memory? I would have expected that the iopt accesses must all be
 done on dma_alloc_coherent() provided memory to guarantee proper
 accesses.
 
At least the OMAP one seems to use non-coherent memory which will
need CMO.

Regards,
Santosh

--
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 5/5] drivers: bus: omap_l3: Change pr_crit() to dev_err() when IRQ request fails

[Santosh Shilimkar]

On Thursday 13 March 2014 01:28 AM, Tony Lindgren wrote:
 * Peter Ujfalusi peter.ujfal...@ti.com [140304 23:14]:
 On 03/04/2014 04:37 PM, Santosh Shilimkar wrote:
 On Tuesday 04 March 2014 08:48 PM, Peter Ujfalusi wrote:
 Use dev_err() which will going to print the driver's name as well and the
 KERN_ERR level is sufficient in this case (we also print via dev_err when
 there is an error with the mem resources)

 Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
 Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
 ---
  drivers/bus/omap_l3_noc.c | 7 +++
  1 file changed, 3 insertions(+), 4 deletions(-)

 diff --git a/drivers/bus/omap_l3_noc.c b/drivers/bus/omap_l3_noc.c
 index 0eff48585ae3..972691a668a3 100644
 --- a/drivers/bus/omap_l3_noc.c
 +++ b/drivers/bus/omap_l3_noc.c
 @@ -158,8 +158,8 @@ static int omap4_l3_probe(struct platform_device *pdev)
ret = devm_request_irq(pdev-dev, l3-debug_irq, l3_interrupt_handler,
   IRQF_DISABLED, l3-dbg-irq, l3);
if (ret) {
 -  pr_crit(L3: request_irq failed to register for 0x%x\n,
 -  l3-debug_irq);
 +  dev_err(pdev-dev, request_irq failed for %d\n,
 +  l3-debug_irq);
return ret;
}
  
 @@ -167,8 +167,7 @@ static int omap4_l3_probe(struct platform_device *pdev)
ret = devm_request_irq(pdev-dev, l3-app_irq, l3_interrupt_handler,
   IRQF_DISABLED, l3-app-irq, l3);
if (ret)
 -  pr_crit(L3: request_irq failed to register for 0x%x\n,
 -  l3-app_irq);
 +  dev_err(pdev-dev, request_irq failed for %d\n, l3-app_irq);
  
return ret;
  }

 So this one change in the log level. If I look at now, may be dev_err
 is fine but the change is not same.

 Not sure what you mean by 'the change is not same'?
 I just picked the old series and rebased it on linux-next, the patch is the
 same as it was back in May 2013:
 https://lkml.org/lkml/2013/5/2/205

 And yes, I have shortened the texts in the print, but the meaning of the
 prints have not changed.
 
 Santosh, got any more comments on this series?
 
Nope. looks good

--
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: Fix definition of IS_PM44XX_ERRATUM

[Santosh Shilimkar]

On Thursday 13 March 2014 05:43 AM, Nishanth Menon wrote:
 Just like IS_PM34XX_ERRATUM, IS_PM44XX_ERRATUM is valid only if
 CONFIG_PM is enabled, else, disabling CONFIG_PM results in build
 failure complaining about the following:
 arch/arm/mach-omap2/built-in.o: In function `omap4_boot_secondary':
 :(.text+0x8a70): undefined reference to `pm44xx_errata'
 
Not entirely accurate since CPU hotplug doesn't depend on CONFIG_PM

 Fixes: c962184 (ARM: OMAP4: PM: add errata support)
 Reported-by: Tony Lindgren t...@atomide.com
 Signed-off-by: Nishanth Menon n...@ti.com
 ---
 
 Patch based on: v3.14-rc6
 Reported originally with a randconfig defconfig: 
 http://slexy.org/view/s21U7eF4k1
 
But without the PM sleep code, hotplug won't work either.
SO I think its ok assumption in this particular case

  arch/arm/mach-omap2/pm.h |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
 index 7bdd22a..d4d0fce 100644
 --- a/arch/arm/mach-omap2/pm.h
 +++ b/arch/arm/mach-omap2/pm.h
 @@ -103,7 +103,7 @@ static inline void 
 enable_omap3630_toggle_l2_on_restore(void) { }
  
  #define PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD   (1  0)
  
 -#if defined(CONFIG_ARCH_OMAP4)
 +#if defined(CONFIG_PM)  defined(CONFIG_ARCH_OMAP4)
  extern u16 pm44xx_errata;
  #define IS_PM44XX_ERRATUM(id)(pm44xx_errata  (id))
  #else
 

--
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: Fix definition of IS_PM44XX_ERRATUM

[Santosh Shilimkar]

On Thursday 13 March 2014 06:07 AM, Nishanth Menon wrote:
 On 03/12/2014 04:59 PM, Santosh Shilimkar wrote:
 On Thursday 13 March 2014 05:43 AM, Nishanth Menon wrote:
 Just like IS_PM34XX_ERRATUM, IS_PM44XX_ERRATUM is valid only if
 CONFIG_PM is enabled, else, disabling CONFIG_PM results in build
 failure complaining about the following:
 arch/arm/mach-omap2/built-in.o: In function `omap4_boot_secondary':
 :(.text+0x8a70): undefined reference to `pm44xx_errata'

 Not entirely accurate since CPU hotplug doesn't depend on CONFIG_PM
 
 Just reporting the build error here.

 Fixes: c962184 (ARM: OMAP4: PM: add errata support)
 Reported-by: Tony Lindgren t...@atomide.com
 Signed-off-by: Nishanth Menon n...@ti.com
 ---

 Patch based on: v3.14-rc6
 Reported originally with a randconfig defconfig: 
 http://slexy.org/view/s21U7eF4k1

 But without the PM sleep code, hotplug won't work either.
 yep - agreed,
 SO I think its ok assumption in this particular case
 
 Can I take that as an Ack here? or would you suggest any improvements?
 
yep. Acked-by: Santosh Shilimkar santosh.shilim...@ti.ocm


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

Re: [PATCH RFC 08/26] dmaengine: omap-dma: consolidate setup of CCR

[Santosh Shilimkar]

On Wednesday 22 January 2014 09:19 AM, Russell King - ARM Linux wrote:
 On Wed, Jan 22, 2014 at 06:25:57PM +0530, Sricharan R wrote:
 Setting up of DMA_DST_SYNC_PREFETCH is missing after this ?
 
 I'm not looking for the DMA engine driver to be a 100% reimplementation
 of the legacy driver.  Rather than supporting the entire set of features
 which the legacy driver did, and have many of them simply not used, the
 approach I'm taking here is to only support what is necessary for the
 drivers we have in mainline - and what fits the DMA engine interfaces.
 
+1 on the approach.

 There is no point inventing new DMA engine interfaces for features for
 which we have no users in mainline kernel - to try to do that will be
 quite rightfully thrown out by the DMA engine maintainers.
 
 Here's the total number of references/definitions of DMA_DST_SYNC_PREFETCH
 in the mainline kernel:
 
 arch/arm/plat-omap/dma.c:   if (src_or_dst_synch == 
 OMAP_DMA_DST_SYNC_PREFETCH) {
 include/linux/omap-dma.h:#define OMAP_DMA_DST_SYNC_PREFETCH 0x02
 
 Hence, this feature is unused at present.
 
I thought the crypto was using the prefetch feature but it isn't. 

Regards,
Santosh
--
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: sleep: byteswap data for big-endian

[Santosh Shilimkar]

On Tuesday 14 January 2014 03:56 PM, Nishanth Menon wrote:
 On Tue, Jan 14, 2014 at 2:20 PM, Victor Kamensky
 victor.kamen...@linaro.org wrote:
 On 14 January 2014 09:56, Nishanth Menon n...@ti.com wrote:
 On Tue, Jan 14, 2014 at 11:35 AM, Victor Kamensky
 victor.kamen...@linaro.org wrote:

 When BE kernel is built Makefile does take of compiling code in BE
 mode. I.e all proper flags like -mbig-endian and -Wl,--be8 will be set.

 Agreed, and I assume you cannot instead switch to LE mode when
 entering assembly assuming LE?

 Yes. Note that this asm interacts with other data in kernel that would
 be in BE form. And after all linker will not allow to put together files
 that were compiled in different endianity.

 The reason I ask this is - most of our development is NOT in BE mode.
 we will continue to manipulate and add assembly - AM335x, DRA7/OMAP5
 etc.. and obviously not every code change will indulge in ensuring
 right markers will be in place.

 by ensuring readl_relaxed handles the variations, you have ensured
 that I dont need to care about drivers other than to ensure they use
 _relaxed variants. in the case of assembly, this does not seem long
 term manageable.

 Yes, I agree if it is outside of main use case it will get broken if not
 attended to. Definitely universe entropy increases :) - if left without
 attention things will decay. Note we admit that even with ARM CPU
 core BE changes similar decay can happen eventually ...that is
 what LNG BE group trying to prevent. I think
 the deal here is that next user of it can/need to fix things if they
 decayed.

 
 Personally, I have no idea what LNG BE stands for.. I see the
 approach we are attempting here is to do any interaction external to
 ARM boundary to go through the ARM_BE8 macro.
 
 If we want to make this something we can live with, then the platforms
 will have to ensure memory operations external to ARM must be operated
 upon by these macros. Instead, an approach that may be used is to
 introduce accessors macros that will provide right instruction based
 on BE/LE build and BE/LE SoC peripheral behavior.
 

 is the idea of BE build meant to deal with having a single BE kernel
 build work for all platforms (including LE ones)?

 Sort of. The idea here to run BE image on OMAP4 chip, with
 kernel that would deals with LE periphery correctly, but ARM
 core run in BE with special kernel that compiled for BE case (i.e
 CONFIG_CPU_BIG_ENDIAN is set).

 I still dont get the usecase - other than hey, we do this coz we can
 do it!.. I mean, yep, it sounds great and all.. but 4 years down the
 line, is this still going to work? is this going to be interesting
 careabout? or we are just maintaining additional code for a passing
 fancy or proof-of-concept?

 Valid concern. From LNG BE group point of view it is not we can do
 it. It is more like we've done it. We have Pandaboard ES running BE
 kernel for a while. It is in LNG BE tree. We used it as development
 and testing vehicle for BE work for a while. We are very grateful to
 the platform for that - it is affordable and easily available! Given,
 beyond ongoing BE testing on Pandaboard in LNG there may not be valid
 use case for further things on OMAP4 BE. We had discussion
 with Santosh Shilimkar from TI during last Linaro connect what to
 do with LNG BE Pandaboard series. Santosh suggested and we
 agreed that we would try to contribute them back to community. And
 that is what Taras is doing. IMHO even though there may not be real
 
 ok.. some sort of Linaro thing about which I have no background about
 - but dont really care in this context.
 
Nothing related Linaro. Its just that platforms are supporting ARM BE
mode and Linaro folks had working patches for Panda. So I suggested
to get them on the lists.

Regards,
Santosh
--
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: OMAP4460: cpuidle: Extend PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD on cpuidle

[Santosh Shilimkar]

On Tuesday 14 January 2014 04:26 PM, Kevin Hilman wrote:
 On Fri, Nov 15, 2013 at 8:12 AM, Santosh Shilimkar
 santosh.shilim...@ti.com wrote:
 On Friday 15 November 2013 11:11 AM, Tony Lindgren wrote:
 * Taras Kondratiuk taras.kondrat...@linaro.org [131115 08:03]:
 On 11/15/2013 05:36 PM, Tony Lindgren wrote:
 * Tony Lindgren t...@atomide.com [131114 10:36]:
 * Grygorii Strashko grygorii.stras...@ti.com [131022 12:09]:
 The same workaround as ff999b8a0983ee15668394ed49e38d3568fc6859
 ARM: OMAP4460: Workaround for ROM bug because of CA9 r2pX GIC ...
 need to be applied not only when system is booting, but when MPUSS hits
 OSWR state through CPUIdle too. Without this WA the same issue is
 reproduced now on boards PandaES and Tablet/Blaze with SOM OMAP4460
 when CONFIG_CPU_IDLE is enabled.
 After MPUSS has enterred OSWR and waken up:
 - GIC distributor became disabled forever
 - scheduling is not performed any more

 Cc: Kevin Hilman khil...@linaro.org
 Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
 Reported-by: Taras Kondratiuk taras.kondrat...@linaro.org
 Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com

 Applying into omap-for-v3.13/fixes thanks.

 Hmm looks like this breaks the build with randconfigs at least
 with the attached .config, so dropping for now.

 Hi Tony
 Have you forgot to attach .config?

 Oops, sorry looks like I removed it already as I rebuilt the tree
 and started a new set of randconfig build tests.

 arch/arm/mach-omap2/built-in.o: In function `omap_enter_idle_coupled':
 :(.text+0xb48c): undefined reference to `pm44xx_errata'

 I assume that .config doesn't have CONFIG_SMP enabled while
 pm44xx_errata is defined in omap-smp.c.
 I think it should be a separate patch to move pm44xx_errata somewhere
 else, so this patch will remain the same.

 Yes something like that probably. Sounds like that should be then
 patches before this fix.

 Btw, do we need omap_enter_idle_coupled() in UP?

 That should be checked, am43xx may need it.

 Nope. omap_enter_idle_coupled() is needed only for SMP
 systems. UP don't need couple idle functionality as
 such.
 
 So what's the status of this fix and dependencies?
 
 Both linux-next[1] and arm-soc/for-next[2] are failing boot tests on
 omap4460/panda-es because multi_v7_defconfig now has CPUidle enabled
 by default.
 
I think Taras needs to refresh the patch based on discussion
and then it can be merged.

 
 [1] 
 http://lists.linaro.org/pipermail/kernel-build-reports/2014-January/001891.html
 [2] 
 http://lists.linaro.org/pipermail/kernel-build-reports/2014-January/001898.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] ARM: OMAP4: sleep: byteswap data for big-endian

[Santosh Shilimkar]

On Tuesday 14 January 2014 04:13 PM, Nishanth Menon wrote:
 On Tue, Jan 14, 2014 at 3:03 PM, Santosh Shilimkar
 santosh.shilim...@ti.com wrote:

 ok.. some sort of Linaro thing about which I have no background about
 - but dont really care in this context.

 Nothing related Linaro. Its just that platforms are supporting ARM BE
 mode and Linaro folks had working patches for Panda. So I suggested
 to get them on the lists.
 
 I tend to think - is this with OFF mode and CPUidle completely
 working? All context save and restore works with this? on HS and GP
 devices with BE mode builds? works on SDP4430,60 variations,
 considered reuse with AM43xx which could use parts of that logic?
 
 I mean to indicate that terms like works on panda tends always to be 
 relative.

Fair enough.
 
 It is nice to see it as a proof of concept, but I'd hate to see some
 dead code lying around in kernel and folks blindly following suit and
 introducing macros for new assembly for a feature that in practice
 just one group of folks care about and creates additional burden for
 rest of folks trying to keep that functionality going as we jump from
 one device tree style churn to another framework? Not to mean that
 good features should be kept away.. but personally, I could not find
 convincing arguments in this case..
 
I haven't looked at patch myself but as you pointed out if it adds
dead code and makes the code un-readable then probably that something
we shouldn't merge.

Regards,
Santosh
--
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 V5 0/4] DRIVERS: IRQCHIP: Add support for crossbar IP

[Santosh Shilimkar]

Sricharan,

On Wednesday 25 December 2013 11:52 PM, Sricharan R wrote:
 Hi Thomas,
 On Wednesday 18 December 2013 02:49 PM, Sricharan R wrote:
 Hi Thomas,

 On Tuesday 03 December 2013 03:57 PM, Sricharan R wrote:
 Some socs have a large number of interrupts requests to service
 the needs of its many peripherals and subsystems. All of the interrupt
 requests lines from the subsystems are not needed at the same
 time, so they have to be muxed to the controllers appropriately.
 In such places a interrupt controllers are preceded by an
 IRQ CROSSBAR that provides flexibility in muxing the device interrupt
 requests to the controller inputs.

 This series models the peripheral interrupts that can be routed through
 the crossbar to the GIC as 'routable-irqs'. The routable irqs are added
 in a separate linear domain inside the GIC. The registered routable domain's
 callback are invoked as a part of the GIC's callback, which in turn should
 allocate a free irq line and configure the IP accordingly. So every 
 peripheral
 in the dts files mentions the fixed crossbar number as its interrupt. A free
 gic line for that gets allocated and configured when the peripheral 
 interrupts
 are mapped.

 The minimal crossbar driver to track and allocate free GIC lines and 
 configure the
 crossbar is added here, along with the DT bindings.

 V5:
Addressed a comment from Mark Rutland mark.rutl...@arm.com,
updated tags and rebased on 3.13-rc2

 V4:
Addressed a couple of comments and split the DTS file updates in to
a separate series.

 V3:
Addressed few more comments from Thomas Gleixner t...@linutronix.de

Rebased patches 3,4,5,7 which updates the DTS file on top of below branch

 git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git
for_3.13/dts

Rebased patches 1,2,6 on top of 3.12 mainline
Updated Commit tags

 V2:
Addressed Thomas Gleixner t...@linutronix.de comments and
Kumar Gala ga...@codeaurora.org

Split updating the DRA7.dtsi file for adding the routable-irqs

 Previous discussions that led to this is at
 https://lkml.org/lkml/2013/9/18/540

 The V1,V2,V3,V4 post of these patches is at
   [V1]  https://lkml.org/lkml/2013/9/30/283
   [V2]  http://www.spinics.net/lists/linux-omap/msg99540.html
   [V3]  http://www.kernelhub.org/?msg=356470p=2
   [V4]  http://www.spinics.net/lists/linux-doc/msg16726.html

 Sricharan R (4):
   DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs
   DRIVERS: IRQCHIP: CROSSBAR: Add support for Crossbar IP
   ARM: OMAP4+: Correct Wakeup-gen code to use physical irq number
   ARM: DRA: Enable Crossbar IP support for DRA7XX

  Documentation/devicetree/bindings/arm/gic.txt  |6 +
  .../devicetree/bindings/arm/omap/crossbar.txt  |   27 +++
  arch/arm/mach-omap2/Kconfig|1 +
  arch/arm/mach-omap2/omap-wakeupgen.c   |4 +-
  arch/arm/mach-omap2/omap4-common.c |2 +
  drivers/irqchip/Kconfig|8 +
  drivers/irqchip/Makefile   |1 +
  drivers/irqchip/irq-crossbar.c |  208 
 
  drivers/irqchip/irq-gic.c  |   81 +++-
  include/linux/irqchip/arm-gic.h|7 +-
  include/linux/irqchip/irq-crossbar.h   |   11 ++
  11 files changed, 343 insertions(+), 13 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/arm/omap/crossbar.txt
  create mode 100644 drivers/irqchip/irq-crossbar.c
  create mode 100644 include/linux/irqchip/irq-crossbar.h


 I have addressed all the comments on this series, can this be merged now ?

   Ping..
 
Thomas has already given his reviewed-by tag so the patches can be
taken via arm-soc tree considering OMAP and GIC changes. Can you
create a branch with all these patches applied and send it
to Tony ?

Tony, Will you able to pull this and send it up to arm-soc ?

Regards,
Santosh



--
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] cpufreq: omap: clk_round_rate() can return a zero upon error

[Santosh Shilimkar]

On Monday 09 December 2013 09:18 PM, Paul Walmsley wrote:
 
 Treat both negative and zero return values from clk_round_rate() as errors.  
 This is needed since subsequent patches will convert clk_round_rate()'s 
 return value to be an unsigned type, rather than a signed type, since some 
 clock sources can generate rates higher than (2^31)-1 Hz.
 
 Eventually, when calling clk_round_rate(), only a return value of
 zero will be considered a error.  All other values will be
 considered valid rates.  The comparison against values less than
 0 is kept to preserve the correct behavior in the meantime.
 
 This patch also removes a bogus usage of IS_ERR_VALUE(), which is intended to 
 be used only on combination pointer/error code return values; a side-benefit.
 
 Signed-off-by: Paul Walmsley pwalms...@nvidia.com
 Cc: Santosh Shilimkar santosh.shilim...@ti.com
 Cc: Viresh Kumar viresh.ku...@linaro.org
 ---
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com


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

Re: [PATCH v2 1/7] usb: dwc3: keystone: add basic PM support

[Santosh Shilimkar]

On Thursday 12 December 2013 07:43 PM, Felipe Balbi wrote:
 On Thu, Dec 12, 2013 at 07:29:24PM -0500, Santosh Shilimkar wrote:
 On Thursday 12 December 2013 04:45 PM, Felipe Balbi wrote:
 A bare-minimum PM implementation which will
 server as building block for more complex
 s/server/serve ;-)
 
 hah! :-) will fix in my branch.
 
 PM implementation in the future.

 At the least will not leave clocks on unnecessarily
 when e.g.  a user write mem to /sys/power/state.

 Signed-off-by: Felipe Balbi ba...@ti.com
 ---

 improve error path a little bit.

 We will test this out. Thanks for the
 patch Felipe.
 
I see Wingman already tested the patch.
Feel free add, my ack if you need one...

Acked-by: Santosh Shilimkar santosh.shilim...@ti.com

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

Re: [PATCH v2 1/7] usb: dwc3: keystone: add basic PM support

[Santosh Shilimkar]

On Thursday 12 December 2013 04:45 PM, Felipe Balbi wrote:
 A bare-minimum PM implementation which will
 server as building block for more complex
s/server/serve ;-)
 PM implementation in the future.
 
 At the least will not leave clocks on unnecessarily
 when e.g.  a user write mem to /sys/power/state.
 
 Signed-off-by: Felipe Balbi ba...@ti.com
 ---
 
 improve error path a little bit.
 
We will test this out. Thanks for the
patch Felipe.

Regards,
Santosh
--
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] gpio: omap: refresh patch be more aggressive with pm_runtime against v3.12-rc5

[Santosh Shilimkar]

Adding Kevin's Linaro id, + Nishant,

On Tuesday 26 November 2013 05:46 PM, Chao Xu wrote:
 From: Felipe Balbi ba...@ti.com
 
 try to keep gpio block suspended as much as possible.
 
 Tested with pandaboard and a sysfs exported gpio.
 
 Signed-off-by: Felipe Balbi balbi at ti.com
 
 [caesarxuc...@gmail.com : Refreshed against v3.12-rc5, and added revision 
 check to enable aggressive pm_runtime on OMAP4-only. Because 
 am33xx_gpio_sysc.idlemodes seems to be wrongly marked as SIDLE_SMART_WKUP, 
 which might cause missed interrupts with this patch. Tested on Pandaboard rev 
 A2.]
 
Please format the text and limit it to 80 char rule.

 Signed-off-by: Chao Xu caesarxuc...@gmail.com
 ---
 According to Mr. Felipe Balbi, the original patch was not accepted because 
 interrupts would be missed when GPIO was used as IRQ source. But in my tests 
 with pandaboard, interrupts were not missed. This is because _idle_sysc() 
 sets the idlemode of gpio module to smart-idle-wakeup, and according to 
 OMAP4430 TRM, under this idlemode, the gpio can generate an asynchronous 
 wakeup request to the PRCM. And after GPIO is awake, the wake-up request is 
 reflected into the interrupt status registers. 
 
 A change made on the original patch is only applying the aggressive runtime 
 pm scheme on OMAP4, because I don’t have HW to test OMAP3 or am33xx devices. 
 According to the respective TRMs, their GPIO modules also can generate 
 wake-up request if the idlemode is set to smart-idle or smart-idle-wakeup. So 
 the patch should work for them, too. But I suspect a potential SW bug may 
 cause missed interrupts: the am33xx_gpio_sysc.idlemodes is marked as capable 
 of SIDLE_SMART_WKUP in omap_hwmod_33xx.c. But according to AM335x TRM, _only_ 
 gpio0 is capable of this mode. This may make GPIO stuck in force-idle mode 
 and unable to generate wakeup request. And thus interrupt will be missed. 
 Again, I don’t have the HW to verify whether this is a bug or not :(
 
In general I am not against this idea but patch has many assumptions which
are not entirely correct.

- SMART_WAKEUP will take care of waking IP etc not always true to power
domain getting into idle.

- If we want to go on this path then I would like to see we address
omap2_gpio_[prepare/resumne]_for_idle()

- GPIO though sound simple is one of the most notorious IP block
on PM front so this needs lot of testing. This patch not seems be
tested at all so I would have much liked it to be in RFC/RFT
state.

  drivers/gpio/gpio-omap.c|  103 
 ++-
  include/linux/platform_data/gpio-omap.h |1 +
  2 files changed, 87 insertions(+), 17 deletions(-)
 
 diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
 index 89675f8..90661f2 100644
 --- a/drivers/gpio/gpio-omap.c
 +++ b/drivers/gpio/gpio-omap.c
 @@ -76,6 +76,7 @@ struct gpio_bank {
   int context_loss_count;
   int power_mode;
   bool workaround_enabled;
 + bool is_aggressive_pm;
  
   void (*set_dataout)(struct gpio_bank *bank, int gpio, int enable);
   int (*get_context_loss_count)(struct device *dev);
 @@ -473,8 +474,15 @@ static void _disable_gpio_module(struct gpio_bank *bank, 
 unsigned offset)
  static int gpio_is_input(struct gpio_bank *bank, int mask)
  {
   void __iomem *reg = bank-base + bank-regs-direction;
 + u32 val;
  
 - return __raw_readl(reg)  mask;
 + if (bank-is_aggressive_pm)
 + pm_runtime_get_sync(bank-dev);
 + val = __raw_readl(reg)  mask;
 + if (bank-is_aggressive_pm)
 + pm_runtime_put(bank-dev);
 +
Move above in some wrapper instead of sprinkling the
'is_aggressive_pm' check everywhere.
  
 @@ -1585,18 +1651,21 @@ static const struct omap_gpio_platform_data 
 omap2_pdata = {
   .regs = omap2_gpio_regs,
   .bank_width = 32,
   .dbck_flag = false,
 + .is_aggressive_pm = false,
  };
  
  static const struct omap_gpio_platform_data omap3_pdata = {
   .regs = omap2_gpio_regs,
   .bank_width = 32,
   .dbck_flag = true,
 + .is_aggressive_pm = false,
  };
  
  static const struct omap_gpio_platform_data omap4_pdata = {
   .regs = omap4_gpio_regs,
   .bank_width = 32,
   .dbck_flag = true,
 + .is_aggressive_pm = true,
  };
  
Well OMAP IP shouldn't have different behavior on OMAP3 and
OMAP4 at least so something you can enable for OMAP4, you
should be able to do it for OMAP3 as well.

Kevin might have some more concerns to add.

Regards,
Santosh

--
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: HYP Kernel boot requirements

[Santosh Shilimkar]

On Tuesday 26 November 2013 09:13 AM, Catalin Marinas wrote:
 On Mon, Nov 25, 2013 at 07:44:08PM +, Santosh Shilimkar wrote:
 On Monday 25 November 2013 12:28 PM, Catalin Marinas wrote:
 On Mon, Nov 25, 2013 at 04:59:16PM +, Santosh Shilimkar wrote:
 What I am saying is the platforms like OMAP5 already support PM in
 mainline kernel and we can't break that for KVM. Boot-loaders
 would be thrashed after boot so you need something which runs
 in Kernel or along with Kernel to have equivalent of hyp
 switching.

 Am not challenging the agreed direction but we need to solve the
 PM problem as well before making all CPU runs boot-loader for
 HYP kernels as a must have. At least its is a change in boot
 strategy from existing kernels.

 Of course I recommend PSCI which covers both hotplug and suspend ;), but
 I guess it's not the case for OMAP5. Since OMAP has its own secondary
 booting protocol and CPU hotplug re-entry, can you not just use
 different entry point when the primary CPU was initially started in Hyp
 mode (e.g. omap5_hyp_secondary_startup)?

 How will that solve the guest secondary boot failure case when using
 the same kernel binary for guest-boot ? Even for primary CPU which
 will be suspended it needs to resume already in HYP mode and its not
 going to go through boot-loader. So the low power code needs to have
 HYP switch code so that CPU resumes in HYP mode.
 
 Is it late to rewrite the OMAP5 firmware?
 
Well its ROM'ed unfortunately so no choice. OMAP5 ROM did implement
a secure API which lets you enter into HYP mode and thats the only
thing can be used.

 What I meant is that you have the same kernel binary but with two sets
 of entry points, or maybe a single set of entry points and some global
 variable that you set during cold boot if the primary CPU is entered in
 Hyp mode. So you change the boot loader to switch to Hyp before it
 starts the kernel and leave the additional switching to be done by the
 secondary entry points (or PM code) based on the variable you set during
 cold boot. But I would recommend rewriting the firmware.
 
 I will look at PSCI more closely and see what can be done here.
 
 PSCI has a different secondary start-up and hotplug/suspend protocol and
 CPUs wake up in Hyp if available. But this requires changing your
 firmware, PSCI is not a kernel-only thing. Do you need to support both
 older and newer kernels with the OMAP5 firmware (and possibly same DT)?

Hmmm.. So thats rules out PSCI for OMAP5 then.

Keystone actually has nice way to deal with the problem since the
boot-monitor code can be patched up and hence I had no trouble
implementing the CPU starts in HYP mode requirement on it.

Regards,
Santosh


 

--
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: HYP Kernel boot requirements

[Santosh Shilimkar]

On Tuesday 26 November 2013 12:37 PM, Dave Martin wrote:
 On Tue, Nov 26, 2013 at 09:47:13AM -0500, Santosh Shilimkar wrote:
 On Tuesday 26 November 2013 09:13 AM, Catalin Marinas wrote:
 On Mon, Nov 25, 2013 at 07:44:08PM +, Santosh Shilimkar wrote:
 On Monday 25 November 2013 12:28 PM, Catalin Marinas wrote:
 On Mon, Nov 25, 2013 at 04:59:16PM +, Santosh Shilimkar wrote:
 What I am saying is the platforms like OMAP5 already support PM in
 mainline kernel and we can't break that for KVM. Boot-loaders
 would be thrashed after boot so you need something which runs
 in Kernel or along with Kernel to have equivalent of hyp
 switching.

 Am not challenging the agreed direction but we need to solve the
 PM problem as well before making all CPU runs boot-loader for
 HYP kernels as a must have. At least its is a change in boot
 strategy from existing kernels.

 Of course I recommend PSCI which covers both hotplug and suspend ;), but
 I guess it's not the case for OMAP5. Since OMAP has its own secondary
 booting protocol and CPU hotplug re-entry, can you not just use
 different entry point when the primary CPU was initially started in Hyp
 mode (e.g. omap5_hyp_secondary_startup)?

 How will that solve the guest secondary boot failure case when using
 the same kernel binary for guest-boot ? Even for primary CPU which
 will be suspended it needs to resume already in HYP mode and its not
 going to go through boot-loader. So the low power code needs to have
 HYP switch code so that CPU resumes in HYP mode.

 Is it late to rewrite the OMAP5 firmware?

 Well its ROM'ed unfortunately so no choice. OMAP5 ROM did implement
 a secure API which lets you enter into HYP mode and thats the only
 thing can be used.
 
 If the ROM is capable of loading some additional signed Secure World
 firmware after the ROM itself has booted, PSCI could be implemented
 in the second, resident firmware payload.
 
 Some SoCs ship with boot ROMs that can do that -- is this not the case
 for OMAP5?
 
On OMAP, the secure devices there is a way to do this but not for 
general purpose devices. General purpose devices once you
exit the ROM code, we exit out of security and only way to
re-enter secure word is via ROM implemented monitor/secure
APIs.

regards,
Santosh

--
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: OMAP5: Add HYP mode entry support for secondary CPUs

[Santosh Shilimkar]

On Monday 25 November 2013 10:09 AM, Christoffer Dall wrote:
 On 23 November 2013 16:07, Santosh Shilimkar santosh.shilim...@ti.com wrote:
 Boot-CPU entry into the HYP mode is managed in boot-loader but
 the secondary CPUs directly jumps to kernel during boot. Same
 path is also used for CPU hotplug as well during suspend for
 secondary CPU.

 Hence patch the secondary CPU boot path for hyp mode etry.

 Cc: Marc Zyngier marc.zyng...@arm.com
 Cc: Christoffer Dall christoffer.d...@linaro.org
 Cc: Tony Lindgren t...@atomide.com
 Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
 ---
  arch/arm/mach-omap2/omap-headsmp.S |7 +++
  1 file changed, 7 insertions(+)

 diff --git a/arch/arm/mach-omap2/omap-headsmp.S 
 b/arch/arm/mach-omap2/omap-headsmp.S
 index 75e9295..4844dd8 100644
 --- a/arch/arm/mach-omap2/omap-headsmp.S
 +++ b/arch/arm/mach-omap2/omap-headsmp.S
 @@ -22,6 +22,7 @@

  /* Physical address needed since MMU not enabled yet on secondary core */
  #define AUX_CORE_BOOT0_PA  0x48281800
 +#define API_HYP_ENTRY  0x102

  /*
   * OMAP5 specific entry point for secondary CPU to jump from ROM
 @@ -38,6 +39,12 @@ wait:ldr r2, =AUX_CORE_BOOT0_PA  @ read from 
 AuxCoreBoot0
 and r4, r4, #0x0f
 cmp r0, r4
 bne wait
 +#ifdef CONFIG_KVM_ARM_HOST
 +   ldr r12, =API_HYP_ENTRY
 +   adr r0, hyp_boot
 +   smc #0
 +hyp_boot:
 +#endif
 b   secondary_startup
  END(omap5_secondary_startup)
  /*
 
 hmm, this means that currently running this in a guest will fail to
 bring-up SMP, right?
 
Nope. Because the code under 'KVM_ARM_HOST' macro. Guest build 
will not enable CONFIG_KVM_ARM_HOST and things should be fine then.
Right ? 

 Couldn't you create a little wrapper-pen in U-Boot instead, which
 replicates the omap boot protocol and takes care of the hyp-mode
 startup there instead, keeping this completely out of the kernel?
 
Its not just booting but CPU hotplug also follows the same path
so we need the mechanism in kernel to switch mode.

In general, I think its important to consider the aspect with
CPU PM. CPUs are not going to go through the boot-loaders in
those paths and hence need of HYP entry in the kernel will
be must.

Regards,
Santosh

Regards,
Santosh
--
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

HYP Kernel boot requirements [Was ...Re: [PATCH 2/2] ARM: OMAP5: Add HYP mode entry support for secondary CPUs]

[Santosh Shilimkar]

On Monday 25 November 2013 11:33 AM, Christoffer Dall wrote:
 On 25 November 2013 08:28, Santosh Shilimkar santosh.shilim...@ti.com wrote:
 On Monday 25 November 2013 10:09 AM, Christoffer Dall wrote:
 On 23 November 2013 16:07, Santosh Shilimkar santosh.shilim...@ti.com 
 wrote:
 Boot-CPU entry into the HYP mode is managed in boot-loader but
 the secondary CPUs directly jumps to kernel during boot. Same
 path is also used for CPU hotplug as well during suspend for
 secondary CPU.

 Hence patch the secondary CPU boot path for hyp mode etry.

 Cc: Marc Zyngier marc.zyng...@arm.com
 Cc: Christoffer Dall christoffer.d...@linaro.org
 Cc: Tony Lindgren t...@atomide.com
 Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
 ---
  arch/arm/mach-omap2/omap-headsmp.S |7 +++
  1 file changed, 7 insertions(+)

 diff --git a/arch/arm/mach-omap2/omap-headsmp.S 
 b/arch/arm/mach-omap2/omap-headsmp.S
 index 75e9295..4844dd8 100644
 --- a/arch/arm/mach-omap2/omap-headsmp.S
 +++ b/arch/arm/mach-omap2/omap-headsmp.S
 @@ -22,6 +22,7 @@

  /* Physical address needed since MMU not enabled yet on secondary core */
  #define AUX_CORE_BOOT0_PA  0x48281800
 +#define API_HYP_ENTRY  0x102

  /*
   * OMAP5 specific entry point for secondary CPU to jump from ROM
 @@ -38,6 +39,12 @@ wait:ldr r2, =AUX_CORE_BOOT0_PA  @ read 
 from AuxCoreBoot0
 and r4, r4, #0x0f
 cmp r0, r4
 bne wait
 +#ifdef CONFIG_KVM_ARM_HOST
 +   ldr r12, =API_HYP_ENTRY
 +   adr r0, hyp_boot
 +   smc #0
 +hyp_boot:
 +#endif
 b   secondary_startup
  END(omap5_secondary_startup)
  /*

 hmm, this means that currently running this in a guest will fail to
 bring-up SMP, right?

 Nope. Because the code under 'KVM_ARM_HOST' macro. Guest build
 will not enable CONFIG_KVM_ARM_HOST and things should be fine then.
 Right ?

 
 That really goes against the whole single binary on all platforms
 thing. With multi-platform support you really shouldn't have to
 compile your kernel any differently for running as a guest as when
 you're running on a host.  Someone may even emulate an OMAP5 in QEMU
 and you'd certainly want your kvm-enabled kernel to run as both guest
 and host.  After all, this is not a paravirtualization solution.
 
Fair enough.

 Couldn't you create a little wrapper-pen in U-Boot instead, which
 replicates the omap boot protocol and takes care of the hyp-mode
 startup there instead, keeping this completely out of the kernel?

 Its not just booting but CPU hotplug also follows the same path
 so we need the mechanism in kernel to switch mode.

 In general, I think its important to consider the aspect with
 CPU PM. CPUs are not going to go through the boot-loaders in
 those paths and hence need of HYP entry in the kernel will
 be must.

 I agree, and PSCI is the obvious only correct answer to this.
 
 We have discussed this a bit earlier (I think Will Deacon brought this
 up - cc'ed), but I don't think anyone had any bright ideas.
 
 However, we broadly agreed on the fact that for KVM/hyp support, you
 need to boot your kernel in that mode, and this is definitely pulling
 in the wrong direction.
 
What I am saying is the platforms like OMAP5 already support PM in
mainline kernel and we can't break that for KVM. Boot-loaders
would be thrashed after boot so you need something which runs
in Kernel or along with Kernel to have equivalent of hyp
switching.

Am not challenging the agreed direction but we need to solve the
PM problem as well before making all CPU runs boot-loader for
HYP kernels as a must have. At least its is a change in boot
strategy from existing kernels.

CC'ing few more folks and changing the subject line

Regards,
Santosh

 

--
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: OMAP5: Add HYP mode entry support for secondary CPUs

[Santosh Shilimkar]

On Monday 25 November 2013 11:42 AM, Marc Zyngier wrote:
 On 25/11/13 16:28, Santosh Shilimkar wrote:
 On Monday 25 November 2013 10:09 AM, Christoffer Dall wrote:
 On 23 November 2013 16:07, Santosh Shilimkar santosh.shilim...@ti.com 
 wrote:
 Boot-CPU entry into the HYP mode is managed in boot-loader but
 the secondary CPUs directly jumps to kernel during boot. Same
 path is also used for CPU hotplug as well during suspend for
 secondary CPU.

 Hence patch the secondary CPU boot path for hyp mode etry.

 Cc: Marc Zyngier marc.zyng...@arm.com
 Cc: Christoffer Dall christoffer.d...@linaro.org
 Cc: Tony Lindgren t...@atomide.com
 Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
 ---
  arch/arm/mach-omap2/omap-headsmp.S |7 +++
  1 file changed, 7 insertions(+)

 diff --git a/arch/arm/mach-omap2/omap-headsmp.S 
 b/arch/arm/mach-omap2/omap-headsmp.S
 index 75e9295..4844dd8 100644
 --- a/arch/arm/mach-omap2/omap-headsmp.S
 +++ b/arch/arm/mach-omap2/omap-headsmp.S
 @@ -22,6 +22,7 @@

  /* Physical address needed since MMU not enabled yet on secondary core */
  #define AUX_CORE_BOOT0_PA  0x48281800
 +#define API_HYP_ENTRY  0x102

  /*
   * OMAP5 specific entry point for secondary CPU to jump from ROM
 @@ -38,6 +39,12 @@ wait:ldr r2, =AUX_CORE_BOOT0_PA  @ read 
 from AuxCoreBoot0
 and r4, r4, #0x0f
 cmp r0, r4
 bne wait
 +#ifdef CONFIG_KVM_ARM_HOST
 +   ldr r12, =API_HYP_ENTRY
 +   adr r0, hyp_boot
 +   smc #0
 +hyp_boot:
 +#endif
 b   secondary_startup
  END(omap5_secondary_startup)
  /*

 hmm, this means that currently running this in a guest will fail to
 bring-up SMP, right?

 Nope. Because the code under 'KVM_ARM_HOST' macro. Guest build 
 will not enable CONFIG_KVM_ARM_HOST and things should be fine then.
 Right ? 
 
 Absolutely not. We're way past the one image per usage model, and I
 fully expect the same kernel to boot both as a guest and a host.
 Otherwise, multiplatform is just a joke.
 
 Couldn't you create a little wrapper-pen in U-Boot instead, which
 replicates the omap boot protocol and takes care of the hyp-mode
 startup there instead, keeping this completely out of the kernel?

 Its not just booting but CPU hotplug also follows the same path
 so we need the mechanism in kernel to switch mode.

 In general, I think its important to consider the aspect with
 CPU PM. CPUs are not going to go through the boot-loaders in
 those paths and hence need of HYP entry in the kernel will
 be must.
 
 I definitely agree that you need to consider PM as well. But we've
 decided a long time ago that we wouldn't take that kind of code in the
 kernel. Your CPU has to reach the kernel in HYP, and that is down to
 your boot protocol to take care off that.
 
 There are a few options. Christoffer mentioned having a pen, and you
 also could implement PSCI fairly easily (I've recently posted a u-boot
 patch series to take care of this, though there is still a fair bit of
 work required).
 
 Whatever the approach is, the bottom line remains: your CPU enters the
 kernel in HYP.
 
Our emails crossed. I understand the stand from you guys. Lets
continue discussion on other thread.
--
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: HYP Kernel boot requirements

[Santosh Shilimkar]

On Monday 25 November 2013 12:28 PM, Catalin Marinas wrote:
 On Mon, Nov 25, 2013 at 04:59:16PM +, Santosh Shilimkar wrote:
 On Monday 25 November 2013 11:33 AM, Christoffer Dall wrote:
 On 25 November 2013 08:28, Santosh Shilimkar santosh.shilim...@ti.com 
 wrote:
 On Monday 25 November 2013 10:09 AM, Christoffer Dall wrote:
 On 23 November 2013 16:07, Santosh Shilimkar santosh.shilim...@ti.com 
 wrote:
 Boot-CPU entry into the HYP mode is managed in boot-loader but
 the secondary CPUs directly jumps to kernel during boot. Same
 path is also used for CPU hotplug as well during suspend for
 secondary CPU.

 Hence patch the secondary CPU boot path for hyp mode etry.

 Cc: Marc Zyngier marc.zyng...@arm.com
 Cc: Christoffer Dall christoffer.d...@linaro.org
 Cc: Tony Lindgren t...@atomide.com
 Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
 ---
  arch/arm/mach-omap2/omap-headsmp.S |7 +++
  1 file changed, 7 insertions(+)

 diff --git a/arch/arm/mach-omap2/omap-headsmp.S 
 b/arch/arm/mach-omap2/omap-headsmp.S
 index 75e9295..4844dd8 100644
 --- a/arch/arm/mach-omap2/omap-headsmp.S
 +++ b/arch/arm/mach-omap2/omap-headsmp.S
 @@ -22,6 +22,7 @@

  /* Physical address needed since MMU not enabled yet on secondary core 
 */
  #define AUX_CORE_BOOT0_PA  0x48281800
 +#define API_HYP_ENTRY  0x102

  /*
   * OMAP5 specific entry point for secondary CPU to jump from ROM
 @@ -38,6 +39,12 @@ wait:ldr r2, =AUX_CORE_BOOT0_PA  @ read 
 from AuxCoreBoot0
 and r4, r4, #0x0f
 cmp r0, r4
 bne wait
 +#ifdef CONFIG_KVM_ARM_HOST
 +   ldr r12, =API_HYP_ENTRY
 +   adr r0, hyp_boot
 +   smc #0
 +hyp_boot:
 +#endif
 b   secondary_startup
  END(omap5_secondary_startup)
  /*

 hmm, this means that currently running this in a guest will fail to
 bring-up SMP, right?

 Nope. Because the code under 'KVM_ARM_HOST' macro. Guest build
 will not enable CONFIG_KVM_ARM_HOST and things should be fine then.
 Right ?


 That really goes against the whole single binary on all platforms
 thing. With multi-platform support you really shouldn't have to
 compile your kernel any differently for running as a guest as when
 you're running on a host.  Someone may even emulate an OMAP5 in QEMU
 and you'd certainly want your kvm-enabled kernel to run as both guest
 and host.  After all, this is not a paravirtualization solution.

 Fair enough.

 Couldn't you create a little wrapper-pen in U-Boot instead, which
 replicates the omap boot protocol and takes care of the hyp-mode
 startup there instead, keeping this completely out of the kernel?

 Its not just booting but CPU hotplug also follows the same path
 so we need the mechanism in kernel to switch mode.

 In general, I think its important to consider the aspect with
 CPU PM. CPUs are not going to go through the boot-loaders in
 those paths and hence need of HYP entry in the kernel will
 be must.

 I agree, and PSCI is the obvious only correct answer to this.

 We have discussed this a bit earlier (I think Will Deacon brought this
 up - cc'ed), but I don't think anyone had any bright ideas.

 However, we broadly agreed on the fact that for KVM/hyp support, you
 need to boot your kernel in that mode, and this is definitely pulling
 in the wrong direction.

 What I am saying is the platforms like OMAP5 already support PM in
 mainline kernel and we can't break that for KVM. Boot-loaders
 would be thrashed after boot so you need something which runs
 in Kernel or along with Kernel to have equivalent of hyp
 switching.

 Am not challenging the agreed direction but we need to solve the
 PM problem as well before making all CPU runs boot-loader for
 HYP kernels as a must have. At least its is a change in boot
 strategy from existing kernels.
 
 Of course I recommend PSCI which covers both hotplug and suspend ;), but
 I guess it's not the case for OMAP5. Since OMAP has its own secondary
 booting protocol and CPU hotplug re-entry, can you not just use
 different entry point when the primary CPU was initially started in Hyp
 mode (e.g. omap5_hyp_secondary_startup)?
 
How will that solve the guest secondary boot failure case when using
the same kernel binary for guest-boot ? Even for primary CPU which
will be suspended it needs to resume already in HYP mode and its not
going to go through boot-loader. So the low power code needs to have
HYP switch code so that CPU resumes in HYP mode.

I will look at PSCI more closely and see what can be done here.

Regards,
Santosh



--
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: dts: OMAP5: Add maintenance interrupt for virtualisation

[Santosh Shilimkar]

Add a maintenance IRQ using PPI 9 to OMAP5 device tree
needed for virtualisation.

Cc: Marc Zyngier marc.zyng...@arm.com
Cc: Christoffer Dall christoffer.d...@linaro.org
Cc: Benoît Cousson bcous...@baylibre.com
Cc: Tony Lindgren t...@atomide.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
 arch/arm/boot/dts/omap5.dtsi |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index fc3fad5..c9f1ae4 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -74,6 +74,7 @@
  0x48212000 0x1000,
  0x48214000 0x2000,
  0x48216000 0x2000;
+   interrupts = 1 9 0x304;
};
 
/*
-- 
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

[PATCH 0/2] ARM: OMAP5: Couple of patches for KVM

[Santosh Shilimkar]

Couple of patches for OMAP5 machines towards KVM support.

Cc: Marc Zyngier marc.zyng...@arm.com
Cc: Christoffer Dall christoffer.d...@linaro.org
Cc: Tony Lindgren t...@atomide.com

Santosh Shilimkar (2):
  ARM: dts: OMAP5: Add maintenance interrupt for virtualisation
  ARM: OMAP5: Add HYP mode entry support for secondary CPUs

 arch/arm/boot/dts/omap5.dtsi   |1 +
 arch/arm/mach-omap2/omap-headsmp.S |7 +++
 2 files changed, 8 insertions(+)

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

[PATCH 2/2] ARM: OMAP5: Add HYP mode entry support for secondary CPUs

[Santosh Shilimkar]

Boot-CPU entry into the HYP mode is managed in boot-loader but
the secondary CPUs directly jumps to kernel during boot. Same
path is also used for CPU hotplug as well during suspend for
secondary CPU.

Hence patch the secondary CPU boot path for hyp mode etry.

Cc: Marc Zyngier marc.zyng...@arm.com
Cc: Christoffer Dall christoffer.d...@linaro.org
Cc: Tony Lindgren t...@atomide.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
 arch/arm/mach-omap2/omap-headsmp.S |7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/mach-omap2/omap-headsmp.S 
b/arch/arm/mach-omap2/omap-headsmp.S
index 75e9295..4844dd8 100644
--- a/arch/arm/mach-omap2/omap-headsmp.S
+++ b/arch/arm/mach-omap2/omap-headsmp.S
@@ -22,6 +22,7 @@
 
 /* Physical address needed since MMU not enabled yet on secondary core */
 #define AUX_CORE_BOOT0_PA  0x48281800
+#define API_HYP_ENTRY  0x102
 
 /*
  * OMAP5 specific entry point for secondary CPU to jump from ROM
@@ -38,6 +39,12 @@ wait:ldr r2, =AUX_CORE_BOOT0_PA  @ read from 
AuxCoreBoot0
and r4, r4, #0x0f
cmp r0, r4
bne wait
+#ifdef CONFIG_KVM_ARM_HOST
+   ldr r12, =API_HYP_ENTRY
+   adr r0, hyp_boot
+   smc #0
+hyp_boot:
+#endif
b   secondary_startup
 END(omap5_secondary_startup)
 /*
-- 
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 1/2] ARM: dts: OMAP5: Add maintenance interrupt for virtualisation

[Santosh Shilimkar]

On Saturday 23 November 2013 07:07 PM, Santosh Shilimkar wrote:
 Add a maintenance IRQ using PPI 9 to OMAP5 device tree
 needed for virtualisation.
 
 Cc: Marc Zyngier marc.zyng...@arm.com
 Cc: Christoffer Dall christoffer.d...@linaro.org
 Cc: Benoît Cousson bcous...@baylibre.com
 Cc: Tony Lindgren t...@atomide.com
 Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
 ---
  arch/arm/boot/dts/omap5.dtsi |1 +
  1 file changed, 1 insertion(+)
 
 diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
 index fc3fad5..c9f1ae4 100644
 --- a/arch/arm/boot/dts/omap5.dtsi
 +++ b/arch/arm/boot/dts/omap5.dtsi
 @@ -74,6 +74,7 @@
 0x48212000 0x1000,
 0x48214000 0x2000,
 0x48216000 0x2000;
 + interrupts = 1 9 0x304;
I should have used the GIC flags. Updated version end of the
email.

Regards,
Santosh


From 91cbd5f65ccd9a0780614fa7ab5505922bdce577 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Thu, 12 Sep 2013 15:53:13 -0400
Subject: [PATCH 1/2] ARM: dts: OMAP5: Add maintenance interrupt for
 virtualisation

Add a maintenance IRQ using PPI 9 to OMAP5 device tree
needed for virtualisation.

Cc: Marc Zyngier marc.zyng...@arm.com
Cc: Christoffer Dall christoffer.d...@linaro.org
Cc: Benoît Cousson bcous...@baylibre.com
Cc: Tony Lindgren t...@atomide.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
 arch/arm/boot/dts/omap5.dtsi |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index fc3fad5..907ab7b 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -74,6 +74,7 @@
  0x48212000 0x1000,
  0x48214000 0x2000,
  0x48216000 0x2000;
+   interrupts = GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(2) | 
IRQ_TYPE_LEVEL_HIGH);
};
 
/*
-- 
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: [RFC 01/23] gpio/omap: raw read and write endian fix

[Santosh Shilimkar]

On Friday 15 November 2013 07:01 PM, Taras Kondratiuk wrote:
 From: Victor Kamensky victor.kamen...@linaro.org
 
 All OMAP IP blocks expect LE data, but CPU may operate in BE mode.
 Need to use endian neutral functions to read/write h/w registers.
 I.e instead of __raw_read[lw] and __raw_write[lw] functions code
 need to use read[lw]_relaxed and write[lw]_relaxed functions.
 If the first simply reads/writes register, the second will byteswap
 it if host operates in BE mode.
 
 Changes are trivial sed like replacement of __raw_xxx functions
 with xxx_relaxed variant.
 
 Signed-off-by: Victor Kamensky victor.kamen...@linaro.org
 Signed-off-by: Taras Kondratiuk taras.kondrat...@linaro.org
 ---
Acked-by: Santosh Shilimkar santosh.shilim...@ti.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