Re: [PATCH v1] sata_mv: conversion to new EH

Jeff Garzik wrote: This is the first cut at converting sata_mv to new EH. It builds, but is untested. Done: - freeze, thaw - hardreset - prereset, software: intentionally not implemented s/software/softreset/ - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body

Re: [PATCHSET] libata: PATA driver for Celleb

Akira Iguchi wrote: Dear everyone. Thank you for many useful comments. This is the latest patchset for the PATA controller of Celleb. This patchset consists of [1] add another IRQ calls (core and headers) [2] add another IRQ calls (libata drivers) [3] PATA driver for Celleb And patch[3] depe

sata driver fails to work after resume from S3

Hi, I met a problem that sata driver fails to work after resume from S3. The kernel version is 2.6.16.33. After resume from S3, I got the following messages: First, "ATA: abnormal status 0x80 on port 0x1F7" for 3 times. Then, "sd 0:0:0(sometimes is 1):0: SCSI error: return code=0x4 end_request

[PATCH 3/3] libata: PATA driver for Celleb

This is the patch for PATA controller of Celleb. This driver uses the managed iomap (devres). Because this driver needs special taskfile accesses, there is a copy of ata_std_softreset(). ata_dev_try_classify() is exported so that it can be used in this function. Signed-off-by: Kou Ishizaki <[EMA

[PATCH 2/3] libata: add another IRQ calls (libata drivers)

This patch is against each libata driver. Two IRQ calls are added in ata_port_operations. - irq_on() is used to enable interrupts. - irq_ack() is used to acknowledge a device interrupt. In most drivers, ata_irq_on() and ata_irq_ack() are used for irq_on and irq_ack respectively. In some driver

[PATCH 1/3] libata: add another IRQ calls (core and headers)

This patch is against the libata core and headers. Two IRQ calls are added in ata_port_operations. - irq_on() is used to enable interrupts. - irq_ack() is used to acknowledge a device interrupt. In most drivers, ata_irq_on() and ata_irq_ack() are used for irq_on and irq_ack respectively. In so

[PATCHSET] libata: PATA driver for Celleb

Dear everyone. Thank you for many useful comments. This is the latest patchset for the PATA controller of Celleb. This patchset consists of [1] add another IRQ calls (core and headers) [2] add another IRQ calls (libata drivers) [3] PATA driver for Celleb And patch[3] depends on patch[1,2]. Thi

[PATCH v1] sata_mv: conversion to new EH

This is the first cut at converting sata_mv to new EH. It builds, but is untested. Done: - freeze, thaw - hardreset - prereset, software: intentionally not implemented Not yet done: - initiate EH from interrupt handler. Right now the "whack it" old error handling remains, when an error is see

[PATCH] ahci: use 0x80 as wait stat value instead of 0xff

Before hardreset, ahci initialized stat part of received FIS area to 0xff to wait for the first D2H Reg FIS which would change the value to device ready state. This used to work but now libata considers status value of 0xff as device not present making this wait prone to failure. This patch makes

[PATCH] sata_via: style clean up, no indirect method call in LLD

Call ata_bmdma_irq_clear() directly instead of through ap->ops->irq_clear() according to libata style guideline. Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> diff --git a/drivers/ata/sata_via.c b/drivers/ata/sata_via.c index 55b0123..d3d5c0d 100644 --- a/drivers/ata/sata_via.c +++ b/drivers/ata/s

[PATCH] ahci: fix endianness in spurious interrupt message

Fix endianness in spurious interrupt message. Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c index 2fe5a58..d8f0ce9 100644 --- a/drivers/ata/ahci.c +++ b/drivers/ata/ahci.c @@ -1178,7 +1178,8 @@ static void ahci_host_intr(struct ata_port *ap)

Re: Failed to set xfermode on LITE-ON LTR-40125S

John Williams wrote: > Hello, > > I just tried the libata support for PATA in kernel 2.6.20-rc5 and I got > this: > > scsi1 : pata_sis > ata2.00: ATAPI, max UDMA/66 > ata2.01: ATAPI, max UDMA/33 > ata2.00: configured for UDMA/33 > ata2.01: qc timeout (cmd 0xef) > ata2.01: failed to set xfermode (

Re: [PATCH] RESPIN: libata: add atapi_passthru=1 parameter

Jeff Garzik wrote: > Mark Lord wrote: >.. >> I believe Tejun and I were in agreement that proper >> ATA16 support for ATAPI was the better way to go. > > I like both approaches. I think direct support of HDIO_GET_IDENTITY can > reduce the number of failure points, while making old tools work a b

Re: [PATCH] remove duplicate ids from ata_piix

Greg KH wrote: From: Greg Kroah-Hartman <[EMAIL PROTECTED]> It seems that the ata_piix driver has two duplicate ids, one of them with a different 'private' field in it, which was never being used due to the match for the device happening on an earlier entry. This patch removes the duplicates, i

[PATCH] remove duplicate ids from ata_piix

From: Greg Kroah-Hartman <[EMAIL PROTECTED]> It seems that the ata_piix driver has two duplicate ids, one of them with a different 'private' field in it, which was never being used due to the match for the device happening on an earlier entry. This patch removes the duplicates, if this is the cor

Re: ahci: improve and limit spurious interrupt messages, take#3

Tejun Heo wrote: + const u32 *f = pp->rx_fis + RX_FIS_SDB; + + ata_port_printk(ap, KERN_INFO, "Spurious SDB FIS during NCQ " + "issue=0x%x SAct=0x%x FIS=%08x:%08x%s\n", + readl(port_mmio + PORT_CMD_ISSUE), +

[git patches] libata fixes

Please pull from 'upstream-linus' branch of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git upstream-linus to receive the following updates: drivers/ata/ahci.c | 57 -- drivers/ata/ata_generic.c|6 +++- drivers/ata/

Re: [PATCH] libata-sff: Don't call bmdma_stop on non DMA capable controllers

Alan wrote: Fixes bogus accesses to ports 0-15 with a non DMA capable controller. This I think should go in for 2.6.20 applied to #upstream-fixes, but it's a hack based on a misunderstanding. See comments below for further work needed. Arguably it shouldn't be called for PIO commands at a

Re: [PATCH] libata: implement ATA_FLAG_IGN_SIMPLEX and use it in sata_uli

Tejun Heo wrote: Some uli controllers have stuck SIMPLEX bit which can't be cleared with ata_pci_clear_simplex(), but the controller is capable of doing DMAs on both channels simultaneously. Implement ATA_FLAG_IGN_SIMPLEX which makes libata ignore the simplex bit and use it in sata_uli. Signed-

Re: ahci: improve and limit spurious interrupt messages, take#3

Tejun Heo wrote: We're still seeing a lot of issues with NCQ implementation in drive firmwares. Sprious FISes during NCQ command phase occur on many drives and some of them seem potentially dangerous (at least to me). Until we find the solution, spurious messages can give us more info. Improve a

Re: [PATCH] sata_via: don't diddle with ATA_NIEN in ->freeze

Tejun Heo wrote: vt6420 completely loses its ability to raise IRQ for ATAPI devices if ATA_NIEN is diddled with in ->freeze. Further investigation is necessary to determine whether this problem is shared on other controllers but it doesn't seem to be at this point. Make vt6420's ->freeze only c

Updated SiI h/w docs (was Re: [PATCH 13/15] ide: fix UDMA/MWDMA/SWDMA masks)

Sergei Shtylyov wrote: Now, the site seems to have 2 versions of the PCI-648/9 specs. :-) I looked into those in specs/sii and noted that PCI-648 spec was newer than mine, but PCI-649 was older. It's probably a good idea to put all the CMD/SiI files in the single directory, so there's no

Failed to set xfermode on LITE-ON LTR-40125S

Hello, I just tried the libata support for PATA in kernel 2.6.20-rc5 and I got this: scsi1 : pata_sis ata2.00: ATAPI, max UDMA/66 ata2.01: ATAPI, max UDMA/33 ata2.00: configured for UDMA/33 ata2.01: qc timeout (cmd 0xef) ata2.01: failed to set xfermode (err_mask=0x4) ata2.01: limiting speed to UD

Re: [PATCH 8/15] ide: disable DMA in ->ide_dma_check for "no IORDY" case

Hello. Bartlomiej Zolnierkiewicz wrote: The other advantage of doing cleanups is that code becomes cleaner/simpler which matters a lot for this codebase, i.e. ide-dma-off-void.patch exposed (yet to be fixed) bug in set_using_dma() (->ide_dma_off_quietly always returns 0 which is passed by ->ide

Re: [PATCH 2/2] ide: clear bmdma status in ide_intr() (revised)

Hello. Sergei Shtylyov wrote: diff -Nrup 01_remove_from_ide_cd/drivers/ide/ide-cd.c 02_add_to_ide_intr/drivers/ide/ide-cd.c --- 01_remove_from_ide_cd/drivers/ide/ide-cd.c2007-01-24 11:00:03.0 +0800 +++ 02_add_to_ide_intr/drivers/ide/ide-cd.c2007-01-25 16:52:20.0 +0800

Re: [PATCH 13/15] ide: fix UDMA/MWDMA/SWDMA masks

Hello. Sergei Shtylyov wrote: Not a suprise to be honest. I fixed some of the ALi stuff when I did it and I think that was pushed back into drivers/ide. The CMD64x hasn't had much love really. Another buglet found by random glancing at this driver: /** * cmd648_dma_stop - D

Re: [PATCH 2/2] ide: clear bmdma status in ide_intr() (revised)

Albert Lee wrote: patch 2/2 (revised): - Do the dma status clearing in ide_intr() and add a new hwif->ide_dma_clear_irq such that LLDD can override it. - Fix drive->waiting_for_dma to work with CDB-intr devices. Signed-off-by: Albert Lee <[EMAIL PROTECTED]> --- hwif->dma is not reliable: ide_in

Re: [PATCH] libata: share PIO limits among devices sharing a channel

Hello. Alan wrote: Not really, at least not all drivers. Namely, hpt366.c (still) doesn't merge 8-bit timings (maybe this is handled in hardware but the datasheets don't tell about it then) -- I need to look at fixing this... Well, it was I've never been able to find out - but HPT's ow

Re: [PATCH] libata: share PIO limits among devices sharing a channel

> Not really, at least not all drivers. Namely, hpt366.c (still) doesn't > merge 8-bit timings (maybe this is handled in hardware but the datasheets > don't tell about it then) -- I need to look at fixing this... Well, it was I've never been able to find out - but HPT's own drivers don't s

Re: [PATCH] libata: share PIO limits among devices sharing a channel

Alan wrote: NAK, this is totally wrong >> Eek.. You actually said this is/was documented and relied upon all over. >> >> http://thread.gmane.org/gmane.linux.ide/13184/focus=14486 > > What I said (well tried to say since it was apparently vague and caused > confusion) was relied upon was the h

Re: [PATCH] libata: share PIO limits among devices sharing a channel

Alan wrote: PIO xfermask limits should be shared by all devices on the same channel to avoid violating device selection timing. libata used to This is not a good way to deal with this. Only command block (8-bit) timings should be the same for both drives on channel, data register (16-bit

Re: [PATCH] libata: share PIO limits among devices sharing a channel

> >> NAK, this is totally wrong > > Eek.. You actually said this is/was documented and relied upon all over. > > http://thread.gmane.org/gmane.linux.ide/13184/focus=14486 What I said (well tried to say since it was apparently vague and caused confusion) was relied upon was the hardware being in

Re: [PATCH] libata: share PIO limits among devices sharing a channel

Jeff Garzik wrote: > Alan wrote: >> On Thu, 25 Jan 2007 20:29:47 +0900 >> Tejun Heo <[EMAIL PROTECTED]> wrote: >> >>> PIO xfermask limits should be shared by all devices on the same >>> channel to avoid violating device selection timing. libata used to >> >> NAK, this is totally wrong Eek.. You a

Re: [PATCH] libata: share PIO limits among devices sharing a channel

Alan wrote: On Thu, 25 Jan 2007 20:29:47 +0900 Tejun Heo <[EMAIL PROTECTED]> wrote: PIO xfermask limits should be shared by all devices on the same channel to avoid violating device selection timing. libata used to NAK, this is totally wrong + /* PIO xfermask limits are shared by all

Re: Linux 2.6 SATA NCQ support

Tejun Heo wrote: V VS wrote: Can you please give us your inputs on why the NCQ depth is not getting set correctly? Should we be looking at any other place for fixing this problem? Please give a shot at 2.6.20-rc5. There was a related bug fix for ahci. 2.6.20-rc6 also has a couple fixes, an

Re: Linux 2.6 SATA NCQ support

V VS wrote: > Thanks for your immediate response. Really appreciate it very much. > > With the kind of output that 2.16.19.1 has displayed, > should we be suspecting lack of NCQ support in the on-board SATA port or > the hard disk or anywhere else? Nope, just driver bug, I thin

Re: [PATCH] sata_via: don't diddle with ATA_NIEN in ->freeze

On Thu, 25 Jan 2007 20:46:59 +0900 Tejun Heo <[EMAIL PROTECTED]> wrote: > vt6420 completely loses its ability to raise IRQ for ATAPI devices if > ATA_NIEN is diddled with in ->freeze. Further investigation is > necessary to determine whether this problem is shared on other > controllers but it do

Re: [PATCH] libata: share PIO limits among devices sharing a channel

On Thu, 25 Jan 2007 20:29:47 +0900 Tejun Heo <[EMAIL PROTECTED]> wrote: > PIO xfermask limits should be shared by all devices on the same > channel to avoid violating device selection timing. libata used to NAK, this is totally wrong > + /* PIO xfermask limits are shared by all devices on t

Re: Linux 2.6 SATA NCQ support

V VS wrote: > Can you please give us your inputs on why the NCQ depth is not getting > set correctly? Should we be looking at any other place for fixing this > problem? Please give a shot at 2.6.20-rc5. There was a related bug fix for ahci. Thanks. -- tejun - To unsubscribe from this list: se

[PATCH] sata_via: don't diddle with ATA_NIEN in ->freeze

vt6420 completely loses its ability to raise IRQ for ATAPI devices if ATA_NIEN is diddled with in ->freeze. Further investigation is necessary to determine whether this problem is shared on other controllers but it doesn't seem to be at this point. Make vt6420's ->freeze only clear IRQ to fix thi

[PATCH] libata: share PIO limits among devices sharing a channel

PIO xfermask limits should be shared by all devices on the same channel to avoid violating device selection timing. libata used to guarantee this at core level but I mistakenly dropped the code during conversion to new EH. This patch revives that guarantee. Signed-off-by: Tejun Heo <[EMAIL PROTE

[PATCH] libata: implement ATA_FLAG_IGN_SIMPLEX and use it in sata_uli

Some uli controllers have stuck SIMPLEX bit which can't be cleared with ata_pci_clear_simplex(), but the controller is capable of doing DMAs on both channels simultaneously. Implement ATA_FLAG_IGN_SIMPLEX which makes libata ignore the simplex bit and use it in sata_uli. Signed-off-by: Tejun Heo <

ahci: improve and limit spurious interrupt messages, take#3

We're still seeing a lot of issues with NCQ implementation in drive firmwares. Sprious FISes during NCQ command phase occur on many drives and some of them seem potentially dangerous (at least to me). Until we find the solution, spurious messages can give us more info. Improve and limit them such

[PATCH 2/2] ide: clear bmdma status in ide_intr() (revised)

patch 2/2 (revised): - Do the dma status clearing in ide_intr() and add a new hwif->ide_dma_clear_irq such that LLDD can override it. - Fix drive->waiting_for_dma to work with CDB-intr devices. Signed-off-by: Albert Lee <[EMAIL PROTECTED]> --- hwif->dma is not reliable: ide_intr() races with dma_