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

[Stefan Roese <sr@denx.de>]

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.

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