TI-SCI firmware will only respond to messages when the
TI_SCI_FLAG_REQ_ACK_ON_PROCESSED flag is set. Most messages
already do this, set this for the ones that do not.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Tested-by: Alejandro Hernandez <ajhernandez@ti.com>
Acked-by: Nishanth Menon <nm@ti.com>
Restart operation never exists and reset operation never
makes the watchdog expire immediately but expire_now operation
does.
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Upcoming sysfw (2019.03) will not open the channelized firewalls during
init, it only going to do so in response to the channel configuration
message.
Remove the channel state checks done before the channel configuration and
move it after the configuration for warning purposes.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
An earlier commit converted the TISCI receive timeouts to be specified
in ms rather than us however it failed to take this change into account
when passing the actual timeout to be used when invoking the mailbox
receive API. This leads to the actual timeout to be 1,000 times shorter
than expected and as a result certain TISCI operations would fail.
Fix the issue by converting the timeout declared in ms to us on the fly
as expected by the respective API.
Fixes: fd6b40b1ba ("firmware: ti_sci: Add support for NAVSS resource management")
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Currently packet data is wrongly extracted when metadata is NULL.
Fix it and negate the if check.
Signed-off-by: Keerthy <j-keerthy@ti.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
The twsi_wait function reads the control register for interrupt flag,
and if interrupt flag is present, it immediately reads status register.
On our device this sometimes causes bad value being read from status
register, as if the value was not yet updated.
My theory is that the controller does approximately this:
1. sets interrupt flag in control register,
2. sets the value of status register,
3. causes an interrupt
In U-Boot we do not use interrupts, so I think that it is possible that
sometimes the status register in the twsi_wait function is read between
points 1 and 2.
The bug does not appear if I add a small delay before reading status
register.
Wait 100ns (which in U-Boot currently means 1 us, because ndelay(i)
function calls udelay(DIV_ROUND_UP(i, 1000))) before reading the status
register.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Stefan Roese <sr@denx.de>
Cc: Mario Six <mario.six@gdsys.cc>
Cc: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Stefan Roese <sr@denx.de>
------------------------
- warp7 to DM
- kp_imx53 to DM
- Warnings in DT
- MX8QM support
- colibri-imx6ull to DM
- imx7d-pico to DM
- ocotp for MX8
-----BEGIN PGP SIGNATURE-----
iQHDBAABCgAtFiEEiZClFGvhzbUNsmAvKMTY0yrV63cFAlzDBtoPHHNiYWJpY0Bk
ZW54LmRlAAoJECjE2NMq1et3UpQL/ipaUejQOOr00oOgUBQqt3JCPZ7KNu8ruih/
nIFUDrI8nP+4psaOhRp1sEPFJUxUjdIqODeAZD8zrlEi1pXNAgPWYrFRfbz54bzw
jLsqqMz1/djQseLydQTcqZTSz8Ys7o+8OfKH64fdsZn+y9no9tHBN5hz5qWdXexN
kbyykkg8TJC3eUyRZqKuULOqzDV9BAdASOXu7UTa04sEekLdVvS2+zkUdB6UVZTN
LOAzm+7xY8Tey1BZxLuZUJDpHzFEMvPvlbbQRrxeDn/feZJwNgIP6hGcMeVOwOIf
KEwFn/m/HI2JWS4taXb5aT+v3xmiQvyCC3jNW0XTf5rq02pbfgyPsVhGQIGyU2yY
Fj7zIN7hVCLJNBpctvXyuAd1MjOlGEPIrHNjRnIZjtr7/iA1AIRn7Hg4cGNCHw6V
5gdza3B/xFODN+Ts6O+UVIukI61MJ6mGGdNCueOnWDviNROOL82D7Jh02KfNNNxR
q+yPsHSpo6rC1MGXv4SOReZtgpng/w==
=CzWQ
-----END PGP SIGNATURE-----
Merge tag 'u-boot-imx-20190426' of git://git.denx.de/u-boot-imx
Porting to DM and i.MX8
------------------------
- warp7 to DM
- kp_imx53 to DM
- Warnings in DT
- MX8QM support
- colibri-imx6ull to DM
- imx7d-pico to DM
- ocotp for MX8
Rockchip use 'arch-rockchip' instead of arch-$(SOC) as common
header file path, so that we can get the correct path directly.
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
To support unaligned output buffers (i.e. 'in' in the terminology of
the SPI framework), this change splits each 16bit FIFO element after
reading and writes them to memory in two 8bit transactions. With this
change, we can now always use the optimised mode for receive-only
transcations independent on the alignment of the target buffer.
Given that we'll run with caches on, the impact should be negligible:
as expected, this has no adverse impact on throughput if running with
a 960MHz LPLL configuration.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
The SPI controller's documentation (I only had access to the RK3399,
RK3368 and PX30 TRMs) specifies that, when operating in master-mode,
the controller will stop the SCLK to avoid RXFIFO overruns and TXFIFO
underruns. Looks like my worries that we'd need to support DMA-330
(aka PL330) to make any further progress were unfounded.
This adds a driver-data structure to capture hardware-specific
settings of individual controller instances (after all, we don't know
if all versions are well-behaved) and adds a 'master_manages_fifo'
flag to it. The first use of said flag is in the optimised
receive-only transfer-handler, which can now request 64Kframe
(i.e. 128KByte) bursts of data on each reprogramming of CTRLR1
(i.e. every time through the loop).
This improves throughput to 46.85MBit/s (a 94.65% bus-utilisation).
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
For the RK3399-Q7 we recommend storing SPL and u-boot.itb in the
on-module 32MBit (and sometimes even larger, if requested as part of a
configure-to-order configuration) SPI-NOR flash that is clocked for a
bitrate of 49.5MBit/s and connected in a single-IO configuration (the
RK3399 only supports single-IO for SPI).
Unfortunately, the existing SPI driver is excruciatingly slow at
reading out large chunks of data (in fact it is just as slow for small
chunks of data, but the overheads of the driver-framework make it less
noticeable): before this change, the throughput on a 4MB read from
SPI-NOR is 8.47MBit/s which equates a 17.11% bus-utilisation.
To improve on this, this commit adds an optimised receive-only
transfer (i.e.: out == NULL) handler that hooks into the main transfer
function and processes data in 16bit frames (utilising the full with
of each FIFO element). As of now, the receive-only handler requires
the in-buffer to be 16bit aligned. Any lingering data (i.e. either if
the in-buffer was not 16-bit aligned or if an odd number of bytes are
to be received) will be handled by the original 8bit reader/wirter.
Given that the SPI controller's documentation does not guarantuee any
interlocking between the RXFIFO and the master SCLK, the transfer loop
will be restarted for each chunk of 32 frames (i.e. 64 bytes).
With this new receive-only transfer handler, the throughput for a 4MB
read increases to 36.28MBit/s (i.e. 73.29% bus-utilisation): this is a
4x improvement over the baseline.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reported-by: Klaus Goger <klaus.goger@theobroma-systems.com>
Series-Cc: Klaus Goger <klaus.goger@theobroma-systems.com>
Series-Cc: Christoph Muellner <christoph.muellner@theobroma-systems.com>
The logic in the main transmit loop took a bit of reading the TRM to
fully understand (due to silent assumptions based in internal logic):
the "wait until idle" at the end of each iteration through the loop is
required for the transmit-path as each clearing of the ENA register
(to update run-length in the CTRLR1 register) will implicitly flush
the FIFOs... transmisson can therefore not overlap loop iterations.
This change adds a comment to clarify the reason/need for waiting
until the controller becomes idle and wraps the entire check into an
'if (out)' to make it clear that this is required for transfers with a
transmit-component only (for transfers having a receive-component,
completion of the transmit-side is trivially ensured by having
received the correct number of bytes).
The change does not increase execution time measurably in any of my
tests.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
While rkspi_enable_chip is called with true/false everywhere else in
the file, one call site uses '0' to denot 'false'.
This change this one parameter to 'false' and effects consistency.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
The maximum transfer length (in a single transaction) for the Rockchip
SPI controller is 64Kframes (i.e. 0x10000 frames) of 8bit or 16bit
frames and is encoded as (num_frames - 1) in CTRLR1. The existing
code subtracted the "minus 1" twice for a maximum transfer length of
0xffff (64K - 1) frames.
While this is not strictly an error (the existing code is correct, but
leads to a bit of head-scrating), fix this off-by-one situation.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Even though the priv-structure and the claim-bus function contain
logic for 16bit frames and for unidirectional transfer modes, neither
of these is used anywhere in the driver.
This removes the unused (as in "has no effect") logic and fields.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
In analysing delays introduced for large SPI reads, the absence of any
indication when a delay was inserted (to ensure the CS toggling is
observed by devices) became apparent.
Add an additional debug-only debug message to record the insertion and
duration of any delay (note that the debug-message will cause a delay
on-top of the delay-duration).
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
AVB 2.0 spec. revision 1.1 introduces support for named persistent values
that must be tamper evident and allows AVB to store arbitrary key-value
pairs [1].
Introduce implementation of two additional AVB operations
read_persistent_value()/write_persistent_value() for retrieving/storing
named persistent values.
Correspondent pull request in the OP-TEE OS project repo [2].
[1]: https://android.googlesource.com/platform/external/avb/+/android-9.0.0_r22
[2]: https://github.com/OP-TEE/optee_os/pull/2699
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>
Signed-off-by: Igor Opaniuk <igor.opaniuk@gmail.com>
The sysreset of 'POWER' type is a PMIC reset defined as
'remove and restore power'.
So normally only COLD/WARN is supported by sysreset_syscon.
This modification allows to use the function sysreset_walk(SYSRESET_POWER)
when it is supported by PMIC driver (see example in stpmic1).
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Since the introduction of the driver, some memory in IRAM is reserved for
the TX buffers.
However there are not used but instead of it, it is the buffer provided
by the net stack which is used. As stated in the comment of the driver,
not using the IRAM buffer could cause cache issue and lower the
throughput.
For the second argument it is less the case for transmitting buffers
because the throughput gain in IRAM is mitigated by the time to copy the
data from RAM to IRAM, but the first argument is still valid and indeed
this patch fixes issue seen with Ethernet on some boards
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
The purpose of "mtd: nand: raw: allow to disable unneeded ECC layouts"
was to allow disabling the default ECC layouts if a driver is known to
provide its own ECC layout. However, this commit did the opposite and
disabled the default layout when it was _not_ selected.
It breaks all the NAND drivers not providing their own ECC layout this
patch fix this situation.
It was tested with the lpc32xx_nand_slc driver.
Fixes: a38c3af868 ("mtd: nand: raw: allow to disable unneeded ECC layouts")
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Tested-by: Eugen Hristev <eugen.hristev@microchip.com>
SYSFW version 2019.01 introduces a slightly modified version of this API,
add support for it here.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Andreas Dannenberg <dannenberg@ti.com>
TI-SCI message protocol provides support for controlling the firewall
configurations available in SoC.
Introduce support for the set of TI-SCI message protocol APIs that
provide us with this capability of controlling firewalls.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Andreas Dannenberg <dannenberg@ti.com>
- Add DM based generic watchdog start and reset implementation
and remove all ad-hoc implementations (Stefan)
- Move mv_sdhci to DM (Pierre)
- Misc turris_omnia updates (Pierre)
- Change openrd targets to correctly build again (size changes
and fixes to the dts targets) and bring it back into Travis
builds (Stefan)
- Add Kirkwood db-88f6281-bp board (Chris)
With the new generic function, the scattered other functions are now
removed to be replaced by the generic one. The new version also enables
the configuration of the watchdog timeout via the DT "timeout-sec"
property (if enabled via CONFIG_OF_CONTROL).
The watchdog servicing is enabled via CONFIG_WATCHDOG.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Heiko Schocher <hs@denx.de>
Cc: Eugen Hristev <eugen.hristev@microchip.com>
With the generic watchdog driver now implemented, this patch removes
some legacy stuff from the MPC8xx watchdog driver and its Kconfig
integration. CONFIG_MPC8xx_WATCHDOG is completely removed and
hw_watchdog_reset() is made static, as the watchdog will now get
serviced via the DM infrastructure if enabled via CONFIG_WATCHDOG.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Christophe Leroy <christophe.leroy@c-s.fr>
Now that we have a generic DT property "timeout-sec" handling, the
driver specific implementation can be dropped.
This patch also changes the timeout restriction to the min and max
values (clipping). Before this patch, the value provided via
"timeout-sec" was used if the parameter was too high or low. Now
the driver specific min and max values are used instead.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Michal Simek <michal.simek@xilinx.com>
Tested-by: Michal Simek <michal.simek@xilinx.com> (on zcu100)
This patch tries to implement a generic watchdog_reset() function that
can be used by all boards that want to service the watchdog device in
U-Boot. This watchdog servicing is enabled via CONFIG_WATCHDOG.
Without this approach, new boards or platforms needed to implement a
board specific version of this functionality, mostly copy'ing the same
code over and over again into their board or platforms code base.
With this new generic function, the scattered other functions are now
removed to be replaced by the generic one. The new version also enables
the configuration of the watchdog timeout via the DT "timeout-sec"
property (if enabled via CONFIG_OF_CONTROL).
This patch also adds a new flag to the GD flags, to flag that the
watchdog is ready to use and adds the pointer to the watchdog device
to the GD. This enables us to remove the global "watchdog_dev"
variable, which was prone to cause problems because of its potentially
very early use in watchdog_reset(), even before the BSS is cleared.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Heiko Schocher <hs@denx.de>
Cc: Tom Rini <trini@konsulko.com>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: "Marek Behún" <marek.behun@nic.cz>
Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Cc: Maxim Sloyko <maxims@google.com>
Cc: Erik van Luijk <evanluijk@interact.nl>
Cc: Ryder Lee <ryder.lee@mediatek.com>
Cc: Weijie Gao <weijie.gao@mediatek.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: "Álvaro Fernández Rojas" <noltari@gmail.com>
Cc: Philippe Reynes <philippe.reynes@softathome.com>
Cc: Christophe Leroy <christophe.leroy@c-s.fr>
Reviewed-by: Michal Simek <michal.simek@xilinx.com>
Tested-by: Michal Simek <michal.simek@xilinx.com> (on zcu100)
The new DM implementation currently does not support the Sheeva
88SV331xV5 specific quirk present in the legacy implementation. The
legacy code is thus kept for this SoC and others not yet migrated to
DM_MMC.
Signed-off-by: Pierre Bourdon <delroth@gmail.com>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Cc: Stefan Roese <sr@denx.de>
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Stefan Roese <sr@denx.de>
On iMX8MQ Rev B1, reading from fuse box is not allowed. The
OCOTP_READ_FUSE_DATA register is tied to magic number 0xff0055aa
for chip rev. So u-boot has to disable the fuse sense function for it.
Signed-off-by: Ye Li <ye.li@nxp.com>
Tested-by: Anson Huang <Anson.Huang@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
On mx7ulp B0, beside bank 0 and 1, the fuse bank 9, 10, 28 are changed to
Redundancy mode not ECC, so they can support to program different bits of
a word in multiple times.
Signed-off-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
To make it easy to add new clk driver for i.MX8, split
the code into common part and SoC specific part.
Make the get/set/enable non static and introduce a num_clks for
soc_clk_dump, because the arrays are moved to clk-imx8qxp.c.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
This commit converts i.MX5's EHCI USB host driver to driver model (DM_USB).
It is a straightforward conversion (to reuse as much code as possible),
based on ehci-mx6.c code.
Signed-off-by: Lukasz Majewski <lukma@denx.de>
This adds a compatible string for m41t82. This ensures that this driver
can be used for m41t82 in DM mode, too (asit was usable for this model in
non-DM mode before).
In addition, the HT bit has to be reset during probe, since the m41t82
chip sets it when entering battery standby mode.
This patch ensures this driver works on socfpga_socrates.
Signed-off-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Using this driver on socfpga gen5 with DM_I2C enabled leads to a data abort
as the 'i2c' reset property cannot be found (the gen5 dtsi does not provide
reset-names).
The actual bug was to check 'if (&priv->reset_ctl)', which is never false.
While at it, convert the driver to use 'reset_get_bulk' instead of looking
at a specific named reset and also make it release the reset on driver
remove before starting the OS.
Fixes: 622597dee4 ("i2c: designware: add reset ctrl to driver")
Signed-off-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
Fixes for tracing with sandbox
Refactoring for boot_get_fdt()
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEslwAIq+Gp8wWVbYnfxc6PpAIreYFAlzAfvkACgkQfxc6PpAI
reYu9AgAjaFmydXjE8DxkSB3rR7DHZFTs1erVKAAL2v+Tdf7LDmz+j6u1M3v55WY
6r54f/gZ1UX5TEmQgEAKLa7QvvRO/lNvSGQnLHhZhv2IVWo7uWCKAUPdQ6XVZnUK
zO5v+ucs9Ne4HxQJHMC509HUIIBbydiRvUm8W0SeBZy4kEyJDuub4L+rpARkXNks
IZfKuY+VS4FK73D4M9PIhoXSubZgVS4AEcapakU1DvEz0kjsN4wr4idGrp3lutPC
455imz83JBq2+mx1oxclOGedkIDzTCq+nWQAwSftMehrJpGrp7RLNo0v4QZZUf4V
LIXRqObIYse9yQLkYPpeBdePMc8/tQ==
=0NJ2
-----END PGP SIGNATURE-----
Merge tag 'pull-24apr19' of git://git.denx.de/u-boot-dm
Various minor sandbox iumprovements
Fixes for tracing with sandbox
Refactoring for boot_get_fdt()
Testing has shown that the current DM implementation of a platform /
board specific translation offset, as its needed for the SPL on MVEBU
platforms is buggy. The translation offset is confingured too late,
after the driver bind functions are run. This may result in incorrect
address translations. With the current implementation its not possible
to configure the offset earlier, as the DM code has not run at all.
This patch now removed the set_/get_translation_offset() calls and
moves the translation offset into the GD variable translation_offset.
This variable will get used when CONFIG_TRANSLATION_OFFSET is enabled.
This option is enabled only for MVEBU on ARM32 platforms, where its
currenty needed and configured in the SPL.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Pierre Bourdon <delroth@gmail.com>
Cc: Baruch Siach <baruch@tkos.co.il>
Cc: Simon Glass <sjg@chromium.org>
Cc: Heiko Schocher <hs@denx.de>
Cc: Tom Rini <trini@konsulko.com>
Tested-by: Pierre Bourdon <delroth@gmail.com>
Tested-by: Baruch Siach <baruch@tkos.co.il>
Boards such as qemu-riscv, which receive their device tree at runtime,
for example from QEMU or firmware, are unable to add the appropriate
device tree properties to make devices available pre relocation.
Instead, they must rely on the DM_FLAG_PRE_RELOC flag to be set for the
required drivers.
Add the DM_FLAG_PRE_RELOC flag to the simple-bus driver to make devices
under it with drivers that have set the flag as well available pre
relocation for these boards.
Signed-off-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
