[...] > Well I think we still have a very small sample size, the sun4i, sun5i and > sun7i boards (all using the same mmc controller afaik) have the broken-hpi > set, the sun6i and sun8i seem to be working fine (different mmc > controller?). > I'm not so sure it is an eMMC specific problem though. The module we're > using is a high-end micron part, industrial grade. Granted, it could be > still broken there, but I find it less likely. Micron has an interessting > technical document: > "TN-52-05 e.EMMC Linux Enablement" > talking specifically about HPI on eMMC. > It also mentions HPI is a mmc/jedic 4.41 thing, afaik our controller is only > 4.3 (which might not even matter according to Ulf if it is just a command). > > The datasheet of the chip I use, MTFC4GACAANA, also mentions explicitly that > it supports HPI. > > Granted, it could still be broken, but I have doubts. Perhaps the same eMMC is used without errors on other controllers? > >> >> But given how rare eMMC-s are on sun4i/sun5i/sun7i I think the current >> solution where we set a flag on the emmc dt node rather then on the >> host node / in the host driver is fine. > > Yeah it is very limited, that is true, and I suppose I can live with that. >> >> >> Taking your case into account too, that will bring us up to 2 cases >> where we set the broken-hpi flag on the emmc node, which does not >> really seem like a number to worry about. > > Actually, 4 :), there are 3 sun5i (tablets?) devices that suffer from this > and my device now. The sun6i and sun8i devices are only 2 (the sinlinx > devices in the current kernel) that a very quick grep (mmc-card ) showed. > Grepping for non-removable yielded a bit more, like the chip sun5i-like > device with a "non-removable" mmc, not sure what to make of that though. >> >> >> TL;DR: Thanks for writing this patch set, but given recent developments >> I believe that it is best to keep handling broken-hpi as we are doing >> in current kernels and no changes are necessary. > > I would still recommend to add the capability and raise the flag for the > sun[457]i devices though, as my gut thinks it's a problem with the sunxi IP > there. But with the emmc-card level work around, it does solve/fix it, so > what is the best way? The best is clearly to make a proper debug investigation before we decide to add a DT binding for the host. I don't know on what level you are able to measure signals on the HW, but if not, perhaps the newly TRACE support in the MMC core can help. Kind regards Uffe -- 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
