public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
* Bug in linux omap clock framework?
@ 2008-12-05 14:49 Tomi.Valkeinen
  2008-12-05 18:23 ` Kevin Hilman
  2008-12-06 23:51 ` Paul Walmsley
  0 siblings, 2 replies; 21+ messages in thread
From: Tomi.Valkeinen @ 2008-12-05 14:49 UTC (permalink / raw)
  To: linux-omap

Hi,

I have had strange clk_enable() crashes with DSS2, and now I managed to
isolate it. With the included patch, on OMAP3 SDP board, with default
kernel config, I always get the crash below. In this example case it
happens at specific time on boot, but with DSS2 it happens randomly at
runtime, when I enable the DSS clocks.

diff --git a/drivers/video/omap/omapfb_main.c
b/drivers/video/omap/omapfb_main.c
index 3bb4247..2d5ef0d 100644
--- a/drivers/video/omap/omapfb_main.c
+++ b/drivers/video/omap/omapfb_main.c
@@ -27,6 +27,7 @@
 #include <linux/platform_device.h>
 #include <linux/mm.h>
 #include <linux/uaccess.h>
+#include <linux/clk.h>
 
 #include <mach/dma.h>
 #include <mach/omapfb.h>
@@ -1806,6 +1807,18 @@ static int omapfb_probe(struct platform_device
*pdev)
 {
        BUG_ON(fbdev_pdev != NULL);
 
+       {
+               struct clk *c1, *c2;
+               c1 = clk_get(&pdev->dev, "dss_ick");
+               c2 = clk_get(&pdev->dev, "dss1_fck");
+               while(1) {
+                       clk_enable(c1);
+                       clk_enable(c2);
+                       clk_disable(c1);
+                       clk_disable(c2);
+               }
+       }
+
        /* Delay actual initialization until the LCD is registered */
        fbdev_pdev = pdev;
        if (fbdev_panel != NULL)
@@ -1958,7 +1971,7 @@ module_param_named(rotate, def_rotate, uint,
0664);
 module_param_named(mirror, def_mirror, uint, 0664);
 module_param_named(manual_update, manual_update, bool, 0664);
 
-module_init(omapfb_init);
+late_initcall(omapfb_init);
 module_exit(omapfb_cleanup);
 
 MODULE_DESCRIPTION("TI OMAP framebuffer driver");


And the crash:



<1>Unhandled fault: external abort on non-linefetch (0x1028) at
0xd8200098
Unhandled fault: external abort on non-linefetch (0x1028) at 0xd8200098
Internal error: : 1028 [#1]
Internal error: : 1028 [#1]
Modules linked in:Modules linked in:

CPU: 0    Not tainted  (2.6.28-rc6-omap1-05264-g1705711-dirty #6)
CPU: 0    Not tainted  (2.6.28-rc6-omap1-05264-g1705711-dirty #6)
PC is at __irq_svc+0x34/0x80
PC is at __irq_svc+0x34/0x80
LR is at _omap2_clk_enable+0xa0/0xe0
LR is at _omap2_clk_enable+0xa0/0xe0
pc : [<c002c9d4>]    lr : [<c0036314>]    psr: 60000193
sp : c7817d30  ip : c7817d40  fp : c7817d8c
pc : [<c002c9d4>]    lr : [<c0036314>]    psr: 60000193
sp : c7817d30  ip : c7817d40  fp : c7817d8c
r10: c001a210  r9 : 00000000  r8 : c0395048
r10: c001a210  r9 : 00000000  r8 : c0395048
r7 : c03910c0  r6 : c03910c0  r5 : d8200000  r4 : ffffffff
r7 : c03910c0  r6 : c03910c0  r5 : d8200000  r4 : ffffffff
r3 : 60000013  r2 : c003ae80  r1 : c0036314  r0 : c7817d78
r3 : 60000013  r2 : c003ae80  r1 : c0036314  r0 : c7817d78
Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 10c5387f  Table: 80004018  DAC: 00000017
Control: 10c5387f  Table: 80004018  DAC: 00000017
Process swapper (pid: 1, stack limit = 0xc78162e0)
Process swapper (pid: 1, stack limit = 0xc78162e0)
Stack: (0xc7817d30 to 0xc7818000)
Stack: (0xc7817d30 to 0xc7818000)
7d20: 7d20:
00000000 00000000 00000000 00000000 00000010 00000010 00000001 00000001 

7d40: 7d40: 80000013 80000013 c037ac4c c037ac4c c03910c0 c03910c0
c03910c0 c03910c0 c0395048 c0395048 00000000 00000000 c001a210 c001a210
c7817d8c c7817d8c 

7d60: 7d60: c7817d40 c7817d40 c7817d78 c7817d78 c0036314 c0036314
c003ae80 c003ae80 60000013 60000013 ffffffff ffffffff fffffffe fffffffe
c037ac4c c037ac4c 

7d80: 7d80: c7817da4 c7817da4 c7817d90 c7817d90 c018bef4 c018bef4
c003ae48 c003ae48 c037de28 c037de28 c037ded4 c037ded4 c7817db4 c7817db4
c7817da8 c7817da8 

7da0: 7da0: c01afd70 c01afd70 c018beac c018beac c7817dd4 c7817dd4
c7817db8 c7817db8 c01aef90 c01aef90 c01afd5c c01afd5c c037de28 c037de28
c037ded4 c037ded4 

7dc0: 7dc0: c03910c0 c03910c0 c03910c0 c03910c0 c7817df4 c7817df4
c7817dd8 c7817dd8 c01af0a4 c01af0a4 c01aeecc c01aeecc 00000000 00000000
c7817df8 c7817df8 

7de0: 7de0: c01af03c c01af03c c03910c0 c03910c0 c7817e1c c7817e1c
c7817df8 c7817df8 c01ae510 c01ae510 c01af048 c01af048 c78034d8 c78034d8
c037de70 c037de70 

7e00: 7e00: 00000000 00000000 c03910c0 c03910c0 00000000 00000000
c7941b60 c7941b60 c7817e2c c7817e2c c7817e20 c7817e20 c01aedd8 c01aedd8
c01ae4d0 c01ae4d0 

7e20: 7e20: c7817e5c c7817e5c c7817e30 c7817e30 c01ae994 c01ae994
c01aedc4 c01aedc4 c0325184 c0325184 c03910c0 c03910c0 00000000 00000000
c03a0480 c03a0480 

7e40: 7e40: c03910c0 c03910c0 00000000 00000000 00000000 00000000
00000000 00000000 c7817e84 c7817e84 c7817e60 c7817e60 c01af298 c01af298
c01ae8f8 c01ae8f8 

7e60: 7e60: c03a0480 c03a0480 c0024b00 c0024b00 00000000 00000000
00000000 00000000 00000000 00000000 c001a210 c001a210 c7817e94 c7817e94
c7817e88 c7817e88 

7e80: 7e80: c01b0108 c01b0108 c01af20c c01af20c c7817ebc c7817ebc
c7817e98 c7817e98 c001a41c c001a41c c01b009c c01b009c c0019c1c c0019c1c
c01754b0 c01754b0 

7ea0: 7ea0: 00000000 00000000 00000000 00000000 12bdf916 12bdf916
c03a0480 c03a0480 c7817fdc c7817fdc c7817ec0 c7817ec0 c002c2d0 c002c2d0
c001a21c c001a21c 

7ec0: 7ec0: c78035a0 c78035a0 c78035a4 c78035a4 00000000 00000000
0000024e 0000024e c7817f34 c7817f34 c7817ee0 c7817ee0 c016ec10 c016ec10
c0099994 c0099994 

7ee0: 7ee0: 00000000 00000000 c7817f54 c7817f54 000000d0 000000d0
c7811f28 c7811f28 00000000 00000000 c03aa84c c03aa84c 000000d0 000000d0
c03a93a4 c03a93a4 

7f00: 7f00: c7817f2c c7817f2c c7817f10 c7817f10 c016ee24 c016ee24
c783c0a0 c783c0a0 c03859bc c03859bc c783d6e0 c783d6e0 c03a93a4 c03a93a4
00000000 00000000 

7f20: 7f20: 00000000 00000000 00000000 00000000 c7817f44 c7817f44
c7817f38 c7817f38 c016ec44 c016ec44 c016ea7c c016ea7c c7817f74 c7817f74
c7817f48 c7817f48 

7f40: 7f40: c00da818 c00da818 c016ec38 c016ec38 c783d6e0 c783d6e0
c0328032 c0328032 c7817f9e c7817f9e 0000024e 0000024e c783c0a0 c783c0a0
c03859bc c03859bc 

7f60: 7f60: 0000015f 0000015f c03a93a4 c03a93a4 c7817f94 c7817f94
c7817f78 c7817f78 c00daa00 c00daa00 c00da7ec c00da7ec c7817f94 c7817f94
c783d6e0 c783d6e0 

7f80: 7f80: c00dab7c c00dab7c c7817f9e c7817f9e c7817fc4 c7817fc4
c7817f98 c7817f98 c0077f98 c0077f98 c00daa0c c00daa0c c7817fb4 c7817fb4
35337588 35337588 

7fa0: 7fa0: 00000031 00000031 00000000 00000000 00000192 00000192
c03865b0 c03865b0 00000000 00000000 c0024e74 c0024e74 c0024b00 c0024b00
00000000 00000000 

7fc0: 7fc0: 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 c7817ff4 c7817ff4 c7817fe0 c7817fe0 c00088b8 c00088b8
c002c27c c002c27c 

7fe0: 7fe0: 00000000 00000000 00000000 00000000 00000000 00000000
c7817ff8 c7817ff8 c00538a8 c00538a8 c0008854 c0008854 ffff0000 ffff0000
ffff0000 ffff0000 

Backtrace: Backtrace: 

[<c003ae3c>] [<c003ae3c>] (clk_enable+0x0/0x54) (clk_enable+0x0/0x54)
from [<c018bef4>] from [<c018bef4>] (omapfb_probe+0x54/0x7c)
(omapfb_probe+0x54/0x7c)
 r5:c037ac4c r5:c037ac4c r4:fffffffe r4:fffffffe

[<c018bea0>] [<c018bea0>] (omapfb_probe+0x0/0x7c)
(omapfb_probe+0x0/0x7c) from [<c01afd70>] from [<c01afd70>]
(platform_drv_probe+0x20/0x24)
(platform_drv_probe+0x20/0x24)
 r5:c037ded4 r5:c037ded4 r4:c037de28 r4:c037de28

[<c01afd50>] [<c01afd50>] (platform_drv_probe+0x0/0x24)
(platform_drv_probe+0x0/0x24) from [<c01aef90>] from [<c01aef90>]
(driver_probe_device+0xd0/0x17c)
(driver_probe_device+0xd0/0x17c)
[<c01aeec0>] [<c01aeec0>] (driver_probe_device+0x0/0x17c)
(driver_probe_device+0x0/0x17c) from [<c01af0a4>] from [<c01af0a4>]
(__driver_attach+0x68/0x8c)
(__driver_attach+0x68/0x8c)
 r7:c03910c0 r7:c03910c0 r6:c03910c0 r6:c03910c0 r5:c037ded4 r5:c037ded4
r4:c037de28 r4:c037de28

[<c01af03c>] [<c01af03c>] (__driver_attach+0x0/0x8c)
(__driver_attach+0x0/0x8c) from [<c01ae510>] from [<c01ae510>]
(bus_for_each_dev+0x4c/0x84)
(bus_for_each_dev+0x4c/0x84)
 r7:c03910c0 r7:c03910c0 r6:c01af03c r6:c01af03c r5:c7817df8 r5:c7817df8
r4:00000000 r4:00000000

[<c01ae4c4>] [<c01ae4c4>] (bus_for_each_dev+0x0/0x84)
(bus_for_each_dev+0x0/0x84) from [<c01aedd8>] from [<c01aedd8>]
(driver_attach+0x20/0x28)
(driver_attach+0x20/0x28)
 r7:c7941b60 r7:c7941b60 r6:00000000 r6:00000000 r5:c03910c0 r5:c03910c0
r4:00000000 r4:00000000

[<c01aedb8>] [<c01aedb8>] (driver_attach+0x0/0x28)
(driver_attach+0x0/0x28) from [<c01ae994>] from [<c01ae994>]
(bus_add_driver+0xa8/0x214)
(bus_add_driver+0xa8/0x214)
[<c01ae8ec>] [<c01ae8ec>] (bus_add_driver+0x0/0x214)
(bus_add_driver+0x0/0x214) from [<c01af298>] from [<c01af298>]
(driver_register+0x98/0x120)
(driver_register+0x98/0x120)
 r8:00000000 r8:00000000 r7:00000000 r7:00000000 r6:00000000 r6:00000000
r5:c03910c0 r5:c03910c0 r4:c03a0480 r4:c03a0480

[<c01af200>] [<c01af200>] (driver_register+0x0/0x120)
(driver_register+0x0/0x120) from [<c01b0108>] from [<c01b0108>]
(platform_driver_register+0x78/0x94)
(platform_driver_register+0x78/0x94)
[<c01b0090>] [<c01b0090>] (platform_driver_register+0x0/0x94)
(platform_driver_register+0x0/0x94) from [<c001a41c>] from [<c001a41c>]
(omapfb_init+0x20c/0x24c)
(omapfb_init+0x20c/0x24c)
[<c001a210>] [<c001a210>] (omapfb_init+0x0/0x24c)
(omapfb_init+0x0/0x24c) from [<c002c2d0>] from [<c002c2d0>]
(do_one_initcall+0x60/0x18c)
(do_one_initcall+0x60/0x18c)
 r4:c03a0480 r4:c03a0480

[<c002c270>] [<c002c270>] (do_one_initcall+0x0/0x18c)
(do_one_initcall+0x0/0x18c) from [<c00088b8>] from [<c00088b8>]
(kernel_init+0x70/0xdc)
(kernel_init+0x70/0xdc)
[<c0008848>] [<c0008848>] (kernel_init+0x0/0xdc) (kernel_init+0x0/0xdc)
from [<c00538a8>] from [<c00538a8>] (do_exit+0x0/0x6ac)
(do_exit+0x0/0x6ac)
 r5:00000000 r5:00000000 r4:00000000 r4:00000000

Code: Code: e58d1000 e58d1000 e1a0100e e1a0100e e885001f e885001f
e59f503c e59f503c (e5950098) (e5950098) 

<4>---[ end trace 7567be4737bae816 ]---
---[ end trace 7567be4737bae816 ]---
<0>Kernel panic - not syncing: Attempted to kill init!
Kernel panic - not syncing: Attempted to kill init!




^ permalink raw reply related	[flat|nested] 21+ messages in thread

* Re: Bug in linux omap clock framework?
  2008-12-05 14:49 Bug in linux omap clock framework? Tomi.Valkeinen
@ 2008-12-05 18:23 ` Kevin Hilman
  2008-12-08  7:59   ` Tomi Valkeinen
  2008-12-06 23:51 ` Paul Walmsley
  1 sibling, 1 reply; 21+ messages in thread
From: Kevin Hilman @ 2008-12-05 18:23 UTC (permalink / raw)
  To: Tomi.Valkeinen; +Cc: linux-omap

<Tomi.Valkeinen@nokia.com> writes:

> Hi,
>
> I have had strange clk_enable() crashes with DSS2, and now I managed to
> isolate it. With the included patch, on OMAP3 SDP board, with default
> kernel config, I always get the crash below. In this example case it
> happens at specific time on boot, but with DSS2 it happens randomly at
> runtime, when I enable the DSS clocks.
>
> diff --git a/drivers/video/omap/omapfb_main.c
> b/drivers/video/omap/omapfb_main.c
> index 3bb4247..2d5ef0d 100644
> --- a/drivers/video/omap/omapfb_main.c
> +++ b/drivers/video/omap/omapfb_main.c
> @@ -27,6 +27,7 @@
>  #include <linux/platform_device.h>
>  #include <linux/mm.h>
>  #include <linux/uaccess.h>
> +#include <linux/clk.h>
>  
>  #include <mach/dma.h>
>  #include <mach/omapfb.h>
> @@ -1806,6 +1807,18 @@ static int omapfb_probe(struct platform_device
> *pdev)
>  {
>         BUG_ON(fbdev_pdev != NULL);
>  
> +       {
> +               struct clk *c1, *c2;
> +               c1 = clk_get(&pdev->dev, "dss_ick");
> +               c2 = clk_get(&pdev->dev, "dss1_fck");
> +               while(1) {
> +                       clk_enable(c1);
> +                       clk_enable(c2);
> +                       clk_disable(c1);
> +                       clk_disable(c2);
> +               }
> +       }
> +
>         /* Delay actual initialization until the LCD is registered */
>         fbdev_pdev = pdev;
>         if (fbdev_panel != NULL)
> @@ -1958,7 +1971,7 @@ module_param_named(rotate, def_rotate, uint,
> 0664);
>  module_param_named(mirror, def_mirror, uint, 0664);
>  module_param_named(manual_update, manual_update, bool, 0664);
>  
> -module_init(omapfb_init);
> +late_initcall(omapfb_init);
>  module_exit(omapfb_cleanup);
>  
>  MODULE_DESCRIPTION("TI OMAP framebuffer driver");
>
>
> And the crash:
>
>
>
> <1>Unhandled fault: external abort on non-linefetch (0x1028) at
> 0xd8200098
> Unhandled fault: external abort on non-linefetch (0x1028) at 0xd8200098
> Internal error: : 1028 [#1]
> Internal error: : 1028 [#1]
> Modules linked in:Modules linked in:
>
> CPU: 0    Not tainted  (2.6.28-rc6-omap1-05264-g1705711-dirty #6)
> CPU: 0    Not tainted  (2.6.28-rc6-omap1-05264-g1705711-dirty #6)
> PC is at __irq_svc+0x34/0x80
> PC is at __irq_svc+0x34/0x80
> LR is at _omap2_clk_enable+0xa0/0xe0
> LR is at _omap2_clk_enable+0xa0/0xe0

What looks to be happening is an interrupt is firing in the middle of
your clk_enable() call, and accesses to the Interrupt controller
registers are triggering a fault.

As a temporary workaround, could you try wrapping your clk_enable() 
with an IRQ save/restore?  Something like:

  local_irq_save(flags);
  clk_enable(c);
  local_irq_restore(flags);

If this works, then we need to investigate in more detail which
interrupt is firing, and why the INTC registers are not accessible.

Kevin

> pc : [<c002c9d4>]    lr : [<c0036314>]    psr: 60000193
> sp : c7817d30  ip : c7817d40  fp : c7817d8c
> pc : [<c002c9d4>]    lr : [<c0036314>]    psr: 60000193
> sp : c7817d30  ip : c7817d40  fp : c7817d8c
> r10: c001a210  r9 : 00000000  r8 : c0395048
> r10: c001a210  r9 : 00000000  r8 : c0395048
> r7 : c03910c0  r6 : c03910c0  r5 : d8200000  r4 : ffffffff
> r7 : c03910c0  r6 : c03910c0  r5 : d8200000  r4 : ffffffff
> r3 : 60000013  r2 : c003ae80  r1 : c0036314  r0 : c7817d78
> r3 : 60000013  r2 : c003ae80  r1 : c0036314  r0 : c7817d78
> Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
> Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
> Control: 10c5387f  Table: 80004018  DAC: 00000017
> Control: 10c5387f  Table: 80004018  DAC: 00000017
> Process swapper (pid: 1, stack limit = 0xc78162e0)
> Process swapper (pid: 1, stack limit = 0xc78162e0)
> Stack: (0xc7817d30 to 0xc7818000)
> Stack: (0xc7817d30 to 0xc7818000)
> 7d20: 7d20:
> 00000000 00000000 00000000 00000000 00000010 00000010 00000001 00000001 
>
> 7d40: 7d40: 80000013 80000013 c037ac4c c037ac4c c03910c0 c03910c0
> c03910c0 c03910c0 c0395048 c0395048 00000000 00000000 c001a210 c001a210
> c7817d8c c7817d8c 
>
> 7d60: 7d60: c7817d40 c7817d40 c7817d78 c7817d78 c0036314 c0036314
> c003ae80 c003ae80 60000013 60000013 ffffffff ffffffff fffffffe fffffffe
> c037ac4c c037ac4c 
>
> 7d80: 7d80: c7817da4 c7817da4 c7817d90 c7817d90 c018bef4 c018bef4
> c003ae48 c003ae48 c037de28 c037de28 c037ded4 c037ded4 c7817db4 c7817db4
> c7817da8 c7817da8 
>
> 7da0: 7da0: c01afd70 c01afd70 c018beac c018beac c7817dd4 c7817dd4
> c7817db8 c7817db8 c01aef90 c01aef90 c01afd5c c01afd5c c037de28 c037de28
> c037ded4 c037ded4 
>
> 7dc0: 7dc0: c03910c0 c03910c0 c03910c0 c03910c0 c7817df4 c7817df4
> c7817dd8 c7817dd8 c01af0a4 c01af0a4 c01aeecc c01aeecc 00000000 00000000
> c7817df8 c7817df8 
>
> 7de0: 7de0: c01af03c c01af03c c03910c0 c03910c0 c7817e1c c7817e1c
> c7817df8 c7817df8 c01ae510 c01ae510 c01af048 c01af048 c78034d8 c78034d8
> c037de70 c037de70 
>
> 7e00: 7e00: 00000000 00000000 c03910c0 c03910c0 00000000 00000000
> c7941b60 c7941b60 c7817e2c c7817e2c c7817e20 c7817e20 c01aedd8 c01aedd8
> c01ae4d0 c01ae4d0 
>
> 7e20: 7e20: c7817e5c c7817e5c c7817e30 c7817e30 c01ae994 c01ae994
> c01aedc4 c01aedc4 c0325184 c0325184 c03910c0 c03910c0 00000000 00000000
> c03a0480 c03a0480 
>
> 7e40: 7e40: c03910c0 c03910c0 00000000 00000000 00000000 00000000
> 00000000 00000000 c7817e84 c7817e84 c7817e60 c7817e60 c01af298 c01af298
> c01ae8f8 c01ae8f8 
>
> 7e60: 7e60: c03a0480 c03a0480 c0024b00 c0024b00 00000000 00000000
> 00000000 00000000 00000000 00000000 c001a210 c001a210 c7817e94 c7817e94
> c7817e88 c7817e88 
>
> 7e80: 7e80: c01b0108 c01b0108 c01af20c c01af20c c7817ebc c7817ebc
> c7817e98 c7817e98 c001a41c c001a41c c01b009c c01b009c c0019c1c c0019c1c
> c01754b0 c01754b0 
>
> 7ea0: 7ea0: 00000000 00000000 00000000 00000000 12bdf916 12bdf916
> c03a0480 c03a0480 c7817fdc c7817fdc c7817ec0 c7817ec0 c002c2d0 c002c2d0
> c001a21c c001a21c 
>
> 7ec0: 7ec0: c78035a0 c78035a0 c78035a4 c78035a4 00000000 00000000
> 0000024e 0000024e c7817f34 c7817f34 c7817ee0 c7817ee0 c016ec10 c016ec10
> c0099994 c0099994 
>
> 7ee0: 7ee0: 00000000 00000000 c7817f54 c7817f54 000000d0 000000d0
> c7811f28 c7811f28 00000000 00000000 c03aa84c c03aa84c 000000d0 000000d0
> c03a93a4 c03a93a4 
>
> 7f00: 7f00: c7817f2c c7817f2c c7817f10 c7817f10 c016ee24 c016ee24
> c783c0a0 c783c0a0 c03859bc c03859bc c783d6e0 c783d6e0 c03a93a4 c03a93a4
> 00000000 00000000 
>
> 7f20: 7f20: 00000000 00000000 00000000 00000000 c7817f44 c7817f44
> c7817f38 c7817f38 c016ec44 c016ec44 c016ea7c c016ea7c c7817f74 c7817f74
> c7817f48 c7817f48 
>
> 7f40: 7f40: c00da818 c00da818 c016ec38 c016ec38 c783d6e0 c783d6e0
> c0328032 c0328032 c7817f9e c7817f9e 0000024e 0000024e c783c0a0 c783c0a0
> c03859bc c03859bc 
>
> 7f60: 7f60: 0000015f 0000015f c03a93a4 c03a93a4 c7817f94 c7817f94
> c7817f78 c7817f78 c00daa00 c00daa00 c00da7ec c00da7ec c7817f94 c7817f94
> c783d6e0 c783d6e0 
>
> 7f80: 7f80: c00dab7c c00dab7c c7817f9e c7817f9e c7817fc4 c7817fc4
> c7817f98 c7817f98 c0077f98 c0077f98 c00daa0c c00daa0c c7817fb4 c7817fb4
> 35337588 35337588 
>
> 7fa0: 7fa0: 00000031 00000031 00000000 00000000 00000192 00000192
> c03865b0 c03865b0 00000000 00000000 c0024e74 c0024e74 c0024b00 c0024b00
> 00000000 00000000 
>
> 7fc0: 7fc0: 00000000 00000000 00000000 00000000 00000000 00000000
> 00000000 00000000 c7817ff4 c7817ff4 c7817fe0 c7817fe0 c00088b8 c00088b8
> c002c27c c002c27c 
>
> 7fe0: 7fe0: 00000000 00000000 00000000 00000000 00000000 00000000
> c7817ff8 c7817ff8 c00538a8 c00538a8 c0008854 c0008854 ffff0000 ffff0000
> ffff0000 ffff0000 
>
> Backtrace: Backtrace: 
>
> [<c003ae3c>] [<c003ae3c>] (clk_enable+0x0/0x54) (clk_enable+0x0/0x54)
> from [<c018bef4>] from [<c018bef4>] (omapfb_probe+0x54/0x7c)
> (omapfb_probe+0x54/0x7c)
>  r5:c037ac4c r5:c037ac4c r4:fffffffe r4:fffffffe
>
> [<c018bea0>] [<c018bea0>] (omapfb_probe+0x0/0x7c)
> (omapfb_probe+0x0/0x7c) from [<c01afd70>] from [<c01afd70>]
> (platform_drv_probe+0x20/0x24)
> (platform_drv_probe+0x20/0x24)
>  r5:c037ded4 r5:c037ded4 r4:c037de28 r4:c037de28
>
> [<c01afd50>] [<c01afd50>] (platform_drv_probe+0x0/0x24)
> (platform_drv_probe+0x0/0x24) from [<c01aef90>] from [<c01aef90>]
> (driver_probe_device+0xd0/0x17c)
> (driver_probe_device+0xd0/0x17c)
> [<c01aeec0>] [<c01aeec0>] (driver_probe_device+0x0/0x17c)
> (driver_probe_device+0x0/0x17c) from [<c01af0a4>] from [<c01af0a4>]
> (__driver_attach+0x68/0x8c)
> (__driver_attach+0x68/0x8c)
>  r7:c03910c0 r7:c03910c0 r6:c03910c0 r6:c03910c0 r5:c037ded4 r5:c037ded4
> r4:c037de28 r4:c037de28
>
> [<c01af03c>] [<c01af03c>] (__driver_attach+0x0/0x8c)
> (__driver_attach+0x0/0x8c) from [<c01ae510>] from [<c01ae510>]
> (bus_for_each_dev+0x4c/0x84)
> (bus_for_each_dev+0x4c/0x84)
>  r7:c03910c0 r7:c03910c0 r6:c01af03c r6:c01af03c r5:c7817df8 r5:c7817df8
> r4:00000000 r4:00000000
>
> [<c01ae4c4>] [<c01ae4c4>] (bus_for_each_dev+0x0/0x84)
> (bus_for_each_dev+0x0/0x84) from [<c01aedd8>] from [<c01aedd8>]
> (driver_attach+0x20/0x28)
> (driver_attach+0x20/0x28)
>  r7:c7941b60 r7:c7941b60 r6:00000000 r6:00000000 r5:c03910c0 r5:c03910c0
> r4:00000000 r4:00000000
>
> [<c01aedb8>] [<c01aedb8>] (driver_attach+0x0/0x28)
> (driver_attach+0x0/0x28) from [<c01ae994>] from [<c01ae994>]
> (bus_add_driver+0xa8/0x214)
> (bus_add_driver+0xa8/0x214)
> [<c01ae8ec>] [<c01ae8ec>] (bus_add_driver+0x0/0x214)
> (bus_add_driver+0x0/0x214) from [<c01af298>] from [<c01af298>]
> (driver_register+0x98/0x120)
> (driver_register+0x98/0x120)
>  r8:00000000 r8:00000000 r7:00000000 r7:00000000 r6:00000000 r6:00000000
> r5:c03910c0 r5:c03910c0 r4:c03a0480 r4:c03a0480
>
> [<c01af200>] [<c01af200>] (driver_register+0x0/0x120)
> (driver_register+0x0/0x120) from [<c01b0108>] from [<c01b0108>]
> (platform_driver_register+0x78/0x94)
> (platform_driver_register+0x78/0x94)
> [<c01b0090>] [<c01b0090>] (platform_driver_register+0x0/0x94)
> (platform_driver_register+0x0/0x94) from [<c001a41c>] from [<c001a41c>]
> (omapfb_init+0x20c/0x24c)
> (omapfb_init+0x20c/0x24c)
> [<c001a210>] [<c001a210>] (omapfb_init+0x0/0x24c)
> (omapfb_init+0x0/0x24c) from [<c002c2d0>] from [<c002c2d0>]
> (do_one_initcall+0x60/0x18c)
> (do_one_initcall+0x60/0x18c)
>  r4:c03a0480 r4:c03a0480
>
> [<c002c270>] [<c002c270>] (do_one_initcall+0x0/0x18c)
> (do_one_initcall+0x0/0x18c) from [<c00088b8>] from [<c00088b8>]
> (kernel_init+0x70/0xdc)
> (kernel_init+0x70/0xdc)
> [<c0008848>] [<c0008848>] (kernel_init+0x0/0xdc) (kernel_init+0x0/0xdc)
> from [<c00538a8>] from [<c00538a8>] (do_exit+0x0/0x6ac)
> (do_exit+0x0/0x6ac)
>  r5:00000000 r5:00000000 r4:00000000 r4:00000000
>
> Code: Code: e58d1000 e58d1000 e1a0100e e1a0100e e885001f e885001f
> e59f503c e59f503c (e5950098) (e5950098) 
>
> <4>---[ end trace 7567be4737bae816 ]---
> ---[ end trace 7567be4737bae816 ]---
> <0>Kernel panic - not syncing: Attempted to kill init!
> Kernel panic - not syncing: Attempted to kill init!
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Bug in linux omap clock framework?
  2008-12-05 14:49 Bug in linux omap clock framework? Tomi.Valkeinen
  2008-12-05 18:23 ` Kevin Hilman
@ 2008-12-06 23:51 ` Paul Walmsley
  2008-12-08  8:59   ` Tomi Valkeinen
  2008-12-09  9:15   ` Tomi Valkeinen
  1 sibling, 2 replies; 21+ messages in thread
From: Paul Walmsley @ 2008-12-06 23:51 UTC (permalink / raw)
  To: Tomi.Valkeinen; +Cc: linux-omap, khilman

Hi Tomi,

nice test case.

On Fri, 5 Dec 2008, Tomi.Valkeinen@nokia.com wrote:

> I have had strange clk_enable() crashes with DSS2, and now I managed to
> isolate it. With the included patch, on OMAP3 SDP board, with default
> kernel config, I always get the crash below. In this example case it
> happens at specific time on boot, but with DSS2 it happens randomly at
> runtime, when I enable the DSS clocks.

Looks like there's some problem with the DSS driver's usage of 
dss_tv_fclk.  Enabling dss_tv_fclk before entering your test code's 
while-loop makes the problem go away here.  Patch below.

As an aside, your test patch does not actually disable dss1_fclk, since it 
is already enabled by the time the while-loop starts.  So you might also 
want to add a clk_disable(c2) before your while-loop starts, when you 
test.

Based on the traceback that you sent, I'd conjecture that probably some 
part of the DSS subsystem is generating an interrupt via DSS_IRQ; but then 
dss_iclk ends up disabled, and the MPU INTC is not able to communicate 
with the DSS, and the INTC wedges.  (The aborting access is to 0xd8200098, 
the INTCPS_PENDING_IRQ0 register, rather than a DSS register.)  Probably 
some IRQs need to be masked before disabling the dss_iclk.


- Paul



 drivers/video/omap/omapfb_main.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/video/omap/omapfb_main.c b/drivers/video/omap/omapfb_main.c
index a77e3bf..57b9e98 100644
--- a/drivers/video/omap/omapfb_main.c
+++ b/drivers/video/omap/omapfb_main.c
@@ -1808,9 +1808,11 @@ static int omapfb_probe(struct platform_device *pdev)
 	BUG_ON(fbdev_pdev != NULL);
 
 	{
-		struct clk *c1, *c2;
+		struct clk *c1, *c2, *c3;
 		c1 = clk_get(&pdev->dev, "dss_ick");
 		c2 = clk_get(&pdev->dev, "dss1_fck");
+		c3 = clk_get(&pdev->dev, "dss_tv_fck");
+ 		clk_enable(c3);
 		while(1) {
 			clk_enable(c1);
 			clk_enable(c2);

^ permalink raw reply related	[flat|nested] 21+ messages in thread

* Re: Bug in linux omap clock framework?
  2008-12-05 18:23 ` Kevin Hilman
@ 2008-12-08  7:59   ` Tomi Valkeinen
  0 siblings, 0 replies; 21+ messages in thread
From: Tomi Valkeinen @ 2008-12-08  7:59 UTC (permalink / raw)
  To: ext Kevin Hilman; +Cc: linux-omap

On Fri, 2008-12-05 at 10:23 -0800, ext Kevin Hilman wrote:
> <Tomi.Valkeinen@nokia.com> writes:
> 
> > Hi,
> >
> > I have had strange clk_enable() crashes with DSS2, and now I managed to
> > isolate it. With the included patch, on OMAP3 SDP board, with default
> > kernel config, I always get the crash below. In this example case it
> > happens at specific time on boot, but with DSS2 it happens randomly at
> > runtime, when I enable the DSS clocks.
> >
> > diff --git a/drivers/video/omap/omapfb_main.c
> > b/drivers/video/omap/omapfb_main.c
> > index 3bb4247..2d5ef0d 100644
> > --- a/drivers/video/omap/omapfb_main.c
> > +++ b/drivers/video/omap/omapfb_main.c
> > @@ -27,6 +27,7 @@
> >  #include <linux/platform_device.h>
> >  #include <linux/mm.h>
> >  #include <linux/uaccess.h>
> > +#include <linux/clk.h>
> >  
> >  #include <mach/dma.h>
> >  #include <mach/omapfb.h>
> > @@ -1806,6 +1807,18 @@ static int omapfb_probe(struct platform_device
> > *pdev)
> >  {
> >         BUG_ON(fbdev_pdev != NULL);
> >  
> > +       {
> > +               struct clk *c1, *c2;
> > +               c1 = clk_get(&pdev->dev, "dss_ick");
> > +               c2 = clk_get(&pdev->dev, "dss1_fck");
> > +               while(1) {
> > +                       clk_enable(c1);
> > +                       clk_enable(c2);
> > +                       clk_disable(c1);
> > +                       clk_disable(c2);
> > +               }
> > +       }
> > +
> >         /* Delay actual initialization until the LCD is registered */
> >         fbdev_pdev = pdev;
> >         if (fbdev_panel != NULL)
> > @@ -1958,7 +1971,7 @@ module_param_named(rotate, def_rotate, uint,
> > 0664);
> >  module_param_named(mirror, def_mirror, uint, 0664);
> >  module_param_named(manual_update, manual_update, bool, 0664);
> >  
> > -module_init(omapfb_init);
> > +late_initcall(omapfb_init);
> >  module_exit(omapfb_cleanup);
> >  
> >  MODULE_DESCRIPTION("TI OMAP framebuffer driver");
> >
> >
> > And the crash:
> >
> >
> >
> > <1>Unhandled fault: external abort on non-linefetch (0x1028) at
> > 0xd8200098
> > Unhandled fault: external abort on non-linefetch (0x1028) at 0xd8200098
> > Internal error: : 1028 [#1]
> > Internal error: : 1028 [#1]
> > Modules linked in:Modules linked in:
> >
> > CPU: 0    Not tainted  (2.6.28-rc6-omap1-05264-g1705711-dirty #6)
> > CPU: 0    Not tainted  (2.6.28-rc6-omap1-05264-g1705711-dirty #6)
> > PC is at __irq_svc+0x34/0x80
> > PC is at __irq_svc+0x34/0x80
> > LR is at _omap2_clk_enable+0xa0/0xe0
> > LR is at _omap2_clk_enable+0xa0/0xe0
> 
> What looks to be happening is an interrupt is firing in the middle of
> your clk_enable() call, and accesses to the Interrupt controller
> registers are triggering a fault.
> 
> As a temporary workaround, could you try wrapping your clk_enable() 
> with an IRQ save/restore?  Something like:
> 
>   local_irq_save(flags);
>   clk_enable(c);
>   local_irq_restore(flags);
> 
> If this works, then we need to investigate in more detail which
> interrupt is firing, and why the INTC registers are not accessible.

No, I get the same error with irq_saves also. However, if I wrap the
whole while loop inside local_irq_save, then it doesn't crash.

So this does crash:

		while(1) {
			local_irq_save(flags);
			clk_enable(c1);
			local_irq_restore(flags);

			local_irq_save(flags);
			clk_disable(c1);
			local_irq_restore(flags);
		}

And this doesn't:

		local_irq_save(flags);
		while(1) {
			clk_enable(c1);
			clk_disable(c1);
		}

 Tomi



^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Bug in linux omap clock framework?
  2008-12-06 23:51 ` Paul Walmsley
@ 2008-12-08  8:59   ` Tomi Valkeinen
  2008-12-08  9:24     ` Paul Walmsley
  2008-12-09  9:15   ` Tomi Valkeinen
  1 sibling, 1 reply; 21+ messages in thread
From: Tomi Valkeinen @ 2008-12-08  8:59 UTC (permalink / raw)
  To: ext Paul Walmsley; +Cc: linux-omap, khilman

On Sat, 2008-12-06 at 16:51 -0700, ext Paul Walmsley wrote:
> Hi Tomi,
> 
> nice test case.
> 
> On Fri, 5 Dec 2008, Tomi.Valkeinen@nokia.com wrote:
> 
> > I have had strange clk_enable() crashes with DSS2, and now I managed to
> > isolate it. With the included patch, on OMAP3 SDP board, with default
> > kernel config, I always get the crash below. In this example case it
> > happens at specific time on boot, but with DSS2 it happens randomly at
> > runtime, when I enable the DSS clocks.
> 
> Looks like there's some problem with the DSS driver's usage of 
> dss_tv_fclk.  Enabling dss_tv_fclk before entering your test code's 
> while-loop makes the problem go away here.  Patch below.

Yes, enabling dss_tv_fclk "fixes" it. Also enabling dss1_alwon_fck fixes
it. (Note that I had a bug in the test code: it's dss1_alwon_fck in
omap3, not dss1_fck =). Funny that I didn't get any error.).

So it's the ick that is causing the crashing.

> 
> As an aside, your test patch does not actually disable dss1_fclk, since it 
> is already enabled by the time the while-loop starts.  So you might also 
> want to add a clk_disable(c2) before your while-loop starts, when you 
> test.

What makes you say that? Who would enable it? And clk_get_count returns
0 for dss_ick, dss1_alwon_fck and dss_tv_fclk.

> 
> Based on the traceback that you sent, I'd conjecture that probably some 
> part of the DSS subsystem is generating an interrupt via DSS_IRQ; but then 
> dss_iclk ends up disabled, and the MPU INTC is not able to communicate 
> with the DSS, and the INTC wedges.  (The aborting access is to 0xd8200098, 
> the INTCPS_PENDING_IRQ0 register, rather than a DSS register.)  Probably 
> some IRQs need to be masked before disabling the dss_iclk.

Okay. So, is this a DSS problem or clock framework problem? I made the
following test module to make testing easier, and to turn off any
interrupts. Crashes with DSS interrupts turned off also (although they
should be off by default).

Disable omapfb from kconfig if you try this.



diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index e39e33e..2da9eab 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -138,3 +138,6 @@ obj-$(CONFIG_FB_VIRTUAL)          += vfb.o
 
 #video output switch sysfs driver
 obj-$(CONFIG_VIDEO_OUTPUT_CONTROL) += output.o
+
+obj-m += test.o
+
diff --git a/drivers/video/test.c b/drivers/video/test.c
new file mode 100644
index 0000000..285658f
--- /dev/null
+++ b/drivers/video/test.c
@@ -0,0 +1,60 @@
+#include <linux/module.h>
+#include <linux/clk.h>
+#include <linux/io.h>
+
+#include <mach/clock.h>
+
+#define DISPC_BASE			0x48050400
+#define DISPC_IRQSTATUS			0x0018
+#define DISPC_IRQENABLE			0x001C
+
+static void __iomem *base;
+
+static void inline dispc_write_reg(int idx, u32 val)
+{
+	__raw_writel(val, base + idx);
+}
+
+static u32 inline dispc_read_reg(int idx)
+{
+	return __raw_readl(base + idx);
+}
+
+static int __init omapfb_init(void)
+{
+	struct clk *c1, *c2, *c3;
+
+	c1 = clk_get(NULL, "dss_ick");
+	c2 = clk_get(NULL, "dss1_alwon_fck");
+	c3 = clk_get(NULL, "dss_tv_fck");
+
+	base = ioremap(DISPC_BASE, SZ_1K);
+	printk("mapped to %p\n", base);
+
+	clk_enable(c1);
+	clk_enable(c2);
+
+	dispc_write_reg(DISPC_IRQENABLE, 0);
+	dispc_write_reg(DISPC_IRQSTATUS, 0);
+
+	clk_disable(c1);
+	clk_disable(c2);
+
+	printk("usecounts %d, %d, %d\n", clk_get_usecount(c1),
+			clk_get_usecount(c2),
+			clk_get_usecount(c3));
+
+	/*clk_enable(c2);*/
+	/*clk_enable(c3);*/
+
+	while(1) {
+		clk_enable(c1);
+		clk_disable(c1);
+	}
+
+	return 0;
+}
+
+module_init(omapfb_init);
+MODULE_LICENSE("GPL");
+




mapped to d8050400
usecounts 0, 0, 0
Unhandled fault: external abort on non-linefetch (0x1028) at 0xd8200098
Internal error: : 1028 [#1]
Modules linked in: test(+)
CPU: 0    Not tainted  (2.6.28-rc6-omap1-05264-g1705711-dirty #27)
PC is at __irq_svc+0x34/0x80
LR is at _omap2_clk_enable+0xa0/0xe0
pc : [<c0029a14>]    lr : [<c0033404>]    psr: 60000193
sp : c7a01de0  ip : c7a01df0  fp : c7a01e3c
r10: bf003000  r9 : 00000000  r8 : c0029f68
r7 : c0364c4c  r6 : c0364aec  r5 : d8200000  r4 : ffffffff
r3 : 60000013  r2 : c0037f78  r1 : c0033404  r0 : c7a01e28
Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 10c5387f  Table: 87930018  DAC: 00000015
Process insmod (pid: 434, stack limit = 0xc7a002e0)
Stack: (0xc7a01de0 to 0xc7a02000)
1de0: 00000000 00000000 00000010 00000001 80000013 00000000 c0364aec c0364c4c 
1e00: c0029f68 00000000 bf003000 c7a01e3c c7a01df0 c7a01e28 c0033404 c0037f78 
1e20: 60000013 ffffffff 00000000 00000000 c7a01e5c c7a01e40 bf0030d0 c0037f40 
1e40: c038a3a0 bf000440 000de220 00000000 c7a01f7c c7a01e60 c0029310 bf00300c 
1e60: c79deaa0 00000001 c8863d68 c885f000 c7a01e8c c7a01e80 c007b6b4 c007b454 
1e80: 00000007 c885f000 c79deaa0 00000001 c7a01ebc c7a01ea0 c008eaf8 c0096ad4 
1ea0: c79b64a0 00000001 bf000440 00000001 c7a01ecc c7a01ec0 c008eb8c c008ea40 
1ec0: c7a01f7c c7a01ed0 c0070704 c008eb58 00000000 c7a01f48 000de068 c8863ed0 
1ee0: c8864268 c8863c22 c79deae0 c88658e0 00000020 00000007 00000000 0000002e 
1f00: 0000002e bf00006c c0037f34 c7a00000 0000002b 00000022 c88642b8 c88642b8 
1f20: c8864290 00000022 00000000 00000000 00000000 00000000 000069b9 c036a548 
1f40: c7a01f6c 000069b9 bf000440 000de220 00000000 000069b9 bf000440 000de220 
1f60: 00000000 c0029f68 c7a00000 00000000 c7a01fa4 c7a01f80 c00708a4 c00292bc 
1f80: ffffffff 03d47e88 00000000 00000000 00000000 00000080 00000000 c7a01fa8 
1fa0: c0029dc0 c0070818 00000000 00000000 000de220 000069b9 000de068 00000000 
1fc0: 00000000 00000000 00000000 00000080 000de038 03d4776c 000db8d8 03d47e84 
1fe0: 03d46ef8 03d46ee8 00021b50 4018aec0 60000010 000de220 00000000 00000000 
Backtrace: 
[<c0037f34>] (clk_enable+0x0/0x54) from [<bf0030d0>] (omapfb_init+0xd0/0xf8 [test])
 r5:00000000 r4:00000000
[<bf003000>] (omapfb_init+0x0/0xf8 [test]) from [<c0029310>] (__exception_text_end+0x60/0x18c)
 r7:00000000 r6:000de220 r5:bf000440 r4:c038a3a0
[<c00292b0>] (__exception_text_end+0x0/0x18c) from [<c00708a4>] (sys_init_module+0x98/0x188)
[<c007080c>] (sys_init_module+0x0/0x188) from [<c0029dc0>] (ret_fast_syscall+0x0/0x2c)
 r7:00000080 r6:00000000 r5:00000000 r4:00000000
Code: e58d1000 e1a0100e e885001f e59f503c (e5950098) 
---[ end trace f89d026fb0e69049 ]---




^ permalink raw reply related	[flat|nested] 21+ messages in thread

* Re: Bug in linux omap clock framework?
  2008-12-08  8:59   ` Tomi Valkeinen
@ 2008-12-08  9:24     ` Paul Walmsley
  2008-12-08  9:36       ` Tomi Valkeinen
  2008-12-09 13:58       ` Tomi Valkeinen
  0 siblings, 2 replies; 21+ messages in thread
From: Paul Walmsley @ 2008-12-08  9:24 UTC (permalink / raw)
  To: Tomi Valkeinen; +Cc: linux-omap, khilman

Hi Tomi,

On Mon, 8 Dec 2008, Tomi Valkeinen wrote:

> On Sat, 2008-12-06 at 16:51 -0700, ext Paul Walmsley wrote:
> > Hi Tomi,
> > 
> > nice test case.
> > 
> > On Fri, 5 Dec 2008, Tomi.Valkeinen@nokia.com wrote:
> > 
> > > I have had strange clk_enable() crashes with DSS2, and now I managed to
> > > isolate it. With the included patch, on OMAP3 SDP board, with default
> > > kernel config, I always get the crash below. In this example case it
> > > happens at specific time on boot, but with DSS2 it happens randomly at
> > > runtime, when I enable the DSS clocks.
> > 
> > Looks like there's some problem with the DSS driver's usage of 
> > dss_tv_fclk.  Enabling dss_tv_fclk before entering your test code's 
> > while-loop makes the problem go away here.  Patch below.
> 
> Yes, enabling dss_tv_fclk "fixes" it. Also enabling dss1_alwon_fck fixes
> it. (Note that I had a bug in the test code: it's dss1_alwon_fck in
> omap3, not dss1_fck =). Funny that I didn't get any error.).

Hmmm, yeah, we should patch the clock code to warn when 
clk_enable()/clk_disable()/etc is passed a NULL pointer, that would help 
quite a bit.

> > As an aside, your test patch does not actually disable dss1_fclk, since it 
> > is already enabled by the time the while-loop starts.  So you might also 
> > want to add a clk_disable(c2) before your while-loop starts, when you 
> > test.
> 
> What makes you say that? Who would enable it? And clk_get_count returns
> 0 for dss_ick, dss1_alwon_fck and dss_tv_fclk.

This was my mistake, I was assuming that dss1_fclk was valid without 
checking it against the clock tree.

> > Based on the traceback that you sent, I'd conjecture that probably some 
> > part of the DSS subsystem is generating an interrupt via DSS_IRQ; but then 
> > dss_iclk ends up disabled, and the MPU INTC is not able to communicate 
> > with the DSS, and the INTC wedges.  (The aborting access is to 0xd8200098, 
> > the INTCPS_PENDING_IRQ0 register, rather than a DSS register.)  Probably 
> > some IRQs need to be masked before disabling the dss_iclk.
> 
> Okay. So, is this a DSS problem or clock framework problem? 

At this point my guess would be that it is a DSS driver problem, but I 
don't think it is clear yet.

> First I made the following test module to make testing easier, and to 
> turn off any interrupts. Crashes with DSS interrupts turned off also 
> (although they should be off by default).
> 
> Disable omapfb from kconfig if you try this.

OK, will try this later on today.


- Paul

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Bug in linux omap clock framework?
  2008-12-08  9:24     ` Paul Walmsley
@ 2008-12-08  9:36       ` Tomi Valkeinen
  2008-12-09 13:58       ` Tomi Valkeinen
  1 sibling, 0 replies; 21+ messages in thread
From: Tomi Valkeinen @ 2008-12-08  9:36 UTC (permalink / raw)
  To: ext Paul Walmsley; +Cc: linux-omap, khilman

On Mon, 2008-12-08 at 02:24 -0700, ext Paul Walmsley wrote:
> Hi Tomi,
> 
> On Mon, 8 Dec 2008, Tomi Valkeinen wrote:
> 
> > On Sat, 2008-12-06 at 16:51 -0700, ext Paul Walmsley wrote:
> 
> > > Based on the traceback that you sent, I'd conjecture that probably some 
> > > part of the DSS subsystem is generating an interrupt via DSS_IRQ; but then 
> > > dss_iclk ends up disabled, and the MPU INTC is not able to communicate 
> > > with the DSS, and the INTC wedges.  (The aborting access is to 0xd8200098, 
> > > the INTCPS_PENDING_IRQ0 register, rather than a DSS register.)  Probably 
> > > some IRQs need to be masked before disabling the dss_iclk.
> > 
> > Okay. So, is this a DSS problem or clock framework problem? 
> 
> At this point my guess would be that it is a DSS driver problem, but I 
> don't think it is clear yet.

Also, after disabling CONFIG_PM the code doesn't crash anymore...
Something is turning powers/clocks off too eagerly?

 Tomi


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Bug in linux omap clock framework?
  2008-12-06 23:51 ` Paul Walmsley
  2008-12-08  8:59   ` Tomi Valkeinen
@ 2008-12-09  9:15   ` Tomi Valkeinen
  1 sibling, 0 replies; 21+ messages in thread
From: Tomi Valkeinen @ 2008-12-09  9:15 UTC (permalink / raw)
  To: ext Paul Walmsley; +Cc: linux-omap, khilman

On Sat, 2008-12-06 at 16:51 -0700, ext Paul Walmsley wrote:
> Hi Tomi,
> 
> nice test case.
> 
> On Fri, 5 Dec 2008, Tomi.Valkeinen@nokia.com wrote:
> 
> > I have had strange clk_enable() crashes with DSS2, and now I managed to
> > isolate it. With the included patch, on OMAP3 SDP board, with default
> > kernel config, I always get the crash below. In this example case it
> > happens at specific time on boot, but with DSS2 it happens randomly at
> > runtime, when I enable the DSS clocks.
> 
> Looks like there's some problem with the DSS driver's usage of 
> dss_tv_fclk.  Enabling dss_tv_fclk before entering your test code's 
> while-loop makes the problem go away here.  Patch below.
> 
> As an aside, your test patch does not actually disable dss1_fclk, since it 
> is already enabled by the time the while-loop starts.  So you might also 
> want to add a clk_disable(c2) before your while-loop starts, when you 
> test.
> 
> Based on the traceback that you sent, I'd conjecture that probably some 
> part of the DSS subsystem is generating an interrupt via DSS_IRQ; but then 
> dss_iclk ends up disabled, and the MPU INTC is not able to communicate 
> with the DSS, and the INTC wedges.  (The aborting access is to 0xd8200098, 
> the INTCPS_PENDING_IRQ0 register, rather than a DSS register.)  Probably 
> some IRQs need to be masked before disabling the dss_iclk.

It doesn't seem to be DSS related, the same crash happens also with
cam_ick and sgx_ick.

 Tomi



^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Bug in linux omap clock framework?
  2008-12-08  9:24     ` Paul Walmsley
  2008-12-08  9:36       ` Tomi Valkeinen
@ 2008-12-09 13:58       ` Tomi Valkeinen
  2008-12-09 23:14         ` Paul Walmsley
                           ` (2 more replies)
  1 sibling, 3 replies; 21+ messages in thread
From: Tomi Valkeinen @ 2008-12-09 13:58 UTC (permalink / raw)
  To: ext Paul Walmsley; +Cc: linux-omap, khilman

Hi,

On Mon, 2008-12-08 at 02:24 -0700, ext Paul Walmsley wrote:
> Hi Tomi,
> 
> On Mon, 8 Dec 2008, Tomi Valkeinen wrote:
> 
> > On Sat, 2008-12-06 at 16:51 -0700, ext Paul Walmsley wrote:
> > > Hi Tomi,
> > > 
> > > nice test case.
> > > 
> > > On Fri, 5 Dec 2008, Tomi.Valkeinen@nokia.com wrote:
> > > 
> > > > I have had strange clk_enable() crashes with DSS2, and now I managed to
> > > > isolate it. With the included patch, on OMAP3 SDP board, with default
> > > > kernel config, I always get the crash below. In this example case it
> > > > happens at specific time on boot, but with DSS2 it happens randomly at
> > > > runtime, when I enable the DSS clocks.
> > > 
> 
> At this point my guess would be that it is a DSS driver problem, but I 
> don't think it is clear yet.
> 

I don't know much about power and clock domains, but I believe I found
the reason and fix for this. At least this should point to the right
direction.

It looks to me that when I do clk_enable() to a clock which is inside a
turned off powerdomain, clk_enable() function will return before the
powerdomain is fully turned on. Reading PM_PWSTST_DSS shows that the
powerdomain is still in transition state.

The following change waits until the powerdomain has finished the
transition. At least it fixed the problem for me, and other things seem
to be still working =).


diff --git a/arch/arm/mach-omap2/clockdomain.c b/arch/arm/mach-omap2/clockdomain.c
index fa62f14..f713d0b 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -567,6 +567,8 @@ int omap2_clkdm_clk_enable(struct clockdomain *clkdm, struct clk *clk)
        else
                omap2_clkdm_wakeup(clkdm);
 
+       pwrdm_wait_transition(clkdm->pwrdm.ptr);
+
        return 0;
 }



^ permalink raw reply related	[flat|nested] 21+ messages in thread

* Re: Bug in linux omap clock framework?
  2008-12-09 13:58       ` Tomi Valkeinen
@ 2008-12-09 23:14         ` Paul Walmsley
  2008-12-10  3:04           ` Igor Stoppa
  2008-12-10  7:37         ` Högander Jouni
  2008-12-11  9:19         ` Högander Jouni
  2 siblings, 1 reply; 21+ messages in thread
From: Paul Walmsley @ 2008-12-09 23:14 UTC (permalink / raw)
  To: Tomi Valkeinen; +Cc: linux-omap, khilman

Hi Tomi,

On Tue, 9 Dec 2008, Tomi Valkeinen wrote:

> I don't know much about power and clock domains, but I believe I found
> the reason and fix for this. At least this should point to the right
> direction.
> 
> It looks to me that when I do clk_enable() to a clock which is inside a
> turned off powerdomain, clk_enable() function will return before the
> powerdomain is fully turned on. Reading PM_PWSTST_DSS shows that the
> powerdomain is still in transition state.
> 
> The following change waits until the powerdomain has finished the
> transition. At least it fixed the problem for me, and other things seem
> to be still working =).

Nice work - this makes sense.  Tested your patch here also. 

Care to put together a patch with something similar to the description 
above and your Signed-off-by, and send it to the list?  This should go 
into l-o.


- Paul


> diff --git a/arch/arm/mach-omap2/clockdomain.c b/arch/arm/mach-omap2/clockdomain.c
> index fa62f14..f713d0b 100644
> --- a/arch/arm/mach-omap2/clockdomain.c
> +++ b/arch/arm/mach-omap2/clockdomain.c
> @@ -567,6 +567,8 @@ int omap2_clkdm_clk_enable(struct clockdomain *clkdm, struct clk *clk)
>         else
>                 omap2_clkdm_wakeup(clkdm);
>  
> +       pwrdm_wait_transition(clkdm->pwrdm.ptr);
> +
>         return 0;
>  }
> 
> 


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Bug in linux omap clock framework?
  2008-12-09 23:14         ` Paul Walmsley
@ 2008-12-10  3:04           ` Igor Stoppa
  2008-12-10  7:02             ` Paul Walmsley
  0 siblings, 1 reply; 21+ messages in thread
From: Igor Stoppa @ 2008-12-10  3:04 UTC (permalink / raw)
  To: ext Paul Walmsley; +Cc: Tomi Valkeinen, linux-omap, khilman

Hi Paul,
On Tue, 2008-12-09 at 16:14 -0700, ext Paul Walmsley wrote:
> Hi Tomi,
> 
> On Tue, 9 Dec 2008, Tomi Valkeinen wrote:
> 
> > I don't know much about power and clock domains, but I believe I found
> > the reason and fix for this. At least this should point to the right
> > direction.
> > 
> > It looks to me that when I do clk_enable() to a clock which is inside a
> > turned off powerdomain, clk_enable() function will return before the
> > powerdomain is fully turned on. Reading PM_PWSTST_DSS shows that the
> > powerdomain is still in transition state.
> > 
> > The following change waits until the powerdomain has finished the
> > transition. At least it fixed the problem for me, and other things seem
> > to be still working =).
> 
> Nice work - this makes sense.  Tested your patch here also. 

Just a thought:
wouldn't this feature be required in basically every similar case?

And if yes, wouldn't it be better to embed it into clk_enable() so that
the driver code doesn't have to address it explicitly and can be more
easily shared across different OMAP architectures?

-- 

Cheers, Igor

---

Igor Stoppa
Maemo Software - Nokia Devices R&D - Helsinki

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Bug in linux omap clock framework?
  2008-12-10  3:04           ` Igor Stoppa
@ 2008-12-10  7:02             ` Paul Walmsley
  0 siblings, 0 replies; 21+ messages in thread
From: Paul Walmsley @ 2008-12-10  7:02 UTC (permalink / raw)
  To: Igor Stoppa; +Cc: Tomi Valkeinen, linux-omap, khilman

Hi Igor,

On Wed, 10 Dec 2008, Igor Stoppa wrote:

> On Tue, 2008-12-09 at 16:14 -0700, ext Paul Walmsley wrote:
> > 
> > On Tue, 9 Dec 2008, Tomi Valkeinen wrote:
> > 
> > > It looks to me that when I do clk_enable() to a clock which is inside a
> > > turned off powerdomain, clk_enable() function will return before the
> > > powerdomain is fully turned on. Reading PM_PWSTST_DSS shows that the
> > > powerdomain is still in transition state.
> > > 
> > > The following change waits until the powerdomain has finished the
> > > transition. At least it fixed the problem for me, and other things seem
> > > to be still working =).
> > 
> > Nice work - this makes sense.  Tested your patch here also. 
> 
> Just a thought:
> wouldn't this feature be required in basically every similar case?
> 
> And if yes, wouldn't it be better to embed it into clk_enable() so that
> the driver code doesn't have to address it explicitly and can be more
> easily shared across different OMAP architectures?

I think Tomi's patch covers all of the similar cases, even though it isn't 
in clock..d directly.  clock.c:omap2_clk_enable() calls 
clockdomain.c:omap2_clkdm_clk_enable() whenever a clock is enabled.  This 
is the function that Tomi's patch changes.  When the number of active 
clocks in a clockdomain goes from 0 to 1, omap2_clkdm_clk_enable() will 
wait until the powerdomain indicates that it has finished its transition 
before continuing.  (The powerdomain may not actually change state at this 
point, but pwrdm_wait_transition() just waits for the "INTRANSITION" bit 
to equal zero, so it should be safe to test even if the powerdomain state 
does not change.)


- Paul

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Bug in linux omap clock framework?
  2008-12-09 13:58       ` Tomi Valkeinen
  2008-12-09 23:14         ` Paul Walmsley
@ 2008-12-10  7:37         ` Högander Jouni
  2008-12-10  7:59           ` Tomi Valkeinen
  2008-12-11  9:19         ` Högander Jouni
  2 siblings, 1 reply; 21+ messages in thread
From: Högander Jouni @ 2008-12-10  7:37 UTC (permalink / raw)
  To: tomi.valkeinen; +Cc: ext Paul Walmsley, linux-omap, khilman

"ext Tomi Valkeinen" <tomi.valkeinen@nokia.com> writes:

> Hi,
>
> On Mon, 2008-12-08 at 02:24 -0700, ext Paul Walmsley wrote:
>> Hi Tomi,
>> 
>> On Mon, 8 Dec 2008, Tomi Valkeinen wrote:
>> 
>> > On Sat, 2008-12-06 at 16:51 -0700, ext Paul Walmsley wrote:
>> > > Hi Tomi,
>> > > 
>> > > nice test case.
>> > > 
>> > > On Fri, 5 Dec 2008, Tomi.Valkeinen@nokia.com wrote:
>> > > 
>> > > > I have had strange clk_enable() crashes with DSS2, and now I managed to
>> > > > isolate it. With the included patch, on OMAP3 SDP board, with default
>> > > > kernel config, I always get the crash below. In this example case it
>> > > > happens at specific time on boot, but with DSS2 it happens randomly at
>> > > > runtime, when I enable the DSS clocks.
>> > > 
>> 
>> At this point my guess would be that it is a DSS driver problem, but I 
>> don't think it is clear yet.
>> 
>
> I don't know much about power and clock domains, but I believe I found
> the reason and fix for this. At least this should point to the right
> direction.
>
> It looks to me that when I do clk_enable() to a clock which is inside a
> turned off powerdomain, clk_enable() function will return before the
> powerdomain is fully turned on. Reading PM_PWSTST_DSS shows that the
> powerdomain is still in transition state.
>
> The following change waits until the powerdomain has finished the
> transition. At least it fixed the problem for me, and other things seem
> to be still working =).
>
>
> diff --git a/arch/arm/mach-omap2/clockdomain.c b/arch/arm/mach-omap2/clockdomain.c
> index fa62f14..f713d0b 100644
> --- a/arch/arm/mach-omap2/clockdomain.c
> +++ b/arch/arm/mach-omap2/clockdomain.c
> @@ -567,6 +567,8 @@ int omap2_clkdm_clk_enable(struct clockdomain *clkdm, struct clk *clk)
>         else
>                 omap2_clkdm_wakeup(clkdm);
>  
> +       pwrdm_wait_transition(clkdm->pwrdm.ptr);
> +

Altough this patch is fixing the problem, I'll guess it's because of
delay it causes rather than waiting for
PM_PWSTST_DSS. omap2_clkdm_clk_enable alone doesn't switch pwrdm to
on. This is because clockdomain/powerdomains are controlled by HW (hw
supervised).

I think the right answer is to use ST_*_IDLE & ST_*_STDBY bits in
omap2_clk_wait_ready.

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

-- 
Jouni Högander

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

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Bug in linux omap clock framework?
  2008-12-10  7:37         ` Högander Jouni
@ 2008-12-10  7:59           ` Tomi Valkeinen
  2008-12-10  8:44             ` Högander Jouni
  0 siblings, 1 reply; 21+ messages in thread
From: Tomi Valkeinen @ 2008-12-10  7:59 UTC (permalink / raw)
  To: Högander Jouni; +Cc: ext Paul Walmsley, linux-omap, khilman

On Wed, 2008-12-10 at 09:37 +0200, Högander Jouni wrote:
> "ext Tomi Valkeinen" <tomi.valkeinen@nokia.com> writes:
> 
> > Hi,
> >
> > On Mon, 2008-12-08 at 02:24 -0700, ext Paul Walmsley wrote:
> >> Hi Tomi,
> >> 
> >> On Mon, 8 Dec 2008, Tomi Valkeinen wrote:
> >> 
> >> > On Sat, 2008-12-06 at 16:51 -0700, ext Paul Walmsley wrote:
> >> > > Hi Tomi,
> >> > > 
> >> > > nice test case.
> >> > > 
> >> > > On Fri, 5 Dec 2008, Tomi.Valkeinen@nokia.com wrote:
> >> > > 
> >> > > > I have had strange clk_enable() crashes with DSS2, and now I managed to
> >> > > > isolate it. With the included patch, on OMAP3 SDP board, with default
> >> > > > kernel config, I always get the crash below. In this example case it
> >> > > > happens at specific time on boot, but with DSS2 it happens randomly at
> >> > > > runtime, when I enable the DSS clocks.
> >> > > 
> >> 
> >> At this point my guess would be that it is a DSS driver problem, but I 
> >> don't think it is clear yet.
> >> 
> >
> > I don't know much about power and clock domains, but I believe I found
> > the reason and fix for this. At least this should point to the right
> > direction.
> >
> > It looks to me that when I do clk_enable() to a clock which is inside a
> > turned off powerdomain, clk_enable() function will return before the
> > powerdomain is fully turned on. Reading PM_PWSTST_DSS shows that the
> > powerdomain is still in transition state.
> >
> > The following change waits until the powerdomain has finished the
> > transition. At least it fixed the problem for me, and other things seem
> > to be still working =).
> >
> >
> > diff --git a/arch/arm/mach-omap2/clockdomain.c b/arch/arm/mach-omap2/clockdomain.c
> > index fa62f14..f713d0b 100644
> > --- a/arch/arm/mach-omap2/clockdomain.c
> > +++ b/arch/arm/mach-omap2/clockdomain.c
> > @@ -567,6 +567,8 @@ int omap2_clkdm_clk_enable(struct clockdomain *clkdm, struct clk *clk)
> >         else
> >                 omap2_clkdm_wakeup(clkdm);
> >  
> > +       pwrdm_wait_transition(clkdm->pwrdm.ptr);
> > +
> 
> Altough this patch is fixing the problem, I'll guess it's because of
> delay it causes rather than waiting for
> PM_PWSTST_DSS. omap2_clkdm_clk_enable alone doesn't switch pwrdm to
> on. This is because clockdomain/powerdomains are controlled by HW (hw
> supervised).
> 
> I think the right answer is to use ST_*_IDLE & ST_*_STDBY bits in
> omap2_clk_wait_ready.

