The driver wrongly takes the address setup time into account when calculating
the PIO recovery time -- this leads to slight overclocking of the PIO modes 0
and 1 (so, the prayers failed to help, as usual :-). Rework the code to be
calculating recovery clock count as a difference between the total cycle count
and the active count (we don't need to calculate the recovery time itself since
it's not specified for the PIO modes 0 to 2, and for modes 3 and 4 this formula
gives enough recovery time anyway in the chip's supported PCI frequency range).
This patch has been inspired by reading the datasheets and looking at what the
libata driver does; it has been compile-tested only (as usual :-) but anyway,
the new code gives the same or longer recovery times than the old one...
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Remove
* "hdx=serialize"
* "idex=noautotune"
* "idex=autotune"
kernel params, they have been obsoleted for ages.
"idex=serialize", "hdx=noautotune" and "hdx=autotune" are still available
so there is no funcionality loss caused by this patch.
v2:
* fix CONFIG_BLK_DEV_4DRIVES=y build broken by version 1 of the patch
[ /me wearing brown paper bag ]
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Revised DRAC4 warning as Jeff suggested, this one includes more info
about why the problem occurs
Signed-off-by: Alan Cox <alan@redhat.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
The tuneproc() method in both these drivers failed to set the drive's own speed.
Fix this by renaming the function and "wrapping around it" the new tuneproc()
method. Switch back to calling tuneproc() in the PIO fallback code.
While at it, also convert the rest of the PIO timing code into proper C. :-)
Has been kind of tested on SLC90E66. I'm too lazy to reboot my box and test
on ICH4... :-)
[ bart: I quickly tested it on ICH4. ]
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
The driver's tuneproc() method fails to set the drive's own speed -- fix this
by renaming the function to cmd64x_tune_pio(), making it return the mode set,
and "wrapping" the new tuneproc() method around it; while at it, also get rid
of the non-working prefetch control code (filtering out related argument values
in the "wrapper"), remove redundant PIO5 mode limitation, make cmdprintk() give
more sensible mode info, and remove mention about the obsolete /proc/ interface.
Get rid of the broken config_chipset_for_pio() which always tried to set PIO4,
switch to always auto-tuning PIO instead.
Oh, and add the missing PIO5 support to the speedproc() method while at it. :-)
Warning: compile tested only -- getting to the real hardware isn't that easy...
On Tuesday 06 February 2007 22:11, Mikael Pettersson <mikpe@it.uu.se> wrote:
>
> Worked fine on my SPARC Ultra5 with a CMD646 IDE controller.
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
The driver's tuneproc() method fails to set the drive's own speed -- fix this
by renaming the function to ali15x3_tune_pio() and "wrapping" the new tuneproc()
method around it and making it return the mode set, update the heading comment.
Also, setting PIO mode via the speedproc() method does not work due to passing
to the tuneproc() method's a mode number not biased by XFER_PIO_0 -- fix this
along with a typo in the heading comment...
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
* since ide_hwif_t.ide_dma_host_on is called either when drive->using_dma == 1
or when return value is discarded make it void, also drop "ide_" prefix
* make __ide_dma_host_on() void and drop "__" prefix
v2:
* while at it rename atiixp_ide_dma_host_on() to atiixp_dma_host_on()
and sgiioc4_ide_dma_host_on() to sgiioc4_dma_host_on().
[ Noticed by Sergei Shtylyov <sshtylyov@ru.mvista.com>. ]
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
* since ide_hwif_t.ide_dma_{host_off,off_quietly} always return '0'
make these functions void and while at it drop "ide_" prefix
* fix comment for __ide_dma_off_quietly()
* make __ide_dma_{host_off,off_quietly,off}() void and drop "__" prefix
v2:
* while at it rename atiixp_ide_dma_host_off() to atiixp_dma_host_off(),
sgiioc4_ide_dma_{host_off,off_quietly}() to sgiioc4_dma_{host_off,off_quietly}()
and sl82c105_ide_dma_off_quietly() to sl82c105_dma_off_quietly()
[ Noticed by Sergei Shtylyov <sshtylyov@ru.mvista.com>. ]
Signed-off-by: Bartlomiej 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: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
All users of ->mmio == 1 are gone so convert ->mmio into flag.
Noticed by Alan Cox.
v2:
* updated for scc_pata
Signed-off-by: Bartlomiej 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: Bartlomiej 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: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
In cmd64x, siimage and scc_pata drivers:
* don't set drive->init_speed as it should be already
set by successful execution of ide_set_xfer_rate()
* use hwif->speedproc functions directly
Above changes allows removal of EXPORT_SYMBOL_GPL(ide_set_xfer_rate).
v2:
* updated for scc_pata driver
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
* remove bogus comment for sis5513_config_xfer_rate()
* there is no need to call config_drive_art_rwp() because
it is called by config_art_rwp_pio()
* remove needless wrapper
* remove stale "TODO" comment
(IDE core should provide generic tuning code)
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
* disable DMA masks if no_piix_dma is set and remove now
not needed no_piix_dma_check from piix_config_drive_for_dma()
* there is no need to read register 0x55 in init_hwif_piix()
* move cable detection code to piix_cable_detect()
* remove unreachable 82371MX code from init_hwif_piix()
Signed-off-by: Bartlomiej 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: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
* BUG() on unknown DMA mode in cs5530_config_dma()
* there is no need to call hwif->ide_dma_host_{off,on}() in
cs5530_config_dma() because hwif->ide_dma_host_{off,on}()
is called by hwif->ide_dma_off_{quietly,on}()
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
In drivers/ide/Kconfig BLK_DEV_TRM290 depends on
BLK_DEV_IDEDMA_PCI (on which is BLK_DEV_IDEDMA dependant on).
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Fix a number of issues with the DMA support code:
- driver claims support for all SW/MW DMA modes while supporting only MWDMA2;
- ide_dma_check() method tries to enable DMA on the "known good" drives which
don't support MWDMA2;
- ide_dma_on() method upon failure to set drive to MWDMA2 re-tunes already
tuned PIO mode and calls ide_dma_off() method instead of returning error;
- ide_dma_off() method sets drive->current_speed while it doesn't actually
change (only the PIO timings are re-loaded into the chip's registers);
- init_hwif() method forcibly sets/resets both "drive DMA capable" bits while
this is properly handled by ide_dma_{on,off}() methods being called later...
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Fix the driver's tuneproc() method to always set the PIO mode requested and not
pick the best possible one, rename it to pdc202xx_tune_drive(), and change the
calls to it accordingly; remove the preceding comment which has nothing to do
with the code.
Sergei Shtylyov wrote:
> The tuneproc() method should take arg 255 for auto-selecting the best PIO
> mode, not 5 as it did here + this driver's method always auto-selected instead
> of setting the mode it's been told to -- issue typical to drivers/ide/...
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Fix two typos found by SiI680A documentation check. They caused the taskfile
transfer overclocking:
- in PIO mode 1 as 0x2283 must be used for both data and taskfile transfers;
- in PIO mode 2 as data and taskfile timings are swapped when writing to the
MMIO regs.
Fix coding style and trailing whitespace in enclosing statements while at it...
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
drivers/ide/pci/siimage.c | 59 ++++++++++++++++++++++------------------------
1 file changed, 29 insertions(+), 30 deletions(-)
patch 2/2:
Remove clearing bmdma status from cdrom_decode_status() since ATA devices
might need it as well.
(http://lkml.org/lkml/2006/12/4/201 and http://lkml.org/lkml/2006/11/15/94)
Signed-off-by: Albert Lee <albertcc@tw.ibm.com>
Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: "Adam W. Hawks" <awhawks@us.ibm.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
patch 1/2 (revised):
- Fix drive->waiting_for_dma to work with CDB-intr devices.
- Do the dma status clearing in ide_intr() and add a new
hwif->ide_dma_clear_irq for Intel ICHx controllers.
Revised per Alan, Sergei and Bart's advice.
Patch against 2.6.20-rc6. Tested ok on my ICH4 and pdc20275 adapters.
Please review/apply, thanks.
Signed-off-by: Albert Lee <albertcc@tw.ibm.com>
Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: "Adam W. Hawks" <awhawks@us.ibm.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
* atiixp: if DMA can't be used atiixp_config_drive_for_dma() should return 0,
atiixp_dma_check() will tune the correct PIO mode anyway
* jmicron: if DMA can't be used config_chipset_for_dma() should return 0,
micron_config_drive_for_dma() will tune the correct PIO mode anyway
config_jmicron_chipset_for_pio(drive, !speed) doesn't program
device transfer mode for speed != 0 (only wastes some CPU cycles
on ide_get_best_pio_mode() call) so remove it
* triflex: if DMA can't be used triflex_config_drive_for_dma() should return 0,
triflex_config_drive_xfer_rate() will tune correct PIO mode anyway
Above changes also fix (theoretical) issue when ->speedproc fails to set
device transfer mode (i.e. when ide_config_drive_speed() fails to program it)
but one of DMA transfer modes is already enabled on the device by the BIOS.
In such scenario ide_dma_enable() will incorrectly return true statement
and ->ide_dma_check will try to enable DMA on the device.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
* remember to clear reg2 bits for the current device before setting mode
* remove no longer needed hpt34x_clear_chipset()
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
On Thursday 11 January 2007 23:17, Bartlomiej Zolnierkiewicz wrote:
>
> My working IDE tree (against Linus' tree) now resides here:
>
> http://kernel.org/pub/linux/kernel/people/bart/pata-2.6/patches/
Bart, here's a driver I've been keeping out-of-tree for the past couple
of years. This is for the Delking/Lexar/ASKA/etc.. 32-bit cardbus IDE
CompactFlash adapter card.
It's probably way out of sync with the latest driver model (??), but it
still builds/works. I'm not interested in doing much of a rewrite, other
than for libata someday, as I no longer use the card myself.
But lots of other people do seem to use it, so it might be nice to see it
"in-tree".
Signed-off-by: Mark Lord <mlord@pobox.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
* set ATAPI/IORDY/TIME bits correctly in it8213_tuneproc()
* fix UDMA/MWDMA/SWDMA masks in it8213_init_hwif()
* in it8213_tune_chipset() SWDMA2 mode should be used instead of MWDMA0
* backport various fixes from piix/slc90e66 drivers:
- in it8213_tuneproc() the highest possible PIO mode is PIO4 (not PIO5)
- clear ATAPI/IORDY/TIME bits before setting them also for slave device
- use ->speedproc in it8213_config_drive_for_dma()
- don't try to tune PIO in config_chipset_for_pio()
- simplify is_slave calculation in it8213_tuneproc()
- misc cleanups
* fix it8213_ratemask() and it8213_tuneproc() comments
* simplify it8213_init_hwif()
* remove init_chipset_it8213()
* add missing Copyrights and update MODULE_AUTHOR()
* CodingStyle cleanups
* remove dead code
v2:
* PCI_DEVICE_ID_ITE_8213 is only defined in -mm kernels,
so just use PCI Device ID (0x8213) directly
* fix ->ultra_mask incorrectly changed to 0x3f in v1 version of the patch
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
This is the driver for the Toshiba TC86C001 GOKU-S PCI IDE controller,
completely reworked from the original brain-damaged Toshiba's 2.4 version.
This single channel UltraDMA/66 controller is very simple in programming,
yet Toshiba managed to plant many interesting bugs in it. The particularly
nasty "limitation 5" (as they call the errata) caused me to abuse the IDE
core in a possibly most interesting way so far. However, this is still
better than the #ifdef mess in drivers/ide/ide-io.c that the original
version included (well, it had much more mess)...
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Acked-by: Alan Cox <alan@redhat.com>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Fold check_in_drive_lists() into quirkproc() handler in both PDC202xx
drivers-- this function was never called with a list other than
pdc_quirk_drives and was a bad example of code overall...
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Remove the following useless fragments from the driver:
- the ide_dma_lostirq() and ide_dma_timeout() handlers which boil down to just
printing the incoherent reset message and calling their default counterparts;
- check for non-NULL drive->id in the ide_dma_check() handler -- this is assumed
to be true by all other handlers (also, get rid of unnecessary nesting of the
conditional statements there);
- the comment before pdcnew_tune_drive() which has nothing to do with the code.
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Synchronize with version 0.46 of the Intel PIIX/ICH driver:
- carry over Alan's and my own fixes in the tuneproc() method and my cleanups
both there and in the ratemask() method;
- SLC90E66 only supports MW DMA modes 1/2 and SW DMA mode 2 (just like Intel
chips), so don't claim support for other MW/SW DMA modes;
- don't check dor non-NULL drive->id in the ide_dma_check() method -- this is
assumed to be true in all other drivers;
- do some coding/formatting cleanups while at it...
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Fix/cleanup the driver's tuneproc() and ratemask() methods:
- PPE, IE, and TIME bits need to be cleared beforehand for the slave drive as
well as master (Alan probably just forgot about it);
- this driver only supports PIO modes up to 4, so must pass the correct limit
to ide_get_best_pio_mode();
- use min_t() macro instead of min();
- simplify slave vs master drive evaluation;
- do come coding and formatting cleanups...
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
According to the datasheet, Intel 82371MX (MPIIX) actually has only a
single IDE channel mapped to the primary or secondary ports depending on
the value of the bit 14 of the IDETIM register at PCI config. offset 0x6C
(the register at 0x6F which the driver refers to. doesn't exist). So,
disguise the controller as dual channel and set enablebits masks/values
such that only either primary or secondary channel is detected enabled.
Also, preclude the IDE probing code from reading PCI BARs, this controller
just doesn't have them (it's not the separate PCI function like the other
PCI controllers), it only decodes the legacy addresses.
[ Alan sayeth " MPIIX does not work with or without the change. It needs its
own different driver and not to use setup-pci. Huge job and since it works
well with libata who cares. Ditto the early PIIX chip." ]
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Fix minor coding mistake in the HPT36x PCI clock detection code noticed by
Bartlomiej Zolnierkiewicz -- it always reported 33 MHz due to the missing
'break' statements. This, however, most probably never mattered -- in fact, I
was thinking of removing the 25/40 MHz cases completely since HPT36x BIOSes
didn't seem to set any other value than 7 into the 'cmd_high_time' field, i.e.
supported only 33 MHz PCI.
Note that in the original driver there was another bug: 25 and 40 MHz cases
were interchanged. Since the 'cmd_high_time' field is in units of PCI clocks,
a lower clock count just *cannot* correspond to a higher frequency, i. e. it
should be 5 for 25 MHz PCI and 9 for 40 MHz PCI, not the other way around.
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Finally, rework the driver init. code to correctly handle all the chip
variants HighPoint has created so far. This should cure the rest of the
timing issues in the driver (especially, on 66 MHz PCI) caused by the
HighPoint's habit of switching the base DPLL clock with every new revision
of the chips...
- switch to using the enumeration type to differ between the numerous chip
variants, matching PCI device/revision ID with the chip type early, at the
init_setup stage;
- extend the hpt_info structure to hold the DPLL and PCI clock frequencies,
stop duplicating it for each channel by storing the pointer in the pci_dev
structure: first, at the init_setup stage, point it to a static "template"
with only the chip type and its specific base DPLL frequency, the highest
supported DMA mode, and the chip settings table pointer filled, then, at
the init_chipset stage, allocate per-chip instance and fill it with the
rest of the necessary information;
- get rid of the constant thresholds in the HPT37x PCI clock detection code,
switch to calculating PCI clock frequency based on the chip's base DPLL
frequency;
- switch to using the DPLL clock and enable UltraATA/133 mode by default on
anything newer than HPT370/A;
- fold PCI clock detection and DPLL setup code into init_chipset_hpt366(),
unify the HPT36x/37x setup code and the speedproc handlers by joining the
register setting lists into the table indexed by the clock selected;
- add enablebits for all the chips to avoid touching disabled channels
(though the HighPoint BIOS seem to only disable the primary one on
HPT371/N);
- separate the UltraDMA and MWDMA masks there to avoid changing PIO timings
when setting an UltraDMA mode in hpt37x_tune_chipset().
This version has been tested on HPT370/302/371N.
Thanks to Alan for the inspiration. Hopefully, his libata driver will also
benefit from the work done on this "obsolete" driver...
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Clean up DMA timeout handling for HPT370:
- hpt370_lostirq_timeout() cleared the DMA status which made __ide_dma_end()
called afterwards return the incorrect result, and the DMA engine was reset
both before and after stopping DMA while the HighPoint drivers only do it
after (which seems logical) -- fix this and also rename the function;
- get rid of the needless mutual recursion in hpt370_ide_dma_end() and
hpt370_ide_dma_timeout();
- get rid of hpt370_lostirq_timeout() since hwif->ide_dma_end() called from
the driver's interrupt handler later does all its work.
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Continue with the driver rewrite:
- move the interrupt twiddling code from the speedproc handlers into the
init_hwif_hpt366 which allows to merge the two HPT37x speedproc handlers
into one;
- get rid of in init_hpt366 which solely consists of the duplicate code, then
fold init_hpt37x() into init_chipset_hpt366();
- fix hpt3xx_tune_drive() to always set the PIO mode requested, not the best
possible one, change hpt366_config_drive_xfer_rate() accordingly, simplify
it a bit;
- group all the DMA related code together init_hwif_hpt366(), and generally
clean up and beautify it.
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Begin the real driver redesign. For the starters:
- cache the offset of the IDE channel's MISC. control registers which are used
throughout the driver in hwif->select_data;
- only touch the relevant MCR when detecting the cable type on HPT374's
function 1;
- make HPT36x's speedproc handler look the same way as HPT37x ones; fix the
PIO timing register mask for HPT37x.
- rename all the HPT3xx register related variables consistently; clean up the
whitespace.
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Switch to using pci_get_slot() to get to the function 1 of HPT36x/374 chips --
there's no need for the driver itself to walk the list of the PCI devices, and
it also forgets to check the bus number of the device found.
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
- Rework the driver setup code so that it prefixes the driver startup
messages with the real chip name.
- Print the measured f_CNT value and the DPLL setting for non-HPT3xx
chips as well.
- Claim the extra 240 bytes of I/O space for all chips, not only for
those having PCI device ID of 0x0004.
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
- Rework hpt3xx_ratemask() and hpt3xx_ratefilter() so that the former
returns the max. mode computed at the load time and doesn't have to do
bad Ultra33 drive list lookups anymore; remove the duplicate code from
the latter function. Move the quirky drive list lookup into
hpt3xx_quirkproc() where it should have been from the start...
- Disable UltraATA/100 for HPT370 by default as the 33 MHz ATA clock
being used does not allow for it, and this *greatly* increases the
transfer speed.
- Save some space by using byte-wide fields in struct hpt_info; switch to
reading the 8-bit PCI revision ID reg. only, not the whole 32-bit reg.
- Start incrementing the driver version number with each patch (should
have been done from the first one posted).
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
jmicron module detects all JMB36x as JMB361 and PATA0 has wrong pin status
of XICBLID.
Cc: Jeff Garzik <jeff@garzik.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This patch:
* Corrects the wrong device ID of PCI_DEVICE_ID_VIA_SATA_EIDE
from 0x0581 to 0x5324.
* Adds VIA CX700 and VT8237S support in drivers/ide/pci/via82cxxx.c
* Adds VIA VT8237S support in drivers/ata/pata_via.c
Signed-off-by: Josepch Chan <josephchan@via.com.tw>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Drop ide-generic support for Jmicron identifiers as we now trust Jmicron.c for
this with drivers/ide. The code check remains for the all-generic-ide case.
Signed-off-by: Alan Cox <alan@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
IDE HDD does not work if it uses a 40-pin PATA cable on ATI chipset.
This patch fixes the bug.
Signed-off-by: Conke Hu <conke.hu@amd.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
AMD/ATI SB600 IDE/PATA controller only has one channel.
Signed-off-by: Conke Hu <conke.hu@amd.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
A previous patch to atiixp.c was removed but some code has not been
cleaned. Now we remove these code sine they are no use any longer.
Signed-off-by: Conke Hu <conke.hu@amd.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
When the old IDE layer calls into methods in the driver during error
handling it is essentially random whether ide_lock is already held. This
causes a deadlock in the atiixp driver which also uses ide_lock internally
for locking.
Switch to a private lock instead.
[akpm@osl.org: cleanup]
Signed-off-by: Alan Cox <alan@redhat.com>
Acked-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This patch fixes 2.6.15 regression, is straightforward and tested.
Cable detection got broken probably while converting the driver to support
multiple controllers. Cable detection is done by examining how BIOS
configured the attached devices. The current code is broken in that it
examines the status *after* modifying Clk66 configuration ending up
detecting 40c cables as 80c. This patch fixes it.
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The fallback to PIO mode in the hwif->dma_check() handler doesn't work in
the Intel PIIX and SMsC SLC90E66 IDE drivers because:
- config_drive_for_dma() calls the hwif->speedproc() handler with a wrong
mode number (unbiased by XFER_PIO_0) in case of the PIO fallback;
- hwif->tuneproc() handler doesn't really set the drive's own speed (this
is not fixed as yet).
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
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>
There's no need to check in piix_config_drive_for_dma() for broken MW DMA
mode 0 as this mode is not supported by the driver (it sets
hwif->mwdma_mask to 0x6), and hence can't be selected by ide_dma_speed().
(Alan sayeth "Probably right but if not you've got a subtle corruptor. Should
at least stick a BUG_ON mode 0 setting right close when the mode is set.")
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
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>
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>
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>
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>
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>
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>
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>
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>
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: Alan Cox <alan@redhat.com>
(Most of the hard work done by Stratus however)
Cc: Jens Axboe <axboe@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
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: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Albert Lee <albertcc@tw.ibm.com>
Acked-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Straighten up the IDE control/status register caching -- you *really* can't
cache the shared register per-channel and hope that it won't get out ouf
sync.
Set the PIO fallback mode to PIO0 for the slave drive as well as master --
there was no point in having them different (most probably a resutl of
typo).
Do a bit of reformat and cleanup while at it...
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Acked-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Fix pdcnew_tune_drive() to always set the PIO mode requested, not pick the
best possible one, change pdcnew_config_drive_xfer_rate() accordingly, and
get rid of the duplicate tuneproc() call in config_chipset_for_dma().
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This completes IDE except for one use which requires a new core PCI function
and will be polished up at the end
Signed-off-by: Alan Cox <alan@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Jeff noted that the via driver returned an error to an unsigned int in a
a case where errors are not permitted. Move the check down earlier so we
can handle it properly. Not as pretty but it works this way and avoids
hacking up ugly stuff in the legacy ide core.
Signed-off-by: Alan Cox <alan@redhat.com>
Cc: Jeff Garzik <jeff@garzik.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This patch removes a module_exit function that sgiioc4 should not have had.
It seems that the IDE layer doesn't support submodule unloading. sgiioc4 was
the only driver in drivers/ide/pci that had an exit function. After an
unload, the devices would stay around and the next attempt to reference would
crash...
Signed-off-by: Jeremy Higdon <jeremy@sgi.com>
Acked-by: "Bartlomiej Zolnierkiewicz" <bzolnier@gmail.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
There is some PPC_CHRP specific code in drivers/ide/pci/via82cxxx.c,
so #ifdef on CONFIG_PPC_CHRP instead of CONFIG_PPC_MULTIPLATFORM.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Add support for PATA controllers of MCP67 to amd74xx.c.
Signed-off-by: Peer Chen <pchen@nvidia.com>
Cc: Jeff Garzik <jeff@garzik.org>
Acked-by: Alan Cox <alan@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The Jmicron JMB368 is PATA only so has the PATA on function zero. Don't
therefore skip function zero on this device when probing
Signed-off-by: Alan Cox <alan@redhat.com>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The change from __setup() to module_param_named() requires users to prefix
the option with "generic.".
This patch re-adds the __setup() additionally to the module_param_named().
Usually it would make sense getting rid of such an obsolete __setup() at
some time, but considering that drivers/ide/ is slowly approaching a RIP
status it's already implicitely scheduled for removal.
This patch fixes kernel Bugzilla #7353.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Acked-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
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: Pat Gefre <pfg@sgi.com>
Acked-by: Jeremy Higdon <jeremy@sgi.com>
Signed-off-by: Brent Casavant <bcasavan@sgi.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Some people find their Jmicron pata port reports its disabled even
though it has devices on it and was boot probed. Fix this
(Candidate for 2.6.18.*, less so for 2.6.19 as we've got a proper
jmicron driver on the merge for that to replace ide-generic support)
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
As per feature-removal-schedule.txt.
Signed-off-by: Yoichi Yuasa <yoichi_yuasa@tripeaks.co.jp>
Acked-by: Alan Cox <alan@redhat.com>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Allow ide/pci/generic to claim chipsets as a a module or when built-in. It
requires using "all_generic_ide" as a boot option.
Signed-off-by: Patrick Jefferson <henj@hp.com>
Acked-by: Alan Cox <alan@redhat.com>
Closes-Bug: 7017
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Remove some code which is unneeded if CONFIG_PM=n.
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Remove dma_base2 field from ide_hwif_t as it's used only in 2 drivers and
without great need.
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: John Keller <jpk@sgi.com>
Signed-off-by: Jeremy Higdon <jeremy@sgi.com>
Acked-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
There are three flags being set by default by the PIIX driver for speeds >
PIO 1, and one not being cleared properly on fallback to PIO0. The most
important one is the prefetch/post write control which only works for ATA
and can do bad things with ATAPI.
The patch does its best to set the flags correctly for drivers/ide. Its
not 100% perfect but its closer than the original. 100% perfect requires
proper IORDY handling but this isn't critical (and its not right in libata
either .. yet)
Sergei Shtylyov <sshtylyov@ru.mvista.com> said:
> + { 0, 0 },
> + { 0, 0 },
> + { 1, 0 },
> + { 2, 1 },
> + { 2, 3 }, };
>
> pio = ide_get_best_pio_mode(drive, pio, 5, NULL);
BTW, there's quite obvious error here which leads to access outside of
timings[] if somebody passes PIO mode 5 (or autotuning code finds out that
drive supports PIO mode 5). Could have been fixed while at it... Those drives
should be rare, though...
> + }
> master_data = master_data | (timings[pio][0] << 12) | (timings[pio][1] << 8);
> }
> pci_write_config_word(dev, master_port, master_data);
Actually, there's one more serious issue with piix_tune_drive() -- it
doesn't actually set the drive's own transfer mode.
Signed-off-by: Alan Cox <alan@redhat.com>
Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This patch allows me to use dma with my cd/dvd attached to my on board
pdc20265 ide controller
Alan sayeth:
Looks sane. Would be nice to know if there is any documentation
supporting this hack being safe but the logic makes sense. The LBA48 case
faces the same problem - the state machine gets confused about the transfer
length and needs kicking
Signed-off-by: Tobias Oed <tobiasoed@hotmail.com>
Acked-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>
Cc: Jens Axboe <axboe@suse.de>
Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Less functional than libata this just uses the merged interface provided for
dumb legacy OS's. This is basically a bridge for people not yet ready to use
libata for some reason or another.
Port visibility is entirely dependant on the BIOS setup.
Signed-off-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Mirrors the drivers/ata version, hold a reference to the host bridge while we
are doing setup.
Signed-off-by: Alan Cox <alan@redhat.com>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
