Re: ATA passthrough questions

Re: ATA passthrough questions

[Bartlomiej Zolnierkiewicz]

Hi,

On 1/9/06, Matt Gillette <Matt.Gillette@netcell.com> wrote:
> Hi,
>
> I have a few questions about ata passthrough. Our controller creates
> its own ATA commands to configure the device, so I need full access to
> the taskfile when sending commands to the controller/drive.

What do you need to configure using non-standard commands?  RAID?

> Could someone tell me why CONFIG_IDE_TASKFILE is disabled by default?

Well, because it is experimental/dangerous/unfinished.
However some distributions enable it by default.

> Is www.kernel.org/pub/linux/kernel/people/jgarzik/libata the place to
> get information on libata? Or are there other places anyone can
> recommend?After glancing at the pdf, it looks like the function

http://linux.yyz.us/sata/

> HDIO_DRIVE_TASKFILE is called ata_tf_to_host in libata - is this
> right?Does this command need to be enabled in the kernel configuration
> options ala CONFIG_IDE_TASKFILE? Is there any open source code that
> uses theata_tf_to_host command so I can see it in action?

Do you need to this from driver of from user-space application?

If the former please give some link to the source code
so we could see what libata functions are needed.

If the latter than are using ATA pass-through interface
you need to issue specially prepared SG_IO ioctl instead.

Thanks,
Bartlomiej

Re: ATA passthrough questions

[Matt Gillette]

Bartlomiej,

Thank you for answering my questions - responses inline

On Jan 19, 2006, at 3:54 AM, Bartlomiej Zolnierkiewicz wrote:
> Hi,
> On 1/9/06, Matt Gillette <Matt.Gillette@netcell.com> wrote:
>> Hi,
>> I have a few questions about ata passthrough. Our controller creates
>> its own ATA commands to configure the device, so I need full  
>> access to
>> the taskfile when sending commands to the controller/drive.
> What do you need to configure using non-standard commands?  RAID?

RAID. The netcell controller is a hardware raid. We have two ways to  
configure it - through bios and using vendor specific ata commands.

>> Could someone tell me why CONFIG_IDE_TASKFILE is disabled by default?
>
> Well, because it is experimental/dangerous/unfinished.
> However some distributions enable it by default.

Is this still being worked on (ie, will it ever be enabled by default)?

Also, if you know the distributions, could you name a couple that  
enable it?

>> Is www.kernel.org/pub/linux/kernel/people/jgarzik/libata the place to
>> get information on libata? Or are there other places anyone can
>> recommend?After glancing at the pdf, it looks like the function
>
> http://linux.yyz.us/sata/

Exactly what I was looking for - thanks.

>> HDIO_DRIVE_TASKFILE is called ata_tf_to_host in libata - is this
>> right?Does this command need to be enabled in the kernel  
>> configuration
>> options ala CONFIG_IDE_TASKFILE? Is there any open source code that
>> uses theata_tf_to_host command so I can see it in action?
>
> Do you need to this from driver of from user-space application?
>
> If the former please give some link to the source code
> so we could see what libata functions are needed.

We are hoping to send these commands from a user-space application.  
Currently we don't have our own driver. We added our vendor/device  
ids to ide-generic so everything is handled by that driver. Now that  
our ids are in kernel.org, I was hoping to find a way to send these  
ATA commands down to our card without requiring another change to the  
kernel.

One question that I have is what's the difference between the older  
ide drivers and libata. What is the future of the ide driver - is it  
going to be phased out and replaced by libata, or will they both  
remain in the kernel and developed in parallel.

Also, I'm unclear about using libata - do we need to have a driver in  
libata to use its functionality, or does our current driver (ide- 
generic) allow us to use libata's passthrough. Our card currently  
doesn't implement any sata features, but it could in the future. If  
we wanted to use these features (say Command Queueing) what is needed  
to get support.

> If the latter than are using ATA pass-through interface
> you need to issue specially prepared SG_IO ioctl instead.

This looks like it could do the trick. Two questions - is this  
enabled by default, and are there any open source projects where I  
can see it being used?

> Thanks,
> Bartlomiej

Thanks,
Matt

Re: ATA passthrough questions

[Mark Lord]

Matt Gillette wrote:
 >
> One question that I have is what's the difference between the older  ide 
> drivers and libata. What is the future of the ide driver - is it  going 
> to be phased out and replaced by libata, or will they both  remain in 
> the kernel and developed in parallel.

The older IDE layer, which I once wrote and maintained, is on the way out.
The original code there wasn't designed for a hotplug world, and has lots
of issues nowadays from years of neglect, bloat, and a changed world.

Anything new should really target libata, or have its own native block driver.

Cheers

Mark

Libata Driver

[Matt Gillette]

I'm still trying to understand what needs to be done, so please  
correct me if I'm wrong.

The netcell card currently uses the ide-generic driver in the old ide  
layer. This is incompatible with libata so a new driver is needed.

I don't see a driver in the scsi (libata) drivers that is as generic  
as the ide driver was (all we needed to add was our vendor and device  
id). Because there is no generic driver, I need to write a driver  
compatible with libata. This new driver should be fairly simple since  
our card only needs the standard IDE taskfile registers set up. Does  
anyone have suggestions on which drivers that I should look at to  
help write our driver (a driver close to being generic)?

If I do write a libata driver, will there be conflicts with the  
generic ide driver? Do I need to remove our vendor id's from this?

Thank you,
Matt


On Jan 19, 2006, at 12:51 PM, Mark Lord wrote:

> Matt Gillette wrote:
> >
>> One question that I have is what's the difference between the  
>> older  ide drivers and libata. What is the future of the ide  
>> driver - is it  going to be phased out and replaced by libata, or  
>> will they both  remain in the kernel and developed in parallel.
>
> The older IDE layer, which I once wrote and maintained, is on the  
> way out.
> The original code there wasn't designed for a hotplug world, and  
> has lots
> of issues nowadays from years of neglect, bloat, and a changed world.
>
> Anything new should really target libata, or have its own native  
> block driver.
>
> Cheers
>
> Mark

Re: Libata Driver

[Mark Lord]

Matt Gillette wrote:
> I'm still trying to understand what needs to be done, so please correct 
> me if I'm wrong.
> 
> The netcell card currently uses the ide-generic driver in the old ide 
> layer. This is incompatible with libata so a new driver is needed.
> 
> I don't see a driver in the scsi (libata) drivers that is as generic as 
> the ide driver was (all we needed to add was our vendor and device id).

Yeah, no generic driver (yet).  Probably because each chipset still seems
to invent it's own mechanism for programming the DMA/PIO timings (something
that ide-generic somewhat-unsafely relied on the BIOS to do).  So you need
a really simple driver, with code to set up the timings if needed,
and just a bunch of binding of standard libata functions to do everything else.
It all ends up being quite simple once figured out.

> Because there is no generic driver, I need to write a driver compatible 
> with libata. This new driver should be fairly simple since our card only 
> needs the standard IDE taskfile registers set up. Does anyone have 
> suggestions on which drivers that I should look at to help write our 
> driver (a driver close to being generic)?

I'll leave it for somebody else to recommend something.
Alan Cox is currently reimplementing libata support for most of the
existing IDE driver chipsets -- he could probably provide a nice
simple almost generic driver for you to hack.

Alan?

> If I do write a libata driver, will there be conflicts with the generic 
> ide driver? Do I need to remove our vendor id's from this?

Yes, and yes.

Cheers