| Message ID | 20220427162123.110458-1-maukka@ext.kapsi.fi (mailing list archive) |
|---|---|
| Headers | show |
| Series | ARM: orion5x: convert D-Link DNS-323 to the Device Tree | expand |
On Wed, Apr 27, 2022 at 6:21 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote: > > Hello all, > > I am making an attempt to create a device tree for D-Link DNS-323 devices > but I am falling short on a few specific details. I am requesting a > general review of the device tree files. I have access to DNS-323 rev A1 > only and the B1 and C1 need to be tested separately, so I am reaching out > to people who might have them. Hi Mauri, It's really nice to see some progress on this! I don't have the hardware, but I'll try to answer some of your questions anyway. > The questions that I have at the moment are below. > > - some of resulting IRQs are different from what was requested in device tree > - logs say NR_IRQS is different from mach file one This is all normal: with a board file, all on-board IRQs are statically assigned to fixed numbers. With DT based boot, IRQ controllers usually define their own IRQ domains, which get a number space assigned according to probe order, and above the preallocated IRQ numbers. > - sata_mv fails to initialise with -22 (-EINVAL) No idea, I'd try inserting a printk in every code path that can return -EINVAL from there > - there is no concensus on how to get ascii formatted MAC address from mtd > partitions so eth is not fully functional without setting the MAC from > userspace Ideally this is handled by the boot loader, but that requires being able to update it. If you cannot, this could perhaps be done using something like https://github.com/zonque/pxa-impedance-matcher Arnd
> > - there is no concensus on how to get ascii formatted MAC address from mtd > > partitions so eth is not fully functional without setting the MAC from > > userspace > > Ideally this is handled by the boot loader, but that requires being > able to update > it. The mv643xx Ethernet driver is happy if it finds the MAC address already in the hardware. The vendor uboot often does this. Does tftp boot work in uboot? That would indicate it has access to the MAC address. Andrew
> - how to configure RTC to wake system from sleep?
The st,m41t80 binding document has:
Optional properties:
- interrupts: rtc alarm interrupt.
- clock-output-names: From common clock binding to override the default output
clock name
- wakeup-source: Enables wake up of host system on alarm
which you don't appear to have in your DT files.
Andrew
Hi Arnd and thanks for your quick reply. On 27.4.2022 21.10, Arnd Bergmann wrote: > On Wed, Apr 27, 2022 at 6:21 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote: >> >> Hello all, >> >> I am making an attempt to create a device tree for D-Link DNS-323 devices >> but I am falling short on a few specific details. I am requesting a >> general review of the device tree files. I have access to DNS-323 rev A1 >> only and the B1 and C1 need to be tested separately, so I am reaching out >> to people who might have them. > > Hi Mauri, > > It's really nice to see some progress on this! I don't have the hardware, > but I'll try to answer some of your questions anyway. > >> The questions that I have at the moment are below. >> >> - some of resulting IRQs are different from what was requested in device tree >> - logs say NR_IRQS is different from mach file one > Ok thanks, I won't worry about it anymore. > This is all normal: with a board file, all on-board IRQs are statically > assigned to fixed numbers. With DT based boot, IRQ controllers > usually define their own IRQ domains, which get a number space assigned > according to probe order, and above the preallocated IRQ numbers. > >> - sata_mv fails to initialise with -22 (-EINVAL) > > No idea, I'd try inserting a printk in every code path that can return -EINVAL > from there > I had something like that but I didn't get any wiser immediately. Then I suspected it's something to do with initialisation of the PCIe bus and that clashing with sata_mv initialisation and thought it's better to ask. The PCIe initialisation uses hardwired irq and maybe that was getting in the way. Is there a way to describe the PCIe bus in the device tree? The initalisation of that bus is done for rev A1 only. >> - there is no concensus on how to get ascii formatted MAC address from mtd >> partitions so eth is not fully functional without setting the MAC from >> userspace > > Ideally this is handled by the boot loader, but that requires being > able to update > it. If you cannot, this could perhaps be done using something like > https://github.com/zonque/pxa-impedance-matcher I had a look at the pxa-impedance-matcher but I am not sure how to use it. Should it be flashed on the device and then it would the boot the rest of the system? Maybe I'll have to add some dns323 specifics there too first. On the dns323 there are these mtd partitions MTD1 and MTD2, which I am not really sure what they are for. Maybe those could accommodate a 3rd stage loader. But I'll consider it as my last resort as they put it in their documentation too. In linux-mtd there's been a few attempts to find a solution and I am hoping one will be found eventually. Adding support in the u-boot was stalled back in the days for some reason and I am not sure I will be much wiser than the previous people that were at it. But I have jtag programmer that should be suitable. -- Mauri
Hello Andrew! On 28.4.2022 3.18, Andrew Lunn wrote: >>> - there is no concensus on how to get ascii formatted MAC address from mtd >>> partitions so eth is not fully functional without setting the MAC from >>> userspace >> >> Ideally this is handled by the boot loader, but that requires being >> able to update >> it. > > The mv643xx Ethernet driver is happy if it finds the MAC address > already in the hardware. The vendor uboot often does this. Does tftp > boot work in uboot? That would indicate it has access to the MAC > address. The u-boot is really limited and I am transferring new images over kermit. Tftp is not enabled.
On Thu, Apr 28, 2022 at 10:01 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote: > On 27.4.2022 21.10, Arnd Bergmann wrote: > > On Wed, Apr 27, 2022 at 6:21 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote: > > This is all normal: with a board file, all on-board IRQs are statically > > assigned to fixed numbers. With DT based boot, IRQ controllers > > usually define their own IRQ domains, which get a number space assigned > > according to probe order, and above the preallocated IRQ numbers. > > > >> - sata_mv fails to initialise with -22 (-EINVAL) > > > > No idea, I'd try inserting a printk in every code path that can return -EINVAL > > from there > > > I had something like that but I didn't get any wiser immediately. Then I > suspected it's something to do with initialisation of the PCIe bus and > that clashing with sata_mv initialisation and thought it's better to > ask. The PCIe initialisation uses hardwired irq and maybe that was > getting in the way. Is there a way to describe the PCIe bus in the > device tree? The initalisation of that bus is done for rev A1 only. I'm not too familiar with the platform, but my interpretation is that the DT support here is incomplete: The DT based PCI probe using drivers/pci/controller/pci-mvebu.c is not hooked up in orion5x.dtsi, and the traditional pci code does not work with DT. I see that orion5x has two separate blocks -- a PCIe host that is similar to the kirkwood one, and a legacy PCI host that needs a completely separate driver. Which of the two do you actually need here? > >> - there is no concensus on how to get ascii formatted MAC address from mtd > >> partitions so eth is not fully functional without setting the MAC from > >> userspace > > > > Ideally this is handled by the boot loader, but that requires being > > able to update > > it. If you cannot, this could perhaps be done using something like > > https://github.com/zonque/pxa-impedance-matcher > > I had a look at the pxa-impedance-matcher but I am not sure how to use > it. Should it be flashed on the device and then it would the boot the > rest of the system? Maybe I'll have to add some dns323 specifics there > too first. On the dns323 there are these mtd partitions MTD1 and MTD2, > which I am not really sure what they are for. Maybe those could > accommodate a 3rd stage loader. But I'll consider it as my last resort > as they put it in their documentation too. In linux-mtd there's been a > few attempts to find a solution and I am hoping one will be found > eventually. > > Adding support in the u-boot was stalled back in the days for some > reason and I am not sure I will be much wiser than the previous people > that were at it. But I have jtag programmer that should be suitable. I think the idea of the impedance-matcher is that you can combine it with a DT-enabled kernel image into a file that looks to the existing boot loader like an old kernel and then provides both a way for code to run before booting the kernel, and for adding in the DT. Arnd
On Thu, Apr 28, 2022 at 11:25:00PM +0300, Mauri Sandberg wrote: > Hello Andrew! > > On 28.4.2022 3.18, Andrew Lunn wrote: > > > > - there is no concensus on how to get ascii formatted MAC address from mtd > > > > partitions so eth is not fully functional without setting the MAC from > > > > userspace > > > > > > Ideally this is handled by the boot loader, but that requires being > > > able to update > > > it. > > > > The mv643xx Ethernet driver is happy if it finds the MAC address > > already in the hardware. The vendor uboot often does this. Does tftp > > boot work in uboot? That would indicate it has access to the MAC > > address. > > The u-boot is really limited and I am transferring new images over kermit. Ouch! If you can, try kexec. You can use wget or similar to grab the kernel from you host machine, and then something like: kexec --append 'rootwait ro earlyprintk console=ttyS0,115200n8' bzImage wget will be much faster then kernel. Andrew
On 29.04.22 02:26, Andrew Lunn wrote: > On Thu, Apr 28, 2022 at 11:25:00PM +0300, Mauri Sandberg wrote: >> Hello Andrew! >> >> On 28.4.2022 3.18, Andrew Lunn wrote: >>>>> - there is no concensus on how to get ascii formatted MAC address from mtd >>>>> partitions so eth is not fully functional without setting the MAC from >>>>> userspace >>>> Ideally this is handled by the boot loader, but that requires being >>>> able to update >>>> it. >>> The mv643xx Ethernet driver is happy if it finds the MAC address >>> already in the hardware. The vendor uboot often does this. Does tftp >>> boot work in uboot? That would indicate it has access to the MAC >>> address. >> The u-boot is really limited and I am transferring new images over kermit. > Ouch! > > If you can, try kexec. You can use wget or similar to grab the kernel > from you host machine, and then something like: > > kexec --append 'rootwait ro earlyprintk console=ttyS0,115200n8' bzImage > > wget will be much faster then kernel. > Nice, this looks promising. Thanks for the tip.
On 28.4.2022 23.56, Arnd Bergmann wrote: > On Thu, Apr 28, 2022 at 10:01 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote: >> On 27.4.2022 21.10, Arnd Bergmann wrote: >>> On Wed, Apr 27, 2022 at 6:21 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote: >>>> - sata_mv fails to initialise with -22 (-EINVAL) >>> >>> No idea, I'd try inserting a printk in every code path that can return -EINVAL >>> from there >>> With debugging the reason for -EINVAL remains a bit mystery. - sata_mv calls ata_host_activate() [1] - later on, in request_threaded_irq(), there are sanity checks [2] - that fail with irq_settings_can_request() returning 0 [3] I cannot really put my finger on why the irq cannot be requested in DT approach. >> Is there a way to describe the PCIe bus in the >> device tree? The initalisation of that bus is done for rev A1 only. > > I'm not too familiar with the platform, but my interpretation is that the > DT support here is incomplete: > > The DT based PCI probe using drivers/pci/controller/pci-mvebu.c > is not hooked up in orion5x.dtsi, and the traditional pci code does > not work with DT. Can the existing pci code still be used to init the PCI bus and describe the rest in the DT or is it a futile attempt? > I see that orion5x has two separate blocks -- a PCIe host that is > similar to the kirkwood one, and a legacy PCI host that needs > a completely separate driver. > > Which of the two do you actually need here? > I really cannot say which one is it. How can I tell? The functions given in struct hw_pci find their way to drivers/pci/probe.c eventually and use pci_scan_root_bus_bridge(). Nothing seems to utilising mvebu or kirkwood explicitly at least. Here's the output from lspci if the ids reveal anything. # lspci -v -k 00:00.0 Class 0580: 11ab:5181 01:00.0 Class 0580: 11ab:5181 00:01.0 Class 0100: 11ab:7042 sata_mv -- Mauri [1] https://elixir.bootlin.com/linux/v5.17/source/drivers/ata/sata_mv.c#L4434 [2] https://elixir.bootlin.com/linux/v5.17/source/kernel/irq/manage.c#L2146 [3] https://elixir.bootlin.com/linux/v5.17/source/kernel/irq/settings.h#L100
On Sun, May 8, 2022 at 4:06 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote: > On 28.4.2022 23.56, Arnd Bergmann wrote: > > On Thu, Apr 28, 2022 at 10:01 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote: > >> On 27.4.2022 21.10, Arnd Bergmann wrote: > >>> On Wed, Apr 27, 2022 at 6:21 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote: > >>>> - sata_mv fails to initialise with -22 (-EINVAL) > >>> > >>> No idea, I'd try inserting a printk in every code path that can return -EINVAL > >>> from there > >>> > > With debugging the reason for -EINVAL remains a bit mystery. > - sata_mv calls ata_host_activate() [1] > - later on, in request_threaded_irq(), there are sanity checks [2] > - that fail with irq_settings_can_request() returning 0 [3] > > I cannot really put my finger on why the irq cannot be requested in DT > approach. Are you sure the marvell,orion-intc driver is successfully probed at this point? If not, the interrupt won't be there. I see that the "sata_mv" driver can be used either as a platform driver for the orion5x on-chip controller, or as a PCI driver for an add-on chip connected to the external bus. It sounds like your system has both. Do you know which one fails? The PCI driver cannot work unless the PCI host works correctly, and that in turn requires a correct devicetree description for it. > >> Is there a way to describe the PCIe bus in the > >> device tree? The initalisation of that bus is done for rev A1 only. > > > > I'm not too familiar with the platform, but my interpretation is that the > > DT support here is incomplete: > > > > The DT based PCI probe using drivers/pci/controller/pci-mvebu.c > > is not hooked up in orion5x.dtsi, and the traditional pci code does > > not work with DT. > > Can the existing pci code still be used to init the PCI bus and describe > the rest in the DT or is it a futile attempt? > > > I see that orion5x has two separate blocks -- a PCIe host that is > > similar to the kirkwood one, and a legacy PCI host that needs > > a completely separate driver. > > > > Which of the two do you actually need here? > > > > I really cannot say which one is it. How can I tell? The functions given > in struct hw_pci find their way to drivers/pci/probe.c eventually and > use pci_scan_root_bus_bridge(). Nothing seems to utilising mvebu or > kirkwood explicitly at least. > > Here's the output from lspci if the ids reveal anything. > > # lspci -v -k > 00:00.0 Class 0580: 11ab:5181 > 01:00.0 Class 0580: 11ab:5181 > 00:01.0 Class 0100: 11ab:7042 sata_mv The first two seem to be the host bridges, but unfortunately they seem both have the same device ID, despite being very different devices. The first one (00:00.0) should be the PCIe driver, the second one (01.00.0) the legacy PCI one. In this case, the 11ab:7042 device is a PCIe device, and it's on the bus (00) of the first host bridge. I think this should work with drivers/pci/controller/pci-mvebu.c if you add the bits for probing. Thomas Petazzoni originally wrote the new driver, and I think he was planning at one point to use it for orion5x. I don't know if there were any major problems preventing this at the time, or if it just needs to get hooked up in the dtsi file. Arnd
On Sunday 08 May 2022 17:02:17 Arnd Bergmann wrote: > On Sun, May 8, 2022 at 4:06 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote: > > On 28.4.2022 23.56, Arnd Bergmann wrote: > > > On Thu, Apr 28, 2022 at 10:01 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote: > > >> On 27.4.2022 21.10, Arnd Bergmann wrote: > > >>> On Wed, Apr 27, 2022 at 6:21 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote: > > >>>> - sata_mv fails to initialise with -22 (-EINVAL) > > >>> > > >>> No idea, I'd try inserting a printk in every code path that can return -EINVAL > > >>> from there > > >>> > > > > With debugging the reason for -EINVAL remains a bit mystery. > > - sata_mv calls ata_host_activate() [1] > > - later on, in request_threaded_irq(), there are sanity checks [2] > > - that fail with irq_settings_can_request() returning 0 [3] > > > > I cannot really put my finger on why the irq cannot be requested in DT > > approach. > > Are you sure the marvell,orion-intc driver is successfully probed > at this point? If not, the interrupt won't be there. > > I see that the "sata_mv" driver can be used either as a platform > driver for the orion5x on-chip controller, or as a PCI driver for > an add-on chip connected to the external bus. It sounds like > your system has both. Do you know which one fails? > > The PCI driver cannot work unless the PCI host works correctly, > and that in turn requires a correct devicetree description for it. > > > >> Is there a way to describe the PCIe bus in the > > >> device tree? The initalisation of that bus is done for rev A1 only. > > > > > > I'm not too familiar with the platform, but my interpretation is that the > > > DT support here is incomplete: > > > > > > The DT based PCI probe using drivers/pci/controller/pci-mvebu.c > > > is not hooked up in orion5x.dtsi, and the traditional pci code does > > > not work with DT. > > > > Can the existing pci code still be used to init the PCI bus and describe > > the rest in the DT or is it a futile attempt? Hello! Orion uses arch/arm/mach-orion5x/pci.c driver for both PCI and PCIe buses. This is not device tree driver. > > > I see that orion5x has two separate blocks -- a PCIe host that is > > > similar to the kirkwood one, and a legacy PCI host that needs > > > a completely separate driver. > > > > > > Which of the two do you actually need here? > > > > > > > I really cannot say which one is it. How can I tell? The functions given > > in struct hw_pci find their way to drivers/pci/probe.c eventually and > > use pci_scan_root_bus_bridge(). Nothing seems to utilising mvebu or > > kirkwood explicitly at least. > > > > Here's the output from lspci if the ids reveal anything. > > > > # lspci -v -k > > 00:00.0 Class 0580: 11ab:5181 > > 01:00.0 Class 0580: 11ab:5181 > > 00:01.0 Class 0100: 11ab:7042 sata_mv > > The first two seem to be the host bridges, but unfortunately they > seem both have the same device ID, despite being very different > devices. The first one (00:00.0) should be the PCIe driver, the > second one (01.00.0) the legacy PCI one. In this case, the 11ab:7042 > device is a PCIe device, and it's on the bus (00) of the first host > bridge. I think this should work with drivers/pci/controller/pci-mvebu.c > if you add the bits for probing. Last time when I looked on Orion PCIe controller registers, I though that they are same as in Kirkwood PCIe controller registers. And Kirkwood is already supported by pci-mvebu.c driver. About PCI host bridge, I do not know. Beware that PCI Class Id and all PCI registers which are different for Type 0 and Type 1 are _broken_ on all PCIe Root Ports form all 32-bit Marvell SoCs. Those registers on Marvell SoCs have different meaning as what is defined in PCI and PCIe specs. So it means that lspci _may_ display bogus information about PCIe Root Port. pci-mvebu.c uses Root Port emulator which fills correct data to make kernel and lspci happy. If you are going to extend pci-mvebu.c to support also Orion PCIe controller, I could try to help with it. But I do not have any Orion hardware, so just basic help... Links to Orion documentations, including PCIe errata is available in kernel documentation. So this could help to understand some details: https://www.kernel.org/doc/html/latest/arm/marvell.html Anyway, could you please provide 'lspci -nn -vv' and 'lspci -nn -t -v' outputs from Orion? > Thomas Petazzoni originally wrote the new driver, and I think he was > planning at one point to use it for orion5x. I don't know if there were > any major problems preventing this at the time, or if it just needs to > get hooked up in the dtsi file. > > Arnd
On Sunday 08 May 2022 17:22:37 Pali Rohár wrote: > On Sunday 08 May 2022 17:02:17 Arnd Bergmann wrote: > > On Sun, May 8, 2022 at 4:06 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote: > > > On 28.4.2022 23.56, Arnd Bergmann wrote: > > > > On Thu, Apr 28, 2022 at 10:01 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote: > > > >> On 27.4.2022 21.10, Arnd Bergmann wrote: > > > >>> On Wed, Apr 27, 2022 at 6:21 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote: > > > >>>> - sata_mv fails to initialise with -22 (-EINVAL) > > > >>> > > > >>> No idea, I'd try inserting a printk in every code path that can return -EINVAL > > > >>> from there > > > >>> > > > > > > With debugging the reason for -EINVAL remains a bit mystery. > > > - sata_mv calls ata_host_activate() [1] > > > - later on, in request_threaded_irq(), there are sanity checks [2] > > > - that fail with irq_settings_can_request() returning 0 [3] > > > > > > I cannot really put my finger on why the irq cannot be requested in DT > > > approach. > > > > Are you sure the marvell,orion-intc driver is successfully probed > > at this point? If not, the interrupt won't be there. > > > > I see that the "sata_mv" driver can be used either as a platform > > driver for the orion5x on-chip controller, or as a PCI driver for > > an add-on chip connected to the external bus. It sounds like > > your system has both. Do you know which one fails? > > > > The PCI driver cannot work unless the PCI host works correctly, > > and that in turn requires a correct devicetree description for it. > > > > > >> Is there a way to describe the PCIe bus in the > > > >> device tree? The initalisation of that bus is done for rev A1 only. > > > > > > > > I'm not too familiar with the platform, but my interpretation is that the > > > > DT support here is incomplete: > > > > > > > > The DT based PCI probe using drivers/pci/controller/pci-mvebu.c > > > > is not hooked up in orion5x.dtsi, and the traditional pci code does > > > > not work with DT. > > > > > > Can the existing pci code still be used to init the PCI bus and describe > > > the rest in the DT or is it a futile attempt? > > Hello! Orion uses arch/arm/mach-orion5x/pci.c driver for both PCI and > PCIe buses. This is not device tree driver. Correction, Orion PCIe driver is arch/arm/plat-orion/pcie.c and it calls common functions from mach-orion5x/pci.c driver. > > > > I see that orion5x has two separate blocks -- a PCIe host that is > > > > similar to the kirkwood one, and a legacy PCI host that needs > > > > a completely separate driver. > > > > > > > > Which of the two do you actually need here? > > > > > > > > > > I really cannot say which one is it. How can I tell? The functions given > > > in struct hw_pci find their way to drivers/pci/probe.c eventually and > > > use pci_scan_root_bus_bridge(). Nothing seems to utilising mvebu or > > > kirkwood explicitly at least. > > > > > > Here's the output from lspci if the ids reveal anything. > > > > > > # lspci -v -k > > > 00:00.0 Class 0580: 11ab:5181 > > > 01:00.0 Class 0580: 11ab:5181 > > > 00:01.0 Class 0100: 11ab:7042 sata_mv > > > > The first two seem to be the host bridges, but unfortunately they > > seem both have the same device ID, despite being very different > > devices. The first one (00:00.0) should be the PCIe driver, the > > second one (01.00.0) the legacy PCI one. In this case, the 11ab:7042 > > device is a PCIe device, and it's on the bus (00) of the first host > > bridge. I think this should work with drivers/pci/controller/pci-mvebu.c > > if you add the bits for probing. > > Last time when I looked on Orion PCIe controller registers, I though > that they are same as in Kirkwood PCIe controller registers. And > Kirkwood is already supported by pci-mvebu.c driver. > > About PCI host bridge, I do not know. > > Beware that PCI Class Id and all PCI registers which are different for > Type 0 and Type 1 are _broken_ on all PCIe Root Ports form all 32-bit > Marvell SoCs. Those registers on Marvell SoCs have different meaning as > what is defined in PCI and PCIe specs. So it means that lspci _may_ > display bogus information about PCIe Root Port. pci-mvebu.c uses Root > Port emulator which fills correct data to make kernel and lspci happy. > > If you are going to extend pci-mvebu.c to support also Orion PCIe > controller, I could try to help with it. But I do not have any Orion > hardware, so just basic help... > > Links to Orion documentations, including PCIe errata is available in > kernel documentation. So this could help to understand some details: > https://www.kernel.org/doc/html/latest/arm/marvell.html > > Anyway, could you please provide 'lspci -nn -vv' and 'lspci -nn -t -v' > outputs from Orion? > > > Thomas Petazzoni originally wrote the new driver, and I think he was > > planning at one point to use it for orion5x. I don't know if there were > > any major problems preventing this at the time, or if it just needs to > > get hooked up in the dtsi file. > > > > Arnd There is Orion-specific errata that config space via CF8/CFC registers is broken. Workaround documented in errata documented (linked from above documentation) does not work when DMA is used and instead other undocumented workaround is needed (implemented in arch/arm) which maps config space to memory (and therefore avoids usage of broken CF8/CFC memory mapped registers).
On 08.05.22 18:22, Pali Rohár wrote: > On Sunday 08 May 2022 17:02:17 Arnd Bergmann wrote: >> On Sun, May 8, 2022 at 4:06 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote: >>> On 28.4.2022 23.56, Arnd Bergmann wrote: >>>> On Thu, Apr 28, 2022 at 10:01 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote: >>>>> On 27.4.2022 21.10, Arnd Bergmann wrote: >>>>>> On Wed, Apr 27, 2022 at 6:21 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote: >>>>>>> - sata_mv fails to initialise with -22 (-EINVAL) >>>>>> >>>>>> No idea, I'd try inserting a printk in every code path that can return -EINVAL >>>>>> from there >>>>>> >>> >>> With debugging the reason for -EINVAL remains a bit mystery. >>> - sata_mv calls ata_host_activate() [1] >>> - later on, in request_threaded_irq(), there are sanity checks [2] >>> - that fail with irq_settings_can_request() returning 0 [3] >>> >>> I cannot really put my finger on why the irq cannot be requested in DT >>> approach. >> >> Are you sure the marvell,orion-intc driver is successfully probed >> at this point? If not, the interrupt won't be there. I made the pci setup to be the very last thing in the boot and results are still the same. There are other devices that do get their interrupts from intc. >> >> I see that the "sata_mv" driver can be used either as a platform >> driver for the orion5x on-chip controller, or as a PCI driver for >> an add-on chip connected to the external bus. It sounds like >> your system has both. Do you know which one fails? >> >> The PCI driver cannot work unless the PCI host works correctly, >> and that in turn requires a correct devicetree description for it. >> >>>>> Is there a way to describe the PCIe bus in the >>>>> device tree? The initalisation of that bus is done for rev A1 only. >>>> >>>> I'm not too familiar with the platform, but my interpretation is that the >>>> DT support here is incomplete: >>>> >>>> The DT based PCI probe using drivers/pci/controller/pci-mvebu.c >>>> is not hooked up in orion5x.dtsi, and the traditional pci code does >>>> not work with DT. >>> >>> Can the existing pci code still be used to init the PCI bus and describe >>> the rest in the DT or is it a futile attempt? > > Hello! Orion uses arch/arm/mach-orion5x/pci.c driver for both PCI and > PCIe buses. This is not device tree driver. > >>>> I see that orion5x has two separate blocks -- a PCIe host that is >>>> similar to the kirkwood one, and a legacy PCI host that needs >>>> a completely separate driver. >>>> >>>> Which of the two do you actually need here? >>>> >>> >>> I really cannot say which one is it. How can I tell? The functions given >>> in struct hw_pci find their way to drivers/pci/probe.c eventually and >>> use pci_scan_root_bus_bridge(). Nothing seems to utilising mvebu or >>> kirkwood explicitly at least. >>> >>> Here's the output from lspci if the ids reveal anything. >>> >>> # lspci -v -k >>> 00:00.0 Class 0580: 11ab:5181 >>> 01:00.0 Class 0580: 11ab:5181 >>> 00:01.0 Class 0100: 11ab:7042 sata_mv >> >> The first two seem to be the host bridges, but unfortunately they >> seem both have the same device ID, despite being very different >> devices. The first one (00:00.0) should be the PCIe driver, the >> second one (01.00.0) the legacy PCI one. In this case, the 11ab:7042 >> device is a PCIe device, and it's on the bus (00) of the first host >> bridge. I think this should work with drivers/pci/controller/pci-mvebu.c >> if you add the bits for probing. > > Last time when I looked on Orion PCIe controller registers, I though > that they are same as in Kirkwood PCIe controller registers. And > Kirkwood is already supported by pci-mvebu.c driver. > I seemed that way to me too on the first glance. And it looks like there are no devices using the PCI driver. I knocked off that part altogether and the boot log looks pretty much the same it was. Perhaps I can do with describing the PCIe bus only. > About PCI host bridge, I do not know. > > Beware that PCI Class Id and all PCI registers which are different for > Type 0 and Type 1 are _broken_ on all PCIe Root Ports form all 32-bit > Marvell SoCs. Those registers on Marvell SoCs have different meaning as > what is defined in PCI and PCIe specs. So it means that lspci _may_ > display bogus information about PCIe Root Port. pci-mvebu.c uses Root > Port emulator which fills correct data to make kernel and lspci happy. > > If you are going to extend pci-mvebu.c to support also Orion PCIe > controller, I could try to help with it. But I do not have any Orion > hardware, so just basic help... I could make an attempt at this. Should I try to look at an existing kirkwood based device first, say kirkwood-6281.dtsi? I didn't see anything SoC-specific in pci-mvebu.c. All different compatibles seem to share the same functionality. > > Links to Orion documentations, including PCIe errata is available in > kernel documentation. So this could help to understand some details: > https://www.kernel.org/doc/html/latest/arm/marvell.html > > Anyway, could you please provide 'lspci -nn -vv' and 'lspci -nn -t -v' > outputs from Orion? # lspci -nn -vv 0000:00:00.0 Memory controller [0580]: Marvell Technology Group Ltd. 88f5181 [Orion-1] ARM SoC [11ab:5181] (rev 03) Subsystem: Marvell Technology Group Ltd. Device [11ab:11ab] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 0 Region 0: Memory at <ignored> (64-bit, prefetchable) Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+ Address: 0000000000000000 Data: 0000 Capabilities: [60] Express (v1) Root Port (Slot-), MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0 ExtTag- RBE- DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend- LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Exit Latency L0s <256ns ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp- LnkCtl: ASPM Disabled; RCB 128 bytes, Disabled- CommClk- ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s (ok), Width x1 (ok) TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- RootCap: CRSVisible- RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible- RootSta: PME ReqID 0000, PMEStatus- PMEPending- 0000:00:01.0 SCSI storage controller [0100]: Marvell Technology Group Ltd. 88SX7042 PCI-e 4-port SATA-II [11ab:7042] (rev 02) Subsystem: Marvell Technology Group Ltd. Device [11ab:11ab] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 12 Region 0: Memory at e0000000 (64-bit, non-prefetchable) [size=1M] Region 2: I/O ports at 1000 [size=256] Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+ Address: 0000000000000000 Data: 0000 Capabilities: [60] Express (v1) Legacy Endpoint, MSI 00 DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <256ns, L1 <1us ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend- LnkCap: Port #0, Speed 2.5GT/s, Width x4, ASPM L0s, Exit Latency L0s <256ns ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp- LnkCtl: ASPM Disabled; RCB 128 bytes, Disabled- CommClk- ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s (ok), Width x1 (downgraded) TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- Kernel driver in use: sata_mv 0001:01:00.0 Memory controller [0580]: Marvell Technology Group Ltd. 88f5181 [Orion-1] ARM SoC [11ab:5181] (rev 03) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B+ DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 0 BIST result: 00 Region 0: Memory at <unassigned> (64-bit, prefetchable) Region 2: Memory at <ignored> (64-bit, prefetchable) Region 4: Memory at <ignored> (64-bit, non-prefetchable) Expansion ROM at <ignored> [disabled] Capabilities: [40] Power Management version 2 Flags: PMEClk+ DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME+ Capabilities: [48] Vital Product Data Not readable Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+ Address: 0000000000000000 Data: 0000 Capabilities: [60] PCI-X non-bridge device Command: DPERE- ERO- RBC=512 OST=4 Status: Dev=ff:1f.0 64bit+ 133MHz+ SCD- USC- DC=bridge DMMRBC=512 DMOST=4 DMCRS=8 RSCEM- 266MHz- 533MHz- Capabilities: [68] CompactPCI hot-swap <?> # lspci -nn -t -v -+-[0001:01]---00.0 Marvell Technology Group Ltd. 88f5181 [Orion-1] ARM SoC [11ab:5181] \-[0000:00]-+-00.0 Marvell Technology Group Ltd. 88f5181 [Orion-1] ARM SoC [11ab:5181] \-01.0 Marvell Technology Group Ltd. 88SX7042 PCI-e 4-port SATA-II [11ab:7042] > >> Thomas Petazzoni originally wrote the new driver, and I think he was >> planning at one point to use it for orion5x. I don't know if there were >> any major problems preventing this at the time, or if it just needs to >> get hooked up in the dtsi file. >> >> Arnd -- Mauri
On Sunday 08 May 2022 22:34:19 Mauri Sandberg wrote: > On 08.05.22 18:22, Pali Rohár wrote: > > On Sunday 08 May 2022 17:02:17 Arnd Bergmann wrote: > > > On Sun, May 8, 2022 at 4:06 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote: > > > > On 28.4.2022 23.56, Arnd Bergmann wrote: > > > > > On Thu, Apr 28, 2022 at 10:01 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote: > > > > > > On 27.4.2022 21.10, Arnd Bergmann wrote: > > > > > > > On Wed, Apr 27, 2022 at 6:21 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote: > > > > > > > > - sata_mv fails to initialise with -22 (-EINVAL) > > > > > > > > > > > > > > No idea, I'd try inserting a printk in every code path that can return -EINVAL > > > > > > > from there > > > > > > > > > > > > > > > With debugging the reason for -EINVAL remains a bit mystery. > > > > - sata_mv calls ata_host_activate() [1] > > > > - later on, in request_threaded_irq(), there are sanity checks [2] > > > > - that fail with irq_settings_can_request() returning 0 [3] > > > > > > > > I cannot really put my finger on why the irq cannot be requested in DT > > > > approach. > > > > > > Are you sure the marvell,orion-intc driver is successfully probed > > > at this point? If not, the interrupt won't be there. > > I made the pci setup to be the very last thing in the boot and > results are still the same. There are other devices that do get > their interrupts from intc. > > > > > > > I see that the "sata_mv" driver can be used either as a platform > > > driver for the orion5x on-chip controller, or as a PCI driver for > > > an add-on chip connected to the external bus. It sounds like > > > your system has both. Do you know which one fails? > > > > > > The PCI driver cannot work unless the PCI host works correctly, > > > and that in turn requires a correct devicetree description for it. > > > > > > > > > Is there a way to describe the PCIe bus in the > > > > > > device tree? The initalisation of that bus is done for rev A1 only. > > > > > > > > > > I'm not too familiar with the platform, but my interpretation is that the > > > > > DT support here is incomplete: > > > > > > > > > > The DT based PCI probe using drivers/pci/controller/pci-mvebu.c > > > > > is not hooked up in orion5x.dtsi, and the traditional pci code does > > > > > not work with DT. > > > > > > > > Can the existing pci code still be used to init the PCI bus and describe > > > > the rest in the DT or is it a futile attempt? > > > > Hello! Orion uses arch/arm/mach-orion5x/pci.c driver for both PCI and > > PCIe buses. This is not device tree driver. > > > > > > > I see that orion5x has two separate blocks -- a PCIe host that is > > > > > similar to the kirkwood one, and a legacy PCI host that needs > > > > > a completely separate driver. > > > > > > > > > > Which of the two do you actually need here? > > > > > > > > > > > > > I really cannot say which one is it. How can I tell? The functions given > > > > in struct hw_pci find their way to drivers/pci/probe.c eventually and > > > > use pci_scan_root_bus_bridge(). Nothing seems to utilising mvebu or > > > > kirkwood explicitly at least. > > > > > > > > Here's the output from lspci if the ids reveal anything. > > > > > > > > # lspci -v -k > > > > 00:00.0 Class 0580: 11ab:5181 > > > > 01:00.0 Class 0580: 11ab:5181 > > > > 00:01.0 Class 0100: 11ab:7042 sata_mv > > > > > > The first two seem to be the host bridges, but unfortunately they > > > seem both have the same device ID, despite being very different > > > devices. The first one (00:00.0) should be the PCIe driver, the > > > second one (01.00.0) the legacy PCI one. In this case, the 11ab:7042 > > > device is a PCIe device, and it's on the bus (00) of the first host > > > bridge. I think this should work with drivers/pci/controller/pci-mvebu.c > > > if you add the bits for probing. > > > > Last time when I looked on Orion PCIe controller registers, I though > > that they are same as in Kirkwood PCIe controller registers. And > > Kirkwood is already supported by pci-mvebu.c driver. > > > > I seemed that way to me too on the first glance. And it looks like there > are no devices using the PCI driver. I knocked off that part altogether and > the boot log looks pretty much the same it was. Perhaps I can do > with describing the PCIe bus only. > > > About PCI host bridge, I do not know. > > > > Beware that PCI Class Id and all PCI registers which are different for > > Type 0 and Type 1 are _broken_ on all PCIe Root Ports form all 32-bit > > Marvell SoCs. Those registers on Marvell SoCs have different meaning as > > what is defined in PCI and PCIe specs. So it means that lspci _may_ > > display bogus information about PCIe Root Port. pci-mvebu.c uses Root > > Port emulator which fills correct data to make kernel and lspci happy. > > > > If you are going to extend pci-mvebu.c to support also Orion PCIe > > controller, I could try to help with it. But I do not have any Orion > > hardware, so just basic help... > > I could make an attempt at this. Should I try to look at an existing > kirkwood based device first, say kirkwood-6281.dtsi? I didn't see > anything SoC-specific in pci-mvebu.c. All different compatibles seem > to share the same functionality. Yes, this could be a good starting point. But you will need new compatible string for orion, specially to implement workaround for accessing config space. > > > > Links to Orion documentations, including PCIe errata is available in > > kernel documentation. So this could help to understand some details: > > https://www.kernel.org/doc/html/latest/arm/marvell.html > > > > Anyway, could you please provide 'lspci -nn -vv' and 'lspci -nn -t -v' > > outputs from Orion? > > # lspci -nn -vv > 0000:00:00.0 Memory controller [0580]: Marvell Technology Group Ltd. 88f5181 > [Orion-1] ARM SoC [11ab:5181] (rev 03) > Subsystem: Marvell Technology Group Ltd. Device [11ab:11ab] > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ > Stepping- SERR+ FastB2B- DisINTx- > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- > <MAbort- >SERR- <PERR- INTx- > Latency: 0, Cache Line Size: 32 bytes > Interrupt: pin A routed to IRQ 0 > Region 0: Memory at <ignored> (64-bit, prefetchable) > Capabilities: [40] Power Management version 2 > Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) > Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- > Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+ > Address: 0000000000000000 Data: 0000 > Capabilities: [60] Express (v1) Root Port (Slot-), MSI 00 > DevCap: MaxPayload 128 bytes, PhantFunc 0 > ExtTag- RBE- > DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- > RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- > MaxPayload 128 bytes, MaxReadReq 512 bytes > DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend- > LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Exit Latency L0s > <256ns > ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp- > LnkCtl: ASPM Disabled; RCB 128 bytes, Disabled- CommClk- > ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- > LnkSta: Speed 2.5GT/s (ok), Width x1 (ok) > TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- > RootCap: CRSVisible- > RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible- > RootSta: PME ReqID 0000, PMEStatus- PMEPending- > > 0000:00:01.0 SCSI storage controller [0100]: Marvell Technology Group Ltd. > 88SX7042 PCI-e 4-port SATA-II [11ab:7042] (rev 02) > Subsystem: Marvell Technology Group Ltd. Device [11ab:11ab] > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ > Stepping- SERR+ FastB2B- DisINTx- > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- > <MAbort- >SERR- <PERR- INTx- > Latency: 0, Cache Line Size: 32 bytes > Interrupt: pin A routed to IRQ 12 > Region 0: Memory at e0000000 (64-bit, non-prefetchable) [size=1M] > Region 2: I/O ports at 1000 [size=256] > Capabilities: [40] Power Management version 2 > Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) > Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- > Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+ > Address: 0000000000000000 Data: 0000 > Capabilities: [60] Express (v1) Legacy Endpoint, MSI 00 > DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <256ns, L1 <1us > ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- > DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- > RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- > MaxPayload 128 bytes, MaxReadReq 512 bytes > DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend- > LnkCap: Port #0, Speed 2.5GT/s, Width x4, ASPM L0s, Exit Latency L0s > <256ns > ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp- > LnkCtl: ASPM Disabled; RCB 128 bytes, Disabled- CommClk- > ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- > LnkSta: Speed 2.5GT/s (ok), Width x1 (downgraded) > TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- > Kernel driver in use: sata_mv > > 0001:01:00.0 Memory controller [0580]: Marvell Technology Group Ltd. 88f5181 > [Orion-1] ARM SoC [11ab:5181] (rev 03) > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ > Stepping- SERR+ FastB2B+ DisINTx- > Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- > <MAbort+ >SERR- <PERR- INTx- > Latency: 0, Cache Line Size: 32 bytes > Interrupt: pin A routed to IRQ 0 > BIST result: 00 > Region 0: Memory at <unassigned> (64-bit, prefetchable) > Region 2: Memory at <ignored> (64-bit, prefetchable) > Region 4: Memory at <ignored> (64-bit, non-prefetchable) > Expansion ROM at <ignored> [disabled] > Capabilities: [40] Power Management version 2 > Flags: PMEClk+ DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-) > Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME+ > Capabilities: [48] Vital Product Data > Not readable > Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+ > Address: 0000000000000000 Data: 0000 > Capabilities: [60] PCI-X non-bridge device > Command: DPERE- ERO- RBC=512 OST=4 > Status: Dev=ff:1f.0 64bit+ 133MHz+ SCD- USC- DC=bridge DMMRBC=512 DMOST=4 > DMCRS=8 RSCEM- 266MHz- 533MHz- > Capabilities: [68] CompactPCI hot-swap <?> > > # lspci -nn -t -v > -+-[0001:01]---00.0 Marvell Technology Group Ltd. 88f5181 [Orion-1] ARM SoC > [11ab:5181] > \-[0000:00]-+-00.0 Marvell Technology Group Ltd. 88f5181 [Orion-1] ARM SoC > [11ab:5181] > \-01.0 Marvell Technology Group Ltd. 88SX7042 PCI-e 4-port > SATA-II [11ab:7042] Ok, so domain 0 is PCIe bus for sure. 0000:00:00.0 is PCIe Root Port (PCI-to-PCI bridge) incorrectly detected as Memory controller (known HW issue on all 32-bit Marvell SoCs). 0000:00:01.0 seems to be that SATA controller and this device is connected behind the PCIe Root Port. Topology is also incorrectly reports due to same known issue. Then there is domain 1 (first line in -t output) on which is just one device 0001:01:00.0 detected as Memory controller and has capability of "PCI-X non-bridge device". This seems to be PCI bus. I guess that Memory controller is also bogus information. What is "PCI-X non-bridge device"? I thought that "root" of the PCI bus should be Host Bridge. Anyway, there is my pending patch which should fix Class ID to not report incorrect Memory controller identification: https://lore.kernel.org/linux-pci/20211102171259.9590-1-pali@kernel.org/#Z31arch:arm:mach-orion5x:pci.c > > > > > Thomas Petazzoni originally wrote the new driver, and I think he was > > > planning at one point to use it for orion5x. I don't know if there were > > > any major problems preventing this at the time, or if it just needs to > > > get hooked up in the dtsi file. > > > > > > Arnd > > -- Mauri
On Sun, May 8, 2022 at 5:41 PM Pali Rohár <pali@kernel.org> wrote: > On Sunday 08 May 2022 17:22:37 Pali Rohár wrote: > > On Sunday 08 May 2022 17:02:17 Arnd Bergmann wrote: > > > > > > > > Can the existing pci code still be used to init the PCI bus and describe > > > > the rest in the DT or is it a futile attempt? > > > > Hello! Orion uses arch/arm/mach-orion5x/pci.c driver for both PCI and > > PCIe buses. This is not device tree driver. > > Correction, Orion PCIe driver is arch/arm/plat-orion/pcie.c and it calls > common functions from mach-orion5x/pci.c driver. FWIW, I have an older patch series that turns the plat-orion/pcie.c and mach-orion5x/pci.c into standalone host bridge drivers that no longer use the arm/kernel/bios32.c helpers. If anyone wants to work on DT support for the legacy-pci side (not for this machine but maybe another orion5x one), I can try to rebase those patches to make it easier to add the missing DT support. Arnd
On 8.5.2022 18.41, Pali Rohár wrote: > On Sunday 08 May 2022 17:22:37 Pali Rohár wrote: >> On Sunday 08 May 2022 17:02:17 Arnd Bergmann wrote: >>> On Sun, May 8, 2022 at 4:06 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote: >>>> On 28.4.2022 23.56, Arnd Bergmann wrote: >>>>> On Thu, Apr 28, 2022 at 10:01 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote: >>>>>> On 27.4.2022 21.10, Arnd Bergmann wrote: >>>>>>> On Wed, Apr 27, 2022 at 6:21 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote: >>>>>>>> - sata_mv fails to initialise with -22 (-EINVAL) >>>>>>> >>>>>>> No idea, I'd try inserting a printk in every code path that can return -EINVAL >>>>>>> from there >>>>>>> >>>> >>>> With debugging the reason for -EINVAL remains a bit mystery. >>>> - sata_mv calls ata_host_activate() [1] >>>> - later on, in request_threaded_irq(), there are sanity checks [2] >>>> - that fail with irq_settings_can_request() returning 0 [3] >>>> >>>> I cannot really put my finger on why the irq cannot be requested in DT >>>> approach. >>> >>> Are you sure the marvell,orion-intc driver is successfully probed >>> at this point? If not, the interrupt won't be there. >>> >>> I see that the "sata_mv" driver can be used either as a platform >>> driver for the orion5x on-chip controller, or as a PCI driver for >>> an add-on chip connected to the external bus. It sounds like >>> your system has both. Do you know which one fails? >>> >>> The PCI driver cannot work unless the PCI host works correctly, >>> and that in turn requires a correct devicetree description for it. >>> >>>>>> Is there a way to describe the PCIe bus in the >>>>>> device tree? The initalisation of that bus is done for rev A1 only. >>>>> >>>>> I'm not too familiar with the platform, but my interpretation is that the >>>>> DT support here is incomplete: >>>>> >>>>> The DT based PCI probe using drivers/pci/controller/pci-mvebu.c >>>>> is not hooked up in orion5x.dtsi, and the traditional pci code does >>>>> not work with DT. >>>> >>>> Can the existing pci code still be used to init the PCI bus and describe >>>> the rest in the DT or is it a futile attempt? >> >> Hello! Orion uses arch/arm/mach-orion5x/pci.c driver for both PCI and >> PCIe buses. This is not device tree driver. > > Correction, Orion PCIe driver is arch/arm/plat-orion/pcie.c and it calls > common functions from mach-orion5x/pci.c driver. > >>>>> I see that orion5x has two separate blocks -- a PCIe host that is >>>>> similar to the kirkwood one, and a legacy PCI host that needs >>>>> a completely separate driver. >>>>> >>>>> Which of the two do you actually need here? >>>>> >>>> >>>> I really cannot say which one is it. How can I tell? The functions given >>>> in struct hw_pci find their way to drivers/pci/probe.c eventually and >>>> use pci_scan_root_bus_bridge(). Nothing seems to utilising mvebu or >>>> kirkwood explicitly at least. >>>> >>>> Here's the output from lspci if the ids reveal anything. >>>> >>>> # lspci -v -k >>>> 00:00.0 Class 0580: 11ab:5181 >>>> 01:00.0 Class 0580: 11ab:5181 >>>> 00:01.0 Class 0100: 11ab:7042 sata_mv >>> >>> The first two seem to be the host bridges, but unfortunately they >>> seem both have the same device ID, despite being very different >>> devices. The first one (00:00.0) should be the PCIe driver, the >>> second one (01.00.0) the legacy PCI one. In this case, the 11ab:7042 >>> device is a PCIe device, and it's on the bus (00) of the first host >>> bridge. I think this should work with drivers/pci/controller/pci-mvebu.c >>> if you add the bits for probing. >> >> Last time when I looked on Orion PCIe controller registers, I though >> that they are same as in Kirkwood PCIe controller registers. And >> Kirkwood is already supported by pci-mvebu.c driver. >> >> About PCI host bridge, I do not know. >> >> Beware that PCI Class Id and all PCI registers which are different for >> Type 0 and Type 1 are _broken_ on all PCIe Root Ports form all 32-bit >> Marvell SoCs. Those registers on Marvell SoCs have different meaning as >> what is defined in PCI and PCIe specs. So it means that lspci _may_ >> display bogus information about PCIe Root Port. pci-mvebu.c uses Root >> Port emulator which fills correct data to make kernel and lspci happy. >> >> If you are going to extend pci-mvebu.c to support also Orion PCIe >> controller, I could try to help with it. But I do not have any Orion >> hardware, so just basic help... >> >> Links to Orion documentations, including PCIe errata is available in >> kernel documentation. So this could help to understand some details: >> https://www.kernel.org/doc/html/latest/arm/marvell.html >> >> Anyway, could you please provide 'lspci -nn -vv' and 'lspci -nn -t -v' >> outputs from Orion? >> >>> Thomas Petazzoni originally wrote the new driver, and I think he was >>> planning at one point to use it for orion5x. I don't know if there were >>> any major problems preventing this at the time, or if it just needs to >>> get hooked up in the dtsi file. >>> >>> Arnd > > There is Orion-specific errata that config space via CF8/CFC registers > is broken. Workaround documented in errata documented (linked from above > documentation) does not work when DMA is used and instead other > undocumented workaround is needed (implemented in arch/arm) which maps > config space to memory (and therefore avoids usage of broken CF8/CFC > memory mapped registers). So basically I should look at arch/arm/plat-orion/pcie.c for the configuration part, add new compatible to pci-mvebu.c for orion5x and alter the probing function accoringly for the same. Did I get it correctly? If so, sounds simple when said out lout but I might need some more pointers to get started. Like with configuration people generally mean setting BARs and WINs? Or is there more to it? :) If you could lay out the basic steps that are needed I would really appreciate it.
On 8.5.2022 23.10, Pali Rohár wrote: > On Sunday 08 May 2022 22:34:19 Mauri Sandberg wrote: >> On 08.05.22 18:22, Pali Rohár wrote: >>> On Sunday 08 May 2022 17:02:17 Arnd Bergmann wrote: >>>> On Sun, May 8, 2022 at 4:06 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote: >>>>> On 28.4.2022 23.56, Arnd Bergmann wrote: >>>>>> On Thu, Apr 28, 2022 at 10:01 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote: >>>>>>> On 27.4.2022 21.10, Arnd Bergmann wrote: >>>>>>>> On Wed, Apr 27, 2022 at 6:21 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote: >>>>>>>>> - sata_mv fails to initialise with -22 (-EINVAL) >>>>>>>> >>>>>>>> No idea, I'd try inserting a printk in every code path that can return -EINVAL >>>>>>>> from there >>>>>>>> >>>>> >>>>> With debugging the reason for -EINVAL remains a bit mystery. >>>>> - sata_mv calls ata_host_activate() [1] >>>>> - later on, in request_threaded_irq(), there are sanity checks [2] >>>>> - that fail with irq_settings_can_request() returning 0 [3] >>>>> >>>>> I cannot really put my finger on why the irq cannot be requested in DT >>>>> approach. >>>> >>>> Are you sure the marvell,orion-intc driver is successfully probed >>>> at this point? If not, the interrupt won't be there. >> >> I made the pci setup to be the very last thing in the boot and >> results are still the same. There are other devices that do get >> their interrupts from intc. >> >>>> >>>> I see that the "sata_mv" driver can be used either as a platform >>>> driver for the orion5x on-chip controller, or as a PCI driver for >>>> an add-on chip connected to the external bus. It sounds like >>>> your system has both. Do you know which one fails? >>>> >>>> The PCI driver cannot work unless the PCI host works correctly, >>>> and that in turn requires a correct devicetree description for it. >>>> >>>>>>> Is there a way to describe the PCIe bus in the >>>>>>> device tree? The initalisation of that bus is done for rev A1 only. >>>>>> >>>>>> I'm not too familiar with the platform, but my interpretation is that the >>>>>> DT support here is incomplete: >>>>>> >>>>>> The DT based PCI probe using drivers/pci/controller/pci-mvebu.c >>>>>> is not hooked up in orion5x.dtsi, and the traditional pci code does >>>>>> not work with DT. >>>>> >>>>> Can the existing pci code still be used to init the PCI bus and describe >>>>> the rest in the DT or is it a futile attempt? >>> >>> Hello! Orion uses arch/arm/mach-orion5x/pci.c driver for both PCI and >>> PCIe buses. This is not device tree driver. >>> >>>>>> I see that orion5x has two separate blocks -- a PCIe host that is >>>>>> similar to the kirkwood one, and a legacy PCI host that needs >>>>>> a completely separate driver. >>>>>> >>>>>> Which of the two do you actually need here? >>>>>> >>>>> >>>>> I really cannot say which one is it. How can I tell? The functions given >>>>> in struct hw_pci find their way to drivers/pci/probe.c eventually and >>>>> use pci_scan_root_bus_bridge(). Nothing seems to utilising mvebu or >>>>> kirkwood explicitly at least. >>>>> >>>>> Here's the output from lspci if the ids reveal anything. >>>>> >>>>> # lspci -v -k >>>>> 00:00.0 Class 0580: 11ab:5181 >>>>> 01:00.0 Class 0580: 11ab:5181 >>>>> 00:01.0 Class 0100: 11ab:7042 sata_mv >>>> >>>> The first two seem to be the host bridges, but unfortunately they >>>> seem both have the same device ID, despite being very different >>>> devices. The first one (00:00.0) should be the PCIe driver, the >>>> second one (01.00.0) the legacy PCI one. In this case, the 11ab:7042 >>>> device is a PCIe device, and it's on the bus (00) of the first host >>>> bridge. I think this should work with drivers/pci/controller/pci-mvebu.c >>>> if you add the bits for probing. >>> >>> Last time when I looked on Orion PCIe controller registers, I though >>> that they are same as in Kirkwood PCIe controller registers. And >>> Kirkwood is already supported by pci-mvebu.c driver. >>> >> >> I seemed that way to me too on the first glance. And it looks like there >> are no devices using the PCI driver. I knocked off that part altogether and >> the boot log looks pretty much the same it was. Perhaps I can do >> with describing the PCIe bus only. >> >>> About PCI host bridge, I do not know. >>> >>> Beware that PCI Class Id and all PCI registers which are different for >>> Type 0 and Type 1 are _broken_ on all PCIe Root Ports form all 32-bit >>> Marvell SoCs. Those registers on Marvell SoCs have different meaning as >>> what is defined in PCI and PCIe specs. So it means that lspci _may_ >>> display bogus information about PCIe Root Port. pci-mvebu.c uses Root >>> Port emulator which fills correct data to make kernel and lspci happy. >>> >>> If you are going to extend pci-mvebu.c to support also Orion PCIe >>> controller, I could try to help with it. But I do not have any Orion >>> hardware, so just basic help... >> >> I could make an attempt at this. Should I try to look at an existing >> kirkwood based device first, say kirkwood-6281.dtsi? I didn't see >> anything SoC-specific in pci-mvebu.c. All different compatibles seem >> to share the same functionality. > > Yes, this could be a good starting point. But you will need new > compatible string for orion, specially to implement workaround for > accessing config space. > >>> >>> Links to Orion documentations, including PCIe errata is available in >>> kernel documentation. So this could help to understand some details: >>> https://www.kernel.org/doc/html/latest/arm/marvell.html >>> >>> Anyway, could you please provide 'lspci -nn -vv' and 'lspci -nn -t -v' >>> outputs from Orion? >> >> # lspci -nn -vv >> 0000:00:00.0 Memory controller [0580]: Marvell Technology Group Ltd. 88f5181 >> [Orion-1] ARM SoC [11ab:5181] (rev 03) >> Subsystem: Marvell Technology Group Ltd. Device [11ab:11ab] >> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ >> Stepping- SERR+ FastB2B- DisINTx- >> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- >> <MAbort- >SERR- <PERR- INTx- >> Latency: 0, Cache Line Size: 32 bytes >> Interrupt: pin A routed to IRQ 0 >> Region 0: Memory at <ignored> (64-bit, prefetchable) >> Capabilities: [40] Power Management version 2 >> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) >> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- >> Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+ >> Address: 0000000000000000 Data: 0000 >> Capabilities: [60] Express (v1) Root Port (Slot-), MSI 00 >> DevCap: MaxPayload 128 bytes, PhantFunc 0 >> ExtTag- RBE- >> DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- >> RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- >> MaxPayload 128 bytes, MaxReadReq 512 bytes >> DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend- >> LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Exit Latency L0s >> <256ns >> ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp- >> LnkCtl: ASPM Disabled; RCB 128 bytes, Disabled- CommClk- >> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- >> LnkSta: Speed 2.5GT/s (ok), Width x1 (ok) >> TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- >> RootCap: CRSVisible- >> RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible- >> RootSta: PME ReqID 0000, PMEStatus- PMEPending- >> >> 0000:00:01.0 SCSI storage controller [0100]: Marvell Technology Group Ltd. >> 88SX7042 PCI-e 4-port SATA-II [11ab:7042] (rev 02) >> Subsystem: Marvell Technology Group Ltd. Device [11ab:11ab] >> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ >> Stepping- SERR+ FastB2B- DisINTx- >> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- >> <MAbort- >SERR- <PERR- INTx- >> Latency: 0, Cache Line Size: 32 bytes >> Interrupt: pin A routed to IRQ 12 >> Region 0: Memory at e0000000 (64-bit, non-prefetchable) [size=1M] >> Region 2: I/O ports at 1000 [size=256] >> Capabilities: [40] Power Management version 2 >> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) >> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- >> Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+ >> Address: 0000000000000000 Data: 0000 >> Capabilities: [60] Express (v1) Legacy Endpoint, MSI 00 >> DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <256ns, L1 <1us >> ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- >> DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- >> RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- >> MaxPayload 128 bytes, MaxReadReq 512 bytes >> DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend- >> LnkCap: Port #0, Speed 2.5GT/s, Width x4, ASPM L0s, Exit Latency L0s >> <256ns >> ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp- >> LnkCtl: ASPM Disabled; RCB 128 bytes, Disabled- CommClk- >> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- >> LnkSta: Speed 2.5GT/s (ok), Width x1 (downgraded) >> TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- >> Kernel driver in use: sata_mv >> >> 0001:01:00.0 Memory controller [0580]: Marvell Technology Group Ltd. 88f5181 >> [Orion-1] ARM SoC [11ab:5181] (rev 03) >> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ >> Stepping- SERR+ FastB2B+ DisINTx- >> Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- >> <MAbort+ >SERR- <PERR- INTx- >> Latency: 0, Cache Line Size: 32 bytes >> Interrupt: pin A routed to IRQ 0 >> BIST result: 00 >> Region 0: Memory at <unassigned> (64-bit, prefetchable) >> Region 2: Memory at <ignored> (64-bit, prefetchable) >> Region 4: Memory at <ignored> (64-bit, non-prefetchable) >> Expansion ROM at <ignored> [disabled] >> Capabilities: [40] Power Management version 2 >> Flags: PMEClk+ DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-) >> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME+ >> Capabilities: [48] Vital Product Data >> Not readable >> Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+ >> Address: 0000000000000000 Data: 0000 >> Capabilities: [60] PCI-X non-bridge device >> Command: DPERE- ERO- RBC=512 OST=4 >> Status: Dev=ff:1f.0 64bit+ 133MHz+ SCD- USC- DC=bridge DMMRBC=512 DMOST=4 >> DMCRS=8 RSCEM- 266MHz- 533MHz- >> Capabilities: [68] CompactPCI hot-swap <?> >> >> # lspci -nn -t -v >> -+-[0001:01]---00.0 Marvell Technology Group Ltd. 88f5181 [Orion-1] ARM SoC >> [11ab:5181] >> \-[0000:00]-+-00.0 Marvell Technology Group Ltd. 88f5181 [Orion-1] ARM SoC >> [11ab:5181] >> \-01.0 Marvell Technology Group Ltd. 88SX7042 PCI-e 4-port >> SATA-II [11ab:7042] > > Ok, so domain 0 is PCIe bus for sure. > 0000:00:00.0 is PCIe Root Port (PCI-to-PCI bridge) incorrectly detected > as Memory controller (known HW issue on all 32-bit Marvell SoCs). > 0000:00:01.0 seems to be that SATA controller and this device is > connected behind the PCIe Root Port. Topology is also incorrectly > reports due to same known issue. > > Then there is domain 1 (first line in -t output) on which is just one > device 0001:01:00.0 detected as Memory controller and has capability of > "PCI-X non-bridge device". This seems to be PCI bus. I guess that Memory > controller is also bogus information. > > What is "PCI-X non-bridge device"? I thought that "root" of the PCI bus > should be Host Bridge. > > Anyway, there is my pending patch which should fix Class ID to not > report incorrect Memory controller identification: > https://lore.kernel.org/linux-pci/20211102171259.9590-1-pali@kernel.org/#Z31arch:arm:mach-orion5x:pci.c With the patch the roots are identified as follows: # lspci -nn -vv 0000:00:00.0 Host bridge [0600]: Marvell Technology Group Ltd. 88f5181 [Orion-1] ARM SoC [11ab:5181] (rev 03) ... 0001:01:00.0 Host bridge [0600]: Marvell Technology Group Ltd. 88f5181 [Orion-1] ARM SoC [11ab:5181] (rev 03) Everything else remained the same. >>> >>>> Thomas Petazzoni originally wrote the new driver, and I think he was >>>> planning at one point to use it for orion5x. I don't know if there were >>>> any major problems preventing this at the time, or if it just needs to >>>> get hooked up in the dtsi file. >>>> >>>> Arnd >> >> -- Mauri
On Monday 09 May 2022 13:48:53 Mauri Sandberg wrote: > On 8.5.2022 18.41, Pali Rohár wrote: > > On Sunday 08 May 2022 17:22:37 Pali Rohár wrote: > >> On Sunday 08 May 2022 17:02:17 Arnd Bergmann wrote: > >>> On Sun, May 8, 2022 at 4:06 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote: > >>>> On 28.4.2022 23.56, Arnd Bergmann wrote: > >>>>> On Thu, Apr 28, 2022 at 10:01 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote: > >>>>>> On 27.4.2022 21.10, Arnd Bergmann wrote: > >>>>>>> On Wed, Apr 27, 2022 at 6:21 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote: > >>>>>>>> - sata_mv fails to initialise with -22 (-EINVAL) > >>>>>>> > >>>>>>> No idea, I'd try inserting a printk in every code path that can return -EINVAL > >>>>>>> from there > >>>>>>> > >>>> > >>>> With debugging the reason for -EINVAL remains a bit mystery. > >>>> - sata_mv calls ata_host_activate() [1] > >>>> - later on, in request_threaded_irq(), there are sanity checks [2] > >>>> - that fail with irq_settings_can_request() returning 0 [3] > >>>> > >>>> I cannot really put my finger on why the irq cannot be requested in DT > >>>> approach. > >>> > >>> Are you sure the marvell,orion-intc driver is successfully probed > >>> at this point? If not, the interrupt won't be there. > >>> > >>> I see that the "sata_mv" driver can be used either as a platform > >>> driver for the orion5x on-chip controller, or as a PCI driver for > >>> an add-on chip connected to the external bus. It sounds like > >>> your system has both. Do you know which one fails? > >>> > >>> The PCI driver cannot work unless the PCI host works correctly, > >>> and that in turn requires a correct devicetree description for it. > >>> > >>>>>> Is there a way to describe the PCIe bus in the > >>>>>> device tree? The initalisation of that bus is done for rev A1 only. > >>>>> > >>>>> I'm not too familiar with the platform, but my interpretation is that the > >>>>> DT support here is incomplete: > >>>>> > >>>>> The DT based PCI probe using drivers/pci/controller/pci-mvebu.c > >>>>> is not hooked up in orion5x.dtsi, and the traditional pci code does > >>>>> not work with DT. > >>>> > >>>> Can the existing pci code still be used to init the PCI bus and describe > >>>> the rest in the DT or is it a futile attempt? > >> > >> Hello! Orion uses arch/arm/mach-orion5x/pci.c driver for both PCI and > >> PCIe buses. This is not device tree driver. > > > > Correction, Orion PCIe driver is arch/arm/plat-orion/pcie.c and it calls > > common functions from mach-orion5x/pci.c driver. > > > >>>>> I see that orion5x has two separate blocks -- a PCIe host that is > >>>>> similar to the kirkwood one, and a legacy PCI host that needs > >>>>> a completely separate driver. > >>>>> > >>>>> Which of the two do you actually need here? > >>>>> > >>>> > >>>> I really cannot say which one is it. How can I tell? The functions given > >>>> in struct hw_pci find their way to drivers/pci/probe.c eventually and > >>>> use pci_scan_root_bus_bridge(). Nothing seems to utilising mvebu or > >>>> kirkwood explicitly at least. > >>>> > >>>> Here's the output from lspci if the ids reveal anything. > >>>> > >>>> # lspci -v -k > >>>> 00:00.0 Class 0580: 11ab:5181 > >>>> 01:00.0 Class 0580: 11ab:5181 > >>>> 00:01.0 Class 0100: 11ab:7042 sata_mv > >>> > >>> The first two seem to be the host bridges, but unfortunately they > >>> seem both have the same device ID, despite being very different > >>> devices. The first one (00:00.0) should be the PCIe driver, the > >>> second one (01.00.0) the legacy PCI one. In this case, the 11ab:7042 > >>> device is a PCIe device, and it's on the bus (00) of the first host > >>> bridge. I think this should work with drivers/pci/controller/pci-mvebu.c > >>> if you add the bits for probing. > >> > >> Last time when I looked on Orion PCIe controller registers, I though > >> that they are same as in Kirkwood PCIe controller registers. And > >> Kirkwood is already supported by pci-mvebu.c driver. > >> > >> About PCI host bridge, I do not know. > >> > >> Beware that PCI Class Id and all PCI registers which are different for > >> Type 0 and Type 1 are _broken_ on all PCIe Root Ports form all 32-bit > >> Marvell SoCs. Those registers on Marvell SoCs have different meaning as > >> what is defined in PCI and PCIe specs. So it means that lspci _may_ > >> display bogus information about PCIe Root Port. pci-mvebu.c uses Root > >> Port emulator which fills correct data to make kernel and lspci happy. > >> > >> If you are going to extend pci-mvebu.c to support also Orion PCIe > >> controller, I could try to help with it. But I do not have any Orion > >> hardware, so just basic help... > >> > >> Links to Orion documentations, including PCIe errata is available in > >> kernel documentation. So this could help to understand some details: > >> https://www.kernel.org/doc/html/latest/arm/marvell.html > >> > >> Anyway, could you please provide 'lspci -nn -vv' and 'lspci -nn -t -v' > >> outputs from Orion? > >> > >>> Thomas Petazzoni originally wrote the new driver, and I think he was > >>> planning at one point to use it for orion5x. I don't know if there were > >>> any major problems preventing this at the time, or if it just needs to > >>> get hooked up in the dtsi file. > >>> > >>> Arnd > > > > There is Orion-specific errata that config space via CF8/CFC registers > > is broken. Workaround documented in errata documented (linked from above > > documentation) does not work when DMA is used and instead other > > undocumented workaround is needed (implemented in arch/arm) which maps > > config space to memory (and therefore avoids usage of broken CF8/CFC > > memory mapped registers). > > So basically I should look at arch/arm/plat-orion/pcie.c for the > configuration part, add new compatible to pci-mvebu.c for orion5x > and alter the probing function accoringly for the same. Did I get > it correctly? You would need to replace mvebu_pcie_child_rd_conf() and mvebu_pcie_child_wr_conf() implementation in pci-mvebu.c with the correct orion implementation. Orion implementation is in function pcie_rd_conf_wa() or pcie_rd_conf() (file arch/arm/mach-orion5x/pci.c) based on the fact if workaround has to be applied or not. Same for *wr* functions. Workaround uses wa_base address, which needs to be mapped via mbus driver. This is something new which is not supported by pci-mvebu.c. And wa_base address should be correctly specified in ranges= property of type "configuration space" (ss = 00). See: https://elinux.org/Device_Tree_Usage#PCI_Address_Translation > If so, sounds simple when said out lout but I might need some more > pointers to get started. Like with configuration people generally > mean setting BARs and WINs? Or is there more to it? :) If you > could lay out the basic steps that are needed I would really > appreciate it. BARs and WINs are configured by pci-mvebu.c. You just have specify correct ids in DTS. See usage of MBUS_ID() macro and Port X IO/MEM comments e.g. in arch/arm/boot/dts/armada-385.dtsi file. Also it is required to set pcie-mem-aperture and pcie-io-aperture properties, see e.g. in arch/arm/boot/dts/armada-38x.dtsi file. I'm not sure if this is clear for you. If not, please ask additional questions :-)