| Message ID | 20171214134545.11143-1-thierry.reding@gmail.com |
|---|---|
| Headers | show |
| Series | PCI: tegra: Configuration space mapping cleanups and fixes | expand |
Hi Thierry, On Thu, Dec 14, 2017 at 02:45:41PM +0100, Thierry Reding wrote: > From: Thierry Reding <treding@nvidia.com> > > Hi Lorenzo, > > This cleans up a few oddities that I found while reviewing and testing > the patch > > [PATCH V3 1/2] PCI: tegra: refactor config space mapping code > > that Vidya Sagar sent out earlier. The first three patches are mostly > cleanup and admittedly somewhat bikeshedding in nature. They could've > been just review comments, but I thought I'd just submit them as a > series of patches since I had already typed them up anyway. > > The last patch gets rid of an artificial restriction regarding the > mapping address and does a bit of simplification. > > These are technically incremental on top of the original patch, but if > you prefer, feel free to squash them into that patch. I took some time to have a look at all of them and actually I am happy with the end result, except that I would prefer if you squash them all in and rewrite the logs since I can easily miss something (eg I have no insights into the Tegra config space FPCI windowing mechanism) - I will merge the resulting patch(es). I have a question: after merging both series, are tegra_pcie_{add/remove}_bus() (and struct tegra_pcie_bus) still needed ? I do not think so. > I've tested these on all of Tegra20, Tegra30, Tegra124, Tegra210 and > Tegra186. If the testing goes OK please send me unified series and will merge that one. This brings me to a question for you and Bjorn: how do you usually handle DT updates ? I assume we send them via the PCI tree but I am asking to prevent any issue upfront. 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 05:37:45PM +0000, Lorenzo Pieralisi wrote: > Hi Thierry, > > On Thu, Dec 14, 2017 at 02:45:41PM +0100, Thierry Reding wrote: > > From: Thierry Reding <treding@nvidia.com> > > > > Hi Lorenzo, > > > > This cleans up a few oddities that I found while reviewing and testing > > the patch > > > > [PATCH V3 1/2] PCI: tegra: refactor config space mapping code > > > > that Vidya Sagar sent out earlier. The first three patches are mostly > > cleanup and admittedly somewhat bikeshedding in nature. They could've > > been just review comments, but I thought I'd just submit them as a > > series of patches since I had already typed them up anyway. > > > > The last patch gets rid of an artificial restriction regarding the > > mapping address and does a bit of simplification. > > > > These are technically incremental on top of the original patch, but if > > you prefer, feel free to squash them into that patch. > > I took some time to have a look at all of them and actually I am happy > with the end result, except that I would prefer if you squash them all > in and rewrite the logs since I can easily miss something (eg I have no > insights into the Tegra config space FPCI windowing mechanism) - I will > merge the resulting patch(es). > > I have a question: after merging both series, are > > tegra_pcie_{add/remove}_bus() > > (and struct tegra_pcie_bus) > > still needed ? I do not think so. Yes, you're right, those were only to track the quilt mappings that we used to do. I've removed them in the patch I just sent (v4). > > I've tested these on all of Tegra20, Tegra30, Tegra124, Tegra210 and > > Tegra186. > > If the testing goes OK please send me unified series and will merge > that one. > > This brings me to a question for you and Bjorn: how do you usually > handle DT updates ? I assume we send them via the PCI tree but I am > asking to prevent any issue upfront. DT updates usually go through the ARM SoC tree. It's usually okay to do that because the DT stability requirement nicely decouples DT and driver updates already. In this particular case, the driver will be presented with a 256 MiB window from existing DTs and simply use the first 4 KiB of that window for the configuration space mapping. We can apply the DT patches at any later time to reduce the region from 256 MiB to 4 KiB. I plan to do that during for v4.17. Thierry
From: Thierry Reding <treding@nvidia.com> Hi Lorenzo, This cleans up a few oddities that I found while reviewing and testing the patch [PATCH V3 1/2] PCI: tegra: refactor config space mapping code that Vidya Sagar sent out earlier. The first three patches are mostly cleanup and admittedly somewhat bikeshedding in nature. They could've been just review comments, but I thought I'd just submit them as a series of patches since I had already typed them up anyway. The last patch gets rid of an artificial restriction regarding the mapping address and does a bit of simplification. These are technically incremental on top of the original patch, but if you prefer, feel free to squash them into that patch. I've tested these on all of Tegra20, Tegra30, Tegra124, Tegra210 and Tegra186. Thanks, Thierry Thierry Reding (4): PCI: tegra: Clarify configuration space address computations PCI: tegra: Reorder parameters in offset computations PCI: tegra: Consolidate I/O register variables PCI: tegra: Remove artificial mapping restriction drivers/pci/host/pci-tegra.c | 71 ++++++++++++++++++++------------------------ 1 file changed, 33 insertions(+), 38 deletions(-)