[U-Boot] [PATCH v2 0/3] Serial Flash: call spi_flash_free more coherently

[Valentin Longchamp]

On 12/18/2014 03:03 PM, Jagan Teki wrote:
> On 3 November 2014 at 19:31, Valentin Longchamp
> <valentin.longchamp at keymile.com> wrote:
>> Some board require spi_flash_free to be called after all the accesses,
>> in order, for instance, to restore the pin multiplexing configuration in
>> the case where the SPI pins are multiplexed.
> 
> So, for each probe calls you must need to free the flash even-though
> the flash is-in-use, looks some different behavior.

To be precise, AFTER the flash has been used is a better description. The flash
is not in use anymore.

> 
> Can you pleas elaborate little more.

Let me explain you our use case more in details. In our case the pins used for
accessing the SPI NOR flash (contains u-boot and the environment) are
multiplexed with the pins used for accessing the NAND Flash.

In an usual boot sequence, the SPI NOR is accessed first (copying u-boot to the
RAM, reading out the environment) and so the pins are configured in hardware at
boot time for accessing the SPI NOR. After that, they are configured to access
the NAND where the kernel and filesystem are stored to boot Linux thanks to
env_relocate_spec() calling spi_flash_free() on exit in conjunction with [1]

Now in the case where the boot sequence is interrupted and some accesses are
done to the SPI NOR, the pins are changed again temporarily to NOR to do these
accesses. But we have to make sure that the pins are configured back to NAND by
calling spi_flash_free() after these accesses. In our case, there are 2 types of
such accesses:
- environment variables write: this is the first patch of the series. It simply
adds calls to spi_flash_free() at function exit no only in env_relocate_spec()
but also in saveenv() so that the behavior here is coherent for the whole env_sf
file (spi_flash_probe() at function start, spi_flash_free() at function exit).
- updating u-boot: this is solved for us with the last 2 patches of the series.
The first one just adds a sf release command that does the opposite/cleanup to
sf probe and the second patch just calls this command in our scripts where
u-boot is updated/the SPI NOR is written.

[1] http://patchwork.ozlabs.org/patch/162307/

> 
>>
>> This patch series tries to enhance this. Patch 1 adds spi_flash_free
>> calls to env_sf so that the SPI interface is always "cleaned up" after
>> the env read/writes. Patch 2 adds a 'sf release' command that implicitly
>> calls spi_flash_free and is thus the pendant of 'sf probe'. Patch 3 uses
>> the 'sf command' for the km_arm board scripts.
>>
>> The whole series had already been sent more than a year ago [1] but it
>> was rejected without any feedback. So I send this rebased v2 so that it
>> finally gets reviewed and merged.
>>
>> [1] http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/169723
>>
>> Changes in v2:
>> - Rebased on v2014.10
>>
>> Valentin Longchamp (3):
>>   env_sf: generalize call to spi_flash_free after accesses
>>   cmd_sf: add 'release' command
> 
> This may not be an optimistic solutions where we couldn't add command
> to have generic behavior which does at-least on probe time - IMHO.

Do you mean optimal ? Anyway I don't understand your sentence/what you mean
here. Could you rephrase it, please ?

But if we have a sf probe command, why can't we have a sf release command ?

> 
>>   km_arm: call 'sf release' in the newenv and update scripts
>>
>>  common/cmd_sf.c             | 13 ++++++++++++-
>>  common/env_sf.c             | 34 ++++++++++++++++------------------
>>  include/configs/km/km_arm.h |  6 ++++--
>>  3 files changed, 32 insertions(+), 21 deletions(-)
>>
>> --
>> 1.8.0.1
>>
> 
> thanks!
> 

Valentin