All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Daniel Thompson <daniel.thompson@linaro.org>,
	Will Deacon <will.deacon@arm.com>,
	"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"benh@kernel.crashing.org" <benh@kernel.crashing.org>,
	"chris@zankel.net" <chris@zankel.net>,
	"cmetcalf@tilera.com" <cmetcalf@tilera.com>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"deller@gmx.de" <deller@gmx.de>,
	"dhowells@redhat.com" <dhowells@redhat.com>,
	"geert@linux-m68k.org" <geert@linux-m68k.org>,
	"heiko.carstens@de.ibm.com" <heiko.carstens@de.ibm.com>,
	"hpa@zytor.com" <hpa@zytor.com>,
	"jcmvbkbc@gmail.com" <jcmvbkbc@gmail.com>,
	"jesper.nilsson@axis.com" <jesper.nilsson@axis.com>,
	"mingo@redhat.com" <mingo@redhat.com>,
	"monstr@monstr.eu" <monstr@monstr.eu>,
	"paulmck@linux.vnet.ibm.com" <paulmck@linux.vnet.ibm.com>,
	"rdunlap@infradead.org" <rdunlap@infradead.org>,
	"sam@ravnborg.org" <sam@ravnborg.org>,
	"schwidefsky@de.ibm.com" <schwidefsky@de.ibm.com>,
	"starvik@axis.com" <starvik@axis.com>,
	"takata@linux-m32r.org" <takata@linux-m32r.org>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"tony.luck@intel.com" <tony.luck@intel.com>,
	"broonie@linaro.org" <broonie@linaro.org>,
	"thierry.reding@gmail.com" <thierry.reding@gmail.com>
Subject: Re: [PATCH v3 00/17] Cross-architecture definitions of relaxed MMIO accessors
Date: Fri, 26 Sep 2014 11:28:38 +0200	[thread overview]
Message-ID: <2497501.Mvb1tbCjLR@wuerfel> (raw)
In-Reply-To: <20140926084019.GJ5182@n2100.arm.linux.org.uk>

On Friday 26 September 2014 09:40:19 Russell King - ARM Linux wrote:
> 
> How would a 32-bit architecture know whether it should read the least
> significant 32-bit or the most significant 32-bit part of the 64-bit
> register first.  What would be right for one driver may not ben correct
> for another.  Hence, this decision should only be made by the driver
> wanting the accessor, and not having the accessor symbol defined should
> be the trigger for the driver to handle the problem themselves.

Some 32-bit architectures can trigger 64-bit bus cycles using well
defined accesses using register pairs. Meta seems to fit into this
category:

static inline u64 __raw_readq(const volatile void __iomem *addr)
{
       u64 ret;
       asm volatile("GETL %0,%t0,[%1]"
                    : "=da" (ret)
                    : "da" (addr)
                    : "memory");
       return ret;
}

Most other architectures I think cannot do this however, and would
turn the access into two separate bus cycles, which in addition to
the problem you mentioned could also result in side-effects from
doing an access at the wrong offset, so we definitely can't rely
on having these functions.

	Arnd

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Daniel Thompson <daniel.thompson@linaro.org>,
	Will Deacon <will.deacon@arm.com>,
	"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"benh@kernel.crashing.org" <benh@kernel.crashing.org>,
	"chris@zankel.net" <chris@zankel.net>,
	"cmetcalf@tilera.com" <cmetcalf@tilera.com>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"deller@gmx.de" <deller@gmx.de>,
	"dhowells@redhat.com" <dhowells@redhat.com>,
	"geert@linux-m68k.org" <geert@linux-m68k.org>,
	"heiko.carstens@de.ibm.com" <heiko.carstens@de.ibm.com>,
	"hpa@zytor.com" <hpa@zytor.com>,
	"jcmvbkbc@gmail.com" <jcmvbkbc@gmail.com>,
	"jesper.nilsson@axis.com" <jesper.nilsson@axis.com>,
	"mingo@redhat.com" <mingo@redhat.com>,
	"monstr@monstr.eu" <monstr@monstr.eu>,
	"paulmck@linux.vnet.ibm.com" <paulmck@linux.vnet.ibm.com>,
	"rdunlap@infradead.org" <rdunlap@infradead.>
