public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jgarzik@mandrakesoft.com>
To: Will Newton <will@misconception.org.uk>
Cc: Tim Waugh <twaugh@redhat.com>,
	Mike Galbraith <mikeg@wen-online.de>,
	linux-kernel@vger.kernel.org
Subject: Re: VIA audio and parport in 2.4.2
Date: Wed, 21 Mar 2001 09:19:35 -0500	[thread overview]
Message-ID: <3AB8B877.D36E8719@mandrakesoft.com> (raw)
In-Reply-To: <Pine.LNX.4.33.0103211333440.1541-100000@dogfox.localdomain>

Will Newton wrote:
> On Tue, 20 Mar 2001, Jeff Garzik wrote:
> > I am not sure that I agree, however, that an "irq=none" on the kernel
> > cmd line should affect the operation of the Via code.  I would much
> > rather fix the Via code as I suggest above.
> 
> irq=none seems pretty unequivocal to me, I'm not sure how easy it is to
> explain to a user that irq=none doesn't do what it says.

For this specific case, Via motherboards, we know exactly whether or not
an interrupt was assigned to the parallel port, and whether or not the
parallel port is in an interrupt-driven mode.  Attempting to pretend
that the parallel port is not in an interrupt driven mode by passing
irq=none is folly.

If irq=none is passed to tell the Via code to -force- the parallel port
into a non-irq-driven mode is one thing.  If irq=none is passed to hide
a problem with spurious interrupts, we need to fix that problem, not
hide it.

So as I see it, I should fix the Via code to read (only!) the parallel
port configuration from BIOS, and set up the parallel port that way.  I
still am not convinced that irq=<anything> should affect the Via code at
all.  Maybe I can print out a message "irq=foo ignored".

Optionally, I could handle irq=none by force-disabling the parallel
port's interrupt driven modes, if they are active.  I don't want to do
this, but may be forced to by circumstance...

-- 
Jeff Garzik       | May you have warm words on a cold evening,
Building 1024     | a full mooon on a dark night,
MandrakeSoft      | and a smooth road all the way to your door.

  reply	other threads:[~2001-03-21 14:21 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-03-15 18:45 VIA audio and parport in 2.4.2 Will Newton
2001-03-16 10:53 ` Tim Waugh
2001-03-16 14:53   ` Will Newton
2001-03-17  7:09     ` Mike Galbraith
2001-03-17 17:46       ` Will Newton
2001-03-17 19:13         ` Mike Galbraith
2001-03-19  0:16           ` Will Newton
2001-03-19  0:22             ` Tim Waugh
2001-03-21  4:21               ` Jeff Garzik
2001-03-21 10:04                 ` Tim Waugh
2001-03-21 13:37                 ` Will Newton
2001-03-21 14:19                   ` Jeff Garzik [this message]
2001-03-21 14:49                     ` Tim Waugh
2001-03-22  2:41                       ` TimO
2001-03-27 18:21                         ` Tim Waugh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3AB8B877.D36E8719@mandrakesoft.com \
    --to=jgarzik@mandrakesoft.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mikeg@wen-online.de \
    --cc=twaugh@redhat.com \
    --cc=will@misconception.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox