This is actually an attempt to remove some stall code from
this driver. However if some *real* users complain (Not just
the usuall: "Hey - if someone!" but the "Hey I'm using this!")
I'm all open to reenable it. Since I prepared this patch
yerstoday it doesn't contain the ide_module.h fixup. This will
follow later.

- Don't use the convoluted byte type in ide-pci.c. Just use the proper
   u8instead.

- Move ide_get_or_set_dma_base to the only place where it's used and
   reorganize the code there by killing the unnecessary
   CONFIG_BLK_DEV_IDEDMA_FORCED configuration option.

- Remove unfunctional CONFIG_PKT_TASK_IOCTL code.

- Kill unused ALTSTAT_SCREW_UP code.

- Tons of dead code removed from ide-taskfile.c (#if 0 #endif and
   friends)

- Remove unused IDE_DEBUG macro as well as lots of other name space
   pollution from ide.h.

- Start using the ide_lock spin-lock for protecting access to data
   structures instead of the excessive interrupt disabling games.

- Shorten the proc ouput of the piix initialization module.

- Remove special /proc tape "name" output from ide-tape.c. This was
   redundant data which should only show up on syslog anyway.

- Kill the REALLY_FAST_IO undef from the ide.h. This was a mistake
   present since far too many years in this driver. The proper way to
   deal with broken systems is to define REALLY_SLOW_IO in system
   dependent headers or particular driver files.  We can always
   reintroduce it easy if real users will complain, since OUT_BYTE() and
   similar can be used as hooks. But I don't expect anybody reporting
   about this. Even on the most broken IDE chip in the world (cmd640
   at VLB) undefining this *always* worked for me. Nearly all the code
   pieces in the ide driver code *reverted* it's effects explicitly
   anyway.

- Remove the obsolete CONFIG_BLK_DEV_4DRIVES support. This was supposed
   to support 4 drivers attached at one channel on some older chipsets,
   in esp. Tekram 690CD, in the last century. They where all supposed to
   work at a register set starting at the base address 0x1f0.  Before
   complaining that this is removing functionality, please note that this
   must have been broken for already quite a long time, since the ide
   driver didn't contain the special device selection methods implicated
   by this any longer.  It didn't scan   this port too if PCI host chip
   support was enabled (as it is in all those distributions around
   there).  On the other hand this is the most prominent case of
   incoherent use of the mate member in the struct hwif_s. And please
   think about how big the probability is, that there are systems out
   there, where there are actually 4 drivers on such a channel?

- Streamline module initialization code by removing one shoot functions.

- Make the WAIT_READY value used in case of CONFIG_APM or
   CONFIG_APM_MODULE the default, since this is what really reflects the
   behavior of modern drives. It won't hurt any other case and finally
   removing it is reducing the necessary coverage for overall driver code
   testing/analysis.

- Move the IDE_LARGE_SEEK macro to the only place where it's actually
   used. Replace the IDE_MIN() and IDE_MAX() drivers with the obvious.
   Remove unused SPLIT_WORD and MAKE WORD from the local header.

- Remove CMD640_DUMP_REGS from global scope, since there is no
   development done on this any longer. Finally, the way the host chip
   initialization routines are called changed in the time between allows
   this to remain fully local to the host chip driver in question.

- Some spell checking of comments in the code. (Yeep I have extended my
   Vim to do this the "Word" way with nice undercurl lines... mozilla
   remains to be fixed...)