summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2021-01-05zynq: mtd: nand: remove superfluous ifHeinrich Schuchardt1-6/+4
This sort of code does not make much sense: if (ondie_ecc_enabled) { if (ondie_ecc_enabled) { Remove the inner if. The problem was indicated by cppcheck. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2021-01-04cosmetic: fix typo in drivers/usb/KconfigMarc Ferland1-1/+1
This commit fixes a simple typo: sPL --> SPL. Signed-off-by: Marc Ferland <ferlandm@amotus.ca>
2021-01-04nvme: Use only 32-bit accesses in nvme_writeq/nvme_readqStefan Agner1-8/+0
There might be hardware configurations where 64-bit data accesses to NVMe registers are not supported properly. This patch removes the readq/writeq so always two 32-bit accesses are used to read/write 64-bit NVMe registers, similarly as it is done in Linux kernel. This patch fixes operation of NVMe devices on RPi4 Broadcom BCM2711 SoC based board, where the PCIe Root Complex, which is attached to the system through the SCB bridge. Even though the architecture is 64-bit the PCIe BAR is 32-bit and likely the 64-bit wide register accesses initiated by the CPU are not properly translated to a sequence of 32-bit PCIe accesses. nvme_readq(), for example, always returns same value in upper and lower 32-bits, e.g. 0x3c033fff3c033fff which lead to NVMe devices to fail probing. This fix is analogous to commit 8e2ab05000ab ("usb: xhci: Use only 32-bit accesses in xhci_writeq/xhci_readq"). Cc: Sylwester Nawrocki <s.nawrocki@samsung.com> Cc: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Cc: Matthias Brugger <mbrugger@suse.com> Reviewed-by: Stefan Roese <sr@denx.de> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Signed-off-by: Stefan Agner <stefan@agner.ch>
2021-01-04spi: zynqmp_gqspi: Fix unaligned data writes issueT Karthik Reddy1-4/+2
When unaligned 3 bytes data write operation is performed, 3rd byte is being over written by 1st byte of 3 bytes data. This patch fixes it. Signed-off-by: T Karthik Reddy <t.karthik.reddy@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2021-01-04serial: uartlite: Fix uninitialized ret in debug uartliteAshok Reddy Soma1-1/+1
Endianness detection is checked against uninitialized ret variable. Assign ret with read value from status register to fix this. Fixes: 31a359f87eaa ("serial: uartlite: Add support to work with any endianness") Signed-off-by: Ashok Reddy Soma <ashok.reddy.soma@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2020-12-31dfu_mtd: Add provision to unlock mtd deviceSughosh Ganu1-3/+17
Prior to writing to an mtd device, mtd_erase is called. This call fails in case the sector being erased is locked. Call mtd_unlock to unlock the region which is to be erased and later written to. Lock the region once the write to the region has completed. Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
2020-12-28Merge tag 'u-boot-imx-20201227' of ↵Tom Rini1-1/+1
https://gitlab.denx.de/u-boot/custodians/u-boot-imx Fixes for 2021.1 ---------------- CI: https://gitlab.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/5680 - fixes for Variscite dart6ul - imx8mp : increase malloc area - fixes for bx50v3 - imx8m: HS400ES and UHS for EVK - imx8qm-rom7720: fix phy bind
2020-12-28Revert "arm64: a37xx: pci: Assert PERST# signal when unloading driver"Pali Rohár1-3/+0
This reverts commit 828d32621686aec593076d16445d39b9b8d49c05. This change revers code which asserting PERST# signal when unloading driver. Driver's remove callback is still there as it is used for other functionality. Asserting PERST# signal prior booting kernel is causing that A3720 boards (Turris MOX and Espressobin) with stable Linux kernel versions 4.14 and 4.19 are not able to detect some PCIe cards (e.g. Compex WLE200 and WLE900) and anymore. When PERST# signal is not asserted these cards are detected correctly. As this is regression for existing stable Linux kernel versions revert this problematic change in U-Boot. To make cards working with OpenWRT 4.14 kernel it is needed to disable link training prior booting kernel, which is already done in driver's remove callback. Described issue is in Linux kernel pci aardvark driver which is (hopefully) fixed in latest upstream versions. Latest upstream versions should be able to initialize PCIe bus and detects cards independently of the link training and PERST# signal state. So with this change, U-Boot on A3720 boards should be able to boot OpenWRT 4.14 kernel, stable 4.14 and 4.19 kernels and also latest mainline kernels. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Stefan Roese <sr@denx.de>
2020-12-26i2c: mxc_i2c: improve error message readabilityMarc Ferland1-1/+1
Use 0x%2lx to print the i2c bus base address in hexadecimal format instead of printing as an integer. Signed-off-by: Marc Ferland <ferlandm@amotus.ca> Reviewed-by: Fabio Estevam <festevam@gmail.com>
2020-12-23dm: core: Inline a few ofnode functions in SPLSimon Glass2-0/+18
A recent change to unify the flattree/livetree code introduced a small size increase in SPL on some boards. For example SPL code size for px30-core-ctouch2-px30 increased by 40 bytes. To address this we can take advantage of the fact that some of the ofnode functions are only called a few times in SPL, so it is worth inlining them. Add new Kconfig options to control this. These functions are not inlined for U-Boot proper, since this increases code size. Fixes: 2ebea5eaebf ("dm: core: Combine the flattree and livetree binding code") Signed-off-by: Simon Glass <sjg@chromium.org>
2020-12-23dm: spi: Fix spi_free_slave() freed memory writeNiel Fourie1-1/+0
Remove setting slave->dev to NULL after the device_remove() call. The slave pointer points to dev->parent_priv, which has already been freed by device_free(), called from device_remove() in the preceding line. Writing to slave->dev may cause corruption of the dlmalloc free chunk forward pointer of the previously freed chunk. Signed-off-by: Niel Fourie <lusus@denx.de> Cc: Simon Glass <sjg@chromium.org> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-12-23spi: spi-uclass: Fix spi_claim_bus() speed/mode setup logicOvidiu Panait2-6/+12
Currently, when different spi slaves claim the bus consecutively using spi_claim_bus(), spi_set_speed_mode() will only be executed on the first two calls, leaving the bus in a bad state starting with the third call. This patch drops spi_slave->speed member and adds caching of bus speed/mode in dm_spi_bus struct. It also updates spi_claim_bus() to call spi_set_speed_mode() if either speed or mode is different from what the bus is currently configured for. Current behavior is to only take into account the speed, but not the mode, which seems wrong. Fixes: 60e2809a848 ("dm: spi: Avoid setting the speed with every transfer") Reviewed-by: Simon Glass <sjg@chromium.org> Reported-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Reported-by: Moshe, Yaniv <yanivmo@amazon.com> Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com>
2020-12-23test: spi: Add sandbox_spi_get_{speed, mode} interfaceOvidiu Panait1-0/+14
Introduce sandbox_spi_get_{speed, mode} public interface to retrieve the sandbox spi bus internal state. They are meant to be used in sandbox spi testcases. Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-12-23spi: sandbox_spi: Implement speed/mode setupOvidiu Panait1-0/+26
Implement sandbox_spi_set_{speed, mode} routines, to be able to keep track of the current bus speed/mode. This will help determine whether the values passed from dm_spi_claim_bus() are valid. Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com>
2020-12-23sandbox: test: Add a second SPI slave on sandbox_spi busOvidiu Panait1-2/+2
Place a second spi slave on the sandbox_spi bus, to be used by the spi_claim_bus() testcase we are about to introduce. We need to make sure that jumping between slaves calling spi_claim_bus() sets the bus speed and mode appropriately. Use different max-hz and mode properties for this new slave. Also, update sandbox_spi cs_info call to allow activity on CS0/CS1 and adapt dm_test_spi_find() testcase for this new setup. Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-12-23sandbox: spi: Drop unused sandbox_spi_parse_spec functionOvidiu Panait1-16/+0
Commit 1289e96797bf ("sandbox: spi: Drop command-line SPI option") dropped support for specifying SPI devices on the command line, removing the only user of sandbox_spi_parse_spec(). Remove the function too. Fixes: 1289e96797bf ("sandbox: spi: Drop command-line SPI option") Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-12-19dm: core: Drop seq and req_seqSimon Glass2-16/+2
Now that migration to the new sequence numbers is complete, drop the old fields. Add a test that covers the new behaviour. Also drop the check for OF_PRIOR_STAGE since we always assign sequence numbers now. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-12-19cmd: Drop use of old sequence numbers in commandsSimon Glass1-2/+2
Several commands use sequence numbers. Update them to use the new ones. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-12-19dm: core: Update uclass_find_next_free_req_seq() for new schemeSimon Glass3-13/+16
This function current deals with req_seq which is deprecated. Update it to use the new sequence numbers, putting them above existing aliases. Rename the function to make this clear. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-12-19dm: Drop the unused arg in uclass_find_device_by_seq()Simon Glass4-30/+16
Now that there is only one sequence number (rather than both requested and assigned ones) we can simplify this function. Also update its caller to simplify the logic. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-12-19dm: Drop uclass_resolve_seq()Simon Glass2-47/+0
This function is not needed anymore. Drop it. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-12-19dm: Switch over to use new sequence number for dev_seq()Simon Glass1-4/+2
Update this function to use the new sequence number and fix up the test that deals with this. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-12-19pinctrl: Update for new sequence numbersSimon Glass1-1/+1
Use the dev_seq() sequence number in all cases. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-12-19gpio: Update for new sequence numbersSimon Glass5-5/+5
Use the dev_seq() sequence number in all cases. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-12-19usb: Update for new sequence numbersSimon Glass1-4/+2
Use the new sequence number in all cases. Since all devices are assigned a number when bound, this hack should not be needed. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-12-19usb: ehci-mx6: Drop assignment of sequence numberSimon Glass1-3/+9
This hack cannot work in the new sequence-numbering scheme. Remove it while we wait for the maintainer to complete DM conversion as noted in the existing comment. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-12-19spi: Update for new sequence numbersSimon Glass2-2/+1
Use the new sequence number in all cases. Drop the rockchip case because the sequence number should be 0 anyway, and assigning to the sequence number is not permitted. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-12-19pci: Update to use new sequence numbersSimon Glass2-23/+32
Now that we know the sequence number at bind time, there is no need for special-case code in dm_pci_hose_probe_bus(). Note: the PCI_CAP_ID_EA code may need a look, but there are no test failures so I have left it as is. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-12-19dm: core: Allow manual sequence numberingSimon Glass1-1/+1
Some buses have their own rules which require assigning sequence numbers with a bus-specific algorithm. For example, PCI requires that sub-buses are numbered higher than their parent buses, meaning effectively that parent buses must be numbered only after all of their child buses have been numbered. Add a uclass flag to indicate that driver model should not assign sequence numbers. In this case, the uclass must do it. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-12-19net: Update to use new sequence numbersSimon Glass1-1/+1
Checking for seq == -1 is effectively checking that the device is activated. The new sequence numbers are never -1 for a bound device, so update the check. Also drop the note about valid sequence numbers so it is accurate with the new approach. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-12-19i2c: Update for new sequence numbersSimon Glass6-80/+8
Use the new sequence number in all cases. Drop the logic to check for a valid number in designware_i2c, since it will always be valid. Also drop the numbering in the uclass, since we can rely on driver model giving us the right sequence numbers. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-12-19octeon: Don't attempt to set the sequence numberSimon Glass3-4/+0
Several Octeon drivers operate by setting the sequence number of their device. This should not be needed with the new sequence number setup. Also it is not permitted. Drop it. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-12-19dm: Fix return value in dev_read_alias_seq()Simon Glass1-1/+3
This should return 0 on success but currently does not. Fix it. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-12-19dm: core: Switch binding to use new sequence numbersSimon Glass1-4/+1
Update the core logic to use the new approach. For now the old code is left as is. Update one test so it still passes. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-12-19dm: core: Add a new sequence number for devicesSimon Glass2-9/+21
At present each device has two sequence numbers, with 'req_seq' being set up at bind time and 'seq' at probe time. The idea is that devices can 'request' a sequence number and then the conflicts are resolved when the device is probed. This makes things complicated in a few cases, since we don't really know what the sequence number will end up being. We want to honour the bind-time requests if at all possible, but in fact the only source of these at present is the devicetree aliases. Since we have the devicetree available at bind time, we may as well just use it, in the hope that the required processing will turn out to be useful later (i.e. the device actually gets used). Add a new 'sqq' member, the bind-time sequence number. It operates in parallel to the old values for now. All devices get a valid sqq value, i.e. it is never -1. Drop an #ifdef while we are here. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-12-19dm: core: Update uclass_find_next_free_req_seq() argsSimon Glass3-10/+10
At present this is passed a uclass ID and it has to do a lookup. The callers all have the uclass pointer, except for the I2C uclass where the code will soon be deleted. Update the argument to a uclass * instead of an ID since it is more efficient. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-12-19dm: Avoid accessing seq directlySimon Glass79-153/+160
At present various drivers etc. access the device's 'seq' member directly. This makes it harder to change the meaning of that member. Change access to go through a function instead. The drivers/i2c/lpc32xx_i2c.c file is left unchanged for now. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-12-18Merge branch 'master' of https://gitlab.denx.de/u-boot/custodians/u-boot-spiTom Rini8-136/+944
2020-12-18mtd: spi-nor-ids: add Micron MT25QL01G flashHongwei Zhang1-0/+1
Add Micron MT25QL01G flash, used on AST2600 board. Signed-off-by: Hongwei Zhang <hongweiz@ami.com> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
2020-12-18spi: ca_sflash: Add CAxxxx SPI Flash ControllerPengpeng Chen3-0/+585
Add SPI Flash controller driver for Cortina Access CAxxxx SoCs Signed-off-by: Pengpeng Chen <pengpeng.chen@cortina-access.com> Signed-off-by: Alex Nemirovsky <alex.nemirovsky@cortina-access.com> CC: Vignesh R <vigneshr@ti.com> CC: Tom Rini <trini@konsulko.com> [jagan: rebase on master] Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
2020-12-18spi: dw: Add mem_opsSean Anderson1-7/+111
The designware ssi device has "broken" chip select behaviour [1], and needs specific manipulation to use the built-in chip select. The existing fix is to use an external GPIO for chip select, but typically the K210 has SPI3 directly connected to a flash chip with dedicated pins. This makes it impossible to use the spi_xfer function to use spi, since the CS is de-asserted in between calls. This patch adds an implementation of exec_op, which gives correct behaviour when reading/writing spi flash. This patch also rearranges the headers to conform to U-Boot style. [1] https://lkml.org/lkml/2015/12/23/132 Signed-off-by: Sean Anderson <seanga2@gmail.com> Tested-by Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
2020-12-18spi: dw: Add support for multiple CTRLR0 layoutsSean Anderson1-35/+149
CTRLR0 can have several different layouts depending on the specific device (dw-apb-ssi vs dwc-ssi), and specific parameters set during synthesis. Update the driver to support three specific configurations: dw-apb-ssi with SSI_MAX_XFER_SIZE=16, dw-apb-ssi with SSI_MAX_XFER_SIZE=32, and dwc-ssi. dw-apb-ssi is the version of the device on Altera/Intel SoCFPGAs, MSCC SoCs, and Canaan Kendryte K210 SoCs. This is the only version this driver supported before this change. The register layout before version 3.23a is: | 31 .. 16 | | other stuff | | 15 .. 10 | 9 .. 8 | 7 .. 6 | 5 .. 4 | 3 .. 0 | | other stuff | TMOD | MODE | FRF | DFS | Note that DFS (Data Frame Size) is only 4 bits, limiting transfers to data frames of 16 bits or less. In version 3.23a, the SSI_MAX_XFER_SIZE parameter was introduced. This parameter defaults to 16 (resulting in the same layout as prior versions), but may also be set to 32. To allow setting longer data frame sizes, a new DFS_32 register was introduced: | 31 .. 21 | 20 .. 16 | | other stuff | DFS_32 | | 15 .. 10 | 9 .. 8 | 7 .. 6 | 5 .. 4 | 3 .. 0 | | other stuff | TMOD | MODE | FRF | all zeros | The old DFS field no longer controls the data frame size. To detect this layout, we try writing 0xF to DFS. If we read back 0x0, then this device has SSI_MAX_XFER_SIZE=32. dwc-ssi is the version of the device on Intel Keem Bay SoCs and Canaan Kendryte K210 SoCs. The layout of ctrlr0 is: | 31 .. 16 | | other stuff | | 15 .. 12 | 11 .. 10 | 9 .. 8 | 7 .. 6 | 4 .. 0 | | other stuff | TMOD | MODE | FRF | DFS_32 | The semantics of the fields have not changed since the previous version. However, SSI_MAX_XFER_SIZE is effectively always 32. To support these different layouts, we model our approach on the one which the Linux kernel has taken. During probe, the driver calls an init function stored in driver_data. This init function is responsible for determining the layout of CTRLR0, and supplying the update_cr0 function. The style of and information behind this commit is based on the Linux MMIO driver for these devices. Specific reference was made to the series adding support for Intel Keem Bay SoCs [1]. [1] https://lore.kernel.org/linux-spi/20200505130618.554-1-wan.ahmad.zainie.wan.mohamad@intel.com/ Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
2020-12-18spi: dw: Rearrange struct dw_spi_privSean Anderson1-14/+13
This should reduce the size of the struct, and also groups more similar fields together. Signed-off-by: Sean Anderson <seanga2@gmail.com> Tested-by Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
2020-12-18spi: dw: Remove spi_enable_chipSean Anderson1-11/+6
This function does nothing but wrap dw_write. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
2020-12-18spi: dw: Rename registers to match datasheetSean Anderson1-9/+9
A few registers had slightly different names from what is in the datasheet. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
2020-12-18spi: dw: Use generic function to read reg addressSean Anderson1-0/+2
Using an fdt-specific function causes problems when compiled with a live tree. Signed-off-by: Sean Anderson <seanga2@gmail.com> Tested-by Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
2020-12-18spi: dw: Rename "cs-gpio" to "cs-gpios"Sean Anderson1-1/+2
This property is named differently than other SPI drivers with the same property, as well as the property as used in Linux. Signed-off-by: Sean Anderson <seanga2@gmail.com> Tested-by Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
2020-12-18spi: dw: Convert calls to debug to dev_*Sean Anderson1-19/+19
This allows different log levels to be enabled or disabled depending on the desired level of verbosity. In particular, it allows for general debug information to be printed while excluding more verbose logging which may interfere with timing. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
2020-12-18spi: dw: Fix driving MOSI low while recievingSean Anderson1-1/+1
The resting state of MOSI is high when nothing is driving it. If we drive it low while recieving, it looks like we are transmitting 0x00 instead of transmitting nothing. This can confuse slaves (like SD cards) which allow new commands to be sent over MOSI while they are returning data over MISO. The return of MOSI from 0 to 1 at the end of recieving a byte can look like a start bit and a transmission bit to an SD card. This will cause the card to become out-of-sync with the SPI device, as it thinks the device has already started transmitting two bytes of a new command. The mmc-spi driver will not detect the R1 response from the SD card, since it is sent too early, and offset by two bits. This patch fixes transfer errors when using SD cards with dw spi. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
2020-12-18mtd: spinand: enable erasing of bad mtd blocksMikhail Kshevetskiy1-1/+9
U-Boot is able to erase bad mtd blocks on raw nand devices, but this is not true for spinand flashes. Lets enable this feature for spinand flashes as well. This is extemelly useful for flash testing. Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@oktetlabs.ru>