But ST_DSS_IDLE says active only after both interface and functional
clock are on, so it doesn't help here.

Why is it wrong to wait for PM_PWSTST_DSS? Do you mean that this crash
is not caused by the DSS being not powered on, but by something else,
and so the small delay just accidentally fixes the problem?

 Tomi


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

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Bug in linux omap clock framework?
  2008-12-10  7:59           ` Tomi Valkeinen
@ 2008-12-10  8:44             ` Högander Jouni
  2008-12-10  8:57               ` Tomi Valkeinen
  0 siblings, 1 reply; 21+ messages in thread
From: Högander Jouni @ 2008-12-10  8:44 UTC (permalink / raw)
  To: tomi.valkeinen; +Cc: ext Paul Walmsley, linux-omap, khilman

Tomi Valkeinen <tomi.valkeinen@nokia.com> writes:

> On Wed, 2008-12-10 at 09:37 +0200, Högander Jouni wrote:
>> "ext Tomi Valkeinen" <tomi.valkeinen@nokia.com> writes:
>> 
>> > Hi,
>> >
>> > On Mon, 2008-12-08 at 02:24 -0700, ext Paul Walmsley wrote:
>> >> Hi Tomi,
>> >> 
>> >> On Mon, 8 Dec 2008, Tomi Valkeinen wrote:
>> >> 
>> >> > On Sat, 2008-12-06 at 16:51 -0700, ext Paul Walmsley wrote:
>> >> > > Hi Tomi,
>> >> > > 
>> >> > > nice test case.
>> >> > > 
>> >> > > On Fri, 5 Dec 2008, Tomi.Valkeinen@nokia.com wrote:
>> >> > > 
>> >> > > > I have had strange clk_enable() crashes with DSS2, and now I managed to
>> >> > > > isolate it. With the included patch, on OMAP3 SDP board, with default
>> >> > > > kernel config, I always get the crash below. In this example case it
>> >> > > > happens at specific time on boot, but with DSS2 it happens randomly at
>> >> > > > runtime, when I enable the DSS clocks.
>> >> > > 
>> >> 
>> >> At this point my guess would be that it is a DSS driver problem, but I 
>> >> don't think it is clear yet.
>> >> 
>> >
>> > I don't know much about power and clock domains, but I believe I found
>> > the reason and fix for this. At least this should point to the right
>> > direction.
>> >
>> > It looks to me that when I do clk_enable() to a clock which is inside a
>> > turned off powerdomain, clk_enable() function will return before the
>> > powerdomain is fully turned on. Reading PM_PWSTST_DSS shows that the
>> > powerdomain is still in transition state.
>> >
>> > The following change waits until the powerdomain has finished the
>> > transition. At least it fixed the problem for me, and other things seem
>> > to be still working =).
>> >
>> >
>> > diff --git a/arch/arm/mach-omap2/clockdomain.c b/arch/arm/mach-omap2/clockdomain.c
>> > index fa62f14..f713d0b 100644
>> > --- a/arch/arm/mach-omap2/clockdomain.c
>> > +++ b/arch/arm/mach-omap2/clockdomain.c
>> > @@ -567,6 +567,8 @@ int omap2_clkdm_clk_enable(struct clockdomain *clkdm, struct clk *clk)
>> >         else
>> >                 omap2_clkdm_wakeup(clkdm);
>> >  
>> > +       pwrdm_wait_transition(clkdm->pwrdm.ptr);
>> > +
>> 
>> Altough this patch is fixing the problem, I'll guess it's because of
>> delay it causes rather than waiting for
>> PM_PWSTST_DSS. omap2_clkdm_clk_enable alone doesn't switch pwrdm to
>> on. This is because clockdomain/powerdomains are controlled by HW (hw
>> supervised).
>> 
>> I think the right answer is to use ST_*_IDLE & ST_*_STDBY bits in
>> omap2_clk_wait_ready.
>
> But ST_DSS_IDLE says active only after both interface and functional
> clock are on, so it doesn't help here.

Yes and in ST_DSS_IDLE description it is saying that if it's "0x1
Display sub-system is in idle mode and cannot be accessed". So it only
way to get it out of idle is to enable both clocks it needs to be done.

If you look at arch/arm/mach-omap2/clock.c:omap2_clk_wait_ready it is
actually checking that both clocks are enabled.

>
> Why is it wrong to wait for PM_PWSTST_DSS? Do you mean that this crash
> is not caused by the DSS being not powered on, but by something else,
> and so the small delay just accidentally fixes the problem?

Something like that.

If you look at your code:

+static int __init omapfb_init(void)
+{
+	struct clk *c1, *c2, *c3;
+
+	c1 = clk_get(NULL, "dss_ick");
+	c2 = clk_get(NULL, "dss1_alwon_fck");
+	c3 = clk_get(NULL, "dss_tv_fck");
+
+	base = ioremap(DISPC_BASE, SZ_1K);
+	printk("mapped to %p\n", base);
+
+	clk_enable(c1);

At this point ST_DSS_IDLE should not be yet checked (because fck is
not enabled yet.

+	clk_enable(c2);

But at this point (actually inside clk_enable and
omap2_clk_wait_ready) ST_DSS_IDLE should be checked before those
register accesses in next two lines. You can verify my comment by
adding "while(ST_DSS_IDLE);" here.

+
+	dispc_write_reg(DISPC_IRQENABLE, 0);
+	dispc_write_reg(DISPC_IRQSTATUS, 0);
+
+	clk_disable(c1);
+	clk_disable(c2);
+
+	printk("usecounts %d, %d, %d\n", clk_get_usecount(c1),
+			clk_get_usecount(c2),
+			clk_get_usecount(c3));
+
+	/*clk_enable(c2);*/
+	/*clk_enable(c3);*/
+
+	while(1) {
+		clk_enable(c1);
+		clk_disable(c1);
+	}
+
+	return 0;
+}
+
+module_init(omapfb_init);
+MODULE_LICENSE("GPL");
>  Tomi
>
>

-- 
Jouni Högander

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

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Bug in linux omap clock framework?
  2008-12-10  8:44             ` Högander Jouni