Subject: Re: [PATCH v3 00/17] Cross-architecture definitions of relaxed MMIO accessors
Date: Fri, 26 Sep 2014 11:28:38 +0200	[thread overview]
Message-ID: <2497501.Mvb1tbCjLR@wuerfel> (raw)
In-Reply-To: <20140926084019.GJ5182@n2100.arm.linux.org.uk>

On Friday 26 September 2014 09:40:19 Russell King - ARM Linux wrote:
> 
> How would a 32-bit architecture know whether it should read the least
> significant 32-bit or the most significant 32-bit part of the 64-bit
> register first.  What would be right for one driver may not ben correct
> for another.  Hence, this decision should only be made by the driver
> wanting the accessor, and not having the accessor symbol defined should
> be the trigger for the driver to handle the problem themselves.

Some 32-bit architectures can trigger 64-bit bus cycles using well
defined accesses using register pairs. Meta seems to fit into this
category:

static inline u64 __raw_readq(const volatile void __iomem *addr)
{
       u64 ret;
       asm volatile("GETL %0,%t0,[%1]"
                    : "=da" (ret)
                    : "da" (addr)
                    : "memory");
       return ret;
}

Most other architectures I think cannot do this however, and would
turn the access into two separate bus cycles, which in addition to
the problem you mentioned could also result in side-effects from
doing an access at the wrong offset, so we definitely can't rely
on having these functions.

	Arnd

  reply	other threads:[~2014-09-26  9:29 UTC|newest]

