Age | Commit message (Collapse) | Author |
|
drivers can find the IIS bus clock rate.
Signed-off-by: Ben Dooks <ben@simtec.co.uk>
|
|
s3c_gpio_cfgpin and s3c_gpio_setpull to allow modules
to use them (such as ASoC drivers)
Signed-off-by: Ben Dooks <ben@simtec.co.uk>
|
|
the user of the problem. This is generally due to a
problem on the i2c bus such as an un-powered or
non-connected codec.
Signed-off-by: Ben Dooks <ben@simtec.co.uk>
|
|
Reported-by: Mickey Lauer <mickey@openmoko.org>
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Apparetly setting the number of VTs to 8 gets rid of the
android flickering issue, this patch does it for GTA01/2/3
configs.
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Sascha's last changes didn't take care about case where blocker stuff
is disabled.
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
|
|
|
|
|
|
The overrun bit has used only if the rx interrupt error is enabled.
Signed-off-by: Michael Trimarchi <michael@panicking.kicks-ass.org>
|
|
-do the parameter check of setting operating mode.
-add device haeder file.
Signed-off-by: Matt Hsu <matt_hsu@openmoko.org>
|
|
Signed-off-by: Matt Hsu <matt_hsu@openmoko.org>
|
|
The following two features are added as platform data.
- externel reset
- operating mode
Signed-off-by: Matt Hsu <matt_hsu@openmoko.org>
|
|
Hi.
The recent patch to fix a USB current limit violation when turning the
device off triggered a bug in setting the battery charge current limit. We
now get a charge current limit of 0 mA on the GTA02 when plugging in the
wall charger (just as when setting 1000 mA in /sys/class/[...]/chg_curlim).
This patch fixes it (and a comment typo). Tested on a GTA02 with a wall
charger.
Signed-off-by: Rask Ingemann Lambertsen <rask@sygehus.dk>
|
|
Move the regulator handling stuff away from s3cmci.c to mach-gta01.c.
Signed-off-by: Balaji Rao <balajirrao@openmoko.org>
|
|
The DMA used for S3C2440 is also used for S3C2442, so we also need the defines.
This patch is rebased on the latest andy-tracking branch.
Signed-off-by: Sven Rebhan <odinshorse@googlemail.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>
|
|
The dependency on ARCH_S3C2440 forces us to select at least one S3C2440 machine to get the makefile system to select the required options for our
S3C2442 GTA02. By removing this option I can build fine with only the GTA02 machine selected.
Signed-off-by: Sven Rebhan <odinshorse@googlemail.com>
|
|
Please ignore the previous patch. Here's the right one. I'll now write
100 times "I shall git-pull before making changes." Sorry.
- Werner
---------------------------------- cut here -----------------------------------
> I already tested and measured the signal of the "/MODEM_RST","/MODEM_ON"
[...]
> + s3c_gpio_setpull(GTA03_GPIO_MODEN_ON, S3C_GPIO_PULL_NONE);
~~~~~~~~
Here's a patch that changes GTA03_GPIO_MODEN_ON to GTA03_GPIO_MODEM_ON.
Signed-off-by: Werner Almesberger <werner@openmoko.org>
|
|
hes-tracking-MERGE-via-master-MERGE-via-master-hist-1232625318-1233879011-1233879414-1233879505
pending-tracking-hist top was MERGE-via-stable-tracking-MERGE-via-mokopatches-tracking-MERGE-via-master-MERGE-via-master-hist-1232625318-1233879011-1233879414-1233879505 / 1c405b6ccee468298e7ccbfd9a3a3f4d123207b0 ... parent commitmessage:
From: merge <null@invalid>
MERGE-via-stable-tracking-hist-MERGE-via-mokopatches-tracking-MERGE-via-master-MERGE-via-master-hist-1232625318-1233879011-1233879414
stable-tracking-hist top was MERGE-via-mokopatches-tracking-MERGE-via-master-MERGE-via-master-hist-1232625318-1233879011-1233879414 / 71be0a45396066b1f8f27f8f4f87937247a129e1 ... parent commitmessage:
From: merge <null@invalid>
MERGE-via-mokopatches-tracking-hist-MERGE-via-master-MERGE-via-master-hist-1232625318-1233879011
mokopatches-tracking-hist top was MERGE-via-master-MERGE-via-master-hist-1232625318-1233879011 / 1be1b01373f572a02c6f1f99863c8c11ed2f9f5b ... parent commitmessage:
From: merge <null@invalid>
MERGE-via-master-MERGE-via-master-hist-1232625318
master top was MERGE-via-master-hist-1232625318 / dd4b117123ae66451695810017eb72fbdfc05df5 ... parent commitmessage:
From: merge <null@invalid>
MERGE-master-patchset-edits
|
|
Cedric noticed that when he turned his GTA02 OFF while hooked to
a "dumb" USB charger that should only be asked for 100mA, suddenly
much more current was demanded.
When PMU enters PMU standmy when we go OFF, its USB current limit
is reset to the variant default of 500mA. Since we previously had
the charging current limit fixed at 1A, it meant we immediately
charge at 500mA.
This patch makes the charging limit follow the USB current limit,
so that even when we go off, no more than the last authorized amount
of current will be taken, even if the USB current limit is later
broken by the variant default.
Reported-by: Cedric Berger <cedric.berger74@gmail.com>
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Remove the spew from GTA02 POWER_SUPPLY debugging messages,
it's just the HDQ stuff filling up dmesg every 30s or so.
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Signed-off-by: DKAY_CHEN <dkay_chen@openmoko.com>
|
|
We need to clear down the wakeup source reg if we woke from
threshold.
Reported-by: Simon Kagstrom <simon.kagstrom@gmail.com>
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
We shouldn't be resetting the highpass filter every sample.
It should be disabled if we don't use it or allowed to
work across multiple samples if we do.
Was this hiding some other problem?
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
We can see and account for any overruns caused by IRQ latency
now that we fetch the status register. This patch adds a /sys
node so it can be queried, and accounting.
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Level interrupts solve the sticky loss of service from accels issue.
But currently, we get two service actions per one interrupt, leading to
information getting read and sent to the input subsystem twice.
This patch makes the ISR confirm with the lis302dl status register
that there is fresh data before accepting it, it works around the
issue and allows use of the other information in the status reg by
another patch.
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Unlike SMDK we use 48MHz xtal on GTA03, don't copy
platform phy clock init from SMDK then
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Make previous Michael's patch verbose about truncating
mixer names. Sample message:
sound/soc/soc-dapm.c:349 mixer name 'Playback Mixer Voice Capture Switch' truncated
to 31 characters.
Signed-off-by: Nelson Castillo <arhuaco@freaks-unidos.net>
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Please revert in feuture version
Pointed-out-by: Andy Green <andy@openmoko.com>
Signed-off-by: Michael Trimarchi <michael@panicking.kicks-ass.org>
|
|
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>
|
|
has a dummy inizialization.
Signed-off-by: Michael Trimarchi <michael@panicking.kicks-ass.org>
|
|
The naming of our defconfigs is currently inconsistent: three of them
end in -defconfig and use - also as an internal separator. One sends
in _defconfig but uses - as internal separator, and one ends in
_defconfig without needing an internal separator so far.
All the other defconfigs end in _defconfig. 21 use _ also as
internal separator and 5 use -.
So most of our names differ from the style everyone else is following
and there's also inconsistency among our names.
The git patch below renames them to the dominant all _ scheme.
There's always some latent undesirability for such cleanup patches
that may break some habits or scripts. So if there are strong
sentiments against doing this now, I won't push the issue. But in
general, the sooner one gets those little things done, the better.
Signed-off-by: Werner Almesberger <werner@openmoko.org>
|
|
Received: from mail.openmoko.org ([unix socket])
by mail.openmoko.org (Cyrus v2.1.18-IPv6-Debian-2.1.18-5.1) with LMTP; Fri, 30 Jan 2009 23:00:03 +0000
X-Sieve: CMU Sieve 2.2
Return-path: <openmoko-kernel-bounces@lists.openmoko.org>
Received: from sita.openmoko.org ([88.198.124.203])
by mail.openmoko.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32)
(Exim 4.63)
(envelope-from <openmoko-kernel-bounces@lists.openmoko.org>)
id 1LT2LD-0001st-Fo
for andy@imap.openmoko.org; Fri, 30 Jan 2009 23:00:03 +0000
Received: from localhost ([127.0.0.1] helo=sita.openmoko.org)
by sita.openmoko.org with esmtp (Exim 4.63)
(envelope-from <openmoko-kernel-bounces@lists.openmoko.org>)
id 1LT2Kb-0001Xw-JH; Fri, 30 Jan 2009 23:59:25 +0100
Received: from mail.openmoko.org ([88.198.124.205])
by sita.openmoko.org with esmtp (Exim 4.63)
(envelope-from <werner@openmoko.org>) id 1LT2KV-0001Xn-Lv
for openmoko-kernel@lists.openmoko.org; Fri, 30 Jan 2009 23:59:22 +0100
Received: from 175-205-16-190.fibertel.com.ar ([190.16.205.175] helo=ws)
by mail.openmoko.org with esmtpsa (TLS-1.0:DHE_RSA_AES_128_CBC_SHA1:16)
(Exim 4.63) (envelope-from <werner@openmoko.org>) id 1LT2KS-0001Xk-0U
for openmoko-kernel@lists.openmoko.org; Fri, 30 Jan 2009 22:59:19 +0000
Received: by ws (sSMTP sendmail emulation); Fri, 30 Jan 2009 22:02:47 -0200
Date: Fri, 30 Jan 2009 22:02:47 -0200
From: Werner Almesberger <werner@openmoko.org>
To: openmoko-kernel@lists.openmoko.org
Message-ID: <20090131000247.GF4526@almesberger.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on sita.openmoko.org
X-Spam-Level:
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL, BAYES_00, UPPERCASE_50_75
autolearn=no version=3.2.3
Subject: [PATCH] back out Android wakelocks breaking suspend
X-BeenThere: openmoko-kernel@lists.openmoko.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion regarding the OpenMoko Linux Kernel and boot loader
<openmoko-kernel.lists.openmoko.org>
List-Unsubscribe: <http://lists.openmoko.org/mailman/listinfo/openmoko-kernel>,
<mailto:openmoko-kernel-request@lists.openmoko.org?subject=unsubscribe>
List-Archive: <http://lists.openmoko.org/pipermail/openmoko-kernel>
List-Post: <mailto:openmoko-kernel@lists.openmoko.org>
List-Help: <mailto:openmoko-kernel-request@lists.openmoko.org?subject=help>
List-Subscribe: <http://lists.openmoko.org/mailman/listinfo/openmoko-kernel>,
<mailto:openmoko-kernel-request@lists.openmoko.org?subject=subscribe>
Sender: openmoko-kernel-bounces@lists.openmoko.org
Errors-To: openmoko-kernel-bounces@lists.openmoko.org
In current andy-tracking, a resume gets almost immediately followed
by another suspend, so we can never really leave suspend. This is
somehow caused by the Android wakelocks.
I think the most expedite way to deal with this is to back them out
of our configurations until they've been properly debugged, which
is what this patch does.
Signed-off-by: Werner Almesberger <werner@openmoko.org>
|
|
GTA02 config suitable for bootloader menu application
Signed-off-by: Werner Almesberger <werner@openmoko.org>
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Received: from mail.openmoko.org ([unix socket])
by mail.openmoko.org (Cyrus v2.1.18-IPv6-Debian-2.1.18-5.1) with LMTP; Fri, 30 Jan 2009 14:13:43 +0000
X-Sieve: CMU Sieve 2.2
Return-path: <openmoko-kernel-bounces@lists.openmoko.org>
Received: from sita.openmoko.org ([88.198.124.203])
by mail.openmoko.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32)
(Exim 4.63)
(envelope-from <openmoko-kernel-bounces@lists.openmoko.org>)
id 1LSu7r-000566-Sm
for andy@imap.openmoko.org; Fri, 30 Jan 2009 14:13:43 +0000
Received: from localhost ([127.0.0.1] helo=sita.openmoko.org)
by sita.openmoko.org with esmtp (Exim 4.63)
(envelope-from <openmoko-kernel-bounces@lists.openmoko.org>)
id 1LSu7M-0004nA-JB; Fri, 30 Jan 2009 15:13:12 +0100
Received: from mail.openmoko.org ([88.198.124.205])
by sita.openmoko.org with esmtp (Exim 4.63)
(envelope-from <werner@openmoko.org>) id 1LSu7H-0004n3-4S
for openmoko-kernel@lists.openmoko.org; Fri, 30 Jan 2009 15:13:10 +0100
Received: from 175-205-16-190.fibertel.com.ar ([190.16.205.175] helo=ws)
by mail.openmoko.org with esmtpsa (TLS-1.0:DHE_RSA_AES_128_CBC_SHA1:16)
(Exim 4.63) (envelope-from <werner@openmoko.org>) id 1LSu7F-0004mk-Pb
for openmoko-kernel@lists.openmoko.org; Fri, 30 Jan 2009 14:13:07 +0000
Received: by ws (sSMTP sendmail emulation); Fri, 30 Jan 2009 13:16:38 -0200
Date: Fri, 30 Jan 2009 13:16:38 -0200
From: Werner Almesberger <werner@openmoko.org>
To: openmoko-kernel@lists.openmoko.org
Message-ID: <20090130151638.GA10711@almesberger.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on sita.openmoko.org
X-Spam-Level:
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=3.2.3
Subject: [PATCH] fix #if vs. #ifdef cpp warning in neo1973_pm_gps.c
X-BeenThere: openmoko-kernel@lists.openmoko.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion regarding the OpenMoko Linux Kernel and boot loader
<openmoko-kernel.lists.openmoko.org>
List-Unsubscribe: <http://lists.openmoko.org/mailman/listinfo/openmoko-kernel>,
<mailto:openmoko-kernel-request@lists.openmoko.org?subject=unsubscribe>
List-Archive: <http://lists.openmoko.org/pipermail/openmoko-kernel>
List-Post: <mailto:openmoko-kernel@lists.openmoko.org>
List-Help: <mailto:openmoko-kernel-request@lists.openmoko.org?subject=help>
List-Subscribe: <http://lists.openmoko.org/mailman/listinfo/openmoko-kernel>,
<mailto:openmoko-kernel-request@lists.openmoko.org?subject=subscribe>
Sender: openmoko-kernel-bounces@lists.openmoko.org
Errors-To: openmoko-kernel-bounces@lists.openmoko.org
#if is a poor substitute for #ifdef :-)
Signed-off-by: Werner Almesberger <werner@openmoko.org>
|
|
This patch adds setting and clearing of the "pending" flag of the
RTC alarm. The semantics follow the UEFI specification 2.2 available
at http://www.uefi.org/specs/, i.e., the "pending" flag is cleared
by disabling the alarm, but not by any other condition (such as the
passing of time, a successful wakeup, or setting of a new alarm.)
Signed-off-by: Werner Almesberger <werner@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>
|
|
Hi Balaji,
Mickey mentioned to me that he had trouble with the RTC wakeup interrupt.
I had a quick look at the problem and it seems that alrm->enable doesn't
get propagated when setting the alarm time with RTC_WKALM_SET.
Does something like my patch below look right ? We also don't handle
alrm->pending, but I'm not sure if we have to.
I tested this only very lightly since my current andy-tracking crashes
in soc_suspend. If nobody else beats me to it, I'll have a look at it
tomorrow.
- Werner
---------------------------------- cut here -----------------------------------
According to Documentation/rtc.txt, RTC_WKALM_SET sets the alarm time
and enables/disables the alarm. We implement RTC_WKALM_SET through
pcf50633_rtc_set_alarm. The enabling/disabling part was missing.
Signed-off-by: Werner Almesberger <werner@openmoko.org>
Reported-by: Michael 'Mickey' Lauer <mickey@openmoko.org>
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
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>
|