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.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".
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).
--
Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
