ichwd: add support for TCO watchdog timer in Lewisburg PCH (C620)

[avg]

Summary

The change is based on public documents listed below as well as
Linux changes and the code developed by Kostik.

The documents:

• Intel® C620 Series Chipset Platform Controller Hub Datasheet
• Intel® 100 Series and Intel® C230 Series Chipset Family Platform Controller Hub (PCH) Datasheet - Volume 2 of 2

Interesting Linux commits:

• https://github.com/torvalds/linux/commit/9424693035a57961a8eb09e96aab315a7096535d
• https://github.com/torvalds/linux/commit/2a7a0e9bf7b32e838d873226808ab8a6c00148f7

The peculiarity of the new chipsets is that the watchdog resources are
configured in PCI registers of SMBus controller and Power Management
function as opposed to the LPC bridge.
I took a simplistic approach of querying the resources from the
respective PCI devices. ichwd is still a device on isa bus.
The PCI devices are found by their slot and function defined in the
datasheets as siblings of the upstream LPC bridge.

There are some shortcuts and missing features.

First of all, I have not implemented the functionality required to clear
the no-reboot bit. That would require writing to a special PCI configuration
register of a hidden / invisible PCI device after which the device would
start responding to access to other registers. The no-reboot bit was
not set on my test hardware, so I decided to leave its handling for the
later time.

Also, I did not try to handle the case where the watchdog resources are
not configured by the hardware as well as the case where ACPI defined
operational region conflicts with the watchdog resources. My test
system did not have either of those problem, so, again, I decided to leave
those cases until later.

See this Linux commit for some details of the ACPI problem:
https://github.com/torvalds/linux/commit/a7ae81952cdab56a1277bd2f9ed7284c0f575120

Finally, I have added only the PCI ID found on my test system.
I think that more IDs can be added as the change gets tested.

This change is developed for and is sponsored by Panzura.

Bug report: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222079

Test Plan

Tested on Dell PowerEdge R740.

[avg]

Another note is that the test system has a BIOS option to enable the watchdog support. That option does not seem to affect the hardware configuration in any way, but when it is enabled the firmware generates WDAT (WatchDog Action Table) ACPI table. I see that Linux now has a driver for that table:
https://github.com/torvalds/linux/commits/master/drivers/watchdog/wdat_wdt.c

The specification is here: http://msdn.microsoft.com/en-us/windows/hardware/gg463320.aspx

Perhaps we may want to add such a driver as well.

[mav]

I have no particular objections, just quietly sighing that this area remains so tangled. I haven't investigated the area much recently, but it seems like WDAT-based attach could be cleaner, if it is a widespread standard and does not conflict too badly with existing drivers. Having watchdog drivers enabled in FreeNAS for years we had huge number of complains, caused by random platform specifics, and obtaining some valid configuration directly from platform in face of this table could be priceless.

[avg]

In D17585#375321, @mav wrote:

I have no particular objections, just quietly sighing that this area remains so tangled. I haven't investigated the area much recently, but it seems like WDAT-based attach could be cleaner, if it is a widespread standard and does not conflict too badly with existing drivers. Having watchdog drivers enabled in FreeNAS for years we had huge number of complains, caused by random platform specifics, and obtaining some valid configuration directly from platform in face of this table could be priceless.

I agree on all points.
My impression is WDAT should be supported on most "server class" hardware that's advertised as supporting Windows Server, because it seems to be a Microsoft's requirement (as well as invention).
Consumer class hardware is probably a different story.