On Tue, May 27, 2014 at 09:23:30PM +0100, Benjamin Herrenschmidt wrote:
> On Tue, 2014-05-27 at 20:34 +0100, Will Deacon wrote:
>
> > Do you mean the io{read,write} functions? Funnily enough, they're already
> > relaxed on ARM if you go by the semantics I've proposed. That implies we at
> > least
On Tue, May 27, 2014 at 09:21:38PM +0100, Benjamin Herrenschmidt wrote:
> On Tue, 2014-05-27 at 20:32 +0100, Will Deacon wrote:
>
> > Why would you need two barriers? I would have though an mmiowb() inlined
> > into writel after the store operation would be sufficient. Or is this to
> > ensure a
On Tue, 2014-05-27 at 20:34 +0100, Will Deacon wrote:
> Do you mean the io{read,write} functions? Funnily enough, they're already
> relaxed on ARM if you go by the semantics I've proposed. That implies we at
> least need some Documentation to that effect...
>
> What do you do on ppc?
They are
On Tue, 2014-05-27 at 20:32 +0100, Will Deacon wrote:
> Why would you need two barriers? I would have though an mmiowb() inlined
> into writel after the store operation would be sufficient. Or is this to
> ensure a non-relaxed write is ordered with respect to a relaxed write?
Well, so the
On Sun, May 25, 2014 at 10:47:50PM +0100, Benjamin Herrenschmidt wrote:
> On Thu, 2014-05-22 at 17:47 +0100, Will Deacon wrote:
> > Hi all,
> >
> > This is version 2 of the series I originally posted here:
> >
> > https://lkml.org/lkml/2014/4/17/269
> >
> > Changes since v1 include:
> >
> >
Hi Ben,
On Sun, May 25, 2014 at 10:46:03PM +0100, Benjamin Herrenschmidt wrote:
> On Thu, 2014-05-22 at 17:47 +0100, Will Deacon wrote:
> > A corollary to this is that mmiowb() probably needs rethinking. As it
> > currently
> > stands, an mmiowb() is required to order MMIO writes to a device
Hi Ben,
On Sun, May 25, 2014 at 10:46:03PM +0100, Benjamin Herrenschmidt wrote:
On Thu, 2014-05-22 at 17:47 +0100, Will Deacon wrote:
A corollary to this is that mmiowb() probably needs rethinking. As it
currently
stands, an mmiowb() is required to order MMIO writes to a device from
On Sun, May 25, 2014 at 10:47:50PM +0100, Benjamin Herrenschmidt wrote:
On Thu, 2014-05-22 at 17:47 +0100, Will Deacon wrote:
Hi all,
This is version 2 of the series I originally posted here:
https://lkml.org/lkml/2014/4/17/269
Changes since v1 include:
- Added relevant
On Tue, 2014-05-27 at 20:32 +0100, Will Deacon wrote:
Why would you need two barriers? I would have though an mmiowb() inlined
into writel after the store operation would be sufficient. Or is this to
ensure a non-relaxed write is ordered with respect to a relaxed write?
Well, so the
On Tue, 2014-05-27 at 20:34 +0100, Will Deacon wrote:
Do you mean the io{read,write} functions? Funnily enough, they're already
relaxed on ARM if you go by the semantics I've proposed. That implies we at
least need some Documentation to that effect...
What do you do on ppc?
They are not
On Tue, May 27, 2014 at 09:21:38PM +0100, Benjamin Herrenschmidt wrote:
On Tue, 2014-05-27 at 20:32 +0100, Will Deacon wrote:
Why would you need two barriers? I would have though an mmiowb() inlined
into writel after the store operation would be sufficient. Or is this to
ensure a
On Tue, May 27, 2014 at 09:23:30PM +0100, Benjamin Herrenschmidt wrote:
On Tue, 2014-05-27 at 20:34 +0100, Will Deacon wrote:
Do you mean the io{read,write} functions? Funnily enough, they're already
relaxed on ARM if you go by the semantics I've proposed. That implies we at
least need
On Thu, 2014-05-22 at 17:47 +0100, Will Deacon wrote:
> Hi all,
>
> This is version 2 of the series I originally posted here:
>
> https://lkml.org/lkml/2014/4/17/269
>
> Changes since v1 include:
>
> - Added relevant acks from arch maintainers
> - Fixed potential compiler re-ordering issue
On Thu, 2014-05-22 at 17:47 +0100, Will Deacon wrote:
> A corollary to this is that mmiowb() probably needs rethinking. As it
> currently
> stands, an mmiowb() is required to order MMIO writes to a device from multiple
> CPUs, even if that device is protected by a lock. However, this isn't often
On Thu, 2014-05-22 at 17:47 +0100, Will Deacon wrote:
A corollary to this is that mmiowb() probably needs rethinking. As it
currently
stands, an mmiowb() is required to order MMIO writes to a device from multiple
CPUs, even if that device is protected by a lock. However, this isn't often
On Thu, 2014-05-22 at 17:47 +0100, Will Deacon wrote:
Hi all,
This is version 2 of the series I originally posted here:
https://lkml.org/lkml/2014/4/17/269
Changes since v1 include:
- Added relevant acks from arch maintainers
- Fixed potential compiler re-ordering issue for x86
Hi all,
This is version 2 of the series I originally posted here:
https://lkml.org/lkml/2014/4/17/269
Changes since v1 include:
- Added relevant acks from arch maintainers
- Fixed potential compiler re-ordering issue for x86 definitions
I'd *really* appreciate some feedback on the
Hi all,
This is version 2 of the series I originally posted here:
https://lkml.org/lkml/2014/4/17/269
Changes since v1 include:
- Added relevant acks from arch maintainers
- Fixed potential compiler re-ordering issue for x86 definitions
I'd *really* appreciate some feedback on the
18 matches
Mail list logo
