drivers/macintosh/Kconfig (was: Re: Linux 2.6.3-rc1)

On Fri, 6 Feb 2004, Linus Torvalds wrote:

Benjamin Herrenschmidt:
  o ppc32: Use drivers/Kconfig and move some Mac stuffs to
    drivers/macintosh/Kconfig

And of course we just started to use drivers/Kconfig on m68k in CVS ;-)

This patch is a first attempt to fix the issues. What do you think?

ADB_CUDA is shared between m68k and PPC. Anyone who knows which m68k models use
it, so we can list them in the help text?

And probably we want to move a few more options from arch/m68k/Kconfig to
drivers/macintosh/Kconfig.

--- linux-m68k-2.6.3-rc1/arch/m68k/Kconfig.orig	2004-02-02 22:27:03.000000000 +0100
+++ linux-m68k-2.6.3-rc1/arch/m68k/Kconfig	2004-02-08 13:11:34.000000000 +0100

@@ -550,80 +563,6 @@
 	tristate "Macintosh serial support"
 	depends on MAC

-config ADB
-	bool "Apple Desktop Bus (ADB) support"
-	depends on MAC
-	help
-	  Apple Desktop Bus (ADB) support is for support of devices which
-	  are connected to an ADB port.  ADB devices tend to have 4 pins.
-	  If you have an Apple Macintosh prior to the iMac, or a
-	  "Blue and White G3", you probably want to say Y here.  Otherwise
-	  say N.
-
-config ADB_MACII
-	bool "Include Mac II ADB driver"
-	depends on ADB
-	help
-	  Say Y here if want your kernel to support Macintosh systems that use
-	  the Mac II style ADB.  This includes the II, IIx, IIcx, SE/30, IIci,
-	  Quadra 610, Quadra 650, Quadra 700, Quadra 800, Centris 610 and
-	  Centris 650.
-
-config ADB_MACIISI
-	bool "Include Mac IIsi ADB driver"
-	depends on ADB
-	help
-	  Say Y here if want your kernel to support Macintosh systems that use
-	  the Mac IIsi style ADB.  This includes the IIsi, IIvi, IIvx, Classic
-	  II, LC, LC II, LC III, Performa 460, and the Performa 600.
-
-config ADB_CUDA
-	bool "Include CUDA ADB driver"
-	depends on ADB
-	help
-	  This provides support for CUDA based Power Macintosh systems.  This
-	  includes most OldWorld PowerMacs, the first generation iMacs, the
-	  Blue&White G3 and the Yikes G4 (PCI Graphics).  All later models
-	  should use CONFIG_ADB_PMU instead.
-
-	  If unsure say Y.
-
-config ADB_IOP
-	bool "Include IOP (IIfx/Quadra 9x0) ADB driver"
-	depends on ADB
-	help
-	  The I/O Processor (IOP) is an Apple custom IC designed to provide
-	  intelligent support for I/O controllers.  It is described at
-	  <http://www.angelfire.com/ca2/dev68k/iopdesc.html> to enable direct
-	  support for it, say 'Y' here.
-
-config ADB_PMU68K
-	bool "Include PMU (Powerbook) ADB driver"
-	depends on ADB
-	help
-	  Say Y here if want your kernel to support the m68k based Powerbooks.
-	  This includes the PowerBook 140, PowerBook 145, PowerBook 150,
-	  PowerBook 160, PowerBook 165, PowerBook 165c, PowerBook 170,
-	  PowerBook 180, PowerBook, 180c, PowerBook 190cs, PowerBook 520,
-	  PowerBook Duo 210, PowerBook Duo 230, PowerBook Duo 250,
-	  PowerBook Duo 270c, PowerBook Duo 280 and PowerBook Duo 280c.
-
-config INPUT_ADBHID
-	bool "Use input layer for ADB devices"
-	depends on MAC && INPUT=y
-	---help---
-	  Say Y here if you want to have ADB (Apple Desktop Bus) HID devices
-	  such as keyboards, mice, joysticks, or graphic tablets handled by
-	  the input layer.  If you say Y here, make sure to say Y to the
-	  corresponding drivers "Keyboard support" (CONFIG_INPUT_KEYBDEV),
-	  "Mouse Support" (CONFIG_INPUT_MOUSEDEV) and "Event interface
-	  support" (CONFIG_INPUT_EVDEV) as well.
-
-	  If you say N here, you still have the option of using the old ADB
-	  keyboard and mouse drivers.
-
-	  If unsure, say Y.
-
 config MAC_HID
 	bool
 	depends on INPUT_ADBHID

