lkml.org 
[lkml]   [1999]   [Dec]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: More on the IDE multiwrite problem
From
Date
>>>>> "Dave" == David S Miller <davem@redhat.com> writes:

Dave> From: Jes Sorensen <Jes.Sorensen@cern.ch> Date: 18 Dec 1999
Dave> 21:57:38 +0100

> Then I would suggest to have the low level drivers register a
> function that does the chipset specific stuff. The generic IDE
> code really shouldn't know anything about
> disable_irq()/enable_irq() nor try to use them.

Dave> I think one of the things Mark was trying to say is that some
Dave> IDE chipsets have no mechanism or the mechanism is undocumented.

I am aware of this, I have even seen IDE implementations where people
connect the IDE data lines directly to the CPU bus without buffering -
veeery scary.

Dave> To handle all cases, if we did callbacks, we should need a
Dave> default one which did the disable_irq/enable_irq trick.

This is still way better than enforcing the use of
disable_irq()/enable_irq() on everybody. Even on the PC it should be
fairly noticeable to branch to a sub routine that disables the
device's interrupt with a writel() rather than going out to the PIC
and doing it there.

Dave> Do you know how all the IDE chipsets on m68k implement irq
Dave> disabling? If you have the platform with the problem, not being
Dave> able to answer this question makes going to such callbacks
Dave> futile as nothing will change.

This has nothing to do with being m68k nor IDE specific, my point is
that no generic device layer has enough information about interrupt
sources to know whether an interrupt is shared or not.

Jes

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.077 / U:0.264 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site