@ 2008-12-10  8:57               ` Tomi Valkeinen
  2008-12-10 10:44                 ` Högander Jouni
  0 siblings, 1 reply; 21+ messages in thread
From: Tomi Valkeinen @ 2008-12-10  8:57 UTC (permalink / raw)
  To: Högander Jouni; +Cc: ext Paul Walmsley, linux-omap, khilman

On Wed, 2008-12-10 at 10:44 +0200, Högander Jouni wrote:
> Tomi Valkeinen <tomi.valkeinen@nokia.com> writes:
> 
> > On Wed, 2008-12-10 at 09:37 +0200, Högander Jouni wrote:
> >> "ext Tomi Valkeinen" <tomi.valkeinen@nokia.com> writes:
> >> 
> >> > Hi,
> >> >
> >> > On Mon, 2008-12-08 at 02:24 -0700, ext Paul Walmsley wrote:
> >> >> Hi Tomi,
> >> >> 
> >> >> On Mon, 8 Dec 2008, Tomi Valkeinen wrote:
> >> >> 
> >> >> > On Sat, 2008-12-06 at 16:51 -0700, ext Paul Walmsley wrote:
> >> >> > > Hi Tomi,
> >> >> > > 
> >> >> > > nice test case.
> >> >> > > 
> >> >> > > On Fri, 5 Dec 2008, Tomi.Valkeinen@nokia.com wrote:
> >> >> > > 
> >> >> > > > I have had strange clk_enable() crashes with DSS2, and now I managed to
> >> >> > > > isolate it. With the included patch, on OMAP3 SDP board, with default
> >> >> > > > kernel config, I always get the crash below. In this example case it
> >> >> > > > happens at specific time on boot, but with DSS2 it happens randomly at
> >> >> > > > runtime, when I enable the DSS clocks.
> >> >> > > 
> >> >> 
> >> >> At this point my guess would be that it is a DSS driver problem, but I 
> >> >> don't think it is clear yet.
> >> >> 
> >> >
> >> > I don't know much about power and clock domains, but I believe I found
> >> > the reason and fix for this. At least this should point to the right
> >> > direction.
> >> >
> >> > It looks to me that when I do clk_enable() to a clock which is inside a
> >> > turned off powerdomain, clk_enable() function will return before the
> >> > powerdomain is fully turned on. Reading PM_PWSTST_DSS shows that the
> >> > powerdomain is still in transition state.
> >> >
> >> > The following change waits until the powerdomain has finished the
> >> > transition. At least it fixed the problem for me, and other things seem
> >> > to be still working =).
> >> >
> >> >
> >> > diff --git a/arch/arm/mach-omap2/clockdomain.c b/arch/arm/mach-omap2/clockdomain.c
> >> > index fa62f14..f713d0b 100644
> >> > --- a/arch/arm/mach-omap2/clockdomain.c
> >> > +++ b/arch/arm/mach-omap2/clockdomain.c
> >> > @@ -567,6 +567,8 @@ int omap2_clkdm_clk_enable(struct clockdomain *clkdm, struct clk *clk)
> >> >         else
> >> >                 omap2_clkdm_wakeup(clkdm);
> >> >  
> >> > +       pwrdm_wait_transition(clkdm->pwrdm.ptr);
> >> > +
> >> 
> >> Altough this patch is fixing the problem, I'll guess it's because of
> >> delay it causes rather than waiting for
> >> PM_PWSTST_DSS. omap2_clkdm_clk_enable alone doesn't switch pwrdm to
> >> on. This is because clockdomain/powerdomains are controlled by HW (hw
> >> supervised).
> >> 
> >> I think the right answer is to use ST_*_IDLE & ST_*_STDBY bits in
> >> omap2_clk_wait_ready.
> >
> > But ST_DSS_IDLE says active only after both interface and functional
> > clock are on, so it doesn't help here.
> 
> Yes and in ST_DSS_IDLE description it is saying that if it's "0x1
> Display sub-system is in idle mode and cannot be accessed". So it only
> way to get it out of idle is to enable both clocks it needs to be done.
> 
> If you look at arch/arm/mach-omap2/clock.c:omap2_clk_wait_ready it is
> actually checking that both clocks are enabled.

