From: Guennadi Liakhovetski <g.liakhovetski@gmx.de> To: Arnd Bergmann <arnd@arndb.de> Cc: linux-mmc@vger.kernel.org, devicetree-discuss@lists.ozlabs.org, linux-sh@vger.kernel.org, Magnus Damm <magnus.damm@gmail.com>, Simon Horman <horms@verge.net.au>, Russell King - ARM Linux <linux@arm.linux.org.uk> Subject: Re: [PATCH v4 13/13] mmc: tmio: add barriers to IO operations Date: Mon, 18 Feb 2013 15:56:09 +0000 [thread overview] Message-ID: <Pine.LNX.4.64.1302181614070.4526@axis700.grange> (raw) In-Reply-To: <201302181505.58118.arnd@arndb.de> Hi Arnd On Mon, 18 Feb 2013, Arnd Bergmann wrote: > On Friday 15 February 2013, Guennadi Liakhovetski wrote: > > Without barriers SDIO operations fail with runtime PM enabled. > > I don't understand how the changeset comment relates to the patch. > > > diff --git a/drivers/mmc/host/tmio_mmc.h b/drivers/mmc/host/tmio_mmc.h > > index d857f5c..a10ebd0 100644 > > --- a/drivers/mmc/host/tmio_mmc.h > > +++ b/drivers/mmc/host/tmio_mmc.h > > @@ -159,19 +159,20 @@ int tmio_mmc_host_runtime_resume(struct device *dev); > > > > static inline u16 sd_ctrl_read16(struct tmio_mmc_host *host, int addr) > > { > > - return readw(host->ctl + (addr << host->bus_shift)); > > + return ioread16(host->ctl + (addr << host->bus_shift)); > > } > > > > As far as I know, all architectures are required to have the same barrier > semantics on readw and ioread16. The only difference between the two is > that ioread16 must be able top operate on an __iomem token returned by > ioport_map() or pci_iomap, which readw does not have to, but does on ARM. Indeed, the real difference are the barriers in repeated IO operations. > > static inline void sd_ctrl_read16_rep(struct tmio_mmc_host *host, int addr, > > u16 *buf, int count) > > { > > - readsw(host->ctl + (addr << host->bus_shift), buf, count); > > + wmb(); > > + ioread16_rep(host->ctl + (addr << host->bus_shift), buf, count); > > } > > Same thing here: both readsw and ioread16_rep are supposed to do the same > thing, and I would assume that they should also include that barrier. > For some reason I don't understand, they do not have the barrier on > ARM at the moment, but I cannot say whether that is intentional or not. > > Maybe Russell can comment on this. > > Also, should the barrier not be /after/ the MMIO read, rather than before it? > Typically the barrier should ensure that any read from memory after an > MMIO read reflects the memory contents after any DMA is complete that > the MMIO read has already claimed to be done. Errors, that I've been observing were happening with no DMA, in pure PIO mode. Unfortunately, I don't have a good explanation, why the barriers _have_ to be there, where I put them. At some point during my testing, I had printk()s in the code and SDIO worked. Then the classical - remove printk()s - stops working. Delays didn't halp, but barriers did. The motivation to put a write barrier before a (repeated) read was to wait for completion of any write operations before starting a read. And indeed, normal write operations, like writew() / iowrite16() have a write barrier _before_ the write. So, isn't it possible, that the last write hasn't completed yet, while we begin with reading? But reads / writes should, probably, anyway be serialised on the bus... It's also possible, that these errors are related to runtime power-management, which would involve IO to other SoC peripherals. But they all should also contain barriers, so, this doesn't explain it immediately either. Thanks Guennadi > > static inline void sd_ctrl_write16_rep(struct tmio_mmc_host *host, int addr, > > u16 *buf, int count) > > { > > - writesw(host->ctl + (addr << host->bus_shift), buf, count); > > + iowrite16_rep(host->ctl + (addr << host->bus_shift), buf, count); > > + wmb(); > > } > > Similarly here: why do you have the wmb after the iowrite rather than before it? > > Arnd > --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/
WARNING: multiple messages have this Message-ID (diff)
From: Guennadi Liakhovetski <g.liakhovetski@gmx.de> To: Arnd Bergmann <arnd@arndb.de> Cc: linux-mmc@vger.kernel.org, devicetree-discuss@lists.ozlabs.org, linux-sh@vger.kernel.org, Magnus Damm <magnus.damm@gmail.com>, Simon Horman <horms@verge.net.au>, Russell King - ARM Linux <linux@arm.linux.org.uk> Subject: Re: [PATCH v4 13/13] mmc: tmio: add barriers to IO operations Date: Mon, 18 Feb 2013 16:56:09 +0100 (CET) [thread overview] Message-ID: <Pine.LNX.4.64.1302181614070.4526@axis700.grange> (raw) In-Reply-To: <201302181505.58118.arnd@arndb.de> Hi Arnd On Mon, 18 Feb 2013, Arnd Bergmann wrote: > On Friday 15 February 2013, Guennadi Liakhovetski wrote: > > Without barriers SDIO operations fail with runtime PM enabled. > > I don't understand how the changeset comment relates to the patch. > > > diff --git a/drivers/mmc/host/tmio_mmc.h b/drivers/mmc/host/tmio_mmc.h > > index d857f5c..a10ebd0 100644 > > --- a/drivers/mmc/host/tmio_mmc.h > > +++ b/drivers/mmc/host/tmio_mmc.h > > @@ -159,19 +159,20 @@ int tmio_mmc_host_runtime_resume(struct device *dev); > > > > static inline u16 sd_ctrl_read16(struct tmio_mmc_host *host, int addr) > > { > > - return readw(host->ctl + (addr << host->bus_shift)); > > + return ioread16(host->ctl + (addr << host->bus_shift)); > > } > > > > As far as I know, all architectures are required to have the same barrier > semantics on readw and ioread16. The only difference between the two is > that ioread16 must be able top operate on an __iomem token returned by > ioport_map() or pci_iomap, which readw does not have to, but does on ARM. Indeed, the real difference are the barriers in repeated IO operations. > > static inline void sd_ctrl_read16_rep(struct tmio_mmc_host *host, int addr, > > u16 *buf, int count) > > { > > - readsw(host->ctl + (addr << host->bus_shift), buf, count); > > + wmb(); > > + ioread16_rep(host->ctl + (addr << host->bus_shift), buf, count); > > } > > Same thing here: both readsw and ioread16_rep are supposed to do the same > thing, and I would assume that they should also include that barrier. > For some reason I don't understand, they do not have the barrier on > ARM at the moment, but I cannot say whether that is intentional or not. > > Maybe Russell can comment on this. > > Also, should the barrier not be /after/ the MMIO read, rather than before it? > Typically the barrier should ensure that any read from memory after an > MMIO read reflects the memory contents after any DMA is complete that > the MMIO read has already claimed to be done. Errors, that I've been observing were happening with no DMA, in pure PIO mode. Unfortunately, I don't have a good explanation, why the barriers _have_ to be there, where I put them. At some point during my testing, I had printk()s in the code and SDIO worked. Then the classical - remove printk()s - stops working. Delays didn't halp, but barriers did. The motivation to put a write barrier before a (repeated) read was to wait for completion of any write operations before starting a read. And indeed, normal write operations, like writew() / iowrite16() have a write barrier _before_ the write. So, isn't it possible, that the last write hasn't completed yet, while we begin with reading? But reads / writes should, probably, anyway be serialised on the bus... It's also possible, that these errors are related to runtime power-management, which would involve IO to other SoC peripherals. But they all should also contain barriers, so, this doesn't explain it immediately either. Thanks Guennadi > > static inline void sd_ctrl_write16_rep(struct tmio_mmc_host *host, int addr, > > u16 *buf, int count) > > { > > - writesw(host->ctl + (addr << host->bus_shift), buf, count); > > + iowrite16_rep(host->ctl + (addr << host->bus_shift), buf, count); > > + wmb(); > > } > > Similarly here: why do you have the wmb after the iowrite rather than before it? > > Arnd > --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/
next prev parent reply other threads:[~2013-02-18 15:56 UTC|newest] Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-02-15 15:13 [PATCH v4 00/13] mmc: core and driver DT and related development Guennadi Liakhovetski 2013-02-15 15:13 ` Guennadi Liakhovetski 2013-02-15 15:13 ` [PATCH v4 01/13] mmc: sdhi, tmio: only check flags in tmio-mmc driver proper Guennadi Liakhovetski 2013-02-15 15:13 ` Guennadi Liakhovetski 2013-02-15 15:13 ` [PATCH v4 02/13] mmc: detailed definition of CD and WP MMC line polarities in DT Guennadi Liakhovetski 2013-02-15 15:13 ` Guennadi Liakhovetski 2013-02-15 15:13 ` [PATCH v4 03/13] mmc: provide a standard MMC device-tree binding parser centrally Guennadi Liakhovetski 2013-02-15 15:13 ` Guennadi Liakhovetski 2013-02-16 6:05 ` Simon Horman 2013-02-16 6:05 ` Simon Horman 2013-02-16 10:54 ` Arnd Bergmann 2013-02-16 11:41 ` Simon Horman 2013-02-16 11:41 ` Simon Horman 2013-02-16 14:02 ` Guennadi Liakhovetski 2013-02-16 14:02 ` Guennadi Liakhovetski 2013-02-16 15:21 ` [PATCH v5 " Guennadi Liakhovetski 2013-02-16 15:21 ` Guennadi Liakhovetski 2013-02-16 16:58 ` Sascha Hauer 2013-02-16 16:58 ` Sascha Hauer 2013-02-17 7:52 ` Simon Horman 2013-02-17 7:52 ` Simon Horman 2013-02-17 7:58 ` Simon Horman 2013-02-17 7:58 ` Simon Horman 2013-02-18 8:54 ` Guennadi Liakhovetski 2013-02-18 8:54 ` Guennadi Liakhovetski 2013-02-15 15:13 ` [PATCH v4 04/13] mmc: (cosmetic) remove "extern" from function declarations Guennadi Liakhovetski 2013-02-15 15:13 ` Guennadi Liakhovetski 2013-02-15 15:13 ` [PATCH v4 05/13] mmc: sh-mmcif: use mmc_of_parse() to parse standard MMC DT bindings Guennadi Liakhovetski 2013-02-15 15:13 ` Guennadi Liakhovetski 2013-02-15 15:13 ` [PATCH v4 06/13] mmc: tmio-mmc: define device-tree bindings Guennadi Liakhovetski 2013-02-15 15:13 ` Guennadi Liakhovetski 2013-02-15 15:13 ` [PATCH v4 07/13] mmc: tmio-mmc: parse " Guennadi Liakhovetski 2013-02-15 15:13 ` Guennadi Liakhovetski 2013-02-15 15:13 ` [PATCH v4 08/13] mmc: sh_mobile_sdhi: remove unused .pdata field Guennadi Liakhovetski 2013-02-15 15:13 ` Guennadi Liakhovetski 2013-02-15 15:13 ` [PATCH v4 09/13] mmc: sh_mobile_sdhi: use managed resource allocations Guennadi Liakhovetski 2013-02-15 15:13 ` Guennadi Liakhovetski 2013-02-15 15:13 ` [PATCH v4 10/13] mmc: tmio: remove unused and deprecated symbols Guennadi Liakhovetski 2013-02-15 15:13 ` Guennadi Liakhovetski 2013-02-15 15:14 ` [PATCH v4 11/13] mmc: tmio: add support for the VccQ regulator Guennadi Liakhovetski 2013-02-15 15:14 ` Guennadi Liakhovetski 2013-02-15 15:14 ` [PATCH v4 12/13] mmc: add DT bindings for more MMC capability flags Guennadi Liakhovetski 2013-02-15 15:14 ` Guennadi Liakhovetski 2013-02-16 22:58 ` Sergei Shtylyov 2013-02-16 23:58 ` Sergei Shtylyov [not found] ` <51201D32.20006-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org> 2013-02-18 8:52 ` Guennadi Liakhovetski 2013-02-18 8:52 ` Guennadi Liakhovetski 2013-06-06 1:55 ` Olof Johansson 2013-06-06 1:55 ` Olof Johansson 2013-02-15 15:14 ` [PATCH v4 13/13] mmc: tmio: add barriers to IO operations Guennadi Liakhovetski 2013-02-15 15:14 ` Guennadi Liakhovetski 2013-02-18 15:05 ` Arnd Bergmann 2013-02-18 15:56 ` Guennadi Liakhovetski [this message] 2013-02-18 15:56 ` Guennadi Liakhovetski 2013-02-18 16:34 ` Arnd Bergmann 2013-02-18 17:20 ` Guennadi Liakhovetski 2013-02-18 17:20 ` Guennadi Liakhovetski 2013-02-18 22:11 ` Arnd Bergmann [not found] ` <201302182211.46697.arnd-r2nGTMty4D4@public.gmane.org> 2013-02-19 21:59 ` Guennadi Liakhovetski 2013-02-19 21:59 ` Guennadi Liakhovetski 2013-02-16 2:26 ` [PATCH v4 00/13] mmc: core and driver DT and related development Simon Horman 2013-02-16 2:26 ` Simon Horman 2013-02-18 13:15 ` Chris Ball 2013-02-18 13:15 ` Chris Ball 2013-02-19 21:57 ` Guennadi Liakhovetski 2013-02-19 21:57 ` Guennadi Liakhovetski 2013-02-19 22:00 ` Chris Ball 2013-02-19 22:00 ` Chris Ball 2013-02-18 14:52 ` Arnd Bergmann 2013-02-19 19:20 ` Stephen Warren 2013-02-19 19:20 ` Stephen Warren
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=Pine.LNX.4.64.1302181614070.4526@axis700.grange \ --to=g.liakhovetski@gmx.de \ --cc=arnd@arndb.de \ --cc=devicetree-discuss@lists.ozlabs.org \ --cc=horms@verge.net.au \ --cc=linux-mmc@vger.kernel.org \ --cc=linux-sh@vger.kernel.org \ --cc=linux@arm.linux.org.uk \ --cc=magnus.damm@gmail.com \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.