kernel.git/arch/arm/mach-omap1/clock_data.c, branch linux-3.2.y

ARM: OMAP1: recalculate loops per jiffy after dpll1 reprogram

2011-12-05T17:28:32Z

Otherwise timing is inaccurate, resulting in devices which depend on it, like omap-keypad, broken. Tested on Amstrad Delta. Signed-off-by: Janusz Krzysztofik [tony@atomide.com: removed comment referencing a development branch] Signed-off-by: Tony Lindgren

ARM: OMAP1: Fix ckctl value used for dpll1 defualt rate

2011-12-02T01:51:34Z

Use the exact value found in omap1_rate_table, otherwise I have been experiencing issues with correct timekeeping on my Amstrad Delta. Signed-off-by: Janusz Krzysztofik [tony@atomide.com: removed comment referencing a development branch] Signed-off-by: Tony Lindgren

ARM: OMAP1: Fix reprogramming of DPLL1 for systems that boot at rates below 60MHz

2011-12-02T01:47:06Z

Commit e9b7086b80c4d9e354f4edc9e280ae85a60df408 (ARM: OMAP: Fix reprogramming of dpll1 rate) fixed a regression for systems that did not rely on bootloader set rates. However, it also introduced a new problem where the rates selected in .config would not take affect as omap1_select_table_rate currently refuses to reprogram DPLL1 if it's already initialized. This was not a problem earlier, as the reprogramming was done earlier with ck_dpll1_p->rate uninitialized. Fix this by forcing the reprogramming on systems booting at rates below 60MHz. Note that the long term fix is to make the rates SoC specific later on. Thanks for Janusz Krzysztofik for figuring this one out. Reported-by: Janusz Krzysztofik Acked-by: Janusz Krzysztofik Signed-off-by: Tony Lindgren

ARM: OMAP: Fix reprogramming of dpll1 rate

2011-11-11T18:15:11Z

