On 2021-02-05 23:08, Bean Huo wrote:
On Fri, 2021-02-05 at 14:06 +0000, Avri Altman wrote:
> > > + put_unaligned_be64(ppn, &cdb[6]);
> >
> > You are assuming the HPB entries read out by "HPB Read Buffer"
> > cmd
> > are
> > in Little
> > Endian, which is why you are using put_unaligned_be64 here.
> > However,
> > this assumption
> > is not right for all the other flash vendors - HPB entries read
> > out
> > by
> > "HPB Read Buffer"
> > cmd may come in Big Endian, if so, their random read performance
> > are
> > screwed.
>
> For this question, it is very hard to make a correct format since
> the
> Spec doesn't give a clear definition. Should we have a default
> format,
> if there is conflict, and then add quirk or add a vendor-specific
> table?
>
> Hi Avri
> Do you have a good idea?
I don't know. Better let Daejun answer this.
This was working for me for both Galaxy S20 (Exynos) as well as
Xiaomi Mi10 (8250).
Thanks, I tested Daejun's patchset before, it is also ok (I don't know
which version patchset). maybe we can keep current implementation as
default, then if there is conflict, and submit the quirk.
Yeah, you've tested it, are you sure that Micron's UFS devices are OK
with this specific code line?
Micron UFS FW team has confirmed that Micron's HPB entries read out by
"HPB Buffer Read" cmd are in big-endian byte ordering.
If Micron FW team is right, I am pretty sure that you would have seen
random read performance regression on Micron UFS devices caused by
invalid HPB entry format in HPB Read cmd UPIU (which leads to L2P cache
miss in device side all the time) during your test.
Can Guo.
Thanks,
Bean
Thanks,
Avri
