Commit Graph

5 Commits

Author SHA1 Message Date
Marius Strobl
1510a2b019 Several chipset drivers alter parameters relevant for the DMA tag creation,
i.e. alignment, max_address, max_iosize and segsize (only max_address is
thought to have an negative impact regarding this issue though), after
calling ata_dmainit() either directly or indirectly so these values have
no effect or at least no effect on the DMA tags and the defaults are used
for the latter instead. So change the drivers to set these parameters
up-front and ata_dmainit() to honor them.

Reviewd by:	mav
MFC after:	1 month
2010-11-28 18:53:29 +00:00
Alexander Motin
066f913a94 MFp4:
Introduce ATA_CAM kernel option, turning ata(4) controller drivers into
cam(4) interface modules. When enabled, this options deprecates all ata(4)
peripheral drivers (ad, acd, ...) and interfaces and allows cam(4) drivers
(ada, cd, ...) and interfaces to be natively used instead.

As side effect of this, ata(4) mode setting code was completely rewritten
to make controller API more strict and permit above change. While doing
this, SATA revision was separated from PATA mode. It allows DMA-incapable
SATA devices to operate and makes hw.ata.atapi_dma tunable work again.

Also allow ata(4) controller drivers (except some specific or broken ones)
to handle larger data transfers. Previous constraint of 64K was artificial
and is not really required by PCI ATA BM specification or hardware.

Submitted by:	nwitehorn (powerpc part)
2009-12-06 00:10:13 +00:00
Alexander Motin
f95dcaae42 MFp4:
Reduce default PCI ATA drivers priorities from absolute to default,
to allow them been overriden. It was so before modularization.
2009-06-24 19:49:18 +00:00
John Baldwin
dd8c8a8e43 - For chipsets that can't do 64k transfers, fall back to 32k transfers
(still a power of 2) rather than 63k transfers.  Even with 63k transfers
  some machines (such as Dell SC1435's) were experiencing chronic data
  corruption.
- Use the MIO method to talk to the Serverworks HT1000_S1 SATA controller
  like all the other SATA controllers rather than the compat PATA
  method.  This lets the controller see all 4 SATA ports and also
  matches the behavior of the Linux driver.

Silence from:	sos
MFC after:	3 days
2008-10-17 16:03:37 +00:00
Søren Schmidt
13014ca04a This is the roumored ATA modulerisation works, and it needs a little explanation.
If you just config KERNEL as usual there should be no apparent changes, you'll get all chipset support code compiled in.

However there is now a way to only compile in code for chipsets needed on a pr vendor basis. ATA now has the following "device" entries:

atacore:	ATA core functionality, always needed for any ATA setup

atacard:	CARDBUS support
atacbus:	PC98 cbus support
ataisa:		ISA bus support
atapci:		PCI bus support only generic chipset support.

ataahci:	AHCI support, also pulled in by some vendor modules.

ataacard, ataacerlabs, ataadaptec, ataamd, ataati, atacenatek, atacypress, atacyrix, atahighpoint, ataintel, ataite, atajmicron, atamarvell, atamicron, atanational, atanetcell, atanvidia, atapromise, ataserverworks, atasiliconimage, atasis, atavia;	Vendor support, ie atavia for VIA chipsets

atadisk:	ATA disk driver
ataraid:	ATA softraid driver

atapicd:	ATAPI cd/dvd driver
atapifd:	ATAPI floppy/flashdisk driver
atapist:	ATAPI tape driver

atausb:		ATA<>USB bridge
atapicam:	ATA<>CAM bridge

This makes it possible to config a kernel with just VIA chipset support by having the following ATA lines in the kernel config file:

device          atacore
device          atapci
device          atavia

And then you need the atadisk, atapicd etc lines in there just as usual.

If you use ATA as modules loaded at boot there is few changes except the rename of the "ata" module to "atacore", things looks just as usual.
However under atapci you now have a whole bunch of vendor specific drivers, that you can kldload individually depending on you needs. Drivers have the same names as used in the kernel config explained above.
2008-10-09 12:56:57 +00:00