> > On 2019/3/6 16:48, Ulf Hansson wrote: > > On Wed, 6 Mar 2019 at 01:45, Shawn Lin <shawn.lin@xxxxxxxxxxxxxx> > wrote: > >> > >> Hi Ulf > >> > >> On 2019/3/5 17:31, Ulf Hansson wrote: > >>> On Fri, 1 Mar 2019 at 08:58, Shawn Lin <shawn.lin@xxxxxxxxxxxxxx> > wrote: > >>>> > >>>> This caps2 is to skip doing memory compare tuning block > >>>> pattern with the received data from devices when doing > >>>> tuning. > >>>> > >>>> The data from device is all formatted like: > >>>> Start bit + data + CRC + End bit > >>>> > >>>> For normal data read, we just verify host sample the data > >>>> w/o any errors, but not need care the data context. But for > >>>> a tuning process, we now compare the data context with JEDEC > >>>> pattern. I highly suspect the rational behide it for the following > >>>> details: > >>>> > >>>> (1) The tuning process is mostly used for identifing the rational > >>>> sample window, so if the host read the tuning block successfully > >>>> like a noraml data read, isn't it enough for sure that *this* single > >>>> sample phase is good to work, no? The original patch to support it > >>>> didn't quote any spec details but let's see the JESD84-B51, section > 6.6.5, > >>>> "Bus Sampling Tuning Concept" just says "This example is given for > >>>> concept explanation purpose. The Host may use any other > implementation > >>>> according to its design consideration. " The concept isn't the order, > >>>> and whether the MMC core need to verify the tuning block? See my > argue (2). > >>>> > >>>> (2) AFAICT, the tuning block is handled by a fixed HW module within > >>>> the device, if a JEDEC compatible device receive tuning block cmd and > >>>> response it, could it sends back a non-compatible tuning block? > >>> > >>> It's hard to tell whether the above makes sense. I think only the HW > >>> designers can give us a good answer on this, have you talked with > >>> someone that can confirm your analyze? > >>> > >> > >> I haven't talked with HW designers from device vendors. > > > > You don't need to card vendors, but your own HW guys that develops > > your mmc controller. But, I assume you have done that, just wanted to > > confirm it!? > > yes, I did. I can also consult our device hw designers, maybe they can provide some further insight. Please allow a day or two for that. Thanks, Avri
