[LinuxBIOS] [RFC] i82801 generic patch

[Corey Osgood]

The attached patch is a unified version of the current ports of the
i82801 series currently in LinuxBIOS. Since most of the ports are nearly
identical, I've taken for each file and chosen the cleanest or best
version of the code, then checked over the datasheets to *some* of the
series, including the aa, ba, ca, and db, to make sure that it would
work. I've also made some changes here and there, mostly cleanup and
clarification. The only things left to look at are the huge difference
between this version's lpc init and the i82801er's, finding a better way
to select which chip is present on the board, and gpl headers in all
files. Anyways, comments, suggestions, even flames are welcome ;)
Testing on other chips can be done at this point as well, this is tested
and working on one model, the i82801aa.

-Corey

[Corey Osgood]

Corey Osgood wrote:
  Testing on other chips can be done at this point as
well, this is tested
 and working on one model, the i82801aa.
Whoops, forgot to mention, usage is pretty straightforward. In your
mainboard's Options.lb, add

uses I82801_MODEL
uses I82801<yourmodel>

default I82810_MODEL = I82801<yourmodel>

then in the devices section below use "southbridge/intel/i82801xx"
instead of your model's name. Thanks!

-Corey

Quoting Corey Osgood <corey_osgood(a)verizon.net>et>:

  The attached patch is a unified version of the current
ports of the
 i82801 series currently in LinuxBIOS. Since most of the ports are nearly
 identical, I've taken for each file and chosen the cleanest or best
 version of the code, then checked over the datasheets to *some* of the
 series, including the aa, ba, ca, and db, to make sure that it would
 work. I've also made some changes here and there, mostly cleanup and
 clarification. The only things left to look at are the huge difference
 between this version's lpc init and the i82801er's, finding a better way
 to select which chip is present on the board, and gpl headers in all
 files. Anyways, comments, suggestions, even flames are welcome ;)
 Testing on other chips can be done at this point as well, this is tested
 and working on one model, the i82801aa.

 -Corey
Looks great Corey! How soon can this be Acked??

Thanks - Joe

[Uwe Hermann]

On Sun, Jun 03, 2007 at 10:34:26AM -0400, joe(a)smittys.pointclark.net wrote:
  Looks great Corey! How soon can this be Acked??
Pretty soon, I guess. I'm looking over it, but we need to be careful to
not break any existing boards. Also, at the very minimum the proper
license headers have to be added/merged.

A more in-depth review will follow...


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org

[Corey Osgood]

Uwe Hermann wrote:
  On Sun, Jun 03, 2007 at 10:34:26AM -0400,
joe(a)smittys.pointclark.net wrote:
  Looks great Corey! How soon can this be Acked??
 
 Pretty soon, I guess. I'm looking over it, but we need to be careful to
 not break any existing boards.
No boards will be broken, I don't intend to remove the old devices nor
swap over any boards. I'm leaving that for people that actually have
them and can test it to do.

  Also, at the very minimum the proper
 license headers have to be added/merged.
Yeah, working on that right now. Anyone know who svn user magnanisj is?
I think this person worked for Linux Networx or SuSE in late 2005, but I
could be wrong. If they can't be identified, I've got to rewrite a
couple files.

  A more in-depth review will follow...
 
 
 Uwe.
Thanks,
Corey

[LinuxBIOS] [RFC] i82801 generic patch (anyone know magnanisj?)

[Corey Osgood]

Corey Osgood wrote:
  Yeah, working on that right now. Anyone know who svn
user magnanisj is?
 I think this person worked for Linux Networx or SuSE in late 2005, but I
 could be wrong. If they can't be identified, I've got to rewrite a
 couple files.
