linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
* set_cfg_type
@ 2002-08-22  5:31 Paul Mackerras
  2002-08-23  0:04 ` set_cfg_type Matt Porter
  0 siblings, 1 reply; 3+ messages in thread
From: Paul Mackerras @ 2002-08-22  5:31 UTC (permalink / raw)
  To: linuxppc-dev


I see that the indirect_pci methods only do Type 1 configuration
cycles for devices behind PCI-PCI bridges if ppc_md.set_cfg_type is
set.  Are there *any* host bridges for which we *don't* want to do
Type 1 cycles for devices behind PCI-PCI bridges?  If the answer is
no, let's get rid of ppc_md.set_cfg_type and do Type 1 cycles
unconditionally when dev->bus->number != hose->first_busno.

Paul.

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: set_cfg_type
  2002-08-22  5:31 set_cfg_type Paul Mackerras
@ 2002-08-23  0:04 ` Matt Porter
  2002-08-30  4:24   ` set_cfg_type Paul Mackerras
  0 siblings, 1 reply; 3+ messages in thread
From: Matt Porter @ 2002-08-23  0:04 UTC (permalink / raw)
  To: Paul Mackerras; +Cc: linuxppc-dev


On Thu, Aug 22, 2002 at 03:31:42PM +1000, Paul Mackerras wrote:
>
> I see that the indirect_pci methods only do Type 1 configuration
> cycles for devices behind PCI-PCI bridges if ppc_md.set_cfg_type is
> set.  Are there *any* host bridges for which we *don't* want to do
> Type 1 cycles for devices behind PCI-PCI bridges?  If the answer is
> no, let's get rid of ppc_md.set_cfg_type and do Type 1 cycles
> unconditionally when dev->bus->number != hose->first_busno.

Although spec defines the format of type 0 and type 1 transactions,
it doesn't define how the registers the host bridge registers that
generate the transactions behave.  Previously, all the host bridges
we have dealt with have been somewhat intelligent.  That is, they
would note a config transaction addressed for the primary bus and
generate a type 0 transaction.  A non 0 bus number (on a single hose
system) on most host bridge's CFGA generates a type1.  This is ,of
course, slightly different on multi-hose systems.  I've touched
a lot of different host bridges, and the 440GP's PCIX macro cell
was the first that actually used the speced type 1 transation bit
in their CFGA to control generation of type 1 transactions.

I made it an option since we may get undesirable results fiddling
with that bit on other host bridges.  We *could* leave it that
way for safety sake on 2.4 and do it all the time on 2.5 and see
what we break.  Recall that the PCI spec does not define host
bridge operation, so the CFGA could do just about anything by
twiddling that bit.

Regards,
--
Matt Porter
porter@cox.net
This is Linux Country. On a quiet night, you can hear Windows reboot.

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: set_cfg_type
  2002-08-23  0:04 ` set_cfg_type Matt Porter
@ 2002-08-30  4:24   ` Paul Mackerras
  0 siblings, 0 replies; 3+ messages in thread
From: Paul Mackerras @ 2002-08-30  4:24 UTC (permalink / raw)
  To: Matt Porter; +Cc: linuxppc-dev


Matt Porter writes:

> I made it an option since we may get undesirable results fiddling
> with that bit on other host bridges.  We *could* leave it that
> way for safety sake on 2.4 and do it all the time on 2.5 and see
> what we break.  Recall that the PCI spec does not define host
> bridge operation, so the CFGA could do just about anything by
> twiddling that bit.

OK, then let's put the `set_cfg_type' field in the hose structure.  It
doesn't really belong in the ppc_md structure.

Paul.

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2002-08-30  4:24 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-08-22  5:31 set_cfg_type Paul Mackerras
2002-08-23  0:04 ` set_cfg_type Matt Porter
2002-08-30  4:24   ` set_cfg_type Paul Mackerras

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).