summaryrefslogtreecommitdiffstats
path: root/drivers
Commit message (Collapse)AuthorAgeFilesLines
* core: add support for U_BOOT_DRIVER_ALIASWalter Lozano2020-07-0913-0/+28
| | | | | | | | | | | | | | | | Currently when using OF_PLATDATA the binding between devices and drivers is done trying to match the compatible string in the node with a driver name. However, usually a single driver supports multiple compatible strings which causes that only devices which its compatible string matches a driver name get bound. To overcome this issue, this patch adds the U_BOOT_DRIVER_ALIAS macro, which generates no code at all, but allows an easy way to declare driver name aliases. Thanks to this, dtoc could be improve to look for the driver name based on its alias when it populates the U_BOOT_DEVICE entry. Signed-off-by: Walter Lozano <walter.lozano@collabora.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* drivers: rename drivers to match compatible stringWalter Lozano2020-07-0937-77/+63
| | | | | | | | | | | | | | | | | When using OF_PLATDATA, the bind process between devices and drivers is performed trying to match compatible string with driver names. However driver names are not strictly defined, and also there are different names used when declaring a driver with U_BOOT_DRIVER, the name of the symbol used in the linker list and the used in the struct driver_info. In order to make things a bit more clear, rename the drivers names. This will also help for further OF_PLATDATA improvements, such as checking for valid driver names. Signed-off-by: Walter Lozano <walter.lozano@collabora.com> Reviewed-by: Simon Glass <sjg@chromium.org> Add a fix for sandbox of-platdata to avoid using an invalid ANSI colour: Signed-off-by: Simon Glass <sjg@chromium.org>
* sandbox: spi: sandbox_sf_state_name() is requiredHeinrich Schuchardt2020-07-091-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Compiling drivers/mtd/spi/sandbox.c fails when compiled with CONFIG_LOG=n: In file included from include/common.h:20, from drivers/mtd/spi/sandbox.c:13: drivers/mtd/spi/sandbox.c:295:15: error: format ‘%s’ expects argument of type ‘char *’, but argument 7 has type ‘int’ [-Werror=format=] 295 | log_content(" cmd: transition to %s state\n", | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ include/linux/printk.h:37:21: note: in definition of macro ‘pr_fmt’ 37 | #define pr_fmt(fmt) fmt | ^~~ include/log.h:128:30: note: in expansion of macro ‘log_nop’ 128 | #define log_content(_fmt...) log_nop(LOG_CATEGORY, \ | ^~~~~~~ drivers/mtd/spi/sandbox.c:295:3: note: in expansion of macro ‘log_content’ 295 | log_content(" cmd: transition to %s state\n", | ^~~~~~~~~~~ drivers/mtd/spi/sandbox.c:295:37: note: format string is defined here 295 | log_content(" cmd: transition to %s state\n", | ~^ | | | char * | %d Supply function sandbox_sf_state_name() independent of CONFIG_LOG. Fixes: c3aed5db591e ("sandbox: spi: Add more logging") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
* Merge https://gitlab.denx.de/u-boot/custodians/u-boot-x86Tom Rini2020-07-0912-66/+388
|\ | | | | | | | | | | | | | | - Add two- and three-argument versions of CONFIG_IS_ENABLED in linux/kconfig.h - Adds a new feature which supports copying modified parts of the frame buffer to the uncached hardware buffer - Enable the copy framebuffer on various x86 targets
| * minnowmax: Enable the copy framebufferSimon Glass2020-07-091-1/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Update the video driver to support this feature and enable it on minnowmax to speed up the display. With this change, the time taken to print the environment to the display without CONFIG_CONSOLE_SCROLL_LINES is reduced from over 13 seconds to 300ms, at 1280x1024. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Anatolij Gustschin <agust@denx.de> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
| * chromebook_link: Enable the copy framebufferSimon Glass2020-07-091-6/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | Update the video driver to support this feature and enable it on link. Also remove the multi-line scrolling since normal scrolling is fast enough now. With this change, the time taken to print the environment to the display without CONFIG_CONSOLE_SCROLL_LINES is reduced from about 930ms to 29ms. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Anatolij Gustschin <agust@denx.de> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
| * chromebook_samus: Enable the copy framebufferSimon Glass2020-07-091-1/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | Update the video driver to support this feature and enable it on samus. Also remove the multi-line scrolling since normal scrolling is fast enough now. With this change, the time taken to print the environment to the display without CONFIG_CONSOLE_SCROLL_LINES is reduced from about 430ms to 12ms. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Anatolij Gustschin <agust@denx.de> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
| * x86: video: Support copy framebuffer with probed devicesSimon Glass2020-07-092-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For PCI video devices that are not mentioned in the devicetree, U-Boot does not bind a driver before relocation, since PCI is not fully probed at that point. Furthermore it is possible for the video device to be on a secondary bus which is not even scanned. This is fine if the framebuffer is allocated in fixed memory, as it normally is on x86. But when using this as a copy framebuffer, we also need U-Boot to allocate its own cached framebuffer for working in. Since the video driver is never bound before relocation, the framebuffer size is never set and U-Boot does no allocation. Add a new CONFIG option to reserve 16MB of memory for this eventuality. This allows vesa devices to use the copy framebuffer. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Anatolij Gustschin <agust@denx.de> Tested-by: Bin Meng <bmeng.cn@gmail.com>
| * video: Correctly handle multiple framebuffersSimon Glass2020-07-091-2/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | At present video_bottom is set to the bottom of each framebuffer when it is allocated. This is not correct, since it should hold the bottom of the entire area available for framebuffers. Fix this by adding a private address in the uclass which keeps track of the next available spot for a framebuffer. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Anatolij Gustschin <agust@denx.de> Tested-by: Bin Meng <bmeng.cn@gmail.com>
| * video: pci: Set up the copy framebufferSimon Glass2020-07-091-1/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When using a copy framebuffer we need to tell the video subsystem its address. U-Boot's normally allocated framebuffer is used as the working buffer, but nothing is displayed until it is copied to the copy framebuffer. For this to work the video driver must request that a framebuffer be allocated separately from the hardware framebuffer, so add a check for that. Also add a log category so that logging appears correctly. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Anatolij Gustschin <agust@denx.de> Tested-by: Bin Meng <bmeng.cn@gmail.com>
| * video: sandbox: Add support for the copy framebufferSimon Glass2020-07-091-1/+8
| | | | | | | | | | | | | | | | | | | | Enable this feature on sandbox by updating the SDL driver to have two framebuffers. Update the video tests to check that the copy framebuffer is kept in sync. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Anatolij Gustschin <agust@denx.de>
| * video: Update the copy framebuffer when writing bitmapsSimon Glass2020-07-091-3/+13
| | | | | | | | | | | | | | | | Adjust the bitmap code to sync to the copy framebuffer when done. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Anatolij Gustschin <agust@denx.de> Tested-by: Bin Meng <bmeng.cn@gmail.com>
| * video: Update rotated console to support copy bufferSimon Glass2020-07-091-23/+60
| | | | | | | | | | | | | | | | | | | | | | Update the implementation to keep a track of what it changes in the frame buffer and then tell the copy buffer about it. Use the special vidconsole_memmove() helper so that memmove() operations are also reflected in the copy buffer. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Anatolij Gustschin <agust@denx.de> Tested-by: Bin Meng <bmeng.cn@gmail.com>
| * video: Update truetype console to support copy bufferSimon Glass2020-07-091-12/+31
| | | | | | | | | | | | | | | | | | | | | | Update the implementation to keep a track of what it changes in the frame buffer and then tell the copy buffer about it. Use the special vidconsole_memmove() helper so that memmove() operations are also reflected in the copy buffer. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Anatolij Gustschin <agust@denx.de> Tested-by: Bin Meng <bmeng.cn@gmail.com>
| * video: Update normal console to support copy bufferSimon Glass2020-07-091-3/+23
| | | | | | | | | | | | | | | | | | | | | | Update the implementation to keep a track of what it changes in the frame buffer and then tell the copy buffer about it. Use the special vidconsole_memmove() helper so that memmove() operations are also reflected in the copy buffer. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Anatolij Gustschin <agust@denx.de> Tested-by: Bin Meng <bmeng.cn@gmail.com>
| * video: Add helpers for vidconsole for the copy framebufferSimon Glass2020-07-091-0/+16
| | | | | | | | | | | | | | | | | | Add a convenience function to call video_sync_copy() for a vidconsole. Also add a memmove() helper, which does the memmove() as well as the sync. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Anatolij Gustschin <agust@denx.de> Tested-by: Bin Meng <bmeng.cn@gmail.com>
| * video: Clear the copy framebuffer when clearing the screenSimon Glass2020-07-091-0/+4
| | | | | | | | | | | | | | | | Update video_clear() to also sync to the copy framebuffer. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Anatolij Gustschin <agust@denx.de> Tested-by: Bin Meng <bmeng.cn@gmail.com>
| * video: Set up the copy framebuffer when enabledSimon Glass2020-07-091-0/+3
| | | | | | | | | | | | | | | | | | This framebuffer is separately mapped. Update the video post-probe function to set this up. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Anatolij Gustschin <agust@denx.de> Tested-by: Bin Meng <bmeng.cn@gmail.com>
| * video: Add support for copying to a hardware framebufferSimon Glass2020-07-092-0/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some architectures use a cached framebuffer and flush the cache as needed so that changes are visible. This is supported by U-Boot. However x86 uses an uncached framebuffer with a 'write-combining' feature to speed up writes. Reads are permitted but they are extremely expensive. Unfortunately, reading from the frame buffer is quite common, e.g. to scroll it. This makes scrolling very slow. Add a new feature which supports copying modified parts of the frame buffer to the uncached hardware buffer. This speeds up scrolling by at least 10x on x86 so the extra complexity cost seems worth it. As a starting point, add the Kconfig, update the video structures to keep track of the buffer and add a function to do the copy. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Anatolij Gustschin <agust@denx.de> Tested-by: Bin Meng <bmeng.cn@gmail.com>
| * video: Adjust rotated console to start at right edgeSimon Glass2020-07-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At present when the console is rotated 180 degrees it starts almost a whole character to the left of the right edge (typically 7 pixels with an 8-pixel-wide font). On a display which aligns with the font width, this just wastes space. On a display that does not this can result in x_frac going negative for the final character (the one on the left side) and the overflow -EAGAIN check at the start of the function failing. Change the function to start at the rightmost pixel to fix these problems. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Anatolij Gustschin <agust@denx.de> Tested-by: Bin Meng <bmeng.cn@gmail.com>
| * video: Split out expression parts into variablesSimon Glass2020-07-091-17/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The functions in this file do similar things but not always in the same way. To make the code easier to read and compare, use a separate 'linenum' variable in every function. This is then multiplied by the line length to get the offset within the frame buffer to modify. Also use an 'x' variable to hold the pixel position within that line. This is multipled by the pixel size and added to the offset. Also move the pbytes declaration up a little with the other long lines. A side effect of splitting out these variables is that they are promoted to int, i.e. a signed type, from the unsigned short used in the vidconsole_priv struct. This would be necessary should any of the variables go negative. At present this can actually happen in console_putc_xy_2(), if the display width is not a multiple of the character size (see next patch). Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Anatolij Gustschin <agust@denx.de> Tested-by: Bin Meng <bmeng.cn@gmail.com>
| * sandbox: video: Allow selection of rotated consoleSimon Glass2020-07-091-0/+1
| | | | | | | | | | | | | | | | | | Add a devicetree property to select a rotated console. This uses the same encoding as vidconsole itself: 0=normal; 1=90 degrees clockwise, 2=upside down, 3=90 degrees anticlockwise. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Anatolij Gustschin <agust@denx.de>
| * video: Show an error when a vidconsole function failsSimon Glass2020-07-091-3/+19
| | | | | | | | | | | | | | | | | | | | At present these functions fail silently even when debugging, which is not very helpful. Add a way to print a message to the serial output when an error is detected. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Anatolij Gustschin <agust@denx.de> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* | Merge tag 'for-v2020.10' of https://gitlab.denx.de/u-boot/custodians/u-boot-i2cTom Rini2020-07-0914-60/+1655
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | i2c changes for v2020.10 - Add support for I2C controllers found on Octeon II/III and Octeon TX TX2 SoC platforms. - Add I2C controller support for Cortina Access CAxxxx SoCs - new rtc methods, rtc command, and tests - imx_lpi2c: Improve the codes to use private data - stm32f7_i2c.c: Add new compatible "st,stm32mp15-i2c" - stm32f7_i2c.c: Add Fast Mode Plus support - pwm: Add PWM driver for SiFive SoC
| * | pwm: Add PWM driver for SiFive SoCYash Shah2020-07-093-0/+179
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Adds a PWM driver for PWM chip present in SiFive's HiFive Unleashed SoC This driver is simple port of Linux pwm sifive driver from Linux v5.6 commit: 9e37a53eb051 ("pwm: sifive: Add a driver for SiFive SoC PWM") Signed-off-by: Yash Shah <yash.shah@sifive.com> Reviewed-by: Heiko Schocher <hs@denx.de>
| * | i2c: stm32f7: SYSCFG Fast Mode Plus support for I2C STM32F7Patrick Delaunay2020-07-091-1/+73
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Read SYSCFG bindings to set Fast Mode Plus bits if Fast Mode Plus speed is selected. Handle the stm32mp15 specific compatible to handle FastMode+ registers handling which is different on the stm32mp15 compared to the stm32f7 or stm32h7. Indeed, on the stm32mp15, the FastMode+ set and clear registers are separated while on the other platforms (F7 or H7) the control is done in a unique register. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Reviewed-by: Heiko Schocher <hs@denx.de>
| * | i2c: stm32f7: add stm32mp15 compatiblePatrick Delaunay2020-07-091-0/+1
| | | | | | | | | | | | | | | | | | | | | Add a new compatible "st,stm32mp15-i2c" introduced in Linux kernel v5.8 Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Reviewed-by: Heiko Schocher <hs@denx.de>
| * | rtc: i2c_rtc_emul: catch any write to the "reset" registerRasmus Villemoes2020-07-091-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It's more natural that any write that happens to touch the reset register should cause a reset, rather than just a write that starts at that offset. Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heiko Schocher <hs@denx.de> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
| * | rtc: sandbox-rtc: fix set methodRasmus Villemoes2020-07-091-41/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current set method is broken; a simple test case is to first set the date to something in April, then change the date to 31st May: => date 040412122020.34 Date: 2020-04-04 (Saturday) Time: 12:12:34 => date 053112122020.34 Date: 2020-05-01 (Friday) Time: 12:12:34 or via the amending of the existing rtc_set_get test case similarly: $ ./u-boot -T -v => ut dm rtc_set_get Test: dm_test_rtc_set_get: rtc.c expected: 31/08/2004 18:18:00 actual: 01/08/2004 18:18:00 The problem is that after each register write, sandbox_i2c_rtc_complete_write() gets called and sets the internal time from the current set of registers. However, when we get to writing 31 to mday, the registers are in an inconsistent state (mon is still 4), so the mktime machinery ends up translating April 31st to May 1st. Upon the next register write, the registers are populated by sandbox_i2c_rtc_prepare_read(), so the 31 we just wrote to mday gets overwritten by a 1. Fix it by writing all registers at once, and for consistency, update the get method to retrieve them all with one "i2c transfer". Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heiko Schocher <hs@denx.de> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
| * | rtc: pcf2127: provide ->write methodRasmus Villemoes2020-07-091-0/+7
| | | | | | | | | | | | | | | | | | Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heiko Schocher <hs@denx.de> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
| * | rtc: pcf2127: provide ->read methodRasmus Villemoes2020-07-091-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This simply consists of renaming the existing pcf2127_read_reg() helper to follow the naming of the other methods (i.e. pcf2127_rtc_<method name>) and changing the type of its "len" parameter. Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heiko Schocher <hs@denx.de> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
| * | rtc: fall back to ->{read, write} if ->{read, write}8 are not providedRasmus Villemoes2020-07-091-6/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Similar to how the dm_rtc_{read,write} functions fall back to using the {read,write}8 methods, do the opposite in the rtc_{read,write}8 functions. This way, each driver only needs to provide either ->read8 or ->read to make both rtc_read8() and dm_rtc_read() work - without this, a driver that provides ->read() would most likely just duplicate the logic here for implementing a ->read8() method in term of its ->read() method. The same remarks of course apply to the write case. Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heiko Schocher <hs@denx.de> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
| * | rtc: add dm_rtc_write() helperRasmus Villemoes2020-07-091-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Similar to dm_rtc_read(), introduce a helper that allows the caller to write multiple consecutive 8-bit registers with one call. If the driver provides the ->write method, use that, otherwise loop using ->write8. Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heiko Schocher <hs@denx.de> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
| * | rtc: add dm_rtc_read helper and ->read methodRasmus Villemoes2020-07-091-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some users may want to read multiple consecutive 8-bit registers. Instead of each caller having to implement the loop, provide a dm_rtc_read() helper. Also, allow a driver to provide a ->read method, which can be more efficient than reading one register at a time. Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heiko Schocher <hs@denx.de> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
| * | i2c: imx_lpi2c: Improve the codes to use private dataYe Li2020-07-091-11/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Current driver calls the devfdt_get_addr to get the base address of lpi2c controller in each sub-functions. Since the devfdt_get_addr accesses the DTB and translate the address, it introduces much overhead. Improve the codes to use private variable which has recorded the base address from probe. Signed-off-by: Ye Li <ye.li@nxp.com> Reviewed-by: Peng Fan <peng.fan@nxp.com>
| * | i2c: i2c-cortina: added CAxxxx I2C supportArthur Li2020-07-094-0/+443
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add I2C controller support for Cortina Access CAxxxx SoCs Signed-off-by: Arthur Li <arthur.li@cortina-access.com> Signed-off-by: Alex Nemirovsky <alex.nemirovsky@cortina-access.com> CC: Heiko Schocher <hs@denx.de> Reviewed-by: Heiko Schocher <hs@denx.de> hs: fixed build error, add include log.h
| * | i2c: octeon_i2c: Add I2C controller driver for OcteonSuneel Garapati2020-07-093-0/+858
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for I2C controllers found on Octeon II/III and Octeon TX TX2 SoC platforms. Signed-off-by: Aaron Williams <awilliams@marvell.com> Signed-off-by: Suneel Garapati <sgarapati@marvell.com> Signed-off-by: Stefan Roese <sr@denx.de> Cc: Heiko Schocher <hs@denx.de> Cc: Simon Glass <sjg@chromium.org> Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com> Cc: Aaron Williams <awilliams@marvell.com> Cc: Chandrakala Chavva <cchavva@marvell.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heiko Schocher <hs@denx.de> Reviewed-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
* | net: mvpp2: fix second cp110 initializationSven Auhagen2020-07-091-29/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since the mdio code got upstreamed it is not possible to activate network ports on CP110 Master and Slave. The problem is in mvpp2_base_probe which is called for each CP110 and it initializes the buffer area for descs and rx_buffers. This should only happen once though and the bd space is actually set to 0 after the first run of the function. This leads to an error when the second CP110 tries the initialization again and disables all network ports on this CP110. This patch adds a static variable to check if the buffer area is initialized only once globally. Signed-off-by: Sven Auhagen <sven.auhagen@voleatech.de> Reviewed-by: Stefan Roese <sr@denx.de>
* | mv_ddr: ddr3: Update {min,max}_read_sample calculationChris Packham2020-07-091-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | Measurements on actual hardware shown that the read ODT is early by 3 clocks. Adjust the calculation to avoid this. Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> [upstream https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell/pull/22] Signed-off-by: Chris Packham <judge.packham@gmail.com> Tested-by: Baruch Siach <baruch@tkos.co.il> Reviewed-by: Stefan Roese <sr@denx.de>
* | mv_ddr: ddr3: Use correct bitmask for read sample delayChris Packham2020-07-091-1/+1
|/ | | | | | | | | | | | In the Armada 385 functional spec (MV-S109094-00 Rev. C) the read sample delay fields are 5 bits wide. Use the correct bitmask of 0x1f when extracting the value. Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> [upstream https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell/pull/22] Signed-off-by: Chris Packham <judge.packham@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de>
* spl: fit: nand: fix fit loading in case of bad blocksDario Binacchi2020-07-081-0/+28
| | | | | | | | | | | | The offset at which the image to be loaded from NAND is located is retrieved from the itb header. The presence of bad blocks in the area of the NAND where the itb image is located could invalidate the offset which must therefore be adjusted taking into account the state of the sectors concerned. cc: Michael Trimarchi <michael@amarulasolutions.com> Signed-off-by: Dario Binacchi <dariobin@libero.it> Reviewed-by: Michael Trimarchi <michael@amarulasolutions.com>
* tpm: add #ifndef to fix redeclaration build errorsJohannes Holland2020-07-081-0/+2
| | | | | | | | tpm_tis_spi.c directly includes tpm_tis.h and tpm-v2.h which both define the same enums (see e.g. TPM_ACCESS_VALID). Add an #ifndef to prevent redeclaration errors. Signed-off-by: Johannes Holland <johannes.holland@infineon.com>
* tpm2: tis_spi: add linux compatible fallback stringBruno Thomsen2020-07-081-1/+1
| | | | | | | | | | | | | | | | | | | This solves a compatibility issue with Linux device trees that contain TPMv2.x hardware. So it's easier to import DTS from upstream kernel when migrating board init from C code to DTS. The issue is that fallback binding is different between Linux and u-Boot. Linux: "tcg,tpm_tis-spi" U-Boot: "tis,tpm2-spi" As there are currently no in-tree users of the U-Boot binding, it makes sense to use Linux fallback binding. Signed-off-by: Bruno Thomsen <bruno.thomsen@gmail.com> Reviewed-by: Tom Rini <trini@konsulko.com>
* sata_sil: Enable DM_PCI operationAndre Przywara2020-07-072-2/+15
| | | | | | | | | | | Even though the sata_sil driver was converted over to the driver model, it still assumed that the PCI controller is using the legacy interface. Allow the "devno" member to be a struct udevice pointer and use DM_PCI_COMPAT to covert the rest of the interface. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
* net: smc911x: Properly handle EEPROM MAC addressAndre Przywara2020-07-071-24/+36
| | | | | | | | | | | | | | | | | | When compiled as a DM_ETH driver, the scm911x driver was reading the MAC address from the optional EEPROM storage, but failed to copy this to the platdata struct. Since it was also missing a definition of the read_rom_hwaddr() function, the generic Ethernet code was dismissing this MAC address, falling back to a random address or denying to start at all. Add an implementation of .read_rom_hwaddr, and refactor the function reading the ROM address to be called by all interested parties. This fixes MAC address issues when using the driver in DM_ETH "mode". Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-By: Ramon Fried <rfried.dev@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
* gpio: search for gpio label if gpio is not found through bank nameHeiko Schocher2020-07-072-0/+66
| | | | | | | | | | | | | | | | | | | | | dm_gpio_lookup_name() searches for a gpio through the bank name. But we have also gpio labels, and it makes sense to search for a gpio also in the labels we have defined, if no gpio is found through the bank name definition. This is useful for example if you have a wp pin on different gpios on different board versions. If dm_gpio_lookup_name() searches also for the gpio labels, you can give the gpio an unique label name and search for this label, and do not need to differ between board revisions. Signed-off-by: Heiko Schocher <hs@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org> [trini: Don't enable by default] Signed-off-by: Tom Rini <trini@konsulko.com>
* net: designware: s700: Add glue code for S700 macAmit Singh Tomar2020-07-073-0/+75
| | | | | | | | | | | | This patchs adds glue logic to enable designware mac present on Action Semi based S700 SoC, Configures SoC specific bits. Undocumented bit that programs the PHY interface select register comes from vendor source. It has been tested on Cubieboard7-lite based on S700 SoC. Signed-off-by: Amit Singh Tomar <amittomer25@gmail.com>
* net: phy: realtek: Introduce PHY_RTL8201F_S700_RMII_TIMINGS to adjust rx/tx ↵Amit Singh Tomar2020-07-072-0/+44
| | | | | | | | | | | | | timings RTL8201F PHY module found on Actions Semi Cubieboard7 seems to have specific Rx/Tx interface timings requirement for proper PHY operations. These timing values are not documented anywhere and picked from vendor code. This commits lets proper packets to be transmitted over the network. Signed-off-by: Amit Singh Tomar <amittomer25@gmail.com>
* net: phy: realtek: Add support for RTL8201F PHY module.Amit Singh Tomar2020-07-071-0/+20
| | | | | | | | This patch adds support for Realtek PHY RTL8201F 10/100Mbs (with variants: RTL8201FN and RTL8201FL) PHYceiver. It is present on Actions Semi Cubieboard7 board. Signed-off-by: Amit Singh Tomar <amittomer25@gmail.com>
* clk: actions: Add Ethernet clocksAmit Singh Tomar2020-07-072-2/+9
| | | | | | | This commit adds clocks needed for ethernet operations for Actions OWL family of SoCs (S700 and S900). Signed-off-by: Amit Singh Tomar <amittomer25@gmail.com>
generated by cgit (git 2.34.1) at 2025-01-16 16:49:55 +0000