Parallel ATA with libata status with the patches I'm working on

Parallel ATA with libata status with the patches I'm working on

[Alan Cox]

Core Features Fixed
- Per drive tuning
- Filter quirk lists
- Single channel support

And To Add
- Specify PCI bus speed
- HPA
- IRQ mask
- PIO only LBA48
- Serialize
- CRC downspeed
- Mixed legacy/native mode (most work done)

Drivers so far written for the libata parallel work I'm doing

ALI
Driver written with equivalent support to the drivers/ide one. Needs
core changes for LBA48 PIO only

AMD
Driver written, given basic testing and equivalent to current
drivers/ide

CS5520
Driver written, some debug work to do. Works unlike the drivers/ide one

CS5530
Works single channel needs core changes for dual

CS5535
Written but untested

HPT34X
Driver written, functionality same as drivers/ide. Needs more testing.

HPT36x
Support done for chips up to 302. No 372N/302N or PLL support yet

IT821x
Written but needs further driver and core work yet

RZ1000
Written, simulation tested

SC1200
Written, needs core changes for dual channel

Serverworks
Written, equivalent functionality to drivers/ide plus some bugs fixed

SIL680
Written, tested, running. 

Triflex
Written tested, running

VIA
Written, tested on some controllers. Does not yet support the 6410 (TODO
item) and very early VIA (needs core changes)

'Generic'
Written, tested, needs polishing and some core changes ideally for irq
mask and for simplex

ISA Legacy
Work in progress

---------------

Unsupported Hardware

ACPI
TODO item - it's possible to drive unknown motherboard chipsets through
ACPI. Not supported by drivers/ide either

AEC62xx
ATIIXP
CMD64x
CY82C693
IT8172
NS87415
OPTI621
PDC202xx
SGI IOC4
SIS5513
SL82C105
SLC90E66
TRM290
PCMCIA (needs hotplug merge first)

Re: Parallel ATA with libata status with the patches I'm working on

[Russell King]

On Thu, Nov 03, 2005 at 02:54:46PM +0000, Alan Cox wrote:
> AEC62xx
> ATIIXP
> CMD64x
> CY82C693
> IT8172
> NS87415
> OPTI621
> PDC202xx
> SGI IOC4
> SIS5513
> SL82C105
> SLC90E66
> TRM290
> PCMCIA (needs hotplug merge first)

+ icside ?

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: Parallel ATA with libata status with the patches I'm working on

[Bartlomiej Zolnierkiewicz]

On 11/3/05, Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> On Thu, Nov 03, 2005 at 02:54:46PM +0000, Alan Cox wrote:
> > AEC62xx
> > ATIIXP
> > CMD64x
> > CY82C693
> > IT8172
> > NS87415
> > OPTI621
> > PDC202xx
> > SGI IOC4
> > SIS5513
> > SL82C105
> > SLC90E66
> > TRM290
> > PCMCIA (needs hotplug merge first)
>
> + icside ?

pmac
rapide
bast-ide
ide_arm
ide-cris
ide-h8300
mpc8xx
legacy stuff (optional?)...

IMO porting/rewriting host-drivers to libata now is just
counter-productive waste of time...

Bartlomiej

Re: Parallel ATA with libata status with the patches I'm working on

[David S. Miller]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Date: Thu, 3 Nov 2005 16:02:45 +0100

> IMO porting/rewriting host-drivers to libata now is just
> counter-productive waste of time...

This would be an interesting opinion if you were asked for it.
But you were not, yet you keep stating it, therefore you must
feel threatened in some way.

I have to admit that your handling of Alan's desire to do this work
makes you look very non-transparent as the IDE layer maintainer.

What do you care if Alan converts all the drivers with his own time
and effort?  If it's a waste of time, it's his time, which he can
spend in any way he so chooses.  You've already stated that you think
it's a waste of time on at least 2 or 3 occaisions, so I think he and
everyone else gets your point and you don't need to restate this over
and over again.

Re: Parallel ATA with libata status with the patches I'm working on

[Bartlomiej Zolnierkiewicz]

On 11/3/05, David S. Miller <davem@davemloft.net> wrote:
> From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> Date: Thu, 3 Nov 2005 16:02:45 +0100
>
> > IMO porting/rewriting host-drivers to libata now is just
> > counter-productive waste of time...
>
> This would be an interesting opinion if you were asked for it.
> But you were not, yet you keep stating it, therefore you must
> feel threatened in some way.

