| Age | Commit message (Collapse) | Author |
|---|
|
Last rebase to stable-2.6.26 left some trash from rebasing the patches on top of this,
clean it back out
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
We always return -EINVAL when changing s3c2410 USB host and device modes
due to lack of { }.
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
More effort to refine power code that does the suspend and resume actions
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Weeks of frantic effort to control Glamo, traced the issue to two outcomes:
nWAIT is forced down and the device is hard locked, or we survive immediate
Glamo resume and die again with nWAIT forced down when the framebuffer driver
tries to flash the soft cursor.
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Big chunk of trying to own Glamo resume and not really succeeding
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Stop the debugging stuff, see if that impacts resume error (not really, it
was actually Glamo)
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Light an LED in the dark crashing hell of dead resume... the problems come from
Glamo it turns out
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
All that stuff should be enforced by device tree now, out with it
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Hum well that's the idea, Glamo did not play ball
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
We panic on SD boot now we changed Glamo order, because it
didn't succeed to bring up mmcblk0p1. But, if you do loglevel=8
then it works OK. So we are racing with something...
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Nasty temporary patch that is VERY useful, basically if you hit AUX key
during suspend time, it will force an OOPS, which due to another debug patch
forces a spew on serial console showing dmesg to date and the oops.
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Backout from failed probe was quite broken.
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
We shouldn't have to reset it in glamo probe
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Running heavily instrumented kernel, get report about glamo IRQ spinlock
probem.
[ 8.795000] =============================================
[ 8.795000] [ INFO: possible recursive locking detected ]
[ 8.795000] 2.6.24 #782
[ 8.795000] ---------------------------------------------
[ 8.795000] swapper/1 is trying to acquire lock:
[ 8.795000] (&irq_desc_lock_class){++..}, at: [<c0077ae4>] handle_level_irq+0x24/0x120
[ 8.795000]
[ 8.795000] but task is already holding lock:
[ 8.795000] (&irq_desc_lock_class){++..}, at: [<c01be628>] glamo_irq_demux_handler+0x24/0x140
[ 8.795000]
[ 8.795000] other info that might help us debug this:
[ 8.795000] 1 lock held by swapper/1:
[ 8.795000] #0: (&irq_desc_lock_class){++..}, at: [<c01be628>] glamo_irq_demux_handler+0x24/0x140
[ 8.795000]
[ 8.795000] stack backtrace:
[ 8.795000] [<c002ec28>] (dump_stack+0x0/0x14) from [<c006ad74>] (__lock_acquire+0x9a0/0xdec)
[ 8.795000] [<c006a3d4>] (__lock_acquire+0x0/0xdec) from [<c006b264>] (lock_acquire+0xa4/0xc0)
[ 8.795000] [<c006b1c0>] (lock_acquire+0x0/0xc0) from [<c02f7878>] (_spin_lock+0x44/0x78)
[ 8.795000] [<c02f7834>] (_spin_lock+0x0/0x78) from [<c0077ae4>] (handle_level_irq+0x24/0x120)
[ 8.795000] r6:c03e11c0 r5:0000005c r4:c03e11c0
[ 8.795000] [<c0077ac0>] (handle_level_irq+0x0/0x120) from [<c01be708>] (glamo_irq_demux_handler+0x104/0x140)
[ 8.795000] r7:00000038 r6:c03e11c0 r5:00000008 r4:c03e0560
[ 8.795000] [<c01be604>] (glamo_irq_demux_handler+0x0/0x140) from [<c003c934>] (s3c_irq_demux_extint8+0x94/0xa4)
[ 8.795000] r8:00000002 r7:00000003 r6:00000000 r5:c03df958 r4:00000000
[ 8.795000] [<c003c8a0>] (s3c_irq_demux_extint8+0x0/0xa4) from [<c0029048>] (__exception_text_start+0x48/0x64)
[ 8.795000] r4:00000015
[ 8.795000] [<c0029000>] (__exception_text_start+0x0/0x64) from [<c0029a5c>] (__irq_svc+0x3c/0xb4)
Patch removes desc->lock locking around glamo_irq_demux_handler... guess it is OK
since we didn't clear interrupt source, can't recurse?
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
If we ever fall through to the yield when we turned off interrupts...
it wouldn't be pretty.
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Along the same lines as FIQ, HDQ can have children in device tree terms too.
Allow the same kind of callback in machine-specific code
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Trial to see if (mainly 32-bit) memcpy is any better than u16 loop
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
The delay versions of the access to registers were based on a misunderstanding of
the Glamo docs: it can force nWAIT differently depending on the access type. Therefore
we don't need to take special care about delays on CPU side.
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>
|
|
Rather than using conservative default timings for the NAND flash,
use the timings as specified in the S3C2442B MCP data sheet.
Signed-off-by: Harald Welte <laforge@openmoko.org>
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Removed unused variable.
Signed-off-by: Nelson Castillo <nelsoneci@gmail.com>
|
|
The function glamo_mci_reset is not being used. Let's comment it out.
Signed-off-by: Nelson Castillo <nelsoneci@gmail.com>
|
|
This patch carries over the OpenMoko modifications at
include/asm-arm/arch-s3c2410/spi-gpio.h to
arch/arm/mach-s3c2410/include/mach/spi-gpio.h
Note: board_size and board_info have been removed upstream, but as we
still rely on them we'll just put them back for now. These will need to
be removed (and the corresponding driver changes made, of course) before
this can go upstream.
Signed-off-by: Jonas Bonn <jonas.bonn@gmail.com>
|
|
This pulls the Moko changes to regs-sdi.h that were in
include/asm-arm/arch-s3c2410 over to the file at arch/arm/../mach and
deletes the file at include/asm-arm.
Note: we have been using a mix of regs-sdi.h from the two different
locations. The unification of these two files may have some unknown
consequences... keep your eyes open for oddities after applying this.
Signed-off-by: Jonas Bonn <jonas.bonn@gmail.com>
|
|
Signed-off-by: Jonas Bonn <jonas.bonn@gmail.com>
|
|
Signed-off-by: Jonas Bonn <jonas.bonn@gmail.com>
|
|
Signed-off-by: Jonas Bonn <jonas.bonn@gmail.com>
|
|
Signed-off-by: Jonas Bonn <jonas.bonn@gmail.com>
|
|
Signed-off-by: Jonas Bonn <jonas.bonn@gmail.com>
|
|
Remove unneeded spaces and coding style fixes. Purely cosmetic.
|
|
Signed-off-by: Andy Green <andy@openmoko.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>
|
|
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>
|
|
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>
|
