libata ignores non-dma disks?

libata ignores non-dma disks?

[Ed Sweetman]

I'm using 2.6.16-rc6-ide1 (alan's patchset) and using the sata_nv and 
pata_amd drivers.  I have all UDMA drives except a CF disk -> IDE 
interface, which should be running in PIO mode4.   Libata detects the 
device, but spits out a message about "no dma" and then says it's not 
supported and is ignoring it.   Is this device not supported because 
it's not using dma or for some other reason?  
It's the only device on it's channel (secondary pata)

ata6: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 15
ata6: dev 0 cfg 49:0e00 82:0000 83:0000 84:0000 85:0000 86:0000 87:0000 
88:0000
ata6: no dma
ata6: dev 0 not supported, ignoring
scsi5 : pata_amd


I'd really like to get this up and running so if anyone has any 
suggestions, I'm all ears.

libata ignores non-dma disks?

[Ed Sweetman]

I'm using 2.6.16-rc6-ide1 (alan's patchset) and using the sata_nv and
pata_amd drivers.  I have all UDMA drives except a CF disk -> IDE
interface, which should be running in PIO mode4.   Libata detects the
device, but spits out a message about "no dma" and then says it's not
supported and is ignoring it.   Is this device not supported because
it's not using dma or for some other reason?
It's the only device on it's channel (secondary pata)

ata6: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 15
ata6: dev 0 cfg 49:0e00 82:0000 83:0000 84:0000 85:0000 86:0000 87:0000
88:0000
ata6: no dma
ata6: dev 0 not supported, ignoring
scsi5 : pata_amd


I'd really like to get this up and running so if anyone has any
suggestions, I'm all ears.

Re: libata ignores non-dma disks?

[Jeff Garzik]

Ed Sweetman wrote:
> I'm using 2.6.16-rc6-ide1 (alan's patchset) and using the sata_nv and
> pata_amd drivers.  I have all UDMA drives except a CF disk -> IDE
> interface, which should be running in PIO mode4.   Libata detects the
> device, but spits out a message about "no dma" and then says it's not
> supported and is ignoring it.   Is this device not supported because
> it's not using dma or for some other reason?
> It's the only device on it's channel (secondary pata)
> 
> ata6: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 15
> ata6: dev 0 cfg 49:0e00 82:0000 83:0000 84:0000 85:0000 86:0000 87:0000
> 88:0000
> ata6: no dma
> ata6: dev 0 not supported, ignoring
> scsi5 : pata_amd

Delete the "no dma" check, and debug from there...  PIO support is in 
there, just needs a few final fixes.

	Jeff

[PATCH] libata: do not ignore PIO-only devices

[Tejun Heo]

As libata now can do PIO, don't ignore PIO-only devices.

Signed-off-by: Tejun Heo <htejun@gmail.com>

---

I'm currently away from my machines due to idiotic/useless national
reserve military training :-(, so I only compile tested it.  Ed, can
you please try the following patch and report the result?  Jeff,
please don't apply until Ed confirms.

 libata-core.c |    7 -------
 1 file changed, 7 deletions(-)

diff --git a/drivers/scsi/libata-core.c b/drivers/scsi/libata-core.c
index 714b42b..c4e528c 100644
--- a/drivers/scsi/libata-core.c
+++ b/drivers/scsi/libata-core.c
@@ -1219,13 +1219,6 @@ static int ata_dev_configure(struct ata_
 	 * common ATA, ATAPI feature tests
 	 */
 
-	/* we require DMA support (bits 8 of word 49) */
-	if (!ata_id_has_dma(id)) {
-		printk(KERN_DEBUG "ata%u: no dma\n", ap->id);
-		rc = -EINVAL;
-		goto err_out_nosup;
-	}
-
 	/* find max transfer mode; for printk only */
 	xfer_mask = ata_id_xfermask(id);
 

Re: [PATCH] libata: do not ignore PIO-only devices

[Tejun Heo]

Tejun Heo wrote:
> As libata now can do PIO, don't ignore PIO-only devices.
> 
> Signed-off-by: Tejun Heo <htejun@gmail.com>
> 
> ---
> 
> I'm currently away from my machines due to idiotic/useless national
> reserve military training :-(, so I only compile tested it.  Ed, can
> you please try the following patch and report the result?  Jeff,
> please don't apply until Ed confirms.
> 

More info. I've tested PIO only mode with several harddisks and PX716SA 
by nuking dma mask in ata_set_mode() in not-so-distant past (several 
weeks ago) and didn't have any problem.

-- 
tejun

Re: libata ignores non-dma disks?

[Ed Sweetman]

Jeff Garzik wrote:

> Ed Sweetman wrote:
>
>> I'm using 2.6.16-rc6-ide1 (alan's patchset) and using the sata_nv and
>> pata_amd drivers.  I have all UDMA drives except a CF disk -> IDE
>> interface, which should be running in PIO mode4.   Libata detects the
>> device, but spits out a message about "no dma" and then says it's not
>> supported and is ignoring it.   Is this device not supported because
>> it's not using dma or for some other reason?
>> It's the only device on it's channel (secondary pata)
>>
>> ata6: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 15
>> ata6: dev 0 cfg 49:0e00 82:0000 83:0000 84:0000 85:0000 86:0000 87:0000
>> 88:0000
>> ata6: no dma
>> ata6: dev 0 not supported, ignoring
>> scsi5 : pata_amd
>
>
> Delete the "no dma" check, and debug from there...  PIO support is in 
> there, just needs a few final fixes.
>
>     Jeff


Works perfectly now.   Thanks.   What isn't finished about it? 

anyways, here's an hdparm readout, for those that care.

CompactFlash ATA device, with removable media
        Model Number:       TOSHIBA THNCF512MPG
        Serial Number:      TSBC512M05928B66857C
        Firmware Revision:  1.00
Standards:
        Likely used: 4
Configuration:
        Logical         max     current
        cylinders       993     993
        heads           16      16
        sectors/track   63      63
        --
        bytes/track: 33264      bytes/sector: 528
        CHS current addressable sectors:    1000944
        LBA    user addressable sectors:    1000944
        device size with M = 1024*1024:         488 MBytes
        device size with M = 1000*1000:         512 MBytes
Capabilities:
        LBA, IORDY(can be disabled)
        Buffer size: 2.0kB      bytes avail on r/w long: 4      Queue 
depth: 1
        Standby timer values: spec'd by Vendor
        R/W multiple sector transfer: Max = 1   Current = 1
        DMA: not supported
        PIO: pio0 pio1 pio2 pio3 pio4
             Cycle time: no flow control=120ns  IORDY flow control=120ns

Re: [PATCH] libata: do not ignore PIO-only devices

[Jeff Garzik]

Tejun Heo wrote:
> As libata now can do PIO, don't ignore PIO-only devices.
> 
> Signed-off-by: Tejun Heo <htejun@gmail.com>

applied