public inbox for linuxppc-dev@ozlabs.org 
 help / color / mirror / Atom feed
From: Andrew May <acmay@acmay•homeip.net>
To: Matt Porter <porter@cox•net>, linuxppc-embedded@lists•linuxppc.org
Subject: Re: very minor 405GP and 405GPr PCI difference
Date: Mon, 7 Oct 2002 22:21:36 -0700	[thread overview]
Message-ID: <20021008052136.GA26470@acmay.homeip.net> (raw)
In-Reply-To: <20021008041419.GF32555@zax>


On Tue, Oct 08, 2002 at 02:14:19PM +1000, David Gibson wrote:
>
> On Sun, Oct 06, 2002 at 06:31:20PM -0700, Matt Porter wrote:
> >
> > On Sat, Oct 05, 2002 at 10:23:14PM -0700, Andrew May wrote:
> > >
> > > It would be nice to have the option to let the boot loader set the
> > > mapping. I have been happy with getting things done in PPCBoot and
> > > ripping out the PCI scanning in the kernel.
> >
> > Yes, that's the ideal situation and going to what David and I would
> > like to see makes that yet another simple fallout feature.
> >
> > Your custom port using a good implementation of PPCBoot simply
> > would not call the pci macro init library nor would it use pci_auto.
>
> As Matt says, this would fall out naturally from a better control
> structure.  Howeever, I tend to think that leaving things like this to
> the bootloader/firmware is a bad idea:

A full featured bootloader like PPCboot will need to setup the PCI bus
to work with PCI devices, so it is not like it is always an extra burden
on the bootloader or useless work.

> The kernel has to know how PCI addresses are mapped anyway, so this
> becomes yet another point at which the kernel and firmware are bound
> together.  Why should the kernel have code to deal with umpteen
> different cases of how PCI might have been set up, or not set up by
> the firmware/bootloader, when it can just take control of the host
> bridge and reprogram it how it wants?  Once the debugging cruft comes
> out, it should only be a couple of hundred bytes of code.

I wouldn't want to see the kernel deal with all the possible mapping
configurations. Right now with everything getting remapped a couple
of times it makes it hard to follow what the final mapping will be.
Then we also have the core Linux PCI code that will try to fixup things
again, if it thinks it is needed. PPCBoot knows how the kernel wants
things setup so there should be no need to fix it up.

So I just want you to keep in mind the PCI bus fixup can be a config
option that can be built out if desired. It really shouldn't be tied
to the board itself, since it is also common to load in PPCboot into
Walnut boards.

Then there is always the case of hot-plugs, and the kernel will always
have to do that mapping there.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

  reply	other threads:[~2002-10-08  5:21 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-09-27 12:27 very minor 405GP and 405GPr PCI difference Ralph Blach
2002-09-30  4:01 ` David Gibson
2002-10-01  5:21   ` David Gibson
2002-10-01  8:37     ` "David Müller (ELSOFT AG)"
2002-10-02  1:42       ` David Gibson
2002-10-02  4:26         ` Allen Curtis
2002-10-02  5:34           ` David Gibson
2002-10-02 17:03             ` Matt Porter
2002-10-03  1:10               ` David Gibson
2002-10-03 15:14                 ` Matt Porter
2002-10-04  2:48                   ` David Gibson
2002-10-04 18:33                     ` Todd Poynor
2002-10-08  4:17                       ` David Gibson
2002-10-08 19:39                         ` Todd Poynor
2002-10-09  2:14                           ` David Gibson
     [not found]                           ` <20021 <20021023040850.GC1198@zax>
2002-10-24 23:50                             ` Ralph Blach
2002-10-25  1:19                               ` David Gibson
2002-10-02  7:46         ` "David Müller (ELSOFT AG)"
2002-10-03  1:12           ` David Gibson
2002-10-03  8:28             ` "David Müller (ELSOFT AG)"
2002-10-06  5:23             ` Andrew May
2002-10-07  1:31               ` Matt Porter
2002-10-08  4:14                 ` David Gibson
2002-10-08  5:21                   ` Andrew May [this message]
2002-10-08 14:56                     ` Matt Porter
2002-10-08 17:31                       ` Andrew May
2002-10-08 18:20                         ` Matt Porter
2002-10-09  1:58                     ` David Gibson
2002-10-09 10:35                       ` Kenneth Johansson
2002-10-09 15:21                         ` Allen Curtis
2002-10-11 19:37                       ` Andrew May
2002-10-14  1:20                         ` David Gibson
2002-10-08  6:19                   ` Allen Curtis
2002-10-08 15:18                     ` Matt Porter
2002-10-09  2:10                     ` David Gibson
2002-10-22 21:55         ` Todd Poynor
2002-10-23  4:08           ` David Gibson
  -- strict thread matches above, loose matches on Subject: below --
2002-10-23 13:10 Ralph Blach

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=20021008052136.GA26470@acmay.homeip.net \
    --to=acmay@acmay$(echo .)homeip.net \
    --cc=linuxppc-embedded@lists$(echo .)linuxppc.org \
    --cc=porter@cox$(echo .)net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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