| To: | david-b@pacbell.net |
|---|---|
| Subject: | Re: [spi-devel-general] [PATCH] TXx9 SPI controller driver |
| From: | Atsushi Nemoto <anemo@mba.ocn.ne.jp> |
| Date: | Mon, 25 Jun 2007 00:56:00 +0900 (JST) |
| Cc: | spi-devel-general@lists.sourceforge.net, sshtylyov@ru.mvista.com, linux-mips@linux-mips.org, ralf@linux-mips.org, mlachwani@mvista.com |
| In-reply-to: | <200706230909.52037.david-b@pacbell.net> |
| Original-recipient: | rfc822;linux-mips@linux-mips.org |
| References: | <200706221151.24959.david-b@pacbell.net> <20070624.004159.07644824.anemo@mba.ocn.ne.jp> <200706230909.52037.david-b@pacbell.net> |
| Sender: | linux-mips-bounce@linux-mips.org |
On Sat, 23 Jun 2007 09:09:51 -0700, David Brownell <david-b@pacbell.net> wrote: > > And for mmiowb() issue, I put it just only I was not sure whether > > gpio_set_value() guarantee I/O barrier. Now I see i2c-gpio.c, etc. do > > not have such barriers. I will remove these barriers and fix platform > > gpio codes. > > I don't think this is a case where there'd be a benefit to > allowing non-barriered implementations, and thus requiring > all portable code to include platform-neutral I/O barriers. > I don't know that such neutral primitives actually exist... > > I'll update the GPIO docs to make that clear, unless you > have some strong argument to the contrary. No contrary argument. Some guide to writers of GPIO implementations about the I/O barriers should be appreciated. --- Atsushi Nemoto |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [spi-devel-general] [PATCH] TXx9 SPI controller driver, David Brownell |
|---|---|
| Next by Date: | Re: [PATCH] TXx9 SPI controller driver, Atsushi Nemoto |
| Previous by Thread: | Re: [spi-devel-general] [PATCH] TXx9 SPI controller driver, David Brownell |
| Next by Thread: | Re: [PATCH] TXx9 SPI controller driver, Atsushi Nemoto |
| Indexes: | [Date] [Thread] [Top] [All Lists] |