Begin the real driver redesign. For the starters:

- cache the offset of the IDE channel's MISC. control registers which are used
   throughout the driver in hwif->select_data;

- only touch the relevant MCR when detecting the cable type on HPT374's
   function 1;

- make HPT36x's speedproc handler look the same way as HPT37x ones; fix the
   PIO timing register mask for HPT37x.

- rename all the HPT3xx register related variables consistently; clean up the
   whitespace.
Signed-off-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

Switch to using pci_get_slot() to get to the function 1 of HPT36x/374 chips --
there's no need for the driver itself to walk the list of the PCI devices, and
it also forgets to check the bus number of the device found.
Signed-off-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

- Rework the driver setup code so that it prefixes the driver startup
  messages with the real chip name.

- Print the measured f_CNT value and the DPLL setting for non-HPT3xx
  chips as well.

- Claim the extra 240 bytes of I/O space for all chips, not only for
  those having PCI device ID of 0x0004.
Signed-off-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

- Rework hpt3xx_ratemask() and hpt3xx_ratefilter() so that the former
  returns the max.  mode computed at the load time and doesn't have to do
  bad Ultra33 drive list lookups anymore; remove the duplicate code from
  the latter function.  Move the quirky drive list lookup into
  hpt3xx_quirkproc() where it should have been from the start...

- Disable UltraATA/100 for HPT370 by default as the 33 MHz ATA clock
  being used does not allow for it, and this *greatly* increases the
  transfer speed.

- Save some space by using byte-wide fields in struct hpt_info; switch to
  reading the 8-bit PCI revision ID reg.  only, not the whole 32-bit reg.

- Start incrementing the driver version number with each patch (should
  have been done from the first one posted).
Signed-off-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

also change __devinit tag for sgiioc4.c:ioc4_ide_init() to __init
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

The undocumented register BIOS uses for saving f_CNT seems to only be
mapped to I/O space while all the other HPT3xx regs are dual-mapped.  Looks
like another HighPoint's dirty trick.  With this patch, the deadly kernel
oops on the cards having the modern HighPoint BIOSes is now at last gone!
Signed-off-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Use the f_CNT value saved by the HighPoint BIOS if available as reading it
directly would give us a wrong PCI frequency after DPLL has already been
calibrated by BIOS.
Signed-off-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

init_chipset_hpt366() modifies some fields of the ide_pci_device_t structure
depending on the chip's revision, so pass it a copy of the structure to avoid
issues when multiple different chips are present.
Signed-off-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Fix the broken hotswap code: on HPT37x it caused RESET- to glitch when
tristating the bus (the MISC control 3/6 and soft control 2 need to be written
to in the certain order), and for HPT36x the obsolete HDIO_TRISTATE_HWIF
ioctl() handler was called instead which treated the state argument wrong.
Also, get rid of the soft control reg.  1 wtite to enable IDE interrupt --
this is done in init_hpt37x() already...

Have been tested on HPT370 and 371N.
Signed-off-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Save some space on the timing tables by introducing the separate transfer mode
table in which the mode lookup is done to get the index into the timing table
itself.  Get rid of the rest of the obsolete/duplicate tables and use one set
of tables for the whole HPT37x chip family like the HighPoint open-source
drivers do.  Documnent the different timing register layout for the HPT36x
chip family (this is my guesswork based on the timing values).

Have been tested and works fine on HPT370/302/371N.
Signed-off-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Fix/remove bad/unused timing tables: HPT370/A 66 MHz tables weren't really
needed (the chips are not UltraATA/133 capable and shouldn't support 66 MHz
PCI) and had many modes over- and underclocked, HPT372 33 MHz table was in
fact for 66 MHz and 50 MHz table missed UltraDMA mode 6, HPT374 33 MHz table
was really for 50 MHz...  (Actually, HPT370/A 33 MHz tables also have issues.
e.g.  HPT370 has PIO modes 0/1 overlocked.)

There's also no need in the separate HPT374 tables because HPT372 timings
should be the same (and those tables has UltraDMA mode 6 which HPT374 supports
depending on HPT374_ALLOW_ATA133_6 #define)...
Signed-off-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Fix serious problems with the HPT372N clock turnaround code:

- the wrong ports were written to when called for the secondary channel;

- it didn't serialize access to the channels;

- turnaround shou;dn't be done on 66 MHz PCI;

- caching the clock mode per-channel caused it to get out of sync with the
  actual register value.

Additionally, avoid calibrating PLL twice (for each channel) as the second try
results in a wrong PCI frequency and thus in the wrong timings.

Make the driver deal with HPT302N and HPT371N correctly -- the clocking and
(seemingly) a need for clock tunaround is the same as for HPT372N.  HPT371/N
chips have only one, secondary channel, so avoid touching their "pure virtual"
primary channel, and disable it if the BIOS haven't done this already.

Also, while at it, disable UltraATA/133 for HPT372 by default -- 50 MHz DPLL
clock don't allow for this speed anyway.  And remove the traces of the former
bad patch that wasn't even applicable to this version of driver.

Has been tested on HPT370/371N, unfortunately I don't have an instant access
to the other chips...
Signed-off-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Signed-off-by: NJörn Engel <joern@wohnheim.fh-wedel.de>
Signed-off-by: NAdrian Bunk <bunk@stusta.de>

I just purchased a HighPoint Rocket 1520 SATA controller.  There seems to
be no libata driver (yet), but there is an ide driver, hpt366.  When the
driver gets loaded, it causes a kernel NULL pointer dereference in
pci_bus_clock_list.  It seems to be because the driver is waiting for clock
stabilization in init_hpt37x() which never comes.  The driver just
continues on with the pci drvdata set to NULL, instead of a valid clock
entry.  The following patch prevents the NULL dereference from happening,
but instead exit with an error.
Acked-by: NBartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Signed-off-by: NDeepak Saxena <dsaxena@plexity.net>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This is one heck of a confused driver.  It uses a byte write to a dword
register to enable a ROM resource that it doesn't even seem to be using.

"Lost and wandering in the desert of confusion"
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

The highpoint driver is unreadable, buggy and crashes on some chipsets.  The
-ac one is more readable (but not ideal) and doesn't crash all over the place.
 Been in Fedora for some time.

Backported from the Fedora one to the old Bartlomiej IDE core.  No other
dependencies.
Signed-off-by: NAlan Cox <alan@redhat.com>
Acked-by: NBartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!