Bart's efforts?

Bart's efforts?

[Greg Freemyer]

Jeff / Alan,

I mostly lurk here, but I know there is a long term effort/ToDo to
move libata away from the SCSI infrastructure.

I've also seen that Bart has been making a large number of
improvements to drivers/ide over the last little while.  From my
limited perspective, many changes appear to be to the core
infrastructure.

My question is if the drivers/ide infrastructure is slowly moving in
the direction of being leverageable by libata when/if it moves out of
scsi.  Or does the drivers/ide code simply have the wrong kind of
plumbing for libata to ever use.

Thanks
Greg
-- 
Greg Freemyer
Litigation Triage Solutions Specialist
http://www.linkedin.com/in/gregfreemyer
First 99 Days Litigation White Paper -
http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf

The Norcross Group
The Intersection of Evidence & Technology
http://www.norcrossgroup.com

Re: Bart's efforts?

[Jeff Garzik]

Greg Freemyer wrote:
> Jeff / Alan,
> 
> I mostly lurk here, but I know there is a long term effort/ToDo to
> move libata away from the SCSI infrastructure.
> 
> I've also seen that Bart has been making a large number of
> improvements to drivers/ide over the last little while.  From my
> limited perspective, many changes appear to be to the core
> infrastructure.
> 
> My question is if the drivers/ide infrastructure is slowly moving in
> the direction of being leverageable by libata when/if it moves out of
> scsi.  Or does the drivers/ide code simply have the wrong kind of
> plumbing for libata to ever use.

One of my key goals with libata was to "make a driver look like a 
driver" and greatly improve upon the IDE driver API, which was a 
complete and utter piece of garbage (this is no reflection on Bart, he 
inherited it).  As a result, each driver is a fully fledged 
PCI/SCSI/ATA/platform driver, without anything getting in the way.  That 
made things like controller hotplug trivial to support from day one.

Bart has definitely made many good improvements, but I don't think 
people would be surprised that I feel CONFIG_IDE is legacy...

	Jeff

Re: Bart's efforts?

[Greg Freemyer]

Thanks,

I was just curious.

On 11/3/07, Jeff Garzik <jeff@garzik.org> wrote:
> Greg Freemyer wrote:
> > Jeff / Alan,
> >
> > I mostly lurk here, but I know there is a long term effort/ToDo to
> > move libata away from the SCSI infrastructure.
> >
> > I've also seen that Bart has been making a large number of
> > improvements to drivers/ide over the last little while.  From my
> > limited perspective, many changes appear to be to the core
> > infrastructure.
> >
> > My question is if the drivers/ide infrastructure is slowly moving in
> > the direction of being leverageable by libata when/if it moves out of
> > scsi.  Or does the drivers/ide code simply have the wrong kind of
> > plumbing for libata to ever use.
>
> One of my key goals with libata was to "make a driver look like a
> driver" and greatly improve upon the IDE driver API, which was a
> complete and utter piece of garbage (this is no reflection on Bart, he
> inherited it).  As a result, each driver is a fully fledged
> PCI/SCSI/ATA/platform driver, without anything getting in the way.  That
> made things like controller hotplug trivial to support from day one.
>
> Bart has definitely made many good improvements, but I don't think
> people would be surprised that I feel CONFIG_IDE is legacy...
>
>         Jeff
>
>
>
>
>
>


-- 
Greg Freemyer
Litigation Triage Solutions Specialist
http://www.linkedin.com/in/gregfreemyer
First 99 Days Litigation White Paper -
http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf

The Norcross Group
The Intersection of Evidence & Technology
http://www.norcrossgroup.com

Re: Bart's efforts?

[Alan Cox]

> My question is if the drivers/ide infrastructure is slowly moving in
> the direction of being leverageable by libata when/if it moves out of
> scsi.  Or does the drivers/ide code simply have the wrong kind of
> plumbing for libata to ever use.

I don't think there is anything useful in old IDE that isn't in the new.
However libata PATA support is not all new code, its built on and from
the old IDE driver code. Similarly there is stuff recently going on in
drivers/ide that is then going into drivers/ata (eg the IVB blacklists).

