aboutsummaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2008-11-19tracking-2.6.27-rc2-include-path-changes.patchAndy Green
Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19fix-no-discharging.patchAndy Green
We failed to report status of "discharging", instead reporting "not charging" even if we knew that the charger was not present. This patch corrects it and reports "discharging" when charger is absent. Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19checkpatch-fixes.patchAndy Green
This cleans out some random externs in C files that checkpatch does not like and introduces a couple of .h files to contain them. Plus some other minor checkpatch style complaints. Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19fix-suspend-backlight-timing-gta01.patchMike Westerhof
This patch adds the gta01 backlight callback that defers the restoring of the backlight until after the jbt driver has resumed. This doesn't eliminate the flashing of the LCD on the gta01, but it reduces it considerably. Signed-off-by: Mike Westerhof <mwester@dls.net>
2008-11-19gta01-pcf50606-disable-irq-from-suspend-until-resume.patchMike Westerhof
This patch is the pcf50606 equivalent of the pcf50633 patch that disables interrupts from the chip until after resume is complete. In order to ensure no data is lost, the work function is called post-resume to process any pending interrupts. Most of the code was quite literally re-used from Andy Green's original patch. Signed-off-by: Mike Westerhof <mwester@dls.net>
2008-11-19silence-serial-console-gta01.patchMike Westerhof
This patch ensures that no console data will go the UART while the GSM mux is switched to the GSM. This is necessary despite the code that disables the console due to the fact that the console resumes before the neo1973_pm_gsm driver, and consoles always resume in the "on" state. Signed-off-by: Mike Westerhof <mwester@dls.net>
2008-11-19commit 830ea3d0c27c0c750b7bf1b56c002ee7943f3edcMike Westerhof
gta0x-log-serial-rx-error.patch This patch causes a KERN_DEBUG message to be printed each time an error status is read from a UART. This is intended to facilitate the reporting of more useful problem and bug reports from users in the field. Signed-off-by: Mike Westerhof <mwester@dls.net>
2008-11-19From fa269b44512a03523b164c3cebc20312748c524b Mon Sep 17 00:00:00 2001Holger Freyther
Subject: [PATCH] [ar6k] Build the wireless driver without DEBUG - Remove DEBUG from the Makefile - Do not send events through netlink to userspace. We might need to reevaluate this. But we seem to use wireless_send_event at the right places. (SEND_EVENT_TO_APP) - Do not report debug logs to apps (REPORT_DEBUG_LOGS_TO_APP) Signed-Off-By: Holger Freyther <zecke@openmoko.org>
2008-11-19fix-pcf50633-usbrem-charging-led.patchAndy Green
If the charger was removed, we fell through back to old hdq-driven code with normally wrong but slightly random results for charging LED behaviour in that circumstance This patch makes us use the tracked charger status callbacks alone if they are defined in the platform data. Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19fix-glamo-crank-memory-to-90MHz.patchAndy Green
Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19fix-glamo-turbo-host-interface.patchAndy Green
Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19pcf50606: fix gllin compat linkCesar Eduardo Barros
Uses bus_create_device_link to correctly create the gllin compat link. Signed-off-by: Cesar Eduardo Barros <cesarb@cesarb.net>
2008-11-19device model: Allow the creation of symlinks on /sys/bus/*/devicesCesar Eduardo Barros
Allows the direct creation of symlinks on /sys/bus/*/devices. This is needed for a compat symlink from gta01-pm-gps.0 to neo1973-pm-gps.0 on the Openmoko Neo1973 GTA01. Signed-off-by: Cesar Eduardo Barros <cesarb@cesarb.net>
2008-11-19Signed-Off-Number: Holger Freyther <zecke@openmoko.org>Andy Green
2008-11-19tracking-2.6.27-rc1-broken-cfg-uninit-nand.patchAndy Green
Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19tracking-2.6.27-rc1-ar6000.patchAndy Green
Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19tracking-2.6.27-rc1-last-2400-ordering.patchAndy Green
Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19tracking-2.6.27-rc1-borked-eth-gadget.patchAndy Green
Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19tracking-2.6.27-rc1-tty-not-in-uart_port.patchAndy Green
Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19tracking-2.6.27-mmc-ultiwrite-gone.patchAndy Green
Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19tracking-2.6.27-rc1-irqtype-falling-glamo.patchAndy Green
Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19fix-backlight-def-pcf50633.patchAndy Green
Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19tracking-2.6.27-rc1-pcf50306-defs.patchAndy Green
Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19add-glamo-mci-slower-clocking-dynamic-switching.patchAndy Green
This patch gives glamo-mci a concept of a platform-defined dynamic clock slowing callback. It means that platform code can associate some completely external state to decide if we run the SD clock at normal rate or a rate divided by a module parameter "sd_slow_ratio", which you can set on kernel commandline like this: glamo_mci.sd_slow_ratio=8 you can also change it at runtime by echo 8 > /sys/module/glamo_mci/parameters/sd_slow_ratio If no platform callback is defined, then no slow mode is used. If it is defined, then the default division action is / 8, eg, 16MHz normal -> 2MHz slow mode. Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19fix-glamo-mci-dont-filter-voltage-change.patchAndy Green
Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19fix-allow-full-sd-voltage-range-selection.patchAndy Green
Until now we just drove the SD Card at 3.3V all the time. But in fact we can do better, and use a voltage negotiated with the SD Card itself. With the shipping 512MB Sandisk SD Card, 2.7V is negotiated which gives 1.7dBm reduction in power on all the SD Card lines and should further reduce GPS perturbation during SD Card usage. Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19fix-glamo-mci-ensure-more-than-74-clocks-after-power.patchAndy Green
We are meant to run SD_CLK a little while after power-on for the SD Card, but with the no idle clock changes we didn't take care about it. This makes us sleep a little bit before disabling clock if we just powered up the SD Card. Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19fix-glamo-mci-possible-timeout-overflow.patchAndy Green
The MMC stack hands us a timeout calibrated in SD_CLK clocks, but the Glamo can only deal with up to 65520 clocks of timeout. If the stack handed us a request bigger than this, it would just wrap and the timeout we actually used would be way too short. With this patch if that happens, we use the longest timeout we can, 65520 clocks and give it our best shot. Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19fix-pcf50633-only-do-platform-callback-once-per-event.patchAndy Green
Reported-by: Holger Freyther <zecke@openmoko.org> We harmlessly repeated PMU platform callbacks about charging state twice. Clean it up and leave it to pcf50633_charge_enable() to report once. Also tidies the sequencing so we set current limit before we enable charger now. Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19fix-pcf50633-remove-charger-curlim-and-enable-apis-from-export.patchAndy Green
Setting the current limit directly and enabling the charger isn't anyone's business except pcf50633 driver itself, so these two functions should not be exported and become static. Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19fix-glamo-mci-set-default-drive-level-0.patchAndy Green
Tests on access to SD Card with Glamo drive level "0" show that it reduces SD_CLK energy at 1.5GHz by 24dBm compared to drive level 3. This puts it only 6dB above the background noise floor compared to 30dB and should make a solution for GPS trouble with SD Card in. SD card communication seems unaffected so far on the Sandisk 512MB card we ship. Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19fix-bq27000-charger-state-tracking.patchAndy Green
Charger trigger stuff goes and asks for POWER_SUPPLY_PROP_STATUS to figure out what the charger state is. But until now, we only reported there what we found out from HDQ, and the HDQ registers are not updated very often in the coulomb counter, it can be 4 or more second lag before it tells us about what it experiences. When we react to USB insertion and only after 500ms debounce tell power_supply stuff that something changed, it most times will see old pre-USB-insertion state from bq27000 over HDQ at that time and will report it ain't charging, buggering up the LED trigger tracking. This patch maintains distance between bq27000 and pcf50633 by having platform callbacks in bq27000 that it can use to ask about definitive charger "online" presence and "activity", whether the charger says it is charging. If these callbacks are implemented (and we implement them in this patch up in mach_gta02.c) then this information is used in preference to what is found from HDQ. Result is if you set the LED trigger like this: echo bat-charging > /sys/devices/platform/gta02-led.0/leds/gta02-aux:red/trigger then it lights up properly on USB insertion now, goes away on removal properly, as as far as I saw, when charging stops too. Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19debug-add-glamo-drive-strength-module-param.patchAndy Green
Suggested-by: Werner Almesberger <werner@openmoko.org> This patch allows users to control two additional settings in Glamo MCI driver from kernel commandline or module parameters. First is Glamo drive strength on SD IOs including CLK. This ranges from 0 (weakest) to 3 (strongest). echo 0 > /sys/module/glamo_mci/parameters/sd_drive (Changes to this take effect on next SD Card transaction) or, from kernel commandline glamo_mci.sd_drive=0 On tests here with 0 strength, communication to SD card (shipped 512MB Sandisk) seemed fine, and a dd of 10MB urandom had the same md5 when written to cache as after a reboot. I set the default to 2. Second is whether we allow SD_CLK when the SD interface is idle. # stop the clock when we are idle (default) echo 0 > /sys/module/glamo_mci/parameters/sd_idleclk # run the SD clock all the time echo 1 > /sys/module/glamo_mci/parameters/sd_idleclk (changes take effect on next SD Card transaction) From kernel commandline, eg: glamo_mci.sd_idleclk=1 Normally you don't want to run the SD Clock all the time. Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19debug-move-dev-info-to-dbg.patchAndy Green
Suggested-by: Sean McNeil <sean@mcneil.com> To see if some subtle race is involved, Sean has tried removing syslog traffic during resume and found he was not seeing the resume crash any more. We're giving it a try to see if it changes the behaviour for anyone else. It would mean we have a pretty fine race in there somewhere. Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19fix-scard-stop-on-resume.patchAndy Green
Reported-by: Ville-Pekka Vainio <vpivaini@cs.helsinki.fi> The reporter noticed SD Card clock is running again after resume. After looking at the code I saw I missed two tricks, this will force it off after resume and will do better generally depending on what the last SD Card packet was. Since bulk read packet is normally last action (which set the clock off even without this) the old patch worked for normal cases. But after resume, the last packet on the wire was not a bulk transfer and we didn't take care about the clock then. Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19add-limit-sdcard-clk-cmdline.patchAndy Green
This patch allows you to control the maximum clock rate that will be selected for SD Card access, from the kernel commandline using glamo_mci.sd_max_clk=10000000 and also from echo 10000000 > /sys/module/glamo_mci/parameters/sd_max_clk although you have to suspend and resume to make the limit operational on the actual SD_CLK line. Clocks that are possible are divided down from ~50MHz, so 25000000, 16666666, 12500000, 10000000, etc. With Freerunner A5 revision that has 100R series resistors in SD Card signals, I didn't get reliable operation above 16MHz. With A6 revision the series resistors went down to 75R, maybe it can work at 25MHz. Reducing the clock rate is something to try if you find that your SD Card is not communicating properly with the default speed. Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19fix-force-sdcard-clk-off-when-idle.patchAndy Green
Existing Glamo bit for stopping SD Card Clock when there is no transfer taking place does not work. This patch adds stuff around the transfer code to force the SD clock up when something is going on and down when it is idle. This'll save a little power and noise ;-) I tested it briefly and was able to SD Boot normally on Sandisk 512M. Wider testing is appreciated. Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19change-backlight-level-not-forced-up-on-resume.patchAndy Green
We at least always enabled backlight on resume, this patch changes us to set backlight back to last requested backlight brightness level on resume. Note it means that you can resume with screen blanked, but it should come back if that happened with touchscreen action as usual. /sys/class/backlight/pcf50633-bl/actual_brightness and /sys/class/backlight/pcf50633-bl/brightness seem to agree after resume when reportedly they didn't before. Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19add-pcf50633-allow-force-charger-type.patchAndy Green
This patch adds a sysfs node: /sys/class/i2c-adapter/i2c-0/0-0073/force_usb_limit_dangerous it allows to force the charging limit regardless of the one chosen by pcf50633 kernel driver. As such, if you write a charging limit here that is not suitable for the power source, and the power source is not current limited on its side, it could draw more current than your power source can handle, burn down you house, etc. If you're certain that your power supply can handle it, you can use this on your own responsibility to make the amount drawn by the PMU match what you believed your power supply could handle. Example usage, in case where you have a dumb 500mA USB charger that does not have the ID resistor: # cat /sys/class/i2c-adapter/i2c-0/0-0073/charger_type host/500mA usb mode 100mA <=== dumb charger does not ennumerate us # echo 500 > /sys/class/i2c-adapter/i2c-0/0-0073/force_usb_limit_dangerous # cat /sys/class/i2c-adapter/i2c-0/0-0073/charger_type host/500mA usb mode 500mA Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19fix-aux-key-level-by-gtaxx.patchAndy Green
Reported-by: Mickey Lauer <mickey@openmoko.org> AUX level detection is inverted based on GTA01 or 02 Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19fix-pcf50633-mask-second-on-resume.patchAndy Green
We leave SECOND unmasked on resume, it's like the situation at probe() time, but there it makes us turn SECOND off after coldplug action. So we need to act like after that has happened, not exactly like what we do at probe / init time. Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19From 3a32be40f78404d5f1185f0b3d6b5632381cb33f Mon Sep 17 00:00:00 2001Holger Freyther
Subject: [PATCH] [neo1973 leds] Move from mutex to spinlock because we may not use mutexes The led triggers may call set_brightness from atomic contexts. As mutex_lock calls might_sleep and sleeping is not allowed in atomic contexts we have to switch to spinlocks here. Signed-Off-By: Holger Freyther <zecke@openmoko.org>
2008-11-19From cede5c6c9b06ecbb0f7f2df7b7070092b87ddaf8 Mon Sep 17 00:00:00 2001Holger Freyther
Subject: [PATCH] [pcf50633] Avoid ooops on start with inserted usb cable The pcf50633_global might not be initialized when we get the first usb interrupt. We would oops inside the dev_err because we made up a struct device. Signed-Off-By: Holger Freyther <zecke@openmoko.org>
2008-11-19From c221bb27c8e22daa451e26353140777223d397d2 Mon Sep 17 00:00:00 2001Holger Freyther
Subject: [PATCH] [pcf50633] Report more events to userspace using the default callback Signed-Off-By: Holger Freyther <zecke@openmoko.org>
2008-11-19From 5718bde77ed1a75e0fd2cdf5e099e66121d10c0a Mon Sep 17 00:00:00 2001Holger Freyther
Subject: [PATCH] [battery] Make the bq27000 send an uevent when the charging state possible changed Remove the todo entries from the pcf50633, make the mach-gta02 call the bq27000 driver from the pmu callback.
2008-11-19From 000450f1ad2c713d2345a872fdf44f5dd3702e1b Mon Sep 17 00:00:00 2001Holger Freyther
Subject: [PATCH] [janitor] make checkpatch.pl happy
2008-11-19From ae3f72fc608fcd0a98a980a335ac4dc7ad95b221 Mon Sep 17 00:00:00 2001Holger Freyther
Subject: [PATCH] [bq27000] Make the checkpatch.pl happy
2008-11-19tracking-2.6.26-rc7-repeat-cdev-removal-pcf50633.patchAndy Green
Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19introduce-resume-exception-capture.patchAndy Green
This patch introduces a new resume debugging concept: if we get an OOPS inbetween starting suspend and finishing resume, it uses a new "emergency spew" device similar to BUT NOT REQUIRING CONFIG_DEBUG_LL to dump the syslog buffer and then the OOPS on the debug device defined by the existing CONFIG_DEBUG_S3C_UART index. But neither CONFIG_DEBUG_LL nor the S3C low level configs are needed to use this feature. Another difference between this feature and CONFIG_DEBUG_LL is that it does not affect resume timing, ordering or UART traffic UNLESS there is an OOPS during resume. The patch adds three global exports, one to say if we are inside suspend / resume, and two callbacks for printk() to use to init and dump the emergency data. The callbacks are set in s3c serial device init, but the whole structure is arch independent. Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19fix-gsm-resume-problems.patchAndy Green
Signed-off-by: Andy Green <andy@openmoko.com>