* [PATCH] arm64: pci: add support for pci_mmap_page_range
@ 2015-07-24 5:54 Jerin Jacob
2015-07-24 14:41 ` Will Deacon
0 siblings, 1 reply; 6+ messages in thread
From: Jerin Jacob @ 2015-07-24 5:54 UTC (permalink / raw)
To: linux-arm-kernel
certain X11 servers and user space network drivers frameworks
need PCI mmaped /sys/bus/pci/devices/B:D:F/resourceX file to access PCI bar
address space from user space.
Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
---
arch/arm64/include/asm/pci.h | 6 ++++++
arch/arm64/kernel/pci.c | 20 ++++++++++++++++++++
2 files changed, 26 insertions(+)
diff --git a/arch/arm64/include/asm/pci.h b/arch/arm64/include/asm/pci.h
index b008a72..e7afe8d 100644
--- a/arch/arm64/include/asm/pci.h
+++ b/arch/arm64/include/asm/pci.h
@@ -39,5 +39,11 @@ static inline int pci_proc_domain(struct pci_bus *bus)
}
#endif /* CONFIG_PCI */
+#define HAVE_PCI_MMAP
+
+extern int pci_mmap_page_range(struct pci_dev *dev, struct vm_area_struct *vma,
+ enum pci_mmap_state mmap_state, int write_combine);
+
+
#endif /* __KERNEL__ */
#endif /* __ASM_PCI_H */
diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
index 4095379..94b04c7 100644
--- a/arch/arm64/kernel/pci.c
+++ b/arch/arm64/kernel/pci.c
@@ -71,3 +71,23 @@ struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
return NULL;
}
#endif
+
+int pci_mmap_page_range(struct pci_dev *dev, struct vm_area_struct *vma,
+ enum pci_mmap_state mmap_state, int write_combine)
+{
+ /*
+ * I/O space can be accessed via normal processor loads and stores on
+ * this platform but for now we elect not to do this and portable
+ * drivers should not do this anyway.
+ */
+ if (mmap_state == pci_mmap_io)
+ return -EINVAL;
+
+ if (write_combine)
+ vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
+ else
+ vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
+
+ return remap_pfn_range(vma, vma->vm_start, vma->vm_pgoff,
+ vma->vm_end - vma->vm_start, vma->vm_page_prot);
+}
--
2.1.0
^ permalink raw reply related [flat|nested] 6+ messages in thread
* [PATCH] arm64: pci: add support for pci_mmap_page_range
2015-07-24 5:54 [PATCH] arm64: pci: add support for pci_mmap_page_range Jerin Jacob
@ 2015-07-24 14:41 ` Will Deacon
2015-07-27 5:10 ` Jerin Jacob
0 siblings, 1 reply; 6+ messages in thread
From: Will Deacon @ 2015-07-24 14:41 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Jul 24, 2015 at 06:54:23AM +0100, Jerin Jacob wrote:
> certain X11 servers and user space network drivers frameworks
> need PCI mmaped /sys/bus/pci/devices/B:D:F/resourceX file to access PCI bar
> address space from user space.
>
> Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> ---
> arch/arm64/include/asm/pci.h | 6 ++++++
> arch/arm64/kernel/pci.c | 20 ++++++++++++++++++++
> 2 files changed, 26 insertions(+)
>
> diff --git a/arch/arm64/include/asm/pci.h b/arch/arm64/include/asm/pci.h
> index b008a72..e7afe8d 100644
> --- a/arch/arm64/include/asm/pci.h
> +++ b/arch/arm64/include/asm/pci.h
> @@ -39,5 +39,11 @@ static inline int pci_proc_domain(struct pci_bus *bus)
> }
> #endif /* CONFIG_PCI */
>
> +#define HAVE_PCI_MMAP
> +
> +extern int pci_mmap_page_range(struct pci_dev *dev, struct vm_area_struct *vma,
> + enum pci_mmap_state mmap_state, int write_combine);
> +
> +
> #endif /* __KERNEL__ */
> #endif /* __ASM_PCI_H */
> diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
> index 4095379..94b04c7 100644
> --- a/arch/arm64/kernel/pci.c
> +++ b/arch/arm64/kernel/pci.c
> @@ -71,3 +71,23 @@ struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
> return NULL;
> }
> #endif
> +
> +int pci_mmap_page_range(struct pci_dev *dev, struct vm_area_struct *vma,
> + enum pci_mmap_state mmap_state, int write_combine)
> +{
> + /*
> + * I/O space can be accessed via normal processor loads and stores on
> + * this platform but for now we elect not to do this and portable
> + * drivers should not do this anyway.
> + */
> + if (mmap_state == pci_mmap_io)
> + return -EINVAL;
> +
> + if (write_combine)
> + vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
> + else
> + vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
> +
> + return remap_pfn_range(vma, vma->vm_start, vma->vm_pgoff,
> + vma->vm_end - vma->vm_start, vma->vm_page_prot);
> +}
So pci_iomap_range chooses the memory attributes based on the BAR flags
(and even then it looks weird -- CACHEABLE => ioremap, else ioremap_nocache,
which is just the same as ioremap on arm64).
It would be good to understand (a) why this is different and (b) what
the consistent set of attributes should be.
Will
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH] arm64: pci: add support for pci_mmap_page_range
2015-07-24 14:41 ` Will Deacon
@ 2015-07-27 5:10 ` Jerin Jacob
2015-07-28 11:20 ` Will Deacon
0 siblings, 1 reply; 6+ messages in thread
From: Jerin Jacob @ 2015-07-27 5:10 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Jul 24, 2015 at 03:41:03PM +0100, Will Deacon wrote:
> On Fri, Jul 24, 2015 at 06:54:23AM +0100, Jerin Jacob wrote:
> > certain X11 servers and user space network drivers frameworks
> > need PCI mmaped /sys/bus/pci/devices/B:D:F/resourceX file to access PCI bar
> > address space from user space.
> >
> > Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> > ---
> > arch/arm64/include/asm/pci.h | 6 ++++++
> > arch/arm64/kernel/pci.c | 20 ++++++++++++++++++++
> > 2 files changed, 26 insertions(+)
> >
> > diff --git a/arch/arm64/include/asm/pci.h b/arch/arm64/include/asm/pci.h
> > index b008a72..e7afe8d 100644
> > --- a/arch/arm64/include/asm/pci.h
> > +++ b/arch/arm64/include/asm/pci.h
> > @@ -39,5 +39,11 @@ static inline int pci_proc_domain(struct pci_bus *bus)
> > }
> > #endif /* CONFIG_PCI */
> >
> > +#define HAVE_PCI_MMAP
> > +
> > +extern int pci_mmap_page_range(struct pci_dev *dev, struct vm_area_struct *vma,
> > + enum pci_mmap_state mmap_state, int write_combine);
> > +
> > +
> > #endif /* __KERNEL__ */
> > #endif /* __ASM_PCI_H */
> > diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
> > index 4095379..94b04c7 100644
> > --- a/arch/arm64/kernel/pci.c
> > +++ b/arch/arm64/kernel/pci.c
> > @@ -71,3 +71,23 @@ struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
> > return NULL;
> > }
> > #endif
> > +
> > +int pci_mmap_page_range(struct pci_dev *dev, struct vm_area_struct *vma,
> > + enum pci_mmap_state mmap_state, int write_combine)
> > +{
> > + /*
> > + * I/O space can be accessed via normal processor loads and stores on
> > + * this platform but for now we elect not to do this and portable
> > + * drivers should not do this anyway.
> > + */
> > + if (mmap_state == pci_mmap_io)
> > + return -EINVAL;
> > +
> > + if (write_combine)
> > + vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
> > + else
> > + vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
> > +
> > + return remap_pfn_range(vma, vma->vm_start, vma->vm_pgoff,
> > + vma->vm_end - vma->vm_start, vma->vm_page_prot);
> > +}
>
> So pci_iomap_range chooses the memory attributes based on the BAR flags
> (and even then it looks weird -- CACHEABLE => ioremap, else ioremap_nocache,
> which is just the same as ioremap on arm64).
>
> It would be good to understand (a) why this is different and (b) what
AFAIU, pci_iomap_range is the generic implementation and chooses to
use only minimal attributes that works on all the architectures.
The primary consumer of pci_iomap_range is virtio_pci driver,Which
doesn't care about HW PCI memory attributes like Prefetchable.
> the consistent set of attributes should be.
PCI perspective, memory attributes are Prefetchable and non-Prefetchable
for a given BAR.
Former one does have read side-effects or supports write
merging(typically used
by graphics memory) and latter one has read side effects and does not
support write merging(typically used by register files)
IMO, In armv8 nomenclature, MT_NORMAL_NC and MT_DEVICE_nGnRnE map
correctly to above PCI memory attribute definitions.
and pci-sysfs.c(consumer of pci_mmap_page_range)
creates the /sys/bus/pci/devices/B:D:F/resource[_wc]X file based
on BAR flag(Prefetchable or non-Prefetchable) and expose to userspace.
Jerin
>
> Will
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH] arm64: pci: add support for pci_mmap_page_range
2015-07-27 5:10 ` Jerin Jacob
@ 2015-07-28 11:20 ` Will Deacon
2015-07-28 14:03 ` Jerin Jacob
0 siblings, 1 reply; 6+ messages in thread
From: Will Deacon @ 2015-07-28 11:20 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Jul 27, 2015 at 06:10:29AM +0100, Jerin Jacob wrote:
> On Fri, Jul 24, 2015 at 03:41:03PM +0100, Will Deacon wrote:
> > On Fri, Jul 24, 2015 at 06:54:23AM +0100, Jerin Jacob wrote:
> > > +int pci_mmap_page_range(struct pci_dev *dev, struct vm_area_struct *vma,
> > > + enum pci_mmap_state mmap_state, int write_combine)
> > > +{
> > > + /*
> > > + * I/O space can be accessed via normal processor loads and stores on
> > > + * this platform but for now we elect not to do this and portable
> > > + * drivers should not do this anyway.
> > > + */
> > > + if (mmap_state == pci_mmap_io)
> > > + return -EINVAL;
> > > +
> > > + if (write_combine)
> > > + vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
> > > + else
> > > + vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
> > > +
> > > + return remap_pfn_range(vma, vma->vm_start, vma->vm_pgoff,
> > > + vma->vm_end - vma->vm_start, vma->vm_page_prot);
> > > +}
> >
> > So pci_iomap_range chooses the memory attributes based on the BAR flags
> > (and even then it looks weird -- CACHEABLE => ioremap, else ioremap_nocache,
> > which is just the same as ioremap on arm64).
> >
> > It would be good to understand (a) why this is different and (b) what
>
> AFAIU, pci_iomap_range is the generic implementation and chooses to
> use only minimal attributes that works on all the architectures.
> The primary consumer of pci_iomap_range is virtio_pci driver,Which
> doesn't care about HW PCI memory attributes like Prefetchable.
pci_iomap calls pci_iomap_range.
> > the consistent set of attributes should be.
>
> PCI perspective, memory attributes are Prefetchable and non-Prefetchable
> for a given BAR.
>
> Former one does have read side-effects or supports write
> merging(typically used
> by graphics memory) and latter one has read side effects and does not
> support write merging(typically used by register files)
>
> IMO, In armv8 nomenclature, MT_NORMAL_NC and MT_DEVICE_nGnRnE map
> correctly to above PCI memory attribute definitions.
I agree with your choice of memory types (well, almost. We probably don't
need the nE), I'm just after some consistency within the kernel, because
pci_iomap_range looks wrong to me. Another different example is
pci_ioremap_bar, which always uses ioremap_nocache.
Will
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH] arm64: pci: add support for pci_mmap_page_range
2015-07-28 11:20 ` Will Deacon
@ 2015-07-28 14:03 ` Jerin Jacob
2015-07-28 14:41 ` Will Deacon
0 siblings, 1 reply; 6+ messages in thread
From: Jerin Jacob @ 2015-07-28 14:03 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Jul 28, 2015 at 12:20:57PM +0100, Will Deacon wrote:
> On Mon, Jul 27, 2015 at 06:10:29AM +0100, Jerin Jacob wrote:
> > On Fri, Jul 24, 2015 at 03:41:03PM +0100, Will Deacon wrote:
> > > On Fri, Jul 24, 2015 at 06:54:23AM +0100, Jerin Jacob wrote:
> > > > +int pci_mmap_page_range(struct pci_dev *dev, struct vm_area_struct *vma,
> > > > + enum pci_mmap_state mmap_state, int write_combine)
> > > > +{
> > > > + /*
> > > > + * I/O space can be accessed via normal processor loads and stores on
> > > > + * this platform but for now we elect not to do this and portable
> > > > + * drivers should not do this anyway.
> > > > + */
> > > > + if (mmap_state == pci_mmap_io)
> > > > + return -EINVAL;
> > > > +
> > > > + if (write_combine)
> > > > + vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
> > > > + else
> > > > + vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
> > > > +
> > > > + return remap_pfn_range(vma, vma->vm_start, vma->vm_pgoff,
> > > > + vma->vm_end - vma->vm_start, vma->vm_page_prot);
> > > > +}
> > >
> > > So pci_iomap_range chooses the memory attributes based on the BAR flags
> > > (and even then it looks weird -- CACHEABLE => ioremap, else ioremap_nocache,
> > > which is just the same as ioremap on arm64).
> > >
> > > It would be good to understand (a) why this is different and (b) what
> >
> > AFAIU, pci_iomap_range is the generic implementation and chooses to
> > use only minimal attributes that works on all the architectures.
> > The primary consumer of pci_iomap_range is virtio_pci driver,Which
> > doesn't care about HW PCI memory attributes like Prefetchable.
>
> pci_iomap calls pci_iomap_range.
Yes, I missed that.
>
> > > the consistent set of attributes should be.
> >
> > PCI perspective, memory attributes are Prefetchable and non-Prefetchable
> > for a given BAR.
> >
> > Former one does have read side-effects or supports write
> > merging(typically used
> > by graphics memory) and latter one has read side effects and does not
> > support write merging(typically used by register files)
> >
> > IMO, In armv8 nomenclature, MT_NORMAL_NC and MT_DEVICE_nGnRnE map
> > correctly to above PCI memory attribute definitions.
>
> I agree with your choice of memory types (well, almost. We probably don't
> need the nE), I'm just after some consistency within the kernel, because
I thought so, However, Since PCIe deals with off-chip peripherals,
IMO it should be MT_DEVICE_nGnRnE(strongly ordered).
Early write acknowledgment may have side effect based on the topology.
(connected under Bridge etc).
IMO, It make sense to mark as nGnRE for on-chip peripherals. But
If you still think we need to mark as nGnRE then I can submit v2 with
nGnRE else IMO, currect patch is fine for pci_mmap_page_range
Jerin
> pci_iomap_range looks wrong to me. Another different example is
> pci_ioremap_bar, which always uses ioremap_nocache.
>
> Will
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH] arm64: pci: add support for pci_mmap_page_range
2015-07-28 14:03 ` Jerin Jacob
@ 2015-07-28 14:41 ` Will Deacon
0 siblings, 0 replies; 6+ messages in thread
From: Will Deacon @ 2015-07-28 14:41 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Jul 28, 2015 at 03:03:52PM +0100, Jerin Jacob wrote:
> On Tue, Jul 28, 2015 at 12:20:57PM +0100, Will Deacon wrote:
> > On Mon, Jul 27, 2015 at 06:10:29AM +0100, Jerin Jacob wrote:
> > > On Fri, Jul 24, 2015 at 03:41:03PM +0100, Will Deacon wrote:
> > > > So pci_iomap_range chooses the memory attributes based on the BAR flags
> > > > (and even then it looks weird -- CACHEABLE => ioremap, else ioremap_nocache,
> > > > which is just the same as ioremap on arm64).
> > > >
> > > > It would be good to understand (a) why this is different and (b) what
> > >
> > > AFAIU, pci_iomap_range is the generic implementation and chooses to
> > > use only minimal attributes that works on all the architectures.
> > > The primary consumer of pci_iomap_range is virtio_pci driver,Which
> > > doesn't care about HW PCI memory attributes like Prefetchable.
> >
> > pci_iomap calls pci_iomap_range.
>
> Yes, I missed that.
>
> >
> > > > the consistent set of attributes should be.
> > >
> > > PCI perspective, memory attributes are Prefetchable and non-Prefetchable
> > > for a given BAR.
> > >
> > > Former one does have read side-effects or supports write
> > > merging(typically used
> > > by graphics memory) and latter one has read side effects and does not
> > > support write merging(typically used by register files)
> > >
> > > IMO, In armv8 nomenclature, MT_NORMAL_NC and MT_DEVICE_nGnRnE map
> > > correctly to above PCI memory attribute definitions.
> >
> > I agree with your choice of memory types (well, almost. We probably don't
> > need the nE), I'm just after some consistency within the kernel, because
>
> I thought so, However, Since PCIe deals with off-chip peripherals,
> IMO it should be MT_DEVICE_nGnRnE(strongly ordered).
> Early write acknowledgment may have side effect based on the topology.
> (connected under Bridge etc).
> IMO, It make sense to mark as nGnRE for on-chip peripherals. But
> If you still think we need to mark as nGnRE then I can submit v2 with
> nGnRE else IMO, currect patch is fine for pci_mmap_page_range
It's the inconsistencies that I've pointed out previously that bother
me the most. I don't really care what attributes we use, as long as
there's a common way to translate a given BAR to a given MT_*.
Will
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2015-07-28 14:41 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-07-24 5:54 [PATCH] arm64: pci: add support for pci_mmap_page_range Jerin Jacob
2015-07-24 14:41 ` Will Deacon
2015-07-27 5:10 ` Jerin Jacob
2015-07-28 11:20 ` Will Deacon
2015-07-28 14:03 ` Jerin Jacob
2015-07-28 14:41 ` Will Deacon
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).