@@ -643,18 +582,6 @@

 	  If unsure, say Y here.

-config MAC_EMUMOUSEBTN
-	bool "Support for mouse button 2+3 emulation"
-	depends on INPUT_ADBHID
-	help
-	  This provides generic support for emulating the 2nd and 3rd mouse
-	  button with keypresses.  If you say Y here, the emulation is still
-	  disabled by default.  The emulation is controlled by these sysctl
-	  entries:
-	  /proc/sys/dev/mac_hid/mouse_button_emulation
-	  /proc/sys/dev/mac_hid/mouse_button2_keycode
-	  /proc/sys/dev/mac_hid/mouse_button3_keycode
-
 config ADB_KEYBOARD
 	bool "Support for ADB keyboard (old driver)"
 	depends on MAC && !INPUT_ADBHID
--- linux-m68k-2.6.3-rc1/drivers/macintosh/Kconfig.orig	2004-02-08 10:19:24.000000000 +0100
+++ linux-m68k-2.6.3-rc1/drivers/macintosh/Kconfig	2004-02-08 13:29:01.000000000 +0100

@@ -1,16 +1,64 @@

 menu "Macintosh device drivers"

+config ADB
+	bool "Apple Desktop Bus (ADB) support"
+	depends on MAC || PPC_PMAC
+	help
+	  Apple Desktop Bus (ADB) support is for support of devices which
+	  are connected to an ADB port.  ADB devices tend to have 4 pins.
+	  If you have an Apple Macintosh prior to the iMac, an iBook or
+	  PowerBook, or a "Blue and White G3", you probably want to say Y
+	  here.  Otherwise say N.
+
+config ADB_MACII
+	bool "Include Mac II ADB driver"
+	depends on ADB && MAC
+	help
+	  Say Y here if want your kernel to support Macintosh systems that use
+	  the Mac II style ADB.  This includes the II, IIx, IIcx, SE/30, IIci,
+	  Quadra 610, Quadra 650, Quadra 700, Quadra 800, Centris 610 and
+	  Centris 650.
+
+config ADB_MACIISI
+	bool "Include Mac IIsi ADB driver"
+	depends on ADB && MAC
+	help
+	  Say Y here if want your kernel to support Macintosh systems that use
+	  the Mac IIsi style ADB.  This includes the IIsi, IIvi, IIvx, Classic
+	  II, LC, LC II, LC III, Performa 460, and the Performa 600.
+
+config ADB_IOP
+	bool "Include IOP (IIfx/Quadra 9x0) ADB driver"
+	depends on ADB && MAC
+	help
+	  The I/O Processor (IOP) is an Apple custom IC designed to provide
+	  intelligent support for I/O controllers.  It is described at
+	  <http://www.angelfire.com/ca2/dev68k/iopdesc.html> to enable direct
+	  support for it, say 'Y' here.
+
+config ADB_PMU68K
+	bool "Include PMU (Powerbook) ADB driver"
+	depends on ADB && MAC
+	help
+	  Say Y here if want your kernel to support the m68k based Powerbooks.
+	  This includes the PowerBook 140, PowerBook 145, PowerBook 150,
+	  PowerBook 160, PowerBook 165, PowerBook 165c, PowerBook 170,
+	  PowerBook 180, PowerBook, 180c, PowerBook 190cs, PowerBook 520,
+	  PowerBook Duo 210, PowerBook Duo 230, PowerBook Duo 250,
+	  PowerBook Duo 270c, PowerBook Duo 280 and PowerBook Duo 280c.
+
 # we want to change this to something like CONFIG_SYSCTRL_CUDA/PMU
 config ADB_CUDA
-	bool "Support for CUDA based PowerMacs"
-	depends on PPC_PMAC && !POWER4
+	bool "Support for CUDA based Macs and PowerMacs"
+	depends on (ADB || PPC_PMAC) && !POWER4
 	help
