[U-Boot] [PATCH] mx6: mx6qsabrelite/nitrogen6x: Fix use of gpio number in SF chip select

[Dirk Behme]

On 30.05.2013 13:32, Gabbasov, Andrew wrote:
> Hi Dirk,
> ________________________________________
>> From: Behme, Dirk - Bosch
>> Sent: Thursday, May 30, 2013 14:50
>> To: Gabbasov, Andrew
>> Cc: u-boot at lists.denx.de
>> Subject: Re: [U-Boot] [PATCH] mx6: mx6qsabrelite/nitrogen6x: Fix use of gpio number in SF chip select
>
> [skipped]
>
>> To my understanding, above change is correct, but not complete ;)
>>
>> The question is "why has it worked with the wrong setting and nobody
>> ever noticed that its wrong?"
>>
>> To my understanding the answer is "because the SPI driver does it
>> correctly":
>>
>> http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=blob;f=drivers/spi/mxc_spi.c;h=5bed858787f610a9c9a46bb2214665a51d60a9e9;hb=refs/heads/master#l376
>>
>> So IMHO the gpio_direction_output() above can be removed completely.
>>
>> Best regards
>>
>> Dirk
>
> Yes, the SPI driver correctly activates and deactivates the CS signal.
> But before the first activation it relies on what signal state was set before that.
> Setting it early at startup just adds some confidence that we have correct
> (inactive) chip select state before the first activation by SPI driver.
> Otherwise we have to rely on particular pad configuration (e.g. EIM_D19).
> I understand, that we set its configuration to "pull-up" (and this is also
> the reset default), and if we do nothing here, it will be recognized as "high".
> But in order to make sure, it's more safe to explicitly set the signal to 1.

Hmm, what's 'unsure' in the time between calling setup_spi() the first 
time and calling spi_setup_slave() the first time?

Are they even called in this order? How long is the time between these 
two calls? What's 'unsafe' in this time frame? Why isn't it unsafe 
_until_ setup_spi() is called, then?

Best regards

Dirk