On Dec 8, 2015 6:11 AM, "Ulf Hansson" <ulf.hansson@xxxxxxxxxx> wrote: > > On 4 December 2015 at 21:34, Daniel Lenski <dlenski@xxxxxxxxx> wrote: > > In conclusion... it seems that the kernel is attempting to drive this > > card faster than it can actually work. What I'm trying to figure out > > now: > > - How does the kernel attempt to figure out the capability of a given > > SD card? Where is that in the kernel source tree? > > drivers/mmc/core/* > > It's kind of complicated, but please go ahead and have a look. Will do. > > - Is it possible to make the list of supported caps a module > > parameter, to more easily throttle high-speed modes that don't work > > with a particular card? > > Maybe a sysfs/debugfs interface would be better, but I like the idea! > > Currently there is no way for userspace to disable some of these > "speed mode" caps, which would be very useful in cases like yours. > > I don't know if I ever will get time to hack on such code, so feel > free to have a try yourself! Ideally, would it be better to have a userspace control at the level of the individual host control drivers, or for the entire mmc/SD subsystem? > Regarding how to fix this problem right now, I guess we should remove > the caps which the host driver wrongly claims to support. Do you want > to send a patch for that? I can do that, but am unsure whether it is truly an issue with the host driver, or the card itself, in my case. Is there any information which I can use to clearly rule one or the other case out? If I understood Marcus Overhagen's original post correctly, he was successful with a UHS SDHC card and this same controller. Thanks, Dan -- 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
