| Message ID | EE11001F9E5DDD47B7634E2F8A612F2E01D4E6A2@lhreml503-mbs (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Gabriele Paoloni wrote: >> Both series are applied to v4.1, use the same .config file, and the >> same dtb. >> I will investigate further. >> >> (Re-testing v2 works, so this isn't an interim hardware failure) > > This is a bit weird.... > > Patch 2/5 is the only one that affect platforms different from Hisilicon > > The only difference between V3 patch[2/5] and v2 patch[2/4] is Between v3:2/5 and your replacement for v2:2/4, which arrived after I had tested the v2 series. As the patch has been replaced with a different one - neither 'tested-by' is true any more. It looks like the BAR containing the bridge window is not being assigned, so no devices on bus 1 are discovered. I will send the full v2 and v3 dmesg output separately. Thanks, James
On 2015/7/2 1:32, James Morse wrote: > Gabriele Paoloni wrote: >>> Both series are applied to v4.1, use the same .config file, and the >>> same dtb. >>> I will investigate further. >>> >>> (Re-testing v2 works, so this isn't an interim hardware failure) >> >> This is a bit weird.... >> >> Patch 2/5 is the only one that affect platforms different from Hisilicon >> >> The only difference between V3 patch[2/5] and v2 patch[2/4] is > > Between v3:2/5 and your replacement for v2:2/4, which arrived after I had > tested the v2 series. As the patch has been replaced with a different one - > neither 'tested-by' is true any more. > Hi James, Firstly, many thanks for your test! Yes. v3:2/5 had merged Gabriele's codes in. So if you made test on original v2 patchset and v3 patchset, I think the differences include Gabriele's codes and codes in pci-keystone-dw.c. As the patch has been replaced with a different one, I think I should have added 'tested-by' after it passes your test, is this right? > It looks like the BAR containing the bridge window is not being assigned, > so no devices on bus 1 are discovered. > > I will send the full v2 and v3 dmesg output separately. > Thanks, I will debug the problem according your log. Regards, Zhou > > Thanks, > > James > > > . >
> -----Original Message----- > From: linux-pci-owner@vger.kernel.org [mailto:linux-pci- > owner@vger.kernel.org] On Behalf Of James Morse > Sent: 01 July 2015 18:33 > To: Gabriele Paoloni; Wangzhou (B); Bjorn Helgaas; Jingoo Han; Pratyush > Anand; Arnd Bergmann; Liviu Dudau; kishon@ti.com; xobs@kosagi.com; m- > karicheri2@ti.com; Minghuan.Lian@freescale.com > Cc: linux-pci@vger.kernel.org; linux-arm-kernel@lists.infradead.org; > devicetree@vger.kernel.org; Yuanzhichang; Zhudacai; zhangjukuo; > qiuzhenfa; Liguozhu (Kenneth) > Subject: Re: [PATCH v3 2/5] PCI: designware: Add ARM64 support > > Gabriele Paoloni wrote: > >> Both series are applied to v4.1, use the same .config file, and the > >> same dtb. > >> I will investigate further. > >> > >> (Re-testing v2 works, so this isn't an interim hardware failure) > > > > This is a bit weird.... > > > > Patch 2/5 is the only one that affect platforms different from > Hisilicon > > > > The only difference between V3 patch[2/5] and v2 patch[2/4] is > > Between v3:2/5 and your replacement for v2:2/4, which arrived after I > had > tested the v2 series. As the patch has been replaced with a different > one - > neither 'tested-by' is true any more. Sorry I misread your previous email > > It looks like the BAR containing the bridge window is not being assigned, > so no devices on bus 1 are discovered. Can you confirm the dtsi you are using..."imx6qdl.dtsi" ? Thanks Gab > > I will send the full v2 and v3 dmesg output separately. > > > Thanks, > > James > > -- > To unsubscribe from this list: send the line "unsubscribe linux-pci" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
On 02/07/15 08:24, Gabriele Paoloni wrote: >> It looks like the BAR containing the bridge window is not being assigned, >> so no devices on bus 1 are discovered. > > Can you confirm the dtsi you are using..."imx6qdl.dtsi" ? Yes, that looks right. The on-disk file was 'imx6q-sabrelite.dtb' when I received the board, I replaced it with the one from the v4.1 kernel tree. Decompiled from /sys/firmware/fdt (to eliminate bootloader trickery), the pcie section reads: pcie@0x01000000 { compatible = "fsl,imx6q-pcie", "snps,dw-pcie"; reg = <0x1ffc000 0x4000 0x1f00000 0x80000>; reg-names = "dbi", "config"; #address-cells = <0x3>; #size-cells = <0x2>; device_type = "pci"; ranges = <0x800 0x0 0x1f00000 0x1f00000 0x0 0x80000 0x81000000 0x0 0x0 0x1f80000 0x0 0x10000 0x82000000 0x0 0x1000000 0x1000000 0x0 0xf00000>; num-lanes = <0x1>; interrupts = <0x0 0x78 0x4>; interrupt-names = "msi"; #interrupt-cells = <0x1>; interrupt-map-mask = <0x0 0x0 0x0 0x7>; interrupt-map = <0x0 0x0 0x0 0x1 0x1 0x0 0x7b 0x4 0x0 0x0 0x0 0x2 0x1 0x0 0x7a 0x4 0x0 0x0 0x0 0x3 0x1 0x0 0x79 0x4 0x0 0x0 0x0 0x4 0x1 0x0 0x78 0x4>; clocks = <0x3 0x90 0x3 0xce 0x3 0xbd>; clock-names = "pcie", "pcie_bus", "pcie_phy"; status = "okay"; }; James
diff --git a/drivers/pci/host/pci-keystone-dw.c b/drivers/pci/host/pci-keystone-dw.c index f34892e..b1e4135 100644 --- a/drivers/pci/host/pci-keystone-dw.c +++ b/drivers/pci/host/pci-keystone-dw.c @@ -327,7 +327,7 @@ static void ks_dw_pcie_clear_dbi_mode(void __iomem *reg_virt) void ks_dw_pcie_setup_rc_app_regs(struct keystone_pcie *ks_pcie) { struct pcie_port *pp = &ks_pcie->pp; - u32 start = pp->mem.start, end = pp->mem.end; + u32 start = pp->mem->start, end = pp->mem->end; int i, tr_size; /* Disable BARs for inbound access */