- Jul 08, 2024
-
-
Robert Nelson authored
6.6.32-ti-arm32-r7 bb.org_defconfig TI SDK: 10.00.05 6.6 TI Delta: https://github.com/RobertCNelson/ti-linux-kernel/compare/4bd0d44f69cbda913ca7fcb809ae0fa682416b14...dd0c137e219ab179c10ecb067bdf67a268004e14 BBDTBS: BeagleBoard-DeviceTrees@7844bd3a WIRELESS_REGDB: https://git.kernel.org/pub/scm/linux/kernel/git/wens/wireless-regdb.git/commit/?id=4838054744fdceb694637ad55bad8516714729c2 WPANUSB: beagleconnect/linux/wpanusb@6aa9bf65 Signed-off-by:
Robert Nelson <robertcnelson@gmail.com>
-
Robert Nelson authored
-
Robert Nelson authored
Signed-off-by: -
Robert Nelson authored
Signed-off-by: -
-
Ben Hutchings authored
We want to enable use of the Android ashmem and binder drivers to support Anbox, but they should not be built-in as that would waste resources and increase security attack surface on systems that don't need them. Export the currently un-exported symbols they depend on.
-
Ben Hutchings authored
We want to enable use of the Android ashmem and binder drivers to support Anbox, but they should not be built-in as that would waste resources and increase security attack surface on systems that don't need them. - Add a MODULE_LICENSE declaration to ashmem - Change the Makefiles to build each driver as an object with the "_linux" suffix (which is what Anbox expects) - Change config symbol types to tristate Update: In upstream commit 721412ed titled "staging: remove ashmem" the ashmem driver was removed entirely. Secondary commit message: "The mainline replacement for ashmem is memfd, so remove the legacy code from drivers/staging/" Consequently, the ashmem part of this patch has been removed.
-
Jason Kridner authored -
Matthijs van Duin authored
"uio" for generic use "ti,pruss-shmem" for backwards compatibility the of_id module parameter is still supported to add another id
-
Matthijs van Duin authored
-
Robert Nelson authored
Reference: Signed-off-by: -
-
-
Robert Nelson authored
ieee802154_xmit_hw_error() is the right helper to call when a transmission has failed for a non-determined (and probably not IEEE802.15.4 specific) reason. Let's use this helper instead of open-coding it. Based on: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v6.5-rc1&id=35f34ee102a5b2376f4b4700ac017b8f2770e754 Signed-off-by:
-
Jason Kridner authored
From https://github.com/statropy/wpanusb
-
-
- Jul 04, 2024
-
-
Vignesh Raghavendra authored
Enclose system suspend hooks under CONFIG_SUSPEND to fix build errors with ti_rt.config which disables this config option. Fixes: ca11e100 ("pmdomain: ti_sci: add per-device latency constraint management") Signed-off-by:
Vignesh Raghavendra <vigneshr@ti.com>
-
Guillaume La Roque authored
When we build with android build fail on : error: variable 'mask' is used uninitialized whenever 'if' condition is false To fix this initialize mask variable. Fixes: 93022077f0f5 ("TI: drm/tidss: Add OLDI bridge support") Change-Id: If2ae28b61fe6c0e15bb7a27f2098ed1dd6c2c2e4 Signed-off-by:Guillaume La Roque <glaroque@baylibre.com> Reviewed-by:
Aradhya Bhatia <a-bhatia1@ti.com>
-
- Jul 03, 2024
-
-
Devarsh Thakkar authored
Mark RTOS framebuffer region as the reserved region so that Linux doesn't map it. This region is used by DSS sharing firmware based device manager on AM62P. Signed-off-by:Devarsh Thakkar <devarsht@ti.com>
-
Devarsh Thakkar authored
The AM62P DSS0 node lists separate power-domains for OLDI, which need to be held up too during bootup by simple-framebuffer to facilitate flicker-free transition by keeping the display (which was pre-initialized by bootloader) alive during bootup so that it keep displaying the splash-screen or boot animation until weston comes up. Signed-off-by:
-
Devarsh Thakkar authored
Some devices such as AM62P [1] may have multiple power domains to power up the display. So during driver probe, power up all attached PM domains enumerated in devicetree node. Link: https://www.ti.com/lit/ug/spruiv7a/spruiv7a.pdf [1] Signed-off-by:
-
Devarsh Thakkar authored
Fix error paths for display initialization to de-initialize the OLDI and power off the display related domains for failure scenarios. Fixes: 554d9d19 ("drm/tidss: Initialize OLDI after dispc_init") Signed-off-by:
-
Devarsh Thakkar authored
Display subsystem present in TI Keystone family of devices supports sharing of display between multiple hosts as it provides separate register space (common* region) for each host to programming display controller and also a unique interrupt line for each host. This adds support for display sharing, by allowing partitioning of resources either at video port level or at video plane level as described below : 1) Linux can own (i.e have write access) completely one or more of video ports along with corresponding resources (viz. overlay managers, video planes) used by Linux in context of those video ports. Even if Linux is owning these video ports it can still share this video port with a remote core which can own one or more video planes associated with this video port. 2) Linux owns one or more of the video planes with video port (along with corresponding overlay manager) associated with these planes being owned and controlled by a remote core. Linux still has read-only access to the associated video port and overlay managers so that it can parse the settings made by remote core. For both the cases, the resources used in context of processing core running Linux along with ownership information are exposed by user as part of device-tree blob and driver uses an updated feature list tailored for this shared mode accordingly. The driver also auto-populates matching overlay managers and output types from shared video port list provided in device-tree blob. In dispc_feature struct remove const access specfier for output_type array as it is required to be updated dynamically in run-time for shared mode. For 2) where Linux is only owning a set of video planes with corresponding video port and overlay manager controlled by a remote core, separate set of CRTC callbacks are used which just latch on to the preset mode set by remote core, thus avoiding any reconfiguration of associated video ports, overlay managers and clocks. For this case, it is also checked that Linux controlled video planes don't exceed screen size set by remote core while running the display. Display clocks and OLDI related fields are also not populated for this scenario as remote core is owning those resources. For 1), where Linux owns only a set of video port and associated planes with rest of resources owned completely by remote cores, only those set of resources are exposed to Linux and programmed using traditional CRTC helpers and rest of video ports and associated resources are removed from feature list accordingly. Signed-off-by: -
Devarsh Thakkar authored
This overlay needs to be used with display sharing supported device manager firmware named as : ti-dm/am62pxx/dss_display_share.wkup-r5f0_0.release.strip.out Remote core running this firmware has write access to "common" register space, VIDL pipeline, OVR1 overlay and VP1 videoport. The processing core running Linux is provided write access to VID pipeline and "common1" register space. The VP1 video port is shared between Linux and remote core with remote core configuring the overlay manager to set Zorder 1 for VID pipeline and Zorder 2 for VIDL pipeline. Signed-off-by: -
Devarsh Thakkar authored
Add support for using TI Keystone DSS hardware present in display sharing mode. TI Keystone DSS hardware supports partitioning of resources between multiple hosts as it provides separate register space and unique interrupt line to each host. The DSS hardware can be used in shared mode in such a way that one or more of video planes can be owned by Linux wherease other planes can be owned by remote cores. One or more of the video ports can be dedicated exclusively to a processing core, wherease some of the video ports can be shared between two hosts too with only one of them having write access. Signed-off-by: -
Devarsh Thakkar authored
De-initialize OLDI before tidss module remove as otherwise the OLDI context is not cleaned up properly and we see below crash on module reload [ 40.732608] Unable to handle kernel paging request at virtual address ffff800079695768 [1251/99286] [ 40.971398] Call trace: [ 40.973835] drm_bridge_attach+0x70/0x198 [drm] [ 40.978507] tidss_bridge_attach+0x20/0x2c [tidss] [ 40.983306] drm_bridge_attach+0x80/0x198 [drm] [ 40.987957] tidss_encoder_create+0x70/0x154 [tidss] [ 40.992924] tidss_dispc_modeset_init.constprop.0+0x220/0x3b4 [tidss] [ 40.999363] tidss_modeset_init+0x70/0xa8 [tidss] [ 41.004070] tidss_probe+0x1e4/0x3ac [tidss] [ 41.008343] platform_probe+0x68/0xc4 [ 41.012001] really_probe+0x148/0x2ac [ 41.015653] __driver_probe_device+0x78/0x12c [ 41.019998] driver_probe_device+0xd8/0x15c [ 41.024169] __driver_attach+0x94/0x19c [ 41.027993] bus_for_each_dev+0x78/0xd4 [ 41.031821] driver_attach+0x24/0x30 Fixes: f4fe7a54 ("drm/tidss: Add OLDI bridge support") Suggested-by:
-
Santhosh Kumar K authored
nor->params->addr_mode_nbytes defines the number of address bytes to send for the current address mode. During a switch to DTR mode, or back, the addr_mode_nbytes should be updated accordingly. So, update nor->params->addr_mode_nbytes during dtr enable and disable. Signed-off-by:
Santhosh Kumar K <s-k6@ti.com> Acked-by:
Prasanth Babu Mantena <p-mantena@ti.com>
-
Kevin Hilman authored
Add support for resume latency constraint control. Default constraint is "no constraint", but control of this constraint is exposed to userspace via the PM QoS sysfs API. The sysfs control is named pm_qos_resume_latency_us and is under the devices power directory. For example, for one of the R5 remoteproc cores, doing this: $ cd /sys/devices/platform/bus@f0000/bus@f0000:bus@4000000/bus@f0000:bus@4000000:r5fss@79000000/power $ echo 100 > pm_qos_resume_latency_us will set a 100 usec resume latency constraint for the R5 MCU. Signed-off-by:Kevin Hilman <khilman@baylibre.com>
-
Kevin Hilman authored
During system-wide suspend, check all devices connected to PM domain to see if they are wakeup-enabled. If so, set a TI SCI device constraint. Note: DM firmware clears all constraints on resume. Co-developed-by:
Vibhore Vardhan <vibhore@ti.com> Signed-off-by:
Dhruva Gole <d-gole@ti.com>
-
Kevin Hilman authored
For each device in a TI SCI PM domain, check whether the device has any resume latency constraints set via per-device PM QoS. If constraints are set, send them to DM via the new SCI constraints API. Checking for constraints happen: 1) before SCI PM domain power off (->power_off() hook) 2) before system-wide suspend (via ->suspend() hook) For TI SCI devices that are runtime PM enabled, check (1) will be the primary method, and will happen when the TI SCI PM domain is powered off (e.g. when the runtime PM usecount of the last device in that domain goes to zero.) For devices that are either not runtime PM enabled, or are not yet runtime suspended (e.g. due to being used during the suspend path), the constraints check will happen by check(2). Since constraints can be sent by either (1) or (2), driver keeps track of whether a valid constraint has been sent already. Note: DM firmware clears constraints during its resume, so Linux has to check/update/send constraints each time system suspends. Co-developed-by:
-
Kevin Hilman authored
During system-wide suspend, check if any of the CPUs have PM QoS resume latency constraints set. If so, set TI SCI constraint. TI SCI has a single system-wide latency constraint, so use the max of any of the CPU latencies as the system-wide value. Note: DM firmware clears all constraints at resume time, so constraints need to be checked/updated/sent at each system suspend. Co-developed-by:
-
Kevin Hilman authored
DM firmware now manages which low power mode is chosen. Going forward, this is the default state supported by Linux. The state chosen by DM can be influenced by sending constraints using the new constraints APIs. In case the firmware does not support DM_MANAGED mode, check if any Suspend-to-RAM mode is supported? If none, return without taking any action. Suggested-by:
-
Vibhore Vardhan authored
Introduce the Low Power Mode constraint ops supported by the TISCI Low Power Mode API [1]. 1) TISCI_MSG_LPM_SET_DEVICE_CONSTRAINT Set LPM constraint on behalf of a device. By setting a constraint, the device ensures that it will not be powered off or reset in the selected mode. 2) TISCI_MSG_LPM_SET_LATENCY_CONSTRAINT Set LPM resume latency constraint. By setting a constraint, the host ensures that the resume time from selected mode will be less than the constraint value. These new APIs are only available via pm_ops after checking if the DM_MANAGED flag is set in fw_ccaps. [1] https://software-dl.ti.com/tisci/esd/latest/2_tisci_msgs/pm/lpm.html Co-developed-by:
Akashdeep Kaur <a-kaur@ti.com> Signed-off-by:
-
Hari Nagalla authored
Upon a stop request, K3-M4 remote proc driver sends a RP_MBOX_SHUTDOWN mailbox message to the remote R5 core. The remote core is expected to: - relinquish all the resources acquired through Device Manager (DM) - disable its interrupts - send back a mailbox acknowledgment RP_MBOX_SHUDOWN_ACK - enter WFI state. Meanwhile, the K3-M4 remote proc driver does: - wait for the RP_MBOX_SHUTDOWN_ACK from the remote core - wait for the remote proc to enter WFI state - reset the remote core through device manager Signed-off-by:Hari Nagalla <hnagalla@ti.com>
-
Hari Nagalla authored
Upon a stop request, K3-dsp remote proc driver sends a RP_MBOX_SHUTDOWN mailbox message to the remote dsp core. The remote core is expected to: - relinquish all the resources acquired through Device Manager (DM) - disable its interrupts - send back a mailbox acknowledgment RP_MBOX_SHUDOWN_ACK - enter WFI state. Meanwhile, the K3-dsp remote proc driver does: - wait for the RP_MBOX_SHUTDOWN_ACK from the remote core - wait for the remote proc to enter WFI state - reset the remote core through device manager Signed-off-by: -
Hari Nagalla authored
Upon a stop request, K3-R5 remote proc driver sends a RP_MBOX_SHUTDOWN mailbox message to the remote R5 core. The remote core is expected to: - relinquish all the resources acquired through Device Manager (DM) - disable its interrupts - send back a mailbox acknowledgment RP_MBOX_SHUDOWN_ACK - enter WFI state. Meanwhile, the K3-R5 remote proc driver does: - wait for the RP_MBOX_SHUTDOWN_ACK from the remote core - wait for the remote proc to enter WFI state - reset the remote core through device manager Signed-off-by: -
Hari Nagalla authored
Two mailbox messages are added to facilitate handshake between the remote processors to ensure graceful stop of the remote processors. Signed-off-by:
-
- Jul 02, 2024
-
-
Rahul T R authored
k3-r5fs can address 48 bit using RAT Signed-off-by:
Rahul T R <r-ravikumar@ti.com> Reviewed-by:
Andrew Davis <afd@ti.com>
-
Rahul T R authored
c6x DSP can address 48 bit using RAT and c7x has 48 bit address bus Signed-off-by:
-
Vignesh Raghavendra authored
As per errata id i2285 of AM64x Errata doc [1] BCDMA can only be used when data source and DMA descriptor source is on the same endpoint. In case of OSPI mem to mem DMA read, descriptor is in DDR while source data is in OSPI which may trigger above errata leading to read data corruption on AM64x SR1.0 devices. Therefore disable OSPI DMA on such SoCs. Subsequent SR versions are not affected. [1] https://www.ti.com/lit/er/sprz457e/sprz457e.pdf Signed-off-by:
Apurva Nandan <a-nandan@ti.com> Signed-off-by:
-