-	  This provides support for CUDA based Power Macintosh systems.  This
-	  includes most OldWorld PowerMacs, the first generation iMacs, the
-	  Blue&White G3 and the "Yikes" G4 (PCI Graphics).  All later models
-	  should use CONFIG_ADB_PMU instead.  It is safe to say Y here even if
-	  your machine doesn't have a CUDA.
+	  This provides support for CUDA based Macintosh and Power Macintosh
+	  systems.  This includes some m68k based Macs, most OldWorld
+	  PowerMacs, the first generation iMacs, the Blue&White G3 and the
+	  "Yikes" G4 (PCI Graphics).  All later models should use
+	  CONFIG_ADB_PMU instead.  It is safe to say Y here even if your
+	  machine doesn't have a CUDA.

 	  If unsure say Y.

@@ -81,19 +129,9 @@
 	  This driver is obsolete. Use CONFIG_SERIAL_PMACZILOG in
 	  "Character devices --> Serial drivers --> PowerMac z85c30" option.

-config ADB
-	bool "Apple Desktop Bus (ADB) support"
-	depends on PPC_PMAC
-	help
-	  Apple Desktop Bus (ADB) support is for support of devices which
-	  are connected to an ADB port.  ADB devices tend to have 4 pins.
-	  If you have an Apple Macintosh prior to the iMac, an iBook or
-	  PowerBook, or a "Blue and White G3", you probably want to say Y
-	  here.  Otherwise say N.
-
 config ADB_MACIO
 	bool "Include MacIO (CHRP) ADB driver"
-	depends on ADB && !POWER4
+	depends on ADB && PPC_CHRP && !POWER4
 	help
 	  Say Y here to include direct support for the ADB controller in the
 	  Hydra chip used on PowerPC Macintoshes of the CHRP type.  (The Hydra

@@ -151,6 +189,6 @@

 config ANSLCD
 	bool "Support for ANS LCD display"
-	depends on ADB_CUDA
+	depends on ADB_CUDA && PPC_PMAC

 endmenu

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

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

On Sun, Feb 08, 2004 at 03:25:50PM +0100, Geert Uytterhoeven wrote:

On Fri, 6 Feb 2004, Linus Torvalds wrote:

quoted

Benjamin Herrenschmidt:
  o ppc32: Use drivers/Kconfig and move some Mac stuffs to
    drivers/macintosh/Kconfig

And of course we just started to use drivers/Kconfig on m68k in CVS ;-)

This patch is a first attempt to fix the issues. What do you think?

ADB_CUDA is shared between m68k and PPC. Anyone who knows which m68k
models use it, so we can list them in the help text?

According to arch/m68k/mac/config.c:

Color Classic
Mac TV
Performa 475
Performa 520
Performa 550
Performa 575
Performa 588
Quadra 605
Quadra 630
Quadra/Centris 660AV
Quadra 840AV

Dave

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

On Sun, 8 Feb 2004, David D. Kilzer wrote:

On Sun, Feb 08, 2004 at 03:25:50PM +0100, Geert Uytterhoeven wrote:

quoted

On Fri, 6 Feb 2004, Linus Torvalds wrote:

quoted

Benjamin Herrenschmidt:
  o ppc32: Use drivers/Kconfig and move some Mac stuffs to
    drivers/macintosh/Kconfig

And of course we just started to use drivers/Kconfig on m68k in CVS ;-)

This patch is a first attempt to fix the issues. What do you think?

ADB_CUDA is shared between m68k and PPC. Anyone who knows which m68k
models use it, so we can list them in the help text?

According to arch/m68k/mac/config.c:

Color Classic
Mac TV
Performa 475
Performa 520
Performa 550
Performa 575
Performa 588
Quadra 605
Quadra 630
Quadra/Centris 660AV
Quadra 840AV

Thanks! So my second version looks like:

--- linux-m68k-2.6.3-rc1/arch/m68k/Kconfig.orig	2004-02-02 22:27:03.000000000 +0100
+++ linux-m68k-2.6.3-rc1/arch/m68k/Kconfig	2004-02-08 20:13:45.000000000 +0100

@@ -550,80 +550,6 @@
 	tristate "Macintosh serial support"
 	depends on MAC

