[RFC] snd-aoa and interrupts (headphone detection etc)

[RFC] snd-aoa and interrupts (headphone detection etc)

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 2668 bytes --]

Hey,

I thought about this a bit, but I'm not sure what the right way to
handle this is. First, I guess an introduction is on order about how the
fabrics and codecs currently work together.

As codecs can have arbitrary inputs and outputs, we have to keep this
generic enough. The tas for example has one analog output, and two
analog inputs (line-in and microphone). The analog output it has is
connected to the amps and then you can select where you want to hear
sound (possibly line-out, headphone, speakers) by controlling the amps
via the GPIOs.
On the other hand, the onyx for example has digital and analog output
along with two analog inputs. Instead of limiting myself to any fixed
items I decided to keep this generic. I probably should change this to
introduce fixed bits for various items though.

Anyway, the fabric has the hardcoded list of how things are hooked up,
and then creates a bitmap of which in/outputs of a codec are connected
and gives this bitmap to the codec driver which creates the appropriate
controls if applicable. This is currently only implemented properly for
the Onyx chip though.

Now, in- and output detection comes into play. The interrupt is always
generated via GPIOs.

Headphone detection is easy: We make the fabric register the interrupt
via the GPIO layer and when we get an interrupt we actually simply do
whatever the user wanted (this ought to be controllable).

The problematic part is things that the codec must control. Say we want
line-in detection to automatically switch to line-in if microphone is
selected (does anyone ever want this?). Then the problem is that the
interrupt arrives at the GPIO layer, and I can easily make it seen in
the fabric too. However, then propagating it to the codec is a bit
harder. Or we don't have it in the fabric but have the codec register
for that interrupt (through our GPIO layer). This is the first option.

The second option is changing the whole in-/output control code that we
have and moving it from the codec to the fabric layer. The fabric
already knows what in- and outputs a codec has (in order to know what is
connected), hence if we added a codec driver function to turn on/off any
in- or output we could have the fabric control this. But then we'd also
have to make known to the codec which of those are mutually exclusive,
and generally make it more complicated.

I currently favour the first option, the codec driver can know when it
makes sense to try registering the interrupt (if it isn't present it
fails anyway) and then do the appropriate stuff (possibly giving the
user a choice).

Comments?
johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]

Re: [RFC] snd-aoa and interrupts (headphone detection etc)

[Benjamin Herrenschmidt]

> The problematic part is things that the codec must control. Say we want
> line-in detection to automatically switch to line-in if microphone is
> selected (does anyone ever want this?). Then the problem is that the
> interrupt arrives at the GPIO layer, and I can easily make it seen in
> the fabric too. However, then propagating it to the codec is a bit
> harder. Or we don't have it in the fabric but have the codec register
> for that interrupt (through our GPIO layer). This is the first option.

No. I don't think the codecs should mess with the GPIOs directly. The
policy should be implemented in the fabric. If in some case you need to
change some codec settings, then the codec shall provide an accessor for
doing so.

> The second option is changing the whole in-/output control code that we
> have and moving it from the codec to the fabric layer. The fabric
> already knows what in- and outputs a codec has (in order to know what is
> connected), hence if we added a codec driver function to turn on/off any
> in- or output we could have the fabric control this. But then we'd also
> have to make known to the codec which of those are mutually exclusive,
> and generally make it more complicated.

We don't have to make known to the codec, we just turn on/off the right
ones.

> I currently favour the first option, the codec driver can know when it
> makes sense to try registering the interrupt (if it isn't present it
> fails anyway) and then do the appropriate stuff (possibly giving the
> user a choice).

I disagree :) But then, it's your code :)

Ben.

Re: [RFC] snd-aoa and interrupts (headphone detection etc)

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1825 bytes --]

On Sat, 2006-05-27 at 07:45 +1000, Benjamin Herrenschmidt wrote:
> > The problematic part is things that the codec must control. Say we want
> > line-in detection to automatically switch to line-in if microphone is
> > selected (does anyone ever want this?). Then the problem is that the
> > interrupt arrives at the GPIO layer, and I can easily make it seen in
> > the fabric too. However, then propagating it to the codec is a bit
> > harder. Or we don't have it in the fabric but have the codec register
> > for that interrupt (through our GPIO layer). This is the first option.
> 
> No. I don't think the codecs should mess with the GPIOs directly. The
> policy should be implemented in the fabric. If in some case you need to
> change some codec settings, then the codec shall provide an accessor for
> doing so.

Yeah. That was my second option mostly.

> > The second option is changing the whole in-/output control code that we
> > have and moving it from the codec to the fabric layer. The fabric
> > already knows what in- and outputs a codec has (in order to know what is
> > connected), hence if we added a codec driver function to turn on/off any
> > in- or output we could have the fabric control this. But then we'd also
> > have to make known to the codec which of those are mutually exclusive,
> > and generally make it more complicated.
> 
> We don't have to make known to the codec, we just turn on/off the right
> ones.

Hmm, ok, good point, then we don't even need the complication of telling
the codec what is connected to it. Maybe that simplifies the code in
total... But the codecs will still need hardcoded numbers for the
various in- and outputs that the fabric needs to know.

I'll think about this a bit more, maybe experiment with the code a
bit :)

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]