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: Nicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Otherwise we can't do generic map_io as we currently rely on
static mappings that work only because of arch_ioremap.
Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
This allows us to remove omap hacks for map_io.
Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
This assumes fixed mappings which will not work once we move
to use ioremap_exec(). It seems that these are currently
not in use, or in use for some out of tree corner cases.
If SRAM support for framebuffer is wanted, it should be done
with ioremap in the driver.
Note that further removal of the code can now be done,
but that can be done seprately by the driver maintainers.
Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
This way we don't need to initialize SoC detection early
and can start using generic map_io.
Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
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: Tony Lindgren <tony@atomide.com>
Add nodes for devices used by PM code (mpu, dsp, iva).
Add a cpus node as well as recommended in the DT spec.
Remove mpu, dsp, iva devices init if is populated.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Cc: Kevin Hilman <khilman@ti.com>
Used the main OCP node to add bindings with the l3_noc driver.
Remove l3_noc static device creation if DT is populated.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Add device-tree support for the l3-noc driver.
Use platform_driver_register to defer the probing at device init
time.
Add documentation for the l3-noc bindings.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Still needed to boot until the i2c & twl driver is adapted to
device-tree. Otherwise the voltage control code will try to
access the twl and crash.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Re-cycle the original board-generic.c file to support Device Tree
for every OMAP2+ variants.
The current approach is an intermediate step before having only
one machine descriptor that will use some generic DT aware
functions.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Add OMAP3 beagleboard DTS file to use the omap3.dtsi SoC file.
Add a default bootargs line to allow a boot from RAMDISK.
Add memory node information.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Cc: G, Manjunath Kondaiah <manjugk@ti.com>
Add the SDP/Blaze (Software Development Board) support with
device tree.
That file is based on the omap4-panda.dts.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Cc: G, Manjunath Kondaiah <manjugk@ti.com>
Based on the original omap4-panda.dts file from Manju.
http://www.spinics.net/lists/linux-omap/msg55836.html
Add memory information and a default bootargs to allow
a boot from RAMDISK.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Cc: G, Manjunath Kondaiah <manjugk@ti.com>
Add initial device-tree support for OMAP4 SoC.
This is based on the original panda board patch done by Manju:
http://permalink.gmane.org/gmane.linux.ports.arm.omap/60393
Add the generic GIC interrupt-controller from ARM.
Add an empty "soc" node to contain non memory mapped IPs
(DSP, MPU, IPU...).
Note: Since reg, irq and dma are provided by hwmod for the
moment, these attributes will not be present at all in DTS
to highlight the gap. They will be added as soon as dma bindings
will be there and drivers will be adapted.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Cc: G, Manjunath Kondaiah <manjugk@ti.com>
Add a notifier called during device_add phase. If an of_node is present,
retrieve the hwmod entry in order to populate properly the omap_device
structure.
For the moment the resource from the device-tree are overloaded.
DT does not support named resource yet, and thus, most driver will not
work without that information.
Add a documentation to capture the specifics OMAP bindings needed for
device-tree support.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Kevin Hilman <khilman@ti.com>
Split the omap_device_build_ss into two smaller functions
that will allow to populate a platform_device already allocated by
device-tree.
The functionality of the omap_device_build_ss is still the same, but
the omap_device_alloc will be usable with devices already built by
device-tree.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
Add of_property_read_string_index and of_property_count_strings
to retrieve one string inside a property that will contains
severals strings.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Kevin Hilman <khilman@ti.com>
Remove all these duplicated structures since a default one is now
available.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
Most devices are using the same default omap_device_pm_latency structure
during device built. In order to avoid the duplication of the same
structure everywhere, add a default structure that will be used if
the device does not have an explicit one.
Next patches will clean the duplicated structures.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
Since the device pointer is now retrieved using the hwmod name, remove
the static variables used to store the device pointers for DSP, MPU, IVA
and L3 devices for PM/DVFS usage.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
Replace the struct device parameter of omap2_set_init_voltage
by the hwmod name. It will avoid having to store explicitely
the device pointer into a static variable.
Moreover, it will be a little bit more scalable if we introduce
new DVFS devices.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
Replace the multiple omap2_get_XXX_device APIs with the new
omap_hwmod_name_get_dev that uses the hwmod name to get the proper
device.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
An API which translates a standard hwmod name to corresponding
platform_device is useful for drivers when they need to look up the
device associated with a hwmod name to map back into the device
structure pointers. These ideally should be used by drivers in
mach directory. Using a generic hwmod name like "gpu" instead of
the actual device name which could change in the future, allows
us to:
a) Could in effect help replace apis such as omap2_get_mpuss_device,
omap2_get_iva_device, omap2_get_l3_device, omap4_get_dsp_device,
etc..
b) Scale to more devices rather than be restricted to named functions
c) Simplify driver's platform_data from passing additional fields
all doing the same thing with different function pointer names
just for accessing a different device name.
Signed-off-by: Nishanth Menon <nm@ti.com>
[b-cousson@ti.com: Adapt it to the new pdev pointer inside od,
remove the unneeded helpers, and fold the next patch here]
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
Fixes bug where variable i was redundantly used for counting two nested loops.
Signed-off-by: Tapani Utriainen <tapani@technexion.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
`keypad_pads' is referred to by `keypad_data' which is
not __initdata, so `keypad_pads' should not be __initdata either.
Signed-off-by: Bjarne Steinsbo <bsteinsbo@gmail.com>
Reviewed-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Current code calls omap4430_phy_init() twice in usb_musb_init().
Calling omap4430_phy_init() once is enough.
This patch removes the first omap4430_phy_init() call, which using an
uninitialized pointer as parameter.
This patch elimates below build warning:
arch/arm/mach-omap2/usb-musb.c: In function 'usb_musb_init':
arch/arm/mach-omap2/usb-musb.c:141: warning: 'dev' may be used uninitialized in this function
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Bjarne Steinsbo <bsteinsbo@gmail.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Looks like 2600 kHz rate does not work reliably on 2430,
so just use the 100 kHz rate.
Otherwise the system often fails to boot properly with:
omap_i2c omap_i2c.2: timeout waiting for bus ready
omap_i2c omap_i2c.2: timeout waiting for bus ready
twl: i2c_write failed to transfer all messages
omap_i2c omap_i2c.2: timeout waiting for bus ready
twl: i2c_write failed to transfer all messages
omap_i2c omap_i2c.2: timeout waiting for bus ready
twl: i2c_write failed to transfer all messages
twl: clock init err [-110]
omap_i2c omap_i2c.2: timeout waiting for bus ready
twl: i2c_write failed to transfer all messages
TWL4030 Unable to unlock IDCODE registers --110
Signed-off-by: Tony Lindgren <tony@atomide.com>
Remove OMAP4_USBC1_ICUSB_PWRDNZ_MASK during enable/disable PWRDNZ mode for
MMC1_PBIAS and associated extended-drain MMC1 I/O cell. This is in accordance
with the control module programming guide. This fixes a bug where if trying to
use gpio_98 or gpio_99 and MMC1 at the same time the GPIO signal will be
affected by a changing SDMMC1_VDDS.
Software must keep MMC1_PBIAS cell and MMC1_IO cell PWRDNZ signals low whenever
SDMMC1_VDDS ramps up/down or changes for cell protection purposes.
MMC1 is based on SDMMC1_VDDS whereas USBC1 is based on SIM_VDDS therefore
they can operate independently.
Signed-off-by: Bryan Buckley <bryan.buckley@ti.com>
Acked-by: Kishore Kadiyala <kishore.kadiyala@ti.com>
Tested-by: Balaji T K <balajitk@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
* 'for-linus' of git://github.com/tiwai/sound:
ASoC: ssm2602: Re-enable oscillator after suspend
ALSA: usb-audio: Check for possible chip NULL pointer before clearing probing flag
ALSA: hda/realtek - Don't detect LO jack when identical with HP
ALSA: hda/realtek - Avoid bogus HP-pin assignment
ALSA: HDA: No power nids on 92HD93
ASoC: omap-mcbsp: Do not attempt to change DAI sysclk if stream is active
That flag no longer makes sense, since we don't look up automount points
as eagerly any more. Additionally, it turns out that the NO_AUTOMOUNT
handling was buggy to begin with: it would avoid automounting even for
cases where we really *needed* to do the automount handling, and could
return ENOENT for autofs entries that hadn't been instantiated yet.
With our new non-eager automount semantics, one discussion has been
about adding a AT_AUTOMOUNT flag to vfs_fstatat (and thus the
newfstatat() and fstatat64() system calls), but it's probably not worth
it: you can always force at least directory automounting by simply
adding the final '/' to the filename, which works for *all* of the stat
family system calls, old and new.
So AT_NO_AUTOMOUNT (and thus LOOKUP_NO_AUTOMOUNT) really were just a
result of our bad default behavior.
Acked-by: Ian Kent <raven@themaw.net>
Acked-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Currently the the internal oscillator is powered down when entering BIAS_OFF
state, but not re-enabled when going back to BIAS_STANDBY. As a result the
CODEC will stop working after suspend if the internal oscillator is used to
generate the sysclock signal. This patch fixes it by clearing the appropriate
bit in the power down register when the CODEC is re-enabled.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: stable@kernel.org
The concensus seems to be that system calls such as stat() etc should
not trigger an automount. Neither should the l* versions.
This patch therefore adds a LOOKUP_AUTOMOUNT flag to tag those lookups
that _should_ trigger an automount on the last path element.
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
[ Edited to leave out the cases that are already covered by LOOKUP_OPEN,
LOOKUP_DIRECTORY and LOOKUP_CREATE - all of which also fundamentally
force automounting for their own reasons - Linus ]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
With SoC specific timers, board specific init_irq is
no longer needed. Earlier this was still needed to
initialize the gptimer12 on Beagle based boards.
Also convert board-h4.c to use omap2_init_irq accidentally
did not get converted earlier.
Signed-off-by: Tony Lindgren <tony@atomide.com>
Add SoC specific map_io function to be used by the generic DT
board file. This is an intermediate step before having some
generic DT aware map_io function.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
This generalizes the omap2_mcbsp1_mux_clkr_src and omap2_mcbsp1_mux_fsr_src
implementation between generic McBSP and OMAP2 specific McBSP code. These
functions are used to select source for CLKR and FSR signals on OMAP2+.
Start generalizing the code by implementing an optional mux_signal function
pointer in platform data that will implement the actual muxing and which is
called now from omap2_mcbsp1_mux_clkr_src and omap2_mcbsp1_mux_fsr_src.
These functions are to be removed later and cleanup the API so that
mux_signal gets its arguments directly from client code.
Signed-off-by: Jarkko Nikula <jarkko.nikula@bitmer.com>
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Signed-off-by: Tony Lindgren <tony@atomide.com>
This generalizes the omap2_mcbsp_set_clks_src implementation between generic
McBSP and OMAP2 specific McBSP code. Currently this function is used to
select either internal fclk or clks pin as a McBSP CLKS source on OMAP2+.
Implement generalization by having an optional set_clk_src function pointer
in platform data that is used to select parent for a given clock. Idea is to
pass higher level source clock name (later coming from client driver) that
platform specific code will map to platform specific clock name.
API cleanup between McBSP and client code comes later.
Signed-off-by: Jarkko Nikula <jarkko.nikula@bitmer.com>
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Signed-off-by: Tony Lindgren <tony@atomide.com>
These address definitions are OMAP1 specific can be in single source file.
Signed-off-by: Jarkko Nikula <jarkko.nikula@bitmer.com>
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Signed-off-by: Tony Lindgren <tony@atomide.com>
hardware.h is not needed here and let the definition for struct clk to come
via linux/clk.h.
Signed-off-by: Jarkko Nikula <jarkko.nikula@bitmer.com>
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Sidetone resource is already registered for a device so there is no need
for cpu_is_omap34xx() and McBSP port number tests in the driver. We can
cleanup and make the code generic by dropping remaining CONFIG_ARCH_OMAP3
conditional compilations and then using sidetone resource and st_data
variable for runtime tests.
Signed-off-by: Jarkko Nikula <jarkko.nikula@bitmer.com>
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Active sidetone requires that McBSP interface clock doesn't idle and there
is no mechanism in hwmod to turn autoidling on/off in runtime. McBSP2 and 3
in OMAP34xx share their interface clock with McBSP sidetone module and
that interface clock must be active when the sidetone is operating.
Sidetone has its own autoidle bit which should keep the interface clock
active but it is broken. Putting the McBSP core to no-idle mode when the
sidetone is active is no good either since it results to higher power
consumption when using the threshold based DMA transfers.
For making the McBSP code more generic, move this sidetone clock management
with fixme comments to mach-omap2/mcbsp.c and pass pointer to it via
platform data.
Signed-off-by: Jarkko Nikula <jhnikula@gmail.com>
Cc: Paul Wamsley <paul@pwsan.com>
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Rationale here is to remove one global variable and to make possible to have
variable size McBSP register maps inside SoC.
Signed-off-by: Jarkko Nikula <jarkko.nikula@bitmer.com>
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Tony Lindgren