Re: [PATCH 24/24] mtd: spinand: winbond: Add support for DTR operations

[Miquel Raynal <miquel.raynal@bootlin.com>]

Hello Tudor,

On 23/12/2024 at 19:22:12 +01, Miquel Raynal <miquel.raynal@bootlin.com> wrote:

> Hello Tudor,
>
> On 11/11/2024 at 14:40:59 GMT, Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>
>> On 10/25/24 5:15 PM, Miquel Raynal wrote:
>>> W25N01JW and W25N02JW support many DTR read modes in single, dual and
>>> quad configurations.
>>> 
>>> DTR modes however cannot be used at 166MHz, as the bus frequency in
>>> this case must be lowered to 80MHz.
>>
>> ha, what's the benefit then? Aren't we better of with non dtr modes
>> then? 80 MHz * 2 < 166 MHz?
>
> This is actually a good question, and you are right DDR in this case
> does not bring better throughputs, it can even make it a little bit
> slower. I think however we should expect some gains at the PCB design
> step, which may be way simpler as routing 8 166MHz lines might
> apparently be challenging. It is common to have PCB limitations on the
> frequency, so enabling DDR can be a great way to keep signal integrity
> while definitely improving the performances. However, you're right, I
> should probably move these definitions lower in the table to make sure
> we run at 166MHz if that's possible.

Actually this is probably not a good solution. This stable is parsed
once from top to bottom. The elements order decide whether we'll use a
variant or another, not by deciding which one is the fastest, but by
taking the first one that fits. But with DTR operations it no longer
works so well. If I list items like that:

SPINAND_PAGE_READ_FROM_CACHE_QUADIO_DTR_OP(0, 8, NULL, 0, 80 * HZ_PER_MHZ),
SPINAND_PAGE_READ_FROM_CACHE_QUADIO_OP(0, 2, NULL, 0 /* 166 MHz */),

It is likely that I will not run at the fastest possible throughput, ie
about 160MHz instead of 166MHz. But if I do the reverse:

SPINAND_PAGE_READ_FROM_CACHE_QUADIO_OP(0, 2, NULL, 0 /* 166 MHz */),
SPINAND_PAGE_READ_FROM_CACHE_QUADIO_DTR_OP(0, 8, NULL, 0, 80 * HZ_PER_MHZ),

I will only run at the fastest throughput if the PCB lines are so well
designed that they can support 166MHz. If they only support 150MHz (or
anything lower) it would have been better to pick the DTR op.

My conclusion is: the current logic needs to be improved, so I'm
drafting a slightly more complex variant picker which will evaluate the
theoretical length of an op based on the speed, parallel lines, DTR
capability, etc. This way the order in this table will no longer matter.

I will soon respin a series because I've enhanced a lot of things
inside.

Cheers,
Miquèl

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/