I'm worried about crap being pushed into libata, that's all.

Besides does current situation of ALSA and OSS bring any bells?

> I have to admit that your handling of Alan's desire to do this work
> makes you look very non-transparent as the IDE layer maintainer.

By reading linux-ide ML you will see that actually
I help in development of libata PATA support.

> What do you care if Alan converts all the drivers with his own time
> and effort?  If it's a waste of time, it's his time, which he can

Are you familiar with background discussions before Alan started
this work?  Never explained FUD about current state of drivers/ide,
personal attacks and replying to eny post relating to IDE with either
FUD or "IDE driver is going away"...

Alan plays dirty game and don't say me that this doesn't influnce
my work...

> spend in any way he so chooses.  You've already stated that you think
> it's a waste of time on at least 2 or 3 occaisions, so I think he and
> everyone else gets your point and you don't need to restate this over
> and over again.

OK, I'll shut up now.

Bartlomiej (no more mr nice guy)

Re: Parallel ATA with libata status with the patches I'm working on

[Alan Cox]

On Iau, 2005-11-03 at 16:48 +0100, Bartlomiej Zolnierkiewicz wrote:
> I'm worried about crap being pushed into libata, that's all.

I wouldn't be too worried. Jeff Garzik is quite fussy about what goes in
and that it gets designed the right way. Various things aren't currently
merged because Jeff wants them redone better - such as the ISA legacy
support.

Alan

Re: Parallel ATA with libata status with the patches I'm working on

[Alan Cox]

On Iau, 2005-11-03 at 16:02 +0100, Bartlomiej Zolnierkiewicz wrote:
> IMO porting/rewriting host-drivers to libata now is just
> counter-productive waste of time...

Face it, drivers/ide/ is beyong saving, it has entered the software
engineering twilight zone that follows 'maintainable'.

Shifting a non-complex driver to libata with a few libata improvements
is not a difficult process. Figuring out the extra hooks and bits to
make it clean is the difficult bit. Each time another PATA horror is
supported by libata it becomes easy for other cards with that horror to
be moved over.

Also drivers/ide contains detailed support for things that just aren't
worth moving over - like SWDMA.

Once the core support is done then quite frankly I'll be able to port a
PATA driver to libata faster than sherlock holmes could deduce the
drivers/ide locking "rules" let alone fix them.

Alan

Re: Parallel ATA with libata status with the patches I'm working on

[Krzysztof Halasa]

Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> writes:

> IMO porting/rewriting host-drivers to libata now is just
> counter-productive waste of time...

That would only make sense if you consider all PATA obsolete/dead
(do you? I'm sometimes not sure).

I don't and (unable to use old IDE due to hot-plug issues) am thankful
for Alan's efforts.

Yes, I think it's similar to OSS-ALSA, WRT - you know, 6-months forward
notice etc :-)
-- 
Krzysztof Halasa

Re: Parallel ATA with libata status with the patches I'm working on

[Bartlomiej Zolnierkiewicz]

On 11/3/05, Krzysztof Halasa <khc@pm.waw.pl> wrote:
> Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> writes:
>
> > IMO porting/rewriting host-drivers to libata now is just
> > counter-productive waste of time...
>
> That would only make sense if you consider all PATA obsolete/dead
> (do you? I'm sometimes not sure).

I want to merge old IDE driver w/ libata... and drop remaining crap on the way.
If libata gains full PATA support before I do this - it is even better for me...

> I don't and (unable to use old IDE due to hot-plug issues) am thankful
> for Alan's efforts.

Do you think that libata is currently so much better wrt to PATA
hot-(un)plug support?

If so than dream on...

> Yes, I think it's similar to OSS-ALSA, WRT - you know, 6-months forward
> notice etc :-)

Ain't going to happen...

Guys, I'm not against libata PATA support - I'm all for it but I want
TRANSPARENT development and FAIR look at current state of affairs
(there is still a lot of stuff on libata's PATA TODO)...

Plus I don't like needless bashing of IDE driver which is still messy
but orders of magnitude less than during 2.4.x days... :-)

Bartlomiej

Re: Parallel ATA with libata status with the patches I'm working on

[Krzysztof Halasa]

Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> writes:

> Do you think that libata is currently so much better wrt to PATA
> hot-(un)plug support?

