On Monday 29 August 2016, Alan Cooper wrote: > I think there's some confusion over the core issue so let be summarize. > The SDHCI host controller CAPABILITIES register bit 28 indicates if > the host controller hardware can support 64 bit addresses using the > larger 96 bit DMA descriptors. We currently don't have any SoCs that > have this support, even our current 64bit ARM SoCs don't support this, > though there are future ARM SoCs that will have this support. The bug > is that a few MIPS based SoCs had this bit incorrectly set even though > the hardware did not support it and this caused the driver to use the > larger DMA descriptors which crashed the driver. All we're trying to > fix here is a simple SDHCI host controller hardware bug where a CAPs > bit is a 1 where it should be a 0. Our future 64 ARM chips that do > support 64bit addressing should be the only chips with this bit set. Ok, got it. Thanks for the clarification. So the SDHCI device claims to have a capability that doesn't work, rather than correctly listing a property that works in principle but is prevented from working by something outside of the device as we discussed another time [1] If this happens in other chips as well, I guess we could also solve this by changing the code to only enable the 64-bit ADMA feature when dma_get_required_mask() returns something larger than a 32-bit mask. This would also be (very slightly) more efficient because we have to access fewer registers per transfer. Arnd [1] http://marc.info/?l=linux-mmc&m=141457290627820&w=2 -- 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
