Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
接近 2 年 前同步成功

通知 170
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 14 12月, 2006 6 次提交
    • S
      [PATCH] ide: HPT3xx: fix PCI clock detection · 26c068da
      由 Sergei Shtylyov 提交于 
      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>
      26c068da
    • S
      [PATCH] ide: fix the case of multiple HPT3xx chips present · 73d1dd93
      由 Sergei Shtylyov 提交于 
      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>
      73d1dd93
    • S
      [PATCH] ide: fix HPT3xx hotswap support · 33b18a60
      由 Sergei Shtylyov 提交于 
      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>
      33b18a60
    • S
      [PATCH] ide: optimize HPT37x timing tables · 471a0bda
      由 Sergei Shtylyov 提交于 
      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>
      471a0bda
    • S
      [PATCH] ide: fix HPT37x timing tables · 9448732f
      由 Sergei Shtylyov 提交于 
      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>
      9448732f
    • S
      [PATCH] ide: HPT3xxN clocking fixes · 836c0063
      由 Sergei Shtylyov 提交于 
      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>
      836c0063
  3. 11 12月, 2006 2 次提交
    • A
      [PATCH] ide-cd: Handle strange interrupt on the Intel ESB2 · ee2f344b
      由 Alan Cox 提交于 
      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: NAlan Cox <alan@redhat.com>
(Most of the hard work done by Stratus however)
Cc: Jens Axboe <axboe@suse.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      ee2f344b
    • S
      [PATCH] pdc202xx_new: fix PLL/timing issues · 47694bb8
      由 Sergei Shtylyov 提交于 
      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: NSergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Albert Lee <albertcc@tw.ibm.com>
Acked-by: NAlan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      47694bb8
  5. 09 12月, 2006 3 次提交
  7. 08 12月, 2006 1 次提交
  9. 26 11月, 2006 1 次提交
  11. 13 11月, 2006 1 次提交
  13. 04 11月, 2006 1 次提交
  15. 31 10月, 2006 1 次提交
  17. 29 10月, 2006 1 次提交
  19. 22 10月, 2006 1 次提交
  21. 17 10月, 2006 1 次提交
  23. 12 10月, 2006 1 次提交
  25. 04 10月, 2006 2 次提交
  27. 03 10月, 2006 7 次提交
  29. 01 10月, 2006 3 次提交
  31. 30 9月, 2006 1 次提交
  33. 13 9月, 2006 1 次提交
  35. 11 9月, 2006 1 次提交
  37. 09 9月, 2006 1 次提交
  39. 02 9月, 2006 1 次提交
  41. 31 8月, 2006 1 次提交
    • A
      [PATCH] Missing PCI id update for VIA IDE · a7dec1e0
      由 Alan Cox 提交于 
      The following change from -mm is important to 2.6.18 (actually to 2.6.17
but its too late for that). This was contributed over three months ago
by VIA to Bartlomiej and nothing happened. As a result the new chipset
is now out and Linux won't run on it. By the time 2.6.18 is finalised
this will be the defacto standard VIA chipset so support would be a good
plan.

Tested in -mm for a while, its essentially a PCI ident update but for
the bridge chip because VIA do things in weird ways.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      a7dec1e0
  43. 10 8月, 2006 1 次提交
  45. 28 7月, 2006 1 次提交