| Age | Commit message (Collapse) | Author |
|---|
|
Update the tegra114 spi driver to support a live device tree.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Tested-on: Beaver, Jetson-TK1
Tested-by: Stephen Warren <swarren@nvidia.com>
|
|
Adjust this to take a device as a parameter instead of a node.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Tested-on: Beaver, Jetson-TK1
Tested-by: Stephen Warren <swarren@nvidia.com>
|
|
For devices that need a delay between SPI transactions we seem to need an
additional delay before the first one if the CPU is running at full speed.
Add this, under control of the existing setting. At present it will only
be enabled with the Chrome OS EC.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
These support the flat device tree. We want to use the dev_read_..()
prefix for functions that support both flat tree and live tree. So rename
the existing functions to avoid confusion.
In the end we will have:
1. dev_read_addr...() - works on devices, supports flat/live tree
2. devfdt_get_addr...() - current functions, flat tree only
3. of_get_address() etc. - new functions, live tree only
All drivers will be written to use 1. That function will in turn call
either 2 or 3 depending on whether the flat or live tree is in use.
Note this involves changing some dead code - the imx_lpi2c.c file.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
At present devices use a simple integer offset to record the device tree
node associated with the device. In preparation for supporting a live
device tree, which uses a node pointer instead, refactor existing code to
access this field through an inline function.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
In a number of places we had wordings of the GPL (or LGPL in a few
cases) license text that were split in such a way that it wasn't caught
previously. Convert all of these to the correct SPDX-License-Identifier
tag.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
Replace numeric mask hexcodes with GENMASK macro
in tegra*.c
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Tom Warren <twarren@nvidia.com>
Signed-off-by: Jagan Teki <jteki@openedev.com>
|
|
Replace numerical bit shift with BIT macro
in tegra*.c
:%s/(1 << nr)/BIT(nr)/g
where nr = 0, 1, 2 .... 31
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Tom Warren <twarren@nvidia.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Jagan Teki <jteki@openedev.com>
|
|
This is a convenient way for a driver to get the hardware address of a
device, when regmap or syscon are not being used. Change existing callers
to use it as an example to others.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Joe Hershberger <joe.hershberger@ni.com>
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
|
|
Use the oscillator as the source clock when we cannot achieve a low-enough
speed with the peripheral clock. This happens when we request 3MHz on a SPI
clock, for example.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
|
|
At present the driver does not properly honour the requested SPI CS
deactivation delay since the SPI bus is changed in the claim_bus() method.
Everything the claim_bus() method does can be done when the device is probed
(setting the speed and mode) and at the start of a new transfer (where the
fifo_status is already cleared). So drop this method.
Also, until the delay is complete, we should not touch the bus, so make sure
that spi_cs_activate() is called before other things are done in the xfer()
method.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
|
|
These methods should be passed a slave device, not a bus. This matches the
old SPI interface. It is important to know which device is claiming the bus
so passing a bus is not that useful.
Reported-by: Haikun Wang <haikun.wang@freescale.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Peng Fan <Peng.Fan@freescale.com>
Reviewed-by: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
|
|
This is common to all SPI drivers and specifies a structure used by the
uclass. It makes more sense to define it in the uclass.
Reviewed-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
This converts the Tegra SPI drivers to use driver model. This is tested
on:
- Tegra20 - trimslice
- Tegra30 - beaver
- Tegra124 - dalmore
(not tested on Tegra124)
Reviewed-by: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
The RDY bit indicates that a transfer is complete. This needs to be
cleared by SW before every single HW transaction, rather than only
at the start of each SW transaction (those being made up of n HW
transactions).
It seems that earlier HW may have cleared this bit autonomously when
starting a new transfer, and hence this code was not needed in practice.
However, this is generally a good idea in all cases. In Tegra124, the
HW behaviour appears to have changed, and SW must explicitly clear this
bit. Otherwise, SW will believe that transfers have completed when they
have not, and may e.g. read stale data from the RX FIFO.
Signed-off-by: Yen Lin <yelin@nvidia.com>
[swarren, rewrote commit description, unified duplicate RDY clearing code
and moved it right before the start of the HW transaction, unconditionally
exit loop after reading RX data, rather than checking if TX FIFO is empty,
since it is guaranteed to be]
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
|
|
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-by: Marek Vasut <marex@denx.de>
Reviewed-by: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
|
|
Add driver for tegra114 SPI controller. This controller is not
compatible with either the tegra20 or tegra30 controllers, so it
requires a new driver.
Signed-off-by: Allen Martin <amartin@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
|
