Support for Hydra i2c

Support for Hydra i2c

[Geert Uytterhoeven]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2098 bytes --]

	Hi,

The attached patch adds support for the i2c interface on the Apple `Hydra' Mac
I/O, found on CHRP PPC motherboards. The patch is relative to the anon CVS
version of yesterday evening.

Changed files:

  - CHANGES
  - CONTRIBUTORS
  - doc/modules
  - kernel/busses/Module.mk
  - prog/detect/sensors-detect
  - doc/busses/i2c-hydra
  - kernel/busses/i2c-hydra.c

      o add i2c-hydra

  - doc/developers/design
  - i2c/algo-bit.h

      o fix some typos

  - i2c/bit-lp.c
  - kernel/smbus.c

      o fix compile problems

  - i2c/i2c.h

      o add i2c-hydra
      o fix some typos

  - prog/dump/isadump.c

      o glibc 2.1 doesn't have <sys/perm.h>
      o make it compile on PPC (ISA I/O is memory mapped, but it doesn't work
	anyway because different types of PPC boxes have ISA I/O space at
	different addresses :-(
      o fix a typo (datareg -> addrreg)

The only things on my i2c bus are 2 SPD EEPROMS. I attached the output of the
decode-dimms Perl script. It looks a bit weird though. I have 2 64 MB 100 MHz
SDRAM DIMMs. Probably they aren't PC-100 compliant, though. Each DIMM has 32 16
Mbit (4Mx4) 2-bank 10 ns SDRAM chips. The memory controller in the VLSI
VAS96011/12 `Golden Gate II' chipset (a 1996 design?) on my CHRP LongTrail
motherboard supports 2-bank SDRAM only, and not the newer 4-bank type that's
commonly used in PCs these days (I once read some Intel chipsets don't work
well with 2-bank SDRAM, hence it's _very_ difficult to find 2-bank SDRAM).

You can find out more about my LongTrail motherboard at

    http://www.cs.kuleuven.ac.be/~geert/PowerPC/

My experiences with various types of SDRAM, including links to useful documents
about the bank-issues, are at

    http://www.cs.kuleuven.ac.be/~geert/PowerPC/Motherboard.html

Greetings,

						Geert

P.S. For the other PPC developers: check out http://www.netroedge.com/~lm78/.
--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium

[-- Attachment #2: Type: TEXT/PLAIN, Size: 12353 bytes --]

Index: CHANGES
===================================================================
RCS file: /home/cvs/lm_sensors2/CHANGES,v
retrieving revision 1.10
diff -u -r1.10 CHANGES
--- CHANGES	1999/04/22 16:37:15	1.10
+++ CHANGES	1999/04/27 22:19:53
@@ -29,6 +29,10 @@
 2.2.2 (199903??)
   Just some minor updates and bug fixes.
 
+XXXX (19990427)
+  Module i2c-hydra: NEW
+  Now compiles on PPC
+
 2.2.1 (19990218)
   All: Removed compile warnings
   Module i2c-dev: Small bug removed if DEBUG=1 was used
Index: CONTRIBUTORS
===================================================================
RCS file: /home/cvs/lm_sensors2/CONTRIBUTORS,v
retrieving revision 1.8
diff -u -r1.8 CONTRIBUTORS
--- CONTRIBUTORS	1999/04/11 16:17:48	1.8
+++ CONTRIBUTORS	1999/04/27 22:19:53
@@ -24,6 +24,8 @@
   Author of the i2c-via and sis5595 drivers.
 * Mark D. Studebaker <mds@eng.paradyne.com>
   Author of the i2c-ali15x3 driver, as well as other drivers.
+* Geert Uytterhoeven <geert@linux-m68k.org>
+  Author of the i2c-hydra driver.
 * Adrian Baugh <adrian.baugh@keble.ox.ac.uk>
   Author of wmsensors (get it at http://users.ox.ac.uk/~kebl0850/wmlm78);
   he also tested lots of things, and helped us out on several occasions.
Index: doc/modules
===================================================================
RCS file: /home/cvs/lm_sensors2/doc/modules,v
retrieving revision 1.11
diff -u -r1.11 modules
--- doc/modules	1999/04/22 13:06:24	1.11
+++ doc/modules	1999/04/27 22:19:54
@@ -67,6 +67,9 @@
   SMBus emulation on i2c busses. Base algorithm, on which SMBus-only adapters
   rely.
 
+(src/busses) i2c-hydra: algo-bit i2c-core
+  Apple Hydra Mac I/O bus access on CHRP motherboards.
+
 (src/busses) i2c-isa: i2c-core
   Defines the ISA bus as being a I2C adapter. It isn't, of course; but this is
   often used by sensor client modules, to keep the code small and simple.
Index: doc/developers/design
===================================================================
RCS file: /home/cvs/lm_sensors2/doc/developers/design,v
retrieving revision 1.3
diff -u -r1.3 design
--- doc/developers/design	1999/04/22 14:35:23	1.3
+++ doc/developers/design	1999/04/27 22:19:56
@@ -183,7 +183,7 @@
 ============
 
 This is Simon Vogl's i2c module (this one is different from the i2c module
-included in kernels around 1.2.120!). 
+included in kernels around 2.1.120!). 
 
 A driver
 --------
Index: i2c/algo-bit.h
===================================================================
RCS file: /home/cvs/lm_sensors2/i2c/algo-bit.h,v
retrieving revision 1.2
diff -u -r1.2 algo-bit.h
--- i2c/algo-bit.h	1999/04/14 18:25:57	1.2
+++ i2c/algo-bit.h	1999/04/27 22:19:56
@@ -11,7 +11,7 @@
 struct bit_adapter {
         char name[32];		/* give it a nice name 			*/
 	unsigned int id;	/* not used yet, maybe later		*/
-	void *data;		/* private data for lolevel routines	*/
+	void *data;		/* private data for lowlevel routines	*/
 	void (*setsda) (void *data, int state);
 	void (*setscl) (void *data, int state);
 	int  (*getsda) (void *data);
Index: i2c/bit-lp.c
===================================================================
RCS file: /home/cvs/lm_sensors2/i2c/bit-lp.c,v
retrieving revision 1.6
diff -u -r1.6 bit-lp.c
--- i2c/bit-lp.c	1999/03/28 14:49:54	1.6
+++ i2c/bit-lp.c	1999/04/27 22:19:56
@@ -24,6 +24,7 @@
 #include <linux/ioport.h>
 #include <linux/module.h>
 #include <asm/io.h>
+#include <stddef.h>
 
 #include "i2c.h"
 #include "algo-bit.h"
Index: i2c/i2c.h
===================================================================
RCS file: /home/cvs/lm_sensors2/i2c/i2c.h,v
retrieving revision 1.6
diff -u -r1.6 i2c.h
--- i2c/i2c.h	1999/04/18 19:59:57	1.6
+++ i2c/i2c.h	1999/04/27 22:19:56
@@ -339,11 +339,12 @@
 #define HW_B_BT848	0x05	/* BT848 video boards			*/
 #define HW_B_WNV	0x06	/* Winnov Videums			*/
 #define HW_B_VIA        0x07    /* Via vt82c586b			*/
+#define HW_B_HYDRA      0x08    /* Apple Hydra Mac I/O			*/
 
 /* --- PCF 8584 based algorithms					*/
 #define HW_P_LP		0x00	/* Parallel port interface		*/
-#define HW_P_ISA	0x01	/* generic ISA Bus inteface card	*/
-#define HW_P_ELEK	0x02	/* Elektor ISA Bus inteface card	*/
+#define HW_P_ISA	0x01	/* generic ISA Bus interface card	*/
+#define HW_P_ELEK	0x02	/* Elektor ISA Bus interface card	*/
 
 
 
Index: kernel/smbus.c
===================================================================
RCS file: /home/cvs/lm_sensors2/kernel/smbus.c,v
retrieving revision 1.18
diff -u -r1.18 smbus.c
--- kernel/smbus.c	1999/04/16 16:19:26	1.18
+++ kernel/smbus.c	1999/04/27 22:19:56
@@ -21,6 +21,7 @@
 #include <linux/module.h>
 #include <linux/kernel.h>
 #include <linux/stddef.h>
+#include <asm/system.h>
 
 #include "i2c.h"
 #ifdef I2C_SPINLOCK
Index: kernel/busses/Module.mk
===================================================================
RCS file: /home/cvs/lm_sensors2/kernel/busses/Module.mk,v
retrieving revision 1.6
diff -u -r1.6 Module.mk
--- kernel/busses/Module.mk	1999/02/10 04:33:01	1.6
+++ kernel/busses/Module.mk	1999/04/27 22:19:56
@@ -23,7 +23,8 @@
 # Regrettably, even 'simply expanded variables' will not put their currently
 # defined value verbatim into the command-list of rules...
 KERNELBUSSESTARGETS := $(MODULE_DIR)/i2c-piix4.o $(MODULE_DIR)/i2c-isa.o \
-		       $(MODULE_DIR)/i2c-via.o $(MODULE_DIR)/i2c-ali15x3.o
+		       $(MODULE_DIR)/i2c-via.o $(MODULE_DIR)/i2c-ali15x3.o \
+		       $(MODULE_DIR)/i2c-hydra.o
 
 KERNELBUSSESOLD := bit-via.o bit-mb.o isa.o piix4.o
 
Index: prog/detect/sensors-detect
===================================================================
RCS file: /home/cvs/lm_sensors2/prog/detect/sensors-detect,v
retrieving revision 1.62
diff -u -r1.62 sensors-detect
--- prog/detect/sensors-detect	1999/04/22 13:08:59	1.62
+++ prog/detect/sensors-detect	1999/04/27 22:19:57
@@ -77,6 +77,14 @@
        procid => "Acer Labs M7101",
        driver => "i2c-ali15x3",
        match => sub { $_[0] =~ /^SMBus ALI15X3 adapter at [0-9,a-f]{4}/ },
+     } , 
+     { 
+       vendid => 0x106b,
+       devid  => 0x000e,
+       func => 0,
+       procid => "Apple Computer Inc. Hydra Mac I/O",
+       driver => "i2c-hydra",
+       match => sub { $_[0] =~ /^Hydra i2c/ },
      }
 );
 