For me? Libata works. Old IDE driver doesn't work. To be honest, haven't
checked since switched to libata, this problem might be fixed now.
-- 
Krzysztof Halasa

Re: Parallel ATA with libata status with the patches I'm working on

[Bartlomiej Zolnierkiewicz]

On 11/3/05, Krzysztof Halasa <khc@pm.waw.pl> wrote:
> Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> writes:
>
> > Do you think that libata is currently so much better wrt to PATA
> > hot-(un)plug support?
>
> For me? Libata works. Old IDE driver doesn't work. To be honest, haven't
> checked since switched to libata, this problem might be fixed now.

Are you talking about PATA here?

If no there is no point in further discussion (libata is the right choice)...

Bartlomiej

Re: Parallel ATA with libata status with the patches I'm working on

[Alan Cox]

On Iau, 2005-11-03 at 22:29 +0100, Bartlomiej Zolnierkiewicz wrote:
> Do you think that libata is currently so much better wrt to PATA
> hot-(un)plug support?

With the hot plug patches for SATA it certainly is. Mainstream it isn't.
Best is still 2.4-ac

> > Yes, I think it's similar to OSS-ALSA, WRT - you know, 6-months forward
> > notice etc :-)
> 
> Ain't going to happen...

I don't think this a six month project. Well no getting all the PCI
stuff sorted is a six month project. Knocking it into shape and cleaning
up corner cases and details is considerably more.

Still I've done atiixp, opt621 and it8172 this afternoon. 

Alan

Re: Parallel ATA with libata status with the patches I'm working on

[Rogério Brito]

On Nov 03 2005, Alan Cox wrote:
> Still I've done atiixp, opt621 and it8172 this afternoon. 

Do you want a guinea pig? I have a system with an Asus A7V motherboard
(with both via82xxxx and PDC20265 controllers) and also a notebook with
a 440BX/ZX chipset.

I'm willing to trash some installations of mine.

Hope this helps if you're looking for stupid^w^w^w^w^w^wbrave users. :-)


Thanks, Rogério.

-- 
Rogério Brito : rbrito@ime.usp.br : http://www.ime.usp.br/~rbrito
Homepage of the algorithms package : http://algorithms.berlios.de
Homepage on freshmeat:  http://freshmeat.net/projects/algorithms/

Re: Parallel ATA with libata status with the patches I'm working on

[Alan Cox]

On Iau, 2005-11-03 at 23:30 -0200, Rogério Brito wrote:
> On Nov 03 2005, Alan Cox wrote:
> > Still I've done atiixp, opt621 and it8172 this afternoon. 
> 
> Do you want a guinea pig? I have a system with an Asus A7V motherboard
> (with both via82xxxx and PDC20265 controllers) and also a notebook with
> a 440BX/ZX chipset.
> 
> I'm willing to trash some installations of mine.
> 
> Hope this helps if you're looking for stupid^w^w^w^w^w^wbrave users. :-)


Let me get the patches cleaned up and in order start of next week and
I'd be glad of testers. Especially if a 2.6.14-mm1 appears so I've got
something nice to diff against 8)

Alan

Re: Parallel ATA with libata status with the patches I'm working on

[Alan Cox]

While writing the new sl82c05 driver I noticed a real nasty lurking in
the old code. According to the errata docs you have to reset the DMA
engine every transfer to work around chip errata. It also says that this
resets any other ATA transfer in progress.

If both channels are in use there is no locking between the channels to
stop a reset on one channel as DMA begins making a mess of the other
channel. Looks like serialize should be set on the driver ?

Alan

Re: Parallel ATA with libata status with the patches I'm working on

[Russell King]

On Fri, Nov 04, 2005 at 01:41:06PM +0000, Alan Cox wrote:
> While writing the new sl82c05 driver I noticed a real nasty lurking in
> the old code. According to the errata docs you have to reset the DMA
> engine every transfer to work around chip errata. It also says that this
> resets any other ATA transfer in progress.
> 
> If both channels are in use there is no locking between the channels to
> stop a reset on one channel as DMA begins making a mess of the other
> channel. Looks like serialize should be set on the driver ?

Possibly, though benh needs to comment.  (I think benh has the only
hardware which has the possibility of both channels - the NetWinder
only has one channel with one disk.)

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: Parallel ATA with libata status with the patches I'm working on

[Benjamin Herrenschmidt]

