[PATCH/RFC] Change how we pick which _kd_mksound to use.

[PATCH/RFC] Change how we pick which _kd_mksound to use.

[Tom Rini]

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.

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

===== drivers/char/vt.c 1.9 vs edited =====
--- 1.9/drivers/char/vt.c	Tue Feb  5 00:55:25 2002
+++ edited/drivers/char/vt.c	Mon Jul  1 08:05:43 2002
@@ -90,7 +90,8 @@
  * comments - KDMKTONE doesn't put the process to sleep.
  */

-#if defined(__i386__) || defined(__alpha__) || defined(__powerpc__) \
+#if defined(__i386__) || defined(__alpha__) || defined(CONFIG_PPC64) \
+    || (defined(CONFIG_PPC32) && defined(CONFIG_6xx)) \
     || (defined(__mips__) && defined(CONFIG_ISA)) \
     || (defined(__arm__) && defined(CONFIG_HOST_FOOTBRIDGE)) \
     || defined(__x86_64__)

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

Re: [PATCH/RFC] Change how we pick which _kd_mksound to use.

[Paul Mackerras]

Tom Rini 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.

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.

Paul.

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

Re: [PATCH/RFC] Change how we pick which _kd_mksound to use.

[Tom Rini]

On Sun, Jul 07, 2002 at 11:32:05AM +1000, Paul Mackerras wrote:
> Tom Rini 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.
>
> This is one of those "there's got to be a better way" places.

heh..

> 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.

Well, lets think about what we want here.  We want to know if we have a
PC-style SuperIO (or similar) on board.  This is true of every board
under CONFIG_6xx, except for pmac, and possibly the 8260 boards.

Perhaps in 2.5, if this is still an issue after the input bits are all
sorted out, and Ben gets his version of MS' CONFIG_GENERIC_PPC32
working, we can get CONFIG_PPC_SUPERIO or so added for all of the boards
which have one (which would catch any of the odd-ball, not existant but
no technically impossible 4xx boards with a SuperIO or something).

And is is popping up on the input layer discussion, what does CONFIG_ISA
actually mean?  In a lot of places (most even?) it means the existance
of ISA slots.

> I would really rather
> that _kd_mksound was provided in the platform-specific files on those
> platforms where it applies, though.

Er, I don't know if I follow you here.  Are you suggesting we take the
__powerpc__ test out of drivers/char/vt.c (or change it to CONFIG_PPC64)
and then make every board with a SuperIO have a copy of the 'proper'
_kd_mksound ? (The Makefile mojo would look like this tho :) :
ifeq ($(CONFIG_6xx)$(CONFIG_8260),yn) # It's a feature damnit...
obj-$(CONFIG_VT) += pc_mksound.o
endif
)

Or did you mean to make this a per-architecture problem?

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

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

Re: [PATCH/RFC] Change how we pick which _kd_mksound to use.

[Armin]

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.

>
>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.
>
>Paul.
>
For 4xx it should be defined at the board level in most cases :)

armin


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

Re: [PATCH/RFC] Change how we pick which _kd_mksound to use.

[Tom Rini]

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/