05 Dec, 2015
9 commits
-
Add a dspmem node on the K2 Galileo EVM board. The node
allows the entire MSM RAM (1 MB) to be mapped to userspace
to enable the Keystone Multi Proc Manager (MPM) based
usecases.Signed-off-by: Suman Anna
-
The Keystone 2 Galileo SoC has a single TMS320C66x DSP
Core Subsystem (C66x CorePac), containing a C66x Fixed /
Floating-Point DSP Core, and 32KB of L1P & L1D SRAMs and a
1MB L2 SRAM. Add the DT node and the rproc alias for this DSP
processor sub-system.The DT node has a new property 'power-domains', and uses
slightly different property values for 'clocks' and 'resets'
compared to other Keystone 2 SoCs. The processor does not have
a MMU, and uses various IPC Generation registers and shared
memory for inter-processor communication.NOTE:
The node name uses a DSP number suffix and does not include the
address for now. This is required to match the DT name used by
the userland MPM stack for working properly.Signed-off-by: Andrew F. Davis
Signed-off-by: Suman Anna -
Add support to the keystone remoteproc driver for managing the
DSP present in the Keystone 2 Galileo (K2G) SoC. The K2G SoC has
a Power Management Micro Controller (PMMC) that manages the
individual device's power, clock and reset functionalities.The keystone remoteproc driver already uses standard frameworks
for reset and clock control, so it doesn't require any significant
modifications other than a new compatible suitable for K2G DSP.The binding document is also updated to reflect the modified
property values used by the K2G DSP node as compared to the
values used by existing Keystone 2 DSPs.NOTE:
The enhancement to use common pm_runtime framework for all Keystone
2 SoCs is left for a future time. The redundata clock API usage for
K2G does not impact any functionality, but is still required for
other K2 SoCs.Signed-off-by: Suman Anna
Signed-off-by: Andrew F. Davis -
The Keystone remoteproc driver has already been enhanced to
support using the reset framework API for managing the DSP
device resets. All the existing DSP DT nodes have also been
switched to use the 'resets' property instead of the deprecated
'ti,syscon-psc' property.All the Keystone 2 family of SoCs are expected to be using reset
drivers going forward, so drop the support for the direct syscon
PSC based reset handling from the driver completely. The DT
binding has also been updated accordingly.While at this, also add a build dependency for the driver
against the RESET_CONTROLLER Kconfig, and switch to using the
devm_reset_control_get() API instead of the optional variant.Signed-off-by: Andrew F. Davis
[s-anna@ti.com: mandatory reset dependencies, binding updates]
Signed-off-by: Suman Anna -
Replace the custom 'ti,syscon-psc' property used for representing
device resets with a DT standard 'resets' property in the DSP node
present within the Keystone 2 Edison SoC. The 'ti,syscon-psc'
property is deprecated, and will not be supported anymore.Signed-off-by: Andrew F. Davis
[s-anna@ti.com: update commit description]
Signed-off-by: Suman Anna -
Replace the custom 'ti,syscon-psc' property used for representing
device resets with a DT standard 'resets' property in the DSP nodes
present within the Keystone 2 Lamarr SoC. The 'ti,syscon-psc'
property is deprecated, and will not be supported anymore.Signed-off-by: Andrew F. Davis
[s-anna@ti.com: update commit description]
Signed-off-by: Suman Anna -
Replace the custom 'ti,syscon-psc' property used for representing
device resets with a DT standard 'resets' property in the DSP nodes
present within the Keystone 2 Hawking/Kepler SoCs. The 'ti,syscon-psc'
property is deprecated, and will not be supported anymore.Signed-off-by: Andrew F. Davis
[s-anna@ti.com: update commit description]
Signed-off-by: Suman Anna -
The Keystone family of SoCs has the reset registers as part of the
Power and Sleep Controller (PSC) module. The keystone remoteproc
driver currently manages these DSP resets by itself through the
regmap/syscon API.Enhance the keystone remoteproc driver to start using the reset
framework API for managing resets. This is being done to streamline
the driver usage for supporting the DSP on Keystone 2 Galileo (K2G)
SoC. This also switches the driver to use a more standard framework
for resets.The support is added as an incremental change, so the regmap/syscon
framework is used as a fallback to support the transition of the
Keystone 2 DSP DTS nodes from using 'ti,psc-syscon' to the 'resets'
property.Signed-off-by: Andrew F. Davis
[s-anna@ti.com: add error checking, checkpatch fixes, binding updates]
Signed-off-by: Suman Anna -
…nel/platform-linux-feature-tree into rproc-linux-4.1.y
Resync with the latest platform base code. The merge pulls in various
required patches, fixes and new features including the following:
- A new SYSCON reset driver that will be used by Keystone 2
remoteproc driver for K2HK/L/E SoCs
- Device nodes for Device State Controller, IRQ Controller for
receiving interrupts from remoteprocs, and a DSP GPIO Controller
for sending interrupts to DSPs on Keystone 2 Galileo SoC
- Fixes in the TI SCI protocol to work with latest updates on the
PMMC firmware for isolating reset control from clock control ops
for K2G reset driver functionality
- A new TI SCI reset driver that will be used by Keystone 2
remoteproc driver for K2G SoCOther updates include
- Clock updates to various Keystone 2 Galileo DTS nodes
- LDO/SMPS fixes on AM57xx IDK boards
- Various config fragments improvements to enable reset
framework and drivers* 'platform-ti-linux-4.1.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree: (53 commits)
ARM: dts: k2g: Add DSP GPIO controller node
ARM: dts: k2g: Add keystone IRQ controller node
ARM: dts: k2g: Add device state controller node
ti_config_fragments/baseport: Enable TI SCI reset driver
ARM: dts: k2g: Add TI SCI reset-controller node
reset: Add the TI SCI reset driver
Documentation: dt: reset: Add TI SCI reset binding
dt-bindings: reset: Add k2g reset definitions
ti_config_fragments/baseport: enable reset-syscon driver
ARM: Keystone: Enable ARCH_HAS_RESET_CONTROLLER
ARM: dts: keystone: Add PSC reset node
reset: add a SYSCON based reset driver
Documentation: dt: reset: Add syscon reset binding
ARM: OMAP2+: omap_hwmod: Always restore saved hardreset context
hwmon: (tmp102) Force wait for conversion time for the first valid data
ti_config_fragments/baseport: Build thermal into kernel
firmware: ti_sci: Add device_resets calls to the device ops
firmware: ti_sci: Drop resets field from ti_sci_set_device_state calls
ARM: dts: k2g: Fix Message Manager interrupt polarity
baseport.cfg: Enable SYSTEM V IPC
...Signed-off-by: Suman Anna <s-anna@ti.com>
04 Dec, 2015
13 commits
-
Add the DSP GPIO controller node on Keystone 2 Galileo SoC.
This is used to send interrupts to the only DSP processor
subsystem present on the SoC. The IP is identical to that
of the equivalent nodes on existing K2 SoCs.Signed-off-by: Andrew F. Davis
[s-anna@ti.com: revise commit description slightly]
Signed-off-by: Suman Anna -
Add the Keystone IRQ controller IP node on Keystone 2 Galileo
SoC. This allows the ARM CorePac core to receive interrupts
from remote processor devices (eg: DSP) on the SoC.The IP is identical in functionality to that of the equivalent
nodes on existing K2 SoCs. The only difference is the ARM INTC
interrupt id/event number.Signed-off-by: Andrew F. Davis
[s-anna@ti.com: revise commit description slightly]
Signed-off-by: Suman Anna -
Add the device state controller node as a syscon node to the
Keystone 2 Galileo SoC. This module provides similar device
control functionality as that on the existing K2 SoCs.One example usage would be the boot address programming of the
DSP processor sub-system.Signed-off-by: Andrew F. Davis
[s-anna@ti.com: relocate node and revise commit description]
Signed-off-by: Suman Anna -
Enable the TI SCI Reset driver required for the reset management
of remote processor devices on Keystone 2 Galileo SoC. The driver
is built-in by default to reduce the chances of deferred probing.Signed-off-by: Suman Anna
Acked-by: Nishanth Menon -
Add a reset-controller node for managing resets of various
remote processor devices on the SoC over the Texas Instrument's
System Control Interface (TI SCI) protocol.Signed-off-by: Andrew F. Davis
[s-anna@ti.com: revise commit description slightly]
Signed-off-by: Suman Anna
Acked-by: Nishanth Menon -
Some TI Keystone family of SoCs contain a system controller (like the
Power Management Micro Controller (PMMC) on Keystone 2 Galileo SoC)
that manage the low-level device control (like clocks, resets etc)
for the various hardware modules present on the SoC. These device
control operations are provided to the host processor OS through a
communication protocol called the TI System Control Interface (TI SCI)
protocol.This patch adds a reset driver that communicates to the system
controller over the TI SCI protocol for performing reset management
of various devices present on the SoC. Various reset functionalities
are achieved by the means of different TI SCI device operations
provided by the TI SCI framework.Signed-off-by: Andrew F. Davis
[s-anna@ti.com: documentation changes, revised commit message]
Signed-off-by: Suman Anna
Acked-by: Nishanth Menon -
Add TI SCI reset controller binding. This describes the DT binding
details for a reset controller node providing reset management services
to hardware blocks (reset consumers) using the Texas Instrument's System
Control Interface (TI SCI) protocol to communicate to a system controller
block present on the SoC.Signed-off-by: Andrew F. Davis
[s-anna@ti.com: revise the binding format]
Signed-off-by: Suman Anna
Acked-by: Nishanth Menon -
Add identifiers for the reset values to be used by reset
consumer device nodes (like a DSP) on the Keystone 2
Galileo (K2G) SoC. The values are used to define the
resets required by the devices, and are defined in
conformance with those used on the Power Management
Micro Controller (PMMC) firmware.Signed-off-by: Andrew F. Davis
Signed-off-by: Suman Anna
Acked-by: Nishanth Menon -
Enable the SYSCON based Reset driver required for the reset
management of remote processor devices on Keystone 2 family of
SoCs (K2HK/K2L/K2E). The driver is built-in by default to reduce
the chances of deferred probing.Signed-off-by: Suman Anna
-
The Keystone 2 family of SoCs will use various Reset Controller
drivers for managing the resets of remote processor devices like
DSPs on the SoC, so select the ARCH_HAS_RESET_CONTROLLER option
by default to enable the Reset framework.Signed-off-by: Suman Anna
-
Add a Power Sleep Controller (PSC) reset controller node
managing the resets required by the DSPs on Keystone 2
family of SoCs (K2HK/K2L/K2E).Signed-off-by: Andrew F. Davis
Signed-off-by: Suman Anna -
Add a reset-controller driver for performing reset management of
various devices present on the SoC, with the reset registers shared
between devices in a common register memory space. This driver uses
the syscon/regmap frameworks to actually implement the various reset
functionalities needed by the reset consumer devices.Signed-off-by: Andrew F. Davis
[s-anna@ti.com: add documentation, syscon name change]
Signed-off-by: Suman Anna -
Add syscon reset controller binding. This will hook to the reset
framework and use syscon/regmap to set reset bits. This allows
reset control of individual SoC subsytems and devices with
memory-mapped reset registers in a common register memory
space.Signed-off-by: Andrew F. Davis
[s-anna@ti.com: revise the binding format]
Signed-off-by: Suman Anna
03 Dec, 2015
1 commit
-
Previously when restoring hardreset context during
omap_hwmod_restore_context we would only deassert the hardreset lines if
the module was previously active, however, if a hwmod has all hardresets
asserted then _enable will return without actually enabling the module.This is a problem for the gfx hwmod on am437x as it gets disabled in
suspend path so it appears as disabled to the restore context code but
then during the attempted enable call during the regular kernel resume
path, the hwmod cannot actually be enabled.Signed-off-by: Dave Gerlach
Acked-by: Tero Kristo
01 Dec, 2015
2 commits
-
TMP102 works based on conversions done periodically. However, as per
the TMP102 data sheet[1] the first conversion is triggered immediately
after we program the configuration register. The temperature data
registers do not reflect proper data until the first conversion is
complete (in our case HZ/4).The driver currently sets the last_update to be jiffies - HZ, just
after the configuration is complete. When tmp102 driver registers
with the thermal framework, it immediately tries to read the sensor
temperature data. This takes place even before the conversion on the
TMP102 is complete and results in an invalid temperature read.Depending on the value read, this may cause thermal framework to
assume that a critical temperature event has occurred and attempts to
shutdown the system.Instead of causing an invalid mid-conversion value to be read
erroneously, we mark the last_update to be in-line with the current
jiffies. This allows the tmp102_update_device function to skip update
until the required conversion time is complete. Further, we ensure to
return -EAGAIN result instead of returning spurious temperature (such
as 0C) values to the caller to prevent any wrong decisions made with
such values.A simpler alternative approach could be to sleep in the probe for the
duration required, but that will result in latency that is undesirable
that can delay boot sequence un-necessarily.[1] http://www.ti.com/lit/ds/symlink/tmp102.pdf
Reported-by: Aparna Balasubramanian
Reported-by: Elvita Lobo
Reported-by: Yan Liu
Signed-off-by: Nishanth Menon -
Thermal support is not an optional module on SoCs such as DRA7. It
needs to be built in to protect the system in case of kernel boot even
before filesystems startup OR in cases of user errors (such as missing
modules).Signed-off-by: Nishanth Menon
25 Nov, 2015
3 commits
-
Add set_device_resets to the device ops of ti_sci to handle new
TI_SCI_MSG_SET_DEVICE_RESETS message introduced with ABI 2.3 that
will control the resets of a device without touching any of the
other state associated with that device.Previously resets control was handled by the TI_SCI_MSG_SET_DEVICE
message which also controls device state. This would lead to the
reset framework being responsible for controlling resets but also
requiring knowledge about the state of the device or making assumptions
and causing undefined behavior. With this new split ti_sci_pm_domains
can control the state exclusively while also setting the reset value
when turning the device on and the reset framework will be able to
control resets independently of device state.Also add get_device_resets to return the state of the resets of a
device.Acked-by: Nishanth Menon
Signed-off-by: Dave Gerlach -
TI_SCI_MSG_SET_DEVICE_STATE no longer will control resets as this has
been moved to a new separate ABI as of ABI 2.3 so drop the resets field
from the message request and update ti_sci_set_device_state and all
functions using it to no longer set the resets field.Also update ti_sci_pm_domains to avoid build breakage as it uses the
get_device op which used to take resets as a parameter.Acked-by: Nishanth Menon
Signed-off-by: Dave Gerlach -
It seems that the message manager proxy interrupt is held high for as
long as there is data in the queue. Since we handle a single message
in the TI message manager driver, If there are multiple messages already
pending in the queue prior to the driver's handler getting invoked,
Then, only the first message is handled (triggered by the rising edge).Other pending messages in the queue are never handled and system
deadlocks and eventually queue overflows.Signed-off-by: Nishanth Menon
24 Nov, 2015
4 commits
-
The phys_addr_t types can be printed properly using the %pa
printk format-specifier, there is no need to resort to the
unsigned long long type-casting to deal with different
possible type sizes.Reviewed-by: Lokesh Vutla
Signed-off-by: Suman Anna -
The dma_addr_t types can be printed properly using the %pad
printk format-specifier, there is no need to resort to the
unsigned long long type-casting to deal with different possible
type sizes.Reviewed-by: Lokesh Vutla
Signed-off-by: Suman Anna -
System V IPC is enabled in omap2plus_defconfig but it is not enabled
in keystone_defconfig.
System V IPC is required by some LTP tests and it is good to have
in general as other userspace tools depend on it.Signed-off-by: Carlos Hernandez
-
Merge in the updated iommu feature branch into remoteproc tree to
pull in a minor mutex locking fix in OMAP IOMMU quirks code.* 'iommu-linux-4.1.y' of git://git.ti.com/rpmsg/iommu:
ARM: OMAP2+: iommu: fix sleeping lock usage in atomic context bugSigned-off-by: Suman Anna
21 Nov, 2015
1 commit
-
The function omap_iommu_dra7_emu_swsup_config() implements the
workaround for DRA7 DSP MStandby errata i879, and uses a mutex for
providing mutual exclusion between the two DSP subsystems on DRA7
disabling the HW_AUTO mode on the EMU clock domain. This function
is called in an atomic context though (spinlocks are acquired in
omap_iommu_attach_dev()), and reports the following BUG:remoteproc3: powering up 41000000.dsp
remoteproc3: Booting fw image dra7-dsp2-fw.xe66, size 6631556
BUG: sleeping function called from invalid context at kernel/locking/mutex.c:616
in_atomic(): 1, irqs_disabled(): 0, pid: 923, name: kworker/1:2
6 locks held by kworker/1:2/923:
#0: ("events"){.+.+.+}, at: [] process_one_work+0x124/0x8d4
#1: ((&fw_work->work)){+.+.+.}, at: [] process_one_work+0x124/0x8d4
#2: (&dev->mutex){......}, at: [] device_attach+0x18/0x8c
#3: (&rproc->lock){+.+.+.}, at: [] rproc_boot+0x24/0x564
#4: (&(&omap_domain->lock)->rlock){+.+...}, at: [] omap_iommu_attach_dev+0x38/0x434
#5: (&(&obj->iommu_lock)->rlock){+.+...}, at: [] omap_iommu_attach_dev+0x170/0x434
Preemption disabled at:[< (null)>] (null)CPU: 1 PID: 923 Comm: kworker/1:2 Not tainted 4.1.13-01787-gaa3bf4ce5e05 #4
Hardware name: Generic DRA74X (Flattened Device Tree)
Workqueue: events request_firmware_work_func
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0x80/0xc8)
[] (dump_stack) from [] (mutex_lock_nested+0x24/0x48c)
[] (mutex_lock_nested) from [] (omap_iommu_dra7_emu_swsup_config+0x38/0x11c)
[] (omap_iommu_dra7_emu_swsup_config) from [] (omap_iommu_set_pwrdm_constraint+0x80/0xc0)
[] (omap_iommu_set_pwrdm_constraint) from [] (omap_iommu_attach_dev+0x1a4/0x434)
[] (omap_iommu_attach_dev) from [] (iommu_attach_device+0x1c/0x28c)
[] (iommu_attach_device) from [] (rproc_boot+0x2a8/0x564)
[] (rproc_boot) from [] (rproc_virtio_find_vqs+0x1bc/0x220)
[] (rproc_virtio_find_vqs) from [] (rpmsg_probe+0xa4/0x400 [virtio_rpmsg_bus])
[] (rpmsg_probe [virtio_rpmsg_bus]) from [] (virtio_dev_probe+0x1e8/0x2d0)
[] (virtio_dev_probe) from [] (driver_probe_device+0x1f0/0x42c)
[] (driver_probe_device) from [] (bus_for_each_drv+0x64/0x98)
[] (bus_for_each_drv) from [] (device_attach+0x74/0x8c)
[] (device_attach) from [] (bus_probe_device+0x88/0xb0)
[] (bus_probe_device) from [] (device_add+0x3e0/0x5a8)
[] (device_add) from [] (register_virtio_device+0xa8/0xf8)
[] (register_virtio_device) from [] (rproc_add_virtio_dev+0x3c/0x98)
[] (rproc_add_virtio_dev) from [] (rproc_handle_vdev+0x294/0x384)
[] (rproc_handle_vdev) from [] (rproc_handle_resources+0x90/0x1b8)
[] (rproc_handle_resources) from [] (rproc_fw_config_virtio+0xe8/0xf4)
[] (rproc_fw_config_virtio) from [] (request_firmware_work_func+0x30/0x50)
[] (request_firmware_work_func) from [] (process_one_work+0x204/0x8d4)
[] (process_one_work) from [] (worker_thread+0x34/0x4d8)
[] (worker_thread) from [] (kthread+0xe0/0x100)
[] (kthread) from [] (ret_from_fork+0x14/0x3c)Fix this invalid sleeping function invocation in atomic context BUG
by converting the mutex into a spinlock.Reported-by: Carlos Hernandez
Fixes: ffd06e9cec49 ("ARM: OMAP2+: Add workaround for DRA7 DSP MStandby errata i879")
Signed-off-by: Suman Anna
20 Nov, 2015
7 commits
-
Tweak the UART pinmux comment spacing to match the other peripherals that
are being pinmuxed.Signed-off-by: Franklin S Cooper Jr
Acked-by: Sekhar Nori -
The K2G evm has a 258 MB Micron NAND (MT29F2G16ABAFAWP). Add support for
this NAND by enabling the GPMC and ELM peripheral along with the appropriate
NAND node settings.Signed-off-by: Roger Quadros
Signed-off-by: Murali Karicheri
[fcooper@ti.com: Add pinmuxing and update node to match latest bindings]
Signed-off-by: Franklin S Cooper Jr
Acked-by: Sekhar Nori -
Enable both DCAN0 and DCAN 1 which are accessible via the D SUB 9
connectors on the evm.Signed-off-by: Franklin S Cooper Jr
Acked-by: Sekhar Nori -
Enable USB0 which is used as a USB host port.
Signed-off-by: Roger Quadros
Signed-off-by: Murali Karicheri
[fcooper@ti.com: Remove usb1 entry]
Signed-off-by: Franklin S Cooper Jr
Acked-by: Sekhar Nori -
K2G EVM uses N25Q128A13 SPI NOR flash on SPI-1. This patch add DT bindings
to support this.Signed-off-by: Murali Karicheri
[lokeshvutla@ti.com: Add pinmuxing]
Signed-off-by: Lokesh Vutla
[fcooper@ti.com: Add buffer class and pullup and pulldown pinmux settings]
Signed-off-by: Franklin S Cooper Jr
Acked-by: Sekhar Nori -
Enable MMC0 which is used for micro SD and MMC1 which is used for the on
board EMMC.Signed-off-by: Lokesh Vutla
[fcooper@ti.com: add mmc1, bufferclass and pullup/pulldown settings]
Signed-off-by: Franklin S Cooper Jr
Acked-by: Sekhar Nori -
Add support for Atmel's 24C1024 which is a I2C based EEPROM connected
to I2C0.Signed-off-by: Murali Karicheri
[lokeshvutla@ti.com: add I2C0 pinmuxing]
Signed-off-by: Lokesh Vutla
[fcooper@ti.com Add buffer class and pullup/pulldown settings]
Signed-off-by: Franklin S Cooper Jr
Acked-by: Sekhar Nori
