All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tim Waugh <twaugh@redhat.com>
To: Jeff Garzik <jgarzik@mandrakesoft.com>
Cc: Mike Galbraith <mikeg@wen-online.de>,
	linux-kernel@vger.kernel.org,
	Will Newton <will@misconception.org.uk>
Subject: Re: VIA audio and parport in 2.4.2
Date: Wed, 21 Mar 2001 10:04:23 +0000	[thread overview]
Message-ID: <20010321100423.P12081@redhat.com> (raw)
In-Reply-To: <Pine.LNX.4.33.0103171951340.440-100000@mikeg.weiden.de> <Pine.LNX.4.33.0103190015080.8534-100000@dogfox.localdomain> <20010318192221.A27150@redhat.com> <3AB82C36.C807B787@mandrakesoft.com>
In-Reply-To: <3AB82C36.C807B787@mandrakesoft.com>; from jgarzik@mandrakesoft.com on Tue, Mar 20, 2001 at 11:21:10PM -0500

[-- Attachment #1: Type: text/plain, Size: 1084 bytes --]

On Tue, Mar 20, 2001 at 11:21:10PM -0500, Jeff Garzik wrote:

> The current Via-specific parport_pc.c code forces on the best possible
> parallel port modes the chip can handle.  In retrospect, what it should
> be doing is reading the configuration BIOS has set up, and not touching
> it.

Yes, I think you are right.

> 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 should definitely be honoured, or else the user has to reboot
in order to debug problems with printing.  The user's io=, irq= and
dma= settings should always be honoured. IMHO.

When irq=auto, the BIOS settings should be used.

Case in point: until very recently there was a bad problem in the
irq-driven printing path.  But only people with Via chipsets were
reporting it, and it didn't go away with 'irq=none' (which parport.txt
says to do in order to trouble-shoot).  It makes Via chipsets the
exception, and it's confusing IMHO (it confused me, anyhow).

Tim.
*/

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

  reply	other threads:[~2001-03-21 10:05 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 [this message]
2001-03-21 13:37                 ` Will Newton
2001-03-21 14:19                   ` Jeff Garzik
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=20010321100423.P12081@redhat.com \
    --to=twaugh@redhat.com \
    --cc=jgarzik@mandrakesoft.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mikeg@wen-online.de \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.