Please help me to understand the interaction of the various ATA drivers

Please help me to understand the interaction of the various ATA drivers

[Andy Falanga (afalanga)]

Jeff,

I don't know if you're still the maintainer of these drivers but you're
listed as the original author of the code in the 2.6 kernel which I'm
working on modifying.  I have to write a driver which I can expose
access to the various HBA and Port registers for an AHCI class HBA.  In
addition, this driver must act as a pass through driver for my clients
to be able to execute ATA commands.  I'd like for it to be a true pass
through driver and not have to run through the kernel's schedules and
such, but that's another discussion.

My question for you is simply, how are these various drivers supposed to
work together?  On the VM which I'm doing my development, I see the
following from lsmod:

# lsmod
...
ahci                      41208         2
pata_acpi                  3701         0
ata_generic                3837         0
ata_piix                  24409         1
...


This at least shows me that none of these modules depend upon one
another for functionality.  However, to some level, they must be
interrelated.  

Thanks for any light you can shed on this for me.

Andy

Re: Please help me to understand the interaction of the various ATA drivers

[Hendrik Visage]

Hi Andy,

 I'm not involved in the development etc. but just a few notes below:

On Wed, Apr 29, 2015 at 11:38 PM, Andy Falanga (afalanga)
<afalanga@micron.com> wrote:
> Jeff,
>
> I don't know if you're still the maintainer of these drivers but you're
> listed as the original author of the code in the 2.6 kernel which I'm
> working on modifying.  I have to write a driver which I can expose
> access to the various HBA and Port registers for an AHCI class HBA.  In
> addition, this driver must act as a pass through driver for my clients
> to be able to execute ATA commands.  I'd like for it to be a true pass
> through driver and not have to run through the kernel's schedules and
> such, but that's another discussion.
>
> My question for you is simply, how are these various drivers supposed to
> work together?  On the VM which I'm doing my development, I see the
> following from lsmod:
>
> # lsmod
> ...
> ahci                      41208         2

^^^This is (as you might know) the "new" ATA "standard" interface, and
that AFAIK should be the device the filesystem etc. would talk to.

> pata_acpi                  3701         0

>From *me* understanding, that would be related to the IDE, aka
Parallel ATA, interface, and acpi is the BIOS/DMI/system description
stuff, so that would tell the OS what IDE/PATA/etc. options is
inside/described by the ACPI in some or other method.

> ata_generic                3837         0

>From *my* understanding: that was one of the first/early methods to
combine the IDE/pata with SATA

> ata_piix                  24409         1

The PIIX stuff is an Intel class of chipsets with a similar interface,
and I recall the PIIX4 being a very prominent one years gone back,
providing the IDE interface, and then also the SATA interface in an
IDE emulation/compatible format/method.

> ...
>
>
> This at least shows me that none of these modules depend upon one
> another for functionality.  However, to some level, they must be
> interrelated.

What I would expect from what you've mentioned, is that your VM is
emulating an Intel PIIX(4?) chipset, with IDE and SATA options
(perhaps the CD-rom is on the IDE interface??)

>
> Thanks for any light you can shed on this for me.
>
> Andy

Re: Please help me to understand the interaction of the various ATA drivers

[One Thousand Gnomes]

On Wed, 29 Apr 2015 21:38:41 +0000
"Andy Falanga (afalanga)" <afalanga@micron.com> wrote:

> Jeff,
> 
> I don't know if you're still the maintainer of these drivers but you're
> listed as the original author of the code in the 2.6 kernel which I'm

Think Jeff is mostly off doing wonderous things with Bitcoin. 

> working on modifying.  I have to write a driver which I can expose
> access to the various HBA and Port registers for an AHCI class HBA.  In
> addition, this driver must act as a pass through driver for my clients
> to be able to execute ATA commands.  I'd like for it to be a true pass
> through driver and not have to run through the kernel's schedules and
> such, but that's another discussion.

Then you probably need to make the existing kernel drivers skip whatever
specific device you are driving directly (I assume for things like
validation ?)

> My question for you is simply, how are these various drivers supposed to
> work together?  On the VM which I'm doing my development, I see the
> following from lsmod:
> 
> # lsmod
> ...
> ahci                      41208         2
> pata_acpi                  3701         0
> ata_generic                3837         0
> ata_piix                  24409         1

ata_generic is a bus mastering driver for PCI IDE class devices. In your
case its been loaded for some reason but is not being used

