Name already in use

http://lists.goldelico.com/pipermail/gta04-owner/2012-September/002961.html

On Thu, 13 Sep 2012 19:03:26 +0200 Christoph Mair <christoph.mair at gmail.com>
wrote:

> On Wed, Sep 12, 2012 at 8:38 PM, Radek Polak <psonek2 at seznam.cz> wrote:
> > QtMoko v48 is out now, you can download images for Freerunner and GTA04 from
> > here [1][2]. For more info about QtMoko please visit our homepage [3].
>
> Thanks for another great release!
>
> >   * changes for 3.5 kernel on gta04
> >   * turning of gps antena on gta04 during startup to save power
>
> I've noticed that my device does not recognize the external antenna
> anymore. The VSIM regulator which supplies the antenna delivers only
> 1.8V instead of 2.8V. I haven't looked at the kernel source yet, but
> there might be a bug somewhere because 'cat
> /sys/class/regulator/regulator.8/microvolts' returns 1.8V while the
> min and max parameters are set to 2.8V

Try

diff --git a/arch/arm/mach-omap2/board-omap3gta04.c b/arch/arm/mach-omap2/board-omap3gta04.c
index 8d750d2..19b9fe3 100644
--- a/arch/arm/mach-omap2/board-omap3gta04.c
+++ b/arch/arm/mach-omap2/board-omap3gta04.c
@@ -572,6 +572,7 @@ static struct regulator_init_data gta04_vsim = {
 		.name			= "VSIM",
 		.min_uV			= 2800000,
 		.max_uV			= 2800000,
+		.apply_uV		= 1,
 		.valid_modes_mask	= REGULATOR_MODE_NORMAL
 					| REGULATOR_MODE_STANDBY,
 		.valid_ops_mask		= REGULATOR_CHANGE_VOLTAGE

without this, it just assumes the voltage is correct.

NeilBrown

there is no need for software routing on gta04a4

Power management is still not ok. Using the voice routing
does not yet automatically power on the amps on the microphone side.
But that can be reached using some alsa settings.

Signed-off-by: Andreas Kemnade <andreas@kemnade.info>

Conflicts:
	sound/soc/codecs/twl4030.c

…', 'hso', 'mmc', 'serial', 'sensors', 'touchscreen', 'hdq-paul', 'suspend', 'dtr', 'devicetree', 'bugs', 'f2fs' and 'gta04' into mainline

pressures is being reported inverted  - fix that

Signed-off-by:  NeilBrown <neilb@suse.de>

One an hdq buss, a missing device reads as 0xff, not -1.
So do a translation to allow detecting of a missing bus.

Signed-off-by: NeilBrown <neilb@suse.de>

Seems to work at all

Signed-off-by: NeilBrown <neilb@suse.de>

If CORE and USBHOST both go the off-mode the first time
USBHOST does, then my device will not resume.
However if we let USBHOST go to off-mode and back will CORE is
in RETENSION at most, then subsequent off-mode transitions are
not a problem.

So for RETENTION for the first transition, and OFF for the next.

Signed-off-by: NeilBrown <neilb@suse.de>

It is possible that the  musb device will be runtime-active (not
suspended) when system suspend happens.
In particular, usb_suspend() will have called choose_wakeup() which
might have called  pm_runtime_resume().

In that case, after system-resume, the state of the device will be
'active', but the state of the registers will have been lost (if
off_mode is enabled).

So we need to save_context in musb_suspend (if runtime state is
active), and restore_context on resume.

This effectively reverts

  5d193ce (usb: musb: PM: fix context save/restore in suspend/resume path)

and adds a rest to avoid saving/restoring context if device is already
runtime suspended.

Tested-by: Kevin Hilman <khilman@deeprootsystems.com>
Cc: "Bilovol, Ruslan" <ruslan.bilovol@ti.com>
Cc: Igor Grinberg <grinberg@compulab.co.il>
Signed-off-by: NeilBrown <neilb@suse.de>

I'm sure  sure that this does anything useful, but
let's have the code there and see.

Signed-off-by: NeilBrown <neilb@suse.de>

Before we enable off-mode, we really need the wakeup
to work, and I broke it recently.

Signed-off-by: NeilBrown <neilb@suse.de>

Maybe this will cause problems, maybe it will help...

This primarily removes the pull up/down, which shouldn't
be much of a problem, but is best avoided.

Signed-off-by: NeilBrown <neilb@suse.de>

Signed-off-by: NeilBrown <neilb@suse.de>

If get_madc_conversion returns an error, we should ignore the value.

Reported-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Signed-off-by: NeilBrown <neilb@suse.de>

It provides no value

Signed-off-by: NeilBrown <neilb@suse.de>

The context loss handling in dmtimer appears to assume that
   omap_dm_timer_set_load_start() or omap_dm_timer_start()
and
   omap_dm_timer_stop()

bracket all interactions.  Only the first two restore the context and
the last updates the context loss counter.
However omap_dm_timer_set_load() or omap_dm_timer_set_match() can
reasonably be call outside this bracketing, and the fact that they
call omap_dm_timer_enable() / omap_dm_timer_disable() suggest that
is expected.

So if, after a transition into and out of off-mode, which would cause
the dm timer to loose all state, omap_dm_timer_set_match() is called
before omap_dm_timer_start(), the value read from OMAP_TIMER_CTRL_REG
will be 'wrong' and this wrong value will be stored context.tclr so
a subsequent omap_dm_timer_start() can fail (As the control register
is wrong).

Simplify this be doing the restore-from-context in
omap_dm_timer_enable() so that whenever the timer is enabled, the
context is correct.
Also update the ctx_loss_count at the same time as we notice it is
wrong - these is no value in delaying this until the
omap_dm_timer_disable() as it cannot change while the timer is
enabled.

Signed-off-by: NeilBrown <neilb@suse.de>

Signed-off-by: Marek Belisko <marek.belisko@open-nandra.com>

Enhance jack detection to differentiate with and without a microphone,
and to report a button-press when the microphone is shorted.

Signed-off-by: NeilBrown <neilb@suse.de>

As headset-insert doesn't generate an interrupt we need to
poll the MICSENSE line to see if a headset is present.
We do this every 500ms.  It takes nearly that long to physically
insert a jack, so much faster wouldn't help and would impact
power drain more.

As detection is done by polling, a jack-insert or removal event cannot
wake the device from suspend.  Events are only detected while device
is awake.

We keep the HSMIC bias enabled whenever the 'input' device is open,
except during suspend so that we can poll reliably.  Turning it off
and on seems to interfere with reliable measurements.

Currently a reading below 100 is 'nothing plugged in' while a reading
above that is 'mic and headphone plugged in'.
I measure between 19 and 26 when nothing is plugged in, and between
804 and 811 when a headset is plugged in.

Signed-off-by: NeilBrown <neilb@suse.de>

works with new jack driver support.

Signed-off-by: NeilBrown <neilb@suse.de>

Useful for testing.

  /sys/class/hwmon/hwmon0/device/in7_input

show the reading for MICSENSE which detects a jack plugged in.

You need HSMIC_BIAS enabled which is forced by the next patch
or can be achieved with alsamixer by
  "Analog Left Headset Mic"  set to capture, and so loopback enabled,
  e.g.
    HeadsetL Mixer AudioL1  not muted
    Left1 Analog Loopback   not muted

Signed-off-by: NeilBrown <neilb@suse.de>

This is more appropriate than 'powersave' which always uses lowest
speed.

Reported-by: Radek Polak <psonek2@seznam.cz>
Signed-off-by: NeilBrown <neilb@suse.de>

Mostly about __initdata section mismatches.

Signed-off-by: NeilBrown <neilb@suse.de>

Add new gyroscope driver to defconfig

Signed-off-by: NeilBrown <neilb@suse.de>

Each axis can be individually disabled to save power.
Sample rate can be set.
Appropriate clock is set automatically.

No triggers implemented yet, so no streaming of data.  Just read
it from sysfs.

Signed-off-by: NeilBrown <neilb@suse.de>