6.1.69-ti-rt-arm64-r28 bb.org_defconfig
TI SDK: 09.02.00.005
6.1 TI Delta: https://github.com/RobertCNelson/ti-linux-kernel/compare/78d2216bc679e98b7edb07ffabddb6d0337b5fcb...77aa27cbdca359bf0735b36ada464ec65b520943
BBDTBS: BeagleBoard-DeviceTrees@25306228
RT: patch-6.1.69-rt21.patch.xz
WIRELESS_REGDB: https://git.kernel.org/pub/scm/linux/kernel/git/sforshee/wireless-regdb.git/commit/?id=37dcea0e6e5effb4228fe385e906edba3cbee389
WPANUSB: beagleconnect/linux/wpanusb@6aa9bf65



Signed-off-by: Robert Nelson <robertcnelson@gmail.com>

Signed-off-by: Robert Nelson <robertcnelson@gmail.com>

Signed-off-by: Robert Nelson <robertcnelson@gmail.com>

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.

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.

Lets drive Sierra clock output and workaround a TIFS/DM bug for now.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>

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: Ayush Singh <ayushdevel1325@gmail.com>
Link: https://lore.kernel.org/r/20231017101116.178041-3-ayushdevel1325@gmail.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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: Ayush Singh <ayushdevel1325@gmail.com>
Reviewed-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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Reference: rpi-6.1.y
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>

Reference: v6.1.78
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>

Signed-off-by: Robert Nelson <robertcnelson@gmail.com>

"uio" for generic use
"ti,pruss-shmem" for backwards compatibility

the of_id module parameter is still supported to add another id

Reference: v5.10.209
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>

https://openbeagle.org/beagleboard/BeagleBoard-DeviceTrees/-/tree/v6.1.x-Beagle

BeagleBoard-DeviceTrees@25306228


Signed-off-by: Robert Nelson <robertcnelson@gmail.com>

https://git.kernel.org/pub/scm/linux/kernel/git/sforshee/wireless-regdb.git/commit/?id=37dcea0e6e5effb4228fe385e906edba3cbee389


Signed-off-by: Robert Nelson <robertcnelson@gmail.com>

patch-6.1.69-rt21.patch.xz

Signed-off-by: Robert Nelson <robertcnelson@gmail.com>

From
https://github.com/statropy/wpanusb

beagleconnect/linux/wpanusb@6aa9bf65


Signed-off-by: Robert Nelson <robertcnelson@gmail.com>

While STRB is currently used for DATA and CRC responses, the CMD
responses from the device to the host still require ITAPDLY for
HS400 timing.

Currently what is stored for HS400 is the ITAPDLY from High Speed
mode which is incorrect. The ITAPDLY for HS400 speed mode should
be the same as ITAPDLY as HS200 timing after tuning is executed.
Add the functionality to save ITAPDLY from HS200 tuning and save
as HS400 ITAPDLY.

Fixes: a161c45f

 ("mmc: sdhci_am654: Enable DLL only for some speed modes")
Signed-off-by: Judith Mendez <jm@ti.com>

The sdhci_am654_set_clock function is also used to enable
delay chain, therefore fix comment to be more generic in
case we are not enabling the DLL.

Fix comment in sdhci_j721e_4bit_set_clock function, since
DLL is not enabled in this function. Add comment for input
tap delay while we are at it.

Fixes: fe52e2fb

 ("mmc: sdhci_am654: Fix conditions for enabling dll")

Signed-off-by: Judith Mendez <jm@ti.com>

While integer type works, the otap_del_sel and itap_del_sel
arrays are manipulated as u32, so change array types to u32.

Fixes: 8ee5fc0e ("mmc: sdhci_am654: Update OTAPDLY writes")
Fixes: a0a62497

 ("mmc: sdhci_am654: Add support for input tap delay")
Signed-off-by: Judith Mendez <jm@ti.com>

Currently the OTAP/ITAP delay enable functionality is missing in
the am654_set_clock function which is used for MMC0 on AM62p
and AM64x devices. The OTAP delay is not enabled when timing <
SDR25 bus speed mode. The ITAP delay is not enabled for all bus
speed modes.

Add this OTAP/ITAP delay functionality according to the datasheet
[1] OTAPDLYENA and ITAPDLYENA for MMC0.