pata_acpi is a driver for ACPI described generic interfaces, and again is
not being used

ata_piix is a driver specifically for Intel PIIX/ICH interfaces in legacy
mode and does seem to be getting used, so presumably your virtual machine
has at least one legacy mode PIIX or ICH emulated on it

ahci is a driver for controllers that are AHCI class, or match a few
identifiers for AHCI controllers not declaring themselves AHCI class (eg
those that try and hide from Windows AHCI drivers so proprietary raid
products can be used with them on Windows)

So I think you'd need to

a) modify ahci to ignore your specific device in its probe method
b) write a simple driver so you can poke the ports and do any needed DMA

Alan

Re: Please help me to understand the interaction of the various ATA drivers

[Andy Falanga (afalanga)]

-----Original Message-----
From: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
To: Andy Falanga (afalanga) <afalanga@micron.com>
Subject: Re: Please help me to understand the interaction of the various
ATA drivers
Date: Thu, 30 Apr 2015 11:43:06 +0100

On Wed, 29 Apr 2015 21:38:41 +0000
"Andy Falanga (afalanga)" <afalanga@micron.com> wrote:

>> Jeff,
>> 
>> I don't know if you're still the maintainer of these drivers but you're
>> listed as the original author of the code in the 2.6 kernel which I'm

> Think Jeff is mostly off doing wonderous things with Bitcoin. 

I'm wonderfully out of touch.  Ha, I had to look up Bitcoin.


>> My question for you is simply, how are these various drivers supposed to
>> work together?  On the VM which I'm doing my development, I see the
>> following from lsmod:
>> 
>> # lsmod
>> ...
>> ahci                      41208         2
>> pata_acpi                  3701         0
>> ata_generic                3837         0
>> ata_piix                  24409         1

> ata_generic is a bus mastering driver for PCI IDE class devices. In your
> case its been loaded for some reason but is not being used

> pata_acpi is a driver for ACPI described generic interfaces, and again is
> not being used

I had figured out that pata_acpi was for IDE devices but I hadn't figured
that ata_generic was.  Thanks.  Yes, my VM placed a CD drive on the PATA
interface.  As you know, my application needn't worry about this one.

> ata_piix is a driver specifically for Intel PIIX/ICH interfaces in legacy
> mode and does seem to be getting used, so presumably your virtual machine
> has at least one legacy mode PIIX or ICH emulated on it

I can ignore this one as well it would seem.


> ahci is a driver for controllers that are AHCI class, or match a few
> identifiers for AHCI controllers not declaring themselves AHCI class (eg
> those that try and hide from Windows AHCI drivers so proprietary raid
> products can be used with them on Windows)

This is the one I was hoping I could tap into.  That is, I was hoping to
write a high-level driver, exposing a device node, which I could just pass
requests to ahci.ko.  Sounds like this may be more trouble that it's worth
given that you're suggesting I modify it to ignore the hardware I'd like
to control and write a simple driver to so.  The one drawback is that my
driver really needs to work with all AHCI devices.  This would mean I either
remove ahci or hamstring it to ignore all AHCI hardware.

> So I think you'd need to
>
> a) modify ahci to ignore your specific device in its probe method
> b) write a simple driver so you can poke the ports and do any needed DMA

Thanks for the suggestions.  This gives me something to go on.

Andy

Re: Please help me to understand the interaction of the various ATA drivers

[Christoph Hellwig]

Why don't you just send your ATA taskfile as ATA_12 or ATA_16 CDB
through the device node ans save yourself all the work of writing a
driver?

Re: Please help me to understand the interaction of the various ATA drivers

[Andy Falanga (afalanga)]

> -----Original Message-----
> From: Christoph Hellwig <hch@infradead.org>
> To: Andy Falanga (afalanga) <afalanga@micron.com>
> Subject: Re: Please help me to understand the interaction of the
> various ATA drivers
> Date: Thu, 30 Apr 2015 08:09:54 -0700
> 
> Why don't you just send your ATA taskfile as ATA_12 or ATA_16 CDB
> through the device node ans save yourself all the work of writing a
> driver?

2 reasons mainly.  First, I have a need to read the entire HBA and port
register set.  Second, in some situations, a device node isn't present.

Having said that, however, what you propose interests me.  Forgive my
ignorance but it sounds like there's a method of executing ATA commands
without using sg.  Is this true?