The big issue with drivers/ide is the core code which simply can't cope
with SMP or modern hardware designs.   don't consider drivers/ide
anything but "legacy" but lots of older systems use it and its important
it stays maintained. Bart is doing whats actually a pretty thankless job
- working on maintaining stuff for the short term knowing it has no real
future.

Alan

Re: Bart's efforts?

[Felix Miata]

On 2007/11/03 14:10 (GMT) Alan Cox apparently typed:

> I don't think there is anything useful in old IDE that isn't in the new.

You mean besides being able to access all existing disk partitions? Google
can show you I'm not the only multiboot upgrader with far more than 14
filesystems per disk. The standard drivers should be able to provide access
to every standard partition fdisk/cfdisk/sfdisk or any other conforming
partitioning tool is able to create. LVM should not be prerequisite to using
SATA for those who need many low level logical disk subdivisions.

Disk /dev/hda: 250.0 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/hda1               1          13      104391   17  Hidden HPFS/NTFS
/dev/hda2   *          14          14        8032+   a  OS/2 Boot Manager
/dev/hda3              15          46      257040    6  FAT16
/dev/hda4              48       30401   243818505    5  Extended
/dev/hda5              48          73      208813+  83  Linux
/dev/hda6              74         188      923706   82  Linux swap / Solaris
/dev/hda7             189         800     4915858+  83  Linux
/dev/hda8            1108        1108        8001    1  FAT12
/dev/hda9            1109        1140      257008+   6  FAT16
/dev/hda10           1142        1243      819283+   7  HPFS/NTFS
/dev/hda11           1269        1523     2048256    7  HPFS/NTFS
/dev/hda12           1575        1693      955836    7  HPFS/NTFS
/dev/hda13           1694        2012     2562336    7  HPFS/NTFS
/dev/hda14           2014        2217     1638598+  83  Linux
/dev/hda15           2218        2568     2819376   83  Linux
/dev/hda16           2569        3486     7373803+  83  Linux
/dev/hda17           3487        4379     7172991   83  Linux
/dev/hda18           4380        4409      240943+  83  Linux
/dev/hda19           4410        4549     1124518+  83  Linux
/dev/hda20           4550        5187     5124703+  83  Linux
/dev/hda21          18234       18845     4915858+  83  Linux
/dev/hda22          18846       19457     4915858+  83  Linux
/dev/hda23          20383       20391       72261   83  Linux
/dev/hda24          20392       30401    80405293+  83  Linux

> However libata PATA support is not all new code, its built on and from
> the old IDE driver code. Similarly there is stuff recently going on in
> drivers/ide that is then going into drivers/ata (eg the IVB blacklists).

> The big issue with drivers/ide is the core code which simply can't cope
> with SMP or modern hardware designs.   don't consider drivers/ide
> anything but "legacy" but lots of older systems use it and its important
> it stays maintained. Bart is doing whats actually a pretty thankless job
> - working on maintaining stuff for the short term knowing it has no real
> future.
-- 
"   A patriot without religion . . . is as great a
paradox, as an honest man without the fear of God."
	                             John Adams

 Team OS/2 ** Reg. Linux User #211409

Felix Miata  ***  http://mrmazda.no-ip.com/

Re: Bart's efforts?

[Mikael Pettersson]

On Sat, 3 Nov 2007 14:10:22 +0000, Alan Cox wrote:
> > My question is if the drivers/ide infrastructure is slowly moving in
> > the direction of being leverageable by libata when/if it moves out of
> > scsi.  Or does the drivers/ide code simply have the wrong kind of
> > plumbing for libata to ever use.
> 
> I don't think there is anything useful in old IDE that isn't in the new.

For semi-modern machines that might be true. However:

1) there's no libata replacement for the IDE pmac driver
2) pata_pdc202xx_old can't do UDMA on my 440BX PIII box
3) pata_legacy doesn't release io/irq combinations for failed
   probes, causing conflicts with drivers loaded later on

