All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Rini <trini@kernel.crashing.org>
To: Armin <akuster@dslextreme.com>
Cc: Paul Mackerras <paulus@samba.org>, linuxppc-dev@lists.linuxppc.org
Subject: Re: [PATCH/RFC] Change how we pick which _kd_mksound to use.
Date: Mon, 8 Jul 2002 09:11:57 -0700	[thread overview]
Message-ID: <20020708161157.GF695@opus.bloom.county> (raw)
In-Reply-To: <3D29B8CB.9020204@dslextreme.com>


On Mon, Jul 08, 2002 at 09:07:39AM -0700, Armin wrote:

> Paul Mockeries wrote:
>
> >Tom Rind writes:
> >
> >>The following changes how we pick a _kd_mksound.  The problem is that on
> >>some machines, such as IBM405, the default _kd_mksound breaks horribly
> >>due to the inb/outb's attempting to fiddle with timers which don't
> >>exist.  This changes the test which selects either an empty _kd_mksound
> >>or the one in question from __powerpc__ to CONFIG_PPC64 (since from what I
> >>understand, __powerpc__ is defined on ppc64) || (CONFIG_PPC32 &&
> >>CONFIG_6xx).  The CONFIG_6xx test is because these boards are the ones
> >>which tend to have a SuperIO chip, or something else with the timers at
> >>0x61, 0xB6, etc.
> >>
> >>The other option would be to define an empty no_kd_mksound or so on
> >>4xx/8xx and then conditionally set kd_mksound to that, but I would
> >>prefer this since we're already doing some preprocessor checks anyhow.
> >>
> It looks to me as if the CONFIG_REDWOOD should be changed to CONFIG_4XX
> to start with and there are no guarantees that the timer will be at the
> same locations plus on a pci base 4xx , in*/out* can't br used on local
> bus i/o access.

Well, CONFIG_REDWOOD should be changed into something that catches all
of the other boards that it won't work on. :)

> >This is one of those "there's got to be a better way" places.  The
> >CONFIG_PPC32 && CONFIG_6xx test doesn't really capture what we want
> >much better than the existing __powerpc__ test does.  Testing
> >CONFIG_PPC32 && CONFIG_ISA might go closer.  I would really rather
> >that _kd_mksound was provided in the platform-specific files on those
> >platforms where it applies, though.
>
> For 4xx it should be defined at the board level in most cases :)

Right, just how pmac case is done.  If we want/can have the beep on a
4xx board :)

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

      reply	other threads:[~2002-07-08 16:11 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-01 15:27 [PATCH/RFC] Change how we pick which _kd_mksound to use Tom Rini
2002-07-07  1:32 ` Paul Mackerras
2002-07-08 14:46   ` Tom Rini
2002-07-08 16:07   ` Armin
2002-07-08 16:11     ` Tom Rini [this message]

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=20020708161157.GF695@opus.bloom.county \
    --to=trini@kernel.crashing.org \
    --cc=akuster@dslextreme.com \
    --cc=linuxppc-dev@lists.linuxppc.org \
    --cc=paulus@samba.org \
    /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.