[1] https://www.ti.com/lit/ds/symlink/am62p.pdf

Fixes: 8ee5fc0e

 ("mmc: sdhci_am654: Update OTAPDLY writes")
Signed-off-by: Judith Mendez <jm@ti.com>

For DDR52 timing, DLL is enabled but tuning is not carried
out, therefore the ITAPDLY value in PHY CTRL 4 register is
not correct. Fix this by writing ITAPDLY after enabling DLL.

Fixes: a161c45f

 ("mmc: sdhci_am654: Enable DLL only for some speed modes")
Signed-off-by: Judith Mendez <jm@ti.com>

Currently the sdhci_am654 driver only supports one tuning
algorithm which should be used only when DLL is enabled. The
ITAPDLY is selected from the largest passing window and the
buffer is viewed as a circular buffer.

The new algorithm should be used when the delay chain
is enabled. The ITAPDLY is selected from the largest passing
window and the buffer is not viewed as a circular buffer.

This implementation is based off of the following paper: [0].

Also add support for multiple failing windows.

[0] https://www.ti.com/lit/an/spract9/spract9.pdf

Fixes: 13ebeae6

 ("mmc: sdhci_am654: Add support for software tuning")
Signed-off-by: Judith Mendez <jm@ti.com>

Move bus-width property to *main.dtsi, above the OTAP/ITAP
delay values. While there is no error with where it is
currently at, it is easier to read the MMC node if the
bus-width property is located above the OTAP/ITAP delay
values consistently across MMC nodes.

Add missing bus-width for sdhci2 in k3-am62-main.

Signed-off-by: Judith Mendez <jm@ti.com>

Move ti,clkbuf-sel property above the OTAP/ITAP delay values.
While there is no error with where it is currently at, it is
easier to read the MMC node if ti,clkbuf-sel is located above
the OTAP/ITAP delay values consistently across MMC nodes.

Add missing ti,clkbuf-sel for MMC0 in k3-am64-main.

Signed-off-by: Judith Mendez <jm@ti.com>

Remove DLL properties which are not applicable for soft PHYs
since these PHYs do not have a DLL to enable.

Signed-off-by: Judith Mendez <jm@ti.com>

Update MMC OTAP/ITAP values according to the datasheet
[0], refer to Table 7-79 for MMC0.

[0] https://www.ti.com/lit/ds/symlink/am62p.pdf



Signed-off-by: Judith Mendez <jm@ti.com>

Add sdhci2 DT node in k3-am62a-main for mmc2. Add otap/itap
values according to the datasheet[0], Refer to Table 7-97.

[0] https://www.ti.com/lit/ds/symlink/am62a3.pdf



Signed-off-by: Judith Mendez <jm@ti.com>

Add OmniVision OV1063x driver as a module.

Signed-off-by: Sukrut Bellary <sbellary@baylibre.com>

Add ov10635 camera support for am57xx-evm.

Signed-off-by: Sukrut Bellary <sbellary@baylibre.com>

Add new V4L2 subdev based driver for OV10633 and OV10635 sensors.
This is based on the original patch posted at
http://www.spinics.net/lists/linux-media/msg64347.html



Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Signed-off-by: Sukrut Bellary <sbellary@baylibre.com>

Device Tree bindings for the OmniVision OV1063x sensor driver.

Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Sukrut Bellary <sbellary@baylibre.com>

Add Video Input Port(VIP) driver for AM57x platforms as a module.

Signed-off-by: Sukrut Bellary <sbellary@baylibre.com>

VIP stands for Video Input Port; it can be found on devices such as
DRA7xx and provides a parallel interface to a video source such as
a sensor or TV decoder.  Each VIP can support two inputs (slices) and
an SoC can be configured with a variable number of VIPs.
Each slice ican support two ports, each connected to it's own
sub-device.

Signed-off-by: Sukrut Bellary <sbellary@baylibre.com>

The DRA74xx/AM57xx has three Video Input Ports (VIP) i.e., VIP1, VIP2,
and VIP3.
Add VIP2 port node which has 2 slices VIN3 and VIN4.

Signed-off-by: Sukrut Bellary <sbellary@baylibre.com>

Device Tree bindings for the Video Input Port (VIP) driver.

Signed-off-by: Sukrut Bellary <sbellary@baylibre.com>