On 25/11/2015 04:52, Stefan Roese wrote: > Hi Valentine, > > On 24.11.2015 17:02, Valentin Longchamp wrote: > > <snip> > >>>>> 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.
No I didn't. I was just looking at what should be done for that. For my above problem I want to send a patch to the current driver without porting it at all. > > BTW: I would love to see the Kirkwood platform to be moved over to > arch-mvebu at some time, which already supports DM. > Tell me if you're doing something in this area, I may give some help or test a few things, according to the remaining time besides my current projects. The Kirkwood platform would definitely be better if this was done. Valentin _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
