lkml.org 
[lkml]   [2014]   [Apr]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v7 1/6] pci: Introduce pci_register_io_range() helper function.
    On Tue, Apr 08, 2014 at 12:21:51AM +0100, Bjorn Helgaas wrote:
    > On Fri, Mar 14, 2014 at 9:34 AM, Liviu Dudau <Liviu.Dudau@arm.com> wrote:
    > > Some architectures do not share x86 simple view of the PCI I/O space
    > > and instead use a range of addresses that map to bus addresses. For
    > > some architectures these ranges will be expressed by OF bindings
    > > in a device tree file.
    > >
    > > Introduce a pci_register_io_range() helper function that can be used
    > > by the architecture code to keep track of the I/O ranges described by the
    > > PCI bindings. If the PCI_IOBASE macro is not defined that signals
    > > lack of support for PCI and we return an error.
    > >
    > > Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
    > > Acked-by: Grant Likely <grant.likely@linaro.org>
    > > Tested-by: Tanmay Inamdar <tinamdar@apm.com>
    > > ---
    > > drivers/of/address.c | 9 +++++++++
    > > include/linux/of_address.h | 1 +
    > > 2 files changed, 10 insertions(+)
    > >
    > > diff --git a/drivers/of/address.c b/drivers/of/address.c
    > > index 1a54f1f..be958ed 100644
    > > --- a/drivers/of/address.c
    > > +++ b/drivers/of/address.c
    > > @@ -619,6 +619,15 @@ const __be32 *of_get_address(struct device_node *dev, int index, u64 *size,
    > > }
    > > EXPORT_SYMBOL(of_get_address);
    > >
    > > +int __weak pci_register_io_range(phys_addr_t addr, resource_size_t size)
    > > +{
    > > +#ifndef PCI_IOBASE
    > > + return -EINVAL;
    > > +#else
    > > + return 0;
    > > +#endif
    > > +}
    >
    > This isn't PCI code, so I'm fine with it in that sense, but I'm not
    > sure the idea of a PCI_IOBASE #define is really what we need. It's
    > not really determined by the processor architecture, it's determined
    > by the platform. And a single address isn't enough in general,
    > either, because if there are multiple host bridges, there's no reason
    > the apertures that generate PCI I/O transactions need to be contiguous
    > on the CPU side.

    It should not be only platform's choice if the architecture doesn't support it.
    To my mind PCI_IOBASE means "I support MMIO operations and this is the
    start of the virtual address where my I/O ranges are mapped." It's the
    same as ppc's _IO_BASE. And pci_address_to_pio() will take care to give
    you the correct io_offset in the presence of multiple host bridges,
    while keeping the io resource in the range [0 .. host_bridge_io_range_size - 1]

    >
    > That's just a long way of saying that if we ever came up with a more
    > generic way to handle I/O port spaces, PCI_IOBASE might go away. And
    > I guess part of that rework could be changing this use of it along
    > with the others.

    And I have a patch series that #defines PCI_IOBASE only in those architectures
    that support MMIO, where this macro makes sense. Also notice that the
    arm64 series has a patch that I'm going to roll into this one where ioport_map()
    gets fixed to include PCI_IOBASE when !CONFIG_GENERIC_MAP.

    Best regards,
    Liviu

    >
    > > unsigned long __weak pci_address_to_pio(phys_addr_t address)
    > > {
    > > if (address > IO_SPACE_LIMIT)
    > > diff --git a/include/linux/of_address.h b/include/linux/of_address.h
    > > index 5f6ed6b..40c418d 100644
    > > --- a/include/linux/of_address.h
    > > +++ b/include/linux/of_address.h
    > > @@ -56,6 +56,7 @@ extern void __iomem *of_iomap(struct device_node *device, int index);
    > > extern const __be32 *of_get_address(struct device_node *dev, int index,
    > > u64 *size, unsigned int *flags);
    > >
    > > +extern int pci_register_io_range(phys_addr_t addr, resource_size_t size);
    > > extern unsigned long pci_address_to_pio(phys_addr_t addr);
    > >
    > > extern int of_pci_range_parser_init(struct of_pci_range_parser *parser,
    > > --
    > > 1.9.0
    > >
    >

    --
    ====================
    | I would like to |
    | fix the world, |
    | but they're not |
    | giving me the |
    \ source code! /
    ---------------
    ¯\_(ツ)_/¯

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2014-04-08 12:41    [W:4.988 / U:0.144 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site