-config ADB
-	bool "Apple Desktop Bus (ADB) support"
-	depends on MAC
-	help
-	  Apple Desktop Bus (ADB) support is for support of devices which
-	  are connected to an ADB port.  ADB devices tend to have 4 pins.
-	  If you have an Apple Macintosh prior to the iMac, or a
-	  "Blue and White G3", you probably want to say Y here.  Otherwise
-	  say N.
-
-config ADB_MACII
-	bool "Include Mac II ADB driver"
-	depends on ADB
-	help
-	  Say Y here if want your kernel to support Macintosh systems that use
-	  the Mac II style ADB.  This includes the II, IIx, IIcx, SE/30, IIci,
-	  Quadra 610, Quadra 650, Quadra 700, Quadra 800, Centris 610 and
-	  Centris 650.
-
-config ADB_MACIISI
-	bool "Include Mac IIsi ADB driver"
-	depends on ADB
-	help
-	  Say Y here if want your kernel to support Macintosh systems that use
-	  the Mac IIsi style ADB.  This includes the IIsi, IIvi, IIvx, Classic
-	  II, LC, LC II, LC III, Performa 460, and the Performa 600.
-
-config ADB_CUDA
-	bool "Include CUDA ADB driver"
-	depends on ADB
-	help
-	  This provides support for CUDA based Power Macintosh systems.  This
-	  includes most OldWorld PowerMacs, the first generation iMacs, the
-	  Blue&White G3 and the Yikes G4 (PCI Graphics).  All later models
-	  should use CONFIG_ADB_PMU instead.
-
-	  If unsure say Y.
-
-config ADB_IOP
-	bool "Include IOP (IIfx/Quadra 9x0) ADB driver"
-	depends on ADB
-	help
-	  The I/O Processor (IOP) is an Apple custom IC designed to provide
-	  intelligent support for I/O controllers.  It is described at
-	  <http://www.angelfire.com/ca2/dev68k/iopdesc.html> to enable direct
-	  support for it, say 'Y' here.
-
-config ADB_PMU68K
-	bool "Include PMU (Powerbook) ADB driver"
-	depends on ADB
-	help
-	  Say Y here if want your kernel to support the m68k based Powerbooks.
-	  This includes the PowerBook 140, PowerBook 145, PowerBook 150,
-	  PowerBook 160, PowerBook 165, PowerBook 165c, PowerBook 170,
-	  PowerBook 180, PowerBook, 180c, PowerBook 190cs, PowerBook 520,
-	  PowerBook Duo 210, PowerBook Duo 230, PowerBook Duo 250,
-	  PowerBook Duo 270c, PowerBook Duo 280 and PowerBook Duo 280c.
-
-config INPUT_ADBHID
-	bool "Use input layer for ADB devices"
-	depends on MAC && INPUT=y
-	---help---
-	  Say Y here if you want to have ADB (Apple Desktop Bus) HID devices
-	  such as keyboards, mice, joysticks, or graphic tablets handled by
-	  the input layer.  If you say Y here, make sure to say Y to the
-	  corresponding drivers "Keyboard support" (CONFIG_INPUT_KEYBDEV),
-	  "Mouse Support" (CONFIG_INPUT_MOUSEDEV) and "Event interface
-	  support" (CONFIG_INPUT_EVDEV) as well.
-
-	  If you say N here, you still have the option of using the old ADB
-	  keyboard and mouse drivers.
-
-	  If unsure, say Y.
-
 config MAC_HID
 	bool
 	depends on INPUT_ADBHID

@@ -643,18 +600,6 @@

 	  If unsure, say Y here.

-config MAC_EMUMOUSEBTN
-	bool "Support for mouse button 2+3 emulation"
-	depends on INPUT_ADBHID
-	help
-	  This provides generic support for emulating the 2nd and 3rd mouse
-	  button with keypresses.  If you say Y here, the emulation is still
-	  disabled by default.  The emulation is controlled by these sysctl
-	  entries:
-	  /proc/sys/dev/mac_hid/mouse_button_emulation
-	  /proc/sys/dev/mac_hid/mouse_button2_keycode
-	  /proc/sys/dev/mac_hid/mouse_button3_keycode
-
 config ADB_KEYBOARD
 	bool "Support for ADB keyboard (old driver)"
 	depends on MAC && !INPUT_ADBHID
--- linux-2.6.3-rc1/drivers/macintosh/Kconfig.orig	2004-02-08 10:19:24.000000000 +0100
+++ linux-m68k-2.6.3-rc1/drivers/macintosh/Kconfig	2004-02-08 20:18:18.000000000 +0100

@@ -1,16 +1,66 @@

 menu "Macintosh device drivers"

