- 31 Oct, 2012 13 commits
-
-
Tony Lindgren authored
As discussed on linux-arm-kernel, we want to avoid relative includes for the arch/arm/*omap* code: http://www.spinics.net/lists/linux-omap/msg80520.html Fix serial.h by moving it to mach/serial.h. Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Tony Lindgren authored
As discussed on linux-arm-kernel, we want to avoid relative includes for the arch/arm/*omap* code: http://www.spinics.net/lists/linux-omap/msg80520.html Fix includes for fpga.h by making fpga.h local to mach-omap1. The common code in plat-omap just needs to know the struct h2p2_dbg_fpga, which can be local to debug-leds.c. This also fixes the braindead <../*.h> style includes that got accidentally added with search and replace during the cleanup. Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Tony Lindgren authored
As discussed on linux-arm-kernel, we want to avoid relative includes for the arch/arm/*omap* code: http://www.spinics.net/lists/linux-omap/msg80520.html Note that eventually when the omap1 specific drivers are fixed to not use cpu_is_omap macros and not depend on mach/hardware.h, this patch can be reverted and these headers can be local. But since just fixing the drivers for omap2+ is already a big enough hassle, let's deal with that properly first. [tony@atomide.com: also drop unused include for ispvideo.c] Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Tony Lindgren authored
This code will be eventually in drivers, and for the code in the drivers we don't want to have any cpu_is_omap usage. Those macros should be private to arch/arm/mach-omap1 and arch/arm/mach-omap2. To fix this, let's move the define for dma_omap2plus() to dma-omap.h, and use the existing dma_attr passed in the platform_data as the revision registers are what they are. Note that we can now also remove the relative includes introduced by the recent clean-up patches. Cc: Russell King <linux@arm.linux.org.uk> Cc: Vinod Koul <vinod.koul@intel.com> Cc: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Tony Lindgren authored
As discussed on linux-arm-kernel, we want to avoid relative includes for the arch/arm/*omap* shared code: http://www.spinics.net/lists/linux-omap/msg80520.html Let's add plat/debug-devices.h for debug_card_init() to fix the relative includes. Note that drivers must not use this header as it will break build for omap2+ CONFIG_MULTIPLATFORM builds. Cc: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Tony Lindgren authored
Most of the prototypes in plat-omap/common.h are not common to omap1 and omap2+, they are local to omap2+ and should not be in plat-omap/common.h. The only shared function prototype in this file is omap_init_clocksource_32k(), let's put that into counter-32k.h. Note that the new plat/counter-32k.h must not be included from drivers, that will break omap2+ build for CONFIG_MULTIPLATFORM. Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Tony Lindgren authored
This code should be private to mach-omap2. The only use for it in for omap1 has been in dmtimer.c to check for context loss. However, omap1 does not lose context during idle, so the code is not needed. Further, omap1 timer has OMAP_TIMER_ALWON set, so omap1 was not hitting omap_pm_get_dev_context_loss_count() test. Cc: Jon Hunter <jon-hunter@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Tony Lindgren authored
As discussed on linux-arm-kernel, we want to avoid relative includes for the arch/arm/*omap* shared code: http://www.spinics.net/lists/linux-omap/msg80520.html To fix this for the shared i2c.h, let's re-introduce a minimal plat/i2c.h. Note that drivers must not use this header as it will break build for omap2+ CONFIG_MULTIPLATFORM builds. Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Tony Lindgren authored
The common code should not have any omap1 or omap2+ specific code, and should not need to call the cpu_is_omap macros. The only remaining user for cpu_is_omap macros is omap_i2c_nr_ports(). Let's make those checks in the omap specific implementation of omap_i2c_add_bus() instead in order to remove cpu_is_omap usage from the common code. Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Tony Lindgren authored
Let's make the omap2+ specific parts private to mach-omap2. This leaves just a minimal shared code into plat-omap like it should be. Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Tony Lindgren authored
Let's make the omap1 specific parts private to mach-omap1. These should not be in the shared code. Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Tony Lindgren authored
This will allow us to separate out omap1 and omap2+ specific code in the later patches. Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Tony Lindgren authored
Most of the defines are specific to omap1 and omap2+, and should be in the local headers. Only minimal function prototypes need to be shared. As discussed on linux-arm-kernel, we want to avoid relative includes for the arch/arm/*omap* shared code: http://www.spinics.net/lists/linux-omap/msg80520.html So this patch re-adds a minimal plat/sram.h. The new plat/sram.h must not be included from drivers, that will break build for omap2+ CONFIG_MULTIPLATFORM. Note that this patch temporarily adds two more relative includes; Those will be removed in the following patch. Signed-off-by: Tony Lindgren <tony@atomide.com>
-
- 26 Oct, 2012 5 commits
-
-
Paul Walmsley authored
Resolve the following sparse warnings: arch/arm/mach-omap1/usb.c:304:12: warning: symbol 'omap1_usb0_init' was not declared. Should it be static? arch/arm/mach-omap1/usb.c:412:12: warning: symbol 'omap1_usb1_init' was not declared. Should it be static? arch/arm/mach-omap1/usb.c:478:12: warning: symbol 'omap1_usb2_init' was not declared. Should it be static? by declaring those functions as static. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Felipe Balbi <balbi@ti.com> [tony@atomide.com: this was missed with plat/usb.h removal] Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Tony Lindgren authored
Merge tag 'omap-cleanup-fixes-a-for-3.8' of git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into omap-for-v3.8/cleanup-headers Several fixes for build failures and sparse warnings in the OMAP cleanup-headers branch. Intended for 3.8 cleanup. Basic build, boot, and PM test logs are available from here: http://www.pwsan.com/omap/testlogs/cleanup-headers-compile-fixes-3.8/20121026132711/ Due to underlying problems in v3.7-rc2, several tests fail. These failures are unrelated to these patches.
-
Paul Walmsley authored
Commit 4c98dc6b ("ARM: OMAP: Make plat/fpga.h local to arch/arm/plat-omap") results in a new warning from sparse: arch/arm/mach-omap1/fpga.c:147:6: warning: symbol 'omap1510_fpga_init_irq' was not declared. Should it be static? Fix by adding a missing include. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Tony Lindgren <tony@atomide.com>
-
Paul Walmsley authored
Commit 25c7d49e ("ARM: OMAP: Make omap_device local to mach-omap2") broke an OMAP5912-only build here: arch/arm/mach-omap1/pm_bus.c: In function 'omap1_pm_runtime_init': arch/arm/mach-omap1/pm_bus.c:69:2: error: implicit declaration of function 'cpu_class_is_omap1' make[1]: *** [arch/arm/mach-omap1/pm_bus.o] Error 1 Fix by adding a missing include. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Tony Lindgren <tony@atomide.com>
-
Paul Walmsley authored
Commit b7754452 ("mtd: onenand: omap: use pdata info instead of cpu_is") broke an OMAP3+4 build and an N800 multi-OMAP2xxx build here: drivers/built-in.o: In function `omap2_onenand_probe': drivers/mtd/onenand/omap2.c:742: undefined reference to `omap2_onenand_read_bufferram' drivers/mtd/onenand/omap2.c:743: undefined reference to `omap2_onenand_write_bufferram' drivers/mtd/onenand/omap2.c:742: undefined reference to `omap2_onenand_read_bufferram' drivers/mtd/onenand/omap2.c:743: undefined reference to `omap2_onenand_write_bufferram' ... drivers/built-in.o: In function `omap2_onenand_probe': drivers/mtd/onenand/omap2.c:788: undefined reference to `omap3_onenand_read_bufferram' drivers/mtd/onenand/omap2.c:788: undefined reference to `omap3_onenand_write_bufferram' Fix by declaring static functions for the missing symbols, rather than just prototypes. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Afzal Mohammed <afzal@ti.com> Cc: Tony Lindgren <tony@atomide.com>
-
- 25 Oct, 2012 1 commit
-
-
Tony Lindgren authored
Conflicts: arch/arm/mach-omap2/board-h4.c arch/arm/mach-omap2/board-n8x0.c
-
- 24 Oct, 2012 11 commits
-
-
Tony Lindgren authored
Conflicts: arch/arm/mach-omap1/clock.c arch/arm/mach-omap2/board-2430sdp.c arch/arm/mach-omap2/board-4430sdp.c arch/arm/mach-omap2/board-cm-t35.c arch/arm/mach-omap2/board-igep0020.c arch/arm/mach-omap2/board-ldp.c arch/arm/mach-omap2/board-omap3beagle.c arch/arm/mach-omap2/board-omap3logic.c arch/arm/mach-omap2/board-omap4panda.c arch/arm/mach-omap2/board-overo.c arch/arm/mach-omap2/board-rm680.c arch/arm/mach-omap2/board-rx51.c arch/arm/mach-omap2/twl-common.c arch/arm/mach-omap2/usb-host.c arch/arm/mach-omap2/usb-musb.c
-
Felipe Balbi authored
In order to make single zImage work for ARM architecture, we need to make sure we don't depend on private headers. Move USB platform_data to <linux/platform_data/omap-usb.h> and add a minimal drivers/mfd/usb-omap.h. Cc: Samuel Ortiz <sameo@linux.intel.com> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Partha Basak <parthab@india.ti.com> Cc: Keshava Munegowda <keshava_mgowda@ti.com> Cc: linux-usb@vger.kernel.org Signed-off-by: Felipe Balbi <balbi@ti.com> [tony@atomide.com: updated for local mfd/usb-omap.h] Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Tony Lindgren authored
Let's move what we can from plat/usb.h to the local usb.h for ARM common zImage support. This is needed so we can remove plat/usb.h for ARM common zImage support. Cc: Samuel Ortiz <sameo@linux.intel.com> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Partha Basak <parthab@india.ti.com> Cc: Keshava Munegowda <keshava_mgowda@ti.com> Cc: linux-usb@vger.kernel.org Acked-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Tony Lindgren authored
For omap1, we'll keep mach/serial.h around for 8250.c hardware workarounds. For omap2+, we no longer need mach/serial.h and can make it local to mach-omap2. Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Tony Lindgren authored
This allows us to eventually move omap2+ to generic debug code that's configured in Kconfig for the port. Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Tony Lindgren authored
This is the first set of omap cleanup patches for v3.8 merge window to remove most of the remaining plat includes to get us closer to ARM common zImage support. To avoid a huge amount of trivial merge conflicts with includes, this branch is based on several small topic branches coordinated with the driver subsystem maintainers. These branches are based on v3.7-rc1 and can also be merged into the related driver subsystem branches as needed: omap-for-v3.8/cleanup-headers-prepare few trivial driver changes omap-for-v3.8/cleanup-headers-dma move of the DMA header omap-for-v3.8/cleanup-headers-gpmc GPMC and MTD changes omap-for-v3.8/cleanup-headers-mmc MMC related changes omap-for-v3.8/cleanup-headers-dss DSS related changes omap-for-v3.8/cleanup-headers-asoc ASoC related changes Note that for the dma-omap.h, it was decided that it should be is completed. For the related discussion, please see: https://patchwork.kernel.org/patch/1519591/# After these patches we still have a few plat headers remaining that will be handled in later pull requests.
-
Tony Lindgren authored
This allows us to get rid of the ifdefs in 8250.c. Cc: Alan Cox <alan@linux.intel.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Alexey Brodkin authored
Modify divisor to select the nearest baud rate divider rather than the lowest. It minimizes baud rate errors especially on low UART clock frequencies. For example, if uartclk is 33000000 and baud is 115200 the ratio is about 17.9 The current code selects 17 (5% error) but should select 18 (0.5% error). This 5% error in baud rate leads to garbage on receiving end, while 0.5% doesn't. The issue showed up when using the stock 8250 driver for Synopsys DW UART. This was on a FPGA with ~12MHz UART clock. When we enabled early serial, we saw garbage which was narrowed down to the rounding error. So the bug had been latent and it only showed up with such low clock rates. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Thomas Abraham authored
Convert clk_enable/clk_disable to clk_prepare_enable/clk_disable_unprepare calls as required by common clock framework. Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Ivo Sieben authored
When a driver has the low_latency flag set and uses the schedule_flip() function to initiate copying data to the line discipline, a workqueue is scheduled in but never actually flushed. This is incorrect use of the low_latency flag (driver should not support the low_latency flag, or use the tty_flip_buffer_push() function instead). Make sure a warning is reported to catch incorrect use of the low_latency flag. This patch goes with: cee4ad1eSigned-off-by: Ivo Sieben <meltedpianoman@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Daniel Vetter authored
Instead of BUG_ON(in_interrupt()), since that doesn't check for all the newfangled stuff like preempt. Note that this is valid since the console_sem is essentially used like a real mutex with only two twists: - we allow trylock from hardirq context - across suspend/resume we lock the logical console_lock, but drop the semaphore protecting the locking state. Now that doesn't guarantee that no one is playing tricks in single-thread atomic contexts at suspend/resume/boot time, but - I couldn't find anything suspicious with some grepping, - might_sleep shouldn't die, - and I think the upside of catching more potential issues is worth the risk of getting a might_sleep backtrace that would have been save (and then dealing with that fallout). Cc: Dave Airlie <airlied@gmail.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 22 Oct, 2012 10 commits
-
-
Jiri Slaby authored
So this is it. The big step why we did all the work over the past kernel releases. Now everything is prepared, so nothing protects us from doing that big step. | | \ \ nnnn/^l | | | | \ / / | | | '-,.__ => \/ ,-` => | '-,.__ | O __.´´) ( .` | O __.´´) ~~~ ~~ `` ~~~ ~~ The buffers are now in the tty_port structure and we can start teaching the buffer helpers (insert char/string, flip etc.) to use tty_port instead of tty_struct all around. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jiri Slaby authored
For that purpose we have to temporarily introduce a second tty back pointer into tty_port. It is because serial layer, and maybe others, still do not use tty_port_tty_set/get. So that we cannot set the tty_port->tty to NULL at will now. Yes, the fix would be to convert whole serial layer and all its users to tty_port_tty_set/get. However we are in the process of removing the need of tty in most of the call sites, so this would lead to a duplicated work. Instead we have now tty_port->itty (internal tty) which will be used only in flush_to_ldisc. For that one it is ensured that itty is valid wherever the work is run. IOW, the work is synchronously cancelled before we set itty to NULL and also before hangup is processed. After we need only tty_port and not tty_struct in most code, this shall be changed to tty_port_tty_set/get and itty removed completely. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jiri Slaby authored
During the move of tty buffers from tty_struct to tty_port, we will need to switch all users of buf to tty->port->buf. There are many functions where this is accessed directly in their code many times. Cache the tty->buf pointer in such functions now and change only single lines in each function in the next patch. Not that it is convenient for the next patch, but the code is now also more readable. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jiri Slaby authored
They are only TTY buffers specific. And the buffers will go to tty_port in the next patches. So to remove the need to have both tty_port and tty_struct at some places, let us move the flags to tty_port. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jiri Slaby authored
In some funtions we need only n_tty_data, so pass it down directly in case tty is not needed there. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jiri Slaby authored
atomic_write_lock is not n_tty specific, so move it up in the tty_struct. And since these are the last ones to move, remove also the comment saying there are some ldisc' members. There are none now. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jiri Slaby authored
All the ring-buffers... Signed-off-by: Jiri Slaby <jslaby@suse.cz> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jiri Slaby authored
Here we move bitmaps and use DECLARE_BITMAP to declare them in the new structure. And instead of memset, we use bitmap_zero as it is more appropriate. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jiri Slaby authored
Here we start moving all the n_tty related bits from tty_struct to the newly defined n_tty_data struct in n_tty proper. In this patch primitive members and bits are moved. The rest will be done per-partes in the next patches. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jiri Slaby authored
All n_tty related members from tty_struct will be moved here. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-