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 <twarren@nvidia.com> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
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 <twarren@nvidia.com> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
The 4 bit MMC controllers have an internal debounce for the SDCD line with a debounce delay of 1 second. Therefore, after clocks to the IP are enabled, software has to wait for this time before it can power on the controller. Add a deferred_probe() callback which polls on sdcd for a maximum of 2 seconds before switching on power to the controller or (in the case of no card) returning a ENOMEDIUM. This pushes the 1 second wait time to when the card is actually needed rather than at every probe() making sure that users who don't insert an SD card in the slot don't have to wait such a long time. Signed-off-by: Faiz Abbas <faiz_abbas@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
With the latest RIOT, there is a different otap delay value for each speed mode. Add a new binding with every supported speed mode. Also disable a given speed mode in the host caps if its corresponding otap-del-sel is not present. Signed-off-by: Faiz Abbas <faiz_abbas@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
MMC_LEGACY & SD_LEGACY are not differentiated timings in the spec and don't have any meaningful differences. Therefore, get rid of all references to SD_LEGACY and use MMC_LEGACY to mean both of them. Signed-off-by: Faiz Abbas <faiz_abbas@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Add the sdhci_deferred_probe() function to register as the deferred_probe() callback to the mmc core. It will in turn call the deferred_probe() callback of the platform drivers as declared in the sdhci_ops. Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Add a deferred_probe() API for platforms that want to do some configurations just before starting to enumerate the device. Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Initial DesignWare based DM 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>
This driver currently performs cache operation before the DMA start, but does nothing after the DMA completion. When reading data by DMA, the cache invalidation is needed also after finishing the DMA transfer. Otherwise, the CPU might read data from the cache instead of from the main memory when speculative memory read or memory prefetch occurs. Instead of calling the cache operation directly, this commit adds dma_unmap_single(), which performs cache invalidation internally, but drivers do not need which operation is being run. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Currently, sdhci_prepare_dma() calls flush_cache() regardless of the DMA direction. Actually, cache invalidation is enough when reading data from the device. This is correctly handled by dma_map_single(), which mimics the DMA-API in Linux kernel. Drivers can be agnostic which cache operation occurs behind the scene. This commit also sanitizes the difference between the virtual address and the dma address. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>