On Fri, 2005-11-04 at 23:10 +0000, Russell King wrote:
> On Fri, Nov 04, 2005 at 01:41:06PM +0000, Alan Cox wrote:
> > While writing the new sl82c05 driver I noticed a real nasty lurking in
> > the old code. According to the errata docs you have to reset the DMA
> > engine every transfer to work around chip errata. It also says that this
> > resets any other ATA transfer in progress.
> > 
> > If both channels are in use there is no locking between the channels to
> > stop a reset on one channel as DMA begins making a mess of the other
> > channel. Looks like serialize should be set on the driver ?
> 
> Possibly, though benh needs to comment.  (I think benh has the only
> hardware which has the possibility of both channels - the NetWinder
> only has one channel with one disk.)

I don't have this hw anymore, it was a design I worked on for my
previous employer, years ago, I don't have access to it anymore and the
company doesn't exist anymore.

Ben.

Re: Parallel ATA with libata status with the patches I'm working on

[Alan Cox]

On Iau, 2005-11-03 at 14:48 +0000, Russell King wrote:
> 
> + icside ?
> 

I've not really looked much outside of the PCI space yet (my first goal
is to rescue the PC world and to get testing it wants x86 users) but
Jeffs core libata code is strictly bus agnostic.

Alan

Re: Parallel ATA with libata status with the patches I'm working on

[Russell King]

On Thu, Nov 03, 2005 at 03:58:03PM +0000, Alan Cox wrote:
> On Iau, 2005-11-03 at 14:48 +0000, Russell King wrote:
> > 
> > + icside ?
> > 
> 
> I've not really looked much outside of the PCI space yet (my first goal
> is to rescue the PC world and to get testing it wants x86 users) but
> Jeffs core libata code is strictly bus agnostic.

Ok, I look forward to fiddling with libata on ARM. 8)

You mentioned that libata doesn't do SWDMA - does it do MWDMA and PIO?

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: Parallel ATA with libata status with the patches I'm working on

[Alan Cox]

On Iau, 2005-11-03 at 15:30 +0000, Russell King wrote:
> Ok, I look forward to fiddling with libata on ARM. 8)
> 
> You mentioned that libata doesn't do SWDMA - does it do MWDMA and PIO?

Yes. MWDMA works well, PIO is pretty crap in the base -mm tree but much
improved in the devel trees. I've generally been running stuff pio
before adding the DMA code in fact.

Re: Parallel ATA with libata status with the patches I'm working on

[Jeff Garzik]

Russell King wrote:
> You mentioned that libata doesn't do SWDMA - does it do MWDMA and PIO?

It even supports polled PIO :)

	Jeff

Re: Parallel ATA with libata status with the patches I'm working on

[Jeff Garzik]

Alan Cox wrote:
> I've not really looked much outside of the PCI space yet (my first goal
> is to rescue the PC world and to get testing it wants x86 users) but
> Jeffs core libata code is strictly bus agnostic.

