From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nikita Kiryanov Date: Mon, 04 Aug 2014 17:19:28 +0300 Subject: [U-Boot] [PATCH 03/18] sf: fix sf probe In-Reply-To: <20140804140242.GE19374@bill-the-cat> References: <1407051288-17324-1-git-send-email-nikita@compulab.co.il> <201408031546.39080.marex@denx.de> <53DF8136.8050804@compulab.co.il> <201408041510.29017.marex@denx.de> <53DF8E95.1000702@compulab.co.il> <20140804140242.GE19374@bill-the-cat> Message-ID: <53DF9670.5030109@compulab.co.il> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 04/08/14 17:02, Tom Rini wrote: > 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 . Instead, the user must use sf probe >>>>> 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 >>>>>> Cc: Eric Nelson >>>>>> Cc: Eric Benard >>>>>> Cc: Fabio Estevam >>>>>> Cc: Tim Harvey >>>>>> Cc: Stefano Babic >>>>>> Cc: Tom Rini >>>>>> Signed-off-by: Nikita Kiryanov >>>>> >>>>> 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; > } That's pretty much what the patch does. > > 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). > Agreed.