1. 03 Jul, 2007 1 commit
  2. 15 May, 2007 1 commit
    • Bartlomiej Zolnierkiewicz's avatar
      pdc202xx_new: use ide_tune_dma() · 7f86723a
      Bartlomiej Zolnierkiewicz authored
      * remove code enabling IORDY and prefetch from config_chipset_for_dma(),
        as the comment states it has no real effect because these settings are
        overriden when the PIO mode is set (and for this driver ->autotune == 1
        so PIO mode is always programmed)
      * use ide_tune_dma() in pdcnew_config_drive_xfer_rate() and remove no longer
        needed config_chipset_for_dma()
      There should be no functionality changes caused by this patch.
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
  3. 09 May, 2007 3 commits
    • Bartlomiej Zolnierkiewicz's avatar
      ide: cable detection fixes (take 2) · 7f8f48af
      Bartlomiej Zolnierkiewicz authored
      Tejun's recent eighty_ninty_three() fix has inspired me to do more thorough
      review of the cable detection code...
      * print user-friendly warning about limiting the maximum transfer speed
        to UDMA33 (and the reason behind it) when 80-wire cable is not detected,
        also while at it cleanup eighty_ninty_three() a bit
      * use eighty_ninty_three() in ide_ata66_check(), this actually fixes 3 bugs:
        - bit 14 (word 93 validity check) == 1 && bit 13 (80-wire cable test) == 1
          were used as 80-wire cable present test for CONFIG_IDEDMA_IVB=n case
          (please see FIXME comment in eighty_ninty_three() for more details)
        - CONFIG_IDEDMA_IVB=y/n cases were interchanged
        - check for SATA devices was missing
      * remove private cable warnings from pdc_202xx{old,new} drivers now that core
        code provides this functionality (plus, in pdc202xx_new case the test could
        give false warnings for ATAPI devices because pdc202xx_new driver doesn't
        even support ATAPI DMA)
      Cc: Tejun Heo <htejun@gmail.com>
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
    • Bartlomiej Zolnierkiewicz's avatar
      ide: rework the code for selecting the best DMA transfer mode (v3) · 2d5eaa6d
      Bartlomiej Zolnierkiewicz authored
      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()
      * rename ->filter_udma_mask to ->udma_filter
        [ Suggested by Sergei Shtylyov <sshtylyov@ru.mvista.com>. ]
      * 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: default avatarBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
    • Bartlomiej Zolnierkiewicz's avatar
      ide: fix UDMA/MWDMA/SWDMA masks (v3) · 18137207
      Bartlomiej Zolnierkiewicz authored
      * use 0x00 instead of 0x80 to disable ->{ultra,mwdma,swdma}_mask
      * add udma_mask field to ide_pci_device_t and use it to initialize
        ->ultra_mask in aec62xx, cmd64x, pdc202xx_{new,old} and piix drivers
      * fix UDMA masks to match with chipset specific *_ratemask()
        (alim15x3, hpt366, serverworks and siimage drivers need UDMA mask
         filtering method - done in the next patch)
      * piix: fix cable detection for 82801AA_1 and 82372FB_1
        [ Noticed by Sergei Shtylyov <sshtylyov@ru.mvista.com>. ]
      * cmd64x: use hwif->cds->udma_mask
        [ Suggested by Sergei Shtylyov <sshtylyov@ru.mvista.com>. ]
      * aec62xx: fix newly introduced bug - check DMA status not command register
        [ Noticed by Sergei Shtylyov <sshtylyov@ru.mvista.com>. ]
      * piix: use hwif->cds->udma_mask
        [ Suggested by Sergei Shtylyov <sshtylyov@ru.mvista.com>. ]
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
  4. 07 May, 2007 1 commit
  5. 05 May, 2007 1 commit
  6. 26 Mar, 2007 1 commit
    • Albert Lee's avatar
      pdc202xx_new: Enable ATAPI DMA · 362ebd83
      Albert Lee authored
      [ bart: the ressurection of 2 years old patch which slipped thru the cracks
        (thanks to Sergei Shtylyov for finding it) ]
      These is the patch to turn on pdc202xx_new for ATAPI DMA.  When testing, it
      works fine without the (request_bufflen % 256) workaround as needed in libata.
      ide-scsi filters out (pc->request_transfer % 1024) and use PIO, so the pdc202xx
      ATAPI DMA problem is avoid.  Both ide-cd and ide-scsi won't hit the ATAPI DMA
      problem on pdc202xx_new.
      Signed-off-by: default avatarAlbert Lee <albertcc@tw.ibm.com>
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
  7. 16 Feb, 2007 4 commits
  8. 07 Feb, 2007 2 commits
  9. 27 Jan, 2007 1 commit
  10. 10 Dec, 2006 1 commit
    • 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>
  11. 08 Dec, 2006 2 commits
  12. 30 Jun, 2006 1 commit
  13. 28 Jun, 2006 1 commit
  14. 27 Jun, 2006 1 commit
  15. 03 Feb, 2006 1 commit
  16. 10 Jan, 2006 1 commit
  17. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      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!