devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Liviu Dudau <Liviu.Dudau@arm.com>
Cc: Rob Herring <robherring2@gmail.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	Catalin Marinas <Catalin.Marinas@arm.com>,
	Olof Johansson <olof@lixom.net>, Arnd Bergmann <arnd@arndb.de>,
	Michal Simek <monstr@monstr.eu>,
	"grant.likely@linaro.org" <grant.likely@linaro.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
Subject: Re: [RFC] Architecture independent pcibios?
Date: Wed, 09 Oct 2013 21:37:48 +1100	[thread overview]
Message-ID: <1381315068.4330.1.camel@pasglop> (raw)
In-Reply-To: <20131009090923.GE25606@e102652-lin.cambridge.arm.com>

On Wed, 2013-10-09 at 10:09 +0100, Liviu Dudau wrote:
> On Tue, Oct 08, 2013 at 09:28:55PM +0100, Benjamin Herrenschmidt wrote:
> > On Tue, 2013-10-08 at 11:55 -0500, Rob Herring wrote:
> >
> > > > I wonder if pci_process_bridge_OF_ranges() would fit somewhere in
> > > > drivers/of?  The implementations I looked at are mostly concerned with
> > > > parsing OF resources, and they don't have much to do with PCI
> > > > directly.
> > >
> > > This was being done until Ben weighed in:
> > >
> > > https://lkml.org/lkml/2013/5/4/103
> >
> > Well, I proposed an alternative (better) approach which I of course had
> > no time to actually implement yet :-)
> 
> In order to avoid any confusion, could you please point me again to the
> relevant message(s) where you proposed your approach?

The one pointed to by the above URL ?

> > I have done the changes I needed to do to powerpc
> > pci_process_bridge_OF_ranges so it would be possible to move that now to
> > a generic place, but I still think it's not a great idea. It means the
> > pci_controller structure with its resources will have to become generic
> > which somewhat overlaps with the pci_host_bridge that Bjorn introduced,
> > so that's really not great.
> >
> > I still think an arch with DT and simpler PCI code that powerpc could
> > start looking at the transition to a better model that I hinted at...
> 
> As tempting as it is to start anew and with a cleaner code, I am wary
> that porting the existing platforms to the new code will take longer
> that way. My intentions are to make the (probably infrequent) task of
> adding a new architecture to the PCI infrastructure a simple and
> straighforward task. But adding code for my platform is no guarantee
> that new ones will have an easier job.

It still makes little sense to generalize a pci_controller with
resources & offset on top of the generic pci_host_bridge with apertures.

Ben.

> Best regards,
> Liviu
> 
> >
> > Cheers,
> > Ben.
> >
> >
> >
> 
> --
> ====================
> | I would like to |
> | fix the world,  |
> | but they're not |
> | giving me the   |
>  \ source code!  /
>   ---------------
>     ¯\_(ツ)_/¯
> 
> -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.
> 
> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2557590
> ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2548782

  parent reply	other threads:[~2013-10-09 10:37 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20131008144211.GA25231@e102652-lin.cambridge.arm.com>
     [not found] ` <20131008144211.GA25231-CibnQJhq84/ZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org>
2013-10-08 16:32   ` [RFC] Architecture independent pcibios? Bjorn Helgaas
2013-10-08 16:55     ` Rob Herring
2013-10-08 17:20       ` Andrew Murray
2013-10-08 20:32         ` Benjamin Herrenschmidt
2013-10-08 20:28       ` Benjamin Herrenschmidt
2013-10-09  9:09         ` Liviu Dudau
2013-10-09 10:04           ` Liviu Dudau
2013-10-09 10:37           ` Benjamin Herrenschmidt [this message]
2013-10-09 10:45             ` Liviu Dudau
2013-10-09 14:30               ` Bjorn Helgaas
2013-10-09 16:23                 ` Liviu Dudau
2013-10-15 11:48           ` Grant Likely
2013-10-08 17:13     ` Liviu Dudau
2013-10-08 18:58       ` Bjorn Helgaas
2013-10-08 20:31       ` Benjamin Herrenschmidt
2013-10-09 11:52         ` Michal Simek

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=1381315068.4330.1.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=Catalin.Marinas@arm.com \
    --cc=Liviu.Dudau@arm.com \
    --cc=arnd@arndb.de \
    --cc=bhelgaas@google.com \
    --cc=devicetree@vger.kernel.org \
    --cc=grant.likely@linaro.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=monstr@monstr.eu \
    --cc=olof@lixom.net \
    --cc=robherring2@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).