| Age | Commit message (Collapse) | Author |
|---|
|
By avoiding conflicts of memory access inside Glamo, this doubles the
speed of internal memory access.
Signed-off-by: Thomas White <taw@bitwiz.org.uk>
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
|
|
Fix compilation error due to missing semicolon
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
|
|
Clean up debugging messages so that we don't see any output with loglevel=4
(default for Qi). This avoids slowing down suspend/resume by slow fb
output.
Checkpatch barks on this patch but i guess most of that debugging would
have to be changed prior to upstream submission anyway.
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
|
|
This patch fixes a linking failure in the Glamo GPIO SPI bitbang support.
Signed-off-by: Rask Ingemann Lambertsen <rask@sygehus.dk>
|
|
This patch fixes some indentation which was off by one and converts
spaces to tabs.
Signed-off-by: Rask Ingemann Lambertsen <rask@sygehus.dk>
|
|
Distributions that use Xorg will not need the workaround at
all and now they can disable it.
Updated configurations to enable it by default.
Signed-off-by: Nelson Castillo <arhuaco@freaks-unidos.net>
|
|
~ Cleanup of a redundant call I introduced before.
~ Removed useless assignation.
Signed-off-by: Nelson Castillo <arhuaco@freaks-unidos.net>
|
|
To disable the workaround at run-time run:
echo 0 > /sys/class/i2c-adapter/i2c-0/0-0073/pcf50633-regltr.9/glamo3362.0/glamo-fb.0/xglamo_hack
I guess I should add a compile option now to completely disable the workaround but let's call
this an enhancement and let's close the bug now.
By default the workaround is enabled.
Signed-off-by: Nelson Castillo <arhuaco@freaks-unidos.net>
Reported-by: Timo Juhani Lindfors <timo.lindfors@iki.fi>
|
|
issue""
This reverts commit aa2dbc74bed8cf60e591c654ba1882011b9a8ece.
Reverting the revert. Sorry for the noise.
Check:
http://lists.openmoko.org/pipermail/openmoko-kernel/2009-April/010023.html
|
|
This reverts commit bd4b7e8e84ab43a13a4620b001d52d373c2122b3 which brought
WSOD back for some devices.
It was reported that the problem does not happen with Qi and it
seem it is good news. See:
https://docs.openmoko.org/trac/ticket/2274
Conflicts:
drivers/video/display/jbt6k74.c
|
|
Space transition between sleep-in and sleep-out of at least
120 ms as mentionned in the spec. Also, made sure the LCM
is moved into sleep state before the pixel clock is turned off.
To do so, I've modified glamo-fb to send FB_BLANK_POWERDOWN before
turning off the pixel clock. Also fixed various violation of coding
style. This patch should reduce the risk of white screen.
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@gmail.com>
|
|
The kernel would fail to link because cfb_fillrect, cfb_copyarea and
cfb_imageblit weren't build. This patch fixes it.
Signed-off-by: Rask Ingemann Lambertsen <rask@sygehus.dk>
|
|
spigpio_info.
X-Git-Url: http://git.openmoko.org/?p=kernel.git;a=commitdiff_plain;h=740c6704e830829d8539a6cc34346ff1980cd9ee
Get rid of board_info information in glamo and s3c24xx_gpio spigpio_info.
The board info does not belong there and has been removed. In
spi_s3c24xx_gpio, board_info has been removed in mainline.
Signed-off-by: Balaji Rao <balajirrao@openmoko.org>
|
|
This patch moves the bulk transfer action outside of
interrupt context, along with the STOP transmission action
for multiblock transfers.
It's prompted by
https://docs.openmoko.org/trac/ticket/2180
But it can impact throughput to SD card, so it's for testing
currently.
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
It looks like I made a mistake in the original pan implementation that
is now getting exercised. The following fixes pan again.
Cheers,
Sean
|
|
People on bug
https://docs.openmoko.org/trac/ticket/2217
experiencing problems with default emmory settings on Glamo
reported that changing reg 0x200 <- 0xef0 as in 2.6.24 made
the problem not reproducible any more.
However this changes three bitfields, two are to do with
waitstates before sampling read and write cycles off the
bus, and the last is to do with which PLL provides the clock
to the memory interface unit logic. The old settings has
all three of these very conservative, 3 waitstates and using
the 50MHz PLL instead of the 90MHz one; the new default
setting has all of these at their fastest of 0 wait states
and the 90MHz PLL.
This patch adds some more granular tests to the same
glamo3362.slow_memory=
parameter to see if we can find some middle ground. For
example the issue may be the waitstates and not the PLL
source, in which case even users with the bad Glamo
behaviour can have the advantage of the faster PLL / bus
bandwidth.
0 90MHz PLL, no wait states (default)
1 50MHz PLL, 3 wait states
2 50MHz PLL, 2 wait states
3 50MHz PLL, 1 wait state
4 50MHz PLL, no wait states
5 90MHz PLL, 3 wait states
6 90MHz PLL, 2 wait states
7 90MHz PLL, 1 wait state
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
X-Git-Url: http://git.openmoko.org/?p=kernel.git;a=commitdiff_plain;h=3b09161ffa5f29870d1f2cab1442f79ff2017b69
glamo_fix_improper_xrandr_geometry_setting.patch
Switching to xrandr -o 3 from xrandr -o 1 caused the screen to look crazy
because of the way lcd geometry is set in glamo. This patch fixes it.
Signed-off-by: Balaji Rao <balajirrao@openmoko.org>
|
|
X-Git-Url: http://git.openmoko.org/?p=kernel.git;a=commitdiff_plain;h=40fe0a30c75937a476ea50220814ca8b1fd81b45
fix_glamo_xrandr_bug.patch
This patch reintroduces the 2-cycle delay used when accessing glamo-fb
registers. This seems to be required even when the corresponding
registers in HOST_BUS are off.
Signed-off-by: Balaji Rao <balajirrao@openmoko.org>
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
hes-tracking-fix-stray-endmenu-patch-1232632040-1232632141
pending-tracking-hist top was MERGE-via-stable-tracking-MERGE-via-mokopatches-tracking-fix-stray-endmenu-patch-1232632040-1232632141 / fdf777a63bcb59e0dfd78bfe2c6242e01f6d4eb9 ... parent commitmessage:
From: merge <null@invalid>
MERGE-via-stable-tracking-hist-MERGE-via-mokopatches-tracking-fix-stray-endmenu-patch-1232632040
stable-tracking-hist top was MERGE-via-mokopatches-tracking-fix-stray-endmenu-patch-1232632040 / 90463bfd2d5a3c8b52f6e6d71024a00e052b0ced ... parent commitmessage:
From: merge <null@invalid>
MERGE-via-mokopatches-tracking-hist-fix-stray-endmenu-patch
mokopatches-tracking-hist top was fix-stray-endmenu-patch / 3630e0be570de8057e7f8d2fe501ed353cdf34e6 ... parent commitmessage:
From: Andy Green <andy@openmoko.com>
fix-stray-endmenu.patch
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Fix suspend/resume dummy in glamo-fb.c
Signed-off-by: Werner Almesberger <werner@openmoko.org>
|
|
When building the MMC subsystem as modules,
drivers/mfd/glamo/glamo-mci.ko cannot access irq_desc, because it
isn't exported by kernel/irq/handle.c All the functions that
indirectly access irq_desc are inlined, so they cannot be used to
avoid having to resolve irq_desc.
Fortunately, we can solve the problem locally: we don't really need
to access irq_desc anyway. This patch splits glamo_mci_irq into a
small wrapper that implements the IRQ handler interface and the main
code that doesn't need to know about the semantics of the latter.
Then we simply call the main code with the information we already
have.
Signed-off-by: Werner Almesberger <werner@openmoko.org>
Tested-by: Rafael Ignacio Zurita <rizurita@yahoo.com>
|
|
Sometimes we see failures with cards where the status is eg, 0x310.
This corresponds to a "no data" timeout and an assertion that the
data is present. This patch makes the data present status have
priority over the timeout status.
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
mc-insanity-1228425445
pending-tracking-hist top was MERGE-via-stable-tracking-workaround-glamo-mmc-insanity-1228425445 / 8c97326a7ad33d8690a4b433abc14918e5900e58 ... parent commitmessage:
From: merge <null@invalid>
MERGE-via-stable-tracking-hist-workaround-glamo-mmc-insanity-
stable-tracking-hist top was workaround-glamo-mmc-insanity- / 7a55cd6f948a33c4452dd99da39e15efe832f2e2 ... parent commitmessage:
From: sprite_tm <unknown@invalid>
workaround-glamo-mmc-insanity-timeout-warning-only.patch
Modified version of one line patch from
https://docs.openmoko.org/trac/ticket/2078
by sprite_tm
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Now the card is powered when we send the last command from the stack,
SELECT CARD with arg 0, we learn that the card can't reply when
deselected. So detect SELECT CARD and arg 0 and don't bother waiting
for an ack that isn't coming. This chops three seconds off suspend :-)
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Nothing on the card can really take 3s.. reduce to 300ms
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Now Qi is changed to default to loglevel 4 where it will show KERN_ERR on
LCM, we need to reduce the debugging KERN_ERR traffic so as not to
obscure the real things.
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Changes the glamo-mci driver to use the regulator API.
|
|
Work in progress.
|
|
Glamo GPIO are not set correctly after resume / reset action.
This patch forces them to correct state for GTA02.
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Signed-off-by: Sean McNeil <sean@mcneil.com>
|
|
Subject: [PATCH] glamofb: Initialize only visible part of the memory.
It takes lots of time (0.5 seconds) to initialize the whole memory. As
only the visible part matters, we could just initialize that part.
Signed-off-by: Chia-I Wu <olv@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>
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
