[PATCH] libata: Add pata_dma option so users can disable pata_dma as they can with old-ide

[PATCH] libata: Add pata_dma option so users can disable pata_dma as they can with old-ide

[Alan Cox]

Allow

	libata.pata_dma=0

to disable DMA (default is 1)

SATA is unaffected as disabling DMA for SATA makes no sense at all.

Signed-off-by: Alan Cox <alan@redhat.com>

diff -u --new-file --recursive --exclude-from /usr/src/exclude linux.vanilla-2.6.22-rc4-mm2/drivers/ata/libata-core.c linux-2.6.22-rc4-mm2/drivers/ata/libata-core.c
--- linux.vanilla-2.6.22-rc4-mm2/drivers/ata/libata-core.c	2007-06-07 14:26:08.000000000 +0100
+++ linux-2.6.22-rc4-mm2/drivers/ata/libata-core.c	2007-06-07 16:53:43.000000000 +0100
@@ -94,6 +94,10 @@
 module_param_named(ignore_hpa, ata_ignore_hpa, int, 0644);
 MODULE_PARM_DESC(ignore_hpa, "Ignore HPA limit (0=keep BIOS limits, 1=ignore limits, using full disk)");
 
+static int ata_pata_dma = 1;
+module_param_named(pata_dma, ata_pata_dma, int, 0644);
+MODULE_PARM_DESC(pata_dma, "Use DMA on PATA devices");
+
 static int ata_probe_timeout = ATA_TMOUT_INTERNAL / HZ;
 module_param(ata_probe_timeout, int, 0444);
 MODULE_PARM_DESC(ata_probe_timeout, "Set ATA probing timeout (seconds)");
@@ -2815,7 +2831,12 @@
 		ata_dev_xfermask(dev);
 
 		pio_mask = ata_pack_xfermask(dev->pio_mask, 0, 0);
-		dma_mask = ata_pack_xfermask(0, dev->mwdma_mask, dev->udma_mask);
+		
+		if (ata_pata_dma || ap->cbl == ATA_CBL_SATA)
+			dma_mask = ata_pack_xfermask(0, dev->mwdma_mask, dev->udma_mask);
+		else
+			dma_mask = 0;
+
 		dev->pio_mode = ata_xfer_mask2mode(pio_mask);
 		dev->dma_mode = ata_xfer_mask2mode(dma_mask);
 

Re: [PATCH] libata: Add pata_dma option so users can disable pata_dma as they can with old-ide

[Mark Lord]

Alan Cox wrote:
> Allow
> 
> 	libata.pata_dma=0
> 
> to disable DMA (default is 1)
> 
> SATA is unaffected as disabling DMA for SATA makes no sense at all.
> 
> Signed-off-by: Alan Cox <alan@redhat.com>

Alan,

Should we really be piling up like this on global boot/module options
rather than run-time flags on individual channels/devices ?

I can imagine systems with internal notebook drives that want dma=1,
plus Cardbus CF devices that require dma=0.

With a single global flag, how does one do that?

Cheers

Re: [PATCH] libata: Add pata_dma option so users can disable pata_dma as they can with old-ide

[Alan Cox]

On Fri, 22 Jun 2007 11:01:09 -0400
Mark Lord <liml@rtr.ca> wrote:

> Alan Cox wrote:
> > Allow
> > 
> > 	libata.pata_dma=0
> > 
> > to disable DMA (default is 1)
> > 
> > SATA is unaffected as disabling DMA for SATA makes no sense at all.
> > 
> > Signed-off-by: Alan Cox <alan@redhat.com>
> 
> Alan,
> 
> Should we really be piling up like this on global boot/module options
> rather than run-time flags on individual channels/devices ?
> 
> I can imagine systems with internal notebook drives that want dma=1,
> plus Cardbus CF devices that require dma=0.
> 
> With a single global flag, how does one do that?

We need proper tuning as well but there is huge value (with distro hat
on especially) in a single "try this to get it installed and then we can
debug it" button. Same with the old IDE. Trying to guide users through
selecting specific channels/devices is going to be painful. I want
something that I can tell people to get them 'off the ground' and work
with them to sort the rest.

One possibility I did consider was it being a set of bit flags

Default 0x7

0x01		- Disk DMA
0x02		- CF DMA
0x04		- ATAPI DMA

then you'd tell folks "try 0" and "try 1" to get them up and going and
most would be blissfully unaware of the details of bitflags but still
happy

Jeff - any preference.

Re: [PATCH] libata: Add pata_dma option so users can disable pata_dma as they can with old-ide

[Mark Lord]

