On 04/08/14 16:51, Marek Vasut wrote:
On Monday, August 04, 2014 at 03:45:57 PM, Nikita Kiryanov wrote:
On 04/08/14 16:10, Marek Vasut wrote:
On Monday, August 04, 2014 at 02:48:54 PM, Nikita Kiryanov wrote:
Hi Marek,
On 03/08/14 16:46, Marek Vasut wrote:
On Sunday, August 03, 2014 at 09:34:33 AM, Nikita Kiryanov wrote:
MXC SPI driver has a feature whereas a GPIO line can be used as a CS signal. This is set up by joining the CS and GPIO values into a single value using (cs | gpio << 8), and passing it off as a CS value. This breaks the sf probe command, because it is no longer possible to invoke it as sf probe <cs>. Instead, the user must use sf probe <cs | gpio << 8>.
Fix this by introducing a new board function: board_spi_cs_gpio(). When called, board_spi_cs_gpio() will return the gpio number for the cs value it is given.
Cc: Jagannadha Sutradharudu Teki jagannadh.teki@gmail.com Cc: Eric Nelson eric.nelson@boundarydevices.com Cc: Eric Benard eric@eukrea.com Cc: Fabio Estevam fabio.estevam@freescale.com Cc: Tim Harvey tharvey@gateworks.com Cc: Stefano Babic sbabic@denx.de Cc: Tom Rini trini@ti.com Signed-off-by: Nikita Kiryanov nikita@compulab.co.il
Just curious, but is this fixing generic SF code or MXC SPI driver ? I'd think the later, but it's not obvious from neither the description nor the subject. I don't quite understand the problem that you're trying to fix either, what happened, did the user command interface change ?
The U-Boot shell command "sf probe" can accept a chip select value, but if the SPI device on the other end requires an active chip-select over multiple transactions (achieved in the MXC SPI driver using a GPIO), simply typing something like "sf probe 0" will not work.
Why not ?
This is because whatever the user passes as chip select is propagated to the driver, and the driver expects this value to have GPIO information. So for example, if IMX_GPIO_NR(2, 30) is used to force active chip select 0, then instead of "sf probe 0" the user will have to type "sf probe 15872".
You mean sf probe 0:15872 , right ?
It's the same thing: sf probe [[bus:]cs] [hz] [mode]
The point is that cs 0 has to be represented as "15872", instead of "0".
That's expected, yep.
By whom?
But then, you can use CONFIG_DEFAULT_SPI_CS to specify the default CS, no ?
This only works if you have just one SPI device that requires GPIO use. Otherwise, chances are the user will have no idea how to access devices on other chip selects without looking at the code.
Oh, so you're confused by those crazy chipselect numbers ?
Are you suggesting that they make sense?
Best regards, Marek Vasut