MMC core expects (now) valid mmc->dev pointer. During conversion in commit cffe5d86 not every driver was updated. This patch fixes crash while accessing MMC on boards using Qualcomm SDHCI controller. Signed-off-by: Mateusz Kulikowski <mateusz.kulikowski@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
Return value of rtl_send_common propogates unmodified all the way up to eth_send and further to API consumer if CONFIG_API is enabled. Previously rtl_send_common returned number of bytes sent on success which was erroneouly detected as error condition by API consumers that checked for operation success by comparing return value with 0. Switch rtl_send_common to use common convention: return 0 on success and negative value for failure. Cc: Stephen Warren <swarren@nvidia.com> Cc: Joe Hershberger <joe.hershberger@ni.com> Signed-off-by: Oleksandr Tymoshenko <gonzo@bluezbox.com> Reviewed-by: Simon Glass <sjg@chromium.org> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
This patch adds support for aquantia AQR106/107 PHY. Signed-off-by: Mingkai Hu <mingkai.hu@nxp.com> Signed-off-by: Gong Qianyu <Qianyu.Gong@nxp.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Commit 90b7fc924adf "net: designware: support phy reset device-tree bindings" made DW GMAC driver dependent on DM_GPIO by unconditional usage of purely DM_GPIO stuff like: * dm_gpio_XXX() * gpio_request_by_name() But since that driver as of today might be easily used without DM_GPIO (that's the case for Synopsys AXS10x boards) we're shielding all DM_GPIO things by ifdefs. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: Simon Glass <sjg@chromium.org> Cc: Beniamino Galvani <b.galvani@gmail.com> Cc: Joe Hershberger <joe.hershberger@ni.com> Cc: Sjoerd Simons <sjoerd.simons@collabora.co.uk> Cc: Sonic Zhang <sonic.zhang@analog.com> Cc: Bin Meng <bmeng.cn@gmail.com> Cc: Marek Vasut <marex@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
This seems to give the best performance, so let's use it always. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
We have standard drivers for panels and backlights which can do most of the work for us. Move the tegra20 LCD driver over to use those instead of custom code. This patch includes device tree changes for the nvidia boards. I have only been able to test seaboard. If this patch is applied, these boards will also need to be synced with the kernel, and updated to use display-timings: - colibri - medcom-wide - paz00 - tec Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Warren <twarren@nvidia.com>
On recent SoCs, tegra_pcie_phy_enable() isn't called; but instead tegra_pcie_enable_controller() calls tegra_xusb_phy_enable(). However, part of tegra_pcie_phy_enable() needs to happen in all cases. Move that code to tegra_pcie_port_enable() instead. For reference, NVIDIA's downstream Linux kernel performs this operation in tegra_pcie_enable_rp_features(), which is called immediately after tegra_pcie_port_enable(). Since that function doesn't exist in the U-Boot driver, we'll just add it to the tail of tegra_pcie_port_enable() instead. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
The value that should be programmed into the PADS_REFCLK register varies per SoC. Fix the Tegra PCIe driver to program the correct values. Future SoCs will require different values in cfg0/1, so the two values are stored separately in the per-SoC data structures. For reference, the values are all documented in NV bug 1771116 comment 20. The Tegra210 value doesn't match the current TRM, but I've filed a bug to get the TRM fixed. Earlier TRMs don't document the value this register should contain, but the ASIC team has validated all these values, except for the Tegra20 value which is simply left unchanged in this patch. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>