(Not a complaint, just a reminder that rm -rf drivers/ide/
isn't an option yet.)

Re: Bart's efforts?

[Alan Cox]

> > I don't think there is anything useful in old IDE that isn't in the new.
> 
> You mean besides being able to access all existing disk partitions? Google

Al Viro vetoed this support in the SCSI core. Take it up with him. The
libata layer is happy with lots of partitions but it needs a change for
sparse minors, or your distribution to use device mapper to do the work.

Alan

Re: Bart's efforts?

[Alan Cox]

> 1) there's no libata replacement for the IDE pmac driver

This is true currently. David Woodhouse loaned me a Pmac to fix that but
it died so thats waiting for the PPC people to do something about it.

> 2) pata_pdc202xx_old can't do UDMA on my 440BX PIII box

Bug # ?

> 3) pata_legacy doesn't release io/irq combinations for failed
>    probes, causing conflicts with drivers loaded later on

In my tree it does but I'm still testing some bits. I've been rewriting
the legacy driver to make it a lot cleaner and easy to plug other ISA/VLB
device handlers into it.

Re: Bart's efforts?

[Mikael Pettersson]

Alan Cox wrote:
>> 2) pata_pdc202xx_old can't do UDMA on my 440BX PIII box
>
>Bug # ?

No bz # yet, but you and I had a private email conversation about
this on March 13 and 15 this year.

There's been a couple of recent reports to linux-ide with identical
(as far as I can see) issues as I get:
<http://marc.info/?l=linux-ide&m=119152811824641&w=2>
<http://marc.info/?l=linux-ide&m=118890476223188&w=2>
<http://marc.info/?l=linux-ide&m=118855473322630&w=2>

I'll add a bugzilla entry for this next week so it doesn't get lost.

>> 3) pata_legacy doesn't release io/irq combinations for failed
>>    probes, causing conflicts with drivers loaded later on
>
>In my tree it does but I'm still testing some bits.

Good news.

/Mikael

Re: Bart's efforts?

[Mark Lord]

delkin_cb is also missing from libata.

I was going to port it over once, but no longer have a cardbus slot
in either of my notebooks here.

Cheers

Re: Bart's efforts?

[Alan Cox]

On Wed, 07 Nov 2007 17:37:07 -0500
Mark Lord <liml@rtr.ca> wrote:

> delkin_cb is also missing from libata.
> 
> I was going to port it over once, but no longer have a cardbus slot
> in either of my notebooks here.

Yes I looked at it but it didn't have any proper speed setting, so I
decided it wasn't actually worth doing.

Alan

Re: Bart's efforts?

[Mark Lord]

Alan Cox wrote:
> On Wed, 07 Nov 2007 17:37:07 -0500
> Mark Lord <liml@rtr.ca> wrote:
> 
>> delkin_cb is also missing from libata.
>>
>> I was going to port it over once, but no longer have a cardbus slot
>> in either of my notebooks here.
> 
> Yes I looked at it but it didn't have any proper speed setting, so I
> decided it wasn't actually worth doing.
..

Yeah.  No docs whatsoever, but there's more than a few users
of it out there.

Cheers

Re: Bart's efforts?

[Alan Cox]

> Yeah.  No docs whatsoever, but there's more than a few users
> of it out there.

So how do we handle devices that don't support PIO4 ?

Other than the speed handling mystery the port is trivial.

Alan

Re: Bart's efforts?

[Mark Lord]

Alan Cox wrote:
>> Yeah.  No docs whatsoever, but there's more than a few users
>> of it out there.
> 
> So how do we handle devices that don't support PIO4 ?
..

I'm not actually sure that it's even running that fast (PIO4), 
as the performance is still only half of what Windoze gets.

I have a logic analyzer here, but no Cardbus extender to hook it onto.

Re: Bart's efforts?

[Mikael Pettersson]

Mikael Pettersson writes:
 > On Sat, 3 Nov 2007 14:10:22 +0000, Alan Cox wrote:
 > > > My question is if the drivers/ide infrastructure is slowly moving in
 > > > the direction of being leverageable by libata when/if it moves out of
 > > > scsi.  Or does the drivers/ide code simply have the wrong kind of
 > > > plumbing for libata to ever use.
 > > 
 > > I don't think there is anything useful in old IDE that isn't in the new.
 > 
 > For semi-modern machines that might be true. However:
 > 
