author | Suman Anna <s-anna@ti.com> | |
Mon, 2 Feb 2015 21:42:51 +0000 (15:42 -0600) | ||
committer | Suman Anna <s-anna@ti.com> | |
Tue, 3 Feb 2015 00:55:14 +0000 (18:55 -0600) | ||
commit | e707094abaf42a3dfa27cc419db899e1c6d7b012 | |
tree | 0a8704cf4b807d0cf8291e9d859e4466a22efcf5 | tree | snapshot (tar.xz tar.gz zip) |
parent | 33a427b820334985a108cf909a22d3b21b18ff0f | commit | diff |
remoteproc/pruss: fix shutdown for manually booted PRU cores
The remoteproc infrastructure auto-boots the processors that have
support for virtio transports. The remoteproc virtio layer also
handles the shutdown for such remoteproc devices, but not for
processors booted outside the remoteproc virtio layer.
The current PRU remoteproc driver also provides support to manually
boot a PRU processor if there are no virtio devices associated with
the processor (standalone functionality without any communication
with the MPU, usually used in a configuration where one of the PRU
cores is used in a slave-mode and complements the functionality
implemented on the other PRU core). The manual boot is done during
the probe of the PRU rproc driver, but it isn't handling the shutdown
of the PRU processor, so the same has been fixed.
This also fixes an issue with the module reference count of the PRUSS
remoteproc module. The rproc_boot() function holds a reference count
to the module implementing the driver for the corresponding remoteproc
device. The PRUSS remoteproc module implements two platform drivers -
one for the PRUSS subsystem, and the other to deal with the individual
PRU cores, and as such the module reference count module is incremented
for every booted processor, and is decremented properly only when the
corresponding processor is shutdown. Without the fix, the reference
count is never decremented when the PRU rproc device or the parent
PRUSS subsystem device is unbound from their corresponding drivers.
NOTE:
The rmmod of the PRUSS remoteproc module can only succeed when the
PRU/PRUSS devices are unbound from their drivers, if there were any
manually booted PRU cores. Ideally, the boot would have to be
implemented in a different layer to avoid this issue.
Signed-off-by: Suman Anna <s-anna@ti.com>
The remoteproc infrastructure auto-boots the processors that have
support for virtio transports. The remoteproc virtio layer also
handles the shutdown for such remoteproc devices, but not for
processors booted outside the remoteproc virtio layer.
The current PRU remoteproc driver also provides support to manually
boot a PRU processor if there are no virtio devices associated with
the processor (standalone functionality without any communication
with the MPU, usually used in a configuration where one of the PRU
cores is used in a slave-mode and complements the functionality
implemented on the other PRU core). The manual boot is done during
the probe of the PRU rproc driver, but it isn't handling the shutdown
of the PRU processor, so the same has been fixed.
This also fixes an issue with the module reference count of the PRUSS
remoteproc module. The rproc_boot() function holds a reference count
to the module implementing the driver for the corresponding remoteproc
device. The PRUSS remoteproc module implements two platform drivers -
one for the PRUSS subsystem, and the other to deal with the individual
PRU cores, and as such the module reference count module is incremented
for every booted processor, and is decremented properly only when the
corresponding processor is shutdown. Without the fix, the reference
count is never decremented when the PRU rproc device or the parent
PRUSS subsystem device is unbound from their corresponding drivers.
NOTE:
The rmmod of the PRUSS remoteproc module can only succeed when the
PRU/PRUSS devices are unbound from their drivers, if there were any
manually booted PRU cores. Ideally, the boot would have to be
implemented in a different layer to avoid this issue.
Signed-off-by: Suman Anna <s-anna@ti.com>
drivers/remoteproc/pruss_remoteproc.c | diff | blob | history |