+config ADB
+	bool "Apple Desktop Bus (ADB) support"
+	depends on MAC || PPC_PMAC
+	help
+	  Apple Desktop Bus (ADB) support is for support of devices which
+	  are connected to an ADB port.  ADB devices tend to have 4 pins.
+	  If you have an Apple Macintosh prior to the iMac, an iBook or
+	  PowerBook, or a "Blue and White G3", you probably want to say Y
+	  here.  Otherwise say N.
+
+config ADB_MACII
+	bool "Include Mac II ADB driver"
+	depends on ADB && MAC
+	help
+	  Say Y here if want your kernel to support Macintosh systems that use
+	  the Mac II style ADB.  This includes the II, IIx, IIcx, SE/30, IIci,
+	  Quadra 610, Quadra 650, Quadra 700, Quadra 800, Centris 610 and
+	  Centris 650.
+
+config ADB_MACIISI
+	bool "Include Mac IIsi ADB driver"
+	depends on ADB && MAC
+	help
+	  Say Y here if want your kernel to support Macintosh systems that use
+	  the Mac IIsi style ADB.  This includes the IIsi, IIvi, IIvx, Classic
+	  II, LC, LC II, LC III, Performa 460, and the Performa 600.
+
+config ADB_IOP
+	bool "Include IOP (IIfx/Quadra 9x0) ADB driver"
+	depends on ADB && MAC
+	help
+	  The I/O Processor (IOP) is an Apple custom IC designed to provide
+	  intelligent support for I/O controllers.  It is described at
+	  <http://www.angelfire.com/ca2/dev68k/iopdesc.html> to enable direct
+	  support for it, say 'Y' here.
+
+config ADB_PMU68K
+	bool "Include PMU (Powerbook) ADB driver"
+	depends on ADB && MAC
+	help
+	  Say Y here if want your kernel to support the m68k based Powerbooks.
+	  This includes the PowerBook 140, PowerBook 145, PowerBook 150,
+	  PowerBook 160, PowerBook 165, PowerBook 165c, PowerBook 170,
+	  PowerBook 180, PowerBook, 180c, PowerBook 190cs, PowerBook 520,
+	  PowerBook Duo 210, PowerBook Duo 230, PowerBook Duo 250,
+	  PowerBook Duo 270c, PowerBook Duo 280 and PowerBook Duo 280c.
+
 # we want to change this to something like CONFIG_SYSCTRL_CUDA/PMU
 config ADB_CUDA
-	bool "Support for CUDA based PowerMacs"
-	depends on PPC_PMAC && !POWER4
+	bool "Support for CUDA based Macs and PowerMacs"
+	depends on (ADB || PPC_PMAC) && !POWER4
 	help
-	  This provides support for CUDA based Power Macintosh systems.  This
-	  includes most OldWorld PowerMacs, the first generation iMacs, the
-	  Blue&White G3 and the "Yikes" G4 (PCI Graphics).  All later models
-	  should use CONFIG_ADB_PMU instead.  It is safe to say Y here even if
-	  your machine doesn't have a CUDA.
+	  This provides support for CUDA based Macintosh and Power Macintosh
+	  systems.  This includes many m68k based Macs (Color Classic, Mac TV,
+	  Performa 475, Performa 520, Performa 550, Performa 575,
+	  Performa 588, Quadra 605, Quadra 630, Quadra/Centris 660AV, and
+	  Quadra 840AV), most OldWorld PowerMacs, the first generation iMacs,
+	  the Blue&White G3 and the "Yikes" G4 (PCI Graphics).  All later
+	  models should use CONFIG_ADB_PMU instead.  It is safe to say Y here
+	  even if your machine doesn't have a CUDA.

 	  If unsure say Y.

@@ -81,19 +131,9 @@
 	  This driver is obsolete. Use CONFIG_SERIAL_PMACZILOG in
 	  "Character devices --> Serial drivers --> PowerMac z85c30" option.

-config ADB
-	bool "Apple Desktop Bus (ADB) support"
-	depends on PPC_PMAC
-	help
-	  Apple Desktop Bus (ADB) support is for support of devices which
-	  are connected to an ADB port.  ADB devices tend to have 4 pins.
-	  If you have an Apple Macintosh prior to the iMac, an iBook or
-	  PowerBook, or a "Blue and White G3", you probably want to say Y
-	  here.  Otherwise say N.
-
 config ADB_MACIO
 	bool "Include MacIO (CHRP) ADB driver"
