From: Dan Malek <dan@netx4.com>
To: Steve Rossi <srossi@ccrl.mot.com>
Cc: Embedded Linux PPC List <linuxppc-embedded@lists.linuxppc.org>
Subject: Re: Question on QSPAN Driver
Date: Mon, 20 Mar 2000 12:31:21 -0500 [thread overview]
Message-ID: <38D66069.AA538C28@embeddededge.com> (raw)
In-Reply-To: 38D64A54.D5A8E8BA@ccrl.mot.com
Steve Rossi wrote:
> ........ I've noticed
> that there are two occurances of qspan_pci.c and pci.c - one in
> arch/ppc/kernel
> and another in /arch/ppc/mbxboot.
The PCI functions in arch/ppc/mbxboot are used by boards that don't
have a 'bios' function for the initialization and mapping of the
PCI bus (which are nearly all PowerPC boards I have ever seen, and
those that attempt it don't do it correctly). The qspan_init function
is just the basic, minimal initialization of the QSpan to get slave
mode PCI access. These functions may not be complete for your
environment. You are likely to add more functions for the mapping.
The PCI functions in arch/ppc/kernel are Linux generic functions for
supporting PCI devices.
> ......the
> exception of CONFIG_RPXCLASSIC support in the version in /arch/ppc/
> kernel (seemingly indicating that its an updated version) and the lack
> of
> qspan_init in that same version.
The Embedded Planet RPX Classic just went through a major design
change, and I am updating the functions to support that now.
The qspan_init function isn't needed in the Linux kernel because that
should have been done long before the kernel was started.
> ...... When I include the QSPAN PCI support
> in the kernel configuration - it appears that during the PCI bus scan at
>
> boot time the version of qspan_pcibios_read_config_byte() in
> arch/ppc/kernel/qspan_pci.c is called.
That is correct.
> So here are my questions:
> 1. Why doesn't qspan_init ever get called before the PCI bus is scanned?
That is the job of something during the boot process before the Linux
kernel is started.
> 2. Should the pci_scanner function in arch/ppc/mbxboot/pci.c be called
> in
> place of the normal pci_scan_bus() function in drivers/pci/pci.c?
No, those functions are very different. The functions in 'mbxboot'
are used to initialize and map the PCI bus. The functions in the
Linux kernel are discovery functions.
> 3. Does Linux have a table of valid memory areas for peripheral devices
> -
> I've seen this in other embedded OS's.
Take a look at one of the board configuration files in include/asm-ppc,
like 'mbx.h' or 'rpxclassic.h'. Then look at arch/ppc/mm/init.c.
-- Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2000-03-20 17:31 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-03-20 15:57 Question on QSPAN Driver Steve Rossi
2000-03-20 17:31 ` Dan Malek [this message]
2000-03-20 19:44 ` Steve Rossi
2000-03-20 20:03 ` Dan Malek
2000-03-21 2:07 ` Jason Wohlgemuth
2000-03-21 3:07 ` Dan Malek
2000-03-22 1:35 ` Does mpc8xx-2.2.13 support "Enable loadable module support"? dony
2000-03-22 1:54 ` Joe Green
2000-03-22 3:10 ` dony
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=38D66069.AA538C28@embeddededge.com \
--to=dan@netx4.com \
--cc=linuxppc-embedded@lists.linuxppc.org \
--cc=srossi@ccrl.mot.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).