- Mar 21, 2024
-
-
Robert Nelson authored
6.1.80-ti-arm64-r34 bb.org_defconfig TI SDK: 09.02.00.009 6.1 TI Delta: https://github.com/RobertCNelson/ti-linux-kernel/compare/1c154b1fe4c462d8b383515bb388e289816e4b01...2e423244f8c09173a344e7069f0fe2bdf26cccee BBDTBS: beagleboard/BeagleBoard-DeviceTrees@042278e8 WIRELESS_REGDB: https://git.kernel.org/pub/scm/linux/kernel/git/wens/wireless-regdb.git/commit/?id=454130065a5857bc0c534d5c52ed17a97b704c36 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: -
Jared McArthur authored
-
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.
-
Ayush Singh authoredSigned-off-by:Ayush Singh <ayushdevel1325@gmail.com>
-
Vaishnav Achath authored
add of_find_serdev_controller_by_node to obtain a serdev_controller from the device_node, which can help if the serdev_device is not described over device tree and instantiation of the device happens from a different driver, for the same purpose an option to not delete an empty serdev controller is added. Signed-off-by:
Vaishnav M A <vaishnav@beagleboard.org> Signed-off-by:
-
Ayush Singh authored
This externalizes and exports the symbol of_find_spi_controller_by_node() from the SPI core akin to how of_find_i2c_adapter_by_node() is already available. As we will need this also for non-dynamic OF setups, we move it under a CONFIG_OF check. Signed-off-by: -
Ayush Singh authored
Signed-off-by: -
Ayush Singh authored
Signed-off-by: -
Kishon Vijay Abraham I authored
Lets drive Sierra clock output and workaround a TIFS/DM bug for now. Signed-off-by:Kishon Vijay Abraham I <kishon@ti.com>
-
Jason Kridner authored -
Ayush Singh authored
Add the Greybus host driver for BeaglePlay board by BeagleBoard.org. The current greybus setup involves running SVC in a user-space application (GBridge) and using netlink to communicate with kernel space. GBridge itself uses wpanusb kernel driver, so the greybus messages travel from kernel space (gb_netlink) to user-space (GBridge) and then back to kernel space (wpanusb) before reaching CC1352. This driver directly communicates with CC1352 (running SVC Zephyr application). Thus, it simplifies the complete greybus setup eliminating user-space GBridge. This driver is responsible for the following: - Start SVC (CC1352) on driver load. - Send/Receive Greybus messages to/from CC1352 using HDLC over UART. - Print Logs from CC1352. - Stop SVC (CC1352) on driver load. Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Ayush Singh authored
Add DT bindings for Texas Instruments Simplelink CC1352P7 wireless MCU BeaglePlay has CC1352P7 co-processor connected to the main AM62 (running Linux) over UART. In the BeagleConnect Technology, CC1352 is responsible for handling 6LoWPAN communication with beagleconnect freedom nodes as well as their discovery. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by:
Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20231017101116.178041-2-ayushdevel1325@gmail.com Signed-off-by:
-
Robert Nelson authored
Reference: rpi-6.1.y Signed-off-by: -
Robert Nelson authored
Signed-off-by: -
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: v5.10.213 Signed-off-by: -
-
-
Jason Kridner authored
From https://github.com/statropy/wpanusb
-
-
- Mar 20, 2024
-
-
MD Danish Anwar authored
The driver drops RX frames due to flags not being cleared during XDP buffer init. XDP framework provides helper APIs to initialize and prepare XDP buffer. Fix the RX frame drops by calling these helper APIs. Fixes: 78264a12 ("net: ethernet: ti: icssg_prueth: Add AF_XDP support") Signed-off-by:
MD Danish Anwar <danishanwar@ti.com> Reviewed-by:
Ravi Gunasekaran <r-gunasekaran@ti.com>
-
Sukrut Bellary authored
Enable I2C5 node for OV10635 camera EVM so that it can standalone work with the am57xx-beagle-x15.dtb. Signed-off-by:Sukrut Bellary <sbellary@baylibre.com>
-
Jayesh Choudhary authored
Add missing 'cdns,max-bit-rate' property for mhdp phy. If not specified, the default value taken is 8100 Mbps which often leads to phy link training errors like "CR: max swing reached" and eventually falls back to 1620 Mbps which limits the maximum supported resolution to 1920x1200 which is way less than what hardware can actually support theoretically i.e. 4K. Adding 2700 (as a HACK) instead of 5400 like other platforms as the latter causes CRTC SYNC LOST issue for 3840x2160@60fps resolution. So limiting the phy-rate for max resolution of 3840x2160@30fps as it is better to have a stable low fps than flaky high fps. The HACK can be removed when 4K@60fps is stable. Signed-off-by:Jayesh Choudhary <j-choudhary@ti.com>
-
- Mar 19, 2024
-
-
Dasnavis Sabiya authored
AM69-SK has a 2 Lane PCIe M.2 Key M PCIe instance (PCIe1) and a 1 Lane PCIe M.2 Key E PCIe instance (PCIe3), both of which are interfaced via a shared Serdes instance namely Serdes0. Update the Serdes0 link to enable Multilink PCIe configuration. Signed-off-by:
Dasnavis Sabiya <sabiya.d@ti.com> Reviewed-by:
Siddharth Vadapalli <s-vadapalli@ti.com>
-
Dasnavis Sabiya authored
From: Swapnil Jakhade <sjakhade@cadence.com> Add register sequences for PCIe multilink + USB configuration for 100MHz reference clock. The same SSC is used for both PCIe and USB. Signed-off-by:
Swapnil Jakhade <sjakhade@cadence.com> Signed-off-by:
-
Dasnavis Sabiya authored
From: Swapnil Jakhade <sjakhade@cadence.com> Add register sequences to support multi link PCIe configuration for 100MHz refclk. Maximum two PCIe links are supported. Signed-off-by:
-
- Mar 14, 2024
-
-
Chintan Vankar authored
The CPSW Ethernet Switch on TI's K3 SoCs supports two mechanisms to timestamp packets received on external ports. The first mechanism which is currently enabled by the am65-cpsw-nuss driver is that of timestamping all received packets by setting the "TSTAMP_EN" bit in the CPTS_CONTROL register, which directs the CPTS module to timestamp all received packets, followed by passing the timestamps via the DMA descriptors. This mechanism is responsible for triggering errata i2401: "CPSW: Host Timestamps Cause CPSW Port to Lock up" The workaround is to use the second mechanism for timestamping received packets. The second mechanism utilizes the CPTS Event FIFO that records timestamps corresponding to certain events, with one such event being the reception of an Ethernet packet with the EtherType field set to Precision Time Protocol (PTP). Hence, switch to the second mechanism to address the errata. The errata affects all K3 SoCs. Link to errata for AM64x: https://www.ti.com/lit/er/sprz457h/sprz457h.pdf Fixes: b1f66a5b ("net: ethernet: ti: am65-cpsw-nuss: enable packet timestamping support") Signed-off-by:
Chintan Vankar <c-vankar@ti.com> Reviewed-by:
-
Abhishek Sharma authored
Add OX05B1S device tree bindings. Signed-off-by:Abhishek Sharma <abhishek.sharma@ti.com>
-
Abhishek Sharma authored
OX05B1S is a raw (4x4 RGB-IR bayer) sensor. The LI-OX05B1S-MIPI-137H module [1] uses a LI-FPC22-IPEX-PI [2] adapter cable for connection with CSI port on the board. [1] Link: https://www.mouser.com/ProductDetail/Leopard-Imaging/ LI-OX05B1S-MIPI-137H?qs=VJzv269c%252BPbBVMoFtZszhQ%3D%3D [2] Link: https://www.leopardimaging.com/product/nvidia-jetson-cameras/ nvidia-jetson-orin-nx-camera-kit/li-fpc22-ipex-pi/ Signed-off-by:
-
Abhishek Sharma authored
As of now, only AM62A supports the OX05B1S sensor. The sensor module can be connected to a single CSI port on AM62A. Enable the driver for OX05B1S. Signed-off-by: -
Abhishek Sharma authored
OmniVision OX05B1S is an RGB-IR sensor, i.e. it uses a 4x4 R,G,B,Ir bayer pattern to capture both visible and near-infrared light. Every alternate frame, the sensor changes the exposure and the analogue/digital gain registers to stream an - A. IR-dominant frame on CSI-2 virtual channel 0 B. RGB-dominant frame on CSI-2 virtual channel 1 Both of these streams are captured at a resolution of 2592x1944, 30 fps each (60fps total). This driver also supports a few v4l2 controls like exposure and gain controls. The RGB dominant stream uses the normal v4l2 control identifiers (CIDs) for exposure and gain change while custom CIDs have been defined for the IR dominant stream. Signed-off-by: -
Abhishek Sharma authored
The OX05B1S camera sensor supports both RGB and IR stream exposure/gain controls. The sensor has one source pad which gives out 2 streams: IR dominant (stream 0) and RGB dominant stream (stream 1). When programming the exposure/gain settings for the camera from a user space application like V4L2 user space API, we are unable to specify the stream for which the exposure/gain change is required. Hence, we have defined 3 custom control IDs for IR channel exposure, anologue and digital gain control. These custom controls added for IR channel are not an upstream acceptable solution and a better solution is required in the V4L2 framework for exposure/gain control in multistream sensors to remove this HACK. Signed-off-by: -
Tomi Valkeinen authored
J721E common processor board can be interfaced with the infotainment expansion board[0] to enable the following audio/video interfaces in addition to the peripherals provided by the common processor board: - Two Audio codecs each with three Stereo Inputs and four Stereo Outputs - Audio input over FPD Link III - Digital Audio Interface TX/RX - HDMI/FPD LINK III Display out - LI/OV Camera input Add support for TFP410 HDMI bridge located on the Infotainment Expansion Board (connected to J46 & J51). Add a HDMI connector node and connect the endpoints as below: DSS => TFP410 bridge => HDMI connector Also add the pinmux data and board muxes for DPI. Rest of the peripherals are missing as of now. [0]: <https://www.ti.com/lit/ug/spruit0a/spruit0a.pdf> Link: <https://git.ti.com/cgit/ti-linux-kernel/ti-upstream-tools/commit/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board-infotainment.dtso?id=da742e7e0043555c6705ea75dcda55c1d29a0520 > Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> [j-choudhary@ti.com: minor cleanup] Signed-off-by:
-
- Mar 13, 2024
-
-
Vaishnav Achath authored
IMX390 is a 2.1MP raw (bayer) sensor, the rugged camera module by D3 [1] packages it with an FPDLink-III serializer (DS90UB953) for use with sensor fusion setups using FPDLink-III deserializer boards. Add overlays for the cases when the modules are connected to ports on the DS90UB960 deserializer in fusion EVM when connected to third CSI port in a device like J784S4 or AM69. This helps to enable 12 camera use cases on AM69 SK. 1 - https://www.d3engineering.co/product/designcore-d3rcm-imx390-953-rugged-camera-module/ Signed-off-by:
Vaishnav Achath <vaishnav.a@ti.com> Acked-by:
Jai Luthra <j-luthra@ti.com> Tested-by:
Abhay Chirania <a-chirania@ti.com>
-
Vaishnav Achath authored
Fusion application board [1] can be used to connect multiple FPDLink-III based sensors to TI EVMs. Upto 12x sensors can simultaneously stream over the three CSI RX ports on J784S4/AM69, add an overlay to support the fusion board connected to CSI port 2(CSI_AUX port) on AM69 SK to enable 12 camera applications with AM69 SK. Link: https://svtronics.com/portfolio/evm577pfusion-v1-0-fusion/ [1] Signed-off-by:
-
