Commit graph

13 commits

Author SHA1 Message Date
Sergei Shtylyov
f13c152684 [PATCH] HPT37x: read f_CNT saved by BIOS from port
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: Sergei 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: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-12-13 09:05:55 -08:00
Sergei Shtylyov
26c068daf0 [PATCH] ide: HPT3xx: fix PCI clock detection
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: Sergei 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: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-12-13 09:05:55 -08:00
Sergei Shtylyov
73d1dd93c4 [PATCH] ide: fix the case of multiple HPT3xx chips present
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: Sergei 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: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-12-13 09:05:55 -08:00
Sergei Shtylyov
33b18a6025 [PATCH] ide: fix HPT3xx hotswap support
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: Sergei 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: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-12-13 09:05:55 -08:00
Sergei Shtylyov
471a0bda5a [PATCH] ide: optimize HPT37x timing tables
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: Sergei 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: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-12-13 09:05:55 -08:00
Sergei Shtylyov
9448732f6c [PATCH] ide: fix HPT37x timing tables
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: Sergei 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: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-12-13 09:05:55 -08:00
Sergei Shtylyov
836c0063c7 [PATCH] ide: HPT3xxN clocking fixes
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: Sergei 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: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-12-13 09:05:55 -08:00
Jörn Engel
6ab3d5624e Remove obsolete #include <linux/config.h>
Signed-off-by: Jörn Engel <joern@wohnheim.fh-wedel.de>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
2006-06-30 19:25:36 +02:00
Loren M. Lang
9ea244b4b5 [PATCH] RocketPoint 1520 [hpt366] fails clock stabilization
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: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-02-03 08:32:12 -08:00
Deepak Saxena
f5e3c2faa2 [PATCH] ide: kmalloc + memset -> kzalloc conversion
Signed-off-by: Deepak Saxena <dsaxena@plexity.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-07 07:54:00 -08:00
Linus Torvalds
9ec4ff421f hpt366: write the full 4 bytes of ROM address, not just low 1 byte
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: Linus Torvalds <torvalds@osdl.org>
2005-09-11 09:22:50 -07:00
Alan Cox
b39b01ffb7 [PATCH] ide: fix the HPT366 driver layer
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: Alan Cox <alan@redhat.com>
Acked-by: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-27 17:36:40 -07:00
Linus Torvalds
1da177e4c3 Linux-2.6.12-rc2
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!
2005-04-16 15:20:36 -07:00