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.t...@gmail.com> > >>>>>> Cc: Eric Nelson <eric.nel...@boundarydevices.com> > >>>>>> Cc: Eric Benard <e...@eukrea.com> > >>>>>> Cc: Fabio Estevam <fabio.este...@freescale.com> > >>>>>> Cc: Tim Harvey <thar...@gateworks.com> > >>>>>> Cc: Stefano Babic <sba...@denx.de> > >>>>>> Cc: Tom Rini <tr...@ti.com> > >>>>>> Signed-off-by: Nikita Kiryanov <nik...@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 ;-) [...] _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
