- Apr 27, 2020
-
-
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:
LCPD Auto Merger <lcpd_integration@list.ti.com>
-
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:
-
- 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
-
-
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 : ethernet: ti: am65-cpsw-qos: implement ethtool priv flag for IET ethernet: ti: am65-cpsw-qos: Add IET Frame preemption feature drm/tidss: fix crash related to accessing freed memory drm/tidss: Drop pointless static qualifier in dispc_find_csc() drm/tidss: fix spelling mistakes "bufer" and "requsted" drm/tidss: dispc: Fix broken plane positioning code Signed-off-by:
-
Vignesh Raghavendra authored
Merge branch 'lcpd-18155_fpe-v3' of ssh://bitbucket.itg.ti.com/~a0868495/ti-linux-kernel into connectivity-ti-linux-5.4.y
-
- Apr 20, 2020
-
-
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 : crypto: sa2ul: Fix Error handling for rx2 and tx DMA channels arm64: dts: ti: k3-j721e-mcu-wakeup: add k3 platforms chipid module node arm64: dts: ti: k3-am65-wakeup: add k3 platforms chipid module node arm64: arch_k3: enable chipid driver soc: ti: add k3 platforms chipid module driver dt-bindings: soc: ti: add binding for k3 platforms chipid module Signed-off-by:
-
Murali Karicheri authored
This patch introduce two priv flags to control IET Frame Preemption (FPE). iet-frame-preemption for IET FPE enable/disable and iet-mac-verify to enable/disable MAC Verify. Also add compatibility check to enable IET frame-preemption only if p0-rx-ptype-rrobin flag is off since IET requires priority queue handling in the driver. Also MAC Verify is allowed only if IET FPE is configured. Note that the interface is TBD and depends on LKML status. Signed-off-by:
Murali Karicheri <m-karicheri2@ti.com> Reviewed-by:
Grygorii Strashko <grygorii.strashko@ti.com>
-
Murali Karicheri authored
This patch adds support for Intersperse Express Traffic (IET, defined in P802.3br/D2.0 spec which later is included in IEEE 802.3 2018) Frame preemption (FPE) feature available in CPSW h/w. Also add MAC Verify to allow MAC layer to Verify if the peer supports IET MAC merge layer or not. MAC merge layer is responsible for preempting the transmission of frame from a preemptible queue if there is frame waiting for transmission at a higher priority Express queue. The h/w sends an initial segment of the frame satisfying min fragment size requirement and then schedule frame from the Express queue for transmission. Finally when no more frames available at the Express queue, it will resume transmission of remaining segments of the frame of the preemptible queue which was preempted. At the peer end, the segments are re-assembled and delivered to the MAC interface. IET FPE is configured for a port through ethtool --set-priv-flags command. Driver configures IET FPE for a port in ndo_open() if the fpe_configured flag is set. It schedules a worker to do the MAC/Verify process as soon as the Link is up and mac_verify_configured is set. It resets the LINKFAIL bit and check if the Verify succeeds or not. On failure, the MAC Verify state machine is reset and process repeats. As the peer comes up at different instances, it attempts multiple time until succeeds or times out. This patch moves am65_est_cmd_ns_to_cnt() function to the top of the file to re-use the same in the IET code as the Verify timeout configured in the IET register is in wired clocks. Also initializes IET in am65_cpsw_nuss_ndo_slave_open() and cleanup the same in am65_cpsw_nuss_ndo_slave_stop() Driver configures lower queues (Q0-QN-2, where N is the maximum number of queues configured) as preemptible queues by programming the PN_REG_IET_CTRL register if the MAC Verify succeeds or if the force mode is enabled (MAC Verify disabled through priv flag). Also configures the TX_RX_MAX_BLKS for IET in am65_cpsw_nuss_ndo_slave_open() if IET FPE is configured by user. Signed-off-by:
-
Peter Ujfalusi authored
In the unlikely event of channel request failure the code should check the failed channel against error code. Signed-off-by: -
Grygorii Strashko authored
Add DT node for the Texas Instruments K3 Multicore J721E SoC platforms chipid module. Signed-off-by:
-
Grygorii Strashko authored
Add DT node for the Texas Instruments K3 Multicore AM65x SoC platforms chipid module. Signed-off-by:
-
Grygorii Strashko authored
Select TI chip id driver for TI's SoCs based on K3 architecture to provide this information to user space and Kernel as it is required by other drivers to determine SoC revision to function properly. Signed-off-by:
-
Grygorii Strashko authored
The Texas Instruments K3 Multicore SoC platforms have chipid module which is represented by CTRLMMR_xxx_JTAGID register and contains information about SoC id and revision. Bits: 31-28 VARIANT Device variant 27-12 PARTNO Part number 11-1 MFG Indicates TI as manufacturer (0x17) 1 Always 1 This patch adds corresponding driver to identify the TI K3 SoC family and revision, and registers this information with the SoC bus. It is available under /sys/devices/soc0/ for user space, and can be checked, where needed, in Kernel using soc_device_match(). Identification is done by: - checking MFG to be TI ID - retrieving Device variant (revision) - retrieving Part number and convert it to the family - retrieving machine from DT "/model" Example J721E: # cat /sys/devices/soc0/{machine,family,revision} Texas Instruments K3 J721E SoC J721E SR1.0 Example AM65x: # cat /sys/devices/soc0/{machine,family,revision} Texas Instruments AM654 Base Board AM65X SR1.0 Signed-off-by: -
Grygorii Strashko authored
Add DT binding for Texas Instruments K3 Multicore SoC platforms chipid module which is represented by CTRLMMR_xxx_JTAGID register and contains information about SoC id and revision. Signed-off-by:
-
Tomi Valkeinen authored
tidss uses devm_kzalloc to allocate DRM plane, encoder and crtc objects. This is not correct as the lifetime of those objects should be longer than the underlying device's. When unloading tidss module, the devm_kzalloc'ed objects have already been freed when tidss_release() is called, and the driver will accesses freed memory possibly causing a crash, a kernel WARN, or other undefined behavior, and also KASAN will give a bug. Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
YueHaibing authored
commit 46cf7d98 upstream. There is no need to have the 'const struct dispc_csc_coef *coef' variable static since new value always be assigned before use it. Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Reviewed-by:
Jyri Sarha <jsarha@ti.com> Tested-by:
-
Colin Ian King authored
commit 652f67fd upstream. There are two spelling mistakes in warning and debug messages. Fix them. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Reviewed-by:
-
