Hi Thomas, Thanks for the explanation. On Fri, Jul 30, 2021 at 10:30 AM Thomas Bogendoerfer <tsbogend@xxxxxxxxxxxxxxxx> wrote: > > On Thu, Jul 29, 2021 at 01:21:45PM +0200, Sergio Paracuellos wrote: > > Hi Thomas, > > > > On Thu, Jul 29, 2021 at 12:02 PM Thomas Bogendoerfer > > <tsbogend@xxxxxxxxxxxxxxxx> wrote: > > > > > > On Mon, Jun 14, 2021 at 12:06:15PM +0200, Sergio Paracuellos wrote: > > > > PCI_IOBASE is used to create VM maps for PCI I/O ports, it is > > > > required by generic PCI drivers to make memory mapped I/O range > > > > work. Hence define it for ralink architectures to be able to > > > > avoid parsing manually IO ranges in PCI generic driver code. > > > > Function 'plat_mem_setup' for ralink is using 'set_io_port_base' > > > > call using '0xa0000000' as address, so use the same address in > > > > the definition to align things. > > > > > > > > Signed-off-by: Sergio Paracuellos <sergio.paracuellos@xxxxxxxxx> > > > > --- > > > > arch/mips/include/asm/mach-ralink/spaces.h | 10 ++++++++++ > > > > 1 file changed, 10 insertions(+) > > > > create mode 100644 arch/mips/include/asm/mach-ralink/spaces.h > > > > > > > > diff --git a/arch/mips/include/asm/mach-ralink/spaces.h b/arch/mips/include/asm/mach-ralink/spaces.h > > > > new file mode 100644 > > > > index 000000000000..87d085c9ad61 > > > > --- /dev/null > > > > +++ b/arch/mips/include/asm/mach-ralink/spaces.h > > > > @@ -0,0 +1,10 @@ > > > > +/* SPDX-License-Identifier: GPL-2.0 */ > > > > +#ifndef __ASM_MACH_RALINK_SPACES_H_ > > > > +#define __ASM_MACH_RALINK_SPACES_H_ > > > > + > > > > +#define PCI_IOBASE _AC(0xa0000000, UL) > > > > +#define PCI_IOSIZE SZ_16M > > > > +#define IO_SPACE_LIMIT (PCI_IOSIZE - 1) > > > > + > > > > +#include <asm/mach-generic/spaces.h> > > > > +#endif > > > > > > does this really work for you ? I tried the same trick for RB532 > > > and the generated IO addresses are wrong... > > > > I got pci io resources assigned without complaints from the pci core > > code. I don't have real pci card that uses I/O bars but this is what I > > see in the boot (I added some traces when I was testing this): > > resource handling works, but the addresses generated for IO access > are wrong, because the iomap tries to ioremap it to a fixed > virtual address (PCI_IOBASE), which can't work for KSEG1 addresses. What I don't understand is why the kernel is not complaining about remapping this if "devm_pci_remap_iospace" can't work. I cannot see any complaints in my dmesg log. > > > Is this wrong? > > to get it working this way, we would need to put PCI_IOBASE somewhere > into KSEG2, which I don't like since it will create TLB entries for IO > addresses, which most of the time isn't needed on MIPS because of > access via KSEG1. If I am understanding you correctly, you mean to change PCI_IOBASE location to be somewhere in KSEG2 and set up the new io base address through "set_io_port_base", right? TLB entries should be out of this. Yes, I don't like this either. > I'd much prefer to make the devm_pci_remap_iospace() in drivers/pci/of.c > optional. Something like this > > diff --git a/drivers/pci/of.c b/drivers/pci/of.c > index a143b02b2dcd..657aef39bf63 100644 > --- a/drivers/pci/of.c > +++ b/drivers/pci/of.c > @@ -564,12 +564,14 @@ static int pci_parse_request_of_pci_ranges(struct device *dev, > > switch (resource_type(res)) { > case IORESOURCE_IO: > +#ifdef PCI_IOBASE > err = devm_pci_remap_iospace(dev, res, iobase); > if (err) { > dev_warn(dev, "error %d: failed to map resource %pR\n", > err, res); > resource_list_destroy_entry(win); > } > +#endif > break; > case IORESOURCE_MEM: > res_valid |= !(res->flags & IORESOURCE_PREFETCH); > I don't know which architectures are not currently defining PCI_IOBASE and might need this to be called (or if this is also not possible at all scenario), honestly. > > This together with an increased IO space via > > #define IO_SPACE_LIMIT 0x1fffffff I guess we can also redefine the weak "pci_address_to_pio" symbol for mips to avoid this change, but only to do a "return (unsigned long) address;" it might make no sense also :). > > gives me a working PCI bus on the RB532. > > No idea, if the patch would be accepted by the PCI maintainers. > Let's ask about this, just to be sure... +cc Bjorn Helgaas and Lorenzo Pieralisi. Bjorn, Lorenzo. Sorry to bother you. What do you think about this? What should be the correct approach to handle this? Does the "pci_parse_request_of_pci_ranges" change sound reasonable for you? Thanks in advance for your time and clarification. Best regards, Sergio Paracuellos > Thomas. > > -- > Crap can work. Given enough thrust pigs will fly, but it's not necessarily a > good idea. [ RFC1925, 2.3 ]