From: Paul Gortmaker <paul.gortmaker@windriver.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 1/8] sbc8548: delete unused MPC8548CDS info carried over from port
Date: Sat, 19 Sep 2009 12:05:33 -0400 [thread overview]
Message-ID: <4AB5014D.4030009@windriver.com> (raw)
In-Reply-To: <51DCE285-5BA5-49ED-B8EB-0482E77ED72D@kernel.crashing.org>
Kumar Gala wrote:
>
> On Sep 18, 2009, at 6:08 PM, Paul Gortmaker wrote:
>
>> There are a couple defines and PCI bridge quirks related to the PCI
>> backplane of the MPC8548CDS that have no meaning in the context of
>> the port to the sbc8548 board, so delete them.
>>
>> Also, the form factor of the sbc8548 is a standalone board with a
>> single PCI-X and a single PCI-e slot. That pretty much guarantees
>> that it will never be a PCI agent itself, so the host/agent and root
>> complex/end node distinctions have been removed.
>>
>> Similarly, since there is no physical connector mapping to PCI2, so
>> all references of PCI2 in the board support files have been removed
>> as well.
>>
>> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
>> ---
>> board/sbc8548/sbc8548.c | 63
>> ++++----------------------------------------
>> include/configs/sbc8548.h | 9 ------
>> 2 files changed, 6 insertions(+), 66 deletions(-)
>
> Can we look at using fsl_pci_init_port()?
Sure.
>
> See my recent patches for p2020/mpc8572ds/mpc8536ds
What did you have in mind - me creating a similar patch
like the above to layer on what I've got now, or is there
a preference for me to munge the same change into the
existing 5/8 PCI update patch? I guess the former gives
an extra bisection point...
P.
>
> - k
next prev parent reply other threads:[~2009-09-19 16:05 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-18 23:08 [U-Boot] [PATCH 0/8] Update/enhance sbc8548 support Paul Gortmaker
2009-09-18 23:08 ` [U-Boot] [PATCH 1/8] sbc8548: delete unused MPC8548CDS info carried over from port Paul Gortmaker
2009-09-18 23:08 ` [U-Boot] [PATCH 2/8] sbc8548: get_clock_freq is not valid for this board Paul Gortmaker
2009-09-18 23:08 ` [U-Boot] [PATCH 3/8] sbc8548: enable access to second bank of flash Paul Gortmaker
2009-09-18 23:08 ` [U-Boot] [PATCH 4/8] sbc8548: correct local bus SDRAM size from 64M to 128M Paul Gortmaker
2009-09-18 23:08 ` [U-Boot] [PATCH 5/8] sbc8548: update PCI/PCI-e support code Paul Gortmaker
2009-09-18 23:08 ` [U-Boot] [PATCH 6/8] sbc8548: enable use of PCI network cards Paul Gortmaker
2009-09-18 23:08 ` [U-Boot] [PATCH 7/8] sbc8548: allow enabling PCI via a make config option Paul Gortmaker
2009-09-18 23:08 ` [U-Boot] [PATCH 8/8] sbc8548: replace README with completely new document Paul Gortmaker
2009-09-19 17:11 ` Kumar Gala
2009-09-19 16:50 ` [U-Boot] [PATCH 7/8] sbc8548: allow enabling PCI via a make config option Kumar Gala
2009-09-19 17:11 ` [U-Boot] [PATCH 6/8] sbc8548: enable use of PCI network cards Kumar Gala
2009-09-23 20:13 ` [U-Boot] [PATCH 5/8] sbc8548: update PCI/PCI-e support code Wolfgang Denk
2009-09-23 20:22 ` Paul Gortmaker
2009-09-19 16:55 ` [U-Boot] [PATCH 4/8] sbc8548: correct local bus SDRAM size from 64M to 128M Kumar Gala
2009-09-23 20:10 ` Wolfgang Denk
2009-09-23 20:10 ` Wolfgang Denk
2009-09-19 17:11 ` [U-Boot] [PATCH 3/8] sbc8548: enable access to second bank of flash Kumar Gala
2009-09-23 20:08 ` Wolfgang Denk
2009-09-23 20:15 ` Paul Gortmaker
2009-09-23 20:48 ` Wolfgang Denk
2009-09-23 22:28 ` Paul Gortmaker
2009-09-23 20:07 ` Wolfgang Denk
2009-09-19 17:11 ` [U-Boot] [PATCH 2/8] sbc8548: get_clock_freq is not valid for this board Kumar Gala
2009-09-19 4:25 ` [U-Boot] [PATCH 1/8] sbc8548: delete unused MPC8548CDS info carried over from port Kumar Gala
2009-09-19 16:05 ` Paul Gortmaker [this message]
2009-09-19 16:34 ` Kumar Gala
2009-09-19 17:11 ` Kumar Gala
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=4AB5014D.4030009@windriver.com \
--to=paul.gortmaker@windriver.com \
--cc=u-boot@lists.denx.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.