On 2019/3/11 4:25, Avri Altman wrote:
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
Sure, will post a normal patch if got ready and reword it.
(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.
Thanks,
Avri
