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)
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
On 11/3/05, Alan Cox <[email protected]> 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
On 11/3/05, Russell King <[email protected]> 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
On Iau, 2005-11-03 at 15:58 +0100, Bartlomiej Zolnierkiewicz wrote:
> On 11/3/05, Alan Cox <[email protected]> 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)
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
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
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
From: Bartlomiej Zolnierkiewicz <[email protected]>
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.
On 11/3/05, Alan Cox <[email protected]> wrote:
> On Iau, 2005-11-03 at 15:58 +0100, Bartlomiej Zolnierkiewicz wrote:
> > On 11/3/05, Alan Cox <[email protected]> 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
On 11/3/05, David S. Miller <[email protected]> wrote:
> From: Bartlomiej Zolnierkiewicz <[email protected]>
> 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)
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.
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
Bartlomiej Zolnierkiewicz <[email protected]> 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
On 11/3/05, Krzysztof Halasa <[email protected]> wrote:
> Bartlomiej Zolnierkiewicz <[email protected]> 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
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
Bartlomiej Zolnierkiewicz <[email protected]> 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
On 11/3/05, Krzysztof Halasa <[email protected]> wrote:
> Bartlomiej Zolnierkiewicz <[email protected]> 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
>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.
[email protected]
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.
[email protected]
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)
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 : [email protected] : http://www.ime.usp.br/~rbrito
Homepage of the algorithms package : http://algorithms.berlios.de
Homepage on freshmeat: http://freshmeat.net/projects/algorithms/
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
Russell King wrote:
> You mentioned that libata doesn't do SWDMA - does it do MWDMA and PIO?
It even supports polled PIO :)
Jeff
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).
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.
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
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 ?
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
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
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
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.
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
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.
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!
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