-	depends on ADB && !POWER4
+	depends on ADB && PPC_CHRP && !POWER4
 	help
 	  Say Y here to include direct support for the ADB controller in the
 	  Hydra chip used on PowerPC Macintoshes of the CHRP type.  (The Hydra

@@ -151,6 +191,6 @@

 config ANSLCD
 	bool "Support for ANS LCD display"
-	depends on ADB_CUDA
+	depends on ADB_CUDA && PPC_PMAC

 endmenu

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

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

On Sun, Feb 08, 2004 at 03:25:50PM +0100, Geert Uytterhoeven wrote:

On Fri, 6 Feb 2004, Linus Torvalds wrote:

quoted

Benjamin Herrenschmidt:
  o ppc32: Use drivers/Kconfig and move some Mac stuffs to
    drivers/macintosh/Kconfig

And of course we just started to use drivers/Kconfig on m68k in CVS ;-)

And probably we want to move a few more options from arch/m68k/Kconfig to
drivers/macintosh/Kconfig.

I've started rewriting ADB for the new driver model, and I have been
putting it into a new directory, drivers/adb/. Seeing this makes me
wonder if that's what people think is the best idea. We could have
ADB support on non-Mac machines at some point. I'll try to get the
Griffin iMate (a UDB-ADB converter) working at some point, although
the built-in interfaces take priority for me. The hydra chip is
technically not in any Mac either, although it's very much a Mac
oriented chip. I personally think drivers/macintosh/ should be
limited to things like macio-*, mediabay, and other similar stuff.
Anyone care to comment?

	Brad Boyer
	flar@allandria.com


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

NeXT workstations (which are also m68k-based) contain ADB hardware, so
it's not Macintosh-specific.

I guess it is company-founded-by-Steve-Jobs specific, though.  :)

Dave


On Sun, Feb 08, 2004 at 12:57:34PM -0800, Brad Boyer wrote:

I've started rewriting ADB for the new driver model, and I have been
putting it into a new directory, drivers/adb/. Seeing this makes me
wonder if that's what people think is the best idea. We could have
ADB support on non-Mac machines at some point. I'll try to get the
Griffin iMate (a UDB-ADB converter) working at some point, although
the built-in interfaces take priority for me. The hydra chip is
technically not in any Mac either, although it's very much a Mac
oriented chip. I personally think drivers/macintosh/ should be
limited to things like macio-*, mediabay, and other similar stuff.
Anyone care to comment?

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

On Mon, 2004-02-09 at 01:25, Geert Uytterhoeven wrote:

+config ADB
+	bool "Apple Desktop Bus (ADB) support"
+	depends on MAC || PPC_PMAC
+	help
+	  Apple Desktop Bus (ADB) support is for support of devices which
+	  are connected to an ADB port.  ADB devices tend to have 4 pins.
+	  If you have an Apple Macintosh prior to the iMac, an iBook or
+	  PowerBook, or a "Blue and White G3", you probably want to say Y
+	  here.  Otherwise say N.

I'd be more precise, like: ADB devices are usually input devices (mice
and keyboards) connected via a 4 pin daisy chained bus. All Apple
laptops also use ADB internally for the built-in keyboar & trackpad.

Now, for Cuda and PMU, as long as you let them be selected even
without CONFIG_ADB, it's fine.

Ben.


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

I've started rewriting ADB for the new driver model, and I have been
putting it into a new directory, drivers/adb/.

Ah, good to know, as I was about to do it too ! Though I don't
fully agree with moving it to a new directory.

Seeing this makes me
wonder if that's what people think is the best idea. We could have
ADB support on non-Mac machines at some point.

What for ? NeXT cubes ? :)

I'll try to get the
Griffin iMate (a UDB-ADB converter) working at some point, although
the built-in interfaces take priority for me. The hydra chip is
technically not in any Mac either, although it's very much a Mac
oriented chip. I personally think drivers/macintosh/ should be
limited to things like macio-*, mediabay, and other similar stuff.
Anyone care to comment?

Well... via-pmu at least is a lot more than just an ADB host
driver and should stay in drivers/macintosh. But if we go that way,
then it make little sense to have via-pmu and via-cuda in different
locations..

Ben.


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

On Mon, Feb 09, 2004 at 08:29:46AM +1100, Benjamin Herrenschmidt wrote:

Ah, good to know, as I was about to do it too ! Though I don't
fully agree with moving it to a new directory.

quoted

Seeing this makes me
wonder if that's what people think is the best idea. We could have
ADB support on non-Mac machines at some point.

What for ? NeXT cubes ? :)

