Re: pcmaudio(4), for fun and games.

[Cherry G. Mathew <cherry%zyx.in@localhost>]

>>>>> "Quentin" == Quentin Garnier <cube%cubidou.net@localhost> writes:


[...]


    Quentin> I am not happy at all with the way autoconf(9) is abused
    Quentin> in that patch.  

This is not very different from how pcppi(4) handles autoconf(9),
actually, it depends on it.

The feeling I got was that the constraint on the pcppi(4) <->
attimer(4) relationship required by midi_pcppi, for example, is hard
to express via autoconf(9) in a generic fashion. (See comment about
dev/ic/attimer.c: attimer_attach_speaker()).

[...]


    Quentin> If I understand that patch correctly, you're basically
    Quentin> attaching an audio device to pcppi(4), pretty much like
    Quentin> we're already attaching a midi(4) device to it.  I don't
    Quentin> see any reason for an intermediate device.

To state what I understand a bit more explicitly: 

autoconf(9) doesn't have a generic mechanism to express
non-hierarchical relationships between instances of devices.

In this example:


--------------ISA-BUS---------------------------
                / \                 ^
               /   \                |
              /     \               |
             /       \              |
      pcppi(4) <---> attimer(4)     |
                 ^                 /
                 |                /
                 |               /
                 |              /
             pcmaudio(4)-------/


ie; pcmaudio(4) can only attach based on the fact that there is an
"association" between a pcppi(4) instance and a attimer(4) and the
fact that both of them are attached to the isa-bus.


At least the following h/w related things need to be frobbed by the
driver:
          - pcppi registers.
          - attimer registers.
          - attimer interrupts.
          - i8254 timecounters.

what I really needed was something like:

attach pcmaudio at pcppi and attimer

or less preferrably (see below),

attach audio at pcppi and attimer with pwmaudio_isa

without which, I toyed with a couple of options:

a) attach audio at pcppi with pwmaudio_isa
b) attach pcmaudio at isa
c) attach pcmaudio at pcppi

a) would seem to imply that the pcppi were in charge of the other two
   entities, namely the attimer counter2, and the ISA bus hardwiring
   (or is this PC XT architecture specific ? ) of the attimer and the
   pcppi speaker output. I can't seem to justify this. A good case in
   point would be the 'hw.xxx.samplingrate' sysctl variable. Would the
   pcppi have a sampling rate ? Certainly not, without having any
   notion of time in the hardware it drives. Would it be a variable in
   audio(4) ? Certainly not, since this is a h/w related variable, not
   a audio(9) API visible one. The sampling rate would therefore be
   more appropriate to a separate 'driver' which would of course,
   implement this by programming the appropriate attimer (assuming
   there were more than one on the board).

b) would have been ideal, since pcmaudio(4) could be thought of as
   driver in charge of a 'device' consisting of a unified subset of
   unused (or carefully stolen) registers on both the attimer and pcppi
   devices. However, this was hard to orchestrate via autoconf(9).

c) is what I chose as a clean alternative - The pcmaudio(4) driver is
  a driver which non-intrusively programs registers actually owned by
  the other two drivers, non-intrusively hijacks the attimer
  interrupt, and interfaces with the audio(4) driver. 

    Quentin> It looks to me you should just set up the audio_attach_mi
    Quentin> call from pcppi_attach_speaker() (because that's where
    Quentin> the pcppi device registers itself to its [hopefully]
    Quentin> matching attimer device, so you're about the existence,
    Quentin> or not, of the attimer device).

I think this can be arranged, irrespective of a) and c), above.

Cheers,
-- 
Cherry