linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Liviu Dudau <Liviu.Dudau@arm.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Mark Rutland <Mark.Rutland@arm.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"jason@lakedaemon.net" <jason@lakedaemon.net>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	Marc Zyngier <Marc.Zyngier@arm.com>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	Will Deacon <Will.Deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>,
	"suravee.suthikulpanit@amd.com" <suravee.suthikulpanit@amd.com>,
	Catalin Marinas <Catalin.Marinas@arm.com>,
	"bhelgaas@google.com" <bhelgaas@google.com>,
	"tglx@linutronix.de" <tglx@linutronix.de>
Subject: Re: [RFC 2/4] PCI: generic: Add support for ARM64 and MSI(x)
Date: Tue, 7 Oct 2014 13:06:59 +0100	[thread overview]
Message-ID: <20141007120659.GA30590@e102568-lin.cambridge.arm.com> (raw)
In-Reply-To: <3256560.C0cZnIlnAv@wuerfel>

On Wed, Oct 01, 2014 at 10:38:45AM +0100, Arnd Bergmann wrote:

[...]

> pci_mmap_page_range could either get generalized some more in an attempt
> to have a __weak default implementation that works on ARM, or it could
> be changed to lose the dependency on pci_sys_data instead. In either
> case, the change would involve using the generic pci_host_bridge_window
> list.

On ARM pci_mmap_page_range requires pci_sys_data to retrieve its
mem_offset parameter. I had a look, and I do not understand *why*
it is required in that function, so I am asking. That function
is basically used to map PCI resources to userspace, IIUC, through
/proc or /sysfs file mappings. As far as I understand those mappings
expect VMA pgoff to be the CPU address when files representing resources
are mmapped from /proc and 0 when mmapped from /sys (I mean from
userspace, then VMA pgoff should be updated by the kernel to map the
resource).

Question is: why pci_mmap_page_range() should apply an additional
shift to the VMA pgoff based on pci_sys_data.mem_offset, which represents
the offset from cpu->bus offset. I do not understand that. PowerPC
does not seem to apply that fix-up (in PowerPC __pci_mmap_make_offset there
is commented out code which prevents the pci_mem_offset shift to be
applied). I think it all boils down to what the userspace interface is
expecting when the memory areas are mmapped, if anyone has comments on
this that is appreciated.

Thanks,
Lorenzo


  reply	other threads:[~2014-10-07 12:07 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-28 20:53 [RFC 0/4] Add PCI/MSI(x) support for AMD Seattle Platform suravee.suthikulpanit
2014-09-28 20:53 ` [RFC 1/4] arm64: amd-seattle: Adding device tree for AMD Seattle platform suravee.suthikulpanit
2014-10-10 13:45   ` Mark Rutland
2014-10-24 12:08     ` Suravee Suthikulpanit
2014-09-28 20:53 ` [RFC 2/4] PCI: generic: Add support for ARM64 and MSI(x) suravee.suthikulpanit
2014-09-29 14:36   ` Arnd Bergmann
2014-09-30 12:03     ` Lorenzo Pieralisi
2014-09-30 12:31       ` Arnd Bergmann
2014-09-30 16:12         ` Lorenzo Pieralisi
2014-09-30 16:42           ` Liviu Dudau
2014-09-30 17:35             ` Lorenzo Pieralisi
2014-09-30 17:48               ` Liviu Dudau
2014-09-30 18:54                 ` Arnd Bergmann
2014-09-30 20:01                   ` Arnd Bergmann
2014-10-01  8:46                     ` Liviu Dudau
2014-10-01  9:38                       ` Arnd Bergmann
2014-10-07 12:06                         ` Lorenzo Pieralisi [this message]
2014-10-07 13:52                           ` Arnd Bergmann
2014-10-07 14:47                             ` Lorenzo Pieralisi
2014-10-07 21:39                               ` Arnd Bergmann
2014-10-08 10:19                                 ` Lorenzo Pieralisi
2014-10-08 14:47                                   ` Arnd Bergmann
2014-10-09  9:04                                     ` Lorenzo Pieralisi
2014-10-09 10:51                                       ` Arnd Bergmann
2014-10-10 13:58                                         ` Lorenzo Pieralisi
2014-10-10 18:31                                           ` Arnd Bergmann
2014-10-13  9:36                                             ` Lorenzo Pieralisi
2014-10-22 15:59                         ` Lorenzo Pieralisi
2014-10-22 16:49                           ` Bjorn Helgaas
2014-10-22 20:52                           ` Arnd Bergmann
2014-10-23  9:13                             ` Liviu Dudau
2014-10-23 11:27                               ` Lorenzo Pieralisi
2014-10-23 16:52                                 ` Jason Gunthorpe
2014-10-27 16:10                                   ` Lorenzo Pieralisi
2014-10-23 13:33                               ` Arnd Bergmann
2014-10-24 10:04                                 ` Liviu Dudau
2014-11-05 23:40                                 ` Bjorn Helgaas
2014-11-06  0:06                                   ` Arnd Bergmann
2014-12-29 19:32                                 ` Suravee Suthikulpanit
2015-01-02 11:55                                   ` Lorenzo Pieralisi
2015-01-02 18:18                                     ` Suravee Suthikulanit
2015-01-02 21:09                                       ` Arnd Bergmann
2015-01-05 14:48                                         ` Lorenzo Pieralisi
2014-11-05 23:39                             ` Bjorn Helgaas
2014-11-06  0:05                               ` Arnd Bergmann
2014-11-06  9:52                                 ` Lorenzo Pieralisi
2014-09-29 19:19   ` Sunil Kovvuri
2014-09-28 20:53 ` [RFC 3/4] arm64: Do not call enable PCI resources when specify PCI_PROBE_ONLY suravee.suthikulpanit
2014-09-29 14:38   ` Arnd Bergmann
2014-09-29 18:17   ` Bjorn Helgaas
2015-06-23 22:34     ` Benjamin Herrenschmidt
2015-06-23 23:05       ` Russell King - ARM Linux
2015-06-23 22:32   ` Benjamin Herrenschmidt
2014-09-28 20:53 ` [RFC 4/4] irqchip: gicv2m: Add supports for ARM GICv2m MSI(-X) suravee.suthikulpanit
2014-09-28 21:35   ` Suravee Suthikulpanit
2014-09-29 14:23     ` Thomas Gleixner
2014-09-29 14:42   ` Arnd Bergmann

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=20141007120659.GA30590@e102568-lin.cambridge.arm.com \
    --to=lorenzo.pieralisi@arm.com \
    --cc=Catalin.Marinas@arm.com \
    --cc=Liviu.Dudau@arm.com \
    --cc=Marc.Zyngier@arm.com \
    --cc=Mark.Rutland@arm.com \
    --cc=Will.Deacon@arm.com \
    --cc=arnd@arndb.de \
    --cc=bhelgaas@google.com \
    --cc=devicetree@vger.kernel.org \
    --cc=jason@lakedaemon.net \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=suravee.suthikulpanit@amd.com \
    --cc=tglx@linutronix.de \
    /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 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).