Subject: autoconf(9) tree in an odd hardware arrangement
To: None <tech-kern@netbsd.org>
From: Marco Trillo <marcotrillo@gmail.com>
List: tech-kern
Date: 11/23/2007 22:23:15
Hi all,

For an experiment, I ran into some sort of, perhaps stupid, autoconf(9)-
-related doubt.

The hardware arrangement looks like this (please excuse the
poor ASCII drawing):

             +------------+
             |    bus     |
             +------------+
     /---------|         |
     v                   v
+------------+        +----------+
|   Audio    |        |   I2C    |
| controller |        |controller|
+------------+        +----------+
  ||                       | (I2C bus)
  ||                       v
  ||                   +-------+
  \\=== (audio link) ==| CODEC |->audio out
                       +-------+

The 'doubt' is what is the most clean way to attach an audio(4) bus
in such an arrangement. Some functions of the audio setup need to
configure the CODEC via the I2C bus, some functions need to configure
the 'Audio controller', and some need to configure both devices.

A) Attach all the devices. Defer the configuration of the 'Audio
   controller' with config_defer(9) and then look for the 'CODEC',
   connect to it, and attach the 'audio' bus:

   audio_controller0 at bus0
   [defers configuration]
   i2c_controller0 at bus0
   iic0 at i2c_controller0: I2C bus
   codec0 at iic0
   [...]
   audio_controller0: connecting to codec0
   audio0 at audio_controller0

B) Similar to A), but inverse: make the 'codec' look for the controller
   and attach the 'audio' bus to the 'codec'.
   However, the most logic thing seems to be for the 'audio' bus to
   be attached to the audio controller.

C) Do not make the 'CODEC' a real device, but embed it into the
   'audio_controller' driver. I think this is uglier, since it
   still needs to look for the I2C controller in order to talk to it,
   so it still needs to call config_defer(9). Also, how does it know what
   of the possible attached controllers is the good one?

   Also, there is no reason for the 'CODEC' driver to depend on a specific
   controller.

D) Use some kind of 'mux' pseudo device:
   audio_controller0 at bus0
   [...]
   codec0 at iic0
   [...]
   audio_mux0: using (audio_controller0, codec0)
   audio0 at audio_mux0

   However this does not reflect that the codec0 'CODEC' is physically
   connected to the audio_controller0.

What do you think?

Thanks,
Marco.