Honestly, I think the NeXT cubes will never be supported, but if
someone does get back into trying that, it might happen. The most
likely thing in my opinion is the iMate. Griffin Technology does
support using it (for keyboards/mice only) in Windows, so I think
it's a good idea to have Linux support for it, too.

Well... via-pmu at least is a lot more than just an ADB host
driver and should stay in drivers/macintosh. But if we go that way,
then it make little sense to have via-pmu and via-cuda in different
locations..

I've been thinking about splitting up the ADB and other functions
of the egret, cuda, and pmu. The abuse of adb_request for non-ADB
functionality should go away. With the new driver model, the ADB
bus will be represented as a generic bus and any request should
go to a specific bus or device. I don't want to have to assume
a single, global bus the way the current code does.

I would prefer to have ADB be really just for ADB. The power
management stuff should be a separate interface, and really
should be more generic across the different Mac power management
systems. Although the egret and cuda don't do as much as pmu,
they still manage poweroff, reset, and the PRAM/RTC. These are
totally unrelated to ADB, and that stuff I think should be left
in drivers/macintosh/.

	Brad Boyer
	flar@allandria.com


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

On Mon, 9 Feb 2004, Benjamin Herrenschmidt wrote:

On Mon, 2004-02-09 at 01:25, Geert Uytterhoeven wrote:

quoted

+config ADB
+	bool "Apple Desktop Bus (ADB) support"
+	depends on MAC || PPC_PMAC
+	help
+	  Apple Desktop Bus (ADB) support is for support of devices which
+	  are connected to an ADB port.  ADB devices tend to have 4 pins.
+	  If you have an Apple Macintosh prior to the iMac, an iBook or
+	  PowerBook, or a "Blue and White G3", you probably want to say Y
+	  here.  Otherwise say N.

I'd be more precise, like: ADB devices are usually input devices (mice
and keyboards) connected via a 4 pin daisy chained bus. All Apple
laptops also use ADB internally for the built-in keyboar & trackpad.

I just moved the old help text, I didn't modify it.

Now, for Cuda and PMU, as long as you let them be selected even
without CONFIG_ADB, it's fine.

That's what I did...

BTW, why do some of these conflict with POWER4? Can't you build a generic
kernel that runs on both PowerMac and POWER4?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

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

Hi,

Brad Boyer:

ADB support on non-Mac machines at some point. I'll try to get the
Griffin iMate (a UDB-ADB converter) working at some point, although
the built-in interfaces take priority for me.

This may be a stupid question, but I've got an iMate, and it already
works rather well -- it checks whether the (single!) ADB device behind
it is a keyboard or a mouse, and then translates that to standard PCish
USB keycodes or mouse events, transparently.

Do you have documentation that says it can do more ..?

               I personally think drivers/macintosh/ should be limited
to things like macio-*, mediabay, and other similar stuff. Anyone care
to comment?

I tend to agree.

--
Matthias Urlichs

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

On Sun, 8 Feb 2004, David D. Kilzer wrote:

NeXT workstations (which are also m68k-based) contain ADB hardware, so
it's not Macintosh-specific.

Care to resurrect the NeXT port of Linux/m68k?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

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

On Sun, Feb 08, 2004 at 11:07:10PM +0100, Matthias Urlichs wrote:

This may be a stupid question, but I've got an iMate, and it already
works rather well -- it checks whether the (single!) ADB device behind
it is a keyboard or a mouse, and then translates that to standard PCish
USB keycodes or mouse events, transparently.

Yes, it can convert a standard keyboard and mouse directly to a USB
keyboard and mouse, but if you want to treat it as a generic ADB
bus, you need a driver.

Do you have documentation that says it can do more ..?

How about the official page?

http://www.griffintechnology.com/products/imate/

It specifically says "and other ADB peripherals" in the description.
The various documentation if you search around their site talks
about how you can just plug in a keyboard or mouse and it works,
but has a driver download for OSX and OS9 to allow using anything
with a real ADB driver to work.

I'm pretty sure keyboards and mice are the only devices currently
supported on ADB in Linux anyway, but it's a thought for the future.

	Brad Boyer
	flar@allandria.com


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

I've been thinking about splitting up the ADB and other functions
of the egret, cuda, and pmu. The abuse of adb_request for non-ADB
functionality should go away. With the new driver model, the ADB
bus will be represented as a generic bus and any request should
go to a specific bus or device. I don't want to have to assume
a single, global bus the way the current code does.

