u-boot.git/arch/arm/include, branch v2020.04

Merge branch 'master' of https://gitlab.denx.de/u-boot/custodians/u-boot-tegra

2020-04-03T20:05:46Z

- Add support for Jetson Nano, plus miscellaneous other fixes found during Nano bringup. - Add Igor's update_uboot wrapper patches.

mmc: t210: Fix 'bad' SD-card clock when doing 400KHz card detect

2020-04-02T21:30:01Z

According to the HW team, for some reason the normal clock select code picks what appears to be a perfectly valid 375KHz SD card clock, based on the CAR clock source and SDMMC1 controller register settings (CAR = 408MHz PLLP0 divided by 68 for 6MHz, then a SD Clock Control register divisor of 16 = 375KHz). But the resulting SD card clock, as measured by the HW team, is 700KHz, which is out-of-spec. So the WAR is to use the values given in the TRM PLLP table to generate a 400KHz SD-clock (CAR clock of 24.7MHz, SD Clock Control divisor of 62) only for SDMMC1 on T210 when the requested clock is <= 400KHz. Note that as far as I can tell, the other requests for clocks in the Tegra MMC driver result in valid SD clocks. Signed-off-by: Tom Warren Reviewed-by: Jaehoon Chung

mmc: t210: Add autocal and tap/trim updates for SDMMC1/3

2020-04-02T21:30:01Z

As per the T210 TRM, when running at 3.3v, the SDMMC1 tap/trim and autocal values need to be set to condition the signals correctly before talking to the SD-card. This is the same as what's being done in CBoot, but it gets reset when the SDMMC1 HW is soft-reset during SD driver init, so needs to be repeated here. Also set autocal and tap/trim for SDMMC3, although no T210 boards use it for SD-card at this time. Signed-off-by: Tom Warren Reviewed-by: Jaehoon Chung

t210: do not enable PLLE and UPHY PLL HW PWRSEQ

2020-04-02T21:30:01Z

This commit removes the programming sequence that enables PLLE and UPHY PLL hardware power sequencers. Per TRM, boot software should enable PLLE and UPHY PLLs in software controlled power-on state and should power down PLL before jumping into kernel or the next stage boot software. Adds call to board_cleanup_before_linux to facilitate this. Signed-off-by: JC Kuo Signed-off-by: Tom Warren Acked-by: Stephen Warren

video: rockchip: Fix vop modes for rk3399

2020-04-02T13:47:35Z

VOP display endpoint pipeline configuration differs between rk3288 vs rk3399. These VOP pipeline configuration depends on how the different display interfaces connected in sequence to IN and OUT ports like for, RK3288: vopb_out: port { #address-cells = <1>; #size-cells = <0>; vopb_out_edp: endpoint@0 { reg = <0>; remote-endpoint = <&edp_in_vopb>; }; vopb_out_hdmi: endpoint@1 { reg = <1>; remote-endpoint = <&hdmi_in_vopb>; }; vopb_out_lvds: endpoint@2 { reg = <2>; remote-endpoint = <&lvds_in_vopb>; }; vopb_out_mipi: endpoint@3 { reg = <3>; remote-endpoint = <&mipi_in_vopb>; }; }; RK3399: vopb_out: port { #address-cells = <1>; #size-cells = <0>; vopb_out_edp: endpoint@0 { reg = <0>; remote-endpoint = <&edp_in_vopb>; }; vopb_out_mipi: endpoint@1 { reg = <1>; remote-endpoint = <&mipi_in_vopb>; }; vopb_out_hdmi: endpoint@2 { reg = <2>; remote-endpoint = <&hdmi_in_vopb>; }; vopb_out_mipi1: endpoint@3 { reg = <3>; remote-endpoint = <&mipi1_in_vopb>; }; vopb_out_dp: endpoint@4 { reg = <4>; remote-endpoint = <&dp_in_vopb>; }; }; here, HDMI interface has endpoint 1 in rk3288 and 2 in rk3399. The rockchip vop driver often depends on this determined endpoint number and stored in vop_mode. So based on this vop_mode the bpp and pin polarity would configure on detected display interface. Since, the existing driver using rk3288 vop mode settings enabling the same will result wrong display interface configuration for rk3399. Add the patch for fixing these vop modes for rk3399. Signed-off-by: Jagan Teki Reviewed-by: Kever Yang Tested-by: Peter Robinson

dm: arm64: ls1046a: add i2c DM support

2020-03-30T02:42:13Z

This supports i2c DM and enables CONFIG_DM_I2C for SoC LS1046A Signed-off-by: Biwen Li Signed-off-by: Priyanka Jain

dm: arm64: ls1043a: add i2c DM support

2020-03-30T02:42:13Z

This supports i2c DM and enables CONFIG_DM_I2C for SoC LS1043A Signed-off-by: Biwen Li Signed-off-by: Priyanka Jain

dma-mapping: move dma_map_(un)single() to

2020-02-19T13:27:30Z

The implementation of dma_map_single() and dma_unmap_single() is exactly the same for all the architectures that support them. Factor them out to , and make all drivers to include instead of . If we need to differentiate them for some architectures, we can move the generic definitions to . Add some comments to the helpers. The concept is quite similar to the DMA-API of Linux kernel. Drivers are agnostic about what is going on behind the scene. Just call dma_map_single() before the DMA, and dma_unmap_single() after it. Signed-off-by: Masahiro Yamada

dma-mapping: fix the prototype of dma_unmap_single()

2020-02-19T13:27:30Z

dma_unmap_single() takes the dma address, not virtual address. Signed-off-by: Masahiro Yamada

dma-mapping: fix the prototype of dma_map_single()

2020-02-19T13:27:30Z

Make dma_map_single() return the dma address, and remove the pointless volatile. Signed-off-by: Masahiro Yamada