The mailbox register for usb otg in omap is present in control module.
On detection of any events VBUS or ID, this register should be written
to send the notification to musb core.
Till we have a separate control module driver to write to control module,
omap2430 will handle the register writes to control module by itself. So
a new address space to represent this control module register is added
to usb_otg_hs.
Acked-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
plat/board.h file is now empty - remove it.
Cc: Jarkko Lavinen <jarkko.lavinen@nokia.com>
Cc: Chris Ball <cjb@laptop.org>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: linux-mmc@vger.kernel.org
Cc: linux-mtd@lists.infradead.org
Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
Acked-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
debug_card_init() function resides in the plat/board.h file.
Move it to a separate header file under plat/ so the board.h file can be
removed.
Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
Signed-off-by: Tony Lindgren <tony@atomide.com>
The sti console workaround uses the OMAP custom tags.
Those tags are not used in upstream kernel and therefore the workaround
never fires on upstream kernels.
Remove the sti console workaround tags part.
This leaves the workaround functional part intact so can be reused if
needed.
Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
Signed-off-by: Tony Lindgren <tony@atomide.com>
The omap3evm has its revision information bits inside the plat/board.h
file. Those bits are not used anywhere in the upstream tree besides the
board-omap3evm.c file.
Move the OMAP3EVM_BOARD_GEN_* bits to the board file and remove the
get_omap3_evm_rev() function declaration.
Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
Signed-off-by: Tony Lindgren <tony@atomide.com>
struct omap_board_config_kernel defined in the board files
is always empty and does not bring any added value.
Remove the struct omap_board_config_kernel instances from the board
files.
Also remove the omap_get_nr_config() macro and the omap_get_var_config()
function as both are not used for quite a long time (if ever).
Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
Signed-off-by: Tony Lindgren <tony@atomide.com>
pdata and pdata->regs have been allocated in this function and
should be freed before leaving it, and in the other error handling
cases too.
spatch with a semantic match is used to found this problem.
(http://coccinelle.lip6.fr/)
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Select PINCTRL in Kconfig under Typical OMAP configuration, this
is required to add pinctrl driver to omap2+ family of devices.
Signed-off-by: AnilKumar Ch <anilkumar@ti.com>
[tony@atomide.com: updated to select pinctrl-single in defconfig]
Signed-off-by: Tony Lindgren <tony@atomide.com>
The extra serial port is not available on 34xx. And the current
omap3-beagle.dts file is for omap3-beagle-xm.dts as it lists 512MB
of memory.
Please somebody submit a new omap3-beagle.dts for the original 34xx
BeagleBoard after testing it properly.
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: devicetree-discuss@lists.ozlabs.org
Signed-off-by: Tony Lindgren <tony@atomide.com>
The Gumstix Overo is a computer on module using an OMAP3 processor.
This module must be plugged into an expansion board.
This patch adds a first device tree support for the Overo, using the
Tobi expansion board. The current support is able to boot and mount
the rootfs from MMC.
This patche also updates the omap3 dtb build target.
Currently working:
- mmc0 (on board microSD)
- i2c0 and i2c2 (i2c1 not used)
- led on GPIO
Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch>
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Add cortex-a9 local timer support for all OMAP4 based
SOCs using DT.
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Provide PL310 Level 2 Cache Controller Device Tree
support for OMAP4 based devices.
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
With the new devices (like, AM33XX and OMAP5) we now only support
DT boot mode of operation and now it is the time to start killing
slowly the dependency on hwmod, so with this patch, we are starting
with device resources.
The idea here is implemented considering to both boot modes -
- DT boot mode
OF framework will construct the resource structure (currently
does for MEM & IRQ resource) and we should respect/use these
resources, killing hwmod dependency.
If pdev->num_resources > 0, we assume that MEM & IRQ resources
have been allocated by OF layer already (through DTB).
Once DMA resource is available from OF layer, we should
kill filling any resources from hwmod.
- Non-DT boot mode
Here, pdev->num_resources = 0, and we should get all the
resources from hwmod (following existing steps)
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@ti.com>
[b-cousson@ti.com: Fix some checkpatch CHECK issues]
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
DSI clocks are now configured dynamically by the DSI driver, so we can
remove the hardcoded clock configuration from the board file.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
HDMI requires vdda_hdmi_dac (vdac) power for operation. The regulator,
or the regulator supplying the vdac, has been enabled by default and
things have worked without the HDMI driver enabling the vdac.
I encountered the problem when implementing HDMI device tree support,
where the regulator was not enabled by default.
This patch adds the vdda_hdmi_dac to twl-common.c so that the HDMI
driver can use it.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
We currently manage HDMI GPIOs in the board files via
platform_enable/disable calls. This won't work with device tree, and in
any case the correct place to manage the GPIOs is in the HDMI driver.
This patch moves the handling of the GPIOs to the HDMI driver. The GPIO
handling is moved to the common hdmi.c file, and this probably needs to
be revisited when adding OMAP5 HDMI support to see if the GPIO handling
needs to be moved to IP specific files.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
All the unnessary functions in omap-phy-internal is removed.
These functionality are now handled by omap-usb2 phy driver.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
The driver doesn't need to know about its platform_device.
Everything the driver needs can be done through the
struct device pointer. In case we need to use the
OMAP-specific PM function pointers, those can make
sure to find the device's platform_device pointer
so they can find the struct omap_device through
pdev->archdata field.
Tested-by: Shubhrajyoti D <shubhrajyoti@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Test logs can be found here:
http://www.pwsan.com/omap/testlogs/omap_fixes_a_3.6rc/20120904110254/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJQR3ZZAAoJEMePsQ0LvSpLRwwQAJ/tvZhDwhBZ2/2XIn+SWWrU
wS7MRkN+g3rsoQXjYI6n1BVCVj/qEpHpfZluaZy+09JrW2Db0pKtYGcJGF3U+TAb
RrqOS9r2PnLrmkIpsYfigXRtDvyYuMHP/eN4WpSZywVeY8xxs7azOrCN+0pGCUYA
DJ0ewAhini2SRGGcFqt7zXbkeOoPNGQZHpSChrN9m93fbqDqcJsk6mQ9H4Fd7oTm
JY72d9MmgkqaGsA2hmQA25KD3NFi6u8cu/31nu+gTMZbmOA0ZYmHP8fqEk/pSyBU
fPNIAnDs5RFYryntoQgVLQbOnhYYUIiuP+V2TBum44bG3sc0DEh4fBU/wDLNNy+H
JBQEirZ5DYqO0sELyXC1aZtbpu5rz/lHiYPQrMlA3NXQkQKOnRtyGHsv5MO3L45R
Gr+UyHq8nI8zB7kPIzxvlQ1mqzABUGmE8x8QlJy5PGbJW7naLaKzyUr7ULIvrekU
fxhKmFR3I1zpXRuN5bSX/95RDSfUEJpEVpBYuhOOaXBj+T2L3tkc5zH5vJZlX2/t
q3Qc0YXQ1/seToywVfJIqZGYceyeECdY1JCWeFwwdPBhQc8BPj/Dgor1Z460JRbg
aJ5PTPl8q9G2aiMaB3exQkQH09CB0ZJ0oWHhkiMyxGUxGsTesuTKfriWQ7/X31AR
GVLXEMQTvEPKJVSbiLdw
=R0kV
-----END PGP SIGNATURE-----
Merge tag 'omap-fixes-a-for-3.6rc' of git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into fixes
Some hwmod, clockdomain, am335x fixes against v3.6-rc4.
Test logs can be found here:
http://www.pwsan.com/omap/testlogs/omap_fixes_a_3.6rc/20120904110254/
If NR_IRQS is less than MAX_IRQS, we end up writing past the
irq_target_cpu array in omap_wakeupgen_init():
/* Associate all the IRQs to boot CPU like GIC init does. */
for (i = 0; i < max_irqs; i++)
irq_target_cpu[i] = boot_cpu;
This can happen if SPARSE_IRQ is enabled as by default NR_IRQS is
set to 16. Without this patch we're overwriting other data during
the boot.
Looks like a similar fix was posted by Benoit Cousson earlier
as "ARM: OMAP2+: wakeupgen: Fix wrong array size for irq_target_cpu"
but was lost.
Cc: stable@vger.kernel.org
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
The OMAP4 sl2if IP block requires some special programming for it to
enter idle. Without this programming, it will prevent the rest of
the chip from entering full chip idle.
This patch comments out the IP block data.
Later, once the appropriate support is available, this patch can be
reverted.
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Clock and module mode are explictly enable when hwmod is enabled. But if
the hwmod doesn't get ready on time, clocks are disabled but module is left
enabled.
Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com>
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
IVA2 hwmod resets were missing the status bit offsets. Also, as the
hwmod itself didn't have prcm info at all, resetting iva hwmod was
accessing some bogus memory addresses. Added both infos to fix this.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Commit 4da71ae6 ("OMAP: clockdomain: Arch specific funcs for
clkdm_clk_enable/disable") called the OMAP2xxx-specific functions for
clockdomain wakeup and sleep. This would probably have broken
software-supervised clockdomain wakeup and sleep on OMAP3.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Jon Hunter <jon-hunter@ti.com>
Acked-by: Rajendra Nayak <rnayak@ti.com>
With commit ae6df418a2
Sub: ARM: OMAP2+: dmtimer: cleanup fclk usage)
The Timer functional clock naming convention has changed from
gptX_fck => timerXfck, and so as the timer init function
in mach-omap2/timer.c.
OMAP4 clocktree also has changed accordingly.
AM33xx Clock Tree has been merged during rc3-4 timeframe,
before above commit got merged, so similar change is required
for AM33xx as well (Change the gptX_fck => timerX_fck).
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Fix inconsistency between mach-types and CONFIG_ name that prevents
touchbook board from booting.
Signed-off-by: Radek Pilar <mrkva@mrkva.eu>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Currently, omap2_sync32k_clocksource_init() function initializes the 32K
timer as the system clock source regardless of the CONFIG_OMAP_32K_TIMER
setting.
Fix this by providing a default implementation for
!CONFIG_OMAP_32K_TIMER case.
Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
Reviewed-by: Paul Walmsley <paul@pwsan.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: stable@vger.kernel.org
Signed-off-by: Tony Lindgren <tony@atomide.com>
Now GPMC provides its client with interrupts that can be handled
using the standard interrupt API. Modify GPMC NAND setup to work
with it.
Also disable write protect in GPMC code, so that NAND driver can
be ignorant of GPMC configuration.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Modify interrupt handling such that interrupts can be handled by GPMC
client drivers using standard interrupt APIs rather than requiring
the drivers to have knowledge about GPMC interrupt handling. Currently
only NAND related interrupts has been considered (which is the case
even without this change) as the only user of GPMC interrupt is NAND.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Currently omap onenand driver invokes gpmc_cs_request, obtains address
space allocated by gpmc to onenand. Remove this, instead use resource
structure; this is now updated with address space for onenand by gpmc
initialization with the help of gpmc_cs_request. And remove usage of
gpmc_cs_request in onenand driver.
This helps in smooth migration of gpmc to driver.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Currently omap nand driver uses a field in platform data - phys_base
for passing the address space allocated by gpmc for nand. Use struct
resource instead. With this change omap nand driver has to get
address space from memory resource.
This helps in smooth migration of gpmc to driver.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
GPMC has NAND registers, update nand platform data with those details
so that NAND driver can configure those by itself instead of using
exported symbols.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Provide helper function for updating NAND register details for
the necessary chip select. NAND drivers platform data can be
updated with this information so that NAND driver can handle
GPMC NAND operations by itself.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Makes it easier to just do 'make dtbs' for whatever the kernel was
configured for, just like some other platforms.
Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Small platform specific bug fixes for problems found in randconfig builds.
* randconfig/mach:
ARM: ux500: don't select LEDS_GPIO for snowball
ARM: imx: build i.MX6 functions only when needed
ARM: imx: select CPU_FREQ_TABLE when needed
ARM: imx: fix ksz9021rn_phy_fixup
ARM: imx: build pm-imx5 code only when PM is enabled
ARM: omap: allow building omap44xx without SMP
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
The new omap4 cpuidle implementation currently requires
ARCH_NEEDS_CPU_IDLE_COUPLED, which only works on SMP.
This patch makes it possible to build a non-SMP kernel
for that platform. This is not normally desired for
end-users but can be useful for testing.
Without this patch, building rand-0y2jSKT results in:
drivers/cpuidle/coupled.c: In function 'cpuidle_coupled_poke':
drivers/cpuidle/coupled.c:317:3: error: implicit declaration of function '__smp_call_function_single' [-Werror=implicit-function-declaration]
It's not clear if this patch is the best solution for
the problem at hand. I have made sure that we can now
build the kernel in all configurations, but that does
not mean it will actually work on an OMAP44xx.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Fixes:
CC arch/arm/mach-omap2/twl-common.o arch/arm/mach-omap2/twl-common.c:562: error: conflicting types for ‘omap_twl4030_audio_init’
arch/arm/mach-omap2/twl-common.h:62: error: previous declaration of ‘omap_twl4030_audio_init’ was here
make[1]: *** [arch/arm/mach-omap2/twl-common.o] Error 1
make: *** [arch/arm/mach-omap2] Error 2
When building the kernel with !SND_OMAP_SOC_OMAP_TWL4030
Reported-by: Brian Austin <brian.austin@cirrus.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
The arm_pmu_type enumeration was initially introduced to identify
different PMU types in the system, the usual one being that on the CPU
(ARM_PMU_DEVICE_CPU). With the removal of the PMU reservation code and
the introduction of devicetree bindings for the CPU PMU, the enumeration
is no longer required.
This patch removes the enumeration and updates the various CPU PMU
platform devices so that they no longer pass an .id field referring
to identify the PMU type.
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
Cc: Olof Johansson <olof@lixom.net>
Cc: Pawel Moll <pawel.moll@arm.com>
Acked-by: Jon Hunter <jon-hunter@ti.com>
Acked-by: Kukjin Kim <kgene.kim@samsung.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Jiandong Zheng <jdzheng@broadcom.com>
Signed-off-by: Sudeep KarkadaNagesha <Sudeep.KarkadaNagesha@arm.com>
[will: cosmetic edits and actual removal of the enum type]
Signed-off-by: Will Deacon <will.deacon@arm.com>
Only create the devices in a legacy way if we do not have the DT data.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Remove the feature to configure the CLKR/FSR mux on McBSP port with 6pin
configuration.
When moving to devicetree these callback can no longer be used in a clean
way anymore.
If a board require to change the 6pin port to work in 4pin setup it needs
to set up the mux in the board file.
For OMAP2/3:
u32 devconf0;
/* McBSP1 CLKR/FSR signal to be connected to CLKX/FSX pin */
devconf0 = omap_ctrl_readl(OMAP2_CONTROL_DEVCONF0);
devconf0 |= OMAP2_MCBSP1_CLKR_MASK | OMAP2_MCBSP1_FSR_MASK;
omap_ctrl_writel(devconf0, OMAP2_CONTROL_DEVCONF0);
For OMAP4:
u32 mcbsp_pad;
/* McBSP4 CLKR/FSR signal to be connected to CLKX/FSX pin */
mcbsp_pad = omap4_ctrl_pad_readl(OMAP2_CONTROL_DEVCONF0);
mcbsp_pad |= ((1 << 31) | (1 << 30));
omap4_ctrl_pad_writel(mcbsp_pad, OMAP2_CONTROL_DEVCONF0);
In case when the kernel is booted with DT blob the pinctrl-single will be
provided as soon as it is enabled on the platform.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: Jarkko Nikula <jarkko.nikula@bitmer.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
am3517evm board uses McBSP1 for audio with 4pin configuration.
The CLKR/FSR signals need to be connected to CLKX/FSX pin of the SoC in
this case.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: Jarkko Nikula <jarkko.nikula@bitmer.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
On OMAP2430 all McBSP ports have 128 word long buffer, enable the use of
the FIFO for the audio stack.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: Jarkko Nikula <jarkko.nikula@bitmer.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Move the McBSP CLKS re-parenting code to ASoC driver from
arch/arm/mach-omap2.
The call fort the re-parenting has been already limited to OMAP2+ SoC in
the ASoC driver. There is no longer need to have callback function for it.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: Jarkko Nikula <jarkko.nikula@bitmer.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
This is a alternative to "HACK: OMAP: DSS2: VENC: disable VENC on OMAP4 to
prevent crash" (ba02fa37de) by Tomi Valkeinen <tomi.valkeinen@ti.com> to prevent
VENC from crashing OMAP4 kernel. This prevents OMAPDSS from initial registration
of a device for VENC on OMAP4.
Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
OMAP hardware doesn't provide a phyisical DTR line, but
some configurations may need a DTR line which tracks whether
the device is open or not.
So allow a gpio to be configured as the DTR line.
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
