| Age | Commit message (Collapse) | Author |
|---|
|
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: Swapnil Jakhade <sjakhade@cadence.com>
Signed-off-by: Dasnavis Sabiya <sabiya.d@ti.com>
Reviewed-by: Siddharth Vadapalli <s-vadapalli@ti.com>
|
|
TI commit 390df90762fb ("arm64: defconfig: Enable OX05B1S driver")
enabled OX05B1S driver as module.
Upstream-Status: Inappropriate [Configuration]
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
|
|
RC Release 09.02.00.008
|
|
In current configuration, wm8904 codec on Dahlia carrier board provides
distorted audio output. This happens due to reference clock is fixed to
25MHz and no FLL is enabled. During playback following parameters are set:
44100Hz:
[ 310.276924] wm8904 1-001a: Target BCLK is 1411200Hz
[ 310.276990] wm8904 1-001a: Using 25000000Hz MCLK
[ 310.277001] wm8904 1-001a: CLK_SYS is 12500000Hz
[ 310.277018] wm8904 1-001a: Selected CLK_SYS_RATIO of 256
[ 310.277026] wm8904 1-001a: Selected SAMPLE_RATE of 44100Hz
[ 310.277034] wm8904 1-001a: Selected BCLK_DIV of 80 for 1562500Hz BCLK
[ 310.277044] wm8904 1-001a: LRCLK_RATE is 35
Deviation = 1411200 vs 1562500 = 10.721%
Also, LRCLK_RATE is 35, should be 32.
48000Hz:
[ 302.449970] wm8904 1-001a: Target BCLK is 1536000Hz
[ 302.450037] wm8904 1-001a: Using 25000000Hz MCLK
[ 302.450049] wm8904 1-001a: CLK_SYS is 12500000Hz
[ 302.450065] wm8904 1-001a: Selected CLK_SYS_RATIO of 256
[ 302.450074] wm8904 1-001a: Selected SAMPLE_RATE of 48000Hz
[ 302.450083] wm8904 1-001a: Selected BCLK_DIV of 80 for 1562500Hz BCLK
[ 302.450092] wm8904 1-001a: LRCLK_RATE is 32
Deviation = 1536000 vs 1562500 = 1.725%
Enabling wm8904 FLL via providing mclk-fs property to simple-audio-card
configures clocks properly, but also adjusts audio reference clock
(mclk), which in case of TI AM62 should be avoided, as it only
supports 25MHz output [1][2].
This change enables FLL on wm8904 by providing mclk-fs, and drops
audio reference clock out of DAI configuration, which prevents
simple-audio-card to adjust it before every playback [3].
41000Hz:
[ 111.820533] wm8904 1-001a: FLL configured for 25000000Hz->11289600Hz
[ 111.820597] wm8904 1-001a: Clock source is 0 at 11289600Hz
[ 111.820651] wm8904 1-001a: Using 11289600Hz FLL clock
[ 111.820703] wm8904 1-001a: CLK_SYS is 11289600Hz
[ 111.820798] wm8904 1-001a: Target BCLK is 1411200Hz
[ 111.820847] wm8904 1-001a: Using 11289600Hz FLL clock
[ 111.820894] wm8904 1-001a: CLK_SYS is 11289600Hz
[ 111.820933] wm8904 1-001a: Selected CLK_SYS_RATIO of 256
[ 111.820971] wm8904 1-001a: Selected SAMPLE_RATE of 44100Hz
[ 111.821009] wm8904 1-001a: Selected BCLK_DIV of 80 for 1411200Hz BCLK
[ 111.821051] wm8904 1-001a: LRCLK_RATE is 32
48000Hz:
[ 144.119254] wm8904 1-001a: FLL configured for 25000000Hz->12288000Hz
[ 144.119309] wm8904 1-001a: Clock source is 0 at 12288000Hz
[ 144.119364] wm8904 1-001a: Using 12288000Hz FLL clock
[ 144.119413] wm8904 1-001a: CLK_SYS is 12288000Hz
[ 144.119512] wm8904 1-001a: Target BCLK is 1536000Hz
[ 144.119561] wm8904 1-001a: Using 12288000Hz FLL clock
[ 144.119608] wm8904 1-001a: CLK_SYS is 12288000Hz
[ 144.119646] wm8904 1-001a: Selected CLK_SYS_RATIO of 256
[ 144.119685] wm8904 1-001a: Selected SAMPLE_RATE of 48000Hz
[ 144.119723] wm8904 1-001a: Selected BCLK_DIV of 80 for 1536000Hz BCLK
[ 144.119764] wm8904 1-001a: LRCLK_RATE is 32
[1]: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1175479/processor-sdk-am62x-output-audio_ext_refclk0-as-mclk-for-codec-and-mcbsp/4444986#4444986
[2]: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1188051/am625-audio_ext_refclk1-clock-output---dts-support/4476322#4476322
[3]: sound/soc/generic/simple-card-utils.c#L441
Upstream-Status: Submitted [https://lore.kernel.org/all/20240315102500.18492-1-andrejs.cainikovs@gmail.com/]
Fixes: f5bf894c865b ("arm64: dts: ti: verdin-am62: dahlia: add sound card")
Suggested-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Andrejs Cainikovs <andrejs.cainikovs@toradex.com>
|
|
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: b1f66a5bee07 ("net: ethernet: ti: am65-cpsw-nuss: enable packet timestamping support")
Signed-off-by: Chintan Vankar <c-vankar@ti.com>
Reviewed-by: Ravi Gunasekaran <r-gunasekaran@ti.com>
|
|
Add OX05B1S device tree bindings.
Signed-off-by: Abhishek Sharma <abhishek.sharma@ti.com>
|
|
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 <abhishek.sharma@ti.com>
|
|
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 <abhishek.sharma@ti.com>
|
|
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 <abhishek.sharma@ti.com>
|
|
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: Abhishek Sharma <abhishek.sharma@ti.com>
|
|
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: Jayesh Choudhary <j-choudhary@ti.com>
|
|
RC Release 09.02.00.007
|
|
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>
|
|
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: Vaishnav Achath <vaishnav.a@ti.com>
Acked-by: Jai Luthra <j-luthra@ti.com>
Tested-by: Abhay Chirania <a-chirania@ti.com>
|
|
Fusion application board [1] can be used to connect multiple FPDLink-III
based sensors to TI EVMs. Upto 8x sensors can simultaneously stream
over the two CSI RX ports on J722S EVM.
Link: https://svtronics.com/portfolio/evm577pfusion-v1-0-fusion/ [1]
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>
|
|
Arducam's UC-A09 is a V3Link "mini" fusion board. [1]
It can be used to connect multiple V3Link (and FPD-III)
based cameras to TI EVMs using a single 22-pin FFC (4-lane)
CSI2 connector. Add an overlay to support it on J722S EVM.
[1] https://www.arducam.com/downloads/datasheet/Arducam_V3Link_Datasheet.pdf
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>
|
|
Arducam's UC-A09 is a V3Link "mini" fusion board. [1]
It can be used to connect multiple V3Link (and FPD-III)
based cameras to TI EVMs using a single 22-pin FFC (4-lane)
CSI2 connector. Add an overlay to support it on AM69 SK, Also while
at it fix the missing symbol export on k3-am69-sk-csi2-fpdlink-fusion overlay.
[1] https://www.arducam.com/downloads/datasheet/Arducam_V3Link_Datasheet.pdf
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>
|
|
Arducam's UC-A09 is a V3Link "mini" fusion board. [1]
It can be used to connect multiple V3Link (and FPD-III)
based cameras to TI EVMs using a single 22-pin FFC (4-lane)
CSI2 connector. Add an overlay to support it on AM68 SK,
Also while at it fix the missing symbol export on
k3-am68-sk-fpdlink-fusion overlay.
[1] https://www.arducam.com/downloads/datasheet/Arducam_V3Link_Datasheet.pdf
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>
|
|
Enable support to use Intel Wireless Next-Gen WiFi adapters for AM57x
platform.
Signed-off-by: Sinthu Raja <sinthu.raja@ti.com>
Reviewed-by: Udit Kumar <u-kumar1@ti.com>
|
|
Re-enable hardware on system resume before resuming the v4l2 m2m jobs so
that jobs that were queued prior to system suspend can be resumed back.
This helps support scenario to resume back from active use-case where
a jpeg encoding use-case was already running before system got
suspended.
Signed-off-by: Devarsh Thakkar <devarsht@ti.com>
|
|
Add the gpio hog for HDMI_LS_OE for HDMI ESD device TPD12S016PWR.
Without this signal pulled up, TPD12S016PWR is unable to pass through
the I2C request to HDMI connector which results in EDID not being read.
After that fallback mode 1024x768 and smaller resolutions are added
as valid modes.
Pull up the control pin HDMI_LS_OE to get EDID working.
Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
Reviewed-by: Udit Kumar <u-kumar1@ti.com>
|
|
Currently, mode_valid hook returns all mode as valid. Add the check
for the maximum and minimum pixel clock that the bridge can support
while validating a mode.
Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
Reviewed-by: Aradhya Bhatia <a-bhatia1@ti.com>
|
|
The VLAN table is a shared memory between the two ports/slices
in a ICSSG cluster and this may lead to race condition when the
common code paths for both ports are executed in different CPUs.
Fix the race condition access by locking the shared memory access.
Signed-off-by: Ravi Gunasekaran <r-gunasekaran@ti.com>
|
|
commit 4322af8c3aec ("net: hsr: Disable promiscuous mode in
offload mode") disables promiscuous mode of slave devices
while creating an HSR interface. But while deleting the
HSR interface, it does not take care of it. It decreases the
promiscuous mode count, which eventually enables promiscuous
mode on the slave devices when creating HSR interface again.
Fix this by not decrementing the promiscuous mode count while
deleting the HSR interface when offload is enabled.
Fixes: 4322af8c3aec ("net: hsr: Disable promiscuous mode in offload mode")
Signed-off-by: Ravi Gunasekaran <r-gunasekaran@ti.com>
|
|
In HSR mode, the netdev notifier does not take care of the unlinking
event of the upper net device. Fix this.
Signed-off-by: Ravi Gunasekaran <r-gunasekaran@ti.com>
|
|
Add support to offload HSR Tx Tag Insertion and Rx Tag Removal
and duplicate discard.
Support for offloading these features needs ICSSG HSR FW version
REL.HSR_1G_01.02.00.01.
Steps to offload to HSR Tx Tag Insertion and Rx Tag Removal.
-----------------------------------------------------------
Example assuming eth1, eth2 ports of ICSSG1 on AM64-EVM
1) Delete existing HSR interface
ip link delete hsr0
2) Bring down the interfaces
ip link set eth1 down
ip link set eth2 down
3) Configure both interfaces to have same MAC address
ip link set dev eth2 address <ETH1_MAC_ADDRESS>
4) Enable HSR offload for both interfaces
ethtool -K eth1 hsr-fwd-offload on
ethtool -K eth1 hsr-dup-offload on
ethtool -K eth1 hsr-tag-ins-offload on
ethtool -K eth1 hsr-tag-rm-offload on
ethtool -K eth2 hsr-fwd-offload on
ethtool -K eth2 hsr-dup-offload on
ethtool -K eth2 hsr-tag-ins-offload on
ethtool -K eth2 hsr-tag-rm-offload on
devlink dev param set platform/icssg1-eth \
name hsr_offload_mode \
value true cmode runtime
5) Bring up the interfaces
ip link set eth1 up
ip link set eth2 up
6) Create HSR interface and add slave interfaces to it
ip link add name hsr0 type hsr slave1 eth1 slave2 eth2 \
supervision 45 version 1
7) Add IP address to the HSR interface
ip addr add <IP_ADDR>/24 dev hsr0
8) Bring up the HSR interface
ip link set hsr0 up
Switching back to Dual EMAC mode:
---------------------------------
1) Delete HSR interface
ip link delete hsr0
2) Bring down the interfaces
ip link set eth1 down
ip link set eth2 down
3) Disable HSR port-to-port offloading mode, packet duplication
ethtool -K eth1 hsr-fwd-offload off
ethtool -K eth1 hsr-dup-offload off
ethtool -K eth1 hsr-tag-ins-offload off
ethtool -K eth1 hsr-tag-rm-offload off
ethtool -K eth2 hsr-fwd-offload off
ethtool -K eth2 hsr-dup-offload off
ethtool -K eth2 hsr-tag-ins-offload off
ethtool -K eth2 hsr-tag-rm-offload off
devlink dev param set platform/icssg1-eth \
name hsr_offload_mode \
value false cmode runtime
Note:
1) At the very least, hsr-fwd-offload must be enabled.
Without offloading the port-to-port offload, other
HSR offloads cannot be enabled.
2) Inorder to enable hsr-tag-ins-offload, hsr-dup-offload
must also be enabled as these are tightly coupled in
the firmware implementation.
Signed-off-by: Ravi Gunasekaran <r-gunasekaran@ti.com>
|
|
In order to fully to support all the HSR offload features at 1G,
more clock cycles are needed. So switch the ICSSG core clock from
250MHz to 333MHz.
This switch to 333MHz is applicable for all 3 modes - MAC mode,
Switch Mode and HSR Mode and improves performance as well.
Performance update in dual mac mode
With Core Clk @ 333MHz
Tx throughput - 934 Mbps
Rx throuhput - 914 Mbps,
With core clk @ 250MHz,
Tx throughput - 920 Mbps
Rx throughput - 706 Mbps
The improvement in performance is in alignment with the firmware
team's understanding that Rx budget cycle is tight at 250MHz.
Signed-off-by: Ravi Gunasekaran <r-gunasekaran@ti.com>
|
|
With the declarations of struct and enum related to IEP
present in .c file, it is not possible to access the structures
in other source code files. So move the declarations from
icss_iep.c to icss_iep.h.
IEP's def_inc is derived from the IEP reference clock.
Instead of using hard coded value, use the def_inc as
this is safer when changing the reference clock value.
Signed-off-by: Ravi Gunasekaran <r-gunasekaran@ti.com>
|
|
TI SDHCI IP has a hardware debounce timer of 1 second as described in
commit 7ca0f166f5b2 ("mmc: sdhci_am654: Add workaround for card detect
debounce timer"), because of this the boot time increases of up to 1
second.
Workaround the issue the same way that is done on
arch/arm64/boot/dts/ti/k3-am625-beagleplay.dts, using the SD1 CD as
GPIO.
Upstream-Status: Submitted [https://lore.kernel.org/all/20240312144956.40211-1-francesco@dolcini.it/]
Suggested-by: Nishanth Menon <nm@ti.com>
Reported-by: João Paulo Silva Gonçalves <joao.goncalves@toradex.com>
Closes: https://lore.kernel.org/all/0e81af80de3d55e72f79af83fa5db87f5c9938f8.camel@toradex.com/
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
|
|
main_pmx0 node in J722s inherits properties from same node in the am62p dt.
Interrupt was introduced[0] in am62p dt for IO daisy chain wake up. There
is no IP that needs this interrupt on am62p. However, J722s uses this
interrupt line for the IMG E5010 JPEG Encoder.
[0]: https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/commit/?&id=678ec1b76016
Signed-off-by: Brandon Brnich <b-brnich@ti.com>
Reviewed-by: Devarsh Thakkar <devarsht@ti.com>
|
|
Add support for IMG E5010 Stateful JPEG Encoder that supports
baseline encoding for semiplanar YUV420 and YUV422.
Signed-off-by: Brandon Brnich <b-brnich@ti.com>
Reviewed-by: Devarsh Thakkar <devarsht@ti.com>
|
|
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: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
|
|
During PHY calibration the return code of cqspi_find_rx_high() is not
assigned to 'ret'. So the check for failure will take the previous value
of 'ret', which will always be 0 since it was already checked by the
previous step. This means that the calibration procedure will always
think that rxhigh is found even when it is not. Fix this by assigning
the return value of cqspi_find_rx_high() to 'ret'.
Fixes: be58a6d2184f ("spi: cadence-qspi: Tune PHY to allow running at higher frequencies")
Reported-by: Brian Paiva <bpaiva@blackberry.com>
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
|
|
On Octal DTR capable flashes like Micron Xcella the writes cannot start
or end at an odd address in Octal DTR mode. Extra 0xff bytes need to be
appended or prepended to make sure the start address and end address are
even. 0xff is used because on NOR flashes a program operation can only
flip bits from 1 to 0, not the other way round. 0 to 1 flip needs to
happen via erases.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
|
|
On Octal DTR capable flashes like Micron Xcella reads cannot start or
end at an odd address in Octal DTR mode. Extra bytes need to be read at
the start or end to make sure both the start address and length remain
even.
To avoid allocating too much extra memory, thereby putting unnecessary
memory pressure on the system, the temporary buffer containing the extra
padding bytes is capped at PAGE_SIZE bytes. The rest of the 2-byte
aligned part should be read directly in the main buffer.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
|
|
For reads this small it does not make a lot of sense to go through DMA
which usually has a significant setup overhead. The benefits of DMA are
reaped in larger transfers. This is especially relevant in case a
register is being polled. The DMA overhead will make the polling slower
than it should be.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
|
|
In 8D-8D-8D mode an odd number of bytes cannot be read from the flash
since they would result in half a cycle being left over. memcpy_fromio()
makes no guarantees of access width size. On arm64 it is a mix of 1-byte
and 8-bytes accesses. On arm it is just 1-byte accesses.
memcpy_fromio() cannot be trusted when 8D-8D-8D reads are involved.
Instead, explicitly perfrom memcpy from the IO space for 8D-8D-8D ops by
making sure no odd-length accesses are performed. Since this controller
can be used on both arm and arm64 platforms, only 4-byte reads are used
to make sure the same code works on both platforms.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
|
|
cqspi_read_setup() and cqspi_write_setup() program the address width as
the last step in the setup. This is likely to be immediately followed by
a DAC region read/write. On TI K3 SoCs the DAC region is on a different
endpoint from the register region. This means that the order of the two
operations is not guaranteed, and they might be reordered at the
interconnect level. It is possible that the DAC read/write goes through
before the address width update goes through. In this situation if the
previous command used a different address width the OSPI command is sent
with the wrong number of address bytes, resulting in an invalid command
and undefined behavior.
Read back the size register to make sure the write gets flushed before
accessing the DAC region.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
|
|
cqspi_indirect_read_execute() and cqspi_indirect_write_execute() first
set the enable bit on APB region and then start reading/writing to the
AHB region. On TI K3 SoCs these regions lie on different endpoints. This
means that the order of the two operations is not guaranteed, and they
might be reordered at the interconnect level.
It is possible for the AHB write to be executed before the APB write to
enable the indirect controller, causing the transaction to be invalid
and the write erroring out. Read back the APB region write before
accessing the AHB region to make sure the write got flushed and the race
condition is eliminated.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
|
|
Drop unused macros "CPSW_RX_PSD_CSUM_ADD" and "CPSW_RX_PSD_IS_TCP" that
correspond to the fields defined in the RX DMA descriptor header.
Fixes: 9343810f28a1 ("net: ethernet: ti: Add CPSW Proxy Client driver")
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
|
|
The variable "response_status" in "cpsw_proxy_client_cb()" stores the
status of the response message received from EthFw. However the status
of the response is not checked in the "cpsw_proxy_client_cb()" function.
Rather, it is checked in the "cpsw_proxy_client_send_request()" function
which sends a request to EthFw and processes the response passed to it via
the "cpsw_proxy_client_cb()" callback function. Thus drop this unused
"response_status" variable in the callback function.
Fixes: 9343810f28a1 ("net: ethernet: ti: Add CPSW Proxy Client driver")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
|
|
In the "cpsw_proxy_client_detach()" function, the validity of the TX and RX
DMA Channels is supposed to be checked in order to notify EthFw that they
are being released and no longer used. However, the existing implementation
incorrectly validates the address of the "is_valid" member of the TX and RX
channel structures rather than its value. Fix this.
Fixes: 5f1b32f6bd1b ("net: ethernet: ti: cpsw-proxy-client: Switch to ATTACH Request")
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Francesco Dolcini <francesco@dolcini.it>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
|
|
Enable XCBC-MAC (Extended Cipher Block Chaining MAC) mode
to provide authentication mechanisms for IPsec Encapsulating
Security Payload (ESP) and the Authentication Header (AH)
protocols.
Signed-off-by: Sinthu Raja <sinthu.raja@ti.com>
|
|
Enable IPsec ESP (Encapsulating Security Payload) for encrypting
and authenticating IP packets, enable support for the XFRM (Transform)
user configuration interface similar to IPsec, as modules.
Signed-off-by: Sinthu Raja <sinthu.raja@ti.com>
|
|
wkup_uart0 is a reserved node that is used by Device Manager firmware.
Enabling pinctrl for CTS and RTS breaks the wakeup functionality of
wkup_uart0. Hence they have been dropped.
Signed-off-by: Vibhore Vardhan <vibhore@ti.com>
|
|
Similar to am62-wakeup, am62p-wakeup is capable of wakeup from
wkup_uart0. ti-sysc manages the sysconfig registers while
wkup_uart0 is only a portion of the register space.
See the link below for the upstream version of this patch for AM62.
Built and tested on AM62p5-sk board.
Link: https://lore.kernel.org/r/20231219072503.12427-1-tony@atomide.com
Signed-off-by: Vibhore Vardhan <vibhore@ti.com>
|
|
Move simplefb detection to a separate function and handle the node and
device de-referencing properly for failure scenarios.
Fixes: e59cbc4f912e ("HACK: drm: tidss: Soft reset dispc if simple-framebuffer is absent")
Signed-off-by: Devarsh Thakkar <devarsht@ti.com>
Reviewed-by: Aradhya Bhatia <a-bhatia1@ti.com>
|
|
Now that the characteriztion process is finalized for AM62p,
update the strobe delay: STRBSEL to 0x55 since this value is more
often in the middle of our passing region.
Signed-off-by: Judith Mendez <jm@ti.com>
|
|
TI commit cd94d748990c ("config: ti_arm64_prune.config: expand prune
list") disabled more unused network drivers.
Upstream commit db4677b35047 ("lib/Kconfig.debug: do not enable
DEBUG_PREEMPT by default") sets a new default.
Upstream commit b93aeb6352b0 ("net/sched: Retire rsvp classifier")
removed the Resource Reservation Protocol code.
Upstream-Status: Inappropriate [Configuration]
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
|
|
RC Release 09.02.00.006
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
Conflicts:
drivers/gpu/drm/bridge/lontium-lt8912b.c
drivers/gpu/drm/bridge/tc358768.c
drivers/usb/dwc3/dwc3-am62.c
|
