5 years agoMerge branch 'rproc-linux-4.9.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg... rpmsg-ti-linux-4.9.y
Merge branch 'rproc-linux-4.9.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-4.9.y
Pull in the updated remoteproc feature branch that pulls in couple of
fixes - an OMAP IOMMU patch fixing the improper cache flushing of L2
MMU entries triggering false MMU faults, a patch in remoteproc core
resolving kernel crashes in couple of code paths affecting remoteprocs
using CMA pools from HighMem, and a patch in remoteproc core fixing
cleanups on firmware version section processing.
* 'rproc-linux-4.9.y' of git://git.ti.com/rpmsg/remoteproc:
remoteproc: fix cleanup on firmware version processing failures
remoteproc: fix kernel crashes for rprocs using HighMem CMA pools
iommu/omap: Fix cache flushes on L2 page table entries
Signed-off-by: Suman Anna <s-anna@ti.com>
Pull in the updated remoteproc feature branch that pulls in couple of
fixes - an OMAP IOMMU patch fixing the improper cache flushing of L2
MMU entries triggering false MMU faults, a patch in remoteproc core
resolving kernel crashes in couple of code paths affecting remoteprocs
using CMA pools from HighMem, and a patch in remoteproc core fixing
cleanups on firmware version section processing.
* 'rproc-linux-4.9.y' of git://git.ti.com/rpmsg/remoteproc:
remoteproc: fix cleanup on firmware version processing failures
remoteproc: fix kernel crashes for rprocs using HighMem CMA pools
iommu/omap: Fix cache flushes on L2 page table entries
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc: fix cleanup on firmware version processing failures
The commit 50f7304d728f ("remoteproc: add debugfs entry to print the
firmware version info") has added support for printing an optional
firmware version info retrieved from a firmware image's .version
section, but has couple of issues related to cleanup as below:
- The processed resources are not cleaned up upon any failure in
processing of this version info. Fix this by using the correct
goto label in code.
- The fw_version field is not reset in the resource cleanup function
to fix a potential double free issue on a stale pointer - this is
possible with consecutive boots of a processor with the first
firmware containing a version info and the second firmware none.
Fix this by resetting the pointer to NULL.
Fixes: 50f7304d728f ("remoteproc: add debugfs entry to print the firmware version info")
Signed-off-by: Suman Anna <s-anna@ti.com>
The commit 50f7304d728f ("remoteproc: add debugfs entry to print the
firmware version info") has added support for printing an optional
firmware version info retrieved from a firmware image's .version
section, but has couple of issues related to cleanup as below:
- The processed resources are not cleaned up upon any failure in
processing of this version info. Fix this by using the correct
goto label in code.
- The fw_version field is not reset in the resource cleanup function
to fix a potential double free issue on a stale pointer - this is
possible with consecutive boots of a processor with the first
firmware containing a version info and the second firmware none.
Fix this by resetting the pointer to NULL.
Fixes: 50f7304d728f ("remoteproc: add debugfs entry to print the firmware version info")
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc: fix kernel crashes for rprocs using HighMem CMA pools
The remoteproc core driver uses a table_ptr state variable for
handling and processing various resources and updating certain
fields in the resource table during the loading phase. This ptr
is pointing at one of two copies during the life cycle of a remote
processor. An initial cached table (allocated in linear kernel
memory and copied during firmware parsing step) is used until
the firmware segments are loaded, and thereafter a loaded table
reflecting the memory in one of the loaded segments where the
table is present just before releasing the processor from reset.
The loaded segments are allocated using the DMA API and can come
from the remoteproc device's CMA or carveout pools, and so can
be present anywhere in memory.
The current state machine logic has couple of use after free errors
in certain code paths resulting in kernel crashes:
- Failure paths in rproc_fw_boot() after the table_ptr is updated
to point to the loaded table
- Shutdown paths either during a graceful shutdown (using sysfs
stop or unbind opertions) or during a shutdown as part of the
error recovery when the loaded segments are freed and the
table_ptr still pointing to a memory in the loaded segment.
The kernel crashes were a result of freeing the vdevs using memory
that has already been freed. These use after free issues were exposed
specifically only when the memory segments are allocated from CMA
pools in HighMem, as they are mapped and unmapped at runtime into
kernel memory. The kernel mappings are linear (one-to-one and always
present) with memory segments allocated from CMA pools in LowMem,
and runtime mapped in vmalloc space linearly the first time permanently
for Carveouts irrespective of LowMem or HighMem, so the issues were
masked. Fix these by properly resetting the table_ptr variable back
to the cached table at appropriate places.
The common crash signature looks (only a snippet) as follows:
Unable to handle kernel paging request at virtual address f3acf070
pgd = ec83c000
[f3acf070] *pgd=acaa9811, *pte=00000000, *ppte=00000000
...
PC is at rproc_free_vring+0x168/0x1e0 [remoteproc]
...
Backtrace:
[<bf001368>] (rproc_free_vring [remoteproc]) from [<bf001854>] (rproc_vdev_release+0x24/0x74 [remoteproc])
r10:ed336800 r9:e0600000 r8:00100000 r7:f4013000 r6:ee29d810 r5:ed3369f8
r4:ed336400
[<bf001830>] (rproc_vdev_release [remoteproc]) from [<bf001cec>] (rproc_resource_cleanup+0x448/0x57c [remoteproc])
r5:ed3369f8 r4:ed336a10
[<bf0018a4>] (rproc_resource_cleanup [remoteproc]) from [<bf002478>] (rproc_shutdown+0x9c/0x154 [remoteproc])
[gdaubar@harris.com: reported issue with graceful shutdown]
Reported-by: Gerard Daubar <gdaubar@harris.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
The remoteproc core driver uses a table_ptr state variable for
handling and processing various resources and updating certain
fields in the resource table during the loading phase. This ptr
is pointing at one of two copies during the life cycle of a remote
processor. An initial cached table (allocated in linear kernel
memory and copied during firmware parsing step) is used until
the firmware segments are loaded, and thereafter a loaded table
reflecting the memory in one of the loaded segments where the
table is present just before releasing the processor from reset.
The loaded segments are allocated using the DMA API and can come
from the remoteproc device's CMA or carveout pools, and so can
be present anywhere in memory.
The current state machine logic has couple of use after free errors
in certain code paths resulting in kernel crashes:
- Failure paths in rproc_fw_boot() after the table_ptr is updated
to point to the loaded table
- Shutdown paths either during a graceful shutdown (using sysfs
stop or unbind opertions) or during a shutdown as part of the
error recovery when the loaded segments are freed and the
table_ptr still pointing to a memory in the loaded segment.
The kernel crashes were a result of freeing the vdevs using memory
that has already been freed. These use after free issues were exposed
specifically only when the memory segments are allocated from CMA
pools in HighMem, as they are mapped and unmapped at runtime into
kernel memory. The kernel mappings are linear (one-to-one and always
present) with memory segments allocated from CMA pools in LowMem,
and runtime mapped in vmalloc space linearly the first time permanently
for Carveouts irrespective of LowMem or HighMem, so the issues were
masked. Fix these by properly resetting the table_ptr variable back
to the cached table at appropriate places.
The common crash signature looks (only a snippet) as follows:
Unable to handle kernel paging request at virtual address f3acf070
pgd = ec83c000
[f3acf070] *pgd=acaa9811, *pte=00000000, *ppte=00000000
...
PC is at rproc_free_vring+0x168/0x1e0 [remoteproc]
...
Backtrace:
[<bf001368>] (rproc_free_vring [remoteproc]) from [<bf001854>] (rproc_vdev_release+0x24/0x74 [remoteproc])
r10:ed336800 r9:e0600000 r8:00100000 r7:f4013000 r6:ee29d810 r5:ed3369f8
r4:ed336400
[<bf001830>] (rproc_vdev_release [remoteproc]) from [<bf001cec>] (rproc_resource_cleanup+0x448/0x57c [remoteproc])
r5:ed3369f8 r4:ed336a10
[<bf0018a4>] (rproc_resource_cleanup [remoteproc]) from [<bf002478>] (rproc_shutdown+0x9c/0x154 [remoteproc])
[gdaubar@harris.com: reported issue with graceful shutdown]
Reported-by: Gerard Daubar <gdaubar@harris.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'iommu-linux-4.9.y' of git://git.ti.com/rpmsg/iommu into rproc-linux-4.9.y
Pull in the updated iommu feature branch into the remoteproc feature
branch. This merge pulls in a fix for a streaming DMA API cache flushing
bug of the L2 page table entries.
* 'iommu-linux-4.9.y' of git://git.ti.com/rpmsg/iommu:
iommu/omap: Fix cache flushes on L2 page table entries
Signed-off-by: Suman Anna <s-anna@ti.com>
Pull in the updated iommu feature branch into the remoteproc feature
branch. This merge pulls in a fix for a streaming DMA API cache flushing
bug of the L2 page table entries.
* 'iommu-linux-4.9.y' of git://git.ti.com/rpmsg/iommu:
iommu/omap: Fix cache flushes on L2 page table entries
Signed-off-by: Suman Anna <s-anna@ti.com>
iommu/omap: Fix cache flushes on L2 page table entries
The flush_iopte_range() function is used for flushing the programmed
L1/L2 page table entries from the cache. This function takes in a base
dma address, an offset from that base, and number of entries to be used
for computing the address and size to be flushed.
The base address used for DMA operations on the second-level table did
incorrectly include the offset for the table entry. The L2 page table
entry offset was then added again to the base address resulting in
flushing the cache for the wrong memory locations. This resulted in
occasional MMU faults getting triggered (even though the entries
themselves are programmed correctly) when the corresponding address
is accessed on the remote processor side when the hardware page table
walk is performed and fetching an incorrect translation.
Operations on the L1 table are not affected.
Fix this by changing base address to point to the beginning of the L2
page directory address.
Fixes: a313fc4938b8 ("iommu/omap: Use DMA-API for performing cache flushes")
Acked-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Ralf Goebel <ralf.goebel@imago-technologies.com>
[s-anna@ti.com: backport linux-omap patchwork id '10552411', revise description]
Signed-off-by: Suman Anna <s-anna@ti.com>
The flush_iopte_range() function is used for flushing the programmed
L1/L2 page table entries from the cache. This function takes in a base
dma address, an offset from that base, and number of entries to be used
for computing the address and size to be flushed.
The base address used for DMA operations on the second-level table did
incorrectly include the offset for the table entry. The L2 page table
entry offset was then added again to the base address resulting in
flushing the cache for the wrong memory locations. This resulted in
occasional MMU faults getting triggered (even though the entries
themselves are programmed correctly) when the corresponding address
is accessed on the remote processor side when the hardware page table
walk is performed and fetching an incorrect translation.
Operations on the L1 table are not affected.
Fix this by changing base address to point to the beginning of the L2
page directory address.
Fixes: a313fc4938b8 ("iommu/omap: Use DMA-API for performing cache flushes")
Acked-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Ralf Goebel <ralf.goebel@imago-technologies.com>
[s-anna@ti.com: backport linux-omap patchwork id '10552411', revise description]
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'rpmsg-linux-4.9.y' of git://git.ti.com/rpmsg/rpmsg into rpmsg-ti-linux-4.9.y
Pull in the updated rpmsg base feature branch that includes a minor fix
in the rpmsg rpc driver for a minor bug exposed with ONFIG_PROVE_RCU
enabled.
* 'rpmsg-linux-4.9.y' of git://git.ti.com/rpmsg/rpmsg:
rpmsg: rpc: fix suspicious rcu_dereference_check() usage
Signed-off-by: Suman Anna <s-anna@ti.com>
Pull in the updated rpmsg base feature branch that includes a minor fix
in the rpmsg rpc driver for a minor bug exposed with ONFIG_PROVE_RCU
enabled.
* 'rpmsg-linux-4.9.y' of git://git.ti.com/rpmsg/rpmsg:
rpmsg: rpc: fix suspicious rcu_dereference_check() usage
Signed-off-by: Suman Anna <s-anna@ti.com>
rpmsg: rpc: fix suspicious rcu_dereference_check() usage
The rpmsg rpc code uses fcheck() to verify that the passed-in
dma-buf file descriptors during buffer pre-registration or
unregistration are valid. The caller must hold a rcu though
as part of the lock-free semantics of the file descriptor
management. Add the appropriate rcu locking to fix the following
warning thrown when CONFIG_PROVE_RCU is enabled:
===============================
[ INFO: suspicious RCU usage. ]
4.9.54-02664-g557222289973 #410 Not tainted
-------------------------------
./include/linux/fdtable.h:93 suspicious rcu_dereference_check() usage!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
no locks held by multiqueue0:src/1066.
stack backtrace:
CPU: 0 PID: 1066 Comm: multiqueue0:src Not tainted 4.9.54-02664-g557222289973 #410
Hardware name: Generic DRA74X (Flattened Device Tree)
[<c011144c>] (unwind_backtrace) from [<c010c4f8>] (show_stack+0x10/0x14)
[<c010c4f8>] (show_stack) from [<c0418fc0>] (dump_stack+0x98/0xc4)
[<c0418fc0>] (dump_stack) from [<bf2e4e70>] (rppc_ioctl+0x514/0x730 [rpmsg_rpc])
[<bf2e4e70>] (rppc_ioctl [rpmsg_rpc]) from [<c026f158>] (do_vfs_ioctl+0xa0/0xa10)
[<c026f158>] (do_vfs_ioctl) from [<c026fafc>] (SyS_ioctl+0x34/0x5c)
[<c026fafc>] (SyS_ioctl) from [<c0108240>] (ret_fast_syscall+0x0/0x1c)
Redistribute latency...
The fcheck() calls can perhaps be removed completely and relying on
the implicit checking during the dma_buf_get() calls, but is retained
to provide a preliminary check of the file descriptors.
Fixes: 06302fc65e3d ("rpmsg: rpc: introduce a new rpmsg_rpc driver")
Signed-off-by: Suman Anna <s-anna@ti.com>
The rpmsg rpc code uses fcheck() to verify that the passed-in
dma-buf file descriptors during buffer pre-registration or
unregistration are valid. The caller must hold a rcu though
as part of the lock-free semantics of the file descriptor
management. Add the appropriate rcu locking to fix the following
warning thrown when CONFIG_PROVE_RCU is enabled:
===============================
[ INFO: suspicious RCU usage. ]
4.9.54-02664-g557222289973 #410 Not tainted
-------------------------------
./include/linux/fdtable.h:93 suspicious rcu_dereference_check() usage!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
no locks held by multiqueue0:src/1066.
stack backtrace:
CPU: 0 PID: 1066 Comm: multiqueue0:src Not tainted 4.9.54-02664-g557222289973 #410
Hardware name: Generic DRA74X (Flattened Device Tree)
[<c011144c>] (unwind_backtrace) from [<c010c4f8>] (show_stack+0x10/0x14)
[<c010c4f8>] (show_stack) from [<c0418fc0>] (dump_stack+0x98/0xc4)
[<c0418fc0>] (dump_stack) from [<bf2e4e70>] (rppc_ioctl+0x514/0x730 [rpmsg_rpc])
[<bf2e4e70>] (rppc_ioctl [rpmsg_rpc]) from [<c026f158>] (do_vfs_ioctl+0xa0/0xa10)
[<c026f158>] (do_vfs_ioctl) from [<c026fafc>] (SyS_ioctl+0x34/0x5c)
[<c026fafc>] (SyS_ioctl) from [<c0108240>] (ret_fast_syscall+0x0/0x1c)
Redistribute latency...
The fcheck() calls can perhaps be removed completely and relying on
the implicit checking during the dma_buf_get() calls, but is retained
to provide a preliminary check of the file descriptors.
Fixes: 06302fc65e3d ("rpmsg: rpc: introduce a new rpmsg_rpc driver")
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'rproc-linux-4.9.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-4.9.y
Pull in the updated remoteproc feature branch that adds support for
loading into the L1P and L1D memories on DRA7 DSPs, and the updated
OMAP IOMMU driver that leverages DMA API for flushing the MMU Page
Table Entries instead of ARM-specific cache functions.
* 'rproc-linux-4.9.y' of git://git.ti.com/rpmsg/remoteproc:
iommu/omap: Use DMA-API for performing cache flushes
Revert "HACK: iommu/omap: flush page table entries from L2 cache"
Revert "TEMP: iommu/omap: fix range for cache flush operations"
remoteproc/omap: add support for parsing DRA7 DSP L1D and L1P memories
Signed-off-by: Suman Anna <s-anna@ti.com>
Pull in the updated remoteproc feature branch that adds support for
loading into the L1P and L1D memories on DRA7 DSPs, and the updated
OMAP IOMMU driver that leverages DMA API for flushing the MMU Page
Table Entries instead of ARM-specific cache functions.
* 'rproc-linux-4.9.y' of git://git.ti.com/rpmsg/remoteproc:
iommu/omap: Use DMA-API for performing cache flushes
Revert "HACK: iommu/omap: flush page table entries from L2 cache"
Revert "TEMP: iommu/omap: fix range for cache flush operations"
remoteproc/omap: add support for parsing DRA7 DSP L1D and L1P memories
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'iommu-linux-4.9.y' of git://git.ti.com/rpmsg/iommu into rproc-linux-4.9.y
Pull in the updated iommu feature branch into the remoteproc feature
branch. This merge pulls in the clean upstreamable solution that
replaces the existing ARM-specific cache functions with the streaming
DMA API for flushing the L1 and L2 page table entries.
* 'iommu-linux-4.9.y' of git://git.ti.com/rpmsg/iommu:
iommu/omap: Use DMA-API for performing cache flushes
Revert "HACK: iommu/omap: flush page table entries from L2 cache"
Revert "TEMP: iommu/omap: fix range for cache flush operations"
Signed-off-by: Suman Anna <s-anna@ti.com>
Pull in the updated iommu feature branch into the remoteproc feature
branch. This merge pulls in the clean upstreamable solution that
replaces the existing ARM-specific cache functions with the streaming
DMA API for flushing the L1 and L2 page table entries.
* 'iommu-linux-4.9.y' of git://git.ti.com/rpmsg/iommu:
iommu/omap: Use DMA-API for performing cache flushes
Revert "HACK: iommu/omap: flush page table entries from L2 cache"
Revert "TEMP: iommu/omap: fix range for cache flush operations"
Signed-off-by: Suman Anna <s-anna@ti.com>
iommu/omap: Use DMA-API for performing cache flushes
The OMAP IOMMU driver was using ARM assembly code directly for
flushing the MMU page table entries from the caches. This caused
MMU faults on OMAP4 (Cortex-A9 based SoCs) as L2 caches were not
handled due to the presence of a PL310 L2 Cache Controller. These
faults were however not seen on OMAP5/DRA7 SoCs (Cortex-A15 based
SoCs).
The OMAP IOMMU driver is adapted to use the DMA Streaming API
instead now to flush the page table/directory table entries from
the CPU caches. This ensures that the devices always see the
updated page table entries. The outer caches are now addressed
automatically with the usage of the DMA API.
[j-albarran@ti.com: backport commit 'bfee0cf0ee1d' staged for v4.14]
Signed-off-by: Josue Albarran <j-albarran@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
The OMAP IOMMU driver was using ARM assembly code directly for
flushing the MMU page table entries from the caches. This caused
MMU faults on OMAP4 (Cortex-A9 based SoCs) as L2 caches were not
handled due to the presence of a PL310 L2 Cache Controller. These
faults were however not seen on OMAP5/DRA7 SoCs (Cortex-A15 based
SoCs).
The OMAP IOMMU driver is adapted to use the DMA Streaming API
instead now to flush the page table/directory table entries from
the CPU caches. This ensures that the devices always see the
updated page table entries. The outer caches are now addressed
automatically with the usage of the DMA API.
[j-albarran@ti.com: backport commit 'bfee0cf0ee1d' staged for v4.14]
Signed-off-by: Josue Albarran <j-albarran@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Revert "HACK: iommu/omap: flush page table entries from L2 cache"
This reverts commit 59116088bdb373c13a97f5a4c7ee1418d7095d5d.
Undo the changes added to the OMAP IOMMU driver in commit 59116088bdb3
("HACK: iommu/omap: flush page table entries from L2 cache"), which added
the proper outer cache operations to flush the page table entries from
L2 cache. L2 cache was not being flushed before and this resulted in
MMU faults on the DSP and IPU processors on OMAP4.
This reverts the temporary commit in preparation of a proper fix with the
DMA Streaming API. The OMAP IOMMU driver will use the DMA Streaming API
to achieve cache functionality by flushing the page table/directory table
entries from the CPU caches. This operation must be done so that the
contents of the cache is written back to main memory and the device is
then able to read it.
Signed-off-by: Josue Albarran <j-albarran@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
This reverts commit 59116088bdb373c13a97f5a4c7ee1418d7095d5d.
Undo the changes added to the OMAP IOMMU driver in commit 59116088bdb3
("HACK: iommu/omap: flush page table entries from L2 cache"), which added
the proper outer cache operations to flush the page table entries from
L2 cache. L2 cache was not being flushed before and this resulted in
MMU faults on the DSP and IPU processors on OMAP4.
This reverts the temporary commit in preparation of a proper fix with the
DMA Streaming API. The OMAP IOMMU driver will use the DMA Streaming API
to achieve cache functionality by flushing the page table/directory table
entries from the CPU caches. This operation must be done so that the
contents of the cache is written back to main memory and the device is
then able to read it.
Signed-off-by: Josue Albarran <j-albarran@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Revert "TEMP: iommu/omap: fix range for cache flush operations"
This reverts commit 4424597becb984d6e38ee28cf642031bad4b4a1c.
Undo the changes added to the OMAP IOMMU driver in commit 4424597becb9
("TEMP: iommu/omap: fix range for cache flush operations"), which fixed
an issue with some of the pgd and pte entries not getting flushed
completely due to incorrect ranges being passed into the cache flush
operations. This was needed with the changes added in commit 59116088bdb3
("HACK: iommu/omap: flush page table entries from L2 cache") to flush
the page table entries from the L2 cache.
This reverts the temporary commit in preparation of a proper fix with the
DMA Streaming API. The OMAP IOMMU driver will use the DMA Streaming API
to achieve cache functionality by flushing the page table/directory table
entries from the CPU caches. This operation must be done so that the
contents of the cache is written back to main memory and the device is
then able to read it.
Signed-off-by: Josue Albarran <j-albarran@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
This reverts commit 4424597becb984d6e38ee28cf642031bad4b4a1c.
Undo the changes added to the OMAP IOMMU driver in commit 4424597becb9
("TEMP: iommu/omap: fix range for cache flush operations"), which fixed
an issue with some of the pgd and pte entries not getting flushed
completely due to incorrect ranges being passed into the cache flush
operations. This was needed with the changes added in commit 59116088bdb3
("HACK: iommu/omap: flush page table entries from L2 cache") to flush
the page table entries from the L2 cache.
This reverts the temporary commit in preparation of a proper fix with the
DMA Streaming API. The OMAP IOMMU driver will use the DMA Streaming API
to achieve cache functionality by flushing the page table/directory table
entries from the CPU caches. This operation must be done so that the
contents of the cache is written back to main memory and the device is
then able to read it.
Signed-off-by: Josue Albarran <j-albarran@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'rpmsg-linux-4.9.y' of git://git.ti.com/rpmsg/rpmsg into rpmsg-ti-linux-4.9.y
Pull in the updated rpmsg base feature branch that includes a fix in
the rpmsg proto driver for a kernel crash that occurs when an unexpected
message is sent to the probed device's endpoint.
* 'rpmsg-linux-4.9.y' of git://git.ti.com/rpmsg/rpmsg:
net/rpmsg: fix kernel crash for Rx messages on probed devices
Signed-off-by: Suman Anna <s-anna@ti.com>
Pull in the updated rpmsg base feature branch that includes a fix in
the rpmsg proto driver for a kernel crash that occurs when an unexpected
message is sent to the probed device's endpoint.
* 'rpmsg-linux-4.9.y' of git://git.ti.com/rpmsg/rpmsg:
net/rpmsg: fix kernel crash for Rx messages on probed devices
Signed-off-by: Suman Anna <s-anna@ti.com>
net/rpmsg: fix kernel crash for Rx messages on probed devices
The rpmsg proto devices that are probed do create an embedded rpmsg
endpoint for receiving messages, but are not really designed to
process any such received messages. The endpoint's callback field
was repurposed to store and maintain a list of the rpmsg sockets
bound to this device. This list is used to mark the linked sockets
with appropriate status for achieving error recovery functionality.
Any messages sent to this endpoint are reusing the function designed
to receive messages for sockets and results in a kernel crash due
to incorrect interpretation of the endpoint's private data field.
Fix this by reusing/renaming the current callback function to use
strictly for endpoints associated with userspace create rpmsg
sockets, and a different callback function to print a warning
trace about unexpected Rx message.
Reported-by: Sam Nelson <samnelson@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
The rpmsg proto devices that are probed do create an embedded rpmsg
endpoint for receiving messages, but are not really designed to
process any such received messages. The endpoint's callback field
was repurposed to store and maintain a list of the rpmsg sockets
bound to this device. This list is used to mark the linked sockets
with appropriate status for achieving error recovery functionality.
Any messages sent to this endpoint are reusing the function designed
to receive messages for sockets and results in a kernel crash due
to incorrect interpretation of the endpoint's private data field.
Fix this by reusing/renaming the current callback function to use
strictly for endpoints associated with userspace create rpmsg
sockets, and a different callback function to print a warning
trace about unexpected Rx message.
Reported-by: Sam Nelson <samnelson@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc/omap: add support for parsing DRA7 DSP L1D and L1P memories
The OMAP remoteproc driver currently parses only the L2 RAM memories
for all IPU devices on OMAP4+ SoCs and DSP devices on DRA7 SoCs. The
DSPs on DRA7 SoCs also have two additional RAMs at L1 level - L1P and
L1D. The internal memory parsing logic has been enhanced to look for
these memories now so that the remoteproc driver can support loading
into these regions for a small subset of firmware images requiring as
such. This support was left out intentionally before as the most
common usage would be to use these programmable RAMs as L1 Caches.
Signed-off-by: Suman Anna <s-anna@ti.com>
The OMAP remoteproc driver currently parses only the L2 RAM memories
for all IPU devices on OMAP4+ SoCs and DSP devices on DRA7 SoCs. The
DSPs on DRA7 SoCs also have two additional RAMs at L1 level - L1P and
L1D. The internal memory parsing logic has been enhanced to look for
these memories now so that the remoteproc driver can support loading
into these regions for a small subset of firmware images requiring as
such. This support was left out intentionally before as the most
common usage would be to use these programmable RAMs as L1 Caches.
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'rproc-linux-4.9.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-4.9.y
Pull in the updated remoteproc feature branch that fixes couple of
minor issues with OMAP remoteproc, Keystone remoteproc and PRU
remoteproc drivers. The OMAP remoteproc driver patch includes a
boot address alignment check, while the remaining patches include
updates to the remoteproc core to fix a state-machine issue with
Keystone remoteproc driver usage in userspace-driven MPM loader
mode, and a memory leak with no auto-boot remoteprocs currently
seen with PRU remoteproc driver.
* 'rproc-linux-4.9.y' of git://git.ti.com/rpmsg/remoteproc:
remoteproc: fix unbalanced boot with sysfs for no auto-boot rprocs
remoteproc: deny sysfs operations with MPM userspace loader
remoteproc/omap: add a sanity check for DSP boot address alignment
Signed-off-by: Suman Anna <s-anna@ti.com>
Pull in the updated remoteproc feature branch that fixes couple of
minor issues with OMAP remoteproc, Keystone remoteproc and PRU
remoteproc drivers. The OMAP remoteproc driver patch includes a
boot address alignment check, while the remaining patches include
updates to the remoteproc core to fix a state-machine issue with
Keystone remoteproc driver usage in userspace-driven MPM loader
mode, and a memory leak with no auto-boot remoteprocs currently
seen with PRU remoteproc driver.
* 'rproc-linux-4.9.y' of git://git.ti.com/rpmsg/remoteproc:
remoteproc: fix unbalanced boot with sysfs for no auto-boot rprocs
remoteproc: deny sysfs operations with MPM userspace loader
remoteproc/omap: add a sanity check for DSP boot address alignment
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc: fix unbalanced boot with sysfs for no auto-boot rprocs
The remoteproc core performs automatic boot and shutdown of a remote
processor during rproc_add() and rproc_del() for remote processors
supporting 'auto-boot'. The remoteproc devices not using 'auto-boot'
require either a remoteproc client driver or an userspace client to
use the sysfs 'state' variable to perform the boot and shutdown. The
in-kernel client drivers hold the corresponding remoteproc driver
module's reference count when they acquire a rproc handle through
the rproc_get_by_phandle() API, but there is no such support for
userspace applications performing the boot through sysfs interface.
The shutdown of a remoteproc upon removing a remoteproc platform
driver is automatic only with 'auto-boot' and this can cause a
remoteproc with no auto-boot to stay powered on and never freed
up if booted using the sysfs interface without a matching stop,
and when the remoteproc driver module is removed or unbound from
the device. This will result in a memory leak as well as the
corresponding remoteproc ida being never deallocated. Fix this
by holding a module reference count for the remoteproc's driver
during a sysfs 'start' and releasing it during the sysfs 'stop'
operation.
This issue is currently seen with PRU remoteproc drivers for
PRUs booting non-Ethernet applications.
Signed-off-by: Suman Anna <s-anna@ti.com>
The remoteproc core performs automatic boot and shutdown of a remote
processor during rproc_add() and rproc_del() for remote processors
supporting 'auto-boot'. The remoteproc devices not using 'auto-boot'
require either a remoteproc client driver or an userspace client to
use the sysfs 'state' variable to perform the boot and shutdown. The
in-kernel client drivers hold the corresponding remoteproc driver
module's reference count when they acquire a rproc handle through
the rproc_get_by_phandle() API, but there is no such support for
userspace applications performing the boot through sysfs interface.
The shutdown of a remoteproc upon removing a remoteproc platform
driver is automatic only with 'auto-boot' and this can cause a
remoteproc with no auto-boot to stay powered on and never freed
up if booted using the sysfs interface without a matching stop,
and when the remoteproc driver module is removed or unbound from
the device. This will result in a memory leak as well as the
corresponding remoteproc ida being never deallocated. Fix this
by holding a module reference count for the remoteproc's driver
during a sysfs 'start' and releasing it during the sysfs 'stop'
operation.
This issue is currently seen with PRU remoteproc drivers for
PRUs booting non-Ethernet applications.
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc: deny sysfs operations with MPM userspace loader
The remoteproc framework provides sysfs interfaces for changing
the firmware name and for starting/stopping a remote processor
through the sysfs files 'state' and 'firmware'. The Keystone
remoteproc driver also supports a custom userspace-driven load
and boot mechanism called Multi Proc Manager (MPM) through a
char device and custom ioctls supporting a userspace daemon.
The sysfs interface does conflict with the MPM state-machine and
the corresponding state variables within the keystone remoteproc
driver. So, add a check to the sysfs interface operations to fix
this by obstructing any changes to the remoteproc state-machine
when a remote processor is configured for supporting the userspace
loader/boot mechanism.
Signed-off-by: Suman Anna <s-anna@ti.com>
The remoteproc framework provides sysfs interfaces for changing
the firmware name and for starting/stopping a remote processor
through the sysfs files 'state' and 'firmware'. The Keystone
remoteproc driver also supports a custom userspace-driven load
and boot mechanism called Multi Proc Manager (MPM) through a
char device and custom ioctls supporting a userspace daemon.
The sysfs interface does conflict with the MPM state-machine and
the corresponding state variables within the keystone remoteproc
driver. So, add a check to the sysfs interface operations to fix
this by obstructing any changes to the remoteproc state-machine
when a remote processor is configured for supporting the userspace
loader/boot mechanism.
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc/omap: add a sanity check for DSP boot address alignment
The DSP remote processors on OMAP SoCs require a boot register to
be programmed with a boot address, and this boot address needs to
be on a 1KB boundary. The current code is simply masking the boot
address appropriately without performing any sanity checks before
releasing the resets. An unaligned boot address results in an
undefined execution behavior and can result in various bus errors
like MMU Faults or L3 NoC errors. Such errors are hard to debug and
can be easily avoided by adding a sanity check for the alignment
before booting a DSP remote processor.
Signed-off-by: Suman Anna <s-anna@ti.com>
The DSP remote processors on OMAP SoCs require a boot register to
be programmed with a boot address, and this boot address needs to
be on a 1KB boundary. The current code is simply masking the boot
address appropriately without performing any sanity checks before
releasing the resets. An unaligned boot address results in an
undefined execution behavior and can result in various bus errors
like MMU Faults or L3 NoC errors. Such errors are hard to debug and
can be easily avoided by adding a sanity check for the alignment
before booting a DSP remote processor.
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'rproc-linux-4.9.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-4.9.y
Pull in the updated remoteproc base feature branch that includes couple
of Kconfig cleanups to the remoteproc Kconfig. These patches helped in
alleviating some recursive Kconfig dependencies on v4.13 upstream kernel.
* 'rproc-linux-4.9.y' of git://git.ti.com/rpmsg/remoteproc:
remoteproc: Drop redundant REMOTEPROC dependency from driver Kconfigs
remoteproc: Drop VIRTUALIZATION dependency from REMOTEPROC
Signed-off-by: Suman Anna <s-anna@ti.com>
Pull in the updated remoteproc base feature branch that includes couple
of Kconfig cleanups to the remoteproc Kconfig. These patches helped in
alleviating some recursive Kconfig dependencies on v4.13 upstream kernel.
* 'rproc-linux-4.9.y' of git://git.ti.com/rpmsg/remoteproc:
remoteproc: Drop redundant REMOTEPROC dependency from driver Kconfigs
remoteproc: Drop VIRTUALIZATION dependency from REMOTEPROC
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'rpmsg-linux-4.9.y' of git://git.ti.com/rpmsg/rpmsg into rpmsg-ti-linux-4.9.y
Pull in the updated rpmsg base feature branch that includes a Kconfig
cleanup to the virtio rpmsg core to fix a recursive Kconfig dependency
on ppc64_defconfig.
* 'rpmsg-linux-4.9.y' of git://git.ti.com/rpmsg/rpmsg:
rpmsg: Drop VIRTUALIZATION dependency from RPMSG_VIRTIO
Signed-off-by: Suman Anna <s-anna@ti.com>
Pull in the updated rpmsg base feature branch that includes a Kconfig
cleanup to the virtio rpmsg core to fix a recursive Kconfig dependency
on ppc64_defconfig.
* 'rpmsg-linux-4.9.y' of git://git.ti.com/rpmsg/rpmsg:
rpmsg: Drop VIRTUALIZATION dependency from RPMSG_VIRTIO
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc: Drop redundant REMOTEPROC dependency from driver Kconfigs
[ Upstream commit e3f37c5ed70ca3902ab84762763e18abb742f627 ]
All the remoteproc platform driver Kconfig symbols are defined and
included under an if REMOTEPROC condition, so the dependency on
REMOTEPROC is implicit and they do not need an explicit 'depends
on REMOTEPROC' line. So, clean these up.
[s-anna@ti.com: backport and fixup commit 'e3f37c5ed70c' from v4.13]
Signed-off-by: Suman Anna <s-anna@ti.com>
[ Upstream commit e3f37c5ed70ca3902ab84762763e18abb742f627 ]
All the remoteproc platform driver Kconfig symbols are defined and
included under an if REMOTEPROC condition, so the dependency on
REMOTEPROC is implicit and they do not need an explicit 'depends
on REMOTEPROC' line. So, clean these up.
[s-anna@ti.com: backport and fixup commit 'e3f37c5ed70c' from v4.13]
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc: Drop VIRTUALIZATION dependency from REMOTEPROC
[ Upstream commit 384700d4653e7ad6d774bf2f217aaca1bcbe62e8 ]
A dependency to VIRTUALIZATION has been added to REMOTEPROC in v3.10
kernel in commit b9777859ec01 ("remoteproc: fix kconfig dependencies
for VIRTIO") to resolve Kconfig warnings due to the inclusion of the
virtio configuration file from the ARM's KVM config file. The KVM
config was fixed properly in the subsequent release in commit
8bd4ffd6b3a9 ("ARM: kvm: don't include drivers/virtio/Kconfig").
So, drop this unneeded VIRTUALIZATION dependency from REMOTEPROC.
[s-anna@ti.com: cherry-pick commit '384700d4653e' from v4.13]
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[ Upstream commit 384700d4653e7ad6d774bf2f217aaca1bcbe62e8 ]
A dependency to VIRTUALIZATION has been added to REMOTEPROC in v3.10
kernel in commit b9777859ec01 ("remoteproc: fix kconfig dependencies
for VIRTIO") to resolve Kconfig warnings due to the inclusion of the
virtio configuration file from the ARM's KVM config file. The KVM
config was fixed properly in the subsequent release in commit
8bd4ffd6b3a9 ("ARM: kvm: don't include drivers/virtio/Kconfig").
So, drop this unneeded VIRTUALIZATION dependency from REMOTEPROC.
[s-anna@ti.com: cherry-pick commit '384700d4653e' from v4.13]
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
rpmsg: Drop VIRTUALIZATION dependency from RPMSG_VIRTIO
[ Upstream commit 82e484dfef0bb29ca1a82740f2b8100cd0a64df3 ]
A dependency to VIRTUALIZATION has been added to RPMSG_VIRTIO (back
when it was named RPMSG) in v3.10 kernel in commit 397944df3290
("rpmsg: fix kconfig dependencies for VIRTIO") to resolve Kconfig
warnings due to the inclusion of the virtio configuration file from
the ARM's KVM config file. The KVM config was fixed properly in the
subsequent release in commit 8bd4ffd6b3a9 ("ARM: kvm: don't include
drivers/virtio/Kconfig"). So, drop this unneeded VIRTUALIZATION
dependency from RPMSG_VIRTIO.
[s-anna@ti.com: cherry-pick commit '82e484dfef0b' from v4.13]
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[ Upstream commit 82e484dfef0bb29ca1a82740f2b8100cd0a64df3 ]
A dependency to VIRTUALIZATION has been added to RPMSG_VIRTIO (back
when it was named RPMSG) in v3.10 kernel in commit 397944df3290
("rpmsg: fix kconfig dependencies for VIRTIO") to resolve Kconfig
warnings due to the inclusion of the virtio configuration file from
the ARM's KVM config file. The KVM config was fixed properly in the
subsequent release in commit 8bd4ffd6b3a9 ("ARM: kvm: don't include
drivers/virtio/Kconfig"). So, drop this unneeded VIRTUALIZATION
dependency from RPMSG_VIRTIO.
[s-anna@ti.com: cherry-pick commit '82e484dfef0b' from v4.13]
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Merge branch 'rproc-linux-4.9.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-4.9.y
Pull in the updated remoteproc feature branch that provides an updated
PRUSS driver to provide a PRUSS instance id back to the PRU client/user
drivers.
* 'rproc-linux-4.9.y' of git://git.ti.com/rpmsg/remoteproc:
remoteproc/pruss: update pruss_get() to retrieve a PRUSS id
remoteproc/pruss: add instance id to each PRUSS data
Signed-off-by: Suman Anna <s-anna@ti.com>
Pull in the updated remoteproc feature branch that provides an updated
PRUSS driver to provide a PRUSS instance id back to the PRU client/user
drivers.
* 'rproc-linux-4.9.y' of git://git.ti.com/rpmsg/remoteproc:
remoteproc/pruss: update pruss_get() to retrieve a PRUSS id
remoteproc/pruss: add instance id to each PRUSS data
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc/pruss: update pruss_get() to retrieve a PRUSS id
Update the pruss_get() function to take in an additional integer
pointer argument in which the PRUSS instance id is filled in and
provided back to the callers. This allows the drivers to add some
instance-specific logic/customization in their code, as the PRUSS
handle is not useful to build this logic.
Signed-off-by: Suman Anna <s-anna@ti.com>
Update the pruss_get() function to take in an additional integer
pointer argument in which the PRUSS instance id is filled in and
provided back to the callers. This allows the drivers to add some
instance-specific logic/customization in their code, as the PRUSS
handle is not useful to build this logic.
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'rproc-linux-4.9.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-4.9.y
Pull in the updated remoteproc feature branch that adds switches the PRU
remoteproc driver to a client-driven boot methodology and reverts the logic
in the driver to boot PRU Ethernet specific firmwares on various TI IDK and
ICE boards supporting PRU Ethernet ports. The PRU Ethernet driver will
supply these firmware names going forward.
* 'rproc-linux-4.9.y' of git://git.ti.com/rpmsg/remoteproc:
Revert "TEMP: remoteproc/pru: use different firmware names for ethernet"
Revert "TEMP: remoteproc/pru: enable ethernet fw for PRUSS1 on AM571x IDK"
Revert "TEMP: remoteproc/pru: enable ethernet fw for PRUSSs on K2G ICE EVM"
remoteproc/pru: switch to client-driven boot methodology
Signed-off-by: Suman Anna <s-anna@ti.com>
Pull in the updated remoteproc feature branch that adds switches the PRU
remoteproc driver to a client-driven boot methodology and reverts the logic
in the driver to boot PRU Ethernet specific firmwares on various TI IDK and
ICE boards supporting PRU Ethernet ports. The PRU Ethernet driver will
supply these firmware names going forward.
* 'rproc-linux-4.9.y' of git://git.ti.com/rpmsg/remoteproc:
Revert "TEMP: remoteproc/pru: use different firmware names for ethernet"
Revert "TEMP: remoteproc/pru: enable ethernet fw for PRUSS1 on AM571x IDK"
Revert "TEMP: remoteproc/pru: enable ethernet fw for PRUSSs on K2G ICE EVM"
remoteproc/pru: switch to client-driven boot methodology
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc/pruss: add instance id to each PRUSS data
The PRUSS driver provided a struct pruss handle to client drivers
using the pruss_get() API for them to operate on a PRUSS instance.
The PRU client drivers may also want to know the exact PRUSS instance
id so that they can program/configure different PRUSS instances
differently (eg: running a Dual-EMAC PRU Ethernet usecase on one
instance, and running a PRU Ethernet Switch usecase on the other).
Add an instance id to each of the PRUSS so that the PRUSS API can
be enhanced to provide this instance id to PRU client drivers. The
values match the terminology used in each of the SoC's Technical
Reference Manuals.
Signed-off-by: Suman Anna <s-anna@ti.com>
The PRUSS driver provided a struct pruss handle to client drivers
using the pruss_get() API for them to operate on a PRUSS instance.
The PRU client drivers may also want to know the exact PRUSS instance
id so that they can program/configure different PRUSS instances
differently (eg: running a Dual-EMAC PRU Ethernet usecase on one
instance, and running a PRU Ethernet Switch usecase on the other).
Add an instance id to each of the PRUSS so that the PRUSS API can
be enhanced to provide this instance id to PRU client drivers. The
values match the terminology used in each of the SoC's Technical
Reference Manuals.
Signed-off-by: Suman Anna <s-anna@ti.com>
Revert "TEMP: remoteproc/pru: use different firmware names for ethernet"
This reverts commit dced756b496d7a81c97cf657ca0e68eca76c6a3b.
The PRU Ethernet driver will use the rproc_set_firmware() API to
configure the appropriate firmware names to be used by the remoteproc
core for loading and booting the PRU remoteprocs. Undo the changes
added previously in PRU remoteproc driver in commit dced756b496
("TEMP: remoteproc/pru: use different firmware names for ethernet")
to perform the same, the auto-boot code logic is already handled
and so is not reverted.
TODO:
The internal pinmux programming added in commit a67dccf15475
("HACK: remoteproc/pru: allow device tree to configure GP_MUX_SEL")
and required for AM571x-IDK and K2G-ICE boards is still in place,
and needs to be moved into PRU Ethernet driver.
Signed-off-by: Suman Anna <s-anna@ti.com>
This reverts commit dced756b496d7a81c97cf657ca0e68eca76c6a3b.
The PRU Ethernet driver will use the rproc_set_firmware() API to
configure the appropriate firmware names to be used by the remoteproc
core for loading and booting the PRU remoteprocs. Undo the changes
added previously in PRU remoteproc driver in commit dced756b496
("TEMP: remoteproc/pru: use different firmware names for ethernet")
to perform the same, the auto-boot code logic is already handled
and so is not reverted.
TODO:
The internal pinmux programming added in commit a67dccf15475
("HACK: remoteproc/pru: allow device tree to configure GP_MUX_SEL")
and required for AM571x-IDK and K2G-ICE boards is still in place,
and needs to be moved into PRU Ethernet driver.
Signed-off-by: Suman Anna <s-anna@ti.com>
Revert "TEMP: remoteproc/pru: enable ethernet fw for PRUSS1 on AM571x IDK"
This reverts commit 2f7dc44e8e030bb9d18cd6bac2892fa41c34ea35.
The PRU Ethernet driver will use the rproc_set_firmware() API to
configure the appropriate firmware names to be used by the remoteproc
core for loading and booting the PRU remoteprocs. Undo the changes
added previously in PRU remoteproc driver in commit 2f7dc44e8e03
("TEMP: remoteproc/pru: enable ethernet fw for PRUSS1 on AM571x IDK")
to perform the same. The AM571x IDK vs AM572x IDK differences will
be inherent due to the presence/absence of the corresponding prueth
DT nodes.
NOTE:
The internal pinmux programming required for AM571x IDK is still in
place in the PRU remoteproc driver.
Signed-off-by: Suman Anna <s-anna@ti.com>
This reverts commit 2f7dc44e8e030bb9d18cd6bac2892fa41c34ea35.
The PRU Ethernet driver will use the rproc_set_firmware() API to
configure the appropriate firmware names to be used by the remoteproc
core for loading and booting the PRU remoteprocs. Undo the changes
added previously in PRU remoteproc driver in commit 2f7dc44e8e03
("TEMP: remoteproc/pru: enable ethernet fw for PRUSS1 on AM571x IDK")
to perform the same. The AM571x IDK vs AM572x IDK differences will
be inherent due to the presence/absence of the corresponding prueth
DT nodes.
NOTE:
The internal pinmux programming required for AM571x IDK is still in
place in the PRU remoteproc driver.
Signed-off-by: Suman Anna <s-anna@ti.com>
Revert "TEMP: remoteproc/pru: enable ethernet fw for PRUSSs on K2G ICE EVM"
This reverts commit 8eabf4474a3c2300337450635a75d62700aeb689.
The PRU Ethernet driver will use the rproc_set_firmware() API to
configure the appropriate firmware names to be used by the remoteproc
core for loading and booting the PRU remoteprocs. Undo the changes
added previously in PRU remoteproc driver in commit 8eabf4474a3c
("TEMP: remoteproc/pru: enable ethernet fw for PRUSSs on K2G ICE EVM")
to perform the same.
NOTE:
The internal pinmux programming required for K2G-ICE is still in
place in the PRU remoteproc driver.
Signed-off-by: Suman Anna <s-anna@ti.com>
This reverts commit 8eabf4474a3c2300337450635a75d62700aeb689.
The PRU Ethernet driver will use the rproc_set_firmware() API to
configure the appropriate firmware names to be used by the remoteproc
core for loading and booting the PRU remoteprocs. Undo the changes
added previously in PRU remoteproc driver in commit 8eabf4474a3c
("TEMP: remoteproc/pru: enable ethernet fw for PRUSSs on K2G ICE EVM")
to perform the same.
NOTE:
The internal pinmux programming required for K2G-ICE is still in
place in the PRU remoteproc driver.
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc/pru: switch to client-driven boot methodology
The PRU remoteproc driver currently supports a hybrid boot methodology
- it supports auto-boot only for non PRU-Ethernet firmwares/usecases
and no auto-boot for PRU-Ethernet usecases in which the PRU Ethernet
driver is responsible for booting the PRUs. This is made possible due
to a short-term/temporary solution by using a module parameter and
specific PRU capabilities based on board detection in the driver. This
is not a scalable solution as the driver leveraged specific board
compatibles.
The PRU remoteproc driver is now modified to _not_ support auto-boot
by default for all use-cases so that the PRU load and boot is dictated
by the corresponding client drivers. This allows flexibility for the
client drivers/applications to set a firmware name (if needed) based
on their desired functionality and boot the PRU. The sysfs bind and
unbind attributes have also been suppressed so that the PRU devices
cannot be unbound and thereby shutdown a PRU from underneath a PRU
client driver.
Signed-off-by: Suman Anna <s-anna@ti.com>
The PRU remoteproc driver currently supports a hybrid boot methodology
- it supports auto-boot only for non PRU-Ethernet firmwares/usecases
and no auto-boot for PRU-Ethernet usecases in which the PRU Ethernet
driver is responsible for booting the PRUs. This is made possible due
to a short-term/temporary solution by using a module parameter and
specific PRU capabilities based on board detection in the driver. This
is not a scalable solution as the driver leveraged specific board
compatibles.
The PRU remoteproc driver is now modified to _not_ support auto-boot
by default for all use-cases so that the PRU load and boot is dictated
by the corresponding client drivers. This allows flexibility for the
client drivers/applications to set a firmware name (if needed) based
on their desired functionality and boot the PRU. The sysfs bind and
unbind attributes have also been suppressed so that the PRU devices
cannot be unbound and thereby shutdown a PRU from underneath a PRU
client driver.
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'rproc-linux-4.9.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-4.9.y
Pull in the updated remoteproc feature branch that adds a new remoteproc
kernel API to allow a remoteproc user to configure the firmware name for
a remote processor. The logic is reused between sysfs and remoteproc client
drivers.
* 'rproc-linux-4.9.y' of git://git.ti.com/rpmsg/remoteproc:
remoteproc: update sysfs firmware_store() to use rproc_set_firmware()
remoteproc: add a rproc_set_firmware() API
Signed-off-by: Suman Anna <s-anna@ti.com>
Pull in the updated remoteproc feature branch that adds a new remoteproc
kernel API to allow a remoteproc user to configure the firmware name for
a remote processor. The logic is reused between sysfs and remoteproc client
drivers.
* 'rproc-linux-4.9.y' of git://git.ti.com/rpmsg/remoteproc:
remoteproc: update sysfs firmware_store() to use rproc_set_firmware()
remoteproc: add a rproc_set_firmware() API
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc: update sysfs firmware_store() to use rproc_set_firmware()
Update the firmware_store() function that provides a sysfs interface
to set a new firmware name for a remote processor to reuse the newly
added rproc_set_firmware() function. This avoids code duplication.
Signed-off-by: Suman Anna <s-anna@ti.com>
Update the firmware_store() function that provides a sysfs interface
to set a new firmware name for a remote processor to reuse the newly
added rproc_set_firmware() function. This avoids code duplication.
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc: add a rproc_set_firmware() API
A new API, rproc_set_firmware() is added to allow the remoteproc client
drivers to be able to configure a custom firmware name that is different
from the default name registered by a remoteproc platform driver. This
function is being introduced to provide a kernel-level equivalent of
the current sysfs interface, so as to allow these kernel-drivers to
choose different firmwares based on their functional feature it is
implementing using the remote processor.
Signed-off-by: Suman Anna <s-anna@ti.com>
A new API, rproc_set_firmware() is added to allow the remoteproc client
drivers to be able to configure a custom firmware name that is different
from the default name registered by a remoteproc platform driver. This
function is being introduced to provide a kernel-level equivalent of
the current sysfs interface, so as to allow these kernel-drivers to
choose different firmwares based on their functional feature it is
implementing using the remote processor.
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'rproc-linux-4.9.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-4.9.y
Pull in the updated remoteproc feature branch that fixes a minor issue
in the Davinci remoteproc driver with repeated start/stop using sysfs.
The merge also includes couple of cleanups to streamline the code
between the driver's probe/remove and start/stop functions.
* 'rproc-linux-4.9.y' of git://git.ti.com/rpmsg/remoteproc:
remoteproc/davinci: streamline the interrupt management
remoteproc/davinci: fix unbalanced reset between start and stop ops
remoteproc/davinci: simplify the reset function
Signed-off-by: Suman Anna <s-anna@ti.com>
Pull in the updated remoteproc feature branch that fixes a minor issue
in the Davinci remoteproc driver with repeated start/stop using sysfs.
The merge also includes couple of cleanups to streamline the code
between the driver's probe/remove and start/stop functions.
* 'rproc-linux-4.9.y' of git://git.ti.com/rpmsg/remoteproc:
remoteproc/davinci: streamline the interrupt management
remoteproc/davinci: fix unbalanced reset between start and stop ops
remoteproc/davinci: simplify the reset function
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'rproc-linux-4.9.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-4.9.y
Pull in the updated remoteproc feature branch that fixes a minor
kernel crash issue with sysfs unbind in the Keystone remoteproc
driver configured for Multi Proc Manager (MPM) load/boot mechanism.
* 'rproc-linux-4.9.y' of git://git.ti.com/rpmsg/remoteproc:
remoteproc/keystone: fix kernel crash with sysfs unbind and MPM loader
Signed-off-by: Suman Anna <s-anna@ti.com>
Pull in the updated remoteproc feature branch that fixes a minor
kernel crash issue with sysfs unbind in the Keystone remoteproc
driver configured for Multi Proc Manager (MPM) load/boot mechanism.
* 'rproc-linux-4.9.y' of git://git.ti.com/rpmsg/remoteproc:
remoteproc/keystone: fix kernel crash with sysfs unbind and MPM loader
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc/davinci: streamline the interrupt management
The davinci remoteproc driver is currently requesting its interrupt
that deals with the virtio kicks in probe, and that too before all
the associated variables used by the handler are initialized. This
is a lot in advance before the DSP remote processor is even loaded
and booted and is not essential. Streamline the interrupt request
and freeing operations instead alongside the boot and shutdown of
the remote processor.
Signed-off-by: Suman Anna <s-anna@ti.com>
The davinci remoteproc driver is currently requesting its interrupt
that deals with the virtio kicks in probe, and that too before all
the associated variables used by the handler are initialized. This
is a lot in advance before the DSP remote processor is even loaded
and booted and is not essential. Streamline the interrupt request
and freeing operations instead alongside the boot and shutdown of
the remote processor.
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc/davinci: fix unbalanced reset between start and stop ops
The davinci remoteproc driver is currently de-asserting the reset in
its rproc .start() ops, but is not asserting the reset in its .stop()
ops. This leaves the remote processor to not boot properly when using
the sysfs 'state' variable between multiple start and stop operations.
On the other hand, a reset is being asserted unconditionally in the
driver remove function to alleviate some of these issues.
Move this reset assertion logic into the .stop() ops implementation
to fix the sysfs state-machine and the unbalanced reset. The logic
from remove is still effective since .stop() ops will be invoked
during the remove due to the enabled 'auto-boot' support. The probe
already has support for asserting the reset in case the DSP is not
in reset for some reason.
Signed-off-by: Suman Anna <s-anna@ti.com>
The davinci remoteproc driver is currently de-asserting the reset in
its rproc .start() ops, but is not asserting the reset in its .stop()
ops. This leaves the remote processor to not boot properly when using
the sysfs 'state' variable between multiple start and stop operations.
On the other hand, a reset is being asserted unconditionally in the
driver remove function to alleviate some of these issues.
Move this reset assertion logic into the .stop() ops implementation
to fix the sysfs state-machine and the unbalanced reset. The logic
from remove is still effective since .stop() ops will be invoked
during the remove due to the enabled 'auto-boot' support. The probe
already has support for asserting the reset in case the DSP is not
in reset for some reason.
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc/davinci: simplify the reset function
The reset_assert() function is used to make sure the DSP remote
processor is in a reset state regardless of its previous state.
The driver relies on davinci_clk_reset_{assert,deassert}()
functions for reset management which take in a clock parameter.
The assert_reset() performs a clk_get()/clk_put() cycle to
acquire the clock handle to use with this function. This is
totally unnecessary and the code can be simplified to use
the clock acquired during probe and directly use the reset
functions, so simplify this logic.
Signed-off-by: Suman Anna <s-anna@ti.com>
The reset_assert() function is used to make sure the DSP remote
processor is in a reset state regardless of its previous state.
The driver relies on davinci_clk_reset_{assert,deassert}()
functions for reset management which take in a clock parameter.
The assert_reset() performs a clk_get()/clk_put() cycle to
acquire the clock handle to use with this function. This is
totally unnecessary and the code can be simplified to use
the clock acquired during probe and directly use the reset
functions, so simplify this logic.
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc/keystone: fix kernel crash with sysfs unbind and MPM loader
The Keystone remoteproc driver supports two different load & boot
mechanisms - the regular kernel space based loading and a userspace
based Multi Proc Manager (MPM) loading. The driver has slightly
different state machine flow between the two mechanisms. The standard
platform driver's bind and unbind sysfs attributes can be used to
boot and shutdown a Keystone DSP processor supporting remoteproc core's
auto-boot. Suppress these attributes for MPM-based stack so that the
sysfs approach does not mess up the MPM-based state-machine by unbinding
the device from the driver even when it has open usage reference counts.
Signed-off-by: Suman Anna <s-anna@ti.com>
The Keystone remoteproc driver supports two different load & boot
mechanisms - the regular kernel space based loading and a userspace
based Multi Proc Manager (MPM) loading. The driver has slightly
different state machine flow between the two mechanisms. The standard
platform driver's bind and unbind sysfs attributes can be used to
boot and shutdown a Keystone DSP processor supporting remoteproc core's
auto-boot. Suppress these attributes for MPM-based stack so that the
sysfs approach does not mess up the MPM-based state-machine by unbinding
the device from the driver even when it has open usage reference counts.
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'rproc-linux-4.9.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-4.9.y
Pull in the updated remoteproc feature branch that fixes a minor
runtime autosuspend state-machine issue in the OMAP remoteproc driver
when the recovery is halted and a remote processor crash is triggered.
* 'rproc-linux-4.9.y' of git://git.ti.com/rpmsg/remoteproc:
remoteproc/omap: fix auto-suspend failure warning during crashed state
Signed-off-by: Suman Anna <s-anna@ti.com>
Pull in the updated remoteproc feature branch that fixes a minor
runtime autosuspend state-machine issue in the OMAP remoteproc driver
when the recovery is halted and a remote processor crash is triggered.
* 'rproc-linux-4.9.y' of git://git.ti.com/rpmsg/remoteproc:
remoteproc/omap: fix auto-suspend failure warning during crashed state
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc/omap: fix auto-suspend failure warning during crashed state
The runtime autosuspend on a OMAP remoteproc device is attempted when
the suspend timer expires (autosuspend delay elapsed since the last
time the device is busy). This is the normal autosuspend scenario
for a device functioning normally. This timer can also expire during
the debugging of a remoteproc crash when the remoteproc recovery is
disabled. This is an invalid pre-condition though, so check for the
RPROC_CRASHED state and bail out before the actual check for the
RPROC_RUNNING state. The auto-suspend is also not re-attempted until
the remoteproc is recovered and restored to normal functional state.
Signed-off-by: Suman Anna <s-anna@ti.com>
The runtime autosuspend on a OMAP remoteproc device is attempted when
the suspend timer expires (autosuspend delay elapsed since the last
time the device is busy). This is the normal autosuspend scenario
for a device functioning normally. This timer can also expire during
the debugging of a remoteproc crash when the remoteproc recovery is
disabled. This is an invalid pre-condition though, so check for the
RPROC_CRASHED state and bail out before the actual check for the
RPROC_RUNNING state. The auto-suspend is also not re-attempted until
the remoteproc is recovered and restored to normal functional state.
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'rproc-linux-4.9.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-4.9.y
Pull in the updated remoteproc feature branch that includes various
fixes for the Multi Proc Manager (MPM) stack with the Keystone
remoteproc driver.
The following is the summary:
- Provide sysfs interface for presenting the DSP internal memory
regions to userspace
- Revert the HACKs for the Keystone remoteproc DSP nodes to fix
the DT missing unit address warnings
- Fix a unnecessary request_firmware_nowait call during the MPM
path
- Memory leak fix in keystone_dsp_mem driver on failure path
* 'rproc-linux-4.9.y' of git://git.ti.com/rpmsg/remoteproc:
remoteproc: Modify the function names
remoteproc: Reduce asynchronous request_firmware to auto-boot only
remoteproc: Drop firmware_loading_complete
remoteproc: Add RPROC_DELETED state
remoteproc: Move rproc_delete_debug_dir() to rproc_del()
remoteproc: Cleanup last_traces in rproc_del()
TEMP: soc: ti: keystone_dsp_mem: fix memory leak on kobject_uevent()
Revert "HACK: ARM: dts: keystone-k2g: Rename DSP node for MPM"
Revert "HACK: ARM: dts: keystone-k2e: Rename DSP node for MPM"
Revert "HACK: ARM: dts: keystone-k2l: Rename DSP nodes for MPM"
Revert "HACK: ARM: dts: keystone-k2hk: Rename DSP nodes for MPM"
remoteproc/keystone: create sysfs entries for memories
Signed-off-by: Suman Anna <s-anna@ti.com>
Pull in the updated remoteproc feature branch that includes various
fixes for the Multi Proc Manager (MPM) stack with the Keystone
remoteproc driver.
The following is the summary:
- Provide sysfs interface for presenting the DSP internal memory
regions to userspace
- Revert the HACKs for the Keystone remoteproc DSP nodes to fix
the DT missing unit address warnings
- Fix a unnecessary request_firmware_nowait call during the MPM
path
- Memory leak fix in keystone_dsp_mem driver on failure path
* 'rproc-linux-4.9.y' of git://git.ti.com/rpmsg/remoteproc:
remoteproc: Modify the function names
remoteproc: Reduce asynchronous request_firmware to auto-boot only
remoteproc: Drop firmware_loading_complete
remoteproc: Add RPROC_DELETED state
remoteproc: Move rproc_delete_debug_dir() to rproc_del()
remoteproc: Cleanup last_traces in rproc_del()
TEMP: soc: ti: keystone_dsp_mem: fix memory leak on kobject_uevent()
Revert "HACK: ARM: dts: keystone-k2g: Rename DSP node for MPM"
Revert "HACK: ARM: dts: keystone-k2e: Rename DSP node for MPM"
Revert "HACK: ARM: dts: keystone-k2l: Rename DSP nodes for MPM"
Revert "HACK: ARM: dts: keystone-k2hk: Rename DSP nodes for MPM"
remoteproc/keystone: create sysfs entries for memories
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc: Modify the function names
[ Upstream commit 5e6533f72ce849bf49aaee96429bbe3558789d08 ]
The functions rproc_add_virtio_devices() and rproc_fw_config_virtio()
are reduced to trigger auto-boot only. Modify these function names and
related comments to reflect their current state.
This patch does not add any functional change.
Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick commit '5e6533f72ce8' from v4.11]
Signed-off-by: Suman Anna <s-anna@ti.com>
[ Upstream commit 5e6533f72ce849bf49aaee96429bbe3558789d08 ]
The functions rproc_add_virtio_devices() and rproc_fw_config_virtio()
are reduced to trigger auto-boot only. Modify these function names and
related comments to reflect their current state.
This patch does not add any functional change.
Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick commit '5e6533f72ce8' from v4.11]
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc: Reduce asynchronous request_firmware to auto-boot only
[ Upstream commit 7a20c64ddb3deeb08bbe1ca8e9bcafd3241a5e0e ]
The rproc_add_virtio_devices() requests firmware asynchronously and
triggers boot if the auto_boot flag is set. However, this
asynchronous call seems to be redundant for non auto-boot scenario
since the rproc_boot() would call request_firmware() anyways. Move
the auto_boot check to rproc_add() so that a redundant call to
_request_firmware can be avoided for non auto-boot case.
Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick commit '7a20c64ddb3d' from v4.11]
Signed-off-by: Suman Anna <s-anna@ti.com>
[ Upstream commit 7a20c64ddb3deeb08bbe1ca8e9bcafd3241a5e0e ]
The rproc_add_virtio_devices() requests firmware asynchronously and
triggers boot if the auto_boot flag is set. However, this
asynchronous call seems to be redundant for non auto-boot scenario
since the rproc_boot() would call request_firmware() anyways. Move
the auto_boot check to rproc_add() so that a redundant call to
_request_firmware can be avoided for non auto-boot case.
Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick commit '7a20c64ddb3d' from v4.11]
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc: Drop firmware_loading_complete
[ Upstream commit 2099c77d4af7d1582db6d4437014cf18fe62e74b ]
firmware_loading_complete is used to synchronize operations
on rproc while asynchronous firmware loading is in progress.
However, rproc_boot() no longer waits on
firmware_loading_complete. Hence drop this completion
variable altogether and handle the race between rproc_del()
and rproc_boot() using new state RPROC_DELETED.
The request_firmware_nowait() will hold the reference to
rproc device by using a get_device()/put_device(), so the
rproc struct will remain valid even when we return from
rproc_del() before the asynchronous call to
rproc_fw_config_virtio() completes.
CC: Loic Pallardy <loic.pallardy@st.com>
CC: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick commit '2099c77d4af7' from v4.11]
Signed-off-by: Suman Anna <s-anna@ti.com>
[ Upstream commit 2099c77d4af7d1582db6d4437014cf18fe62e74b ]
firmware_loading_complete is used to synchronize operations
on rproc while asynchronous firmware loading is in progress.
However, rproc_boot() no longer waits on
firmware_loading_complete. Hence drop this completion
variable altogether and handle the race between rproc_del()
and rproc_boot() using new state RPROC_DELETED.
The request_firmware_nowait() will hold the reference to
rproc device by using a get_device()/put_device(), so the
rproc struct will remain valid even when we return from
rproc_del() before the asynchronous call to
rproc_fw_config_virtio() completes.
CC: Loic Pallardy <loic.pallardy@st.com>
CC: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick commit '2099c77d4af7' from v4.11]
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc: Add RPROC_DELETED state
[ Upstream commit 608d792192d7136d354bc1b44585c441164dc54e ]
Add new state RPROC_DELETED to handle synchronization
between rproc_del() and other operations on rproc. This
state represents the rproc device that has been "deleted".
CC: Loic Pallardy <loic.pallardy@st.com>
CC: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick commit '608d792192d7' from v4.11]
Signed-off-by: Suman Anna <s-anna@ti.com>
[ Upstream commit 608d792192d7136d354bc1b44585c441164dc54e ]
Add new state RPROC_DELETED to handle synchronization
between rproc_del() and other operations on rproc. This
state represents the rproc device that has been "deleted".
CC: Loic Pallardy <loic.pallardy@st.com>
CC: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick commit '608d792192d7' from v4.11]
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc: Move rproc_delete_debug_dir() to rproc_del()
[ Upstream commit b003d45b37b2d2c682f279e6fd5a9254b8ddc244 ]
The "remoteproc{0,1...}" sysfs entries are added in
rproc_add() and deleted in rproc_type_release() instead of
in rproc_del(). That leaves these lingering entries sticking
around after we return from rproc_del(). Move the
rproc_delete_debug_dir() to rproc_del() to fix this.
Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick commit 'b003d45b37b2' from v4.11]
Signed-off-by: Suman Anna <s-anna@ti.com>
[ Upstream commit b003d45b37b2d2c682f279e6fd5a9254b8ddc244 ]
The "remoteproc{0,1...}" sysfs entries are added in
rproc_add() and deleted in rproc_type_release() instead of
in rproc_del(). That leaves these lingering entries sticking
around after we return from rproc_del(). Move the
rproc_delete_debug_dir() to rproc_del() to fix this.
Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick commit 'b003d45b37b2' from v4.11]
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc: Cleanup last_traces in rproc_del()
Move the cleanup of the remoteproc last_trace debugfs entries
from rproc_type_release() into the rproc_del() function in
preparation for moving the logic to delete the debugfs directory
also in rproc_del(). The original code was added in commit
ca7e120c3866 ("remoteproc: implement last trace for remoteproc")
and this move prepares the code for backporting some upstream
commits.
Signed-off-by: Suman Anna <s-anna@ti.com>
Move the cleanup of the remoteproc last_trace debugfs entries
from rproc_type_release() into the rproc_del() function in
preparation for moving the logic to delete the debugfs directory
also in rproc_del(). The original code was added in commit
ca7e120c3866 ("remoteproc: implement last trace for remoteproc")
and this move prepares the code for backporting some upstream
commits.
Signed-off-by: Suman Anna <s-anna@ti.com>
TEMP: soc: ti: keystone_dsp_mem: fix memory leak on kobject_uevent()
The keystone-dsp-mem driver provides sysfs entries for various SoC-level
memory regions that are exposed to userspace. A KOBJ_ADD event is raised
once these sysfs files were added, but any failure of this event results
in a memory leak due to an incorrect loop iterator initialization. Fix
this memory leak properly.
Fixes: 56f72f081b10 ("TEMP: soc: ti: keystone_dsp_mem: create sysfs entries for memories")
Signed-off-by: Suman Anna <s-anna@ti.com>
The keystone-dsp-mem driver provides sysfs entries for various SoC-level
memory regions that are exposed to userspace. A KOBJ_ADD event is raised
once these sysfs files were added, but any failure of this event results
in a memory leak due to an incorrect loop iterator initialization. Fix
this memory leak properly.
Fixes: 56f72f081b10 ("TEMP: soc: ti: keystone_dsp_mem: create sysfs entries for memories")
Signed-off-by: Suman Anna <s-anna@ti.com>
Revert "HACK: ARM: dts: keystone-k2g: Rename DSP node for MPM"
This reverts commit 18975402365221c2249107c456ad2e568a63da0c.
The Keystone remoteproc driver has been enhanced to provide sysfs
entries for the memory regions being exposed to userspace and the
Keystone Multi Proc Manager (MPM) stack has been updated to leverage
these sysfs entries instead of looking for specific DT names in the
procfs. Undo the changes added in commit 189754023652 ("HACK: ARM:
dts: keystone-k2g: Rename DSP node for MPM") so that the DSP node
name can be fixed back to follow the DT standard convention and
not throw any DTC compiler warnings.
Signed-off-by: Suman Anna <s-anna@ti.com>
This reverts commit 18975402365221c2249107c456ad2e568a63da0c.
The Keystone remoteproc driver has been enhanced to provide sysfs
entries for the memory regions being exposed to userspace and the
Keystone Multi Proc Manager (MPM) stack has been updated to leverage
these sysfs entries instead of looking for specific DT names in the
procfs. Undo the changes added in commit 189754023652 ("HACK: ARM:
dts: keystone-k2g: Rename DSP node for MPM") so that the DSP node
name can be fixed back to follow the DT standard convention and
not throw any DTC compiler warnings.
Signed-off-by: Suman Anna <s-anna@ti.com>
Revert "HACK: ARM: dts: keystone-k2e: Rename DSP node for MPM"
This reverts commit c0d7fe7d9474a35f47f1862658eaaeff74fdc3b7.
The Keystone remoteproc driver has been enhanced to provide sysfs
entries for the memory regions being exposed to userspace and the
Keystone Multi Proc Manager (MPM) stack has been updated to leverage
these sysfs entries instead of looking for specific DT names in the
procfs. Undo the changes added in commit c0d7fe7d9474 ("HACK: ARM:
dts: keystone-k2e: Rename DSP node for MPM") so that the DSP node
name can be fixed back to follow the DT standard convention and
not throw any DTC compiler warnings.
Signed-off-by: Suman Anna <s-anna@ti.com>
This reverts commit c0d7fe7d9474a35f47f1862658eaaeff74fdc3b7.
The Keystone remoteproc driver has been enhanced to provide sysfs
entries for the memory regions being exposed to userspace and the
Keystone Multi Proc Manager (MPM) stack has been updated to leverage
these sysfs entries instead of looking for specific DT names in the
procfs. Undo the changes added in commit c0d7fe7d9474 ("HACK: ARM:
dts: keystone-k2e: Rename DSP node for MPM") so that the DSP node
name can be fixed back to follow the DT standard convention and
not throw any DTC compiler warnings.
Signed-off-by: Suman Anna <s-anna@ti.com>
Revert "HACK: ARM: dts: keystone-k2l: Rename DSP nodes for MPM"
This reverts commit f816a30d2e55f411fb94370d31bd7f23bc92798e.
The Keystone remoteproc driver has been enhanced to provide sysfs
entries for the memory regions being exposed to userspace and the
Keystone Multi Proc Manager (MPM) stack has been updated to leverage
these sysfs entries instead of looking for specific DT names in the
procfs. Undo the changes added in commit f816a30d2e55 ("HACK: ARM:
dts: keystone-k2l: Rename DSP nodes for MPM") so that the DSP node
names can be fixed back to follow the DT standard convention and not
throw any DTC compiler warnings.
Signed-off-by: Suman Anna <s-anna@ti.com>
This reverts commit f816a30d2e55f411fb94370d31bd7f23bc92798e.
The Keystone remoteproc driver has been enhanced to provide sysfs
entries for the memory regions being exposed to userspace and the
Keystone Multi Proc Manager (MPM) stack has been updated to leverage
these sysfs entries instead of looking for specific DT names in the
procfs. Undo the changes added in commit f816a30d2e55 ("HACK: ARM:
dts: keystone-k2l: Rename DSP nodes for MPM") so that the DSP node
names can be fixed back to follow the DT standard convention and not
throw any DTC compiler warnings.
Signed-off-by: Suman Anna <s-anna@ti.com>
Revert "HACK: ARM: dts: keystone-k2hk: Rename DSP nodes for MPM"
This reverts commit ba03535c4e154ce6f5beacad22a8c0a0ff904876.
The Keystone remoteproc driver has been enhanced to provide sysfs
entries for the memory regions being exposed to userspace and the
Keystone Multi Proc Manager (MPM) stack has been updated to leverage
these sysfs entries instead of looking for specific DT names in the
procfs. Undo the changes added in commit ba03535c4e15 ("HACK: ARM:
dts: keystone-k2hk: Rename DSP nodes for MPM") so that the DSP node
names can be fixed back to follow the DT standard convention and not
throw any DTC compiler warnings.
Signed-off-by: Suman Anna <s-anna@ti.com>
This reverts commit ba03535c4e154ce6f5beacad22a8c0a0ff904876.
The Keystone remoteproc driver has been enhanced to provide sysfs
entries for the memory regions being exposed to userspace and the
Keystone Multi Proc Manager (MPM) stack has been updated to leverage
these sysfs entries instead of looking for specific DT names in the
procfs. Undo the changes added in commit ba03535c4e15 ("HACK: ARM:
dts: keystone-k2hk: Rename DSP nodes for MPM") so that the DSP node
names can be fixed back to follow the DT standard convention and not
throw any DTC compiler warnings.
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc/keystone: create sysfs entries for memories
The keystone-remoteproc driver is enhanced to provide sysfs entries
for each DSP remoteproc processor to allow the userspace to read the
address and size of the various DSP internal RAM memories that are
exposed to userspace through a corresponding misc device. This sysfs
logic allows the userspace-based Multi Proc Manager (MPM) stack to
not rely on procfs-based DT parsing for looking up the memories.
Each supported memory region is represented by its own directory and
presents two sysfs files 'addr' and 'size', and are created under the
respective dspX misc device. The directories can be accessed under the
/sys/class/misc/dspX/ path, where X is the DSP number (indexed from 0).
Signed-off-by: Suman Anna <s-anna@ti.com>
The keystone-remoteproc driver is enhanced to provide sysfs entries
for each DSP remoteproc processor to allow the userspace to read the
address and size of the various DSP internal RAM memories that are
exposed to userspace through a corresponding misc device. This sysfs
logic allows the userspace-based Multi Proc Manager (MPM) stack to
not rely on procfs-based DT parsing for looking up the memories.
Each supported memory region is represented by its own directory and
presents two sysfs files 'addr' and 'size', and are created under the
respective dspX misc device. The directories can be accessed under the
/sys/class/misc/dspX/ path, where X is the DSP number (indexed from 0).
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'rproc-linux-4.9.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-4.9.y
Pull in the updated remoteproc feature branch that adds the
Watchdog timer for DSP2 remote processor on all applicable
EVMs having DRA75x/DRA74x & AM572x SoCs.
* 'rproc-linux-4.9.y' of git://git.ti.com/rpmsg/remoteproc:
ARM: dts: am572x-idk: Add watchdog timer for DSP2
ARM: dts: beagle-x15-common: Add watchdog timer for DSP2
ARM: dts: dra7-evm: Add watchdog timer for DSP2
Signed-off-by: Suman Anna <s-anna@ti.com>
Pull in the updated remoteproc feature branch that adds the
Watchdog timer for DSP2 remote processor on all applicable
EVMs having DRA75x/DRA74x & AM572x SoCs.
* 'rproc-linux-4.9.y' of git://git.ti.com/rpmsg/remoteproc:
ARM: dts: am572x-idk: Add watchdog timer for DSP2
ARM: dts: beagle-x15-common: Add watchdog timer for DSP2
ARM: dts: dra7-evm: Add watchdog timer for DSP2
Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: dts: am572x-idk: Add watchdog timer for DSP2
The watchdog timer information has been added to the DSP2 remote
processor device node on the AM572x IDK boards. The watchdog timers
for other processors have already been added. This data is identical
to the timer used on the AM57xx EVM board board to maintain firmware
compatibility between both the SoC and board variants. The watchdog
functionality will use GPTimer 13 for the DSP processor core.
The MPU-side drivers will use this data to initialize the watchdog
timer, and listen for any watchdog triggers. The BIOS-side code on
DSP2 needs to configure/refresh this timer properly to not throw a
watchdog error.
This timer 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 DSP2 remote
processor device node on the AM572x IDK boards. The watchdog timers
for other processors have already been added. This data is identical
to the timer used on the AM57xx EVM board board to maintain firmware
compatibility between both the SoC and board variants. The watchdog
functionality will use GPTimer 13 for the DSP processor core.
The MPU-side drivers will use this data to initialize the watchdog
timer, and listen for any watchdog triggers. The BIOS-side code on
DSP2 needs to configure/refresh this timer properly to not throw a
watchdog error.
This timer 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: beagle-x15-common: Add watchdog timer for DSP2
The watchdog timer information has been added to the DSP2 remote
processor device node on all the AM57xx BeagleBoard-X15 boards.
The watchdog timers for other processors have already been added.
This data is identical to the timers used on the DRA7 EVM board
to maintain firmware compatibility between both the SoC and board
variants. The watchdog functionality will use GPTimer 13 for the
DSP processor core.
The MPU-side drivers will use this data to initialize the watchdog
timer, and listen for any watchdog triggers. The BIOS-side code on
DSP2 needs to configure/refresh this timer properly to not throw a
watchdog error.
This timer 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 DSP2 remote
processor device node on all the AM57xx BeagleBoard-X15 boards.
The watchdog timers for other processors have already been added.
This data is identical to the timers used on the DRA7 EVM board
to maintain firmware compatibility between both the SoC and board
variants. The watchdog functionality will use GPTimer 13 for the
DSP processor core.
The MPU-side drivers will use this data to initialize the watchdog
timer, and listen for any watchdog triggers. The BIOS-side code on
DSP2 needs to configure/refresh this timer properly to not throw a
watchdog error.
This timer 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 timer for DSP2
The watchdog timer information has been added to the DSP2 remote
processor device node on DRA7 EVM board. The watchdog timers for
other processors have already been added. The watchdog functionality
will use GPTimer 13 for the DSP processor core.
The MPU-side drivers will use this data to initialize the watchdog
timer, and listen for any watchdog triggers. The BIOS-side code on
DSP2 needs to configure/refresh this timer properly to not throw a
watchdog error.
This timer 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 DSP2 remote
processor device node on DRA7 EVM board. The watchdog timers for
other processors have already been added. The watchdog functionality
will use GPTimer 13 for the DSP processor core.
The MPU-side drivers will use this data to initialize the watchdog
timer, and listen for any watchdog triggers. The BIOS-side code on
DSP2 needs to configure/refresh this timer properly to not throw a
watchdog error.
This timer 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>
ti_config_fragments/defconfig_map.txt: add ipc.cfg to OMAP-L138
Add the RPMsg domain config fragment file ipc.cfg to the OMAP-L138
defconfigs in the defconfig map file, so that the RPMsg drivers can
be built by the defconfig builder tool.
Signed-off-by: Suman Anna <s-anna@ti.com>
Add the RPMsg domain config fragment file ipc.cfg to the OMAP-L138
defconfigs in the defconfig map file, so that the RPMsg drivers can
be built by the defconfig builder tool.
Signed-off-by: Suman Anna <s-anna@ti.com>
ti_config_fragments: rpmsg: Add Davinci remoteproc module
Add the Davinci remoteproc module to the rpmsg Kconfig fragment.
The relevant CMA dependencies (both CMA and DMA_CMA) were also
enabled. These are the minimum required options for building the
Davinci remoteproc driver. The other virtio/rpmsg modules needed
for enabling remoteproc/rpmsg communication with the DSP remote
processor on the Davinci OMAP-L138 SoCs were already enabled.
Signed-off-by: Suman Anna <s-anna@ti.com>
Add the Davinci remoteproc module to the rpmsg Kconfig fragment.
The relevant CMA dependencies (both CMA and DMA_CMA) were also
enabled. These are the minimum required options for building the
Davinci remoteproc driver. The other virtio/rpmsg modules needed
for enabling remoteproc/rpmsg communication with the DSP remote
processor on the Davinci OMAP-L138 SoCs were already enabled.
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'rproc-linux-4.9.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-4.9.y
Pull in the updated remoteproc feature branch that adds the DT support
to the Davinci remoteproc driver to load the DSP core on the OMAP-L138
SoCs. The remoteproc driver continues to support the legacy-mode devices
on non-DT platforms, and the DT-mode device is supported on the OMAP-L138
LCDK board. Additional changes include support for parsing of DSP internal
memories and other minor improvements including a build dependency cleanup.
The merge also pulls in the latest platform base tree into the
RPMsg integration branch. The merge brings in the defconfig_builder
infrastructure support for the OMAP-L138 SoCs using the
davinci_all_defconfig base config file.
* 'rproc-linux-4.9.y' of git://git.ti.com/rpmsg/remoteproc: (103 commits)
remoteproc/davinci: add a trace to print missing alias ids
ARM: dts: da850: Add alias for DSP node
ARM: dts: da850-lcdk: Add and enable CMA reserved pool for DSP
ARM: davinci: da8xx-dt: Add OF_DEV_AUXDATA entry for DSP clock matching
ARM: dts: da850: Add DSP node
remoteproc/davinci: Add device tree support for OMAP-L138 DSP
Documentation: dt: Add bindings for Davinci DSP processors
remoteproc/davinci: add support to parse internal memories
remoteproc/davinci: Switch to platform_get_resource_byname()
remoteproc/davinci: Update Kconfig to depend on DMA_CMA
ARM: davinci: da8xx: Add DSP internal RAM memories as IOMEM resources
ARM: davinci: da8xx: Add names to DSP IOMEM resources
ARM: davinci: da8xx: Create DSP device only when assigned memory
ARM: OMAP2+: omap_device: Sync omap_device and pm_runtime after probe defer
soc: ti: wkup_m3_ipc: Drop wait from wkup_m3_rproc_boot_thread
soc: ti: wkup_m3_ipc: Fix error return code in wkup_m3_ipc_probe()
ARM: dts: dra7: Add power hold and power controller properties to palmas
ARM: dts: am4372: Add dma entries for UART nodes
pinctrl: ti: iodelay: Lower the priority of prints
thermal: arm: dra752: Remove all TSHUT related definitions
...
Signed-off-by: Suman Anna <s-anna@ti.com>
Pull in the updated remoteproc feature branch that adds the DT support
to the Davinci remoteproc driver to load the DSP core on the OMAP-L138
SoCs. The remoteproc driver continues to support the legacy-mode devices
on non-DT platforms, and the DT-mode device is supported on the OMAP-L138
LCDK board. Additional changes include support for parsing of DSP internal
memories and other minor improvements including a build dependency cleanup.
The merge also pulls in the latest platform base tree into the
RPMsg integration branch. The merge brings in the defconfig_builder
infrastructure support for the OMAP-L138 SoCs using the
davinci_all_defconfig base config file.
* 'rproc-linux-4.9.y' of git://git.ti.com/rpmsg/remoteproc: (103 commits)
remoteproc/davinci: add a trace to print missing alias ids
ARM: dts: da850: Add alias for DSP node
ARM: dts: da850-lcdk: Add and enable CMA reserved pool for DSP
ARM: davinci: da8xx-dt: Add OF_DEV_AUXDATA entry for DSP clock matching
ARM: dts: da850: Add DSP node
remoteproc/davinci: Add device tree support for OMAP-L138 DSP
Documentation: dt: Add bindings for Davinci DSP processors
remoteproc/davinci: add support to parse internal memories
remoteproc/davinci: Switch to platform_get_resource_byname()
remoteproc/davinci: Update Kconfig to depend on DMA_CMA
ARM: davinci: da8xx: Add DSP internal RAM memories as IOMEM resources
ARM: davinci: da8xx: Add names to DSP IOMEM resources
ARM: davinci: da8xx: Create DSP device only when assigned memory
ARM: OMAP2+: omap_device: Sync omap_device and pm_runtime after probe defer
soc: ti: wkup_m3_ipc: Drop wait from wkup_m3_rproc_boot_thread
soc: ti: wkup_m3_ipc: Fix error return code in wkup_m3_ipc_probe()
ARM: dts: dra7: Add power hold and power controller properties to palmas
ARM: dts: am4372: Add dma entries for UART nodes
pinctrl: ti: iodelay: Lower the priority of prints
thermal: arm: dra752: Remove all TSHUT related definitions
...
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc/davinci: add a trace to print missing alias ids
The alias ids for Davinci remoteprocs are required by some
rpmsg client drivers to identify a remote processor in
a fixed manner to userspace. Add a trace during probe
to warn developers if the alias id is not defined for a
remoteproc DT node.
Signed-off-by: Suman Anna <s-anna@ti.com>
The alias ids for Davinci remoteprocs are required by some
rpmsg client drivers to identify a remote processor in
a fixed manner to userspace. Add a trace during probe
to warn developers if the alias id is not defined for a
remoteproc DT node.
Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: dts: da850: Add alias for DSP node
Add alias for the lone DSP remoteproc processor node present
on the OMAP-L13x/DA8xx SoCs. The alias uses the stem "rproc".
The alias is added to assign a fixed remoteproc id to the DSP
processor.
Signed-off-by: Suman Anna <s-anna@ti.com>
Add alias for the lone DSP remoteproc processor node present
on the OMAP-L13x/DA8xx SoCs. The alias uses the stem "rproc".
The alias is added to assign a fixed remoteproc id to the DSP
processor.
Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: dts: da850-lcdk: Add and enable CMA reserved pool for DSP
A CMA reserved memory node of 16 MB has been added and assigned to
the DSP remoteproc device on the OMAP-L138 LCDK board. The CMA starting
address matches the values used within the TI IPC 3.x software. Both
the CMA node and the corresponding rproc node are also marked okay
to enable the DSP on the OMAP-L138 LCDK board.
Signed-off-by: Suman Anna <s-anna@ti.com>
A CMA reserved memory node of 16 MB has been added and assigned to
the DSP remoteproc device on the OMAP-L138 LCDK board. The CMA starting
address matches the values used within the TI IPC 3.x software. Both
the CMA node and the corresponding rproc node are also marked okay
to enable the DSP on the OMAP-L138 LCDK board.
Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: davinci: da8xx-dt: Add OF_DEV_AUXDATA entry for DSP clock matching
Add the OF_DEV_AUXDATA entry needed to match the device-tree DSP node
to its non-device-tree clock, so that the da8xx-remoteproc driver can
properly enable the clocks. The device name has also been assigned
"davinci-rproc.0" to match the device id used in the da850_clks
clk_lookup array.
Signed-off-by: Suman Anna <s-anna@ti.com>
Add the OF_DEV_AUXDATA entry needed to match the device-tree DSP node
to its non-device-tree clock, so that the da8xx-remoteproc driver can
properly enable the clocks. The device name has also been assigned
"davinci-rproc.0" to match the device id used in the da850_clks
clk_lookup array.
Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: dts: da850: Add DSP node
The TI Davinci DA8xx family of SoCs have a single DSP subsystem
that is comprised of TI's standard TMS320C674x megamodule and
several blocks of internal memory (L1P, L1D and L2 RAMs). Add
the DT node for this DSP processor sub-system. The processor
does not have an MMU, and uses a chip-level signalling register
and shared memory for inter-processor communication with the
ARM core.
The node has been added in disabled state, and can be enabled
in the respective board dts file with an associated reserved
memory block.
Signed-off-by: Suman Anna <s-anna@ti.com>
The TI Davinci DA8xx family of SoCs have a single DSP subsystem
that is comprised of TI's standard TMS320C674x megamodule and
several blocks of internal memory (L1P, L1D and L2 RAMs). Add
the DT node for this DSP processor sub-system. The processor
does not have an MMU, and uses a chip-level signalling register
and shared memory for inter-processor communication with the
ARM core.
The node has been added in disabled state, and can be enabled
in the respective board dts file with an associated reserved
memory block.
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc/davinci: Add device tree support for OMAP-L138 DSP
The Davinci remoteproc driver currently supports the DSP remoteproc
device created in legacy-style on OMAP-L13x SoCs. The driver has been
enhanced to support the DSP remoteproc device created through Device
Tree now. The current DT support handles the C674x DSP processor
subsystem on OMAP-L138 SoCs.
Signed-off-by: Suman Anna <s-anna@ti.com>
The Davinci remoteproc driver currently supports the DSP remoteproc
device created in legacy-style on OMAP-L13x SoCs. The driver has been
enhanced to support the DSP remoteproc device created through Device
Tree now. The current DT support handles the C674x DSP processor
subsystem on OMAP-L138 SoCs.
Signed-off-by: Suman Anna <s-anna@ti.com>
Documentation: dt: Add bindings for Davinci DSP processors
Add the device tree bindings document for the DSP processor
subsystem devices on TI Davinci DA8xx/OMAP-L13x SoCs.
Signed-off-by: Suman Anna <s-anna@ti.com>
Add the device tree bindings document for the DSP processor
subsystem devices on TI Davinci DA8xx/OMAP-L13x SoCs.
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc/davinci: add support to parse internal memories
The DSP subsystem on OMAP-L13x SoCs has various internal RAM
memories that can accessed from the ARM side. These memories
can be configured to be used as either RAM or Cache.
The Davinci remoteproc driver has been enhanced to parse and
store the kernel mappings for these internal RAM memories.
These mappings can then be used to support direct loading of
text/data into these memories from the remoteproc driver.
Signed-off-by: Suman Anna <s-anna@ti.com>
The DSP subsystem on OMAP-L13x SoCs has various internal RAM
memories that can accessed from the ARM side. These memories
can be configured to be used as either RAM or Cache.
The Davinci remoteproc driver has been enhanced to parse and
store the kernel mappings for these internal RAM memories.
These mappings can then be used to support direct loading of
text/data into these memories from the remoteproc driver.
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc/davinci: Switch to platform_get_resource_byname()
The davinci remoteproc driver currently uses the platform_get_resource()
API for retrieving the IOMEM resources. Switch this function to use the
platform_get_resource_byname() API instead in preparation for adding the
DT support so that the binding can be agnostic of the IOMEM resource
order.
Signed-off-by: Suman Anna <s-anna@ti.com>
The davinci remoteproc driver currently uses the platform_get_resource()
API for retrieving the IOMEM resources. Switch this function to use the
platform_get_resource_byname() API instead in preparation for adding the
DT support so that the binding can be agnostic of the IOMEM resource
order.
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc/davinci: Update Kconfig to depend on DMA_CMA
The davinci remoteproc driver requires a CMA pool for allocating
memory for virtio vrings/buffers and other sections of the firmware
image. The allocations are done using the DMA API. The CMA option is
currently selected automatically on systems with MMU when davinci
remoteproc is enabled, switch this to a saner depends on dependency
convention. The dependency is also updated to use the DMA_CMA kconfig
symbol that is used for CMA allocations using the DMA API, the CMA
dependency is inherited implicitly.
Signed-off-by: Suman Anna <s-anna@ti.com>
The davinci remoteproc driver requires a CMA pool for allocating
memory for virtio vrings/buffers and other sections of the firmware
image. The allocations are done using the DMA API. The CMA option is
currently selected automatically on systems with MMU when davinci
remoteproc is enabled, switch this to a saner depends on dependency
convention. The dependency is also updated to use the DMA_CMA kconfig
symbol that is used for CMA allocations using the DMA API, the CMA
dependency is inherited implicitly.
Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: davinci: da8xx: Add DSP internal RAM memories as IOMEM resources
The DSP subsystem on DA8xx has various internal RAM memories that can
accessed from the ARM side. These memories can be configured to be
used as either RAM or Cache. Add these memories as IOMEM resources
to the DSP device so that the driver can support loading of images
into internal memories.
Signed-off-by: Suman Anna <s-anna@ti.com>
The DSP subsystem on DA8xx has various internal RAM memories that can
accessed from the ARM side. These memories can be configured to be
used as either RAM or Cache. Add these memories as IOMEM resources
to the DSP device so that the driver can support loading of images
into internal memories.
Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: davinci: da8xx: Add names to DSP IOMEM resources
Add names to the IOMEM resources for the DSP device present on
DA8xx SoCs. This will facilitate the driver to use the names and
be agnostic of the resource order, and facilitate scalable DT
support in follow-up patches.
Signed-off-by: Suman Anna <s-anna@ti.com>
Add names to the IOMEM resources for the DSP device present on
DA8xx SoCs. This will facilitate the driver to use the names and
be agnostic of the resource order, and facilitate scalable DT
support in follow-up patches.
Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: davinci: da8xx: Create DSP device only when assigned memory
The DSP device on Davinci platforms does not have an MMU and requires
specific DDR memory to boot. This memory is reserved using the rproc_mem
kernel boot parameter and is assigned to the device on non-DT boots.
The remoteproc core uses the DMA API and so will fall back to assigning
random memory if this memory is not assigned to the device, but the DSP
remote processor boot will not be successful in such cases. So, check
that memory has been reserved and assigned to the device specifically
before even creating the DSP device.
Signed-off-by: Suman Anna <s-anna@ti.com>
The DSP device on Davinci platforms does not have an MMU and requires
specific DDR memory to boot. This memory is reserved using the rproc_mem
kernel boot parameter and is assigned to the device on non-DT boots.
The remoteproc core uses the DMA API and so will fall back to assigning
random memory if this memory is not assigned to the device, but the DSP
remote processor boot will not be successful in such cases. So, check
that memory has been reserved and assigned to the device specifically
before even creating the DSP device.
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'platform-ti-linux-4.9.y-golden' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree into rproc-linux-4.9.y
Resync/Pull in the latest platform base tree into the remoteproc feature
tree. The merge pulls in the necessary base support for the OMAP-L138 SoCs
on the OMAP-L138 LCDK board using Device tree. The Davinci platforms are
supported using the davinci_all_defconfig config.
Other enhancements and fixes include:
- A new pinctrl driver for TI DA850/OMAP-L138/AM18XX SoCs
- Various fixes and cleanup to wkup_m3_ipc driver including the removal
of the remoteproc firmware_loading_complete completion variable
- Various hwmod fixes/enhancements on OMAP platforms
- Various PM / Wakeirq fixes
This merges establishes the baseline to allow to add the DT support to the
da8xx-remoteproc driver.
* 'platform-ti-linux-4.9.y-golden' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree: (90 commits)
ARM: OMAP2+: omap_device: Sync omap_device and pm_runtime after probe defer
soc: ti: wkup_m3_ipc: Drop wait from wkup_m3_rproc_boot_thread
soc: ti: wkup_m3_ipc: Fix error return code in wkup_m3_ipc_probe()
ARM: dts: dra7: Add power hold and power controller properties to palmas
ARM: dts: am4372: Add dma entries for UART nodes
pinctrl: ti: iodelay: Lower the priority of prints
thermal: arm: dra752: Remove all TSHUT related definitions
thermal: arm: dra752: Remove TSHUT configuration
ti_config_fragments: baseport: Enable CONFIG_KEXEC option for omap and keystone
ti_config_fragments: move crypto self tests under debug build
crypto: omap-des: Verify page zone of scatterlists before starting DMA
crypto: omap-aes: Verify page zone of scatterlists before starting DMA
crypto: omap-des: Use bool instead of int for omap_des_copy_needed()
crypto: omap-aes: Use bool instead of int for omap_aes_check_aligned()
ARM: dts: am437x-gp-evm: Add uart0 pinctrl default and sleep states
thermal: ti-soc-thermal: Call pm_power_off in emergency shutdown function
gpio: davinci: Assign first bank regs for unbanked case
soc: ti: wkup_m3_ipc: Fix wkup_m3_ipc debugfs entry
ti_config_fragments/defconfig_map.txt: introduce support for OMAP-L138
HACK: ARM: omap2+: prevent cpu1 reset for secure devices during boot
...
Signed-off-by: Suman Anna <s-anna@ti.com>
Resync/Pull in the latest platform base tree into the remoteproc feature
tree. The merge pulls in the necessary base support for the OMAP-L138 SoCs
on the OMAP-L138 LCDK board using Device tree. The Davinci platforms are
supported using the davinci_all_defconfig config.
Other enhancements and fixes include:
- A new pinctrl driver for TI DA850/OMAP-L138/AM18XX SoCs
- Various fixes and cleanup to wkup_m3_ipc driver including the removal
of the remoteproc firmware_loading_complete completion variable
- Various hwmod fixes/enhancements on OMAP platforms
- Various PM / Wakeirq fixes
This merges establishes the baseline to allow to add the DT support to the
da8xx-remoteproc driver.
* 'platform-ti-linux-4.9.y-golden' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree: (90 commits)
ARM: OMAP2+: omap_device: Sync omap_device and pm_runtime after probe defer
soc: ti: wkup_m3_ipc: Drop wait from wkup_m3_rproc_boot_thread
soc: ti: wkup_m3_ipc: Fix error return code in wkup_m3_ipc_probe()
ARM: dts: dra7: Add power hold and power controller properties to palmas
ARM: dts: am4372: Add dma entries for UART nodes
pinctrl: ti: iodelay: Lower the priority of prints
thermal: arm: dra752: Remove all TSHUT related definitions
thermal: arm: dra752: Remove TSHUT configuration
ti_config_fragments: baseport: Enable CONFIG_KEXEC option for omap and keystone
ti_config_fragments: move crypto self tests under debug build
crypto: omap-des: Verify page zone of scatterlists before starting DMA
crypto: omap-aes: Verify page zone of scatterlists before starting DMA
crypto: omap-des: Use bool instead of int for omap_des_copy_needed()
crypto: omap-aes: Use bool instead of int for omap_aes_check_aligned()
ARM: dts: am437x-gp-evm: Add uart0 pinctrl default and sleep states
thermal: ti-soc-thermal: Call pm_power_off in emergency shutdown function
gpio: davinci: Assign first bank regs for unbanked case
soc: ti: wkup_m3_ipc: Fix wkup_m3_ipc debugfs entry
ti_config_fragments/defconfig_map.txt: introduce support for OMAP-L138
HACK: ARM: omap2+: prevent cpu1 reset for secure devices during boot
...
Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: OMAP2+: omap_device: Sync omap_device and pm_runtime after probe defer
Starting from commit 5de85b9d57ab ("PM / runtime: Re-init runtime PM
states at probe error and driver unbind") pm_runtime core now changes
device runtime_status back to after RPM_SUSPENDED after a probe defer.
Certain OMAP devices make use of "ti,no-idle-on-init" flag which causes
omap_device_enable to be called during the BUS_NOTIFY_ADD_DEVICE event
during probe, along with pm_runtime_set_active.
This call to pm_runtime_set_active typically will prevent a call to
pm_runtime_get in a driver probe function from re-enabling the
omap_device. However, in the case of a probe defer that happens before the
probe function is able to run, such as a missing pinctrl states defer,
pm_runtime_reinit will set the device as RPM_SUSPENDED and then once
driver probe is actually able to run, pm_runtime_get will see the device as
suspended and call through to the omap_device layer, attempting to enable
the already enabled omap_device and causing errors like this:
omap-gpmc 50000000.gpmc: omap_device: omap_device_enable() called from invalid state 1
omap-gpmc 50000000.gpmc: use pm_runtime_put_sync_suspend() in driver?
We can avoid this error by making sure the pm_runtime status of a device
matches the omap_device state before a probe attempt. By extending the
omap_device bus notifier to act on the BUS_NOTIFY_BIND_DRIVER event we
can check if a device is enabled in omap_device but with a pm_runtime
status of RPM_SUSPENDED and once again mark the device as RPM_ACTIVE to
avoid a second incorrect call to omap_device_enable.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Starting from commit 5de85b9d57ab ("PM / runtime: Re-init runtime PM
states at probe error and driver unbind") pm_runtime core now changes
device runtime_status back to after RPM_SUSPENDED after a probe defer.
Certain OMAP devices make use of "ti,no-idle-on-init" flag which causes
omap_device_enable to be called during the BUS_NOTIFY_ADD_DEVICE event
during probe, along with pm_runtime_set_active.
This call to pm_runtime_set_active typically will prevent a call to
pm_runtime_get in a driver probe function from re-enabling the
omap_device. However, in the case of a probe defer that happens before the
probe function is able to run, such as a missing pinctrl states defer,
pm_runtime_reinit will set the device as RPM_SUSPENDED and then once
driver probe is actually able to run, pm_runtime_get will see the device as
suspended and call through to the omap_device layer, attempting to enable
the already enabled omap_device and causing errors like this:
omap-gpmc 50000000.gpmc: omap_device: omap_device_enable() called from invalid state 1
omap-gpmc 50000000.gpmc: use pm_runtime_put_sync_suspend() in driver?
We can avoid this error by making sure the pm_runtime status of a device
matches the omap_device state before a probe attempt. By extending the
omap_device bus notifier to act on the BUS_NOTIFY_BIND_DRIVER event we
can check if a device is enabled in omap_device but with a pm_runtime
status of RPM_SUSPENDED and once again mark the device as RPM_ACTIVE to
avoid a second incorrect call to omap_device_enable.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
soc: ti: wkup_m3_ipc: Drop wait from wkup_m3_rproc_boot_thread
commit 36cc9fd9ce0fd0e4654890aa347d258616aef5fa upstream.
The function wkup_m3_rproc_boot_thread waits for asynchronous
firmware loading to parse the resource table before calling
rproc_boot(). However, as the resource table parsing has been
moved to rproc_boot(), there's no need to wait for the
asynchronous firmware loading completion. So, drop this.
CC: Dave Gerlach <d-gerlach@ti.com>
CC: Bjorn Andersson <bjorn.andersson@linaro.org>
Tested-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
[s-anna@ti.com: cherry-pick commit '36cc9fd9ce0f' from v4.11]
Signed-off-by: Suman Anna <s-anna@ti.com>
commit 36cc9fd9ce0fd0e4654890aa347d258616aef5fa upstream.
The function wkup_m3_rproc_boot_thread waits for asynchronous
firmware loading to parse the resource table before calling
rproc_boot(). However, as the resource table parsing has been
moved to rproc_boot(), there's no need to wait for the
asynchronous firmware loading completion. So, drop this.
CC: Dave Gerlach <d-gerlach@ti.com>
CC: Bjorn Andersson <bjorn.andersson@linaro.org>
Tested-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
[s-anna@ti.com: cherry-pick commit '36cc9fd9ce0f' from v4.11]
Signed-off-by: Suman Anna <s-anna@ti.com>
soc: ti: wkup_m3_ipc: Fix error return code in wkup_m3_ipc_probe()
commit 36b29eb30ee0f6c99f06bea406c23a3fd4cbb80b upstream.
Fix to return a negative error code from the kthread_run() error
handling case instead of 0, as done elsewhere in this function.
Fixes: cdd5de500b2c ("soc: ti: Add wkup_m3_ipc driver")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
[s-anna@ti.com: cherry-pick commit '36b29eb30ee0' from v4.10]
Signed-off-by: Suman Anna <s-anna@ti.com>
commit 36b29eb30ee0f6c99f06bea406c23a3fd4cbb80b upstream.
Fix to return a negative error code from the kthread_run() error
handling case instead of 0, as done elsewhere in this function.
Fixes: cdd5de500b2c ("soc: ti: Add wkup_m3_ipc driver")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
[s-anna@ti.com: cherry-pick commit '36b29eb30ee0' from v4.10]
Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: dts: dra7: Add power hold and power controller properties to palmas
Add power hold and power controller properties to palmas node.
This is needed to shutdown pmic correctly on boards with
powerhold set.
Signed-off-by: Keerthy <j-keerthy@ti.com>
Add power hold and power controller properties to palmas node.
This is needed to shutdown pmic correctly on boards with
powerhold set.
Signed-off-by: Keerthy <j-keerthy@ti.com>
ARM: dts: am4372: Add dma entries for UART nodes
Add dma entries to uart0 and uart3 nodes so that 8250_omap driver starts
using EDMA. Adding support only for uart0 and uart3 as these instance
are testable on the board.
Signed-off-by: Vignesh R <vigneshr@ti.com>
Add dma entries to uart0 and uart3 nodes so that 8250_omap driver starts
using EDMA. Adding support only for uart0 and uart3 as these instance
are testable on the board.
Signed-off-by: Vignesh R <vigneshr@ti.com>
pinctrl: ti: iodelay: Lower the priority of prints
Dont print every single iodelay register configuration - this is just
plain noise. Since this is useful debug information, just lower to debug
Signed-off-by: Nishanth Menon <nm@ti.com>
Dont print every single iodelay register configuration - this is just
plain noise. Since this is useful debug information, just lower to debug
Signed-off-by: Nishanth Menon <nm@ti.com>
thermal: arm: dra752: Remove all TSHUT related definitions
Upstream commit 2c189f492f921e29e9734eade8ef586993398fe9
No configuration needs to be done for TSHUT from software.
Hence remove all the unnecessary definitions.
Signed-off-by: Keerthy <j-keerthy@ti.com>
Upstream commit 2c189f492f921e29e9734eade8ef586993398fe9
No configuration needs to be done for TSHUT from software.
Hence remove all the unnecessary definitions.
Signed-off-by: Keerthy <j-keerthy@ti.com>
thermal: arm: dra752: Remove TSHUT configuration
Upstream commit 7104563bf3e725cdc82e9c7157f2debd45d2ac80
Technical Reference Manual [1] mandates that software should
not be configuring the thermal shutdown thresholds. Hence
removing TSHUT_CONFIG.
[1] http://www.ti.com/lit/ug/sprui30b/sprui30b.pdf
Signed-off-by: Keerthy <j-keerthy@ti.com>
Reported-by: Ravikumar Kattekola <rk@ti.com>
Upstream commit 7104563bf3e725cdc82e9c7157f2debd45d2ac80
Technical Reference Manual [1] mandates that software should
not be configuring the thermal shutdown thresholds. Hence
removing TSHUT_CONFIG.
[1] http://www.ti.com/lit/ug/sprui30b/sprui30b.pdf
Signed-off-by: Keerthy <j-keerthy@ti.com>
Reported-by: Ravikumar Kattekola <rk@ti.com>
ti_config_fragments: baseport: Enable CONFIG_KEXEC option for omap and keystone
Now that OMAP side also has the KEXEC functional along with
already enabled keystone devices. Enable the KEXEC options
in baseport.cfg which is common to both OMAP and Keystone.
Signed-off-by: Keerthy <j-keerthy@ti.com>
Now that OMAP side also has the KEXEC functional along with
already enabled keystone devices. Enable the KEXEC options
in baseport.cfg which is common to both OMAP and Keystone.
Signed-off-by: Keerthy <j-keerthy@ti.com>
ti_config_fragments: move crypto self tests under debug build
Move crypto self tests from release build to debug build only. This is
clearly a debug option rather than release feature. Potentially avoids
multiple issues also by disabling this feature by default.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Cc: Carlos Hernandez <ceh@ti.com>
Cc: Aparna Balasubramanian <aparnab@ti.com>
Move crypto self tests from release build to debug build only. This is
clearly a debug option rather than release feature. Potentially avoids
multiple issues also by disabling this feature by default.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Cc: Carlos Hernandez <ceh@ti.com>
Cc: Aparna Balasubramanian <aparnab@ti.com>
Merge branch 'rproc-linux-4.9.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-4.9.y
Pull in the updated remoteproc feature branch that includes a fix
to a SRCU deadlock with the remoteproc debugfs 'recovery' file.
* 'rproc-linux-4.9.y' of git://git.ti.com/rpmsg/remoteproc:
remoteproc: debugfs: fix a SRCU deadlock with recovery file
Signed-off-by: Suman Anna <s-anna@ti.com>
Pull in the updated remoteproc feature branch that includes a fix
to a SRCU deadlock with the remoteproc debugfs 'recovery' file.
* 'rproc-linux-4.9.y' of git://git.ti.com/rpmsg/remoteproc:
remoteproc: debugfs: fix a SRCU deadlock with recovery file
Signed-off-by: Suman Anna <s-anna@ti.com>
crypto: omap-des: Verify page zone of scatterlists before starting DMA
In certain platforms like DRA7xx having memory > 2GB with LPAE enabled
has a constraint that DMA can be done with the initial 2GB and marks it
as ZONE_DMA. But openssl when used with cryptodev does not make sure that
input buffer is DMA capable. So, adding a check to very if the input buffer
is capable of DMA.
Tested-by: Aparna Balasubramanian <aparnab@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
[t-kristo@ti.com: fixed compile error in case CONFIG_ZONE_DMA was not set]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
In certain platforms like DRA7xx having memory > 2GB with LPAE enabled
has a constraint that DMA can be done with the initial 2GB and marks it
as ZONE_DMA. But openssl when used with cryptodev does not make sure that
input buffer is DMA capable. So, adding a check to very if the input buffer
is capable of DMA.
Tested-by: Aparna Balasubramanian <aparnab@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
[t-kristo@ti.com: fixed compile error in case CONFIG_ZONE_DMA was not set]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
crypto: omap-aes: Verify page zone of scatterlists before starting DMA
In certain platforms like DRA7xx having memory > 2GB with LPAE enabled
has a constraint that DMA can be done with the initial 2GB and marks it
as ZONE_DMA. But openssl when used with cryptodev does not make sure that
input buffer is DMA capable. So, adding a check to very if the input buffer
is capable of DMA.
Tested-by: Aparna Balasubramanian <aparnab@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
[t-kristo@ti.com: fixed compile error in case CONFIG_ZONE_DMA was not set]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
In certain platforms like DRA7xx having memory > 2GB with LPAE enabled
has a constraint that DMA can be done with the initial 2GB and marks it
as ZONE_DMA. But openssl when used with cryptodev does not make sure that
input buffer is DMA capable. So, adding a check to very if the input buffer
is capable of DMA.
Tested-by: Aparna Balasubramanian <aparnab@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
[t-kristo@ti.com: fixed compile error in case CONFIG_ZONE_DMA was not set]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
crypto: omap-des: Use bool instead of int for omap_des_copy_needed()
omap_des_copy_needed() verifies whether the input buffer is aligned for DMA
or a new buffer is needed, but uses int for this verification.
So use bool instead of int.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
omap_des_copy_needed() verifies whether the input buffer is aligned for DMA
or a new buffer is needed, but uses int for this verification.
So use bool instead of int.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
crypto: omap-aes: Use bool instead of int for omap_aes_check_aligned()
omap_aes_check_aligned() verifies whether the input buffer is aligned for
DMA or not but uses int for this verification. So use bool instead of int.
Also rename the function to omap_aes_copy_needed() as it is not checking
for just alignment.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
omap_aes_check_aligned() verifies whether the input buffer is aligned for
DMA or not but uses int for this verification. So use bool instead of int.
Also rename the function to omap_aes_copy_needed() as it is not checking
for just alignment.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
ARM: dts: am437x-gp-evm: Add uart0 pinctrl default and sleep states
Currently uart0 uses pinctrl config set by bootloader so
create default state that can be restored after a suspend
event.
Also, modify uart0 pinctrl to include RTS and CTS pins as by
default these are not in a mode for optimal power savings.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
[nsekhar@ti.com: wrap commit description to 60 chars]
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
[vigneshr@ti.com: Use AM4372_IOPAD() macro]
Signed-off-by: Vignesh R <vigneshr@ti.com>
Currently uart0 uses pinctrl config set by bootloader so
create default state that can be restored after a suspend
event.
Also, modify uart0 pinctrl to include RTS and CTS pins as by
default these are not in a mode for optimal power savings.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
[nsekhar@ti.com: wrap commit description to 60 chars]
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
[vigneshr@ti.com: Use AM4372_IOPAD() macro]
Signed-off-by: Vignesh R <vigneshr@ti.com>
thermal: ti-soc-thermal: Call pm_power_off in emergency shutdown function
The core thermal framework already calls kernel_power_off
through order_power_off path. Calling kernel_power_off from
two places eventually led to shutdown though giving warning
dumps before shutting off PMIC. Replace kernel_power_off with
pm_power_off and directly shut off the PMIC.
Signed-off-by: Keerthy <j-keerthy@ti.com>
The core thermal framework already calls kernel_power_off
through order_power_off path. Calling kernel_power_off from
two places eventually led to shutdown though giving warning
dumps before shutting off PMIC. Replace kernel_power_off with
pm_power_off and directly shut off the PMIC.
Signed-off-by: Keerthy <j-keerthy@ti.com>
remoteproc: debugfs: fix a SRCU deadlock with recovery file
The remoteproc debugfs file 'recovery' interface is provided to
aid developers to halt an error recovery and perform a post-mortem
analysis of a remote processor before continuing with the error
recovery. A write operation on this file can be used to disable
the recovery, recover once or to re-enable the error recovery
without halting.
This debugfs file is created using the debugfs_create_file(), so
supports the file lifetime management support intrinsically by means
of the srcu construct in the debugfs core (added in 4.7 kernel). The
remoteproc recovery process when triggered also involves the caching
and removal of the current traces and creation of the last traces
which operate on the same debugfs srcu lock, causing an SRCU deadlock
with the following signature,
"Illegal synchronize_srcu() in same-type SRCU (or in RCU) read-side
critical section!".
Use the debugfs_create_file_unsafe() to create the recovery file in a
non-proxying operation mode to avoid this deadlock. The file lifetime
management for the corresponding file_operations is skipped for now as
the creation of this recovery file is failrly self-managed within the
remoteproc core. A long term solution would probably be to revise the
crash handler workqueue to perform just the recovery in the workqueue
function.
Signed-off-by: Suman Anna <s-anna@ti.com>
The remoteproc debugfs file 'recovery' interface is provided to
aid developers to halt an error recovery and perform a post-mortem
analysis of a remote processor before continuing with the error
recovery. A write operation on this file can be used to disable
the recovery, recover once or to re-enable the error recovery
without halting.
This debugfs file is created using the debugfs_create_file(), so
supports the file lifetime management support intrinsically by means
of the srcu construct in the debugfs core (added in 4.7 kernel). The
remoteproc recovery process when triggered also involves the caching
and removal of the current traces and creation of the last traces
which operate on the same debugfs srcu lock, causing an SRCU deadlock
with the following signature,
"Illegal synchronize_srcu() in same-type SRCU (or in RCU) read-side
critical section!".
Use the debugfs_create_file_unsafe() to create the recovery file in a
non-proxying operation mode to avoid this deadlock. The file lifetime
management for the corresponding file_operations is skipped for now as
the creation of this recovery file is failrly self-managed within the
remoteproc core. A long term solution would probably be to revise the
crash handler workqueue to perform just the recovery in the workqueue
function.
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'rproc-linux-4.9.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-4.9.y
Pull in the updated remoteproc feature branch that includes minor
improvements to the pruss_get() API in the PRUSS module to support
deferred probing in PRUSS client drivers.
* 'rproc-linux-4.9.y' of git://git.ti.com/rpmsg/remoteproc:
remoteproc: pruss: fix pruss_get() to support deferred probe in clients
Signed-off-by: Suman Anna <s-anna@ti.com>
Pull in the updated remoteproc feature branch that includes minor
improvements to the pruss_get() API in the PRUSS module to support
deferred probing in PRUSS client drivers.
* 'rproc-linux-4.9.y' of git://git.ti.com/rpmsg/remoteproc:
remoteproc: pruss: fix pruss_get() to support deferred probe in clients
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc: pruss: fix pruss_get() to support deferred probe in clients
Knowing the error cause in pruss_get() is required to implement deferred
probe in the prueth driver and other PRUSS client drivers: deferred probe
must take place only when the pruss device is not yet available, not when
it is never going to be available. Fix up the pruss_get() function to
return an appropriate error-scenario specific ERR_PTR instead of a NULL
value on all errors.
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
Acked-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Knowing the error cause in pruss_get() is required to implement deferred
probe in the prueth driver and other PRUSS client drivers: deferred probe
must take place only when the pruss device is not yet available, not when
it is never going to be available. Fix up the pruss_get() function to
return an appropriate error-scenario specific ERR_PTR instead of a NULL
value on all errors.
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
Acked-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'rproc-linux-4.9.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-4.9.y
Pull in the updated remoteproc feature branch that includes various
minor bug fixes in the OMAP remoteproc driver, specifically in the
probe path.
* 'rproc-linux-4.9.y' of git://git.ti.com/rpmsg/remoteproc:
remoteproc/omap: fix return values in some probe failure paths
remoteproc/omap: fix compatibles in omap_rproc_get_autosuspend_delay()
remoteproc/omap: check for all timer ops for watchdog timers
Signed-off-by: Suman Anna <s-anna@ti.com>
Pull in the updated remoteproc feature branch that includes various
minor bug fixes in the OMAP remoteproc driver, specifically in the
probe path.
* 'rproc-linux-4.9.y' of git://git.ti.com/rpmsg/remoteproc:
remoteproc/omap: fix return values in some probe failure paths
remoteproc/omap: fix compatibles in omap_rproc_get_autosuspend_delay()
remoteproc/omap: check for all timer ops for watchdog timers
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc/omap: fix return values in some probe failure paths
The OMAP remoteproc probe is returning success on some failure
code paths, even though the function actually failed and all
necessary cleanup has been performed. This results in an invalid
device being bound to the driver from the driver core perspective
and causes a crash when the driver's remove function is invoked
on this failed rproc device during the removal of the module.
Fix these failure code paths by initializing the return variable
appropriately.
Signed-off-by: Suman Anna <s-anna@ti.com>
The OMAP remoteproc probe is returning success on some failure
code paths, even though the function actually failed and all
necessary cleanup has been performed. This results in an invalid
device being bound to the driver from the driver core perspective
and causes a crash when the driver's remove function is invoked
on this failed rproc device during the removal of the module.
Fix these failure code paths by initializing the return variable
appropriately.
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc/omap: fix compatibles in omap_rproc_get_autosuspend_delay()
The omap_rproc_get_autosuspend_delay() function uses incorrect
compatible name checks while retrieving the autosuspend delay
values. These incorrect checks result in using the autosuspend
delay value from the first device defined in the dra7_rproc_dev_data
array structure for all the devices in DRA7xx/AM57xx SoCs. There
is no value defined at present resulting in returning the default
autosuspend delay value for all DRA7xx OMAP remoteproc devices,
and thereby masking the error in logic. Fix this logic to use the
proper compatible names so that the corresponding device value is
used to derive the respective device's autosuspend delay properly.
Fixes: 0c0f1e44cf34 ("remoteproc/omap: add support for runtime auto-suspend/resume")
Signed-off-by: Suman Anna <s-anna@ti.com>
The omap_rproc_get_autosuspend_delay() function uses incorrect
compatible name checks while retrieving the autosuspend delay
values. These incorrect checks result in using the autosuspend
delay value from the first device defined in the dra7_rproc_dev_data
array structure for all the devices in DRA7xx/AM57xx SoCs. There
is no value defined at present resulting in returning the default
autosuspend delay value for all DRA7xx OMAP remoteproc devices,
and thereby masking the error in logic. Fix this logic to use the
proper compatible names so that the corresponding device value is
used to derive the respective device's autosuspend delay properly.
Fixes: 0c0f1e44cf34 ("remoteproc/omap: add support for runtime auto-suspend/resume")
Signed-off-by: Suman Anna <s-anna@ti.com>