Re: [PATCH 10/10] mtd: spi-nor: aspeed: optimize read mode

Cédric Le Goater
2017-04-18T15:47:06Z

On 04/15/2017 12:42 AM, Benjamin Herrenschmidt wrote:
> On Sat, 2017-04-15 at 00:25 +0200, Marek Vasut wrote:
>> That sounds like a good option, yes. And if it's just forcing fixed
>> speed, that's awesome, but I think there are more values that might need
>> to be passed ... I think that's what Cedric can answer.
>
> Yes, fixed and delay. Not a huge deal.

Do we really need to specify the delays in the DT ? As we loop on
the different delay settings, if a setting is bogus, we can just
pick the following HCLK divider. No ? I don't think it is worth
adding black magic properties like this in the DT. We never had to
tune it manually AFAICT and anyway, we can always add that later
if needed.

So, that would leave two properties :

- safe divider for "normal/write/erase" commands
- speedy divider for "read" commands

If the property is not present, we would keep the low HW default,
which is /16.

If there is such a property, the divider value would be considered
as a max. The range should be 1..5. Let's introduce "literal" values
like "min" and "max" for 1 and 5 ?

Do we care for the other HCLK settings < 5 for which we can not set
any delay ?

> Also a module parameter makes it hard to specify different settings for
> different instances of the device/flash. IE, there can be multiple
> flash controllers and each of them can have multiple chip selects.
>
> The DT is the only sane way for that.

Yes. Can we keep the global module parameter as a global chicken
switch to deactivate the algo ? It could be useful, some chips tend
to freak out when hammered on a bit too much.

Thanks,

C.

>>> That becomes akin to what we do with Ethernet PHYs for example :)
>>
>> Even better, I recall seeing some speed DT props in the SPI binding
>> docs, so we already have those in place.
>
> Right though the gate delay is rather IP block specific but that's
> not a huge issue.
>
> Cheers,
> Ben.
>