On Mon, Aug 04, 2014 at 04:45:57PM +0300, 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".
Eeep. That seems very likely to be gotten incorrect by users.
Can we do something like: mxc_spi.c: __weak int board_map_spi_cs_value(int desired_cs) { return -EINVAL; }
fooboard.c: board_map_spi_cs_value(int desired_cs) { if (desired_cs == 0) return IMX_GPIO_NR(2, 30); else return -EINVAL; }
I think it'll be very bad if the user has to type 'sf probe 0:15872' or 'sf probe 15872' since that's a programming detail rather than saying bank 2, gpio 30 (which I assume is what IMX_GPIO_NR means).