aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2009-02-15Add checks to see if wmXXXX_reset() failed and notifyAndy Green
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>
2009-02-12fix-lis302dl-reset-threshold-on-resume.patchAndy Green
Reported-by: Mickey Lauer <mickey@openmoko.org> Signed-off-by: Andy Green <andy@openmoko.com>
2009-02-11config-android-change-CONFIG_NR_TTY_DEVICES-8.patchAndy Green
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>
2009-02-11fix-irqblocker-improvements-only-if-config-enabled.patchAndy Green
Sascha's last changes didn't take care about case where blocker stuff is disabled. Signed-off-by: Andy Green <andy@openmoko.com>
2009-02-11interrupt-handlin-time-detector.patchSascha Wessel
2009-02-11ignore-serial-overruns.patchSascha Wessel
2009-02-11iblock-fixes.patchSascha Wessel
2009-02-09fix-serial-interrupt-init.patchMichael Trimarchi
The overrun bit has used only if the rx interrupt error is enabled. Signed-off-by: Michael Trimarchi <michael@panicking.kicks-ass.org>
2009-02-09This patch fixes the following items on pcap7200 driver,Matt Hsu
-do the parameter check of setting operating mode. -add device haeder file. Signed-off-by: Matt Hsu <matt_hsu@openmoko.org>
2009-02-09Fill up platform data of pcap7200 device on gta03.Matt Hsu
Signed-off-by: Matt Hsu <matt_hsu@openmoko.org>
2009-02-09Add platform data of pcap7200 touch panel device.Matt Hsu
The following two features are added as platform data. - externel reset - operating mode Signed-off-by: Matt Hsu <matt_hsu@openmoko.org>
2009-02-08power: pcf50633 wall charger current limit fixRask Ingemann Lambertsen
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>
2009-02-08s3c_mci_move_regulator_stuff_to_platform_code.patchBalaji Rao
Move the regulator handling stuff away from s3cmci.c to mach-gta01.c. Signed-off-by: Balaji Rao <balajirrao@openmoko.org>
2009-02-07Take 2: Define DMA for S3C2442Sven Rebhan
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>
2009-02-07config-tracking-2.6.29-rc3-uplevel.patchAndy Green
Signed-off-by: Andy Green <andy@openmoko.com>
2009-02-07tracking-2.6.29-rc3-s3cmci-cfgpin-changes.patchAndy Green
Signed-off-by: Andy Green <andy@openmoko.com>
2009-02-07tracking-2.6.29-rc3-s3cmci-dma-change.patchAndy Green
Signed-off-by: Andy Green <andy@openmoko.com>
2009-02-07tracking-2.6.29-rc3-wm8753-gta02-changes.patchAndy Green
Signed-off-by: Andy Green <andy@openmoko.com>
2009-02-07tracking-2.6.29-rc3-touchscreen-changed-include-for-cfgpin.patchAndy Green
Signed-off-by: Andy Green <andy@openmoko.com>
2009-02-07CPU_S3C2442 does not depend on ARCH_S3C2440Sven Rebhan
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>
2009-02-07Rename GTA03_GPIO_MODEN_ON to GTA03_GPIO_MODEM_ONWerner Almesberger
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>
2009-02-06MERGE-via-pending-tracking-hist-MERGE-via-stable-tracking-MERGE-via-mokopatc ↵merge
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
2009-02-05fix-pcf50633-set-charging-limit-with-usb-limit.patchAndy Green
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>
2009-02-05config-gta02-remove-power-debug.patchAndy Green
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>
2009-02-04[GTA03] Fix power on/off sequence of the GSM moduleDKAY_CHEN
Signed-off-by: DKAY_CHEN <dkay_chen@openmoko.com>
2009-02-03fix-lis302dl-clear-wakeup-source-if-threshold.patchAndy Green
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>
2009-02-03fix-lis302dl-dont-reset-hpf-each-time.patchAndy Green
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>
2009-02-03add-lis302dl-overrun-stats.patchAndy Green
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>
2009-02-03fix-lis302dl-get-status-confirm-data-ready.patchAndy Green
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>
2009-02-02gta03-usb-otg-init-48MHz-source-fix.patchDkay Chen
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>
2009-02-02Make ALSA name truncation verboseNelson Castillo
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>
2009-02-02build-add-HEAD-to-uploadable-builds.patchAndy Green
Signed-off-by: Andy Green <andy@openmoko.com>
2009-02-02This is a ugly openmokoo revert for name changing in alsa.conf.Michael Trimarchi
Please revert in feuture version Pointed-out-by: Andy Green <andy@openmoko.com> Signed-off-by: Michael Trimarchi <michael@panicking.kicks-ass.org>
2009-02-01debug-add-more-glamo-mem-speed-options.patchAndy Green
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>
2009-01-31The continue instead of return is not necessary now, because the DAIAndy Green
has a dummy inizialization. Signed-off-by: Michael Trimarchi <michael@panicking.kicks-ass.org>
2009-01-31consistent defconfig naming ?Werner Almesberger
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>
2009-01-31Return-Path: <openmoko-kernel-bounces@lists.openmoko.org>Andy Green
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>
2009-01-30introduce-gta02-micro-defconfig.patchWerner Almesberger
GTA02 config suitable for bootloader menu application Signed-off-by: Werner Almesberger <werner@openmoko.org>
2009-01-30clean-gta01-gps-warnings.patchAndy Green
Signed-off-by: Andy Green <andy@openmoko.com>
2009-01-30Return-Path: <openmoko-kernel-bounces@lists.openmoko.org>Andy Green
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>
2009-01-30manage RTC alarm "pending" flag of PCF50633Werner Almesberger
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>
2009-01-30fix-s3c64xx-hs-otg-bitfield-errors-and-clean.patchAndy Green
Signed-off-by: Andy Green <andy@openmoko.com>
2009-01-30fix-s3c6410-hsusb-platform-init.patchAndy Green
Signed-off-by: Andy Green <andy@openmoko.com>
2009-01-30fix-s3c6410-hsusb-phy-regs.patchAndy Green
Signed-off-by: Andy Green <andy@openmoko.com>
2009-01-30consider alrm->enable in pcf50633_rtc_set_alarmWerner Almesberger
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>
2009-01-29smdk6410-add-usb-otg.patchAndy Green
Signed-off-by: Andy Green <andy@openmoko.com>
2009-01-29introduce-smdk6410.patchAndy Green
Signed-off-by: Andy Green <andy@openmoko.com>
2009-01-29Subject: glamo_fix_improper_xrandr_geometry_setting.patchBalaji Rao
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>
2009-01-29Subject: gta02_fix_defconfig.patchBalaji Rao
X-Git-Url: http://git.openmoko.org/?p=kernel.git;a=commitdiff_plain;h=5ef528551ba670d228dbe442d878b571df1cf98d gta02_fix_defconfig.patch Signed-off-by: Balaji Rao <balajirrao@openmoko.org>
2009-01-29 pcf50633_charging_current_control.patchBalaji Rao
Introduces battery charging current control. Signed-off-by: Balaji Rao <balajirrao@openmoko.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-17 01:18:36 +0000