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

[Cédric Le Goater]

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.
>