On 24/11/2015 02:49, Simon Glass wrote: > Hi Valentine, > > On 23 November 2015 at 02:19, Valentin Longchamp > <valentin.longch...@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.longch...@keymile.com> wrote: >>>> On 19/11/2015 17:57, Jagan Teki wrote: >>>>> On 13 November 2015 at 18:55, Valentin Longchamp >>>>> <valentin.longch...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
