https://git.kernel.org/pub/scm/linux/kernel/git/wens/wireless-regdb.git/commit/?id=bf55ed481432cbd91e05b54c5f7bccd687c69bb7


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

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: Robert Nelson <robertcnelson@gmail.com>

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

beagleconnect/linux/wpanusb@6aa9bf65


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

Add bootloader-backdoor-gpios which is required for enabling bootloader
backdoor for flashing firmware to cc1352p7.

Also fix the incorrect reset-gpio.

Signed-off-by: Ayush Singh <ayush@beagleboard.org>

bootloader-backdoor-gpio (along with reset-gpio) is used to enable
bootloader backdoor for flashing new firmware.

The pin and pin level to enable bootloader backdoor is configured using
the following CCFG variables in cc1352p7:
- SET_CCFG_BL_CONFIG_BL_PIN_NO
- SET_CCFG_BL_CONFIG_BL_LEVEL

Acked-by: Conor Dooley <conor.dooley@microchip.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Ayush Singh <ayush@beagleboard.org>

BeagleBoard.org BeagleY-AI is an easy to use, affordable open source
hardware single board computer based on the Texas Instruments AM67A,
which features a quad-core 64-bit Arm CPU subsystem, 2 general-purpose
digital-signal-processors (DSP) and matrix-multiply-accelerators (MMA),
GPU, vision and deep learning accelerators, and multiple Arm Cortex-R5
cores for low-power, low-latency GPIO control.

https://beagley-ai.org/
https://openbeagle.org/beagley-ai/beagley-ai



Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
Reviewed-by: Roger Quadros <rogerq@kernel.org>
Reviewed-by: Jared McArthur <j-mcarthur@ti.com>
Link: https://lore.kernel.org/r/20240829213929.48540-2-robertcnelson@gmail.com


Signed-off-by: Nishanth Menon <nm@ti.com>

This board is based on ti,j722s family using the am67a variation.

https://beagley-ai.org/
https://openbeagle.org/beagley-ai/beagley-ai



Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
Reviewed-by: Jared McArthur <j-mcarthur@ti.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20240829213929.48540-1-robertcnelson@gmail.com


Signed-off-by: Nishanth Menon <nm@ti.com>

There is a HW errata for 10M issues which is present on AM65x but not on
AM64x. The workaround for this errata is to enable IEP1. Since both
AM64x and AM65x shares the same ICSSG firmware, firmware is expecting
IEP1 to be enabled for both AM64x and AM65x. As a result 10M Link fails
on AM64x.

Enable the quirk_10m_link_issue so that IEP1 can be enabled for AM64x

Signed-off-by: MD Danish Anwar <danishanwar@ti.com>
Reviewed-by: Daolin Qiu <d-qiu@ti.com>

PHY is tuned with optimal tuning point which allows controller to
run at higher speeds. Hence, increase the data writes' throughput in
OSPI/QSPI NAND flashes by enabling PHY for data writes to the NAND
flash devices.

The aim is to enable PHY only for the OSPI/QSPI NAND data writes,
so, exclude other operations like register writes to NAND flashes,
register and data writes to NOR flashes by introducing a check for
the 'n_tx' (op->data.nbytes) value before enabling.

Currently, OSPI/QSPI NOR's highest page size is 512 bytes, so, check
whether 'n_tx' is greater than or equal to 1024.

Signed-off-by: Santhosh Kumar K <s-k6@ti.com>

Utilising PHY is limited to read operation, but, PHY can be enabled
for data writes, register reads and/or writes in future. Hence, move
the cqspi_phy_enable() and cqspi_readdata_capture() functions above
all the read and write operations.

Signed-off-by: Santhosh Kumar K <s-k6@ti.com>

Multiple mailbox users can share one interrupt line. This flag was
mistakenly dropped as part of the FIFO removal. Mark the IRQ as shared.

Reported-by: Beleswar Padhi <b-padhi@ti.com>
Fixes: 3f58c1f4 ("mailbox: omap: Remove kernel FIFO message queuing")
Signed-off-by: Andrew Davis <afd@ti.com>
Tested-by: Beleswar Padhi <b-padhi@ti.com>
Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>

The kernel FIFO queue has a couple issues. The biggest issue is that
it causes extra latency in a path that can be used in real-time tasks,
such as communication with real-time remote processors.

