On Wed, Jun 15, 2011 at 7:57 AM, <subhashj@xxxxxxxxxxxxxx> wrote: > Hi Arindam, > >> -----Original Message----- >> From: linux-mmc-owner@xxxxxxxxxxxxxxx [mailto:linux-mmc- >> owner@xxxxxxxxxxxxxxx] On Behalf Of Nath, Arindam >> Sent: Tuesday, June 14, 2011 12:00 AM >> To: subhashj@xxxxxxxxxxxxxx >> Cc: Philip Rakity; zhangfei gao; cjb@xxxxxxxxxx; linux- >> mmc@xxxxxxxxxxxxxxx; Lu, Aaron >> Subject: RE: UHS-I bus speed mode should be set last in UHS >> initialization >> >> Adding Philip and Zhangfei. >> >> Hi Subhash, >> >> Does your controller follow some non-standard steps for initialization? >> I referred to Figure 3-14, section 3.9.4 of Physical Layer Spec v3.01, >> and it shows the order, setting Driver Strength Select, Bus Speed Mode, >> and then Current Limit. So please confirm back. > > Sorry, I don't know what do you mean by non standard steps for > initialization. Nowhere in v3.01 spec, it is mentioned that Bus speed mode > **must** be set before current limit. Figure 3-14 also doesn't indicate > this. > > If you set the bus speed mode in sd_set_bus_speed_mode(), you are changing > the host controller timings as well and if it's SDR50/SDR104 mode, then > immediately after setting the host controller timing mode, we have to > execute tuning sequence but here before executing tuning sequence, you are > sending the CMD6 which involves the read data transfer from card which is > bound to fail without tuning and it does fail with our host controller. > > Do let me know if this explanation make sense. I think the concern does make sense. Though Figure 3-14 and 4-6 describe Bus Speed Mode is selected ahead of Current limit, the controller timing is changed in sd_set_bus_speed_mode, which may cause following cmd6 fail. However, the test here shows mmp2 does not care the sequence of speed_mode and current_limit. Thanks -- 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
