Re: [PATCH V3 0/2] Tegra PCIe end point config space map code refactoring

On Mon, Dec 11, 2017 at 11:54:53AM -0600, Bjorn Helgaas wrote:

[+cc Lorenzo]

On Mon, Dec 11, 2017 at 11:54:31AM +0100, Thierry Reding wrote:

quoted

On Mon, Dec 04, 2017 at 11:23:48PM +0530, Vidya Sagar wrote:

quoted

PCIe host controller in Tegra SoCs has 1GB of aperture available
for mapping end points config space, IO and BARs. In that, currently
256MB is being reserved for mapping end points configuration space
which leaves less memory space available for mapping end points BARs
on some of the platforms.
This patch series attempts to map only 4K space from 1GB aperture to
access end points configuration space.

Currently, this change can benefit T20 and T186 in saving (i.e. repurposed
to use for BAR mapping) physical space as well as kernel virtual mapping space,
it saves only kernel virtual address space in T30, T124, T132 and T210.

NOTE: Since T186 PCIe DT entry is not yet present in main line (it is currently
merged to 'for-4.15/arm64/dt' branch), nothing gets broken with this change for T186.
For older platforms (T20, T30, T124, T132, T210), this change works fine without any
DT modifications

Testing Done on T124, T210 & T186:
 Enumeration and basic functionality of immediate devices
 Enumeration of devices behind a PCIe switch
 Complete 4K configuration space access

Vidya Sagar (2):
  PCI: tegra: refactor config space mapping code
  ARM64: tegra: limit PCIe config space mapping to 4K for T186

 arch/arm64/boot/dts/nvidia/tegra186.dtsi |   8 +-
 drivers/pci/host/pci-tegra.c             | 125 ++++++++++---------------------
 2 files changed, 44 insertions(+), 89 deletions(-)

Hi Bjorn,

there's a bunch of PCI related patches for Tegra floating around on the
lists. I'm wondering if you'd be okay if I pick those up into the Tegra
tree after they've been reviewed and send you a pull request later on
(say around v4.15-rc6). That would allow me to get things cooking in
linux-next for a bit and get broader testing in addition to the
flexibility to patch things up if they break.

Lorenzo will be merging the Tegra stuff, so this is more a question
for him.

Just to clarify, I think your questions is about putting those patches
in
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git#for-next.
If you put them there they will show up in linux-next, and then when
Lorenzo merges them, you'll have to coordinate so they don't get
merged into linux-next twice (once via the usual PCI tree route and
again via the Tegra tree).

If you wait until after they've been reviewed to put them into the
Tegra tree, I'm not sure what the gain is, because I assume Lorenzo
would merge them at about that same point.

I think that after the review, the Tegra patches that are considered for
upstream they should go to -next via the PCI tree as any other platform PCI
patches; the relevant patches need ACKs from the respective platform
maintainer - I am getting to them as fast as I can.

This cycle isn't going to be ideal timing with all the holidays
coming up.  I know I'm going to be traveling and on vacation quite a
bit in the rc5, 6, 7 timeframe.

Yes timing is not ideal - I won't be able to review anything in the -rc5
week either but apart from that I should be online.

Lorenzo