- Oct 21, 2020
-
-
When sending a command via the MDIO bus, the Designware MAC expects some bits in the CMD register to describe the clock divider value between the main clock and the MDIO clock. So far we were omitting these bits, resulting in setting "00", which means "/ 16", so ending up with an MDIO frequency of either 18.75 or 12.5 MHz. All the internal PHYs in the H3/H5/H6 SoCs as well as the Gbit Realtek PHYs seem to be fine with that - although it looks like to be severly overclocked (the MDIO spec limits the frequency to 2.5 MHz). However the external 100Mbit PHY on the Pine64 (non-plus) board is not happy with that, Ethernet was actually never working there, as the PHY didn't probe. As we set the EMAC clock (via AHB2) to 300 MHz in ATF (on the 64-bit SoCs), and use 200 MHz on the H3, we need the highest divider of 128 to let the MDIO clock end up below the required 2.5 MHz. This enables Ethernet on the Pine64(non-plus). Signed-off-by:
Andre Przywara <andre.przywara@arm.com> Acked-by:
Maxime Ripard <mripard@kernel.org> Tested-by: Amit Singh Tomar <amittomer25@gmail.com> # Pine64+ Reviewed-by:
Jagan Teki <jagan@amarulasolutions.com>
-
The current implementation of sun8i_get_ephy_nodes() makes quite some assumptions, in general relying on DT path names is a bad idea. I think the idea of the code was to determine if we are using the internal PHY, for which there are simpler and more robust methods: Rewrite (and rename) the existing function to simply lookup the DT node that "phy-handle" points to, using the device's DT node. Then check whether the parent of that PHY node is using an "H3 internal MDIO" compatible string. If we ever get another internal MDIO bus implementation, we will probably need code adjustments anyway, so this is good enough for now. Signed-off-by:
Andre Przywara <andre.przywara@arm.com> [jagan: rebase on master] Signed-off-by:
Jagan Teki <jagan@amarulasolutions.com> Acked-by:
Maxime Ripard <mripard@kernel.org> Tested-by: Amit Singh Tomar <amittomer25@gmail.com> # Pine64+ Reviewed-by:
Jagan Teki <jagan@amarulasolutions.com>
-
The error handling in recv() is somewhat broken, for instance good_packet isn't really used, and it's hardly readable. Also we try to check for short or too big packets, but those are actually filtered out by the hardware. Simplify the whole routine and improve the error handling: - Bail out early if the current RX descriptor is not ready. - Enable propagation of runt, huge and broken packets. - Check for runt and huge packets, and return 0 to indicate this. This will force the framework to call free_pkt for cleanup. - Avoid aligning the packet buffer for invalidation again. Signed-off-by:
Andre Przywara <andre.przywara@arm.com> Acked-by:
Maxime Ripard <mripard@kernel.org> Tested-by: Amit Singh Tomar <amittomer25@gmail.com> # Pine64+ Reviewed-by:
Jagan Teki <jagan@amarulasolutions.com>
-
The EMAC soft reset routine was subtly broken, using an open coded timeout routine without any actual delay. Remove the unneeded initial reset bit read, and call wait_for_bit_le32() to handle the timeout correctly. Signed-off-by:
Andre Przywara <andre.przywara@arm.com> Acked-by:
Maxime Ripard <mripard@kernel.org> Tested-by: Amit Singh Tomar <amittomer25@gmail.com> # Pine64+ Reviewed-by:
Jagan Teki <jagan@amarulasolutions.com>
-
When iterating over all RX/TX buffers, we were using a rather long "idx" control variable, which lead to a nasty overlong line. Replace "idx" with "i" to avoid this. Signed-off-by:
Andre Przywara <andre.przywara@arm.com> Acked-by:
Maxime Ripard <mripard@kernel.org> Tested-by: Amit Singh Tomar <amittomer25@gmail.com> # Pine64+ Reviewed-by:
Jagan Teki <jagan@amarulasolutions.com>
-
To meet the current alignment requirements for our cache maintenance functions, we were explicitly aligning the *arguments* to those calls. This is not only ugly to read, but also wrong, as we need to make sure we are not accidentally stepping on other data. Provide wrapper functions for the common case of cleaning or invalidating a descriptor, to make the cache maintenance calls more readable. This fixes a good deal of the problematic calls. Signed-off-by:
Andre Przywara <andre.przywara@arm.com> Acked-by:
Maxime Ripard <mripard@kernel.org> Tested-by: Amit Singh Tomar <amittomer25@gmail.com> # Pine64+ Reviewed-by:
Jagan Teki <jagan@amarulasolutions.com>
-
There is no reason to invalidate a TX descriptor before we are setting it up, as we will only write to a field. Remove the not needed invalidate_dcache_range() call. Signed-off-by:
Andre Przywara <andre.przywara@arm.com> Acked-by:
Maxime Ripard <mripard@kernel.org> Tested-by: Amit Singh Tomar <amittomer25@gmail.com> # Pine64+ Reviewed-by:
Jagan Teki <jagan@amarulasolutions.com>
-
When we initialise the TX descriptors, there is no need yet to clean them all to memory, as they don't contain any data yet. Later we will touch and clean each descriptor anyway. However we tell the MAC about the beginning of the chain, so we have to clean at least the first descriptor, to make it clear that this is empty and there are no packets to transfer yet. Signed-off-by:
Andre Przywara <andre.przywara@arm.com> Acked-by:
Maxime Ripard <mripard@kernel.org> Tested-by: Amit Singh Tomar <amittomer25@gmail.com> # Pine64+ Reviewed-by:
Jagan Teki <jagan@amarulasolutions.com>
-
Before we initialise the RX descriptors, there is no need to *clean* them from the cache, as we touch them for the first time. However we should cover the case that those buffers contain dirty cache lines, which could be evicted and written back to DRAM any time later, in the worst case *after* the MAC has transferred a packet into them. Signed-off-by:
Andre Przywara <andre.przywara@arm.com> Acked-by:
Maxime Ripard <mripard@kernel.org> Tested-by: Amit Singh Tomar <amittomer25@gmail.com> # Pine64+ Reviewed-by:
Jagan Teki <jagan@amarulasolutions.com>
-
The EMAC driver contains a lot of magic bits, although the manuals and the Linux driver have all names for them. Define those names and use them when programming the registers. Also this replaces a lot of readl/mask/writel operations with the much easier-to-read setbits_le32() macro. Signed-off-by:
Andre Przywara <andre.przywara@arm.com> Acked-by:
Maxime Ripard <mripard@kernel.org> Tested-by: Amit Singh Tomar <amittomer25@gmail.com> # Pine64+ Reviewed-by:
Jagan Teki <jagan@amarulasolutions.com>
-
Apparently due to copying from some older or converted driver, the sun8i_emac driver contains pointless wrapper functions to bridge between a legacy driver and the driver model. Since sun8i_emac is (and always was) driver model only, there is no reason to have those confusing wrappers. Just remove them, and use the driver model prototypes directly. Signed-off-by:
Andre Przywara <andre.przywara@arm.com> Acked-by:
Maxime Ripard <mripard@kernel.org> Tested-by: Amit Singh Tomar <amittomer25@gmail.com> # Pine64+ Reviewed-by:
Jagan Teki <jagan@amarulasolutions.com>
-
When preparing the register value for the MDIO command register, we start with a zeroed register, so there is no need to mask off certain bits before setting them. Simplify the sequence, and rename the variable to a more matching mii_cmd on the way. Also the open-coded time-out routine can be replaced with a much safer and easier-to-read call to wait_for_bit_le32(). Signed-off-by:
Andre Przywara <andre.przywara@arm.com> Acked-by:
Maxime Ripard <mripard@kernel.org> Tested-by: Amit Singh Tomar <amittomer25@gmail.com> # Pine64+ Reviewed-by:
Jagan Teki <jagan@amarulasolutions.com>
-
When initialising the TX DMA descriptors, we mostly chain them up, but of course don't know about any data or its length yet. That means they are still invalid, and the OWN bit should NOT be set yet. In fact when we later tell the MAC about the beginning of the chain, and enable TX DMA in the start() routine, the MAC will start fetching TX descriptors prematurely, as it can be seen by dumping the TX_DMA_STA and TX_DMA_CUR_DESC registers. Clear the owner bit, to not give the MAC the wrong illusion that it owns the descriptors already. Signed-off-by:
Andre Przywara <andre.przywara@arm.com> Acked-by:
Maxime Ripard <mripard@kernel.org> Tested-by: Amit Singh Tomar <amittomer25@gmail.com> # Pine64+ Reviewed-by:
Jagan Teki <jagan@amarulasolutions.com>
-
When phy_startup() returns with an error, because there is no link or the user interrupted the process, we shall stop the _start() routine and return with an error, instead of proceeding anyway. This fixes pointless operations when there is no Ethernet cable connected, for instance. Signed-off-by:
Andre Przywara <andre.przywara@arm.com> Acked-by:
Maxime Ripard <mripard@kernel.org> Tested-by: Amit Singh Tomar <amittomer25@gmail.com> # Pine64+ Reviewed-by:
Jagan Teki <jagan@amarulasolutions.com>
-
- Oct 19, 2020
-
-
https://gitlab.denx.de/u-boot/custodians/u-boot-atmelTom Rini authored
Second set of u-boot-atmel features for 2021.01 cycle: This feature set brings the rework of the clock tree for sam9x60 SoC. This makes the clock tree fully compatible with Common Clock Framework and allows full clock configuration in U-Boot. This means that the sam9x60 boards can boot now using U-Boot. This also includes the definitions for sam9x60 SiPs and a divisor fix for the clock on sama7g5 SoC.
-
Eugen Hristev authored
This SoC has the 5th divisor for the mck0 master clock. Adapt the characteristics accordingly. Reported-by:
Mihai Sain <mihai.sain@microchip.com> Signed-off-by:
Eugen Hristev <eugen.hristev@microchip.com> Reviewed-by:
Claudiu Beznea <claudiu.beznea@microchip.com>
-
Eugen Hristev authored
clk-master can have 5 divisors with a field width of 3 bits on some products. Change the mask and number of divisors accordingly. Reported-by:
Mihai Sain <mihai.sain@microchip.com> Signed-off-by:
Eugen Hristev <eugen.hristev@microchip.com> Reviewed-by:
Claudiu Beznea <claudiu.beznea@microchip.com>
-
Nicolas Ferre authored
SAM9X60 SiP (System in Package) are added for SoC identification. Signed-off-by:
Nicolas Ferre <nicolas.ferre@microchip.com>
-
Claudiu Beznea authored
Use alphabetical order for entries in sam9x60ek-u-boot.dtsi Signed-off-by:
Claudiu Beznea <claudiu.beznea@microchip.com>
-
Claudiu Beznea authored
Update defconfigs for using common clock framework compatible clocks. Signed-off-by:
Claudiu Beznea <claudiu.beznea@microchip.com>
-
Claudiu Beznea authored
Use CCF compatible for PMC. With this, the board/SoC will be able to boot. Signed-off-by:
Claudiu Beznea <claudiu.beznea@microchip.com>
-
Claudiu Beznea authored
Use slow clock CCF compatible DT bindings. This will not break the above functionality as the SoC is not booting with current PMC bindings. Signed-off-by:
Claudiu Beznea <claudiu.beznea@microchip.com>
-
Claudiu Beznea authored
Use u-boot,dm-pre-reloc for slow xtal and main xtal. Signed-off-by:
Claudiu Beznea <claudiu.beznea@microchip.com>
-
Claudiu Beznea authored
Slow Xtal and Main Xtal are board specific. Add their proper frequency to board file. Signed-off-by:
Claudiu Beznea <claudiu.beznea@microchip.com>
-
Claudiu Beznea authored
Add SAM9X60 clock support compatible with CCF. Signed-off-by:
Claudiu Beznea <claudiu.beznea@microchip.com>
-
Claudiu Beznea authored
Heap base address is computed based on SYS_INIT_SP_ADDR by subtracting the SYS_MALLOC_F_LEN value in board_init_f_init_reserve(). Signed-off-by:
Claudiu Beznea <claudiu.beznea@microchip.com>
-
https://gitlab.denx.de/u-boot/custodians/u-boot-videoTom Rini authored
- add dw-mipi-dsi phy timings and Tx escape clock configuration - fix pwm backlight duty cycle calculation - migrate CONFIG_VIDEO_BMP_* and CONFIG_BMP_* to Kconfig
-
- Oct 18, 2020
-
-
Done with: ./tools/moveconfig.py BMP_16BPP BMP_24BPP BMP_32BPP Signed-off-by:
Patrick Delaunay <patrick.delaunay@st.com> Reviewed-by:
Simon Glass <sjg@chromium.org>
-
Done with: ./tools/moveconfig.py VIDEO_BMP_RLE8 Signed-off-by:
Patrick Delaunay <patrick.delaunay@st.com> Reviewed-by:
Simon Glass <sjg@chromium.org>
-
Done with: ./tools/moveconfig.py VIDEO_BMP_GZIP The 3 suspicious migration because CMD_BMP and SPLASH_SCREEN are not activated in these defconfigs: - trats_defconfig - s5pc210_universal_defconfig - trats2_defconfig Signed-off-by:
Patrick Delaunay <patrick.delaunay@st.com> Reviewed-by:
Simon Glass <sjg@chromium.org>
-
For levels equal to the maximum value, the duty cycle must be equal to the period. Signed-off-by:
Dario Binacchi <dariobin@libero.it> Reviewed-by:
Simon Glass <sjg@chromium.org>
-
The description of the 'max_level' field was incorrectly assigned to the 'min_level' field. Signed-off-by:
Dario Binacchi <dariobin@libero.it>
-
The Amlogic D-PHY in the Amlogic AXG SoC Family does support a frequency higher than 10MHz for the TX Escape Clock, thus make the target rate configurable. This is based on the Linux commit [1] and adapted to the U-Boot driver. [1] a328ca7e4af3 ("drm/bridge: dw-mipi-dsi: permit configuring the escape clock rate") Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com>
-
The timing values for dw-dsi are often dependent on the used display and according to Philippe Cornu will most likely also depend on the used phy technology in the soc-specific implementation. To solve this and allow specific implementations to define them as needed add a new get_timing callback to phy_ops and call this from the dphy_timing function to retrieve the necessary values for the specific mode. This is based on the Linux commit [1] and adapted to the U-Boot driver. [1] 25ed8aeb9c39 ("drm/bridge/synopsys: dsi: driver-specific configuration of phy timings") Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com>
-
- Oct 17, 2020
-
-
syslog_test.h is in test/log/, not include/ Fixes: 52d3df7f ("log: Allow LOG_DEBUG to always enable log output") Signed-off-by:
Sean Anderson <seanga2@gmail.com> Reviewed-by:
Simon Glass <sjg@chromium.org>
-
- Oct 16, 2020
-
-
https://gitlab.denx.de/u-boot/custodians/u-boot-marvellTom Rini authored
- Fix Octeon SPI driver for Octeon TX2 - Fix and enhance Octeon watchdog driver - Misc minor enhancements to Octeon TX/TX2
-
Tom Rini authored
- Bring in the next round of dev_xxx cleanup patches.
-
Now that linux/compat.h does not define these macros, we do not need to undefine them. Signed-off-by:
Sean Anderson <seanga2@gmail.com> Reviewed-by:
Simon Glass <sjg@chromium.org>
-
All users of these functions now include dm/device_compat.h directly. Signed-off-by:
Sean Anderson <seanga2@gmail.com> Reviewed-by:
Simon Glass <sjg@chromium.org>
-
Tom Rini authored
Necessary for dev_xxx. Signed-off-by:
Tom Rini <trini@konsulko.com>
-