8 years agoMerge branch 'rpmsg-linux-3.14.y' of git://git.ti.com/rpmsg/rpmsg into rpmsg-ti-linux... rpmsg-ti-linux-3.14.y
Merge branch 'rpmsg-linux-3.14.y' of git://git.ti.com/rpmsg/rpmsg into rpmsg-ti-linux-3.14.y
Pull in the updated rpmsg base feature branch that includes
various miscellaneous fixes:
- fix autoloading of rpmsg-proto driver
- a mutex lockdep warning fix in virtio rpmsg core
- a minor return value fix in rpmsg rpc driver
- build warnings with ARM_LPAE enabled
* 'rpmsg-linux-3.14.y' of git://git.ti.com/rpmsg/rpmsg:
net/rpmsg: fix a use after free error
net/rpmsg: fix autoloading of rpmsg-proto driver
rpmsg: fix a lockdep warning in virtio rpmsg driver
rpmsg: rpc: fix return values in rppc_local_to_remote_da
rpmsg: use proper format-specifier for printing dma_addr_t
rpmsg: rpc: fix the definition of virt_addr_t
rpmsg: rpc: define and use a device address type
rpmsg: rpc: use %pa for printing phys_addr_t
Signed-off-by: Suman Anna <s-anna@ti.com>
Pull in the updated rpmsg base feature branch that includes
various miscellaneous fixes:
- fix autoloading of rpmsg-proto driver
- a mutex lockdep warning fix in virtio rpmsg core
- a minor return value fix in rpmsg rpc driver
- build warnings with ARM_LPAE enabled
* 'rpmsg-linux-3.14.y' of git://git.ti.com/rpmsg/rpmsg:
net/rpmsg: fix a use after free error
net/rpmsg: fix autoloading of rpmsg-proto driver
rpmsg: fix a lockdep warning in virtio rpmsg driver
rpmsg: rpc: fix return values in rppc_local_to_remote_da
rpmsg: use proper format-specifier for printing dma_addr_t
rpmsg: rpc: fix the definition of virt_addr_t
rpmsg: rpc: define and use a device address type
rpmsg: rpc: use %pa for printing phys_addr_t
Signed-off-by: Suman Anna <s-anna@ti.com>
net/rpmsg: fix a use after free error
The rpmsg_proto probe function assigns a freed sock_list
pointer variable after it has been freed when the radix
tree insertion fails. Fix this by properly bailing out
on an error. Defect is discovered using the Coverity code
coverage tool.
Note that the patch is not fixing any real issue as the
driver core will unwind whatever is done on the device,
and the rpmsg-proto driver will never use this rpmsg
device or dereference the assigned pointer.
Signed-off-by: Karthik Ramanan <a0393906@ti.com>
[s-anna@ti.com: revise commit description]
Signed-off-by: Suman Anna <s-anna@ti.com>
The rpmsg_proto probe function assigns a freed sock_list
pointer variable after it has been freed when the radix
tree insertion fails. Fix this by properly bailing out
on an error. Defect is discovered using the Coverity code
coverage tool.
Note that the patch is not fixing any real issue as the
driver core will unwind whatever is done on the device,
and the rpmsg-proto driver will never use this rpmsg
device or dereference the assigned pointer.
Signed-off-by: Karthik Ramanan <a0393906@ti.com>
[s-anna@ti.com: revise commit description]
Signed-off-by: Suman Anna <s-anna@ti.com>
net/rpmsg: fix autoloading of rpmsg-proto driver
The rpmsg-proto is a rpmsg bus driver that provides support
for a new remote-processor socket protocol, and exposes a
rpmsg communication channel to userspace through the socket
API. It resides in the networking layer, but is not a true
networking driver.
The driver is not probed based on devices from DT, but rather
the devices are published to the kernel when a firmware is
loaded by a remoteproc driver. The existing MODULE_ALIAS_NETPROTO
doesn't trigger an autoload of the driver by udev. So, add a
rpmsg-specific MODULE_ALIAS that fixes the autoloading of the
rpmsg-proto driver.
Signed-off-by: Suman Anna <s-anna@ti.com>
The rpmsg-proto is a rpmsg bus driver that provides support
for a new remote-processor socket protocol, and exposes a
rpmsg communication channel to userspace through the socket
API. It resides in the networking layer, but is not a true
networking driver.
The driver is not probed based on devices from DT, but rather
the devices are published to the kernel when a firmware is
loaded by a remoteproc driver. The existing MODULE_ALIAS_NETPROTO
doesn't trigger an autoload of the driver by udev. So, add a
rpmsg-specific MODULE_ALIAS that fixes the autoloading of the
rpmsg-proto driver.
Signed-off-by: Suman Anna <s-anna@ti.com>
rpmsg: fix a lockdep warning in virtio rpmsg driver
When a remote processor sends a RPMSG_NS_DESTROY message to the HOST,
the name service endpoint callback will run, holding ept->cb_lock for
the name service endpoint. The callback will destroy the requested
channel, which will ultimately result in all the rpmsg client channel
device endpoints also to be destroyed. During destruction of the
channel's endpoint, ept->cb_lock for the channel's endpoint is locked.
In this scenario, the ept->cb_lock is used in a nested fashion even
though the locking is on different mutexes. This will result in a
false warning from the lockdep validator when it is enabled because
the lockdep deals with classes and both are of the same class, although
they are different instances.
This issue is fixed by replacing the existing mutex_lock() calls with
the mutex_lock_nested() API variation and using different subclasses
for the NameService end-point and for the rpmsg channel device
end-points. Following is the signature of the warning:
virtio_rpmsg_bus virtio2: destroying channel rpmsg-proto addr 0x33
=============================================
[ INFO: possible recursive locking detected ]
3.14.51-00688-gea6ac1b #1 Tainted: G W
---------------------------------------------
kworker/0:2/960 is trying to acquire lock:
(&ept->cb_lock){+.+.+.}, at: [<c05f4e80>] __rpmsg_destroy_ept+0x48/0x8c
but task is already holding lock:
(&ept->cb_lock){+.+.+.}, at: [<c05f486c>] rpmsg_recv_done+0xe4/0x258
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&ept->cb_lock);
lock(&ept->cb_lock);
*** DEADLOCK ***
May be due to missing lock nesting notation
4 locks held by kworker/0:2/960:
#0: ("events"){.+.+.+}, at: [<c00528b4>] process_one_work+0x12c/0x44c
#1: ((&mq->work)){+.+.+.}, at: [<c00528b4>] process_one_work+0x12c/0x44c
#2: (&ept->cb_lock){+.+.+.}, at: [<c05f486c>] rpmsg_recv_done+0xe4/0x258
#3: (&__lockdep_no_validate__){......}, at: [<c040d494>] device_release_driver+0x20/0x34
stack backtrace:
CPU: 0 PID: 960 Comm: kworker/0:2 Tainted: G W 3.14.51-00688-gea6ac1b #1
Workqueue: events mbox_rx_work
Backtrace:
[<c00126a4>] (dump_backtrace) from [<c00128bc>] (show_stack+0x18/0x1c)
[<c00128a4>] (show_stack) from [<c07b8a98>] (dump_stack+0x84/0xc4)
[<c07b8a14>] (dump_stack) from [<c007df84>] (__lock_acquire+0x1c08/0x1d7c)
[<c007c37c>] (__lock_acquire) from [<c007e8f4>] (lock_acquire+0x70/0x84)
[<c007e884>] (lock_acquire) from [<c07bbc50>] (mutex_lock_nested+0x6c/0x478)
[<c07bbbe4>] (mutex_lock_nested) from [<c05f4e80>] (__rpmsg_destroy_ept+0x48/0x8c)
[<c05f4e38>] (__rpmsg_destroy_ept) from [<c05f4f30>] (rpmsg_dev_remove+0x4c/0xd4)
[<c05f4ee4>] (rpmsg_dev_remove) from [<c040d418>] (__device_release_driver+0x78/0xd4)
[<c040d3a0>] (__device_release_driver) from [<c040d49c>] (device_release_driver+0x28/0x34)
[<c040d474>] (device_release_driver) from [<c040ce4c>] (bus_remove_device+0xe8/0x114)
[<c040cd64>] (bus_remove_device) from [<c040a1c8>] (device_del+0x10c/0x1a0)
[<c040a0bc>] (device_del) from [<c040a270>] (device_unregister+0x14/0x28)
[<c040a25c>] (device_unregister) from [<c05f473c>] (rpmsg_ns_cb+0xfc/0x148)
[<c05f4640>] (rpmsg_ns_cb) from [<c05f4894>] (rpmsg_recv_done+0x10c/0x258)
[<c05f4788>] (rpmsg_recv_done) from [<c039ca58>] (vring_interrupt+0x40/0x58)
[<c039ca18>] (vring_interrupt) from [<c05f2024>] (rproc_vq_interrupt+0x4c/0x74)
[<c05f1fd8>] (rproc_vq_interrupt) from [<c05f3634>] (omap_rproc_mbox_callback+0xcc/0xe4)
[<c05f3568>] (omap_rproc_mbox_callback) from [<c05e7e7c>] (mbox_chan_received_data+0x20/0x24)
[<c05e7e5c>] (mbox_chan_received_data) from [<c05e8e30>] (mbox_rx_work+0x5c/0xdc)
[<c05e8dd4>] (mbox_rx_work) from [<c0052930>] (process_one_work+0x1a8/0x44c)
[<c0052788>] (process_one_work) from [<c00537e0>] (worker_thread+0x140/0x3f8)
[<c00536a0>] (worker_thread) from [<c0059b5c>] (kthread+0xe4/0xf8)
[<c0059a78>] (kthread) from [<c000e9f0>] (ret_from_fork+0x14/0x24)
Signed-off-by: Angela Stegmaier <angelabaker@ti.com>
[s-anna@ti.com: flip the subclass values and other minor mods]
Signed-off-by: Suman Anna <s-anna@ti.com>
When a remote processor sends a RPMSG_NS_DESTROY message to the HOST,
the name service endpoint callback will run, holding ept->cb_lock for
the name service endpoint. The callback will destroy the requested
channel, which will ultimately result in all the rpmsg client channel
device endpoints also to be destroyed. During destruction of the
channel's endpoint, ept->cb_lock for the channel's endpoint is locked.
In this scenario, the ept->cb_lock is used in a nested fashion even
though the locking is on different mutexes. This will result in a
false warning from the lockdep validator when it is enabled because
the lockdep deals with classes and both are of the same class, although
they are different instances.
This issue is fixed by replacing the existing mutex_lock() calls with
the mutex_lock_nested() API variation and using different subclasses
for the NameService end-point and for the rpmsg channel device
end-points. Following is the signature of the warning:
virtio_rpmsg_bus virtio2: destroying channel rpmsg-proto addr 0x33
=============================================
[ INFO: possible recursive locking detected ]
3.14.51-00688-gea6ac1b #1 Tainted: G W
---------------------------------------------
kworker/0:2/960 is trying to acquire lock:
(&ept->cb_lock){+.+.+.}, at: [<c05f4e80>] __rpmsg_destroy_ept+0x48/0x8c
but task is already holding lock:
(&ept->cb_lock){+.+.+.}, at: [<c05f486c>] rpmsg_recv_done+0xe4/0x258
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&ept->cb_lock);
lock(&ept->cb_lock);
*** DEADLOCK ***
May be due to missing lock nesting notation
4 locks held by kworker/0:2/960:
#0: ("events"){.+.+.+}, at: [<c00528b4>] process_one_work+0x12c/0x44c
#1: ((&mq->work)){+.+.+.}, at: [<c00528b4>] process_one_work+0x12c/0x44c
#2: (&ept->cb_lock){+.+.+.}, at: [<c05f486c>] rpmsg_recv_done+0xe4/0x258
#3: (&__lockdep_no_validate__){......}, at: [<c040d494>] device_release_driver+0x20/0x34
stack backtrace:
CPU: 0 PID: 960 Comm: kworker/0:2 Tainted: G W 3.14.51-00688-gea6ac1b #1
Workqueue: events mbox_rx_work
Backtrace:
[<c00126a4>] (dump_backtrace) from [<c00128bc>] (show_stack+0x18/0x1c)
[<c00128a4>] (show_stack) from [<c07b8a98>] (dump_stack+0x84/0xc4)
[<c07b8a14>] (dump_stack) from [<c007df84>] (__lock_acquire+0x1c08/0x1d7c)
[<c007c37c>] (__lock_acquire) from [<c007e8f4>] (lock_acquire+0x70/0x84)
[<c007e884>] (lock_acquire) from [<c07bbc50>] (mutex_lock_nested+0x6c/0x478)
[<c07bbbe4>] (mutex_lock_nested) from [<c05f4e80>] (__rpmsg_destroy_ept+0x48/0x8c)
[<c05f4e38>] (__rpmsg_destroy_ept) from [<c05f4f30>] (rpmsg_dev_remove+0x4c/0xd4)
[<c05f4ee4>] (rpmsg_dev_remove) from [<c040d418>] (__device_release_driver+0x78/0xd4)
[<c040d3a0>] (__device_release_driver) from [<c040d49c>] (device_release_driver+0x28/0x34)
[<c040d474>] (device_release_driver) from [<c040ce4c>] (bus_remove_device+0xe8/0x114)
[<c040cd64>] (bus_remove_device) from [<c040a1c8>] (device_del+0x10c/0x1a0)
[<c040a0bc>] (device_del) from [<c040a270>] (device_unregister+0x14/0x28)
[<c040a25c>] (device_unregister) from [<c05f473c>] (rpmsg_ns_cb+0xfc/0x148)
[<c05f4640>] (rpmsg_ns_cb) from [<c05f4894>] (rpmsg_recv_done+0x10c/0x258)
[<c05f4788>] (rpmsg_recv_done) from [<c039ca58>] (vring_interrupt+0x40/0x58)
[<c039ca18>] (vring_interrupt) from [<c05f2024>] (rproc_vq_interrupt+0x4c/0x74)
[<c05f1fd8>] (rproc_vq_interrupt) from [<c05f3634>] (omap_rproc_mbox_callback+0xcc/0xe4)
[<c05f3568>] (omap_rproc_mbox_callback) from [<c05e7e7c>] (mbox_chan_received_data+0x20/0x24)
[<c05e7e5c>] (mbox_chan_received_data) from [<c05e8e30>] (mbox_rx_work+0x5c/0xdc)
[<c05e8dd4>] (mbox_rx_work) from [<c0052930>] (process_one_work+0x1a8/0x44c)
[<c0052788>] (process_one_work) from [<c00537e0>] (worker_thread+0x140/0x3f8)
[<c00536a0>] (worker_thread) from [<c0059b5c>] (kthread+0xe4/0xf8)
[<c0059a78>] (kthread) from [<c000e9f0>] (ret_from_fork+0x14/0x24)
Signed-off-by: Angela Stegmaier <angelabaker@ti.com>
[s-anna@ti.com: flip the subclass values and other minor mods]
Signed-off-by: Suman Anna <s-anna@ti.com>
rpmsg: rpc: fix return values in rppc_local_to_remote_da
The function rppc_local_to_remote_da() is used for translating
kernel local buffer addresses to remote processor device addresses,
and is expected to return a value of 0 on errors. This translation
is done using the rproc_da_to_va() exported function from the
remoteproc core, with a rproc handle looked up using the current
rpc instance. However, it is returning an uninitialized value at
present when the rproc handle lookup fails, or -EINTR if the mutex
locking is interrupted. This results in a kernel crash further
along due to operation on an invalid buffer address value.
Fix this by returning a value of 0 on all possible error paths.
Also, updated the comments with details about the return values.
Reported-by: Buddy Liong <a0270631@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
The function rppc_local_to_remote_da() is used for translating
kernel local buffer addresses to remote processor device addresses,
and is expected to return a value of 0 on errors. This translation
is done using the rproc_da_to_va() exported function from the
remoteproc core, with a rproc handle looked up using the current
rpc instance. However, it is returning an uninitialized value at
present when the rproc handle lookup fails, or -EINTR if the mutex
locking is interrupted. This results in a kernel crash further
along due to operation on an invalid buffer address value.
Fix this by returning a value of 0 on all possible error paths.
Also, updated the comments with details about the return values.
Reported-by: Buddy Liong <a0270631@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-3.14.y
Pull in the updated remoteproc feature branch that includes the
minor fixes in OMAP IOMMU driver and PRUSS remoteproc driver.
* 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc:
remoteproc/pruss: fix couple of NULL pointer dereferences
remoteproc/pruss: use %pa for printing phys_addr_t
remoteproc/pruss: remove dead rproc_put() in pruss probe
ARM: OMAP2+: iommu: fix sleeping lock usage in atomic context bug
iommu/omap: Print phys_addr_t using %pa
Signed-off-by: Suman Anna <s-anna@ti.com>
Pull in the updated remoteproc feature branch that includes the
minor fixes in OMAP IOMMU driver and PRUSS remoteproc driver.
* 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc:
remoteproc/pruss: fix couple of NULL pointer dereferences
remoteproc/pruss: use %pa for printing phys_addr_t
remoteproc/pruss: remove dead rproc_put() in pruss probe
ARM: OMAP2+: iommu: fix sleeping lock usage in atomic context bug
iommu/omap: Print phys_addr_t using %pa
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc/pruss: fix couple of NULL pointer dereferences
The platform_get_resource_byname() function returns a NULL
pointer on failure (device does not have the corresponding
resource). The devm_ioremap_resource() function can handle
this NULL resource NULL pointer, and will fail in turn, but
any direct dereferences of the resource structure results in
a NULL pointer dereference error. Fix these by checking first
for the ERR_PTR()s returned by devm_ioremap_resource() for
a NULL resource pointer.
Signed-off-by: Felipe Balbi <balbi@ti.com>
[afd@ti.com: add fix in pru_rproc_probe as well]
Signed-off-by: Andrew F. Davis <afd@ti.com>
[s-anna@ti.com: revise commit description]
Signed-off-by: Suman Anna <s-anna@ti.com>
The platform_get_resource_byname() function returns a NULL
pointer on failure (device does not have the corresponding
resource). The devm_ioremap_resource() function can handle
this NULL resource NULL pointer, and will fail in turn, but
any direct dereferences of the resource structure results in
a NULL pointer dereference error. Fix these by checking first
for the ERR_PTR()s returned by devm_ioremap_resource() for
a NULL resource pointer.
Signed-off-by: Felipe Balbi <balbi@ti.com>
[afd@ti.com: add fix in pru_rproc_probe as well]
Signed-off-by: Andrew F. Davis <afd@ti.com>
[s-anna@ti.com: revise commit description]
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc/pruss: use %pa for printing phys_addr_t
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 <lokeshvutla@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
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 <lokeshvutla@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc/pruss: remove dead rproc_put() in pruss probe
The PRUSS platform driver doesn't have anything to do with the
management of a rproc device, that is the responsibility of the
PRU remoteproc platform driver. However, the pruss probe code has
a stale dead code fragment of rproc_put(). This should have never
been present to begin with, so clean it up.
Signed-off-by: Suman Anna <s-anna@ti.com>
The PRUSS platform driver doesn't have anything to do with the
management of a rproc device, that is the responsibility of the
PRU remoteproc platform driver. However, the pruss probe code has
a stale dead code fragment of rproc_put(). This should have never
been present to begin with, so clean it up.
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'iommu-linux-3.14.y' of git://git.ti.com/rpmsg/iommu into rproc-linux-3.14.y
Merge in the updated iommu feature branch into remoteproc tree
to fix couple of issues in the OMAP IOMMU driver, one an invalid
mutex usage in an atomic context, and another a minor compile
warning when kernel is compiled with CONFIG_ARM_LPAE enabled.
* 'iommu-linux-3.14.y' of git://git.ti.com/rpmsg/iommu:
ARM: OMAP2+: iommu: fix sleeping lock usage in atomic context bug
iommu/omap: Print phys_addr_t using %pa
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge in the updated iommu feature branch into remoteproc tree
to fix couple of issues in the OMAP IOMMU driver, one an invalid
mutex usage in an atomic context, and another a minor compile
warning when kernel is compiled with CONFIG_ARM_LPAE enabled.
* 'iommu-linux-3.14.y' of git://git.ti.com/rpmsg/iommu:
ARM: OMAP2+: iommu: fix sleeping lock usage in atomic context bug
iommu/omap: Print phys_addr_t using %pa
Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: OMAP2+: iommu: fix sleeping lock usage in atomic context bug
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: [<c0062088>] process_one_work+0x124/0x8d4
#1: ((&fw_work->work)){+.+.+.}, at: [<c0062088>] process_one_work+0x124/0x8d4
#2: (&dev->mutex){......}, at: [<c04d6644>] device_attach+0x18/0x8c
#3: (&rproc->lock){+.+.+.}, at: [<c05e5ad8>] rproc_boot+0x24/0x564
#4: (&(&omap_domain->lock)->rlock){+.+...}, at: [<c0491d54>] omap_iommu_attach_dev+0x38/0x434
#5: (&(&obj->iommu_lock)->rlock){+.+...}, at: [<c0491e8c>] 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
[<c0018e78>] (unwind_backtrace) from [<c00141e0>] (show_stack+0x10/0x14)
[<c00141e0>] (show_stack) from [<c0737c80>] (dump_stack+0x80/0xc8)
[<c0737c80>] (dump_stack) from [<c073bc88>] (mutex_lock_nested+0x24/0x48c)
[<c073bc88>] (mutex_lock_nested) from [<c003ebf8>] (omap_iommu_dra7_emu_swsup_config+0x38/0x11c)
[<c003ebf8>] (omap_iommu_dra7_emu_swsup_config) from [<c003ed5c>] (omap_iommu_set_pwrdm_constraint+0x80/0xc0)
[<c003ed5c>] (omap_iommu_set_pwrdm_constraint) from [<c0491ec0>] (omap_iommu_attach_dev+0x1a4/0x434)
[<c0491ec0>] (omap_iommu_attach_dev) from [<c048da08>] (iommu_attach_device+0x1c/0x28c)
[<c048da08>] (iommu_attach_device) from [<c05e5d5c>] (rproc_boot+0x2a8/0x564)
[<c05e5d5c>] (rproc_boot) from [<c05e733c>] (rproc_virtio_find_vqs+0x1bc/0x220)
[<c05e733c>] (rproc_virtio_find_vqs) from [<bf0013dc>] (rpmsg_probe+0xa4/0x400 [virtio_rpmsg_bus])
[<bf0013dc>] (rpmsg_probe [virtio_rpmsg_bus]) from [<c044fbf4>] (virtio_dev_probe+0x1e8/0x2d0)
[<c044fbf4>] (virtio_dev_probe) from [<c04d68f8>] (driver_probe_device+0x1f0/0x42c)
[<c04d68f8>] (driver_probe_device) from [<c04d4bd4>] (bus_for_each_drv+0x64/0x98)
[<c04d4bd4>] (bus_for_each_drv) from [<c04d66a0>] (device_attach+0x74/0x8c)
[<c04d66a0>] (device_attach) from [<c04d5be0>] (bus_probe_device+0x88/0xb0)
[<c04d5be0>] (bus_probe_device) from [<c04d3db4>] (device_add+0x3e0/0x5a8)
[<c04d3db4>] (device_add) from [<c044f824>] (register_virtio_device+0xa8/0xf8)
[<c044f824>] (register_virtio_device) from [<c05e75b0>] (rproc_add_virtio_dev+0x3c/0x98)
[<c05e75b0>] (rproc_add_virtio_dev) from [<c05e4630>] (rproc_handle_vdev+0x294/0x384)
[<c05e4630>] (rproc_handle_vdev) from [<c05e47b0>] (rproc_handle_resources+0x90/0x1b8)
[<c05e47b0>] (rproc_handle_resources) from [<c05e49c0>] (rproc_fw_config_virtio+0xe8/0xf4)
[<c05e49c0>] (rproc_fw_config_virtio) from [<c04ed56c>] (request_firmware_work_func+0x30/0x50)
[<c04ed56c>] (request_firmware_work_func) from [<c0062168>] (process_one_work+0x204/0x8d4)
[<c0062168>] (process_one_work) from [<c006286c>] (worker_thread+0x34/0x4d8)
[<c006286c>] (worker_thread) from [<c00687dc>] (kthread+0xe0/0x100)
[<c00687dc>] (kthread) from [<c0010378>] (ret_from_fork+0x14/0x3c)
Fix this invalid sleeping function invocation in atomic context BUG
by converting the mutex into a spinlock.
Fixes: a2062f5aa3ca ("ARM: OMAP2+: Add workaround for DRA7 DSP MStandby errata i879")
Signed-off-by: Suman Anna <s-anna@ti.com>
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: [<c0062088>] process_one_work+0x124/0x8d4
#1: ((&fw_work->work)){+.+.+.}, at: [<c0062088>] process_one_work+0x124/0x8d4
#2: (&dev->mutex){......}, at: [<c04d6644>] device_attach+0x18/0x8c
#3: (&rproc->lock){+.+.+.}, at: [<c05e5ad8>] rproc_boot+0x24/0x564
#4: (&(&omap_domain->lock)->rlock){+.+...}, at: [<c0491d54>] omap_iommu_attach_dev+0x38/0x434
#5: (&(&obj->iommu_lock)->rlock){+.+...}, at: [<c0491e8c>] 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
[<c0018e78>] (unwind_backtrace) from [<c00141e0>] (show_stack+0x10/0x14)
[<c00141e0>] (show_stack) from [<c0737c80>] (dump_stack+0x80/0xc8)
[<c0737c80>] (dump_stack) from [<c073bc88>] (mutex_lock_nested+0x24/0x48c)
[<c073bc88>] (mutex_lock_nested) from [<c003ebf8>] (omap_iommu_dra7_emu_swsup_config+0x38/0x11c)
[<c003ebf8>] (omap_iommu_dra7_emu_swsup_config) from [<c003ed5c>] (omap_iommu_set_pwrdm_constraint+0x80/0xc0)
[<c003ed5c>] (omap_iommu_set_pwrdm_constraint) from [<c0491ec0>] (omap_iommu_attach_dev+0x1a4/0x434)
[<c0491ec0>] (omap_iommu_attach_dev) from [<c048da08>] (iommu_attach_device+0x1c/0x28c)
[<c048da08>] (iommu_attach_device) from [<c05e5d5c>] (rproc_boot+0x2a8/0x564)
[<c05e5d5c>] (rproc_boot) from [<c05e733c>] (rproc_virtio_find_vqs+0x1bc/0x220)
[<c05e733c>] (rproc_virtio_find_vqs) from [<bf0013dc>] (rpmsg_probe+0xa4/0x400 [virtio_rpmsg_bus])
[<bf0013dc>] (rpmsg_probe [virtio_rpmsg_bus]) from [<c044fbf4>] (virtio_dev_probe+0x1e8/0x2d0)
[<c044fbf4>] (virtio_dev_probe) from [<c04d68f8>] (driver_probe_device+0x1f0/0x42c)
[<c04d68f8>] (driver_probe_device) from [<c04d4bd4>] (bus_for_each_drv+0x64/0x98)
[<c04d4bd4>] (bus_for_each_drv) from [<c04d66a0>] (device_attach+0x74/0x8c)
[<c04d66a0>] (device_attach) from [<c04d5be0>] (bus_probe_device+0x88/0xb0)
[<c04d5be0>] (bus_probe_device) from [<c04d3db4>] (device_add+0x3e0/0x5a8)
[<c04d3db4>] (device_add) from [<c044f824>] (register_virtio_device+0xa8/0xf8)
[<c044f824>] (register_virtio_device) from [<c05e75b0>] (rproc_add_virtio_dev+0x3c/0x98)
[<c05e75b0>] (rproc_add_virtio_dev) from [<c05e4630>] (rproc_handle_vdev+0x294/0x384)
[<c05e4630>] (rproc_handle_vdev) from [<c05e47b0>] (rproc_handle_resources+0x90/0x1b8)
[<c05e47b0>] (rproc_handle_resources) from [<c05e49c0>] (rproc_fw_config_virtio+0xe8/0xf4)
[<c05e49c0>] (rproc_fw_config_virtio) from [<c04ed56c>] (request_firmware_work_func+0x30/0x50)
[<c04ed56c>] (request_firmware_work_func) from [<c0062168>] (process_one_work+0x204/0x8d4)
[<c0062168>] (process_one_work) from [<c006286c>] (worker_thread+0x34/0x4d8)
[<c006286c>] (worker_thread) from [<c00687dc>] (kthread+0xe0/0x100)
[<c00687dc>] (kthread) from [<c0010378>] (ret_from_fork+0x14/0x3c)
Fix this invalid sleeping function invocation in atomic context BUG
by converting the mutex into a spinlock.
Fixes: a2062f5aa3ca ("ARM: OMAP2+: Add workaround for DRA7 DSP MStandby errata i879")
Signed-off-by: Suman Anna <s-anna@ti.com>
iommu/omap: Print phys_addr_t using %pa
Fixes this compile warning:
drivers/iommu/omap-iommu.c: In function 'omap_iommu_map':
drivers/iommu/omap-iommu.c:1139:2: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'phys_addr_t' [-Wformat=]
dev_dbg(dev, "mapping da 0x%lx to pa 0x%x size 0x%x\n", da, pa, bytes);
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
[s-anna@ti.com: cherry-pick commit '1d7f449' from v4.0]
Signed-off-by: Suman Anna <s-anna@ti.com>
Fixes this compile warning:
drivers/iommu/omap-iommu.c: In function 'omap_iommu_map':
drivers/iommu/omap-iommu.c:1139:2: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'phys_addr_t' [-Wformat=]
dev_dbg(dev, "mapping da 0x%lx to pa 0x%x size 0x%x\n", da, pa, bytes);
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
[s-anna@ti.com: cherry-pick commit '1d7f449' from v4.0]
Signed-off-by: Suman Anna <s-anna@ti.com>
rpmsg: use proper format-specifier for printing dma_addr_t
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 <lokeshvutla@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
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 <lokeshvutla@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
rpmsg: rpc: fix the definition of virt_addr_t
The current rpmsg_rpc code uses the type virt_addr_t for variables
storing the MPU virtual addresses of buffers (either kernel-mapped
addresses or userspace buffer addresses). This type is conditionally
defined to be 64-bit relying on the macro CONFIG_PHYS_ADDR_T_64BIT.
Even though the physical memory available is addressed using 64 bit,
it is not necessary that 64 bit virtual addresses are being generated.
A 32-bit processor always generates a 32 bit virtual address, and
therefore this definition is wrong. Fix it by making it always a u32,
as we currently support only 32-bit virtual addresses.
This fixes a bunch of build warnings [1] of the type "cast to pointer
from integer of different size [-Wint-to-pointer-cast]" and "cast from
pointer to integer of different size [-Wpointer-to-int-cast]" when
CONFIG_ARM_LPAE is enabled.
[1] http://pastebin.ubuntu.com/13494230/
Fixes: 63fc17851142 ("rpmsg: rpc: introduce a new rpmsg_rpc driver")
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
[s-anna@ti.com: revise commit description slightly]
Signed-off-by: Suman Anna <s-anna@ti.com>
The current rpmsg_rpc code uses the type virt_addr_t for variables
storing the MPU virtual addresses of buffers (either kernel-mapped
addresses or userspace buffer addresses). This type is conditionally
defined to be 64-bit relying on the macro CONFIG_PHYS_ADDR_T_64BIT.
Even though the physical memory available is addressed using 64 bit,
it is not necessary that 64 bit virtual addresses are being generated.
A 32-bit processor always generates a 32 bit virtual address, and
therefore this definition is wrong. Fix it by making it always a u32,
as we currently support only 32-bit virtual addresses.
This fixes a bunch of build warnings [1] of the type "cast to pointer
from integer of different size [-Wint-to-pointer-cast]" and "cast from
pointer to integer of different size [-Wpointer-to-int-cast]" when
CONFIG_ARM_LPAE is enabled.
[1] http://pastebin.ubuntu.com/13494230/
Fixes: 63fc17851142 ("rpmsg: rpc: introduce a new rpmsg_rpc driver")
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
[s-anna@ti.com: revise commit description slightly]
Signed-off-by: Suman Anna <s-anna@ti.com>
rpmsg: rpc: define and use a device address type
The current rpmsg_rpc code uses a phys_addr_t type for variables
storing the remote processor device addresses. The phys_addr_t
type can either be a 32-bit or a 64-bit integer type (based on
CONFIG_PHYS_ADDR_T_64BIT). Define a new address type, dev_addr_t,
and use this for remote processor addresses instead of phys_addr_t,
so as to not to confuse with either the actual physical addresses
or the MPU virtual addresses. The new type is defined to be a 32-bit
integer type as all the existing OMAP remote processors use 32-bit
addresses only.
This fixes couple of build warnings of the type "cast to pointer from
integer of different size" when CONFIG_ARM_LPAE is enabled.
Signed-off-by: Suman Anna <s-anna@ti.com>
The current rpmsg_rpc code uses a phys_addr_t type for variables
storing the remote processor device addresses. The phys_addr_t
type can either be a 32-bit or a 64-bit integer type (based on
CONFIG_PHYS_ADDR_T_64BIT). Define a new address type, dev_addr_t,
and use this for remote processor addresses instead of phys_addr_t,
so as to not to confuse with either the actual physical addresses
or the MPU virtual addresses. The new type is defined to be a 32-bit
integer type as all the existing OMAP remote processors use 32-bit
addresses only.
This fixes couple of build warnings of the type "cast to pointer from
integer of different size" when CONFIG_ARM_LPAE is enabled.
Signed-off-by: Suman Anna <s-anna@ti.com>
rpmsg: rpc: use %pa for printing phys_addr_t
The phys_addr_t types can be printed properly using the %pa
printk format-specifier, there is no need to type-cast the
corresponding variables to a different type and print them
accordingly.
Signed-off-by: Suman Anna <s-anna@ti.com>
The phys_addr_t types can be printed properly using the %pa
printk format-specifier, there is no need to type-cast the
corresponding variables to a different type and print them
accordingly.
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'rpmsg-linux-3.14.y' of git://git.ti.com/rpmsg/rpmsg into rpmsg-ti-linux-3.14.y
Pull in the updated rpmsg base feature branch that fixes the
rpmsg communication issues when using carveout memories for
device specific pools. The fixes are based on enhancements to
the virtio_ring and virtio_rpmsg_bus drivers to work properly
for buffers whose kernel virtual addresses lie in the vmalloc
range (essentially non-linear mappings).
* 'rpmsg-linux-3.14.y' of git://git.ti.com/rpmsg/rpmsg:
rpmsg: fill in dma fields for sgs passed to virtio
virtio_ring: add virtqueue_add_inbuf/outbuf_rpmsg API
virtio_ring: revise descriptor addition logic for virtio_rpmsg
Signed-off-by: Suman Anna <s-anna@ti.com>
Pull in the updated rpmsg base feature branch that fixes the
rpmsg communication issues when using carveout memories for
device specific pools. The fixes are based on enhancements to
the virtio_ring and virtio_rpmsg_bus drivers to work properly
for buffers whose kernel virtual addresses lie in the vmalloc
range (essentially non-linear mappings).
* 'rpmsg-linux-3.14.y' of git://git.ti.com/rpmsg/rpmsg:
rpmsg: fill in dma fields for sgs passed to virtio
virtio_ring: add virtqueue_add_inbuf/outbuf_rpmsg API
virtio_ring: revise descriptor addition logic for virtio_rpmsg
Signed-off-by: Suman Anna <s-anna@ti.com>
rpmsg: fill in dma fields for sgs passed to virtio
The virtio_rpmsg bus allocates the vring buffers using the
dma_alloc_coherent() API, and passes them to the virtio core
using the virtqueue_add_inbuf/outbuf() API. This API takes in a
scatterlist which is prepared using the returned virtual address
from the above dma allocation API. The virtio core expects the
descriptors to be allocated from linear address space in general,
but the dma_alloc_coherent() API can return virtual addresses from
the vmalloc range if the underlying memory is allocated from a
carveout.
This patch fills in the dma fields of the scatterlist structure,
and uses the newly added virtqueue_add_inbuf/outbuf_rpmsg() API
to pass these to the virtio core, so that the virtio core can
use sg_dma_address() API instead of sg_phys() API and thereby
fill in properly the physical addresses of the vring buffers in
the vring transport.
Based on a RFC patch from Edgar E. Iglesias <edgar.iglesias@xilinx.com>,
http://marc.info/?l=linux-virtualization&m=143047903512230&w=2
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Angela Stegmaier <angelabaker@ti.com>
The virtio_rpmsg bus allocates the vring buffers using the
dma_alloc_coherent() API, and passes them to the virtio core
using the virtqueue_add_inbuf/outbuf() API. This API takes in a
scatterlist which is prepared using the returned virtual address
from the above dma allocation API. The virtio core expects the
descriptors to be allocated from linear address space in general,
but the dma_alloc_coherent() API can return virtual addresses from
the vmalloc range if the underlying memory is allocated from a
carveout.
This patch fills in the dma fields of the scatterlist structure,
and uses the newly added virtqueue_add_inbuf/outbuf_rpmsg() API
to pass these to the virtio core, so that the virtio core can
use sg_dma_address() API instead of sg_phys() API and thereby
fill in properly the physical addresses of the vring buffers in
the vring transport.
Based on a RFC patch from Edgar E. Iglesias <edgar.iglesias@xilinx.com>,
http://marc.info/?l=linux-virtualization&m=143047903512230&w=2
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Angela Stegmaier <angelabaker@ti.com>
virtio_ring: add virtqueue_add_inbuf/outbuf_rpmsg API
Expose new variants of virtqueue_add_inbuf() & virtqueue_add_outbuf()
API specifically to deal with virtio_rpmsg. The virtio core in general
expects all the vring buffers to be allocated from linear addresses,
but the virtio_rpmsg can have buffers in non-linear space due to its
usage of the dma_alloc_coherent() API.
Based on a RFC patch from Edgar E. Iglesias <edgar.iglesias@xilinx.com>,
http://marc.info/?l=linux-virtualization&m=143047902512226&w=2
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Angela Stegmaier <angelabaker@ti.com>
Expose new variants of virtqueue_add_inbuf() & virtqueue_add_outbuf()
API specifically to deal with virtio_rpmsg. The virtio core in general
expects all the vring buffers to be allocated from linear addresses,
but the virtio_rpmsg can have buffers in non-linear space due to its
usage of the dma_alloc_coherent() API.
Based on a RFC patch from Edgar E. Iglesias <edgar.iglesias@xilinx.com>,
http://marc.info/?l=linux-virtualization&m=143047902512226&w=2
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Angela Stegmaier <angelabaker@ti.com>
virtio_ring: revise descriptor addition logic for virtio_rpmsg
The virtio core expects the vring buffers to be allocated from
linear address space in general, but this may not be true always
with virtio_rpmsg. The virtio_rpmsg bus allocates the vring buffers
using the dma_alloc_coherent() API, and this API can return virtual
addresses from the vmalloc range if the underlying memory is allocated
from a carveout (physical contiguous memory not mapped into kernel).
This patch adds a 'rpmsg' flag to the internal virtqueue_add function
and leverages this flag to revise the descriptor preparation when
adding the buffers. The revised logic uses the sg_dma_address() and
sg_dma_len() helpers instead of relying on sg_phys() and sg->length
fields, so that the remote side sees the physical addresses of the
vring buffers properly. The virtio rpmsg core is expected to prepare
the scatterlist structures with the dma fields filled in properly, and
use a new API (will be added in following patch) to add the virtqueue
buffers.
Based on a RFC patch from Edgar E. Iglesias <edgar.iglesias@xilinx.com>,
http://marc.info/?l=linux-virtualization&m=143047901612225&w=2
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Angela Stegmaier <angelabaker@ti.com>
The virtio core expects the vring buffers to be allocated from
linear address space in general, but this may not be true always
with virtio_rpmsg. The virtio_rpmsg bus allocates the vring buffers
using the dma_alloc_coherent() API, and this API can return virtual
addresses from the vmalloc range if the underlying memory is allocated
from a carveout (physical contiguous memory not mapped into kernel).
This patch adds a 'rpmsg' flag to the internal virtqueue_add function
and leverages this flag to revise the descriptor preparation when
adding the buffers. The revised logic uses the sg_dma_address() and
sg_dma_len() helpers instead of relying on sg_phys() and sg->length
fields, so that the remote side sees the physical addresses of the
vring buffers properly. The virtio rpmsg core is expected to prepare
the scatterlist structures with the dma fields filled in properly, and
use a new API (will be added in following patch) to add the virtqueue
buffers.
Based on a RFC patch from Edgar E. Iglesias <edgar.iglesias@xilinx.com>,
http://marc.info/?l=linux-virtualization&m=143047901612225&w=2
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Angela Stegmaier <angelabaker@ti.com>
Merge branch 'rpmsg-linux-3.14.y' of git://git.ti.com/rpmsg/rpmsg into rpmsg-ti-linux-3.14.y
Pull in a minor fix in the rpmsg-proto driver that removes the
include of a header file that should not have been included
directly.
* 'rpmsg-linux-3.14.y' of git://git.ti.com/rpmsg/rpmsg:
net/rpmsg: remove rwlock.h header inclusion
Signed-off-by: Suman Anna <s-anna@ti.com>
Pull in a minor fix in the rpmsg-proto driver that removes the
include of a header file that should not have been included
directly.
* 'rpmsg-linux-3.14.y' of git://git.ti.com/rpmsg/rpmsg:
net/rpmsg: remove rwlock.h header inclusion
Signed-off-by: Suman Anna <s-anna@ti.com>
net/rpmsg: remove rwlock.h header inclusion
The rpmsg-proto driver is currently including the linux/rwlock.h
header file, and it is not recommended to be including this header
file directly. So remove the inclusion of this header file.
Signed-off-by: Suman Anna <s-anna@ti.com>
The rpmsg-proto driver is currently including the linux/rwlock.h
header file, and it is not recommended to be including this header
file directly. So remove the inclusion of this header file.
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-3.14.y
Pull in the updated remoteproc feature branch that includes the
fixes for PM suspend/resume support on the DSP remote processors
on DRA7xx family of SoCs.
* 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc:
ARM: OMAP2+: Add workaround for DRA7 DSP MStandby errata i879
ARM: OMAP2+: Extend DRA7 IPU1 MMU pdata quirks to DSP MDMA MMUs
Signed-off-by: Suman Anna <s-anna@ti.com>
Pull in the updated remoteproc feature branch that includes the
fixes for PM suspend/resume support on the DSP remote processors
on DRA7xx family of SoCs.
* 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc:
ARM: OMAP2+: Add workaround for DRA7 DSP MStandby errata i879
ARM: OMAP2+: Extend DRA7 IPU1 MMU pdata quirks to DSP MDMA MMUs
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'iommu-linux-3.14.y' of git://git.ti.com/rpmsg/iommu into rproc-linux-3.14.y
Merge in the updated iommu feature branch into remoteproc tree to
pull in the necessary support to fix various DRA7 DSP PM suspend/
resume issues.
* 'iommu-linux-3.14.y' of git://git.ti.com/rpmsg/iommu:
ARM: OMAP2+: Add workaround for DRA7 DSP MStandby errata i879
ARM: OMAP2+: Extend DRA7 IPU1 MMU pdata quirks to DSP MDMA MMUs
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge in the updated iommu feature branch into remoteproc tree to
pull in the necessary support to fix various DRA7 DSP PM suspend/
resume issues.
* 'iommu-linux-3.14.y' of git://git.ti.com/rpmsg/iommu:
ARM: OMAP2+: Add workaround for DRA7 DSP MStandby errata i879
ARM: OMAP2+: Extend DRA7 IPU1 MMU pdata quirks to DSP MDMA MMUs
Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: OMAP2+: Add workaround for DRA7 DSP MStandby errata i879
Errata Title:
i879: DSP MStandby requires CD_EMU in SW_WKUP
Description:
The DSP requires the internal emulation clock to be actively toggling
in order to successfully enter a low power mode via execution of the
IDLE instruction and PRCM MStandby/Idle handshake. This assumes that
other prerequisites and software sequence are followed.
Workaround:
The emulation clock to the DSP is free-running anytime CCS is connected
via JTAG debugger to the DSP subsystem or when the CD_EMU clock domain
is set in SW_WKUP mode. The CD_EMU domain can be set in SW_WKUP mode
via the CM_EMU_CLKSTCTRL [1:0]CLKTRCTRL field.
Implementation:
This patch implements this workaround by denying the HW_AUTO mode
for the EMU clockdomain during the power-up of any DSP processor
and re-enabling the HW_AUTO mode during the shutdown of the last
DSP processor (actually done during the enabling and disabling of
the respective DSP MDMA MMUs). Reference counting has to be used to
manage the independent sequencing between the multiple DSP processors.
This switching is done at runtime rather than a static clockdomain
flags value to meet the target power domain state for the EMU power
domain during suspend.
Tested-by: Angela Stegmaier <angelabaker@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Errata Title:
i879: DSP MStandby requires CD_EMU in SW_WKUP
Description:
The DSP requires the internal emulation clock to be actively toggling
in order to successfully enter a low power mode via execution of the
IDLE instruction and PRCM MStandby/Idle handshake. This assumes that
other prerequisites and software sequence are followed.
Workaround:
The emulation clock to the DSP is free-running anytime CCS is connected
via JTAG debugger to the DSP subsystem or when the CD_EMU clock domain
is set in SW_WKUP mode. The CD_EMU domain can be set in SW_WKUP mode
via the CM_EMU_CLKSTCTRL [1:0]CLKTRCTRL field.
Implementation:
This patch implements this workaround by denying the HW_AUTO mode
for the EMU clockdomain during the power-up of any DSP processor
and re-enabling the HW_AUTO mode during the shutdown of the last
DSP processor (actually done during the enabling and disabling of
the respective DSP MDMA MMUs). Reference counting has to be used to
manage the independent sequencing between the multiple DSP processors.
This switching is done at runtime rather than a static clockdomain
flags value to meet the target power domain state for the EMU power
domain during suspend.
Tested-by: Angela Stegmaier <angelabaker@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: OMAP2+: Extend DRA7 IPU1 MMU pdata quirks to DSP MDMA MMUs
The C66-based DSPs on DRA7xx SoCs do not support a Powerdown-RET
mode, and only supports a Powerdown-Grid OFF mode which requires
a boot from reset. The HW_AUTO setting and a target power domain
state of OFF implies that the DSPs are powered off as soon as
they are idled by executing an IDLE instruction. The DSPs lose
their context as a result and will be unable to resume operations
from any wakeup event.
The DSP power domains therefore need to be restricted to ON state
for the duration a DSP processor is actively running. This is
similar to the restriction required for DRA7 IPU1 processor (albeit
because of a different reason). The IPU1 behavior is handled in
commit 9d964601689c ("ARM: OMAP2+: use separate IOMMU pdata to fix
DRA7 IPU1 boot") which adds a .set_pwrdm_constraint ops to the OMAP
IOMMU platform data to restrict the IPU1 power domain to ON state
during the active period of the IPU1 remote processor.
Extend the IPU1 iommu pdata quirks to the DRA7 MDMA MMUs as well
to restrict the DSP power domains to ON state. The MDMA MMU module
configuration will be the first and last steps in the boot and
shutdown sequences of the DSP processors. The existing IPU1 IOMMU
pdata variable has also been renamed appropriately to reflect the
common usage between the IPU1 and the DSPs.
Tested-by: Angela Stegmaier <angelabaker@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
The C66-based DSPs on DRA7xx SoCs do not support a Powerdown-RET
mode, and only supports a Powerdown-Grid OFF mode which requires
a boot from reset. The HW_AUTO setting and a target power domain
state of OFF implies that the DSPs are powered off as soon as
they are idled by executing an IDLE instruction. The DSPs lose
their context as a result and will be unable to resume operations
from any wakeup event.
The DSP power domains therefore need to be restricted to ON state
for the duration a DSP processor is actively running. This is
similar to the restriction required for DRA7 IPU1 processor (albeit
because of a different reason). The IPU1 behavior is handled in
commit 9d964601689c ("ARM: OMAP2+: use separate IOMMU pdata to fix
DRA7 IPU1 boot") which adds a .set_pwrdm_constraint ops to the OMAP
IOMMU platform data to restrict the IPU1 power domain to ON state
during the active period of the IPU1 remote processor.
Extend the IPU1 iommu pdata quirks to the DRA7 MDMA MMUs as well
to restrict the DSP power domains to ON state. The MDMA MMU module
configuration will be the first and last steps in the boot and
shutdown sequences of the DSP processors. The existing IPU1 IOMMU
pdata variable has also been renamed appropriately to reflect the
common usage between the IPU1 and the DSPs.
Tested-by: Angela Stegmaier <angelabaker@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'rpmsg-linux-3.14.y' of git://git.ti.com/rpmsg/rpmsg into rpmsg-ti-linux-3.14.y
Pull in a minor fix in the rpmsg-proto driver that performs a sanity
check of the length of the buffer to be transmitted.
* 'rpmsg-linux-3.14.y' of git://git.ti.com/rpmsg/rpmsg:
net/rpmsg: sanity check the input buffer length in sendmsg
Signed-off-by: Suman Anna <s-anna@ti.com>
Pull in a minor fix in the rpmsg-proto driver that performs a sanity
check of the length of the buffer to be transmitted.
* 'rpmsg-linux-3.14.y' of git://git.ti.com/rpmsg/rpmsg:
net/rpmsg: sanity check the input buffer length in sendmsg
Signed-off-by: Suman Anna <s-anna@ti.com>
net/rpmsg: sanity check the input buffer length in sendmsg
The virtio rpmsg transport uses 512 byte buffers, and this is
the maximum data that can be transmitted including the rpmsg
message header size. The individual rpmsg client drivers
therefore can transmit only upto about 496 bytes (based on
16-bytes for rpmsg_hdr), and the rpmsg_sock_sendmsg() uses
a local kernel buffer on the stack for copying the buffer
from userspace and transmitting it.
Perform a sanity check on the length of the buffer passed in
from the userspace in rpmsg_sock_sendmsg() to not exceed the
rpmsg client driver payload size. This fixes a kernel hang
when large messages are attempted to be transmitted.
Reported-by: Robert Tivy <rtivy@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
The virtio rpmsg transport uses 512 byte buffers, and this is
the maximum data that can be transmitted including the rpmsg
message header size. The individual rpmsg client drivers
therefore can transmit only upto about 496 bytes (based on
16-bytes for rpmsg_hdr), and the rpmsg_sock_sendmsg() uses
a local kernel buffer on the stack for copying the buffer
from userspace and transmitting it.
Perform a sanity check on the length of the buffer passed in
from the userspace in rpmsg_sock_sendmsg() to not exceed the
rpmsg client driver payload size. This fixes a kernel hang
when large messages are attempted to be transmitted.
Reported-by: Robert Tivy <rtivy@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'rpmsg-linux-3.14.y' of git://git.ti.com/rpmsg/rpmsg into rpmsg-ti-linux-3.14.y
Pull in a minor enhancement to the rpmsg_client_sample driver to support
multiple instances. This will allow the driver to communicate to each
instance that may be present on different remote processors.
* 'rpmsg-linux-3.14.y' of git://git.ti.com/rpmsg/rpmsg:
samples/rpmsg: add support for multiple instances
Signed-off-by: Suman Anna <s-anna@ti.com>
Pull in a minor enhancement to the rpmsg_client_sample driver to support
multiple instances. This will allow the driver to communicate to each
instance that may be present on different remote processors.
* 'rpmsg-linux-3.14.y' of git://git.ti.com/rpmsg/rpmsg:
samples/rpmsg: add support for multiple instances
Signed-off-by: Suman Anna <s-anna@ti.com>
samples/rpmsg: add support for multiple instances
The current rpmsg_client_sample is a very simple example and
is not designed to handle multiple instances. Add support for
multiple instances, so that the same number of pings are sent
to each instance. The instances can be on one or multiple
remote processors.
Signed-off-by: Suman Anna <s-anna@ti.com>
The current rpmsg_client_sample is a very simple example and
is not designed to handle multiple instances. Add support for
multiple instances, so that the same number of pings are sent
to each instance. The instances can be on one or multiple
remote processors.
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-3.14.y
Pull in the updated remoteproc feature branch that includes the
necessary support to fix the DRA7 IPU1 boot issue when integrated
with PM tree or TI Integration kernel. The merge also syncs up
the RPMsg integration branch with the latest platform base code.
* 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc: (132 commits)
Revert "ARM: OMAP: DRA7: change IPU1 clk domain to SWSUP for proper boot"
ARM: OMAP2+: use separate IOMMU pdata to fix DRA7 IPU1 boot
iommu/omap: fix boot issue on remoteprocs with AMMU/Unicache
iommu/omap: add pdata ops for setting powerdomain constraint
ARM: dts: OMAP5: Fix the standby info for IPU & DSP
ARM: OMAP: Check for clocks which do not have parents
ARM: OMAP: DRA7: clockdomain: Implement timer workaround for errata i874
ARM: dts: DRA7: Add DT node for AES2 IP
ARM: DRA7: hwmod: Add data for AES2 IP
crypto: omap-aes - Add support for multiple cores
crypto: omap-aes - Fix registration of Algos
crypto: omap-aes - Fix enabling clocks
crypto: tcrypt - Added speed tests for Async AEAD crypto alogrithms
crypto: omap-aes - Add support for GCM mode
crypto: omap-aes - Fix configuring of AES mode
crypto: omap-aes - Add support for lengths not aligned with AES_BLOCK_SIZE
crypto: omap-des: Fix unmapping of dma channels
dmaenegine: edma: allow pause/resume for non-cyclic mode
ARM: common: edma: clear completion interrupts on stop
bus: omap_l3_noc: Fix master id address decoding for OMAP5
...
Signed-off-by: Suman Anna <s-anna@ti.com>
Pull in the updated remoteproc feature branch that includes the
necessary support to fix the DRA7 IPU1 boot issue when integrated
with PM tree or TI Integration kernel. The merge also syncs up
the RPMsg integration branch with the latest platform base code.
* 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc: (132 commits)
Revert "ARM: OMAP: DRA7: change IPU1 clk domain to SWSUP for proper boot"
ARM: OMAP2+: use separate IOMMU pdata to fix DRA7 IPU1 boot
iommu/omap: fix boot issue on remoteprocs with AMMU/Unicache
iommu/omap: add pdata ops for setting powerdomain constraint
ARM: dts: OMAP5: Fix the standby info for IPU & DSP
ARM: OMAP: Check for clocks which do not have parents
ARM: OMAP: DRA7: clockdomain: Implement timer workaround for errata i874
ARM: dts: DRA7: Add DT node for AES2 IP
ARM: DRA7: hwmod: Add data for AES2 IP
crypto: omap-aes - Add support for multiple cores
crypto: omap-aes - Fix registration of Algos
crypto: omap-aes - Fix enabling clocks
crypto: tcrypt - Added speed tests for Async AEAD crypto alogrithms
crypto: omap-aes - Add support for GCM mode
crypto: omap-aes - Fix configuring of AES mode
crypto: omap-aes - Add support for lengths not aligned with AES_BLOCK_SIZE
crypto: omap-des: Fix unmapping of dma channels
dmaenegine: edma: allow pause/resume for non-cyclic mode
ARM: common: edma: clear completion interrupts on stop
bus: omap_l3_noc: Fix master id address decoding for OMAP5
...
Signed-off-by: Suman Anna <s-anna@ti.com>
Revert "ARM: OMAP: DRA7: change IPU1 clk domain to SWSUP for proper boot"
This reverts commit 6d6dd44c55638d54a151bf2ae6cc77b2f4e459d0.
The commit 6d6dd44c5563 ("ARM: OMAP: DRA7: change IPU1 clk domain to SWSUP
for proper boot") switched the IPU1 clock domain to SWSUP only to resolve
an IPU1 boot issue. However, this solution worked only because of another
pre-existing bug in the omap_hwmod code, wherein a usage count for the hwmod
parent clockdomain was incremented during omap_device_deassert_hardreset()
and was never balanced, causing the clockdomain to always remain on and
never allowing the corresponding power domain to enter a low power state.
This eliminated the pre-condition for the IPU1 boot issue. The bug in
omap_hwmod layer was resolved by commit e1d52c6d4ff7 ("ARM: OMAP2+: hwmod:
fix deassert hardreset clkdm usecounting"), and this resulted in the
recurrence of the IPU1 boot issue on some platforms.
The IPU1 boot issue has now been resolved by restricting the target power
domain state to ON during the power-up of the MMU and allowing RET or a
lower power state only when the MMU and the corresponding parent remoteproc
is suspended (system or runtime suspend). So revert back to the default
expected HWSUP mode for the IPU1 clock domain.
Signed-off-by: Suman Anna <s-anna@ti.com>
This reverts commit 6d6dd44c55638d54a151bf2ae6cc77b2f4e459d0.
The commit 6d6dd44c5563 ("ARM: OMAP: DRA7: change IPU1 clk domain to SWSUP
for proper boot") switched the IPU1 clock domain to SWSUP only to resolve
an IPU1 boot issue. However, this solution worked only because of another
pre-existing bug in the omap_hwmod code, wherein a usage count for the hwmod
parent clockdomain was incremented during omap_device_deassert_hardreset()
and was never balanced, causing the clockdomain to always remain on and
never allowing the corresponding power domain to enter a low power state.
This eliminated the pre-condition for the IPU1 boot issue. The bug in
omap_hwmod layer was resolved by commit e1d52c6d4ff7 ("ARM: OMAP2+: hwmod:
fix deassert hardreset clkdm usecounting"), and this resulted in the
recurrence of the IPU1 boot issue on some platforms.
The IPU1 boot issue has now been resolved by restricting the target power
domain state to ON during the power-up of the MMU and allowing RET or a
lower power state only when the MMU and the corresponding parent remoteproc
is suspended (system or runtime suspend). So revert back to the default
expected HWSUP mode for the IPU1 clock domain.
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'iommu-linux-3.14.y' of git://git.ti.com/rpmsg/iommu into rproc-linux-3.14.y
Merge in the updated iommu feature branch into remoteproc tree to
pull in the necessary support to fix the DRA7 IPU1 boot issue when
integrated with PM tree.
* 'iommu-linux-3.14.y' of git://git.ti.com/rpmsg/iommu:
ARM: OMAP2+: use separate IOMMU pdata to fix DRA7 IPU1 boot
iommu/omap: fix boot issue on remoteprocs with AMMU/Unicache
iommu/omap: add pdata ops for setting powerdomain constraint
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge in the updated iommu feature branch into remoteproc tree to
pull in the necessary support to fix the DRA7 IPU1 boot issue when
integrated with PM tree.
* 'iommu-linux-3.14.y' of git://git.ti.com/rpmsg/iommu:
ARM: OMAP2+: use separate IOMMU pdata to fix DRA7 IPU1 boot
iommu/omap: fix boot issue on remoteprocs with AMMU/Unicache
iommu/omap: add pdata ops for setting powerdomain constraint
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'platform-ti-linux-3.14.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree into rproc-linux-3.14.y
Resync with the latest platform base code. Relevant
fixes include fixes on DPLL bypass clock settings
and support for Timers 12 through 16.
* 'platform-ti-linux-3.14.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree: (127 commits)
ARM: OMAP: Check for clocks which do not have parents
ARM: OMAP: DRA7: clockdomain: Implement timer workaround for errata i874
ARM: dts: DRA7: Add DT node for AES2 IP
ARM: DRA7: hwmod: Add data for AES2 IP
crypto: omap-aes - Add support for multiple cores
crypto: omap-aes - Fix registration of Algos
crypto: omap-aes - Fix enabling clocks
crypto: tcrypt - Added speed tests for Async AEAD crypto alogrithms
crypto: omap-aes - Add support for GCM mode
crypto: omap-aes - Fix configuring of AES mode
crypto: omap-aes - Add support for lengths not aligned with AES_BLOCK_SIZE
crypto: omap-des: Fix unmapping of dma channels
dmaenegine: edma: allow pause/resume for non-cyclic mode
ARM: common: edma: clear completion interrupts on stop
bus: omap_l3_noc: Fix master id address decoding for OMAP5
ARM: edma: Clear IRQ if we get interrupted by a unknown event
bus: omap_l3_noc: Fix connID for OMAP4
bus: omap_l3_noc: Fix offset for DRA7 CLK1_HOST_CLK1_2 instance
crypto: omap-sham: Use pm_runtime_irq_safe()
crypto: omap-sham: Add the offset of sg page to vaddr
...
Signed-off-by: Suman Anna <s-anna@ti.com>
Resync with the latest platform base code. Relevant
fixes include fixes on DPLL bypass clock settings
and support for Timers 12 through 16.
* 'platform-ti-linux-3.14.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree: (127 commits)
ARM: OMAP: Check for clocks which do not have parents
ARM: OMAP: DRA7: clockdomain: Implement timer workaround for errata i874
ARM: dts: DRA7: Add DT node for AES2 IP
ARM: DRA7: hwmod: Add data for AES2 IP
crypto: omap-aes - Add support for multiple cores
crypto: omap-aes - Fix registration of Algos
crypto: omap-aes - Fix enabling clocks
crypto: tcrypt - Added speed tests for Async AEAD crypto alogrithms
crypto: omap-aes - Add support for GCM mode
crypto: omap-aes - Fix configuring of AES mode
crypto: omap-aes - Add support for lengths not aligned with AES_BLOCK_SIZE
crypto: omap-des: Fix unmapping of dma channels
dmaenegine: edma: allow pause/resume for non-cyclic mode
ARM: common: edma: clear completion interrupts on stop
bus: omap_l3_noc: Fix master id address decoding for OMAP5
ARM: edma: Clear IRQ if we get interrupted by a unknown event
bus: omap_l3_noc: Fix connID for OMAP4
bus: omap_l3_noc: Fix offset for DRA7 CLK1_HOST_CLK1_2 instance
crypto: omap-sham: Use pm_runtime_irq_safe()
crypto: omap-sham: Add the offset of sg page to vaddr
...
Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: OMAP2+: use separate IOMMU pdata to fix DRA7 IPU1 boot
The IPU1 MMU has been using common IOMMU pdata quirks defined and
used by all IPU IOMMU devices on OMAP4 and beyond. Separate out the
pdata for IPU1 MMU with the additional .set_pwrdm_constraint ops
plugged in, so that the IPU1 power domain can be restricted to ON
state during the boot and active period of the IPU1 remote processor.
This eliminates the pre-conditions for the IPU1 boot issue as
described in [1].
NOTE:
The fix is currently applied only to IPU1 on DRA7xx SoC, as the
other affected processors on OMAP4/OMAP5/DRA7 are in domains that
are not entering RET. The fix can be easily scaled if these domains
do hit RET in the future.
[1] http://git.ti.com/gitweb/?p=rpmsg/rpmsg.git;a=commit;h=6d6dd44c55638d54a151bf2ae6cc77b2f4e459d0
Signed-off-by: Suman Anna <s-anna@ti.com>
The IPU1 MMU has been using common IOMMU pdata quirks defined and
used by all IPU IOMMU devices on OMAP4 and beyond. Separate out the
pdata for IPU1 MMU with the additional .set_pwrdm_constraint ops
plugged in, so that the IPU1 power domain can be restricted to ON
state during the boot and active period of the IPU1 remote processor.
This eliminates the pre-conditions for the IPU1 boot issue as
described in [1].
NOTE:
The fix is currently applied only to IPU1 on DRA7xx SoC, as the
other affected processors on OMAP4/OMAP5/DRA7 are in domains that
are not entering RET. The fix can be easily scaled if these domains
do hit RET in the future.
[1] http://git.ti.com/gitweb/?p=rpmsg/rpmsg.git;a=commit;h=6d6dd44c55638d54a151bf2ae6cc77b2f4e459d0
Signed-off-by: Suman Anna <s-anna@ti.com>
iommu/omap: fix boot issue on remoteprocs with AMMU/Unicache
This patch invokes the .set_pwrdm_constraint pdata ops, if present,
during the runtime resume and suspend callbacks to resolve a possible
boot issue on remote processors with AMMU/Unicache, and whose power
domains enter RET between the time the MMU is powered ON to the time
the remote processor is released from reset. The issue is described
in detail in [1].
The pdata ops implementation restricts the target power domain to
ON during resume, and back to the original power domain state during
suspend, and thereby eliminating the conditions for the boot issue.
The implementation is effective only when the original power domain
state is either RET or OFF, and is a no-op when it is ON or INACTIVE.
Doing this in the PM runtime callbacks ensures that the target power
domain stays ON only during the time when the remote processor is
active. The remote processors are typically auto-suspended after an
inactivity period of 10 seconds.
The .set_pwrdm_constraint ops need to be plugged in pdata-quirks
for the affected remote processors to be able to boot properly.
[1] http://git.ti.com/gitweb/?p=rpmsg/rpmsg.git;a=commit;h=6d6dd44c55638d54a151bf2ae6cc77b2f4e459d0
Signed-off-by: Suman Anna <s-anna@ti.com>
This patch invokes the .set_pwrdm_constraint pdata ops, if present,
during the runtime resume and suspend callbacks to resolve a possible
boot issue on remote processors with AMMU/Unicache, and whose power
domains enter RET between the time the MMU is powered ON to the time
the remote processor is released from reset. The issue is described
in detail in [1].
The pdata ops implementation restricts the target power domain to
ON during resume, and back to the original power domain state during
suspend, and thereby eliminating the conditions for the boot issue.
The implementation is effective only when the original power domain
state is either RET or OFF, and is a no-op when it is ON or INACTIVE.
Doing this in the PM runtime callbacks ensures that the target power
domain stays ON only during the time when the remote processor is
active. The remote processors are typically auto-suspended after an
inactivity period of 10 seconds.
The .set_pwrdm_constraint ops need to be plugged in pdata-quirks
for the affected remote processors to be able to boot properly.
[1] http://git.ti.com/gitweb/?p=rpmsg/rpmsg.git;a=commit;h=6d6dd44c55638d54a151bf2ae6cc77b2f4e459d0
Signed-off-by: Suman Anna <s-anna@ti.com>
iommu/omap: add pdata ops for setting powerdomain constraint
Add a new platform data ops to allow the OMAP IOMMU driver to be able
to request a specific target power domain state for the domain it
belongs to. This ops is being added to resolve a boot issue on OMAP
remote processors like IPU that have an AMMU/Unicache, which will be
in an invalid state if the particular power domain enters RET between
the MMU programming and releasing the reset of the remote processor.
See [1] for more details on the issue.
The ops will allow to invoke the pwrdm_set_next_pwrst() API in a
multi-arch kernel environment. The ops also returns the current power
domain state while enforcing the constraint so that the driver can
store it and use it to set back the power domain state while releasing
the constraint.
[1] http://git.ti.com/gitweb/?p=rpmsg/rpmsg.git;a=commit;h=6d6dd44c55638d54a151bf2ae6cc77b2f4e459d0
Signed-off-by: Suman Anna <s-anna@ti.com>
Add a new platform data ops to allow the OMAP IOMMU driver to be able
to request a specific target power domain state for the domain it
belongs to. This ops is being added to resolve a boot issue on OMAP
remote processors like IPU that have an AMMU/Unicache, which will be
in an invalid state if the particular power domain enters RET between
the MMU programming and releasing the reset of the remote processor.
See [1] for more details on the issue.
The ops will allow to invoke the pwrdm_set_next_pwrst() API in a
multi-arch kernel environment. The ops also returns the current power
domain state while enforcing the constraint so that the driver can
store it and use it to set back the power domain state while releasing
the constraint.
[1] http://git.ti.com/gitweb/?p=rpmsg/rpmsg.git;a=commit;h=6d6dd44c55638d54a151bf2ae6cc77b2f4e459d0
Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: dts: OMAP5: Fix the standby info for IPU & DSP
The commit 04e7b6f76f6b ("ARM: dts: OMAP5: Add standby info for
IPU and DSP") added the ti,rproc-standby-info property mistakenly
to the IPU & DSP MMU nodes instead of adding them to the processor
nodes. This results in a probe failure of the OMAP remoteproc driver.
Fix this error by moving these properties from the MMU nodes to the
processor nodes.
Fixes: 04e7b6f76f6b ("ARM: dts: OMAP5: Add standby info for IPU and DSP")
Signed-off-by: Suman Anna <s-anna@ti.com>
The commit 04e7b6f76f6b ("ARM: dts: OMAP5: Add standby info for
IPU and DSP") added the ti,rproc-standby-info property mistakenly
to the IPU & DSP MMU nodes instead of adding them to the processor
nodes. This results in a probe failure of the OMAP remoteproc driver.
Fix this error by moving these properties from the MMU nodes to the
processor nodes.
Fixes: 04e7b6f76f6b ("ARM: dts: OMAP5: Add standby info for IPU and DSP")
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-3.14.y
Pull in couple of minor patches from the remoteproc feature tree,
one is a minor bug fix in PRUSS remoteproc driver, and the other
is a comment correction in OMAP remoteproc driver.
* 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc:
remoteproc/omap: revise the comment about standby in _suspend
remoteproc/pruss: fix pruss_init return on error
Signed-off-by: Suman Anna <s-anna@ti.com>
Pull in couple of minor patches from the remoteproc feature tree,
one is a minor bug fix in PRUSS remoteproc driver, and the other
is a comment correction in OMAP remoteproc driver.
* 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc:
remoteproc/omap: revise the comment about standby in _suspend
remoteproc/pruss: fix pruss_init return on error
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc/omap: revise the comment about standby in _suspend
The _suspend() function has a TODO comment about implementing a
BIOS-independent hook to send a message to notify the MPU the
completion of the context save on the remoteproc side. This has
been clarified with the SYS/BIOS team now, and this race condition
between the remoteproc saving the context and the MPU waiting for
the sync point before it puts the remote processor into reset, can
never be resolved using a message ACK or a shared memory variable
signalling. So, update the comment appropriately.
Signed-off-by: Suman Anna <s-anna@ti.com>
The _suspend() function has a TODO comment about implementing a
BIOS-independent hook to send a message to notify the MPU the
completion of the context save on the remoteproc side. This has
been clarified with the SYS/BIOS team now, and this race condition
between the remoteproc saving the context and the MPU waiting for
the sync point before it puts the remote processor into reset, can
never be resolved using a message ACK or a shared memory variable
signalling. So, update the comment appropriately.
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc/pruss: fix pruss_init return on error
If the pru_rproc_driver fails to register in pruss_init(),
the failure code should be returned instead of returning 0,
a success value. So, fix the pruss_init() return code
accordingly.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
If the pru_rproc_driver fails to register in pruss_init(),
the failure code should be returned instead of returning 0,
a success value. So, fix the pruss_init() return code
accordingly.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-3.14.y
Pull in a minor trace change for the PRUSS remoteproc driver.
* 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc:
remoteproc/pruss: lower the trace level in pru_rproc_mbox_callback
Signed-off-by: Suman Anna <s-anna@ti.com>
Pull in a minor trace change for the PRUSS remoteproc driver.
* 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc:
remoteproc/pruss: lower the trace level in pru_rproc_mbox_callback
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc/pruss: lower the trace level in pru_rproc_mbox_callback
The current virtio rpmsg stack is such that it processes all the
pending messages in the vring on a single interrupt. So, it is
possible to see an empty interrupt without having to process any
messages, especially in cases where there is additional message
message communication that happens in-band within the callback
of a received message while processing it.
This behavior is seen when running the rpmsg_client_sample, and
printing the current trace message in pru_rproc_mbox_callback()
rather frequently, so lower the level of this trace from KERN_ERR
to KERN_DBG.
Reported-by: Jason Reeder <jreeder@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
The current virtio rpmsg stack is such that it processes all the
pending messages in the vring on a single interrupt. So, it is
possible to see an empty interrupt without having to process any
messages, especially in cases where there is additional message
message communication that happens in-band within the callback
of a received message while processing it.
This behavior is seen when running the rpmsg_client_sample, and
printing the current trace message in pru_rproc_mbox_callback()
rather frequently, so lower the level of this trace from KERN_ERR
to KERN_DBG.
Reported-by: Jason Reeder <jreeder@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-3.14.y
Pull in the updated remoteproc feature branch that adds the runtime
auto-suspend/resume support on the IPU and DSP remote processors
that already support system suspend. Also, includes a minor typo fix.
* 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc:
remoteproc/omap: fix a minor typo in a trace message
remoteproc/omap: add support for runtime auto-suspend/resume
Signed-off-by: Suman Anna <s-anna@ti.com>
Pull in the updated remoteproc feature branch that adds the runtime
auto-suspend/resume support on the IPU and DSP remote processors
that already support system suspend. Also, includes a minor typo fix.
* 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc:
remoteproc/omap: fix a minor typo in a trace message
remoteproc/omap: add support for runtime auto-suspend/resume
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc/omap: fix a minor typo in a trace message
The omap_mbox_msg_send() is the legacy API for sending a mailbox
message. It has been replaced with the mbox_send_message() from
the mailbox framework, so update the failure trace message
accordingly.
Signed-off-by: Suman Anna <s-anna@ti.com>
The omap_mbox_msg_send() is the legacy API for sending a mailbox
message. It has been replaced with the mbox_send_message() from
the mailbox framework, so update the failure trace message
accordingly.
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc/omap: add support for runtime auto-suspend/resume
This patch enhances the PM support in the OMAP remoteproc driver to
support the runtime auto-suspend. A remoteproc may not be required to
be running all the time, and typically will need to be active only
during certain usecases. As such, to save power, it should be turned
off during potential long periods of inactivity between usecases.
This suspend and resume of the device is a relatively heavy process
in terms of latencies, so a remoteproc should be suspended only after
a certain period of prolonged inactivity. The OMAP remoteproc driver
leverages the runtime pm framework's auto_suspend feature to accomplish
this functionality. This feature is automatically enabled when a remote
processor has successfully booted. The 'autosuspend_delay_ms' for each
device dictates the inactivity period/time to wait for before
suspending the device.
The runtime auto-suspend design relies on marking the last busy time
on every communication (virtqueue kick) to and from the remote processor.
When there has been no activity for 'autosuspend_delay_ms' time, the
runtime PM framework invokes the driver's runtime pm suspend callback
to suspend the device. The remote processor will be woken up on the
initiation of the next communication message through the runtime pm
resume callback. The current auto-suspend design also allows a remote
processor to deny a auto-suspend attempt, if it wishes to, by sending a
NACK response to the initial suspend request message sent to the remote
processor as part of the suspend process. The auto-suspend request is
also only attempted if the remote processor is idled and in standby at
the time of inactivity timer expiry. This choice is made to avoid
unnecessary messaging, and the auto-suspend is simply rescheduled to
be attempted again after a further lapse of autosuspend_delay_ms.
The runtime pm callbacks functionality in this patch reuses most of the
core logic from the suspend/resume support code, and make use of an
additional auto_suspend flag to differentiate the logic in common code
from system suspend. The system suspend/resume sequences are also updated
to reflect the proper pm_runtime statuses, and also to really perform a
suspend/resume only if the remoteproc has not been auto-suspended at the
time of request. The remote processor is left in suspended state on a
system resume if it has been auto-suspended before, and will be woken up
only when a usecase needs to run. The other significant change in this
patch is to reset the remoteproc device's pm_domain so as to avoid
conflicts with the ordering sequences in the device pm_domain's runtime
callbacks and the reset management and clock management implemented
within the runtime callbacks in the driver.
The OMAP remoteproc driver currently uses a default value of 10 seconds
for all OMAP remoteprocs, and a different value can be chosen either by
choosing a positive value for the 'autosuspend_delay' in the device's
omap_rproc_fw_data in the driver match data or by updating the
'autosuspend_delay_ms' field at runtime through the sysfs interface.
Eg: To use 25 seconds for IPU2 on DRA7xx,
echo 25000 > /sys/bus/platform/devices/55020000.ipu/power/autosuspend_delay_ms
The runtime suspend feature can also be similarly enabled or disabled by
writing 'auto' or 'on' to the device's 'control' power field. The default
is enabled.
Eg: To disable auto-suspend for IPU2 on DRA7xx SoC,
echo on > /sys/bus/platform/devices/55020000.ipu/power/control
Signed-off-by: Suman Anna <s-anna@ti.com>
This patch enhances the PM support in the OMAP remoteproc driver to
support the runtime auto-suspend. A remoteproc may not be required to
be running all the time, and typically will need to be active only
during certain usecases. As such, to save power, it should be turned
off during potential long periods of inactivity between usecases.
This suspend and resume of the device is a relatively heavy process
in terms of latencies, so a remoteproc should be suspended only after
a certain period of prolonged inactivity. The OMAP remoteproc driver
leverages the runtime pm framework's auto_suspend feature to accomplish
this functionality. This feature is automatically enabled when a remote
processor has successfully booted. The 'autosuspend_delay_ms' for each
device dictates the inactivity period/time to wait for before
suspending the device.
The runtime auto-suspend design relies on marking the last busy time
on every communication (virtqueue kick) to and from the remote processor.
When there has been no activity for 'autosuspend_delay_ms' time, the
runtime PM framework invokes the driver's runtime pm suspend callback
to suspend the device. The remote processor will be woken up on the
initiation of the next communication message through the runtime pm
resume callback. The current auto-suspend design also allows a remote
processor to deny a auto-suspend attempt, if it wishes to, by sending a
NACK response to the initial suspend request message sent to the remote
processor as part of the suspend process. The auto-suspend request is
also only attempted if the remote processor is idled and in standby at
the time of inactivity timer expiry. This choice is made to avoid
unnecessary messaging, and the auto-suspend is simply rescheduled to
be attempted again after a further lapse of autosuspend_delay_ms.
The runtime pm callbacks functionality in this patch reuses most of the
core logic from the suspend/resume support code, and make use of an
additional auto_suspend flag to differentiate the logic in common code
from system suspend. The system suspend/resume sequences are also updated
to reflect the proper pm_runtime statuses, and also to really perform a
suspend/resume only if the remoteproc has not been auto-suspended at the
time of request. The remote processor is left in suspended state on a
system resume if it has been auto-suspended before, and will be woken up
only when a usecase needs to run. The other significant change in this
patch is to reset the remoteproc device's pm_domain so as to avoid
conflicts with the ordering sequences in the device pm_domain's runtime
callbacks and the reset management and clock management implemented
within the runtime callbacks in the driver.
The OMAP remoteproc driver currently uses a default value of 10 seconds
for all OMAP remoteprocs, and a different value can be chosen either by
choosing a positive value for the 'autosuspend_delay' in the device's
omap_rproc_fw_data in the driver match data or by updating the
'autosuspend_delay_ms' field at runtime through the sysfs interface.
Eg: To use 25 seconds for IPU2 on DRA7xx,
echo 25000 > /sys/bus/platform/devices/55020000.ipu/power/autosuspend_delay_ms
The runtime suspend feature can also be similarly enabled or disabled by
writing 'auto' or 'on' to the device's 'control' power field. The default
is enabled.
Eg: To disable auto-suspend for IPU2 on DRA7xx SoC,
echo on > /sys/bus/platform/devices/55020000.ipu/power/control
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-3.14.y
Pull in the updated remoteproc feature branch that adds the support for
system suspend/resume for the IPU and DSP remote processors on OMAP4, OMAP5
and DRA7 (only IPUs). The feature branch also pulls in automatically the
dependent mailbox and iommu feature branches with suspend/resume support.
* 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc:
remoteproc/omap: add support for system suspend/resume
ARM: dts: DRA7: Add standby info for IPU & DSPs
ARM: dts: OMAP5: Add standby info for IPU and DSP
ARM: dts: OMAP4: Add standby info for IPU and DSP
Documentation: dt: update omap remoteproc binding for suspend
remoteproc/omap: use consistent match data structures for all SoCs
iommu/omap: add support for runtime auto suspend/resume
iommu/omap: add logic to save/restore locked TLBs
iommu/omap: introduce new API for suspend/resume
iommu/omap: streamline enable/disable through runtime pm callbacks
ARM: OMAP2+: add pdata-quirks for OMAP3 ISP IOMMU
ARM: OMAP2+: Add iommu pdata-quirks for DRA7 DSP EDMA MMUs
ARM: OMAP2+: plug in device_enable/idle ops for IOMMUs
iommu/omap: add pdata ops for omap_device_enable/idle
mailbox/omap: check for any unread messages during suspend
mailbox/omap: add support for suspend/resume
mailbox/omap: store mailbox interrupt type in omap_mbox_device
Signed-off-by: Suman Anna <s-anna@ti.com>
Pull in the updated remoteproc feature branch that adds the support for
system suspend/resume for the IPU and DSP remote processors on OMAP4, OMAP5
and DRA7 (only IPUs). The feature branch also pulls in automatically the
dependent mailbox and iommu feature branches with suspend/resume support.
* 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc:
remoteproc/omap: add support for system suspend/resume
ARM: dts: DRA7: Add standby info for IPU & DSPs
ARM: dts: OMAP5: Add standby info for IPU and DSP
ARM: dts: OMAP4: Add standby info for IPU and DSP
Documentation: dt: update omap remoteproc binding for suspend
remoteproc/omap: use consistent match data structures for all SoCs
iommu/omap: add support for runtime auto suspend/resume
iommu/omap: add logic to save/restore locked TLBs
iommu/omap: introduce new API for suspend/resume
iommu/omap: streamline enable/disable through runtime pm callbacks
ARM: OMAP2+: add pdata-quirks for OMAP3 ISP IOMMU
ARM: OMAP2+: Add iommu pdata-quirks for DRA7 DSP EDMA MMUs
ARM: OMAP2+: plug in device_enable/idle ops for IOMMUs
iommu/omap: add pdata ops for omap_device_enable/idle
mailbox/omap: check for any unread messages during suspend
mailbox/omap: add support for suspend/resume
mailbox/omap: store mailbox interrupt type in omap_mbox_device
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc/omap: add support for system suspend/resume
This patch adds the support for system suspend/resume to the
OMAP remoteproc driver so that the OMAP remoteproc devices can
be suspended/resumed during a system suspend/resume. The support
is added through the driver PM .suspend/.resume callbacks, and
requires appropriate support from the OS running on the remote
processors.
The IPU & DSP remote processors typically have their own private
modules like registers, internal memories, caches etc. The context
of these modules need to be saved and restored properly for a
suspend/resume to work. There are in general not accessible from
the MPU, so the remote processors themselves have to implement
the logic for the context save & restore of these modules.
The OMAP remoteproc driver initiates a suspend by sending a mailbox
message requesting the remote processor to save its context and
enter into an idle/standby state. The remote processor should
usually stop whatever processing it is doing to switch to a context
save mode. The OMAP remoteproc driver detects the completion of
the context save by checking the module standby status for the
remoteproc device. It also stops any resources used by the remote
processors like the timers. The timers need to be running only when
when the processor is active and executing, and need to be stopped
otherwise to allow the timer driver to reach low-power states. The
IOMMUs are also suspended by the remoteproc driver, and the suspend
process is completed by putting the remote processors into reset,
after which the Linux kernel can put the domain into further lower
power states as possible.
The resume sequence undoes the operations performed in the PM suspend
callback, by restoring the IOMMUs, starting the timers and finally
releasing the processors from reset. This requires that the remote
processor side OS be able to distinguish a power-resume boot from a
power-on/cold boot, restore the context of its private modules saved
during the suspend phase, and resume executing code from where it
was suspended.
The remote processors should save their context into System RAM (DDR),
as any internal memories are not guaranteed to retain context as it
depends on the lowest power domain that the remote processor device\
is put into. The management of the DDR contents will be managed by
the Linux kernel.
Signed-off-by: Suman Anna <s-anna@ti.com>
This patch adds the support for system suspend/resume to the
OMAP remoteproc driver so that the OMAP remoteproc devices can
be suspended/resumed during a system suspend/resume. The support
is added through the driver PM .suspend/.resume callbacks, and
requires appropriate support from the OS running on the remote
processors.
The IPU & DSP remote processors typically have their own private
modules like registers, internal memories, caches etc. The context
of these modules need to be saved and restored properly for a
suspend/resume to work. There are in general not accessible from
the MPU, so the remote processors themselves have to implement
the logic for the context save & restore of these modules.
The OMAP remoteproc driver initiates a suspend by sending a mailbox
message requesting the remote processor to save its context and
enter into an idle/standby state. The remote processor should
usually stop whatever processing it is doing to switch to a context
save mode. The OMAP remoteproc driver detects the completion of
the context save by checking the module standby status for the
remoteproc device. It also stops any resources used by the remote
processors like the timers. The timers need to be running only when
when the processor is active and executing, and need to be stopped
otherwise to allow the timer driver to reach low-power states. The
IOMMUs are also suspended by the remoteproc driver, and the suspend
process is completed by putting the remote processors into reset,
after which the Linux kernel can put the domain into further lower
power states as possible.
The resume sequence undoes the operations performed in the PM suspend
callback, by restoring the IOMMUs, starting the timers and finally
releasing the processors from reset. This requires that the remote
processor side OS be able to distinguish a power-resume boot from a
power-on/cold boot, restore the context of its private modules saved
during the suspend phase, and resume executing code from where it
was suspended.
The remote processors should save their context into System RAM (DDR),
as any internal memories are not guaranteed to retain context as it
depends on the lowest power domain that the remote processor device\
is put into. The management of the DDR contents will be managed by
the Linux kernel.
Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: dts: DRA7: Add standby info for IPU & DSPs
Add the data for the "ti,rproc-standby-info" property for all
the DSP and IPU remoteproc processor nodes on DRA7xx family of
SoCs. This data is same for all DRA7 boards, and is required
by the OMAP remoteproc driver to implement suspend/resume for
the IPU & DSP remoteproc devices on DRA7 SoCs.
Signed-off-by: Suman Anna <s-anna@ti.com>
Add the data for the "ti,rproc-standby-info" property for all
the DSP and IPU remoteproc processor nodes on DRA7xx family of
SoCs. This data is same for all DRA7 boards, and is required
by the OMAP remoteproc driver to implement suspend/resume for
the IPU & DSP remoteproc devices on DRA7 SoCs.
Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: dts: OMAP5: Add standby info for IPU and DSP
Add the data for the "ti,rproc-standby-info" property for
the DSP and IPU remoteproc processor nodes, applicable to
all OMAP5 boards. This is required by the OMAP remoteproc
driver to implement suspend/resume for the OMAP5 remoteproc
devices.
Signed-off-by: Suman Anna <s-anna@ti.com>
Add the data for the "ti,rproc-standby-info" property for
the DSP and IPU remoteproc processor nodes, applicable to
all OMAP5 boards. This is required by the OMAP remoteproc
driver to implement suspend/resume for the OMAP5 remoteproc
devices.
Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: dts: OMAP4: Add standby info for IPU and DSP
Add the data for the "ti,rproc-standby-info" property for
the DSP and IPU remoteproc processor nodes. This data is
common to all OMAP4 boards, and is required by the OMAP
remoteproc driver to implement suspend/resume for the OMAP4
remoteproc devices.
Signed-off-by: Suman Anna <s-anna@ti.com>
Add the data for the "ti,rproc-standby-info" property for
the DSP and IPU remoteproc processor nodes. This data is
common to all OMAP4 boards, and is required by the OMAP
remoteproc driver to implement suspend/resume for the OMAP4
remoteproc devices.
Signed-off-by: Suman Anna <s-anna@ti.com>
Documentation: dt: update omap remoteproc binding for suspend
The OMAP remoteproc binding has been updated to add an additional
property, "ti,rproc-standby-info". The property is used to define
the standby register address required by the OMAP remoteproc driver
to check that a remote proessor has entered standby and ready to
be suspended during a system suspend or a runtime auto-suspend of
the corresponding remoteproc device.
Signed-off-by: Suman Anna <s-anna@ti.com>
The OMAP remoteproc binding has been updated to add an additional
property, "ti,rproc-standby-info". The property is used to define
the standby register address required by the OMAP remoteproc driver
to check that a remote proessor has entered standby and ready to
be suspended during a system suspend or a runtime auto-suspend of
the corresponding remoteproc device.
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc/omap: use consistent match data structures for all SoCs
The OMAP remoteproc code currently stores the firmware names directly
in the match data fields for the OMAP4 & OMAP5 SoCs, while a separate
data structure (omap_rproc_fw_data) containing the device name and
firmware name is used for the processors on DRA7xx SoC family.
Switch the OMAP4 and OMAP5 SoCs also to use the same style as DRA7
SoCs for consistency. This also allows to easily add additional data
fields to this structure in the future if needed.
Signed-off-by: Suman Anna <s-anna@ti.com>
The OMAP remoteproc code currently stores the firmware names directly
in the match data fields for the OMAP4 & OMAP5 SoCs, while a separate
data structure (omap_rproc_fw_data) containing the device name and
firmware name is used for the processors on DRA7xx SoC family.
Switch the OMAP4 and OMAP5 SoCs also to use the same style as DRA7
SoCs for consistency. This also allows to easily add additional data
fields to this structure in the future if needed.
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'iommu-linux-3.14.y' of git://git.ti.com/rpmsg/iommu into rproc-linux-3.14.y
Merge in the updated iommu feature branch into remoteproc tree to
pull in the suspend/resume support in the OMAP IOMMU driver. The
following are the main changes:
- improvements in the OMAP iommu to perform the enabling &
disabling of the IOMMU from within the runtime pm callbacks
- two new API that needs to be invoked from the OMAP remoteproc
driver to suspend/resume the IOMMU.
- locked TLB save & restore logic
- add needed pdata quirks to all supported IOMMUs
* 'iommu-linux-3.14.y' of git://git.ti.com/rpmsg/iommu:
iommu/omap: add support for runtime auto suspend/resume
iommu/omap: add logic to save/restore locked TLBs
iommu/omap: introduce new API for suspend/resume
iommu/omap: streamline enable/disable through runtime pm callbacks
ARM: OMAP2+: add pdata-quirks for OMAP3 ISP IOMMU
ARM: OMAP2+: Add iommu pdata-quirks for DRA7 DSP EDMA MMUs
ARM: OMAP2+: plug in device_enable/idle ops for IOMMUs
iommu/omap: add pdata ops for omap_device_enable/idle
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge in the updated iommu feature branch into remoteproc tree to
pull in the suspend/resume support in the OMAP IOMMU driver. The
following are the main changes:
- improvements in the OMAP iommu to perform the enabling &
disabling of the IOMMU from within the runtime pm callbacks
- two new API that needs to be invoked from the OMAP remoteproc
driver to suspend/resume the IOMMU.
- locked TLB save & restore logic
- add needed pdata quirks to all supported IOMMUs
* 'iommu-linux-3.14.y' of git://git.ti.com/rpmsg/iommu:
iommu/omap: add support for runtime auto suspend/resume
iommu/omap: add logic to save/restore locked TLBs
iommu/omap: introduce new API for suspend/resume
iommu/omap: streamline enable/disable through runtime pm callbacks
ARM: OMAP2+: add pdata-quirks for OMAP3 ISP IOMMU
ARM: OMAP2+: Add iommu pdata-quirks for DRA7 DSP EDMA MMUs
ARM: OMAP2+: plug in device_enable/idle ops for IOMMUs
iommu/omap: add pdata ops for omap_device_enable/idle
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'mailbox-linux-3.14.y' of git://git.ti.com/rpmsg/mailbox into rproc-linux-3.14.y
Pull in the updated mailbox feature branch into the remoteproc tree,
this includes the suspend/resume support in the OMAP mailbox driver.
* 'mailbox-linux-3.14.y' of git://git.ti.com/rpmsg/mailbox:
mailbox/omap: check for any unread messages during suspend
mailbox/omap: add support for suspend/resume
mailbox/omap: store mailbox interrupt type in omap_mbox_device
Signed-off-by: Suman Anna <s-anna@ti.com>
Pull in the updated mailbox feature branch into the remoteproc tree,
this includes the suspend/resume support in the OMAP mailbox driver.
* 'mailbox-linux-3.14.y' of git://git.ti.com/rpmsg/mailbox:
mailbox/omap: check for any unread messages during suspend
mailbox/omap: add support for suspend/resume
mailbox/omap: store mailbox interrupt type in omap_mbox_device
Signed-off-by: Suman Anna <s-anna@ti.com>
iommu/omap: add support for runtime auto suspend/resume
This patches adds the support for the OMAP IOMMUs to be suspended
during the auto suspend/resume of the OMAP remoteproc devices. The
remote processors are auto suspended after a certain time of idle
or inactivity period. This is done by extending the suspend/resume
API added with an additional flag to indicate the auto-suspend.
The runtime auto-suspend simply decrements and increments the
runtime usage count of the IOMMU devices and let the context be
saved/restored using the existing runtime pm callbacks.
Signed-off-by: Suman Anna <s-anna@ti.com>
This patches adds the support for the OMAP IOMMUs to be suspended
during the auto suspend/resume of the OMAP remoteproc devices. The
remote processors are auto suspended after a certain time of idle
or inactivity period. This is done by extending the suspend/resume
API added with an additional flag to indicate the auto-suspend.
The runtime auto-suspend simply decrements and increments the
runtime usage count of the IOMMU devices and let the context be
saved/restored using the existing runtime pm callbacks.
Signed-off-by: Suman Anna <s-anna@ti.com>
iommu/omap: add logic to save/restore locked TLBs
The MMUs provide a mechanism to lock TLB entries to avoid
eviction and fetching of frequently used page table entries.
These TLBs lose context when the MMUs are turned OFF. Add the
logic to save and restore these locked TLBS during suspend
and resume respectively. There are no locked TLBs during
initial power ON, and they need not be saved during final
shutdown.
Signed-off-by: Suman Anna <s-anna@ti.com>
The MMUs provide a mechanism to lock TLB entries to avoid
eviction and fetching of frequently used page table entries.
These TLBs lose context when the MMUs are turned OFF. Add the
logic to save and restore these locked TLBS during suspend
and resume respectively. There are no locked TLBs during
initial power ON, and they need not be saved during final
shutdown.
Signed-off-by: Suman Anna <s-anna@ti.com>
iommu/omap: introduce new API for suspend/resume
The MMU registers for the remote processors lose their context
in Open Switch Retention (OSWR) or device OFF modes. Hence, the
context of the IOMMU needs to be saved before it is put to these
lower power state (OSWR/OFF) and restored before it is powered
up to ON again. The IOMMUs need to be active as long as the
client devices that are present behind the IOMMU are active.
This patch introduces two new API, omap_iommu_domain_suspend()
and omap_iommu_domain_resume() to allow the client users of the
IOMMU devices to suspend & resume the IOMMU devices during their
suspend/resume operations. The API leverages the pm runtime
framework API to implement suspend/resume functionality, and
invoke the runtime PM callbacks. The PM runtime_suspend and
runtime_callbacks already are used to enable, configure and
disable the IOMMUs during the attaching and detaching of the
client devices to the IOMMUs, and this code is reused during
suspend/resume.
NOTE:
There are two other existing API, omap_iommu_save_ctx() and
omap_iommu_restore_ctx(). These are left as is to support
suspend/resume of devices on legacy OMAP3 SoC.
Signed-off-by: Suman Anna <s-anna@ti.com>
The MMU registers for the remote processors lose their context
in Open Switch Retention (OSWR) or device OFF modes. Hence, the
context of the IOMMU needs to be saved before it is put to these
lower power state (OSWR/OFF) and restored before it is powered
up to ON again. The IOMMUs need to be active as long as the
client devices that are present behind the IOMMU are active.
This patch introduces two new API, omap_iommu_domain_suspend()
and omap_iommu_domain_resume() to allow the client users of the
IOMMU devices to suspend & resume the IOMMU devices during their
suspend/resume operations. The API leverages the pm runtime
framework API to implement suspend/resume functionality, and
invoke the runtime PM callbacks. The PM runtime_suspend and
runtime_callbacks already are used to enable, configure and
disable the IOMMUs during the attaching and detaching of the
client devices to the IOMMUs, and this code is reused during
suspend/resume.
NOTE:
There are two other existing API, omap_iommu_save_ctx() and
omap_iommu_restore_ctx(). These are left as is to support
suspend/resume of devices on legacy OMAP3 SoC.
Signed-off-by: Suman Anna <s-anna@ti.com>
iommu/omap: streamline enable/disable through runtime pm callbacks
The OMAP IOMMU devices are typically present within the respective
client processor subsystem and have their own dedicated hard-reset
line. Enabling an IOMMU requires the reset line be deasserted and
the clocks be enabled before programming the necessary IOMMU
registers. The IOMMU disable sequence follow the reverse order of
enabling. The OMAP IOMMU driver programs the reset lines through
pdata ops to invoke the omap_device_assert/deassert_hardreset API.
The clocks are managed through the pm_runtime framework, and the
callbacks associated with the device's pm_domain, implemented in
the omap_device layer.
Streamline the enable and disable sequences in the OMAP IOMMU
driver by implementing all the above operations within the
runtime pm callbacks. All the OMAP devices have device pm_domain
callbacks plugged in the omap_device layer for automatic runtime
management of the clocks. Invoking the reset management functions
within the runtime pm callbacks in OMAP IOMMU driver therefore
requires that the default device's pm domain callbacks in the
omap_device layer be reset, as the ordering sequence for managing
the reset lines and clocks from the pm_domain callbacks don't gel
well with the implementation in the IOMMU driver callbacks. The
omap_device_enable/omap_device_idle functions are invoked through
the newly added pdata ops.
Consolidating all the device management sequences within the
runtime pm callbacks allows the driver to easily support both
system suspend/resume and runtime suspend/resume using common
code.
Signed-off-by: Suman Anna <s-anna@ti.com>
The OMAP IOMMU devices are typically present within the respective
client processor subsystem and have their own dedicated hard-reset
line. Enabling an IOMMU requires the reset line be deasserted and
the clocks be enabled before programming the necessary IOMMU
registers. The IOMMU disable sequence follow the reverse order of
enabling. The OMAP IOMMU driver programs the reset lines through
pdata ops to invoke the omap_device_assert/deassert_hardreset API.
The clocks are managed through the pm_runtime framework, and the
callbacks associated with the device's pm_domain, implemented in
the omap_device layer.
Streamline the enable and disable sequences in the OMAP IOMMU
driver by implementing all the above operations within the
runtime pm callbacks. All the OMAP devices have device pm_domain
callbacks plugged in the omap_device layer for automatic runtime
management of the clocks. Invoking the reset management functions
within the runtime pm callbacks in OMAP IOMMU driver therefore
requires that the default device's pm domain callbacks in the
omap_device layer be reset, as the ordering sequence for managing
the reset lines and clocks from the pm_domain callbacks don't gel
well with the implementation in the IOMMU driver callbacks. The
omap_device_enable/omap_device_idle functions are invoked through
the newly added pdata ops.
Consolidating all the device management sequences within the
runtime pm callbacks allows the driver to easily support both
system suspend/resume and runtime suspend/resume using common
code.
Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: OMAP2+: add pdata-quirks for OMAP3 ISP IOMMU
The OMAP3 ISP IOMMU does not have any reset lines, so it didn't
need any pdata. The OMAP IOMMU driver now requires the platform
data ops for device_enable/idle on all the IOMMU devices to be
able to enable/disable the clocks and maintain the reference
count and the omap_hwmod state machine. So, add the iommu pdata
quirks for the OMAP3 ISP IOMMU.
Signed-off-by: Suman Anna <s-anna@ti.com>
The OMAP3 ISP IOMMU does not have any reset lines, so it didn't
need any pdata. The OMAP IOMMU driver now requires the platform
data ops for device_enable/idle on all the IOMMU devices to be
able to enable/disable the clocks and maintain the reference
count and the omap_hwmod state machine. So, add the iommu pdata
quirks for the OMAP3 ISP IOMMU.
Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: OMAP2+: Add iommu pdata-quirks for DRA7 DSP EDMA MMUs
The DSP processor subsystems in DRA7xx have two MMUs, one for the
processor port and another for an EDMA port. Both these MMUs share
a common reset line, and the reset management is done through the
pdata quirks for the MMU associated with the processor port, so the
DSP EDMA MMUs didn't need any pdata ops. The OMAP IOMMU driver now
requires the device_enable/idle platform data ops on all the IOMMU
devices to be able to enable/disable the clocks and maintain the
reference count and the omap_hwmod state machine. So, add the iommu
pdata quirks for the DSP EDMA MMUs.
Signed-off-by: Suman Anna <s-anna@ti.com>
The DSP processor subsystems in DRA7xx have two MMUs, one for the
processor port and another for an EDMA port. Both these MMUs share
a common reset line, and the reset management is done through the
pdata quirks for the MMU associated with the processor port, so the
DSP EDMA MMUs didn't need any pdata ops. The OMAP IOMMU driver now
requires the device_enable/idle platform data ops on all the IOMMU
devices to be able to enable/disable the clocks and maintain the
reference count and the omap_hwmod state machine. So, add the iommu
pdata quirks for the DSP EDMA MMUs.
Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: OMAP2+: plug in device_enable/idle ops for IOMMUs
The OMAP IOMMU driver requires the device_enable/idle platform
data ops on all the IOMMU devices to be able to enable and disable
the clocks. Plug in these pdata ops for all the existing IOMMUs,
both for non-DT devices, and for DT-devices through pdata quirks.
Signed-off-by: Suman Anna <s-anna@ti.com>
The OMAP IOMMU driver requires the device_enable/idle platform
data ops on all the IOMMU devices to be able to enable and disable
the clocks. Plug in these pdata ops for all the existing IOMMUs,
both for non-DT devices, and for DT-devices through pdata quirks.
Signed-off-by: Suman Anna <s-anna@ti.com>
iommu/omap: add pdata ops for omap_device_enable/idle
Add two new platform data ops to allow the OMAP iommu driver to
be able to invoke the omap_device_enable and omap_device_idle
from within the driver. These are being added to streamline the
sequence between managing the hard reset lines and the clocks
during the suspend path, as the default device pm_domain callback
sequences in omap_device layer are not conducive for the OMAP
IOMMU driver.
This could have been done by expanding the existing pdata ops
for reset management (like in the OMAP remoteproc driver), but
this was chosen to avoid adding new code in a separate file in
the mach-omap2 layer.
Signed-off-by: Suman Anna <s-anna@ti.com>
Add two new platform data ops to allow the OMAP iommu driver to
be able to invoke the omap_device_enable and omap_device_idle
from within the driver. These are being added to streamline the
sequence between managing the hard reset lines and the clocks
during the suspend path, as the default device pm_domain callback
sequences in omap_device layer are not conducive for the OMAP
IOMMU driver.
This could have been done by expanding the existing pdata ops
for reset management (like in the OMAP remoteproc driver), but
this was chosen to avoid adding new code in a separate file in
the mach-omap2 layer.
Signed-off-by: Suman Anna <s-anna@ti.com>
mailbox/omap: check for any unread messages during suspend
The OMAP mailbox driver is used by clients to communicate with remote
processors in general. The mailbox clients are expected to have stopped
communicating with these remote processors during a system suspend. The
OMAP mailbox fifos are expected to not have any messages as such. Add a
check for any pending unprocessed messages in the suspend callback, to
detect any communication protocol issues of the mailbox clients. The
system suspend is aborted if any messsages are found.
Signed-off-by: Suman Anna <s-anna@ti.com>
The OMAP mailbox driver is used by clients to communicate with remote
processors in general. The mailbox clients are expected to have stopped
communicating with these remote processors during a system suspend. The
OMAP mailbox fifos are expected to not have any messages as such. Add a
check for any pending unprocessed messages in the suspend callback, to
detect any communication protocol issues of the mailbox clients. The
system suspend is aborted if any messsages are found.
Signed-off-by: Suman Anna <s-anna@ti.com>
mailbox/omap: add support for suspend/resume
Support has been added to the OMAP mailbox driver to allow it
to work across a system suspend/resume. The OMAP mailbox driver
requires only the interrupt configuration registers to be saved
and restored, and this is done in the suspend/resume callbacks.
The registers need to be saved only if there are active clients
at the time of suspend. The enabling and disabling of the mailbox
clocks is done automatically by the omap_device layer.
Signed-off-by: Suman Anna <s-anna@ti.com>
Support has been added to the OMAP mailbox driver to allow it
to work across a system suspend/resume. The OMAP mailbox driver
requires only the interrupt configuration registers to be saved
and restored, and this is done in the suspend/resume callbacks.
The registers need to be saved only if there are active clients
at the time of suspend. The enabling and disabling of the mailbox
clocks is done automatically by the omap_device layer.
Signed-off-by: Suman Anna <s-anna@ti.com>
mailbox/omap: store mailbox interrupt type in omap_mbox_device
The interrupt type used for identifying the layout of the interrupt
configuration registers between OMAP4+ SoCs and older SoCs is stored
only in the sub-mailbox structures for easier access. Store this type
in the the omap_mbox_device structure as well long with the other
global variables. This is being done to facilitate the context save
and restore of appropriate registers during system suspend/resume.
Signed-off-by: Suman Anna <s-anna@ti.com>
The interrupt type used for identifying the layout of the interrupt
configuration registers between OMAP4+ SoCs and older SoCs is stored
only in the sub-mailbox structures for easier access. Store this type
in the the omap_mbox_device structure as well long with the other
global variables. This is being done to facilitate the context save
and restore of appropriate registers during system suspend/resume.
Signed-off-by: Suman Anna <s-anna@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>
Merge branch 'rpmsg-linux-3.14.y' of git://git.ti.com/rpmsg/rpmsg into rpmsg-ti-linux-3.14.y
Pull in fixes in the rpmsg-proto driver to unblock a thread waiting for
data on an errored socket, and return appropriate error on such errored
out Rx sockets.
* 'rpmsg-linux-3.14.y' of git://git.ti.com/rpmsg/rpmsg:
net/rpmsg: unblock reader threads operating on errored sockets
net/rpmsg: return ENOLINK upon Rx on errored sockets
Signed-off-by: Suman Anna <s-anna@ti.com>
Pull in fixes in the rpmsg-proto driver to unblock a thread waiting for
data on an errored socket, and return appropriate error on such errored
out Rx sockets.
* 'rpmsg-linux-3.14.y' of git://git.ti.com/rpmsg/rpmsg:
net/rpmsg: unblock reader threads operating on errored sockets
net/rpmsg: return ENOLINK upon Rx on errored sockets
Signed-off-by: Suman Anna <s-anna@ti.com>
net/rpmsg: unblock reader threads operating on errored sockets
The rpmsg_proto driver is used to provide a socket interface
to userspace under the AF_RPMSG address family, and is used
by the TI IPC MessageQ stack. The typical usage for receiving
messages include a thread blocked on a select() call with
appropriate socket fds, followed by a recvfrom() on the fd
returned/marked ready by select().
The rpmsg_sock_poll() function implements the logic needed
by the select() call, and marks a socket ready only when there
is data to be read currently. Any reader thread waiting on the
select() call to return is currently not unblocked when a remote
processor goes through an error recovery, and can remain blocked
forever as its remote processor peer thread may never send it
another message. Enhance the rpmsg_proto driver so that a waiting
thread can be unblocked by waking it up during the process of
marking the open sockets with the error status RPMSG_ERROR. This
is achieved by using the socket's .sk_error_report() ops, and is
preferred over the .sk_state_change() ops to wakeup only a single
exclusive thread.
Signed-off-by: Suman Anna <s-anna@ti.com>
The rpmsg_proto driver is used to provide a socket interface
to userspace under the AF_RPMSG address family, and is used
by the TI IPC MessageQ stack. The typical usage for receiving
messages include a thread blocked on a select() call with
appropriate socket fds, followed by a recvfrom() on the fd
returned/marked ready by select().
The rpmsg_sock_poll() function implements the logic needed
by the select() call, and marks a socket ready only when there
is data to be read currently. Any reader thread waiting on the
select() call to return is currently not unblocked when a remote
processor goes through an error recovery, and can remain blocked
forever as its remote processor peer thread may never send it
another message. Enhance the rpmsg_proto driver so that a waiting
thread can be unblocked by waking it up during the process of
marking the open sockets with the error status RPMSG_ERROR. This
is achieved by using the socket's .sk_error_report() ops, and is
preferred over the .sk_state_change() ops to wakeup only a single
exclusive thread.
Signed-off-by: Suman Anna <s-anna@ti.com>
net/rpmsg: return ENOLINK upon Rx on errored sockets
The rpmsg_proto driver is used to provide a socket interface to
userspace under the AF_RPMSG address family, and is used by the TI
IPC MessageQ stack. The rpmsg proto driver creates a rpmsg channel
device per remote processor (a Rx socket) for each MessageQ object
through the socket's bind() call. These rpmsg channel devices are
cleaned up normally either when the userspace application closes
them or through the automatic cleanup of the file descriptors when
a process is terminated/closed. These devices can also be cleaned
up by the rpmsg_proto driver as part of the error recovery of a
remote processor, with the parent Rx sockets simply marked with
the error status RPMSG_ERROR.
This error status is not currently being returned to the userspace
in the socket's recvfrom() interface. Fix this by specifically
checking for this error status, and returning an error value of
ENOLINK back to userspace. The ENOLINK error code is used to allow
the userspace to differentiate this terminal error from other errors
on the Rx sockets and take appropriate action. This error code on
Rx sockets serves the same as the error code ESHUTDOWN used for Tx
sockets, and is chosen specifically to have a meaningful strerror
message appropriate to Rx sockets.
Signed-off-by: Suman Anna <s-anna@ti.com>
The rpmsg_proto driver is used to provide a socket interface to
userspace under the AF_RPMSG address family, and is used by the TI
IPC MessageQ stack. The rpmsg proto driver creates a rpmsg channel
device per remote processor (a Rx socket) for each MessageQ object
through the socket's bind() call. These rpmsg channel devices are
cleaned up normally either when the userspace application closes
them or through the automatic cleanup of the file descriptors when
a process is terminated/closed. These devices can also be cleaned
up by the rpmsg_proto driver as part of the error recovery of a
remote processor, with the parent Rx sockets simply marked with
the error status RPMSG_ERROR.
This error status is not currently being returned to the userspace
in the socket's recvfrom() interface. Fix this by specifically
checking for this error status, and returning an error value of
ENOLINK back to userspace. The ENOLINK error code is used to allow
the userspace to differentiate this terminal error from other errors
on the Rx sockets and take appropriate action. This error code on
Rx sockets serves the same as the error code ESHUTDOWN used for Tx
sockets, and is chosen specifically to have a meaningful strerror
message appropriate to Rx sockets.
Signed-off-by: Suman Anna <s-anna@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>
Merge branch 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-3.14.y
Pull in the updated remoteproc feature branch that adds the
Watchdog timers for IPU1 & DSP1 remote processors on DRA7 &
DRA72 EVMs as well as the AM572x Beagle-X15 boards.
* 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc:
ARM: dts: beagle-x15: Add watchdog timers for IPU1 and DSP1
ARM: dts: dra72-evm: Add watchdog timers for IPU1 and DSP1
ARM: dts: dra7-evm: Add watchdog timers for IPU1 and DSP1
Signed-off-by: Suman Anna <s-anna@ti.com>
Pull in the updated remoteproc feature branch that adds the
Watchdog timers for IPU1 & DSP1 remote processors on DRA7 &
DRA72 EVMs as well as the AM572x Beagle-X15 boards.
* 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc:
ARM: dts: beagle-x15: Add watchdog timers for IPU1 and DSP1
ARM: dts: dra72-evm: Add watchdog timers for IPU1 and DSP1
ARM: dts: dra7-evm: Add watchdog timers for IPU1 and DSP1
Signed-off-by: Suman Anna <s-anna@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>
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>
Merge branch 'rpmsg-linux-3.14.y' of git://git.ti.com/rpmsg/rpmsg into rpmsg-ti-linux-3.14.y
Pull in a minor bug fix in rpmsg-rpc driver for incorrectly returning
success in a Tx buffer translation failure path.
* 'rpmsg-linux-3.14.y' of git://git.ti.com/rpmsg/rpmsg:
rpmsg: rpc: fix overwriting of return value in rppc_xlate_buffers
rpmsg: rpc: add a trace on translation errors in reverse path
Signed-off-by: Suman Anna <s-anna@ti.com>
Pull in a minor bug fix in rpmsg-rpc driver for incorrectly returning
success in a Tx buffer translation failure path.
* 'rpmsg-linux-3.14.y' of git://git.ti.com/rpmsg/rpmsg:
rpmsg: rpc: fix overwriting of return value in rppc_xlate_buffers
rpmsg: rpc: add a trace on translation errors in reverse path
Signed-off-by: Suman Anna <s-anna@ti.com>
rpmsg: rpc: fix overwriting of return value in rppc_xlate_buffers
The rppc_xlate_buffers() function is used for translating the host
buffer descriptors to/from the appropriate remote processor pointers
in the message packets being transmitted/received to/from the remote
processor. The function reuses the same loop for unwinding any buffer
translations in case of an error during the Tx path, but happens to
overwrite the initial error value and return the status from the
unwinding operation. This caused the caller to send a buffer with
incorrect/incomplete pointer translations, and creating subsequent
failure paths on the remote processor during the buffer processing.
Fix this by storing away the initial status error and returning it
to the caller. The logic returns only the first error code and not
the values of any subsequent failures.
Reported-by: Sunita Nadampalli <sunitan@ti.com>
Signed-off-by: Sunita Nadampalli <sunitan@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
The rppc_xlate_buffers() function is used for translating the host
buffer descriptors to/from the appropriate remote processor pointers
in the message packets being transmitted/received to/from the remote
processor. The function reuses the same loop for unwinding any buffer
translations in case of an error during the Tx path, but happens to
overwrite the initial error value and return the status from the
unwinding operation. This caused the caller to send a buffer with
incorrect/incomplete pointer translations, and creating subsequent
failure paths on the remote processor during the buffer processing.
Fix this by storing away the initial status error and returning it
to the caller. The logic returns only the first error code and not
the values of any subsequent failures.
Reported-by: Sunita Nadampalli <sunitan@ti.com>
Signed-off-by: Sunita Nadampalli <sunitan@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
rpmsg: rpc: add a trace on translation errors in reverse path
Add a debug trace to print buffer translation errors while processing
the returned function packet. This trace should ideally never be seen
in actual usage, as any translation errors are expected to be caught
during the forward call path to the remote processor.
Signed-off-by: Suman Anna <s-anna@ti.com>
Add a debug trace to print buffer translation errors while processing
the returned function packet. This trace should ideally never be seen
in actual usage, as any translation errors are expected to be caught
during the forward call path to the remote processor.
Signed-off-by: Suman Anna <s-anna@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>
Merge branch 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-3.14.y
Pull in a minor fix for the PRUSS remoteproc driver.
* 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc:
remoteproc/pruss: fix incorrect failure reporting of pru_rproc_kick
Signed-off-by: Suman Anna <s-anna@ti.com>
Pull in a minor fix for the PRUSS remoteproc driver.
* 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc:
remoteproc/pruss: fix incorrect failure reporting of pru_rproc_kick
Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: dts: beagle-x15: Add watchdog timers for IPU1 and DSP1
The watchdog timer information has been added to the IPU1 and DSP1
remote processor device nodes on DRA7 EVM board. The following timers
(same as the timers on DRA7 EVM board) are used as the watchdog timers,
DSP1 : GPT10
IPU1 : GPT7 & GPT8 (one for each Cortex-M4 core)
The MPU-side drivers will use this data to initialize the watchdog
timers, and listen for any watchdog triggers. The BIOS-side code on
IPU2 needs to configure/refresh this timer properly to not throw a
watchdog error.
These timers can be changed or removed as per the system integration
needs, alongside appropriate equivalent changes on the firmware side.
No watchdog timer is added yet for the DSP2 processor.
Signed-off-by: Suman Anna <s-anna@ti.com>
The watchdog timer information has been added to the IPU1 and DSP1
remote processor device nodes on DRA7 EVM board. The following timers
(same as the timers on DRA7 EVM board) are used as the watchdog timers,
DSP1 : GPT10
IPU1 : GPT7 & GPT8 (one for each Cortex-M4 core)
The MPU-side drivers will use this data to initialize the watchdog
timers, and listen for any watchdog triggers. The BIOS-side code on
IPU2 needs to configure/refresh this timer properly to not throw a
watchdog error.
These timers can be changed or removed as per the system integration
needs, alongside appropriate equivalent changes on the firmware side.
No watchdog timer is added yet for the DSP2 processor.
Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: dts: dra72-evm: Add watchdog timers for IPU1 and DSP1
The watchdog timer information has been added to the IPU1 and DSP1
remote processor device nodes on DRA7 EVM board. The following timers
(same as the timers on DRA7 EVM board) are used as the watchdog timers,
DSP1 : GPT10
IPU1 : GPT7 & GPT8 (one for each Cortex-M4 core)
The MPU-side drivers will use this data to initialize the watchdog
timers, and listen for any watchdog triggers. The BIOS-side code on
IPU2 needs to configure/refresh this timer properly to not throw a
watchdog error.
These timers can be changed or removed as per the system integration
needs, alongside appropriate equivalent changes on the firmware side.
Signed-off-by: Suman Anna <s-anna@ti.com>
The watchdog timer information has been added to the IPU1 and DSP1
remote processor device nodes on DRA7 EVM board. The following timers
(same as the timers on DRA7 EVM board) are used as the watchdog timers,
DSP1 : GPT10
IPU1 : GPT7 & GPT8 (one for each Cortex-M4 core)
The MPU-side drivers will use this data to initialize the watchdog
timers, and listen for any watchdog triggers. The BIOS-side code on
IPU2 needs to configure/refresh this timer properly to not throw a
watchdog error.
These timers can be changed or removed as per the system integration
needs, alongside appropriate equivalent changes on the firmware side.
Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: dts: dra7-evm: Add watchdog timers for IPU1 and DSP1
The watchdog timer information has been added to the IPU1 and DSP1
remote processor device nodes on DRA7 EVM board. The following timers
are used as the watchdog timers,
DSP1 : GPT10
IPU1 : GPT7 & GPT8 (one for each Cortex-M4 core)
The MPU-side drivers will use this data to initialize the watchdog
timers, and listen for any watchdog triggers. The BIOS-side code on
IPU2 needs to configure/refresh this timer properly to not throw a
watchdog error.
These timers can be changed or removed as per the system integration
needs, alongside appropriate equivalent changes on the firmware side.
No watchdog timer is added yet for the DSP2 processor.
Signed-off-by: Suman Anna <s-anna@ti.com>
The watchdog timer information has been added to the IPU1 and DSP1
remote processor device nodes on DRA7 EVM board. The following timers
are used as the watchdog timers,
DSP1 : GPT10
IPU1 : GPT7 & GPT8 (one for each Cortex-M4 core)
The MPU-side drivers will use this data to initialize the watchdog
timers, and listen for any watchdog triggers. The BIOS-side code on
IPU2 needs to configure/refresh this timer properly to not throw a
watchdog error.
These timers can be changed or removed as per the system integration
needs, alongside appropriate equivalent changes on the firmware side.
No watchdog timer is added yet for the DSP2 processor.
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc/pruss: fix incorrect failure reporting of pru_rproc_kick
The mbox_send_message() API returns a zero or a positive token id on
success, and a negative value on failure. The pru_rproc_kick() function
is incorrectly checking for a non-zero return value to report a failure,
even though the mailbox message has been transmitted successfully, so
fix the error condition check properly.
Signed-off-by: Jason Reeder <jreeder@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
The mbox_send_message() API returns a zero or a positive token id on
success, and a negative value on failure. The pru_rproc_kick() function
is incorrectly checking for a non-zero return value to report a failure,
even though the mailbox message has been transmitted successfully, so
fix the error condition check properly.
Signed-off-by: Jason Reeder <jreeder@ti.com>
Signed-off-by: Suman Anna <s-anna@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>