Hmm, browsing trac a little more seems that magnanisj also checked in
the xe7501devkit as a port of the agami aruma, and the i82801ca was done
for that board
(http://tracker.linuxbios.org/trac/LinuxBIOS/browser/trunk/LinuxBIOSv2/src/m…)
The header in acpi_tables.c says the port was done by Digital Design
Corporation, does that ring any bells for anyone? If not, I'll see if
they can dig up anything, it's the best lead I've come up with so far.

-Corey

[LinuxBIOS] [RFC] i82801 generic patch (anyone know magnanisj?)

[Joseph Smith]

Quoting Corey Osgood <corey.osgood(a)gmail.com>om>:

  Corey Osgood wrote:
  Yeah, working on that right now. Anyone know who
svn user magnanisj is?
 I think this person worked for Linux Networx or SuSE in late 2005, but I
 could be wrong. If they can't be identified, I've got to rewrite a
 couple files.
 Hmm, browsing trac a little more seems that magnanisj also checked in
 the xe7501devkit as a port of the agami aruma, and the i82801ca was done
 for that board

(http://tracker.linuxbios.org/trac/LinuxBIOS/browser/trunk/LinuxBIOSv2/src/m…)
 The header in acpi_tables.c says the port was done by Digital Design
 Corporation, does that ring any bells for anyone? If not, I'll see if
 they can dig up anything, it's the best lead I've come up with so far.

 -Corey

I also says in the header "written by Stefan Reinauer
<stepan(a)openbios.org>"
Is this true Stefan??


Thanks - Joe

[LinuxBIOS] [RFC] i82801 generic patch (anyone know magnanisj?)

[Stefan Reinauer]

* Joseph Smith <joe(a)smittys.pointclark.net> [070604 11:57]:
  The header in
acpi_tables.c says the port was done by Digital Design
 Corporation, does that ring any bells for anyone? If not, I'll see if
 they can dig up anything, it's the best lead I've come up with so far.

 -Corey

 I also says in the header "written by Stefan Reinauer
<stepan(a)openbios.org>"
 Is this true Stefan??
The acpi_tables.c was just adapted by Steven, I originally wrote it for
the Agami Aruma (which is an AMD board). I was not directly involved in
the intel xe7501 port though

Stefan

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: [phone] • Fax: [phone]
Email: info(a)coresystems.de  • http://www.coresystems.de/

[LinuxBIOS] [RFC] i82801 generic patch (anyone know magnanisj?)

[Carl-Daniel Hailfinger]

On 04.06.2007 07:01, Corey Osgood wrote:
  Corey Osgood wrote:
   
  Yeah, working on that right now. Anyone know who
svn user magnanisj is?
 I think this person worked for Linux Networx or SuSE in late 2005, but I
 could be wrong. If they can't be identified, I've got to rewrite a
 couple files.
 Hmm, browsing trac a little more seems that magnanisj also checked in
 the xe7501devkit as a port of the agami aruma, and the i82801ca was done
 for that board

(http://tracker.linuxbios.org/trac/LinuxBIOS/browser/trunk/LinuxBIOSv2/src/m…)
 The header in acpi_tables.c says the port was done by Digital Design
 Corporation, does that ring any bells for anyone? If not, I'll see if
 they can dig up anything, it's the best lead I've come up with so far.
Just in case you are still trying to find out who svn user magnanisj is,
here is the solution:
Steven J. Magnani

Regards,
Carl-Daniel

[Stefan Reinauer]

Corey Osgood wrote:
  The attached patch is a unified version of the current
ports of the
 i82801 series currently in LinuxBIOS. Since most of the ports are nearly
 identical, I've taken for each file and chosen the cleanest or best
 version of the code, then checked over the datasheets to *some* of the
 series, including the aa, ba, ca, and db, to make sure that it would
 work. I've also made some changes here and there, mostly cleanup and
 clarification. The only things left to look at are the huge difference
 between this version's lpc init and the i82801er's, finding a better way
 to select which chip is present on the board, and gpl headers in all
 files. Anyways, comments, suggestions, even flames are welcome ;)
 Testing on other chips can be done at this point as well, this is tested
 and working on one model, the i82801aa.
Some ideas that could simplify the code:
[..]
+#elif 	I82801_MODEL == I82801ER
+#define	I82801_PCI	0x244e
+#define	I82801_LPC	0x24d0
+#define	I82801_IDE	0x24db
+#define	I82801_SATA	0x24df
[..]

You can also add several PCI driver structures in a driver, pointing to
the same PCI ops.

+static struct pci_driver pci_driver __pci_driver = {
+	.ops    = &pci_ops,
+	.vendor = PCI_VENDOR_ID_INTEL,
+	.device = I82801_PCI,
+};

So you could add one of these for each supported component. Since each
pci_driver struct is only 8 bytes, the driver could be made to
completely autodetect which southbridge chip you are using without the
need for any #defines.

The only non-pci_driver use of the _MODEL #define is in
src/southbridge/intel/i82801xx/i82801xx_smbus.h
which is for smbus_write_block() which does not seem to be used, yet.

So my suggestion is to put an unconditional #warning there so that code
can be fixed if it should not work on a given ICH and is ever used.



Forgot to say:
Good work! Really nice!


Stefan

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: [phone] • Fax: [phone]
Email: info(a)coresystems.de  • http://www.coresystems.de/

[Corey Osgood]

Stefan Reinauer wrote:
  Corey Osgood wrote:
   
  The attached patch is a unified version of the
current ports of the
 i82801 series currently in LinuxBIOS. Since most of the ports are nearly
 identical, I've taken for each file and chosen the cleanest or best
 version of the code, then checked over the datasheets to *some* of the
 series, including the aa, ba, ca, and db, to make sure that it would
 work. I've also made some changes here and there, mostly cleanup and
 clarification. The only things left to look at are the huge difference
 between this version's lpc init and the i82801er's, finding a better way
 to select which chip is present on the board, and gpl headers in all
 files. Anyways, comments, suggestions, even flames are welcome ;)
 Testing on other chips can be done at this point as well, this is tested
 and working on one model, the i82801aa.
 Some ideas that could simplify the code:
 [..]
 +#elif 	I82801_MODEL == I82801ER
 +#define	I82801_PCI	0x244e
 +#define	I82801_LPC	0x24d0
 +#define	I82801_IDE	0x24db
 +#define	I82801_SATA	0x24df
 [..]

 You can also add several PCI driver structures in a driver, pointing to
 the same PCI ops.

 +static struct pci_driver pci_driver __pci_driver = {
 +	.ops    = &pci_ops,
 +	.vendor = PCI_VENDOR_ID_INTEL,
 +	.device = I82801_PCI,
 +};

 So you could add one of these for each supported component. Since each
 pci_driver struct is only 8 bytes, the driver could be made to
 completely autodetect which southbridge chip you are using without the
 need for any #defines.
Cool! I didn't even think about that, I'll rework it.
  The only non-pci_driver use of the _MODEL #define is
in
 src/southbridge/intel/i82801xx/i82801xx_smbus.h
 which is for smbus_write_block() which does not seem to be used, yet.

enable_smbus uses it as well, but both could be handled by using a
static device instead of probing. As long as the code is used with an
ICH-series, the smbus is always at the same location.
  So my suggestion is to put an unconditional #warning
there so that code
 can be fixed if it should not work on a given ICH and is ever used.

 Forgot to say:
 Good work! Really nice!
Thanks!

-Corey