This patch allows users to override both host and device side cable detection
with "ideX=ata66" kernel parameter.  Thanks to this it should be now possible
to use UDMA > 2 modes on systems (laptops mainly) which use short 40-pin cable
instead of 80-pin one.

Next patches add automatic detection of some systems using short cables.

Changes:

* Rename hwif->udma_four to hwif->cbl and make it u8.

* Convert all existing users accordingly (use ATA_CBL_* defines while at it).  

* Add ATA_CBL_PATA40_SHORT support to ide-iops.c:eighty_ninty_three().

* Use ATA_CBL_PATA40_SHORT for "ideX=ata66" kernel parameter.
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Reviewed-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>

Switch the driver to always program DMA/PIO timings and set device transfer
mode instead of trusting BIOS on CSB6 controllers (libata pata_serverworks.c
driver is also doing things this way and there were no problems reported so
far).  While doing conversion I noticed that the old code had many issues:

* the code was assuming that hwif->dma_status is always valid
  (which obviously isn't true if hwif->dma_base == NULL)

* value of "(ultra_timing >> (4*unit)) & ~(0xF0)" expression wasn't checked
  to fit into udma_modes[5]

* code validating DMA timings didn't validate corresponding PIO timings

* extra CSB5 PIO register wasn't validated et all

* hwif->ide_dma_off_quietly() is always called before ide_set_dma() (which in
  turn calls hwif->speedproc() method - svwks_tune_chipset() in this case)
  so the code depending on DMA capable bit of DMA status to be set was never
  executed (=> the code was never validating DMA timings despite actually
  enabling DMA if the PIO timings were OK!)

* on resume driver dependend entirely on BIOS to restore timings and set
  transfer mode on the device

While at it:

There is no need to read PIO/MWDMA timings now so don't do it.
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Acked-by: NAlan Cox <alan@lxorguk.ukuu.org.uk>

Problem noticed by Joe Zbiciak, see

	http://kerneltrap.org/node/8252

for details.

On CSB6 the driver is using BIOS settings and not programming DMA/PIO timings
itself.  However the logic was completely broken and resulted in wrong timings
being silently allowed (instead of being corrected by the driver).

This bug would explain some data corruption/timeout issues with Serverworks
MegaIDE in RAID mode that Alan Cox has fixed recently with:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=2074a106f52b6371885afbd714e929d60d0e3f64

For 2.6.23 we may be better off with completely switching the driver to always
programming timings (libata pata_serverworks.c driver is doing things this way
and there were no problems reported so far) but for 2.6.22 lets fix the bug
in the simplest and the least intrusive way.

Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

Remove crappy code noticed by Linus, see

	http://lkml.org/lkml/2007/5/23/476

for details.

While at it simplify logic a bit.

There should be no functionality changes caused by this patch.

Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

gcc-4.3:

drivers/ide/pci/serverworks.c: In function 'svwks_tune_chipset':
drivers/ide/pci/serverworks.c:176: warning: overflow in implicit constant conversion
drivers/ide/pci/serverworks.c:190: warning: overflow in implicit constant conversion
drivers/ide/pci/serverworks.c:211: warning: overflow in implicit constant conversion
drivers/ide/pci/serverworks.c:212: warning: overflow in implicit constant conversion
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

It turns out from customer reports to Red Hat and some PCI dumps that the
MegaIDE in RAID mode doesn't provide the drive tuning data that the
serverworks driver expects but sometimes does provide something that
fools the code.

For the RAID class case skip the oem setup and don't trust the BIOS data.
We then tune from scratch and this sorts it out. (This has been confirmed
on an afflicted IBM blade)

[libata serverworks.c never trusts the BIOS in the first place so is
accidentally immune]
Signed-off-by: NAlan Cox <alan@redhat.com>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

Use ide_tune_dma() in ide-cris/it821x/pdc202xx_old/serverworks drivers.
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

* limit max PIO mode to PIO4, this driver doesn't support PIO5 and attempt
  to program PIO5 by svwks_tune_chipset() could result in incorrect PIO
  timings being programmed and possibly the data corruption (it seems that
  the minimum possible values were used but I lack the datasheets to be sure)

* select best PIO mode in svwks_tune_drive() and not in svwks_tune_chipset()
  when doing PIO autotuning (pio == 255)

* don't try to tune PIO in config_chipset_for_dma() as ide_dma_enable() could
  return 1 if DMA was previously enabled (svwks_config_drive_xfer_rate()
  takes care of PIO tuning if no suitable DMA mode is found)

* remove config_chipset_for_pio() and use svwks_tune_drive() instead,
  config_chipset_for_pio() contained numerous bugs when selecting PIO mode
  (luckily it was only used for devices limited to PIO by capabilities/BIOS):

  - it didn't check for validity of id->eide_pio_modes and id->eide_pio_iordy
    before using them

  - it tried to found out maximum PIO mode basing on minimum IORDY cycle time
    (moreover wrong cycle times were used for PIO0/1/5)

  - it was overriding PIO blacklist and conservative PIO "downgrade" done
    by ide_get_best_pio_mode()

  - if the max drive PIO was PIO5 then XFER_PIO_0/XFER_PIO_SLOW was selected
    (XFER_PIO_SLOW is not supported by svwks_tune_chipset() so the result
     was the same as if using XFER_PIO_5 => wrong PIO timings were set)

  - it was overriding drive->current_speed

* bump driver version
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

Depends on the "ide: fix UDMA/MWDMA/SWDMA masks" patch.

* add ide_hwif_t.udma_filter hook for filtering UDMA mask
  (use it in alim15x3, hpt366, siimage and serverworks drivers)
* add ide_max_dma_mode() for finding best DMA mode for the device
  (loosely based on some older libata-core.c code)
* convert ide_dma_speed() users to use ide_max_dma_mode()
* make ide_rate_filter() take "ide_drive_t *drive" as an argument instead
  of "u8 mode" and teach it to how to use UDMA mask to do filtering
* use ide_rate_filter() in hpt366 driver
* remove no longer needed ide_dma_speed() and *_ratemask()
* unexport eighty_ninty_three()

v2:
* rename ->filter_udma_mask to ->udma_filter
  [ Suggested by Sergei Shtylyov <sshtylyov@ru.mvista.com>. ]

v3:
* updated for scc_pata driver (fixes XFER_UDMA_6 filtering for user-space
  originated transfer mode change requests when 100MHz clock is used)
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

* add ide_set_dma() helper and make ide_hwif_t.ide_dma_check return
  -1 when DMA needs to be disabled (== need to call ->ide_dma_off_quietly)
   0 when DMA needs to be enabled  (== need to call ->ide_dma_on)
   1 when DMA setting shouldn't be changed
* fix IDE code to use ide_set_dma() instead if using ->ide_dma_check directly

v2:
* updated for scc_pata
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

If DMA is unsupported ->ide_dma_check should disable DMA.

v2:
* updated for scc_pata
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

This results in smaller/faster/simpler code and allows future optimizations.
Also remove no longer needed ide[_mm]_{inl,outl}() and ide_hwif_t.{INL,OUTL}.

v2:
* updated for scc_pata
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

* add ide_use_fast_pio() helper for use by host drivers

* add DMA capability and hwif->autodma checks to ide_use_dma()

  - au1xxx-ide/it8213/it821x drivers didn't check for (id->capability & 1)

    [ for the IT8211/2 in SMART mode this check shouldn't be made but since
      in it821x_fixups() we set DMA bit explicitly:

               if(strstr(id->model, "Integrated Technology Express")) {
                       /* In raid mode the ident block is slightly buggy
                          We need to set the bits so that the IDE layer knows
                          LBA28. LBA48 and DMA ar valid */
                       id->capability |= 3;            /* LBA28, DMA */

       we are better off using generic helper if we can ]

  - ide-cris driver didn't set ->autodma

    [ before the patch hwif->autodma was only checked in the chipset specific
      hwif->ide_dma_check implementations, for ide-cris it is cris_dma_check()
      function so there no behavior change here ]

v2:
* updated patch description (thanks to Alan Cox for the feedback)

v3:
* updated for scc_pata driver
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

* remove redundant svwks_ide_dma_end() [ __ide_dma_end() is used by default ]
* remove init_dma_svwks() so the default ide_setup_dma() function is used
  [ init_setup_csb6() takes care of not initializing disabled channels ]
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>

As we don't support hotplug we end up leaking an isa_dev reference which if
unload was ever added we would drop at the end of unloading.  This is fine
because we do genuinely need the isa_dev pointer until unload.
Signed-off-by: NAlan Cox <alan@redhat.com>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

There are two changes here.  The first reverses the broken PCI_DEVICE
conversion back to the old format.  The second adds a missing PCI ID so
you can actually boot 2.6.18 on 2 month old VIA motherboards (right now
only 2.6.18-mm works).

CC'd to Jeff to check the PCI ident but its a) in several distro kernels
and b) in 2.6.18-mm [twice ??]
Signed-off-by: NAlan Cox <alan@redhat.com>
Cc: Jeff Garzik <jeff@garzik.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>

Move auto arrays to static (const).  Clean up using PCI_DEVICE in places,
remove unreachable junk and dead code.

Fix the serverworks cable detect logic (if ordering is wrong).  Backport
from libata.  Plenty of scope for more cleanup left.
Signed-off-by: NAlan Cox <alan@redhat.com>
Cc: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>
Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Fix an uninitialised variable warning in the serverworks driver.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

BCM5785 (HT1000) is a Opteron Southbridge from Serverworks/Broadcom that
incorporates a single channel ATA100 IDE controller that is functionally
identical to the Serverworks CSB6 IDE controller.  This patch adds support
for the new PCI device ID and also the support for this controller.
Signed-off-by: NNarendra Sankar <nsankar@broadcom.com>
Acked-by: NJeff Garzik <jgarzik@pobox.com>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@elka.pw.edu.pl>

You can't install the base kernel on a Stratus box because of the overuse of
__init.  Affects both IDE layers identically.  It isn't the only misuser of
__init so more review of other drivers (or fixing ide_register code to know
about hotplug v non-hotplug chipsets) would be good.

Original issue found by Stratus and their patch was the inspiration for this
trivial one.
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!