On 4 February 2016 at 10:12, Carlo Caione <carlo@xxxxxxxxxx> wrote: > On Wed, Feb 3, 2016 at 11:46 AM, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote: >> On 2 February 2016 at 22:54, Carlo Caione <carlo@xxxxxxxxxx> wrote: > > [cut] > >> Huh, another broken MMC controller. :-) > > Oh, actually I found in the datasheet a couple of undocumented > registers (also not used in the original Amlogic SDK code) that seems > to have something to do with timeout (hard to say without proper > documentation but they are called "Timeout counter for preload setting > and present status" and "Timeout Counter Interrupt Enable for ARC/ARM" > so I guess I'm on the right track here). > I briefly tried yesterday to enable this timeout interrupt with a > dummy value in the counter register (I have no idea how get this value > from the clocking) and it seems working (the counter value is > decremented when reading the register upon command completion). Let's hope this works, as this will for sure be a better solution. > >> In some cases there are no data in the request, it's just a command >> being sent. So to deal with this issue, you will have to adjust the >> timer depending on the request we send to the controller. > > I see that the CMD13 used to poll the card has no data so in that case > should we use a fixed / dummy value to use as timeout counter? > I'm kind of confused here since the MMC drivers I'm looking at use the > hardware timeout register only when the data->timeout_ns is actually > present. That's a different timeout value. It's elated to *each* block data transfer and not the entire request. So it provides information to the controller about what delays it shall accept during a block being written/read. More details is found in the electrical descriptions of the interface in the eMMC/SD spec. 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
