5 years agoMerge branch 'ti-linux-4.19.y-for-next' of git://git.ti.com/linux-phy/kishons-ti... ti-linux-4.19.y-next-20190323
Merge branch 'ti-linux-4.19.y-for-next' of git://git.ti.com/linux-phy/kishons-ti-linux-kernel into ti-linux-4.19.y-next
TI-Feature: kishon_next
TI-Tree: git://git.ti.com/linux-phy/kishons-ti-linux-kernel.git
TI-Branch: ti-linux-4.19.y-for-next
* 'ti-linux-4.19.y-for-next' of git://git.ti.com/linux-phy/kishons-ti-linux-kernel:
ARM: dts: k2e-evm: enable PCIe on port 1
ARM: dts: keystone-k2e: Use the updated binding to describe PCIe in k2e
ARM: keystone: dts: add PCI serdes driver bindings
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
TI-Feature: kishon_next
TI-Tree: git://git.ti.com/linux-phy/kishons-ti-linux-kernel.git
TI-Branch: ti-linux-4.19.y-for-next
* 'ti-linux-4.19.y-for-next' of git://git.ti.com/linux-phy/kishons-ti-linux-kernel:
ARM: dts: k2e-evm: enable PCIe on port 1
ARM: dts: keystone-k2e: Use the updated binding to describe PCIe in k2e
ARM: keystone: dts: add PCI serdes driver bindings
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
Merge branch 'rpmsg-ti-linux-4.19.y-next' of git://git.ti.com/rpmsg/rpmsg into ti-linux-4.19.y-next
TI-Feature: rpmsg_next
TI-Tree: git://git.ti.com/rpmsg/rpmsg.git
TI-Branch: rpmsg-ti-linux-4.19.y-next
* 'rpmsg-ti-linux-4.19.y-next' of git://git.ti.com/rpmsg/rpmsg:
remoteproc: Add a sysfs interface for name
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
TI-Feature: rpmsg_next
TI-Tree: git://git.ti.com/rpmsg/rpmsg.git
TI-Branch: rpmsg-ti-linux-4.19.y-next
* 'rpmsg-ti-linux-4.19.y-next' of git://git.ti.com/rpmsg/rpmsg:
remoteproc: Add a sysfs interface for name
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
Merge branch 'connectivity-next' of git://git.ti.com/~nsekhar/ti-linux-kernel/nsekhar-ti-linux-kernel into ti-linux-4.19.y-next
TI-Feature: connectivity_next
TI-Tree: git://git.ti.com/~nsekhar/ti-linux-kernel/nsekhar-ti-linux-kernel.git
TI-Branch: connectivity-next
* 'connectivity-next' of git://git.ti.com/~nsekhar/ti-linux-kernel/nsekhar-ti-linux-kernel:
ARM: dts: k2e-evm: enable PCIe on port 1
ARM: dts: keystone-k2e: Use the updated binding to describe PCIe in k2e
ARM: keystone: dts: add PCI serdes driver bindings
arm64: dts: ti:k3-am6: Add DMA entries for UART nodes
serial: 8250_omap: Add DMA support for UARTs on AM654 SoC
serial: 8250_omap: Extend driver data to pass FIFO trigger info
serial: 8250_omap: Account for data in flight during DMA teardown
serial: 8250_omap: Terminate DMA before pushing data on RX timeout
serial: 8250_omap: Work around errata spurious IRQs with DMA
phy: ti-pipe3: Fix PCIe power up sequence
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
TI-Feature: connectivity_next
TI-Tree: git://git.ti.com/~nsekhar/ti-linux-kernel/nsekhar-ti-linux-kernel.git
TI-Branch: connectivity-next
* 'connectivity-next' of git://git.ti.com/~nsekhar/ti-linux-kernel/nsekhar-ti-linux-kernel:
ARM: dts: k2e-evm: enable PCIe on port 1
ARM: dts: keystone-k2e: Use the updated binding to describe PCIe in k2e
ARM: keystone: dts: add PCI serdes driver bindings
arm64: dts: ti:k3-am6: Add DMA entries for UART nodes
serial: 8250_omap: Add DMA support for UARTs on AM654 SoC
serial: 8250_omap: Extend driver data to pass FIFO trigger info
serial: 8250_omap: Account for data in flight during DMA teardown
serial: 8250_omap: Terminate DMA before pushing data on RX timeout
serial: 8250_omap: Work around errata spurious IRQs with DMA
phy: ti-pipe3: Fix PCIe power up sequence
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
Merge branch 'audio_display-ti-linux-4.19.y' of git.ti.com:~jyrisarha/ti-linux-kernel/jyrisarhas-audio-video-linux-feature-tree into ti-linux-4.19.y
TI-Feature: audio-display
TI-Tree: git@git.ti.com:~jyrisarha/ti-linux-kernel/jyrisarhas-audio-video-linux-feature-tree.git
TI-Branch: audio_display-ti-linux-4.19.y
* 'audio_display-ti-linux-4.19.y' of git.ti.com:~jyrisarha/ti-linux-kernel/jyrisarhas-audio-video-linux-feature-tree:
drm/atomic: integrate private objects with suspend/resume helpers
drm/omap: Use builtin locking with private objects
drm/atomic: integrate modeset lock with private objects
drm/omap: Fix omapdrm_init error path
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
TI-Feature: audio-display
TI-Tree: git@git.ti.com:~jyrisarha/ti-linux-kernel/jyrisarhas-audio-video-linux-feature-tree.git
TI-Branch: audio_display-ti-linux-4.19.y
* 'audio_display-ti-linux-4.19.y' of git.ti.com:~jyrisarha/ti-linux-kernel/jyrisarhas-audio-video-linux-feature-tree:
drm/atomic: integrate private objects with suspend/resume helpers
drm/omap: Use builtin locking with private objects
drm/atomic: integrate modeset lock with private objects
drm/omap: Fix omapdrm_init error path
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
Merge branch 'platform-ti-linux-4.19.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree into ti-linux-4.19.y
TI-Feature: platform_base
TI-Tree: git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree.git
TI-Branch: platform-ti-linux-4.19.y
* 'platform-ti-linux-4.19.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree:
clk: ti: dra7: disable the RNG and TIMER12 clkctrl clocks on HS devices
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
TI-Feature: platform_base
TI-Tree: git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree.git
TI-Branch: platform-ti-linux-4.19.y
* 'platform-ti-linux-4.19.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree:
clk: ti: dra7: disable the RNG and TIMER12 clkctrl clocks on HS devices
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
ARM: dts: k2e-evm: enable PCIe on port 1
PCIe is disabled in the SoC specific DTS file. K2E EVM has Marvell SATA
controller connected to port1. To enable SATA over PCIe, set the status to
"okay" in K2E EVM dts file.
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
PCIe is disabled in the SoC specific DTS file. K2E EVM has Marvell SATA
controller connected to port1. To enable SATA over PCIe, set the status to
"okay" in K2E EVM dts file.
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
ARM: dts: keystone-k2e: Use the updated binding to describe PCIe in k2e
Use the updated binding to describe PCIe in k2e. (The older binding has
never worked in upstream kernel since serdes driver was never upstreamed).
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Use the updated binding to describe PCIe in k2e. (The older binding has
never worked in upstream kernel since serdes driver was never upstreamed).
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
ARM: keystone: dts: add PCI serdes driver bindings
This patch adds the serdes phy driver dts bindings
for the keystone PCIe host driver.
Signed-off-by: WingMan Kwok <w-kwok2@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
This patch adds the serdes phy driver dts bindings
for the keystone PCIe host driver.
Signed-off-by: WingMan Kwok <w-kwok2@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
clk: ti: dra7: disable the RNG and TIMER12 clkctrl clocks on HS devices
RNG and TIMER12 are reserved for secure side usage only on HS devices,
so disable their clkctrl clocks on HS SoCs also.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Tested-by: Andrew F. Davis <afd@ti.com>
RNG and TIMER12 are reserved for secure side usage only on HS devices,
so disable their clkctrl clocks on HS SoCs also.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Tested-by: Andrew F. Davis <afd@ti.com>
arm64: dts: ti:k3-am6: Add DMA entries for UART nodes
Add DMA entries for MCU UART0, MAIN UART0,1,2.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Add DMA entries for MCU UART0, MAIN UART0,1,2.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
serial: 8250_omap: Add DMA support for UARTs on AM654 SoC
Unlike, older OMAP SoCs, AM654 SoC has configurable RX timeout behavior
(controlled via EFR2) and better DMA integration. This allows to
transfer as larger amount data per DMA transfer compared to older SoC.
Add support for the same.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Unlike, older OMAP SoCs, AM654 SoC has configurable RX timeout behavior
(controlled via EFR2) and better DMA integration. This allows to
transfer as larger amount data per DMA transfer compared to older SoC.
Add support for the same.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
serial: 8250_omap: Extend driver data to pass FIFO trigger info
Although same 8250 compliant UART IP is reused across different SoC,
their integration wrt DMA varies greatly across SoCs. Therefore,
different SoC may need to use different FIFO trigger level for DMA
event and DMA configuration parameters. Provide a way to pass this
information via driver data. This is required to support UART DMA on
AM654 SoC.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Although same 8250 compliant UART IP is reused across different SoC,
their integration wrt DMA varies greatly across SoCs. Therefore,
different SoC may need to use different FIFO trigger level for DMA
event and DMA configuration parameters. Provide a way to pass this
information via driver data. This is required to support UART DMA on
AM654 SoC.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
serial: 8250_omap: Account for data in flight during DMA teardown
Take into account data stuck in DMA internal buffers before pushing data to
higher layer. dma_tx_state has "in_flight_bytes" member that provides this
information.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Take into account data stuck in DMA internal buffers before pushing data to
higher layer. dma_tx_state has "in_flight_bytes" member that provides this
information.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
serial: 8250_omap: Terminate DMA before pushing data on RX timeout
Terminate and flush DMA internal buffers, before pushing RX data to
higher layer. Otherwise, this will lead to data corruption, as driver
would end up pushing stale buffer data to higher layer while actual data
is still stuck inside DMA hardware and has yet not arrived at the
memory.
While at that, replace deprecated dmaengine_terminate_all() with
dmaengine_terminate_async().
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Terminate and flush DMA internal buffers, before pushing RX data to
higher layer. Otherwise, this will lead to data corruption, as driver
would end up pushing stale buffer data to higher layer while actual data
is still stuck inside DMA hardware and has yet not arrived at the
memory.
While at that, replace deprecated dmaengine_terminate_all() with
dmaengine_terminate_async().
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
serial: 8250_omap: Work around errata spurious IRQs with DMA
As per Advisory 27 of AM437x Silicon errata document, Spurious UART
interrupts may occur when DMA mode (FCR.DMA_MODE) is enabled. The
Interrupt Controller flags that a UART interrupt has occurred; however,
the associated IT_PENDING bit remains set to 1, indicating that no
interrupt is pending. Acknowledge the spurious interrupts for every
occurrence as workaround.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
As per Advisory 27 of AM437x Silicon errata document, Spurious UART
interrupts may occur when DMA mode (FCR.DMA_MODE) is enabled. The
Interrupt Controller flags that a UART interrupt has occurred; however,
the associated IT_PENDING bit remains set to 1, indicating that no
interrupt is pending. Acknowledge the spurious interrupts for every
occurrence as workaround.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
phy: ti-pipe3: Fix PCIe power up sequence
TRM [1] mentions that we need to power up
PCIESS_PHY_TX and PCIESS_PHY_RX before configuring
PCIe_PHY_RX SCP settings.
See "Table 26-81. PCIePHY Subsystem Low-Level Programming Sequence".
[1] DRA75x, DRA74x TRM - http://www.ti.com/lit/ug/sprui30f/sprui30f.pdf
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
TRM [1] mentions that we need to power up
PCIESS_PHY_TX and PCIESS_PHY_RX before configuring
PCIe_PHY_RX SCP settings.
See "Table 26-81. PCIePHY Subsystem Low-Level Programming Sequence".
[1] DRA75x, DRA74x TRM - http://www.ti.com/lit/ug/sprui30f/sprui30f.pdf
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Merge branch 'for19.00.04' of git.ti.com:~bparrot/ti-linux-kernel/bp-ti-linux into audio_display-ti-linux-4.19.y
2019.00 drm fixes
* 'for19.00.04' of git.ti.com:~bparrot/ti-linux-kernel/bp-ti-linux:
drm/atomic: integrate private objects with suspend/resume helpers
drm/omap: Use builtin locking with private objects
drm/atomic: integrate modeset lock with private objects
drm/omap: Fix omapdrm_init error path
2019.00 drm fixes
* 'for19.00.04' of git.ti.com:~bparrot/ti-linux-kernel/bp-ti-linux:
drm/atomic: integrate private objects with suspend/resume helpers
drm/omap: Use builtin locking with private objects
drm/atomic: integrate modeset lock with private objects
drm/omap: Fix omapdrm_init error path
remoteproc: Add a sysfs interface for name
This patch adds a sysfs interface that provides the name of the
remote processor to userspace. This allows the userspace to identify
a remote processor as the remoteproc devices themselves are created
based on probe order and can change from one boot to another or
at runtime.
The name is made available in debugfs originally, and is being
retained for now. This can be cleaned up after couple of releases
once users get familiar with the new interface.
Signed-off-by: Suman Anna <s-anna@ti.com>
This patch adds a sysfs interface that provides the name of the
remote processor to userspace. This allows the userspace to identify
a remote processor as the remoteproc devices themselves are created
based on probe order and can change from one boot to another or
at runtime.
The name is made available in debugfs originally, and is being
retained for now. This can be cleaned up after couple of releases
once users get familiar with the new interface.
Signed-off-by: Suman Anna <s-anna@ti.com>
drm/atomic: integrate private objects with suspend/resume helpers
During a suspend cycle the atomic state is saved to be used during the
restore cycle.
However the current state duplication logic does not duplicate private
objects. This leads to state inconsistencies at resume time.
With private objects modeset lock now integrated, we can make sure that
private object state are properly saved and restored.
Signed-off-by: Benoit Parrot <bparrot@ti.com>
During a suspend cycle the atomic state is saved to be used during the
restore cycle.
However the current state duplication logic does not duplicate private
objects. This leads to state inconsistencies at resume time.
With private objects modeset lock now integrated, we can make sure that
private object state are properly saved and restored.
Signed-off-by: Benoit Parrot <bparrot@ti.com>
drm/omap: Use builtin locking with private objects
Since modeset lock have been integrated into private objects, update
omap hw overlay to use this mechanism instead of the ad hoc method.
drm_mode_config_init() needs to be called earlier because it also now
creates/initializes the private_obj link list maintained by the
atomic framework. The private_obj link list has to exist prior to
calling drm_atomic_private_obj_init(). Similarly the cleanup handler are
reordered appropriately.
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Since modeset lock have been integrated into private objects, update
omap hw overlay to use this mechanism instead of the ad hoc method.
drm_mode_config_init() needs to be called earlier because it also now
creates/initializes the private_obj link list maintained by the
atomic framework. The private_obj link list has to exist prior to
calling drm_atomic_private_obj_init(). Similarly the cleanup handler are
reordered appropriately.
Signed-off-by: Benoit Parrot <bparrot@ti.com>
drm/atomic: integrate modeset lock with private objects
commit b962a12050a387e4bbf3a48745afe1d29d396b0d upstream.
Follow the same pattern of locking as with other state objects. This
avoids boilerplate in the driver.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20181022123122.30468-1-boris.brezillon@bootlin.com
commit b962a12050a387e4bbf3a48745afe1d29d396b0d upstream.
Follow the same pattern of locking as with other state objects. This
avoids boilerplate in the driver.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20181022123122.30468-1-boris.brezillon@bootlin.com
drm/omap: Fix omapdrm_init error path
When adding support for hw_overlays and global state object, the order
in which the cleanup was added to the error path was wrong, as things
should be cleaned up the reverse order in which they were created.
Fixes: 730a8131571c ("drm/omap: Add global state as a private atomic object")
Fixes: 974e39a9cbae ("drm/omap: introduce omap_hw_overlay")
Signed-off-by: Benoit Parrot <bparrot@ti.com>
When adding support for hw_overlays and global state object, the order
in which the cleanup was added to the error path was wrong, as things
should be cleaned up the reverse order in which they were created.
Fixes: 730a8131571c ("drm/omap: Add global state as a private atomic object")
Fixes: 974e39a9cbae ("drm/omap: introduce omap_hw_overlay")
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Merge branch 'platform-ti-linux-4.19.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree into ti-linux-4.19.y
TI-Feature: platform_base
TI-Tree: git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree.git
TI-Branch: platform-ti-linux-4.19.y
* 'platform-ti-linux-4.19.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree:
clk: ti: am33xx: drop idlest polling from gfx clkctrl clock
clk: ti: am43xx: drop idlest polling from gfx clkctrl clock
crypto: omap-aes: remove the sysfs group during driver removal
crypto: omap-sham: remove the sysfs group during driver removal
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
TI-Feature: platform_base
TI-Tree: git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree.git
TI-Branch: platform-ti-linux-4.19.y
* 'platform-ti-linux-4.19.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree:
clk: ti: am33xx: drop idlest polling from gfx clkctrl clock
clk: ti: am43xx: drop idlest polling from gfx clkctrl clock
crypto: omap-aes: remove the sysfs group during driver removal
crypto: omap-sham: remove the sysfs group during driver removal
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
clk: ti: am33xx: drop idlest polling from gfx clkctrl clock
The GFX modules on AM33xx SoCs have a hardreset line and are controlled
by a GFX reset line. Any clkctrl enable/disable operations cannot be
checked for module enabled/disabled status independent of the reset
operation, and this causes some unwanted timeouts in the kernel and
unbalanced states for the GFX clocks. These details should be handled
by the driver integration code itself.
Signed-off-by: Eric Ruei <e-ruei1@ti.com>
The GFX modules on AM33xx SoCs have a hardreset line and are controlled
by a GFX reset line. Any clkctrl enable/disable operations cannot be
checked for module enabled/disabled status independent of the reset
operation, and this causes some unwanted timeouts in the kernel and
unbalanced states for the GFX clocks. These details should be handled
by the driver integration code itself.
Signed-off-by: Eric Ruei <e-ruei1@ti.com>
clk: ti: am43xx: drop idlest polling from gfx clkctrl clock
The GFX modules on AM43xx SoCs have a hardreset line and are controlled
by a GFX reset line. Any clkctrl enable/disable operations cannot be
checked for module enabled/disabled status independent of the reset
operation, and this causes some unwanted timeouts in the kernel and
unbalanced states for the GFX clocks. These details should be handled
by the driver integration code itself.
Add the CLKF_NO_IDLEST flag to the GFX clkctrl clock so that these
module status checks are skipped.
Signed-off-by: Eric Ruei <e-ruei1@ti.com>
The GFX modules on AM43xx SoCs have a hardreset line and are controlled
by a GFX reset line. Any clkctrl enable/disable operations cannot be
checked for module enabled/disabled status independent of the reset
operation, and this causes some unwanted timeouts in the kernel and
unbalanced states for the GFX clocks. These details should be handled
by the driver integration code itself.
Add the CLKF_NO_IDLEST flag to the GFX clkctrl clock so that these
module status checks are skipped.
Signed-off-by: Eric Ruei <e-ruei1@ti.com>
Merge branch 'connectivity-ti-linux-4.19.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel into ti-linux-4.19.y
TI-Feature: connectivity
TI-Tree: git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel.git
TI-Branch: connectivity-ti-linux-4.19.y
* 'connectivity-ti-linux-4.19.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel:
HACK: net: ethernet: ti: cpsw: allow to configure min tx packet size
phy: ti-pipe3: Fix SATA & USB PHY power up sequence
phy: ti-pipe3: improve DPLL stability for SATA & USB
phy: ti-pipe3: Introduce mode property in driver data
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
TI-Feature: connectivity
TI-Tree: git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel.git
TI-Branch: connectivity-ti-linux-4.19.y
* 'connectivity-ti-linux-4.19.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel:
HACK: net: ethernet: ti: cpsw: allow to configure min tx packet size
phy: ti-pipe3: Fix SATA & USB PHY power up sequence
phy: ti-pipe3: improve DPLL stability for SATA & USB
phy: ti-pipe3: Introduce mode property in driver data
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
crypto: omap-aes: remove the sysfs group during driver removal
The driver removal should also cleanup the created sysfs group. If not,
the driver fails the subsequent probe as the files exist already. Also,
drop a completely unnecessary pointer assignment from the removal
function at the same time.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
The driver removal should also cleanup the created sysfs group. If not,
the driver fails the subsequent probe as the files exist already. Also,
drop a completely unnecessary pointer assignment from the removal
function at the same time.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
crypto: omap-sham: remove the sysfs group during driver removal
The driver removal should also cleanup the created sysfs group. If not,
the driver fails the subsequent probe as the files exist already.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
The driver removal should also cleanup the created sysfs group. If not,
the driver fails the subsequent probe as the files exist already.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
HACK: net: ethernet: ti: cpsw: allow to configure min tx packet size
For proper VLAN packets forwarding CPSW driver uses min tx packet size of
64bytes (VLAN_ETH_ZLEN, excluding ETH_FCS) which was corrected by
commit 9421c9015047 ("net: ethernet: ti: cpsw: fix min eth packet size").
Unfortunately, this breaks some industrial automation protocols, as
reported by TI customers [1], which can work only with min TX packet size
from 60 byte (ecluding FCS).
Hence, introduce module boot parameter "tx_packet_min" to allow configure
min TX packet size at boot time.
LKML link:
https://patchwork.kernel.org/patch/10697191/
[1] https://e2e.ti.com/support/arm/sitara_arm/f/791/t/701669
Fixes: 9421c9015047 ("net: ethernet: ti: cpsw: fix min eth packet size")
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
For proper VLAN packets forwarding CPSW driver uses min tx packet size of
64bytes (VLAN_ETH_ZLEN, excluding ETH_FCS) which was corrected by
commit 9421c9015047 ("net: ethernet: ti: cpsw: fix min eth packet size").
Unfortunately, this breaks some industrial automation protocols, as
reported by TI customers [1], which can work only with min TX packet size
from 60 byte (ecluding FCS).
Hence, introduce module boot parameter "tx_packet_min" to allow configure
min TX packet size at boot time.
LKML link:
https://patchwork.kernel.org/patch/10697191/
[1] https://e2e.ti.com/support/arm/sitara_arm/f/791/t/701669
Fixes: 9421c9015047 ("net: ethernet: ti: cpsw: fix min eth packet size")
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
phy: ti-pipe3: Fix SATA & USB PHY power up sequence
As per "Table 26-7. SATA PHY Subsystem Low-Level Programming Sequence"
in TRM [1] we need to turn on SATA_PHY_TX before SATA_PHY_RX.
[1] DRA75x, DRA74x TRM - http://www.ti.com/lit/ug/sprui30f/sprui30f.pdf
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
As per "Table 26-7. SATA PHY Subsystem Low-Level Programming Sequence"
in TRM [1] we need to turn on SATA_PHY_TX before SATA_PHY_RX.
[1] DRA75x, DRA74x TRM - http://www.ti.com/lit/ug/sprui30f/sprui30f.pdf
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
phy: ti-pipe3: improve DPLL stability for SATA & USB
For increased DPLL stability use the settings recommended in
the TRM [1] for PHY_RX registers for SATA and USB.
For SATA we need to use spread spectrum settings even
though we don't have spread spectrum enabled. The
suggested non-spread spectrum settings don't work.
[1] DRA75x, DRA74x TRM - http://www.ti.com/lit/ug/sprui30f/sprui30f.pdf
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
For increased DPLL stability use the settings recommended in
the TRM [1] for PHY_RX registers for SATA and USB.
For SATA we need to use spread spectrum settings even
though we don't have spread spectrum enabled. The
suggested non-spread spectrum settings don't work.
[1] DRA75x, DRA74x TRM - http://www.ti.com/lit/ug/sprui30f/sprui30f.pdf
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
phy: ti-pipe3: Introduce mode property in driver data
Introduce a mode property in the driver data so that
we don't have to keep using "of_device_is_compatible()"
throughtout the driver.
No functional change.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Introduce a mode property in the driver data so that
we don't have to keep using "of_device_is_compatible()"
throughtout the driver.
No functional change.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
ARM: dts: k2e-evm: enable PCIe on port 1
PCIe is disabled in the SoC specific DTS file. K2E EVM has Marvell SATA
controller connected to port1. To enable SATA over PCIe, set the status to
"okay" in K2E EVM dts file.
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
PCIe is disabled in the SoC specific DTS file. K2E EVM has Marvell SATA
controller connected to port1. To enable SATA over PCIe, set the status to
"okay" in K2E EVM dts file.
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
ARM: dts: keystone-k2e: Use the updated binding to describe PCIe in k2e
Use the updated binding to describe PCIe in k2e. (The older binding has
never worked in upstream kernel since serdes driver was never upstreamed).
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Use the updated binding to describe PCIe in k2e. (The older binding has
never worked in upstream kernel since serdes driver was never upstreamed).
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
ARM: keystone: dts: add PCI serdes driver bindings
This patch adds the serdes phy driver dts bindings
for the keystone PCIe host driver.
Signed-off-by: WingMan Kwok <w-kwok2@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
This patch adds the serdes phy driver dts bindings
for the keystone PCIe host driver.
Signed-off-by: WingMan Kwok <w-kwok2@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Merge branch 'connectivity-ti-linux-4.19.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel into ti-linux-4.19.y
TI-Feature: connectivity
TI-Tree: git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel.git
TI-Branch: connectivity-ti-linux-4.19.y
* 'connectivity-ti-linux-4.19.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel:
ti_config_fragments/connectivity.cfg: enable nl80211 testmode command
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
TI-Feature: connectivity
TI-Tree: git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel.git
TI-Branch: connectivity-ti-linux-4.19.y
* 'connectivity-ti-linux-4.19.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel:
ti_config_fragments/connectivity.cfg: enable nl80211 testmode command
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
Merge branch 'audio_display-ti-linux-4.19.y' of git.ti.com:~jyrisarha/ti-linux-kernel/jyrisarhas-audio-video-linux-feature-tree into ti-linux-4.19.y
TI-Feature: audio-display
TI-Tree: git@git.ti.com:~jyrisarha/ti-linux-kernel/jyrisarhas-audio-video-linux-feature-tree.git
TI-Branch: audio_display-ti-linux-4.19.y
* 'audio_display-ti-linux-4.19.y' of git.ti.com:~jyrisarha/ti-linux-kernel/jyrisarhas-audio-video-linux-feature-tree:
media: ov490: Fix module auto-loading issue
media: ov1063x: Fix module auto-loading issue
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
TI-Feature: audio-display
TI-Tree: git@git.ti.com:~jyrisarha/ti-linux-kernel/jyrisarhas-audio-video-linux-feature-tree.git
TI-Branch: audio_display-ti-linux-4.19.y
* 'audio_display-ti-linux-4.19.y' of git.ti.com:~jyrisarha/ti-linux-kernel/jyrisarhas-audio-video-linux-feature-tree:
media: ov490: Fix module auto-loading issue
media: ov1063x: Fix module auto-loading issue
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
Merge branch 'for19.00.03' of git.ti.com:~bparrot/ti-linux-kernel/bp-ti-linux into audio_display-ti-linux-4.19.y
2019.00 camera fixes
* 'for19.00.03' of git.ti.com:~bparrot/ti-linux-kernel/bp-ti-linux:
media: ov490: Fix module auto-loading issue
media: ov1063x: Fix module auto-loading issue
2019.00 camera fixes
* 'for19.00.03' of git.ti.com:~bparrot/ti-linux-kernel/bp-ti-linux:
media: ov490: Fix module auto-loading issue
media: ov1063x: Fix module auto-loading issue
media: ov490: Fix module auto-loading issue
Module is no longer auto-loading.
Add the of_device_id table to MODULE_DEVICE_TABLE.
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Module is no longer auto-loading.
Add the of_device_id table to MODULE_DEVICE_TABLE.
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
media: ov1063x: Fix module auto-loading issue
Module is no longer auto-loading.
Add the of_device_id table to MODULE_DEVICE_TABLE.
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Module is no longer auto-loading.
Add the of_device_id table to MODULE_DEVICE_TABLE.
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Merge branch 'audio_display-ti-linux-4.19.y' of git.ti.com:~jyrisarha/ti-linux-kernel/jyrisarhas-audio-video-linux-feature-tree into ti-linux-4.19.y
TI-Feature: audio-display
TI-Tree: git@git.ti.com:~jyrisarha/ti-linux-kernel/jyrisarhas-audio-video-linux-feature-tree.git
TI-Branch: audio_display-ti-linux-4.19.y
* 'audio_display-ti-linux-4.19.y' of git.ti.com:~jyrisarha/ti-linux-kernel/jyrisarhas-audio-video-linux-feature-tree:
ti_config_fragments: audio_display.cfg: Enable OMAP4/5 HDMI audio module
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
TI-Feature: audio-display
TI-Tree: git@git.ti.com:~jyrisarha/ti-linux-kernel/jyrisarhas-audio-video-linux-feature-tree.git
TI-Branch: audio_display-ti-linux-4.19.y
* 'audio_display-ti-linux-4.19.y' of git.ti.com:~jyrisarha/ti-linux-kernel/jyrisarhas-audio-video-linux-feature-tree:
ti_config_fragments: audio_display.cfg: Enable OMAP4/5 HDMI audio module
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
ti_config_fragments: audio_display.cfg: Enable OMAP4/5 HDMI audio module
We have missed to enable the OMAP HDMI audio support.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
We have missed to enable the OMAP HDMI audio support.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Merge branch 'graphics-ti-linux-4.19.y' of git://git.ti.com/graphics/graphics-kernel-feature-tree into ti-linux-4.19.y
TI-Feature: graphics
TI-Tree: git://git.ti.com/graphics/graphics-kernel-feature-tree.git
TI-Branch: graphics-ti-linux-4.19.y
* 'graphics-ti-linux-4.19.y' of git://git.ti.com/graphics/graphics-kernel-feature-tree:
ARM: dts: am57xx evm: Enable BB2D node
ARM: dts: dra72-evm-common: Enable BB2D node
ARM: dts: dra7-evm: Enable BB2D node
ARM: dts: dra7: add entry for bb2d module
dt-bindings: gpu: add bindings for ti bb2d
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
TI-Feature: graphics
TI-Tree: git://git.ti.com/graphics/graphics-kernel-feature-tree.git
TI-Branch: graphics-ti-linux-4.19.y
* 'graphics-ti-linux-4.19.y' of git://git.ti.com/graphics/graphics-kernel-feature-tree:
ARM: dts: am57xx evm: Enable BB2D node
ARM: dts: dra72-evm-common: Enable BB2D node
ARM: dts: dra7-evm: Enable BB2D node
ARM: dts: dra7: add entry for bb2d module
dt-bindings: gpu: add bindings for ti bb2d
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
ti_config_fragments/connectivity.cfg: enable nl80211 testmode command
The nl80211 testmode command helps implementing things like
factory calibration or validation tools for wireless chips.
It us used by TI's WL18xx devices too. Enable it.
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
The nl80211 testmode command helps implementing things like
factory calibration or validation tools for wireless chips.
It us used by TI's WL18xx devices too. Enable it.
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
ARM: dts: am57xx evm: Enable BB2D node
The BB2D graphics accelerator node has been enabled for AM57x based
Beagle-X15 (GPEVM) and IDK platforms. The BB2D device node properties
are inherited from the base dra7 dtsi file.
Signed-off-by: Eric Ruei <e-ruei1@ti.com>
Signed-off-by: Jacob Stiffler <j-stiffler@ti.com>
Signed-off-by: Gowtham Tammana <g-tammana@ti.com>
[g-tammana@ti.com: rebase from ti-linux-k4.14.y]
The BB2D graphics accelerator node has been enabled for AM57x based
Beagle-X15 (GPEVM) and IDK platforms. The BB2D device node properties
are inherited from the base dra7 dtsi file.
Signed-off-by: Eric Ruei <e-ruei1@ti.com>
Signed-off-by: Jacob Stiffler <j-stiffler@ti.com>
Signed-off-by: Gowtham Tammana <g-tammana@ti.com>
[g-tammana@ti.com: rebase from ti-linux-k4.14.y]
ARM: dts: dra72-evm-common: Enable BB2D node
The BB2D graphics accelerator node has been enabled for DRA72 EVM
family boards. The BB2D device node properties are inherited from the
base dra7 dtsi file.
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Gowtham Tammana <g-tammana@ti.com>
The BB2D graphics accelerator node has been enabled for DRA72 EVM
family boards. The BB2D device node properties are inherited from the
base dra7 dtsi file.
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Gowtham Tammana <g-tammana@ti.com>
ARM: dts: dra7-evm: Enable BB2D node
The BB2D graphics accelerator node has been enabled for DRA7 EVM board.
The BB2D node properties are inherited from the base dra7 dtsi file.
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Gowtham Tammana <g-tammana@ti.com>
The BB2D graphics accelerator node has been enabled for DRA7 EVM board.
The BB2D node properties are inherited from the base dra7 dtsi file.
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Gowtham Tammana <g-tammana@ti.com>
ARM: dts: dra7: add entry for bb2d module
BB2D entry is added to the dts file. Crossbar index number is used
for interrupt mapping.
Reviewed-by: Suman Anna <s-anna@ti.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Gowtham Tammana <g-tammana@ti.com>
BB2D entry is added to the dts file. Crossbar index number is used
for interrupt mapping.
Reviewed-by: Suman Anna <s-anna@ti.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Gowtham Tammana <g-tammana@ti.com>
dt-bindings: gpu: add bindings for ti bb2d
Add documentation for device tree bindings description for
2D GPU blitter module present in Texas Instruments family of SoCs.
Reviewed-by: Suman Anna <s-anna@ti.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Gowtham Tammana <g-tammana@ti.com>
Add documentation for device tree bindings description for
2D GPU blitter module present in Texas Instruments family of SoCs.
Reviewed-by: Suman Anna <s-anna@ti.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Gowtham Tammana <g-tammana@ti.com>
Merge branch 'rpmsg-ti-linux-4.19.y-intg' of git://git.ti.com/rpmsg/rpmsg into ti-linux-4.19.y
TI-Feature: rpmsg
TI-Tree: git://git.ti.com/rpmsg/rpmsg.git
TI-Branch: rpmsg-ti-linux-4.19.y-intg
* 'rpmsg-ti-linux-4.19.y-intg' of git://git.ti.com/rpmsg/rpmsg:
iommu/omap: Fix a typo in the public omap-iommu.h file
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
TI-Feature: rpmsg
TI-Tree: git://git.ti.com/rpmsg/rpmsg.git
TI-Branch: rpmsg-ti-linux-4.19.y-intg
* 'rpmsg-ti-linux-4.19.y-intg' of git://git.ti.com/rpmsg/rpmsg:
iommu/omap: Fix a typo in the public omap-iommu.h file
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
Merge branch 'rpmsg-ti-linux-4.19.y' of git://git.ti.com/rpmsg/rpmsg into rpmsg-ti-linux-4.19.y-intg
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'rproc-linux-4.19.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-4.19.y
Pull in the updated remoteproc feature branch that includes a
fix for a minor build issue with OMAP IOMMU driver.
* 'rproc-linux-4.19.y' of git://git.ti.com/rpmsg/remoteproc:
iommu/omap: Fix a typo in the public omap-iommu.h file
Signed-off-by: Suman Anna <s-anna@ti.com>
Pull in the updated remoteproc feature branch that includes a
fix for a minor build issue with OMAP IOMMU driver.
* 'rproc-linux-4.19.y' of git://git.ti.com/rpmsg/remoteproc:
iommu/omap: Fix a typo in the public omap-iommu.h file
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'iommu-linux-4.19.y' of git://git.ti.com/rpmsg/iommu into rproc-linux-4.19.y
Merge in the updated iommu feature branch into remoteproc tree to
pull in a minor build fix seen when CONFIG_OMAP_IOMMU is not defined
and used with COMPILE_TEST.
* 'iommu-linux-4.19.y' of git://git.ti.com/rpmsg/iommu:
iommu/omap: Fix a typo in the public omap-iommu.h file
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge in the updated iommu feature branch into remoteproc tree to
pull in a minor build fix seen when CONFIG_OMAP_IOMMU is not defined
and used with COMPILE_TEST.
* 'iommu-linux-4.19.y' of git://git.ti.com/rpmsg/iommu:
iommu/omap: Fix a typo in the public omap-iommu.h file
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'rpmsg-ti-linux-4.19.y-intg' of git://git.ti.com/rpmsg/rpmsg into ti-linux-4.19.y
TI-Feature: rpmsg
TI-Tree: git://git.ti.com/rpmsg/rpmsg.git
TI-Branch: rpmsg-ti-linux-4.19.y-intg
* 'rpmsg-ti-linux-4.19.y-intg' of git://git.ti.com/rpmsg/rpmsg: (22 commits)
ti_config_fragments: rpmsg: Enable OMAP remoteproc watchdog support
ARM: dts: dra7-ipu-dsp-common: Add watchdog timers to IPU and DSP nodes
ARM: dts: omap5-uevm: Add watchdog timers for IPU and DSP
ARM: dts: omap4-panda-common: Add watchdog timers for IPU and DSP
remoteproc/omap: add watchdog functionality for remote processors
remoteproc/omap: fix auto-suspend failure warning during crashed state
remoteproc: fix multiple back-to-back error recoveries
remoteproc/omap: report device exceptions and trigger recovery
remoteproc: implement last trace for remoteproc
Revert "remoteproc: Introduce rproc_{start,stop}() functions"
Revert "remoteproc: Modify recovery path to use rproc_{start,stop}()"
Revert "remoteproc: Remove depricated crash completion"
rpmsg: fix lockdep warnings in virtio rpmsg bus driver
net/rpmsg: unblock reader threads operating on errored sockets
net/rpmsg: return ENOLINK upon Rx on errored sockets
net/rpmsg: return ESHUTDOWN upon Tx on errored sockets
net/rpmsg: add support to handle a remote processor error recovery
rpmsg: rpc: fix potential memory leak of unprocessed skbs
rpmsg: rpc: fix ept memory leak during recovery
rpmsg: rpc: use the local device pointer in all file operations
...
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
TI-Feature: rpmsg
TI-Tree: git://git.ti.com/rpmsg/rpmsg.git
TI-Branch: rpmsg-ti-linux-4.19.y-intg
* 'rpmsg-ti-linux-4.19.y-intg' of git://git.ti.com/rpmsg/rpmsg: (22 commits)
ti_config_fragments: rpmsg: Enable OMAP remoteproc watchdog support
ARM: dts: dra7-ipu-dsp-common: Add watchdog timers to IPU and DSP nodes
ARM: dts: omap5-uevm: Add watchdog timers for IPU and DSP
ARM: dts: omap4-panda-common: Add watchdog timers for IPU and DSP
remoteproc/omap: add watchdog functionality for remote processors
remoteproc/omap: fix auto-suspend failure warning during crashed state
remoteproc: fix multiple back-to-back error recoveries
remoteproc/omap: report device exceptions and trigger recovery
remoteproc: implement last trace for remoteproc
Revert "remoteproc: Introduce rproc_{start,stop}() functions"
Revert "remoteproc: Modify recovery path to use rproc_{start,stop}()"
Revert "remoteproc: Remove depricated crash completion"
rpmsg: fix lockdep warnings in virtio rpmsg bus driver
net/rpmsg: unblock reader threads operating on errored sockets
net/rpmsg: return ENOLINK upon Rx on errored sockets
net/rpmsg: return ESHUTDOWN upon Tx on errored sockets
net/rpmsg: add support to handle a remote processor error recovery
rpmsg: rpc: fix potential memory leak of unprocessed skbs
rpmsg: rpc: fix ept memory leak during recovery
rpmsg: rpc: use the local device pointer in all file operations
...
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
iommu/omap: Fix a typo in the public omap-iommu.h file
The commit b8ee97c59fb1 ("iommu/omap: introduce new API for
runtime suspend/resume control") has introduced two new functions
omap_iommu_domain_deactivate() & omap_iommu_domain_activate(),
and has also added their stubs to allow COMPILE_TEST of consumer
drivers using this header file. The return values in these stubs
used a wrong error value of ENOTSUP instead of ENOTSUPP. Fix this
typo. While at this, include the errno header file that defines
this macro as well to make the omap-iommu.h self-contained.
Fixes: b8ee97c59fb1 ("iommu/omap: introduce new API for runtime suspend/resume control")
Signed-off-by: Suman Anna <s-anna@ti.com>
The commit b8ee97c59fb1 ("iommu/omap: introduce new API for
runtime suspend/resume control") has introduced two new functions
omap_iommu_domain_deactivate() & omap_iommu_domain_activate(),
and has also added their stubs to allow COMPILE_TEST of consumer
drivers using this header file. The return values in these stubs
used a wrong error value of ENOTSUP instead of ENOTSUPP. Fix this
typo. While at this, include the errno header file that defines
this macro as well to make the omap-iommu.h self-contained.
Fixes: b8ee97c59fb1 ("iommu/omap: introduce new API for runtime suspend/resume control")
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'rpmsg-ti-linux-4.19.y' of git://git.ti.com/rpmsg/rpmsg into rpmsg-ti-linux-4.19.y-intg
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
ti_config_fragments: rpmsg: Enable OMAP remoteproc watchdog support
Enable the Watchdog timer support for the OMAP remoteproc driver. This
enables the OMAP remoteproc driver to recovery any remote processor
executions stuck in a loop. This also mandatas that that all the IPU
and DSP firmwares to be used with the OMAP remoteproc driver support
the Watchdog timers and are petting the corresponding dmtimers to avoid
a recurring reboot of that processor.
Signed-off-by: Suman Anna <s-anna@ti.com>
Enable the Watchdog timer support for the OMAP remoteproc driver. This
enables the OMAP remoteproc driver to recovery any remote processor
executions stuck in a loop. This also mandatas that that all the IPU
and DSP firmwares to be used with the OMAP remoteproc driver support
the Watchdog timers and are petting the corresponding dmtimers to avoid
a recurring reboot of that processor.
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'rpmsg-linux-4.19.y' of git://git.ti.com/rpmsg/rpmsg into rpmsg-ti-linux-4.19.y
Pull in the updated rpmsg base feature branch that adds the support
to the rpmsg-proto driver for handling error recovery with active open
sockets.
The merge also includes a bug fix in the virtio rpmsg core to fix
various mutex circular/recursive dependency issues in rpmsg-rpc and
rpmsg-proto drivers during error recovery.
* 'rpmsg-linux-4.19.y' of git://git.ti.com/rpmsg/rpmsg:
rpmsg: fix lockdep warnings in virtio rpmsg bus driver
net/rpmsg: unblock reader threads operating on errored sockets
net/rpmsg: return ENOLINK upon Rx on errored sockets
net/rpmsg: return ESHUTDOWN upon Tx on errored sockets
net/rpmsg: add support to handle a remote processor error recovery
Signed-off-by: Suman Anna <s-anna@ti.com>
Pull in the updated rpmsg base feature branch that adds the support
to the rpmsg-proto driver for handling error recovery with active open
sockets.
The merge also includes a bug fix in the virtio rpmsg core to fix
various mutex circular/recursive dependency issues in rpmsg-rpc and
rpmsg-proto drivers during error recovery.
* 'rpmsg-linux-4.19.y' of git://git.ti.com/rpmsg/rpmsg:
rpmsg: fix lockdep warnings in virtio rpmsg bus driver
net/rpmsg: unblock reader threads operating on errored sockets
net/rpmsg: return ENOLINK upon Rx on errored sockets
net/rpmsg: return ESHUTDOWN upon Tx on errored sockets
net/rpmsg: add support to handle a remote processor error recovery
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'rpmsg-linux-4.19.y' of git://git.ti.com/rpmsg/rpmsg into rpmsg-ti-linux-4.19.y
Pull in the updated rpmsg base feature branch that includes fixes
to various bugs and memory leak issues found during error recovery
with active open applications.
* 'rpmsg-linux-4.19.y' of git://git.ti.com/rpmsg/rpmsg:
rpmsg: rpc: fix potential memory leak of unprocessed skbs
rpmsg: rpc: fix ept memory leak during recovery
rpmsg: rpc: use the local device pointer in all file operations
rpmsg: rpc: maintain a reference device pointer per open fd
rpmsg: rpc: fix sysfs entry creation failures during recovery
Signed-off-by: Suman Anna <s-anna@ti.com>
Pull in the updated rpmsg base feature branch that includes fixes
to various bugs and memory leak issues found during error recovery
with active open applications.
* 'rpmsg-linux-4.19.y' of git://git.ti.com/rpmsg/rpmsg:
rpmsg: rpc: fix potential memory leak of unprocessed skbs
rpmsg: rpc: fix ept memory leak during recovery
rpmsg: rpc: use the local device pointer in all file operations
rpmsg: rpc: maintain a reference device pointer per open fd
rpmsg: rpc: fix sysfs entry creation failures during recovery
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'rproc-linux-4.19.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-4.19.y
Pull in the remoteproc feature branch that restores the error recovery
functionality for remoteprocs with virtio devices and MMUs, and adds the
support for error recovery from both internal exceptions and Watchdog
errors on all IPU and DSP remote processors on OMAP4+ SoCs. The merge
also adds a debugfs last trace feature to remoteproc core. Also included
are fixes couple of issues in remoteproc core w.r.t sysfs interface and
debugfs 'recovery' file; and fixes for some state-machine issues related
to OMAP remoteproc driver.
* 'rproc-linux-4.19.y' of git://git.ti.com/rpmsg/remoteproc:
ARM: dts: dra7-ipu-dsp-common: Add watchdog timers to IPU and DSP nodes
ARM: dts: omap5-uevm: Add watchdog timers for IPU and DSP
ARM: dts: omap4-panda-common: Add watchdog timers for IPU and DSP
remoteproc/omap: add watchdog functionality for remote processors
remoteproc/omap: fix auto-suspend failure warning during crashed state
remoteproc: fix multiple back-to-back error recoveries
remoteproc/omap: report device exceptions and trigger recovery
remoteproc: implement last trace for remoteproc
Revert "remoteproc: Introduce rproc_{start,stop}() functions"
Revert "remoteproc: Modify recovery path to use rproc_{start,stop}()"
Revert "remoteproc: Remove depricated crash completion"
Signed-off-by: Suman Anna <s-anna@ti.com>
Pull in the remoteproc feature branch that restores the error recovery
functionality for remoteprocs with virtio devices and MMUs, and adds the
support for error recovery from both internal exceptions and Watchdog
errors on all IPU and DSP remote processors on OMAP4+ SoCs. The merge
also adds a debugfs last trace feature to remoteproc core. Also included
are fixes couple of issues in remoteproc core w.r.t sysfs interface and
debugfs 'recovery' file; and fixes for some state-machine issues related
to OMAP remoteproc driver.
* 'rproc-linux-4.19.y' of git://git.ti.com/rpmsg/remoteproc:
ARM: dts: dra7-ipu-dsp-common: Add watchdog timers to IPU and DSP nodes
ARM: dts: omap5-uevm: Add watchdog timers for IPU and DSP
ARM: dts: omap4-panda-common: Add watchdog timers for IPU and DSP
remoteproc/omap: add watchdog functionality for remote processors
remoteproc/omap: fix auto-suspend failure warning during crashed state
remoteproc: fix multiple back-to-back error recoveries
remoteproc/omap: report device exceptions and trigger recovery
remoteproc: implement last trace for remoteproc
Revert "remoteproc: Introduce rproc_{start,stop}() functions"
Revert "remoteproc: Modify recovery path to use rproc_{start,stop}()"
Revert "remoteproc: Remove depricated crash completion"
Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: dts: dra7-ipu-dsp-common: Add watchdog timers to IPU and DSP nodes
The watchdog timer information has been added to all the IPU and DSP
remote processor device nodes in the DRA7xx/AM57xx SoC families. The
data has been added to the two common dra7-ipu-dsp-common and
dra74-ipu-dsp-common dtsi files that can be included by all the
desired board files. The following timers are chosen as the watchdog
timers, as per the usage on the current firmware images:
IPU2: GPTimers 4 & 9 (one for each Cortex-M4 core)
IPU1: GPTimers 7 & 8 (one for each Cortex-M4 core)
DSP1: GPTimer 10
DSP2: GPTimer 13
Each of the IPUs has two Cortex-M4 processors and so uses a timer
each for providing watchdog support on that processor irrespective of
whether the IPU is running in SMP-mode or non-SMP node. The chosen
timers also need to be unique from the ones used by other processors
(regular timers or watchdog timers) so that they can be supported
simultaneously.
The MPU-side drivers will use this data to initialize the watchdog
timer(s), and listen for any watchdog triggers. The BIOS-side code on
these processors needs to configure/refresh the corresponding timer
properly to not throw a watchdog error.
The watchdog timers are optional in general, but are mandatory to
be added to support watchdog error recovery on a particular processor.
These timers can be changed or removed as per the system integration
needs, alongside appropriate equivalent changes on the firmware side.
Signed-off-by: Angela Stegmaier <angelabaker@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
The watchdog timer information has been added to all the IPU and DSP
remote processor device nodes in the DRA7xx/AM57xx SoC families. The
data has been added to the two common dra7-ipu-dsp-common and
dra74-ipu-dsp-common dtsi files that can be included by all the
desired board files. The following timers are chosen as the watchdog
timers, as per the usage on the current firmware images:
IPU2: GPTimers 4 & 9 (one for each Cortex-M4 core)
IPU1: GPTimers 7 & 8 (one for each Cortex-M4 core)
DSP1: GPTimer 10
DSP2: GPTimer 13
Each of the IPUs has two Cortex-M4 processors and so uses a timer
each for providing watchdog support on that processor irrespective of
whether the IPU is running in SMP-mode or non-SMP node. The chosen
timers also need to be unique from the ones used by other processors
(regular timers or watchdog timers) so that they can be supported
simultaneously.
The MPU-side drivers will use this data to initialize the watchdog
timer(s), and listen for any watchdog triggers. The BIOS-side code on
these processors needs to configure/refresh the corresponding timer
properly to not throw a watchdog error.
The watchdog timers are optional in general, but are mandatory to
be added to support watchdog error recovery on a particular processor.
These timers can be changed or removed as per the system integration
needs, alongside appropriate equivalent changes on the firmware side.
Signed-off-by: Angela Stegmaier <angelabaker@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: dts: omap5-uevm: Add watchdog timers for IPU and DSP
The watchdog timers have been added for the IPU and DSP remoteproc
devices for the OMAP5 uEVM board. The following timers (same as the
timers on OMAP4 Panda boards) are used as the watchdog timers,
DSP : GPT6
IPU : GPT9 & GPT11 (one for each Cortex-M4 core)
The MPU-side drivers will use this data to initialize the watchdog
timers, and listen for any watchdog triggers. The BIOS-side code
needs to configure and refresh these timers properly to not throw
a watchdog error.
These timers can be changed or removed as per the system integration
needs, alongside appropriate equivalent changes on the firmware side.
Signed-off-by: Suman Anna <s-anna@ti.com>
The watchdog timers have been added for the IPU and DSP remoteproc
devices for the OMAP5 uEVM board. The following timers (same as the
timers on OMAP4 Panda boards) are used as the watchdog timers,
DSP : GPT6
IPU : GPT9 & GPT11 (one for each Cortex-M4 core)
The MPU-side drivers will use this data to initialize the watchdog
timers, and listen for any watchdog triggers. The BIOS-side code
needs to configure and refresh these timers properly to not throw
a watchdog error.
These timers can be changed or removed as per the system integration
needs, alongside appropriate equivalent changes on the firmware side.
Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: dts: omap4-panda-common: Add watchdog timers for IPU and DSP
The watchdog timers have been added for the IPU and DSP remoteproc
devices on all the OMAP4-based Panda boards. The following timers
are used as the watchdog timers,
DSP : GPT6
IPU : GPT9 & GPT11 (one for each Cortex-M3 core)
The MPU-side drivers will use this data to initialize the watchdog
timers, and listen for any watchdog triggers. The BIOS-side code
needs to configure and refresh these timers properly to not throw
a watchdog error.
These timers can be changed or removed as per the system integration
needs, alongside appropriate equivalent changes on the firmware side.
Signed-off-by: Suman Anna <s-anna@ti.com>
The watchdog timers have been added for the IPU and DSP remoteproc
devices on all the OMAP4-based Panda boards. The following timers
are used as the watchdog timers,
DSP : GPT6
IPU : GPT9 & GPT11 (one for each Cortex-M3 core)
The MPU-side drivers will use this data to initialize the watchdog
timers, and listen for any watchdog triggers. The BIOS-side code
needs to configure and refresh these timers properly to not throw
a watchdog error.
These timers can be changed or removed as per the system integration
needs, alongside appropriate equivalent changes on the firmware side.
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc/omap: add watchdog functionality for remote processors
Remote processors can be stuck in a loop, and may not be recoverable
if they do not have a built-in watchdog. The watchdog implementation
for OMAP remote processors uses external gptimers that can be used
to interrupt both the Linux host as well as the remote processor.
Each remote processor is responsible for refreshing the timer during
normal behavior - during OS task scheduling or entering the idle loop
properly. During a watchdog condition (executing a tight loop causing
no scheduling), the host processor gets interrupts and schedules a
recovery for the corresponding remote processor. The remote processor
may also get interrupted to be able to print a back trace.
A menuconfig option has also been added to enable/disable the Watchdog
functionality, with the default as disabled.
Signed-off-by: Suman Anna <s-anna@ti.com>
Remote processors can be stuck in a loop, and may not be recoverable
if they do not have a built-in watchdog. The watchdog implementation
for OMAP remote processors uses external gptimers that can be used
to interrupt both the Linux host as well as the remote processor.
Each remote processor is responsible for refreshing the timer during
normal behavior - during OS task scheduling or entering the idle loop
properly. During a watchdog condition (executing a tight loop causing
no scheduling), the host processor gets interrupts and schedules a
recovery for the corresponding remote processor. The remote processor
may also get interrupted to be able to print a back trace.
A menuconfig option has also been added to enable/disable the Watchdog
functionality, with the default as disabled.
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>
remoteproc: fix multiple back-to-back error recoveries
The remoteproc core uses a dedicated work item per remote processor
to perform an error recovery of that processor. This work item is
always scheduled upon notification of an error at the moment. The
error recovery process itself is performed when the workqueue gets
scheduled and executes the work function, but an error recovery
needs to be performed only once if there are multiple notifications
while an existing error recovery is in progress. Fix this by adding
a check to make sure the remote processor error recovery work item
is not already running or scheduled.
This fixes an issue with error recovery upon MMU Faults on OMAP
IPU remote processors. An MMU fault on OMAP IPU sends two error
notifications - one a direct interrupt from the MMU, and the second
a mailbox-based crash notification after the remote processor has
collected some backtrace. The mailbox based interrupt mechanism,
added in commit 7f275d21e240 ("remoteproc/omap: report device
exceptions and trigger recovery"), is used for Attribute MMU (AMMU)
faults and other internal exceptions on the IPU. The backtrace
collection on the IPU remote processor is triggered by the same
interrupt which cannot be differentiated between an MMU fault and
an AMMU fault. The remoteproc core changes in 4.9 kernel around the
boot sequences has now caused the second notification to trigger a
secondary error recovery, which was avoided in previous kernels due
to the event detection in the work-function itself. The newer code
sequences changes the timing w.r.t previous kernels where the
recovery process was performed a bit later due to the asynchronous
firmware loading.
Signed-off-by: Suman Anna <s-anna@ti.com>
The remoteproc core uses a dedicated work item per remote processor
to perform an error recovery of that processor. This work item is
always scheduled upon notification of an error at the moment. The
error recovery process itself is performed when the workqueue gets
scheduled and executes the work function, but an error recovery
needs to be performed only once if there are multiple notifications
while an existing error recovery is in progress. Fix this by adding
a check to make sure the remote processor error recovery work item
is not already running or scheduled.
This fixes an issue with error recovery upon MMU Faults on OMAP
IPU remote processors. An MMU fault on OMAP IPU sends two error
notifications - one a direct interrupt from the MMU, and the second
a mailbox-based crash notification after the remote processor has
collected some backtrace. The mailbox based interrupt mechanism,
added in commit 7f275d21e240 ("remoteproc/omap: report device
exceptions and trigger recovery"), is used for Attribute MMU (AMMU)
faults and other internal exceptions on the IPU. The backtrace
collection on the IPU remote processor is triggered by the same
interrupt which cannot be differentiated between an MMU fault and
an AMMU fault. The remoteproc core changes in 4.9 kernel around the
boot sequences has now caused the second notification to trigger a
secondary error recovery, which was avoided in previous kernels due
to the event detection in the work-function itself. The newer code
sequences changes the timing w.r.t previous kernels where the
recovery process was performed a bit later due to the asynchronous
firmware loading.
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc/omap: report device exceptions and trigger recovery
The OMAP remote processors send a special mailbox message
(RP_MBOX_CRASH) when they crash and detect an internal device
exception.
Add support to the mailbox handling function upon detection of
this special message to report this crash to the remoteproc core.
The remoteproc core can trigger a recovery using the prevailing
recovery mechanism, already in use for MMU Fault recovery.
Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
The OMAP remote processors send a special mailbox message
(RP_MBOX_CRASH) when they crash and detect an internal device
exception.
Add support to the mailbox handling function upon detection of
this special message to report this crash to the remoteproc core.
The remoteproc core can trigger a recovery using the prevailing
recovery mechanism, already in use for MMU Fault recovery.
Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc: implement last trace for remoteproc
The last trace is a way of preserving the remoteproc traces past
remoteproc recovery. This is achieved by creating a new traceY_last
debugfs entry during a crash for each trace entry, and copying the
trace buffer contents into the corresponding last trace entry. This
copied contents can then be read out using a debugfs entry. The
trace entries themselves are cleaned up after the copy and are
recreated during a recovery reload.
Eg:
cat <debugfs_root>/remoteproc/remoteprocX/traceY_last
should give the traces that were printed out just before the recovery
happened on remoteproc X for trace Y.
Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
The last trace is a way of preserving the remoteproc traces past
remoteproc recovery. This is achieved by creating a new traceY_last
debugfs entry during a crash for each trace entry, and copying the
trace buffer contents into the corresponding last trace entry. This
copied contents can then be read out using a debugfs entry. The
trace entries themselves are cleaned up after the copy and are
recreated during a recovery reload.
Eg:
cat <debugfs_root>/remoteproc/remoteprocX/traceY_last
should give the traces that were printed out just before the recovery
happened on remoteproc X for trace Y.
Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Revert "remoteproc: Introduce rproc_{start,stop}() functions"
This reverts commit 1efa30d0895e7e9a58a59b0880b330b38245be68.
The commit 1efa30d0895e ("remoteproc: Introduce rproc_{start,stop}()
functions") has refactored code out from rproc_boot() and rproc_shutdown()
to optimize resource allocation overheads during the recovery. This
patch was made with an implicit assumption that the same firmware
image will always be used during recovery (rightfully so in a product
environment), and so the resources will also remain the same. The patch
had also changed the rproc state to RPROC_OFFLINE prior to cleaning up
all resources and disabling the MMU in rproc_shutdown(). This does not
play nice with doing any additional processing steps during recovery
in the resource cleanup function.
This patch is a custom revert of the above commit, accounting for all
the changes added to the rproc_start() and rproc_stop() functions since
kernel v4.13 and some additional changes added in commit 20afed1b45bf
("remoteproc: add infrastructure support to allow pre-loaded remoteprocs")
and commit 2794d1693b05 ("remoteproc: Add support to handle device
specific resource types") thereby allowing a new last trace mechanism
to be supported in a subsequent patch.
Signed-off-by: Suman Anna <s-anna@ti.com>
This reverts commit 1efa30d0895e7e9a58a59b0880b330b38245be68.
The commit 1efa30d0895e ("remoteproc: Introduce rproc_{start,stop}()
functions") has refactored code out from rproc_boot() and rproc_shutdown()
to optimize resource allocation overheads during the recovery. This
patch was made with an implicit assumption that the same firmware
image will always be used during recovery (rightfully so in a product
environment), and so the resources will also remain the same. The patch
had also changed the rproc state to RPROC_OFFLINE prior to cleaning up
all resources and disabling the MMU in rproc_shutdown(). This does not
play nice with doing any additional processing steps during recovery
in the resource cleanup function.
This patch is a custom revert of the above commit, accounting for all
the changes added to the rproc_start() and rproc_stop() functions since
kernel v4.13 and some additional changes added in commit 20afed1b45bf
("remoteproc: add infrastructure support to allow pre-loaded remoteprocs")
and commit 2794d1693b05 ("remoteproc: Add support to handle device
specific resource types") thereby allowing a new last trace mechanism
to be supported in a subsequent patch.
Signed-off-by: Suman Anna <s-anna@ti.com>
Revert "remoteproc: Modify recovery path to use rproc_{start,stop}()"
This reverts commit 7e83cab824a86704cdbd7735c19d34e0ce423dc5.
The commit 7e83cab824a8 ("remoteproc: Modify recovery path to use
rproc_{start,stop}()") has modified the rproc_trigger_recovery()
function to leverage rproc_stop() and rproc_start() functions
introduced in commit 1efa30d0895e ("remoteproc: Introduce
rproc_{start,stop}() functions") in place of the previous usage
of rproc_shutdown() and rproc_boot() functions. These new functions
execute only a portion of the previous functions, and are primarily
designed to optimize the allocation of memory resources. They do
not handle other resources like virtio devices and the resetting
of any IOMMUs. The new functions also do not re-initialize the
memory used by the firmware image sections during recovery. This
results in a kernel crash like below when performing error recovery
on remoteprocs using both MMUs and virtio devices like the OMAP
remoteproc driver.
omap-iommu 55082000.mmu: 55082000.mmu: version 2.1
omap-iommu 55082000.mmu: iommu fault: da 0x8004cc60 flags 0x0
remoteproc remoteproc1: crash detected in 55020000.ipu: type mmufault
omap-iommu 55082000.mmu: 55082000.mmu: errs:0x00000002 da:0x8004cc60 pgd:0x63ed70cb *pgd:px95f00002
remoteproc remoteproc1: handling crash #1 in 55020000.ipu
remoteproc remoteproc1: recovering 55020000.ipu
omap-rproc 55020000.ipu: omap rproc 55020000.ipu crashed
remoteproc remoteproc1: stopped remote processor 55020000.ipu
kobject (44f48dcd): tried to init an initialized object, something is seriously wrong.
CPU: 0 PID: 23 Comm: kworker/0:1 Not tainted 4.19.0-00420-gd9f97bb86434 #658
Hardware name: Generic DRA74X (Flattened Device Tree)
Workqueue: events rproc_crash_handler_work [remoteproc]
[<c0114224>] (unwind_backtrace) from [<c010e618>] (show_stack+0x10/0x14)
[<c010e618>] (show_stack) from [<c09585c8>] (dump_stack+0xb0/0xe8)
[<c09585c8>] (dump_stack) from [<c095cec0>] (kobject_init+0x78/0x94)
[<c095cec0>] (kobject_init) from [<c06224bc>] (device_initialize+0x20/0xf0)
[<c06224bc>] (device_initialize) from [<bf0003d4>] (register_virtio_device+0x1c/0x110 [virtio])
[<bf0003d4>] (register_virtio_device [virtio]) from [<bf02bf34>] (rproc_add_virtio_dev+0x44/0xa0 [remoteproc])
[<bf02bf34>] (rproc_add_virtio_dev [remoteproc]) from [<bf028744>] (rproc_start+0x1c8/0x264 [remoteproc])
[<bf028744>] (rproc_start [remoteproc]) from [<bf02acac>] (rproc_trigger_recovery+0x28c/0x2dc [remoteproc])
[<bf02acac>] (rproc_trigger_recovery [remoteproc]) from [<c015d438>] (process_one_work+0x2ac/0x788)
[<c015d438>] (process_one_work) from [<c015d940>] (worker_thread+0x2c/0x584)
[<c015d940>] (worker_thread) from [<c0164648>] (kthread+0x140/0x15c)
[<c0164648>] (kthread) from [<c01010b4>] (ret_from_fork+0x14/0x20)
... exception stack dump ...
virtio_rpmsg_bus virtio1: rpmsg host is online
driver_bound: device virtio1 already bound
remoteproc remoteproc1: registered virtio1 (type 7)
remoteproc remoteproc1: remote processor 55020000.ipu is now up
Unable to handle kernel NULL pointer dereference at virtual address 00000004
Revert the above commit to fix/restore the error recovery functionality.
This patch is a custom revert of the above commit, accounting for some
additional changes done in commit 2666ca9197e3 ("remoteproc: Add remote
processor coredump support"). The coredump function is invoked in
rproc_stop() now.
Signed-off-by: Suman Anna <s-anna@ti.com>
This reverts commit 7e83cab824a86704cdbd7735c19d34e0ce423dc5.
The commit 7e83cab824a8 ("remoteproc: Modify recovery path to use
rproc_{start,stop}()") has modified the rproc_trigger_recovery()
function to leverage rproc_stop() and rproc_start() functions
introduced in commit 1efa30d0895e ("remoteproc: Introduce
rproc_{start,stop}() functions") in place of the previous usage
of rproc_shutdown() and rproc_boot() functions. These new functions
execute only a portion of the previous functions, and are primarily
designed to optimize the allocation of memory resources. They do
not handle other resources like virtio devices and the resetting
of any IOMMUs. The new functions also do not re-initialize the
memory used by the firmware image sections during recovery. This
results in a kernel crash like below when performing error recovery
on remoteprocs using both MMUs and virtio devices like the OMAP
remoteproc driver.
omap-iommu 55082000.mmu: 55082000.mmu: version 2.1
omap-iommu 55082000.mmu: iommu fault: da 0x8004cc60 flags 0x0
remoteproc remoteproc1: crash detected in 55020000.ipu: type mmufault
omap-iommu 55082000.mmu: 55082000.mmu: errs:0x00000002 da:0x8004cc60 pgd:0x63ed70cb *pgd:px95f00002
remoteproc remoteproc1: handling crash #1 in 55020000.ipu
remoteproc remoteproc1: recovering 55020000.ipu
omap-rproc 55020000.ipu: omap rproc 55020000.ipu crashed
remoteproc remoteproc1: stopped remote processor 55020000.ipu
kobject (44f48dcd): tried to init an initialized object, something is seriously wrong.
CPU: 0 PID: 23 Comm: kworker/0:1 Not tainted 4.19.0-00420-gd9f97bb86434 #658
Hardware name: Generic DRA74X (Flattened Device Tree)
Workqueue: events rproc_crash_handler_work [remoteproc]
[<c0114224>] (unwind_backtrace) from [<c010e618>] (show_stack+0x10/0x14)
[<c010e618>] (show_stack) from [<c09585c8>] (dump_stack+0xb0/0xe8)
[<c09585c8>] (dump_stack) from [<c095cec0>] (kobject_init+0x78/0x94)
[<c095cec0>] (kobject_init) from [<c06224bc>] (device_initialize+0x20/0xf0)
[<c06224bc>] (device_initialize) from [<bf0003d4>] (register_virtio_device+0x1c/0x110 [virtio])
[<bf0003d4>] (register_virtio_device [virtio]) from [<bf02bf34>] (rproc_add_virtio_dev+0x44/0xa0 [remoteproc])
[<bf02bf34>] (rproc_add_virtio_dev [remoteproc]) from [<bf028744>] (rproc_start+0x1c8/0x264 [remoteproc])
[<bf028744>] (rproc_start [remoteproc]) from [<bf02acac>] (rproc_trigger_recovery+0x28c/0x2dc [remoteproc])
[<bf02acac>] (rproc_trigger_recovery [remoteproc]) from [<c015d438>] (process_one_work+0x2ac/0x788)
[<c015d438>] (process_one_work) from [<c015d940>] (worker_thread+0x2c/0x584)
[<c015d940>] (worker_thread) from [<c0164648>] (kthread+0x140/0x15c)
[<c0164648>] (kthread) from [<c01010b4>] (ret_from_fork+0x14/0x20)
... exception stack dump ...
virtio_rpmsg_bus virtio1: rpmsg host is online
driver_bound: device virtio1 already bound
remoteproc remoteproc1: registered virtio1 (type 7)
remoteproc remoteproc1: remote processor 55020000.ipu is now up
Unable to handle kernel NULL pointer dereference at virtual address 00000004
Revert the above commit to fix/restore the error recovery functionality.
This patch is a custom revert of the above commit, accounting for some
additional changes done in commit 2666ca9197e3 ("remoteproc: Add remote
processor coredump support"). The coredump function is invoked in
rproc_stop() now.
Signed-off-by: Suman Anna <s-anna@ti.com>
Revert "remoteproc: Remove depricated crash completion"
This reverts commit b26210cda63564a7478486faaea713f6ea965633.
The commit b26210cda635 ("remoteproc: Remove depricated crash completion")
has dropped the crash_comp completion variable as it was not needed after
the rproc_trigger_recovery() function was modified to leverage rproc_stop()
and rproc_start() functions in commit 7e83cab824a8 ("remoteproc: Modify
recovery path to use rproc_{start,stop}()"). These new functions execute
only a portion of the previous functions, and break the error recovery
on OMAP remoteproc devices.
Reintroduce the crash completion variable by reverting the above commit
in preparation for reverting the error recovery logic to not use the
rproc_start() and rproc_stop() functions.
Signed-off-by: Suman Anna <s-anna@ti.com>
This reverts commit b26210cda63564a7478486faaea713f6ea965633.
The commit b26210cda635 ("remoteproc: Remove depricated crash completion")
has dropped the crash_comp completion variable as it was not needed after
the rproc_trigger_recovery() function was modified to leverage rproc_stop()
and rproc_start() functions in commit 7e83cab824a8 ("remoteproc: Modify
recovery path to use rproc_{start,stop}()"). These new functions execute
only a portion of the previous functions, and break the error recovery
on OMAP remoteproc devices.
Reintroduce the crash completion variable by reverting the above commit
in preparation for reverting the error recovery logic to not use the
rproc_start() and rproc_stop() functions.
Signed-off-by: Suman Anna <s-anna@ti.com>
rpmsg: fix lockdep warnings in virtio rpmsg bus driver
The virtio rpmsg bus framework uses endpoints as the basis for
sending and receiving messages to/from a remote processor. Each
rpmsg bus device will have a primary endpoint if the corresponding
rpmsg bus driver supports a callback, and secondary child endpoints
associated with the same rpmsg bus device. The life-cycle of these
endpoints are tied to the corresponding rpmsg device. A virtio rpmsg
bus device can also have its own endpoint for supporting name service
announcements from a corresponding remote processor to create and
delete rpmsg devices dynamically.
Each endpoint has a callback lock associated with it to provide
protection/mutual exclusion between threads that process incoming
rpmsg messages and threads that want to delete the endpoint. The
virtio rpmsg name service endpoint callback will run while holding
it's ept->cb_lock to create/delete rpmsg devices for RPMSG_NS_CREATE
and RPMSG_NS_DELETE messages respectively. The latter message
processing will destroy the requested channel, and will ultimately
result in all the secondary rpmsg device endpoints also to be
destroyed. The ept->cb_lock for the channel's endpoint is also
locked during its destruction while setting the callback to NULL.
This results in a seemingly nested locking of the ept->cb_lock even
though the locking is on different mutexes. This will result in a
false warning from the lockdep validator when it is enabled because
the lockdep deals with classes and both are the same class, although
they are different instances.
Similar circular dependency scenarios also exist with remoteproc
error recovery and existing rpmsg drivers - rpmsg_rpc and rpmsg_proto.
These issues are fixed by replacing the existing mutex_lock() calls
with the mutex_lock_nested() API variation and using different
subclasses for the NameService end-point and for the rpmsg channel
device end-points.
Following are example warning signatures that get fixed by this patch:
1. Recursive locking dependency during RPMSG_NS_DESTROY message processing
=============================================
WARNING: possible recursive locking detected
---------------------------------------------
kworker/0:1/23 is trying to acquire lock:
9fded1aa (&ept->cb_lock){+.+.}, at: __rpmsg_destroy_ept+0x40/0x6c [virtio_rpmsg_bus]
but task is already holding lock:
b33d53aa (&ept->cb_lock){+.+.}, at: rpmsg_recv_done+0x68/0x344 [virtio_rpmsg_bus]
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&ept->cb_lock);
lock(&ept->cb_lock);
*** DEADLOCK ***
May be due to missing lock nesting notatio
2. Circular locking dependency during error recovery of rpmsg-rpc driver
======================================================
WARNING: possible circular locking dependency detected
-------------------------------------------------------
kworker/0:2/69 is trying to acquire lock:
2e551f56 (&ept->cb_lock){+.+.}, at: __rpmsg_destroy_ept+0x40/0x6c [virtio_rpmsg_bus]
but task is already holding lock:
a034cfcf (&rppcdev->lock){+.+.}, at: rppc_remove+0x8c/0x244 [rpmsg_rpc]
which lock already depends on the new lock.
other info that might help us debug this:
Chain exists of:
&ept->cb_lock --> rppc_devices_lock --> &rppcdev->lock
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&rppcdev->lock);
lock(rppc_devices_lock);
lock(&rppcdev->lock);
lock(&ept->cb_lock);
*** DEADLOCK ***
3. Circular locking dependency during error recovery of rpmsg-proto driver
======================================================
WARNING: possible circular locking dependency detected
-------------------------------------------------------
kworker/0:1/23 is trying to acquire lock:
b012b19d (&ept->cb_lock){+.+.}, at: __rpmsg_destroy_ept+0x40/0x6c [virtio_rpmsg_bus]
but task is already holding lock:
d88d2852 (rpmsg_channels_lock){+.+.}, at: rpmsg_proto_remove+0x28/0x170 [rpmsg_proto]
which lock already depends on the new lock.
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(rpmsg_channels_lock);
lock(&ept->cb_lock);
lock(rpmsg_channels_lock);
lock(&ept->cb_lock);
*** DEADLOCK ***
Signed-off-by: Angela Stegmaier <angelabaker@ti.com>
[s-anna@ti.com: flip the subclass values, update patch description for 4.19]
Signed-off-by: Suman Anna <s-anna@ti.com>
The virtio rpmsg bus framework uses endpoints as the basis for
sending and receiving messages to/from a remote processor. Each
rpmsg bus device will have a primary endpoint if the corresponding
rpmsg bus driver supports a callback, and secondary child endpoints
associated with the same rpmsg bus device. The life-cycle of these
endpoints are tied to the corresponding rpmsg device. A virtio rpmsg
bus device can also have its own endpoint for supporting name service
announcements from a corresponding remote processor to create and
delete rpmsg devices dynamically.
Each endpoint has a callback lock associated with it to provide
protection/mutual exclusion between threads that process incoming
rpmsg messages and threads that want to delete the endpoint. The
virtio rpmsg name service endpoint callback will run while holding
it's ept->cb_lock to create/delete rpmsg devices for RPMSG_NS_CREATE
and RPMSG_NS_DELETE messages respectively. The latter message
processing will destroy the requested channel, and will ultimately
result in all the secondary rpmsg device endpoints also to be
destroyed. The ept->cb_lock for the channel's endpoint is also
locked during its destruction while setting the callback to NULL.
This results in a seemingly nested locking of the ept->cb_lock even
though the locking is on different mutexes. This will result in a
false warning from the lockdep validator when it is enabled because
the lockdep deals with classes and both are the same class, although
they are different instances.
Similar circular dependency scenarios also exist with remoteproc
error recovery and existing rpmsg drivers - rpmsg_rpc and rpmsg_proto.
These issues are fixed by replacing the existing mutex_lock() calls
with the mutex_lock_nested() API variation and using different
subclasses for the NameService end-point and for the rpmsg channel
device end-points.
Following are example warning signatures that get fixed by this patch:
1. Recursive locking dependency during RPMSG_NS_DESTROY message processing
=============================================
WARNING: possible recursive locking detected
---------------------------------------------
kworker/0:1/23 is trying to acquire lock:
9fded1aa (&ept->cb_lock){+.+.}, at: __rpmsg_destroy_ept+0x40/0x6c [virtio_rpmsg_bus]
but task is already holding lock:
b33d53aa (&ept->cb_lock){+.+.}, at: rpmsg_recv_done+0x68/0x344 [virtio_rpmsg_bus]
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&ept->cb_lock);
lock(&ept->cb_lock);
*** DEADLOCK ***
May be due to missing lock nesting notatio
2. Circular locking dependency during error recovery of rpmsg-rpc driver
======================================================
WARNING: possible circular locking dependency detected
-------------------------------------------------------
kworker/0:2/69 is trying to acquire lock:
2e551f56 (&ept->cb_lock){+.+.}, at: __rpmsg_destroy_ept+0x40/0x6c [virtio_rpmsg_bus]
but task is already holding lock:
a034cfcf (&rppcdev->lock){+.+.}, at: rppc_remove+0x8c/0x244 [rpmsg_rpc]
which lock already depends on the new lock.
other info that might help us debug this:
Chain exists of:
&ept->cb_lock --> rppc_devices_lock --> &rppcdev->lock
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&rppcdev->lock);
lock(rppc_devices_lock);
lock(&rppcdev->lock);
lock(&ept->cb_lock);
*** DEADLOCK ***
3. Circular locking dependency during error recovery of rpmsg-proto driver
======================================================
WARNING: possible circular locking dependency detected
-------------------------------------------------------
kworker/0:1/23 is trying to acquire lock:
b012b19d (&ept->cb_lock){+.+.}, at: __rpmsg_destroy_ept+0x40/0x6c [virtio_rpmsg_bus]
but task is already holding lock:
d88d2852 (rpmsg_channels_lock){+.+.}, at: rpmsg_proto_remove+0x28/0x170 [rpmsg_proto]
which lock already depends on the new lock.
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(rpmsg_channels_lock);
lock(&ept->cb_lock);
lock(rpmsg_channels_lock);
lock(&ept->cb_lock);
*** DEADLOCK ***
Signed-off-by: Angela Stegmaier <angelabaker@ti.com>
[s-anna@ti.com: flip the subclass values, update patch description for 4.19]
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'connectivity-ti-linux-4.19.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel into ti-linux-4.19.y
TI-Feature: connectivity
TI-Tree: git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel.git
TI-Branch: connectivity-ti-linux-4.19.y
* 'connectivity-ti-linux-4.19.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel:
arm64: dts: k3-am654-idk: Add rotary encoder DT node
tools: PCI: Add 'h' in optstring of getopt()
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
TI-Feature: connectivity
TI-Tree: git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel.git
TI-Branch: connectivity-ti-linux-4.19.y
* 'connectivity-ti-linux-4.19.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel:
arm64: dts: k3-am654-idk: Add rotary encoder DT node
tools: PCI: Add 'h' in optstring of getopt()
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
arm64: dts: k3-am654-idk: Add rotary encoder DT node
Add DT nodes to enable rotary encoder on AM654 IDK addon card conncted
to gpios of PCA9536 I2C IO expander.
Signed-off-by: Vignesh R <vigneshr@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Add DT nodes to enable rotary encoder on AM654 IDK addon card conncted
to gpios of PCA9536 I2C IO expander.
Signed-off-by: Vignesh R <vigneshr@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
tools: PCI: Add 'h' in optstring of getopt()
'h' is a valid option character for pcitest utility used to print
the pcitest usage. Add 'h' in optstring of getopt() in order to get
rid of "pcitest: invalid option -- 'h'" warning. While at that remove
unncessary case '?'.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
'h' is a valid option character for pcitest utility used to print
the pcitest usage. Add 'h' in optstring of getopt() in order to get
rid of "pcitest: invalid option -- 'h'" warning. While at that remove
unncessary case '?'.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Merge branch 'connectivity-ti-linux-4.19.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel into ti-linux-4.19.y
TI-Feature: connectivity
TI-Tree: git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel.git
TI-Branch: connectivity-ti-linux-4.19.y
* 'connectivity-ti-linux-4.19.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel:
ARM: dts: am57xx-evm: Add wilink8 wlan support
ARM: dts: dt-overlays: fixup dra71x-evm NAND support
usb: dwc3: don't log probe deferrals; but do log other error codes
arm64: dts: ti: k3-am654-pcie-usb2: Add USB host port
PCI: endpoint: functions: use memcpy_fromio()/memcpy_toio()
ARM: dts: am57xx-beagle-x15/am57xx-idk: Remove "gpios" for endpoint dt nodes
ARM: dts: am571x-idk: Fix gpios property to have the correct gpio number
ARM: dts: dra7: Add properties to enable PCIe x2 lane mode
PCI: dra7xx: Enable x2 mode support for dra74x, dra76x and dra72x
dt-bindings: PCI: dra7xx: Add properties to enable x2 lane in dra7
dt-bindings: PCI: dra7xx: Add SoC specific compatible strings
ARM: dts: beagle-x15-common: Model 5V0 regulator
Signed-off-by: Dan Murphy <dmurphy@ti.com>
TI-Feature: connectivity
TI-Tree: git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel.git
TI-Branch: connectivity-ti-linux-4.19.y
* 'connectivity-ti-linux-4.19.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel:
ARM: dts: am57xx-evm: Add wilink8 wlan support
ARM: dts: dt-overlays: fixup dra71x-evm NAND support
usb: dwc3: don't log probe deferrals; but do log other error codes
arm64: dts: ti: k3-am654-pcie-usb2: Add USB host port
PCI: endpoint: functions: use memcpy_fromio()/memcpy_toio()
ARM: dts: am57xx-beagle-x15/am57xx-idk: Remove "gpios" for endpoint dt nodes
ARM: dts: am571x-idk: Fix gpios property to have the correct gpio number
ARM: dts: dra7: Add properties to enable PCIe x2 lane mode
PCI: dra7xx: Enable x2 mode support for dra74x, dra76x and dra72x
dt-bindings: PCI: dra7xx: Add properties to enable x2 lane in dra7
dt-bindings: PCI: dra7xx: Add SoC specific compatible strings
ARM: dts: beagle-x15-common: Model 5V0 regulator
Signed-off-by: Dan Murphy <dmurphy@ti.com>
ARM: dts: am57xx-evm: Add wilink8 wlan support
On am57xx-evm, MMC3 is used for connecting wilink8 module.
Add dt node for com_3v6 and vmmcwl_fixed requlators
connected to vmmc-supply and vqmmc-supply of MMC3 dt node.
Also add wlcore dt node as a sub-node of MMC3 dt node.
MMC3 has different IODelay values for ES1.1 and ES2.0.
In order to handle this, create am57xx-evm-reva3.dtso
which has IODelay values for ES2.0, keep ES1.1 IODelay
values in am57xx-evm.dtso and create am57xx-evm-common.dtso
to keep everything that is common to both revisions.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
On am57xx-evm, MMC3 is used for connecting wilink8 module.
Add dt node for com_3v6 and vmmcwl_fixed requlators
connected to vmmc-supply and vqmmc-supply of MMC3 dt node.
Also add wlcore dt node as a sub-node of MMC3 dt node.
MMC3 has different IODelay values for ES1.1 and ES2.0.
In order to handle this, create am57xx-evm-reva3.dtso
which has IODelay values for ES2.0, keep ES1.1 IODelay
values in am57xx-evm.dtso and create am57xx-evm-common.dtso
to keep everything that is common to both revisions.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
ARM: dts: dt-overlays: fixup dra71x-evm NAND support
commit c24bb977be0d ("ARM: dts: dt-overlays: Add Support for dra71-evm NAND")
left out the important part of adding a makefile target for building
device-tree blob with NAND overlay applied.
Fix it.
Reported-by: Denys Dmytriyenko <denys@ti.com>
Fixes: c24bb977be0d ("ARM: dts: dt-overlays: Add Support for dra71-evm NAND")
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
commit c24bb977be0d ("ARM: dts: dt-overlays: Add Support for dra71-evm NAND")
left out the important part of adding a makefile target for building
device-tree blob with NAND overlay applied.
Fix it.
Reported-by: Denys Dmytriyenko <denys@ti.com>
Fixes: c24bb977be0d ("ARM: dts: dt-overlays: Add Support for dra71-evm NAND")
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
usb: dwc3: don't log probe deferrals; but do log other error codes
commit 408d3ba006af57380fa48858b39f72fde6405031 upstream.
It's not very useful to repeat a bunch of probe deferral errors. And
it's also not very useful to log "failed" without telling the error
code.
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
commit 408d3ba006af57380fa48858b39f72fde6405031 upstream.
It's not very useful to repeat a bunch of probe deferral errors. And
it's also not very useful to log "failed" without telling the error
code.
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
arm64: dts: ti: k3-am654-pcie-usb2: Add USB host port
This card has a USB 2.0 dual-role port. As the base board
already supports a 2.0 dual-role port we enable the
port on the SERDES card to be a host only port.
This will prevent user confusion as having 2 ports in
device mode often leads to confusion as to which port
is bound to the gadget function driver.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
This card has a USB 2.0 dual-role port. As the base board
already supports a 2.0 dual-role port we enable the
port on the SERDES card to be a host only port.
This will prevent user confusion as having 2 ports in
device mode often leads to confusion as to which port
is bound to the gadget function driver.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
PCI: endpoint: functions: use memcpy_fromio()/memcpy_toio()
Use the IO memcpy() functions when copying from/to IO memory.
These locations were found via sparse.
Signed-off-by: Wen Yang <wen.yang99@zte.com.cn>
Suggested-by: Kishon Vijay Abraham I <kishon@ti.com>
CC: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
CC: Bjorn Helgaas <bhelgaas@google.com>
CC: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
CC: Niklas Cassel <niklas.cassel@axis.com>
CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CC: Cyrille Pitchen <cyrille.pitchen@free-electrons.com>
CC: linux-pci@vger.kernel.org
CC: linux-kernel@vger.kernel.org
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Use the IO memcpy() functions when copying from/to IO memory.
These locations were found via sparse.
Signed-off-by: Wen Yang <wen.yang99@zte.com.cn>
Suggested-by: Kishon Vijay Abraham I <kishon@ti.com>
CC: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
CC: Bjorn Helgaas <bhelgaas@google.com>
CC: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
CC: Niklas Cassel <niklas.cassel@axis.com>
CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CC: Cyrille Pitchen <cyrille.pitchen@free-electrons.com>
CC: linux-pci@vger.kernel.org
CC: linux-kernel@vger.kernel.org
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
ARM: dts: am57xx-beagle-x15/am57xx-idk: Remove "gpios" for endpoint dt nodes
PERST# line in the PCIE connector is driver by the host mode and not
EP mode. The gpios property here is used for driving the PERST# line.
Remove gpios property from all endpoint device tree nodes.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
PERST# line in the PCIE connector is driver by the host mode and not
EP mode. The gpios property here is used for driving the PERST# line.
Remove gpios property from all endpoint device tree nodes.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
ARM: dts: am571x-idk: Fix gpios property to have the correct gpio number
commit d23f3839fe97d8dce03d ("ARM: dts: DRA7: Add pcie1 dt node for
EP mode") while adding the dt node for EP mode for DRA7 platform,
added rc node for am571x-idk and populated gpios property with
"gpio3 23". However the GPIO_PCIE_SWRST line is actually connected
to "gpio5 18". Fix it here. (The patch adding "gpio3 23" was tested
with another am57x board in EP mode which doesn't rely on reset from
host).
Fixes: d23f3839fe97d8dce03d ("ARM: dts: DRA7: Add pcie1 dt node for
EP mode")
Cc: stable <stable@vger.kernel.org> # 4.14+
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
commit d23f3839fe97d8dce03d ("ARM: dts: DRA7: Add pcie1 dt node for
EP mode") while adding the dt node for EP mode for DRA7 platform,
added rc node for am571x-idk and populated gpios property with
"gpio3 23". However the GPIO_PCIE_SWRST line is actually connected
to "gpio5 18". Fix it here. (The patch adding "gpio3 23" was tested
with another am57x board in EP mode which doesn't rely on reset from
host).
Fixes: d23f3839fe97d8dce03d ("ARM: dts: DRA7: Add pcie1 dt node for
EP mode")
Cc: stable <stable@vger.kernel.org> # 4.14+
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
ARM: dts: dra7: Add properties to enable PCIe x2 lane mode
ti,syscon-lane-sel and ti,syscon-lane-conf properties specific to enable
PCIe x2 lane mode are added here.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
ti,syscon-lane-sel and ti,syscon-lane-conf properties specific to enable
PCIe x2 lane mode are added here.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
PCI: dra7xx: Enable x2 mode support for dra74x, dra76x and dra72x
dra74x/dra76x and dra72x have separate compatible strings. Add support
for these compatible strings in pci-dra7xx driver to perform syscon
configurations required to get x2 mode working.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
dra74x/dra76x and dra72x have separate compatible strings. Add support
for these compatible strings in pci-dra7xx driver to perform syscon
configurations required to get x2 mode working.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
dt-bindings: PCI: dra7xx: Add properties to enable x2 lane in dra7
Add syscon properties required for configuring PCIe in x2 lane mode.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Add syscon properties required for configuring PCIe in x2 lane mode.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
dt-bindings: PCI: dra7xx: Add SoC specific compatible strings
Add new compatible strings for dra74x SoC (also used by dra76x) and
dra72x. This can be used to perform SoC specific configuration
(like configuring PCIe in x2 lane mode).
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Add new compatible strings for dra74x SoC (also used by dra76x) and
dra72x. This can be used to perform SoC specific configuration
(like configuring PCIe in x2 lane mode).
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
ARM: dts: beagle-x15-common: Model 5V0 regulator
On am57xx-beagle-x15, 5V0 is connected to P16, P17, P18 and P19
connectors. On am57xx-evm, 5V0 regulator is used to get 3V6 regulator
which is connected to the COMQ port. Model 5V0 regulator here in order
for it to be used in am57xx-evm to model 3V6 regulator.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
On am57xx-beagle-x15, 5V0 is connected to P16, P17, P18 and P19
connectors. On am57xx-evm, 5V0 regulator is used to get 3V6 regulator
which is connected to the COMQ port. Model 5V0 regulator here in order
for it to be used in am57xx-evm to model 3V6 regulator.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Merge branch 'connectivity-ti-linux-4.19.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel into ti-linux-4.19.y
TI-Feature: connectivity
TI-Tree: git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel.git
TI-Branch: connectivity-ti-linux-4.19.y
* 'connectivity-ti-linux-4.19.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel:
arm64: dts: k3-am6: Enable PCIe GEN3 mode in RC mode
PCI: keystone: Set DMA mask and coherent DMA mask
misc: pci_endpoint_test: Use streaming DMA APIs for buffer allocation
PCI: endpoint: functions/pci-epf-test: Use data_transfer API for tranferring data
PCI: designware-ep: Populate epf_init and data_transfer callbacks to use DMA
PCI: endpoint: Add callbacks for EPF initialization and data transfer
PCI: endpoint: Add helpers to use dmaengine APIs for data transfers
PCI: endpoint: Protect concurrent access to pci_epf_ops with mutex
PCI: endpoint: Protect concurrent access to memory allocation with mutex
PCI: endpoint: Replace spinlock with mutex
PCI: endpoint: Use notification chain mechanism to notify EPC events to EPF
ARM: dts: k2g-ice: Enable PCIe EP
ARM: dts: keystone-k2g: Add node for PCI EP
misc: pci_endpoint_test: Add support to test PCI EP in K2G
PCI: keystone: Add support for PCIe EP in K2G
PCI: dwc: designware: Add callbacks for configuring inbound and outbound ATU
ARM: dts: keystone-k2g: Change #interrupt-cells of legacy-interrupt-controller to '2'
arm64: dts: k3-am6: Change #interrupt-cells of legacy-interrupt-controller to '2'
dt-bindings: PCI: Fix legacy-interrupt-controller #interrupt-cells to be '2'
PCI: keystone: Fix error handling when "num-viewport" dt binding is not populated
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
TI-Feature: connectivity
TI-Tree: git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel.git
TI-Branch: connectivity-ti-linux-4.19.y
* 'connectivity-ti-linux-4.19.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel:
arm64: dts: k3-am6: Enable PCIe GEN3 mode in RC mode
PCI: keystone: Set DMA mask and coherent DMA mask
misc: pci_endpoint_test: Use streaming DMA APIs for buffer allocation
PCI: endpoint: functions/pci-epf-test: Use data_transfer API for tranferring data
PCI: designware-ep: Populate epf_init and data_transfer callbacks to use DMA
PCI: endpoint: Add callbacks for EPF initialization and data transfer
PCI: endpoint: Add helpers to use dmaengine APIs for data transfers
PCI: endpoint: Protect concurrent access to pci_epf_ops with mutex
PCI: endpoint: Protect concurrent access to memory allocation with mutex
PCI: endpoint: Replace spinlock with mutex
PCI: endpoint: Use notification chain mechanism to notify EPC events to EPF
ARM: dts: k2g-ice: Enable PCIe EP
ARM: dts: keystone-k2g: Add node for PCI EP
misc: pci_endpoint_test: Add support to test PCI EP in K2G
PCI: keystone: Add support for PCIe EP in K2G
PCI: dwc: designware: Add callbacks for configuring inbound and outbound ATU
ARM: dts: keystone-k2g: Change #interrupt-cells of legacy-interrupt-controller to '2'
arm64: dts: k3-am6: Change #interrupt-cells of legacy-interrupt-controller to '2'
dt-bindings: PCI: Fix legacy-interrupt-controller #interrupt-cells to be '2'
PCI: keystone: Fix error handling when "num-viewport" dt binding is not populated
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
Merge branch 'audio_display-ti-linux-4.19.y' of git.ti.com:~jyrisarha/ti-linux-kernel/jyrisarhas-audio-video-linux-feature-tree into ti-linux-4.19.y
TI-Feature: audio-display
TI-Tree: git@git.ti.com:~jyrisarha/ti-linux-kernel/jyrisarhas-audio-video-linux-feature-tree.git
TI-Branch: audio_display-ti-linux-4.19.y
* 'audio_display-ti-linux-4.19.y' of git.ti.com:~jyrisarha/ti-linux-kernel/jyrisarhas-audio-video-linux-feature-tree:
ARM: dts: keystone-k2g-evm-lcd: Fix non bidirectional graph connection
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
TI-Feature: audio-display
TI-Tree: git@git.ti.com:~jyrisarha/ti-linux-kernel/jyrisarhas-audio-video-linux-feature-tree.git
TI-Branch: audio_display-ti-linux-4.19.y
* 'audio_display-ti-linux-4.19.y' of git.ti.com:~jyrisarha/ti-linux-kernel/jyrisarhas-audio-video-linux-feature-tree:
ARM: dts: keystone-k2g-evm-lcd: Fix non bidirectional graph connection
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
net/rpmsg: unblock reader threads operating on errored sockets
The rpmsg_proto driver is used to provide a socket interface
to userspace under the AF_RPMSG address family, and is used
by the TI IPC MessageQ stack. The typical usage for receiving
messages include a thread blocked on a select() call with
appropriate socket fds, followed by a recvfrom() on the fd
returned/marked ready by select().
The rpmsg_sock_poll() function implements the logic needed
by the select() call, and marks a socket ready only when there
is data to be read currently. Any reader thread waiting on the
select() call to return is currently not unblocked when a remote
processor goes through an error recovery, and can remain blocked
forever as its remote processor peer thread may never send it
another message. Enhance the rpmsg_proto driver so that a waiting
thread can be unblocked by waking it up during the process of
marking the open sockets with the error status RPMSG_ERROR. This
is achieved by using the socket's .sk_error_report() ops, and is
preferred over the .sk_state_change() ops to wakeup only a single
exclusive thread.
Signed-off-by: Suman Anna <s-anna@ti.com>
The rpmsg_proto driver is used to provide a socket interface
to userspace under the AF_RPMSG address family, and is used
by the TI IPC MessageQ stack. The typical usage for receiving
messages include a thread blocked on a select() call with
appropriate socket fds, followed by a recvfrom() on the fd
returned/marked ready by select().
The rpmsg_sock_poll() function implements the logic needed
by the select() call, and marks a socket ready only when there
is data to be read currently. Any reader thread waiting on the
select() call to return is currently not unblocked when a remote
processor goes through an error recovery, and can remain blocked
forever as its remote processor peer thread may never send it
another message. Enhance the rpmsg_proto driver so that a waiting
thread can be unblocked by waking it up during the process of
marking the open sockets with the error status RPMSG_ERROR. This
is achieved by using the socket's .sk_error_report() ops, and is
preferred over the .sk_state_change() ops to wakeup only a single
exclusive thread.
Signed-off-by: Suman Anna <s-anna@ti.com>
net/rpmsg: return ENOLINK upon Rx on errored sockets
The rpmsg_proto driver is used to provide a socket interface to
userspace under the AF_RPMSG address family, and is used by the TI
IPC MessageQ stack. The rpmsg proto driver creates a rpmsg endpoint
per remote processor (a Rx socket) for each MessageQ object through
the socket's bind() call. These rpmsg endpoints are associated with
a published parent rpmsg device from that remote processor. These
endpoints are cleaned up normally either when the userspace program
/ application closes them or through the automatic cleanup of the
file descriptors when a process is terminated/closed. These endpoints
can also be cleaned up by the rpmsg_proto driver as part of the error
recovery of a remote processor, during the removal of their parent
rpmsg device, with the corresponding Rx sockets simply marked with
the error status RPMSG_ERROR.
This error status is not currently being returned to the userspace
in the socket's recvfrom() interface. Fix this by specifically
checking for this error status, and returning an error value of
ENOLINK back to userspace. The ENOLINK error code is used to allow
the userspace to differentiate this terminal error from other errors
on the Rx sockets and take appropriate action. This error code on
Rx sockets serves the same as the error code ESHUTDOWN used for Tx
sockets, and is chosen specifically to have a meaningful strerror
message appropriate to Rx sockets.
Signed-off-by: Suman Anna <s-anna@ti.com>
The rpmsg_proto driver is used to provide a socket interface to
userspace under the AF_RPMSG address family, and is used by the TI
IPC MessageQ stack. The rpmsg proto driver creates a rpmsg endpoint
per remote processor (a Rx socket) for each MessageQ object through
the socket's bind() call. These rpmsg endpoints are associated with
a published parent rpmsg device from that remote processor. These
endpoints are cleaned up normally either when the userspace program
/ application closes them or through the automatic cleanup of the
file descriptors when a process is terminated/closed. These endpoints
can also be cleaned up by the rpmsg_proto driver as part of the error
recovery of a remote processor, during the removal of their parent
rpmsg device, with the corresponding Rx sockets simply marked with
the error status RPMSG_ERROR.
This error status is not currently being returned to the userspace
in the socket's recvfrom() interface. Fix this by specifically
checking for this error status, and returning an error value of
ENOLINK back to userspace. The ENOLINK error code is used to allow
the userspace to differentiate this terminal error from other errors
on the Rx sockets and take appropriate action. This error code on
Rx sockets serves the same as the error code ESHUTDOWN used for Tx
sockets, and is chosen specifically to have a meaningful strerror
message appropriate to Rx sockets.
Signed-off-by: Suman Anna <s-anna@ti.com>
net/rpmsg: return ESHUTDOWN upon Tx on errored sockets
The rpmsg proto driver uses a single rpmsg channel device
published from a remote processor to transmit all socket-based
messages intended for that remote processor. This channel will
be auto-removed and recreated if the remote processor goes
through an error recovery process. Any connected sockets are
marked with an error status, and further transmissions on these
connected sockets should gracefully return an error. This error
condition is specifically checked for and a new error ESHUTDOWN
is returned back to userspace to differentiate it from
transmissions on an unconnected socket.
Signed-off-by: Suman Anna <s-anna@ti.com>
The rpmsg proto driver uses a single rpmsg channel device
published from a remote processor to transmit all socket-based
messages intended for that remote processor. This channel will
be auto-removed and recreated if the remote processor goes
through an error recovery process. Any connected sockets are
marked with an error status, and further transmissions on these
connected sockets should gracefully return an error. This error
condition is specifically checked for and a new error ESHUTDOWN
is returned back to userspace to differentiate it from
transmissions on an unconnected socket.
Signed-off-by: Suman Anna <s-anna@ti.com>
net/rpmsg: add support to handle a remote processor error recovery
The rpmsg_proto driver is used to provide a socket interface to
userspace under the AF_RPMSG address family, and is used by the
TI IPC MessageQ stack. The rpmsg proto driver uses a single rpmsg
channel device published from a remote processor to transmit and
receive all socket-based messages to/from that remote processor.
There can be any number of Tx and Rx sockets associated with each
remote processor's rpmsg device. This rpmsg channel device will be
auto-removed and recreated if the associated remote processor goes
through an error recovery process. Any existing open sockets (both
Tx and Rx) are oblivious if the underlying rpmsg channel has been
removed, and any further operations on such sockets can create
various kernel crashes due to invalid pointer dereferences.
This patch adds the error recovery support to the rpmsg-proto driver.
This is achieved by using the private field of the published rpmsg
channel device's endpoint (ept->priv) to maintain a list of all the
connected and bound sockets, and setting a new error status
(RPMSG_ERROR) on all these open sockets when the associated parent
rpmsg device is removed. This new error status allows the driver
to check for a valid state of a socket before performing any actions
on it thereby preventing any kernel crashes. The status is also used
to allow the userspace to perform appropriate cleanup and/or recovery
steps.
The logic is asymmetric because of the slight difference between the
Rx and Tx sockets. All the Tx sockets use the one-time published
rpmsg_channel devices for transmissions and just need to be marked
with the error status, while each of the Rx sockets have their own
derivative rpmsg endpoints, and so need to be removed alongside the
removal of the associated rpmsg channel device in addition. The
sockets themselves are freed up anytime either by the userspace
closing them or through an automatic close when the process is
terminated/closed.
Signed-off-by: Suman Anna <s-anna@ti.com>
The rpmsg_proto driver is used to provide a socket interface to
userspace under the AF_RPMSG address family, and is used by the
TI IPC MessageQ stack. The rpmsg proto driver uses a single rpmsg
channel device published from a remote processor to transmit and
receive all socket-based messages to/from that remote processor.
There can be any number of Tx and Rx sockets associated with each
remote processor's rpmsg device. This rpmsg channel device will be
auto-removed and recreated if the associated remote processor goes
through an error recovery process. Any existing open sockets (both
Tx and Rx) are oblivious if the underlying rpmsg channel has been
removed, and any further operations on such sockets can create
various kernel crashes due to invalid pointer dereferences.
This patch adds the error recovery support to the rpmsg-proto driver.
This is achieved by using the private field of the published rpmsg
channel device's endpoint (ept->priv) to maintain a list of all the
connected and bound sockets, and setting a new error status
(RPMSG_ERROR) on all these open sockets when the associated parent
rpmsg device is removed. This new error status allows the driver
to check for a valid state of a socket before performing any actions
on it thereby preventing any kernel crashes. The status is also used
to allow the userspace to perform appropriate cleanup and/or recovery
steps.
The logic is asymmetric because of the slight difference between the
Rx and Tx sockets. All the Tx sockets use the one-time published
rpmsg_channel devices for transmissions and just need to be marked
with the error status, while each of the Rx sockets have their own
derivative rpmsg endpoints, and so need to be removed alongside the
removal of the associated rpmsg channel device in addition. The
sockets themselves are freed up anytime either by the userspace
closing them or through an automatic close when the process is
terminated/closed.
Signed-off-by: Suman Anna <s-anna@ti.com>
rpmsg: rpc: fix potential memory leak of unprocessed skbs
A user thread sends a request for a remote function execution
on the remote processor through a write() fop. All the responses
from the remote service are queued using allocated skbs in the
driver's rpmsg callback. The allocated skbs are processed and
freed in a read() fop. An error recovery causes a blocked user
thread to bail out immediately and any in-flight queued skbs
are left unprocessed. These in-flight skbs are never freed and
can result in a memory leak.
Fix the memory leak by checking for the presence of any of these
unprocessed skbs in the read queue, and freeing them during the
file descriptor's release() function. This also ensures no memory
is leaked for user applications with bugs and not using matching
write() and read() fops.
Signed-off-by: Suman Anna <s-anna@ti.com>
A user thread sends a request for a remote function execution
on the remote processor through a write() fop. All the responses
from the remote service are queued using allocated skbs in the
driver's rpmsg callback. The allocated skbs are processed and
freed in a read() fop. An error recovery causes a blocked user
thread to bail out immediately and any in-flight queued skbs
are left unprocessed. These in-flight skbs are never freed and
can result in a memory leak.
Fix the memory leak by checking for the presence of any of these
unprocessed skbs in the read queue, and freeing them during the
file descriptor's release() function. This also ensures no memory
is leaked for user applications with bugs and not using matching
write() and read() fops.
Signed-off-by: Suman Anna <s-anna@ti.com>
rpmsg: rpc: fix ept memory leak during recovery
The rpmsg-rpc driver exposes a character device for each remote
service (a rpmsg-rpc device) providing a bunch of remote execution
functions. An endpoint is created in the open() fops, and forms the
source end-point of a dedicated communication channel to allow an
application to send and receive remote function execution commands/
responses on this service. This endpoint address is a child of the
parent virtio device to which the rpmsg-rpc device belongs to. The
virtio devices are deleted and recreated during a remoteproc crash
and recovery process. The associated child endpoints are not deleted
at present during recovery, and the corresponding release() cannot
delete the end-points if it happens after a recovery as the parent
rpmsg-rpc device has already been removed, thereby resulting in a
memory leak during recovery amidst an active usage.
Fix this by deleting all the epts associated with the parent virtio
device of the corresponding rpmsg-rpc device. This is done during the
rpmsg-rpc driver's .remove() which is invoked during the deletion of
the virtio device.
Signed-off-by: Suman Anna <s-anna@ti.com>
The rpmsg-rpc driver exposes a character device for each remote
service (a rpmsg-rpc device) providing a bunch of remote execution
functions. An endpoint is created in the open() fops, and forms the
source end-point of a dedicated communication channel to allow an
application to send and receive remote function execution commands/
responses on this service. This endpoint address is a child of the
parent virtio device to which the rpmsg-rpc device belongs to. The
virtio devices are deleted and recreated during a remoteproc crash
and recovery process. The associated child endpoints are not deleted
at present during recovery, and the corresponding release() cannot
delete the end-points if it happens after a recovery as the parent
rpmsg-rpc device has already been removed, thereby resulting in a
memory leak during recovery amidst an active usage.
Fix this by deleting all the epts associated with the parent virtio
device of the corresponding rpmsg-rpc device. This is done during the
rpmsg-rpc driver's .remove() which is invoked during the deletion of
the virtio device.
Signed-off-by: Suman Anna <s-anna@ti.com>
rpmsg: rpc: use the local device pointer in all file operations
The remote processor recovery process includes the deletion and
recreation of an rpmsg-rpc device. The representative rppc_device
structure is retained and reused if there are any open applications
using the exposed character device. The underlying device pointer
for a rppc_device is though deleted and recreated and can become
NULL at any point if an error recovery happens. So, switch to using
the local reference device pointer in all the fop functions for
the exposed character device.
Signed-off-by: Suman Anna <s-anna@ti.com>
The remote processor recovery process includes the deletion and
recreation of an rpmsg-rpc device. The representative rppc_device
structure is retained and reused if there are any open applications
using the exposed character device. The underlying device pointer
for a rppc_device is though deleted and recreated and can become
NULL at any point if an error recovery happens. So, switch to using
the local reference device pointer in all the fop functions for
the exposed character device.
Signed-off-by: Suman Anna <s-anna@ti.com>
rpmsg: rpc: maintain a reference device pointer per open fd
The remote processor recovery process includes the deletion and
recreation of an rpmsg-rpc device. The representative rppc_device
structure is retained and reused if there are any open applications
using the exposed character device. The underlying device pointer
for a rppc_device is though deleted and recreated and is asynchronous
to any of the operations on the exposed character device. A reference
to this device pointer is to be maintained therefore for each open
application so that it can be used during regular fops and until the
file descriptor is closed instead of referencing the rppc_device's
dev pointer, which can become NULL at any point due to a recovery
process. The actual memory of the rppc_device's dev pointer deleted
in the driver's .remove() is freed when all the open applications
have closed either gracefully or forcefully. Any new applications
after a recovery will leverage a newly created device pointer.
Signed-off-by: Suman Anna <s-anna@ti.com>
The remote processor recovery process includes the deletion and
recreation of an rpmsg-rpc device. The representative rppc_device
structure is retained and reused if there are any open applications
using the exposed character device. The underlying device pointer
for a rppc_device is though deleted and recreated and is asynchronous
to any of the operations on the exposed character device. A reference
to this device pointer is to be maintained therefore for each open
application so that it can be used during regular fops and until the
file descriptor is closed instead of referencing the rppc_device's
dev pointer, which can become NULL at any point due to a recovery
process. The actual memory of the rppc_device's dev pointer deleted
in the driver's .remove() is freed when all the open applications
have closed either gracefully or forcefully. Any new applications
after a recovery will leverage a newly created device pointer.
Signed-off-by: Suman Anna <s-anna@ti.com>
rpmsg: rpc: fix sysfs entry creation failures during recovery
The rpmsg-rpc driver exposes a character device for each remote
service (a rpmsg-rpc device) providing a bunch of remote execution
functions. The remote service can be running on any of the available
remote processors, and the supported functions are published as
different sysfs entries on that particular device. These rpmsg-rpc
devices are deleted and recreated as part of the reboot of the remote
processor during an error recovery. The sysfs entries are also deleted
and recreated. The current logic retains the associated rppc_device
structure and the underlying device pointer if there are any
applications actively using the character device at the time of the
rpmsg-rpc device removal, and reuses it upon the reprobe of the same
rpmsg-rpc device. The creation of the sysfs entries fails with -ENOENT
due to an invalid reference to a non-existing parent object, and this
is exposed first in 3.14 kernel due to the repartitioning of the core
sysfs code into a new common kernfs code.
Fix this by deleting the underlying device pointer in the driver's
.remove, and recreating it with the appropriate new rpmsg server
device as its parent in the driver's .probe function. A name
description field is also added to the representative rppc_device
structure for looking up the service on reprobe as the device name
cannot be used due to the deletion of the device pointer.
Signed-off-by: Suman Anna <s-anna@ti.com>
The rpmsg-rpc driver exposes a character device for each remote
service (a rpmsg-rpc device) providing a bunch of remote execution
functions. The remote service can be running on any of the available
remote processors, and the supported functions are published as
different sysfs entries on that particular device. These rpmsg-rpc
devices are deleted and recreated as part of the reboot of the remote
processor during an error recovery. The sysfs entries are also deleted
and recreated. The current logic retains the associated rppc_device
structure and the underlying device pointer if there are any
applications actively using the character device at the time of the
rpmsg-rpc device removal, and reuses it upon the reprobe of the same
rpmsg-rpc device. The creation of the sysfs entries fails with -ENOENT
due to an invalid reference to a non-existing parent object, and this
is exposed first in 3.14 kernel due to the repartitioning of the core
sysfs code into a new common kernfs code.
Fix this by deleting the underlying device pointer in the driver's
.remove, and recreating it with the appropriate new rpmsg server
device as its parent in the driver's .probe function. A name
description field is also added to the representative rppc_device
structure for looking up the service on reprobe as the device name
cannot be used due to the deletion of the device pointer.
Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: dts: keystone-k2g-evm-lcd: Fix non bidirectional graph connection
While disabling sii9022 and connecting lcd node to dss instead is
enough to make lcd work, even the disabled sii9022 node with a port
node endpoint without backward link causes a dtb warning.
Delete sii9022 node completely to fix this. When sii9022 node goes, so
must sound1 and hdmi nodes that refer to it.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
While disabling sii9022 and connecting lcd node to dss instead is
enough to make lcd work, even the disabled sii9022 node with a port
node endpoint without backward link causes a dtb warning.
Delete sii9022 node completely to fix this. When sii9022 node goes, so
must sound1 and hdmi nodes that refer to it.
Signed-off-by: Jyri Sarha <jsarha@ti.com>