The xSPI Profile 1.0 table specifies how many dummy cycles and address
bytes are needed for the Read Status Register command in Octal DTR mode.
Use that information to send the correct Read SR command.
Some controllers might have trouble reading just 1 byte in DTR mode. So,
when we are in DTR mode read 2 bytes and discard the second. This shows
no side effects with the two flashes I tested: Micron mt35xu512aba and
Cypress s28hs512t.
Update Read FSR to mimic Read SR because they share the same
characteristics.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
This table is indication that the flash is xSPI compliant and hence
supports octal DTR mode. Extract information like the fast read opcode,
the number of dummy cycles needed for a Read Status Register command,
and the number of address bytes needed for a Read Status Register
command.
The default dummy cycles for a fast octal DTR read are set to 20. Since
there is no simple way of determining the dummy cycles needed for the
fast read command, flashes that use a different value should update it
in their flash-specific hooks.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Acked-by: Jagan Teki <jagan@amarulasolutions.com>
Some devices in DTR mode expect an extra command byte called the
extension. The extension can either be same as the opcode, bitwise
inverse of the opcode, or another additional byte forming a 16-byte
opcode. Get the extension type from the BFPT. For now, only flashes with
"repeat" and "inverse" extensions are supported.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
JESD216 rev D makes BFPT 20 DWORDs. Update the BFPT size define to
reflect that.
The check for rev A or later compared the BFPT header length with the
maximum BFPT length, BFPT_DWORD_MAX. Since BFPT_DWORD_MAX was 16, and so
was the BFPT length for both rev A and B, this check worked fine. But
now, since BFPT_DWORD_MAX is 20, it means this check will also stop BFPT
parsing for rev A or B, since their length is 16.
So, instead check for BFPT_DWORD_MAX_JESD216 to stop BFPT parsing for
the first JESD216 version, and check for BFPT_DWORD_MAX_JESD216B for the
next two versions.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Double Transfer Rate (DTR) is SPI protocol in which data is transferred
on each clock edge as opposed to on each clock cycle. Make
framework-level changes to allow supporting flashes in DTR mode.
Right now, mixed DTR modes are not supported. So, for example a mode
like 4S-4D-4D will not work. All phases need to be either DTR or STR.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Even when spi_nor_write_reg() has no data to write, like when executing
a write enable operation, it sets the data direction to
SPI_MEM_DATA_OUT. This trips up spi_mem_check_buswidth() because it
expects a data phase when there is none. Make sure the data direction is
set to SPI_MEM_NO_DATA when there is no data to write.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
The spi-mem layer provides a spi_mem_supports_op() function to check
whether a specific operation is supported by the controller or not.
This is much more accurate than the hwcaps selection logic based on
SPI_{RX,TX}_ flags.
Rework the hwcaps selection logic to use spi_mem_supports_op().
To make sure the build doesn't break for boards not using CONFIG_DM_SPI,
add a simple SPI_{RX,TX}_ based hwcaps selection logic in spi-mem-nodm
similar to spi_mem_default_supports_op(). This change is only
compile-tested.
To avoid SPL size problems on the x530 board, the old hwcaps selection
is still kept around. Leaving the code in-place was getting difficult to
read and understand, so the code is restructured to have it all in one
isolated function. As a result of this, the parameter hwcaps to
spi_nor_setup() is no longer needed. Remove it.
Based on the Linux commit c76f5089796a (mtd: spi-nor: Rework hwcaps
selection for the spi-mem case, 2019-08-06)
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Sometimes the information in a flash's SFDP tables is wrong. Sometimes
some information just can't be expressed in the SFDP table. So,
introduce the fixup hooks to allow tailoring settings for a specific
flash.
Three hooks are added: default_init, post_sfdp, and post_bfpt. These
allow tweaking the flash settings at different point in the probe
sequence. Since the hooks reside in nor->info, set that value just
before the call to spi_nor_init_params().
The hooks and at what points they are executed mimics Linux's spi-nor
framework. One major difference is that Linux puts the struct
spi_nor_fixups in nor->info. This is not possible in U-Boot because the
spi-nor-ids list is shared between spi-nor-core.c and spi-nor-tiny.c.
Since spi-nor-tiny shouldn't have those fixup hooks populated, add a
separate function that lets flashes populate their fixup hooks.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
These structures will be used in a later commit inside another structure
definition. Also take the declarations out of the ifdef since they won't
affect the final binary anyway and will be used in a later commit.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
nor->setup() can be used by flashes to configure settings in case they
have any peculiarities that can't be easily expressed by the generic
spi-nor framework. This includes things like different opcodes, dummy
cycles, page size, uniform/non-uniform sector sizes, etc.
Move related declarations to avoid forward declarations.
Inspired by the Linux kernel's setup() hook.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Acked-by: Jagan Teki <jagan@amarulasolutions.com>
If a flash chip has more than 16MB capacity but its BFPT reports
BFPT_DWORD1_ADDRESS_BYTES_3_OR_4, the spi-nor framework defaults to 3.
The check in spi_nor_scan() doesn't catch it because addr_width did get
set. This fixes that check.
Ported from Kernel commit 324f78dfb442b82365548b657ec4e6974c677502.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Set up opcode extension and enable/disable DTR mode based on whether the
command is DTR or not.
xSPI flashes can have a 4-byte dummy address associated with some
commands like the Read Status Register command in octal DTR mode. Since
the flash does not support sending the dummy address, we can not use
automatic write completion polling in DTR mode. Further, no write
completion polling makes it impossible to use DAC mode for DTR writes.
In that mode, the controller does not know beforehand how long a write
will be and so it can de-assert Chip Select (CS#) at any time. Once CS#
is de-assert, the flash will go into burning phase. But since the
controller does not do write completion polling, it does not know when
the flash is busy and might send in writes while the flash is not ready.
So, disable write completion polling and make writes go through indirect
mode for DTR writes and let spi-mem take care of polling the SR.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Acked-by: Jagan Teki <jagan@amarulasolutions.com>
Once the start bit is toggled it takes a small amount of time before it
is internally synchronized. This means we can't start writing during
that part. So add a small delay to allow the bit to be synchronized.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Acked-by: Jagan Teki <jagan@amarulasolutions.com>
If the device tree provides a read delay value, use that directly and do
not perform the calibration procedure.
This allows the device tree to over-ride the read delay value in cases
where the read delay value obtained via calibration is incorrect. One
such example is the Cypress Semper flash. It needs a read delay of 4 in
octal DTR mode. But since the calibration procedure is run before the
flash is switched in octal DTR mode, it yields a read delay of 2. A
value of 4 works for both octal DTR and legacy modes.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
spi_mem_default_supports_op() rejects DTR ops by default to ensure that
the controller drivers that haven't been updated with DTR support
continue to reject them. It also makes sure that controllers that don't
support DTR mode at all (which is most of them at the moment) also
reject them.
This means that controller drivers that want to support DTR mode can't
use spi_mem_default_supports_op(). Driver authors have to roll their own
supports_op() function and mimic the buswidth checks. Or even worse,
driver authors might skip it completely or get it wrong.
Add spi_mem_dtr_supports_op(). It provides a basic sanity check for DTR
ops and performs the buswidth requirement check. Move the logic for
checking buswidth in spi_mem_default_supports_op() to a separate
function so the logic is not repeated twice.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Acked-by: Jagan Teki <jagan@amarulasolutions.com>
In xSPI mode, flashes expect 2-byte opcodes. The second byte is called
the "command extension". There can be 3 types of extensions in xSPI:
repeat, invert, and hex. When the extension type is "repeat", the same
opcode is sent twice. When it is "invert", the second byte is the
inverse of the opcode. When it is "hex" an additional opcode byte based
is sent with the command whose value can be anything.
So, make opcode a 16-bit value and add a 'nbytes', similar to how
multiple address widths are handled.
All usages of sizeof(op->cmd.opcode) also need to be changed to be
op->cmd.nbytes because that is the actual indicator of opcode size.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Each phase is given a separate 'dtr' field so mixed protocols like
4S-4D-4D can be supported.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Add a driver for Macronix SPI controller IP.
This patch referred from linux spi-mxic.c. The difference from the
linux version is described here.
1. To adapt uboot spi framework, modify some functions naming.
2. Remove the incompatible functions of Uboot.
3. Add dummy byte recalculattion function to support dummy buswidth
not align data buswidth operation.(ex: 1-1-4, 1-1-8)
4. Add Octal mode support.
Signed-off-by: Zhengxun <zhengxunli.mxic@gmail.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
[jagan: fixed file permission, comment line, kconfig]
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
The get_mtd_device_nm() function (code imported from Linux) simply
iterates all registered MTD devices and compares the given name with
all MTDs' names.
With SPI_FLASH_MTD enabled U-Boot registers a SPI-NOR as a MTD device
with name identical to the SPI flash chip name (from SPI ID table). Thus
for a board with multiple same SPI-NORs it registers multiple MTDs, but
all with the same name (such as "s25fl164k"). We do not want to change
this behaviour, since such a change could break existing boot scripts,
which can rely on a hardcoded name.
In order to allow somehow to uniqely select a MTD device, change
get_mtd_device_nm() function as such:
- if first character of name is '/', try interpreting it as OF path
- otherwise compare the name with MTDs name and MTDs device name.
In the following example a board has two "s25fl164k" SPI-NORs. They both
have name "s25fl164k", thus cannot be uniquely selected via this name.
With this change, the user can select the second SPI-NOR either with
"spi-nor@1" or "/soc/spi@10600/spi-nor@1".
Example:
=> mtd list
List of MTD devices:
* s25fl164k
- device: spi-nor@0
- parent: spi@10600
- driver: jedec_spi_nor
- path: /soc/spi@10600/spi-nor@0
- type: NOR flash
- block size: 0x1000 bytes
- min I/O: 0x1 bytes
- 0x000000000000-0x000000800000 : "s25fl164k"
* s25fl164k
- device: spi-nor@1
- parent: spi@10600
- driver: jedec_spi_nor
- path: /soc/spi@10600/spi-nor@1
- type: NOR flash
- block size: 0x1000 bytes
- min I/O: 0x1 bytes
- 0x000000000000-0x000000800000 : "s25fl164k"
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Tested-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Cc: Priyanka Jain <priyanka.jain@nxp.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Heiko Schocher <hs@denx.de>
Cc: Patrick Delaunay <patrick.delaunay@st.com>
In order for `mtd list` U-Boot command to list SPI NOR devices without
the need to run `sf probe` before, we have to probe SPI NOR devices in
mtd_probe_devices().
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Tested-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Cc: Priyanka Jain <priyanka.jain@nxp.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Heiko Schocher <hs@denx.de>
Cc: Patrick Delaunay <patrick.delaunay@st.com>
The device_probe() function does the same thing as mtd_probe() and
mtd_probe() is only used in mtd_probe_uclass_mtd_devs(), where the
probing can be made simpler by using uclass_foreach_dev_probe macro.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Tested-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Cc: Priyanka Jain <priyanka.jain@nxp.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Heiko Schocher <hs@denx.de>
Cc: Patrick Delaunay <patrick.delaunay@st.com>
Fill in mtd->dev member with nor->dev.
This can be used by MTD OF partition parser.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Tested-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Cc: Priyanka Jain <priyanka.jain@nxp.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Heiko Schocher <hs@denx.de>
Cc: Patrick Delaunay <patrick.delaunay@st.com>
Currently when the SPI_FLASH_MTD config option is enabled, only one SPI
can be registered as MTD at any time - it is the last one probed (since
with old non-DM model only one SPI NOR could be probed at any time).
When DM is enabled, allow for registering multiple SPI NORs as MTDs by
utilizing the nor->mtd structure, which is filled in by spi_nor_scan
anyway, instead of filling a separate struct mtd_info.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Tested-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Cc: Priyanka Jain <priyanka.jain@nxp.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Heiko Schocher <hs@denx.de>
Cc: Patrick Delaunay <patrick.delaunay@st.com>
Add support for parsing partitions defined in device-trees via the
`partitions` node with `fixed-partitions` compatible.
The `mtdparts`/`mtdids` mechanism takes precedence. If some partitions
are defined for a MTD device via this mechanism, the code won't register
partitions for that MTD device from OF, even if they are defined.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Tested-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Heiko Schocher <hs@denx.de>
Cc: Patrick Delaunay <patrick.delaunay@st.com>
Add function for retrieving full node path of a given ofnode.
This uses np->full_name if OF is live, otherwise a call to
fdt_get_path() is made.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Tested-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Add functions ofnode_get_addr_size_index_notrans(), which is a
non-translating version of ofnode_get_addr_size_index().
Some addresses are not meant to be translated, for example those of MTD
fixed-partitions.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Tested-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Macronix NAND Flash devices are available in different configurations
and densities.
MX"35" means SPI NAND
MX35"UF" , UF meands 1.8V
MX35LF"2G" , 2G means 2Gbits
MX35LF2G"E4" , E4 means internal ECC and Quad I/O(x4)
MX35UF4GE4AD/MX35UF2GE4AD/MX35UF1GE4AD are 1.8V 4G/2Gbit serial
NAND flash device with 8-bit on-die ECC
https://www.mxic.com.tw/Lists/Datasheet/Attachments/7983/MX35UF4GE4AD,%201.8V,%204Gb,%20v0.00.pdf
MX35UF2GE4AC/MX35UF1GE4AC are 1.8V 2G/1Gbit serial
NAND flash device with 8-bit on-die ECC
https://www.mxic.com.tw/Lists/Datasheet/Attachments/7974/MX35UF2GE4AC,%201.8V,%202Gb,%20v1.0.pdf
Validated via normal(default) and QUAD mode by read, erase, read back,
on Xilinx Zynq PicoZed FPGA board which included Macronix
SPI Host(drivers/spi/spi-mxic.c).
Signed-off-by: Jaime Liao <jaimeliao@mxic.com.tw>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
The MX66UW2G345G is Macronix Flash with SINGLE and OCTAL I/O. Hence,
add SPI_NOR_OCTAL_READ flag for this flash.
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
[jagan: change order of id flags]
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Signed-off-by: zhengxun <zhengxunli.mxic@gmail.com>
Remove the tab in clk_get_bulk to respect the coding rules.
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Add error callback in dfu stack to manage some board specific
behavior on DFU targets.
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
For NOR devices the logical DFU buffer size is the sector_size,
as it is done in dfu_sf.c or in spi/sf_mtd.c
(sf_mtd_info.erasesize = flash->sector_size)
For NAND the DFU size was already limited to erasesize as
has_pages = true.
So the mtd dfu backend can use this erasesize for all the MTD devices,
NOR and NAND with dfu->max_buf_size = mtd->erasesize
This difference was initially copied from MTD command, where
data is fully available in RAM without size limitation.
This patch avoids to have many sector write in dfu_mtd.c at the end
of the DFU transfer and avoids issues with USB timeout or WATCHDOG.
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
TCF flag only means that all data was sent to FIFO. To check if the
data was sent out of FIFO we should also wait for the BUSY flag to be
cleared. Otherwise there is a race condition which can lead to
inability to write short (one byte long) data.
Signed-off-by: Daniil Stas <daniil.stas@posteo.net>
Cc: Patrick Delaunay <patrick.delaunay@foss.st.com>
Cc: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
This driver supports Rockchip NFC (NAND Flash Controller) found on
RK3308, RK2928, RKPX30, RV1108 and other SOCs. The driver has been
tested using 8-bit NAND interface on the ARM based RK3308 platform.
Support Rockchip SoCs and NFC versions:
- PX30 and RK3326(NFCv900).
ECC: 16/40/60/70 bits/1KB.
CLOCK: ahb and nfc.
- RK3308 and RV1108(NFCv800).
ECC: 16 bits/1KB.
CLOCK: ahb and nfc.
- RK3036 and RK3128(NFCv622).
ECC: 16/24/40/60 bits/1KB.
CLOCK: ahb and nfc.
- RK3066, RK3188 and RK2928(NFCv600).
ECC: 16/24/40/60 bits/1KB.
CLOCK: ahb.
Supported features:
- Read full page data by DMA.
- Support HW ECC(one step is 1KB).
- Support 2 - 32K page size.
- Support 8 CS(depend on SoCs)
Limitations:
- No support for the ecc step size is 512.
- Untested on some SoCs.
- No support for subpages.
- No support for the builtin randomizer.
- The original bad block mask is not supported. It is recommended to
use the BBT(bad block table).
Signed-off-by: Yifeng Zhao <yifeng.zhao@rock-chips.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Replace msleep occurences by udelay.
drivers/pci/pcie_dw_rockchip.c:254:3: warning: implicit
declaration of function 'msleep' [-Wimplicit-function-declaration]
Cc: Patrick Wildt <patrick@blueri.se>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Kever Yang <kever.yang@rock-chips.com>
Signed-off-by: Anand Moon <linux.amoon@gmail.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Use the generic error number instead of specific error number.
Changes fix the below error.
drivers/pci/pcie_dw_rockchip.c: In function 'rk_pcie_read':
drivers/pci/pcie_dw_rockchip.c:70:10: error: 'PCIBIOS_UNSUPPORTED'
undeclared (first use in this function)
70 | return PCIBIOS_UNSUPPORTED;
| ^~~~~~~~~~~~~~~~~~~
drivers/pci/pcie_dw_rockchip.c: In function 'rk_pcie_write':
drivers/pci/pcie_dw_rockchip.c:90:10: error: 'PCIBIOS_UNSUPPORTED'
undeclared (first use in this function)
90 | return PCIBIOS_UNSUPPORTED;
| ^~~~~~~~~~~~~~~~~~~
Cc: Patrick Wildt <patrick@blueri.se>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Patrick Wildt <patrick@blueri.se>
Signed-off-by: Anand Moon <linux.amoon@gmail.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Add the driver for rk3568 u-boot to get sdram capacity.
Signed-off-by: Joseph Chen <chenjh@rock-chips.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
-----BEGIN PGP SIGNATURE-----
iQFQBAABCgA6FiEEqxhEmNJ6d7ZdeFLIHrMeAg6sL8gFAmDLD78cHGV1Z2VuLmhy
aXN0ZXZAbWljcm9jaGlwLmNvbQAKCRAesx4CDqwvyLhSB/0UqOd+Ujf2meiHU9yr
oOOCLxVTjTUfIZKLad/zwlj2Xqzsjs6XMawC95BgouvkQLmj/gwerRWcZPg9l7/X
hvb9VJi+iJoLRRpBPbeF3bMb92kCE+YZodFXyutlcY+Z0ZB9755zoVgR6ccKfksd
Xp2y8AFptfYQNZ1l0yb3lhm1261CldWALrGTjRpY2hQ8nEMbV8z6WUB1hAF9CECa
PGbKaiqm9OdktwHsLy4cYFFCuzkykn6T3P6ODineP7IxgEgZKTfJClSTFGY9S0GQ
kwd7K/7j0W3rI5NPknB+Fb4IFAaTs/oozR+5ml7j+2S3G5GXjSGx8zaSOmOZvpP3
KxwN
=/I5V
-----END PGP SIGNATURE-----
Merge tag 'u-boot-atmel-2021.10-a' of https://source.denx.de/u-boot/custodians/u-boot-atmel into next
First set of u-boot-atmel features for the 2021.10 cycle:
This feature set converts the boards pm9261 and pm9263 Ethernet support
to DM; enables hash command for all SAM boards; fixes the NAND pmecc
bit-flips correction; adds Falcon boot for sama5d3_xplained board; and
other minor adjustments.
Now that we have only one clock driver, we don't need to have our own
subdirectory. Move the driver back with the rest of the clock drivers.
The MAINTAINERS for kendryte pinctrl is also fixed since it has always been
wrong.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
This driver no longer serves a purpose now that we have moved away from
CCF. Drop it.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
This speeds up boot by preventing multiple reconfigurations of the PLLs.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
This adds support for setting clock rates, which was left out of the
initial CCF expunging. There are several tricky bits here, mostly related
to the PLLS:
* The PLL's bypass is broken. If the PLL is reconfigured, any child clocks
will be stopped.
* PLL0 is the parent of ACLK which is the CPU and SRAM's clock. To prevent
stopping the CPU while we configure PLL0's rate, ACLK is reparented
to IN0 while PLL0 is disabled.
* PLL1 is the parent of the AISRAM clock. This clock cannot be reparented,
so we instead just disallow changing PLL1's rate after relocation (when
we are using the AISRAM).
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Since we are no longer using CCF we cannot use the default soc_clk_dump.
Instead, implement our own.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Now that there no separate PLL driver, we can no longer make the PLL
functions static. By moving the PLL driver in with the rest of the clock
code, we can make these functions static again. We still keep the pll
header for unit testing, but it is pretty reduced.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
This is effectively a complete rewrite to remove all dependency on CCF.
The code is now smaller, and so is the binary. It also takes up less memory
at runtime (since we don't have to create 40 udevices). In general, I am
much happier with this driver as much of the complexity and late binding
has been removed.
The k210_*_params structs which were previously used to initialize CCF
clocks are now used as the complete configuration. Since we can write our
own division logic, we can now do away with several "half" clocks which
only existed to provide constant factors of two.
The clock IDs have been renumbered to remove unused clocks. This may not be
the last time they are renumbered, since we have diverged with Linux. There
are also still a few clocks left out which may need to be added back in.
In general, I have tried to leave out behavioral changes. However, there is
a small bugfix regarding ACLK. According to the technical reference manual,
its mux comes *after* its divider (which is present only for PLL0). This
would have required yet another intermediate clock to fix with CCF, but
with the new driver it is just 2 lines of code :)
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Since 291da96b8e ("clk: Allow clock defaults to be set during re-reloc
state for SPL only") it has been impossible to set clock defaults before
relocation. This is annoying on boards without SPL, since there is no way
to set clock defaults before U-Boot proper. In particular, the aisram rate
must be changed before relocation on the K210, since U-Boot will hang if we
try and change the rate while we are using aisram.
To get around this, extend the stage parameter to allow force setting
defaults, even if they would be otherwise postponed for later. A device
tree property was decided against because of the concerns in the original
commit thread about the overhead of repeatedly parsing the device tree.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
In absence of Device Manager (DM) services such as at R5 SPL stage,
driver will have to natively setup TCHAN/RCHAN/RFLOW cfg registers.
Add support for the same.
Note that we still need to send chan/flow cfg message to TIFS via TISCI
client driver in order to open up firewalls around chan/flow but setting
up of cfg registers is handled locally.
U-Boot specific code is in a separate file included in main driver so
as to maintain similarity with kernel driver in order to ease porting of
code in future.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210607141753.28796-8-vigneshr@ti.com
In absence of Device Manager (DM) services such as at R5 SPL stage,
driver will have to natively setup Ring Cfg registers. Add support for
the same.
Note that we still need to send RING_CFG message to TIFS via TISCI
client driver in order to open up firewalls around Rings.
U-Boot specific code is in a separate file included in main driver so
as to maintain similarity with kernel driver in order to ease porting of
code in future.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210607141753.28796-7-vigneshr@ti.com
