Subject: Re: PCI master

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Mon, 23 Nov 1998 21:17:04 +0000 (GMT)

Philip Blundell writes:
> We've now got a lot of constructs like this in the hardware-specific setup 
> code for both EBSA/CATS and VNC:
> 
> +	pci_set_cmd(dev, 0, PCI_COMMAND_MASTER | PCI_COMMAND_MEMORY | PCI_COMMAND_IO);
> 
> For things like the ISA bridge this seems fair enough, but for most 
> peripherals I'd expect that the driver ought to be doing pci_set_master() 
> -- and if it isn't, that's where it ought to get fixed.  Is there any reason 
> why this won't work?

Peripherals also need their IO and memory access bits set correctly.  If you'd
care to read the code, you'll notice that the Netwinder port sets up the PCI
bus completely.  Hence, there is no point in writing to the control register
twice, when you can do it in one go.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |  http://www.arm.linux.org.uk/~rmk/armlinux.html    /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Philip Blundell <[email-masked]>
Date: Mon, 23 Nov 1998 22:39:26 +0100

>twice, when you can do it in one go.

And for the non-Netwinder ports?

p.

---

From: Philip Blundell <[email-masked]>
Date: Tue, 24 Nov 1998 09:35:43 +0100

>care to read the code, you'll notice that the Netwinder port sets up the PCI

Thinking about it more I think this argument is spurious.  The driver should 
probably be responsible for setting the I/O and memory bits as well.

p.

---

From: Alan Cox <[email-masked]>
Date: Tue, 24 Nov 1998 19:47:34 +0000 (GMT)

> probably be responsible for setting the I/O and memory bits as well.

Think about shared PCI busses where some drivers are on each system board.
Linux drivers expect the PCI to be set up in advance 
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Tue, 24 Nov 1998 22:47:17 +0000 (GMT)

> probably be responsible for setting the I/O and memory bits as well.

There appear to be some drivers that take these bits as 'enabled', and will
specifically not initialise if they're not set (eg, all PCI IDE, rz1000, etc).

Hmm, in fact, it looks like most PCI drivers look at the IO and memory enabled
bits, and skip devices that aren't enabled.  Maybe there's a reason...
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |  http://www.arm.linux.org.uk/~rmk/armlinux.html    /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Philip Blundell <[email-masked]>
Date: Wed, 25 Nov 1998 22:04:03 +0100

>specifically not initialise if they're not set (eg, all PCI IDE, rz1000, etc).

Mmm, that's true.  I've never quite understood why that's the case and IMHO 
it's broken -- but regardless of that, the consensus seems to be that as Alan 
says Linux drivers expect PCI to be set up in advance.  Fair enough I guess.

p.

---

From: Alan Cox <[email-masked]>
Date: Thu, 26 Nov 1998 11:31:11 +0000 (GMT)

> >specifically not initialise if they're not set (eg, all PCI IDE, rz1000, etc).

[Think "turned off is bios and the chipset cant disable slots completely"]

> says Linux drivers expect PCI to be set up in advance.  Fair enough I guess.

One reason they need to be set up in advance is that they share resources
with other logical busses that may need to know in advance what resources
they can use - a good example is i2o - the bios tells the i2o controller
what block of address space/i/o space it can have for its devices. 
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]