Some embedded dude (a Finn, I don't remember his name) wrote a libata 
SATA driver for his company's embedded SATA controller... on the ARM 
platform.

Though the driver itself hasn't appeared, libata is apparently working 
quite well with this embedded, non-PCI, ARM SATA chip.

	Jeff

Re: Parallel ATA with libata status with the patches I'm working on

[Xavier Bestel]

On Fri, 2005-11-04 at 04:35, Jeff Garzik wrote:

> Some embedded dude (a Finn, I don't remember his name) wrote a libata 
> SATA driver for his company's embedded SATA controller... on the ARM 
> platform.

Finn Thain ?

Re: Parallel ATA with libata status with the patches I'm working on

[Bartlomiej Zolnierkiewicz]

On 11/3/05, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> Core Features Fixed
> - Per drive tuning
> - Filter quirk lists
> - Single channel support

Are these the same changes that have been recently pushed into
Linus' tree without any previous public review or some new ones?

> And To Add
> - Specify PCI bus speed
> - HPA
> - IRQ mask
> - PIO only LBA48
> - Serialize
> - CRC downspeed
> - Mixed legacy/native mode (most work done)
>
> Drivers so far written for the libata parallel work I'm doing

Are the patches available somewhere?

> ALI
> Driver written with equivalent support to the drivers/ide one. Needs
> core changes for LBA48 PIO only
>
> AMD
> Driver written, given basic testing and equivalent to current
> drivers/ide

Functionality can't be the same as drivers/ide because libata
lacks some core features.

> CS5520
> Driver written, some debug work to do. Works unlike the drivers/ide one

Please fix drivers/ide also if not a big problem.

> HPT34X
> Driver written, functionality same as drivers/ide. Needs more testing.

Same comment as for AMD.

> Serverworks
> Written, equivalent functionality to drivers/ide plus some bugs fixed

Ditto.  Also please backport fixes to drivers/ide.

Thanks,
Bartlomiej

Re: Parallel ATA with libata status with the patches I'm working on

[Alan Cox]

On Iau, 2005-11-03 at 15:58 +0100, Bartlomiej Zolnierkiewicz wrote:
> On 11/3/05, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > Core Features Fixed
> > - Per drive tuning
> > - Filter quirk lists
> > - Single channel support
> 
> Are these the same changes that have been recently pushed into
> Linus' tree without any previous public review or some new ones?

Some of the changes have gone to Jeff Garzik others are pending
improvments/driver fixes for existing drivers and testing before Jeff
accepts them. Beyond that its up to Jeff what is merged into -mm and on.

> > Drivers so far written for the libata parallel work I'm doing
> 
> Are the patches available somewhere?

Yes. I'll post updated sets at some point soon. The patch I posted
pointers to before is now well out of date.

> > AMD
> > Driver written, given basic testing and equivalent to current
> > drivers/ide
> 
> Functionality can't be the same as drivers/ide because libata
> lacks some core features.

Well duh, other than core differences. Functionality is indeed different
- CRC errors dont crash SMP boxes for example ;)

> > CS5520
> > Driver written, some debug work to do. Works unlike the drivers/ide one
> 
> Please fix drivers/ide also if not a big problem.

I started this work in part because it was impossible to work with you.
I've no interest in fixing drivers/ide and in fact I'm now running as
much as I can with CONFIG_IDE=n, because the only way to really test
code is to use it all the time.

The things I've fixed however if you want to go fix them in drivers/ide
are

CS5520 is totally broken. You want the fixes I sent you over a year ago
and maybe more. Its probably best left as I doubt anyone else has a 5520
any more 8)

Serverworks runs the wrong cable detect routine in some cases
(conditions ordered wrongly)

I think the HPT366 driver contains several bugs looking at it in
comparison with hpts driver and the data sheets I can get hold of. It's
hard to be sure however because at times all three disagree with each
other. In particular it doesn't know about 302N but think its a 37x and
the PLL tune code appears to be unrelated to either data sheet or hpt
code. Can't be sure yet on the PLL until I've got PLL modes working in
the libata driver.


Alan (drivers/ide elimination department)

Re: Parallel ATA with libata status with the patches I'm working on

[Bartlomiej Zolnierkiewicz]

On 11/3/05, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> On Iau, 2005-11-03 at 15:58 +0100, Bartlomiej Zolnierkiewicz wrote:
> > On 11/3/05, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > > Core Features Fixed
> > > - Per drive tuning
> > > - Filter quirk lists
> > > - Single channel support
> >
> > Are these the same changes that have been recently pushed into
> > Linus' tree without any previous public review or some new ones?
>
> Some of the changes have gone to Jeff Garzik others are pending
> improvments/driver fixes for existing drivers and testing before Jeff
> accepts them. Beyond that its up to Jeff what is merged into -mm and on.

Of course it is up to Jeff but still it would be nice to see them on linux-ide
ML before hitting -mm or mainline...

> > > Drivers so far written for the libata parallel work I'm doing
> >
> > Are the patches available somewhere?
>
> Yes. I'll post updated sets at some point soon. The patch I posted
> pointers to before is now well out of date.
>
> > > AMD
> > > Driver written, given basic testing and equivalent to current
> > > drivers/ide
> >
> > Functionality can't be the same as drivers/ide because libata
> > lacks some core features.
>
> Well duh, other than core differences. Functionality is indeed different
> - CRC errors dont crash SMP boxes for example ;)
>
> > > CS5520
> > > Driver written, some debug work to do. Works unlike the drivers/ide one
> >
> > Please fix drivers/ide also if not a big problem.
>
> I started this work in part because it was impossible to work with you.

Yes, I don't ack patches only because name of the submitter... ;)

