From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Roese Date: Wed, 25 Nov 2015 04:52:27 +0100 Subject: [U-Boot] [PATCH v3 1/3] cmd_sf: add 'release' command In-Reply-To: <56548A12.9040407@keymile.com> References: <1447421155-13084-1-git-send-email-valentin.longchamp@keymile.com> <1447421155-13084-2-git-send-email-valentin.longchamp@keymile.com> <564EF24A.2010506@keymile.com> <5652DA21.3090800@keymile.com> <56548A12.9040407@keymile.com> Message-ID: <5655307B.9040702@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Valentine, On 24.11.2015 17:02, Valentin Longchamp wrote: >>>> 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. So did you already port the kirkwood SPI driver to DM? I'm asking, since I also do have a patch for this in the queue. I'll hopefully be able to post it by end of this week. BTW: I would love to see the Kirkwood platform to be moved over to arch-mvebu at some time, which already supports DM. Thanks, Stefan