[U-Boot] [PATCH v3 1/3] cmd_sf: add 'release' command

[Simon Glass]

Hi Valentine,

On 23 November 2015 at 02:19, Valentin Longchamp
<valentin.longchamp at keymile.com> wrote:
> Hi Simon,
>
> On 20/11/2015 18:19, Simon Glass wrote:
>> Hi,
>>
>> On 20 November 2015 at 03:13, Valentin Longchamp
>> <valentin.longchamp at keymile.com> wrote:
>>> On 19/11/2015 17:57, Jagan Teki wrote:
>>>> On 13 November 2015 at 18:55, Valentin Longchamp
>>>> <valentin.longchamp at keymile.com> wrote:
>>>>> The release command is the pendant of the probe command. This command
>>>>> allows to call spi_flash_free from the command line. This may be
>>>>> necessary for some boards where sf probe does change the state of the
>>>>> hardware (like with some pin multiplexing changes for instance).
>>>>
>>>> So you want to change the state of pin multiplexing on your board with
>>>> connected slave devices example: spi nor flash is it? what exactly the
>>>> need of releasing? why can't we use pin multiplexing changes like
>>>> selecting or deselecting particular lines through driver or from board
>>>> files itself.
>>>
>>> That's our use case yes. Let me explain you it again in detail. Some of the
>>> signals used to access the NAND Flash and the SPI NOR are shared. At reset, they
>>> are available for the SPI NOR, since u-boot is in there and the CPU then
>>> accesses it.
>>>
>>> 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 to SPI NOR to perform these
>>> accesses. But we have to make sure that the pins are configured back to NAND by
>>> calling spi_flash_free() after these accesses and that's why I introduced the
>>> release() function.
>>>
>>> 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.
>>>
>>> We are *indeed* using pin multiplexing changes, in our case, they are
>>> implemented in the spi controller driver: drivers/spi/kirkwood_spi.c. To be very
>>> specific, in our case this sf release command allows to explicitely call
>>> spi_flash_free() which calls spi_free_slave(), which in our case
>>> (kirkwood_spi.c) sets the pins back to their previous configuration.
>>
>> Does your board use driver model from SPI and SPI flash? If not I
>> think that should be the first step.
>>
>
> No we don't. Could you please elaborate on how this would cover this use case
> and should be the first step ?
>
> I am open to other ways to cover this use case of ours, especially since this
> was done more than 2 years ago and u-boot has changed since then. However I
> don't see the direct link between the driver model and how it would allow to
> make sure spi_flash_free() is called in our u-boot env scripts.

In driver model you would have a remove() method for your SPI driver
which does the required pinmux changing.

There is a detailed howto in doc/driver-model showing how to port your
driver over. Please let me know if you need any help/ideas.

Regards,
Simon