The whole FIFO idea itself looks to be a leftover from before the
unified mailbox framework. The current mailbox framework expects
mbox_chan_received_data() to be called with data immediately as it
arrives. Remove the FIFO and pass the messages to the mailbox
framework directly as part of a threaded IRQ handler.

Signed-off-by: Andrew Davis <afd@ti.com>
Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>

It is much more clear to check if the hardware FIFO is full and return
EBUSY if true. This allows us to also remove one level of indention
from the core of this function. It also makes the similarities between
omap_mbox_chan_send_noirq() and omap_mbox_chan_send() more obvious.

Signed-off-by: Andrew Davis <afd@ti.com>
Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>

This function only checks if mbox_chan *chan is not NULL, but that cannot
be the case and if it was returning NULL which is not later checked
doesn't save us from this. The second check for chan->con_priv is
completely redundant as if it was NULL we would return NULL just the
same. Simply dereference con_priv directly and remove this function.

Signed-off-by: Andrew Davis <afd@ti.com>
Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>

The driver stores a list of omap_mbox structs so it can later use it to
lookup the mailbox names in of_xlate. This same information is already
available in the mbox_controller passed into of_xlate. Simply use that
data and remove the extra allocation and storage of the omap_mbox list.

Signed-off-by: Andrew Davis <afd@ti.com>
Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>

The mbox_controller struct is only needed in the probe function. Make
it a local variable instead of storing a copy in omap_mbox_device
to simplify that struct.

Signed-off-by: Andrew Davis <afd@ti.com>
Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>

Currently the driver loops through all mailbox child nodes twice, once
to read in data from each node, and again to make use of this data.
Instead read the data and make use of it in one pass. This removes
the need for several temporary data structures and reduces the
complexity of this main loop in probe.

Signed-off-by: Andrew Davis <afd@ti.com>
Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>

Use device life-cycle managed runtime enable function to simplify probe
and exit paths.

Signed-off-by: Andrew Davis <afd@ti.com>
Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>

The driver currently creates a new device class "mbox". Then for each
mailbox adds a device to that class. This class provides no file
operations provided for any userspace users of this device class.
It may have been extended to be functional in our vendor tree at
some point, but that is not the case anymore, nor does it matter
for the upstream tree.

Remove this device class and related functions and variables.
This also allows us to switch to module_platform_driver() as
there is nothing left to do in module_init().

Signed-off-by: Andrew Davis <afd@ti.com>
Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>

The type of message sent using omap-mailbox is always u32. The definition
of mbox_msg_t is uintptr_t which is wrong as that type changes based on
the architecture (32bit vs 64bit). This type should have been defined as
u32. Instead of making that change here, simply remove the header usage
and fix the last couple users of the same in this driver.

Signed-off-by: Andrew Davis <afd@ti.com>
Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>

The mbox_kfifo_size can be changed at runtime, the sanity
check on it's value should be done when it is used, not
only once at init time.

Signed-off-by: Andrew Davis <afd@ti.com>
Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>

This is only used internal to the driver, move it out of the
public header and into the driver file. While we are here,
this is not used as a bitwise, so drop that and make it a
simple enum type.

Signed-off-by: Andrew Davis <afd@ti.com>
Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>

This function is not used, remove this function.

Signed-off-by: Andrew Davis <afd@ti.com>
Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>

These function are not used, remove these here.

While here, remove the leading _ from the driver internal functions that
do the same thing as the functions removed.

Signed-off-by: Andrew Davis <afd@ti.com>
Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.

To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>

While these accounting features are useful, they fall more into
debugging a system rather than production ready features. Disable page
statistics features that have real-time latency impacts.

Signed-off-by: Bryan Brattlof <bb@ti.com>

There are 2 mux-controller nodes in J7200 which are responsible for
transferring can signals to the can phy but same node names for both
the mux-controllers led to errors while setting up both can phys
simultaneously. Thus, update node names for these mux-controller.

Fixes: 4d71b914 ("arm64: dts: ti: k3-j7200-som-p0: Add support for CAN instance 0 in main domain")
Signed-off-by: Bhavya Kapoor <b-kapoor@ti.com>

There are 2 mux-controller nodes in J721S2 which are responsible for
transferring can signals to the can phy but same node names for both
the mux-controllers led to errors while setting up both can phys
simultaneously. Thus, update node names for these mux-controller.

Fixes: 98f3b667 ("arm64: dts: ti: k3-j721s2: Add support for CAN instances 3 and 5 in main domain")
Signed-off-by: Bhavya Kapoor <b-kapoor@ti.com>

