[PATCH] MIPS: update documentation files

From: Ralf Baechle <ralf@linux-mips.org>

The pending changes to the MIPS doc files, more changes needed...

diff --git a/Documentation/mips/pci/pci.README b/Documentation/mips/pci/pci.README
index 52e41bbef4e6366843c089dd6874097ffc23d9fc..8697ee41372d0e5772dc9b03cb8dbd5993971d63 100644 (file)
--- a/Documentation/mips/pci/pci.README
+++ b/Documentation/mips/pci/pci.README
@@ -15,13 +15,6 @@ is doing its own pcibios thing and it has become a big
 mess.  This generic pci code is meant to clean up the mips
 pci mess and make it easier to add pci support to new boards.
 
-arch/mips/kernel/pci_auto.c has the pci bus enumeration code.
-This code scans the pci bus(es) and assigns all of the resources.
-Thus, you don't need the boot code to that, and many boot codes
-don't do it correctly anyway.  To enable the pci_auto code, add
-
-define_bool CONFIG_PCI_AUTO y 
-
 inside the define for your board in arch/mips/config.in. 
 For example, the Galileo EV96100 board  looks like this:
 
@@ -29,7 +22,6 @@ if [ "$CONFIG_MIPS_EV96100" = "y" ]; then
        define_bool CONFIG_PCI y
        define_bool CONFIG_MIPS_GT96100 y
        define_bool CONFIG_NEW_PCI y
-       define_bool CONFIG_PCI_AUTO y
        define_bool CONFIG_SWAP_IO_SPACE y
 fi 
 
@@ -42,11 +34,6 @@ define_bool CONFIG_NEW_PCI y
 inside the define for your board. Again, the EV96100 example above
 show NEW_PCI turned on.
 
-Note that you can enable CONFIG_NEW_PCI code without enabling 
-CONFIG_PCI_AUTO. But you can't do the opposite because the pci_auto
-routines are called from pcibios_init(), which is part of the 
-CONFIG_NEW_PCI code.
-
 
 Now you need to add your files to hook in your pci configuration
 cycles.  Usually you'll need only a couple of files named something

diff --git a/Documentation/mips/time.README b/Documentation/mips/time.README
index 47def411c1fc18f71787c735efddac0d1ec44b6f..70bc0dd43d6d52a93c63bc1e91c84ffeccd2d427 100644 (file)
--- a/Documentation/mips/time.README
+++ b/Documentation/mips/time.README
@@ -103,9 +103,9 @@ Step 1: decide how you like to implement the time services.
      Do you plan to use the CPU counter register as the timer interrupt
      or use an exnternal timer?
 
-     In order to CPU counter register as the timer interrupt source, you must
-     know the counter speed (mips_counter_frequency).  It is usually the
-     same as the CPU speed (Or it is ALWAYS the same?)
+     In order to use CPU counter register as the timer interrupt source, you
+     must know the counter speed (mips_counter_frequency).  It is usually the
+     same as the CPU speed or an integral divisor of it.
 
   d) decide on whether you want to use high-level or low-level timer
      interrupt routines.  The low-level one is presumably faster, but should
@@ -154,8 +154,45 @@ For some tricky cases, you may need to add your own wrapper functions
 for some of the functions in time.c.  
 
 For example, you may define your own timer interrupt routine, which does
-its own processing and in turn calls timer_interrupt().
+some of its own processing and then calls timer_interrupt().
 
 You can also over-ride any of the built-in functions (gettimeoffset,
 RTC routines and/or timer interrupt routine).
 
+
+PORTING NOTES FOR SMP
+----------------------
+
+If you have a SMP box, things are slightly more complicated.
+
+The time service running every jiffy is logically divided into two parts:
+
+  1) the one for the whole system  (defined in timer_interrupt())
+  2) the one that should run for each CPU (defined in local_timer_interrupt())
+
+You need to decide on your timer interrupt sources.
+
+  case 1) - whole system has only one timer interrupt delivered to one CPU
+
+       In this case, you set up timer interrupt as in UP systems.  In addtion,
+       you need to set emulate_local_timer_interrupt to 1 so that other
+       CPUs get to call local_timer_interrupt().
+
+       THIS IS CURRENTLY NOT IMPLEMNETED.  However, it is rather easy to write
+       one should such a need arise.  You simply make a IPI call.
+
+  case 2) - each CPU has a separate timer interrupt
+
+       In this case, you need to set up IRQ such that each of them will
+       call local_timer_interrupt().  In addition, you need to arrange
+       one and only one of them to call timer_interrupt().
+
+       You can also do the low-level version of those interrupt routines,
+       following similar dispatching routes described above.
+
+Note about do_gettimeoffset():
+
+  It is very likely the CPU counter registers are not sync'ed up in a SMP box.
+  Therefore you cannot really use the many of the existing routines that
+  are based on CPU counter.  You should wirte your own gettimeoffset rouinte
+  if you want intra-jiffy resolution.