summaryrefslogtreecommitdiffstats
path: root/drivers
Commit message (Collapse)AuthorAgeFilesLines
...
| * | serial: ns16550: Correct the base address typeBin Meng2021-03-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently ns16550_serial_assign_base() treats the argument 'base' with type `ulong`. This is incorrect because the base address was obtained from device tree with type `fdt_addr_t` that can represent a physical address larger than 32-bit in a 32-bit system. Fixes: 9e6ce62190b7 ("serial: ns16550: Fix ordering of getting base address") Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * | sandbox: host bind must close file descriptorHeinrich Schuchardt2021-03-031-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Each invocation of the 'host bind' command with a file name argument opens a file descriptor. The next invocation of the 'host bind' command destroys the block device but the file descriptor remains open. The same holds true for the 'unbind blk' command. Close the file descriptor when unbinding the host block device. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
| * | dm: core: Add DM_DEVICE_REMOVE condition to all exit pathsSimon Glass2021-03-031-8/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | At present device_bind() does some unnecessary work if a device fails to bind in SPL. Add the missing conditions. Also fix a style nit in the same function while we are here. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | dm: core: Fix allocation of empty of-platdataSimon Glass2021-03-031-4/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With of-platdata we always have a dtv struct that holds the platform data provided by the driver_info record. However, this struct can be empty if there are no actual devicetree properties provided. The upshot of empty platform data is that it will end up as a zero-size member in the BSS section, which is fine. But if the driver specifies plat_auto then it expects the correct amount of space to be allocated. At present this does not happen, since device_bind() assumes that the platform-data size will always be >0. As a result we end up not allocating the space and just use the BSS region, overwriting whatever other contents are present. Fix this by removing the condition that platform data be non-empty, always allocating space if requested. This fixes a strange bug that has been lurking since of-platdata was implemented. It has likely never been noticed since devices normally have at least some devicetree properties, BSS is seldom used on SPL, the dtv structs are normally at the end of bss and the overwriting only happens if a driver changes its platform data. It was discovered using sandbox_spl, which exercises more features than a normal board might, and the critical global_data variable 'gd' happened to be at the end of BSS. Fixes: 9fa28190091 ("dm: core: Expand platdata for of-platdata devices") Signed-off-by: Simon Glass <sjg@chromium.org>
| * | Merge tag 'u-boot-imx-20210303' of ↵Tom Rini2021-03-032-0/+13
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://gitlab.denx.de/u-boot/custodians/u-boot-imx i.MX for 2021.04 ---------------- - new boards: - i.MX8MN Beacon EmbeddedWorks (2GB) - Gateworks Venice imx8mm - convert to DM: - imx53-qsb, mx53loco, mx51evk, mx23-evk - Fixes : - Network : FEC ethernet quirks - DH dh-imx6 CI: https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/6597
| | * | mmc: fsl_esdhc_imx: fix the DTOCV to 0xEHaibo Chen2021-03-011-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On imx6Q/imx6DL, we find if config the DTOCV to 0~3, it will impact cmd6 behavior, after cmd6 get transfer complete interrupt, the data0 line will keep low over 5 seconds. This should be a IC bug on imx6Q/DL. For other platforms, do not has this issue. To fix this issue, fix the DTOCV to 0xE, the max setting, this also align with Linux configuration. Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Reviewed-by: Ye Li <ye.li@nxp.com> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
| | * | mmc: fsl_esdhc_imx: Add a compatible for i.MX51Fabio Estevam2021-03-011-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a compatible for i.MX51 so that i.MX51 can use this driver via driver model. Signed-off-by: Fabio Estevam <festevam@gmail.com> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
| | * | thermal: imx_tmu: enable monitoring and default alert/criticalTim Harvey2021-03-011-0/+6
| | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Set default critical/alert temperature and enabling monoitoring. Without calling imx_tmu_enable_msite() monitoring will not be enabled and read_temperature will return 0. Additionally without setting alert temperature will cause imx_tmu_get_temp() to spin indefiniately thinking the system needs to cool. This resolves the board spinning endlessly when enabling IMX_TMU in the SPL. Reviewed-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Tim Harvey <tharvey@gateworks.com>
| * | usb: USB keyboard requires DM_KEYBOARDHeinrich Schuchardt2021-03-031-0/+1
| | | | | | | | | | | | | | | | | | If CONFIG_DM_USB=y, the USB keyboard only works if CONFIG_DM_KEYBOARD=y. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
| * | usb: gadget: Use dbg_ep0() macro instead of serial_printf()Pali Rohár2021-03-031-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | All debug messages from ep0.c except a few are printed by dbg_ep0() macro. So for remaining few exceptions use also dbg_ep0() instead of serial_printf(). Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Lukasz Majewski <lukma@denx.de> Acked-by: Pavel Machek <pavel@ucw.cz>
| * | usb: musb: Ensure that we set musb dynamic FIFO buffer for every endpointPali Rohár2021-03-031-12/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If we do not set FIFO buffer address and size for some endpoint which is in use then default programmed address 0x0 would be used which is in conflict with address of FIFO buffer for endpoint 0. Moreover address of FIFO buffer for endpoint 0 cannot be programmed, it is fixed to 0x0. Sharing address space between more endpoints cause data loss and unexpected errors. This patch is fixing transmission of characters over usbtty serial console and allows using of usbtty for debugging purposes on Nokia N900. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Lukasz Majewski <lukma@denx.de> Acked-by: Pavel Machek <pavel@ucw.cz>
| * | usb: musb: Fix handling interrupts for EP0 and SET ADDRESS commmandPali Rohár2021-03-031-8/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Interrupt for EP0 is indicated in intrtx register via first bit. This bit is set for both RX and TX despite register has only TX in its name. First bit in intrrx register is reserved, not used and never set. So remove calling musb_peri_ep0() function at every iteration of udc_irq() and musb_peri_rx() and call it only from musb_peri_tx() when correct interrupt bit in initrtx it set. Address from SET ADDRESS command must be set to faddr register only after acknowledging SERV_RXPKTRDY followed by received EP0 interrupt. So prior calling musb_peri_ep0_set_address() check for EP0 interrupt instead of (incorrect) MUSB_INTR_SOF interrupt. This patch fixes issue that host (computer) cannot register U-Boot USB device and is failing with errors: usb 1-1: new full-speed USB device number 86 using xhci_hcd usb 1-1: Device not responding to setup address. usb 1-1: Device not responding to setup address. usb 1-1: device not accepting address 86, error -71 U-Boot was writing address to faddr register too early and did not wait for correct interrupt after which should update address. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Lukasz Majewski <lukma@denx.de> Acked-by: Pavel Machek <pavel@ucw.cz>
| * | usb: musb: Fix receiving of bigger buffersPali Rohár2021-03-031-1/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If musb_peri_rx_ep() was called to process received HW buffer but U-Boot cannot read it yet (e.g. because U-Boot SW buffer is full) then interrupt was marked as processed also when HW buffer stayed unprocessed. U-Boot tried to process this buffer again when it received interrupt again, but it can receive it only when sender (host) sends a new data. As sender (host) is not going to send a new data until U-Boot process current data this issue caused a deadlock in case sender (host) is emitting data faster than U-Boot can process it. Reading musb intrrx register automatically clears this register and marks interrupt as processed. So to prevent marking interrupt in U-Boot as processed, adds a new variable pending_intrrx which would contain unprocessed bits of intrrx register. For a second step, every time when musb_peri_rx_ep() is called and there are waiting data to be processed (signaled by MUSB_RXCSR_RXPKTRDY) either acknowledge sender (via musb_peri_rx_ack()) that whole HW buffer was processed or set corresponding bit in pending_intrrx that HW buffer was not fully processed yet and next iteration is required after U-Boot allocates space for reading HW buffer. This patch fixes receiving large usb buffers, e.g. file transfer via Kermit protocol implemented by 'loadb' U-Boot command over usbtty serial console. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Lukasz Majewski <lukma@denx.de> Acked-by: Pavel Machek <pavel@ucw.cz>
| * | usb: musb: Fix transmission of bigger buffersPali Rohár2021-03-031-11/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If udc_endpoint_write() was called with bigger payload which does not fit into one USB packet it is needed to transmit payload in more USB packets. First packet is transmitted by udc_endpoint_write() call itself and other packets are put into waiting queue. Implement function musb_peri_tx() which checks if endpoints are ready for transmit and continue transmission of waiting queue. This patch fixes sending big output from printenv command over usbtty serial console. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Lukasz Majewski <lukma@denx.de> Acked-by: Pavel Machek <pavel@ucw.cz>>
| * | usb: musb: Read value of PERI_RXCSR to 16bit variablePali Rohár2021-03-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | PERI_RXCSR is 16bit register so store its value into 16bit local variable. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Lukasz Majewski <lukma@denx.de> Acked-by: Pavel Machek <pavel@ucw.cz>
| * | usb: musb: Fix configuring FIFO for endpointsPali Rohár2021-03-031-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes configuring FIFOs for one-directional endpoints which have only one queue (either RX or TX, but noth both). Size of FIFO buffer is 2^(idx+3) bytes and starting address is 2^(addr+3). Moreover first 64 bytes are reserved for EP0. Without this patch if FIFO size specified by caller was zero then idx was incorrectly calculated (expr. ffs(0)-1) and size overflowed in fifosz register. This register uses has only 4 bits for FIFO size. Moreover specifying zero buffer size is not possible (with idx=0 is minimal buffer size 8 bytes). So even for one-directional endpoints we need to correctly specify both (RX and TX) FIFO buffer sizes and its addresses. This patch is fixing calculation of start address and buffer size to minimal value and ensures that it would not overlap with buffer reserved for EP0. This issue caused loose of packets on USB bus in both directions and basically usbtty was unusable. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Lukasz Majewski <lukma@denx.de> Acked-by: Pavel Machek <pavel@ucw.cz>
| * | usb: musb: Always clear the data toggle bit when configuring epPali Rohár2021-03-031-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Without this patch clearing was done only when U-Boot was compiled with MUSB Host Controller. But clearing of data toggle bit is needed also for MUSB Device Controller otherwise Device Controller does not work correctly. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Lukasz Majewski <lukma@denx.de> Acked-by: Pavel Machek <pavel@ucw.cz>
| * | serial: usbtty: Send urb data in correct orderPali Rohár2021-03-031-9/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Function next_urb() selects the last urb data buffer from linked list to which next data from usbtty's puts function should be appended. But to check if TX data still exists it is needed to look at the first urb data buffer from linked list. So check for endpoint->tx_urb (first from the linked list) instead of current_urb (the last from the linked list). Successful call to udc_endpoint_write() may invalidate active urb and allocate new urb in queue which invalidates pointer returned by next_urb() function. So call next_urb() prior putting data into urb buffer and call it every time after using udc_endpoint_write() function to prevent sending data from usbtty's puts function in incorrect order. This patch fixes issue that usbtty code does not transmit data when they are waiting in the tx queue. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Lukasz Majewski <lukma@denx.de> Acked-by: Pavel Machek <pavel@ucw.cz>
| * | serial: usbtty: Fix puts functionPali Rohár2021-03-031-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This function has incorrect implementation of prepending CR prior LF. Without this patch it prepended CR prior whole string which is going to be written and let LF without leading CR. Fix this issue by inserting CR at correct place to make output on usbtty serial console more readable. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Lukasz Majewski <lukma@denx.de> Acked-by: Pavel Machek <pavel@ucw.cz>
| * | rng: iproc_rng200: Enable support for RPi4 armv7Matthias Brugger2021-03-021-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | On the RPi4 armv7 build we have the situationt that we use physical addresses of 64 bit, while the virtual addresses are 32 bit. Remap the base address in this scenario via map_physmem(). Signed-off-by: Matthias Brugger <mbrugger@suse.com>
| * | drivers: mmc: iproc_sdhci: enable HS200 modeBharat Gooty2021-03-021-9/+83
| |/ | | | | | | | | | | | | | | | | | | Add tuning functionality which is needed for HS200 mode. For HS200, program the correct needed 1.8 voltage Signed-off-by: Bharat Gooty <bharat.gooty@broadcom.com> Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Matthias Brugger <mbrugger@suse.com>
* | drivers: tee: sandbox: SCP03 control emulatorJorge Ramirez-Ortiz2021-03-142-1/+59
| | | | | | | | | | | | | | | | | | Adds support for a working SCP03 emulation. Input parameters are validated however the commands (enable, provision) executed by the TEE are assumed to always succeed. Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io> Reviewed-by: Simon Glass <sjg@chromium.org>
* | tpm: Correct warning on 32-bit buildSimon Glass2021-03-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix the warning: drivers/tpm/tpm2_tis_sandbox.c: In function ‘sandbox_tpm2_xfer’: drivers/tpm/tpm2_tis_sandbox.c:288:48: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 2 has type ‘size_t’ {aka ‘unsigned int’} [-Wformat=] printf("TPM2: Unmatching length, received: %ld, expected: %d\n", ~~^ %d send_size, length); ~~~~~~~~~ Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
* | dm: core: Fix allocation of empty of-platdataSimon Glass2021-03-121-4/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With of-platdata we always have a dtv struct that holds the platform data provided by the driver_info record. However, this struct can be empty if there are no actual devicetree properties provided. The upshot of empty platform data is that it will end up as a zero-size member in the BSS section, which is fine. But if the driver specifies plat_auto then it expects the correct amount of space to be allocated. At present this does not happen, since device_bind() assumes that the platform-data size will always be >0. As a result we end up not allocating the space and just use the BSS region, overwriting whatever other contents are present. Fix this by removing the condition that platform data be non-empty, always allocating space if requested. This fixes a strange bug that has been lurking since of-platdata was implemented. It has likely never been noticed since devices normally have at least some devicetree properties, BSS is seldom used on SPL, the dtv structs are normally at the end of bss and the overwriting only happens if a driver changes its platform data. It was discovered using sandbox_spl, which exercises more features than a normal board might, and the critical global_data variable 'gd' happened to be at the end of BSS. Fixes: 9fa28190091 ("dm: core: Expand platdata for of-platdata devices") Signed-off-by: Simon Glass <sjg@chromium.org>
* | Merge tag 'next-2021-03-04' of ↵Tom Rini2021-03-041-115/+153
|\ \ | | | | | | | | | | | | | | | https://gitlab.denx.de/u-boot/custodians/u-boot-video into next - convert sunxi_display to DM_VIDEO
| * | video: sunxi_display: Convert to DM_VIDEOJagan Teki2021-03-031-115/+153
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DM_VIDEO migration deadline is already expired, but around 80 Allwinner boards are still using video in a legacy way: ===================== WARNING ====================== This board does not use CONFIG_DM_VIDEO Please update the board to use CONFIG_DM_VIDEO before the v2019.07 release. Failure to update by the deadline may result in board removal. See doc/driver-model/migration.rst for more info. ==================================================== Convert the legacy video driver over to the DM_VIDEO framework. This is a minimal conversion: it doesn't use the DT for finding its resources, nor does it use DM clocks or DM devices for the outputs (LCD, HDMI, CVBS). Tested in Bananapi M1+ Plus 1920x1200 HDMI out. (Jagan) Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> [Andre: rebase and smaller fixes] Signed-off-by: Andre Przywara <andre.przywara@arm.com> Acked-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Jernej Skrabec <jernej.skrabec@siol.net> Reviewed-by: Simon Glass <sjg@chromium.org>
* | gpio: Add a way to read 3-way strapping pinsSimon Glass2021-03-032-4/+90
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Using the internal vs. external pull resistors it is possible to get 27 different combinations from 3 strapping pins. Add an implementation of this. This involves updating the sandbox GPIO driver to model external and (weaker) internal pull resistors. The get_value() method now takes account of what is driving a pin: sandbox: GPIOD_EXT_DRIVEN - in which case GPIO_EXT_HIGH provides the value outside source - in which case GPIO_EXT_PULL_UP/DOWN indicates the external state and we work the final state using those flags and the internal GPIOD_PULL_UP/DOWN flags Of course the outside source does not really exist in sandbox. We are just modelling it for test purpose. Signed-off-by: Simon Glass <sjg@chromium.org>
* | gpio: Define the log category in the uclassSimon Glass2021-03-031-0/+2
| | | | | | | | | | | | This uses log_debug(), etc. but does not define the category. Fix this. Signed-off-by: Simon Glass <sjg@chromium.org>
* | gpio: sandbox: Track whether a GPIO is drivenSimon Glass2021-03-031-6/+15
| | | | | | | | | | | | | | | | | | | | | | Add a new flag to keep track of whether sandbox is driving the pin, or whether it is expecting an input signal. If it is driving, then the value of the pin is the value being driven (0 or 1). If not driving, then we consider the value 0, since we don't currently handle things like pull-ups yet. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
* | gpio: x86: Drop the deprecated methods in intel_gpioSimon Glass2021-03-031-34/+38
| | | | | | | | | | | | | | We don't need to implement direction_input() and direction_output() anymore. Drop them and use update_flags() instead. Signed-off-by: Simon Glass <sjg@chromium.org>
* | gpio: Use an 'ops' variable everywhereSimon Glass2021-03-031-11/+14
| | | | | | | | | | | | | | | | | | | | Update this driver to use the common method of putting the driver operations in an 'ops' variable install of calling gpio_get_ops() repeatedly. Make it const since operations do not change. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
* | gpio: Replace direction_input() and direction_output()Simon Glass2021-03-031-9/+6
| | | | | | | | | | | | | | | | | | | | The new update_flags() method is more flexible since it allows the driver to see the full flags all at once. Use that in preference to these two functions. Add comments to that effect. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
* | dm: gpio: Add a way to update flagsSimon Glass2021-03-033-20/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It is convenient to be able to adjust some of the flags for a GPIO while leaving others alone. Add a function for this. Update dm_gpio_set_dir_flags() to make use of this. Also update dm_gpio_set_value() to use this also, since this allows the open-drain / open-source features to be implemented directly in the driver, rather than using the uclass workaround. Update the sandbox tests accordingly. This involves a lot of changes to dm_test_gpio_opendrain_opensource() since we no-longer have the direciion being reported differently depending on the open drain/open source flags. Also update the STM32 drivers to let the uclass handle the active low/high logic. Drop the GPIOD_FLAGS_OUTPUT() macro which is no-longer used. Signed-off-by: Simon Glass <sjg@chromium.org> Tested-by: Kory Maincent <kory.maincent@bootlin.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Tested-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Tested-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
* | gpio: sandbox: Make sandbox_gpio_set_flags() set all flagsSimon Glass2021-03-031-9/+12
| | | | | | | | | | | | | | | | | | | | | | | | Allow this function to see all flags, including the internal sandbox ones. This allows the tests to fully control the behaviour of the driver. To make this work, move the setting of GPIOD_EXT_HIGH -to where the flags are updated via driver model, rather than the sandbox 'back door'. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
* | gpio: sandbox: Fully separate pin value from output valueSimon Glass2021-03-031-4/+20
| | | | | | | | | | | | | | | | | | | | | | | | At present we have the concept of a pin's external value. This is what is used when getting the value of a pin. But we still set the GPIOD_IS_OUT_ACTIVE flag when changing the value. This is not actually correct, since if the pin changes from output to input, the external value need not change. Adjust the logic for this difference. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
* | gpio: sandbox: Use a separate flag for the valueSimon Glass2021-03-031-23/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At present with the sandbox GPIO driver it is not possible to change the value of GPIOD_IS_OUT_ACTIVE unless the GPIO is an output. This makes it hard to test changing the flags since we need to be aware of the internal workings of the driver. The feature is designed to aid testing. Split this feature out into a separate sandbox-specific flag, so that the flags can change unimpeded. This will make it easier to allow updating the flags in a future patch. Signed-off-by: Simon Glass <sjg@chromium.org>
* | gpio: sandbox: Rename GPIO dir_flags to flagsSimon Glass2021-03-031-26/+34
| | | | | | | | | | | | | | | | | | | | | | | | Adjust the terminology in this driver to reflect that fact that all flags are handled, not just direction flags. Create a new access function to get the full GPIO state, not just the direction flags. Drop the static invalid_dir_flags since we can rely on a segfault if something is wrong. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
* | gpio: Rename dm_gpio_get_dir_flags() to dm_gpio_get_flags()Simon Glass2021-03-031-1/+1
| | | | | | | | | | | | | | | | | | This function can be used to get any flags, not just direction flags. Rename it to avoid confusion. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: Pratyush Yadav <p.yadav@ti.com>
* | dm: gpio: Rename get_dir_flags() method to get_flags()Simon Glass2021-03-034-27/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | It is more useful to be able to read all the flags, not just the direction ones. In fact this is what the STM32 driver does. Update the method name to reflect this. Tweak the docs a little and use 'flagsp' as the return argument, as is common in driver model, to indicate it returns a value. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: Pratyush Yadav <p.yadav@ti.com>
* | dm: gpio: Rename set_dir_flags() method to update_flags()Simon Glass2021-03-034-17/+17
| | | | | | | | | | | | | | | | | | | | | | | | The current method is a misnomer since it is also used (e.g. by stm32) to update pull settings and open source/open drain. Rename it and expand the documentation to cover a few more details. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Pratyush Yadav <p.yadav@ti.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
* | gpio: Disable functions not used with of-platdataSimon Glass2021-03-031-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These functions use devicetree and cannot work with of-platdata, which has no runtime devicetree. If they are used, the current linker error is confusing, since it talks about missing functions in the bowels of driver model. Avoid compiling these functions at all with of-platdata, so that a straightforward link error points to the problem. Series-changes; 3 - Fix 'wprl' typo Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
* | tpm: Use logging in the uclassSimon Glass2021-03-021-3/+5
| | | | | | | | | | | | | | Update this to use log_debug() instead of the old debug(). Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
* | tpm: Don't include cr50 in TPL/SPLSimon Glass2021-03-022-3/+3
| | | | | | | | | | | | | | | | | | | | At present the security chip is not used in these U-Boot phases. Update the Makefile to exclude it. Fix a few logging statements while we are here. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
* | reset: Remove addr parameter from reset_cpu()Harald Seiler2021-03-023-3/+3
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Historically, the reset_cpu() function had an `addr` parameter which was meant to pass in an address of the reset vector location, where the CPU should reset to. This feature is no longer used anywhere in U-Boot as all reset_cpu() implementations now ignore the passed value. Generic code has been added which always calls reset_cpu() with `0` which means this feature can no longer be used easily anyway. Over time, many implementations seem to have "misunderstood" the existence of this parameter as a way to customize/parameterize the reset (e.g. COLD vs WARM resets). As this is not properly supported, the code will almost always not do what it is intended to (because all call-sites just call reset_cpu() with 0). To avoid confusion and to clean up the codebase from unused left-overs of the past, remove the `addr` parameter entirely. Code which intends to support different kinds of resets should be rewritten as a sysreset driver instead. This transformation was done with the following coccinelle patch: @@ expression argvalue; @@ - reset_cpu(argvalue) + reset_cpu() @@ identifier argname; type argtype; @@ - reset_cpu(argtype argname) + reset_cpu(void) { ... } Signed-off-by: Harald Seiler <hws@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
* Merge https://gitlab.denx.de/u-boot/custodians/u-boot-usbTom Rini2021-02-266-100/+255
|\ | | | | | | - fastboot updates / fixes
| * usb: gadget: dwc2_udc_otg: Fix dwc2_gadget_start() and ↵Patrice Chotard2021-02-261-6/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | usb_gadget_register_driver() Since commit 8745b9ebccae ("usb: gadget: add super speed support") ums was no more functional on platform which use dwc2_udc_otg driver. This was due to a too restrictive test which checked that the gadget driver speed was either FS or HS. So all gadget driver with max speed set to speed higher than HS (SS in case of composite gadget driver in our case) are not allowed, which is wrong. Update the speed test in usb_gadget_register_driver() and in dwc2_gadget_start() to allow all gadget driver speed equal or higher than FS. Tested on stm32mp157c-ev1 board. Fixes: c791c8431c34 ("usb: dwc2: convert driver to DM_USB_GADGET") Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
| * fastboot: add UUU command UCmd and ACmd supportHeiko Schocher2021-02-263-0/+94
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | add support for the UUU commands ACmd and UCmd. Enable them through the Kconfig option CONFIG_FASTBOOT_UUU_SUPPORT base was commit in NXP kernel 9b149c2a2882: ("MLK-18591-3 android: Add FSL android fastboot support") and ported it to current mainline. Tested this patch on imx6ul based board. Signed-off-by: Heiko Schocher <hs@denx.de> Acked-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
| * fastboot: Allow u-boot-style partitionsSean Anderson2021-02-261-59/+98
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds support for partitions of the form "dev.hwpart:part" and "dev#partname". This allows one to flash to eMMC boot partitions without having to use CONFIG_FASTBOOT_MMC_BOOT1_SUPPORT. It also allows one to flash to an entire device without needing CONFIG_FASTBOOT_MMC_USER_NAME. Lastly, one can also flash MMC devices other than CONFIG_FASTBOOT_FLASH_MMC_DEV. Because devices can be specified explicitly, CONFIG_FASTBOOT_FLASH_MMC_DEV is used only when necessary for existing functionality. For those cases, fastboot_mmc_get_dev has been added as a helper function. This allows There should be no conflicts with the existing system, but just in case, I have ordered detection of these names after all existing names. The fastboot_mmc_part test has been updated for these new names. Signed-off-by: Sean Anderson <sean.anderson@seco.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * fastboot: Move part_get_info_by_name_or_alias after raw_part_get_info_by_nameSean Anderson2021-02-261-22/+22
| | | | | | | | | | | | | | This makes the next commit more readable by doing the move now. Signed-off-by: Sean Anderson <sean.anderson@seco.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * fastboot: Remove mmcpart argument from raw_part_get_info_by_nameSean Anderson2021-02-261-23/+18
| | | | | | | | | | | | | | | | | | | | The only thing mmcpart was used for was to pass to blk_dselect_hwpart. This calls blk_dselect_hwpart directly from raw_part_get_info_by_name. The error handling is dropped, but it is reintroduced in the next commit (albeit less specificly). Signed-off-by: Sean Anderson <sean.anderson@seco.com> Reviewed-by: Simon Glass <sjg@chromium.org>
generated by cgit (git 2.34.1) at 2024-06-28 07:17:49 +0000