Merged TI feature connectivity into ti-linux-4.19.y
TI-Feature: connectivity
TI-Branch: connectivity-ti-linux-4.19.y
* 'connectivity-ti-linux-4.19.y' of ssh://bitbucket.itg.ti.com/lcpdpublicdom/connectivity:
net: phy: dp83867: enable robust auto-mdix
HACK: Revert "net: ethernet: ti: am65-cpsw-nuss: clean up am65_cpsw_nuss_ndo_slave_stop()"
arm64: dts: ti: k3-j721e-mcu-wakeup: Increase HBMC bus clock to 125MHz
mmc: sdhci_am654: Remove Inverted Write Protect flag
arm64: dts: ti: k3-j721-common-proc-board: Fix write protect handling
arm64: dts: ti: k3-am654-base-board: Fix MMC Write Protect handling
arm64: dts: k3-j721e-proc-board-tps65917: change cpsw2g interface mode to rgmii-rxid
arm64: dts: k3-j721e-common-proc-board: change cpsw2g interface mode to rgmii-rxid
arm64: dts: ti: k3-j721e-proc-board-tps65917: disable main_uart2 for eth switch fw
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
TI-Feature: connectivity
TI-Branch: connectivity-ti-linux-4.19.y
* 'connectivity-ti-linux-4.19.y' of ssh://bitbucket.itg.ti.com/lcpdpublicdom/connectivity:
net: phy: dp83867: enable robust auto-mdix
HACK: Revert "net: ethernet: ti: am65-cpsw-nuss: clean up am65_cpsw_nuss_ndo_slave_stop()"
arm64: dts: ti: k3-j721e-mcu-wakeup: Increase HBMC bus clock to 125MHz
mmc: sdhci_am654: Remove Inverted Write Protect flag
arm64: dts: ti: k3-j721-common-proc-board: Fix write protect handling
arm64: dts: ti: k3-am654-base-board: Fix MMC Write Protect handling
arm64: dts: k3-j721e-proc-board-tps65917: change cpsw2g interface mode to rgmii-rxid
arm64: dts: k3-j721e-common-proc-board: change cpsw2g interface mode to rgmii-rxid
arm64: dts: ti: k3-j721e-proc-board-tps65917: disable main_uart2 for eth switch fw
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
Merged TI feature platform_base into ti-linux-4.19.y
TI-Feature: platform_base
TI-Branch: platform-ti-linux-4.19.y
* 'platform-ti-linux-4.19.y' of ssh://bitbucket.itg.ti.com/lcpdpublicdom/platform:
arm64: dts: k3-j721e: Add gpio-keys on alpha proc board
clk: ti: dra7-atl-clock: Remove unused variable
arm64: dts: ti: k3-j721e-main: Add missing power-domains for smmu
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
TI-Feature: platform_base
TI-Branch: platform-ti-linux-4.19.y
* 'platform-ti-linux-4.19.y' of ssh://bitbucket.itg.ti.com/lcpdpublicdom/platform:
arm64: dts: k3-j721e: Add gpio-keys on alpha proc board
clk: ti: dra7-atl-clock: Remove unused variable
arm64: dts: ti: k3-j721e-main: Add missing power-domains for smmu
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
Merged TI feature rpmsg into ti-linux-4.19.y
TI-Feature: rpmsg
TI-Branch: rpmsg-ti-linux-4.19.y-intg
* 'rpmsg-ti-linux-4.19.y-intg' of git://git.ti.com/rpmsg/rpmsg:
remoteproc/k3-dsp: fix memzero issues with C66x L2SRAM
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
TI-Feature: rpmsg
TI-Branch: rpmsg-ti-linux-4.19.y-intg
* 'rpmsg-ti-linux-4.19.y-intg' of git://git.ti.com/rpmsg/rpmsg:
remoteproc/k3-dsp: fix memzero issues with C66x L2SRAM
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
arm64: dts: k3-j721e: Add gpio-keys on alpha proc board
Common processor board for K3 J721E platform has two push buttons
namely SW10 and SW11.
Add a gpio-keys device node to model them as input keys in Linux.
Add required pinmux nodes to set GPIO pins as input.
Add these DT entries in the alpha proc board DTS
Fixes: 38faa4b (arm64: dts: k3-j721e: Add gpio-keys on common processor board)
Signed-off-by: Nikhil Devshatwar <a0132237@ti.com>
Common processor board for K3 J721E platform has two push buttons
namely SW10 and SW11.
Add a gpio-keys device node to model them as input keys in Linux.
Add required pinmux nodes to set GPIO pins as input.
Add these DT entries in the alpha proc board DTS
Fixes: 38faa4b (arm64: dts: k3-j721e: Add gpio-keys on common processor board)
Signed-off-by: Nikhil Devshatwar <a0132237@ti.com>
clk: ti: dra7-atl-clock: Remove unused variable
Commit 3255ae4ea016 left the ret variable which is now unused.
Fixes: 3255ae4ea016 ("clk: ti: dra7-atl-clock: Remove ti_clk_add_alias call")
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Commit 3255ae4ea016 left the ret variable which is now unused.
Fixes: 3255ae4ea016 ("clk: ti: dra7-atl-clock: Remove ti_clk_add_alias call")
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
arm64: dts: ti: k3-j721e-main: Add missing power-domains for smmu
Add power-domains entry for smmu, so that the it is accessible as long
as the driver is active. Without this device shutdown is throwing the
below warning:
"[ 44.736348] arm-smmu-v3 36600000.smmu: failed to clear cr0"
Reported-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Acked-by: Suman Anna <s-anna@ti.com>
Add power-domains entry for smmu, so that the it is accessible as long
as the driver is active. Without this device shutdown is throwing the
below warning:
"[ 44.736348] arm-smmu-v3 36600000.smmu: failed to clear cr0"
Reported-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Acked-by: Suman Anna <s-anna@ti.com>
net: phy: dp83867: enable robust auto-mdix
CFG3[9] Robust Auto-MDIX option allows significantly improve link detection
in case dp83867 is configured in manual mode and reduce link detection
time.
DM says: "If link partners are configured to operational modes that are not
supported by normal Auto MDI/MDIX mode (like Auto-Neg versus Force
100Base-TX or Force 100Base-TX versus Force 100Base-TX), this Robust Auto
MDI/MDIX mode allows MDI/MDIX resolution and prevents deadlock."
Hence, enable this option by default as there are no known reasons not to do so.
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
CFG3[9] Robust Auto-MDIX option allows significantly improve link detection
in case dp83867 is configured in manual mode and reduce link detection
time.
DM says: "If link partners are configured to operational modes that are not
supported by normal Auto MDI/MDIX mode (like Auto-Neg versus Force
100Base-TX or Force 100Base-TX versus Force 100Base-TX), this Robust Auto
MDI/MDIX mode allows MDI/MDIX resolution and prevents deadlock."
Hence, enable this option by default as there are no known reasons not to do so.
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
HACK: Revert "net: ethernet: ti: am65-cpsw-nuss: clean up am65_cpsw_nuss_ndo_slave_stop()"
This partially reverts commit 358e2e633ad0 ("net: ethernet: ti:
am65-cpsw-nuss: clean up am65_cpsw_nuss_ndo_slave_stop()") and restores
netif_carrier_on()/netif_carrier_off() in am65_cpsw_nuss_adjust_link().
This required to fix manual PHY link configuration in which case Network
core TX watchdog will be triggered periodically. The same is fixed in LKML
Network PHY core, so marked in HACK.
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
This partially reverts commit 358e2e633ad0 ("net: ethernet: ti:
am65-cpsw-nuss: clean up am65_cpsw_nuss_ndo_slave_stop()") and restores
netif_carrier_on()/netif_carrier_off() in am65_cpsw_nuss_adjust_link().
This required to fix manual PHY link configuration in which case Network
core TX watchdog will be triggered periodically. The same is fixed in LKML
Network PHY core, so marked in HACK.
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
arm64: dts: ti: k3-j721e-mcu-wakeup: Increase HBMC bus clock to 125MHz
HBMC bus speed can be as high as 125MHz. Therefore set the functional
clock to 250MHz (which runs at twice the bus frequency) so that bus runs
at 125MHz.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
HBMC bus speed can be as high as 125MHz. Therefore set the functional
clock to 250MHz (which runs at twice the bus frequency) so that bus runs
at 125MHz.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
mmc: sdhci_am654: Remove Inverted Write Protect flag
The MMC/SD controllers on am65x and j721e don't in fact detect the write
protect line as inverted. No issues were detected because of this
because the sdwp line is not connected on any of the evms. Fix this by
removing the flag.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
The MMC/SD controllers on am65x and j721e don't in fact detect the write
protect line as inverted. No issues were detected because of this
because the sdwp line is not connected on any of the evms. Fix this by
removing the flag.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
arm64: dts: ti: k3-j721-common-proc-board: Fix write protect handling
MMC0_SDWP and MMC1_SDWP are not connected to the card/frame on the
common-processor-board. Indicate this by adding the disable-wp flag.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
MMC0_SDWP and MMC1_SDWP are not connected to the card/frame on the
common-processor-board. Indicate this by adding the disable-wp flag.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
arm64: dts: ti: k3-am654-base-board: Fix MMC Write Protect handling
Neither of MMC0_SDWP and MMC1_SDWP are connected to the card/frame in
the base board. Add the disable-wp flag to indicate this.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Neither of MMC0_SDWP and MMC1_SDWP are connected to the card/frame in
the base board. Add the disable-wp flag to indicate this.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
arm64: dts: k3-j721e-proc-board-tps65917: change cpsw2g interface mode to rgmii-rxid
The J721E SoC doesn't allow to disabling RGMII TX internal delay in CPSW2G
MAC. Hence, change CPSW2G interface mode to "rgmii-rxid" - RGMII with
internal RX delay provided by the PHY, the MAC will add an TX delay in this
case.
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
The J721E SoC doesn't allow to disabling RGMII TX internal delay in CPSW2G
MAC. Hence, change CPSW2G interface mode to "rgmii-rxid" - RGMII with
internal RX delay provided by the PHY, the MAC will add an TX delay in this
case.
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
arm64: dts: k3-j721e-common-proc-board: change cpsw2g interface mode to rgmii-rxid
The J721E SoC doesn't allow to disabling RGMII TX internal delay in CPSW2G
MAC. Hence, change CPSW2G interface mode to "rgmii-rxid" - RGMII with
internal RX delay provided by the PHY, the MAC will add an TX delay in this
case.
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
The J721E SoC doesn't allow to disabling RGMII TX internal delay in CPSW2G
MAC. Hence, change CPSW2G interface mode to "rgmii-rxid" - RGMII with
internal RX delay provided by the PHY, the MAC will add an TX delay in this
case.
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
arm64: dts: ti: k3-j721e-proc-board-tps65917: disable main_uart2 for eth switch fw
The main_uart2 is used by eth switch fw running on remote R5F core, so
it has to be hidden from Linux.
This is sync with k3-j721e-common-proc-board.dts.
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
The main_uart2 is used by eth switch fw running on remote R5F core, so
it has to be hidden from Linux.
This is sync with k3-j721e-common-proc-board.dts.
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
remoteproc/k3-dsp: fix memzero issues with C66x L2SRAM
The K3 DSP remoteproc driver supports loading into and executing
code from the DSP internal RAMs, and this feature is enabled after
commit 1f1884de505c ("remoteproc/k3-dsp: Add support for L2RAM
loading on C66x DSPs"). These regions are currently mapped as
device type memory due to the usage of the devm_ioremap_resource()
function.
The remoteproc core ELF loader function zeroes out any remaining
portions of a program segment if the actual memory size (p_memsz)
is more than the loadable content (p_filesz), and this memset can
throw a kernel crash on these DSP internal memories. This is due
to the usage of the "DC ZVA" instruction within the Arm64 memset
library function when zeroing out memory, which throws an alignment
fault on device type memory.
So, update the mapping logic to instead use the devm_ioremap_wc()
function to map these memory regions as Normal Non-Cached memories,
and thereby fix the issues with memset().
An example crash log looks like below:
remoteproc remoteproc0: phdr: type 1 da 0x800000 memsz 0x4a20 filesz 0x4a20
remoteproc remoteproc0: phdr: type 1 da 0x804a20 memsz 0x378 filesz 0x0
Unable to handle kernel paging request at virtual address ffff000012604a40
Mem abort info:
ESR = 0x96000061
Exception class = DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
Data abort info:
ISV = 0, ISS = 0x00000061
CM = 0, WnR = 1
swapper pgtable: 64k pages, 48-bit VAs, pgdp = 00000000f098b163
[ffff000012604a40] pgd=00000008fffe0003, pud=00000008fffe0003, pmd=00000008fffd0003, pte=00e8004d80800707
Internal error: Oops: 96000061 [#1] PREEMPT SMP
Modules linked in: ti_k3_dsp_remoteproc virtio_rpmsg_bus remoteproc
Process kworker/1:0 (pid: 18, stack limit = 0x000000002b4c701b)
CPU: 1 PID: 18 Comm: kworker/1:0 Not tainted 4.19.73-00004-g5de400066f93 #354
Hardware name: Texas Instruments K3 J721E SoC (DT)
Workqueue: events request_firmware_work_func
pstate: 80000005 (Nzcv daif -PAN -UAO)
pc : __memset+0x16c/0x188
lr : rproc_elf_load_segments+0x100/0x1c8 [remoteproc]
sp : ffff0000093afc80
x29: ffff0000093afc80 x28: ffff80084178a838
x27: 0000000000004a60 x26: 0000000000000378
x25: ffff80084178a800 x24: ffff80084a6fca80
x23: ffff000012b10000 x22: 0000000000804a20
x21: 0000000000000000 x20: 0000000000000001
x19: ffff000012fd65bc x18: 0000000000000087
x17: 0000000000000000 x16: 0000000000000000
x15: 0000000000000400 x14: 0000000000000400
x13: 00000000000001ab x12: 0000000000000000
x11: 0000000000000001 x10: 0000000000000980
x9 : 0000000000000000 x8 : ffff000012604a40
x7 : 0000000000000000 x6 : 000000000000003f
x5 : 0000000000000040 x4 : ffffffffffffffe0
x3 : 0000000000000358 x2 : 0000000000000318
x1 : 0000000000000000 x0 : ffff000012604a20
Call trace:
__memset+0x16c/0x188
rproc_boot+0x404/0x668 [remoteproc]
rproc_auto_boot_callback+0x18/0x30 [remoteproc]
request_firmware_work_func+0x48/0x88
process_one_work+0x1e0/0x318
worker_thread+0x40/0x428
kthread+0x124/0x128
ret_from_fork+0x10/0x18
Code: 91010108 54ffff4a 8b040108 cb050042 (d50b7428)
---[ end trace eafd1b2b63d14eb0 ]---
Fixes: af9493dd36d4 ("remoteproc/k3-dsp: add a remoteproc driver of K3 C66x DSPs")
Signed-off-by: Suman Anna <s-anna@ti.com>
The K3 DSP remoteproc driver supports loading into and executing
code from the DSP internal RAMs, and this feature is enabled after
commit 1f1884de505c ("remoteproc/k3-dsp: Add support for L2RAM
loading on C66x DSPs"). These regions are currently mapped as
device type memory due to the usage of the devm_ioremap_resource()
function.
The remoteproc core ELF loader function zeroes out any remaining
portions of a program segment if the actual memory size (p_memsz)
is more than the loadable content (p_filesz), and this memset can
throw a kernel crash on these DSP internal memories. This is due
to the usage of the "DC ZVA" instruction within the Arm64 memset
library function when zeroing out memory, which throws an alignment
fault on device type memory.
So, update the mapping logic to instead use the devm_ioremap_wc()
function to map these memory regions as Normal Non-Cached memories,
and thereby fix the issues with memset().
An example crash log looks like below:
remoteproc remoteproc0: phdr: type 1 da 0x800000 memsz 0x4a20 filesz 0x4a20
remoteproc remoteproc0: phdr: type 1 da 0x804a20 memsz 0x378 filesz 0x0
Unable to handle kernel paging request at virtual address ffff000012604a40
Mem abort info:
ESR = 0x96000061
Exception class = DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
Data abort info:
ISV = 0, ISS = 0x00000061
CM = 0, WnR = 1
swapper pgtable: 64k pages, 48-bit VAs, pgdp = 00000000f098b163
[ffff000012604a40] pgd=00000008fffe0003, pud=00000008fffe0003, pmd=00000008fffd0003, pte=00e8004d80800707
Internal error: Oops: 96000061 [#1] PREEMPT SMP
Modules linked in: ti_k3_dsp_remoteproc virtio_rpmsg_bus remoteproc
Process kworker/1:0 (pid: 18, stack limit = 0x000000002b4c701b)
CPU: 1 PID: 18 Comm: kworker/1:0 Not tainted 4.19.73-00004-g5de400066f93 #354
Hardware name: Texas Instruments K3 J721E SoC (DT)
Workqueue: events request_firmware_work_func
pstate: 80000005 (Nzcv daif -PAN -UAO)
pc : __memset+0x16c/0x188
lr : rproc_elf_load_segments+0x100/0x1c8 [remoteproc]
sp : ffff0000093afc80
x29: ffff0000093afc80 x28: ffff80084178a838
x27: 0000000000004a60 x26: 0000000000000378
x25: ffff80084178a800 x24: ffff80084a6fca80
x23: ffff000012b10000 x22: 0000000000804a20
x21: 0000000000000000 x20: 0000000000000001
x19: ffff000012fd65bc x18: 0000000000000087
x17: 0000000000000000 x16: 0000000000000000
x15: 0000000000000400 x14: 0000000000000400
x13: 00000000000001ab x12: 0000000000000000
x11: 0000000000000001 x10: 0000000000000980
x9 : 0000000000000000 x8 : ffff000012604a40
x7 : 0000000000000000 x6 : 000000000000003f
x5 : 0000000000000040 x4 : ffffffffffffffe0
x3 : 0000000000000358 x2 : 0000000000000318
x1 : 0000000000000000 x0 : ffff000012604a20
Call trace:
__memset+0x16c/0x188
rproc_boot+0x404/0x668 [remoteproc]
rproc_auto_boot_callback+0x18/0x30 [remoteproc]
request_firmware_work_func+0x48/0x88
process_one_work+0x1e0/0x318
worker_thread+0x40/0x428
kthread+0x124/0x128
ret_from_fork+0x10/0x18
Code: 91010108 54ffff4a 8b040108 cb050042 (d50b7428)
---[ end trace eafd1b2b63d14eb0 ]---
Fixes: af9493dd36d4 ("remoteproc/k3-dsp: add a remoteproc driver of K3 C66x DSPs")
Signed-off-by: Suman Anna <s-anna@ti.com>
Merged TI feature rpmsg into ti-linux-4.19.y
TI-Feature: rpmsg
TI-Branch: rpmsg-ti-linux-4.19.y-intg
* 'rpmsg-ti-linux-4.19.y-intg' of git://git.ti.com/rpmsg/rpmsg:
remoteproc/k3-r5: fix memzero issues on reserved SRAM regions
remoteproc/k3-r5: fix loading into BTCM when using R5 local addresses
remoteproc/k3-r5: fix unaligned data faults with TCMs during loading
TEMP: arm64: dts: ti: k3-am654-base-board: Increase reserve memory for RTOS IPC
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
TI-Feature: rpmsg
TI-Branch: rpmsg-ti-linux-4.19.y-intg
* 'rpmsg-ti-linux-4.19.y-intg' of git://git.ti.com/rpmsg/rpmsg:
remoteproc/k3-r5: fix memzero issues on reserved SRAM regions
remoteproc/k3-r5: fix loading into BTCM when using R5 local addresses
remoteproc/k3-r5: fix unaligned data faults with TCMs during loading
TEMP: arm64: dts: ti: k3-am654-base-board: Increase reserve memory for RTOS IPC
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 'topic/4.19/am65x' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-4.19.y
Pull in the dedicated AM65x remoteproc topic branch that includes various
fixes in the K3 R5F remoteproc driver for kernel crashes in memcpy() and
memset() caused during remoteproc loading into the R5F TCMs and on-chip
SRAMs due to the mapping of these regions as device-type memory.
* 'topic/4.19/am65x' of git://git.ti.com/rpmsg/remoteproc:
remoteproc/k3-r5: fix memzero issues on reserved SRAM regions
remoteproc/k3-r5: fix loading into BTCM when using R5 local addresses
remoteproc/k3-r5: fix unaligned data faults with TCMs during loading
Signed-off-by: Suman Anna <s-anna@ti.com>
Pull in the dedicated AM65x remoteproc topic branch that includes various
fixes in the K3 R5F remoteproc driver for kernel crashes in memcpy() and
memset() caused during remoteproc loading into the R5F TCMs and on-chip
SRAMs due to the mapping of these regions as device-type memory.
* 'topic/4.19/am65x' of git://git.ti.com/rpmsg/remoteproc:
remoteproc/k3-r5: fix memzero issues on reserved SRAM regions
remoteproc/k3-r5: fix loading into BTCM when using R5 local addresses
remoteproc/k3-r5: fix unaligned data faults with TCMs during loading
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc/k3-r5: fix memzero issues on reserved SRAM regions
The K3 R5 remoteproc driver can support loading into and executing
code from various on-chip SRAM regions like MCU SRAM or NavSS SRAM,
and these regions are mapped as device type memory because of the
usage of ioremap().
The remoteproc core ELF loader function zeroes out any remaining
portions of a program segment if the actual memory size (p_memsz)
is more than the loadable content (p_filesz), and this memset is
throwing a kernel crash on these reserved SRAM regions at present.
This is because of the usage of the "DC ZVA" instruction within the
Arm64 memset library function when zeroing out memory, which throws
an alignment fault on device type memory.
Fix this by switching to ioremap_wc() function instead of ioremap()
function for mapping the SRAM regions. The ioremap_wc() maps the
SRAM regions as normal non-cacheable memory instead. The solution
follows the similar logic used in the core SRAM driver in
commit 0ab163ad1ea0 ("misc: sram: switch to ioremap_wc from ioremap").
Fixes: 7091176e2f99 ("remoteproc/k3-r5: add loading support for on-chip SRAM regions")
Signed-off-by: Suman Anna <s-anna@ti.com>
The K3 R5 remoteproc driver can support loading into and executing
code from various on-chip SRAM regions like MCU SRAM or NavSS SRAM,
and these regions are mapped as device type memory because of the
usage of ioremap().
The remoteproc core ELF loader function zeroes out any remaining
portions of a program segment if the actual memory size (p_memsz)
is more than the loadable content (p_filesz), and this memset is
throwing a kernel crash on these reserved SRAM regions at present.
This is because of the usage of the "DC ZVA" instruction within the
Arm64 memset library function when zeroing out memory, which throws
an alignment fault on device type memory.
Fix this by switching to ioremap_wc() function instead of ioremap()
function for mapping the SRAM regions. The ioremap_wc() maps the
SRAM regions as normal non-cacheable memory instead. The solution
follows the similar logic used in the core SRAM driver in
commit 0ab163ad1ea0 ("misc: sram: switch to ioremap_wc from ioremap").
Fixes: 7091176e2f99 ("remoteproc/k3-r5: add loading support for on-chip SRAM regions")
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc/k3-r5: fix loading into BTCM when using R5 local addresses
A R5F remote processor can access its TCMs either using its local address
views at address 0x0 and/or 0x41010000 depending on the LOCZRAMA setting,
or using the corresponding SoC-bus address views (one-to-one views since
there are no MMUs).
The K3 R5F remoteproc driver provides the translations for the TCMs
through the k3_r5_rproc_da_to_va() function to allow loading into TCMs.
This function is translating the SoC-view addresses just fine, but is
only translating ATCMs at address 0x0 at present. This results in a
failure to load any segments into BTCMs when using the R5 local address
range at 0x41010000. Update the logic in this function to fix these
BTCM load issues.
Fixes: 80d807f572e9 ("remoteproc/k3-r5: add a remoteproc driver for R5F subsystem")
Signed-off-by: Suman Anna <s-anna@ti.com>
A R5F remote processor can access its TCMs either using its local address
views at address 0x0 and/or 0x41010000 depending on the LOCZRAMA setting,
or using the corresponding SoC-bus address views (one-to-one views since
there are no MMUs).
The K3 R5F remoteproc driver provides the translations for the TCMs
through the k3_r5_rproc_da_to_va() function to allow loading into TCMs.
This function is translating the SoC-view addresses just fine, but is
only translating ATCMs at address 0x0 at present. This results in a
failure to load any segments into BTCMs when using the R5 local address
range at 0x41010000. Update the logic in this function to fix these
BTCM load issues.
Fixes: 80d807f572e9 ("remoteproc/k3-r5: add a remoteproc driver for R5F subsystem")
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc/k3-r5: fix unaligned data faults with TCMs during loading
The R5F processors on TI K3 SoCs all have Tightly Coupled Memory (TCM)
and has both the ATCM and two banks of BTCM. The K3 R5F remoteproc driver
leverages the TCMs to perform boot-strapping and support further execution
of code from DDR. These TCMs are currently mapped into the kernel as device
type memory due to the usage of devm_ioremap_resource(). The remoteproc
core ELF loader uses the regular memcpy function for loading program
segments.
The Arm64 architecture causes an alignment fault on any unaligned access
to any type of device memory. The R5F firmwares can have a TCM program
segment unaligned (due to the presence of the unaligned Elf32 header)
and cause issues with the Arm64 memcpy() function. The TCMs are furthermore
designed in general to support RAM-like backing memories.
So, update the TCM mapping logic to instead use the devm_ioremap_wc()
function to map these memory regions as Normal Non-Cached memories, and
thereby fix any potential unaligned data accesses during remoteproc
loading. This also helps with zeroing out the TCMs using memset().
An example crash log looks like below:
Unable to handle kernel paging request at virtual address ffff0000128c0004
Mem abort info:
ESR = 0x96000061
Exception class = DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
Data abort info:
ISV = 0, ISS = 0x00000061
CM = 0, WnR = 1
swapper pgtable: 64k pages, 48-bit VAs, pgdp = 000000002c996fc5
[ffff0000128c0004] pgd=00000008fffe0003, pud=00000008fffe0003, pmd=00000008fffd0003, pte=00e8000005c00707
Internal error: Oops: 96000061 [#1] PREEMPT SMP
Modules linked in: ti_k3_r5_remoteproc virtio_rpmsg_bus remoteproc
Process kworker/1:2 (pid: 129, stack limit = 0x00000000d72d3758)
CPU: 1 PID: 129 Comm: kworker/1:2 Not tainted 4.19.73-00042-g9c815c9f00bd #347
Hardware name: Texas Instruments K3 J721E SoC (DT)
Workqueue: events request_firmware_work_func
pstate: 00000005 (nzcv daif -PAN -UAO)
pc : __memcpy+0x48/0x180
lr : rproc_elf_load_segments+0x174/0x1c8 [remoteproc]
sp : ffff00000bbcfc80
x29: ffff00000bbcfc80 x28: ffff800843a23838
x27: 0000000000000034 x26: 0000000000000040
x25: ffff800843a23800 x24: ffff80084a8d2c00
x23: ffff000012b10000 x22: 0000000000000000
x21: 0000000000000040 x20: 0000000000000000
x19: ffff000012ca50c0 x18: 0000000000000000
x17: 0000000000000000 x16: 0000000000000000
x15: 0000000000000400 x14: 0000000000000400
x13: 0000000000000044 x12: 0000000000000000
x11: 0000000000000001 x10: 0000000000000980
x9 : ffff00000bbcf860 x8 : ffff8008435609e0
x7 : ffff800843560240 x6 : ffff0000128c0004
x5 : ffff80087fae17e8 x4 : 000000000000000c
x3 : e59ff018e59ff018 x2 : 0000000000000034
x1 : ffff000012b10040 x0 : ffff0000128c0000
Call trace:
__memcpy+0x48/0x180
rproc_boot+0x404/0x668 [remoteproc]
rproc_auto_boot_callback+0x18/0x30 [remoteproc]
request_firmware_work_func+0x48/0x88
process_one_work+0x1e0/0x318
worker_thread+0x40/0x428
kthread+0x124/0x128
ret_from_fork+0x10/0x18
Code: b8404423 b80044c3 36180064 f8408423 (f80084c3)
---[ end trace cbd6238f81b6eda1 ]---
Fixes: 80d807f572e9 ("remoteproc/k3-r5: add a remoteproc driver for R5F subsystem")
Signed-off-by: Suman Anna <s-anna@ti.com>
The R5F processors on TI K3 SoCs all have Tightly Coupled Memory (TCM)
and has both the ATCM and two banks of BTCM. The K3 R5F remoteproc driver
leverages the TCMs to perform boot-strapping and support further execution
of code from DDR. These TCMs are currently mapped into the kernel as device
type memory due to the usage of devm_ioremap_resource(). The remoteproc
core ELF loader uses the regular memcpy function for loading program
segments.
The Arm64 architecture causes an alignment fault on any unaligned access
to any type of device memory. The R5F firmwares can have a TCM program
segment unaligned (due to the presence of the unaligned Elf32 header)
and cause issues with the Arm64 memcpy() function. The TCMs are furthermore
designed in general to support RAM-like backing memories.
So, update the TCM mapping logic to instead use the devm_ioremap_wc()
function to map these memory regions as Normal Non-Cached memories, and
thereby fix any potential unaligned data accesses during remoteproc
loading. This also helps with zeroing out the TCMs using memset().
An example crash log looks like below:
Unable to handle kernel paging request at virtual address ffff0000128c0004
Mem abort info:
ESR = 0x96000061
Exception class = DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
Data abort info:
ISV = 0, ISS = 0x00000061
CM = 0, WnR = 1
swapper pgtable: 64k pages, 48-bit VAs, pgdp = 000000002c996fc5
[ffff0000128c0004] pgd=00000008fffe0003, pud=00000008fffe0003, pmd=00000008fffd0003, pte=00e8000005c00707
Internal error: Oops: 96000061 [#1] PREEMPT SMP
Modules linked in: ti_k3_r5_remoteproc virtio_rpmsg_bus remoteproc
Process kworker/1:2 (pid: 129, stack limit = 0x00000000d72d3758)
CPU: 1 PID: 129 Comm: kworker/1:2 Not tainted 4.19.73-00042-g9c815c9f00bd #347
Hardware name: Texas Instruments K3 J721E SoC (DT)
Workqueue: events request_firmware_work_func
pstate: 00000005 (nzcv daif -PAN -UAO)
pc : __memcpy+0x48/0x180
lr : rproc_elf_load_segments+0x174/0x1c8 [remoteproc]
sp : ffff00000bbcfc80
x29: ffff00000bbcfc80 x28: ffff800843a23838
x27: 0000000000000034 x26: 0000000000000040
x25: ffff800843a23800 x24: ffff80084a8d2c00
x23: ffff000012b10000 x22: 0000000000000000
x21: 0000000000000040 x20: 0000000000000000
x19: ffff000012ca50c0 x18: 0000000000000000
x17: 0000000000000000 x16: 0000000000000000
x15: 0000000000000400 x14: 0000000000000400
x13: 0000000000000044 x12: 0000000000000000
x11: 0000000000000001 x10: 0000000000000980
x9 : ffff00000bbcf860 x8 : ffff8008435609e0
x7 : ffff800843560240 x6 : ffff0000128c0004
x5 : ffff80087fae17e8 x4 : 000000000000000c
x3 : e59ff018e59ff018 x2 : 0000000000000034
x1 : ffff000012b10040 x0 : ffff0000128c0000
Call trace:
__memcpy+0x48/0x180
rproc_boot+0x404/0x668 [remoteproc]
rproc_auto_boot_callback+0x18/0x30 [remoteproc]
request_firmware_work_func+0x48/0x88
process_one_work+0x1e0/0x318
worker_thread+0x40/0x428
kthread+0x124/0x128
ret_from_fork+0x10/0x18
Code: b8404423 b80044c3 36180064 f8408423 (f80084c3)
---[ end trace cbd6238f81b6eda1 ]---
Fixes: 80d807f572e9 ("remoteproc/k3-r5: add a remoteproc driver for R5F subsystem")
Signed-off-by: Suman Anna <s-anna@ti.com>
Merged TI feature platform_base into ti-linux-4.19.y
TI-Feature: platform_base
TI-Branch: platform-ti-linux-4.19.y
* 'platform-ti-linux-4.19.y' of ssh://bitbucket.itg.ti.com/lcpdpublicdom/platform:
crypto: Kconfig: sa2ul: select SHA512/SHA256 explicitly
clk: ti: dra7-atl-clock: Remove ti_clk_add_alias call
dmaengine: ti: k3-navss-udma: Reset flowid range when no extra flows needed
dmaengine: ti: k3-udma: Make sure that extra flows are disabled for rchan
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
TI-Feature: platform_base
TI-Branch: platform-ti-linux-4.19.y
* 'platform-ti-linux-4.19.y' of ssh://bitbucket.itg.ti.com/lcpdpublicdom/platform:
crypto: Kconfig: sa2ul: select SHA512/SHA256 explicitly
clk: ti: dra7-atl-clock: Remove ti_clk_add_alias call
dmaengine: ti: k3-navss-udma: Reset flowid range when no extra flows needed
dmaengine: ti: k3-udma: Make sure that extra flows are disabled for rchan
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
Merge branch 'topic/4.19/am65x' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-4.19.y
Pull in the dedicated AM65x remoteproc topic branch that increases the
IPC DDR carveout region used by the MCU domain R5F cores on AM65x platforms
to match the current usage on the PDK IPC LLD firmwares.
* 'topic/4.19/am65x' of git://git.ti.com/rpmsg/remoteproc:
TEMP: arm64: dts: ti: k3-am654-base-board: Increase reserve memory for RTOS IPC
Signed-off-by: Suman Anna <s-anna@ti.com>
Pull in the dedicated AM65x remoteproc topic branch that increases the
IPC DDR carveout region used by the MCU domain R5F cores on AM65x platforms
to match the current usage on the PDK IPC LLD firmwares.
* 'topic/4.19/am65x' of git://git.ti.com/rpmsg/remoteproc:
TEMP: arm64: dts: ti: k3-am654-base-board: Increase reserve memory for RTOS IPC
Signed-off-by: Suman Anna <s-anna@ti.com>
crypto: Kconfig: sa2ul: select SHA512/SHA256 explicitly
select SHA512/SHA256 & HMAC configs explicitly to avoid any rand config
build issues.
Reported-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
Tested-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
select SHA512/SHA256 & HMAC configs explicitly to avoid any rand config
build issues.
Reported-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
Tested-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
clk: ti: dra7-atl-clock: Remove ti_clk_add_alias call
ti_clk_register() calls it already so the driver should not create
duplicated alias.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
ti_clk_register() calls it already so the driver should not create
duplicated alias.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
dmaengine: ti: k3-navss-udma: Reset flowid range when no extra flows needed
The reset value of FLOWID_CNT in RCHAN_RFLOW_RNG register is 0x4000. If
no extra flows are desired for the rchan this has to be reset to 0.
Make the fliwid_cnt/_start as valid which will reset the flowid_cnt in case
extra flows are not needed for the channel.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
The reset value of FLOWID_CNT in RCHAN_RFLOW_RNG register is 0x4000. If
no extra flows are desired for the rchan this has to be reset to 0.
Make the fliwid_cnt/_start as valid which will reset the flowid_cnt in case
extra flows are not needed for the channel.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
dmaengine: ti: k3-udma: Make sure that extra flows are disabled for rchan
The reset value of FLOWID_CNT in RCHAN_RFLOW_RNG register is 0x4000. If
no extra flows are desired for the rchan this has to be reset to 0.
With DMAengine we do not use rflow at the moment so make sure that both
flowid_cnt and flowid_start is reset to 0.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
The reset value of FLOWID_CNT in RCHAN_RFLOW_RNG register is 0x4000. If
no extra flows are desired for the rchan this has to be reset to 0.
With DMAengine we do not use rflow at the moment so make sure that both
flowid_cnt and flowid_start is reset to 0.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
TEMP: arm64: dts: ti: k3-am654-base-board: Increase reserve memory for RTOS IPC
A 1 MB of carveout memory at 0xa2000000 is reserved currently for achieving
IPC between the two MCU R5F cores when running in split-mode. The PDK IPC
RTOS code though is currently accessing some memory beyond this 1 MB, used
to also achieve IPC with the A53 cores running RTOS (Linux uses a separate
1 MB region per core as part of the overall 16 MB region). Reserve an
additional 1 MB of memory temporarily until the RTOS code logic is fixed
up to avoid memory corruptions with the linux kernel.
Signed-off-by: Suman Anna <s-anna@ti.com>
A 1 MB of carveout memory at 0xa2000000 is reserved currently for achieving
IPC between the two MCU R5F cores when running in split-mode. The PDK IPC
RTOS code though is currently accessing some memory beyond this 1 MB, used
to also achieve IPC with the A53 cores running RTOS (Linux uses a separate
1 MB region per core as part of the overall 16 MB region). Reserve an
additional 1 MB of memory temporarily until the RTOS code logic is fixed
up to avoid memory corruptions with the linux kernel.
Signed-off-by: Suman Anna <s-anna@ti.com>
Merged TI feature audio-display into ti-linux-4.19.y
TI-Feature: audio-display
TI-Branch: audio_display-ti-linux-4.19.y
* 'audio_display-ti-linux-4.19.y' of ssh://bitbucket.itg.ti.com/lcpdpublicdom/audio-display:
ASoC: soc-pcm: Use different sequence for start/stop trigger
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
TI-Feature: audio-display
TI-Branch: audio_display-ti-linux-4.19.y
* 'audio_display-ti-linux-4.19.y' of ssh://bitbucket.itg.ti.com/lcpdpublicdom/audio-display:
ASoC: soc-pcm: Use different sequence for start/stop trigger
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
Merge branch 'peter/ti-linux-4.19.y/topic/audio' of https://github.com/omap-audio/linux-audio into audio_display-ti-linux-4.19.y
2019.04 - ASoC: pcm trigger ordering to fix errors on stream stop/pause
* 'peter/ti-linux-4.19.y/topic/audio' of https://github.com/omap-audio/linux-audio:
ASoC: soc-pcm: Use different sequence for start/stop trigger
2019.04 - ASoC: pcm trigger ordering to fix errors on stream stop/pause
* 'peter/ti-linux-4.19.y/topic/audio' of https://github.com/omap-audio/linux-audio:
ASoC: soc-pcm: Use different sequence for start/stop trigger
ASoC: soc-pcm: Use different sequence for start/stop trigger
On stream stop currently we stop the DMA first followed by the CPU DAI.
This can cause underflow (playback) or overflow (capture) on the DAI side
as the DMA is no longer feeding data while the DAI is still active.
It can be observed easily if the DAI side does not have FIFO (or it is
disabled) to survive the time while the DMA is stopped, but still can
happen on relatively slow CPUs when relatively high sampling rate is used:
the FIFO is drained between the time the DMA is stopped and the DAI is
stopped.
It can only fixed by using different sequence within trigger for 'stop' and
'start':
case SNDRV_PCM_TRIGGER_START:
case SNDRV_PCM_TRIGGER_RESUME:
case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
Trigger order: dai_link, DMA, CPU DAI then the codec
case SNDRV_PCM_TRIGGER_STOP:
case SNDRV_PCM_TRIGGER_SUSPEND:
case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
Trigger order: codec, CPU DAI, DMA then dai_link
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
On stream stop currently we stop the DMA first followed by the CPU DAI.
This can cause underflow (playback) or overflow (capture) on the DAI side
as the DMA is no longer feeding data while the DAI is still active.
It can be observed easily if the DAI side does not have FIFO (or it is
disabled) to survive the time while the DMA is stopped, but still can
happen on relatively slow CPUs when relatively high sampling rate is used:
the FIFO is drained between the time the DMA is stopped and the DAI is
stopped.
It can only fixed by using different sequence within trigger for 'stop' and
'start':
case SNDRV_PCM_TRIGGER_START:
case SNDRV_PCM_TRIGGER_RESUME:
case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
Trigger order: dai_link, DMA, CPU DAI then the codec
case SNDRV_PCM_TRIGGER_STOP:
case SNDRV_PCM_TRIGGER_SUSPEND:
case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
Trigger order: codec, CPU DAI, DMA then dai_link
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Merged TI feature audio-display into ti-linux-4.19.y
TI-Feature: audio-display
TI-Branch: audio_display-ti-linux-4.19.y
* 'audio_display-ti-linux-4.19.y' of ssh://bitbucket.itg.ti.com/lcpdpublicdom/audio-display:
drm/tidss: dispc7: Update scaling limitations for J7 DSS
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
TI-Feature: audio-display
TI-Branch: audio_display-ti-linux-4.19.y
* 'audio_display-ti-linux-4.19.y' of ssh://bitbucket.itg.ti.com/lcpdpublicdom/audio-display:
drm/tidss: dispc7: Update scaling limitations for J7 DSS
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
drm/tidss: dispc7: Update scaling limitations for J7 DSS
J721E DSS has larger linebuffers for scaling and different buffer
width limitations for scaling. The patch updates the values copied
from AM65x DSS support.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
J721E DSS has larger linebuffers for scaling and different buffer
width limitations for scaling. The patch updates the values copied
from AM65x DSS support.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Merged TI feature rpmsg into ti-linux-4.19.y
TI-Feature: rpmsg
TI-Branch: rpmsg-ti-linux-4.19.y-intg
* 'rpmsg-ti-linux-4.19.y-intg' of git://git.ti.com/rpmsg/rpmsg:
remoteproc/k3-dsp: Add support for L2RAM loading on C66x DSPs
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
TI-Feature: rpmsg
TI-Branch: rpmsg-ti-linux-4.19.y-intg
* 'rpmsg-ti-linux-4.19.y-intg' of git://git.ti.com/rpmsg/rpmsg:
remoteproc/k3-dsp: Add support for L2RAM loading on C66x DSPs
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
remoteproc/k3-dsp: Add support for L2RAM loading on C66x DSPs
The resets for the DSP processors on K3 SoCs are managed through the
Power and Sleep Controller (PSC) module. Each DSP typically has two
resets - a global module reset for powering on the device, and a local
reset that affects only the CPU while allowing access to the other
sub-modules within the DSP processor sub-systems.
The C66x DSPs have two levels of internal RAMs that can be used to
boot from, and the firmware loading into these RAMs require the
local reset to be asserted with the device powered on/enabled using
the module reset. Enhance the K3 DSP remoteproc driver to add support
for loading into the internal RAMs. The local reset is deasserted on
SoC power-on-reset, so logic has to be added in probe in remoteproc
mode to balance the remoteproc state-machine.
Note that the local resets are a no-op on C71x cores, and the hardware
does not supporting loading into its internal RAMs.
Signed-off-by: Suman Anna <s-anna@ti.com>
The resets for the DSP processors on K3 SoCs are managed through the
Power and Sleep Controller (PSC) module. Each DSP typically has two
resets - a global module reset for powering on the device, and a local
reset that affects only the CPU while allowing access to the other
sub-modules within the DSP processor sub-systems.
The C66x DSPs have two levels of internal RAMs that can be used to
boot from, and the firmware loading into these RAMs require the
local reset to be asserted with the device powered on/enabled using
the module reset. Enhance the K3 DSP remoteproc driver to add support
for loading into the internal RAMs. The local reset is deasserted on
SoC power-on-reset, so logic has to be added in probe in remoteproc
mode to balance the remoteproc state-machine.
Note that the local resets are a no-op on C71x cores, and the hardware
does not supporting loading into its internal RAMs.
Signed-off-by: Suman Anna <s-anna@ti.com>
Merged TI feature connectivity into ti-linux-4.19.y
TI-Feature: connectivity
TI-Branch: connectivity-ti-linux-4.19.y
* 'connectivity-ti-linux-4.19.y' of ssh://bitbucket.itg.ti.com/lcpdpublicdom/connectivity:
arm64: dts: ti: k3-j721e-proc-board-tps65917: Fix USB0 in super-speed
usb: cdns3: gadget: Fix broken gadget after role switch from host to device
arm64: dts: k3-j721e-proc-board: Add wait time for sampling Type-C DIR line
phy: ti: j721e-wiz: Add support Type-C DIR GPIO delay
dt-bindings: phy: ti,phy-j721e-wiz: Add Type-C dir GPIO debounce
phy: ti: j721e-wiz: Fix error path if Type-C GPIO is not available
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
TI-Feature: connectivity
TI-Branch: connectivity-ti-linux-4.19.y
* 'connectivity-ti-linux-4.19.y' of ssh://bitbucket.itg.ti.com/lcpdpublicdom/connectivity:
arm64: dts: ti: k3-j721e-proc-board-tps65917: Fix USB0 in super-speed
usb: cdns3: gadget: Fix broken gadget after role switch from host to device
arm64: dts: k3-j721e-proc-board: Add wait time for sampling Type-C DIR line
phy: ti: j721e-wiz: Add support Type-C DIR GPIO delay
dt-bindings: phy: ti,phy-j721e-wiz: Add Type-C dir GPIO debounce
phy: ti: j721e-wiz: Fix error path if Type-C GPIO is not available
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
arm64: dts: ti: k3-j721e-proc-board-tps65917: Fix USB0 in super-speed
The controller bindings changed at some point but got missed
when this alpha board DTS was split.
Fixes: ff854b45b49f ("arm64: dts: ti: k3-j721e: Add support for pm2 som")
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
The controller bindings changed at some point but got missed
when this alpha board DTS was split.
Fixes: ff854b45b49f ("arm64: dts: ti: k3-j721e: Add support for pm2 som")
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
usb: cdns3: gadget: Fix broken gadget after role switch from host to device
On switching to host mode, xhci-plat.c sets controller device's
DMA mask to 64-bit. On switching back to gadget mode we need
to reset the DMA mask to 32-bit else gadget controller malfunctions.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
On switching to host mode, xhci-plat.c sets controller device's
DMA mask to 64-bit. On switching back to gadget mode we need
to reset the DMA mask to 32-bit else gadget controller malfunctions.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
arm64: dts: k3-j721e-proc-board: Add wait time for sampling Type-C DIR line
The Type-C compainon chip on the board needs ~133ms (tCCB_DEFAULT)
to debounce the CC lines in order to detect attach and plug orientation
and reflect the correct DIR status. [1]
Let's wait for 300ms before sampling the Type-C DIR line.
[1] http://www.ti.com/lit/ds/symlink/tusb321.pdf
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
The Type-C compainon chip on the board needs ~133ms (tCCB_DEFAULT)
to debounce the CC lines in order to detect attach and plug orientation
and reflect the correct DIR status. [1]
Let's wait for 300ms before sampling the Type-C DIR line.
[1] http://www.ti.com/lit/ds/symlink/tusb321.pdf
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
phy: ti: j721e-wiz: Add support Type-C DIR GPIO delay
Type-C companions typically need some time after the cable is
plugged before and before they reflect the correct status of
Type-C plug orientation on the DIR line.
Type-C Spec specifies CC attachment debounce time (tCCDebounce)
of 100 ms (min) to 200 ms (max).
Use the DT property to figure out if we need to add delay
or not before sampling the Type-C DIR line.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Type-C companions typically need some time after the cable is
plugged before and before they reflect the correct status of
Type-C plug orientation on the DIR line.
Type-C Spec specifies CC attachment debounce time (tCCDebounce)
of 100 ms (min) to 200 ms (max).
Use the DT property to figure out if we need to add delay
or not before sampling the Type-C DIR line.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
dt-bindings: phy: ti,phy-j721e-wiz: Add Type-C dir GPIO debounce
Type-C companions typically need some time after the cable is
plugged before and before they reflect the correct status of
Type-C plug orientation on the DIR line.
Type-C Spec specifies CC attachment debounce time (tCCDebounce)
of 100 ms (min) to 200 ms (max).
Allow the DT node to specify the time (in ms) that we need
to wait before sampling the DIR line.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Type-C companions typically need some time after the cable is
plugged before and before they reflect the correct status of
Type-C plug orientation on the DIR line.
Type-C Spec specifies CC attachment debounce time (tCCDebounce)
of 100 ms (min) to 200 ms (max).
Allow the DT node to specify the time (in ms) that we need
to wait before sampling the DIR line.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
phy: ti: j721e-wiz: Fix error path if Type-C GPIO is not available
We should not be complaining on console if we got -EPROBE_DEFER.
Also, fixup the error path.
Fixes: fa06d29814d0 ("phy: ti: j721e-wiz: Manage typec-gpio-dir")
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
We should not be complaining on console if we got -EPROBE_DEFER.
Also, fixup the error path.
Fixes: fa06d29814d0 ("phy: ti: j721e-wiz: Manage typec-gpio-dir")
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Merged TI feature audio-display into ti-linux-4.19.y
TI-Feature: audio-display
TI-Branch: audio_display-ti-linux-4.19.y
* 'audio_display-ti-linux-4.19.y' of ssh://bitbucket.itg.ti.com/lcpdpublicdom/audio-display:
ASoC: ti: j721e-evm: Add rule to limit the available sampling rates
drm/omap: fix scaling limits
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
TI-Feature: audio-display
TI-Branch: audio_display-ti-linux-4.19.y
* 'audio_display-ti-linux-4.19.y' of ssh://bitbucket.itg.ti.com/lcpdpublicdom/audio-display:
ASoC: ti: j721e-evm: Add rule to limit the available sampling rates
drm/omap: fix scaling limits
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
Merge branch 'peter/ti-linux-4.19.y/topic/audio' of https://github.com/omap-audio/linux-audio into audio_display-ti-linux-4.19.y
2019.04 - j7: do not allow unsupported rates
* 'peter/ti-linux-4.19.y/topic/audio' of https://github.com/omap-audio/linux-audio:
ASoC: ti: j721e-evm: Add rule to limit the available sampling rates
2019.04 - j7: do not allow unsupported rates
* 'peter/ti-linux-4.19.y/topic/audio' of https://github.com/omap-audio/linux-audio:
ASoC: ti: j721e-evm: Add rule to limit the available sampling rates
ASoC: ti: j721e-evm: Add rule to limit the available sampling rates
With the PLLs and the HSDIV we can only support a range of sampling rates.
Make sure that the unsupported rates are not available.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
With the PLLs and the HSDIV we can only support a range of sampling rates.
Make sure that the unsupported rates are not available.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Merge branch 'ti/4.19-pull' of https://bitbucket.itg.ti.com/scm/~a0400822/linux into audio_display-ti-linux-4.19.y
2019.04 DSS scaling fix
* 'ti/4.19-pull' of https://bitbucket.itg.ti.com/scm/~a0400822/linux:
drm/omap: fix scaling limits
2019.04 DSS scaling fix
* 'ti/4.19-pull' of https://bitbucket.itg.ti.com/scm/~a0400822/linux:
drm/omap: fix scaling limits
drm/omap: fix scaling limits
"drm/omap: dynamically assign hw overlays to planes" added a call to
drm_atomic_helper_check_plane_state() in omap_plane_atomic_check(), with
scaling limits that were supposed to allow all the valid setups.
However, the limits were backwards, and the limit meant for upscaling
limited downscaling, and vice versa.
Also, the limit for downscaling is a bit too restrictive (1/4).
Fix the limits so that they allow down to 1/8 downscaling and up to x8
upscaling.
Note that the "real" scaling limits are more complex and calculated in
dispc. Unfortunately that happens only at commit phase, but that is
another topic.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reported-by: Ram Prasad <x0038811@ti.com>
Reviewed-by: Benoit Parrot <bparrot@ti.com>
"drm/omap: dynamically assign hw overlays to planes" added a call to
drm_atomic_helper_check_plane_state() in omap_plane_atomic_check(), with
scaling limits that were supposed to allow all the valid setups.
However, the limits were backwards, and the limit meant for upscaling
limited downscaling, and vice versa.
Also, the limit for downscaling is a bit too restrictive (1/4).
Fix the limits so that they allow down to 1/8 downscaling and up to x8
upscaling.
Note that the "real" scaling limits are more complex and calculated in
dispc. Unfortunately that happens only at commit phase, but that is
another topic.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reported-by: Ram Prasad <x0038811@ti.com>
Reviewed-by: Benoit Parrot <bparrot@ti.com>
Merged TI feature graphics into ti-linux-4.19.y
TI-Feature: graphics
TI-Branch: graphics-ti-linux-4.19.y
* 'graphics-ti-linux-4.19.y' of ssh://bitbucket.itg.ti.com/lcpdpublicdom/graphics:
ARM: dts: dra76-evm: Add CMA pool for GPU device
ARM: dts: dra7-evm: Add CMA pool for GPU
drm/bridge: cdns-mhdp: Probe and add the bridge even without firmware
drm/bridge: cdns-mhdp: Call phy_exit() in mhdp_remove()
drm/bridge: cdns-mhdp: Handle probe failures correctly
drm/bridge: cdns-mhdp: Drop useless container structs
drm/bridge: cdns-mhdp: Remove dependencies to cdns-mhdp-common
drm/rockchip: Restore everything to what is there in v4.19.73
drm/bridge: cdns-mhdp: Remove completely untested audio support
drm/tidss: constify rpmsg ops structs
drm/tidss: add missing static declarations in DSS sharing code
ASoC: pcm3168a: The codec does not support S32_LE
arm64: dts: ti: k3-j721e-proc-board-tps65917: Sync cpsw-virt-mac
serial: 8250: 8250_omap: Remove redundant call to omap_8250_rx_dma_flush
serial: 8250: 8250_omap: Fix DMA teardown sequence during RX timeout
crypto: sa2ul: Add sha512 HW crypto support
crypto: sa2ul: Do spin_lock_init on scid_lock
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
TI-Feature: graphics
TI-Branch: graphics-ti-linux-4.19.y
* 'graphics-ti-linux-4.19.y' of ssh://bitbucket.itg.ti.com/lcpdpublicdom/graphics:
ARM: dts: dra76-evm: Add CMA pool for GPU device
ARM: dts: dra7-evm: Add CMA pool for GPU
drm/bridge: cdns-mhdp: Probe and add the bridge even without firmware
drm/bridge: cdns-mhdp: Call phy_exit() in mhdp_remove()
drm/bridge: cdns-mhdp: Handle probe failures correctly
drm/bridge: cdns-mhdp: Drop useless container structs
drm/bridge: cdns-mhdp: Remove dependencies to cdns-mhdp-common
drm/rockchip: Restore everything to what is there in v4.19.73
drm/bridge: cdns-mhdp: Remove completely untested audio support
drm/tidss: constify rpmsg ops structs
drm/tidss: add missing static declarations in DSS sharing code
ASoC: pcm3168a: The codec does not support S32_LE
arm64: dts: ti: k3-j721e-proc-board-tps65917: Sync cpsw-virt-mac
serial: 8250: 8250_omap: Remove redundant call to omap_8250_rx_dma_flush
serial: 8250: 8250_omap: Fix DMA teardown sequence during RX timeout
crypto: sa2ul: Add sha512 HW crypto support
crypto: sa2ul: Do spin_lock_init on scid_lock
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
Merged TI feature connectivity into ti-linux-4.19.y
TI-Feature: connectivity
TI-Branch: connectivity-ti-linux-4.19.y
* 'connectivity-ti-linux-4.19.y' of ssh://bitbucket.itg.ti.com/lcpdpublicdom/connectivity: (25 commits)
ti_config_fragments/connectivity.cfg: Enable NTB configs
arm64: dts: ti: k3-j721e: Add DT overlay for PCIe Backplane
arm64: dts: ti: k3-j721e: Add reference to *phy* in PCIe EP DT node
NTB: tool: Enable the NTB/PCIe link on the local or remote side of bridge
NTB: Add support for EPF PCI-Express Non-Transparent Bridge
PCI: Add TI J721E device to pci ids
PCI: endpoint: Add EP function driver to provide NTB functionality
PCI: endpoint: *_free_bar() to return error codes on failure
PCI: endpoint: Fix missing mutex_unlock in error case
PCI: endpoint: Remove unused pci_epf_match_device()
PCI: cadence: Implement ->msi_map_irq() ops
PCI: endpoint: Add pci_epc_ops to map MSI irq
PCI: endpoint: Add support to associate secondary EPC with EPF
PCI: endpoint: Add helper API to populate header with values from DT
PCI: endpoint: Make pci_epf_driver ops optional
PCI: endpoint: Add helper API to get the 'next' unreserved BAR
PCI: endpoint: Make *_get_first_free_bar() take into account 64 bit BAR
PCI: endpoint: Add "pci-epf-bus" driver
PCI: endpoint: Add API to create EPF device from device tree
PCI: endpoint: Add API to get reference to EPC from device-tree
...
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
TI-Feature: connectivity
TI-Branch: connectivity-ti-linux-4.19.y
* 'connectivity-ti-linux-4.19.y' of ssh://bitbucket.itg.ti.com/lcpdpublicdom/connectivity: (25 commits)
ti_config_fragments/connectivity.cfg: Enable NTB configs
arm64: dts: ti: k3-j721e: Add DT overlay for PCIe Backplane
arm64: dts: ti: k3-j721e: Add reference to *phy* in PCIe EP DT node
NTB: tool: Enable the NTB/PCIe link on the local or remote side of bridge
NTB: Add support for EPF PCI-Express Non-Transparent Bridge
PCI: Add TI J721E device to pci ids
PCI: endpoint: Add EP function driver to provide NTB functionality
PCI: endpoint: *_free_bar() to return error codes on failure
PCI: endpoint: Fix missing mutex_unlock in error case
PCI: endpoint: Remove unused pci_epf_match_device()
PCI: cadence: Implement ->msi_map_irq() ops
PCI: endpoint: Add pci_epc_ops to map MSI irq
PCI: endpoint: Add support to associate secondary EPC with EPF
PCI: endpoint: Add helper API to populate header with values from DT
PCI: endpoint: Make pci_epf_driver ops optional
PCI: endpoint: Add helper API to get the 'next' unreserved BAR
PCI: endpoint: Make *_get_first_free_bar() take into account 64 bit BAR
PCI: endpoint: Add "pci-epf-bus" driver
PCI: endpoint: Add API to create EPF device from device tree
PCI: endpoint: Add API to get reference to EPC from device-tree
...
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
Merged TI feature audio-display into ti-linux-4.19.y
TI-Feature: audio-display
TI-Branch: audio_display-ti-linux-4.19.y
* 'audio_display-ti-linux-4.19.y' of ssh://bitbucket.itg.ti.com/lcpdpublicdom/audio-display:
drm/tidss: WB: fix nested redefinition of enum kbuild error
drm/tidss: WB: fix frame size kbuild warning
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
TI-Feature: audio-display
TI-Branch: audio_display-ti-linux-4.19.y
* 'audio_display-ti-linux-4.19.y' of ssh://bitbucket.itg.ti.com/lcpdpublicdom/audio-display:
drm/tidss: WB: fix nested redefinition of enum kbuild error
drm/tidss: WB: fix frame size kbuild warning
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
Merged TI feature rpmsg into ti-linux-4.19.y
TI-Feature: rpmsg
TI-Branch: rpmsg-ti-linux-4.19.y-intg
* 'rpmsg-ti-linux-4.19.y-intg' of git://git.ti.com/rpmsg/rpmsg:
HACK: ARM: dts: dra7-ipu-common: Revert to CMA pools for IPU early boots
TEMP: ARM: dts: dra7-ipu-common: Add a common file for IPU early boots
TEMP: remoteproc/omap: add "late attach" support
TEMP: iommu/omap: add support for performing a "late attach"
ARM: OMAP2+: pdata-quirks: Add device_is_enabled ops for IOMMUs and rprocs
clocksource: timer-ti-dm: Add support to handle late attach of rproc timers
TEMP: remoteproc: call the non-zeroing allocation function
TEMP: remoteproc: add "late attach" support
HACK: dma-mapping: add non-zeroing coherent alloc function
HACK: ARM: dma-mapping: create non-zeroing dma_map_ops
ARM: dts: dra76-evm: Fix rproc reserved-memory labels and node names
ARM: dts: dra72-evm-revc: Fix rproc reserved-memory labels and node names
Signed-off-by: Dan Murphy <dmurphy@ti.com>
TI-Feature: rpmsg
TI-Branch: rpmsg-ti-linux-4.19.y-intg
* 'rpmsg-ti-linux-4.19.y-intg' of git://git.ti.com/rpmsg/rpmsg:
HACK: ARM: dts: dra7-ipu-common: Revert to CMA pools for IPU early boots
TEMP: ARM: dts: dra7-ipu-common: Add a common file for IPU early boots
TEMP: remoteproc/omap: add "late attach" support
TEMP: iommu/omap: add support for performing a "late attach"
ARM: OMAP2+: pdata-quirks: Add device_is_enabled ops for IOMMUs and rprocs
clocksource: timer-ti-dm: Add support to handle late attach of rproc timers
TEMP: remoteproc: call the non-zeroing allocation function
TEMP: remoteproc: add "late attach" support
HACK: dma-mapping: add non-zeroing coherent alloc function
HACK: ARM: dma-mapping: create non-zeroing dma_map_ops
ARM: dts: dra76-evm: Fix rproc reserved-memory labels and node names
ARM: dts: dra72-evm-revc: Fix rproc reserved-memory labels and node names
Signed-off-by: Dan Murphy <dmurphy@ti.com>
ARM: dts: dra76-evm: Add CMA pool for GPU device
The CMA reserved memory node is added for the GPU device on the DRA76
EVM board, and assigned to respective node. The configuration in here
matches to that on the DRA7 EVM board. This enables the driver to
allocate from CMA region and there by not limiting all GPU allocations
to come only from normal zone.
Signed-off-by: Gowtham Tammana <g-tammana@ti.com>
The CMA reserved memory node is added for the GPU device on the DRA76
EVM board, and assigned to respective node. The configuration in here
matches to that on the DRA7 EVM board. This enables the driver to
allocate from CMA region and there by not limiting all GPU allocations
to come only from normal zone.
Signed-off-by: Gowtham Tammana <g-tammana@ti.com>
ARM: dts: dra7-evm: Add CMA pool for GPU
The CMA reserved node has been added for GPU core and enabled for the
DRA7 EVM board. The GPU device cannot access LPAE addresses, and as
such the CMA region is set in the *highmem32* region. This enables the
driver to allocate from the CMA region and there by not limiting all
GPU allocations to come only from normal zone.
Signed-off-by: Gowtham Tammana <g-tammana@ti.com>
The CMA reserved node has been added for GPU core and enabled for the
DRA7 EVM board. The GPU device cannot access LPAE addresses, and as
such the CMA region is set in the *highmem32* region. This enables the
driver to allocate from the CMA region and there by not limiting all
GPU allocations to come only from normal zone.
Signed-off-by: Gowtham Tammana <g-tammana@ti.com>
drm/bridge: cdns-mhdp: Probe and add the bridge even without firmware
Load the firmware asynchronously and probe and add the bridge even we
do not yet have it. This makes it possible to pull up the DRM device
and get the other displays working even if we still have to wait for
display port firmware. The display port is locked in disconnected
state until the firmware is loaded and the DP IP is properly enabled.
The patch adds one lock to protect hw_state and bridge_attached in
the driver data struct from from a race between the DRM operations and
the asynchronous FW loading.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Load the firmware asynchronously and probe and add the bridge even we
do not yet have it. This makes it possible to pull up the DRM device
and get the other displays working even if we still have to wait for
display port firmware. The display port is locked in disconnected
state until the firmware is loaded and the DP IP is properly enabled.
The patch adds one lock to protect hw_state and bridge_attached in
the driver data struct from from a race between the DRM operations and
the asynchronous FW loading.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
drm/bridge: cdns-mhdp: Call phy_exit() in mhdp_remove()
We should call phy_exit() when we stop using phy, so call it in
mhdp_remove().
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
We should call phy_exit() when we stop using phy, so call it in
mhdp_remove().
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
drm/bridge: cdns-mhdp: Handle probe failures correctly
If the probe fails after we have enabled and turned the power
management, we should also turn off and disable it.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
If the probe fails after we have enabled and turned the power
management, we should also turn off and disable it.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
drm/bridge: cdns-mhdp: Drop useless container structs
There really is no need for cdns_mhdp_connector or cdns_mhdp_bridge
structs, so remove them. Reorder the struct cdns_mhdp_device members a
bit while at it.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
There really is no need for cdns_mhdp_connector or cdns_mhdp_bridge
structs, so remove them. Reorder the struct cdns_mhdp_device members a
bit while at it.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
drm/bridge: cdns-mhdp: Remove dependencies to cdns-mhdp-common
Copy all necessary parts from cdns-mhdp-common and do not include
cdns-mhdp-common.h and link cdns-mhdp-common.c to cdns-mhdp any
more.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Copy all necessary parts from cdns-mhdp-common and do not include
cdns-mhdp-common.h and link cdns-mhdp-common.c to cdns-mhdp any
more.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
drm/rockchip: Restore everything to what is there in v4.19.73
This patch restores Rockchip driver to a state that matches v4.19.73
tag. This cover the mess left by "drm: bridge: add support for Cadence
MHDP DPI/DP bridge"-patch.
Fixes: 5d9ccc098dff ("drm: bridge: add support for Cadence MHDP DPI/DP bridge")
Signed-off-by: Jyri Sarha <jsarha@ti.com>
This patch restores Rockchip driver to a state that matches v4.19.73
tag. This cover the mess left by "drm: bridge: add support for Cadence
MHDP DPI/DP bridge"-patch.
Fixes: 5d9ccc098dff ("drm: bridge: add support for Cadence MHDP DPI/DP bridge")
Signed-off-by: Jyri Sarha <jsarha@ti.com>
drm/bridge: cdns-mhdp: Remove completely untested audio support
The current cdns-mhdp audio support is completely untested. Remove it
until we have some confidence that it actually works.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The current cdns-mhdp audio support is completely untested. Remove it
until we have some confidence that it actually works.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
drm/tidss: constify rpmsg ops structs
The ops in struct rpmsg_remotedev can be const, so constify them.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The ops in struct rpmsg_remotedev can be const, so constify them.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
drm/tidss: add missing static declarations in DSS sharing code
Make functions static to fix sparse warnings.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Make functions static to fix sparse warnings.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
ASoC: pcm3168a: The codec does not support S32_LE
24 bits is supported in all modes and 16 bit only when the codec is slave
and the DAI is set to RIGHT_J.
Remove the unsupported sample format.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
24 bits is supported in all modes and 16 bit only when the codec is slave
and the DAI is set to RIGHT_J.
Remove the unsupported sample format.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
arm64: dts: ti: k3-j721e-proc-board-tps65917: Sync cpsw-virt-mac
Sync cpsw-virt-mac node with k3-j721e-common-proc-board.dts
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Sync cpsw-virt-mac node with k3-j721e-common-proc-board.dts
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
serial: 8250: 8250_omap: Remove redundant call to omap_8250_rx_dma_flush
omap_8250_rx_dma_flush() is called twice in am654_8250_handle_rx_dma()
and first call quite redundant in case of second one. Drop the redundant
call.
Tested-by: Bin Liu <b-liu@ti.com>
Reported-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
omap_8250_rx_dma_flush() is called twice in am654_8250_handle_rx_dma()
and first call quite redundant in case of second one. Drop the redundant
call.
Tested-by: Bin Liu <b-liu@ti.com>
Reported-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
serial: 8250: 8250_omap: Fix DMA teardown sequence during RX timeout
Calling dmaengine_terminate_async() does not guarantee all the data that
is picked up DMA and is in flight to memory is flushed immediately,
therefore poll for the in flight data to be flushed before pushing
buffer to tty ldisc.
Ideal way to solve this without polling is to call
dmaengine_synchronize() before pushing data to tty layer, but that
cannot be done in interrupt context and code cannot be moved to bottom
half as we need to hold rx_dma_lock spinlock.
Therefore introduce a bounded polling mechanism to know data has been
flushed. Since this is a flush at DMA hardware level, sequence should be
quite deterministic and loop upper bound is set to 5 times the observed
value.
Tested-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Calling dmaengine_terminate_async() does not guarantee all the data that
is picked up DMA and is in flight to memory is flushed immediately,
therefore poll for the in flight data to be flushed before pushing
buffer to tty ldisc.
Ideal way to solve this without polling is to call
dmaengine_synchronize() before pushing data to tty layer, but that
cannot be done in interrupt context and code cannot be moved to bottom
half as we need to hold rx_dma_lock spinlock.
Therefore introduce a bounded polling mechanism to know data has been
flushed. Since this is a flush at DMA hardware level, sequence should be
quite deterministic and loop upper bound is set to 5 times the observed
value.
Tested-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
crypto: sa2ul: Add sha512 HW crypto support
Add sha512 HW crypto support.
Signed-off-by: Keerthy <j-keerthy@ti.com>
Add sha512 HW crypto support.
Signed-off-by: Keerthy <j-keerthy@ti.com>
crypto: sa2ul: Do spin_lock_init on scid_lock
It might work w/o spin_lock_init, but it is not a good practice for sure.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
It might work w/o spin_lock_init, but it is not a good practice for sure.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@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 'topic/4.19/dra7-late-attach' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-4.19.y
Pull in a dedicated remoteproc topic branch that adds the infrastructure
support to allow "late-attach" of the IPU1 and IPU2 remote processors on
DRA7xx/AM57xx SoCs. The late-attach feature is the kernel counterpart to
the early-boot of these processors from U-Boot/SPL to achieve key system
response time goals.
The support is provided through temporary HACKs or workarounds to various
subsystems that includes the DMA API layers, remoteproc core, OMAP IOMMU,
OMAP DMTimer and OMAP remoteproc drivers. The early-booted remoteproc
devices need couple of DT modifications, and these are provided through
a common dtsi file. This common dtsi file needs to be included in the
desired target DRA7/AM57xx board dts files (not merged but available on
the above topic branch).
The following are the main HACKs and needs further rework:
- Introduce new non-zeroing DMA API to allow the remoteproc core to
still process the RSC_CARVEOUTs but not zero them (This will need to
be replaced with static carveout support)
- The new "late_attach" field added to remoteproc core needs to be
replaced with equivalent fields already present that supports the
K3 IPC-only mode and Keystone 2 Multi Proc Manager (MPM) stack.
- The .device_is_enabled() logic is only temporary and applicable only
with hwmod layers, this will need to be replaced with logic around
reset status from OMAP PRM reset driver (next LTS).
- The reserved memory regions used should actually be carveouts (DMA
pools), and this needs some resource table RSC_CARVEOUT entries split
on all the existing firmwares.
- The addition of the DT modifications needs to be evaluated if it can
be moved into U-Boot itself. The current logic requires that both
U-Boot and kernel configs are matched, without which kernel crashes
are seen.
* 'topic/4.19/dra7-late-attach' of git://git.ti.com/rpmsg/remoteproc:
HACK: ARM: dts: dra7-ipu-common: Revert to CMA pools for IPU early boots
TEMP: ARM: dts: dra7-ipu-common: Add a common file for IPU early boots
TEMP: remoteproc/omap: add "late attach" support
TEMP: iommu/omap: add support for performing a "late attach"
ARM: OMAP2+: pdata-quirks: Add device_is_enabled ops for IOMMUs and rprocs
clocksource: timer-ti-dm: Add support to handle late attach of rproc timers
TEMP: remoteproc: call the non-zeroing allocation function
TEMP: remoteproc: add "late attach" support
HACK: dma-mapping: add non-zeroing coherent alloc function
HACK: ARM: dma-mapping: create non-zeroing dma_map_ops
Signed-off-by: Suman Anna <s-anna@ti.com>
Pull in a dedicated remoteproc topic branch that adds the infrastructure
support to allow "late-attach" of the IPU1 and IPU2 remote processors on
DRA7xx/AM57xx SoCs. The late-attach feature is the kernel counterpart to
the early-boot of these processors from U-Boot/SPL to achieve key system
response time goals.
The support is provided through temporary HACKs or workarounds to various
subsystems that includes the DMA API layers, remoteproc core, OMAP IOMMU,
OMAP DMTimer and OMAP remoteproc drivers. The early-booted remoteproc
devices need couple of DT modifications, and these are provided through
a common dtsi file. This common dtsi file needs to be included in the
desired target DRA7/AM57xx board dts files (not merged but available on
the above topic branch).
The following are the main HACKs and needs further rework:
- Introduce new non-zeroing DMA API to allow the remoteproc core to
still process the RSC_CARVEOUTs but not zero them (This will need to
be replaced with static carveout support)
- The new "late_attach" field added to remoteproc core needs to be
replaced with equivalent fields already present that supports the
K3 IPC-only mode and Keystone 2 Multi Proc Manager (MPM) stack.
- The .device_is_enabled() logic is only temporary and applicable only
with hwmod layers, this will need to be replaced with logic around
reset status from OMAP PRM reset driver (next LTS).
- The reserved memory regions used should actually be carveouts (DMA
pools), and this needs some resource table RSC_CARVEOUT entries split
on all the existing firmwares.
- The addition of the DT modifications needs to be evaluated if it can
be moved into U-Boot itself. The current logic requires that both
U-Boot and kernel configs are matched, without which kernel crashes
are seen.
* 'topic/4.19/dra7-late-attach' of git://git.ti.com/rpmsg/remoteproc:
HACK: ARM: dts: dra7-ipu-common: Revert to CMA pools for IPU early boots
TEMP: ARM: dts: dra7-ipu-common: Add a common file for IPU early boots
TEMP: remoteproc/omap: add "late attach" support
TEMP: iommu/omap: add support for performing a "late attach"
ARM: OMAP2+: pdata-quirks: Add device_is_enabled ops for IOMMUs and rprocs
clocksource: timer-ti-dm: Add support to handle late attach of rproc timers
TEMP: remoteproc: call the non-zeroing allocation function
TEMP: remoteproc: add "late attach" support
HACK: dma-mapping: add non-zeroing coherent alloc function
HACK: ARM: dma-mapping: create non-zeroing dma_map_ops
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'for19.04.01' of ssh://bitbucket.itg.ti.com/~a0869644/ti-linux-kernel into audio_display-ti-linux-4.19.y
2019.04-rc2 WB fixes
* 'for19.04.01' of ssh://bitbucket.itg.ti.com/~a0869644/ti-linux-kernel:
drm/tidss: WB: fix nested redefinition of enum kbuild error
drm/tidss: WB: fix frame size kbuild warning
2019.04-rc2 WB fixes
* 'for19.04.01' of ssh://bitbucket.itg.ti.com/~a0869644/ti-linux-kernel:
drm/tidss: WB: fix nested redefinition of enum kbuild error
drm/tidss: WB: fix frame size kbuild warning
Merged TI feature audio-display into ti-linux-4.19.y
TI-Feature: audio-display
TI-Branch: audio_display-ti-linux-4.19.y
* 'audio_display-ti-linux-4.19.y' of ssh://bitbucket.itg.ti.com/lcpdpublicdom/audio-display:
drm/bridge: cdns-mhdp: Probe and add the bridge even without firmware
drm/bridge: cdns-mhdp: Call phy_exit() in mhdp_remove()
drm/bridge: cdns-mhdp: Handle probe failures correctly
drm/bridge: cdns-mhdp: Drop useless container structs
drm/bridge: cdns-mhdp: Remove dependencies to cdns-mhdp-common
ASoC: pcm3168a: The codec does not support S32_LE
drm/rockchip: Restore everything to what is there in v4.19.73
drm/bridge: cdns-mhdp: Remove completely untested audio support
drm/tidss: constify rpmsg ops structs
drm/tidss: add missing static declarations in DSS sharing code
Signed-off-by: Dan Murphy <dmurphy@ti.com>
TI-Feature: audio-display
TI-Branch: audio_display-ti-linux-4.19.y
* 'audio_display-ti-linux-4.19.y' of ssh://bitbucket.itg.ti.com/lcpdpublicdom/audio-display:
drm/bridge: cdns-mhdp: Probe and add the bridge even without firmware
drm/bridge: cdns-mhdp: Call phy_exit() in mhdp_remove()
drm/bridge: cdns-mhdp: Handle probe failures correctly
drm/bridge: cdns-mhdp: Drop useless container structs
drm/bridge: cdns-mhdp: Remove dependencies to cdns-mhdp-common
ASoC: pcm3168a: The codec does not support S32_LE
drm/rockchip: Restore everything to what is there in v4.19.73
drm/bridge: cdns-mhdp: Remove completely untested audio support
drm/tidss: constify rpmsg ops structs
drm/tidss: add missing static declarations in DSS sharing code
Signed-off-by: Dan Murphy <dmurphy@ti.com>
ti_config_fragments/connectivity.cfg: Enable NTB configs
Enable NTB related configs to enable NTB both on the host and device
systems.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Enable NTB related configs to enable NTB both on the host and device
systems.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
arm64: dts: ti: k3-j721e: Add DT overlay for PCIe Backplane
Add DT overlay for PCIe Backplane to configure the PCIe instances
in EP mode and includes a NTB DT node.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Add DT overlay for PCIe Backplane to configure the PCIe instances
in EP mode and includes a NTB DT node.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
arm64: dts: ti: k3-j721e: Add reference to *phy* in PCIe EP DT node
Add *phys* and *phy-names* property to PCIe EP DT nodes.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Add *phys* and *phy-names* property to PCIe EP DT nodes.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
NTB: tool: Enable the NTB/PCIe link on the local or remote side of bridge
Invoke ntb_link_enable() to enable the NTB/PCIe link on the local
or remote side of the bridge.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Invoke ntb_link_enable() to enable the NTB/PCIe link on the local
or remote side of the bridge.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
NTB: Add support for EPF PCI-Express Non-Transparent Bridge
Add support for EPF PCI-Express Non-Transparent Bridge (NTB) device.
This driver is platform independent and could be used by any platform
which have multiple PCIe endpoint instances configured using the
pci-epf-ntb driver. The driver connnects to the standard NTB sub-system
interface. The EPF NTB device has configurable number of memory windows
(Max 4), configurable number of doorbell (Max 32), and configurable
number of scratch-pad registers.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Add support for EPF PCI-Express Non-Transparent Bridge (NTB) device.
This driver is platform independent and could be used by any platform
which have multiple PCIe endpoint instances configured using the
pci-epf-ntb driver. The driver connnects to the standard NTB sub-system
interface. The EPF NTB device has configurable number of memory windows
(Max 4), configurable number of doorbell (Max 32), and configurable
number of scratch-pad registers.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
PCI: Add TI J721E device to pci ids
Add TI J721E device to the pci id database. Since this device has
a configurable PCIe endpoint, it could be used with different
drivers.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Add TI J721E device to the pci id database. Since this device has
a configurable PCIe endpoint, it could be used with different
drivers.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
PCI: endpoint: Add EP function driver to provide NTB functionality
Add a new endpoint function driver to provide NTB functionality
using multiple PCIe endpoint instances.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Add a new endpoint function driver to provide NTB functionality
using multiple PCIe endpoint instances.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
PCI: endpoint: *_free_bar() to return error codes on failure
Modify pci_epc_get_next_free_bar() and pci_epc_get_first_free_bar() to
return error values if there are no free BARs available.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Modify pci_epc_get_next_free_bar() and pci_epc_get_first_free_bar() to
return error values if there are no free BARs available.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
PCI: endpoint: Fix missing mutex_unlock in error case
There is a missing mutex_unlock() in pci_epc_add_epf() in one of the
error scenarios. Fix it here.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
There is a missing mutex_unlock() in pci_epc_add_epf() in one of the
error scenarios. Fix it here.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
PCI: endpoint: Remove unused pci_epf_match_device()
Remove unused pci_epf_match_device() function added in pci-epf-core.c
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Remove unused pci_epf_match_device() function added in pci-epf-core.c
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
PCI: cadence: Implement ->msi_map_irq() ops
Implement ->msi_map_irq() ops in order to map physical address to
MSI address and return MSI data.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Implement ->msi_map_irq() ops in order to map physical address to
MSI address and return MSI data.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
PCI: endpoint: Add pci_epc_ops to map MSI irq
Add pci_epc_ops to map physical address to MSI address and return MSI
data. The physical address is an address in the outbound region. This is
required to implement doorbell functionality of NTB (non transparent
bridge) wherein EPC on either side of the interface (primary and
secondary) can directly write to the physical address (in outbound
region) of the other interface to ring doorbell using MSI.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Add pci_epc_ops to map physical address to MSI address and return MSI
data. The physical address is an address in the outbound region. This is
required to implement doorbell functionality of NTB (non transparent
bridge) wherein EPC on either side of the interface (primary and
secondary) can directly write to the physical address (in outbound
region) of the other interface to ring doorbell using MSI.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
PCI: endpoint: Add support to associate secondary EPC with EPF
In the case of standard endpoint functions, only one endpoint
controller (EPC) will be associated with an endpoint function
(EPF). However for providing NTB (non transparent bridge)
functionality, two EPCs should be associated with a single EPF.
Add support to associate secondary EPC with EPF. This is in
preparation for adding NTB endpoint function driver.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
In the case of standard endpoint functions, only one endpoint
controller (EPC) will be associated with an endpoint function
(EPF). However for providing NTB (non transparent bridge)
functionality, two EPCs should be associated with a single EPF.
Add support to associate secondary EPC with EPF. This is in
preparation for adding NTB endpoint function driver.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
PCI: endpoint: Add helper API to populate header with values from DT
Add helper API pci_epc_of_parse_header() to populate header with
values from device tree. These values will be written to the
configuration space header in the endpoint controller.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Add helper API pci_epc_of_parse_header() to populate header with
values from device tree. These values will be written to the
configuration space header in the endpoint controller.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
PCI: endpoint: Make pci_epf_driver ops optional
pci_epf_driver had two ops for bind and unbind which will be invoked
when an endpoint controller is bound to an endpoint function (using
configfs). Now that endpoint core has support to define an endpoint
function using device tree alone, the bind and unbind ops can be
optional. Make pci_epf_driver ops optional here.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
pci_epf_driver had two ops for bind and unbind which will be invoked
when an endpoint controller is bound to an endpoint function (using
configfs). Now that endpoint core has support to define an endpoint
function using device tree alone, the bind and unbind ops can be
optional. Make pci_epf_driver ops optional here.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
PCI: endpoint: Add helper API to get the 'next' unreserved BAR
Add an API to get the next unreserved BAR starting from a given BAR
number that can be used by the endpoint function.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Add an API to get the next unreserved BAR starting from a given BAR
number that can be used by the endpoint function.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
PCI: endpoint: Make *_get_first_free_bar() take into account 64 bit BAR
pci_epc_get_first_free_bar() uses only "reserved_bar" member in
epc_features to get the first unreserved BAR. However if the
reserved BAR is also a 64-bit BAR, then the next BAR shouldn't be
returned (since 64-bit BAR uses two BARs).
Make pci_epc_get_first_free_bar() take into account 64 bit BAR while
returning the first free unreserved BAR.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
pci_epc_get_first_free_bar() uses only "reserved_bar" member in
epc_features to get the first unreserved BAR. However if the
reserved BAR is also a 64-bit BAR, then the next BAR shouldn't be
returned (since 64-bit BAR uses two BARs).
Make pci_epc_get_first_free_bar() take into account 64 bit BAR while
returning the first free unreserved BAR.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
PCI: endpoint: Add "pci-epf-bus" driver
Add "pci-epf-bus" driver that helps to create EPF device from
device tree. This is added in order to define an endpoint function
completely from device tree.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Add "pci-epf-bus" driver that helps to create EPF device from
device tree. This is added in order to define an endpoint function
completely from device tree.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
PCI: endpoint: Add API to create EPF device from device tree
Add API to create EPF device from device tree and the device managed
interface corresponding to it. This is added in order to define
an endpoint function completely from device tree.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Add API to create EPF device from device tree and the device managed
interface corresponding to it. This is added in order to define
an endpoint function completely from device tree.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
PCI: endpoint: Add API to get reference to EPC from device-tree
Add of_pci_epc_get() and of_pci_epc_get_by_name() to get reference
to EPC from device-tree. This is added in preparation to define
an endpoint function from device tree.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Add of_pci_epc_get() and of_pci_epc_get_by_name() to get reference
to EPC from device-tree. This is added in preparation to define
an endpoint function from device tree.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Documentation: PCI: Add specification for the *PCI NTB* function device
Add specification for the *PCI NTB* function device. The endpoint function
driver and the host PCI driver should be created based on this
specification.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Add specification for the *PCI NTB* function device. The endpoint function
driver and the host PCI driver should be created based on this
specification.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
dt-bindings: PCI: Endpoint: Add DT bindings for PCI EPF NTB Device
Add device tree bindings for PCI endpoint NTB function device.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Add device tree bindings for PCI endpoint NTB function device.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
dt-bindings: PCI: Endpoint: Add DT bindings for PCI EPF Device
Add device tree bindings for PCI endpoint function device. The
nodes for PCI endpoint function device should be attached to
PCI endpoint function bus.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Add device tree bindings for PCI endpoint function device. The
nodes for PCI endpoint function device should be attached to
PCI endpoint function bus.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
dt-bindings: PCI: Endpoint: Add DT bindings for PCI EPF Bus
Add device tree bindings for PCI endpoint function bus to which
endpoint function devices should be attached.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Add device tree bindings for PCI endpoint function bus to which
endpoint function devices should be attached.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
net: ethernet: ti: am65-cpsw: fix sw timestamping for non PTP packets
The cpts can timestmap only ptp packets at this moment, so driver
cannot mark every packet as though it's going to be timestamped,
only because h/w timestamping for given skb is enabled with
SKBTX_HW_TSTAMP. It doesn't allow to use sw timestamping, as result
outgoing packet is not timestamped at all if it's not PTP and h/w
timestamping is enabled. So, fix it by setting SKBTX_IN_PROGRESS
only for packets that can be timestamped. Also move this change to
cpts module it can be reused.
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
The cpts can timestmap only ptp packets at this moment, so driver
cannot mark every packet as though it's going to be timestamped,
only because h/w timestamping for given skb is enabled with
SKBTX_HW_TSTAMP. It doesn't allow to use sw timestamping, as result
outgoing packet is not timestamped at all if it's not PTP and h/w
timestamping is enabled. So, fix it by setting SKBTX_IN_PROGRESS
only for packets that can be timestamped. Also move this change to
cpts module it can be reused.
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
HACK: ARM: dts: dra7-ipu-common: Revert to CMA pools for IPU early boots
The patch d1a42fca5944 ("TEMP: ARM: dts: dra7-ipu-common: Add a common
file for IPU early boots") converts the default CMA pools used in regular
remoteproc mode to carveouts/DMA pools for early-boot usage scenarios
using the "no-map" property to avoid the kernel from corrupting the
remoteproc firmware image sections.
The allocation scheme with DMA pools though is different than with CMA
pools, and this may cause some of the existing firmwares used in the
regular remoteproc mode with CMA to fail. The DMA pools may require a
number of changes in general:
- Split the firmware RSC_CARVEOUT sections into better aligned memory
regions conducive to the DMA pool allocation scheme.
- Increase the vmalloc size, as the DMA pools are no longer mapped by
default in kernel linear memory (for DDR < 2 GB) and needs to be
mapped into vmalloc space to be accessed. This may depend on system
configuration, number of remote cores using a DMA pool, and the sizes
of the DMA pools.
- Increase the size of the carveouts (last resort)
Revert back to CMA pools temporarily to make the current firmware images
be functional. A short-term fix would be to update the firmwares and the
long-term fix would be to eliminate the allocation logic altogether and
rely on fixed memory carveout support.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Angela Stegmaier <angelabaker@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
The patch d1a42fca5944 ("TEMP: ARM: dts: dra7-ipu-common: Add a common
file for IPU early boots") converts the default CMA pools used in regular
remoteproc mode to carveouts/DMA pools for early-boot usage scenarios
using the "no-map" property to avoid the kernel from corrupting the
remoteproc firmware image sections.
The allocation scheme with DMA pools though is different than with CMA
pools, and this may cause some of the existing firmwares used in the
regular remoteproc mode with CMA to fail. The DMA pools may require a
number of changes in general:
- Split the firmware RSC_CARVEOUT sections into better aligned memory
regions conducive to the DMA pool allocation scheme.
- Increase the vmalloc size, as the DMA pools are no longer mapped by
default in kernel linear memory (for DDR < 2 GB) and needs to be
mapped into vmalloc space to be accessed. This may depend on system
configuration, number of remote cores using a DMA pool, and the sizes
of the DMA pools.
- Increase the size of the carveouts (last resort)
Revert back to CMA pools temporarily to make the current firmware images
be functional. A short-term fix would be to update the firmwares and the
long-term fix would be to eliminate the allocation logic altogether and
rely on fixed memory carveout support.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Angela Stegmaier <angelabaker@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
TEMP: ARM: dts: dra7-ipu-common: Add a common file for IPU early boots
The remoteproc 'late attach' functionality has the remote processors
configured, programmed and booted early even before the kernel is booted.
This includes loading the necessary firmware into memory, programming the
IOMMU, configuring the required timers, and programming the corresponding
device's clocks and resets.
The omap hwmod init sequence includes resetting all the hwmods and
idling them to put the devices in sane states to make them independent
of bootloader and corresponding drivers. The "ti,no-idle-on-init" and
"ti,no-reset-on-init" attributes are added to specific omap_hwmod's
associated with the IPU1 & IPU2 processor subsystems to support the
'late attach' feature on these devices, and change the omap hwmod init
behavior. The corresponding memory regions are also removed from the
default kernel memory map (DMA pools instead of CMA pools) so that the
kernel doesn't access anything in these regions until the remoteprocs
are booted.
The "ti,no-reset-on-init" attribute is needed to allow the omap_hwmod
layer to not perform a reset (and thereby reset the programming done
prior to kernel boot). The "ti,no-idle-on-init" is needed to leave the
modules/device in enabled state (and thereby avoid any disabling of the
clocks/modules).
These attributes are added in a new common dtsi file that should be
included into the corresponding TI DRA7xx and AM57xx boards that have
actually early-booted the IPU processors. This file _must_ be included
_only_ when both the IPU1 and IPU2 processors have been booted by
SPL/U-boot.
TODO:
Evaluate the approach where U-Boot can directly add/modify these required
properties using code. Such an approach would eliminate the need for
maintaining one or more dtsi files/overlays and make the support
self-contained within the bootloader.
Signed-off-by: Amarinder Bindra <a-bindra@ti.com>
Signed-off-by: Robert Tivy <rtivy@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Angela Stegmaier <angelabaker@ti.com>
Signed-off-by: Venkateswara Rao Mandela <venkat.mandela@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
The remoteproc 'late attach' functionality has the remote processors
configured, programmed and booted early even before the kernel is booted.
This includes loading the necessary firmware into memory, programming the
IOMMU, configuring the required timers, and programming the corresponding
device's clocks and resets.
The omap hwmod init sequence includes resetting all the hwmods and
idling them to put the devices in sane states to make them independent
of bootloader and corresponding drivers. The "ti,no-idle-on-init" and
"ti,no-reset-on-init" attributes are added to specific omap_hwmod's
associated with the IPU1 & IPU2 processor subsystems to support the
'late attach' feature on these devices, and change the omap hwmod init
behavior. The corresponding memory regions are also removed from the
default kernel memory map (DMA pools instead of CMA pools) so that the
kernel doesn't access anything in these regions until the remoteprocs
are booted.
The "ti,no-reset-on-init" attribute is needed to allow the omap_hwmod
layer to not perform a reset (and thereby reset the programming done
prior to kernel boot). The "ti,no-idle-on-init" is needed to leave the
modules/device in enabled state (and thereby avoid any disabling of the
clocks/modules).
These attributes are added in a new common dtsi file that should be
included into the corresponding TI DRA7xx and AM57xx boards that have
actually early-booted the IPU processors. This file _must_ be included
_only_ when both the IPU1 and IPU2 processors have been booted by
SPL/U-boot.
TODO:
Evaluate the approach where U-Boot can directly add/modify these required
properties using code. Such an approach would eliminate the need for
maintaining one or more dtsi files/overlays and make the support
self-contained within the bootloader.
Signed-off-by: Amarinder Bindra <a-bindra@ti.com>
Signed-off-by: Robert Tivy <rtivy@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Angela Stegmaier <angelabaker@ti.com>
Signed-off-by: Venkateswara Rao Mandela <venkat.mandela@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>