Index: prog/dump/isadump.c
===================================================================
RCS file: /home/cvs/lm_sensors2/prog/dump/isadump.c,v
retrieving revision 1.2
diff -u -r1.2 isadump.c
--- prog/dump/isadump.c	1999/01/14 00:41:44	1.2
+++ prog/dump/isadump.c	1999/04/27 22:19:57
@@ -23,10 +23,14 @@
 #include <asm/io.h>
 
 /* To keep glibc2 happy */
-#ifdef __GLIBC__
+#if defined(__GLIBC__) && __GLIBC__ == 2 && __GLIBC_MINOR__ == 0
 #include <sys/perm.h>
 #endif
 
+#ifdef __powerpc__
+unsigned long isa_io_base = 0;	/* XXX for now */
+#endif /* __powerpc__ */
+
 char hexchar(int i)
 {
   if ((i >= 0) && (i <= 9))
@@ -93,7 +97,8 @@
   fprintf(stderr,"  You have five seconds to reconsider and press CTRL-C!\n\n");
   sleep(5);
 
-  if ((datareg < 0x400) && (datareg < 0x400)) {
+#ifndef __powerpc__
+  if ((datareg < 0x400) && (addrreg < 0x400)) {
     if(ioperm(datareg,1,1)) {
       fprintf(stderr,"Error: Could not ioperm() data register!\n");
       exit(1);
@@ -108,6 +113,7 @@
       exit(1);
     }
   }
+#endif /* !__powerpc__ */
 
   printf("     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f\n");
   for (i = 0; i < 256; i+=16) {
--- /dev/null	Thu Aug  6 16:24:46 1998
+++ doc/busses/i2c-hydra	Sun Apr 25 21:01:32 1999
@@ -0,0 +1,11 @@
+
+i2c-hydra is an i2c bus driver for CHRP motherboards with the Apple Hydra Mac
+I/O.
+
+Your /proc/pci or lspci listing must show this :
+
+ Unknown class: Apple Hydra (rev 2)
+
+To install this driver, simply do
+  # modprobe i2c-hydra  
+
--- /dev/null	Thu Aug  6 16:24:46 1998
+++ kernel/busses/i2c-hydra.c	Tue Apr 27 22:14:29 1999
@@ -0,0 +1,184 @@
+/*
+    i2c-hydra.c - Part of lm_sensors,  Linux kernel modules
+                  for hardware monitoring
+
+    i2c Support for the Apple `Hydra' Mac I/O
+
+    Copyright (c) 1999 Geert Uytterhoeven <geert@linux-m68k.org>
+
+    Based on i2c Support for Via Technologies 82C586B South Bridge
+    Copyright (c) 1998, 1999 Kyösti Mälkki <kmalkki@cc.hut.fi>
+
+    This program is free software; you can redistribute it and/or modify
+    it under the terms of the GNU General Public License as published by
+    the Free Software Foundation; either version 2 of the License, or
+    (at your option) any later version.
+
+    This program is distributed in the hope that it will be useful,
+    but WITHOUT ANY WARRANTY; without even the implied warranty of
+    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+    GNU General Public License for more details.
+
+    You should have received a copy of the GNU General Public License
+    along with this program; if not, write to the Free Software
+    Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+*/
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/pci.h>
+#include <asm/io.h>
+#include <asm/system.h>
+#include <linux/types.h>
+
+#include "i2c.h"
+#include "algo-bit.h"
+
+/* PCI device */
+#define VENDOR		PCI_VENDOR_ID_APPLE
+#define DEVICE		PCI_DEVICE_ID_APPLE_HYDRA
+
+#define HYDRA_CACHE_PD	0x00000030
+
+#define HYDRA_CPD_PD0	0x00000001	/* CachePD lines */
+#define HYDRA_CPD_PD1	0x00000002
+#define HYDRA_CPD_PD2	0x00000004
+#define HYDRA_CPD_PD3	0x00000008
+
+#define HYDRA_SCLK	HYDRA_CPD_PD0
+#define HYDRA_SDAT	HYDRA_CPD_PD1
+#define HYDRA_SCLK_OE	0x00000010
+#define HYDRA_SDAT_OE	0x00000020
+
+static unsigned long hydra_base;
+
+static inline void pdregw(u32 val)
+{
+	writel(val, hydra_base+HYDRA_CACHE_PD);
+}
+
+static inline u32 pdregr(void)
+{
+	u32 val = readl(hydra_base+HYDRA_CACHE_PD);
+	return val;
+}
+
+static void bit_hydra_setscl(void *data, int state)
+{
+    u32 val = pdregr();
+    if (state)
+	val &= ~ HYDRA_SCLK_OE;
+    else {
+	val &= ~HYDRA_SCLK;
+	val |= HYDRA_SCLK_OE;
+    }
+    pdregw(val);
+}
+
+static void bit_hydra_setsda(void *data, int state)
+{
+    u32 val = pdregr();
+    if (state)
+	val &= ~ HYDRA_SDAT_OE;
+    else {
+	val &= ~HYDRA_SDAT;
+	val |= HYDRA_SDAT_OE;
+    }
+    pdregw(val);
+}
+
+static int bit_hydra_getscl(void *data)
+{
+	return (pdregr() & HYDRA_SCLK) != 0;
+}
+
+static int bit_hydra_getsda(void *data)
+{
+	return (pdregr() & HYDRA_SDAT) != 0;
+}
+
+static int bit_hydra_reg(struct i2c_client *client)
+{
+	MOD_INC_USE_COUNT;
+	return 0;
+}
+
+static int bit_hydra_unreg(struct i2c_client *client)
+{
+	MOD_DEC_USE_COUNT;
+	return 0;
+}
+
+
+/* ------------------------------------------------------------------------ */
+
+struct bit_adapter bit_hydra_ops = {
+	"Hydra i2c",
+	HW_B_HYDRA,
+	NULL,
+	bit_hydra_setsda,
+	bit_hydra_setscl,
+	bit_hydra_getsda,
+	bit_hydra_getscl,
+	bit_hydra_reg,
+	bit_hydra_unreg,
+	5, 5, 100,	/*waits, timeout */
+};
+
+
+static int find_hydra(void)
+{
+	struct pci_dev *dev;
+
+	if (!pci_present())
+		return -ENODEV;
+		
+	dev = pci_find_device(VENDOR, DEVICE, NULL);
+		
+	if (!dev) {
+		printk("Hydra not found\n");
+		return -ENODEV;
+	}
+
+	hydra_base = (unsigned long)ioremap(dev->base_address[0], 0x100);
+
+	return 0;
+}
+
+int init_i2c_hydra(void)
+{
+	if (find_hydra() < 0) {
+		printk("Error while reading PCI configuration\n");
+		return -ENODEV;
+	}
+
+	pdregw(0);	/* clear SCLK_OE and SDAT_OE */
+
+	if (i2c_bit_add_bus(&bit_hydra_ops) == 0) {
+		printk("Hydra i2c: Module succesfully loaded\n");
+		return 0;
+	} else {
+		iounmap((void *)hydra_base);
+		printk("Hydra i2c: Algo-bit error, couldn't register bus\n");
+		return -ENODEV;
+	}
+}
+
+#ifdef MODULE
+MODULE_AUTHOR("Geert Uytterhoeven <geert@linux-m68k.org>");
+MODULE_DESCRIPTION("i2c for Apple Hydra Mac I/O");
+
+int init_module(void) 
+{
+	return init_i2c_hydra();
+}
+
+void cleanup_module(void) 
+{
+	i2c_bit_del_bus(&bit_hydra_ops);
+	if (hydra_base) {
+		pdregw(0);	/* clear SCLK_OE and SDAT_OE */
+		iounmap((void *)hydra_base);
+	}
+}
+#endif

[-- Attachment #3: Type: TEXT/PLAIN, Size: 6044 bytes --]

PC-100 DIMM Serial Presence Detect Tester/Decoder
Written by Philip Edelbrock.  Copyright 1998, 1999.
Version 0.2


Decoding EEPROM: /proc/sys/dev/sensors/eeprom-i2c-0-51
Guessing DIMM is in bank 2
		----=== The Following is Required Data and is Applicable to all DIMM Types ===----
	# of bytes written to SDRAM EEPROM:		128
	Total number of bytes in EEPROM:		16
	Fundemental Memory type:			???
	Number of Row Address Bits (SDRAM only):	64
	Number of Col Address Bits (SDRAM only):	1/16
	Number of Module Rows:				160
	Data Width (SDRAM only):			Undefined!
	Module Interface Signal Levels:			5.0 Volt/TTL
	Cycle Time (SDRAM):				9.5ns
	Access Time (SDRAM):				0.7ns
	Module Configuration Type:			Parity
	Refresh Type:					Not Self Refreshing
	Refresh Rate:					Undefined!	Primary SDRAM Component Bank Config:		Bank2 = 2 x Bank1
	Primary SDRAM Component Widths:			81
	Error Checking SDRAM Component Bank Config:	Bank2 = 2 x Bank1
	Error Checking SDRAM Component Widths:		1
	Min Clock Delay for Back to Back Random Access:	88
		----=== The Following Apply to SDRAM DIMMs ONLY ===----
	Burst lengths supported:			Burst Length = 4
							Undefined! (bit 4)
	Number of Device Banks:				50
	Supported CAS Latencies:			(None Supported)
	Supported CS Latencies:				(None Supported)
	Supported WE Latencies:				(None Supported)
	SDRAM Module Attributes:			(None Reported)
	SDRAM Device Attributes (General):		Lower VCC Tolerance:10%
							Upper VCC Tolerance:10%
	SDRAM Cycle Time (2ns highest CAS):		Undefined!
	SDRAM Access from Clock Time (2nd highest CAS):	Undefined!
		----=== The Following are Optional (may be Bogus) ===----
	SDRAM Cycle Time (3rd highest CAS):		Undefined!
	SDRAM Access from Clock Time (3rd highest CAS):	Undefined!
		----=== The Following are Required (for SDRAMs) ===----
	Minumum Row Precharge Time:			Undefined!
	Row Active to Row Active Min:			Undefined!
	RAS to CAS Delay:				Undefined!
	Min RAS Pulse Width:				Undefined!
		----=== The Following are Required and Apply to ALL DIMMs ===----
	Row Densities:					(Undefined! -- None Reported!)
		----=== The Following are Proposed and Apply to SDRAM DIMMs ===----
	Command and Address Signal Setup Time:		0nS
	Command and Address Signal Hold Time:		0nS
	Data Signal Setup Time:				0nS
	Data Signal Hold Time:				0nS
	SPD Revision code:				255
	EEPROM Checksum of bytes 0-62:			0xFF (verses calculated: 0x77)
	Manufacturer's JEDEC ID Code:			0x00FF00FF00FF00FF00FF00FF00FF00FF
	Manufacturing Location Code:			0x00FF
	Manufacurer's Part Number:			"^?^?^?^?^?^?^F^?^?^?^?^?^?^?^?^?^?
	Revision Code:					0x00FF00FF
	Manufacturing Date:				0x00FF00FF
	Assembly Serial Number:				0x00FF00FF00FF00FF
	Intel Specification for Frequency:		Undefined!
	Intel Spec Details for 100MHz Support:		Intel Concurrent AutoPrecharge
							CAS Latency = 2
							CAS Latency = 3
							Junction Temp A (90 degrees C)
							CLK 3 Connected
							CLK 2 Connected
							CLK 1 Connected
							CLK 0 Connected
							Double Sided DIMM

Decoding EEPROM: /proc/sys/dev/sensors/eeprom-i2c-0-52
Guessing DIMM is in bank 3
		----=== The Following is Required Data and is Applicable to all DIMM Types ===----
	# of bytes written to SDRAM EEPROM:		128
	Total number of bytes in EEPROM:		16
	Fundemental Memory type:			???
	Number of Row Address Bits (SDRAM only):	64
	Number of Col Address Bits (SDRAM only):	1/16
	Number of Module Rows:				160
	Data Width (SDRAM only):			Undefined!
	Module Interface Signal Levels:			5.0 Volt/TTL
	Cycle Time (SDRAM):				9.5ns
	Access Time (SDRAM):				0.7ns
	Module Configuration Type:			Parity
	Refresh Type:					Not Self Refreshing
	Refresh Rate:					Undefined!	Primary SDRAM Component Bank Config:		Bank2 = 2 x Bank1
	Primary SDRAM Component Widths:			81
	Error Checking SDRAM Component Bank Config:	Bank2 = 2 x Bank1
	Error Checking SDRAM Component Widths:		1
	Min Clock Delay for Back to Back Random Access:	88
		----=== The Following Apply to SDRAM DIMMs ONLY ===----
	Burst lengths supported:			Burst Length = 4
							Undefined! (bit 4)
	Number of Device Banks:				50
	Supported CAS Latencies:			(None Supported)
	Supported CS Latencies:				(None Supported)
	Supported WE Latencies:				(None Supported)
	SDRAM Module Attributes:			(None Reported)
	SDRAM Device Attributes (General):		Lower VCC Tolerance:10%
							Upper VCC Tolerance:10%
	SDRAM Cycle Time (2ns highest CAS):		Undefined!
	SDRAM Access from Clock Time (2nd highest CAS):	Undefined!
		----=== The Following are Optional (may be Bogus) ===----
	SDRAM Cycle Time (3rd highest CAS):		Undefined!
	SDRAM Access from Clock Time (3rd highest CAS):	Undefined!
		----=== The Following are Required (for SDRAMs) ===----
	Minumum Row Precharge Time:			Undefined!
	Row Active to Row Active Min:			Undefined!
	RAS to CAS Delay:				Undefined!
	Min RAS Pulse Width:				Undefined!
		----=== The Following are Required and Apply to ALL DIMMs ===----
	Row Densities:					(Undefined! -- None Reported!)
		----=== The Following are Proposed and Apply to SDRAM DIMMs ===----
	Command and Address Signal Setup Time:		0nS
	Command and Address Signal Hold Time:		0nS
	Data Signal Setup Time:				0nS
	Data Signal Hold Time:				0nS
	SPD Revision code:				255
	EEPROM Checksum of bytes 0-62:			0xFF (verses calculated: 0x77)
	Manufacturer's JEDEC ID Code:			0x00FF00FF00FF00FF00FF00FF00FF00FF
	Manufacturing Location Code:			0x00FF
	Manufacurer's Part Number:			"^?^?^?^?^?^?^F^?^?^?^?^?^?^?^?^?^?
	Revision Code:					0x00FF00FF
	Manufacturing Date:				0x00FF00FF
	Assembly Serial Number:				0x00FF00FF00FF00FF
	Intel Specification for Frequency:		Undefined!
	Intel Spec Details for 100MHz Support:		Intel Concurrent AutoPrecharge
							CAS Latency = 2
							CAS Latency = 3
							Junction Temp A (90 degrees C)
							CLK 3 Connected
							CLK 2 Connected
							CLK 1 Connected
							CLK 0 Connected
							Double Sided DIMM


Number of SDRAM DIMMs detected and decoded: 2

Re: Support for Hydra i2c

[Frodo Looijaard]

Geert Uytterhoeven wrote:
> 
> The attached patch adds support for the i2c interface on the Apple `Hydra' Mac
> I/O, found on CHRP PPC motherboards. The patch is relative to the anon CVS
> version of yesterday evening.

Congratulations! You are the first to add support for a non-Intel 
architecture. I am very excited by your contribution! To be honest, I did
not even know the PPC architecture had an I2C interface. Very nice indeed!

I will merge your code in later today, and if necessary I will send you some
feedback on it. You may want CVS write access; it will make maintaining 
everything a lot easier for all of us. Phil is the one who needs to make 
an account for you; he also manages the mailing list, which might be 
interesting to you too. Phil, can you contact Geert for this?
 
>   - prog/dump/isadump.c
> 
>       o glibc 2.1 doesn't have <sys/perm.h>
>       o make it compile on PPC (ISA I/O is memory mapped, but it doesn't work
> 	anyway because different types of PPC boxes have ISA I/O space at
> 	different addresses :-(
>       o fix a typo (datareg -> addrreg)

This was a very Intel-centered program :=). On Intel PCs, we often have
some hardware sensors attached to the ISA bus. We will have to find out
whether this is the case with PPCs too.
 
> The only things on my i2c bus are 2 SPD EEPROMS. I attached the output of the
> decode-dimms Perl script. It looks a bit weird though. 

Again, you need to talk to Phil. He wrote the EEPROM decode routines.

I am very curious whether anybody on the PPC has hardware monitoring sensors
attached. People, the sensors-detect script should work for you, but don't
try to do the ISA probing (you are asked whether you want it or not).

Good luck,
  Frodo

-- 
Frodo Looijaard <frodol@dds.nl>  PGP key and more: http://huizen.dds.nl/~frodol
  At my homepage you will also find a guide for installing glibc under Linux.
  New: Linux hardware monitoring kernel modules (LM78/79/80, Winbond etc.)
  

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: Support for Hydra i2c

[Benjamin Herrenschmidt]

On Wed, Apr 28, 1999, Frodo Looijaard <frodol@dds.nl> wrote:

>This was a very Intel-centered program :=). On Intel PCs, we often have
>some hardware sensors attached to the ISA bus. We will have to find out
>whether this is the case with PPCs too.

On non-CHRP PowerMacs, there is at least one I2C bus (maybe more) driven
by Cuda. It's used for things like planB video input, and maybe some more
stuffs. Unfortunately, I think we only know how to write to the i2c bus.
More hacking needed before we can implement this one too.
 

-- 
           Perso. e-mail: <mailto:bh40@calva.net>
           Work   e-mail: <mailto:benh@misys.com>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>




[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: Support for Hydra i2c

[Gabriel Paubert]

	Hi Geert,


>   - prog/dump/isadump.c
> 
>       o glibc 2.1 doesn't have <sys/perm.h>
>       o make it compile on PPC (ISA I/O is memory mapped, but it doesn't work
> 	anyway because different types of PPC boxes have ISA I/O space at
> 	different addresses :-(

And why not add an mmap method to /dev/port ? This would be the most
elegant solution and would work on all architectures which use normal
memory accesses to ISA/PCI I/O space, in contrast to InHell which has an
extremely reduced set of instructions to access this space (you can't even
choose the registers you use). 

<rant>
I always thought that the distinction between I/O space and
non-prefetchable memory in PCI is extremely artificial, most PCI devices
have base registers in both spaces which have exactly the same
functionality (and Intel recommends using the MMIO method, which is much
faster on PPro/PII.../P\infinity).
</rant>

	Regards,
	Gabriel.


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: Support for Hydra i2c

[Geert Uytterhoeven]

On Wed, 28 Apr 1999, Frodo Looijaard wrote:
> Geert Uytterhoeven wrote:
> > The attached patch adds support for the i2c interface on the Apple `Hydra' Mac
> > I/O, found on CHRP PPC motherboards. The patch is relative to the anon CVS
> > version of yesterday evening.
> 
> Congratulations! You are the first to add support for a non-Intel 
> architecture. I am very excited by your contribution! To be honest, I did
> not even know the PPC architecture had an I2C interface. Very nice indeed!
> 
> I will merge your code in later today, and if necessary I will send you some
> feedback on it. You may want CVS write access; it will make maintaining 

You seem to have missed these:

Index: doc/modules
===================================================================
RCS file: /home/cvs/lm_sensors2/doc/modules,v
retrieving revision 1.11
diff -u -r1.11 modules
--- doc/modules	1999/04/22 13:06:24	1.11
+++ doc/modules	1999/04/30 09:36:58
@@ -67,6 +67,9 @@
   SMBus emulation on i2c busses. Base algorithm, on which SMBus-only adapters
   rely.
 
+(src/busses) i2c-hydra: algo-bit i2c-core
+  Apple Hydra Mac I/O bus access on CHRP motherboards.
+
 (src/busses) i2c-isa: i2c-core
   Defines the ISA bus as being a I2C adapter. It isn't, of course; but this is
   often used by sensor client modules, to keep the code small and simple.
Index: prog/dump/isadump.c
===================================================================
RCS file: /home/cvs/lm_sensors2/prog/dump/isadump.c,v
retrieving revision 1.3
diff -u -r1.3 isadump.c
--- prog/dump/isadump.c	1999/04/28 18:18:12	1.3
+++ prog/dump/isadump.c	1999/04/30 09:36:59
@@ -99,7 +99,7 @@
   sleep(5);
 
 #ifndef __powerpc__
-  if ((datareg < 0x400) && (datareg < 0x400)) {
+  if ((datareg < 0x400) && (addrreg < 0x400)) {
     if(ioperm(datareg,1,1)) {
       fprintf(stderr,"Error: Could not ioperm() data register!\n");
       exit(1);

The last one is a typo, I assume. BTW, the ISA stuff doesn't work anyway,
because on PPC the macros inb() and outb() rely on isa_io_base pointed to the
mmap()ed ISA IO space. But I don't think that matters much: this was the `quick
fix', just removing isadump from the compile list on PPC seemed to be more
difficult :-)

A datasheet for the Hydra used to be available on the web, cfr.
include/asm-ppc/hydra.h:

 *  This file is based on the following documentation:
 *
 *      Macintosh Technology in the Common Hardware Reference Platform
 *      Apple Computer, Inc.
 *
 *      © Copyright 1995 Apple Computer, Inc. All rights reserved.
 *
 *  It's available online from http://chrp.apple.com/MacTech.pdf.
 *  You can obtain paper copies of this book from computer bookstores or by
 *  writing Morgan Kaufmann Publishers, Inc., 340 Pine Street, Sixth Floor, San
 *  Francisco, CA 94104. Reference ISBN 1-55860-393-X.

but Apple removed the DNS A record for chrp.apple.com :-( Fortunately I still
have the doc on CD.

BTW, doc/busses/i2c-hydra and kernel/busses/i2c-hydra.c contain carriage
returns now.

Greetings,

						Geert

--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: Support for Hydra i2c

[Michel Lanners]

On  28 Apr, this message from Benjamin Herrenschmidt echoed through cyberspace:
[snip]
> On non-CHRP PowerMacs, there is at least one I2C bus (maybe more) driven
> by Cuda. It's used for things like planB video input,

Not that it matters much, but for correctness: the Apple planb ASIC
includes its own I2C bus interface, controlling the I2C bus on which
the video decoder chip is connected.

By the way, this I2C interface is quite simple: write a (sub)address,
write a value, and off it goes. However, it seems to be hardcoded to
access only the SAA7196 video decoder, and reading that chip is done
with a different interface.

Which gives me another thought, completely unrelated to the subject of
this mail: I'm wondering whether the video output chips in the 8x00
also have I2C, and if yes, how they are accessed...

> and maybe some more stuffs.

The only device on this I2C bus in the PCI Macs that I know off is the
RADACAL RAMDAC/CLUT (used at least with the control chip), which gets
its timebase factors via I2C.

> Unfortunately, I think we only know how to write to the i2c bus.

Yes.

> More hacking needed before we can implement this one too.

One problem might be that there is as yet no readable device on the bus
;-).

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: Support for Hydra i2c

[Geert Uytterhoeven]

On Fri, 30 Apr 1999, Michel Lanners wrote:
> On  28 Apr, this message from Benjamin Herrenschmidt echoed through cyberspace:
> [snip]
> > On non-CHRP PowerMacs, there is at least one I2C bus (maybe more) driven
> > by Cuda. It's used for things like planB video input,
> 
> Not that it matters much, but for correctness: the Apple planb ASIC
> includes its own I2C bus interface, controlling the I2C bus on which
> the video decoder chip is connected.
> 
> By the way, this I2C interface is quite simple: write a (sub)address,
> write a value, and off it goes. However, it seems to be hardcoded to
> access only the SAA7196 video decoder, and reading that chip is done
> with a different interface.
> 
> Which gives me another thought, completely unrelated to the subject of
> this mail: I'm wondering whether the video output chips in the 8x00
> also have I2C, and if yes, how they are accessed...
> 
> > and maybe some more stuffs.
> 
> The only device on this I2C bus in the PCI Macs that I know off is the
> RADACAL RAMDAC/CLUT (used at least with the control chip), which gets
> its timebase factors via I2C.
> 
> > Unfortunately, I think we only know how to write to the i2c bus.
> 
> Yes.
> 
> > More hacking needed before we can implement this one too.
> 
> One problem might be that there is as yet no readable device on the bus
> ;-).

Really? Since i2c devices need to identify on the bus, you must be able to read
something from them.

Are there OF methods for the i2c bus on those Macs? My CHRP box has them under
/pci/mac-io@2/misc@0/iic/.

Greetings,

						Geert

--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: Support for Hydra i2c

[Michel Lanners]

Hi all,

On  10 May, this message from Geert Uytterhoeven echoed through cyberspace:
[snip]
>> > and maybe some more stuffs.
>> 
>> The only device on this I2C bus in the PCI Macs that I know off is the
>> RADACAL RAMDAC/CLUT (used at least with the control chip), which gets
>> its timebase factors via I2C.
>> 
>> > Unfortunately, I think we only know how to write to the i2c bus.
>> 
>> Yes.

On the other hand, you I2C gurus mihgt know that, but the R/W bit on the
I2C bus is actually the lsb of the address; i.e address a device with
an even address, and it expects to recive some data; address it with an
odd address, and the device will write data to the bus.

>> > More hacking needed before we can implement this one too.
>> 
>> One problem might be that there is as yet no readable device on the bus
>> ;-).
>
> Really? Since i2c devices need to identify on the bus, you must be able to read
> something from them.

I did some experimentation on the cuda I2C bus while searching for the
PlanB I2C device. I scanned a whole range of I2C addresses, both read
and write, but didn't find anything apart from RADACAL.

> Are there OF methods for the i2c bus on those Macs? My CHRP box has them under
> /pci/mac-io@2/misc@0/iic/.

I'll check in OF on the next reboot ;-)

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]