Hi Thomas,

Thanks for the explanation.

On Fri, Jul 30, 2021 at 10:30 AM Thomas Bogendoerfer
[off-list ref] wrote:

On Thu, Jul 29, 2021 at 01:21:45PM +0200, Sergio Paracuellos wrote:

quoted

Hi Thomas,

On Thu, Jul 29, 2021 at 12:02 PM Thomas Bogendoerfer
[off-list ref] wrote:

quoted

On Mon, Jun 14, 2021 at 12:06:15PM +0200, Sergio Paracuellos wrote:

quoted

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@gmail.com>
---
 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.

quoted

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 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 ]