Thread overview: 80+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-24 17:17 [PATCH v3 00/17] Cross-architecture definitions of relaxed MMIO accessors Will Deacon
2014-09-24 17:17 ` [PATCH v3 01/17] asm-generic: io: implement relaxed accessor macros as conditional wrappers Will Deacon
2014-09-25 10:32   ` Arnd Bergmann
2014-09-25 10:38     ` Will Deacon
2014-09-25 10:38       ` Will Deacon
2014-09-25 10:43       ` Arnd Bergmann
2014-09-25 10:43         ` Arnd Bergmann
2014-09-25 11:44         ` Will Deacon
2014-09-25 11:44           ` Will Deacon
2014-09-24 17:17 ` [PATCH v3 02/17] microblaze: io: remove dummy relaxed accessor macros Will Deacon
2014-09-24 17:17 ` [PATCH v3 03/17] s390: io: remove dummy relaxed accessor macros for reads Will Deacon
2014-09-24 17:17 ` [PATCH v3 04/17] xtensa: " Will Deacon
2014-09-25 15:22   ` Max Filippov
2014-09-25 15:22     ` Max Filippov
2014-09-24 17:17 ` [PATCH v3 05/17] frv: io: implement dummy relaxed accessor macros for writes Will Deacon
2014-09-24 17:17 ` [PATCH v3 06/17] cris: " Will Deacon
2014-09-24 17:17 ` [PATCH v3 07/17] ia64: " Will Deacon
2014-09-24 17:17 ` [PATCH v3 08/17] m32r: " Will Deacon
2014-09-24 17:17 ` [PATCH v3 09/17] m68k: " Will Deacon
2014-09-25  1:05   ` Greg Ungerer
2014-09-25  1:05     ` Greg Ungerer
2014-09-25  9:33     ` Will Deacon
2014-09-25  9:33       ` Will Deacon
2014-09-25  9:51       ` Geert Uytterhoeven
2014-09-25  9:51         ` Geert Uytterhoeven
2014-09-25 10:33         ` Will Deacon
2014-09-25 10:33           ` Will Deacon
2014-09-24 17:17 ` [PATCH v3 10/17] mn10300: " Will Deacon
2014-09-24 17:17 ` [PATCH v3 11/17] parisc: " Will Deacon
2014-09-25 20:00   ` Helge Deller
2014-09-24 17:17 ` [PATCH v3 12/17] powerpc: " Will Deacon
2014-09-24 17:17 ` [PATCH v3 13/17] sparc: " Will Deacon
2014-09-24 17:17 ` [PATCH v3 14/17] tile: " Will Deacon
2014-09-24 17:17 ` [PATCH v3 15/17] x86: " Will Deacon
2014-09-24 17:17 ` [PATCH v3 16/17] documentation: memory-barriers: clarify relaxed io accessor semantics Will Deacon
2014-09-24 17:17 ` [PATCH v3 17/17] asm-generic: io: define relaxed accessor macros unconditionally Will Deacon
2014-09-25 10:42 ` [PATCH v3 00/17] Cross-architecture definitions of relaxed MMIO accessors Arnd Bergmann
2014-09-25 13:15 ` Arnd Bergmann
2014-09-25 14:55   ` Will Deacon
2014-09-25 14:55     ` Will Deacon
2014-09-25 15:07     ` Arnd Bergmann
2014-09-25 15:07       ` Arnd Bergmann
2014-09-25 15:15       ` Arnd Bergmann
2014-09-25 15:15         ` Arnd Bergmann
2014-09-25 15:24         ` Daniel Thompson
2014-09-25 15:24           ` Daniel Thompson
2014-09-25 19:17           ` Arnd Bergmann
2014-09-25 19:17             ` Arnd Bergmann
2014-09-25 20:17             ` Geert Uytterhoeven
2014-09-25 20:17               ` Geert Uytterhoeven
2014-09-26  8:40             ` Russell King - ARM Linux
2014-09-26  8:40               ` Russell King - ARM Linux
2014-09-26  9:28               ` Arnd Bergmann [this message]
2014-09-26  9:28                 ` Arnd Bergmann
2014-09-26  8:05         ` Thierry Reding
2014-09-26  8:05           ` Thierry Reding
2014-09-26 13:39           ` Arnd Bergmann
2014-09-26 13:39             ` Arnd Bergmann
2014-09-26 13:46             ` Russell King - ARM Linux
2014-09-26 13:46               ` Russell King - ARM Linux
2014-09-26 21:36               ` Arnd Bergmann
2014-09-26 21:36                 ` Arnd Bergmann
2014-09-29  8:23                 ` Thierry Reding
2014-09-29  8:23                   ` Thierry Reding
2014-09-29  9:50                   ` Arnd Bergmann
2014-09-29  9:50                     ` Arnd Bergmann
2014-10-01 15:23                     ` Thierry Reding
2014-10-01 15:23                       ` Thierry Reding
2014-10-01 18:34                       ` Arnd Bergmann
2014-10-01 18:34                         ` Arnd Bergmann
2014-09-29  9:25                 ` Will Deacon
2014-09-29  9:25                   ` Will Deacon
2014-09-29  9:48                   ` Arnd Bergmann
2014-09-29  9:48                     ` Arnd Bergmann
2014-10-30 16:59   ` Will Deacon
2014-10-30 16:59     ` Will Deacon
2014-10-30 20:04     ` Arnd Bergmann
2014-10-30 20:04       ` Arnd Bergmann
2014-10-31 11:09       ` Thierry Reding
2014-10-31 11:09         ` Thierry Reding

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=2497501.Mvb1tbCjLR@wuerfel \
    --to=arnd@arndb.de \
    --cc=benh@kernel.crashing.org \
    --cc=broonie@linaro.org \
    --cc=chris@zankel.net \
    --cc=cmetcalf@tilera.com \
    --cc=daniel.thompson@linaro.org \
    --cc=davem@davemloft.net \
    --cc=deller@gmx.de \
    --cc=dhowells@redhat.com \
    --cc=geert@linux-m68k.org \
    --cc=heiko.carstens@de.ibm.com \
    --cc=hpa@zytor.com \
    --cc=jcmvbkbc@gmail.com \
    --cc=jesper.nilsson@axis.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=mingo@redhat.com \
    --cc=monstr@monstr.eu \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=rdunlap@infradead.org \
    --cc=sam@ravnborg.org \
    --cc=schwidefsky@de.ibm.com \
    --cc=starvik@axis.com \
    --cc=takata@linux-m32r.org \
    --cc=tglx@linutronix.de \
    --cc=thierry.reding@gmail.com \
    --cc=tony.luck@intel.com \
    --cc=will.deacon@arm.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: link
Be 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.