Subject: Re: ebsa-285 things

From: Philip Blundell <[email-masked]>
Date: Thu, 28 Jan 1999 13:17:33 +0100

>I don't think that the EBSA285 port should concern itself
>as to the state of the Central function bit in the control
>register, because this port is only meant for the SA110
>running as the central function.  The co285 port is for
>'add-in' cards without the central function bit set.

I don't agree.  Unless you can think of a way in which the change will 
actually harm anything I think it ought to go in regardless.  The situation 
might well arise in which you want a machine similar to the EBSA-285 in every 
respect except that it's not in charge of PCI configuration.  The co285 port, 
as far as I know, changes other things to do with memory mapping that won't 
always be desirable.

In any case, keeping the co285 and EBSA-285 ports as close together as 
possible can only be a good thing.  If a check like this allows them to share 
the hw-ebsa285 code then all the better.

p.

unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Philip Blundell <[email-masked]>
Date: Thu, 28 Jan 1999 18:04:16 +0100

>It is the way that I intend it.  I don't see that you have to
>agree, it's just the way it was meant from the outset.

Is there any particular reason for that?

p.

---

From: Russell King <[email-masked]>
Date: Thu, 28 Jan 1999 17:26:21 +0000 (GMT)

--
Russell King ([email-masked])

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Thu, 28 Jan 1999 19:12:07 +0000 (GMT)

> the hw-ebsa285 code then all the better.

We'll see when the co285 stuff gets pushed into the kernel.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        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: Russell King - ARM Linux Admin <[email-masked]>
Date: Thu, 28 Jan 1999 19:25:12 +0000 (GMT)

> Is there any particular reason for that?

Yes, performance.  The impact of the extra work for handling the
setup of the SDRAM allocated by the CFN CPU would hit all functions
that use the page tables significantly.  In this case, the SDRAM
PCI base should not be modified by the EBSA285.

IMHO, if you're running a machine with the SDRAM located at a fixed
address in PCI space, you don't really want to have the overhead of
loading the PCI offset *twice* for each and every PTE reference.

In summary, I'm surprised that you're trying to push this when you're
trying to remove individual CPU cycles else where in the kernel.  It
sounds to me very contradictory.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        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: Thu, 28 Jan 1999 20:43:40 +0100

>loading the PCI offset *twice* for each and every PTE reference.

I don't see that it's that big a deal.  As far as I can tell, the only place 
we need to care what address our memory is mapped to in PCI space is in 
virt_to_bus and bus_to_virt.  Changing the PCI base address doesn't alter 
either the physical address as seen by the local CPU, or the virtual 
address where the RAM is mapped.  All that changes is how other busmasters see 
the local memory.

Where do the page tables come into it?  I get the feeling perhaps I'm missing 
the point of what you were trying to say.  Can you give a concrete example of 
where the performance hit is taken?

>sounds to me very contradictory.

The actual patch that you were objecting to doesn't add any cycles at all to 
any fast-path code.  If I'm forgetting about something that means that other 
code has to be compile-time conditional on the model in use then so be it, but 
that's a different issue.

p.