I would prefer to have ADB be really just for ADB. The power
management stuff should be a separate interface, and really
should be more generic across the different Mac power management
systems. Although the egret and cuda don't do as much as pmu,
they still manage poweroff, reset, and the PRAM/RTC. These are
totally unrelated to ADB, and that stuff I think should be left
in drivers/macintosh/.

I agree that the abuse of adb_request should go, though replacing
it isn't easy at this stage. It's not worth bothering with a
common interface for things like poweroff, reset and RTC imho,
it would only solve a small part of the problem, there are too
many places where we actually need to send directly a PMU command.

Part of the problem is that the PMU driver low level state machine
it tied to the format of the adb_request structure. I don't think
I will fix any of that for 2.6. For 2.7, I may define a low level
pmu_request structure _without_ embedded buffers and have the ADB
request handling allocate one of those atomically.

Ben.


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

I'm pretty sure keyboards and mice are the only devices currently
supported on ADB in Linux anyway, but it's a thought for the future.

Do you really see any future to ADB ? :)

Ben.


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

Hi,

Brad Boyer:

[ Link to the manufacturer ]

Ah. Thanks.

I'm pretty sure keyboards and mice are the only devices currently
supported on ADB in Linux anyway, but it's a thought for the future.

OK, so ... (playing around with the thing a bit more) yep, an ADB driver
for it would actually make sense.

Two reasons: One, the Mac keyboards habitually send the same keycodes
for left and right modifier keys, and if you want to distinguish them,
say to use one for ALT and the other for AltGr, you need to send some
special ADB commands; the iMate doesn't do that when it's emulating a
PC keyboard.

Two, people who use their ol' Mac mouse (or trackball...) typically want
to plug it into the keyboard, instead of buying a second iMate. ;-)


If somebody would kindly send two spare weeks or so my way, I'll happily
write one...

--
Matthias Urlichs

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

On Sun, Feb 08, 2004 at 11:16:30PM +0100, Geert Uytterhoeven wrote:

On Sun, 8 Feb 2004, David D. Kilzer wrote:

quoted

NeXT workstations (which are also m68k-based) contain ADB hardware, so
it's not Macintosh-specific.

Care to resurrect the NeXT port of Linux/m68k?

Actually, I bought a complete NeXT system (I think it was a slab) 3-4
years ago for this very purpose, but I haven't even unpacked it yet. :)

I've also got an HP 9000/425e (kbd and mouse, but no monitor), and at
least half a dozen old m68k Macs in my basement.

And I started on a port of uClinux to non-MMU m68k-based Macs 3-4
years ago using a Mac SE with 8 MB RAM an ethernet card.  I managed to
build a working Penguin booter for System 7 and a linux-2.0.38 uClinux
kernel, but the combination never got to userland (although I did get
serial console output through 'POSIX conformance testing by UNIFIX',
then the kernel tried to initialize the MMU and went into an endless
loop).

First things first, though.  I need to get a cross-dev environment set
up that works (or at least that I trust).  I have yet to build a 2.2
kernel (from mac68k CVS) or a 2.4 kernel (from m68k CVS) that will boot
to userland on my Quadra 660av!  The last working kernel I have for it
is 2.2.16 from mac68k CVS.

Dave

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

On Mon, Feb 09, 2004 at 09:22:35AM +1100, Benjamin Herrenschmidt wrote:

I agree that the abuse of adb_request should go, though replacing
it isn't easy at this stage. It's not worth bothering with a
common interface for things like poweroff, reset and RTC imho,
it would only solve a small part of the problem, there are too
many places where we actually need to send directly a PMU command.

Based on my reading of the code, most of the places sending PMU
commands directly are actually calling pmu_request, so I was
planning on leaving that alone as a hook directly into the PMU
driver, and although it's related to ADB, it isn't going through
the current ADB framework, either.

Part of the problem is that the PMU driver low level state machine
it tied to the format of the adb_request structure. I don't think
I will fix any of that for 2.6. For 2.7, I may define a low level
pmu_request structure _without_ embedded buffers and have the ADB
request handling allocate one of those atomically.

I don't see where that is an issue. The PMU driver internally can
continue to be based on the same structure, and interface with
the new ADB layer just for ADB messages. I suppose it will be clearer
once I get that part of the code finished. I've been concentrating
more on the 68k side of things for this, since I don't care if I
confuse one of my older boxes.

	Brad Boyer
	flar@allandria.com


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