From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dirk Behme Date: Thu, 30 May 2013 13:50:38 +0200 Subject: [U-Boot] [PATCH] mx6: mx6qsabrelite/nitrogen6x: Fix use of gpio number in SF chip select In-Reply-To: <6C5EA58090A5ED459815C4D04C2B466FD93304DF@EU-MBX-01.mgc.mentorg.com> References: <1369908169-11310-1-git-send-email-andrew_gabbasov@mentor.com>, <51A72EE2.2040400@de.bosch.com> <6C5EA58090A5ED459815C4D04C2B466FD93304DF@EU-MBX-01.mgc.mentorg.com> Message-ID: <51A73D0E.3000407@de.bosch.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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