From: Bjorn Helgaas <helgaas@kernel.org>
To: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Liviu Dudau <Liviu.Dudau@arm.com>,
Russell King <linux@arm.linux.org.uk>,
linux-arm-kernel@lists.infradead.org, linux-pci@vger.kernel.org
Subject: Re: pci_ioremap_set_mem_type(), pci_remap_iospace()
Date: Thu, 28 Apr 2016 11:03:39 -0500 [thread overview]
Message-ID: <20160428160339.GA19785@localhost> (raw)
In-Reply-To: <20160428163646.432e2c68@free-electrons.com>
On Thu, Apr 28, 2016 at 04:36:46PM +0200, Thomas Petazzoni wrote:
> Hello,
>
> On Thu, 28 Apr 2016 09:19:20 -0500, Bjorn Helgaas wrote:
>
> > > coherency_cpu_base = of_iomap(np, 0);
> > > - arch_ioremap_caller = armada_pcie_wa_ioremap_caller;
> > > + arch_ioremap_caller = armada_wa_ioremap_caller;
> > > + pci_ioremap_set_mem_type(MT_UNCACHED);
> >
> > This makes sense to me because I think this changes ioremap() to do
> > the right thing.
>
> What changes ioremap() to do the right thing for all mappings *except*
> PCI I/O mappings:
>
> arch_ioremap_caller = armada_wa_ioremap_caller;
>
> > But my concern is that ioremap_page_range() doesn't
> > actually use ioremap(), so pci_ioremap_set_mem_type() has no effect on
> > that path. pci_remap_iospace() uses ioremap_page_range(), so I
> > suspect it will use the wrong attributes.
>
> Indeed, ioremap_page_range() doesn't use ioremap(), and that's why
> there is this separate pci_ioremap_set_mem_type() to ensure that
> mappings done for PCI I/O space are done with MT_UNCACHED.
>
> And indeed, pci_remap_iospace() would not work for me, as it wouldn't
> use the memory attributes set by pci_ioremap_set_mem_type().
Right. pci_remap_iospace() is a generic interface and should work
on all arches. It *is* declared __weak, but there's no arch-specific
implementation of it, and I think if we made ioremap_page_range()
truly generic, we could make pci_remap_iospace() non-weak.
> To be honest, I am wondering why we're not using the same memory
> attribute for PCI I/O space as the memory attributes used for anything
> else that's ioremapped. In practice, that's what happens on ARM:
> ioremap() uses MT_DEVICE by default, and pci_ioremap_io() uses
> MT_DEVICE as well.
>
> > > 1/ Providing an alternate version of pci_remap_iospace() that allows
> > > to pass the memory attribute to be used.
> >
> > I'd rather fix ioremap_page_range() somehow, because that's an
> > exported interface, and if we only fix pci_remap_iospace(), we still
> > have to worry about ioremap_page_range() doing the wrong thing.
>
> What do you want to fix in ioremap_page_range() ? It already allows
> passing the memory type that you want, so I'm not sure to understand.
Yes, but in order for ioremap_page_range() to work on arm, we have to
pass in an arm-specific memory type
(__pgprot(get_mem_type(pci_ioremap_mem_type)->prot_pte)).
We can't do that because ioremap_page_range() is a generic function,
implemented in lib/ioremap.c and exported to modules, and generic
callers only know about pgprot_noncached, pgprot_writecombine,
pgprot_writethrough, pgprot_device, etc.
WARNING: multiple messages have this Message-ID (diff)
From: helgaas@kernel.org (Bjorn Helgaas)
To: linux-arm-kernel@lists.infradead.org
Subject: pci_ioremap_set_mem_type(), pci_remap_iospace()
Date: Thu, 28 Apr 2016 11:03:39 -0500 [thread overview]
Message-ID: <20160428160339.GA19785@localhost> (raw)
In-Reply-To: <20160428163646.432e2c68@free-electrons.com>
On Thu, Apr 28, 2016 at 04:36:46PM +0200, Thomas Petazzoni wrote:
> Hello,
>
> On Thu, 28 Apr 2016 09:19:20 -0500, Bjorn Helgaas wrote:
>
> > > coherency_cpu_base = of_iomap(np, 0);
> > > - arch_ioremap_caller = armada_pcie_wa_ioremap_caller;
> > > + arch_ioremap_caller = armada_wa_ioremap_caller;
> > > + pci_ioremap_set_mem_type(MT_UNCACHED);
> >
> > This makes sense to me because I think this changes ioremap() to do
> > the right thing.
>
> What changes ioremap() to do the right thing for all mappings *except*
> PCI I/O mappings:
>
> arch_ioremap_caller = armada_wa_ioremap_caller;
>
> > But my concern is that ioremap_page_range() doesn't
> > actually use ioremap(), so pci_ioremap_set_mem_type() has no effect on
> > that path. pci_remap_iospace() uses ioremap_page_range(), so I
> > suspect it will use the wrong attributes.
>
> Indeed, ioremap_page_range() doesn't use ioremap(), and that's why
> there is this separate pci_ioremap_set_mem_type() to ensure that
> mappings done for PCI I/O space are done with MT_UNCACHED.
>
> And indeed, pci_remap_iospace() would not work for me, as it wouldn't
> use the memory attributes set by pci_ioremap_set_mem_type().
Right. pci_remap_iospace() is a generic interface and should work
on all arches. It *is* declared __weak, but there's no arch-specific
implementation of it, and I think if we made ioremap_page_range()
truly generic, we could make pci_remap_iospace() non-weak.
> To be honest, I am wondering why we're not using the same memory
> attribute for PCI I/O space as the memory attributes used for anything
> else that's ioremapped. In practice, that's what happens on ARM:
> ioremap() uses MT_DEVICE by default, and pci_ioremap_io() uses
> MT_DEVICE as well.
>
> > > 1/ Providing an alternate version of pci_remap_iospace() that allows
> > > to pass the memory attribute to be used.
> >
> > I'd rather fix ioremap_page_range() somehow, because that's an
> > exported interface, and if we only fix pci_remap_iospace(), we still
> > have to worry about ioremap_page_range() doing the wrong thing.
>
> What do you want to fix in ioremap_page_range() ? It already allows
> passing the memory type that you want, so I'm not sure to understand.
Yes, but in order for ioremap_page_range() to work on arm, we have to
pass in an arm-specific memory type
(__pgprot(get_mem_type(pci_ioremap_mem_type)->prot_pte)).
We can't do that because ioremap_page_range() is a generic function,
implemented in lib/ioremap.c and exported to modules, and generic
callers only know about pgprot_noncached, pgprot_writecombine,
pgprot_writethrough, pgprot_device, etc.
next prev parent reply other threads:[~2016-04-28 16:03 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-27 22:58 pci_ioremap_set_mem_type(), pci_remap_iospace() Bjorn Helgaas
2016-04-28 7:21 ` Thomas Petazzoni
2016-04-28 12:06 ` Liviu Dudau
2016-04-28 12:13 ` Thomas Petazzoni
2016-04-28 13:02 ` Liviu Dudau
2016-04-28 13:12 ` Thomas Petazzoni
2016-04-28 14:41 ` Liviu Dudau
2016-04-28 14:47 ` Thomas Petazzoni
2016-04-28 16:23 ` Arnd Bergmann
2016-04-28 14:19 ` Bjorn Helgaas
2016-04-28 14:19 ` Bjorn Helgaas
2016-04-28 14:36 ` Thomas Petazzoni
2016-04-28 14:36 ` Thomas Petazzoni
2016-04-28 16:03 ` Bjorn Helgaas [this message]
2016-04-28 16:03 ` Bjorn Helgaas
2016-04-28 14:33 ` Bjorn Helgaas
2016-04-28 14:33 ` Bjorn Helgaas
2016-04-28 14:38 ` Thomas Petazzoni
2016-04-28 14:38 ` Thomas Petazzoni
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=20160428160339.GA19785@localhost \
--to=helgaas@kernel.org \
--cc=Liviu.Dudau@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=thomas.petazzoni@free-electrons.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.