Protect dmabuf attach list access with mutex

Signed-off-by: Rahul T R <r-ravikumar@ti.com>
Acked-by: Andrew Davis <afd@ti.com>

The remoteproc firmware like of R5F and DSPs in the MAIN voltage domain
use timers. Therefore, change the status of the timer nodes to
"reserved" to avoid any clash. Usage is described as below:

	+===================+=============+
	|  Remoteproc Node  | Timer Node  |
	+===================+=============+
	| mcu_r5fss0_core0  | mcu_timer0  |
	+-------------------+-------------+
	| main_r5fss0_core0 | main_timer0 |
	+-------------------+-------------+
	| c7x_0             | main_timer1 |
	+-------------------+-------------+
	| c7x_1             | main_timer2 |
	+-------------------+-------------+

This change is already incorporated for timer nodes in the MCU voltage
domain with commit 3308a31c ("arm64: dts: ti: k3-am62: Add general
purpose timers for am62").

Signed-off-by: Beleswar Padhi <b-padhi@ti.com>

With PHY being tuned at a optimal tuning point, set the controller
frequency to operate at higher frequency possible and set the SPI
bus frequency to 25 MHz and respective read-delay.

Signed-off-by: Santhosh Kumar K <s-k6@ti.com>

With PHY being tuned at a optimal tuning point, set the controller
frequency to operate at higher frequency possible and set the SPI
bus frequency to 25 MHz and respective read-delay.

Signed-off-by: Santhosh Kumar K <s-k6@ti.com>

Change the dummy clock cycles for octalio_op from 16 to 20, so that,
the reads can run at higher frequencies.

Signed-off-by: Santhosh Kumar K <s-k6@ti.com>

Post initialisation of a NAND flash device, some require a unique
set of configuration to run at optimal speeds/functionality.

In W25N01JW, HS bit needs to be set in Status Register 4 to run at
higher frequencies.

In W35N01JW, IO Mode and Dummy Clocks needs to be set correctly in
Volatile Configuration Register according to the mode and frequency.

So, add a late_init function to carry out these operations.

Signed-off-by: Santhosh Kumar K <s-k6@ti.com>

Add support for Winbond QSPI NAND flash by adding it's spinand ID,
memory organisation, ECC information, operation variants and so on
into the spinand_info structure.

Signed-off-by: Santhosh Kumar K <s-k6@ti.com>

Add the PHY calibration call during SPI NAND probe, so that, the PHY
is tuned with the optimal tuning point which enables controller to
run at higher speeds.

Load the known pattern to page buffer, and pass a page read op with
the do_calibration call.

Signed-off-by: Santhosh Kumar K <s-k6@ti.com>
Tested-by: Prasanth Babu Mantena <p-mantena@ti.com>

Enable SPI_TX_QUAD in spi_controller->mode_bits to add support for
the 1S-4S-4S operations.

Signed-off-by: Santhosh Kumar K <s-k6@ti.com>
Tested-by: Prasanth Babu Mantena <p-mantena@ti.com>

With SDR mode, the controller can only process at 1/4th of the ref
clock without PHY. So, add a SDR based tuning algorithm to enable
higher speed operations. Flash a known pattern to the last block of
the flash device, which will be later used to read back and compare.

Iterate through read_delay from 0 to 4, find first tuning point by
setting tx = 127. Find difference between rxlow and rxhigh and store
it in window1. Find second tuning point with read_delay incremented
by 1 and similarly calculate window2.

Compare window1 and window2 to finalise the optimal tuning point. Write
the final tuning point into PHY configuration register.

Signed-off-by: Santhosh Kumar K <s-k6@ti.com>
Tested-by: Prasanth Babu Mantena <p-mantena@ti.com>

Few times, core 1 was scheduled to boot first before core0.
Which leads to error
'k3_r5_rproc_start: can not start core 1 before core 0'.

This was happening due to some scheduling between prepare
and start callback. The probe function waits for event,
which is getting triggered by prepare callback.

To avoid above condition move even trigger to start instead
of prepare callback.

Fixes: 7dcf3e00 ("remoteproc: k3-r5: Wait for core0 power-up before powering up core1")
Cc: Rahul Ravikumar <r-ravikumar@ti.com>
Cc: Hari Nagalla <hnagalla@ti.com>
Signed-off-by: Udit Kumar <u-kumar1@ti.com>
Reviewed-by: Beleswar Padhi <b-padhi@ti.com>