All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
To: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Cc: linux-staging@lists.linux.dev,
	Greg KH <gregkh@linuxfoundation.org>, NeilBrown <neil@brown.name>,
	"open list:MIPS" <linux-mips@vger.kernel.org>,
	Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com>,
	John Crispin <john@phrozen.org>
Subject: Re: [PATCH v2 1/3] MIPS: ralink: Define PCI_IOBASE
Date: Fri, 30 Jul 2021 14:39:39 +0200	[thread overview]
Message-ID: <20210730123939.GA8207@alpha.franken.de> (raw)
In-Reply-To: <CAMhs-H9EMXi_t=r=LuwudYG0oz0O27xj3_ko-eq-R+75wKE3PQ@mail.gmail.com>

On Fri, Jul 30, 2021 at 01:15:36PM +0200, Sergio Paracuellos wrote:
> On Fri, Jul 30, 2021 at 12:22 PM Sergio Paracuellos
> <sergio.paracuellos@gmail.com> wrote:
> >
> > Hi Thomas,
> >
> > On Fri, Jul 30, 2021 at 10:30 AM Thomas Bogendoerfer
> > <tsbogend@alpha.franken.de> 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@alpha.franken.de> 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@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.
> > >
> > > > 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.
> > >
> > > 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);
> > >
> > >
> > > This together with an increased IO space via
> > >
> > > #define IO_SPACE_LIMIT 0x1fffffff
> > >
> > > gives me a working PCI bus on the RB532.
> >
> > BTW, I have tested your changes and they result in a no working pci
> > for mt7621. I get a resource collision error:
> >
> > mt7621-pci 1e140000.pcie: resource collision: [io
> > 0x1e160000-0x1e16ffff] conflicts with PCI IO [io  0x0000-0xffff]
> >
> > My changes:
> >  - avoid PCI_IOBASE to be defined.
> >  - avoid map in pci_parse_request_of_pci_ranges
> >  - Change spaces.h to have the new IO_SPACE_LIMIT to 0x1fffffff
> >
> > Am I missing something?
> 
> I am forced to set ioport_resource stuff at the beginning of the probe
> function to avoid this collision error:
> 
> /* set resources limits */
> ioport_resource.start = 0x1e160000;
> ioport_resource.end = 0x1e16ffff;

yes, that's then neeed, I'm using

        ioport_resource.start = 0;
        ioport_resource.end = ~0UL;

but 

ioport_resource.end = IO_SPACE_LIMIT;

would be more correct.

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]

  reply	other threads:[~2021-07-30 12:39 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-14 10:06 [PATCH v2 0/3] staging: mt7621-pci: define ralink PCI_IOBASE to avoid manually ranges parsing Sergio Paracuellos
2021-06-14 10:06 ` [PATCH v2 1/3] MIPS: ralink: Define PCI_IOBASE Sergio Paracuellos
2021-06-15 11:51   ` Greg KH
2021-06-15 12:38     ` Sergio Paracuellos
2021-06-15 12:38       ` Sergio Paracuellos
2021-06-15 13:08   ` Thomas Bogendoerfer
2021-06-15 13:12     ` Sergio Paracuellos
2021-06-15 13:12       ` Sergio Paracuellos
2021-06-15 13:24       ` Greg KH
2021-07-29 10:01   ` Thomas Bogendoerfer
2021-07-29 11:21     ` Sergio Paracuellos
2021-07-29 11:21       ` Sergio Paracuellos
2021-07-30  8:30       ` Thomas Bogendoerfer
2021-07-30  9:41         ` Sergio Paracuellos
2021-07-30  9:41           ` Sergio Paracuellos
2021-07-30 10:22         ` Sergio Paracuellos
2021-07-30 10:22           ` Sergio Paracuellos
2021-07-30 11:15           ` Sergio Paracuellos
2021-07-30 11:15             ` Sergio Paracuellos
2021-07-30 12:39             ` Thomas Bogendoerfer [this message]
2021-07-30 15:51               ` Sergio Paracuellos
2021-07-30 15:51                 ` Sergio Paracuellos
2021-06-14 10:06 ` [PATCH v2 2/3] staging: mt7621-pci: remove 'mt7621_pci_parse_request_of_pci_ranges' Sergio Paracuellos
2021-06-14 10:06 ` [PATCH v2 3/3] staging: mt7621-dts: fix pci address for PCI memory range Sergio Paracuellos

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210730123939.GA8207@alpha.franken.de \
    --to=tsbogend@alpha.franken.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=ilya.lipnitskiy@gmail.com \
    --cc=john@phrozen.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=neil@brown.name \
    --cc=sergio.paracuellos@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.