> I've no interest in fixing drivers/ide and in fact I'm now running as
> much as I can with CONFIG_IDE=n, because the only way to really test
> code is to use it all the time.
>
> The things I've fixed however if you want to go fix them in drivers/ide
> are
>
> CS5520 is totally broken. You want the fixes I sent you over a year ago
> and maybe more. Its probably best left as I doubt anyone else has a 5520
> any more 8)
>
> Serverworks runs the wrong cable detect routine in some cases
> (conditions ordered wrongly)

OK, thanks for the hint.

> I think the HPT366 driver contains several bugs looking at it in
> comparison with hpts driver and the data sheets I can get hold of. It's
> hard to be sure however because at times all three disagree with each
> other. In particular it doesn't know about 302N but think its a 37x and
> the PLL tune code appears to be unrelated to either data sheet or hpt
> code. Can't be sure yet on the PLL until I've got PLL modes working in
> the libata driver.
>
>
> Alan (drivers/ide elimination department)

I see... same goal here but in more peaceful way...

Bartlomiej

Re: Parallel ATA with libata status with the patches I'm working on

[Mark Lord]

 >CS5520 is totally broken. You want the fixes I sent you over a year ago
 >and maybe more. Its probably best left as I doubt anyone else has a 5520
 >any more 8)

Send them to me.  I still have the original pre-production CS5520 system
that I used to implement the original (working) driver with.

Thanks.
-- 
Mark Lord
Real-Time Remedies Inc.
mlord@pobox.com

Re: Parallel ATA with libata status with the patches I'm working on

[Mark Lord]

Mark Lord wrote:
>  >CS5520 is totally broken. You want the fixes I sent you over a year ago
>  >and maybe more. Its probably best left as I doubt anyone else has a 5520
>  >any more 8)
> 
> Send them to me.  I still have the original pre-production CS5520 system
> that I used to implement the original (working) driver with.

Oh, wait.  No, I wrote the CS5530 driver, not the 5520.

Is that one okay, or do you also have patches for it (5530)?

Thanks
-- 
Mark Lord
Real-Time Remedies Inc.
mlord@pobox.com

Re: Parallel ATA with libata status with the patches I'm working on

[Alan Cox]

On Iau, 2005-11-03 at 19:17 -0500, Mark Lord wrote:
> Oh, wait.  No, I wrote the CS5530 driver, not the 5520.
> 
> Is that one okay, or do you also have patches for it (5530)?

I've got a test pata driver for the 5530 but not yet added MWDMA/UDMA
switching when the master and slave are in different modes.

The 5520 is a rather different device and quite complex as it implements
virtual DMA (it does PIO0->PIO4 via a PCI IDE DMA interface)

Re: Parallel ATA with libata status with the patches I'm working on

[Jeff Garzik]

My general take on things:

* Supporting PATA has always been a long term libata goal (and people 
have known this for years).

* I try to stay as far as possible away from the fight between Alan and 
Bart.  As the changelog shows, I've merged libata patches from both.

* Alan's patches do tend to come straight to me, and it would be nice if 
he CC'd them to a list (linux-ide).

* Nonetheless, they get exposure in -mm (via libata-dev.git) for a 
while, before going upstream.

* The non-core changes, i.e. Alan and Albert's PATA drivers, aren't 
going upstream for a while, and will be instead living in -mm (via my 
"pata-drivers" libata-dev.git branch)  Too much breakage and user 
confusion will occur if they are pushed {today|soon}.

* CONFIG_IDE=n is still largely for developers and brave souls only (or 
for lucky owners of the newest boxes, which simply don't have PATA on 
them at all).

Re: Parallel ATA with libata status with the patches I'm working on

[Mark Lord]

Jeff Garzik wrote:
>
> * CONFIG_IDE=n is still largely for developers and brave souls only (or 
> for lucky owners of the newest boxes, which simply don't have PATA on 
> them at all).

So, basically the average new user of Linux these days, then.
Installing on a new machine.  No PATA.

Cheers!

Re: Parallel ATA with libata status with the patches I'm working on

[Benjamin Herrenschmidt]

On Thu, 2005-11-03 at 14:54 +0000, Alan Cox wrote:
> Core Features Fixed
> - Per drive tuning
> - Filter quirk lists
> - Single channel support
> 
> And To Add
> - Specify PCI bus speed

Please, do the above such a way that we can have an arch hook for the
bus speed. It's actually not uncommon to have several busses with
different speeds in a machine. In addition, I've seen IDE drivers
calculating based on the bus speed while the HW apparently used a clock
source that didn't necessarily had to be ... PciClk ... Oh well...

