| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
If any of the GPMC child nodes fails, this shouldn't make the
whole gpmc_probe_dt() function to fail. It is better to just
WARN and allow other devices probe function to succeed.
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The GPMC DT probe function use for_each_node_by_name() to search
child device nodes of the GPMC controller. But this function does
not use the GPMC device node as the root of the search and instead
search across the complete Device Tree.
This means that any device node on the DT that is using any of the
GPMC child nodes names searched for will be returned even if they
are not connected to the GPMC, making the gpmc_probe_xxx_child()
function to fail.
Fix this by using the GPMC device node as the search root so the
search will be restricted to its children.
Reported-by: Lars Poeschel <poeschel@lemonage.de>
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Besides being used to interface with external memory devices,
the General-Purpose Memory Controller can be used to connect
Pseudo-SRAM devices such as ethernet controllers to OMAP2+
processors using the TI GPMC as a data bus.
This patch allows an ethernet chip to be defined as an GPMC
child device node.
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The gpmc_probe_nor_child() function is used in the GPMC driver to
configure the GPMC for a NOR child device node.
But this function is quite generic and all the NOR specific configuration
is made by the driver of the actual NOR flash memory used.
Other Pseudo-SRAM devices such as ethernet controllers need a similar
setup so by making this function generic it can be used for those too.
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
gpmc_probe_nor_child() calls of_platform_device_create() to create a
platform device for the NOR child. If this function fails the value
of ret is returned to the caller but this value is zero since it was
assigned the return of a previous call to gpmc_cs_program_settings()
that had to succeed or otherwise gpmc_probe_nor_child() would have
returned before.
This means that if of_platform_device_create() fails, 0 will be returned
to the caller instead of an appropriate error code.
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the GPMC driver is probed, we call gpmc_mem_init() to see which
chip-selects have already been configured and enabled by the boot-loader
and allocate space for them. If we fail to allocate space for one
chip-select, then we return failure from the probe and the GPMC driver
will not be available.
Rather than render the GPMC useless for all GPMC devices, if we fail to
allocate space for one chip-select print a warning and disable the
chip-select. This way other GPMC clients can still be used.
There is no downside to this approach, because all GPMC clients need to
request a chip-select before they can use the GPMC and on requesting a
chip-select, if memory has not already been reserved for the chip-select
then it will be.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
|
|
|
|
|
|
|
|
|
|
| |
With commit 21cc2bd (ARM: OMAP2+: Remove apollon board support) the
variable "boot_rom_space" is now not needed and the code surrounding
this variable can be cleaned up and simplified. Remove unnecessary
definitions and clean-up the comment as well.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Each GPMC chip-select can be configured to map 16MB, 32MB, 64MB or 128MB
of address space. The physical base address where a chip-select starts
is also configurable and must be aligned on a boundary that is equal to
or greater than the size of the address space mapped bt the chip-select.
When enabling a GPMC chip-select, ensure that the base address is aligned
to the appropriate boundary.
Reported-by: Mark Jackson <mpfj-list@mimc.co.uk>
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When booting with device-tree, retrieve GPMC settings for ONENAND from
the device-tree blob. This will allow us to remove all static settings
stored in the gpmc-nand.c in the future once the migration to
device-tree is complete.
The user must now specify the ONENAND device width in the device-tree
binding so that the GPMC can be programmed correctly. Therefore, update
the device-tree binding documentation for ONENAND devices connected to
the GPMC to reflect this.
Please note that this does not include GPMC timings for ONENAND. The
timings are being calculated at runtime.
There is some legacy code that only enables read wait monitoring for
non-OMAP3 devices. There are no known OMAP3 device issues that prevent
this feature being enabled and so when booting with device-tree use the
wait-monitoring settings described in the device-tree blob.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
|
|
|
|
|
|
|
|
|
|
| |
When booting with device-tree, retrieve GPMC settings for NAND from
the device-tree blob. This will allow us to remove all static settings
stored in the gpmc-nand.c in the future once the migration to
device-tree is complete.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
|
|
|
|
|
|
|
|
|
|
|
| |
NOR flash is not currently supported when booting with device-tree
on OMAP2+ devices. Add support to detect and configure NOR devices
when booting with device-tree.
Add documentation for the TI GPMC NOR binding.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some of the GPMC timings parameters are currently missing from the GPMC
device-tree binding. Add these parameters to the binding documentation
as well as code to read them. Also add either "-ps" or "-ns" suffix to
the GPMC timing properties to indicate whether the timing is in
picoseconds or nanoseconds.
The existing code in gpmc_read_timings_dt() is checking the value of
of_property_read_u32() and only is successful storing the value read
in the gpmc_timings structure. Checking the return value in this case
is not necessary and we can simply read the value, if present, and
store directly in the gpmc_timings structure. Therefore, simplify the
code by removing these checks.
The comment in the gpmc_read_timings_dt() function, "only for OMAP3430"
is also incorrect as it is applicable to all OMAP3+ devices. So correct
this too.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
|
|
|
|
|
|
|
|
|
|
|
| |
Adds a function to read the various GPMC chip-select settings from
device-tree and store them in the gpmc_settings structure.
Update the GPMC device-tree binding documentation to describe these
options.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
|
|
|
|
|
|
|
|
|
|
| |
With the addition of the gpmc_cs_program_settings(), we no longer need
or use gpmc_cs_configure() to configure some of the GPMC chip-select
options. So rename the function to gpmc_configure() and remove code that
modifies options in the CONFIG1 register.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
|
|
|
|
|
|
|
|
|
| |
Convert the OMAP2+ TUSB code to use the gpmc_cs_program_settings()
function for configuring the various GPMC options instead of directly
programming the CONFIG1 register.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Convert the OMAP2+ SMC91x code to use the gpmc_cs_program_settings()
function for configuring the various GPMC options instead of directly
programming the CONFIG1 register.
Move configuration of the GPMC settings outside retime function and
this does not need to be done if the timings are changed dynamically
at runtime.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Convert the OMAP2+ NAND code to use the gpmc_cs_program_settings()
function for configuring the various GPMC options instead of directly
programming the CONFIG1 register.
This moves the configuration of some GPMC options outside the
nand_gpmc_retime() because these options should only need to be set once
regardless of whether the gpmc timing is changing dynamically at runtime.
The programming of where the wait-pin is also moved slightly, but this
will not have any impact to existing devices as no boards are currently
setting the dev_ready variable.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
|
|
|
|
|
|
|
|
|
| |
Convert the OMAP2+ ONENAND code to use the gpmc_cs_program_settings()
function for configuring the various GPMC options instead of directly
programming the CONFIG1 register.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The GPMC has various different configuration options such as bus-width,
synchronous or asychronous mode selection, burst mode options etc.
Currently, there is no common function for configuring these options and
various devices set these options by either programming the GPMC CONFIG1
register directly or by calling gpmc_cs_configure() to set some of the
options.
Add a new function for configuring all of the GPMC options. Having a common
function for configuring this options will simplify code and ease the
migration to device-tree.
Also add a new capability flag to detect devices that support the
address-address-data multiplexing mode.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The GPMC has various different configuration options such as bus-width,
synchronous or asychronous mode selection, burst mode options etc.
Currently, there is no central structure for storing all these options
when configuring the GPMC for a given device. Some of the options are
stored in the GPMC timing structure and some are directly programmed
into the GPMC configuration register. Add a new structure to store
these options and convert code to use this structure. Adding this
structure will allow us to create a common function for configuring
these options.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The GPMC has wait-pin signals that can be assigned to a chip-select
to monitor the ready signal of an external device. Add a variable to
indicate the total number of wait-pins for a given device. This will
allow us to detect if the wait-pin being selected is valid or not.
When booting with device-tree read the number of wait-pins from the
device-tree blob. When device-tree is not used set the number of
wait-pins to 4 which is valid for OMAP2-5 devices. Newer devices
that have less wait-pins (such as AM335x) only support booting with
device-tree and so hard-coding the wait-pin number when not using
device-tree is fine.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The OMAP2+ code that configures the GPMC for ONENAND devices is copying
structures between functions unnecessarily. Avoid this by passing
pointers instead and simplify the code.
A pointer to structure "omap_onenand_platform_data" is passed to the
function omap2_onenand_calc_sync_timings(), but only the flags member
of the structure is used. Simplify the code by only passing the flags
member and not the entire structure.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
|
|
|
|
|
|
|
|
|
|
| |
This check is done before the call to gpmc_cs_reserved() and
gpmc_cs_set_reserved() and it's redundant to do it again in each
function. This simplifies the code a bit.
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Reviewed-by: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
|
|
|
|
|
|
|
|
|
| |
Since the condition is not an error but a warning, replace
printk KERN_ERR with dev_warn.
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Reviewed-by: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
|
|
|
|
|
|
|
|
|
| |
Do this becasue dev_err() is preferred over pr_err() and because
it will match gpmc-nand, thus the code shows looks more consistent.
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Reviewed-by: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
|
|
|
|
|
|
|
|
|
| |
If CS request fails the current error message is rather unhelpful.
Fix it by printing the failing chip select and the error code.
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Reviewed-by: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
|
|
|
|
|
|
|
|
|
| |
If CS request fails the current error message is rather unhelpful.
Fix it by printing the failing chip select and the error code.
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Reviewed-by: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently gpmc_cs_reserved() return value is somewhat inconsistent,
returning a negative value on an error condition, a positive value
if the chip select is reserved and zero if it's available.
Fix this by returning a boolean value as the function name suggests:
* true if the chip select is reserved,
* false if it's available
Suggested-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Reviewed-by: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
|
|
|
|
|
|
|
|
|
| |
This function is not used anywhere, so it's safe to remove it.
This means less code to maintain.
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Reviewed-by: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
|
|
|
|
|
|
|
|
|
| |
This patch marks a bunch of functions that are local
to gpmc.c file only as static.
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Reviewed-by: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When setting the GPMC device type, make sure any previous
bits are cleared down, before applying the new setting.
For OMAP4+ devices MUXADDDATA is a 2-bit field (bits 9:8)
where as for OMAP2/3 devices it was only a one bit field
(bit 9). For OMAP2/3 devices bit 8 is reserved and the
OMAP documentation says to write a 0 to this bit. So
clearing bit 8 on OMAP2/3 devices should not be a problem.
Hence update the code to handle both bits 8 and 9 for all
devices.
Signed-off-by: Mark Jackson <mpfj@newflow.co.uk>
[jon-hunter@ti.com: updated changelog]
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
|
|\
| |
| |
| |
| | |
Conflicts:
arch/arm/plat-omap/dmtimer.c
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Commit 6797b4fe (ARM: OMAP2+: Prevent potential crash if GPMC probe fails)
added code to ensure that GPMC chip-selects could not be requested until the
device probe was successful. The chip-selects should have been
unreserved at the end of the probe function, but the code to unreserve
them appears to have ended up in the gpmc_calc_timings() function and
hence, this is causing problems requesting chip-selects. Fix this merge
error by unreserving the chip-selects at the end of the probe, but
before we call the gpmc child probe functions (for device-tree) which
request a chip-select.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Tested-by: Philip Avinash <avinashphilip@ti.com>
Tested-by: Grazvydas Ignotas <notasas@gmail.com>
[tony@atomide.com: updated description to add breaking commit id]
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
| |\
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC late OMAP changes from Olof Johansson:
"This branch contains changes for OMAP that came in late during the
release staging, close to when the merge window opened.
It contains, among other things:
- OMAP PM fixes and some patches for audio device integration
- OMAP clock fixes related to common clock conversion
- A set of patches cleaning up WFI entry and blocking.
- A set of fixes and IP block support for PM on TI AM33xx SoCs
(Beaglebone, etc)
- A set of smaller fixes and cleanups around AM33xx restart and
revision detection, as well as removal of some dead code
(CONFIG_32K_TIMER_HZ)"
* tag 'late-omap' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (34 commits)
ARM: omap2: include linux/errno.h in hwmod_reset
ARM: OMAP2+: fix some omap_device_build() calls that aren't compiled by default
ARM: OMAP4: hwmod data: Enable AESS hwmod device
ARM: OMAP4: hwmod data: Update AESS data with memory bank area
ARM: OMAP4+: AESS: enable internal auto-gating during initial setup
ASoC: TI AESS: add autogating-enable function, callable from architecture code
ARM: OMAP2+: hwmod: add enable_preprogram hook
ARM: OMAP4: clock data: Add missing clkdm association for dpll_usb
ARM: OMAP2+: PM: Fix the dt return condition in pm_late_init()
ARM: OMAP2: am33xx-hwmod: Fix "register offset NULL check" bug
ARM: OMAP2+: AM33xx: hwmod: add missing HWMOD_NO_IDLEST flags
ARM: OMAP: AM33xx hwmod: Add parent-child relationship for PWM subsystem
ARM: OMAP: AM33xx hwmod: Corrects PWM subsystem HWMOD entries
ARM: DTS: AM33XX: Add nodes for OCMC RAM and WKUP-M3
ARM: OMAP2+: AM33XX: Update the hardreset API
ARM: OMAP2+: AM33XX: hwmod: Update the WKUP-M3 hwmod with reset status bit
ARM: OMAP2+: AM33XX: hwmod: Fixup cpgmac0 hwmod entry
ARM: OMAP2+: AM33XX: hwmod: Update TPTC0 hwmod with the right flags
ARM: OMAP2+: AM33XX: hwmod: Register OCMC RAM hwmod
ARM: OMAP2+: AM33XX: CM/PRM: Use __ASSEMBLER__ macros in header files
...
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The newly created omap_hwmod_reset.c is missing an
include of linux/errno.h in commit c02060d8 "ARM:
OMAP4+: AESS: enable internal auto-gating during
initial setup". It still works in omap2_defconfig,
but not in all other combinations.
Without this patch, building allmodconfig results in:
arch/arm/mach-omap2/omap_hwmod_reset.c: In function 'omap_hwmod_aess_preprogram':
arch/arm/mach-omap2/omap_hwmod_reset.c:47:11: error: 'EINVAL' undeclared (first use in this function)
arch/arm/mach-omap2/omap_hwmod_reset.c:47:11: note: each undeclared identifier is reported only once for each function it appears in
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Tony Lindgren <tony@atomide.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Sebastien Guiriec <s-guiriec@ti.com>
|
| | |\
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into late/omap
From Tony Lindgren:
omap4 pm changes via Paul Walmsley <paul@pwsan.com>:
Some OMAP4 power management fixes and audio device integration
patches. This pull request contains a fix for an issue discovered during
branch integration.
Basic test logs are available at:
http://www.pwsan.com/omap/testlogs/omap4_prcm_devel_a_3.9/20130210112717/
* tag 'omap-for-v3.9/pm-omap4-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
ARM: OMAP4: hwmod data: Enable AESS hwmod device
ARM: OMAP4: hwmod data: Update AESS data with memory bank area
ARM: OMAP4+: AESS: enable internal auto-gating during initial setup
ASoC: TI AESS: add autogating-enable function, callable from architecture code
ARM: OMAP2+: hwmod: add enable_preprogram hook
ARM: OMAP2+: PM: Fix the dt return condition in pm_late_init()
ARM: OMAP4: PM: Warn users about usage of older bootloaders
|
| | | |\
| | | | |
| | | | |
| | | | | |
omap4_prcm_devel_a_3.9
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Commit 1416408d {ARM: OMAP2+: PM: share some suspend-related functions
across OMAP2, 3, 4} moved suspend code to common place but now with
that change, for DT build on OMAP4, suspend hooks are not getting
registered which results in no suspend support.
The DT return condition is limited to PMIC and smartreflex
initialization and hence restrict it so that suspend ops gets
registered.
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Reviewed-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
OMAP4 CHIP level PM works only with newer bootloaders. The
dependency on the bootloader comes from the fact that the
kernel is missing reset and initialization code for some
devices.
While the right thing to do is to add reset and init code in
the kernel, for some co-processor IP blocks like DSP and IVA
it means downloading firmware into each one of them to execute
idle instructions.
While a feasible solution is worked upon on how such IP blocks
can be better handled in the kernel, in the interim, to avoid
any further frustration to users testing PM on OMAP4 and finding
it broken, warn them about the bootloader being a possible
cause.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Cc: Tero Kristo <t-kristo@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: R Sricharan <r.sricharan@ti.com>
[paul@pwsan.com: tweaked warning messages and comments slightly]
Acked-by: Kevin Hilman <khilman@linaro.org>
[paul@pwsan.com: fixed checkpatch warning]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Enable AESS data in hwmod in order to be able to probe
audio driver.
Signed-off-by: Sebastien Guiriec <s-guiriec@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Add AESS memory bank data in hwmod in order to provide memory address
information to the driver.
This version also changes the AESS main clock to use a
non-CLKCTRL-based functional clock. These are being removed from the
clock data, since they should be handled by the IP block integration
code. Without this change, the kernel crashes during boot. Thanks to
Tony Lindgren for reporting this during a test merge.
Signed-off-by: Sebastien Guiriec <s-guiriec@ti.com>
[paul@pwsan.com: updated to change the AESS main_clk]
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Enable the AESS auto-gating control bit during AESS hwmod setup. This
fixes the following boot warning on OMAP4:
omap_hwmod: aess: _wait_target_disable failed
Without this patch, the AESS IP block does not indicate to the PRCM
that it is idle after it is reset. This prevents some types of SoC
power management until something sets the auto-gating control bit.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Sebastien Guiriec <s-guiriec@ti.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Péter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
|
| | | |/
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
After setup/enable, some IP blocks need some additional setting to
indicate the PRCM that they are inactive until they are configured.
Some examples on OMAP4 include the AESS and FSUSB IP blocks.
To fix this cleanly, this patch adds another optional function
pointer, enable_preprogram, to the IP block's hwmod data. The function
that is pointed to is called by the hwmod code immediately after the
IP block is reset.
This version of the patch includes a patch description fix from Felipe.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Sebastien Guiriec <s-guiriec@ti.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Péter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Felipe Balbi <balbi@ti.com>
|
| | |\ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into late/omap
From Tony Lindgren:
omap clock changes via Paul Walmsley <paul@pwsan.com>:
Some miscellaneous OMAP2+ clock fixes, mostly related to the recent
common clock framework conversion.
Basic test logs are available here:
http://www.pwsan.com/omap/testlogs/clock_devel_a_3.9/20130208120108/
* tag 'omap-for-v3.9/clock-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
ARM: OMAP4: clock data: Add missing clkdm association for dpll_usb
ARM: OMAP AM33XX: clock data: SET_RATE_PARENT in lcd path
ARM: OMAP2+: clock data: add DEFINE_STRUCT_CLK_FLAGS helper
ARM: OMAP2+: dpll: am335x - avoid freqsel
omap3isp: Set cam_mclk rate directly
ARM: OMAP3: clock: Back-propagate rate change from cam_mclk to dpll4_m5
|
| | | | \ | |
| | | | \ | |
| | | |\ \ \
| | | | |_|/
| | | |/| |
| | | | | | |
'remotes/pinchart/omap3isp/clock' into clock_devel_a_3.9
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The cam_mclk clock is generated through the following clocks chain:
dpll4 -> dpll4_m5 -> dpll4_m5x2 -> cam_mclk
As dpll4_m5 and dpll4_m5x2 do not driver any clock other than cam_mclk,
back-propagate the cam_clk rate changes up to dpll4_m5.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Mike Turquette <mturquette@linaro.org>
Acked-by: Sakari Ailus <sakari.ailus@iki.fi>
Tested-by: Sakari Ailus <sakari.ailus@iki.fi>
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
dpll_usb needs the clkdm association so the clkdm can be
turned on before a relock. All other dplls for omap4 belong
to the ALWON (always on) domain.
The association was present as part of the older data file
(clock44xx_data.c) but looks like got accidently dropped with
the common clk convertion.
More details of the patch which fixed this up in the older
data file can be dound here..
http://www.spinics.net/lists/linux-omap/msg63076.html
Adding the .clkdm_name as part of the clk_hw_omap struct also
means a new .init needs to be part of the clk_ops for dpll_usb
to initialise the clkdm.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
LCDC clock node is a one that does not have set rate capability. It
just passes on the rate that is sent downstream by it's parent. While
lcdc clock parent and it's grand parent - dpll_disp_m2_ck and
dpll_disp_ck has the capability to configure rate.
And the default rates provided by LCDC clock's ancestors are not
sufficient to obtain pixel clock for current LCDC use cases, hence
currently display would not work on AM335x SoC's (with driver
modifications in platfrom independent way).
Hence inform clock framework to propogate set rate for LCDC clock as
well as it's parent - dpll_disp_m2_ck. With this change, set rate on
LCDC clock would get propogated till dpll_disp_ck via dpll_disp_m2_ck,
hence allowing the driver (same driver is used in DaVinci too) to set
rates using LCDC clock without worrying about platform dependent clock
details.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
DEFINE_STRUCT_CLK does not have the capability to set flags, define
DEFINE_STRUCT_CLK_FLAGS to handle flags. This is needed to add
SET_RATE_PARENT flag in statically defined lcd clock in am335x.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
| | | |/ /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
am335x does not have freqsel, avoid it.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
|