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

Marek Vasut
2017-04-18T16:53:21Z

On 04/18/2017 05:46 PM, Cédric Le Goater wrote:
> 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 ?

Can we use the spi max frequency which is a standard property and be
done with it ?

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

I cannot tell, you're the expert :)

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

Can we also use the spi-max-frequency here somehow ?

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

--
Best regards,
Marek Vasut