Add OMAP5 SMP boot support using OMAP4 SMP code. The relevant code paths
are runtime checked using cpu id
Signed-off-by: R Sricharan <r.sricharan@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
OMAP4 and OMAP5 share same WakeupGen IP with below few udpates on OMAP5.
- Additional 32 interrupt support is added w.r.t OMAP4 design.
- The AUX CORE boot registers are now made accessible from non-secure SW.
- SAR offset are changed and PTMSYNC* registers are removed from SAR.
Patch updates the WakeupGen code accordingly.
Signed-off-by: R Sricharan <r.sricharan@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
The l3 interconnect ip is same for OMAP4 and OMAP5.
So reuse the l3 error handler error code for OMAP5
as well. Also a few targets has been newly added for
OMAP5. So updating the driver for that here.
Signed-off-by: R Sricharan <r.sricharan@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
GPMC module is the same as in OMAP4.
Just update the base address and irq number.
Signed-off-by: R Sricharan <r.sricharan@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Adding the Initialisaton for clocksource and clockevent device
on OMAP5 Socs.
Signed-off-by: R Sricharan <r.sricharan@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
OMAP5430 is Texas Instrument's SOC based on ARM Cortex-A15 SMP
architecture. It's a dual core SOC with GIC used for interrupt
handling and with an integrated L2 cache controller.
OMAP5432 is another variant of OMAP5430, with a
memory controller supporting DDR3 and SATA.
Patch includes:
- The machine specific headers and sources updates.
- Platform header updates.
- Minimum initialisation support for serial.
- IO table init
Signed-off-by: R Sricharan <r.sricharan@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Adding the OMAP5 ES1.0, 2.0 and OMAP5432 cpu revision
detection support.
Signed-off-by: R Sricharan <r.sricharan@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
With omap_hwmod_get_main_clk() now available, this can be passed to
clk_get() to extract the fclk and thus avoid construction of fclk name.
Corrected the timer fck name mis-match between clock44xx_data.c and
omap_hwmod_44xx_data.c. For other platforms this is already taken care.
Cc: Cousson, Benoit <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Commit ac5b0ea3d (Merge tag 'omap-devel-f-for-3.6'...) had a merge
conflict that somehow got incorrecly resolved in a lossy way for
commit bed9d1bb (ARM: OMAP2+: hwmod: add omap_hwmod_get_main_clk() API).
Fix the issue by applying the missing pieces.
Reported-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
The function __omap2_set_globals() can be common across all
platforms/architectures, even in case of omap4, internally it
calls same set of functions as in __omap2_set_globals() function
(except for sdrc).
This patch adds new config flag SOC_HAS_OMAP2_SDRC to handle sdrc,
so that we can reuse same function across omap2/3/4...
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
As per recent discussion on the linux-omap list, we are
moving in the direction where, we will have only architecture,
ARCH_OMAP2PLUS and all devices/platforms will be treated
as a SoC underneath.
So the first step in this direction is to adopt this change
for all new devices getting in, converting
cpu_is_am33xx/335x() ==> soc_is_am33xx/335x()
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Initially, we decided to make am33xx family of device to fall
under omap3 class (cpu_is_omap34xx() = true), since it carries
Cortex-A8 core. But while adding complete baseport support
(like, clock, power and hwmod) support, it is observed that,
we are creating more and more problems by treating am33xx device
as omap3 family, as nothing matches between them
(except cortex-A8 mpu).
So, after long discussion we have came to the conclusion that,
we should not consider am33xx device as omap3 family, instead
create separate class (SOC_AM33XX) under OMAP2PLUS.
This means, for am33xx device, cpu_is_omap34xx() will return false,
and only cpu_is_am33xx() will be true.
Please refer to the link below, for mailing-list discussion on this -
http://www.spinics.net/lists/linux-omap/msg69439.html
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
[tony@atomide.com: fixed typo, updated for soc_is changes]
Signed-off-by: Tony Lindgren <tony@atomide.com>
In order to remove unnecessary idefs, move noncore and core
dpll ops to dpll3xxx.c file (where it should have been already).
The clkops (clkops_omap3_core_dpll_ops & clkops_omap3_noncore_dpll_ops)
is used in clock data files, and dependency is already handled by
Makefile rule.
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Acked-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
for 3.6. Mostly small infrastructure improvements, and preparation
for OMAP5 and AM33xx code.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJP9F5FAAoJEMePsQ0LvSpLocAP/00cPRZ+sOrZO6KYjoh84AwB
mMfJd2QKhqwe19nBfPoGL3F+bClM5x9yIgX2pT2X46kJ25DqLcIDUnUeKydo/euF
qON+8n2E2Z24iaiLnQvSLYyIJokTX+81l+RmddGYkT2Go8KT6U6XRcOnQ1J/kkIC
Z9rkHkMtzL7wAtYUBcZktlEMw8PKzcLAayCSQsPQ4Q757JHONijtJFID24UyQQPQ
azsuL4bxUJ5zhSeVjJRmCE7sFWbTgJ6vztMm/d1bc/TH4X7dFNKwhKIuZsMrAMBf
fzf+lyB/UFX7CCt7oqQs8E3mX0E9B2ijq5WCal4SSLf7piLIIHxIpTT9LGAzO/of
zYhRA3hY4o/HsaDmgsYxHZAPYGZoODosI93bYBVxBW2qZceYZ1j3nUfd0dY+AkCe
Nm0L1TWeBhVG0oX3fP8bqTTxyiMCn4eDUUAUe002oJrsEFkeUb1+lAvTNoibXyns
rQ9uQjbtR53V8nHT62sYcORxKdfUxGoDT3KFp2CHtKf/agjsuUe6JqP0Z3IkeYvT
nmd+vUmO7D4delpbsT4OIt7vzmXCzTr6qB0hZIyXitFqQHlz9bBO4Fdow51CG+0V
PNykHS9tfU7Ioe0bOMm9MhqjicbbxAJOc1Y4bBh8JGsNDsnfIAm9ZjHEjq7td/yz
sZnZqUUrQHSB5EHBW5LU
=sy5d
-----END PGP SIGNATURE-----
Merge tag 'omap-devel-f-for-3.6' of git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into cleanup-part2
Miscellaneous OMAP clock, hwmod, clockdomain, and powerdomain patches
for 3.6. Mostly small infrastructure improvements, and preparation
for OMAP5 and AM33xx code.
Conflicts:
arch/arm/mach-omap2/omap_hwmod.c
arch/arm/plat-omap/include/plat/omap_hwmod.h
The DMADISABLE bit is a semi-automatic bit present in sysconfig register
of some modules. When the DMA must perform read/write accesses, the
DMADISABLE bit is cleared by the hardware. But when the DMA must stop for power
management, software must set the DMADISABLE bit back to 1.
In cases where the ROMCODE/BOOTLOADER uses dma, the hardware clears the
DMADISABLE bit (but the romcode/bootloader might not set it back to 1).
In order for the kernel to start in a clean state, it is
necessary for the kernel to set DMADISABLE bit back to 1 (irrespective
of whether it's been set to 1 in romcode or bootloader).
During _reset of the (hwmod)device, the DMADISABLE bit is set so that it
does not prevent idling of the system. (NOTE: having DMADISABLE to 0,
prevents the system to idle)
DMADISABLE bit is present in usbotgss module of omap5.
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
[paul@pwsan.com: updated to apply; fixed checkpatch warnings]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Some prm and cm registers read/write and status functions
are built only for some custom OMAP2+ builds and are stubbed
in header files for other builds under ifdef statements.
But this results in adding new CONFIG_ARCH_OMAPXXX
checks when SOCs are added in the future. So move them
to a common place for OMAP2+ and make them 'weak' implementations.
This way no new ifdefs would be required in the future and also
cleans up the existing code.
Signed-off-by: R Sricharan <r.sricharan@ti.com>
[paul@pwsan.com: unsplit quoted strings; moved PRM functions to
mach-omap2/prm_common.c; resolved sparse warnings]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Add an API to get main clock name associated with a given @oh.
This will avoid the need to construct fclk names during early
initialization in order to get fclk handle using clk_get().
Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
If the dpll is already locked, code can be optimized
to return much earlier than doing redundent set of lock mode
and wait on idlest.
Cc: Tony Lindgren <tony@atomide.com>
Cc: Jon Hunter <jon-hunter@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Mike Turquette <mturquette@ti.com>
Signed-off-by: Vikram Pandita <vikram.pandita@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
The register is used to configure the behaviour of the CSI-2 and CCP-2
receivers. This register is available only in OMAP3630.
The original patch was submitted by Vimarsh Zutshi.
Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi>
Cc: Vimarsh Zutshi <vimarsh.zutshi@gmail.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
The wake-up power domain is an alway-on power domain and so this power domain
does not have a power state status (PM_PWSTST_xxx) register that indicates the
current state. However, during the registering of the wake-up power domain the
state of the domain is queried by calling pwrdm_read_pwrst(). This actually
tries to read a register that does not exist and returns a value of 0 that
indicates that the current state is OFF. The OFF state count of the wake-up
power domain is then set to 1 and the current state to OFF. Both of which are
incorrect.
To fix this, if a power domain only supports the ON state, do not attempt to
read the power state status register and simply return ON as the current power
state.
This is based upon Tony's current linux-omap master branch.
Testing:
- Boot tested on OMAP4460 panda.
- Boot tested on OMAP3430 beagle and validated CORE RET still working (using
Paul's 32k timer patch [1]).
[1] http://marc.info/?l=linux-omap&m=134000053229888&w=2
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
[paul@pwsan.com: edited commit message slightly]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
For OMAP3+ devices, the clock domains (CLKDMs) support one or more of the
following transition modes ...
NO_SLEEP (0x0) - A clock domain sleep transition is never initiated,
irrespective of the hardware conditions.
SW_SLEEP (0x1) - A software-forced sleep transition. The transition is initiated
when the associated hardware conditions are satisfied
SW_WKUP (0x2) - A software-forced clock domain wake-up transition is initiated,
irrespective of the hardware conditions.
HW_AUTO (0x3) - Hardware-controlled automatic sleep and wake-up transition is
initiated by the PRCM module when the associated hardware
conditions are satisfied.
For OMAP4 devices, SW_SLEEP is equivalent to HW_AUTO and NO_SLEEP is equivalent
to SW_WKUP. The only difference between HW_AUTO and SW_SLEEP for OMAP4 devices
is that the PRM_IRQSTATUS_MPU.TRANSITION_ST interrupt status is set in case of
SW_SLEEP transition, and not set in case of HW_AUTO transition.
For OMAP4 devices, all CLKDMs support HW_AUTO and therefore we can place the
CLKDMs in the HW_AUTO state instead of the SW_SLEEP mode. Hence, we do not
need to use the SW_SLEEP mode. With regard to NO_SLEEP and SW_WKUP it is
preferred to use SW_WKUP mode if the CLKDM supports it and so use this mode
instead of NO_SLEEP where possible.
For a software perspective the above 4 modes are represented by the following
flags to indicate what modes are supported by each of the CLKDMs.
CLKDM_CAN_DISABLE_AUTO --> NO_SLEEP
CLKDM_CAN_ENABLE_AUTO --> HW_AUTO
CLKDM_CAN_FORCE_SLEEP --> SW_SLEEP
CLKDM_CAN_FORCE_WAKEUP --> SW_WKUP
By eliminating the SW_SLEEP mode the the mapping of the flags for OMAP4 devices
can becomes ...
CLKDM_CAN_DISABLE_AUTO --> NO_SLEEP
CLKDM_CAN_ENABLE_AUTO --> HW_AUTO
CLKDM_CAN_FORCE_SLEEP --> HW_AUTO
CLKDM_CAN_FORCE_WAKEUP --> SW_WKUP
Cc: Ming Lei <ming.lei@canonical.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@ti.com>
Reviewed-by: Benoit Cousson <b-cousson@ti.com>
Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
In case of AM33xx family of devices (like cpsw) have different sysc
bit field offsets defined,
sysc_type3:
| 3 2 | 1 0 |
| STDBYMODE | IDLEMODE |
So introduce new sysc_type3 in omap_hwmod common data.
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
hwmod, clock, and System Control Module cleanup, and the removal
of the last instance of omap_read/write usage for omap2+ with
the removal of unused USB OHCI Full Speed driver support. The
removed OHCI is only currently used for omap1 as the actively
used omap2+ boards have either MUSB or another instance of
OHCI+EHCI that's more usable.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJP8AYmAAoJEBvUPslcq6VzH2sP/0QlWA9Xl31AnGUgKJ3p5W3A
mjtLf9jHicOisSfYiEnuePHKwLnw7HZniI0xNcHXnFpRcDsxK8q2bmuFVpmqpIBv
OaCTfnOY+hpZR0/sLRQrKRZF13zYiro40StrhgxrSUV6cGwky+fJx/63J3j16NeV
TJkX4FjJXdAiGi/E7v+5XmQn3rpfcjntaDZgGSravVv1U1kYMMfN/2lHAvrALS+w
c8xqommerOnSp0IfjAtPeLnDdgdDXDxSq7MRGyDbNmxffjDR/leTC7j1xl0j0S+O
PSSvUa8aypeBWo9ckH77sXgiaAaMxVLu/X4ksPDijDdBkHsuQSffuj4swJP9B3d5
4d0ryvBqJhfvvgnL6a3emYhiZXgdbYbnerA+smm1Hf5VhGt5BWvZkJgS2RBUWLdW
j4OsaSI+vGhsYFjINNZ6QY3S1OeolGb8qBjNVHN0XsUg/tQPQZCMIjm2Zl+OM7Ex
60mtVoNysA0VKl/bzQ9jH6BwAYkcKli8bHDrvHm5a73DunVrCOG7TmKM4g108kvo
ccVCcEb3XEuqOfi+Nk6MSUQcHc1TkeDeAA9OtoFSi5hYwEh19w7UotRpsAVw2/Qe
D+Rrm4QvfUrDYKRfbj6LRaNRxkgvVnqJ5mC1SyiIbuLLjkZPJDomMATOZ66dYNUi
/tUf+6znwg+Iki+8rlhx
=A9qD
-----END PGP SIGNATURE-----
mergetag object c59b537d87
type commit
tag omap-devel-dmtimer-for-v3.6
tagger Tony Lindgren <tony@atomide.com> 1341130362 -0700
Here are some omap dmtimer changes to make it easier to add
device tree support for dmtimer by simplifying the platform
data structure used by dmtimr.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJP8AbkAAoJEBvUPslcq6Vz46YQAJZ7dWwSKHSQjuIx2j9iloi6
zIgvX8secC8yrli88I27fcAB7qGI9fulebEGQXCu7s3OzHI3/FO1KTAMdW31y4it
6WUkdWkSHfFtFiOcRjR9QTEuQ58Fii550iVcn8qezDizYfnd6ThwPHhhZek39oJC
qSzb2jqvvHgVuMPqpXkCDmQnH3JoEqGZ2Qg+JlyuW9mMmq3ipK7BTY9vLIcCPvdu
ET0rBvSmTr7s/XBMtDLseCHD3XsgnQ8dY0i7j3BWtCSkNjz2DFhj4zXL3/3f+ff6
KCIrkY5CK1R4x4vithXyLpqgniwj66eOOHdnL78iV4Am7jQrbIyvC9k5LeQE28XD
QgB718tO8UVRfAKmA9/zAwLJUN4lg8OUw2PrCBPxy4GXxY0Wu670gD+AqtSEwqV8
8ifOEltLO/46jb/zdBFvNJ+69C0XZdSN48SpdZbGzVVaNMxWprSGxF3hdf8EnbjF
/0F0A8dCtgMcIDgr+hUkSSM+AVVzlxr9imvATsAFTLlgq3G8LQ4bGSh/ywuNN5jn
Ql5ZkuxBVIWwWcd68vCKQVH/X/mPj6jtmz1qRZZTOCbV7oM8/YVQP37tkn6jk+xl
2ZCUrggvUcDYxVx0N1Eb4Yixje4BsrMPFn0zVjKSTzVMpYobxqVuNYPFfZ7ROJnf
caxP57fcIOC3pYp4VYtq
=L0+0
-----END PGP SIGNATURE-----
mergetag object 6fd8246b1c
type commit
tag omap-devel-am33xx-for-v3.6
tagger Tony Lindgren <tony@atomide.com> 1341131157 -0700
Here are changes to add support for am33xx processors for the
clock, power, and voltagedomains.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJP8Am6AAoJEBvUPslcq6VzhVsP/31PxWaX0JboIbAP0VlmJ+GK
J9gIxs2ohx3fDcx4D3da7rLlDue4E0oKmftbj0G4Iom22si2HrtmCnkq41anOkDA
UA9hW8kYfQJr90BzHYuIvOncpb6w6mzjJu7QDSO3j2l1FssoG+rOcDrW0EUSdzhF
1pIaGairntUAsI/EE3Ja6r0reRgacV4CmWksatp3mzxpbyA2+m2zJj8IovY1ghPZ
jq3zcLm4LCxDyiCDYcz6Jrt9fH9OA2cEQ/q0gHKspHvr2lsRu7gzN5gvi+700oML
vIT42/rC6tppf72113arZ+vKluJfa9LhgD0G7JcDqCyRxmwe0w3cKZKWrVklolsZ
sHATYxliWk4gB+pipw8W/hEHKGKPgPEPEAd60RN3g3/SDBo/fcQKvsF5/sZldC70
ngagTSseCKGUOQxWJ1+eRqG+I5WIzgorunNIbN/N9dGyxQ3C+zDAgDbdar24sWFn
1bA1wH7iwEYaqGOCEKfwodl+tSGAeuVXm4e2fR81sHRYY6eIFCKCdExZ/DPJrFTt
FnbV2OgKKz9xYcw6MNmfVEk3TkMSNwFO+g+EtzM1km5oW6PIxkGoiDydxHGvN3fq
gWfv7Y7AJCnbiqKBSahE1WkVADXYTlXk1ySzjHluPXJmqh/iUYDmpKKMYEFQYgyg
ekpI3teAadGhu5ZIrqG5
=bc0b
-----END PGP SIGNATURE-----
Merge tags 'omap-cleanup-for-v3.6', 'omap-devel-dmtimer-for-v3.6' and 'omap-devel-am33xx-for-v3.6' into devel-am33xx-part2
OMAP4470 currently fails to boot, printing various messages such as ...
omap_hwmod: mpu: cannot clk_get main_clk dpll_mpu_m2_ck
omap_hwmod: mpu: cannot _init_clocks
------------[ cut here ]------------
WARNING: at arch/arm/mach-omap2/omap_hwmod.c:2062 _init+0x2a0/0x2e4()
omap_hwmod: mpu: couldn't init clocks
Modules linked in:
[<c001c7fc>] (unwind_backtrace+0x0/0xf4) from [<c0043c64>] (warn_slowpath_common+0x4c/0x64)
[<c0043c64>] (warn_slowpath_common+0x4c/0x64) from [<c0043d10>] (warn_slowpath_fmt+0x30/0x40)
[<c0043d10>] (warn_slowpath_fmt+0x30/0x40) from [<c0674208>] (_init+0x2a0/0x2e4)
[<c0674208>] (_init+0x2a0/0x2e4) from [<c067428c>] (omap_hwmod_setup_one+0x40/0x60)
[<c067428c>] (omap_hwmod_setup_one+0x40/0x60) from [<c0674280>] (omap_hwmod_setup_one+0x34/0x60)
[<c0674280>] (omap_hwmod_setup_one+0x34/0x60) from [<c06726f4>] (omap_dm_timer_init_one+0x30/0x250)
[<c06726f4>] (omap_dm_timer_init_one+0x30/0x250) from [<c0672930>] (omap2_gp_clockevent_init+0x1c/0x108)
[<c0672930>] (omap2_gp_clockevent_init+0x1c/0x108) from [<c0672c60>] (omap4_timer_init+0x10/0x5c)
[<c0672c60>] (omap4_timer_init+0x10/0x5c) from [<c066c418>] (time_init+0x20/0x30)
[<c066c418>] (time_init+0x20/0x30) from [<c0668814>] (start_kernel+0x1b0/0x304)
[<c0668814>] (start_kernel+0x1b0/0x304) from [<80008044>] (0x80008044)
---[ end trace 1b75b31a2719ed1c ]---
The problem is that currently none of the clocks are being registered for
OMAP4470 devices and so on boot-up no clocks can be found and the kernel panics.
This fix allows the kernel to boot without failure using a simple RAMDISK file
system on OMAP4470 blaze board.
Per feedback from Paul and Benoit the 4470 clock data is incomplete for new
modules such as the 2D graphics block that has been added to the 4470.
Therefore add a warning to indicate that the clock data is incomplete.
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
[tony@atomide.com: updated comments]
Signed-off-by: Tony Lindgren <tony@atomide.com>
commit 8259573b (ARM: OMAP2+: nand: Make board_onenand_init() visible
to board code) broke the build for configs with OneNAND disabled. By
removing the static in the header file, it created a duplicate definition
in the .c and the .h files, resuling in a build error:
/work/kernel/omap/dev/arch/arm/mach-omap2/board-flash.c:102:111: error: redefinition of 'board_onenand_init'
/work/kernel/omap/dev/arch/arm/mach-omap2/board-flash.h:56:51: note: previous definition of 'board_onenand_init' was here
make[2]: *** [arch/arm/mach-omap2/board-flash.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [arch/arm/mach-omap2] Error 2
make: *** [sub-make] Error 2
Fix this by removing the duplicate dummy entry from the C file.
Cc: Enric Balletbò i Serra <eballetbo@gmail.com>
Cc: Javier Martinez Canillas <javier@dowhile0.org>
Signed-off-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
reset. All of them are regression fixes, except for the missing omap2
interrupt controller binding that somehow got missed earlier.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJP40b1AAoJEBvUPslcq6Vz9iUP/0JUq0xvUEctn9HMOx4xt4Iz
MYC4DSwdUk9AHdbfzQSxHHHIYULjXJDtO0WlAgt9wHNG4lSHQHEG7XTTvpkWbyaQ
fzIQG/U7xW37HjHTS/v2JFftr/ZaF3gE4e1hcu+GJmUifACR5MBkfOPhqmJDqku2
eN4suYTUoV4Ey4Ijh+bc/T6XKFFyg0YaxyAKaMRpLQKhDK/Ihy8pyA/3+ggLCbnT
2U/ZszJgbc34N9VEYG2kLvz+JVVtG6JzHjI4Oa7wQQ9UpsK/NVWhbZ/F/0yjjyuw
TWWUFSxOIrU+/i1G2Bz1NS4rniCAnNlAMsodmrRbSRgJLItIjdILPV/apX5N8WRL
bus3kV/2I7C1OwbCqiXBCXXQlPZmMzTLhQyQWs6bGhjtmVdpVpoolE4Wgk4okxWJ
eBDh10xmTHwoYh/y3wAcN7q3s1A6cNj6Vl0+nnUFIfTo2w6ca4znLjZUvhVEBkNg
wufARvMP1o1YBRN9yS9wlFsLdVS3J+ALu/+zbHeJKWIzPXSaHLfrVTNSCpb3iHEX
3ZXMPooFjpP23ZYJoi8eILaBP6mD+3vD9eM0PYJYeL181Huihk8i8rQYZDbLQbCL
avWZAyfgul4Pcg48IlStsjE3pBnr0HZ6WPP8T8TCg6oqS19dKqjSG/Jwv1+iuNo6
GQuu/hCsFjrJ3YOBgcDj
=cMPJ
-----END PGP SIGNATURE-----
Merge tag 'omap-fixes-for-v3.5-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes
From Tony Lindgren:
"Here are a few fixes with the biggest one being fix for Beagle DVI
reset. All of them are regression fixes, except for the missing omap2
interrupt controller binding that somehow got missed earlier."
* tag 'omap-fixes-for-v3.5-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
ARM: OMAP: Fix Beagleboard DVI reset gpio
arm/dts: OMAP2: Fix interrupt controller binding
ARM: OMAP2: Fix tusb6010 GPIO interrupt for n8x0
ARM: OMAP2+: Fix MUSB ifdefs for platform init code
As per the OMAP4 documentation, audio over HDMI must be transmitted in
no-idle mode. This patch adds the HWMOD_SWSUP_SIDLE so that omap_hwmod uses
no-idle/force-idle settings instead of smart-idle mode.
This is required as the DSS interface clock is used as functional clock
for the HDMI wrapper audio FIFO. If no-idle mode is not used, audio could
be choppy, have bad quality or not be audible at all.
Signed-off-by: Ricardo Neri <ricardo.neri@ti.com>
[b-cousson@ti.com: Update the subject and align the .flags
location with the script template]
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Commit bbd707acee ("ARM: omap2: use
machine specific hook for late init") resulted in the addition of this
sparse warning:
arch/arm/mach-omap2/mux.c:791:12: warning: symbol 'omap_mux_late_init' was not declared. Should it be static?
Fix by including the header file containing the prototype.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Tony Lindgren <tony@atomide.com>
Increase the timeout for disabling an IP block to five milliseconds.
This is to handle the usb_host_fs idle latency, which takes almost
four milliseconds after a host controller reset.
This is the second of two patches needed to resolve the following
boot warning:
omap_hwmod: usb_host_fs: _wait_target_disable failed
Thanks to Sergei Shtylyov <sshtylyov@mvista.com> for finding
an unrelated hunk in a previous version of this patch.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Sergei Shtylyov <sshtylyov@mvista.com>
Cc: Tero Kristo <t-kristo@ti.com>
Until the OMAP4 code is converted to disable the use of the clock
framework-based clockdomain enable/disable sequence, any clock used as
a hwmod main_clk must have a clockdomain associated with it. This
patch populates some clock structure clockdomain names to resolve the
following warnings during kernel init:
omap_hwmod: dpll_mpu_m2_ck: missing clockdomain for dpll_mpu_m2_ck.
omap_hwmod: trace_clk_div_ck: missing clockdomain for trace_clk_div_ck.
omap_hwmod: l3_div_ck: missing clockdomain for l3_div_ck.
omap_hwmod: ddrphy_ck: missing clockdomain for ddrphy_ck.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Benoît Cousson <b-cousson@ti.com>
The 32k sync timer IP block target idle modes in the hwmod data are
incorrect. The IP block does not support any smart-idle modes.
Update the data to reflect the correct modes.
This problem was initially identified and a diff fragment posted to
the lists by Benoît Cousson <b-cousson@ti.com>. A patch description
bug in the first version was also identified by Benoît.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Tero Kristo <t-kristo@ti.com>
If an IP is configured in Smart-Standby-Wakeup, when disabling wakeup feature the
IP will not go back to Smart-Standby, but will remain in Smart-Standby-Wakeup.
Signed-off-by: Djamil Elaidi <d-elaidi@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Commit e813a55eb9 ("OMAP: board-files:
remove custom PD GPIO handling for DVI output") moved TFP410 chip's
powerdown-gpio handling from the board files to the tfp410 driver. One
gpio_request_one(powerdown-gpio, ...) was mistakenly left unremoved in
the Beagle board file. This causes the tfp410 driver to fail to request
the gpio on Beagle, causing the driver to fail and thus the DVI output
doesn't work.
This patch removes several boot errors from board-omap3beagle.c:
- gpio_request: gpio--22 (DVI reset) status -22
- Unable to get DVI reset GPIO
There is a combination of leftover code and revision confusion.
Additionally, xM support is currently a hack.
For original Beagleboard this removes the double initialization of GPIO
170, properly configures it as an output, and wraps the initialization
in an if block so that xM does not attempt to request it.
For Beagleboard xM it removes reference to GPIO 129 which was part
of rev A1 and A2 designs, but never functioned. It then properly assigns
beagle_dvi_device.reset_gpio in beagle_twl_gpio_setup and removes the
hack of initializing it high. Additionally, it uses
gpio_set_value_cansleep since this GPIO is connected through i2c.
Unfortunately, there is no way to tell the difference between xM A2 and
A3. However, GPIO 129 does not function on rev A1 and A2, and the TWL
GPIO used on A3 and beyond is not used on rev A1 and A2, there are no
problems created by this fix.
Tested on Beagleboard-xM Rev C1 and Beagleboard Rev B4.
Signed-off-by: Russ Dill <Russ.Dill@ti.com>
Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Here's one more gpio_to_irq conversion that we missed
earlier. Tested with n800 in gadget mode using USB_ETH.
Cc: Felipe Balbi <balbi@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Commit 62285963 (usb: musb: drop a gigantic amount of ifdeferry)
got rid of a bunch of ifdefs in the MUSB code. Looks like the
platform init code is still using these dropped defines though,
which in many cases results the board defaulting always to host
mode.
Currently the situation is that USB_MUSB_HDRC is the main
Kconfig option with additional USB_GADGET_MUSB_HDRC so only
these two should be used to select between host and OTG mode.
Fix the situation for omaps. The following users should fix the
platform init code in a similar way:
Dropped Kconfig option Current users
USB_MUSB_OTG blackfin, davinci, not in Kconfigs
USB_MUSB_PERIPHERAL davinci, not in Kconfigs
USB_MUSB_HOST davinci, not in Kconfigs
USB_MUSB_HDRC_HCD blackfin, not in Kconfigs
USB_MUSB_OTG blackfin, not in Kconfigs
Cc: Mike Frysinger <vapier@gentoo.org>
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: linux-usb@vger.kernel.org
Cc: Felipe Balbi <balbi@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Remove prm_clkdm and cm_clkdm and allow hwmods to have no clockdomain.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Remove the existing alias for pad_fck, prcm_fck from the clock data and
add them as opt_clks to the hwmod data.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Remove the existing alias for pad_fck, prcm_fck from the clock data and
add them as opt_clks to the hwmod data.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Remove the existing alias for pad_fck, prcm_fck from the clock data and
add them as opt_clks to the hwmod data.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Provide an interface for a driver to call SCM functions to
set a boot address and boot mode.
Signed-off-by: Omar Ramirez Luna <omar.luna@linaro.org>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
SCM contains boot addr and boot mode registers to control
other processors on different OMAP versions. It controls the
boot address and mode for DSP based subsystems like: IVA 2.1
(OMAP2430), IVA 2.2 (OMAP3) and DSP (OMAP4).
If contained within SCM registers, when a processor is
booting it uses BOOTADDR to start running the code at that
location. BOOTMOD register specifies a different set of
modes for the processor to execute when booting (from direct,
idle, self-loop, user and default).
Since there was no offset associated with OMAP4, this patch
defines it.
Signed-off-by: Omar Ramirez Luna <omar.luna@linaro.org>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Rather than use runtime cpu_is* checking inside _init_clkdm, initialize
SoC specific function pointer at init time.
Signed-off-by: Kevin Hilman <khilman@ti.com>
[paul@pwsan.com: convert to use soc_ops function pointers; remove second para
from commit message since soc_ops function pointers are now set during hwmod
layer init]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Rather than using cpu_is* checking at runtime, initialize SoC specific
function pointers for the various hard reset functions at init time.
Signed-off-by: Kevin Hilman <khilman@ti.com>
[paul@pwsan.com: convert to use soc_ops function pointers; add kerneldoc]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Rather than using cpu_is* checking at runtime, initialize an SoC specific
function pointer for wait_target_ready().
While here, downgrade the BUG() to a WARN_ON() so it gives a noisy
warning instead of causing a kernel panic.
Signed-off-by: Kevin Hilman <khilman@ti.com>
[paul@pwsan.com: convert to use soc_ops function pointers; add kerneldoc;
move soc_ops functions to their own section in the code; integrated
the _wait_target_ready() function with the OMAP2/OMAP4 variants;
renamed the wait_module_ready field to wait_target_ready]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
_omap4_wait_target_disable() is called only from inside _omap4_disable_module()
which is already protected by SoC specific checks. Remove the cpu_is check
here.
Signed-off-by: Kevin Hilman <khilman@ti.com>
Santosh Shilimkar