| Message ID | 1512410030-21038-1-git-send-email-vidyas@nvidia.com |
|---|---|
| Headers | show |
| Series | Tegra PCIe end point config space map code refactoring | expand |
On Mon, Dec 04, 2017 at 11:23:48PM +0530, Vidya Sagar wrote: > 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. Thierry
[+cc Lorenzo] On Mon, Dec 11, 2017 at 11:54:31AM +0100, Thierry Reding wrote: > On Mon, Dec 04, 2017 at 11:23:48PM +0530, Vidya Sagar wrote: > > 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. 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. Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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: > > On Mon, Dec 04, 2017 at 11:23:48PM +0530, Vidya Sagar wrote: > > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Dec 12, 2017 at 11:01:58AM +0000, Lorenzo Pieralisi wrote: > 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: > > > On Mon, Dec 04, 2017 at 11:23:48PM +0530, Vidya Sagar wrote: > > > > 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. Just to clarify: I wasn't suggesting that these patches are merged for v4.16 via the Tegra tree, only that I carry them in the Tegra tree for a little while so that we can get broader testing and fix things up in case they break. My proposal was to then send a pull request for inclusion in the PCI tree. linux-next can deal with this type of scenario just fine because it will simply see the same branch twice and ignore the second one. If you prefer to merge directly via the PCI tree that works for me too. Thierry
On Tue, Dec 12, 2017 at 01:22:52PM +0100, Thierry Reding wrote: [...] > > > > 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. > > Just to clarify: I wasn't suggesting that these patches are merged for > v4.16 via the Tegra tree, only that I carry them in the Tegra tree for a > little while so that we can get broader testing and fix things up in > case they break. My proposal was to then send a pull request for > inclusion in the PCI tree. linux-next can deal with this type of > scenario just fine because it will simply see the same branch twice and > ignore the second one. > > If you prefer to merge directly via the PCI tree that works for me too. We would end up merging the patches into -next at the same time, so there is not much point in queuing them via Tegra if they go via the PCI tree eventually; we should not add to -next patches that are not ready to be merged anyway. I need your help (ACKs) though to queue them up - I review the patches but I can neither test them nor get access to HW TRMs so for some of them there is not much I can do. Thanks, Lorenzo -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Dec 14, 2017 at 10:37:22AM +0000, Lorenzo Pieralisi wrote: > On Tue, Dec 12, 2017 at 01:22:52PM +0100, Thierry Reding wrote: > > [...] > > > > > > 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. > > > > Just to clarify: I wasn't suggesting that these patches are merged for > > v4.16 via the Tegra tree, only that I carry them in the Tegra tree for a > > little while so that we can get broader testing and fix things up in > > case they break. My proposal was to then send a pull request for > > inclusion in the PCI tree. linux-next can deal with this type of > > scenario just fine because it will simply see the same branch twice and > > ignore the second one. > > > > If you prefer to merge directly via the PCI tree that works for me too. > > We would end up merging the patches into -next at the same time, so there > is not much point in queuing them via Tegra if they go via the PCI tree > eventually; we should not add to -next patches that are not ready to > be merged anyway. > > I need your help (ACKs) though to queue them up - I review the patches > but I can neither test them nor get access to HW TRMs so for some of them > there is not much I can do. I've sent out a small series of patches that apply on top of this patch which clean up and fix a couple of issues with this patch. Feel free to squash those into this patch if you prefer. Acked-by: Thierry Reding <treding@nvidia.com>