With the new dev_read functions available, we can convert the rockchip
architecture-specific drivers and common drivers used by these devices
over to the dev_read family of calls.

This change covers the rk_spi.c (SPI driver) used in Rockchip devices.
Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: NSimon 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: NSimon Glass <sjg@chromium.org>

The existing Rockchip SPI (rk_spi.c) driver also matches the hardware
block found in the RK3399.  This has been confirmed both with SPI NOR
flashes and general SPI transfers on the RK3399-Q7 for SPI1 and SPI5.

This change adds the 'rockchip,rk3399-spi' string to its compatible
list to allow reuse of the existing driver.

X-AffectedPlatforms: RK3399-Q7
Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
Tested-by: NJakob Unterwurzacher <jakob.unterwurzacher@theobroma-systems.com>
Acked-by: NSimon Glass <sjg@chromium.org>

The baudrate in rkspi was calculated by using an integer division
(which implicitly discarded any fractional result), then rounding to
an even number and finally clamping to 0xfffe using a bitwise AND
operator.  This introduced two issues:
1) for very small baudrates (overflowing the 0xfffe range), the
   bitwise-AND generates rather random-looking (wildly varying)
   actual output bitrates
2) for higher baudrates, the calculation tends to 'err towards a
   higher baudrate' with the actual error increasing as the dividers
   become very small. E.g., with a 99MHz input clock, a request
   for a 20MBit baudrate (99/20 = 4.95), a 24.75 MBit would be use
   (which amounts to a 23.75% error)... for a 34 MBit request this
   would be an actual outbout of 49.5 Mbit (i.e. a 45% error).

This change rewrites the divider selection (i.e. baudrate calculation)
by making sure that
a) for the normal case: the largest representable baudrate below the
   requested rate will be chosen;
b) for the denormal case (i.e. when the divider can no longer be
   represented), the lowest representable baudrate is chosen.

Even though the denormal case (b) may be of little concern in real
world applications (even with a 198MHz input clock, this will only
happen at below approx. 3kHz/3kBit), our board-verification team kept
complaining.
Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
Tested-by: NKlaus Goger <klaus.goger@theobroma-systems.com>

The original clock/bitrate selection code for the rk_spi driver was a
bit limited, as it always selected a 99MHz input clock rate (which
would allow for a maximum bitrate of 49.5MBit/s), but returned -EINVAL
if a bitrate higher than 48MHz was requested.

To give us better control over the bitrate (i.e. add more operating
points, especially at "higher" bitrate---such as above 9MBit/s), we
try to choose 4x the maximum frequency (clamped to 50MBit) from the
DTS instead of 99MHz... for most use-cases this will yield a frequency
of 198MHz, but is flexible to go beyond this in future configurations.

This also rewrites the check to allow frequencies of up to half the
SPI module rate as bitrates and then clamps to whatever the DTS allows
as a maximum (board-specific) frequency and does away with the -EINVAL
when trying to select a bitrate (for cases that exceeded the hard
limit) and instead consistently clamps to the lower of the hard limit,
the soft limit for the SPI bus (from the DTS) or the soft limit for
the SPI slave device.

This replaces
  "rockchip: spi: rk_spi: select 198MHz input to the SPI module for the RK3399"
  "rockchip: spi: rk_spi: improve clocking code for the RK3399"
from earlier versions of this series.
Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>

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: NSimon Glass <sjg@chromium.org>

This is not currently implemented. Add support for this so that the Chrome
OS EC can be used on jerry.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Allow this driver to be used with of-platdata on rk3288.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Now, arch/${ARCH}/include/asm/errno.h and include/linux/errno.h have
the same content.  (both just wrap <asm-generic/errno.h>)

Replace all include directives for <asm/errno.h> with <linux/errno.h>.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
[trini: Fixup include/clk.]
Signed-off-by: NTom Rini <trini@konsulko.com>

The following changes are made to the clock API:
* The concept of "clocks" and "peripheral clocks" are unified; each clock
  provider now implements a single set of clocks. This provides a simpler
  conceptual interface to clients, and better aligns with device tree
  clock bindings.
* Clocks are now identified with a single "struct clk", rather than
  requiring clients to store the clock provider device and clock identity
  values separately. For simple clock consumers, this isolates clients
  from internal details of the clock API.
* clk.h is split so it only contains the client/consumer API, whereas
  clk-uclass.h contains the provider API. This aligns with the recently
  added reset and mailbox APIs.
* clk_ops .of_xlate(), .request(), and .free() are added so providers
  can customize these operations if needed. This also aligns with the
  recently added reset and mailbox APIs.
* clk_disable() is added.
* All users of the current clock APIs are updated.
* Sandbox clock tests are updated to exercise clock lookup via DT, and
  clock enable/disable.
* rkclk_get_clk() is removed and replaced with standard APIs.

Buildman shows no clock-related errors for any board for which buildman
can download a toolchain.

test/py passes for sandbox (which invokes the dm clk test amongst
others).
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NSimon Glass <sjg@chromium.org>

The correct pinctrl is handled automatically so we don't need to do it in
the driver. The exception is when we want to use a different chip select
(other than 0). But this isn't used at present.
Signed-off-by: NSimon Glass <sjg@chromium.org>

At present there is an incorrect call to rkspi_enable_chip(). It should
be disabling the chip, not enabling it. Correct this and ensure that the
chip is disabled when releasing the bus.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Some devices need delays before and after activiation. Implement these
features in the SPI driver so that we will be able to enable the Chrome
OS EC.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Two of the init values are created locally so cannot be out of range.
The masking is unnecessary and in one case is incorrect. Fix it.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Rather than changing the clock to the same value on every transaction,
remember the last value and don't adjust the clock unless it is necessary.
Signed-off-by: NSimon Glass <sjg@chromium.org>

If full pinctrl is enabled we don't need to manually set the pinctrl in the
driver. It will happen automatically. Adjust the code to suit - we will
still use manual mode in SPL.
Signed-off-by: NSimon Glass <sjg@chromium.org>

We can use the new clk_get_by_index() function to get the correct clock.
Signed-off-by: NSimon Glass <sjg@chromium.org>

We need to use %lx not %x to describe a fdt_addr_t

Cc: Simon Glass <sjg@chromium.org>
Signed-off-by: NTom Rini <trini@konsulko.com>

Add a SPI driver for the Rockchip RK3288, using driver model. It should work
for other Rockchip SoCs also.
Signed-off-by: NSimon Glass <sjg@chromium.org>