| Message ID | PS1PR06MB118061CA5128E4C1A2C70A18F5200@PS1PR06MB1180.apcprd06.prod.outlook.com (mailing list archive) |
|---|---|
| State | Awaiting Upstream |
| Delegated to: | Simon Horman |
| Headers | show |
> Ouch, my bad. I have been working with our out-of-tree BSP for the Salvator-X board on > http://git.kernel.org/cgit/linux/kernel/git/horms/renesas-bsp.git, rcar-3.0.2 tag along > with some patches from colleagues. I hadn't noticed this patch: Thanks! Any plans for pushing this upstream? We will have the build error otherwise... > > Any news if this is really HW related? > I found out that the PCIe controller HW only supports 32-bit AXI bus addresses, so it > works fine if you limit the available memory. The driver will need some work to use > the IPMMU at some point. Ah, okay. Can you send the dts patches, too? I checked the BSP this time, but to no avail...
Hi Wolfram, On 29 October 2015 16:40, Wolfram wrote: > > Ouch, my bad. I have been working with our out-of-tree BSP for the Salvator-X > board on > > http://git.kernel.org/cgit/linux/kernel/git/horms/renesas-bsp.git, rcar-3.0.2 > tag along > > with some patches from colleagues. I hadn't noticed this patch: > > Thanks! Any plans for pushing this upstream? We will have the build error > otherwise... After some digging, that patch won't be accepted upstream. I'm looking into how the driver can be modified so it doesn't need to call this, but I don't expect a small or imminent fix. > > > Any news if this is really HW related? > > I found out that the PCIe controller HW only supports 32-bit AXI bus addresses, > so it > > works fine if you limit the available memory. The driver will need some work to > use > > the IPMMU at some point. > > Ah, okay. > > Can you send the dts patches, too? I checked the BSP this time, but to > no avail... I will once I sort out the arm64 IO resources problem and the MSI problem. Thanks Phil -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Oct 29, 2015 at 04:44:06PM +0000, Phil Edworthy wrote: > Hi Wolfram, > > On 29 October 2015 16:40, Wolfram wrote: > > > Ouch, my bad. I have been working with our out-of-tree BSP for the Salvator-X > > board on > > > http://git.kernel.org/cgit/linux/kernel/git/horms/renesas-bsp.git, rcar-3.0.2 > > tag along > > > with some patches from colleagues. I hadn't noticed this patch: > > > > Thanks! Any plans for pushing this upstream? We will have the build error > > otherwise... > After some digging, that patch won't be accepted upstream. I'm looking into how the > driver can be modified so it doesn't need to call this, but I don't expect a small or > imminent fix. Yes, I'd think so, too. However, a fix for 4.4 would be needed to prevent having a final release with a build error. > > > > Any news if this is really HW related? > > > I found out that the PCIe controller HW only supports 32-bit AXI bus addresses, > > so it > > > works fine if you limit the available memory. The driver will need some work to > > use > > > the IPMMU at some point. > > > > Ah, okay. > > > > Can you send the dts patches, too? I checked the BSP this time, but to > > no avail... > I will once I sort out the arm64 IO resources problem and the MSI problem. What MSI problem? And can't you send the DTS patches as RFC so I can add some testing?
[-cc Nobuhiro (bouncing)] On Thu, Oct 29, 2015 at 07:48:00PM +0100, Wolfram Sang wrote: > On Thu, Oct 29, 2015 at 04:44:06PM +0000, Phil Edworthy wrote: > > Hi Wolfram, > > > > On 29 October 2015 16:40, Wolfram wrote: > > > > Ouch, my bad. I have been working with our out-of-tree BSP for the Salvator-X > > > board on > > > > http://git.kernel.org/cgit/linux/kernel/git/horms/renesas-bsp.git, rcar-3.0.2 > > > tag along > > > > with some patches from colleagues. I hadn't noticed this patch: > > > > > > Thanks! Any plans for pushing this upstream? We will have the build error > > > otherwise... > > After some digging, that patch won't be accepted upstream. I'm looking into how the > > driver can be modified so it doesn't need to call this, but I don't expect a small or > > imminent fix. > > Yes, I'd think so, too. However, a fix for 4.4 would be needed to > prevent having a final release with a build error. I'm thinking I should drop my pci/host-rcar branch until we have a fix for this. It currently contains: 9ac724f20774 PCI: rcar: Fix I/O offset for multiple host bridges 7d75b413f5c6 PCI: rcar: Set root bus nr to that provided in DT 4c22eab88c68 PCI: rcar: Remove dependency on ARM-specific struct hw_pci ef18d2e55ea0 PCI: rcar: Make PCI aware of the I/O resources Is that right? Last I heard, Linus expects to release v4.3 on Sunday, so we really don't have much time to sort this out. Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Bjorn, On 29 October 2015 23:03, Bjorn wrote: > On Thu, Oct 29, 2015 at 07:48:00PM +0100, Wolfram Sang wrote: > > On Thu, Oct 29, 2015 at 04:44:06PM +0000, Phil Edworthy wrote: > > > Hi Wolfram, > > > > > > On 29 October 2015 16:40, Wolfram wrote: > > > > > Ouch, my bad. I have been working with our out-of-tree BSP for the > Salvator-X > > > > board on > > > > > http://git.kernel.org/cgit/linux/kernel/git/horms/renesas-bsp.git, rcar- > 3.0.2 > > > > tag along > > > > > with some patches from colleagues. I hadn't noticed this patch: > > > > > > > > Thanks! Any plans for pushing this upstream? We will have the build error > > > > otherwise... > > > After some digging, that patch won't be accepted upstream. I'm looking into > how the > > > driver can be modified so it doesn't need to call this, but I don't expect a small > or > > > imminent fix. > > > > Yes, I'd think so, too. However, a fix for 4.4 would be needed to > > prevent having a final release with a build error. > > I'm thinking I should drop my pci/host-rcar branch until we > have a fix for this. It currently contains: > > 9ac724f20774 PCI: rcar: Fix I/O offset for multiple host bridges > 7d75b413f5c6 PCI: rcar: Set root bus nr to that provided in DT > 4c22eab88c68 PCI: rcar: Remove dependency on ARM-specific struct hw_pci > ef18d2e55ea0 PCI: rcar: Make PCI aware of the I/O resources > > Is that right? Last I heard, Linus expects to release v4.3 on Sunday, > so we really don't have much time to sort this out. The simple thing is to re-add Geert's patch to stop this driver being built for arm64. Thanks Phil -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Bjorn, On 30 October 2015 07:19, Phil wrote > On 29 October 2015 23:03, Bjorn wrote: > > On Thu, Oct 29, 2015 at 07:48:00PM +0100, Wolfram Sang wrote: > > > On Thu, Oct 29, 2015 at 04:44:06PM +0000, Phil Edworthy wrote: > > > > Hi Wolfram, > > > > > > > > On 29 October 2015 16:40, Wolfram wrote: > > > > > > Ouch, my bad. I have been working with our out-of-tree BSP for the > > Salvator-X > > > > > board on > > > > > > http://git.kernel.org/cgit/linux/kernel/git/horms/renesas-bsp.git, rcar- > > 3.0.2 > > > > > tag along > > > > > > with some patches from colleagues. I hadn't noticed this patch: > > > > > > > > > > Thanks! Any plans for pushing this upstream? We will have the build error > > > > > otherwise... > > > > After some digging, that patch won't be accepted upstream. I'm looking into > > how the > > > > driver can be modified so it doesn't need to call this, but I don't expect a > small > > or > > > > imminent fix. > > > > > > Yes, I'd think so, too. However, a fix for 4.4 would be needed to > > > prevent having a final release with a build error. > > > > I'm thinking I should drop my pci/host-rcar branch until we > > have a fix for this. It currently contains: > > > > 9ac724f20774 PCI: rcar: Fix I/O offset for multiple host bridges > > 7d75b413f5c6 PCI: rcar: Set root bus nr to that provided in DT > > 4c22eab88c68 PCI: rcar: Remove dependency on ARM-specific struct hw_pci > > ef18d2e55ea0 PCI: rcar: Make PCI aware of the I/O resources > > > > Is that right? Last I heard, Linus expects to release v4.3 on Sunday, > > so we really don't have much time to sort this out. > The simple thing is to re-add Geert's patch to stop this driver being built for > arm64. Btw, it's this one: https://patchwork.ozlabs.org/patch/512040/ Thanks Phil -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Bjorn, On 30 October 2015 07:24, Phil wrote: > On 30 October 2015 07:19, Phil wrote > > On 29 October 2015 23:03, Bjorn wrote: > > > On Thu, Oct 29, 2015 at 07:48:00PM +0100, Wolfram Sang wrote: > > > > On Thu, Oct 29, 2015 at 04:44:06PM +0000, Phil Edworthy wrote: > > > > > Hi Wolfram, > > > > > > > > > > On 29 October 2015 16:40, Wolfram wrote: > > > > > > > Ouch, my bad. I have been working with our out-of-tree BSP for the > > > Salvator-X > > > > > > board on > > > > > > > http://git.kernel.org/cgit/linux/kernel/git/horms/renesas-bsp.git, > rcar- > > > 3.0.2 > > > > > > tag along > > > > > > > with some patches from colleagues. I hadn't noticed this patch: > > > > > > > > > > > > Thanks! Any plans for pushing this upstream? We will have the build > error > > > > > > otherwise... > > > > > After some digging, that patch won't be accepted upstream. I'm looking > into > > > how the > > > > > driver can be modified so it doesn't need to call this, but I don't expect a > > small > > > or > > > > > imminent fix. > > > > > > > > Yes, I'd think so, too. However, a fix for 4.4 would be needed to > > > > prevent having a final release with a build error. > > > > > > I'm thinking I should drop my pci/host-rcar branch until we > > > have a fix for this. It currently contains: > > > > > > 9ac724f20774 PCI: rcar: Fix I/O offset for multiple host bridges > > > 7d75b413f5c6 PCI: rcar: Set root bus nr to that provided in DT > > > 4c22eab88c68 PCI: rcar: Remove dependency on ARM-specific struct hw_pci > > > ef18d2e55ea0 PCI: rcar: Make PCI aware of the I/O resources > > > > > > Is that right? Last I heard, Linus expects to release v4.3 on Sunday, > > > so we really don't have much time to sort this out. > > The simple thing is to re-add Geert's patch to stop this driver being built for > > arm64. > Btw, it's this one: https://patchwork.ozlabs.org/patch/512040/ It's worth mentioning that Geert's patch stops both the rcar-pcie driver and the rcar-pci-gen2 driver from being built on arm64 due to build failures for both of them. The rcar-pci-gen2 driver is not for R-Car Gen3 devices, and so should not be built for arm64. The rcar-pcie driver will be used on R-Car Gen3 devices. So if we don't use Geert's patch, I need to fix the rcar-pcie driver so it doesn't use pci_ioremap_io(), _and_ fix Kconfig so that the rcar-pci-gen2 driver doesn't get built on arm64. Let's just use Geert's patch for now. Btw, I saw no build breakages on next as SHMOBILE is currently not included in arm64. Thanks Phil -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Wolfram, On 29 October 2015 18:48, Wolfram wrote: > On Thu, Oct 29, 2015 at 04:44:06PM +0000, Phil Edworthy wrote: > > Hi Wolfram, > > > > On 29 October 2015 16:40, Wolfram wrote: > > > > Ouch, my bad. I have been working with our out-of-tree BSP for the > Salvator-X > > > board on > > > > http://git.kernel.org/cgit/linux/kernel/git/horms/renesas-bsp.git, rcar- > 3.0.2 > > > tag along > > > > with some patches from colleagues. I hadn't noticed this patch: > > > > > > Thanks! Any plans for pushing this upstream? We will have the build error > > > otherwise... > > After some digging, that patch won't be accepted upstream. I'm looking into > how the > > driver can be modified so it doesn't need to call this, but I don't expect a small > or > > imminent fix. > > Yes, I'd think so, too. However, a fix for 4.4 would be needed to > prevent having a final release with a build error. Hopefully, Geert's patch will be applied to avoid build errors in both the rcar-pcie and rcar-pci-gen2 (internal USB bridge) drivers. Meanwhile I'll fix the rcar-pcie driver properly for arm64. > > > > > Any news if this is really HW related? > > > > I found out that the PCIe controller HW only supports 32-bit AXI bus > addresses, > > > so it > > > > works fine if you limit the available memory. The driver will need some work > to > > > use > > > > the IPMMU at some point. > > > > > > Ah, okay. > > > > > > Can you send the dts patches, too? I checked the BSP this time, but to > > > no avail... > > I will once I sort out the arm64 IO resources problem and the MSI problem. > > What MSI problem? I was told that rcar pcie on v4.3-rc5 had an issue with MSI. I've since checked That both v4.3-rc7 and next work ok out of the box on the Koelsch board. There are some problems with next (mstp related), but it doesn't stop the board booting and being able to test pcie. Since shmobile arm64 is not in next yet, I have not checked this. > And can't you send the DTS patches as RFC so I can add some testing? Sure, though what tree? As I mentioned above, next doesn't have shmobile arm64 yet. Thanks Phil -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> Hopefully, Geert's patch will be applied to avoid build errors in both the > rcar-pcie and rcar-pci-gen2 (internal USB bridge) drivers. Meanwhile I'll fix > the rcar-pcie driver properly for arm64. Thanks for taking care. > > What MSI problem? > I was told that rcar pcie on v4.3-rc5 had an issue with MSI. Okay, we'll see. I only have remote access to a Koelsch board, but my own Salvator. And a USB3 PCIE card. That would be my primary test setup. > > And can't you send the DTS patches as RFC so I can add some testing? > Sure, though what tree? As I mentioned above, next doesn't have > shmobile arm64 yet. I use renesas-drivers: git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git renesas-drivers-2015-10-27-v4.3-rc7 Thanks, Wolfram
On Fri, Oct 30, 2015 at 09:00:20AM +0000, Phil Edworthy wrote: > Hi Bjorn, > > On 30 October 2015 07:24, Phil wrote: > > On 30 October 2015 07:19, Phil wrote > > > On 29 October 2015 23:03, Bjorn wrote: > > > > On Thu, Oct 29, 2015 at 07:48:00PM +0100, Wolfram Sang wrote: > > > > > On Thu, Oct 29, 2015 at 04:44:06PM +0000, Phil Edworthy wrote: > > > > > > Hi Wolfram, > > > > > > > > > > > > On 29 October 2015 16:40, Wolfram wrote: > > > > > > > > Ouch, my bad. I have been working with our out-of-tree BSP for the > > > > Salvator-X > > > > > > > board on > > > > > > > > http://git.kernel.org/cgit/linux/kernel/git/horms/renesas-bsp.git, > > rcar- > > > > 3.0.2 > > > > > > > tag along > > > > > > > > with some patches from colleagues. I hadn't noticed this patch: > > > > > > > > > > > > > > Thanks! Any plans for pushing this upstream? We will have the build > > error > > > > > > > otherwise... > > > > > > After some digging, that patch won't be accepted upstream. I'm looking > > into > > > > how the > > > > > > driver can be modified so it doesn't need to call this, but I don't expect a > > > small > > > > or > > > > > > imminent fix. > > > > > > > > > > Yes, I'd think so, too. However, a fix for 4.4 would be needed to > > > > > prevent having a final release with a build error. > > > > > > > > I'm thinking I should drop my pci/host-rcar branch until we > > > > have a fix for this. It currently contains: > > > > > > > > 9ac724f20774 PCI: rcar: Fix I/O offset for multiple host bridges > > > > 7d75b413f5c6 PCI: rcar: Set root bus nr to that provided in DT > > > > 4c22eab88c68 PCI: rcar: Remove dependency on ARM-specific struct hw_pci > > > > ef18d2e55ea0 PCI: rcar: Make PCI aware of the I/O resources > > > > > > > > Is that right? Last I heard, Linus expects to release v4.3 on Sunday, > > > > so we really don't have much time to sort this out. > > > The simple thing is to re-add Geert's patch to stop this driver being built for > > > arm64. > > Btw, it's this one: https://patchwork.ozlabs.org/patch/512040/ > It's worth mentioning that Geert's patch stops both the rcar-pcie driver and the > rcar-pci-gen2 driver from being built on arm64 due to build failures for both of > them. The rcar-pci-gen2 driver is not for R-Car Gen3 devices, and so should not > be built for arm64. The rcar-pcie driver will be used on R-Car Gen3 devices. > > So if we don't use Geert's patch, I need to fix the rcar-pcie driver so it doesn't > use pci_ioremap_io(), _and_ fix Kconfig so that the rcar-pci-gen2 driver doesn't > get built on arm64. > Let's just use Geert's patch for now. OK, I re-added Geert's patch. I split it into two, one for rcar-pci-gen2 and another for rcar-pcie, to help me keep things straight. If I understand correctly, - rcar-pci-gen2 depends on the ARM-specific pci_sys_data, and I don't have anything queued to address that. - rcar-pcie depended on the ARM-specific pci_sys_data and pci_ioremap_io(). Your patches remove the pci_sys_data dependency, and it sounds like future changes will remove the pci_ioremap_io() dependency. The result is in my pci/host-rcar branch: https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/log/?h=pci/host-rcar Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Bjorn, On 30 October 2015 13:32, Bjorn wrote: > On Fri, Oct 30, 2015 at 09:00:20AM +0000, Phil Edworthy wrote: > > Hi Bjorn, > > > > On 30 October 2015 07:24, Phil wrote: > > > On 30 October 2015 07:19, Phil wrote > > > > On 29 October 2015 23:03, Bjorn wrote: > > > > > On Thu, Oct 29, 2015 at 07:48:00PM +0100, Wolfram Sang wrote: > > > > > > On Thu, Oct 29, 2015 at 04:44:06PM +0000, Phil Edworthy wrote: > > > > > > > Hi Wolfram, > > > > > > > > > > > > > > On 29 October 2015 16:40, Wolfram wrote: > > > > > > > > > Ouch, my bad. I have been working with our out-of-tree BSP for > the > > > > > Salvator-X > > > > > > > > board on > > > > > > > > > http://git.kernel.org/cgit/linux/kernel/git/horms/renesas-bsp.git, > > > rcar- > > > > > 3.0.2 > > > > > > > > tag along > > > > > > > > > with some patches from colleagues. I hadn't noticed this patch: > > > > > > > > > > > > > > > > Thanks! Any plans for pushing this upstream? We will have the build > > > error > > > > > > > > otherwise... > > > > > > > After some digging, that patch won't be accepted upstream. I'm > looking > > > into > > > > > how the > > > > > > > driver can be modified so it doesn't need to call this, but I don't expect > a > > > > small > > > > > or > > > > > > > imminent fix. > > > > > > > > > > > > Yes, I'd think so, too. However, a fix for 4.4 would be needed to > > > > > > prevent having a final release with a build error. > > > > > > > > > > I'm thinking I should drop my pci/host-rcar branch until we > > > > > have a fix for this. It currently contains: > > > > > > > > > > 9ac724f20774 PCI: rcar: Fix I/O offset for multiple host bridges > > > > > 7d75b413f5c6 PCI: rcar: Set root bus nr to that provided in DT > > > > > 4c22eab88c68 PCI: rcar: Remove dependency on ARM-specific struct > hw_pci > > > > > ef18d2e55ea0 PCI: rcar: Make PCI aware of the I/O resources > > > > > > > > > > Is that right? Last I heard, Linus expects to release v4.3 on Sunday, > > > > > so we really don't have much time to sort this out. > > > > The simple thing is to re-add Geert's patch to stop this driver being built for > > > > arm64. > > > Btw, it's this one: https://patchwork.ozlabs.org/patch/512040/ > > It's worth mentioning that Geert's patch stops both the rcar-pcie driver and the > > rcar-pci-gen2 driver from being built on arm64 due to build failures for both of > > them. The rcar-pci-gen2 driver is not for R-Car Gen3 devices, and so should not > > be built for arm64. The rcar-pcie driver will be used on R-Car Gen3 devices. > > > > So if we don't use Geert's patch, I need to fix the rcar-pcie driver so it doesn't > > use pci_ioremap_io(), _and_ fix Kconfig so that the rcar-pci-gen2 driver doesn't > > get built on arm64. > > Let's just use Geert's patch for now. > > OK, I re-added Geert's patch. I split it into two, one for > rcar-pci-gen2 and another for rcar-pcie, to help me keep things > straight. If I understand correctly, > > - rcar-pci-gen2 depends on the ARM-specific pci_sys_data, and I > don't have anything queued to address that. Correct, but you don't need anything other than Geert's patch to ensure it's not built for arm64. > - rcar-pcie depended on the ARM-specific pci_sys_data and > pci_ioremap_io(). Your patches remove the pci_sys_data > dependency, and it sounds like future changes will remove the > pci_ioremap_io() dependency. That's correct, hopefully I'll have a patch shortly. Thanks for taking care of this. > The result is in my pci/host-rcar branch: > https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/log/?h=pci/host-rcar I haven't tested this yet, but I have looked them over and they look ok. Thanks Phil -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h index 44be1e0..cea3651 100644 --- a/arch/arm64/include/asm/io.h +++ b/arch/arm64/include/asm/io.h @@ -149,6 +149,8 @@ static inline u64 __raw_readq(const volatile void __iomem *addr) #define IO_SPACE_LIMIT (PCI_IO_SIZE - 1) #define PCI_IOBASE ((void __iomem *)PCI_IO_START) +extern int pci_ioremap_io(unsigned int offset, phys_addr_t phys_addr); + /* * String version of I/O memory access operations. */ diff --git a/arch/arm64/mm/ioremap.c b/arch/arm64/mm/ioremap.c index 01e88c8..34f09a6 100644 --- a/arch/arm64/mm/ioremap.c +++ b/arch/arm64/mm/ioremap.c @@ -104,6 +104,19 @@ void __iomem *ioremap_cache(phys_addr_t phys_addr, size_t size) } EXPORT_SYMBOL(ioremap_cache); +#ifdef CONFIG_PCI +int pci_ioremap_io(unsigned int offset, phys_addr_t phys_addr) +{ + BUG_ON(offset + SZ_64K > IO_SPACE_LIMIT); + + return ioremap_page_range((unsigned long)PCI_IOBASE + offset, + (unsigned long)PCI_IOBASE + offset + SZ_64K, + phys_addr, + __pgprot(PROT_NORMAL_NC)); +} +EXPORT_SYMBOL_GPL(pci_ioremap_io); +#endif + /* * Must be called after early_fixmap_init */