From mboxrd@z Thu Jan  1 00:00:00 1970
From: Marek Vasut <marex@denx.de>
Date: Mon, 4 Aug 2014 15:51:36 +0200
Subject: [U-Boot] [PATCH 03/18] sf: fix sf probe
In-Reply-To: <53DF8E95.1000702@compulab.co.il>
References: <1407051288-17324-1-git-send-email-nikita@compulab.co.il>
	<201408041510.29017.marex@denx.de>
	<53DF8E95.1000702@compulab.co.il>
Message-ID: <201408041551.36501.marex@denx.de>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

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

> > But then, you can use CONFIG_DEFAULT_SPI_CS to specify the default CS, no
> > ?
> 
> This only works if you have just one SPI device that requires GPIO use.
> Otherwise, chances are the user will have no idea how to access devices
> on other chip selects without looking at the code.

Oh, so you're confused by those crazy chipselect numbers ?

Best regards,
Marek Vasut