Commit a66cb3454f220f49f900646ebdc76cb943319eb7 (ARM: OMAP: Map SRAM later on with ioremap_exec()) moved the SRAM init to happen later to remove a dependency to early SoC detection for map_io. This broke booting on some boards not using Kconfig option for OMAP_CLOCKS_SET_BY_BOOTLOADER as the dpll1 reprogramming would cause the following error: kernel BUG at arch/arm/plat-omap/sram.c:226! Internal error: Oops - undefined instruction: 0 [#1] PREEMPT Modules linked in: CPU: 0 Not tainted (3.2.0-rc1-e3 #9) PC is at omap_sram_reprogram_clock+0x28/0x30 LR is at omap1_select_table_rate+0x88/0xb4 pc : [] lr : [] psr: 600000d3 sp : c035bf10 ip : c035bf20 fp : c035bf1c r10: c035bfd4 r9 : 54029252 r8 : c03f8120 r7 : c0362b50 r6 : 00b71b00 r5 : c03873cc r4 : c0362b40 r3 : 00000000 r2 : c0362b40 r1 : 0000010a r0 : 00002cb0 Flags: nZCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel Control: 0000317f Table: 10004000 DAC: 00000017 Process swapper (pid: 0, stack limit = 0xc035a270) Stack: (0xc035bf10 to 0xc035c000) bf00: c035bf3c c035bf20 c0019f54 c001b0ac bf20: 00001000 00002cb3 00000004 c035ed4c c035bf74 c035bf40 c033ea24 c0019edc bf40: c02f526c 00000002 00000015 bc058c9b 93111a16 c035335c 02000000 c035ed4c bf60: c035ed4c c03f8120 c035bf84 c035bf78 c00194c4 c033e8ec c035bfc4 c035bf88 bf80: c033bc24 c00194a0 c035bf90 c035bf98 00000000 00000000 00000000 00000000 bfa0: 00000001 00000000 c0354678 c035ece4 10004000 103532f4 c035bff4 c035bfc8 bfc0: c0338574 c033b598 00000000 00000000 00000000 c035467c 0000317d c035c03c bfe0: c0354678 c035ece4 00000000 c035bff8 10008040 c0338508 00000000 00000000 Backtrace: [] (omap_sram_reprogram_clock+0x0/0x30) from [] (omap1_select_table_rate+0x88/0xb4) [] (omap1_select_table_rate+0x0/0xb4) from [] (omap1_clk_init+0x148/0x334) r7:c035ed4c r6:00000004 r5:00002cb3 r4:00001000 [] (omap1_clk_init+0x0/0x334) from [] (omap1_init_early+0x34/0x48) r8:c03f8120 r7:c035ed4c r6:c035ed4c r5:02000000 r4:c035335c [] (omap1_init_early+0x0/0x48) from [] (setup_arch+0x69c/0x79c) [] (setup_arch+0x0/0x79c) from [] (start_kernel+0x7c/0x2f4) [] (start_kernel+0x0/0x2f4) from [<10008040>] (0x10008040) r7:c035ece4 r6:c0354678 r5:c035c03c r4:0000317d Code: 0a000002 e1a0e00f e12fff13 e89da800 (e7f001f2) Fix this by adding omap1_clk_late_init() that only reprograms dpll1 if the bootloader rate is less than 60MHz. This also allows removing of the OMAP_CLOCKS_SET_BY_BOOTLOADER option. Reported-by: Aaro Koskinen Tested-by: Aaro Koskinen Signed-off-by: Tony Lindgren

OMAP1: clock_data: use runtime cpu / machine checks

2010-12-22T04:08:15Z

Otherwise multi-omap1 configurations may set wrong clock speed. Created and tested against l-o master on Amstrad Delta. Signed-off-by: Janusz Krzysztofik Signed-off-by: Paul Walmsley

I2C: i2c-omap: Change device name: i2c_omap -> omap_i2c

2010-12-21T01:53:04Z

The convention for omap device naming is omap_XXX. Rename the device and driver name in order to stick to this naming convention. Change device name in clock nodes as well. Signed-off-by: Benoit Cousson Cc: Kevin Hilman Cc: Rajendra Nayak Cc: Ben Dooks Acked-by: Paul Walmsley Acked-by: Ben Dooks Signed-off-by: Tony Lindgren

OMAP: GPIO: Implement GPIO as a platform device

2010-12-08T00:26:57Z

Implement GPIO as a platform device. GPIO APIs are used in machine_init functions. Hence it is required to complete GPIO probe before board_init. Therefore GPIO device register and driver register are implemented as postcore_initcalls. omap_gpio_init() does nothing now and this function would be removed in the next patch as it's usage is spread across most of the board files. Inorder to convert GPIO as platform device, modifications are required in clockxxxx_data.c file for OMAP1 so that device names can be used to obtain clock instead of getting clocks by name/NULL ptr. Use runtime pm APIs (pm_runtime_put*/pm_runtime_get*) for enabling or disabling the clocks, modify sysconfig settings and remove usage of clock FW APIs. Note 1: Converting GPIO driver to use runtime PM APIs is not done as a separate patch because GPIO clock names are different for various OMAPs and are different for some of the banks in the same CPU. This would need usage of cpu_is checks and bank id checks while using clock FW APIs in the gpio driver. Hence while making GPIO a platform driver framework, PM runtime APIs are used directly. Note 2: While implementing GPIO as a platform device, pm runtime APIs are used as mentioned above and modification is not done in gpio's prepare for idle/ resume after idle functions. This would be done in the next patch series and GPIO driver would be made to use dev_pm_ops instead of sysdev_class in that series only. Due to the above, the GPIO driver implicitly relies on CM_AUTOIDLE = 1 on its iclk for power management to work, since the driver never disables its iclk. This would be taken care in the next patch series (see Note 3 below). Refer to http://www.mail-archive.com/linux-omap@vger.kernel.org/msg39112.html for more details. Note 3: only pm_runtime_get_sync is called in gpio's probe() and pm_runtime_put* is never called. This is to make the implementation similar to the existing GPIO code. Another patch series would be sent to correct this. In OMAP3 and OMAP4 gpio's debounce clocks are optional clocks. They are enabled/ disabled whenever required using clock framework APIs TODO: 1. Cleanup the GPIO driver. Use function pointers and register offest pointers instead of using hardcoded values 2. Remove all cpu_is_ checks and OMAP specific macros 3. Remove usage of gpio_bank array so that only instance specific information is used in driver code 4. Rename 'method'/ avoid it's usage 5. Fix the non-wakeup gpios handling for OMAP2430, OMAP3 & OMAP4 6. Modify gpio's prepare for idle/ resume after idle functions to use runtime pm implentation. Signed-off-by: Charulatha V Signed-off-by: Rajendra Nayak Reviewed-by: Basak, Partha Acked-by: Kevin Hilman [tony@atomide.com: updated for bank specific revision and updated boards] Signed-off-by: Tony Lindgren

Merge branch 'for_2.6.36' of git://git.pwsan.com/linux-2.6 into omap-for-linus

2010-08-04T05:46:24Z

omap1: omap7xx clocks, mux, serial fixes

2010-08-02T11:21:39Z

This change adds in the necessary clocks and mux pins for UART control on omap7xx devices. I also made a change in the serial code to only try and initialize two UARTs in omap_serial_init, as these devices don't have three. Signed-off-by: Cory Maccarrone Signed-off-by: Tony Lindgren

OMAP1: clock: some cleanup

2010-07-26T22:34:28Z

Convert most of the magic numbers in mach-omap1/clock_data.c to use macros. Clean up a few comments to conform with Documentation/CodingStyle. Mark the current clkops_uart as being OMAP16xx-only, and add some comments to indicate that it does not belong there, for future cleanup. This patch should not cause any functional changes. Signed-off-by: Paul Walmsley