From: Colin Ngam <cngam@sgi.com>
To: Grant Grundler <iod00d@hp.com>
Cc: Patrick Gefre <pfg@sgi.com>, "Luck, Tony" <tony.luck@intel.com>,
Matthew Wilcox <matthew@wil.cx>,
Jesse Barnes <jbarnes@engr.sgi.com>,
linux-kernel@vger.kernel.org, linux-ia64@vger.kernel.org
Subject: Re: [PATCH] 2.6 SGI Altix I/O code reorganization
Date: Wed, 06 Oct 2004 19:09:54 +0000 [thread overview]
Message-ID: <41644301.9EC028B3@sgi.com> (raw)
In-Reply-To: 20041006185739.GA25773@cup.hp.com
Grant Grundler wrote:
> On Wed, Oct 06, 2004 at 10:32:23AM -0500, Patrick Gefre wrote:
> > o added our own pci_ops (Grant/Matthew's request)
>
> Sorry - my bad.
> I confused the issue by claiming one should replace pci_root_ops.
> It was one possibility but it's not an easy path to take.
Hi Grant,
>
>
> Mathew explained replacing the raw_pci_ops pointer is the Right Thing
> and I suspect it's easier to properly implement.
I believe we did just that. We did not touch pci_root_ops.
>
>
> Some comments on the implementation:
> o sn_pci_fixup_bus() is a confusing name. "pcibios_fixup_bus" is normally
> called by generic PCI code after each bus is walked.
> This code obviously doesn't support that.
> Maybe, sn_init_pci_controller() or something like that would be clearer.
That is a good idea and can be done.
>
>
> o This bit of code belongs in the pcibios_fixup_bus() call path:
> + /*
> + * Generic Linux PCI Layer has created the pci_bus and pci_dev
> + * structures - time for us to add our SN PLatform specific
> + * information.
> + */
> +
> + while ((pci_dev > + pci_find_device(PCI_ANY_ID, PCI_ANY_ID, pci_dev)) != NULL) {
> + sn_pci_fixup_slot(pci_dev);
> + }
>
> I realize that's not easy to add/maintain in the arch/ia64 port though
> since pcibios_fixup_bus() is common code for multiple platforms.
Yes, would anybody allow us to make a platform specific callout from within generic
pcibios_fixup_bus()???
>
>
> o sn_pci_fixup_bus() should be called for each PCI root bus controller
> the firmware advertises. The loop in sn_pci_init() is hard coded
> to loop from 0 to 256 busses.
> Is ACPI the only way PCI host controllers are advertised?
That would be my assumption. And ACPI is our next effort.
>
> SN2 doesn't use a different method today?
Correct.
>
>
> It means we are telling PCI subsystem to walk root busses that don't
> exist in all configurations. I hope there are no nasty side effects
> from that.
Not at all. If you look at the loop, sn_pci_fixup_bus(0 gets called for 0 -
PCI_BUSES_TO_SCAN but if the bus does not exist, we do not call pci_scan_bus(),
therefore the PCI subsystem is not called to walk buses that do not exist on SN.
>
>
> o the BUG() in:
>
> + controller = sn_alloc_pci_sysdata();
> + if (!controller) {
> + BUG();
> + }
> is redundant with the BUG in sn_alloc_pci_sysdata().
Thanks. We can fix this.
One favour. Would you agree to letting this patch be included by Tony and we will come
up with another patch to fix the 2 obvious items listed above? It will be great to
avoid spinning this big patch.
Thanks.
colin
>
>
> sorry for the initial bad advice and I hope this helps,
> grant
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Colin Ngam <cngam@sgi.com>
To: Grant Grundler <iod00d@hp.com>
Cc: Patrick Gefre <pfg@sgi.com>, "Luck, Tony" <tony.luck@intel.com>,
Matthew Wilcox <matthew@wil.cx>,
Jesse Barnes <jbarnes@engr.sgi.com>,
linux-kernel@vger.kernel.org, linux-ia64@vger.kernel.org
Subject: Re: [PATCH] 2.6 SGI Altix I/O code reorganization
Date: Wed, 06 Oct 2004 14:09:54 -0500 [thread overview]
Message-ID: <41644301.9EC028B3@sgi.com> (raw)
In-Reply-To: 20041006185739.GA25773@cup.hp.com
Grant Grundler wrote:
> On Wed, Oct 06, 2004 at 10:32:23AM -0500, Patrick Gefre wrote:
> > o added our own pci_ops (Grant/Matthew's request)
>
> Sorry - my bad.
> I confused the issue by claiming one should replace pci_root_ops.
> It was one possibility but it's not an easy path to take.
Hi Grant,
>
>
> Mathew explained replacing the raw_pci_ops pointer is the Right Thing
> and I suspect it's easier to properly implement.
I believe we did just that. We did not touch pci_root_ops.
>
>
> Some comments on the implementation:
> o sn_pci_fixup_bus() is a confusing name. "pcibios_fixup_bus" is normally
> called by generic PCI code after each bus is walked.
> This code obviously doesn't support that.
> Maybe, sn_init_pci_controller() or something like that would be clearer.
That is a good idea and can be done.
>
>
> o This bit of code belongs in the pcibios_fixup_bus() call path:
> + /*
> + * Generic Linux PCI Layer has created the pci_bus and pci_dev
> + * structures - time for us to add our SN PLatform specific
> + * information.
> + */
> +
> + while ((pci_dev =
> + pci_find_device(PCI_ANY_ID, PCI_ANY_ID, pci_dev)) != NULL) {
> + sn_pci_fixup_slot(pci_dev);
> + }
>
> I realize that's not easy to add/maintain in the arch/ia64 port though
> since pcibios_fixup_bus() is common code for multiple platforms.
Yes, would anybody allow us to make a platform specific callout from within generic
pcibios_fixup_bus()???
>
>
> o sn_pci_fixup_bus() should be called for each PCI root bus controller
> the firmware advertises. The loop in sn_pci_init() is hard coded
> to loop from 0 to 256 busses.
> Is ACPI the only way PCI host controllers are advertised?
That would be my assumption. And ACPI is our next effort.
>
> SN2 doesn't use a different method today?
Correct.
>
>
> It means we are telling PCI subsystem to walk root busses that don't
> exist in all configurations. I hope there are no nasty side effects
> from that.
Not at all. If you look at the loop, sn_pci_fixup_bus(0 gets called for 0 -
PCI_BUSES_TO_SCAN but if the bus does not exist, we do not call pci_scan_bus(),
therefore the PCI subsystem is not called to walk buses that do not exist on SN.
>
>
> o the BUG() in:
>
> + controller = sn_alloc_pci_sysdata();
> + if (!controller) {
> + BUG();
> + }
> is redundant with the BUG in sn_alloc_pci_sysdata().
Thanks. We can fix this.
One favour. Would you agree to letting this patch be included by Tony and we will come
up with another patch to fix the 2 obvious items listed above? It will be great to
avoid spinning this big patch.
Thanks.
colin
>
>
> sorry for the initial bad advice and I hope this helps,
> grant
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2004-10-06 19:09 UTC|newest]
Thread overview: 82+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-04 21:57 [PATCH] 2.6 SGI Altix I/O code reorganization Pat Gefre
2004-10-04 21:57 ` Pat Gefre
2004-10-05 5:13 ` Luck, Tony
2004-10-05 5:13 ` Luck, Tony
2004-10-05 15:43 ` Jesse Barnes
2004-10-05 15:43 ` Jesse Barnes
2004-10-05 16:22 ` Grant Grundler
2004-10-05 16:22 ` Grant Grundler
2004-10-05 17:45 ` Matthew Wilcox
2004-10-05 17:45 ` Matthew Wilcox
2004-10-05 19:00 ` Colin Ngam
2004-10-05 19:00 ` Colin Ngam
2004-10-05 19:10 ` Grant Grundler
2004-10-05 19:10 ` Grant Grundler
2004-10-05 19:15 ` Matthew Wilcox
2004-10-05 19:15 ` Matthew Wilcox
2004-10-05 18:20 ` Patrick Gefre
2004-10-05 18:20 ` Patrick Gefre
2004-10-05 18:34 ` Jesse Barnes
2004-10-05 18:34 ` Jesse Barnes
2004-10-05 15:48 ` Christoph Hellwig
2004-10-05 15:48 ` Christoph Hellwig
2004-10-05 18:26 ` Patrick Gefre
2004-10-05 18:26 ` Patrick Gefre
2004-10-05 23:30 ` Patrick Gefre
2004-10-05 23:30 ` Patrick Gefre
2004-10-05 15:50 ` Christoph Hellwig
2004-10-05 15:50 ` Christoph Hellwig
2004-10-05 19:16 ` Luck, Tony
2004-10-05 19:16 ` Luck, Tony
2004-10-05 19:35 ` Patrick Gefre
2004-10-05 19:35 ` Patrick Gefre
2004-10-05 20:34 ` Luck, Tony
2004-10-05 20:34 ` Luck, Tony
2004-10-06 15:32 ` Patrick Gefre
2004-10-06 15:32 ` Patrick Gefre
2004-10-06 18:57 ` Grant Grundler
2004-10-06 18:57 ` Grant Grundler
2004-10-06 19:09 ` Colin Ngam [this message]
2004-10-06 19:09 ` Colin Ngam
2004-10-06 19:54 ` Grant Grundler
2004-10-06 19:54 ` Grant Grundler
2004-10-06 19:54 ` Colin Ngam
2004-10-06 19:54 ` Colin Ngam
2004-10-06 20:10 ` Patrick Gefre
2004-10-06 20:10 ` Patrick Gefre
2004-10-06 20:44 ` Jesse Barnes
2004-10-06 20:44 ` Jesse Barnes
2004-10-07 15:02 ` Patrick Gefre
2004-10-07 15:02 ` Patrick Gefre
2004-10-07 16:52 ` Jesse Barnes
2004-10-07 16:52 ` Jesse Barnes
2004-10-06 20:27 ` Jesse Barnes
2004-10-06 20:27 ` Jesse Barnes
2004-10-06 20:21 ` Colin Ngam
2004-10-06 20:21 ` Colin Ngam
2004-10-06 20:33 ` Matthew Wilcox
2004-10-06 20:33 ` Matthew Wilcox
2004-10-06 20:48 ` Grant Grundler
2004-10-06 20:48 ` Grant Grundler
2004-10-06 21:05 ` Matthew Wilcox
2004-10-06 21:05 ` Matthew Wilcox
2004-10-06 20:55 ` Colin Ngam
2004-10-06 20:55 ` Colin Ngam
2004-10-08 15:16 ` Colin Ngam
2004-10-08 15:16 ` Colin Ngam
2004-10-08 16:37 ` Jesse Barnes
2004-10-08 16:37 ` Jesse Barnes
2004-10-09 22:20 ` Grant Grundler
2004-10-09 22:20 ` Grant Grundler
[not found] ` <4169A508.84FB19C7@sgi.com>
2004-10-11 14:03 ` Patrick Gefre
2004-10-11 14:03 ` Patrick Gefre
2004-10-08 22:37 ` Colin Ngam
2004-10-08 22:37 ` Colin Ngam
2004-10-07 17:06 ` Luck, Tony
2004-10-07 17:06 ` Luck, Tony
2004-10-07 17:22 ` Jesse Barnes
2004-10-07 17:22 ` Jesse Barnes
2004-10-07 18:59 ` Jes Sorensen
2004-10-07 18:59 ` Jes Sorensen
2004-10-11 20:49 ` Luck, Tony
2004-10-11 20:49 ` Luck, Tony
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=41644301.9EC028B3@sgi.com \
--to=cngam@sgi.com \
--cc=iod00d@hp.com \
--cc=jbarnes@engr.sgi.com \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matthew@wil.cx \
--cc=pfg@sgi.com \
--cc=tony.luck@intel.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 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.