> - HPA
> - IRQ mask

Why do we need the above at all ? It always looked to me like a gross
hack but then, I don't fully understand what the problem was on those
old x86 that needed it :)

> AEC62xx
> ATIIXP
> CMD64x
> CY82C693
> IT8172
> NS87415
> OPTI621
> PDC202xx
> SGI IOC4
> SIS5513
> SL82C105
> SLC90E66
> TRM290
> PCMCIA (needs hotplug merge first)

Add ppc/pmac.c but its up to me to do it :)

Ben.

Re: Parallel ATA with libata status with the patches I'm working on

[Jeff Garzik]

Benjamin Herrenschmidt wrote:
>>- HPA
>>- IRQ mask
> 
> 
> Why do we need the above at all ? It always looked to me like a gross
> hack but then, I don't fully understand what the problem was on those
> old x86 that needed it :)


Not sure about IRQ mask.

For host-protected area (HPA), I've been thinking about a dm-hpa driver, 
which libata causes to auto-attach to the libata-discovered disks during 
probe.

That gives people full access to the disk (and to the HPA), while 
ensuring that there are no partition mismatch issues.

Not sure how well it will work out in practice, but it's worth thinking 
about.

If auto-attach/etc. doesn't work, I lean towards defaulting libata to 
enable access to the HPA, under the philosophy "export 100% of the 
hardware".  Then an interested party could create an optional dm-hpa 
piece, to split 100%-of-the-hardware into two pieces, one a 
partitionable device, and the other, the HPA.

	Jeff

Re: Parallel ATA with libata status with the patches I'm working on

[Alan Cox]

On Gwe, 2005-11-04 at 17:43 +1100, Benjamin Herrenschmidt wrote:
> > - HPA
> > - IRQ mask
> 
> Why do we need the above at all ? It always looked to me like a gross
> hack but then, I don't fully understand what the problem was on those
> old x86 that needed it :)

You can't do anything useful with some systems without disabling the HPA
because it is used to mask most of the drive at boot to hide from old
incompatible BIOS.

IRQ mask is on my todo list and looks quite easy. A small number of
controllers mishandle the case when the FIFO empties. Instead of
stalling the drive they dribble random numbers. 

> > ATIIXP
> > IT8172
> > OPTI621

Did initial drivers for those three yesterday

> > SL82C105

And that one last night/this morning although it (and the old one) both
need serialize to fix bugs.

Alan

Re: Parallel ATA with libata status with the patches I'm working on

[Benjamin Herrenschmidt]

On Fri, 2005-11-04 at 13:34 +0000, Alan Cox wrote:
> On Gwe, 2005-11-04 at 17:43 +1100, Benjamin Herrenschmidt wrote:
> > > - HPA
> > > - IRQ mask
> > 
> > Why do we need the above at all ? It always looked to me like a gross
> > hack but then, I don't fully understand what the problem was on those
> > old x86 that needed it :)
> 
> You can't do anything useful with some systems without disabling the HPA
> because it is used to mask most of the drive at boot to hide from old
> incompatible BIOS.

I know, I was talking about IRQ Mask :)

> IRQ mask is on my todo list and looks quite easy. A small number of
> controllers mishandle the case when the FIFO empties. Instead of
> stalling the drive they dribble random numbers. 

OK, but my question why, what is the reason why we need IRQ mask ? Some
old non-PCI controllers can't grok un-related ISA IO cycles during a
FIFO read/write ? I suppose those would be broken on SMP too (though I
suspect then that those don't exist as SMP machines then :)

Ben.

Re: Parallel ATA with libata status with the patches I'm working on

[Alan Cox]

On Sad, 2005-11-05 at 08:50 +1100, Benjamin Herrenschmidt wrote:
> OK, but my question why, what is the reason why we need IRQ mask ? Some
> old non-PCI controllers can't grok un-related ISA IO cycles during a
> FIFO read/write ? I suppose those would be broken on SMP too (though I
> suspect then that those don't exist as SMP machines then :)

There are PCI controllers that are hosed too. They incorrectly handle
the situation where the PCI fifo empties/fills and the controller should
indicate to the drive to stall the transfer. The chipsets I know that
are afflicted with this are all uniprocessor mainboard devices.

Alan