[PATCH dev-5.0 1/4] mtd: spi-nor: aspeed: introduce a aspeed_smc_default_read() helper

Cédric Le Goater clg at kaod.org
Thu Apr 18 16:23:30 AEST 2019


On 4/18/19 8:07 AM, Andrew Jeffery wrote:
> 
> 
> On Thu, 18 Apr 2019, at 03:40, Alexander Amelkin wrote:
>> 17.04.2019 16:39, Cédric Le Goater wrote:
>>> Signed-off-by: Cédric Le Goater <clg at kaod.org>
>>> ---
>>>  drivers/mtd/spi-nor/aspeed-smc.c | 19 ++++++++++++-------
>>>  1 file changed, 12 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/drivers/mtd/spi-nor/aspeed-smc.c b/drivers/mtd/spi-nor/aspeed-smc.c
>>> index ddf7ae78aa0a..ee3059b27c07 100644
>>> --- a/drivers/mtd/spi-nor/aspeed-smc.c
>>> +++ b/drivers/mtd/spi-nor/aspeed-smc.c
>>> @@ -882,6 +882,17 @@ static const uint32_t aspeed_smc_hclk_divs[] = {
>>>  };
>>>  #define ASPEED_SMC_HCLK_DIV(i) (aspeed_smc_hclk_divs[(i) - 1] << 8)
>>>  
>>> +static u32 aspeed_smc_default_read(struct aspeed_smc_chip *chip)
>>> +{
>>> +	return (chip->ctl_val[smc_read] & 0x2000) |
>>
>> Cédric, isn't this a good time to get rid of these cached ctl_val values?
>>
>> Why not read/modify/store the actual register?
>>
>> What's the profit of this caching?

These values are computed when the controller is probed and when 
the chip devices are scanned (which takes a couple of seconds to 
do the training). They are the default values used when the flash 
contents is accessed through the flash MMIO window. 

When in User mode, for register operation, erase, write, other 
values are used, see read/write_reg operations, and we don't want 
to recompute the same values, it takes time and the HW has not 
changed anyhow.

It is also safer as some FW still hack the value in the back of 
the Linux driver so we should not trust how the HW has been 
configured. I believe HIOMAP is available for P8 also now ?

The state of chips is another problem. If the 4B enablement in 
the chip was dropped and if the controller is still configured 
to use 4B, then that's a problem. I agree. Using 4B opcodes only 
should help in the future.  

> Reasonable question, but I've merged the change as-is to dev-5.0 on the
> basis that it helps fix read corruption on AC-cycles.
> 
> We can address this in a follow-up patch if necessary.

spi-mem should be taken into account now, which requires a large 
rewrite of the driver. 

Cheers,

C.

> 
> Cheers,
> 
> Andrew
> 
>>
>> With best regards,
>> Alexander Amelkin,
>> Leading BMC Software Engineer, YADRO
>> https://yadro.com
>>
>>
>>
>> Attachments:
>> * signature.asc



More information about the openbmc mailing list