LKML Archive on
help / color / mirror / Atom feed
Subject: Re: [UPDATED v4] WM97xx touchscreen drivers
Date: Tue, 5 Feb 2008 18:20:15 -0500 (EST)	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

> The expectation of this driver is that the battery monitor driver will
> register as the "wm97xx-battery" device and use the wm97xx_read_aux_adc()
> function exported by the wm97xx-core driver to access the ADC.  Is your
> driver using this interface?

Yes, but this makes the wm97xx-battery device depend on configuring in the

The problem we're having is that when we updated wm97xx-core.c from
version 0.62 to 0.65 the ADC values returned by wm97xx_read_aux_adc() to
the battery driver changed.  We did modify both versions to make the
struct wm97xx * global so the battery monitor could pass it to
wm97xx_read_aux_adc() (is there a better way?).

> The intention is that these drivers should be able to coexist with the
> existing ASoC drivers as-is.  We do have existing users doing this - the
> first publicly available example that springs to mind is tosa which
> also uses the wm9712 with touchscreen and battery, together with the
> ASoC driver for audio (the ASoC bits of this have been merged since ASoC
> was merged in 2006, the other bits are out of tree partly due to the
> fact that they depend on this driver).

They don't just coexist with soc, they depend on it.  If you configure out
the AC97 driver under soc the touchscreen and battery drivers won't work
(but they'll build).  We used the same architecture as tosa and retained
the OH guys for the app framework (and platform assistance - thanks RP :).

> The most obvious way forward if we can't resolve these problems with the
> existing scheme is to pull out the core driver as you say above - this
> is the approach already taken by the touch drivers to allow battery
> monitoring while the touchscreen is in use.

In my mind the wm97xx-core module is independent and exposes an API backed
by wm9712/13/etc.  Layered above that, built into their respective code
areas, are the sound, touchscreen, battery monitor, various platform usage
of the aux ADC channels, etc.  I'm not saying this is possible, without
caveat, or practical, but I would say academically ideal.  Thanks for
keeping the conversations going, as I appreciate these drivers moving into
mainline which reduces our maintenance impact.

> Is your kernel (or the wm9712-related code at least) publicly available?
> If not would it be possible for you to share it with me off-list?  It
> might help me understand what's going on here.

The first release is publicly available; the release I'm working on was
aimed for the 2.6.24 merge window but some key stuff (ARM clock/power
management, USB gadget) changed causing me to re-engineer.  I'm still
troubleshooting some 2.6.18-->24 port issues here (pxa27x_ac97 errors on
resume - we use deep sleep, not sleep on the pxa270), but can publicize a
source tarball and send you the link.

  reply	other threads:[~2008-02-05 23:20 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-04 19:00 linux01
2008-02-04 21:31 ` Mark Brown
2008-02-05 23:20   ` linux01 [this message]
2008-02-06 13:57     ` Mark Brown
  -- strict thread matches above, loose matches on Subject: below --
2008-01-26 15:18 Mark Brown
2008-01-29 22:03 ` Dmitry Baryshkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \
    --subject='Re: [UPDATED v4] WM97xx touchscreen drivers' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).