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

Marek Vasut marex at denx.de
Mon Aug 4 16:20:15 CEST 2014


On Monday, August 04, 2014 at 04:11:57 PM, Nikita Kiryanov wrote:
> 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 at gmail.com>
> >>>>>> Cc: Eric Nelson <eric.nelson at boundarydevices.com>
> >>>>>> Cc: Eric Benard <eric at eukrea.com>
> >>>>>> Cc: Fabio Estevam <fabio.estevam at freescale.com>
> >>>>>> Cc: Tim Harvey <tharvey at gateworks.com>
> >>>>>> Cc: Stefano Babic <sbabic at denx.de>
> >>>>>> Cc: Tom Rini <trini at ti.com>
> >>>>>> Signed-off-by: Nikita Kiryanov <nikita at 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?

By the interface. But anyway, let's proceed discussing this stuff in the other 
thread. This would only turn into pointless bickering here ;-)

[...]


More information about the U-Boot mailing list