Subject: Re: autoconf(9) tree in an odd hardware arrangement
To: Michael Lorenz <macallan@netbsd.org>
From: Marco Trillo <marcotrillo@gmail.com>
List: tech-kern
Date: 12/03/2007 12:25:25
Hi ,

On Nov 25, 2007 11:51 PM, Michael Lorenz <macallan@netbsd.org> wrote:
> > On 11/25/07, Michael Lorenz <macallan@netbsd.org> wrote:
> >>>> The intention was to factor out all the DBDMA goo that's more or
> >>>> less
> >>>> the same in snapper and awacs so we can also have:
> >>>> snapper* at audiodma?
> >>>> daca* at audiodma?
> >>>> dumbcodec* at audiodma?
> >>>> g3audio* at audiodma?
> >>>
> >>> Then the i2s driver could be attached to audiodma too... so the i2s
> >>> driver would only need to do things like setting up the I2S clocks
> >>> and configuring or
> >>> dealing with the gpio stuff (headphones, lineouts, etc.).
> >>
> >> Something like that - I'm not sure they all use the same gpios.
> > Other differences are that some machines have a line-out output
> > with all its
> > associated gpio nodes and interrupts; while other machines have only
> > headphones and speaker.
>
> Yeah, we'd probably need something to parse that sound-objects
> prioperty in order to find out which output is in use.

To make things worse, I discovered that some I2S-based models, in
particular the 'daca'-based ones (which seem to be the first models
that used I2S) don't have any `gpio' nodes at all.

So I think that in order to find the GPIO control to detect the
headphone presence the only way is to parse the `sound-objects' node,
which contains the relative address and the sense-match bits. Other
alternative is to hardcode the address (and the sense bits), which is
what the Darwin driver does, but the `sound-objects' property is
probably the way to go, especially since some screamer-based models
also have it.

So I'll try to write a parser for the sound-objects. I have collected
device trees of the models which have the property so it'll be easy to
test that it works before including it in any driver.

Another problem I've found with such models is that neither the device
tree nor the `sound-objects' proprety mention any interrupt for
detecting the port change. I looked at the Darwin driver but it's
weird since it uses polling... however it does mention in a comment
that it should use an interrupt, so I suspect that it does generate an
interrupt.
What do you think?

Thanks,
Marco

[PS: Perhaps I should have changed the subject, since this is not
related to the autoconf question now]