> >>>> 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 Behide = behind > >>>> 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). Maybe you could reword paragraph (1) - It is hard to follow your line of reasoning > >>>> > >>>> (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. Ack on that. Thanks, Avri
