Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 06 10月, 2005 3 次提交
  3. 05 10月, 2005 1 次提交
  5. 04 10月, 2005 7 次提交
    • A
      [libata scsi] add CHS support to ata_scsi_start_stop_xlat() · 9d5b1302
      由 Albert Lee 提交于
      9d5b1302
    • A
      [libata scsi] tidy up SCSI lba and xfer len calculations · 3aef5231
      由 Albert Lee 提交于 
      move the redundant SCSI lba and transfer length calculation code from
ata_scsi_verify_xlat() and ata_scsi_rw_xlat() to common functions.
      3aef5231
    • A
      libata: minor whitespace, comment, debug message updates · c187c4b5
      由 Albert Lee 提交于
      c187c4b5
    • A
      libata: bitmask based pci init functions for one or two ports · 47a86593
      由 Alan Cox 提交于 
      This redoes the n_ports logic I proposed before as a bitmask.
ata_pci_init_native_mode is now used with a mask allowing for mixed mode
stuff later on. ata_pci_init_legacy_port is called with port number and
does one port now not two. Instead it is called twice by the ata init
logic which cleans both of them up.

There are stil limits in the original code left over

- IRQ/port mapping for legacy mode should be arch specific values
- You can have one legacy mode IDE adapter per PCI root bridge on some systems
- Doesn't handle mixed mode devices yet (but is now a lot closer to it)
      47a86593
    • B
      [PATCH] libata: Marvell SATA support (DMA mode) (resend: v0.22) · 31961943
      由 Brett Russ 提交于 
      This is my libata compatible low level driver for the Marvell SATA
family.  Currently it runs in DMA mode on a 6081 chip.

The 5xxx series parts are not yet DMA capable in this driver because
the registers have differences that haven't been accounted for yet.
Basically, I'm focused on the 6xxx series right now.  I apologize for
those seeing problems on the 5xxx series, I've not had a chance to
look at those problems yet.

For those curious, the previous bug causing the SCSI timeout and
subsequent panics was caused by an improper clear of hc_irq_cause in
mv_host_intr().

This version is running well in my environment (6081 chips,
with/without SW raid1) and is showing equal or better performance
compared to the Marvell driver (mv_sata) in my initial tests (timed
dd's of reads/writes to/from memory/disk).

I still need to look at the causes of occasional problems such as this:

ata11: translating stat 0x35 err 0x00 to sense
ata11: status=0x35 { DeviceFault SeekComplete CorrectedError Error }
SCSI error : <10 0 0 0> return code = 0x8000002
Current sda: sense key Hardware Error
end_request: I/O error, dev sda, sector 3155010

and this, seen at init time:

ATA: abnormal status 0x80 on port 0xE093911C

but they aren't showstoppers.
Signed-off-by: NBrett Russ <russb@emc.com>
Signed-off-by: NJeff Garzik <jgarzik@pobox.com>
      31961943
    • J
      [libata] improve device scan even more · 3f19ee8c
      由 Jeff Garzik 提交于 
      Since our max_lun is unconditionally set to 1, we might as well
hardcode a LUN 0 probe, rather than a wildcard LUN scan.

The ide-scsi driver sets max_lun to a value greater than under
certain conditions:

        if ((drive->id->last_lun & 0x7) != 7)
                host->max_lun = (drive->id->last_lun & 0x7) + 1;
        else
                host->max_lun = 1;

last_lun is Word 126 of IDENTIFY PACKET DEVICE, marked as obsolete
and undocumented in non-ancient specs.  We'll leave it out for now.
Should the need arise to support multi-LUN ATAPI devices, we'll
probably want to add the above code.

Finally, there have been reports of REPORT LUNS commands locking up
ATAPI drives.  Eliminating the wildcard LUN scan could help reduce
the trouble from problematic drives.
      3f19ee8c
    • J
      [libata] improve device scan · 644dd0cc
      由 Jeff Garzik 提交于 
      Replace SCSI's legacy "bang at the door" method of probing with one
directly controlled by the underlying ATA transport layer.

We now only call scsi_scan_target() for devices we find, rather than
probing every possible channel/id within a certain range.
      644dd0cc
  7. 03 10月, 2005 2 次提交
  9. 02 10月, 2005 2 次提交
  11. 01 10月, 2005 15 次提交
  13. 30 9月, 2005 5 次提交
  15. 29 9月, 2005 5 次提交