- These revisions no longer have cable detection capability.
- The UDMA support bit of register 0x4b has been dropped without an
replacement.
- According to Linux it's crucial for working ATAPI DMA support to
also set the reserved bit 1 of regsiter 0x53 with these revisions.
MFC after: 1 week
native, i.e. big-endian, format and convert as appropriate like we
also do with the multibyte fields of the other pages. This fixes
the output of acd_describe() to match reality on big-endian machines
without breaking it on little-endian ones. While at it, also convert
the remaining multibyte fields of the pages read although they are
currently unused for consistency and in order to prevent possible
similar bugs in the future.
MFC after: 1 week
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)
normal in case of media read error and some ATAPI cases, when transfer size
is unknown beforehand. PCI ATA BM specification tells that in case of such
underrun driver should just manually stop DMA engine. DMA engine should
same time guarantie that all bus mastering transfers completed at the moment
of driver reads interrupt flag asserted.
This change should fix interrupt storms and command timeouts in many cases.
PR: kern/103602, sparc64/121539, kern/133122, kern/139654
long as I remember, and completely superseded by better maintained umass(4).
It's main idea was to optionally avoid CAM dependency for such devices, but
with move ATA to CAM, it is not actual any more.
No objections: hselasky@, thompsa@, arch@
Binary divider value 10 specified in datasheet is not a hex 0x10.
UDMA2 should be 33/2 instead of 66/4, which is documented as reverved,
UDMA4 should be 66/2 instead of 66/4, which is definitely wrong.
and Marvell handled. Instead of trying to attach two different drivers to
single device, wrapping each call, make one of them (atajmicron, atamarvell)
attach do device solely, but create child device for AHCI driver,
passing it all required resources. It is quite easy, as none of
resources are shared, except IRQ.
As result, it:
- makes drivers operation more independent and straitforward,
- allows to use new ahci(4) driver with such devices, adding support for
new features, such as PMP and NCQ, same time keeping legacy PATA support,
- will allow to just drop old ataahci driver, when it's time come.
These controllers provide combination of AHCI for SATA and legacy
PCI ATA for PATA. Use same solution as used for JMicron controllers.
Add IDs of Marvell 88SX6102, 88SX6111. 88SX6141 alike controllers
- Remove most of direct relations between ATA(4) peripherial and controller
levels. It makes logic more transparent and is a mandatory step to wrap
ATA(4) controller level into ATA-native CAM SIM.
- Tune AHCI and SATA2 SiI drivers memory allocation a bit to allow bigger
I/O transaction sizes without additional cost.
obsoleted in 1996 by ATA-2, and crashes some modern hardware like some
revisions of the Serverworks K2 SATA controller. Even very ancient
hardware seems not to require it. In the unlikely event this causes
problems, the previous behavior can be re-enabled by defining
ATA_LEGACY_SUPPORT at the top of this file.
Reviewed by: Alexander Motin <mav@freebsd.org>
and progif is evil. It doesn't work reliably[1] and we should honor BIOS
configuration by the user.
- If the SATA controller is enbled but combined mode is disabled, mask off
the emulated IDE channel on the legacy IDE controller.
Pointed out by: mav[1]
the work area was totally unsynchronized which means this driver only
had a chance of working on x86 when no bounce buffers were involved,
which isn't that likely given that support for 64-bit DMA is currently
broken throughout ata(4).
- Add necessary little-endian conversion of accesses to the work area,
making this driver work on big-endian hosts. While at it, use the
alignment-agnostic byte order encoders in order to be on the safe side.
- Clear the reserved member of the SG list entries in order to be on the
safe side. [1]
Submitted by: yongari [1]
Reviewed by: yongari
MFC after: 3 days
requirements. It is busdma task, to manage proper alignment by loading
data to bounce buffers.
PR: kern/127316
Reviewed by: current@
Tested by: Ryan Rogers
The newbus lock is responsible for protecting newbus internIal structures,
device states and devclass flags. It is necessary to hold it when all
such datas are accessed. For the other operations, softc locking should
ensure enough protection to avoid races.
Newbus lock is automatically held when virtual operations on the device
and bus are invoked when loading the driver or when the suspend/resume
take place. For other 'spourious' operations trying to access/modify
the newbus topology, newbus lock needs to be automatically acquired and
dropped.
For the moment Giant is also acquired in some key point (modules subsystem)
in order to avoid problems before the 8.0 release as module handlers could
make assumptions about it. This Giant locking should go just after
the release happens.
Please keep in mind that the public interface can be expanded in order
to provide more support, if there are really necessities at some point
and also some bugs could arise as long as the patch needs a bit of
further testing.
Bump __FreeBSD_version in order to reflect the newbus lock introduction.
Reviewed by: ed, hps, jhb, imp, mav, scottl
No answer by: ariff, thompsa, yongari
Tested by: pho,
G. Trematerra <giovanni dot trematerra at gmail dot com>,
Brandon Gooch <jamesbrandongooch at gmail dot com>
Sponsored by: Yahoo! Incorporated
Approved by: re (ksmith)
requesting IDENTIFY from slave device first. This order is important
for proper cable type detection by master device.
PR: kern/136438
Approved by: re (kib)
modularize it so that new transports can be created.
Add a transport for SATA
Add a periph+protocol layer for ATA
Add a driver for AHCI-compliant hardware.
Add a maxio field to CAM so that drivers can advertise their max
I/O capability. Modify various drivers so that they are insulated
from the value of MAXPHYS.
The new ATA/SATA code supports AHCI-compliant hardware, and will override
the classic ATA driver if it is loaded as a module at boot time or compiled
into the kernel. The stack now support NCQ (tagged queueing) for increased
performance on modern SATA drives. It also supports port multipliers.
ATA drives are accessed via 'ada' device nodes. ATAPI drives are
accessed via 'cd' device nodes. They can all be enumerated and manipulated
via camcontrol, just like SCSI drives. SCSI commands are not translated to
their ATA equivalents; ATA native commands are used throughout the entire
stack, including camcontrol. See the camcontrol manpage for further
details. Testing this code may require that you update your fstab, and
possibly modify your BIOS to enable AHCI functionality, if available.
This code is very experimental at the moment. The userland ABI/API has
changed, so applications will need to be recompiled. It may change
further in the near future. The 'ada' device name may also change as
more infrastructure is completed in this project. The goal is to
eventually put all CAM busses and devices until newbus, allowing for
interesting topology and management options.
Few functional changes will be seen with existing SCSI/SAS/FC drivers,
though the userland ABI has still changed. In the future, transports
specific modules for SAS and FC may appear in order to better support
the topologies and capabilities of these technologies.
The modularization of CAM and the addition of the ATA/SATA modules is
meant to break CAM out of the mold of being specific to SCSI, letting it
grow to be a framework for arbitrary transports and protocols. It also
allows drivers to be written to support discrete hardware without
jeopardizing the stability of non-related hardware. While only an AHCI
driver is provided now, a Silicon Image driver is also in the works.
Drivers for ICH1-4, ICH5-6, PIIX, classic IDE, and any other hardware
is possible and encouraged. Help with new transports is also encouraged.
Submitted by: scottl, mav
Approved by: re
MAXPHYS. Current ataahci driver memory allocation scheme includes only
64 items in DMA S/G table, and so not guarantied to support transactions
with more then 252K data.
Approved by: re (kensmith)
MFC after: 2 weeks
is invalid because the ioctl happens without prior open. The ioctl
got introduced to provide backward compatibility for extended
partitions, but it ended up not being used because it didn't work
as expected. Since there are no consumers of the ioctl and the
implementation is broken, the best fix is to remove the code
entirely.
Spotted by: phk
Approved by: re (kensmith)
