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

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>

The standard suspend sequence involve runtime_resuming
devices before suspending the system.
So just saving context in runtime_suspend and restoring it
in runtime resume isn't enough.  We  must also save in "suspend"
and retore in "resume".

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>

Now that we enter 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...

USB and possibly the GPS UART still have problems with offmode

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>

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.

Input device will appear as
    /dev/input/jack
if the udev rules file in GTA04/udev-rules/input.rules
is installed.

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>

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>

Also fix bug when writing to meas_conf
and arrange for it to be compiled as a module.

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

Conflicts:
	arch/arm/configs/gta04_debug_defconfig
	arch/arm/configs/gta04_defconfig

- discard init_platform_hw and exit_platform_hw as they aren't
  used
- pass GPIO or IRQ to driver and have it initialise the GPIO and
  the IRQ
- finish waiting early if interrupt fires
- clean up GPIO and IRQ on exit.

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

Conflicts:
	arch/arm/configs/gta04_debug_defconfig
	arch/arm/configs/gta04_defconfig
	drivers/misc/bmp085.c

Just having "mpurate=800" in kernel command line doesn't do any good
when cpufreq is enabled.  We need to explicitly enable the higher
operating power points.

So copy the opp_init code from board-omap3beagle.c.  Once cpufreq is
enabled, cpu-bound code can now operate 33% faster.

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

Conflicts:
	arch/arm/mach-omap2/board-omap3gta04.c

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

commit 3339d1e
    mmc: core: Do not rescan non-removable devices

breaks wifi on resume because it stops the rescan.

So clear the 'rescan_entered' flag when we suspend.

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

commit 195e672
   OMAPDSS: DPI: Remove cpu_is_xxxx checks

Made the mistake of assuming that cpu_is_omap34xx() is exclusive of
other cpu_is_* predicates whereas it includes cpu_is_omap3630().

So on an omap3630, code that was previously enabled by
  if (cpu_is_omap34xx())
is now disabled as
  dss_has_feature(FEAT_DPI_USES_VDDS_DSI)
fails.

So add FEAT_DPI_USES_VDDS_DSI to omap3630_dss_feat_list.

Cc: Chandrabhanu Mahapatra <cmahapatra@ti.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: NeilBrown <neilb@suse.de>

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

This patch is based on an earlier patch by Grant Erickson
which provided PWM devices using the 'legacy' interface.

This driver instead uses the new framework interface.

Platform data must be provided to identify which dmtimer to use.

Lots of cleanup and inprovements thanks to Thierry Reding
and Jon Hunter.

Cc: Grant Erickson <marathon96@gmail.com>
Signed-off-by: NeilBrown <neilb@suse.de>

This looks right, but I have another hack in place
to fix the problem, and I think this might becausing
a lock-up on resume.
Need to explore more.

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

various magic copied from changes to other drivers.

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

commit c972143
    usb: musb: twl: use mailbox API to send VBUS or ID events

went a bit too far in removing all event notification
from twl4030-usb.  The notifications are still needed for
twl4030_charger.c to know when to enable the charger.

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

Current kernel will wake from suspend on an event an any active
GPIO event if enable_irq_wake() wasn't called.

There are two reasons that the hardware wake-enable bit should be set:

1/ while non-suspended the CPU might go into a deep sleep (off_mode)
  in which the wake-enable bit is needed for an interrupt to be
  recognised.
2/ while suspended the GPIO interrupt should wake from suspend if and
   only if irq_wake as been enabled.

The code currently doesn't keep these two reasons separate so they get
confused and sometimes the wakeup flags is set incorrectly.

This patch reverts:
 commit 9c4ed9e
    gpio/omap: remove suspend/resume callbacks
and
 commit 0aa2727
    gpio/omap: remove suspend_wakeup field from struct gpio_bank

and makes some minor changes so that we have separate flags for "GPIO
should wake from deep idle" and "GPIO should wake from suspend".

With this patch, the GPIO from my touch screen doesn't wake my device
any more, which is what I want.

Cc: Kevin Hilman <khilman@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Tarun Kanti DebBarma <tarun.kanti@ti.com>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Govindraj.R <govindraj.raja@ti.com>

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