1. 27 Jan, 2007 2 commits
  2. 06 Jan, 2007 2 commits
  3. 30 Dec, 2006 2 commits
  4. 20 Dec, 2006 1 commit
  5. 13 Dec, 2006 7 commits
    • Sergei Shtylyov's avatar
      [PATCH] HPT37x: read f_CNT saved by BIOS from port · f13c1526
      Sergei Shtylyov authored
      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: default avatarSergei 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: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      f13c1526
    • Sergei Shtylyov's avatar
      [PATCH] ide: HPT3xx: fix PCI clock detection · 26c068da
      Sergei Shtylyov authored
      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: default avatarSergei 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: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      26c068da
    • Sergei Shtylyov's avatar
      [PATCH] ide: fix the case of multiple HPT3xx chips present · 73d1dd93
      Sergei Shtylyov authored
      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: default avatarSergei 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: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      73d1dd93
    • Sergei Shtylyov's avatar
      [PATCH] ide: fix HPT3xx hotswap support · 33b18a60
      Sergei Shtylyov authored
      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: default avatarSergei 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: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      33b18a60
    • Sergei Shtylyov's avatar
      [PATCH] ide: optimize HPT37x timing tables · 471a0bda
      Sergei Shtylyov authored
      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: default avatarSergei 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: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      471a0bda
    • Sergei Shtylyov's avatar
      [PATCH] ide: fix HPT37x timing tables · 9448732f
      Sergei Shtylyov authored
      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: default avatarSergei 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: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      9448732f
    • Sergei Shtylyov's avatar
      [PATCH] ide: HPT3xxN clocking fixes · 836c0063
      Sergei Shtylyov authored
      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: default avatarSergei 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: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      836c0063
  6. 10 Dec, 2006 2 commits
    • Alan Cox's avatar
      [PATCH] ide-cd: Handle strange interrupt on the Intel ESB2 · ee2f344b
      Alan Cox authored
      The ESB2 appears to emit spurious DMA interrupts when configured for native
      mode and handling ATAPI devices.  Stratus were able to pin this bug down and
      produce a patch.  This is a rework which applies the fixup only to the ESB2
      (for now).  We can apply it to other chips later if the same problem is found.
      
      This code has been tested and confirmed to fix the problem on the tested
      systems.
      Signed-off-by: default avatarAlan Cox <alan@redhat.com>
      (Most of the hard work done by Stratus however)
      Cc: Jens Axboe <axboe@suse.de>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      ee2f344b
    • Sergei Shtylyov's avatar
      [PATCH] pdc202xx_new: fix PLL/timing issues · 47694bb8
      Sergei Shtylyov authored
      Fix the CRC errors in the higher UltraDMA modes with the Promise PDC20268
      and newer chips that always occur on non-x86 machines and when there are
      more than 2 adapters on x86 machines.  Fix the overclocking issue for
      PDC20269 and newer chips that occurs when an UltraDMA/133 capable drive is
      connected.  Here's the summary of changes:
      
      - add code to detect the PLL input clock detection and setup it output clock,
        remove the PowerMac hacks;
      
      - replace the macros accessing the indexed regiters with functions, switch to
        using them where appropriate, gather the PIO/MWDMA/UDMA timings into tables;
      
      - rewrite the speedproc() handler to set the drive's transfer mode first, and
        then override the timing registers set by hardware on UltraDMA/133 chips;
      
      - use better criterion for determining higher UltraDMA modes, and add comment
        concerning the doubtful value of the code enabling IORDY/prefetch;
      
      - replace the stupid 'pdcnew_new_' prefixes with mere 'pdcnew_';
      
      - get rid of unneded spaces, parens and type casts, clean up some printk's,
        add some new lines here and there...
      
      This work is loosely based on these former patches by Albert Lee:
      
      [1] http://marc.theaimsgroup.com/?l=linux-ide&m=110992442032300
      [2] http://marc.theaimsgroup.com/?l=linux-ide&m=110992457729382
      [3] http://marc.theaimsgroup.com/?l=linux-ide&m=110992474205555
      [4] http://marc.theaimsgroup.com/?l=linux-ide&m=111019224802939
      
      Some PLL clock detection code was backported from his pata_pdc2027x driver...
      
      This code has been successfully tested by me on PDC2026[89] chips.
      
      I tried to keep this rework as several patches but it made no sense: [2] was
      largely a modification of the non-working timing override code, [3] by itself
      extended the overclocking issue to the case of non-UltraDMA/133 drives, and
      finally, the cleanup patch based on [1] ended up rejected...
      Signed-off-by: default avatarSergei Shtylyov <sshtylyov@ru.mvista.com>
      Cc: Albert Lee <albertcc@tw.ibm.com>
      Acked-by: default avatarAlan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      47694bb8
  7. 08 Dec, 2006 3 commits
  8. 07 Dec, 2006 1 commit
  9. 25 Nov, 2006 1 commit
  10. 12 Nov, 2006 1 commit
  11. 03 Nov, 2006 1 commit
  12. 30 Oct, 2006 1 commit
  13. 28 Oct, 2006 1 commit
  14. 21 Oct, 2006 1 commit
  15. 17 Oct, 2006 1 commit
    • Brent Casavant's avatar
      [PATCH] ioc4: Enable build on non-SN2 · 59f14800
      Brent Casavant authored
      The SGI PCI-RT card, based on the SGI IOC4 chip, will be made available on
      Altix XE (x86_64) platforms in the near future.  As such it is now a
      misnomer for the IOC4 base device driver to live under drivers/sn, and
      would complicate builds for non-SN2.
      
      This patch moves the IOC4 base driver code from drivers/sn to drivers/misc,
      and updates the associated Makefiles and Kconfig files to allow building on
      non-SN2 configs.  Due to the resulting change in link order, it is now
      necessary to use late_initcall() for IOC4 subdriver initialization.
      
      [akpm@osdl.org: __udivdi3 fix]
      [akpm@osdl.org: fix default in Kconfig]
      Acked-by: default avatarPat Gefre <pfg@sgi.com>
      Acked-by: default avatarJeremy Higdon <jeremy@sgi.com>
      Signed-off-by: default avatarBrent Casavant <bcasavan@sgi.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      59f14800
  16. 11 Oct, 2006 1 commit
  17. 04 Oct, 2006 1 commit
  18. 03 Oct, 2006 8 commits
  19. 01 Oct, 2006 3 commits