...
 > 2) pata_pdc202xx_old can't do UDMA on my 440BX PIII box

See <http://bugzilla.kernel.org/show_bug.cgi?id=9337> for details.

Delkin Cardbus IDE, a.k.a. ASKA "Ninja" chipset

[Mark Lord]

Mark Lord wrote:
> Alan Cox wrote:
>> On Wed, 07 Nov 2007 17:37:07 -0500
>> Mark Lord <liml@rtr.ca> wrote:
>>
>>> delkin_cb is also missing from libata.
>>>
>>> I was going to port it over once, but no longer have a cardbus slot
>>> in either of my notebooks here.
>>
>> Yes I looked at it but it didn't have any proper speed setting, so I
>> decided it wasn't actually worth doing.
> ..
> 
> Yeah.  No docs whatsoever, but there's more than a few users
> of it out there.
...

Mmmm.. the NetBSD people seem to have detailed information on these chips!
There seems to be more than enough information in the NetBSD sources
to implement full timings support and full bus-master DMA support:

http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/ic/ninjaata32var.h?rev=1.3&content-type=text/x-cvsweb-markup
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/ic/ninjaata32reg.h?rev=1.3&content-type=text/x-cvsweb-markup
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/ic/ninjaata32.c?rev=1.9&content-type=text/x-cvsweb-markup


Anyone want to take this on?

Cheers

Re: Delkin Cardbus IDE, a.k.a. ASKA "Ninja" chipset

[Mark Lord]

Mark Lord wrote:
> Mark Lord wrote:
>> Alan Cox wrote:
>>> On Wed, 07 Nov 2007 17:37:07 -0500
>>> Mark Lord <liml@rtr.ca> wrote:
>>>
>>>> delkin_cb is also missing from libata.
>>>>
>>>> I was going to port it over once, but no longer have a cardbus slot
>>>> in either of my notebooks here.
>>>
>>> Yes I looked at it but it didn't have any proper speed setting, so I
>>> decided it wasn't actually worth doing.
>> ..
>>
>> Yeah.  No docs whatsoever, but there's more than a few users
>> of it out there.
> ...
> 
> Mmmm.. the NetBSD people seem to have detailed information on these chips!
> There seems to be more than enough information in the NetBSD sources
> to implement full timings support and full bus-master DMA support:
> 
> http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/ic/ninjaata32var.h?rev=1.3&content-type=text/x-cvsweb-markup 
> 
> http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/ic/ninjaata32reg.h?rev=1.3&content-type=text/x-cvsweb-markup 
> 
> http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/ic/ninjaata32.c?rev=1.9&content-type=text/x-cvsweb-markup 
..

Plus the man page (which looks slightly out of date):

http://netbsd.gw.com/cgi-bin/man-cgi/man?njata+4+NetBSD-current

Re: Delkin Cardbus IDE, a.k.a. ASKA "Ninja" chipset

[Mark Lord]

Mark Lord wrote:
> Mark Lord wrote:
>> Mark Lord wrote:
>>> Alan Cox wrote:
>>>> On Wed, 07 Nov 2007 17:37:07 -0500
>>>> Mark Lord <liml@rtr.ca> wrote:
>>>>
>>>>> delkin_cb is also missing from libata.
>>>>>
>>>>> I was going to port it over once, but no longer have a cardbus slot
>>>>> in either of my notebooks here.
>>>>
>>>> Yes I looked at it but it didn't have any proper speed setting, so I
>>>> decided it wasn't actually worth doing.
>>> ..
>>>
>>> Yeah.  No docs whatsoever, but there's more than a few users
>>> of it out there.
>> ...
>>
>> Mmmm.. the NetBSD people seem to have detailed information on these 
>> chips!
>> There seems to be more than enough information in the NetBSD sources
>> to implement full timings support and full bus-master DMA support:
>>
>> http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/ic/ninjaata32var.h?rev=1.3&content-type=text/x-cvsweb-markup 
>>
>> http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/ic/ninjaata32reg.h?rev=1.3&content-type=text/x-cvsweb-markup 
>>
>> http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/ic/ninjaata32.c?rev=1.9&content-type=text/x-cvsweb-markup 
> 
> Plus the man page (which looks slightly out of date):
> 
> http://netbsd.gw.com/cgi-bin/man-cgi/man?njata+4+NetBSD-current
..

