- 23 2月, 2012 2 次提交
-
-
由 Tomi Valkeinen 提交于
LCD config for old omapfb driver is passed with OMAP_TAG_LCD from board files or from the bootloader. In an effort to remove OMAP_TAG_LCD, this patch adds omapfb_set_lcd_config() function that the board files can call to set the LCD config. This has the drawback that configuration can no longer come from the bootloader. Of the boards supported by the kernel, this should only affect N770 which depends on the data from the bootloader. This patch adds an LCD config for N770 to its board files, but that is most probably broken. Fixing this would need information about the HW setup in N770 boards. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: NTony Lindgren <tony@atomide.com>
-
由 Tomi Valkeinen 提交于
In an effort to clean up the old omapfb driver, this patch removes HWA742 (the display chip used in N770) platform data. This can be done as N770 is the only user of HWA742, and the platform data contains only one field, te_connected, which we can just presume to be true in the HWA742 driver. This allows us to remove omapfb_set_ctrl_platform_data(), and the mechanism to pass the platform data, in a later patch. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: NTony Lindgren <tony@atomide.com>
-
- 05 1月, 2012 1 次提交
-
-
由 Russell King 提交于
Hook these platforms restart code into the new restart hook rather than using arch_reset(). Acked-by: NTony Lindgren <tony@atomide.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 19 12月, 2011 1 次提交
-
-
由 Marc Zyngier 提交于
sched_clock() is yet another blocker on the road to the single image. This patch implements an idea by Russell King: http://www.spinics.net/lists/linux-omap/msg49561.html Instead of asking the platform to implement both sched_clock() itself and the rollover callback, simply register a read() function, and let the ARM code care about sched_clock() itself, the conversion to ns and the rollover. sched_clock() uses this read() function as an indirection to the platform code. If the platform doesn't provide a read(), the code falls back to the jiffy counter (just like the default sched_clock). This allow some simplifications and possibly some footprint gain when multiple platforms are compiled in. Among the drawbacks, the removal of the *_fixed_sched_clock optimization which could negatively impact some platforms (sa1100, tegra, versatile and omap). Tested on 11MPCore, OMAP4 and Tegra. Cc: Imre Kaloz <kaloz@openwrt.org> Cc: Eric Miao <eric.y.miao@gmail.com> Cc: Colin Cross <ccross@android.com> Cc: Erik Gilling <konkers@android.com> Cc: Olof Johansson <olof@lixom.net> Cc: Sascha Hauer <kernel@pengutronix.de> Cc: Alessandro Rubini <rubini@unipv.it> Cc: STEricsson <STEricsson_nomadik_linux@list.st.com> Cc: Lennert Buytenhek <kernel@wantstofly.org> Cc: Ben Dooks <ben-linux@fluff.org> Tested-by: NJamie Iles <jamie@jamieiles.com> Tested-by: NTony Lindgren <tony@atomide.com> Tested-by: NKyungmin Park <kyungmin.park@samsung.com> Acked-by: NLinus Walleij <linus.walleij@linaro.org> Acked-by: NNicolas Pitre <nico@linaro.org> Acked-by: NKrzysztof Halasa <khc@pm.waw.pl> Acked-by: NKukjin Kim <kgene.kim@samsung.com> Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 09 12月, 2011 3 次提交
-
-
由 Janusz Krzysztofik 提交于
DPLL1 reprogramming to a different rate is actually blocked inside omap1_select_table_rate(). However, it is already forced at boot, for boards which boot at unusable clock rates, and this seems to work correctly. OTOH, we now have a fine, run time performed clock selection algorithm implemented, which prevents less powerfull SoCs from being overclocked unintentionally. Allow reprogramming of dpll1 by default, and use it for switching to the higest supported clock rate with all boards, including those already booting at a usable rate of 60 MHz or above. Created against linux-omap/master tip as of Thu Dec 1, commit f83c2a8cbb59981722d1ab610c79adfd034a2667. Requires the just submitted patch "ARM: OMAP1: Move dpll1 rates selection from config to runtime" to prevent from unintentional overclocking. Tested on Amstrad Delta. Signed-off-by: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Janusz Krzysztofik 提交于
According to comments in omap1_select_table_rate(), reprogramming dpll1 is tricky, and should always be done from SRAM. While being at it, move OMAP730 special case handling inside omap_sram_reprogram_clock(). Created on top of version 2 of the series "ARM: OMAP1: Fix dpll1 reprogramming related issues", which it depends on. Tested on Amstrad Delta. Signed-off-by: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Janusz Krzysztofik 提交于
For still better multi-OMAP1 support, expand omap1_rate_table with flags for different SoC types and match them while selecting clock rates. The idea is stolen from current omap24xx clock rate selection algorithm. Since clkdev platform flag definitions are reused here, those had to be expanded with one extra entry for OMAP1710 subtype, as this is the only SoC for which we allow selection of the highest, 216 MHz rate. Once done, remove no longer needed clock rate configure time options. Tested on Amstrad Delta. Signed-off-by: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl> [tony@atomide.com: updated comments] Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 06 12月, 2011 1 次提交
-
-
由 Janusz Krzysztofik 提交于
Otherwise timing is inaccurate, resulting in devices which depend on it, like omap-keypad, broken. Tested on Amstrad Delta. Signed-off-by: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl> [tony@atomide.com: removed comment referencing a development branch] Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 02 12月, 2011 2 次提交
-
-
由 Janusz Krzysztofik 提交于
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: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl> [tony@atomide.com: removed comment referencing a development branch] Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Tony Lindgren 提交于
Commit e9b7086b (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 <jkrzyszt@tis.icnet.pl> for figuring this one out. Reported-by: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl> Acked-by: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 27 11月, 2011 1 次提交
-
-
由 Nicolas Pitre 提交于
Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
-
- 19 11月, 2011 1 次提交
-
-
由 Nicolas Pitre 提交于
A generic version should replace this later. As io.c has become nearly empty, omap_init_consistent_dma_size() is moved into common.c so that io.c can be removed entirely. Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org> Tested-by: NKevin Hilman <khilman@ti.com>
-
- 18 11月, 2011 1 次提交
-
-
由 Tony Lindgren 提交于
As suggested by Russell King - ARM Linux <linux@arm.linux.org.uk>, there's no need to keep local prototypes in non-local headers. Add mach-omap1/common.h and mach-omap2/common.h and move the local prototypes there from plat/common.h and mach/omap4-common.h. Signed-off-by: NTony Lindgren <tony@atomide.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 12 11月, 2011 1 次提交
-
-
由 Tony Lindgren 提交于
Commit a66cb345 (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 : [<c001b0c4>] lr : [<c0019f54>] 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: [<c001b09c>] (omap_sram_reprogram_clock+0x0/0x30) from [<c0019f54>] (omap1_select_table_rate+0x88/0xb4) [<c0019ecc>] (omap1_select_table_rate+0x0/0xb4) from [<c033ea24>] (omap1_clk_init+0x148/0x334) r7:c035ed4c r6:00000004 r5:00002cb3 r4:00001000 [<c033e8dc>] (omap1_clk_init+0x0/0x334) from [<c00194c4>] (omap1_init_early+0x34/0x48) r8:c03f8120 r7:c035ed4c r6:c035ed4c r5:02000000 r4:c035335c [<c0019490>] (omap1_init_early+0x0/0x48) from [<c033bc24>] (setup_arch+0x69c/0x79c) [<c033b588>] (setup_arch+0x0/0x79c) from [<c0338574>] (start_kernel+0x7c/0x2f4) [<c03384f8>] (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: NAaro Koskinen <aaro.koskinen@iki.fi> Tested-by: NAaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 10 11月, 2011 1 次提交
-
-
由 Tony Lindgren 提交于
Commit 7b88e62f (ARM: OMAP1: Use generic map_io, init_early and init_irq) changed omap1 to use generic map_io. Looks like I missed one board though. Fix this by adding a custom map_io for Amstrad E3. Reported-by: NAaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 05 11月, 2011 2 次提交
-
-
由 Jarkko Nikula 提交于
There is no use for omap-alsa.h and board-palmz71.c doesn't need it either. Signed-off-by: NJarkko Nikula <jarkko.nikula@bitmer.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Tony Lindgren 提交于
Fix "Enable 32kHz OS timer in order to allow sleep states in idle" warning. We are now compiling in bothe MPU timer and 32 KiHz timer, so this warning is only valid when MPU_TIMER is set and OMAP_DM_TIMER is not set. Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 01 11月, 2011 2 次提交
-
-
由 Paul Gortmaker 提交于
These files will fail to compile if we dont clean them up in advance and have them include the appropriate headers they need. Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
-
由 Paul Gortmaker 提交于
These files all make use of one of the EXPORT_SYMBOL variants or the THIS_MODULE macro. So they will need <linux/export.h> Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
-
- 20 10月, 2011 3 次提交
-
-
由 Tony Lindgren 提交于
We don't have cpu_is_omapxxxx SoC detection initialized until SoC detection is initialized from init_early. Note that with the common map_io we should no longer need cpu_is_omapxxxx for ioremap. Acked-by: NNicolas Pitre <nicolas.pitre@linaro.org> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Tony Lindgren 提交于
This allows us to remove omap hacks for map_io. Acked-by: NNicolas Pitre <nicolas.pitre@linaro.org> Reviewed-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Tony Lindgren 提交于
This allows removing omap hacks for map_io allowing generic map_io. Note that in the future we can't do cpu_is_omapxxxx detection until in init_early. This means that board-innovator.c now assumes 15xx only, and board-generic.c assumes 16xx only. This is best fixed later on by passing the SoC type from device tree. Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 17 10月, 2011 1 次提交
-
-
由 Sascha Hauer 提交于
Boards used to specify zreladdr in their Makefile.boot with zreladdr-y := x, so conflicting zreladdrs were silently overwritten. This patch changes this to zreladdr-y += x, so that we end up with multiple words in zreladdr in such a case. We can detect this later and complain if necessary. Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 27 9月, 2011 3 次提交
-
-
由 Jarkko Nikula 提交于
These address definitions are OMAP1 specific can be in single source file. Signed-off-by: NJarkko Nikula <jarkko.nikula@bitmer.com> Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com> Tested-by: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Jarkko Nikula 提交于
Register access can be made more generic by calculating register address offsets runtime from common register definitions and by using reg_size and reg_step variables that are passed via platform data. Common register definitions are possible since McBSP registers are ordered similarly between OMAP versions. Remove also references to OMAP2+ specific config_type variable from generic McBSP code since other variables and feature flags are better to carry needed information from platform code. Signed-off-by: NJarkko Nikula <jarkko.nikula@bitmer.com> Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com> Tested-by: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Jarkko Nikula 提交于
Only OMAP1s are using omap_mcbsp_register_board_cfg after OMAP2+ hwmod conversion so it can be moved to mach-omap1/mcbsp.c. Signed-off-by: NJarkko Nikula <jarkko.nikula@bitmer.com> Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com> Tested-by: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 26 9月, 2011 4 次提交
-
-
由 Nicolas Pitre 提交于
Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org> Acked-by: NTony Lindgren <tony@atomide.com>
-
由 Nicolas Pitre 提交于
This achieves two goals: 1) Get rid of omap_uart_v2p() and omap_uart_p2v() which were the last users of PLAT_PHYS_OFFSET. 2) Remove the probing of the M bit in the CP15 control reg and make the access to the .data variables completely position independent. Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org> Tested-by: NTony Lindgren <tony@atomide.com> Reviewed-by: NKevin Hilman <khilman@ti.com>
-
由 Nicolas Pitre 提交于
This is the first step to remove PLAT_PHYS_OFFSET usage from the debug UART code. Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org> Tested-by: NTony Lindgren <tony@atomide.com> Reviewed-by: NKevin Hilman <khilman@ti.com>
-
由 Nicolas Pitre 提交于
Some platforms (like OMAP not to name it) are doing rather complicated hacks just to determine the base UART address to use. Let's give their addruart macro some slack by providing an extra work register which will allow for much needed cleanups. This is basically a no-op as this commit is only adding the extra argument to the macro but no one is using it yet. Signed-off-by: Nnicolas Pitre <nicolas.pitre@linaro.org> Reviewed-by: NKevin Hilman <khilman@ti.com>
-
- 22 9月, 2011 1 次提交
-
-
由 Tarun Kanti DebBarma 提交于
Convert OMAP1 dmtimers into a platform devices and then registers with device model framework so that it can be bound to corresponding driver. Signed-off-by: NThara Gopinath <thara@ti.com> Signed-off-by: NTarun Kanti DebBarma <tarun.kanti@ti.com> Reviewed-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: NCousson, Benoit <b-cousson@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 25 8月, 2011 1 次提交
-
-
由 Rafael J. Wysocki 提交于
Since the PM clock management code in drivers/base/power/clock_ops.c is used for both runtime PM and system suspend/hibernation, the definitions of data structures and headers related to it should not be located in include/linux/pm_rumtime.h. Move them to a separate header file. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
-
- 22 8月, 2011 2 次提交
-
-
由 Jon Medhurst 提交于
Signed-off-by: NJon Medhurst <tixy@yxit.co.uk> CC: Tony Lindgren <tony@atomide.com>
-
由 Nicolas Pitre 提交于
Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org> Acked-by: NTony Lindgren <tony@atomide.com> Acked-by: NArnd Bergmann <arnd@arndb.de>
-
- 08 8月, 2011 1 次提交
-
-
由 Russell King 提交于
Convert arch/arm includes of mach/gpio.h and asm/gpio.h to linux/gpio.h before we start consolidating the individual platform implementations of the gpio header files. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 27 7月, 2011 1 次提交
-
-
由 Arun Sharma 提交于
This allows us to move duplicated code in <asm/atomic.h> (atomic_inc_not_zero() for now) to <linux/atomic.h> Signed-off-by: NArun Sharma <asharma@fb.com> Reviewed-by: NEric Dumazet <eric.dumazet@gmail.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: David Miller <davem@davemloft.net> Cc: Eric Dumazet <eric.dumazet@gmail.com> Acked-by: NMike Frysinger <vapier@gentoo.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 20 7月, 2011 1 次提交
-
-
由 Kyungmin Park 提交于
Now most of ARM machines has the alsmot same __clk_get/put() macro So place it at the arch/arm/include/asm/clkdev.h and remove the reduntant header files But some machines don't have the same form as above. It can use the machince specific clkdev file by HAVE_MACH_CLKDEV config Now there are only 3 caese. 1) define the clk structure with clkdev macro => Need to move clk structure to proper header file arch/arm/mach-versatile/include/mach/clkdev.h arch/arm/mach-realview/include/mach/clkdev.h arch/arm/mach-vexpress/include/mach/clkdev.h arch/arm/mach-integrator/include/mach/clkdev.h 2) export the __clk_get/put function at clock.c arch/arm/mach-shmobile/include/mach/clkdev.h 3) demuxing the clk source arch/arm/mach-u300/include/mach/clkdev.h Acked-by: NViresh Kumar <viresh.kumar@st.com> Acked-by: NH Hartley Sweeten <hsweeten@visionengravers.com> Acked-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
-
- 08 7月, 2011 1 次提交
-
-
由 Jarkko Nikula 提交于
These McBSP port number enums are used only in two places in the McBSP code so we may remove then and just use numeric values like rest of the code does. Signed-off-by: NJarkko Nikula <jhnikula@gmail.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 04 7月, 2011 1 次提交
-
-
由 Janusz Krzysztofik 提交于
Pointers to statically declared platform device structures which are registered with platform_device_register() are then used during run time to access these structure members, for example from platform_uevent() and much more. Therefore, these structures should never be placed inside sections which are dropped after boot. Fix platform devices incorrectly tagged with __initdata which happen to exist inside OMAP sub-trees. This bug has exhibited itself on my ARM/OMAP1 based Amstrad Delta videophone after commit 6d3163ce, "mm: check if any page in a pageblock is reserved before marking it MIGRATE_RESERVE", resulting in reading from several /sys/device/platform/*/uevent files always ending up with segmentation faults. Signed-off-by: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl> Acked-by: NFelipe Balbi <balbi@ti.com> Cc: Varadarajan, Charulatha <charu@ti.com> Cc: Jarkko Nikula <jhnikula@gmail.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 02 7月, 2011 1 次提交
-
-
由 Rafael J. Wysocki 提交于
The common PM clock management functions may be used for system suspend/resume as well as for runtime PM, so rename them accordingly. Modify kerneldoc comments describing these functions and kernel messages printed by them, so that they refer to power management in general rather that to runtime PM. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Reviewed-by: NKevin Hilman <khilman@ti.com>
-