Haai,

On Fri, November 23, 2007 21:23, Marco Trillo wrote:
> 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):

Meh, I've seen a lot worse...

>
>[snip schematic]
>
> 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?

I've been thinking about this (until now appearantly hypothetical) problem
for a while now, and A) seems like the best generic option, since codec0
is controlled by audio_controller0, no matter where it might logically
attach. However, there has been talk of a redesign of the audio subsystem
similar to D) a while ago (in which, naturally, my input was ignored);
troll through the list archives to find it.

On a somewhat related note, I've come to the conclusion that we should
treat any device which supports potential independent access (for example
graphics  accelerators, but also crap like FPUs and on-CPU vector units)
as seperate devices that may be used independently of the device they
'belong' to:

# For performance reasons, fpu code may be embedded within cpu code; this
# is merely a ceremonial attachment.
fpu* at cpu? # Floating-point coprocessor

radeon* at pci? flags STEALMEM # ATI Radeon blaat blaat
vga* at radeon? # ATI Radeon Display blaat blaat
drm* at radeon? # DRM interface for ATI Radeon

altivec* at cpu?
mdmx* at cpu?
mmx* at cpu?
vis* at cpu?

# Generic vector processor
vect* at altivec?
vect* at mdmx?
vect* at mmx?
vect* at vis?
vect* at radeon?

Set acceleration to DRM:
# radeonctl /dev/radeon0 -A drm
Set acceleration to generic vector emulation:
# radeonctl /dev/radeon0 -A vect
Set amount of memory to steal to augment RAM:
# radeonctl /dev/radeon0 -M 192
Set amount of memory to reserve (remaining may be stolen) for graphics:
# radeonctl /dev/radeon0 -m 64

The 'Generic vector processor' I'm referring to is actually a thin compat
layer presenting a nice, clean interface of all the capabilities of the
underlying processor, without significantly hampering performance. All
supported generic and specific (EXT_ as prefix?) operations can be
performed without exposing the inner workings and pecularities of the
processor it is executed upon. Since these operations are supposed to be
low-level, one might envision both a batch submission mechanism, manual
scheduling by the program, and/or even complete scheduling of operations
by the operating system, like we do across CPUs with generic tasks.

Of course, the chance of having something progressive as this taken
seriously by the NetBSD term is probably near-zero. I'm willing to be
proven wrong, but realistically this is not going to happen.

Baai,

De Zeurkous
-----------

Friggin' Machines!

>
> Thanks,
> Marco.
>

-- 
% NetBSD, zsh, twm, nvi and roff junkie
From the fool file:
I don't see why the way people have historically partitioned disks should
dictate which kernels we build and distribute by default in the future.
        --Darren Reed (darrenr@NetBSD.org), NetBSD tech-kern