On Fri, Oct 31, 2014 at 05:04:49PM +0000, Phil Edworthy wrote:
> Hi Bjorn,
>
> On 31 October 2014 16:37, Bjorn wrote:
> > On Fri, Oct 31, 2014 at 7:43 AM, Phil Edworthy
> > <phil.edworthy@xxxxxxxxxxx> wrote:
> > > Hi Lorenzo,
> > >
> > > On 30 October 2014 11:45, Lorenzo wrote:
> > >> Most if not all ARM PCI host controller device drivers either ignore the
> > >> domain field in the pci_sys_data structure or just increment it every
> > >> time a host controller is probed, using it as a domain counter.
> > >>
> > >> Therefore, instead of relying on pci_sys_data to stash the domain number
> > >> in a standard location, ARM pcibios code can be moved to the newly
> > >> introduced generic PCI domains code, implemented in commits:
> > >>
> > >> commit 41e5c0f81d3e676d671d96a0a1fafb27abfbd9
> > >> ("of/pci: Add pci_get_new_domain_nr() and of_get_pci_domain_nr()")
> > >>
> > >> commit 670ba0c8883b576d0aec28bd7a838358a4be1
> > >> ("PCI: Add generic domain handling")
> > >>
> > >> In order to assign a domain number dynamically, the ARM pcibios defines
> > >> the function, called by core PCI code:
> > >>
> > >> void pci_bus_assign_domain_nr(...)
> > >>
> > >> that relies on a DT property to define the domain number or falls back to
> > >> a counter; its usage replaces the current domain assignment code in PCI
> > >> host controllers present in the kernel.
> > >>
> > >> Cc: Arnd Bergmann <arnd@xxxxxxxx>
> > >> Cc: Phil Edworthy <phil.edworthy@xxxxxxxxxxx>
> > >> Cc: Jason Gunthorpe <jgunthorpe@xxxxxxxxxxxxxxxxxxxx>
> > >> Cc: Jingoo Han <jg1.han@xxxxxxxxxxx>
> > >> Cc: Bjorn Helgaas <bhelgaas@xxxxxxxxxx>
> > >> Cc: Russell King <linux@xxxxxxxxxxxxxxxx>
> > >> Cc: Mohit Kumar <mohit.kumar@xxxxxx>
> > >> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@xxxxxxx>
> > >
> > > This patch fixes a current problem with R-Car devices where there is an
> > > internal PCI bridge and an external PCIe bridge on the devices. Both drivers
> > > work independently but need to be on different domains. Just needed to
> > enable
> > > PCI_DOMAINS along with this.
> > > I've done basic testing that the internal PCI and external PCIe work at the
> > > same time.
> >
> > Hi Phil,
> >
> > Thanks for testing this. Can you give me some more guidance on where
> > you'd like to see this merged? Until your comment about this fixing a
> > current problem on R-Car, I probably would have considered this to be
> > a cleanup and enhancement and hence material for v3.19. But if R-Car
> > is actually broken and this fixes it, maybe this should go in for
> > v3.18 instead.
> I don’t think its urgent as most of our customers use LTSI kernels, e.g. v3.10.
> Renesas typically provide out-of-tree BSPs with upstream code back ported, along
> with other patches. Simon Horman (Renesas maintainer, cc'd) generally handles
> the back ports, so I'll defer to his opinion.
Hi Phil,
from my point of view it would be best if this went into -stable if it is a
fix. However, as you point out, from a customer point of view it shouldn't
be a big deal as they should get backports via our LTSI kernel regardless of
if the patch goes through stable or not.
> > If it is currently broken, is there a point where it broke? I assume
> > it used to work at one time. If there's a commit that broke it, it
> > would be nice to reference that in the changelog and explain exactly
> > what was broken and how this fixes it.
> Both the internal PCI and external PCIe drivers work on their own, but have
> never worked at the same time. I think it was just unfortunate timing when I
> added the PCIe driver. At that time, the internal PCI driver didn’t have the
> relevant DT nodes for the board I was using so I didn't see any conflicts.
>
> Thanks
> Phil
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