But the ST_DSS_IDLE doesn't help here. The kernel crashes after enabling
dss_ick, before your code can even enable dss_fck. The same happens if
you do it other way around, first dss_fck and then dss_ick.

> > Why is it wrong to wait for PM_PWSTST_DSS? Do you mean that this crash
> > is not caused by the DSS being not powered on, but by something else,
> > and so the small delay just accidentally fixes the problem?
> 
> Something like that.
> 
> If you look at your code:
> 
> +static int __init omapfb_init(void)
> +{
> +	struct clk *c1, *c2, *c3;
> +
> +	c1 = clk_get(NULL, "dss_ick");
> +	c2 = clk_get(NULL, "dss1_alwon_fck");
> +	c3 = clk_get(NULL, "dss_tv_fck");
> +
> +	base = ioremap(DISPC_BASE, SZ_1K);
> +	printk("mapped to %p\n", base);
> +
> +	clk_enable(c1);
> 
> At this point ST_DSS_IDLE should not be yet checked (because fck is
> not enabled yet.
> 
> +	clk_enable(c2);
> 
> But at this point (actually inside clk_enable and
> omap2_clk_wait_ready) ST_DSS_IDLE should be checked before those
> register accesses in next two lines. You can verify my comment by
> adding "while(ST_DSS_IDLE);" here.

Doesn't omap2_clk_wait_ready alread check this?

And again, the problem is not accessing DSS registers. The problem is
that clk_enable(dss_ick) crashes. so the following code crashes also:

static int __init test_init(void)
{
	struct clk *c1 = clk_get(NULL, "dss_ick");

	while(1) {
		clk_enable(c1);
		clk_disable(c1);
	}

	return 0;
}


> 
> +
> +	dispc_write_reg(DISPC_IRQENABLE, 0);
> +	dispc_write_reg(DISPC_IRQSTATUS, 0);
> +
> +	clk_disable(c1);
> +	clk_disable(c2);
> +
> +	printk("usecounts %d, %d, %d\n", clk_get_usecount(c1),
> +			clk_get_usecount(c2),
> +			clk_get_usecount(c3));
> +
> +	/*clk_enable(c2);*/
> +	/*clk_enable(c3);*/
> +
> +	while(1) {
> +		clk_enable(c1);
> +		clk_disable(c1);
> +	}
> +
> +	return 0;
> +}
> +
> +module_init(omapfb_init);
> +MODULE_LICENSE("GPL");
> >  Tomi
> >
> >
> 

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

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Bug in linux omap clock framework?
  2008-12-10  8:57               ` Tomi Valkeinen
@ 2008-12-10 10:44                 ` Högander Jouni
  2008-12-10 11:53                   ` Tomi Valkeinen
  0 siblings, 1 reply; 21+ messages in thread
From: Högander Jouni @ 2008-12-10 10:44 UTC (permalink / raw)
  To: tomi.valkeinen; +Cc: ext Paul Walmsley, linux-omap, khilman

Tomi Valkeinen <tomi.valkeinen@nokia.com> writes:

> On Wed, 2008-12-10 at 10:44 +0200, Högander Jouni wrote:
>> Tomi Valkeinen <tomi.valkeinen@nokia.com> writes:
>> 
>> > On Wed, 2008-12-10 at 09:37 +0200, Högander Jouni wrote:
>> >> "ext Tomi Valkeinen" <tomi.valkeinen@nokia.com> writes:
>> >> 
>> >> > Hi,
>> >> >
>> >> > On Mon, 2008-12-08 at 02:24 -0700, ext Paul Walmsley wrote:
>> >> >> Hi Tomi,
>> >> >> 
>> >> >> On Mon, 8 Dec 2008, Tomi Valkeinen wrote:
>> >> >> 
>> >> >> > On Sat, 2008-12-06 at 16:51 -0700, ext Paul Walmsley wrote:
>> >> >> > > Hi Tomi,
>> >> >> > > 
>> >> >> > > nice test case.
>> >> >> > > 
>> >> >> > > On Fri, 5 Dec 2008, Tomi.Valkeinen@nokia.com wrote:
>> >> >> > > 
>> >> >> > > > I have had strange clk_enable() crashes with DSS2, and now I managed to
>> >> >> > > > isolate it. With the included patch, on OMAP3 SDP board, with default
>> >> >> > > > kernel config, I always get the crash below. In this example case it
>> >> >> > > > happens at specific time on boot, but with DSS2 it happens randomly at
>> >> >> > > > runtime, when I enable the DSS clocks.
>> >> >> > > 
>> >> >> 
>> >> >> At this point my guess would be that it is a DSS driver problem, but I 
>> >> >> don't think it is clear yet.
>> >> >> 
>> >> >
>> >> > I don't know much about power and clock domains, but I believe I found
>> >> > the reason and fix for this. At least this should point to the right
>> >> > direction.
>> >> >
>> >> > It looks to me that when I do clk_enable() to a clock which is inside a
>> >> > turned off powerdomain, clk_enable() function will return before the
>> >> > powerdomain is fully turned on. Reading PM_PWSTST_DSS shows that the
>> >> > powerdomain is still in transition state.
>> >> >
>> >> > The following change waits until the powerdomain has finished the
>> >> > transition. At least it fixed the problem for me, and other things seem
>> >> > to be still working =).
>> >> >
>> >> >
>> >> > diff --git a/arch/arm/mach-omap2/clockdomain.c b/arch/arm/mach-omap2/clockdomain.c
>> >> > index fa62f14..f713d0b 100644
>> >> > --- a/arch/arm/mach-omap2/clockdomain.c
>> >> > +++ b/arch/arm/mach-omap2/clockdomain.c
>> >> > @@ -567,6 +567,8 @@ int omap2_clkdm_clk_enable(struct clockdomain *clkdm, struct clk *clk)
>> >> >         else
>> >> >                 omap2_clkdm_wakeup(clkdm);
>> >> >  
>> >> > +       pwrdm_wait_transition(clkdm->pwrdm.ptr);
>> >> > +
>> >> 
>> >> Altough this patch is fixing the problem, I'll guess it's because of
>> >> delay it causes rather than waiting for
>> >> PM_PWSTST_DSS. omap2_clkdm_clk_enable alone doesn't switch pwrdm to
>> >> on. This is because clockdomain/powerdomains are controlled by HW (hw
>> >> supervised).
>> >> 
>> >> I think the right answer is to use ST_*_IDLE & ST_*_STDBY bits in
>> >> omap2_clk_wait_ready.
>> >
>> > But ST_DSS_IDLE says active only after both interface and functional
>> > clock are on, so it doesn't help here.
>> 
>> Yes and in ST_DSS_IDLE description it is saying that if it's "0x1
>> Display sub-system is in idle mode and cannot be accessed". So it only
>> way to get it out of idle is to enable both clocks it needs to be done.
>> 
>> If you look at arch/arm/mach-omap2/clock.c:omap2_clk_wait_ready it is
>> actually checking that both clocks are enabled.
>
> But the ST_DSS_IDLE doesn't help here. The kernel crashes after enabling
> dss_ick, before your code can even enable dss_fck. The same happens if
> you do it other way around, first dss_fck and then dss_ick.
>
>> > Why is it wrong to wait for PM_PWSTST_DSS? Do you mean that this crash
>> > is not caused by the DSS being not powered on, but by something else,
>> > and so the small delay just accidentally fixes the problem?
>> 
>> Something like that.
>> 
>> If you look at your code:
>> 
>> +static int __init omapfb_init(void)
>> +{
>> +	struct clk *c1, *c2, *c3;
>> +
>> +	c1 = clk_get(NULL, "dss_ick");
>> +	c2 = clk_get(NULL, "dss1_alwon_fck");
>> +	c3 = clk_get(NULL, "dss_tv_fck");
>> +
>> +	base = ioremap(DISPC_BASE, SZ_1K);
>> +	printk("mapped to %p\n", base);
>> +
>> +	clk_enable(c1);
>> 
>> At this point ST_DSS_IDLE should not be yet checked (because fck is
>> not enabled yet.
>> 
>> +	clk_enable(c2);
>> 
>> But at this point (actually inside clk_enable and
>> omap2_clk_wait_ready) ST_DSS_IDLE should be checked before those
>> register accesses in next two lines. You can verify my comment by
>> adding "while(ST_DSS_IDLE);" here.
>
> Doesn't omap2_clk_wait_ready alread check this?

Yes, you are right this is already done.

>
> And again, the problem is not accessing DSS registers. The problem is
> that clk_enable(dss_ick) crashes. so the following code crashes also:
>
> static int __init test_init(void)
> {
> 	struct clk *c1 = clk_get(NULL, "dss_ick");
>
> 	while(1) {
> 		clk_enable(c1);
> 		clk_disable(c1);
> 	}
>
> 	return 0;
> }
>

Are you still using SDP and default config + latest linux-omap? I'm
not able to reproduce this using your example code.

>
>> 
>> +
>> +	dispc_write_reg(DISPC_IRQENABLE, 0);
>> +	dispc_write_reg(DISPC_IRQSTATUS, 0);
>> +
>> +	clk_disable(c1);
>> +	clk_disable(c2);
>> +
>> +	printk("usecounts %d, %d, %d\n", clk_get_usecount(c1),
>> +			clk_get_usecount(c2),
>> +			clk_get_usecount(c3));
>> +
>> +	/*clk_enable(c2);*/
>> +	/*clk_enable(c3);*/
>> +
>> +	while(1) {
>> +		clk_enable(c1);
>> +		clk_disable(c1);
>> +	}
>> +
>> +	return 0;
>> +}
>> +
>> +module_init(omapfb_init);
>> +MODULE_LICENSE("GPL");
>> >  Tomi
>> >
>> >
>> 
>

-- 
Jouni Högander

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

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Bug in linux omap clock framework?
  2008-12-10 10:44                 ` Högander Jouni
@ 2008-12-10 11:53                   ` Tomi Valkeinen
  0 siblings, 0 replies; 21+ messages in thread
From: Tomi Valkeinen @ 2008-12-10 11:53 UTC (permalink / raw)
  To: Högander Jouni; +Cc: ext Paul Walmsley, linux-omap, khilman

[-- Attachment #1: Type: text/plain, Size: 1982 bytes --]

On Wed, 2008-12-10 at 12:44 +0200, Högander Jouni wrote:
> Tomi Valkeinen <tomi.valkeinen@nokia.com> writes:

[snip]

> >
> > And again, the problem is not accessing DSS registers. The problem is
> > that clk_enable(dss_ick) crashes. so the following code crashes also:
> >
> > static int __init test_init(void)
> > {
> > 	struct clk *c1 = clk_get(NULL, "dss_ick");
> >
> > 	while(1) {
> > 		clk_enable(c1);
> > 		clk_disable(c1);
> > 	}
> >
> > 	return 0;
> > }
> >
> 
> Are you still using SDP and default config + latest linux-omap? I'm
> not able to reproduce this using your example code.

Yes. But you have to disable omapfb, so that it doesn't enable the
clocks.

Just in case, here's attached my .config, and below is a patch I've
used. It compiles in to kernel, and crashes almost immediately at boot
time.



>From ba19fccb3ac04f9f8c22b42a55ac932f6dc5a99a Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen <tomi.valkeinen@nokia.com>
Date: Mon, 8 Dec 2008 11:15:12 +0200
Subject: [PATCH] DSS clk bug testing

---
 drivers/video/Makefile |    3 +++
 drivers/video/test.c   |   20 ++++++++++++++++++++
 2 files changed, 23 insertions(+), 0 deletions(-)
 create mode 100644 drivers/video/test.c

diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index e39e33e..17611d9 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -138,3 +138,6 @@ obj-$(CONFIG_FB_VIRTUAL)          += vfb.o
 
 #video output switch sysfs driver
 obj-$(CONFIG_VIDEO_OUTPUT_CONTROL) += output.o
+
+obj-y += test.o
+
diff --git a/drivers/video/test.c b/drivers/video/test.c
new file mode 100644
index 0000000..8c9241b
--- /dev/null
+++ b/drivers/video/test.c
@@ -0,0 +1,20 @@
+#include <linux/module.h>
+#include <linux/clk.h>
+
+#include <mach/clock.h>
+
+static int __init test_init(void)
+{
+	struct clk *c1 = clk_get(NULL, "dss_ick");
+
+	while(1) {
+		clk_enable(c1);
+		clk_disable(c1);
+	}
+
+	return 0;
+}
+
+late_initcall(test_init);
+MODULE_LICENSE("GPL");
+
-- 
1.6.0.3



[-- Attachment #2: .config --]
[-- Type: text/plain, Size: 36900 bytes --]

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.28-rc7-omap1
# Wed Dec 10 13:44:45 2008
#
CONFIG_ARM=y
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
CONFIG_GENERIC_GPIO=y
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_MMU=y
# CONFIG_NO_IOPORT is not set
CONFIG_GENERIC_HARDIRQS=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
# CONFIG_ARCH_HAS_ILOG2_U32 is not set
# CONFIG_ARCH_HAS_ILOG2_U64 is not set
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y
CONFIG_VECTORS_BASE=0xffff0000
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
# CONFIG_TASKSTATS is not set
# CONFIG_AUDIT is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=14
# CONFIG_CGROUPS is not set
CONFIG_GROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
# CONFIG_RT_GROUP_SCHED is not set
CONFIG_USER_SCHED=y
# CONFIG_CGROUP_SCHED is not set
CONFIG_SYSFS_DEPRECATED=y
CONFIG_SYSFS_DEPRECATED_V2=y
# CONFIG_RELAY is not set
# CONFIG_NAMESPACES is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
CONFIG_EMBEDDED=y
CONFIG_UID16=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
CONFIG_KALLSYMS_EXTRA_PASS=y
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_COMPAT_BRK=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_SLOB is not set
# CONFIG_PROFILING is not set
# CONFIG_MARKERS is not set
CONFIG_HAVE_OPROFILE=y
# CONFIG_KPROBES is not set
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_CLK=y
CONFIG_HAVE_GENERIC_DMA_COHERENT=y
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
# CONFIG_MODULE_FORCE_LOAD is not set
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_MODVERSIONS=y
CONFIG_MODULE_SRCVERSION_ALL=y
CONFIG_KMOD=y
CONFIG_BLOCK=y
# CONFIG_LBD is not set
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_LSF is not set
# CONFIG_BLK_DEV_BSG is not set
# CONFIG_BLK_DEV_INTEGRITY is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
CONFIG_DEFAULT_AS=y
# CONFIG_DEFAULT_DEADLINE is not set
# CONFIG_DEFAULT_CFQ is not set
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="anticipatory"
CONFIG_CLASSIC_RCU=y
CONFIG_FREEZER=y

#
# System Type
#
# CONFIG_ARCH_AAEC2000 is not set
# CONFIG_ARCH_INTEGRATOR is not set
# CONFIG_ARCH_REALVIEW is not set
# CONFIG_ARCH_VERSATILE is not set
# CONFIG_ARCH_AT91 is not set
# CONFIG_ARCH_CLPS7500 is not set
# CONFIG_ARCH_CLPS711X is not set
# CONFIG_ARCH_EBSA110 is not set
# CONFIG_ARCH_EP93XX is not set
# CONFIG_ARCH_FOOTBRIDGE is not set
# CONFIG_ARCH_NETX is not set
# CONFIG_ARCH_H720X is not set
# CONFIG_ARCH_IMX is not set
# CONFIG_ARCH_IOP13XX is not set
# CONFIG_ARCH_IOP32X is not set
# CONFIG_ARCH_IOP33X is not set
# CONFIG_ARCH_IXP23XX is not set
# CONFIG_ARCH_IXP2000 is not set
# CONFIG_ARCH_IXP4XX is not set
# CONFIG_ARCH_L7200 is not set
# CONFIG_ARCH_KIRKWOOD is not set
# CONFIG_ARCH_KS8695 is not set
# CONFIG_ARCH_NS9XXX is not set
# CONFIG_ARCH_LOKI is not set
# CONFIG_ARCH_MV78XX0 is not set
# CONFIG_ARCH_MXC is not set
# CONFIG_ARCH_ORION5X is not set
# CONFIG_ARCH_PNX4008 is not set
# CONFIG_ARCH_PXA is not set
# CONFIG_ARCH_RPC is not set
# CONFIG_ARCH_SA1100 is not set
# CONFIG_ARCH_S3C2410 is not set
# CONFIG_ARCH_SHARK is not set
# CONFIG_ARCH_LH7A40X is not set
# CONFIG_ARCH_DAVINCI is not set
CONFIG_ARCH_OMAP=y
# CONFIG_ARCH_MSM is not set

#
# TI OMAP Implementations
#
CONFIG_ARCH_OMAP_OTG=y
# CONFIG_ARCH_OMAP1 is not set
# CONFIG_ARCH_OMAP2 is not set
CONFIG_ARCH_OMAP3=y

#
# OMAP Feature Selections
#
# CONFIG_OMAP_DEBUG_POWERDOMAIN is not set
# CONFIG_OMAP_DEBUG_CLOCKDOMAIN is not set
CONFIG_OMAP_SMARTREFLEX=y
# CONFIG_OMAP_SMARTREFLEX_TESTING is not set
CONFIG_OMAP_RESET_CLOCKS=y
CONFIG_OMAP_BOOT_TAG=y
CONFIG_OMAP_BOOT_REASON=y
# CONFIG_OMAP_COMPONENT_VERSION is not set
# CONFIG_OMAP_GPIO_SWITCH is not set
CONFIG_OMAP_MUX=y
CONFIG_OMAP_MUX_DEBUG=y
CONFIG_OMAP_MUX_WARNINGS=y
# CONFIG_OMAP_MCBSP is not set
# CONFIG_OMAP_MMU_FWK is not set
# CONFIG_OMAP_MBOX_FWK is not set
# CONFIG_OMAP_MPU_TIMER is not set
CONFIG_OMAP_32K_TIMER=y
CONFIG_OMAP_32K_TIMER_HZ=128
CONFIG_OMAP_DM_TIMER=y
CONFIG_OMAP_LL_DEBUG_UART1=y
# CONFIG_OMAP_LL_DEBUG_UART2 is not set
# CONFIG_OMAP_LL_DEBUG_UART3 is not set
CONFIG_OMAP_SERIAL_WAKE=y
CONFIG_ARCH_OMAP34XX=y
CONFIG_ARCH_OMAP3430=y

#
# OMAP Board Type
#
# CONFIG_MACH_OMAP_LDP is not set
CONFIG_MACH_OMAP_3430SDP=y
# CONFIG_MACH_OMAP3EVM is not set
# CONFIG_MACH_OMAP3_BEAGLE is not set
# CONFIG_MACH_OVERO is not set
# CONFIG_MACH_OMAP3_PANDORA is not set
CONFIG_OMAP_TICK_GPTIMER=1

#
# Boot options
#

#
# Power management
#

#
# Processor Type
#
CONFIG_CPU_32=y
CONFIG_CPU_32v6K=y
CONFIG_CPU_V7=y
CONFIG_CPU_32v7=y
CONFIG_CPU_ABRT_EV7=y
CONFIG_CPU_PABRT_IFAR=y
CONFIG_CPU_CACHE_V7=y
CONFIG_CPU_CACHE_VIPT=y
CONFIG_CPU_COPY_V6=y
CONFIG_CPU_TLB_V7=y
CONFIG_CPU_HAS_ASID=y
CONFIG_CPU_CP15=y
CONFIG_CPU_CP15_MMU=y

#
# Processor Features
#
CONFIG_ARM_THUMB=y
# CONFIG_ARM_THUMBEE is not set
# CONFIG_CPU_ICACHE_DISABLE is not set
# CONFIG_CPU_DCACHE_DISABLE is not set
# CONFIG_CPU_BPREDICT_DISABLE is not set
CONFIG_HAS_TLS_REG=y
# CONFIG_OUTER_CACHE is not set

#
# Bus support
#
# CONFIG_PCI_SYSCALL is not set
# CONFIG_ARCH_SUPPORTS_MSI is not set
# CONFIG_PCCARD is not set

#
# Kernel Features
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_VMSPLIT_3G=y
# CONFIG_VMSPLIT_2G is not set
# CONFIG_VMSPLIT_1G is not set
CONFIG_PAGE_OFFSET=0xC0000000
# CONFIG_PREEMPT is not set
CONFIG_HZ=128
CONFIG_AEABI=y
CONFIG_OABI_COMPAT=y
CONFIG_ARCH_FLATMEM_HAS_HOLES=y
# CONFIG_ARCH_SPARSEMEM_DEFAULT is not set
# CONFIG_ARCH_SELECT_MEMORY_MODEL is not set
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=4
# CONFIG_RESOURCES_64BIT is not set
# CONFIG_PHYS_ADDR_T_64BIT is not set
CONFIG_ZONE_DMA_FLAG=0
CONFIG_VIRT_TO_BUS=y
CONFIG_UNEVICTABLE_LRU=y
# CONFIG_LEDS is not set
CONFIG_ALIGNMENT_TRAP=y

#
# Boot options
#
CONFIG_ZBOOT_ROM_TEXT=0x0
CONFIG_ZBOOT_ROM_BSS=0x0
CONFIG_CMDLINE="root=/dev/nfs nfsroot=192.168.0.1:/home/user/buildroot ip=192.168.0.2:192.168.0.1:192.168.0.1:255.255.255.0:tgt:eth0:off rw console=ttyS2,115200n8"
# CONFIG_XIP_KERNEL is not set
# CONFIG_KEXEC is not set

#
# CPU Power Management
#
# CONFIG_CPU_FREQ is not set
# CONFIG_CPU_IDLE is not set

#
# Floating point emulation
#

#
# At least one emulation must be selected
#
CONFIG_FPE_NWFPE=y
# CONFIG_FPE_NWFPE_XP is not set
# CONFIG_FPE_FASTFPE is not set
CONFIG_VFP=y
CONFIG_VFPv3=y
# CONFIG_NEON is not set

#
# Userspace binary formats
#
CONFIG_BINFMT_ELF=y
# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
CONFIG_HAVE_AOUT=y
# CONFIG_BINFMT_AOUT is not set
CONFIG_BINFMT_MISC=y

#
# Power management options
#
CONFIG_PM=y
# CONFIG_PM_DEBUG is not set
CONFIG_PM_SLEEP=y
CONFIG_SUSPEND=y
CONFIG_SUSPEND_FREEZER=y
# CONFIG_APM_EMULATION is not set
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
CONFIG_UNIX=y
CONFIG_XFRM=y
# CONFIG_XFRM_USER is not set
# CONFIG_XFRM_SUB_POLICY is not set
# CONFIG_XFRM_MIGRATE is not set
# CONFIG_XFRM_STATISTICS is not set
CONFIG_NET_KEY=y
# CONFIG_NET_KEY_MIGRATE is not set
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_FIB_HASH=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_IP_PNP_BOOTP=y
CONFIG_IP_PNP_RARP=y
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_ARPD is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_XFRM_TUNNEL is not set
# CONFIG_INET_TUNNEL is not set
CONFIG_INET_XFRM_MODE_TRANSPORT=y
CONFIG_INET_XFRM_MODE_TUNNEL=y
CONFIG_INET_XFRM_MODE_BEET=y
# CONFIG_INET_LRO is not set
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set
# CONFIG_IPV6 is not set
# CONFIG_NETWORK_SECMARK is not set
# CONFIG_NETFILTER is not set
# CONFIG_IP_DCCP is not set
# CONFIG_IP_SCTP is not set
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_BRIDGE is not set
# CONFIG_NET_DSA is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_SCHED is not set

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_CAN is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_AF_RXRPC is not set
# CONFIG_PHONET is not set
CONFIG_WIRELESS=y
# CONFIG_CFG80211 is not set
CONFIG_WIRELESS_OLD_REGULATORY=y
# CONFIG_WIRELESS_EXT is not set
# CONFIG_MAC80211 is not set
# CONFIG_IEEE80211 is not set
# CONFIG_RFKILL is not set
# CONFIG_NET_9P is not set

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
# CONFIG_FW_LOADER is not set
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_CONNECTOR is not set
CONFIG_MTD=y
# CONFIG_MTD_DEBUG is not set
CONFIG_MTD_CONCAT=y
CONFIG_MTD_PARTITIONS=y
# CONFIG_MTD_REDBOOT_PARTS is not set
CONFIG_MTD_CMDLINE_PARTS=y
# CONFIG_MTD_AFS_PARTS is not set
# CONFIG_MTD_AR7_PARTS is not set

#
# User Modules And Translation Layers
#
CONFIG_MTD_CHAR=y
CONFIG_MTD_BLKDEVS=y
CONFIG_MTD_BLOCK=y
# CONFIG_FTL is not set
# CONFIG_NFTL is not set
# CONFIG_INFTL is not set
# CONFIG_RFD_FTL is not set
# CONFIG_SSFDC is not set
# CONFIG_MTD_OOPS is not set

#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=y
# CONFIG_MTD_JEDECPROBE is not set
CONFIG_MTD_GEN_PROBE=y
# CONFIG_MTD_CFI_ADV_OPTIONS is not set
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
# CONFIG_MTD_CFI_I4 is not set
# CONFIG_MTD_CFI_I8 is not set
CONFIG_MTD_CFI_INTELEXT=y
# CONFIG_MTD_CFI_AMDSTD is not set
# CONFIG_MTD_CFI_STAA is not set
CONFIG_MTD_CFI_UTIL=y
# CONFIG_MTD_RAM is not set
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set

#
# Mapping drivers for chip access
#
# CONFIG_MTD_COMPLEX_MAPPINGS is not set
# CONFIG_MTD_PHYSMAP is not set
# CONFIG_MTD_ARM_INTEGRATOR is not set
CONFIG_MTD_OMAP_NOR=y
# CONFIG_MTD_PLATRAM is not set

#
# Self-contained MTD device drivers
#
# CONFIG_MTD_DATAFLASH is not set
# CONFIG_MTD_M25P80 is not set
# CONFIG_MTD_SLRAM is not set
# CONFIG_MTD_PHRAM is not set
# CONFIG_MTD_MTDRAM is not set
# CONFIG_MTD_BLOCK2MTD is not set

#
# Disk-On-Chip Device Drivers
#
# CONFIG_MTD_DOC2000 is not set
# CONFIG_MTD_DOC2001 is not set
# CONFIG_MTD_DOC2001PLUS is not set
CONFIG_MTD_NAND=y
# CONFIG_MTD_NAND_VERIFY_WRITE is not set
CONFIG_MTD_NAND_ECC_SMC=y
# CONFIG_MTD_NAND_MUSEUM_IDS is not set
# CONFIG_MTD_NAND_GPIO is not set
CONFIG_MTD_NAND_OMAP2=y
CONFIG_MTD_NAND_IDS=y
# CONFIG_MTD_NAND_DISKONCHIP is not set
# CONFIG_MTD_NAND_NANDSIM is not set
# CONFIG_MTD_NAND_PLATFORM is not set
# CONFIG_MTD_ALAUDA is not set
CONFIG_MTD_ONENAND=y
CONFIG_MTD_ONENAND_VERIFY_WRITE=y
# CONFIG_MTD_ONENAND_GENERIC is not set
CONFIG_MTD_ONENAND_OMAP2=y
# CONFIG_MTD_ONENAND_OTP is not set
# CONFIG_MTD_ONENAND_2X_PROGRAM is not set
# CONFIG_MTD_ONENAND_SIM is not set

#
# UBI - Unsorted block images
#
# CONFIG_MTD_UBI is not set
# CONFIG_PARPORT is not set
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_UB is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=16384
# CONFIG_BLK_DEV_XIP is not set
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
CONFIG_MISC_DEVICES=y
# CONFIG_EEPROM_93CX6 is not set
# CONFIG_ICS932S401 is not set
# CONFIG_OMAP_STI is not set
# CONFIG_ENCLOSURE_SERVICES is not set
# CONFIG_C2PORT is not set
CONFIG_HAVE_IDE=y
# CONFIG_IDE is not set

#
# SCSI device support
#
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
# CONFIG_SCSI_TGT is not set
# CONFIG_SCSI_NETLINK is not set
CONFIG_SCSI_PROC_FS=y

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
# CONFIG_BLK_DEV_SR is not set
# CONFIG_CHR_DEV_SG is not set
# CONFIG_CHR_DEV_SCH is not set

#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
# CONFIG_SCSI_MULTI_LUN is not set
# CONFIG_SCSI_CONSTANTS is not set
# CONFIG_SCSI_LOGGING is not set
# CONFIG_SCSI_SCAN_ASYNC is not set
CONFIG_SCSI_WAIT_SCAN=m

#
# SCSI Transports
#
# CONFIG_SCSI_SPI_ATTRS is not set
# CONFIG_SCSI_FC_ATTRS is not set
# CONFIG_SCSI_ISCSI_ATTRS is not set
# CONFIG_SCSI_SAS_LIBSAS is not set
# CONFIG_SCSI_SRP_ATTRS is not set
CONFIG_SCSI_LOWLEVEL=y
# CONFIG_ISCSI_TCP is not set
# CONFIG_SCSI_DEBUG is not set
# CONFIG_SCSI_DH is not set
# CONFIG_ATA is not set
# CONFIG_MD is not set
CONFIG_NETDEVICES=y
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_MACVLAN is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
# CONFIG_VETH is not set
# CONFIG_PHYLIB is not set
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
# CONFIG_AX88796 is not set
CONFIG_SMC91X=y
# CONFIG_DM9000 is not set
# CONFIG_ENC28J60 is not set
# CONFIG_SMC911X is not set
# CONFIG_IBM_NEW_EMAC_ZMII is not set
# CONFIG_IBM_NEW_EMAC_RGMII is not set
# CONFIG_IBM_NEW_EMAC_TAH is not set
# CONFIG_IBM_NEW_EMAC_EMAC4 is not set
# CONFIG_IBM_NEW_EMAC_NO_FLOW_CTRL is not set
# CONFIG_IBM_NEW_EMAC_MAL_CLR_ICINTSTAT is not set
# CONFIG_IBM_NEW_EMAC_MAL_COMMON_ERR is not set
# CONFIG_B44 is not set
CONFIG_NETDEV_1000=y
CONFIG_NETDEV_10000=y

#
# Wireless LAN
#
# CONFIG_WLAN_PRE80211 is not set
# CONFIG_WLAN_80211 is not set
# CONFIG_IWLWIFI_LEDS is not set

#
# USB Network Adapters
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_USBNET is not set
# CONFIG_WAN is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_ISDN is not set

#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set
# CONFIG_INPUT_POLLDEV is not set

#
# Userland interfaces
#
# CONFIG_INPUT_MOUSEDEV is not set
# CONFIG_INPUT_JOYDEV is not set
CONFIG_INPUT_EVDEV=y
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
# CONFIG_KEYBOARD_ATKBD is not set
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_KEYBOARD_STOWAWAY is not set
CONFIG_KEYBOARD_TWL4030=y
# CONFIG_KEYBOARD_LM8323 is not set
# CONFIG_KEYBOARD_GPIO is not set
# CONFIG_INPUT_MOUSE is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TABLET is not set
CONFIG_INPUT_TOUCHSCREEN=y
CONFIG_TOUCHSCREEN_ADS7846=y
# CONFIG_TOUCHSCREEN_FUJITSU is not set
# CONFIG_TOUCHSCREEN_GUNZE is not set
# CONFIG_TOUCHSCREEN_ELO is not set
# CONFIG_TOUCHSCREEN_MTOUCH is not set
# CONFIG_TOUCHSCREEN_INEXIO is not set
# CONFIG_TOUCHSCREEN_MK712 is not set
# CONFIG_TOUCHSCREEN_PENMOUNT is not set
# CONFIG_TOUCHSCREEN_TOUCHRIGHT is not set
# CONFIG_TOUCHSCREEN_TOUCHWIN is not set
# CONFIG_TOUCHSCREEN_TSC2005 is not set
# CONFIG_TOUCHSCREEN_TSC210X is not set
# CONFIG_TOUCHSCREEN_USB_COMPOSITE is not set
# CONFIG_TOUCHSCREEN_TOUCHIT213 is not set
# CONFIG_INPUT_MISC is not set

#
# Hardware I/O ports
#
# CONFIG_SERIO is not set
# CONFIG_GAMEPORT is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_VT_HW_CONSOLE_BINDING is not set
CONFIG_DEVKMEM=y
# CONFIG_SERIAL_NONSTANDARD is not set

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_NR_UARTS=32
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
CONFIG_SERIAL_8250_DETECT_IRQ=y
CONFIG_SERIAL_8250_RSA=y

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_UNIX98_PTYS=y
# CONFIG_LEGACY_PTYS is not set
# CONFIG_IPMI_HANDLER is not set
CONFIG_HW_RANDOM=y
# CONFIG_NVRAM is not set
# CONFIG_R3964 is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_TCG_TPM is not set
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_CHARDEV=y
CONFIG_I2C_HELPER_AUTO=y

#
# I2C Hardware Bus support
#

#
# I2C system bus drivers (mostly embedded / system-on-chip)
#
# CONFIG_I2C_GPIO is not set
# CONFIG_I2C_OCORES is not set
CONFIG_I2C_OMAP=y
# CONFIG_I2C_SIMTEC is not set

#
# External I2C/SMBus adapter drivers
#
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_TAOS_EVM is not set
# CONFIG_I2C_TINY_USB is not set

#
# Other I2C/SMBus bus drivers
#
# CONFIG_I2C_PCA_PLATFORM is not set
# CONFIG_I2C_STUB is not set

#
# Miscellaneous I2C Chip support
#
# CONFIG_DS1682 is not set
# CONFIG_AT24 is not set
# CONFIG_SENSORS_EEPROM is not set
# CONFIG_SENSORS_PCF8574 is not set
# CONFIG_PCF8575 is not set
# CONFIG_SENSORS_PCA9539 is not set
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_ISP1301_OMAP is not set
# CONFIG_TPS65010 is not set
# CONFIG_TWL4030_MADC is not set
CONFIG_TWL4030_USB=y
# CONFIG_TWL4030_PWRBUTTON is not set
# CONFIG_TWL4030_POWEROFF is not set
# CONFIG_SENSORS_MAX6875 is not set
# CONFIG_SENSORS_TSL2550 is not set
# CONFIG_LP5521 is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set
CONFIG_SPI=y
# CONFIG_SPI_DEBUG is not set
CONFIG_SPI_MASTER=y

#
# SPI Master Controller Drivers
#
# CONFIG_SPI_BITBANG is not set
CONFIG_SPI_OMAP24XX=y

#
# SPI Protocol Masters
#
# CONFIG_SPI_AT25 is not set
# CONFIG_SPI_TSC210X is not set
# CONFIG_SPI_TSC2301 is not set
# CONFIG_SPI_SPIDEV is not set
# CONFIG_SPI_TLE62X0 is not set
CONFIG_ARCH_REQUIRE_GPIOLIB=y
CONFIG_GPIOLIB=y
# CONFIG_DEBUG_GPIO is not set
# CONFIG_GPIO_SYSFS is not set

#
# Memory mapped GPIO expanders:
#

#
# I2C GPIO expanders:
#
# CONFIG_GPIO_MAX732X is not set
# CONFIG_GPIO_PCA953X is not set
# CONFIG_GPIO_PCF857X is not set
CONFIG_GPIO_TWL4030=y

#
# PCI GPIO expanders:
#

#
# SPI GPIO expanders:
#
# CONFIG_GPIO_MAX7301 is not set
# CONFIG_GPIO_MCP23S08 is not set
# CONFIG_W1 is not set
# CONFIG_POWER_SUPPLY is not set
# CONFIG_HWMON is not set
# CONFIG_THERMAL is not set
# CONFIG_THERMAL_HWMON is not set
CONFIG_WATCHDOG=y
CONFIG_WATCHDOG_NOWAYOUT=y

#
# Watchdog Device Drivers
#
# CONFIG_SOFT_WATCHDOG is not set
CONFIG_OMAP_WATCHDOG=y

#
# USB-based Watchdog Cards
#
# CONFIG_USBPCWATCHDOG is not set
CONFIG_SSB_POSSIBLE=y

#
# Sonics Silicon Backplane
#
# CONFIG_SSB is not set

#
# Multifunction device drivers
#
# CONFIG_MFD_CORE is not set
# CONFIG_MFD_SM501 is not set
# CONFIG_MFD_ASIC3 is not set
# CONFIG_HTC_EGPIO is not set
# CONFIG_HTC_PASIC3 is not set
CONFIG_TWL4030_CORE=y
# CONFIG_TWL4030_POWER is not set
# CONFIG_MFD_TMIO is not set
# CONFIG_MFD_T7L66XB is not set
# CONFIG_MFD_TC6387XB is not set
# CONFIG_MFD_TC6393XB is not set
# CONFIG_PMIC_DA903X is not set
# CONFIG_MFD_WM8400 is not set
# CONFIG_MFD_WM8350_I2C is not set

#
# Multimedia devices
#

#
# Multimedia core support
#
# CONFIG_VIDEO_DEV is not set
# CONFIG_DVB_CORE is not set
# CONFIG_VIDEO_MEDIA is not set

#
# Multimedia drivers
#
CONFIG_DAB=y
# CONFIG_USB_DABUSB is not set

#
# Graphics support
#
# CONFIG_VGASTATE is not set
CONFIG_VIDEO_OUTPUT_CONTROL=m
# CONFIG_FB is not set
# CONFIG_FB_OMAP_LCD_VGA is not set
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set

#
# Display device support
#
# CONFIG_DISPLAY_SUPPORT is not set

#
# Console display driver support
#
# CONFIG_VGA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y
# CONFIG_SOUND is not set
CONFIG_HID_SUPPORT=y
CONFIG_HID=y
# CONFIG_HID_DEBUG is not set
# CONFIG_HIDRAW is not set

#
# USB Input Devices
#
CONFIG_USB_HID=y
# CONFIG_HID_PID is not set
# CONFIG_USB_HIDDEV is not set

#
# Special HID drivers
#
CONFIG_HID_COMPAT=y
CONFIG_HID_A4TECH=y
CONFIG_HID_APPLE=y
CONFIG_HID_BELKIN=y
CONFIG_HID_BRIGHT=y
CONFIG_HID_CHERRY=y
CONFIG_HID_CHICONY=y
CONFIG_HID_CYPRESS=y
CONFIG_HID_DELL=y
CONFIG_HID_EZKEY=y
CONFIG_HID_GYRATION=y
CONFIG_HID_LOGITECH=y
# CONFIG_LOGITECH_FF is not set
# CONFIG_LOGIRUMBLEPAD2_FF is not set
CONFIG_HID_MICROSOFT=y
CONFIG_HID_MONTEREY=y
CONFIG_HID_PANTHERLORD=y
# CONFIG_PANTHERLORD_FF is not set
CONFIG_HID_PETALYNX=y
CONFIG_HID_SAMSUNG=y
CONFIG_HID_SONY=y
CONFIG_HID_SUNPLUS=y
# CONFIG_THRUSTMASTER_FF is not set
# CONFIG_ZEROPLUS_FF is not set
CONFIG_USB_SUPPORT=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB=y
CONFIG_USB_DEBUG=y
CONFIG_USB_ANNOUNCE_NEW_DEVICES=y

#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
# CONFIG_USB_DEVICE_CLASS is not set
# CONFIG_USB_DYNAMIC_MINORS is not set
CONFIG_USB_SUSPEND=y
CONFIG_USB_OTG=y
# CONFIG_USB_OTG_WHITELIST is not set
# CONFIG_USB_OTG_BLACKLIST_HUB is not set
CONFIG_USB_MON=y
# CONFIG_USB_WUSB is not set
# CONFIG_USB_WUSB_CBAF is not set

#
# USB Host Controller Drivers
#
# CONFIG_USB_C67X00_HCD is not set
CONFIG_USB_EHCI_HCD=m
CONFIG_OMAP_EHCI_PHY_MODE=y
# CONFIG_OMAP_EHCI_TLL_MODE is not set
# CONFIG_USB_EHCI_ROOT_HUB_TT is not set
# CONFIG_USB_EHCI_TT_NEWSCHED is not set
# CONFIG_USB_ISP116X_HCD is not set
# CONFIG_USB_OHCI_HCD is not set
# CONFIG_USB_SL811_HCD is not set
# CONFIG_USB_R8A66597_HCD is not set
# CONFIG_USB_HWA_HCD is not set
CONFIG_USB_MUSB_HDRC=y
CONFIG_USB_MUSB_SOC=y

#
# OMAP 343x high speed USB support
#
# CONFIG_USB_MUSB_HOST is not set
# CONFIG_USB_MUSB_PERIPHERAL is not set
CONFIG_USB_MUSB_OTG=y
CONFIG_USB_GADGET_MUSB_HDRC=y
CONFIG_USB_MUSB_HDRC_HCD=y
# CONFIG_MUSB_PIO_ONLY is not set
CONFIG_USB_INVENTRA_DMA=y
# CONFIG_USB_TI_CPPI_DMA is not set
# CONFIG_USB_MUSB_DEBUG is not set

#
# USB Device Class drivers
#
# CONFIG_USB_ACM is not set
# CONFIG_USB_PRINTER is not set
# CONFIG_USB_WDM is not set
# CONFIG_USB_TMC is not set

#
# NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may also be needed;
#

#
# see USB_STORAGE Help for more information
#
CONFIG_USB_STORAGE=y
CONFIG_USB_STORAGE_DEBUG=y
# CONFIG_USB_STORAGE_DATAFAB is not set
# CONFIG_USB_STORAGE_FREECOM is not set
# CONFIG_USB_STORAGE_ISD200 is not set
# CONFIG_USB_STORAGE_DPCM is not set
# CONFIG_USB_STORAGE_USBAT is not set
# CONFIG_USB_STORAGE_SDDR09 is not set
# CONFIG_USB_STORAGE_SDDR55 is not set
# CONFIG_USB_STORAGE_JUMPSHOT is not set
# CONFIG_USB_STORAGE_ALAUDA is not set
# CONFIG_USB_STORAGE_ONETOUCH is not set
# CONFIG_USB_STORAGE_KARMA is not set
# CONFIG_USB_STORAGE_CYPRESS_ATACB is not set
# CONFIG_USB_LIBUSUAL is not set

#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set

#
# USB port drivers
#
# CONFIG_USB_SERIAL is not set

#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_ADUTUX is not set
# CONFIG_USB_SEVSEG is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_BERRY_CHARGE is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYPRESS_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_PHIDGET is not set
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_FTDI_ELAN is not set
# CONFIG_USB_APPLEDISPLAY is not set
# CONFIG_USB_SISUSBVGA is not set
# CONFIG_USB_LD is not set
# CONFIG_USB_TRANCEVIBRATOR is not set
# CONFIG_USB_IOWARRIOR is not set
CONFIG_USB_TEST=y
# CONFIG_USB_ISIGHTFW is not set
# CONFIG_USB_VST is not set
CONFIG_USB_GADGET=y
CONFIG_USB_GADGET_DEBUG=y
CONFIG_USB_GADGET_DEBUG_FILES=y
CONFIG_USB_GADGET_VBUS_DRAW=2
CONFIG_USB_GADGET_SELECTED=y
# CONFIG_USB_GADGET_AT91 is not set
# CONFIG_USB_GADGET_ATMEL_USBA is not set
# CONFIG_USB_GADGET_FSL_USB2 is not set
# CONFIG_USB_GADGET_LH7A40X is not set
# CONFIG_USB_GADGET_OMAP is not set
# CONFIG_USB_GADGET_PXA25X is not set
# CONFIG_USB_GADGET_PXA27X is not set
# CONFIG_USB_GADGET_S3C2410 is not set
# CONFIG_USB_GADGET_M66592 is not set
# CONFIG_USB_GADGET_AMD5536UDC is not set
# CONFIG_USB_GADGET_FSL_QE is not set
# CONFIG_USB_GADGET_NET2280 is not set
# CONFIG_USB_GADGET_GOKU is not set
# CONFIG_USB_GADGET_DUMMY_HCD is not set
CONFIG_USB_GADGET_DUALSPEED=y
CONFIG_USB_ZERO=m
# CONFIG_USB_ZERO_HNPTEST is not set
# CONFIG_USB_ETH is not set
# CONFIG_USB_GADGETFS is not set
# CONFIG_USB_FILE_STORAGE is not set
# CONFIG_USB_G_SERIAL is not set
# CONFIG_USB_MIDI_GADGET is not set
# CONFIG_USB_G_PRINTER is not set
# CONFIG_USB_CDC_COMPOSITE is not set
CONFIG_MMC=y
# CONFIG_MMC_DEBUG is not set
# CONFIG_MMC_UNSAFE_RESUME is not set

#
# MMC/SD/SDIO Card Drivers
#
CONFIG_MMC_BLOCK=y
CONFIG_MMC_BLOCK_BOUNCE=y
# CONFIG_SDIO_UART is not set
# CONFIG_MMC_TEST is not set

#
# MMC/SD/SDIO Host Controller Drivers
#
# CONFIG_MMC_SDHCI is not set
CONFIG_MMC_OMAP_HS=m
# CONFIG_MMC_SPI is not set
# CONFIG_MEMSTICK is not set
# CONFIG_ACCESSIBILITY is not set
# CONFIG_NEW_LEDS is not set
CONFIG_RTC_LIB=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
# CONFIG_RTC_DEBUG is not set

#
# RTC interfaces
#
CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_INTF_PROC=y
CONFIG_RTC_INTF_DEV=y
# CONFIG_RTC_INTF_DEV_UIE_EMUL is not set
# CONFIG_RTC_DRV_TEST is not set

#
# I2C RTC drivers
#
# CONFIG_RTC_DRV_DS1307 is not set
# CONFIG_RTC_DRV_DS1374 is not set
# CONFIG_RTC_DRV_DS1672 is not set
# CONFIG_RTC_DRV_MAX6900 is not set
# CONFIG_RTC_DRV_RS5C372 is not set
# CONFIG_RTC_DRV_ISL1208 is not set
# CONFIG_RTC_DRV_X1205 is not set
# CONFIG_RTC_DRV_PCF8563 is not set
# CONFIG_RTC_DRV_PCF8583 is not set
# CONFIG_RTC_DRV_M41T80 is not set
CONFIG_RTC_DRV_TWL4030=y
# CONFIG_RTC_DRV_S35390A is not set
# CONFIG_RTC_DRV_FM3130 is not set
# CONFIG_RTC_DRV_RX8581 is not set

#
# SPI RTC drivers
#
# CONFIG_RTC_DRV_M41T94 is not set
# CONFIG_RTC_DRV_DS1305 is not set
# CONFIG_RTC_DRV_DS1390 is not set
# CONFIG_RTC_DRV_MAX6902 is not set
# CONFIG_RTC_DRV_R9701 is not set
# CONFIG_RTC_DRV_RS5C348 is not set
# CONFIG_RTC_DRV_DS3234 is not set

#
# Platform RTC drivers
#
# CONFIG_RTC_DRV_CMOS is not set
# CONFIG_RTC_DRV_DS1286 is not set
# CONFIG_RTC_DRV_DS1511 is not set
# CONFIG_RTC_DRV_DS1553 is not set
# CONFIG_RTC_DRV_DS1742 is not set
# CONFIG_RTC_DRV_STK17TA8 is not set
# CONFIG_RTC_DRV_M48T86 is not set
# CONFIG_RTC_DRV_M48T35 is not set
# CONFIG_RTC_DRV_M48T59 is not set
# CONFIG_RTC_DRV_BQ4802 is not set
# CONFIG_RTC_DRV_V3020 is not set

#
# on-CPU RTC drivers
#
# CONFIG_DMADEVICES is not set
# CONFIG_REGULATOR is not set
# CONFIG_UIO is not set

#
# CBUS support
#
# CONFIG_CBUS is not set

#
# File systems
#
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=y
# CONFIG_EXT3_FS_XATTR is not set
# CONFIG_EXT4_FS is not set
CONFIG_JBD=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_FS_POSIX_ACL is not set
CONFIG_FILE_LOCKING=y
# CONFIG_XFS_FS is not set
# CONFIG_OCFS2_FS is not set
CONFIG_DNOTIFY=y
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y
CONFIG_QUOTA=y
# CONFIG_QUOTA_NETLINK_INTERFACE is not set
CONFIG_PRINT_QUOTA_WARNING=y
# CONFIG_QFMT_V1 is not set
CONFIG_QFMT_V2=y
CONFIG_QUOTACTL=y
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set
# CONFIG_FUSE_FS is not set

#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_TMPFS_POSIX_ACL is not set
# CONFIG_HUGETLB_PAGE is not set
# CONFIG_CONFIGFS_FS is not set

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
CONFIG_JFFS2_FS=y
CONFIG_JFFS2_FS_DEBUG=0
CONFIG_JFFS2_FS_WRITEBUFFER=y
# CONFIG_JFFS2_FS_WBUF_VERIFY is not set
# CONFIG_JFFS2_SUMMARY is not set
# CONFIG_JFFS2_FS_XATTR is not set
CONFIG_JFFS2_COMPRESSION_OPTIONS=y
CONFIG_JFFS2_ZLIB=y
# CONFIG_JFFS2_LZO is not set
CONFIG_JFFS2_RTIME=y
# CONFIG_JFFS2_RUBIN is not set
# CONFIG_JFFS2_CMODE_NONE is not set
CONFIG_JFFS2_CMODE_PRIORITY=y
# CONFIG_JFFS2_CMODE_SIZE is not set
# CONFIG_JFFS2_CMODE_FAVOURLZO is not set
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_OMFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
# CONFIG_NFS_V3_ACL is not set
CONFIG_NFS_V4=y
CONFIG_ROOT_NFS=y
# CONFIG_NFSD is not set
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
CONFIG_SUNRPC_GSS=y
# CONFIG_SUNRPC_REGISTER_V4 is not set
CONFIG_RPCSEC_GSS_KRB5=y
# CONFIG_RPCSEC_GSS_SPKM3 is not set
# CONFIG_SMB_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
# CONFIG_MAC_PARTITION is not set
CONFIG_MSDOS_PARTITION=y
# CONFIG_BSD_DISKLABEL is not set
# CONFIG_MINIX_SUBPARTITION is not set
# CONFIG_SOLARIS_X86_PARTITION is not set
# CONFIG_UNIXWARE_DISKLABEL is not set
# CONFIG_LDM_PARTITION is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
# CONFIG_KARMA_PARTITION is not set
# CONFIG_EFI_PARTITION is not set
# CONFIG_SYSV68_PARTITION is not set
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=y
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_UTF8 is not set
# CONFIG_DLM is not set

#
# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
CONFIG_ENABLE_WARN_DEPRECATED=y
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=1024
CONFIG_MAGIC_SYSRQ=y
# CONFIG_UNUSED_SYMBOLS is not set
# CONFIG_DEBUG_FS is not set
# CONFIG_HEADERS_CHECK is not set
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
CONFIG_DETECT_SOFTLOCKUP=y
# CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0
CONFIG_SCHED_DEBUG=y
# CONFIG_SCHEDSTATS is not set
# CONFIG_TIMER_STATS is not set
# CONFIG_DEBUG_OBJECTS is not set
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
# CONFIG_DEBUG_SPINLOCK is not set
CONFIG_DEBUG_MUTEXES=y
# CONFIG_DEBUG_LOCK_ALLOC is not set
# CONFIG_PROVE_LOCKING is not set
# CONFIG_LOCK_STAT is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
# CONFIG_DEBUG_KOBJECT is not set
# CONFIG_DEBUG_BUGVERBOSE is not set
CONFIG_DEBUG_INFO=y
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_WRITECOUNT is not set
# CONFIG_DEBUG_MEMORY_INIT is not set
# CONFIG_DEBUG_LIST is not set
# CONFIG_DEBUG_SG is not set
CONFIG_FRAME_POINTER=y
# CONFIG_BOOT_PRINTK_DELAY is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_RCU_CPU_STALL_DETECTOR is not set
# CONFIG_BACKTRACE_SELF_TEST is not set
# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
# CONFIG_FAULT_INJECTION is not set
# CONFIG_LATENCYTOP is not set
CONFIG_HAVE_FUNCTION_TRACER=y

#
# Tracers
#
# CONFIG_FUNCTION_TRACER is not set
# CONFIG_IRQSOFF_TRACER is not set
# CONFIG_SCHED_TRACER is not set
# CONFIG_CONTEXT_SWITCH_TRACER is not set
# CONFIG_BOOT_TRACER is not set
# CONFIG_STACK_TRACER is not set
# CONFIG_DYNAMIC_PRINTK_DEBUG is not set
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
# CONFIG_KGDB is not set
# CONFIG_DEBUG_USER is not set
# CONFIG_DEBUG_ERRORS is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_LL is not set

#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set
# CONFIG_SECURITYFS is not set
# CONFIG_SECURITY_FILE_CAPABILITIES is not set
CONFIG_CRYPTO=y

#
# Crypto core or helper
#
# CONFIG_CRYPTO_FIPS is not set
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_AEAD=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_RNG=y
CONFIG_CRYPTO_MANAGER=y
# CONFIG_CRYPTO_GF128MUL is not set
# CONFIG_CRYPTO_NULL is not set
# CONFIG_CRYPTO_CRYPTD is not set
# CONFIG_CRYPTO_AUTHENC is not set
# CONFIG_CRYPTO_TEST is not set

#
# Authenticated Encryption with Associated Data
#
# CONFIG_CRYPTO_CCM is not set
# CONFIG_CRYPTO_GCM is not set
# CONFIG_CRYPTO_SEQIV is not set

#
# Block modes
#
CONFIG_CRYPTO_CBC=y
# CONFIG_CRYPTO_CTR is not set
# CONFIG_CRYPTO_CTS is not set
CONFIG_CRYPTO_ECB=m
# CONFIG_CRYPTO_LRW is not set
CONFIG_CRYPTO_PCBC=m
# CONFIG_CRYPTO_XTS is not set

#
# Hash modes
#
# CONFIG_CRYPTO_HMAC is not set
# CONFIG_CRYPTO_XCBC is not set

#
# Digest
#
# CONFIG_CRYPTO_CRC32C is not set
# CONFIG_CRYPTO_MD4 is not set
CONFIG_CRYPTO_MD5=y
# CONFIG_CRYPTO_MICHAEL_MIC is not set
# CONFIG_CRYPTO_RMD128 is not set
# CONFIG_CRYPTO_RMD160 is not set
# CONFIG_CRYPTO_RMD256 is not set
# CONFIG_CRYPTO_RMD320 is not set
# CONFIG_CRYPTO_SHA1 is not set
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_WP512 is not set

#
# Ciphers
#
# CONFIG_CRYPTO_AES is not set
# CONFIG_CRYPTO_ANUBIS is not set
# CONFIG_CRYPTO_ARC4 is not set
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
CONFIG_CRYPTO_DES=y
# CONFIG_CRYPTO_FCRYPT is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_SALSA20 is not set
# CONFIG_CRYPTO_SEED is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_TWOFISH is not set

#
# Compression
#
# CONFIG_CRYPTO_DEFLATE is not set
# CONFIG_CRYPTO_LZO is not set

#
# Random Number Generation
#
# CONFIG_CRYPTO_ANSI_CPRNG is not set
CONFIG_CRYPTO_HW=y

#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_CRC_CCITT=y
# CONFIG_CRC16 is not set
# CONFIG_CRC_T10DIF is not set
# CONFIG_CRC_ITU_T is not set
CONFIG_CRC32=y
# CONFIG_CRC7 is not set
CONFIG_LIBCRC32C=y
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_PLIST=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y

^ permalink raw reply related	[flat|nested] 21+ messages in thread

* Re: Bug in linux omap clock framework?
  2008-12-09 13:58       ` Tomi Valkeinen
  2008-12-09 23:14         ` Paul Walmsley
  2008-12-10  7:37         ` Högander Jouni
@ 2008-12-11  9:19         ` Högander Jouni
  2008-12-11 16:17           ` Paul Walmsley
  2 siblings, 1 reply; 21+ messages in thread
From: Högander Jouni @ 2008-12-11  9:19 UTC (permalink / raw)
  To: tomi.valkeinen; +Cc: ext Paul Walmsley, linux-omap, khilman

"ext Tomi Valkeinen" <tomi.valkeinen@nokia.com> writes:

> Hi,
>
> On Mon, 2008-12-08 at 02:24 -0700, ext Paul Walmsley wrote:
>> Hi Tomi,
>> 
>> On Mon, 8 Dec 2008, Tomi Valkeinen wrote:
>> 
>> > On Sat, 2008-12-06 at 16:51 -0700, ext Paul Walmsley wrote:
>> > > Hi Tomi,
>> > > 
>> > > nice test case.
>> > > 
>> > > On Fri, 5 Dec 2008, Tomi.Valkeinen@nokia.com wrote:
>> > > 
>> > > > I have had strange clk_enable() crashes with DSS2, and now I managed to
>> > > > isolate it. With the included patch, on OMAP3 SDP board, with default
>> > > > kernel config, I always get the crash below. In this example case it
>> > > > happens at specific time on boot, but with DSS2 it happens randomly at
>> > > > runtime, when I enable the DSS clocks.
>> > > 
>> 
>> At this point my guess would be that it is a DSS driver problem, but I 
>> don't think it is clear yet.
>> 
>
> I don't know much about power and clock domains, but I believe I found
> the reason and fix for this. At least this should point to the right
> direction.
>
> It looks to me that when I do clk_enable() to a clock which is inside a
> turned off powerdomain, clk_enable() function will return before the
> powerdomain is fully turned on. Reading PM_PWSTST_DSS shows that the
> powerdomain is still in transition state.

I debugged this a bit and I think patch written by Tomi is partly
fixing this issue. It seems to be related to accessing cm_*
registers while there is transition ongoing in pwrdm_*. I
changed test_init to emulate what ckfw is currently doing:

static int __init test_init(void)
{
	struct clk *c1 = clk_get(NULL, "dss_ick");

	while(1) {
/* 		clk_enable(c1); */
/* 		clk_disable(c1); */

                /* Add sleep and wkdeps */
                omap_writel(0x2, 0x48004e44);
                omap_writel(0x2, 0x48306ec8);

                /* Enable dss_ick */
		omap_writel(0x1, 0x48004e10);

                /* disable dss_ick */
		omap_writel(0x0, 0x48004e10);

                /* Remove sleep and wkdeps */
		omap_writel(0x0, 0x48004e44);
		omap_writel(0x0, 0x48306ec8);
	}
	return 0;
}

This code crashes, but if I remove sleep/wkdep addition/removel from
the code it doesn't. It doesn't crash either if I add
"while((omap_readl(0x48306ee4)&0x100000));" after sleep/wkdep
addition/removel.

So it seems that cm_* register should not be written while there is
powerstate transition ongoing in * domain. Patch by Tomi is fixing
this. As it seems to be transition related rather than pwrdm state,
same line should be added into omap2_clkdm_clk_disable also.

>
> The following change waits until the powerdomain has finished the
> transition. At least it fixed the problem for me, and other things seem
> to be still working =).
>
>
> diff --git a/arch/arm/mach-omap2/clockdomain.c b/arch/arm/mach-omap2/clockdomain.c
> index fa62f14..f713d0b 100644
> --- a/arch/arm/mach-omap2/clockdomain.c
> +++ b/arch/arm/mach-omap2/clockdomain.c
> @@ -567,6 +567,8 @@ int omap2_clkdm_clk_enable(struct clockdomain *clkdm, struct clk *clk)
>         else
>                 omap2_clkdm_wakeup(clkdm);
>  
> +       pwrdm_wait_transition(clkdm->pwrdm.ptr);
> +
>         return 0;
>  }
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Jouni Högander

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

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Bug in linux omap clock framework?
  2008-12-11  9:19         ` Högander Jouni
@ 2008-12-11 16:17           ` Paul Walmsley
  2008-12-12  7:48             ` Tomi Valkeinen
  0 siblings, 1 reply; 21+ messages in thread
From: Paul Walmsley @ 2008-12-11 16:17 UTC (permalink / raw)
  To: Högander Jouni; +Cc: tomi.valkeinen, linux-omap, khilman

[-- Attachment #1: Type: TEXT/PLAIN, Size: 538 bytes --]

Hi Jouni, Tomi, 

On Thu, 11 Dec 2008, Högander Jouni wrote:

> So it seems that cm_* register should not be written while there is
> powerstate transition ongoing in * domain. Patch by Tomi is fixing
> this. As it seems to be transition related rather than pwrdm state,
> same line should be added into omap2_clkdm_clk_disable also.

Shouldn't this have also crashed the system if it needed to be done 
in omap2_clkdm_clk_disable() ?  Perhaps we should avoid adding it there 
until we can reproduce a crash there?


- Paul

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Bug in linux omap clock framework?
  2008-12-11 16:17           ` Paul Walmsley
