- Apr 28, 2020
-
-
LCPD Auto Merger authored
TI-Feature: connectivity TI-Branch: connectivity-ti-linux-5.4.y * 'connectivity-ti-linux-5.4.y' of ssh://bitbucket.itg.ti.com/lcpdpublicdom/connectivity : rpmsg-kdrv: rpmsg_kdrv_switch: fix build warnings rpmsg-kdrv: rpmsg_kdrv_display: fix build warns rpmsg-kdrv: fix 'variable 'ret' is used uninitialized whenever 'for' loop exits' Signed-off-by:
LCPD Auto Merger <lcpd_integration@list.ti.com>
-
Vignesh Raghavendra authored
Merge tag 'LCPD-18522' of ssh://bitbucket.itg.ti.com/~x1045550/ti-priv-linux-kernel into connectivity-ti-linux-5.4.y
-
Grygorii Strashko authored
rpmsg_kdrv_switch.c:711:39: warning: symbol 'switch_ops' was not declared. Should it be static? rpmsg_kdrv_switch.c:806:26: warning: symbol 'rpmsg_kdrv_switch' was not declared. Should it be static? Signed-off-by:Grygorii Strashko <grygorii.strashko@ti.com>
-
Grygorii Strashko authored
../drivers/rpmsg-kdrv/rpmsg_kdrv_display.c:359:36: warning: symbol 'disp_ops' was not declared. Should it be static? ../drivers/rpmsg-kdrv/rpmsg_kdrv_display.c:452:26: warning: symbol 'rpmsg_kdrv_display' was not declared. Should it be static? Signed-off-by: -
Grygorii Strashko authored
Fix build warning rpmsg_kdrv.c:282:14: warning: variable 'ret' is used uninitialized whenever 'for' loop exits because its condition is false [-Wsometimes-uninitialized] for (i = 0; i < priv->num_raw_devices; i++) Signed-off-by: -
LCPD Auto Merger authored
TI-Feature: connectivity TI-Branch: connectivity-ti-linux-5.4.y * 'connectivity-ti-linux-5.4.y' of ssh://bitbucket.itg.ti.com/lcpdpublicdom/connectivity : net: ethernet: ti: icssg_prueth: fix irqs type net: ethernet: ti: j721e-cpsw-virt-mac: fix irqs type Signed-off-by:
-
Vignesh Raghavendra authored
Merge tag 'LCPD-18501' of ssh://bitbucket.itg.ti.com/~x1045550/ti-priv-linux-kernel into connectivity-ti-linux-5.4.y
-
- Apr 27, 2020
-
-
Dan Murphy authored
Merge tag 'v5.4.34' of http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable into ti-linux-5.4.y This is the 5.4.34 stable release * tag 'v5.4.34' of http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable: (565 commits) Linux 5.4.34 x86/microcode/AMD: Increase microcode PATCH_MAX_SIZE scsi: target: fix hang when multiple threads try to destroy the same iscsi session scsi: target: remove boilerplate code x86/resctrl: Fix invalid attempt at removing the default resource group x86/resctrl: Preserve CDP enable over CPU hotplug irqchip/ti-sci-inta: Fix processing of masked irqs ext4: do not zeroout extents beyond i_disksize i2c: designware: platdrv: Remove DPM_FLAG_SMART_SUSPEND flag on BYT and CHT drm/amdgpu: fix the hw hang during perform system reboot and reset drm/amd/powerplay: force the trim of the mclk dpm_levels if OD is enabled net/mlx5e: Use preactivate hook to set the indirection table net/mlx5e: Rename hw_modify to preactivate net/mlx5e: Encapsu...
-
LCPD Auto Merger authored
TI-Feature: integration TI-Branch: integration-ti-linux-5.4.y * 'integration-ti-linux-5.4.y' of ssh://bitbucket.itg.ti.com/lcpdpublicdom/integration : perf: Make perf able to build with latest libbfd Signed-off-by:
-
Changbin Du authored
[ Upstream commit 0ada120c ] libbfd has changed the bfd_section_* macros to inline functions bfd_section_<field> since 2019-09-18. See below two commits: o http://www.sourceware.org/ml/gdb-cvs/2019-09/msg00064.html o https://www.sourceware.org/ml/gdb-cvs/2019-09/msg00072.html This fix make perf able to build with both old and new libbfd. Signed-off-by:
Changbin Du <changbin.du@gmail.com> Acked-by:
Jiri Olsa <jolsa@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lore.kernel.org/lkml/20200128152938.31413-1-changbin.du@gmail.com Signed-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
Denys Dmytriyenko <denys@ti.com>
-
LCPD Auto Merger authored
TI-Feature: rpmsg TI-Branch: rpmsg-ti-linux-5.4.y-intg * 'rpmsg-ti-linux-5.4.y-intg' of git://git.ti.com/rpmsg/rpmsg : arm64: dts: ti: am654-base-board: Add a board dts variant for SR1.0 arm64: dts: ti: k3-am65-main: Update ICSSG nodes for SR2.0 remoteproc/pru: Add support for Tx PRU cores on K3 AM65x SR2.0 SoCs dt-bindings: remoteproc: pru: Update bindings for K3 AM65x SR2.0 SoCs remoteproc/pru: Cleanup of_device_is_compatible() usage Signed-off-by:
-
Suman Anna authored
The AM65x family of SoCs has two Silicon Revisions - SR1.0 and SR2.0. The AM65x SR2.0 will be the officially supported revision, and all the current dtsi and dts files will be reused to represent this Silicon Revision. The AM65x SR2.0 SoCs have a revised ICSSG IP that is based off the subsequent IP revision used on J721E SoCs. The ICSSG IP on AM65x SR2.0 SoCs have two new custom auxiliary PRU cores called Transmit PRUs (Tx_PRUs) in addition to the existing PRUs and RTUs, but these are not present on AM65x SR1.0 SoCs. The Tx_PRU nodes are added and enabled by default in the base k3-am654-main.dtsi file. Add a new board dts variant file am654-base-board-sr1.dts, that inherits the regular am654-base-board.dts file, and will be customized to add any changes required to boot a AM65x board using the SR1.0 Silicon. The Tx_PRU nodes are absent on SR1.0 and so are disabled to begin with. NOTE: This will not be upstreamed, and so there is no refactoring done to either introduce a am654-base-board-common.dtsi or a am65x-sr1.dtsi files. Signed-off-by:Suman Anna <s-anna@ti.com>
-
Suman Anna authored
The AM65x SR2.0 SoCs have a significantly revised ICSSG IP that is based off the subsequent IP used on J721E SoCs, yet retaining some of the features from AM65x SR1.0 like the PRU IRAM size etc. The ICSSG2 instance also continues to have a few additional sub-modules like on AM65x SR1.0. One of the main changes is the presence of two new auxiliary PRU cores called Tx_PRUs. The Tx_PRUs have 6 KB of IRAMs and leverage the same host interrupts as the regular PRU cores. The Broadside (BS) RAM within each core is also sized differently w.r.t SR1.0. Update the existing ICSSG nodes for SR2.0 by adding new sub-nodes for the Tx_PRU cores. The compatibles are currently maintained to be the same between SR1.0 and SR2.0, with any sub-module IP differences handled within the driver using SoC device match logic. The Tx_PRU nodes are expected to be disabled in the SR1.0 specific dts or overlay file. The default names for the firmware images for each Tx_PRU core is defined as follows (these can be adjusted either in derivative board dts files or through sysfs at runtime if required): ICSSG0 Tx_PRU0 Core: am65x-txpru0_0-fw ; Tx_PRU1 Core: am65x-txpru0_1-fw ICSSG1 Tx_PRU0 Core: am65x-txpru1_0-fw ; Tx_PRU1 Core: am65x-txpru1_1-fw ICSSG2 Tx_PRU0 Core: am65x-txpru2_0-fw ; Tx_PRU1 Core: am65x-txpru2_1-fw Signed-off-by:
Roger Quadros <rogerq@ti.com>
-
-
git://git.ti.com/rpmsg/remoteprocSuman Anna authored
Pull in the updated remoteproc feature branch that adds the base support to the PRU remoteproc driver for supporting the enhanced ICSSG IP in AM65x SR2.0 SoCs. The merge also includes some cleanup to the PRU remoteproc driver to introduce device match data so as to move away from runtime of_device_is_compatible() usage in code. * 'rproc-linux-5.4.y' of git://git.ti.com/rpmsg/remoteproc : remoteproc/pru: Add support for Tx PRU cores on K3 AM65x SR2.0 SoCs dt-bindings: remoteproc: pru: Update bindings for K3 AM65x SR2.0 SoCs remoteproc/pru: Cleanup of_device_is_compatible() usage Signed-off-by:
-
Suman Anna authored
The AM65x SR2.0 SoCs have a revised ICSSG IP that is based off the subsequent IP revision used on J721E SoCs. This IP instance has two new custom auxiliary PRU cores called Transmit PRUs (Tx_PRUs) in addition to the existing PRUs and RTUs. The Tx_PRU cores have their own dedicated IRAM (smaller than a PRU or RTY), Control and debug feature sets. The RTU and Tx_PRU cores though share the same Data RAMs as the PRU cores, so the memories have to be partitioned carefully between different applications. Enhance the existing PRU remoteproc driver to support these new Tx PRU cores by using specific compatibles. Signed-off-by: -
Suman Anna authored
The AM65x SR2.0 SoCs have a revised ICSSG IP that is based off the subsequent IP revision used on J721E SoCs, yet retaining some of the features from AM65x SR1.0 like the PRU IRAM size etc. The ICSSG IP on K3 AM65x SR2.0 SoCs have two new custom auxiliary PRU cores called Transmit PRUs (Tx_PRUs) in addition to the existing PRUs and RTUs. Update the PRU remoteproc bindings for these Tx PRU cores. Signed-off-by: -
Suman Anna authored
The PRU remoteproc driver uses the of_device_is_compatible() function during probe to dynamically assign some flags and properties for each PRU core. This usage is not recommended and makes the code a bit cumbersome. Cleanup most of this usage by using device compatible match data. The check for K2G to conditionally avoid the mailbox usage is the only check left-out. Signed-off-by: -
Grygorii Strashko authored
The K3 INTA driver, which is source TX/RX IRQs for ICSSG network, defines IRQs triggering type as EDGE by default, but triggering type for CPSW NUSS TX/RX IRQs has to be LEVEL as the EDGE triggering type may cause unnecessary IRQs triggering and NAPI scheduling for empty queues. Fix it by explicitly specifying ICSSG TX/RX IRQ type as IRQF_TRIGGER_HIGH. Signed-off-by: -
Grygorii Strashko authored
The K3 INTA driver, which is source TX/RX IRQs for CPSW NUSS, defines IRQs triggering type as EDGE by default, but triggering type for CPSW NUSS TX/RX IRQs has to be LEVEL as the EDGE triggering type may cause unnecessary IRQs triggering and NAPI scheduling for empty queues. Fix it by explicitly specifying CPSW NUSS TX/RX IRQ type as IRQF_TRIGGER_HIGH. Signed-off-by:
-
- Apr 24, 2020
-
-
LCPD Auto Merger authored
TI-Feature: connectivity TI-Branch: connectivity-ti-linux-5.4.y * 'connectivity-ti-linux-5.4.y' of ssh://bitbucket.itg.ti.com/lcpdpublicdom/connectivity : ti_config_fragments/connectivity.cfg: Enable pwm omap dmtimer Signed-off-by:
-
LCPD Auto Merger authored
TI-Feature: platform_base TI-Branch: platform-ti-linux-5.4.y * 'platform-ti-linux-5.4.y' of ssh://bitbucket.itg.ti.com/lcpdpublicdom/platform : pwm: omap-dmtimer: Implement .apply callback pwm: omap-dmtimer: Do not disable PWM before changing period/duty_cycle pwm: omap-dmtimer: Fix PWM enabling sequence pwm: omap-dmtimer: Update description for PWM OMAP DM timer pwm: omap-dmtimer: Drop unused header file remoteproc/omap: Fix set_load call in omap_rproc_request_timer clocksource/drivers/timer-ti-dm: Enable autoreload in set_pwm clocksource/drivers/timer-ti-dm: Add support to get pwm current status clocksource/drivers/timer-ti-dm: Do not update counter on updating the period clocksource/drivers/timer-ti-dm: Implement cpu_pm notifier for context save and restore clocksource/drivers/timer-ti-dm: Prepare for using cpuidle clocksource/drivers/timer-ti-dm: Convert to SPDX identifier dmaengine: ti: k3-udma: SYSFW ABI 3.0 support Signed-off-by:
-
Lokesh Vutla authored
commit 6b28fb6f upstream. Implement .apply callback and drop the legacy callbacks(enable, disable, config, set_polarity). In .apply() check for the current hardware status before changing the PWM configuration. Signed-off-by:
Lokesh Vutla <lokeshvutla@ti.com> Tested-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
Thierry Reding <thierry.reding@gmail.com>
-
Lokesh Vutla authored
commit e793eef8 upstream. Only the Timer control register(TCLR) cannot be updated when the timer is running. Registers like Counter register (TCRR), loader register (TLDR) and match register (TMAR) can be updated while the counter is running. Since TCLR is not updated in pwm_omap_dmtimer_config(), do not stop the timer for period/duty_cycle update. Tested-by:
-
Lokesh Vutla authored
commit 867beb60 upstream. To configure DM timer in PWM mode the following needs to be set in OMAP_TIMER_CTRL_REG using set_pwm callback: - Set toggle mode on PORTIMERPWM output pin - Set trigger on overflow and match on PORTIMERPWM output pin. - Set auto reload This is a one time configuration and needs to be set before the start of the DM timer. But the current driver tries to set the same configuration for every period/duty cycle update, which is not needed. So move the PWM setup before enabling timer and do not update it in pwm_omap_dmtimer_config(). Tested-by:
-
Lokesh Vutla authored
commit 348fb6f7 upstream. Update the description with a brief about how PWM is generated using OMAP DM timer and add limitations for the PWM generations. Also add a link to the reference manual. Suggested-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by:
-
Lokesh Vutla authored
commit 54091b5f upstream. pwm_omap_dmtimer.h is used only: - to typedef struct omap_dm_timer to pwm_omap_dmtimer - for macro PWM_OMAP_DMTIMER_TRIGGER_OVERFLOW_AND_COMPARE Rest of the file is pretty mush unsed. So reuse omap_dm_timer and OMAP_TIMER_TRIGGER_OVERFLOW_AND_COMPARE in pwm-omap-dmtimer.c and delete the header file. Acked-by:
-
Nathan Chancellor authored
commit e6d05acd upstream. When building arm allyesconfig: drivers/remoteproc/omap_remoteproc.c:174:44: error: too many arguments to function call, expected 2, have 3 timer->timer_ops->set_load(timer->odt, 0, 0); ~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ 1 error generated. This is due to commit 02e6d546 ("clocksource/drivers/timer-ti-dm: Enable autoreload in set_pwm") in the clockevents tree interacting with commit e28edc57 ("remoteproc/omap: Request a timer(s) for remoteproc usage") from the rpmsg tree. This should have been fixed during the merge of the remoteproc tree since it happened after the clockevents tree merge; however, it does not look like my email was noticed by either maintainer and I did not pay attention when the pull was sent since I was on CC. Fixes: c6570114 ("Merge tag 'rproc-v5.7' of git://git.kernel.org/pub/scm/linux/kernel/git/andersson/remoteproc") Link: https://lore.kernel.org/lkml/20200327185055.GA22438@ubuntu-m2-xlarge-x86/ Signed-off-by:
Nathan Chancellor <natechancellor@gmail.com> Acked-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Lokesh Vutla authored
commit 02e6d546 upstream. dm timer ops set_load() api allows to configure the load value and to set the auto reload feature. But auto reload feature is independent of load value and should be part of configuring pwm. This way pwm can be disabled by disabling auto reload feature using set_pwm() so that the current pwm cycle will be completed. Else pwm disabling causes the cycle to be stopped abruptly. Signed-off-by:
Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20200305082715.15861-7-lokeshvutla@ti.com
-
Lokesh Vutla authored
commit 92fd8686 upstream. omap_dm_timer_ops provide support to configure the pwm but there is no support to get the current status. For configuring pwm it is advised to check the current hw status instead of relying on pwm framework. So implement a new timer ops to get the current status of pwm. Signed-off-by:
-
Lokesh Vutla authored
commit aff7665d upstream. Write to trigger register(OMAP_TIMER_TRIGGER_REG) will load the value in Load register(OMAP_TIMER_LOAD_REG) into Counter register (OMAP_TIMER_COUNTER_REG). omap_dm_timer_set_load() writes into trigger register every time load register is updated. When timer is configured in pwm mode, this causes disruption in current pwm cycle, which is not expected especially when pwm is used as PPS signal for synchronized PTP clocks. So do not write into trigger register on updating the period. Tested-by:
-
Lokesh Vutla authored
commit b34677b0 upstream. omap_dm_timer_enable() restores the entire context(including counter) based on 2 conditions: - If get_context_loss_count is populated and context is lost. - If get_context_loss_count is not populated update unconditionally. Case2 has a side effect of updating the counter register even though context is not lost. When timer is configured in pwm mode, this is causing undesired behaviour in the pwm period. Instead of using get_context_loss_count call back, implement cpu_pm notifier with context save and restore support. And delete the get_context_loss_count callback all together. Suggested-by:
-
Tony Lindgren authored
commit 5e20931c upstream. Let's add runtime_suspend and resume functions and atomic enabled flag. This way we can use these when converting to use cpuidle for saving and restoring device context. And we need to maintain the driver state in the driver as documented in "9. Autosuspend, or automatically-delayed suspends" in the Documentation/power/runtime_pm.rst document related to using driver private lock and races with runtime_suspend(). Signed-off-by:
-
Lokesh Vutla authored
commit 341e8cba upstream. Use SPDX-License-Identifier instead of a verbose license text. Signed-off-by:
-
Peter Ujfalusi authored
SYSFW ABI 3.0 introduced non compatible changes in order to support SR2.0 of am654. Signed-off-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by:
Dave Gerlach <d-gerlach@ti.com>
-
Enable CONFIG_PWM_OMAP_DMTIMER Signed-off-by:
Vignesh Raghavendra <vigneshr@ti.com>
-
- Apr 21, 2020
-
-
Greg Kroah-Hartman authored
-
John Allen authored
commit bdf89df3 upstream. Future AMD CPUs will have microcode patches that exceed the default 4K patch size. Raise our limit. Signed-off-by:
John Allen <john.allen@amd.com> Signed-off-by:
Borislav Petkov <bp@suse.de> Cc: stable@vger.kernel.org # v4.14.. Link: https://lkml.kernel.org/r/20200409152931.GA685273@mojo.amd.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Maurizio Lombardi authored
[ Upstream commit 57c46e9f ] A number of hangs have been reported against the target driver; they are due to the fact that multiple threads may try to destroy the iscsi session at the same time. This may be reproduced for example when a "targetcli iscsi/iqn.../tpg1 disable" command is executed while a logout operation is underway. When this happens, two or more threads may end up sleeping and waiting for iscsit_close_connection() to execute "complete(session_wait_comp)". Only one of the threads will wake up and proceed to destroy the session structure, the remaining threads will hang forever. Note that if the blocked threads are somehow forced to wake up with complete_all(), they will try to free the same iscsi session structure destroyed by the first thread, causing double frees, memory corruptions etc... With this patch, the threads that want to destroy the iscsi session will increase the session refcount and will set the "session_close" flag to 1; then they wait for the driver to close the remaining active connections. When the last connection is closed, iscsit_close_connection() will wake up all the threads and will wait for the session's refcount to reach zero; when this happens, iscsit_close_connection() will destroy the session structure because no one is referencing it anymore. INFO: task targetcli:5971 blocked for more than 120 seconds. Tainted: P OE 4.15.0-72-generic #81~16.04.1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. targetcli D 0 5971 1 0x00000080 Call Trace: __schedule+0x3d6/0x8b0 ? vprintk_func+0x44/0xe0 schedule+0x36/0x80 schedule_timeout+0x1db/0x370 ? __dynamic_pr_debug+0x8a/0xb0 wait_for_completion+0xb4/0x140 ? wake_up_q+0x70/0x70 iscsit_free_session+0x13d/0x1a0 [iscsi_target_mod] iscsit_release_sessions_for_tpg+0x16b/0x1e0 [iscsi_target_mod] iscsit_tpg_disable_portal_group+0xca/0x1c0 [iscsi_target_mod] lio_target_tpg_enable_store+0x66/0xe0 [iscsi_target_mod] configfs_write_file+0xb9/0x120 __vfs_write+0x1b/0x40 vfs_write+0xb8/0x1b0 SyS_write+0x5c/0xe0 do_syscall_64+0x73/0x130 entry_SYSCALL_64_after_hwframe+0x3d/0xa2 Link: https://lore.kernel.org/r/20200313170656.9716-3-mlombard@redhat.com Reported-by:
Matt Coleman <mcoleman@datto.com> Tested-by:
Rahul Kundu <rahul.kundu@chelsio.com> Signed-off-by:
Maurizio Lombardi <mlombard@redhat.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Maurizio Lombardi authored
[ Upstream commit e49a7d99 ] iscsit_free_session() is equivalent to iscsit_stop_session() followed by a call to iscsit_close_session(). Link: https://lore.kernel.org/r/20200313170656.9716-2-mlombard@redhat.com Tested-by:
-
