From: Arnd Bergmann <arnd@arndb.de>
To: Liviu Dudau <Liviu.Dudau@arm.com>
Cc: "linux-pci" <linux-pci@vger.kernel.org>,
Bjorn Helgaas <bhelgaas@google.com>,
Catalin Marinas <Catalin.Marinas@arm.com>,
Will Deacon <Will.Deacon@arm.com>,
LKML <linux-kernel@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
LAKML <linux-arm-kernel@lists.infradead.org>,
"linaro-kernel" <linaro-kernel@lists.linaro.org>
Subject: Re: [PATCH] pci: Add support for creating a generic host_bridge from device tree
Date: Tue, 4 Feb 2014 16:56:58 +0100 [thread overview]
Message-ID: <201402041656.59165.arnd@arndb.de> (raw)
In-Reply-To: <20140204120801.GB27975@e106497-lin.cambridge.arm.com>
On Tuesday 04 February 2014, Liviu Dudau wrote:
> On Tue, Feb 04, 2014 at 10:09:44AM +0000, Arnd Bergmann wrote:
> > On Monday 03 February 2014 22:17:44 Liviu Dudau wrote:
> > > On Mon, Feb 03, 2014 at 07:31:31PM +0000, Arnd Bergmann wrote:
> > > > The aperture here reflects the subset of the
> > > > 4GB bus I/O space that is actually mapped into a CPU visible "physical
> > > > I/O aperture" using an inbound mapping of the host bridge. The physical
> > > > I/O aperture in turn gets mapped to the virtual I/O space using
> > > > pci_ioremap_io.
> > >
> > > Agree.
> > >
> > > > The difference between a bus I/O address and a logical
> > > > I/O address is stored in the io_offset.
> > >
> > > Not exactly. If that would be true that means that for an I/O range that
> > > start at bus I/O address zero but physical I/O apperture starts at
> > > 0x40000000 the io_offset is zero. For me, the io_offset should be 0x40000000.
> >
> > That's not how we do it on any of the existing host controllers.
> > Typically the io_offset is zero for the first one, and may be
> > either zero for all the others (meaning BARs get > 64KB values
> > for secondary buses) or between 64KB and 2MB (meaning each bus
> > starts at I/O port number 0).
>
> In that case it is probably worth to rename my variable into phys_io_offset.
>
> I need to go back over my driver code. My assumptions were probably wrong
> wrt to meaning of the io_offset.
Ok. I'd still call it 'base' rather than 'offset', although the meaning
isn't all that different.
> > But there should never be an IORESOURCE_IO resource structure that is
> > not in IO space, i.e. within ioport_resource. Doing an "adjustment"
> > is not an operation defined on this structure. What I meant above is that
> > the pci range parser gets this right and gives you a resource that looks
> > like { .flags = IORESOURCE_MEM, .start = phys_base, .end = phys_base +
> > size - 1}, while the resource we want to register is { .flags = IORESOURCE_IO,
> > .start = log_base, .end = log_base + size -1}. In the of_pci_range struct for
> > the I/O space, the "pci_space" is IORESOURCE_IO (for the pci_addr), while the
> > "flags" are IORESOURCE_MEM, to go along with the cpu_addr.
>
> The pci range parser gives me a range with .flags = IORESOURCE_IO for IO space. It
> does not convert it to IORESOURCE_MEM. Hence the need for adjustment.
Ah, I see that now in the code too. This seems to be a bug in the range parser
though: range->flags should not be initialized to
of_bus_pci_get_flags(parser->range).
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] pci: Add support for creating a generic host_bridge from device tree
Date: Tue, 4 Feb 2014 16:56:58 +0100 [thread overview]
Message-ID: <201402041656.59165.arnd@arndb.de> (raw)
In-Reply-To: <20140204120801.GB27975@e106497-lin.cambridge.arm.com>
On Tuesday 04 February 2014, Liviu Dudau wrote:
> On Tue, Feb 04, 2014 at 10:09:44AM +0000, Arnd Bergmann wrote:
> > On Monday 03 February 2014 22:17:44 Liviu Dudau wrote:
> > > On Mon, Feb 03, 2014 at 07:31:31PM +0000, Arnd Bergmann wrote:
> > > > The aperture here reflects the subset of the
> > > > 4GB bus I/O space that is actually mapped into a CPU visible "physical
> > > > I/O aperture" using an inbound mapping of the host bridge. The physical
> > > > I/O aperture in turn gets mapped to the virtual I/O space using
> > > > pci_ioremap_io.
> > >
> > > Agree.
> > >
> > > > The difference between a bus I/O address and a logical
> > > > I/O address is stored in the io_offset.
> > >
> > > Not exactly. If that would be true that means that for an I/O range that
> > > start at bus I/O address zero but physical I/O apperture starts at
> > > 0x40000000 the io_offset is zero. For me, the io_offset should be 0x40000000.
> >
> > That's not how we do it on any of the existing host controllers.
> > Typically the io_offset is zero for the first one, and may be
> > either zero for all the others (meaning BARs get > 64KB values
> > for secondary buses) or between 64KB and 2MB (meaning each bus
> > starts at I/O port number 0).
>
> In that case it is probably worth to rename my variable into phys_io_offset.
>
> I need to go back over my driver code. My assumptions were probably wrong
> wrt to meaning of the io_offset.
Ok. I'd still call it 'base' rather than 'offset', although the meaning
isn't all that different.
> > But there should never be an IORESOURCE_IO resource structure that is
> > not in IO space, i.e. within ioport_resource. Doing an "adjustment"
> > is not an operation defined on this structure. What I meant above is that
> > the pci range parser gets this right and gives you a resource that looks
> > like { .flags = IORESOURCE_MEM, .start = phys_base, .end = phys_base +
> > size - 1}, while the resource we want to register is { .flags = IORESOURCE_IO,
> > .start = log_base, .end = log_base + size -1}. In the of_pci_range struct for
> > the I/O space, the "pci_space" is IORESOURCE_IO (for the pci_addr), while the
> > "flags" are IORESOURCE_MEM, to go along with the cpu_addr.
>
> The pci range parser gives me a range with .flags = IORESOURCE_IO for IO space. It
> does not convert it to IORESOURCE_MEM. Hence the need for adjustment.
Ah, I see that now in the code too. This seems to be a bug in the range parser
though: range->flags should not be initialized to
of_bus_pci_get_flags(parser->range).
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
To: Liviu Dudau <Liviu.Dudau-5wv7dgnIgG8@public.gmane.org>
Cc: linux-pci <linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Bjorn Helgaas <bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
Catalin Marinas <Catalin.Marinas-5wv7dgnIgG8@public.gmane.org>,
Will Deacon <Will.Deacon-5wv7dgnIgG8@public.gmane.org>,
LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
LAKML
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
linaro-kernel
<linaro-kernel-cunTk1MwBs8s++Sfvej+rw@public.gmane.org>
Subject: Re: [PATCH] pci: Add support for creating a generic host_bridge from device tree
Date: Tue, 4 Feb 2014 16:56:58 +0100 [thread overview]
Message-ID: <201402041656.59165.arnd@arndb.de> (raw)
In-Reply-To: <20140204120801.GB27975-2JSQmVVBSi7ZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org>
On Tuesday 04 February 2014, Liviu Dudau wrote:
> On Tue, Feb 04, 2014 at 10:09:44AM +0000, Arnd Bergmann wrote:
> > On Monday 03 February 2014 22:17:44 Liviu Dudau wrote:
> > > On Mon, Feb 03, 2014 at 07:31:31PM +0000, Arnd Bergmann wrote:
> > > > The aperture here reflects the subset of the
> > > > 4GB bus I/O space that is actually mapped into a CPU visible "physical
> > > > I/O aperture" using an inbound mapping of the host bridge. The physical
> > > > I/O aperture in turn gets mapped to the virtual I/O space using
> > > > pci_ioremap_io.
> > >
> > > Agree.
> > >
> > > > The difference between a bus I/O address and a logical
> > > > I/O address is stored in the io_offset.
> > >
> > > Not exactly. If that would be true that means that for an I/O range that
> > > start at bus I/O address zero but physical I/O apperture starts at
> > > 0x40000000 the io_offset is zero. For me, the io_offset should be 0x40000000.
> >
> > That's not how we do it on any of the existing host controllers.
> > Typically the io_offset is zero for the first one, and may be
> > either zero for all the others (meaning BARs get > 64KB values
> > for secondary buses) or between 64KB and 2MB (meaning each bus
> > starts at I/O port number 0).
>
> In that case it is probably worth to rename my variable into phys_io_offset.
>
> I need to go back over my driver code. My assumptions were probably wrong
> wrt to meaning of the io_offset.
Ok. I'd still call it 'base' rather than 'offset', although the meaning
isn't all that different.
> > But there should never be an IORESOURCE_IO resource structure that is
> > not in IO space, i.e. within ioport_resource. Doing an "adjustment"
> > is not an operation defined on this structure. What I meant above is that
> > the pci range parser gets this right and gives you a resource that looks
> > like { .flags = IORESOURCE_MEM, .start = phys_base, .end = phys_base +
> > size - 1}, while the resource we want to register is { .flags = IORESOURCE_IO,
> > .start = log_base, .end = log_base + size -1}. In the of_pci_range struct for
> > the I/O space, the "pci_space" is IORESOURCE_IO (for the pci_addr), while the
> > "flags" are IORESOURCE_MEM, to go along with the cpu_addr.
>
> The pci range parser gives me a range with .flags = IORESOURCE_IO for IO space. It
> does not convert it to IORESOURCE_MEM. Hence the need for adjustment.
Ah, I see that now in the code too. This seems to be a bug in the range parser
though: range->flags should not be initialized to
of_bus_pci_get_flags(parser->range).
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2014-02-04 15:56 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-03 18:33 [PATCH] [RFC] Support for creating generic host_bridge from device tree Liviu Dudau
2014-02-03 18:33 ` Liviu Dudau
2014-02-03 18:33 ` Liviu Dudau
2014-02-03 18:33 ` [PATCH] pci: Add support for creating a " Liviu Dudau
2014-02-03 18:33 ` Liviu Dudau
2014-02-03 18:46 ` Arnd Bergmann
2014-02-03 18:46 ` Arnd Bergmann
2014-02-03 19:06 ` Liviu Dudau
2014-02-03 19:06 ` Liviu Dudau
2014-02-03 19:06 ` Liviu Dudau
2014-02-03 19:31 ` Arnd Bergmann
2014-02-03 19:31 ` Arnd Bergmann
2014-02-03 22:17 ` Liviu Dudau
2014-02-03 22:17 ` Liviu Dudau
2014-02-04 10:09 ` Arnd Bergmann
2014-02-04 10:09 ` Arnd Bergmann
2014-02-04 12:08 ` Liviu Dudau
2014-02-04 12:08 ` Liviu Dudau
2014-02-04 15:56 ` Arnd Bergmann [this message]
2014-02-04 15:56 ` Arnd Bergmann
2014-02-04 15:56 ` Arnd Bergmann
2014-02-05 22:26 ` Tanmay Inamdar
2014-02-05 22:26 ` Tanmay Inamdar
2014-02-06 10:18 ` Liviu Dudau
2014-02-06 10:18 ` Liviu Dudau
2014-02-08 0:21 ` Tanmay Inamdar
2014-02-08 0:21 ` Tanmay Inamdar
2014-02-08 14:22 ` Liviu Dudau
2014-02-08 14:22 ` Liviu Dudau
2014-02-09 20:22 ` Arnd Bergmann
2014-02-09 20:22 ` Arnd Bergmann
2014-02-09 20:22 ` Arnd Bergmann
2014-02-10 18:06 ` Tanmay Inamdar
2014-02-10 18:06 ` Tanmay Inamdar
2014-02-13 8:10 ` Jingoo Han
2014-02-13 8:10 ` Jingoo Han
2014-02-13 8:18 ` Jingoo Han
2014-02-13 8:18 ` Jingoo Han
2014-02-13 8:36 ` Tanmay Inamdar
2014-02-13 8:36 ` Tanmay Inamdar
2014-02-13 8:36 ` Tanmay Inamdar
2014-02-13 8:57 ` Jingoo Han
2014-02-13 8:57 ` Jingoo Han
2014-02-13 11:27 ` Arnd Bergmann
2014-02-13 11:27 ` Arnd Bergmann
2014-02-13 11:53 ` Russell King - ARM Linux
2014-02-13 11:53 ` Russell King - ARM Linux
2014-02-13 12:15 ` Arnd Bergmann
2014-02-13 12:15 ` Arnd Bergmann
2014-02-13 12:15 ` Arnd Bergmann
2014-02-13 12:20 ` Liviu Dudau
2014-02-13 12:20 ` Liviu Dudau
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=201402041656.59165.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=Catalin.Marinas@arm.com \
--cc=Liviu.Dudau@arm.com \
--cc=Will.Deacon@arm.com \
--cc=bhelgaas@google.com \
--cc=devicetree@vger.kernel.org \
--cc=linaro-kernel@lists.linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
/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.