On 24/11/2015 02:49, Simon Glass wrote:
Hi Valentine,
On 23 November 2015 at 02:19, Valentin Longchamp valentin.longchamp@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@keymile.com wrote:
On 19/11/2015 17:57, Jagan Teki wrote:
On 13 November 2015 at 18:55, Valentin Longchamp valentin.longchamp@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.
OK, when looking at SPI flash, SPI controller driver and the driver model, I have found out why we require this "release" command.
So the SPI subsystem and its drivers (with or without DM support) make sure that spi_claim_bus/release_bus are called before/after the accesses. This should cover the pinmux configuration stuff.
In our case, it was not sufficient since drivers/spi/kirkwood_spi.c does the pinmux configuration at 2 places: spi_claim_bus/release_bus for the IO (MOSI/MISO/CLK) AND spi_setup_slave/free_slave for the chip select.
Since spi_free_slave is not always called after spi_setup_slave (for instance after a sf probe command on the u-boot prompt), the CS pin was not always given back to the NAND flash controller that's why there was a need for a sf release command in our case.
I have now moved all the pinmux configuration for kirkwood_spi into spi_claim_bus/release_bus and the need for this sf release command is not necessary anymore.
I am going to test this a bit more and send a new patch series which will not require this release command.
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.
I have had a look at it and it is a great help on porting a driver to this model. That's something we plan to do for our boards eventually.
Valentin