@ 2008-12-12  7:48             ` Tomi Valkeinen
  0 siblings, 0 replies; 21+ messages in thread
From: Tomi Valkeinen @ 2008-12-12  7:48 UTC (permalink / raw)
  To: ext Paul Walmsley; +Cc: Högander Jouni, linux-omap, khilman

On Thu, 2008-12-11 at 09:17 -0700, ext Paul Walmsley wrote:
> Hi Jouni, Tomi, 
> 
> On Thu, 11 Dec 2008, Högander Jouni wrote:
> 
> > So it seems that cm_* register should not be written while there is
> > powerstate transition ongoing in * domain. Patch by Tomi is fixing
> > this. As it seems to be transition related rather than pwrdm state,
> > same line should be added into omap2_clkdm_clk_disable also.
> 
> Shouldn't this have also crashed the system if it needed to be done 
> in omap2_clkdm_clk_disable() ?  Perhaps we should avoid adding it there 
> until we can reproduce a crash there?
> 

Yep, I haven't seen a crash related to disabling the clock. So perhaps
it's better to just wait in enable for now. I'll resend the patch I sent
earlier.

 Tomi


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

^ permalink raw reply	[flat|nested] 21+ messages in thread

end of thread, other threads:[~2008-12-12  7:48 UTC | newest]

Thread overview: 21+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-12-05 14:49 Bug in linux omap clock framework? Tomi.Valkeinen
2008-12-05 18:23 ` Kevin Hilman
2008-12-08  7:59   ` Tomi Valkeinen
2008-12-06 23:51 ` Paul Walmsley
2008-12-08  8:59   ` Tomi Valkeinen
2008-12-08  9:24     ` Paul Walmsley
2008-12-08  9:36       ` Tomi Valkeinen
2008-12-09 13:58       ` Tomi Valkeinen
2008-12-09 23:14         ` Paul Walmsley
2008-12-10  3:04           ` Igor Stoppa
2008-12-10  7:02             ` Paul Walmsley
2008-12-10  7:37         ` Högander Jouni
2008-12-10  7:59           ` Tomi Valkeinen
2008-12-10  8:44             ` Högander Jouni
2008-12-10  8:57               ` Tomi Valkeinen
2008-12-10 10:44                 ` Högander Jouni
2008-12-10 11:53                   ` Tomi Valkeinen
2008-12-11  9:19         ` Högander Jouni
2008-12-11 16:17           ` Paul Walmsley
2008-12-12  7:48             ` Tomi Valkeinen
2008-12-09  9:15   ` Tomi Valkeinen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox