lkml.org 
[lkml]   [2014]   [Mar]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v7 3/3] arm64: Add architecture support for PCI
    On Thu, Mar 20, 2014 at 11:17:22AM +0000, Arnd Bergmann wrote:
    > On Thursday 20 March 2014, Liviu Dudau wrote:
    > > On Wed, Mar 19, 2014 at 06:37:51PM +0000, Arnd Bergmann wrote:
    > > > On Wednesday 19 March 2014 17:21:41 Liviu Dudau wrote:
    > > > >
    > > > > My ultimate point is that no matter how long we argue about the shape of the functions that
    > > > > I've added into arch/arm64/kernel/pci.c I don't think we can get away without having that
    > > > > file, or at least not in the first phase if we want speedy integration into mainline.
    > > >
    > > > Let me simplify the discussion here:
    > > >
    > > > NAK to adding yet another architecture specific implementation.
    > >
    > > So what would be your approach for handling pci_address_to_pio() in a non-arch specific way?
    > >
    > > unsigned long __weak pci_address_to_pio(phys_addr_t address)
    > > {
    > > #ifdef ARCH_HAS_IOSPACE
    > > if (address > IO_SPACE_LIMIT)
    > > return (unsigned long)-1;
    > >
    > > return (unsigned long) address;
    > > #else
    > > struct ioresource *res;
    > >
    > > list_for_each_entry(res, &io_list, list) {
    > > if (address >= res->start &&
    > > address < res->start + res->size) {
    > > return res->start - address;
    > > }
    > > }
    > >
    > > return (unsigned long)-1;
    > > #endif
    > > }
    > >
    > >
    > > Either that, or you have more magic rabbits than me.
    >
    > I don't even understand why you want to create a generic pci_address_to_pio
    > implementation, when we don't need that for arm64 at all. Unless I'm
    > missing something important, that function is only called in case of
    > PCI_PROBE_DEVTREE with pci_of_scan on PowerPC. I don't expect any
    > architecture to do the same thing, and the only other architecture that
    > needs something like it (sparc) has a different implementation.

    Because in my [v7 2/6]* patch for the generic host bridge support I start
    using pci_address_to_pio to fix the conversion of PCI ranges to resources.
    That requires an arm64 (or more correctly, an arch with memory mapped IO
    specific) version of pci_address_to_pio().

    Best regards,
    Liviu

    >
    > The regular (non-DEVTREE) PCI bus scan should just be able to translate
    > the BUS I/O addresses into Linux I/O port numbers using io_offset,
    > without going through an intermediate step of translating into a CPU
    > physical address first, so the entire lookup method won't get used.
    >
    > The reason why PowerPC needs it is that they traditionally don't
    > use PCI config space access to assign or look at resources, but
    > instead rely on the firmware to have set it up in advance and then
    > put matching information into DT and the BARs. For Solaris and AIX,
    > it's probably easier to use the information from DT, but in Linux,
    > we already need to implement the manual bus scan, e.g. to do
    > PCI device hotplugging if nothing else.
    >
    > Arnd
    > --
    > To unsubscribe from this list: send the line "unsubscribe linux-pci" in
    > the body of a message to majordomo@vger.kernel.org
    > More majordomo info at http://vger.kernel.org/majordomo-info.html
    >

    --
    ====================
    | 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-03-20 13:21    [W:6.263 / U:0.044 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site