Alan Cox wrote:
> On Fri, 22 Jun 2007 11:01:09 -0400
> Mark Lord <liml@rtr.ca> wrote:
> 
>> Alan Cox wrote:
>>> Allow
>>>
>>> 	libata.pata_dma=0
>>>
>>> to disable DMA (default is 1)
>>>
>>> SATA is unaffected as disabling DMA for SATA makes no sense at all.
>>>
>>> Signed-off-by: Alan Cox <alan@redhat.com>
>> Alan,
>>
>> Should we really be piling up like this on global boot/module options
>> rather than run-time flags on individual channels/devices ?
>>
>> I can imagine systems with internal notebook drives that want dma=1,
>> plus Cardbus CF devices that require dma=0.
>>
>> With a single global flag, how does one do that?
> 
> We need proper tuning as well but there is huge value (with distro hat
> on especially) in a single "try this to get it installed and then we can
> debug it" button. Same with the old IDE. Trying to guide users through
> selecting specific channels/devices is going to be painful. I want
> something that I can tell people to get them 'off the ground' and work
> with them to sort the rest.

Oh for sure.  I'm just thinking that some form of on-the-fly tunable
would be of even greater value here, in addition to the boot/load default flag.

I think a /sys/ "dma" attribute (pick a name) might be most appropriate,
or we just just implement HDIO_[GS]ET_DMA as a simpler/lazier mechanism.

Cheers

Re: [PATCH] libata: Add pata_dma option so users can disable pata_dma as they can with old-ide

[Bartlomiej Zolnierkiewicz]

On Friday 22 June 2007, Mark Lord wrote:
> Alan Cox wrote:
> > On Fri, 22 Jun 2007 11:01:09 -0400
> > Mark Lord <liml@rtr.ca> wrote:
> > 
> >> Alan Cox wrote:
> >>> Allow
> >>>
> >>> 	libata.pata_dma=0
> >>>
> >>> to disable DMA (default is 1)
> >>>
> >>> SATA is unaffected as disabling DMA for SATA makes no sense at all.
> >>>
> >>> Signed-off-by: Alan Cox <alan@redhat.com>
> >> Alan,
> >>
> >> Should we really be piling up like this on global boot/module options
> >> rather than run-time flags on individual channels/devices ?
> >>
> >> I can imagine systems with internal notebook drives that want dma=1,
> >> plus Cardbus CF devices that require dma=0.
> >>
> >> With a single global flag, how does one do that?
> > 
> > We need proper tuning as well but there is huge value (with distro hat
> > on especially) in a single "try this to get it installed and then we can
> > debug it" button. Same with the old IDE. Trying to guide users through
> > selecting specific channels/devices is going to be painful. I want
> > something that I can tell people to get them 'off the ground' and work
> > with them to sort the rest.
> 
> Oh for sure.  I'm just thinking that some form of on-the-fly tunable
> would be of even greater value here, in addition to the boot/load default flag.
> 
> I think a /sys/ "dma" attribute (pick a name) might be most appropriate,
> or we just just implement HDIO_[GS]ET_DMA as a simpler/lazier mechanism.

The problem is that libata lacks any locking needed for having this
(and other useful) settings tunable on per device basis.

IDE has a needed locking although it sucks a lot (but is being reworked).

Bart

Re: [PATCH] libata: Add pata_dma option so users can disable pata_dma as they can with old-ide

[Alan Cox]

> > I think a /sys/ "dma" attribute (pick a name) might be most appropriate,
> > or we just just implement HDIO_[GS]ET_DMA as a simpler/lazier mechanism.
> 
> The problem is that libata lacks any locking needed for having this
> (and other useful) settings tunable on per device basis.

Actually libata does have the paths for it and uses them when drives are
hotplugged. Tejun posted an explanation of how to implement it a while
ago when I proposed a totally bogus implementation - it has to be done
via the EH code.

So we'd add user mode masks to each device and the sysfs nodes would
update that mask and trigger the EH processing to halt activity, retune
the disks and continue

Re: [PATCH] libata: Add pata_dma option so users can disable pata_dma as they can with old-ide

[Bartlomiej Zolnierkiewicz]

Hi,

On Friday 22 June 2007, Alan Cox wrote:
> > > I think a /sys/ "dma" attribute (pick a name) might be most appropriate,
> > > or we just just implement HDIO_[GS]ET_DMA as a simpler/lazier mechanism.
> > 
> > The problem is that libata lacks any locking needed for having this
> > (and other useful) settings tunable on per device basis.
> 
> Actually libata does have the paths for it and uses them when drives are
> hotplugged. Tejun posted an explanation of how to implement it a while
> ago when I proposed a totally bogus implementation - it has to be done
> via the EH code.

I must have missed the original discussion.

> So we'd add user mode masks to each device and the sysfs nodes would
> update that mask and trigger the EH processing to halt activity, retune
> the disks and continue

Sounds good.

Thanks,
Bart