One more link, with many PCI IDs for these chips:

http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/cardbus/njata_cardbus.c?rev=1.5&content-type=text/x-cvsweb-markup

Re: Delkin Cardbus IDE, a.k.a. ASKA "Ninja" chipset

[Alan Cox]

On Mon, 12 Nov 2007 15:11:16 -0500
Mark Lord <liml@rtr.ca> wrote:

> Mark Lord wrote:
> > Alan Cox wrote:
> >> On Wed, 07 Nov 2007 17:37:07 -0500
> >> Mark Lord <liml@rtr.ca> wrote:
> >>
> >>> delkin_cb is also missing from libata.
> >>>
> >>> I was going to port it over once, but no longer have a cardbus slot
> >>> in either of my notebooks here.
> >>
> >> Yes I looked at it but it didn't have any proper speed setting, so I
> >> decided it wasn't actually worth doing.
> > ..
> > 
> > Yeah.  No docs whatsoever, but there's more than a few users
> > of it out there.
> ...
> 
> Mmmm.. the NetBSD people seem to have detailed information on these chips!
> There seems to be more than enough information in the NetBSD sources
> to implement full timings support and full bus-master DMA support:
> 
> http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/ic/ninjaata32var.h?rev=1.3&content-type=text/x-cvsweb-markup
> http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/ic/ninjaata32reg.h?rev=1.3&content-type=text/x-cvsweb-markup
> http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/ic/ninjaata32.c?rev=1.9&content-type=text/x-cvsweb-markup
> 
> 
> Anyone want to take this on?

I'll knock a driver out next week providing someone with hardware is
willing to be test monkey.

Alan

Re: Delkin Cardbus IDE, a.k.a. ASKA "Ninja" chipset

[Mark Lord]

Alan Cox wrote:
> On Mon, 12 Nov 2007 15:11:16 -0500
> Mark Lord <liml@rtr.ca> wrote:
> 
>> Mark Lord wrote:
>>> Alan Cox wrote:
>>>> On Wed, 07 Nov 2007 17:37:07 -0500
>>>> Mark Lord <liml@rtr.ca> wrote:
>>>>
>>>>> delkin_cb is also missing from libata.
>>>>>
>>>>> I was going to port it over once, but no longer have a cardbus slot
>>>>> in either of my notebooks here.
>>>> Yes I looked at it but it didn't have any proper speed setting, so I
>>>> decided it wasn't actually worth doing.
>>> ..
>>>
>>> Yeah.  No docs whatsoever, but there's more than a few users
>>> of it out there.
>> ...
>>
>> Mmmm.. the NetBSD people seem to have detailed information on these chips!
>> There seems to be more than enough information in the NetBSD sources
>> to implement full timings support and full bus-master DMA support:
>>
>> http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/ic/ninjaata32var.h?rev=1.3&content-type=text/x-cvsweb-markup
>> http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/ic/ninjaata32reg.h?rev=1.3&content-type=text/x-cvsweb-markup
>> http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/ic/ninjaata32.c?rev=1.9&content-type=text/x-cvsweb-markup
>>
>>
>> Anyone want to take this on?
> 
> I'll knock a driver out next week providing someone with hardware is
> willing to be test monkey.

I've got hardware here that you can have, if you want it.
It's just a cardbus CF adapter, and neither of my own notebooks have slots.

Email me privately with mailing address if you want it.

Cheers

Re: Delkin Cardbus IDE, a.k.a. ASKA "Ninja" chipset

[Alan Cox]

First guess

