On Tuesday 01 March 2016 13:32:44 Alexandre Courbot wrote:
> On T210, the sdhci controller can address more than 32 bits of address
> space. Failing to express this fact results in the use of bounce
> buffers and affects performance.
>
> Signed-off-by: Alexandre Courbot <acourbot@xxxxxxxxxx>
I don't get this one. Why don't you just set the (SDHCI_USE_SDMA | SDHCI_USE_ADMA)
flags that are checked in the first patch?
> @@ -289,6 +291,7 @@ static const struct sdhci_tegra_soc_data soc_data_tegra20 = {
> .pdata = &sdhci_tegra20_pdata,
> .nvquirks = NVQUIRK_FORCE_SDHCI_SPEC_200 |
> NVQUIRK_ENABLE_BLOCK_GAP_DET,
> + .dma_mask = DMA_BIT_MASK(32),
> };
Can you describe what the specific bug is in these controllers? Do you mean they
support SDHCI_USE_SDMA or SDHCI_USE_ADMA in theory but you still have to prevent
them from using high addresses?
> @@ -353,6 +358,7 @@ static const struct sdhci_pltfm_data sdhci_tegra210_pdata = {
>
> static const struct sdhci_tegra_soc_data soc_data_tegra210 = {
> .pdata = &sdhci_tegra210_pdata,
> + .dma_mask = DMA_BIT_MASK(34),
> };
>
> static const struct of_device_id sdhci_tegra_dt_match[] = {
This one still completely weirds me out. What kind of odd limitation does
the controller have in Tegra 210?
Are there actually any machines with more than 16GB?
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
