[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: pcmaudio(4), for fun and games.
>>>>> "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
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:
/ \ ^
/ \ |
/ \ |
/ \ |
pcppi(4) <---> attimer(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
- 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.
Main Index |
Thread Index |