/*
 * pata_ninja32.c 	- Ninja32 PATA for new ATA layer
 *			  (C) 2007 Red Hat Inc
 *			  Alan Cox <alan@redhat.com>
 *
 * Note: The controller like many controllers has shared timings for
 * PIO and DMA. We thus flip to the DMA timings in dma_start and flip back
 * in the dma_stop function. Thus we actually don't need a set_dmamode
 * method as the PIO method is always called and will set the right PIO
 * timing parameters.
 *
 * The Ninja32 Cardbus is not a generic SFF controller. Instead it is
 * laid out as follows off BAR 0. This is based upon Mark Lord's delkin
 * driver and the extensive analysis done by the BSD developers, notably
 * ITOH Yasufumi.
 *
 *	Base + 0x00 IRQ Status
 *	Base + 0x01 IRQ control
 *	Base + 0x02 Chipset control
 *	Base + 0x04 VDMA and reset control + wait bits
 *	Base + 0x08 BMIMBA
 *	Base + 0x0C DMA Length
 *	Base + 0x10 Taskfile
 *	Base + 0x18 BMDMA Status ?
 *	Base + 0x1C
 *	Base + 0x1D Bus master control
 *		bit 0 = enable
 *		bit 1 = 0 write/1 read
 *		bit 2 = 1 sgtable
 *		bit 3 = go
 *		bit 4-6 wait bits
 *		bit 7 = done
 *	Base + 0x1E AltStatus
 *	Base + 0x1F timing register
 */

#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/pci.h>
#include <linux/init.h>
#include <linux/blkdev.h>
#include <linux/delay.h>
#include <scsi/scsi_host.h>
#include <linux/libata.h>

#define DRV_NAME "pata_ninja32"
#define DRV_VERSION "0.0.1"

/**
 *	ninja32_configure_piomode	-	set chip PIO timing
 *	@ap: ATA interface
 *	@adev: ATA device
 *	@pio: PIO mode
 *
 *	Called to do the PIO mode setup. Our timing registers are shared
 *	so a configure_dmamode call will undo any work we do here and vice
 *	versa
 */

static void ninja32_configure_piomode(struct ata_port *ap, struct ata_device *adev, int pio)
{
	static u16 pio_timing[5] = {
		0xd6, 0x85, 0x44, 0x33, 0x13
	};
	iowrite8(pio_timing[pio], ap->ioaddr.bmdma_addr + 0x1f);
}

/**
 *	ninja32_set_piomode	-	set initial PIO mode data
 *	@ap: ATA interface
 *	@adev: ATA device
 *
 *	Called to do the PIO mode setup. Our timing registers are shared
 *	but we want to set the PIO timing by default.
 */

static void ninja32_set_piomode(struct ata_port *ap, struct ata_device *adev)
{
	ninja32_configure_piomode(ap, adev, adev->pio_mode - XFER_PIO_0);
}

static struct scsi_host_template ninja32_sht = {
	.module			= THIS_MODULE,
	.name			= DRV_NAME,
	.ioctl			= ata_scsi_ioctl,
	.queuecommand		= ata_scsi_queuecmd,
	.can_queue		= ATA_DEF_QUEUE,
	.this_id		= ATA_SHT_THIS_ID,
	.sg_tablesize		= LIBATA_MAX_PRD,
	.cmd_per_lun		= ATA_SHT_CMD_PER_LUN,
	.emulated		= ATA_SHT_EMULATED,
	.use_clustering		= ATA_SHT_USE_CLUSTERING,
	.proc_name		= DRV_NAME,
	.dma_boundary		= ATA_DMA_BOUNDARY,
	.slave_configure	= ata_scsi_slave_config,
	.slave_destroy		= ata_scsi_slave_destroy,
	.bios_param		= ata_std_bios_param,
};

static struct ata_port_operations ninja32_port_ops = {
	.set_piomode	= ninja32_set_piomode,
	.mode_filter	= ata_pci_default_filter,

	.tf_load	= ata_tf_load,
	.tf_read	= ata_tf_read,
	.check_status 	= ata_check_status,
	.exec_command	= ata_exec_command,
	.dev_select 	= ata_std_dev_select,

	.freeze		= ata_bmdma_freeze,
	.thaw		= ata_bmdma_thaw,
	.error_handler	= ata_bmdma_error_handler,
	.post_internal_cmd = ata_bmdma_post_internal_cmd,
	.cable_detect	= ata_cable_40wire,

	.bmdma_setup 	= ata_bmdma_setup,
	.bmdma_start 	= ata_bmdma_start,
	.bmdma_stop	= ata_bmdma_stop,
	.bmdma_status 	= ata_bmdma_status,

