| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: Jonas Bonn <jonas.bonn@gmail.com>
|
|
This file was moved in the big file move, but some OpenMoko specific
changes did not make it. This patch peels out the relevant bits and
adds them to the gpio.h file in the upstream location.
The only OpenMoko specific change is the definition of gpio_to_irq and
irq_to_gpio. These functions should really be defined in gpio_chip and
asm-generic/gpio.h; this is coming soon, but until then we'll just use
the Moko definitions that we've been using up until now.
This is not strictly correct for the GTA02 case, but it works given
the configuration that's currently in use. This can be fixed (and
should become evident) when the configuration options are cleaned up.
Signed-off-by: Jonas Bonn <jonas.bonn@gmail.com>
|
|
This file is OpenMoko specific and didn't get moved in the big file
move. Move it to arch/arm/mach-s3c2410/include/mach where it belongs
and fix the references to it.
Signed-off-by: Jonas Bonn <jonas.bonn@gmail.com>
|
|
After the big include file move these paths ended up incorrect. Fix
these so that this builds cleanly again.
Signed-off-by: Jonas Bonn <jonas.bonn@gmail.com>
|
|
This patch removes a large number of #ifdefs that switch on machine
model. Where applicable, the machine_is_* idiom is favoured; this
mainly makes the code easier to read, but it does have some other
advantages, too.
Signed-off-by: Jonas Bonn <jonas.bonn@gmail.com>
|
|
Problems building with GTA01 disabled in config come down to not selecting the
common CONFIG for GTAXX with GTA02, and GTA01-specific gps stuff.
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
buttons in FSO?]
Michael 'Mickey' Lauer wrote:
...
> The problem is (and this is the reason why I'm crossposting this to the
> kernel mailing list), the kernel is not swallowing the power button
> presses that triggers the resume, so you need some "real" programming
> (as opposed to the expressional complexity of our rules) in order to
> prevent falling asleep right after resume.
>
> Kernel-guys, can we change that?
suppress-resume-onkey-event.patch
This suppresses the key press and key release events from the
power button, in the case where the power button is the wake
event for the GTA01 or GTA02 device.
Signed-off-by: Mike Westerhof <mwester@dls.net>
|
|
Delete old configs in stable-tracking, move defconfig-2.6.27 to the common config site
arch/arm/configs/gta02-moredrivers-defconfig
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Don't change bt regulator at all if already at requested state, and
turn it to opposite on | off state before changing regulator voltage
and setting final state.
Signed-off-by: Sean McNeil <sean@mcneil.com>
|
|
LED trigger gets removed in led_brightness_store???
Signed-off-by: Sean McNeil <sean@mcneil.com>
|
|
Move to level from edge, fix local_save... to local_irq...
simplify bitbang sequence
Signed-off-by: Sean McNeil <sean@mcneil.com>
|
|
Remove unsued PWM stuff around LEDs.
Signed-off-by: Sean McNeil <sean@mcneil.com>
|
|
Adds AC and USB powersupply objects, and a workqueue to automonitor
changes in battery state and fire change events on any change to
selected registers.
Signed-off-by: Sean McNeil <sean@mcneil.com>
|
|
Add /sys files for jack state reporting.
Signed-off-by: Sean McNeil <sean@mcneil.com>
|
|
This patch implements fb_blank() for the glamo-fb driver, which switches off
the pixel clock (DCLK) for power saving.
We currently delay the actual pixel clock switch until we enter
FB_BLANK_POWERDOWN, since the backlight fade is slow and we don't want the
user to see artefacts on the screen while the backlight is fading out.
So since the X server first sends FB_BLANK_{V,H}SYNC_SUSPEND, we start the
backlight fade here, and only once we get FB_BLANK_POWERDOWN the pixel clock is
disabled.
There are no measurements yet, but the power savings should be double, since
there is no longer any generation of the high-frequency LCM signals, and
there are no video-related SDRAM accesses anymore.
Signed-off-by: Harald Welte <laforge@openmoko.org>
|
|
the comment claims that DHCLK is enabled, while the
code actually disables it.
No code change, purely cosmetic patch.
Signed-off-by: Harald Welte <laforge@openmoko.org>
|
|
Remove dead code and coding style fixes. Purely cosmetic.
Signed-off-by: Harald Welte <laforge@openmoko.org>
|
|
FIQ is back up again, changed the stack to point to the post FIQ-vector
area, remove various meddlings needed to try to fix it.
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Qi does not touch the backlight, we have to do it in Linux now
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
FB_BLANK events and switch the JBT6K74 LCM controller into
its power saving mode.
This has the potential of saving something like 50mW during screen blank.
Signed-off-by: Harald Welte <laforge@openmoko.org>
|
|
Thomas White noticed that the recent patch from Andrzej cleaning up a
nasty cast in the resume_dependency stuff for Glamo broke resume. The
problem was that the wrong resume callback was arrived at by the new
code, the one in the device's device_driver struct rather than the
struct platform_driver that actually holds the right pointer.
Since this code will be gone in 2.6.26, I reverted this part of Andrzej's
patch, tidying the cast a bit anyway.
Reported-by: Thomas White <taw27@cam.ac.uk>
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
I'm not sure if this patch if complete/correct, but it seems to fix the
clock problem.
Via: http://marc.info/?l=linux-arm-kernel&m=122322617931931&w=2
|
|
Recent patches from Jonas Bonn seemed to need this addition to compile,
it can be because it was rebased earlier today.
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
This makes the GTA02 work with the new-style WM8753 ALSA I2C driver.
Signed-off-by: Jonas Bonn <jonas.bonn@gmail.com>
|
|
This function (set_brightness) may be called in interrupt context and
therefore should not sleep; use a spin_lock instead of a mutex to ensure
this.
This should take care of the following BUG:
[21474678.340000] BUG: sleeping function called from invalid context at kernel/mutex.c:207
[21474678.340000] in_atomic():1, irqs_disabled():0
[21474678.340000] no locks held by python/1255.
[21474678.340000] [<c002d928>] (dump_stack+0x0/0x18) from [<c003b08c>] (__might_sleep+0xdc/0xf8)
[21474678.340000] [<c003afb0>] (__might_sleep+0x0/0xf8) from [<c02efc08>] (mutex_lock_nested+0x2c/0x264)
[21474678.340000] r5:c03ed754 r4:c03ed6dc
[21474678.340000] [<c02efbdc>] (mutex_lock_nested+0x0/0x264) from [<c022e180>] (neo1973_vib_vib_set+0x2c/0x6c)
[21474678.340000] [<c022e154>] (neo1973_vib_vib_set+0x0/0x6c) from [<c022e6a4>] (led_timer_function+0x8c/0xb4)
[21474678.340000] r6:c041a1a0 r5:c7f34820 r4:0000012c
[21474678.340000] [<c022e618>] (led_timer_function+0x0/0xb4) from [<c004aeb4>] (run_timer_softirq+0x180/0x20c)
[21474678.340000] r5:c7f3482c r4:00000102
[21474678.340000] [<c004ad34>] (run_timer_softirq+0x0/0x20c) from [<c0046368>] (__do_softirq+0x64/0xd8)
[21474678.340000] r8:00000000 r7:00000001 r6:0000000a r5:c0419ff8 r4:00000041
[21474678.340000] [<c0046304>] (__do_softirq+0x0/0xd8) from [<c0046764>] (irq_exit+0x48/0x5c)
[21474678.340000] r6:00000000 r5:c03d128c r4:0000001e
[21474678.340000] [<c004671c>] (irq_exit+0x0/0x5c) from [<c0028050>] (__exception_text_start+0x50/0x68)
[21474678.340000] [<c0028000>] (__exception_text_start+0x0/0x68) from [<c0028a8c>] (__irq_usr+0x4c/0xe0)
[21474678.340000] Exception stack(0xc7d7bfb0 to 0xc7d7bff8)
[21474678.340000] bfa0: 0055bb3a 0000004a 00000000 0055baf0
[21474678.340000] bfc0: 0000004a 0052ae30 00000025 005168e0 00000073 00000025 401281ec 00000000
[21474678.340000] bfe0: 0000006f be9b8470 006e0069 400a8844 60000010 ffffffff
[21474678.340000] r6:00004000 r5:f4000000 r4:ffffffff
Signed-off-by: Jonas Bonn <jonas.bonn@gmail.com>
|
|
Signed-off-by: Jonas Bonn <jonas.bonn@gmail.com>
|
|
|
|
When the config option MACH_NEO1973_GTA02 is not set, then we do not need to
have any access to the FIQ symbols.
Signed-off-by: Jonas Bonn <jonas.bonn@gmail.com>
|
|
These fixes are required to build without MACH_NEO1973_GTA02
Signed-off-by: Jonas Bonn <jonas.bonn@gmail.com>
|
|
I2C devices should be registered with i2c_register_board_info in the machine
setup code. This allows the devices to be auto-probed when the requred driver
is loaded.
Signed-off-by: Jonas Bonn <jonas.bonn@gmail.com>
|
|
Mainly this concerns device registration. Registration should be handled
at the machine level and not in the driver itself. This patch drops
registration at the driver level.
As registration allows for specifying an i2c device address, the setup
data is not needed to be passed to the driver.
Signed-off-by: Jonas Bonn <jonas.bonn@gmail.com>
|
|
The function lm4857_write_regs requires that the i2c_client be available in
the local variable 'i2c'.
Signed-off-by: Jonas Bonn <jonas.bonn@gmail.com>
|
|
Device registration should be handled at the machine level and not
in the driver code itself. This patch removes the device registration
from the driver code in preparation for moving it to the machine
definition.
Signed-off-by: Jonas Bonn <jonas.bonn@gmail.com>
|
|
Fix a couple of thinkos introduced during the I2C API update.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
|
Convert the lm4857 driver in neo1973_wm8753 to the new (standard)
i2c device driver binding model. I assumed that the LM4857 was always
on the same I2C bus as the WM8753 codec.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: Tim Niemeyer <reddog@mastersword.de>
Cc: Graeme Gregory <graeme@openmoko.org>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
|
The error handling in neo1973_init is incorrect:
* If platform_device_add fails, we go on with the rest of the
initialization instead of bailing out. Things will break when the
module is removed (platform_device_unregister called on a device
that wasn't registered.)
* If i2c_add_driver fails, we return an error so the module will not
load, but we don't unregister neo1973_snd_device, so we are leaking
resources.
Add the missing error handling.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: Tim Niemeyer <reddog@mastersword.de>
Cc: Graeme Gregory <graeme@openmoko.org>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Attached is a patch that has greatly reduced the frequency of failures
to resume (due to an oops from the glamo resume handler), and the
dreaded "white screen after resume". I can't say that it fixes all of
these, although I have yet to see the white-screen since applying this
patch and suspending/resuming several hundred times (with the 30-second
suspend on the 2008.8 image and the endless stream of GSM error messages
generated by something in that image, it has proved to be very useful to
do an automated stress test!)
This patch will apply to stable, and should make stable slightly more,
well, "stable".
[Feel free to remove the debug messages if someone feels strongly about
that; I left them in because I think they might be useful in triaging
further crashes; I'm not at all convinced that this patch will fix all
the cases of resume failures.]
[[And, yes, this is ugly, really ugly.]]
[[[Oh yeah - there's still one extreme case that will result in an oops:
if a dependent driver is built as a module, and it is unloaded, and it
happened that the preceding suspend/resume was aborted, and that abort
happened between the dependent driver and the driver upon which it is
dependent, then a list entry will be left behind referencing the
unloaded module. There's just no good way to fix that given the way the
resume dependency plumbing is connected up right now, so just avoid
using modules for any of the drivers involved in the resume dependency
stuff.]]]
Regards,
Mike (mwester)
commit 905d2fc9c45f622418ce9ef4e67c23453aab7571
Author: Mike Westerhof <mwester@dls.net>
Date: Mon Aug 11 11:11:25 2008 -0500
always-call-resume-dependencies.patch
Ensure that a dependent resume handler is always executed,
even if the resume handler for driver upon which it is
dependent never suspends (and therefore never resumes either).
Also make sure that we do not end up with duplicate
dependencies registered, something that can happen if the
suspend is aborted due to driver failure or an early resume
(such as occurs when the GSM interrupts during suspend).
Signed-off-by: Mike Westerhof <mwester@dls.net>
|
|
I hit this when updating to 2.6.26. Also if CONFIG_MMC is enabled this
patch converts this horrible horrible hack into a horrible hack by using
dev->resume() (untested).
Signed-off-by: Andrzej Zaborowski <balrog@zabor.org>
|
|
This patch adds another module parameter to glamo-mci which sets the
SD Card clock rate used inbetween powering the card and the completion of
the first bulk transfer. You can set it from kernel commandline like this.
glamo_mci.sd_post_power_clock=1000000
The period between changing the power state and the first bulk transfer
completion is critical because larger SDHC cards take longer to initialize
before they can service the bulk transfer, and the Glamo MMC unit has a
fixed timeout length of a maximum of 4095 x 16 x SD Card clocks. Large
cards like 8GB Sandisk SDHC are not ready before this timeout is used up
at default 16MHz.
Subsequently, the card can handle 16MHz SD Clock and timeout durations
okay.
By default this patch operates the SD Clock at only 1MHz until the first
bulk transfer is completed after each powerup action from the MCI stack. It
also keeps the SD Clock running during this time, and disables the SD Clock
if the card is not present and the MCI stack removes power.
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
I needed the following two changes for g_ether to work with last
week's stable-tracking and no CONFIG_DEBUG_FS. I don't know if
they're related to moko patches, if not I can send them upstream
isntead.
BTW I need to boot off the SD card now because mtd only returns CRC
errors and doesn't mount. Does it work for other people?
Signed-off-by: Andrzej Zaborowski <balrog@zabor.org>
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
- pca9632 is a LED driver which will be adopted in gta03.
Signed-off-by: Matt Hsu <matt_hsu@openmoko.org>
|
|
This patch is a work-around solution to correct charging indication logic.
Signed-off-by: Matt Hsu <matt_hsu@openmoko.org>
|
