From: David Brownell <david-b@pacbell.net>
To: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
"spi-devel-general@lists.sourceforge.net"
<spi-devel-general@lists.sourceforge.net>,
"kyungmin.park@samsung.com" <kyungmin.park@samsung.com>
Subject: Re: [PATCH] [drivers] [SPI] SPI_GPIO: add support for controllers with missing MISO pin
Date: Tue, 23 Jun 2009 11:55:15 -0700 [thread overview]
Message-ID: <200906231155.15339.david-b@pacbell.net> (raw)
In-Reply-To: <E4D3F24EA6C9E54F817833EAE0D912AC0228288531@bssrvexch01.BS.local>
On Tuesday 23 June 2009, Marek Szyprowski wrote:
> There are some boards that do not strictly follow SPI standard and use only 3 wires
> (SCLK, MOSI, SS) for connecting some simple auxiliary chips and controls them with GPIO
> based 'spi controller'. In this configuration the MISO line is missing (it is not
> required if the chip does not transfer any data back to host). The example of such
> board is a NCP ARM S3C64XX based machine. This patch adds support for such non-standard
> configuration in GPIO-based SPI controller.
>
> Reviewed-by: Kyungmin Park <kyungmin.park@samsung.com>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
This is missing one integrity feature: it should reject all
requests that provide a read buffer, since obviously it can't
satisfy any such requests.
Also, please add a comment in spi_gpio_request() explaining
this point: that output-only configs exist, and you're
supporting them by letting MISO be invalid.
Address those two points and this will be almost OK.
Thing is, this raises two related issues: (a) there's the
analagous input-only case where MOSI isn't used, e.g. for
some kinds of sensor; and (b) there's also "real 3-wire SPI"
(spi->mode & SPI_3WIRE) where interactions are limited to
half duplex and one pin switches roles between MOSI and MISO.
Clearly this "output-only" case is a subset of SPI_3WIRE (the
MOMI/SISO pin can't switch direction) so one more change I
want to see is requiring that spi->mode flag be set in all
SPI devices registered when this mode is used.
If you have time, it would be good to generaize this patch
to cover all of those 3-wire modes ... accept all half
duplex calls, use gpio_direction_*() to switch direction.
If not -- e.g. nothing to test that with! -- then I can
understand, but please make your changes with that model
in mind, and leave an appropriate FIXME in place.
- Dave
p.s. I'll CC you on one more related patch. Briefly,
there's a new spi_master->flags field that should
set SPI_MASTER_HALF_DUPLEX. Arguably, this specific
case should also advertise something like NO_RX.
>
> ---
>
> diff --git a/drivers/spi/spi_gpio.c b/drivers/spi/spi_gpio.c
> index 26bd03e..16f74fd 100644
> --- a/drivers/spi/spi_gpio.c
> +++ b/drivers/spi/spi_gpio.c
> @@ -114,7 +114,10 @@ static inline void setmosi(const struct spi_device *spi, int is_on)
>
> static inline int getmiso(const struct spi_device *spi)
> {
> - return !!gpio_get_value(SPI_MISO_GPIO);
> + if (gpio_is_valid(SPI_MISO_GPIO))
> + return !!gpio_get_value(SPI_MISO_GPIO);
> + else
> + return 0;
> }
>
> #undef pdata
> @@ -243,9 +246,11 @@ spi_gpio_request(struct spi_gpio_platform_data *pdata, const char *label)
> if (value)
> goto done;
>
> - value = spi_gpio_alloc(SPI_MISO_GPIO, label, true);
> - if (value)
> - goto free_mosi;
> + if (gpio_is_valid(SPI_MISO_GPIO)) {
> + value = spi_gpio_alloc(SPI_MISO_GPIO, label, true);
> + if (value)
> + goto free_mosi;
> + }
>
> value = spi_gpio_alloc(SPI_SCK_GPIO, label, false);
> if (value)
> @@ -254,7 +259,8 @@ spi_gpio_request(struct spi_gpio_platform_data *pdata, const char *label)
> goto done;
>
> free_miso:
> - gpio_free(SPI_MISO_GPIO);
> + if (gpio_is_valid(SPI_MISO_GPIO))
> + gpio_free(SPI_MISO_GPIO);
> free_mosi:
> gpio_free(SPI_MOSI_GPIO);
> done:
> @@ -308,7 +314,8 @@ static int __init spi_gpio_probe(struct platform_device *pdev)
> if (status < 0) {
> spi_master_put(spi_gpio->bitbang.master);
> gpio_free:
> - gpio_free(SPI_MISO_GPIO);
> + if (gpio_is_valid(SPI_MISO_GPIO))
> + gpio_free(SPI_MISO_GPIO);
> gpio_free(SPI_MOSI_GPIO);
> gpio_free(SPI_SCK_GPIO);
> spi_master_put(master);
> @@ -332,7 +339,8 @@ static int __exit spi_gpio_remove(struct platform_device *pdev)
>
> platform_set_drvdata(pdev, NULL);
>
> - gpio_free(SPI_MISO_GPIO);
> + if (gpio_is_valid(SPI_MISO_GPIO))
> + gpio_free(SPI_MISO_GPIO);
> gpio_free(SPI_MOSI_GPIO);
> gpio_free(SPI_SCK_GPIO);
>
>
>
next prev parent reply other threads:[~2009-06-23 18:55 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-23 8:55 [PATCH] [drivers] [SPI] SPI_GPIO: add support for controllers with missing MISO pin Marek Szyprowski
2009-06-23 18:55 ` David Brownell [this message]
2009-06-25 12:16 ` Marek Szyprowski
2009-06-25 15:36 ` David Brownell
-- strict thread matches above, loose matches on Subject: below --
2009-05-25 13:02 Marek Szyprowski
2009-05-07 12:24 Marek Szyprowski
2009-05-07 12:31 ` Ben Dooks
2009-05-18 8:30 ` Marek Szyprowski
2009-05-18 8:34 ` Ben Dooks
2009-05-18 8:57 ` Daniel Mack
2009-05-18 9:27 ` Marek Szyprowski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200906231155.15339.david-b@pacbell.net \
--to=david-b@pacbell.net \
--cc=kyungmin.park@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=spi-devel-general@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox