Merge branch 'platform-ti-linux-3.14.y' into pm-ti-linux-3.14.y
Conflicts:
arch/arm/common/edma.c
arch/arm/mach-omap2/Makefile
drivers/regulator/palmas-regulator.c
include/dt-bindings/pinctrl/am43xx.h
include/linux/mfd/palmas.h
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Conflicts:
arch/arm/common/edma.c
arch/arm/mach-omap2/Makefile
drivers/regulator/palmas-regulator.c
include/dt-bindings/pinctrl/am43xx.h
include/linux/mfd/palmas.h
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
ARM: OMAP2+: pm33xx: Fix RTC wakeup src handling
Once we enable EXT_WAKEUP in the RTC_PMIC register all wakeup events
report as EXT_WAKEUP because the RTC_WAKEUP line on the SOC is connected
to the nWAKEUP signal of the PMIC which generates an event on any PMIC
power on event, whether it is a pushbutton wake or PMIC_PWR_EN change
from RTC alarm event.
Previously we check the RTC_PMIC register to determine the wakeup source
but now we can just check the RTC_STATUS register to see if RTC_ALARM1
status bit is set, and if it is report RTC_ALARM as wake source,
otherwise report another EXT_WAKEUP.
This is important not only for reporting the correct wake source but
also making sure that the RTC IRQ is set for retrigger_irq in
am33xx_pm_end, otherwise the ALARM1 status does not get cleared and if
an RTC mode transition is made with out using rtcwake (with the
intention of using PB to wake) the board will immediately wake due to
ALARM1 status and fail to enter RTC mode.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Once we enable EXT_WAKEUP in the RTC_PMIC register all wakeup events
report as EXT_WAKEUP because the RTC_WAKEUP line on the SOC is connected
to the nWAKEUP signal of the PMIC which generates an event on any PMIC
power on event, whether it is a pushbutton wake or PMIC_PWR_EN change
from RTC alarm event.
Previously we check the RTC_PMIC register to determine the wakeup source
but now we can just check the RTC_STATUS register to see if RTC_ALARM1
status bit is set, and if it is report RTC_ALARM as wake source,
otherwise report another EXT_WAKEUP.
This is important not only for reporting the correct wake source but
also making sure that the RTC IRQ is set for retrigger_irq in
am33xx_pm_end, otherwise the ALARM1 status does not get cleared and if
an RTC mode transition is made with out using rtcwake (with the
intention of using PB to wake) the board will immediately wake due to
ALARM1 status and fail to enter RTC mode.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
ARM: OMAP2+: sleep43xx: Enable EXT_WAKEUP in RTC_PMIC register
We must set the EXT_WAKEUP_EN and EXT_WAKEUP_POL bits in the RTC_PMIC
register in order for pushbutton wake to work from RTC modes, otherwise
the PMIC will never see the PMIC_PWR_EN signal go high again and enter
off-mode after 20 seconds on boards that support RTC sleep modes.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
We must set the EXT_WAKEUP_EN and EXT_WAKEUP_POL bits in the RTC_PMIC
register in order for pushbutton wake to work from RTC modes, otherwise
the PMIC will never see the PMIC_PWR_EN signal go high again and enter
off-mode after 20 seconds on boards that support RTC sleep modes.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
ARM: OMAP2+: sleep33xx: Move RTC mode failure EMIF reenable to abort path
Previously, on an RTC mode abort, the EMIF reenable path followed the
DeepSleep EMIF restore path which assumes no MMU is active which will
not work, so we must use the abort path, which knows that the MMU is
still enabled and just reenables the EMIF rather than trying to restore
context which isn't needed in an abort.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Previously, on an RTC mode abort, the EMIF reenable path followed the
DeepSleep EMIF restore path which assumes no MMU is active which will
not work, so we must use the abort path, which knows that the MMU is
still enabled and just reenables the EMIF rather than trying to restore
context which isn't needed in an abort.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
ARM: OMAP2+: sleep33xx: Enable EXT_WAKEUP in RTC_PMIC register
We must set the EXT_WAKEUP_EN and EXT_WAKEUP_POL bits in the RTC_PMIC
register in order for pushbutton wake to work from RTC modes, otherwise
the PMIC will never see the PMIC_PWR_EN signal go high again and enter
off-mode after 20 seconds on boards that support RTC sleep modes.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
We must set the EXT_WAKEUP_EN and EXT_WAKEUP_POL bits in the RTC_PMIC
register in order for pushbutton wake to work from RTC modes, otherwise
the PMIC will never see the PMIC_PWR_EN signal go high again and enter
off-mode after 20 seconds on boards that support RTC sleep modes.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
drivers/rtc/rtc-omap.c: Enable power button wake after poweroff event
In order for the rtc to properly reassert PMIC_PWR_EN signal after
a power button event that occurs after the board has been shut off
with a poweroff command we must make sure we set the EXT_WAKEUP_EN
and EXT_WAKEUP_POL bits in the RTC_PMIC register. Otherwise the pmic
will never see the PMIC_PWR_EN signal go low again and enter off-mode
again after 20 seconds, causing the board to power off and remain off.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
In order for the rtc to properly reassert PMIC_PWR_EN signal after
a power button event that occurs after the board has been shut off
with a poweroff command we must make sure we set the EXT_WAKEUP_EN
and EXT_WAKEUP_POL bits in the RTC_PMIC register. Otherwise the pmic
will never see the PMIC_PWR_EN signal go low again and enter off-mode
again after 20 seconds, causing the board to power off and remain off.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
ARM: OMAP2+: pm33xx: Move rtc_write_scratch earlier suspend path
We should not use mutex protected rtc_write_scratch deep in the suspend
path so move the write to earlier during am33xx_pm_begin for rtc-only
path.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Reported-by: Felipe Balbi <balbi@ti.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Acked-by: Nishanth Menon <nm@ti.com>
We should not use mutex protected rtc_write_scratch deep in the suspend
path so move the write to earlier during am33xx_pm_begin for rtc-only
path.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Reported-by: Felipe Balbi <balbi@ti.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Acked-by: Nishanth Menon <nm@ti.com>
ARM: OMAP: Check for clocks which do not have parents
Timer12 for example on DRA7 is fed by internal 32k oscillator clock has no
parent. So check for similar cases and proceed without erring out.
Signed-off-by: Keerthy <j-keerthy@ti.com>
Reviewed-by: Suman Anna <s-anna@ti.com>
Timer12 for example on DRA7 is fed by internal 32k oscillator clock has no
parent. So check for similar cases and proceed without erring out.
Signed-off-by: Keerthy <j-keerthy@ti.com>
Reviewed-by: Suman Anna <s-anna@ti.com>
ARM: OMAP: DRA7: clockdomain: Implement timer workaround for errata i874
Errata: i874: TIMER5/6/7/8 interrupts not propagated
DESCRIPTION
When TIMER5, TIMER6, TIMER7, or TIMER8 clocks are enabled
(CM_IPU_TIMER5/6/7/8_CLKCTRL[0:1]MODULEMODE=0x2:ENABLE) and the CD-IPU is in HW_AUTO
mode (CM_IPU_CLKSTCTRL[0:1]CLKTRCTRL=0x3:HW_AUTO) the corresponding TIMER will continue
counting, but enabled interrupts will not be propagated to the destinations (MPU, DSP, etc) in the SoC
until the TIMER registers are accessed from the CPUs (MPU, DSP etc.). This can result in missed timer
interrupts.
WORKAROUND
In order for TIMER5/6/7/8 interrupts to be propagated and serviced correctly the CD_IPU domain should
be set to SW_WKUP mode (CM_IPU_CLKSTCTRL[0:1]CLKTRCTRL=0x2:SW_WKUP)
Acked-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
Tested-by: Aparna Balasubramanian <aparnab@ti.com>
Errata: i874: TIMER5/6/7/8 interrupts not propagated
DESCRIPTION
When TIMER5, TIMER6, TIMER7, or TIMER8 clocks are enabled
(CM_IPU_TIMER5/6/7/8_CLKCTRL[0:1]MODULEMODE=0x2:ENABLE) and the CD-IPU is in HW_AUTO
mode (CM_IPU_CLKSTCTRL[0:1]CLKTRCTRL=0x3:HW_AUTO) the corresponding TIMER will continue
counting, but enabled interrupts will not be propagated to the destinations (MPU, DSP, etc) in the SoC
until the TIMER registers are accessed from the CPUs (MPU, DSP etc.). This can result in missed timer
interrupts.
WORKAROUND
In order for TIMER5/6/7/8 interrupts to be propagated and serviced correctly the CD_IPU domain should
be set to SW_WKUP mode (CM_IPU_CLKSTCTRL[0:1]CLKTRCTRL=0x2:SW_WKUP)
Acked-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
Tested-by: Aparna Balasubramanian <aparnab@ti.com>
ARM: dts: DRA7: Add DT node for AES2 IP
DRA7 SoC has same two AES IPs as on OMAP4.
Add DT entries for the second core.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
DRA7 SoC has same two AES IPs as on OMAP4.
Add DT entries for the second core.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
ARM: DRA7: hwmod: Add data for AES2 IP
Adding hwmod data for AES2 IP.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Adding hwmod data for AES2 IP.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
crypto: omap-aes - Add support for multiple cores
Adapting driver to support multiple cores.
Using the last used device.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Adapting driver to support multiple cores.
Using the last used device.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
crypto: omap-aes - Fix registration of Algos
Algos can be registered only once. So skip registration of
algos if already registered.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Algos can be registered only once. So skip registration of
algos if already registered.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
crypto: omap-aes - Fix enabling clocks
Enable clocks for all cores before starting session.
Driver has to pic the aes core dynamically based on the queue length.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Enable clocks for all cores before starting session.
Driver has to pic the aes core dynamically based on the queue length.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
crypto: tcrypt - Added speed tests for Async AEAD crypto alogrithms
Adding simple speed tests for a range of block sizes for Async AEAD crypto
algorithms.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Adding simple speed tests for a range of block sizes for Async AEAD crypto
algorithms.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
crypto: omap-aes - Add support for GCM mode
OMAP AES hw supports aes gcm mode.
Adding support for GCM mode in omap-aes driver.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
OMAP AES hw supports aes gcm mode.
Adding support for GCM mode in omap-aes driver.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
crypto: omap-aes - Fix configuring of AES mode
AES_CTRL_REG is used to configure AES mode. Before configuring
any mode we need to make sure all other modes are reset or else
driver will misbehave. So write only the mode instead of using
a mask.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
AES_CTRL_REG is used to configure AES mode. Before configuring
any mode we need to make sure all other modes are reset or else
driver will misbehave. So write only the mode instead of using
a mask.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
crypto: omap-aes - Add support for lengths not aligned with AES_BLOCK_SIZE
OMAP AES driver return an error if the data is not aligned with 16 bytes.
But OMAP AES hw allows data input upto 1 byte aligned.
Adding support for inputs not aligned with AES_BLOCK_SIZE.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
OMAP AES driver return an error if the data is not aligned with 16 bytes.
But OMAP AES hw allows data input upto 1 byte aligned.
Adding support for inputs not aligned with AES_BLOCK_SIZE.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
crypto: omap-des: Fix unmapping of dma channels
dma_unmap_sg() is being called twice after completing the
task. Looks like this is a copy paste error when creating
des driver.
With this the following warn appears during boot:
[ 4.210457] ------------[ cut here ]------------
[ 4.215114] WARNING: CPU: 0 PID: 0 at lib/dma-debug.c:1080 check_unmap+0x710/0x9a0()
[ 4.222899] omap-des 480a5000.des: DMA-API: device driver tries to free DMA memory it has not allocated [device address=0x00000000ab2ce000] [size=8 bytes]
[ 4.236785] Modules linked in:
[ 4.239860] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.14.39-02999-g1bc045a-dirty #182
[ 4.247918] [<c001678c>] (unwind_backtrace) from [<c0012574>] (show_stack+0x10/0x14)
[ 4.255710] [<c0012574>] (show_stack) from [<c05a37e8>] (dump_stack+0x84/0xb8)
[ 4.262977] [<c05a37e8>] (dump_stack) from [<c0046464>] (warn_slowpath_common+0x68/0x8c)
[ 4.271107] [<c0046464>] (warn_slowpath_common) from [<c004651c>] (warn_slowpath_fmt+0x30/0x40)
[ 4.279854] [<c004651c>] (warn_slowpath_fmt) from [<c02d50a4>] (check_unmap+0x710/0x9a0)
[ 4.287991] [<c02d50a4>] (check_unmap) from [<c02d5478>] (debug_dma_unmap_sg+0x90/0x19c)
[ 4.296128] [<c02d5478>] (debug_dma_unmap_sg) from [<c04a77d8>] (omap_des_done_task+0x1cc/0x3e4)
[ 4.304963] [<c04a77d8>] (omap_des_done_task) from [<c004a090>] (tasklet_action+0x84/0x124)
[ 4.313370] [<c004a090>] (tasklet_action) from [<c004a4ac>] (__do_softirq+0xf0/0x20c)
[ 4.321235] [<c004a4ac>] (__do_softirq) from [<c004a840>] (irq_exit+0x98/0xec)
[ 4.328500] [<c004a840>] (irq_exit) from [<c000f9ac>] (handle_IRQ+0x50/0xb0)
[ 4.335589] [<c000f9ac>] (handle_IRQ) from [<c0008688>] (gic_handle_irq+0x28/0x5c)
Removing the duplicate call to dma_unmap_sg().
Reported-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
dma_unmap_sg() is being called twice after completing the
task. Looks like this is a copy paste error when creating
des driver.
With this the following warn appears during boot:
[ 4.210457] ------------[ cut here ]------------
[ 4.215114] WARNING: CPU: 0 PID: 0 at lib/dma-debug.c:1080 check_unmap+0x710/0x9a0()
[ 4.222899] omap-des 480a5000.des: DMA-API: device driver tries to free DMA memory it has not allocated [device address=0x00000000ab2ce000] [size=8 bytes]
[ 4.236785] Modules linked in:
[ 4.239860] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.14.39-02999-g1bc045a-dirty #182
[ 4.247918] [<c001678c>] (unwind_backtrace) from [<c0012574>] (show_stack+0x10/0x14)
[ 4.255710] [<c0012574>] (show_stack) from [<c05a37e8>] (dump_stack+0x84/0xb8)
[ 4.262977] [<c05a37e8>] (dump_stack) from [<c0046464>] (warn_slowpath_common+0x68/0x8c)
[ 4.271107] [<c0046464>] (warn_slowpath_common) from [<c004651c>] (warn_slowpath_fmt+0x30/0x40)
[ 4.279854] [<c004651c>] (warn_slowpath_fmt) from [<c02d50a4>] (check_unmap+0x710/0x9a0)
[ 4.287991] [<c02d50a4>] (check_unmap) from [<c02d5478>] (debug_dma_unmap_sg+0x90/0x19c)
[ 4.296128] [<c02d5478>] (debug_dma_unmap_sg) from [<c04a77d8>] (omap_des_done_task+0x1cc/0x3e4)
[ 4.304963] [<c04a77d8>] (omap_des_done_task) from [<c004a090>] (tasklet_action+0x84/0x124)
[ 4.313370] [<c004a090>] (tasklet_action) from [<c004a4ac>] (__do_softirq+0xf0/0x20c)
[ 4.321235] [<c004a4ac>] (__do_softirq) from [<c004a840>] (irq_exit+0x98/0xec)
[ 4.328500] [<c004a840>] (irq_exit) from [<c000f9ac>] (handle_IRQ+0x50/0xb0)
[ 4.335589] [<c000f9ac>] (handle_IRQ) from [<c0008688>] (gic_handle_irq+0x28/0x5c)
Removing the duplicate call to dma_unmap_sg().
Reported-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
dmaenegine: edma: allow pause/resume for non-cyclic mode
The 8250_omap serial driver relies on dmaengine_pause() actually
pausing the DMA transfer. Before this patch dmaengine_pause() is
a NOP for non-cylic DMA transfers. This allowed the 8250_omap
driver to read DMA buffers while the DMA was still active,
resulting in lost serial data.
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: John Ogness <john.ogness@linutronix.de>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
The 8250_omap serial driver relies on dmaengine_pause() actually
pausing the DMA transfer. Before this patch dmaengine_pause() is
a NOP for non-cylic DMA transfers. This allowed the 8250_omap
driver to read DMA buffers while the DMA was still active,
resulting in lost serial data.
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: John Ogness <john.ogness@linutronix.de>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
ARM: common: edma: clear completion interrupts on stop
When stopping a DMA transfer with interrupts disabled it is possible
that the DMA transfer completes before the events are cleared. In
this case the completion interrupt will be pending, causing a
completion callback after the transfer was stopped.
By clearing the completion interrupt for the stopping channel it is
ensured that no completion event will be generated after the stop.
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: John Ogness <john.ogness@linutronix.de>
When stopping a DMA transfer with interrupts disabled it is possible
that the DMA transfer completes before the events are cleared. In
this case the completion interrupt will be pending, causing a
completion callback after the transfer was stopped.
By clearing the completion interrupt for the stopping channel it is
ensured that no completion event will be generated after the stop.
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: John Ogness <john.ogness@linutronix.de>
bus: omap_l3_noc: Fix master id address decoding for OMAP5
The L3 Error handling on OMAP5 for the most part is very similar
to that of OMAP4, and had leveraged common data structures and
register layout definitions so far. Upon closer inspection, there
are a few minor differences causing an incorrect decoding and
reporting of the master NIU upon an error:
1. The L3_TARG_STDERRLOG_MSTADDR.STDERRLOG_MSTADDR occupies
11 bits on OMAP5 as against 8 bits on OMAP4, with the master
NIU connID encoded in the 6 MSBs of the STDERRLOG_MSTADDR
field.
2. The CLK3 FlagMux component has 1 input source on OMAP4 and 3
input sources on OMAP5. The common DEBUGSS source is at a
different input on each SoC.
Fix the above issues by using a OMAP5-specific compatible property
and using SoC-specific data where there are differences.
Cc: Nishanth Menon <nm@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
The L3 Error handling on OMAP5 for the most part is very similar
to that of OMAP4, and had leveraged common data structures and
register layout definitions so far. Upon closer inspection, there
are a few minor differences causing an incorrect decoding and
reporting of the master NIU upon an error:
1. The L3_TARG_STDERRLOG_MSTADDR.STDERRLOG_MSTADDR occupies
11 bits on OMAP5 as against 8 bits on OMAP4, with the master
NIU connID encoded in the 6 MSBs of the STDERRLOG_MSTADDR
field.
2. The CLK3 FlagMux component has 1 input source on OMAP4 and 3
input sources on OMAP5. The common DEBUGSS source is at a
different input on each SoC.
Fix the above issues by using a OMAP5-specific compatible property
and using SoC-specific data where there are differences.
Cc: Nishanth Menon <nm@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: dts: am437x-sk-evm: Add DCDC5 and DCDC6
Add DCDC5 and DCDC6 to the tps65218 node for am437x-sk-evm and mark them
with regulator-suspend-enable in order to allow use of RTC+DDR mode.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Add DCDC5 and DCDC6 to the tps65218 node for am437x-sk-evm and mark them
with regulator-suspend-enable in order to allow use of RTC+DDR mode.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
ARM: dts: am437x-gp-evm: Add regulator-suspend-enable for RTC DCDCs
TPS65218 present on am437x-gp-evm has defined that DCDC5 and DCDC6 must
be removed from sequencer control in order for them to remain active
when PMIC_PWR_EN line is pulled low during a poweroff or RTC-mode
transition. Add regulator-suspend-enable flag to the corresponding
nodes to do this.
On A1 revision of the TPS65218, FSEAL bit would be undefined without
coin-cell present which in many cases led to it being set, causing DCDC5
and DCDC6 to stay active and allowing RTC-only mode to work but also
leading to unexplained failures when it was not. On B1 revision, FSEAL
is always 0 when no coin-cell is present so this patch is required on
boards with B1 revision to ever work. This implementation works on
boards with either A1 or B1 revision and makes sure that DCDC5 and DCDC6
always stay active.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
TPS65218 present on am437x-gp-evm has defined that DCDC5 and DCDC6 must
be removed from sequencer control in order for them to remain active
when PMIC_PWR_EN line is pulled low during a poweroff or RTC-mode
transition. Add regulator-suspend-enable flag to the corresponding
nodes to do this.
On A1 revision of the TPS65218, FSEAL bit would be undefined without
coin-cell present which in many cases led to it being set, causing DCDC5
and DCDC6 to stay active and allowing RTC-only mode to work but also
leading to unexplained failures when it was not. On B1 revision, FSEAL
is always 0 when no coin-cell is present so this patch is required on
boards with B1 revision to ever work. This implementation works on
boards with either A1 or B1 revision and makes sure that DCDC5 and DCDC6
always stay active.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
ARM: dts: am335x: Add rtc node as ti,system-power-controller
PMIC_PWR_EN pin of RTC on am335x-evm, bone, and boneblack is connected to
PMIC on board, so flag rtc node as ti,system-power-controller to allow
software to poweroff boards.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
PMIC_PWR_EN pin of RTC on am335x-evm, bone, and boneblack is connected to
PMIC on board, so flag rtc node as ti,system-power-controller to allow
software to poweroff boards.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
ARM: OMAP2+: prm44xx: Add context save and restore for am43xx
Add context save/restore of powerdomains to omap4_pwrdm_ops for use
by am437x during modes where PRCM loses context, like RTC+DDR mode.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Add context save/restore of powerdomains to omap4_pwrdm_ops for use
by am437x during modes where PRCM loses context, like RTC+DDR mode.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
ARM: OMAP2+: prm33xx: Fixup up pwrdm context restore
Currently when restoring context am33xx_pwrdm_wait_transition is always
called, however sometimes the powerdomain state does not need to change,
perhaps we only need to change memory retention states, so now let's make
sure the restored state is different from the current state before we wait
for a transition that will never happen and cause a timeout.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Currently when restoring context am33xx_pwrdm_wait_transition is always
called, however sometimes the powerdomain state does not need to change,
perhaps we only need to change memory retention states, so now let's make
sure the restored state is different from the current state before we wait
for a transition that will never happen and cause a timeout.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
ARM: OMAP2+: cminst44xx: Add context save/restore to am437x clkdms
Currently am437x does not save and restore context of clock domains
if PRCM loses context like during an RTC+DDR cycle. Based on
427aef89c720 ("ARM: OMAP2: Add functions to save and restore clockdomain
context en-masse.") and the cm33xx functions to cminst44xx.c so that
am437x can make use of the functionality.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Currently am437x does not save and restore context of clock domains
if PRCM loses context like during an RTC+DDR cycle. Based on
427aef89c720 ("ARM: OMAP2: Add functions to save and restore clockdomain
context en-masse.") and the cm33xx functions to cminst44xx.c so that
am437x can make use of the functionality.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
ARM: edma: Clear IRQ if we get interrupted by a unknown event
It looks like we can get an interrupt even when none of
the events that we're expecting occur. Make sure to
clear the IRQ in that case or else we occassionaly get
the following error at boot on am437x-sk-evm
[ 7.395763] irq 46: nobody cared (try booting with the "irqpoll" option)
[ 7.402499] CPU: 0 PID: 861 Comm: mmcqd/0 Not tainted 3.14.37-00337-g1b4e893 #1116
[ 7.410099] Backtrace:
[ 7.412588] [<c0011e84>] (dump_backtrace) from [<c0012020>] (show_stack+0x18/0x1c)
[ 7.420189] r6:0000002e r5:00000000 r4:00000000 r3:00000000
[ 7.425910] [<c0012008>] (show_stack) from [<c0600e4c>] (dump_stack+0x78/0x94)
[ 7.433178] [<c0600dd4>] (dump_stack) from [<c007b0fc>] (__report_bad_irq+0x28/0xc8)
[ 7.440950] r4:ec806500 r3:c088f358
[ 7.444558] [<c007b0d4>] (__report_bad_irq) from [<c007b6a4>] (note_interrupt+0x25c/0x2b8)
[ 7.452854] r6:0000002e r5:00000000 r4:ec806500 r3:0001863c
[ 7.458569] [<c007b448>] (note_interrupt) from [<c00791a0>] (handle_irq_event_percpu+0xb0/0x1a0)
[ 7.467389] r10:ec806500 r9:c08cb03b r8:0000002e r7:00000000 r6:00000000 r5:00000000
[ 7.475285] r4:00000000 r3:00000000
[ 7.478892] [<c00790f0>] (handle_irq_event_percpu) from [<c00792dc>] (handle_irq_event+0x4c/0x6c)
[ 7.487797] r10:00000006 r9:600f0113 r8:600f0113 r7:fa240100 r6:ecc3dcc0 r5:ec80655c
[ 7.495694] r4:ec806500
[ 7.498247] [<c0079290>] (handle_irq_event) from [<c007c3e0>] (handle_fasteoi_irq+0x84/0x150)
[ 7.506804] r6:ecc3dcc0 r5:0000002e r4:ec806500 r3:00000000
[ 7.512518] [<c007c35c>] (handle_fasteoi_irq) from [<c0078a7c>] (generic_handle_irq+0x28/0x38)
[ 7.521162] r4:0000002e r3:c007c35c
[ 7.524769] [<c0078a54>] (generic_handle_irq) from [<c000f238>] (handle_IRQ+0x40/0x9c)
[ 7.532716] r4:c0865ea8 r3:000001a0
[ 7.536321] [<c000f1f8>] (handle_IRQ) from [<c0008668>] (gic_handle_irq+0x30/0x64)
[ 7.543920] r6:ecc3dbd8 r5:c08709a0 r4:fa24010c r3:00000100
[ 7.549640] [<c0008638>] (gic_handle_irq) from [<c06062c0>] (__irq_svc+0x40/0x50)
[ 7.557154] Exception stack(0xecc3dbd8 to 0xecc3dc20)
[ 7.562226] dbc0: c08cccc0 00000000
[ 7.570439] dbe0: 0000000a 00000000 00000040 0000002c 00000000 ecc3c000 600f0113 600f0113
[ 7.578652] dc00: 00000006 ecc3dc64 ecc3dc20 ecc3dc20 c0040630 c00406a8 200f0113 ffffffff
[ 7.586860] r7:ecc3dc0c r6:ffffffff r5:200f0113 r4:c00406a8
[ 7.592581] [<c0040618>] (__do_softirq) from [<c0040ab8>] (irq_exit+0xa8/0xf8)
[ 7.599829] r10:00000006 r9:600f0113 r8:600f0113 r7:fa240100 r6:00000000 r5:0000002c
[ 7.607724] r4:ecc3c000
[ 7.610276] [<c0040a10>] (irq_exit) from [<c000f23c>] (handle_IRQ+0x44/0x9c)
[ 7.617351] r4:c0865ea8 r3:000001a0
[ 7.620955] [<c000f1f8>] (handle_IRQ) from [<c0008668>] (gic_handle_irq+0x30/0x64)
[ 7.628552] r6:ecc3dcc0 r5:c08709a0 r4:fa24010c r3:00000100
[ 7.634265] [<c0008638>] (gic_handle_irq) from [<c06062c0>] (__irq_svc+0x40/0x50)
[ 7.641777] Exception stack(0xecc3dcc0 to 0xecc3dd08)
[ 7.646850] dcc0: c08cf288 600f0193 c088f358 c088f358 c08cf288 00000001 00000027 c088f34c
[ 7.655062] dce0: 600f0113 600f0113 00000006 ecc3dd6c ecc3dcc0 ecc3dd08 c0076bac c00771f0
[ 7.663272] dd00: 600f0113 ffffffff
[ 7.666771] r7:ecc3dcf4 r6:ffffffff r5:600f0113 r4:c00771f0
[ 7.672485] [<c0076fd0>] (vprintk_emit) from [<c05fef40>] (printk+0x3c/0x44)
[ 7.679560] r10:00001ffe r9:00001000 r8:00000010 r7:00002000 r6:c08a5b00 r5:c08a5b2c
[ 7.687455] r4:c08a5a60
[ 7.690011] [<c05fef08>] (printk) from [<c0359684>] (credit_entropy_bits+0x238/0x260)
[ 7.697870] r3:00000002 r2:00000008 r1:c078cfa0 r0:c078cec4
[ 7.703583] [<c035944c>] (credit_entropy_bits) from [<c0359944>] (add_timer_randomness+0xd4/0xe4)
[ 7.712489] r10:ecc24008 r9:ecc24c00 r8:ecc1fb08 r7:00000000 r6:00000000 r5:c08a5b00
[ 7.720386] r4:ecc0b440
[ 7.722938] [<c0359870>] (add_timer_randomness) from [<c035a554>] (add_disk_randomness+0x2c/0x30)
[ 7.731844] r5:00000000 r4:ecc1fb08
[ 7.735451] [<c035a528>] (add_disk_randomness) from [<c027d888>] (blk_update_bidi_request+0x50/0x74)
[ 7.744625] [<c027d838>] (blk_update_bidi_request) from [<c027dbb0>] (blk_end_bidi_request+0x1c/0x58)
[ 7.753879] r6:00000000 r5:ecc28c00 r4:ecc1fb08 r3:00000000
[ 7.759592] [<c027db94>] (blk_end_bidi_request) from [<c027dc2c>] (blk_end_request+0x14/0x18)
[ 7.768149] r8:ecc1fb08 r7:00000000 r6:ecc24000 r5:00000000 r4:ecc24250 r3:00000000
[ 7.775973] [<c027dc18>] (blk_end_request) from [<c04cb48c>] (mmc_blk_issue_rw_rq+0x8c4/0xbd8)
[ 7.784625] [<c04cabc8>] (mmc_blk_issue_rw_rq) from [<c04cb96c>] (mmc_blk_issue_rq+0x1cc/0x4b8)
[ 7.793358] r10:00000001 r9:00000000 r8:ecc24000 r7:ecbfc29c r6:00000000 r5:ecc24008
[ 7.801255] r4:ecc24c00
[ 7.803807] [<c04cb7a0>] (mmc_blk_issue_rq) from [<c04cc4f8>] (mmc_queue_thread+0xb8/0x14c)
[ 7.812191] r10:00000001 r9:ecc24010 r8:00000000 r7:00000000 r6:ecc3c000 r5:ecc28c00
[ 7.820087] r4:ecc24008
[ 7.822648] [<c04cc440>] (mmc_queue_thread) from [<c00582c8>] (kthread+0xcc/0xe8)
[ 7.830159] r10:00000000 r9:00000000 r8:00000000 r7:c04cc440 r6:ecc24008 r5:ecc0b300
[ 7.838056] r4:00000000 r3:ecb1db40
[ 7.841663] [<c00581fc>] (kthread) from [<c000e9d8>] (ret_from_fork+0x14/0x3c)
[ 7.848911] r7:00000000 r6:00000000 r5:c00581fc r4:ecc0b300
[ 7.854618] handlers:
[ 7.856905] [<c001e8c0>] dma_ccerr_handler
[ 7.861020] Disabling IRQ #46
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
It looks like we can get an interrupt even when none of
the events that we're expecting occur. Make sure to
clear the IRQ in that case or else we occassionaly get
the following error at boot on am437x-sk-evm
[ 7.395763] irq 46: nobody cared (try booting with the "irqpoll" option)
[ 7.402499] CPU: 0 PID: 861 Comm: mmcqd/0 Not tainted 3.14.37-00337-g1b4e893 #1116
[ 7.410099] Backtrace:
[ 7.412588] [<c0011e84>] (dump_backtrace) from [<c0012020>] (show_stack+0x18/0x1c)
[ 7.420189] r6:0000002e r5:00000000 r4:00000000 r3:00000000
[ 7.425910] [<c0012008>] (show_stack) from [<c0600e4c>] (dump_stack+0x78/0x94)
[ 7.433178] [<c0600dd4>] (dump_stack) from [<c007b0fc>] (__report_bad_irq+0x28/0xc8)
[ 7.440950] r4:ec806500 r3:c088f358
[ 7.444558] [<c007b0d4>] (__report_bad_irq) from [<c007b6a4>] (note_interrupt+0x25c/0x2b8)
[ 7.452854] r6:0000002e r5:00000000 r4:ec806500 r3:0001863c
[ 7.458569] [<c007b448>] (note_interrupt) from [<c00791a0>] (handle_irq_event_percpu+0xb0/0x1a0)
[ 7.467389] r10:ec806500 r9:c08cb03b r8:0000002e r7:00000000 r6:00000000 r5:00000000
[ 7.475285] r4:00000000 r3:00000000
[ 7.478892] [<c00790f0>] (handle_irq_event_percpu) from [<c00792dc>] (handle_irq_event+0x4c/0x6c)
[ 7.487797] r10:00000006 r9:600f0113 r8:600f0113 r7:fa240100 r6:ecc3dcc0 r5:ec80655c
[ 7.495694] r4:ec806500
[ 7.498247] [<c0079290>] (handle_irq_event) from [<c007c3e0>] (handle_fasteoi_irq+0x84/0x150)
[ 7.506804] r6:ecc3dcc0 r5:0000002e r4:ec806500 r3:00000000
[ 7.512518] [<c007c35c>] (handle_fasteoi_irq) from [<c0078a7c>] (generic_handle_irq+0x28/0x38)
[ 7.521162] r4:0000002e r3:c007c35c
[ 7.524769] [<c0078a54>] (generic_handle_irq) from [<c000f238>] (handle_IRQ+0x40/0x9c)
[ 7.532716] r4:c0865ea8 r3:000001a0
[ 7.536321] [<c000f1f8>] (handle_IRQ) from [<c0008668>] (gic_handle_irq+0x30/0x64)
[ 7.543920] r6:ecc3dbd8 r5:c08709a0 r4:fa24010c r3:00000100
[ 7.549640] [<c0008638>] (gic_handle_irq) from [<c06062c0>] (__irq_svc+0x40/0x50)
[ 7.557154] Exception stack(0xecc3dbd8 to 0xecc3dc20)
[ 7.562226] dbc0: c08cccc0 00000000
[ 7.570439] dbe0: 0000000a 00000000 00000040 0000002c 00000000 ecc3c000 600f0113 600f0113
[ 7.578652] dc00: 00000006 ecc3dc64 ecc3dc20 ecc3dc20 c0040630 c00406a8 200f0113 ffffffff
[ 7.586860] r7:ecc3dc0c r6:ffffffff r5:200f0113 r4:c00406a8
[ 7.592581] [<c0040618>] (__do_softirq) from [<c0040ab8>] (irq_exit+0xa8/0xf8)
[ 7.599829] r10:00000006 r9:600f0113 r8:600f0113 r7:fa240100 r6:00000000 r5:0000002c
[ 7.607724] r4:ecc3c000
[ 7.610276] [<c0040a10>] (irq_exit) from [<c000f23c>] (handle_IRQ+0x44/0x9c)
[ 7.617351] r4:c0865ea8 r3:000001a0
[ 7.620955] [<c000f1f8>] (handle_IRQ) from [<c0008668>] (gic_handle_irq+0x30/0x64)
[ 7.628552] r6:ecc3dcc0 r5:c08709a0 r4:fa24010c r3:00000100
[ 7.634265] [<c0008638>] (gic_handle_irq) from [<c06062c0>] (__irq_svc+0x40/0x50)
[ 7.641777] Exception stack(0xecc3dcc0 to 0xecc3dd08)
[ 7.646850] dcc0: c08cf288 600f0193 c088f358 c088f358 c08cf288 00000001 00000027 c088f34c
[ 7.655062] dce0: 600f0113 600f0113 00000006 ecc3dd6c ecc3dcc0 ecc3dd08 c0076bac c00771f0
[ 7.663272] dd00: 600f0113 ffffffff
[ 7.666771] r7:ecc3dcf4 r6:ffffffff r5:600f0113 r4:c00771f0
[ 7.672485] [<c0076fd0>] (vprintk_emit) from [<c05fef40>] (printk+0x3c/0x44)
[ 7.679560] r10:00001ffe r9:00001000 r8:00000010 r7:00002000 r6:c08a5b00 r5:c08a5b2c
[ 7.687455] r4:c08a5a60
[ 7.690011] [<c05fef08>] (printk) from [<c0359684>] (credit_entropy_bits+0x238/0x260)
[ 7.697870] r3:00000002 r2:00000008 r1:c078cfa0 r0:c078cec4
[ 7.703583] [<c035944c>] (credit_entropy_bits) from [<c0359944>] (add_timer_randomness+0xd4/0xe4)
[ 7.712489] r10:ecc24008 r9:ecc24c00 r8:ecc1fb08 r7:00000000 r6:00000000 r5:c08a5b00
[ 7.720386] r4:ecc0b440
[ 7.722938] [<c0359870>] (add_timer_randomness) from [<c035a554>] (add_disk_randomness+0x2c/0x30)
[ 7.731844] r5:00000000 r4:ecc1fb08
[ 7.735451] [<c035a528>] (add_disk_randomness) from [<c027d888>] (blk_update_bidi_request+0x50/0x74)
[ 7.744625] [<c027d838>] (blk_update_bidi_request) from [<c027dbb0>] (blk_end_bidi_request+0x1c/0x58)
[ 7.753879] r6:00000000 r5:ecc28c00 r4:ecc1fb08 r3:00000000
[ 7.759592] [<c027db94>] (blk_end_bidi_request) from [<c027dc2c>] (blk_end_request+0x14/0x18)
[ 7.768149] r8:ecc1fb08 r7:00000000 r6:ecc24000 r5:00000000 r4:ecc24250 r3:00000000
[ 7.775973] [<c027dc18>] (blk_end_request) from [<c04cb48c>] (mmc_blk_issue_rw_rq+0x8c4/0xbd8)
[ 7.784625] [<c04cabc8>] (mmc_blk_issue_rw_rq) from [<c04cb96c>] (mmc_blk_issue_rq+0x1cc/0x4b8)
[ 7.793358] r10:00000001 r9:00000000 r8:ecc24000 r7:ecbfc29c r6:00000000 r5:ecc24008
[ 7.801255] r4:ecc24c00
[ 7.803807] [<c04cb7a0>] (mmc_blk_issue_rq) from [<c04cc4f8>] (mmc_queue_thread+0xb8/0x14c)
[ 7.812191] r10:00000001 r9:ecc24010 r8:00000000 r7:00000000 r6:ecc3c000 r5:ecc28c00
[ 7.820087] r4:ecc24008
[ 7.822648] [<c04cc440>] (mmc_queue_thread) from [<c00582c8>] (kthread+0xcc/0xe8)
[ 7.830159] r10:00000000 r9:00000000 r8:00000000 r7:c04cc440 r6:ecc24008 r5:ecc0b300
[ 7.838056] r4:00000000 r3:ecb1db40
[ 7.841663] [<c00581fc>] (kthread) from [<c000e9d8>] (ret_from_fork+0x14/0x3c)
[ 7.848911] r7:00000000 r6:00000000 r5:c00581fc r4:ecc0b300
[ 7.854618] handlers:
[ 7.856905] [<c001e8c0>] dma_ccerr_handler
[ 7.861020] Disabling IRQ #46
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
clk: ti: Move context save/restore from generic clk to ti clk drivers
Patch 31bdb0f10c71 ("ARM: OMAP2: Add functions to save and restore
clock/dpll context en-masse") added context save/restore functions to
the clk drivers in preparation of supporting RTC only mode,
however in the migration from v3.12 to v3.14 it seems these were added
to the generic divider and gate clk drivers rather than the drivers
under ti, which are the ones used on our SoCs.
This patch drops the functions from the generic drivers and moves them
into the proper drivers. Without this, divider and gate clocks were not
being restored correctly after an rtc+ddr cycle on am437x which caused
some strange behavior in certain peripherals, like the cpsw.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Patch 31bdb0f10c71 ("ARM: OMAP2: Add functions to save and restore
clock/dpll context en-masse") added context save/restore functions to
the clk drivers in preparation of supporting RTC only mode,
however in the migration from v3.12 to v3.14 it seems these were added
to the generic divider and gate clk drivers rather than the drivers
under ti, which are the ones used on our SoCs.
This patch drops the functions from the generic drivers and moves them
into the proper drivers. Without this, divider and gate clocks were not
being restored correctly after an rtc+ddr cycle on am437x which caused
some strange behavior in certain peripherals, like the cpsw.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
thermal: ti-soc-thermal: OMAP5: Implement Workaround for Errata i813
DESCRIPTION
Spurious Thermal Alert: Talert can happen randomly while the device remains under the temperature limit
defined for this event to trig. This spurious event is caused by a incorrect re-synchronization between
clock domains. The comparison between configured threshold and current temperature value can happen
while the value is transitioning (metastable), thus causing inappropriate event generation.
No spurious event occurs as long as the threshold value stays unchanged. Spurious event can be
generated while a thermal alert threshold is modified in
CONTROL_BANDGAP_THRESHOLD_MPU/GPU/CORE/DSPEVE/IVA_n.
WORKAROUND
Spurious event generation can be avoided by performing following sequence when the threshold is
modified:
1. Mask the hot/cold events at the thermal IP level.
2. Modify Threshold.
3. Unmask the hot/cold events at the thermal IP level.
Signed-off-by: Keerthy <j-keerthy@ti.com>
DESCRIPTION
Spurious Thermal Alert: Talert can happen randomly while the device remains under the temperature limit
defined for this event to trig. This spurious event is caused by a incorrect re-synchronization between
clock domains. The comparison between configured threshold and current temperature value can happen
while the value is transitioning (metastable), thus causing inappropriate event generation.
No spurious event occurs as long as the threshold value stays unchanged. Spurious event can be
generated while a thermal alert threshold is modified in
CONTROL_BANDGAP_THRESHOLD_MPU/GPU/CORE/DSPEVE/IVA_n.
WORKAROUND
Spurious event generation can be avoided by performing following sequence when the threshold is
modified:
1. Mask the hot/cold events at the thermal IP level.
2. Modify Threshold.
3. Unmask the hot/cold events at the thermal IP level.
Signed-off-by: Keerthy <j-keerthy@ti.com>
thermal: ti-soc-thermal: dra7: Implement Workaround for Errata i814 - Bandgap Temperature read Dtemp can be corrupted
Bandgap Temperature read Dtemp can be corrupted
DESCRIPTION
Read accesses to registers listed below can be corrupted due to incorrect resynchronization between
clock domains.
Read access to registers below can be corrupted :
• CTRL_CORE_DTEMP_MPU/GPU/CORE/DSPEVE/IVA_n (n = 0 to 4)
• CTRL_CORE_TEMP_SENSOR_MPU/GPU/CORE/DSPEVE/IVA_n
WORKAROUND
Multiple reads to CTRL_CORE_TEMP_SENSOR_MPU/GPU/CORE/DSPEVE/IVA[9:0]:
BGAP_DTEMPMPU/GPU/CORE/DSPEVE/IVA is needed to discard false value and read right value:
1. Perform two successive reads to BGAP_DTEMP bit field.
(a) If read1 returns Val1 and read2 returns Val1, then right value is Val1.
(b) If read1 returns Val1, read 2 returns Val2, a third read is needed.
2. Perform third read
(a) If read3 returns Val2 then right value is Val2.
(b) If read3 returns Val3, then right value is Val3.
The above in gist means if val1 and val2 are the same then we can go ahead with that value
else we need a third read which will be right since synchronization will be complete by then.
Signed-off-by: Keerthy <j-keerthy@ti.com>
Bandgap Temperature read Dtemp can be corrupted
DESCRIPTION
Read accesses to registers listed below can be corrupted due to incorrect resynchronization between
clock domains.
Read access to registers below can be corrupted :
• CTRL_CORE_DTEMP_MPU/GPU/CORE/DSPEVE/IVA_n (n = 0 to 4)
• CTRL_CORE_TEMP_SENSOR_MPU/GPU/CORE/DSPEVE/IVA_n
WORKAROUND
Multiple reads to CTRL_CORE_TEMP_SENSOR_MPU/GPU/CORE/DSPEVE/IVA[9:0]:
BGAP_DTEMPMPU/GPU/CORE/DSPEVE/IVA is needed to discard false value and read right value:
1. Perform two successive reads to BGAP_DTEMP bit field.
(a) If read1 returns Val1 and read2 returns Val1, then right value is Val1.
(b) If read1 returns Val1, read 2 returns Val2, a third read is needed.
2. Perform third read
(a) If read3 returns Val2 then right value is Val2.
(b) If read3 returns Val3, then right value is Val3.
The above in gist means if val1 and val2 are the same then we can go ahead with that value
else we need a third read which will be right since synchronization will be complete by then.
Signed-off-by: Keerthy <j-keerthy@ti.com>
ARM: dts: dra7: Fix efuse register size for voltdms
Fix a typo in DRA7 dtsi where 12 bytes are needed for register
description of ABB efuse registers, however only 8 bytes are provided
to map. For some weird reason, this does not generate abort at offset
0x8, probably due to default maps already provided in io.c for the bus
register ranges.
Reported-by: Matt Gessner <Matt.Gessner@windriver.com>
Reported-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Fix a typo in DRA7 dtsi where 12 bytes are needed for register
description of ABB efuse registers, however only 8 bytes are provided
to map. For some weird reason, this does not generate abort at offset
0x8, probably due to default maps already provided in io.c for the bus
register ranges.
Reported-by: Matt Gessner <Matt.Gessner@windriver.com>
Reported-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
ARM: dts: dra7: Fix efuse register size for ABB
Fix a typo in DRA7 dtsi where 12 bytes are needed for register
description of ABB efuse registers, however only 8 bytes are provided
to map. For some weird reason, this does not generate abort at offset
0x8, probably due to default maps already provided in io.c for the bus
register ranges.
Reported-by: Matt Gessner <Matt.Gessner@windriver.com>
Reported-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Fix a typo in DRA7 dtsi where 12 bytes are needed for register
description of ABB efuse registers, however only 8 bytes are provided
to map. For some weird reason, this does not generate abort at offset
0x8, probably due to default maps already provided in io.c for the bus
register ranges.
Reported-by: Matt Gessner <Matt.Gessner@windriver.com>
Reported-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
bus: omap_l3_noc: Fix connID for OMAP4
[ Upstream commit 41fc619dd5584d438d1eb673bd82a722d627ad85 ]
Commit d4d8819e205854c ("bus: omap_l3_noc: fix masterid detection")
did the right thing in dropping the LSB 2 bits which is not part
of the ConnID for NTTP master address. However, as part of that
change, we should also have ensured that existing list of OMAP4 connID
codes are also shifted by 2 bits to ensure that connIDs map to "Table
13-18. ConnID Values" as provided in Technical Reference Manuals for
OMAP4430(Rev AP, April 2014, SWPU220AP) and OMAP4460(Rev AB, April
2014, SWPU234AB)
Fixes: d4d8819e205854c ("bus: omap_l3_noc: fix masterid detection")
Reported-by: Kristian Otnes <kotnes@cisco.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
[ Upstream commit 41fc619dd5584d438d1eb673bd82a722d627ad85 ]
Commit d4d8819e205854c ("bus: omap_l3_noc: fix masterid detection")
did the right thing in dropping the LSB 2 bits which is not part
of the ConnID for NTTP master address. However, as part of that
change, we should also have ensured that existing list of OMAP4 connID
codes are also shifted by 2 bits to ensure that connIDs map to "Table
13-18. ConnID Values" as provided in Technical Reference Manuals for
OMAP4430(Rev AP, April 2014, SWPU220AP) and OMAP4460(Rev AB, April
2014, SWPU234AB)
Fixes: d4d8819e205854c ("bus: omap_l3_noc: fix masterid detection")
Reported-by: Kristian Otnes <kotnes@cisco.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
bus: omap_l3_noc: Fix offset for DRA7 CLK1_HOST_CLK1_2 instance
The base address for DRA7 CLK1_HOST_CLK1_2 host instance is
0x44800000, so correct offset is 0x800000. DRA7 TRM rev X(fewb 2015)
has updates for this information.
With wrong offset these errors are not correctly cleared by the L3
IRQ handler and cause an continuous interrupt scenario and system lockup.
Signed-off-by: Illia Smyrnov <illia.smyrnov@globallogic.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
The base address for DRA7 CLK1_HOST_CLK1_2 host instance is
0x44800000, so correct offset is 0x800000. DRA7 TRM rev X(fewb 2015)
has updates for this information.
With wrong offset these errors are not correctly cleared by the L3
IRQ handler and cause an continuous interrupt scenario and system lockup.
Signed-off-by: Illia Smyrnov <illia.smyrnov@globallogic.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
crypto: omap-sham: Use pm_runtime_irq_safe()
omap_sham_handle_queue() can be called as part of done_task tasklet.
During this its atomic and any calls to pm functions cannot sleep.
But there is a call to pm_runtime_get_sync() (which can sleep) in
omap_sham_handle_queue(), because of which the following appears:
" [ 116.169969] BUG: scheduling while atomic: kworker/0:2/2676/0x00000100"
Add pm_runtime_irq_safe() to avoid this.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
omap_sham_handle_queue() can be called as part of done_task tasklet.
During this its atomic and any calls to pm functions cannot sleep.
But there is a call to pm_runtime_get_sync() (which can sleep) in
omap_sham_handle_queue(), because of which the following appears:
" [ 116.169969] BUG: scheduling while atomic: kworker/0:2/2676/0x00000100"
Add pm_runtime_irq_safe() to avoid this.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
crypto: omap-sham: Add the offset of sg page to vaddr
kmap_atomic() gives only the page address of the input page.
Driver should take care of adding the offset of the scatterlist
within the page to the returned page address.
omap-sham driver is not adding the offset to page and directly operates
on the return vale of kmap_atomic(), because of which the following
error comes when running crypto tests:
00000000: d9 a1 1b 7c aa 90 3b aa 11 ab cb 25 00 b8 ac bf
[ 2.338169] 00000010: c1 39 cd ff 48 d0 a8 e2 2b fa 33 a1
[ 2.344008] alg: hash: Chunking test 1 failed for omap-sha256
So adding the scatterlist offset to vaddr.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
kmap_atomic() gives only the page address of the input page.
Driver should take care of adding the offset of the scatterlist
within the page to the returned page address.
omap-sham driver is not adding the offset to page and directly operates
on the return vale of kmap_atomic(), because of which the following
error comes when running crypto tests:
00000000: d9 a1 1b 7c aa 90 3b aa 11 ab cb 25 00 b8 ac bf
[ 2.338169] 00000010: c1 39 cd ff 48 d0 a8 e2 2b fa 33 a1
[ 2.344008] alg: hash: Chunking test 1 failed for omap-sha256
So adding the scatterlist offset to vaddr.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
crypto: omap-aes - Fix support for unaligned lengths
For cases where total length of on input SGs is not same as
length of the input data for excryption we copy all the pages
from the input SG list into a contiguous buffer and prepare a
single element SG list for this buffer with length as the
total bytes to crypt.
Fixes: 6242332ff2f3 ("crypto: omap-aes - Add support for cases of unaligned lengths")
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
For cases where total length of on input SGs is not same as
length of the input data for excryption we copy all the pages
from the input SG list into a contiguous buffer and prepare a
single element SG list for this buffer with length as the
total bytes to crypt.
Fixes: 6242332ff2f3 ("crypto: omap-aes - Add support for cases of unaligned lengths")
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
gpio: Document GPIO hogging mechanism
[ Upstream commit 6b516a1093006a39368dd11a5396be5bb00c99df ]
Add GPIO hogging documentation to gpio.txt
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
[ Upstream commit 6b516a1093006a39368dd11a5396be5bb00c99df ]
Add GPIO hogging documentation to gpio.txt
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
gpio: add GPIO hog mechanism
[ Upstream commit f625d4601759f1cf1fd3ae58abeb0e203b8993b1 ]
Based on Boris Brezillion work this a reworked patch
of his initial GPIO hogging mechanism.
This patch provides a way to initally configure specific GPIO
when the gpio controller is probe.
The actual DT scanning to collect the GPIO specific data is performed
as part of the gpiochip_add().
The purpose of this is to allows specific GPIOs to be configured
without any driver specific code.
This particularly usueful because board design are getting
increassingly complex and given SoC pins can now have upward
of 10 mux values a lot of connections are now dependent on
external IO muxes to switch various modes and combination.
Specific drivers should not necessarily need to be aware of
what accounts to a specific board implementation. This board level
"description" should be best kept as part of the dts file.
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
[ Upstream commit f625d4601759f1cf1fd3ae58abeb0e203b8993b1 ]
Based on Boris Brezillion work this a reworked patch
of his initial GPIO hogging mechanism.
This patch provides a way to initally configure specific GPIO
when the gpio controller is probe.
The actual DT scanning to collect the GPIO specific data is performed
as part of the gpiochip_add().
The purpose of this is to allows specific GPIOs to be configured
without any driver specific code.
This particularly usueful because board design are getting
increassingly complex and given SoC pins can now have upward
of 10 mux values a lot of connections are now dependent on
external IO muxes to switch various modes and combination.
Specific drivers should not necessarily need to be aware of
what accounts to a specific board implementation. This board level
"description" should be best kept as part of the dts file.
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
dmaengine: omap-dma: Fix memory leak when terminating running transfer
[ Upstream commit 02d88b735f5a60f04dbf6d051b76e1877a0d0844 ]
In omap_dma_start_desc the vdesc->node is removed from the virt-dma
framework managed lists (to be precise from the desc_issued list).
If a terminate_all comes before the transfer finishes the omap_desc will
not be freed up because it is not in any of the lists and we stopped the
DMA channel so the transfer will not going to complete.
There is no special sequence for leaking memory when using cyclic (audio)
transfer: with every start and stop of a cyclic transfer the driver leaks
struct omap_desc worth of memory.
Free up the allocated memory directly in omap_dma_terminate_all() since the
framework will not going to do that for us.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
CC: <stable@vger.kernel.org>
CC: <linux-omap@vger.kernel.org>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
[ Upstream commit 02d88b735f5a60f04dbf6d051b76e1877a0d0844 ]
In omap_dma_start_desc the vdesc->node is removed from the virt-dma
framework managed lists (to be precise from the desc_issued list).
If a terminate_all comes before the transfer finishes the omap_desc will
not be freed up because it is not in any of the lists and we stopped the
DMA channel so the transfer will not going to complete.
There is no special sequence for leaking memory when using cyclic (audio)
transfer: with every start and stop of a cyclic transfer the driver leaks
struct omap_desc worth of memory.
Free up the allocated memory directly in omap_dma_terminate_all() since the
framework will not going to do that for us.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
CC: <stable@vger.kernel.org>
CC: <linux-omap@vger.kernel.org>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
dmaengine: edma: fix memory leak when terminating running transfers
[ Upstream commit 5ca9e7ce6eebec53362ff779264143860ccf68cd ]
If edma_terminate_all() was called while a transfer was running (i.e. after
edma_execute() but before edma_callback()) the echan->edesc was not freed.
This was due to the fact that a running transfer is on none of the
vchan lists: desc_submitted, desc_issued, desc_completed (edma_execute()
removes it from the desc_issued list), so the vchan_dma_desc_free_list()
called at the end of edma_terminate_all() didn't find it and didn't free it.
This bug was found on an AM1808 based hardware (very similar to da850evm,
however using the second MMC/SD controller), where intense operations on the SD
card wasted the device 128MB RAM within a couple of days.
Peter Ujfalusi:
The issue is even more severe since it affects cyclic (audio) transfers as
well. In this case starting/stopping audio will results memory leak.
Signed-off-by: Petr Kulhavy <petr@barix.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
CC: <stable@vger.kernel.org>
CC: <linux-omap@vger.kernel.org>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
[ Upstream commit 5ca9e7ce6eebec53362ff779264143860ccf68cd ]
If edma_terminate_all() was called while a transfer was running (i.e. after
edma_execute() but before edma_callback()) the echan->edesc was not freed.
This was due to the fact that a running transfer is on none of the
vchan lists: desc_submitted, desc_issued, desc_completed (edma_execute()
removes it from the desc_issued list), so the vchan_dma_desc_free_list()
called at the end of edma_terminate_all() didn't find it and didn't free it.
This bug was found on an AM1808 based hardware (very similar to da850evm,
however using the second MMC/SD controller), where intense operations on the SD
card wasted the device 128MB RAM within a couple of days.
Peter Ujfalusi:
The issue is even more severe since it affects cyclic (audio) transfers as
well. In this case starting/stopping audio will results memory leak.
Signed-off-by: Petr Kulhavy <petr@barix.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
CC: <stable@vger.kernel.org>
CC: <linux-omap@vger.kernel.org>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
ti_config_fragments/baseport.cfg: enable opening files by handle
CONFIG_FHANDLE=y is required by systemd and thus systemd based
distributions like debian unstable.
See: https://github.com/systemd/systemd/blob/master/README
Other kernel config options needed by systemd are already enabled
(except CONFIG_FHANDLE).
This option adds two system calls and *should* not create
any performance or functional regressions. OTOH, it will
enable TI kernel to be used with systemd based distributions
without recompilation.
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
CONFIG_FHANDLE=y is required by systemd and thus systemd based
distributions like debian unstable.
See: https://github.com/systemd/systemd/blob/master/README
Other kernel config options needed by systemd are already enabled
(except CONFIG_FHANDLE).
This option adds two system calls and *should* not create
any performance or functional regressions. OTOH, it will
enable TI kernel to be used with systemd based distributions
without recompilation.
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
scripts/dtc: Update to upstream version 1.4.1-ga4b093f7
This updates scripts/dtc to commit
"a4b093f libfdt: Add missing functions to shared library"
from git://git.kernel.org/pub/scm/utils/dtc/dtc.git.
This is autogenerated commit using the update-dtc-source.sh script.
This change is mainly needed for including the new DTC syntax.
"3346e065a dtc: parser: Add label while overriding nodes"
With the new syntax, it is possible to write generic app board
device tree which can work with multiple boards.
For e.g. the JAMR3 DTSI file describes all the devices on an i2c bus.
All these devices are put under i2c2 or i2c5 depending on whether
it's used with dra7-evm or dra72-evm
This way, there is no need to replicate the DT nodes in two places.
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
This updates scripts/dtc to commit
"a4b093f libfdt: Add missing functions to shared library"
from git://git.kernel.org/pub/scm/utils/dtc/dtc.git.
This is autogenerated commit using the update-dtc-source.sh script.
This change is mainly needed for including the new DTC syntax.
"3346e065a dtc: parser: Add label while overriding nodes"
With the new syntax, it is possible to write generic app board
device tree which can work with multiple boards.
For e.g. the JAMR3 DTSI file describes all the devices on an i2c bus.
All these devices are put under i2c2 or i2c5 depending on whether
it's used with dra7-evm or dra72-evm
This way, there is no need to replicate the DT nodes in two places.
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
scripts/dtc: Add a script to update to mainline dtc source
[ Upstream commit c8a3e6a866f91f82b4d04809aa30de2f4d928756 ]
A very simple script that automates pulling in a newer version of DTC.
Not particularly robust, but a whole lot better than doing it by hand
every time.
Signed-off-by: Grant Likely <grant.likely@linaro.org>
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
[ Upstream commit c8a3e6a866f91f82b4d04809aa30de2f4d928756 ]
A very simple script that automates pulling in a newer version of DTC.
Not particularly robust, but a whole lot better than doing it by hand
every time.
Signed-off-by: Grant Likely <grant.likely@linaro.org>
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
cpufreq / OPP: Fix the order of arguments for kcalloc()
[ Upstream commit d359992070901bcd774615910d36cec67dbdb1a7 ]
These changes fix the argument to the kcalloc
@n: number of elements.
@size: element size.
@flags: the type of memory to allocate (see kmalloc).
void *kcalloc(size_t n, size_t size, gfp_t flags)
Fixes: 3c5445ce3a0c (cpufreq: OPP: Avoid sleeping while atomic)
Signed-off-by: Anand Moon <moon.linux@yahoo.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
[ Upstream commit d359992070901bcd774615910d36cec67dbdb1a7 ]
These changes fix the argument to the kcalloc
@n: number of elements.
@size: element size.
@flags: the type of memory to allocate (see kmalloc).
void *kcalloc(size_t n, size_t size, gfp_t flags)
Fixes: 3c5445ce3a0c (cpufreq: OPP: Avoid sleeping while atomic)
Signed-off-by: Anand Moon <moon.linux@yahoo.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
cpufreq: OPP: Avoid sleeping while atomic
[ Upstream commit 3c5445ce3a0c6d6935911212b735772af5115517 ]
We allocate the cpufreq table after calling rcu_read_lock(),
which disables preemption. This causes scheduling while atomic
warnings. Use GFP_ATOMIC instead of GFP_KERNEL and update for
kcalloc while we're here.
BUG: sleeping function called from invalid context at mm/slub.c:1246
in_atomic(): 0, irqs_disabled(): 0, pid: 80, name: modprobe
5 locks held by modprobe/80:
#0: (&dev->mutex){......}, at: [<c050d484>] __driver_attach+0x48/0x98
#1: (&dev->mutex){......}, at: [<c050d494>] __driver_attach+0x58/0x98
#2: (subsys mutex#5){+.+.+.}, at: [<c050c114>] subsys_interface_register+0x38/0xc8
#3: (cpufreq_rwsem){.+.+.+}, at: [<c05a9c8c>] __cpufreq_add_dev.isra.22+0x84/0x92c
#4: (rcu_read_lock){......}, at: [<c05ab24c>] dev_pm_opp_init_cpufreq_table+0x18/0x10c
Preemption disabled at:[< (null)>] (null)
CPU: 2 PID: 80 Comm: modprobe Not tainted 3.16.0-rc3-next-20140701-00035-g286857f216aa-dirty #217
[<c0214da8>] (unwind_backtrace) from [<c02123f8>] (show_stack+0x10/0x14)
[<c02123f8>] (show_stack) from [<c070141c>] (dump_stack+0x70/0xbc)
[<c070141c>] (dump_stack) from [<c02f4cb0>] (__kmalloc+0x124/0x250)
[<c02f4cb0>] (__kmalloc) from [<c05ab270>] (dev_pm_opp_init_cpufreq_table+0x3c/0x10c)
[<c05ab270>] (dev_pm_opp_init_cpufreq_table) from [<bf000508>] (cpufreq_init+0x48/0x378 [cpufreq_generic])
[<bf000508>] (cpufreq_init [cpufreq_generic]) from [<c05a9e08>] (__cpufreq_add_dev.isra.22+0x200/0x92c)
[<c05a9e08>] (__cpufreq_add_dev.isra.22) from [<c050c160>] (subsys_interface_register+0x84/0xc8)
[<c050c160>] (subsys_interface_register) from [<c05a9494>] (cpufreq_register_driver+0x108/0x2d8)
[<c05a9494>] (cpufreq_register_driver) from [<bf000888>] (generic_cpufreq_probe+0x50/0x74 [cpufreq_generic])
[<bf000888>] (generic_cpufreq_probe [cpufreq_generic]) from [<c050e994>] (platform_drv_probe+0x18/0x48)
[<c050e994>] (platform_drv_probe) from [<c050d1f4>] (driver_probe_device+0x128/0x370)
[<c050d1f4>] (driver_probe_device) from [<c050d4d0>] (__driver_attach+0x94/0x98)
[<c050d4d0>] (__driver_attach) from [<c050b778>] (bus_for_each_dev+0x54/0x88)
[<c050b778>] (bus_for_each_dev) from [<c050c894>] (bus_add_driver+0xe8/0x204)
[<c050c894>] (bus_add_driver) from [<c050dd48>] (driver_register+0x78/0xf4)
[<c050dd48>] (driver_register) from [<c0208870>] (do_one_initcall+0xac/0x1d8)
[<c0208870>] (do_one_initcall) from [<c028b6b4>] (load_module+0x190c/0x21e8)
[<c028b6b4>] (load_module) from [<c028c034>] (SyS_init_module+0xa4/0x110)
[<c028c034>] (SyS_init_module) from [<c020f0c0>] (ret_fast_syscall+0x0/0x48)
Fixes: a0dd7b79657b (PM / OPP: Move cpufreq specific OPP functions out of generic OPP library)
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Cc: 3.16+ <stable@vger.kernel.org> # 3.16+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
[ Upstream commit 3c5445ce3a0c6d6935911212b735772af5115517 ]
We allocate the cpufreq table after calling rcu_read_lock(),
which disables preemption. This causes scheduling while atomic
warnings. Use GFP_ATOMIC instead of GFP_KERNEL and update for
kcalloc while we're here.
BUG: sleeping function called from invalid context at mm/slub.c:1246
in_atomic(): 0, irqs_disabled(): 0, pid: 80, name: modprobe
5 locks held by modprobe/80:
#0: (&dev->mutex){......}, at: [<c050d484>] __driver_attach+0x48/0x98
#1: (&dev->mutex){......}, at: [<c050d494>] __driver_attach+0x58/0x98
#2: (subsys mutex#5){+.+.+.}, at: [<c050c114>] subsys_interface_register+0x38/0xc8
#3: (cpufreq_rwsem){.+.+.+}, at: [<c05a9c8c>] __cpufreq_add_dev.isra.22+0x84/0x92c
#4: (rcu_read_lock){......}, at: [<c05ab24c>] dev_pm_opp_init_cpufreq_table+0x18/0x10c
Preemption disabled at:[< (null)>] (null)
CPU: 2 PID: 80 Comm: modprobe Not tainted 3.16.0-rc3-next-20140701-00035-g286857f216aa-dirty #217
[<c0214da8>] (unwind_backtrace) from [<c02123f8>] (show_stack+0x10/0x14)
[<c02123f8>] (show_stack) from [<c070141c>] (dump_stack+0x70/0xbc)
[<c070141c>] (dump_stack) from [<c02f4cb0>] (__kmalloc+0x124/0x250)
[<c02f4cb0>] (__kmalloc) from [<c05ab270>] (dev_pm_opp_init_cpufreq_table+0x3c/0x10c)
[<c05ab270>] (dev_pm_opp_init_cpufreq_table) from [<bf000508>] (cpufreq_init+0x48/0x378 [cpufreq_generic])
[<bf000508>] (cpufreq_init [cpufreq_generic]) from [<c05a9e08>] (__cpufreq_add_dev.isra.22+0x200/0x92c)
[<c05a9e08>] (__cpufreq_add_dev.isra.22) from [<c050c160>] (subsys_interface_register+0x84/0xc8)
[<c050c160>] (subsys_interface_register) from [<c05a9494>] (cpufreq_register_driver+0x108/0x2d8)
[<c05a9494>] (cpufreq_register_driver) from [<bf000888>] (generic_cpufreq_probe+0x50/0x74 [cpufreq_generic])
[<bf000888>] (generic_cpufreq_probe [cpufreq_generic]) from [<c050e994>] (platform_drv_probe+0x18/0x48)
[<c050e994>] (platform_drv_probe) from [<c050d1f4>] (driver_probe_device+0x128/0x370)
[<c050d1f4>] (driver_probe_device) from [<c050d4d0>] (__driver_attach+0x94/0x98)
[<c050d4d0>] (__driver_attach) from [<c050b778>] (bus_for_each_dev+0x54/0x88)
[<c050b778>] (bus_for_each_dev) from [<c050c894>] (bus_add_driver+0xe8/0x204)
[<c050c894>] (bus_add_driver) from [<c050dd48>] (driver_register+0x78/0xf4)
[<c050dd48>] (driver_register) from [<c0208870>] (do_one_initcall+0xac/0x1d8)
[<c0208870>] (do_one_initcall) from [<c028b6b4>] (load_module+0x190c/0x21e8)
[<c028b6b4>] (load_module) from [<c028c034>] (SyS_init_module+0xa4/0x110)
[<c028c034>] (SyS_init_module) from [<c020f0c0>] (ret_fast_syscall+0x0/0x48)
Fixes: a0dd7b79657b (PM / OPP: Move cpufreq specific OPP functions out of generic OPP library)
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Cc: 3.16+ <stable@vger.kernel.org> # 3.16+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
CLK: ti: dra7: Initialize USB_DPLL
USB_DPLL must be initialized and locked at boot so that
USB modules can work.
Also program USB_DLL_M2 output to half rate.
CC: Mike Turquette <mturquette@linaro.org>
CC: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
USB_DPLL must be initialized and locked at boot so that
USB modules can work.
Also program USB_DLL_M2 output to half rate.
CC: Mike Turquette <mturquette@linaro.org>
CC: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
ARM: OMAP2+: cpuidle33xx: Change wkup_m3 idle state to avoid MPU PLL bypass
To get to C1-state in cpuidle am33xx currently uses the wkup_m3 to gate
the MPU clock domain and bypass the MPU PLL. Because we are not shutting
off the MPU power domain in this C-state it is possible for both to be
awake and executing at the same time, and we do not have the ability
to synchronize execution between the two in the cpuidle path due to
no interrupt context.
This leads to racy behavior between the two and in certain instances
where c1-state is entered often during periods of high cpu activity it
is possible for the MPU to interfere with the wake path on the wkup_m3,
which prevents the MPU PLL from being re-locked and causing extreme
system slowdown.
Because of this, we must now use a different idle state available on the
current wkup_m3 firmware (0x190) which does nothing more than put the
MPU clockdomain to sleep, giving us the same power savings seen
previously on the MPU power rail but slightly higher power on the
MPU_PLL voltage rail.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
To get to C1-state in cpuidle am33xx currently uses the wkup_m3 to gate
the MPU clock domain and bypass the MPU PLL. Because we are not shutting
off the MPU power domain in this C-state it is possible for both to be
awake and executing at the same time, and we do not have the ability
to synchronize execution between the two in the cpuidle path due to
no interrupt context.
This leads to racy behavior between the two and in certain instances
where c1-state is entered often during periods of high cpu activity it
is possible for the MPU to interfere with the wake path on the wkup_m3,
which prevents the MPU PLL from being re-locked and causing extreme
system slowdown.
Because of this, we must now use a different idle state available on the
current wkup_m3 firmware (0x190) which does nothing more than put the
MPU clockdomain to sleep, giving us the same power savings seen
previously on the MPU power rail but slightly higher power on the
MPU_PLL voltage rail.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
ARM: DRA7: Enable Cortex A15 errata 798181
RM errata 798181 is applicable for OMAP5/DRA7 based devices. So enable
the same in the build.
DRA7xx is based on Cortex-A15 r2p2 revision.
ARM Errata extract and workaround information is as below.
On Cortex-A15 (r0p0..r3p2) the TLBI*IS/DSB operations are not
adequately shooting down all use of the old entries. The
ARM_ERRATA_798181 option enables the Linux kernel workaround
for this erratum which sends an IPI to the CPUs that are running
the same ASID as the one being invalidated.
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Acked-by: Nishanth Menon <nm@ti.com>
RM errata 798181 is applicable for OMAP5/DRA7 based devices. So enable
the same in the build.
DRA7xx is based on Cortex-A15 r2p2 revision.
ARM Errata extract and workaround information is as below.
On Cortex-A15 (r0p0..r3p2) the TLBI*IS/DSB operations are not
adequately shooting down all use of the old entries. The
ARM_ERRATA_798181 option enables the Linux kernel workaround
for this erratum which sends an IPI to the CPUs that are running
the same ASID as the one being invalidated.
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Acked-by: Nishanth Menon <nm@ti.com>
ARM: OMAP: dmtimer: disable pm runtime on remove
[ Upstream commit 51b7e5728ebcded3f2ced9cd3ff71076c91e85de ]
Disable the pm_runtime of the device upon remove. This is
added to balance the pm_runtime_enable() invoked in the probe.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
[ Upstream commit 51b7e5728ebcded3f2ced9cd3ff71076c91e85de ]
Disable the pm_runtime of the device upon remove. This is
added to balance the pm_runtime_enable() invoked in the probe.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
ARM: OMAP: dmtimer: check for pm_runtime_get_sync() failure
[ Upstream commit a76fc9dda87b51010e4bc60b5e0065a70180b465 ]
The current OMAP dmtimer probe does not check for the return
status of pm_runtime_get_sync() before initializing the timer
registers. Any timer with missing hwmod data would return a
failure here, and the access of registers without enabling the
clocks for the timer would trigger a l3_noc interrupt and a
kernel boot hang. Add proper checking so that the probe would
return a failure graciously without hanging the kernel boot.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
[ Upstream commit a76fc9dda87b51010e4bc60b5e0065a70180b465 ]
The current OMAP dmtimer probe does not check for the return
status of pm_runtime_get_sync() before initializing the timer
registers. Any timer with missing hwmod data would return a
failure here, and the access of registers without enabling the
clocks for the timer would trigger a l3_noc interrupt and a
kernel boot hang. Add proper checking so that the probe would
return a failure graciously without hanging the kernel boot.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
CLK: TI: DRA7: Add timer_sys_ck aliases for Timers 13 through 16
The OMAP DMTimer API, omap_dm_timer_set_source, uses the clock name
timer_sys_ck for setting a timer's clock source for the source index
OMAP_TIMER_SRC_SYS_CLK. There is currently no clock alias data for
the Timers 13 through 16 for this clock name, so add the same.
Cc: Tero Kristo <t-kristo@ti.com>
Acked-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
The OMAP DMTimer API, omap_dm_timer_set_source, uses the clock name
timer_sys_ck for setting a timer's clock source for the source index
OMAP_TIMER_SRC_SYS_CLK. There is currently no clock alias data for
the Timers 13 through 16 for this clock name, so add the same.
Cc: Tero Kristo <t-kristo@ti.com>
Acked-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
CLK: TI: DRA7: Correct timer_sys_ck clock aliases for Timers
The OMAP DMTimer API, omap_dm_timer_set_source, can set the parent
of a timer node using 3 different values that use fixed parent names
for the clocks. The parent name, timer_sys_ck, is used for setting the
parent when used with the source index OMAP_TIMER_SRC_SYS_CLK. This
should point to the TIMER_SYS_CLK and not the SYSCLKIN2, so correct
the clock aliases appropriately. SYSCLKIN2 is not a mandatory clock
input.
Cc: Tero Kristo <t-kristo@ti.com>
Acked-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
The OMAP DMTimer API, omap_dm_timer_set_source, can set the parent
of a timer node using 3 different values that use fixed parent names
for the clocks. The parent name, timer_sys_ck, is used for setting the
parent when used with the source index OMAP_TIMER_SRC_SYS_CLK. This
should point to the TIMER_SYS_CLK and not the SYSCLKIN2, so correct
the clock aliases appropriately. SYSCLKIN2 is not a mandatory clock
input.
Cc: Tero Kristo <t-kristo@ti.com>
Acked-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: OMAP2+: timer: Remove secure timer for DRA7xx devices
Timer 12 on DRA7 SoCs is reserved for secure usage on high-secure (HS)
devices. The timer cannot be used by the kernel on HS devices, but is
available on regular general purpose (GP). This is similar to the
behavior on OMAP3 devices, so extend the logic used in commit ad24bde8f
("ARM: OMAP3: Dynamically disable secure timer nodes for secure devices")
to remove the secure timer on DRA7xx SoCs at run-time based on the SoC
device type.
Signed-off-by: Suman Anna <s-anna@ti.com>
Timer 12 on DRA7 SoCs is reserved for secure usage on high-secure (HS)
devices. The timer cannot be used by the kernel on HS devices, but is
available on regular general purpose (GP). This is similar to the
behavior on OMAP3 devices, so extend the logic used in commit ad24bde8f
("ARM: OMAP3: Dynamically disable secure timer nodes for secure devices")
to remove the secure timer on DRA7xx SoCs at run-time based on the SoC
device type.
Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: DRA7: hwmod: Add data for GPTimer 12
Add the hwmod data for GPTimer 12. GPTimer 12 is present in
WKUPAON power domain and is clocked from a secure 32K clock.
GPTimer 12 serves as a secure timer on HS devices, but is
available for kernel on regular devices.
Signed-off-by: Suman Anna <s-anna@ti.com>
Add the hwmod data for GPTimer 12. GPTimer 12 is present in
WKUPAON power domain and is clocked from a secure 32K clock.
GPTimer 12 serves as a secure timer on HS devices, but is
available for kernel on regular devices.
Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: dts: DRA7: Add timer12 node
Add the DT node for Timer12 present on DRA7 family of
SoCs. Timer12 is present in PD_WKUPAON power domain, and
has the same capabilities as the other timers, except for
the fact that it serves as a secure timer on HS devices
and is clocked only from the secure 32K clock.
The node is marked disabled for now, and the kernel should
refrain from using this secure timer on HS devices.
Signed-off-by: Suman Anna <s-anna@ti.com>
Add the DT node for Timer12 present on DRA7 family of
SoCs. Timer12 is present in PD_WKUPAON power domain, and
has the same capabilities as the other timers, except for
the fact that it serves as a secure timer on HS devices
and is clocked only from the secure 32K clock.
The node is marked disabled for now, and the kernel should
refrain from using this secure timer on HS devices.
Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: dts: DRA7: Remove ti,timer-dsp and ti,timer-pwm properties
Remove the 'ti,timer-dsp' and 'ti,timer-pwm' properties from the timer
nodes that still have them. This seems to be copied from OMAP5, on
which only certain timers are capable of providing PWM functionality
or be able to interrupt the DSP. All the GPTimers On DRA7 are capable
of PWM and interrupting any core.
These properties were used by the driver to add capabilities to each
timer, and support requesting timers by capability. In the DT world,
we expect any users of timers to use phandles to the respective timer,
and use the omap_dm_timer_request_by_node() API. The API to request
using capabilities, omap_dm_timer_request_by_cap() API should be
deprecated eventually.
Signed-off-by: Suman Anna <s-anna@ti.com>
Remove the 'ti,timer-dsp' and 'ti,timer-pwm' properties from the timer
nodes that still have them. This seems to be copied from OMAP5, on
which only certain timers are capable of providing PWM functionality
or be able to interrupt the DSP. All the GPTimers On DRA7 are capable
of PWM and interrupting any core.
These properties were used by the driver to add capabilities to each
timer, and support requesting timers by capability. In the DT world,
we expect any users of timers to use phandles to the respective timer,
and use the omap_dm_timer_request_by_node() API. The API to request
using capabilities, omap_dm_timer_request_by_cap() API should be
deprecated eventually.
Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: DRA7: hwmod: Fix the hwmod class for GPTimer4
GPTimer 4 is a regular timer and not a secure timer, so fix
the hwmod to use the correct hwmod class (even though there
are no differences in the class definition itself).
Signed-off-by: Suman Anna <s-anna@ti.com>
GPTimer 4 is a regular timer and not a secure timer, so fix
the hwmod to use the correct hwmod class (even though there
are no differences in the class definition itself).
Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: DRA7: hwmod: Add data for GPTimers 13 through 16
Add the hwmod data for GPTimers 13, 14, 15 and 16. All these
timers are present in the L4PER3 clock domain.
Without this data, the kernel boot hangs if any of the respective
timers are enabled in the DTS files.
Signed-off-by: Suman Anna <s-anna@ti.com>
Add the hwmod data for GPTimers 13, 14, 15 and 16. All these
timers are present in the L4PER3 clock domain.
Without this data, the kernel boot hangs if any of the respective
timers are enabled in the DTS files.
Signed-off-by: Suman Anna <s-anna@ti.com>
regulator: Palmas: Add has_regen3 check for TPS659038
Palmas driver is used to cater to even TPS659038 but TPS659038 does not have
REGEN3 resource. Adding another field in the driver data to check on that.
Tested-by: Nishanth Menon <nm@ti.com>
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
Palmas driver is used to cater to even TPS659038 but TPS659038 does not have
REGEN3 resource. Adding another field in the driver data to check on that.
Tested-by: Nishanth Menon <nm@ti.com>
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
regulator: palmas: Correct TPS659038 register definition for REGEN2
The register offset for REGEN2_CTRL in different for TPS659038 chip as when
compared with other Palmas family PMICs. In the case of TPS659038 the wrong
offset pointed to PLLEN_CTRL and was causing a hang. Correcting the same.
Tested-by: Nishanth Menon <nm@ti.com>
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
The register offset for REGEN2_CTRL in different for TPS659038 chip as when
compared with other Palmas family PMICs. In the case of TPS659038 the wrong
offset pointed to PLLEN_CTRL and was causing a hang. Correcting the same.
Tested-by: Nishanth Menon <nm@ti.com>
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
regulator: palmas: Fix SMPS enable/disable/is_enable for tps65917
We use regmap regulator ops to enable/disable and check if regulator
is enabled for various SMPS. However, these depend on valid
enable_reg, enable_mask and enable_value in regulator descriptor.
So, similar to fix we did in commit 318dbb02b50c
("regulator: palmas: Fix SMPS enable/disable/is_enabled"), populate the
same for TPS65917 SMPS registration. LDO definitions are already in
place.
Fixes: d6f83370ed97 ("regulator: palmas: Add tps65917 PMIC support")
Signed-off-by: Nishanth Menon <nm@ti.com>
We use regmap regulator ops to enable/disable and check if regulator
is enabled for various SMPS. However, these depend on valid
enable_reg, enable_mask and enable_value in regulator descriptor.
So, similar to fix we did in commit 318dbb02b50c
("regulator: palmas: Fix SMPS enable/disable/is_enabled"), populate the
same for TPS65917 SMPS registration. LDO definitions are already in
place.
Fixes: d6f83370ed97 ("regulator: palmas: Add tps65917 PMIC support")
Signed-off-by: Nishanth Menon <nm@ti.com>
regulator: palmas: Simplify code by not indexing regulator_desc unnecessarily
Palmas regulator needs to full up the regulator_desc based on PMIC and
type of regulator. However, we dont need to do desc[id] every time. we
can simplify by using a pointer to desc[id] and filling up the
parameters.
Signed-off-by: Nishanth Menon <nm@ti.com>
Palmas regulator needs to full up the regulator_desc based on PMIC and
type of regulator. However, we dont need to do desc[id] every time. we
can simplify by using a pointer to desc[id] and filling up the
parameters.
Signed-off-by: Nishanth Menon <nm@ti.com>
regulator: palmas: Rename palmas_regs_info to palmas_generic_regs_info
With commit d6f83370ed978d5570b7c8c22988310cb9376202 (regulator: palmas:
Add tps65917 PMIC support) palmas_regs_info naming is confusing as it is
a driver data parameter and a local variable. To prevent mistaken
updates, rename the local variable to palmas_generic_regs_info.
Signed-off-by: Nishanth Menon <nm@ti.com>
With commit d6f83370ed978d5570b7c8c22988310cb9376202 (regulator: palmas:
Add tps65917 PMIC support) palmas_regs_info naming is confusing as it is
a driver data parameter and a local variable. To prevent mistaken
updates, rename the local variable to palmas_generic_regs_info.
Signed-off-by: Nishanth Menon <nm@ti.com>
regulator: palmas: Simplify code by using pointer to palmas_reg_info
Palmas register information is part of the ddata pointer which is used
through out the code by indexing off the driver data array. Instead,
just do the indexing once and use the pointer to further reference
structure fields.
This simplifies code and prevents errors by accessing wrong variables.
Signed-off-by: Nishanth Menon <nm@ti.com>
Palmas register information is part of the ddata pointer which is used
through out the code by indexing off the driver data array. Instead,
just do the indexing once and use the pointer to further reference
structure fields.
This simplifies code and prevents errors by accessing wrong variables.
Signed-off-by: Nishanth Menon <nm@ti.com>
regulator: palmas: Rename reg_info to palmas_reg_info
reg_info is a generic term which might cause conflict at a later point
in time. To prevent such a thing from occuring in future, rename to
palmas_reg_info.
Signed-off-by: Nishanth Menon <nm@ti.com>
reg_info is a generic term which might cause conflict at a later point
in time. To prevent such a thing from occuring in future, rename to
palmas_reg_info.
Signed-off-by: Nishanth Menon <nm@ti.com>
regulator: palmas: Squelch sparse warnings
convert to static variables to squelch the following sparse warnings:
drivers/regulator/palmas-regulator.c:325:36: warning: symbol 'palma_sleep_req_info' was not declared. Should it be static?
drivers/regulator/palmas-regulator.c:1414:32: warning: symbol 'palmas_ddata' was not declared. Should it be static?
drivers/regulator/palmas-regulator.c:1427:32: warning: symbol 'tps65917_ddata' was not declared. Should it be static?
Signed-off-by: Nishanth Menon <nm@ti.com>
convert to static variables to squelch the following sparse warnings:
drivers/regulator/palmas-regulator.c:325:36: warning: symbol 'palma_sleep_req_info' was not declared. Should it be static?
drivers/regulator/palmas-regulator.c:1414:32: warning: symbol 'palmas_ddata' was not declared. Should it be static?
drivers/regulator/palmas-regulator.c:1427:32: warning: symbol 'tps65917_ddata' was not declared. Should it be static?
Signed-off-by: Nishanth Menon <nm@ti.com>
ARM: dts: am57xx-evm: Remove gpio keys pinmux
MLO now does the pinmuxing, and we need to remove pinmuxing from the
.dts files. This patch removes gpio keys pinmux nodes for
am57xx-evm.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
MLO now does the pinmuxing, and we need to remove pinmuxing from the
.dts files. This patch removes gpio keys pinmux nodes for
am57xx-evm.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
ARM: dts: BeagleBoard-x15: Remove pinmux
MLO now does the pinmuxing, and we need to remove pinmuxing from the
.dts files. This patch removes all the pinmux nodes from
am57xx-beagle-x15.dts
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
MLO now does the pinmuxing, and we need to remove pinmuxing from the
.dts files. This patch removes all the pinmux nodes from
am57xx-beagle-x15.dts
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
ARM: dts: BeagleBoard-x15: Add missing regulators
regen2 is used for PMIC internal resource.
Adding DT node for regen2 regulator.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
regen2 is used for PMIC internal resource.
Adding DT node for regen2 regulator.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
pinctrl: am43xx: dt-bindings: fix SLEWCTRL_FAST binding
According to AM437x TRM, Document SPRUHL7B, Revised December 2014,
Section 7.2.1 Pad Control Registers, setting bit 19 of the pad control
registers actually sets the SLEWCTRL value to slow rather than fast as
the current macro indicates. Introduce a new macro, SLEWCTRL_SLOW, that
sets the bit, and modify SLEWCTRL_FAST to 0 but keep it for
completeness.
Current users of the macro (i2c, mdio, and uart) are left unmodified as
SLEWCTRL_FAST was the macro used and actual desired state. Tested on
am437x-gp-evm with no difference in software performance seen.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
According to AM437x TRM, Document SPRUHL7B, Revised December 2014,
Section 7.2.1 Pad Control Registers, setting bit 19 of the pad control
registers actually sets the SLEWCTRL value to slow rather than fast as
the current macro indicates. Introduce a new macro, SLEWCTRL_SLOW, that
sets the bit, and modify SLEWCTRL_FAST to 0 but keep it for
completeness.
Current users of the macro (i2c, mdio, and uart) are left unmodified as
SLEWCTRL_FAST was the macro used and actual desired state. Tested on
am437x-gp-evm with no difference in software performance seen.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
pinctrl: am33xx: dt-bindings: fix SLEWCTRL_FAST binding
According to AM335x TRM, Document spruh73l, Revised February 2015,
Section 9.2.2 Pad Control Registers, setting bit 6 of the pad control
registers actually sets the SLEWCTRL value to slow rather than fast as
the current macro indicates. Introduce a new macro, SLEWCTRL_SLOW, that
sets the bit, and modify SLEWCTRL_FAST to 0 but keep it for
completeness.
Current users of the macro (i2c and mdio) are left unmodified as
SLEWCTRL_FAST was the macro used and actual desired state. Tested on
am335x-gp-evm with no difference in software performance seen.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
According to AM335x TRM, Document spruh73l, Revised February 2015,
Section 9.2.2 Pad Control Registers, setting bit 6 of the pad control
registers actually sets the SLEWCTRL value to slow rather than fast as
the current macro indicates. Introduce a new macro, SLEWCTRL_SLOW, that
sets the bit, and modify SLEWCTRL_FAST to 0 but keep it for
completeness.
Current users of the macro (i2c and mdio) are left unmodified as
SLEWCTRL_FAST was the macro used and actual desired state. Tested on
am335x-gp-evm with no difference in software performance seen.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
ARM: DRA7-evm: Remove pin mux
As part of IODELAY recalibration sequence all the pin mux
configuration needs to be done as part of MLO. So remove pinmux
definitions in DT.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
As part of IODELAY recalibration sequence all the pin mux
configuration needs to be done as part of MLO. So remove pinmux
definitions in DT.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
ARM: dts: dra7-evm: Keep all VDD rails always-on
[ upstream commit 395b23ca57b46e79d7956ce1d5a9381dc6fe0e3a ]
DRA7 Data Manual (SPRS857L - August 2014) section 4.1.1 states: "All
unused power supply balls must be supplied with the voltages specified
in the Section 5.2, Recommended Operating Conditions".
This implies that all unused voltage rails for Vayu can never be
switched off even if the hardware blocks inside that voltage domain is
unused. Switching off these unused rails may result in stability issues
on other domains and increased leakage and power-on-hour impacts.
J6eco-evm dts file already considers this, however j6evm-dts file needs
to be fixed to consider this constraint of the SoC.
Acked-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
[ upstream commit 395b23ca57b46e79d7956ce1d5a9381dc6fe0e3a ]
DRA7 Data Manual (SPRS857L - August 2014) section 4.1.1 states: "All
unused power supply balls must be supplied with the voltages specified
in the Section 5.2, Recommended Operating Conditions".
This implies that all unused voltage rails for Vayu can never be
switched off even if the hardware blocks inside that voltage domain is
unused. Switching off these unused rails may result in stability issues
on other domains and increased leakage and power-on-hour impacts.
J6eco-evm dts file already considers this, however j6evm-dts file needs
to be fixed to consider this constraint of the SoC.
Acked-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
ARM: DRA7-evm: Add missing regulators
Few regulators information were missing from DT. Add those
missing regulators.
Note that this might cause probe order to change and potentially
root device such as mmcblk0 might change it's order.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Few regulators information were missing from DT. Add those
missing regulators.
Note that this might cause probe order to change and potentially
root device such as mmcblk0 might change it's order.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
ARM: dts: am43xx-clocks: Fix ehrpwm tbclk data on am43xx
ehrpwm tbclk is wrongly modelled as deriving from dpll_per_m2_ck.
The TRM says tbclk is derived from SYSCLKOUT. SYSCLKOUT nothing but the
functional clock of pwmss (l4ls_gclk).
Fix this by changing source of ehrpwmx_tbclk to l4ls_gclk.
Fixes: 4da1c67719f61 ("add tbclk data for ehrpwm")
Signed-off-by: Vignesh R <vigneshr@ti.com>
ehrpwm tbclk is wrongly modelled as deriving from dpll_per_m2_ck.
The TRM says tbclk is derived from SYSCLKOUT. SYSCLKOUT nothing but the
functional clock of pwmss (l4ls_gclk).
Fix this by changing source of ehrpwmx_tbclk to l4ls_gclk.
Fixes: 4da1c67719f61 ("add tbclk data for ehrpwm")
Signed-off-by: Vignesh R <vigneshr@ti.com>
ARM: dts: am33xx-clocks: Fix ehrpwm tbclk data on am33xx
ehrpwm tbclk is wrongly modelled as deriving from dpll_per_m2_ck.
The TRM says tbclk is derived from SYSCLKOUT. SYSCLKOUT nothing but the
functional clock of pwmss (l4ls_gclk).
Fix this by changing source of ehrpwmx_tbclk to l4ls_gclk.
Fixes: 9e100ebafb91: ("Fix ehrpwm tbclk data")
Signed-off-by: Vignesh R <vigneshr@ti.com>
ehrpwm tbclk is wrongly modelled as deriving from dpll_per_m2_ck.
The TRM says tbclk is derived from SYSCLKOUT. SYSCLKOUT nothing but the
functional clock of pwmss (l4ls_gclk).
Fix this by changing source of ehrpwmx_tbclk to l4ls_gclk.
Fixes: 9e100ebafb91: ("Fix ehrpwm tbclk data")
Signed-off-by: Vignesh R <vigneshr@ti.com>
hwmon: (tmp102) add hibernation callbacks
[ Upstream commit dd378b1bcaa0ef5b14cca1e52b58ef9a3279fd8b ]
Setting a dev_pm_ops suspend/resume pair but not a set of
hibernation functions means those pm functions will not be
called upon hibernation.
Fix this by using SIMPLE_DEV_PM_OPS, which appropriately
assigns the suspend and hibernation handlers and move
mp102_suspend/tmp102_resume under CONFIG_PM_SLEEP to avoid
build warnings.
Signed-off-by: Grygorii Strashko <Grygorii.Strashko@linaro.org>
[groeck: Declare tmp102_dev_pm_ops as static variable]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
[ Upstream commit dd378b1bcaa0ef5b14cca1e52b58ef9a3279fd8b ]
Setting a dev_pm_ops suspend/resume pair but not a set of
hibernation functions means those pm functions will not be
called upon hibernation.
Fix this by using SIMPLE_DEV_PM_OPS, which appropriately
assigns the suspend and hibernation handlers and move
mp102_suspend/tmp102_resume under CONFIG_PM_SLEEP to avoid
build warnings.
Signed-off-by: Grygorii Strashko <Grygorii.Strashko@linaro.org>
[groeck: Declare tmp102_dev_pm_ops as static variable]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
ARM: OMAP2+: hwmod: fix deassert hardreset clkdm usecounting
Deasserting hardreset increases the usecount for the hwmod parent clockdomain
always, however usecount is only decreased at end in certain error cases.
This causes clockdomains to remain always on, preventing idle. Fixed by
always releasing the hwmods clockdomain parent when exiting the function.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Tested-by: Carlos Hernandez <ceh@ti.com>
Cc: Lokesh Vutla <lokeshvutla@ti.com>
Deasserting hardreset increases the usecount for the hwmod parent clockdomain
always, however usecount is only decreased at end in certain error cases.
This causes clockdomains to remain always on, preventing idle. Fixed by
always releasing the hwmods clockdomain parent when exiting the function.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Tested-by: Carlos Hernandez <ceh@ti.com>
Cc: Lokesh Vutla <lokeshvutla@ti.com>
ARM: OMAP: DRA7xx: Add clocks for PWMSS
PWMSS does not seem to support smart idle mode when clockdomain
"l4per2_clkdm" is in HW_AUTO. Hence, configuring l4per2_clkdm to
SW_WKUP.
EHRPWM has a TBCLK which is enabled by writing into CTRL_CORE_IO_2. This
clock is derived from the same clock that drives PWMSS. Hence adding
ehrpwmx_tbclk nodes.
Signed-off-by: Vignesh R <vigneshr@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
PWMSS does not seem to support smart idle mode when clockdomain
"l4per2_clkdm" is in HW_AUTO. Hence, configuring l4per2_clkdm to
SW_WKUP.
EHRPWM has a TBCLK which is enabled by writing into CTRL_CORE_IO_2. This
clock is derived from the same clock that drives PWMSS. Hence adding
ehrpwmx_tbclk nodes.
Signed-off-by: Vignesh R <vigneshr@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
ARM: OMAP2+: DRA7xx: add hwmod entries for PWMSS
This patch adds hwmod entries for PWMSS on DRA7.
Signed-off-by: Vignesh R <vigneshr@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
This patch adds hwmod entries for PWMSS on DRA7.
Signed-off-by: Vignesh R <vigneshr@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
ARM: dts: am57xx-beagle-x15: Add thermal map
BeagleBoard-X15 has capability for a fan and has an onboard TMP102
temperature sensor as well. This allows us to create a new thermal
zone (called, un-imaginatively "board"), and allows us to use some
active cooling as temperatures start edge upward in the system by
creating a new alert temperature (emperically 50C) for cpu.
NOTE: Fan is NOT mounted by default on the platform, in such a case,
all we end up doing is switch on a regulator and leak very minimal
current.
Signed-off-by: Nishanth Menon <nm@ti.com>
BeagleBoard-X15 has capability for a fan and has an onboard TMP102
temperature sensor as well. This allows us to create a new thermal
zone (called, un-imaginatively "board"), and allows us to use some
active cooling as temperatures start edge upward in the system by
creating a new alert temperature (emperically 50C) for cpu.
NOTE: Fan is NOT mounted by default on the platform, in such a case,
all we end up doing is switch on a regulator and leak very minimal
current.
Signed-off-by: Nishanth Menon <nm@ti.com>
ARM: dts: DRA7 / OMAP5: Thermal: Introduce phandle
Introduce phandle such that it can be refered from elsewhere (example:
board file)
Signed-off-by: Nishanth Menon <nm@ti.com>
Introduce phandle such that it can be refered from elsewhere (example:
board file)
Signed-off-by: Nishanth Menon <nm@ti.com>
(gpio-fan): Add thermal control hooks
Allow gpio-fan to be used as thermal cooling device for platforms that
use GPIO maps to control fans.
As part of this change, we make the shutdown and remove logic the same
as well.
Back port of: https://patchwork.kernel.org/patch/5594731/
reverted in upstream as a result of http://www.spinics.net/lists/linux-next/msg31573.html
Signed-off-by: Nishanth Menon <nm@ti.com>
Acked-by: Eduardo Valentin <edubezval@gmail.com>
Allow gpio-fan to be used as thermal cooling device for platforms that
use GPIO maps to control fans.
As part of this change, we make the shutdown and remove logic the same
as well.
Back port of: https://patchwork.kernel.org/patch/5594731/
reverted in upstream as a result of http://www.spinics.net/lists/linux-next/msg31573.html
Signed-off-by: Nishanth Menon <nm@ti.com>
Acked-by: Eduardo Valentin <edubezval@gmail.com>
thermal: Introduce dummy functions when thermal is not defined
When CONFIG_THERMAL is not enabled, it is better to introduce
equivalent dummy functions in the exported header than to
introduce #ifdeffery in drivers using the function.
This will prevent issues such as that reported in:
http://www.spinics.net/lists/linux-next/msg31573.html
While at it switch over to IS_ENABLED for thermal macros
to allow for thermal framework to be built as framework
and relevant APIs be usable by relevant drivers as a result.
backport from: https://patchwork.kernel.org/patch/5828261/
Reported-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Nishanth Menon <nm@ti.com>
When CONFIG_THERMAL is not enabled, it is better to introduce
equivalent dummy functions in the exported header than to
introduce #ifdeffery in drivers using the function.
This will prevent issues such as that reported in:
http://www.spinics.net/lists/linux-next/msg31573.html
While at it switch over to IS_ENABLED for thermal macros
to allow for thermal framework to be built as framework
and relevant APIs be usable by relevant drivers as a result.
backport from: https://patchwork.kernel.org/patch/5828261/
Reported-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Nishanth Menon <nm@ti.com>
ARM: dts: am57xx-beagle-x15: Add GPIO controlled fan node
TPS gpio now controls a 5v 500mA TL5209 regulator which may be supply
a fan (such as AFB02505HHB) over J1 connector for various purposes.
Provide device tree node to enable the same.
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Conflicts:
arch/arm/boot/dts/am57xx-beagle-x15.dts
Signed-off-by: Tero Kristo <t-kristo@ti.com>
TPS gpio now controls a 5v 500mA TL5209 regulator which may be supply
a fan (such as AFB02505HHB) over J1 connector for various purposes.
Provide device tree node to enable the same.
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Conflicts:
arch/arm/boot/dts/am57xx-beagle-x15.dts
Signed-off-by: Tero Kristo <t-kristo@ti.com>
hwmon: (gpio-fan) Add a shutdown handler to poweroff the fans
[ Upstream commit b95579cd8795442e75c8846fa6eeb4fb442e9d83 ]
Poweroff the fans when shutting down the system. Else,
echo '1' > /sys/class/hwmon/hwmon0/fan1_target; poweroff leaves the
fan running if the System power off does not drive the gpio expander
which might control the fan power supply.
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
[nsekhar@ti.com: drop unnecessary conflict information]
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
[ Upstream commit b95579cd8795442e75c8846fa6eeb4fb442e9d83 ]
Poweroff the fans when shutting down the system. Else,
echo '1' > /sys/class/hwmon/hwmon0/fan1_target; poweroff leaves the
fan running if the System power off does not drive the gpio expander
which might control the fan power supply.
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
[nsekhar@ti.com: drop unnecessary conflict information]
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
hwmon: (gpio-fan) Allow usage of gpio operations that may sleep
[ Upstream commit 52a95c1185220feb514c8e167bd6033c0da6f576 ]
Certain I2C based GPIO expanders could be used in sleepable context,
this results in:
[ 115.890569] ------------[ cut here ]------------
[ 115.895422] WARNING: CPU: 0 PID: 1115 at drivers/gpio/gpiolib.c:1370 gpiod_set_raw_value+0x40/0x4c()
[ 115.905024] Modules linked in:
[ 115.908229] CPU: 0 PID: 1115 Comm: sh Tainted: G W 3.18.0-rc7-next-20141203-dirty #1
[ 115.917461] Hardware name: Generic DRA74X (Flattened Device Tree)
[ 115.923876] [<c0015368>] (unwind_backtrace) from [<c00119f4>] (show_stack+0x10/0x14)
[ 115.932013] [<c00119f4>] (show_stack) from [<c05b78e8>] (dump_stack+0x78/0x94)
[ 115.939594] [<c05b78e8>] (dump_stack) from [<c003de28>] (warn_slowpath_common+0x7c/0xb4)
[ 115.948094] [<c003de28>] (warn_slowpath_common) from [<c003de7c>] (warn_slowpath_null+0x1c/0x24)
[ 115.957315] [<c003de7c>] (warn_slowpath_null) from [<c03461e8>] (gpiod_set_raw_value+0x40/0x4c)
[ 115.966457] [<c03461e8>] (gpiod_set_raw_value) from [<c04866f4>] (set_fan_speed+0x4c/0x64)
[ 115.975145] [<c04866f4>] (set_fan_speed) from [<c04868a8>] (set_rpm+0x98/0xac)
[ 115.982742] [<c04868a8>] (set_rpm) from [<c039fb4c>] (dev_attr_store+0x18/0x24)
[ 115.990426] [<c039fb4c>] (dev_attr_store) from [<c01b0a28>] (sysfs_kf_write+0x4c/0x50)
[ 115.998742] [<c01b0a28>] (sysfs_kf_write) from [<c01afe1c>] (kernfs_fop_write+0xbc/0x19c)
[ 116.007333] [<c01afe1c>] (kernfs_fop_write) from [<c0148cc4>] (vfs_write+0xb0/0x1a0)
[ 116.015461] [<c0148cc4>] (vfs_write) from [<c0148fbc>] (SyS_write+0x44/0x84)
[ 116.022881] [<c0148fbc>] (SyS_write) from [<c000e5c0>] (ret_fast_syscall+0x0/0x48)
[ 116.030833] ---[ end trace 3a0b636123acab82 ]---
So, switch over to sleepable GPIO operations as there is no mandatory
need for non-sleepable gpio operations in the fan driver.
This allows the fan driver to be used with i2c based gpio expanders such
as palmas_gpio.
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
[ Upstream commit 52a95c1185220feb514c8e167bd6033c0da6f576 ]
Certain I2C based GPIO expanders could be used in sleepable context,
this results in:
[ 115.890569] ------------[ cut here ]------------
[ 115.895422] WARNING: CPU: 0 PID: 1115 at drivers/gpio/gpiolib.c:1370 gpiod_set_raw_value+0x40/0x4c()
[ 115.905024] Modules linked in:
[ 115.908229] CPU: 0 PID: 1115 Comm: sh Tainted: G W 3.18.0-rc7-next-20141203-dirty #1
[ 115.917461] Hardware name: Generic DRA74X (Flattened Device Tree)
[ 115.923876] [<c0015368>] (unwind_backtrace) from [<c00119f4>] (show_stack+0x10/0x14)
[ 115.932013] [<c00119f4>] (show_stack) from [<c05b78e8>] (dump_stack+0x78/0x94)
[ 115.939594] [<c05b78e8>] (dump_stack) from [<c003de28>] (warn_slowpath_common+0x7c/0xb4)
[ 115.948094] [<c003de28>] (warn_slowpath_common) from [<c003de7c>] (warn_slowpath_null+0x1c/0x24)
[ 115.957315] [<c003de7c>] (warn_slowpath_null) from [<c03461e8>] (gpiod_set_raw_value+0x40/0x4c)
[ 115.966457] [<c03461e8>] (gpiod_set_raw_value) from [<c04866f4>] (set_fan_speed+0x4c/0x64)
[ 115.975145] [<c04866f4>] (set_fan_speed) from [<c04868a8>] (set_rpm+0x98/0xac)
[ 115.982742] [<c04868a8>] (set_rpm) from [<c039fb4c>] (dev_attr_store+0x18/0x24)
[ 115.990426] [<c039fb4c>] (dev_attr_store) from [<c01b0a28>] (sysfs_kf_write+0x4c/0x50)
[ 115.998742] [<c01b0a28>] (sysfs_kf_write) from [<c01afe1c>] (kernfs_fop_write+0xbc/0x19c)
[ 116.007333] [<c01afe1c>] (kernfs_fop_write) from [<c0148cc4>] (vfs_write+0xb0/0x1a0)
[ 116.015461] [<c0148cc4>] (vfs_write) from [<c0148fbc>] (SyS_write+0x44/0x84)
[ 116.022881] [<c0148fbc>] (SyS_write) from [<c000e5c0>] (ret_fast_syscall+0x0/0x48)
[ 116.030833] ---[ end trace 3a0b636123acab82 ]---
So, switch over to sleepable GPIO operations as there is no mandatory
need for non-sleepable gpio operations in the fan driver.
This allows the fan driver to be used with i2c based gpio expanders such
as palmas_gpio.
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
ti_config_fragments/baseport.cfg: explicitly enable DEBUG_FS
CONFIG_DEBUG_FS gets automatically selected by CONFIG_TRACING. However,
with CONFIG_FTRACE disabled, CONFIG_DEBUG_FS, DEBUG_FS should have
been removed from the final kernel configuration. It is not the case
since defconfig_merge.sh appends config flags added by config fragments
to the end of the omap2plus based generated config options.
In contrast, tools like merge_config.sh (under scripts/kconfig)
take all config and also account for dependencies. Hence disabling
FTRACE causes DEBUG_FS also to be disabled and therefore enabling
DEBUG_FS explicitly.
Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
CONFIG_DEBUG_FS gets automatically selected by CONFIG_TRACING. However,
with CONFIG_FTRACE disabled, CONFIG_DEBUG_FS, DEBUG_FS should have
been removed from the final kernel configuration. It is not the case
since defconfig_merge.sh appends config flags added by config fragments
to the end of the omap2plus based generated config options.
In contrast, tools like merge_config.sh (under scripts/kconfig)
take all config and also account for dependencies. Hence disabling
FTRACE causes DEBUG_FS also to be disabled and therefore enabling
DEBUG_FS explicitly.
Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
ARM: DRA7: hwmod_data: Change locked_class for atl hwmod
The ATL hwmod can be used in nested way when it is selected to be the
functional clock for McASP. For this lockdep validator will trigger false
positive warning.
By assigning separate class to atl locking will sort this out.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
The ATL hwmod can be used in nested way when it is selected to be the
functional clock for McASP. For this lockdep validator will trigger false
positive warning.
By assigning separate class to atl locking will sort this out.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
ARM: omap2+: omap_hwmod: Use _nested version of spinlock for oh->_lock
Add lockdep_class member to struct omap_hwmod and use this number to
specify the subclass of the given hwmod's lock.
When defining the hwmods the lockdep_level can be initialized to indicate
that this lock might be used in a nested fashion.
DRA7x's ATL hwmod is one example for this since McASP can select ATL clock
as functional clock, which will trigger nested oh->_lock usage. This will
trigger false warning from lockdep validator since it is dealing with
classes and for it all hwmod clocks are the same class.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Add lockdep_class member to struct omap_hwmod and use this number to
specify the subclass of the given hwmod's lock.
When defining the hwmods the lockdep_level can be initialized to indicate
that this lock might be used in a nested fashion.
DRA7x's ATL hwmod is one example for this since McASP can select ATL clock
as functional clock, which will trigger nested oh->_lock usage. This will
trigger false warning from lockdep validator since it is dealing with
classes and for it all hwmod clocks are the same class.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Revert "ARM: OMAP2+: hwmod: Use spin_lock_irqsave_nested() for locking"
This reverts commit 7dca540329010694ca5f2508bf2359cccabb6228.
Not correct fix, any casted pointer will be bigger than
MAX_LOCKDEP_SUBCLASSES, which is 8
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
This reverts commit 7dca540329010694ca5f2508bf2359cccabb6228.
Not correct fix, any casted pointer will be bigger than
MAX_LOCKDEP_SUBCLASSES, which is 8
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
ARM: dts: dra7: Correct clock tree for sys_32k_ck
This is w.r.t J6/J6eco: 32clk is psuedo (erratum i856) - clock source.
Errata i856 for the AM572x (DRA7xx) points out that the 32.768KHz external
crystal is not enabled at power up. Instead the CPU falls back to using
an emulation for the 32KHz clock which is SYSCLK1/610. SYSCLK1 is usually
20MHz on boards so far (which gives an emulated frequency of 32.786KHz)
Modelling the same in device tree.
Signed-off-by: Keerthy <j-keerthy@ti.com>
This is w.r.t J6/J6eco: 32clk is psuedo (erratum i856) - clock source.
Errata i856 for the AM572x (DRA7xx) points out that the 32.768KHz external
crystal is not enabled at power up. Instead the CPU falls back to using
an emulation for the 32KHz clock which is SYSCLK1/610. SYSCLK1 is usually
20MHz on boards so far (which gives an emulated frequency of 32.786KHz)
Modelling the same in device tree.
Signed-off-by: Keerthy <j-keerthy@ti.com>
ti_config_fragments/baseport.cfg: Add IOdelay configuration driver
IODelay module is necessary for DRA7 family of SoCs
Signed-off-by: Nishanth Menon <nm@ti.com>
IODelay module is necessary for DRA7 family of SoCs
Signed-off-by: Nishanth Menon <nm@ti.com>
ARM: dts: dra7: Add iodelay module
Add the IODelay module configuration support for DRA74x/DRA72x/AM57xx family
of devices
Signed-off-by: Nishanth Menon <nm@ti.com>
Add the IODelay module configuration support for DRA74x/DRA72x/AM57xx family
of devices
Signed-off-by: Nishanth Menon <nm@ti.com>
pinctrl: Introduce TI IOdelay configuration driver
SoC family such as DRA7 family of processors have, in addition
to the regular muxing of pins (as done by pinctrl-single), an
additional hardware module called IODelay which is also expected to be
configured. This "IODelay" module has it's own register space that is
independent of the control module.
It is advocated strongly in TI's official documentation considering
the existing design of the DRA7 family of processors during mux or
IODelay reconfiguration, there is a potential for a significant glitch
which may cause functional impairment to certain hardware. It is
hence recommended to do as little of muxing as absolutely necessary
without I/O isolation (which can only be done in initial stages of
bootloader).
NOTE: with the system wide I/O isolation scheme present in DRA7 SoC
family, it is not reasonable to do stop all I/O operations for every
such pad configuration scheme. So, we will let it glitch when used in
this mode.
Even with the above limitation, certain functionality such as MMC has
mandatory need for IODelay reconfiguration requirements, depending on
speed of transfer. In these cases, with careful examination of usecase
involved, the expected glitch can be controlled such that it does not
impact functionality.
In short, IODelay module support as a padconf driver being introduced
here is not expected to do SoC wide I/O Isolation and is meant for
a limited subset of IODelay configuration requirements that need to
be dynamic and whose glitchy behavior will not cause functionality
failure for that interface.
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
SoC family such as DRA7 family of processors have, in addition
to the regular muxing of pins (as done by pinctrl-single), an
additional hardware module called IODelay which is also expected to be
configured. This "IODelay" module has it's own register space that is
independent of the control module.
It is advocated strongly in TI's official documentation considering
the existing design of the DRA7 family of processors during mux or
IODelay reconfiguration, there is a potential for a significant glitch
which may cause functional impairment to certain hardware. It is
hence recommended to do as little of muxing as absolutely necessary
without I/O isolation (which can only be done in initial stages of
bootloader).
NOTE: with the system wide I/O isolation scheme present in DRA7 SoC
family, it is not reasonable to do stop all I/O operations for every
such pad configuration scheme. So, we will let it glitch when used in
this mode.
Even with the above limitation, certain functionality such as MMC has
mandatory need for IODelay reconfiguration requirements, depending on
speed of transfer. In these cases, with careful examination of usecase
involved, the expected glitch can be controlled such that it does not
impact functionality.
In short, IODelay module support as a padconf driver being introduced
here is not expected to do SoC wide I/O Isolation and is meant for
a limited subset of IODelay configuration requirements that need to
be dynamic and whose glitchy behavior will not cause functionality
failure for that interface.
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
pinctrl: bindings: pinctrl: Add support for TI's IODelay configuration
SoCs such as DRA7 family from Texas Instruments also include a highly
configurable hardware block called the IOdelay block. This block
allows very specific custom fine tuning for electrical characteristics
of IO pins.
In addition to the regular pin muxing modes supported by the
pinctrl-single, additional configuration for this block for specific
pins may also be mandatory in certain cases.
It is advocated strongly in TI's official documentation considering
the existing design of the DRA7 family of processors, which during mux
or IODelay reconfiguration, has a potential for a significant glitch
which may cause functional impairment to certain hardware. It is hence
recommended to do as little of muxing as absolutely necessary without
IO isolation (which can only be done in initial stages of bootloader).
Even with the above limitation, certain functionality such as MMC may
mandate the need of IODelay reconfiguration depending on speed of
transfer. Hence, introduce a new binding to facilitate programming the
same.
Signed-off-by: Nishanth Menon <nm@ti.com>
SoCs such as DRA7 family from Texas Instruments also include a highly
configurable hardware block called the IOdelay block. This block
allows very specific custom fine tuning for electrical characteristics
of IO pins.
In addition to the regular pin muxing modes supported by the
pinctrl-single, additional configuration for this block for specific
pins may also be mandatory in certain cases.
It is advocated strongly in TI's official documentation considering
the existing design of the DRA7 family of processors, which during mux
or IODelay reconfiguration, has a potential for a significant glitch
which may cause functional impairment to certain hardware. It is hence
recommended to do as little of muxing as absolutely necessary without
IO isolation (which can only be done in initial stages of bootloader).
Even with the above limitation, certain functionality such as MMC may
mandate the need of IODelay reconfiguration depending on speed of
transfer. Hence, introduce a new binding to facilitate programming the
same.
Signed-off-by: Nishanth Menon <nm@ti.com>
pinctrl: dra: dt-bindings: Add virtual mode configuration option
In addition to the regular mux configuration such as mux mode 1,
2 etc, certain pins of DRA7 require to have "virtual mode" also
programmed. This allows for predefined delay characteristics to
be used by the SoC to meet timing characterstics needed for the
interface.
Provide easy to use macro to do the same.
It is important to note that the official TI guidelines recommend
to do as minimal pin reconfiguration beyond the bootloader given
the design of the hardware involved which can result in substantial
glitches which may impair functionality of certain peripherals.
Signed-off-by: Nishanth Menon <nm@ti.com>
In addition to the regular mux configuration such as mux mode 1,
2 etc, certain pins of DRA7 require to have "virtual mode" also
programmed. This allows for predefined delay characteristics to
be used by the SoC to meet timing characterstics needed for the
interface.
Provide easy to use macro to do the same.
It is important to note that the official TI guidelines recommend
to do as minimal pin reconfiguration beyond the bootloader given
the design of the hardware involved which can result in substantial
glitches which may impair functionality of certain peripherals.
Signed-off-by: Nishanth Menon <nm@ti.com>