	.qc_prep 	= ata_qc_prep,
	.qc_issue	= ata_qc_issue_prot,

	.data_xfer	= ata_data_xfer,

	.irq_handler	= ata_interrupt,
	.irq_clear	= ata_bmdma_irq_clear,
	.irq_on		= ata_irq_on,

	.port_start	= ata_sff_port_start,
};

static int ninja32_init_one(struct pci_dev *dev, const struct pci_device_id *id)
{
	struct ata_host *host;
	struct ata_port *ap;
	void __iomem *base;
	int rc;
	
	host = ata_host_alloc(&dev->dev, 1);
	if (!host)
		return -ENOMEM;
	ap = host->ports[0];

	/* Set up the PCI device */
	rc = pcim_enable_device(dev);
	if (rc)
		return rc;
	rc = pcim_iomap_regions(dev, 1 << 0, DRV_NAME);
	if (rc == -EBUSY)
		pcim_pin_device(dev);
	if (rc)
		return rc;

	host->iomap = pcim_iomap_table(dev);
	rc = pci_set_dma_mask(dev, ATA_DMA_MASK);
	if (rc)
		return rc;
	rc = pci_set_consistent_dma_mask(dev, ATA_DMA_MASK);
	if (rc)
		return rc;
	pci_set_master(dev);
		
	/* Set up the register mappings */
	base = host->iomap[0];
	if (!base)
		return -ENOMEM;
	ap->ops = &ninja32_port_ops;
	ap->pio_mask = 0x1F;
	ap->flags |= ATA_FLAG_SLAVE_POSS;
	
	ap->ioaddr.cmd_addr = base + 0x10;
	ap->ioaddr.ctl_addr = base + 0x1E;
	ap->ioaddr.altstatus_addr = base + 0x1E;
	ap->ioaddr.bmdma_addr = base;
	ata_std_ports(&ap->ioaddr);
	
	return ata_host_activate(host, dev->irq, ata_interrupt, IRQF_SHARED, &ninja32_sht);
}

static const struct pci_device_id ninja32[] = {
	{ 0x1145, 0xf021, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
	{ 0x1145, 0xf024, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
	{ },
};

static struct pci_driver ninja32_pci_driver = {
	.name 		= DRV_NAME,
	.id_table	= ninja32,
	.probe 		= ninja32_init_one,
	.remove		= ata_pci_remove_one
};

static int __init ninja32_init(void)
{
	return pci_register_driver(&ninja32_pci_driver);
}

static void __exit ninja32_exit(void)
{
	pci_unregister_driver(&ninja32_pci_driver);
}

MODULE_AUTHOR("Alan Cox");
MODULE_DESCRIPTION("low-level driver for Ninja32 ATA");
MODULE_LICENSE("GPL");
MODULE_DEVICE_TABLE(pci, ninja32);
MODULE_VERSION(DRV_VERSION);

module_init(ninja32_init);
module_exit(ninja32_exit);

Re: Delkin Cardbus IDE, a.k.a. ASKA "Ninja" chipset

[Mark Lord]

Alan wrote:
> First guess
> 
> /*
>  * pata_ninja32.c 	- Ninja32 PATA for new ATA layer
..

Okay, I tried it on the wife's notebook.
It needs the patch below to enable chip interrupts,
and it is *very* slow on I/O (1MB/sec), slower even
than delkin_cb at present.

But it does work, with this patch:

Signed-off-by: Mark Lord <mlord@pobox.com>
---
(I still have hardware here to send you..)

--- old/pata_ninja32.c	2007-11-13 23:06:21.000000000 -0500
+++ new/pata_ninja32.c	2007-11-13 23:49:24.000000000 -0500
@@ -169,6 +169,7 @@
 	ap->pio_mask = 0x1F;
 	ap->flags |= ATA_FLAG_SLAVE_POSS;
 	
+	iowrite8(0x05, base + 1);
 	ap->ioaddr.cmd_addr = base + 0x10;
 	ap->ioaddr.ctl_addr = base + 0x1E;
 	ap->ioaddr.altstatus_addr = base + 0x1E;