[U-Boot] [PATCH 03/18] sf: fix sf probe

Nikita Kiryanov
2014-08-04T12:48:54Z

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.

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".

I agree that the subject line should be made a bit more specific
to mxc_spi though...

>
> [...]
> Best regards,
> Marek Vasut
>