linaro-dev July 2011

linaro-dev@lists.linaro.org

107 participants
163 discussions

3.0 kernel Android wakelocks and mmc delayed work

by Andy Green

Hi - Yesterday I studied suspend status on 3.0 kernel for Panda, for mem suspend it's working pretty well in Ubuntu case, desktop is coming back up woken by USB keyboard action, WLAN is workable after reassociation. However in Android case, the same tree merged with common-android-3.0 to get Androidization is blowing chunks in suspend / resume, entering a loop where it aborts suspend and then tries to suspend again all the time. Increasing the debug level in wakelock code shows at least two guys that can make trouble, locks "mmc_delayed_work" and "alarm_rtc". "mmc_delayed_work" casues wakelock stuff to return -EAGAIN, and "alarm_rtc" seems to timeout as a wakelock, but leave the alarm device in a state where it will abort suspend on -EBUSY. I took a look in drivers/mmc/core/core.c to see what the wakelock support patches had done there and was a bit surprised. They have a single wakelock to cover delayed work in there, however there are multiple delayed works possible to be queued, eg delayed disable and delayed detect actions, and although they wrap scheduling the delayed work to also lock the wakelock, they don't wrap cancelling it, eg --> void mmc_stop_host(struct mmc_host *host) { ... if (host->caps & MMC_CAP_DISABLE) cancel_delayed_work(&host->disable); cancel_delayed_work_sync(&host->detect); mmc_flush_scheduled_work(); Nor do wakelocks seem to maintain counters, they're either locked or unlocked. So the following code looks highly suspicious: static int mmc_schedule_delayed_work(struct delayed_work *work, unsigned long delay) { wake_lock(&mmc_delayed_work_wake_lock); return queue_delayed_work(workqueue, work, delay); } static int mmc_host_do_disable(struct mmc_host *host, int lazy) { .... (conditionally) mmc_schedule_delayed_work(&host->disable, delay); ... } void mmc_host_deeper_disable(struct work_struct *work) { ... mmc_host_do_disable(host, 1); ... wake_unlock(&mmc_delayed_work_wake_lock); } Ie mmc_host_deeper_disable() can provoke delayed work which it proceeds to unlock wakelock coverage for. To the point of the symptoms: int mmc_pm_notify(struct notifier_block *notify_block, unsigned long mode, void *unused) { ... switch (mode) { case PM_HIBERNATION_PREPARE: case PM_SUSPEND_PREPARE: ... cancel_delayed_work_sync(&host->detect); So here when preparing for suspend we can cancel the delayed work we presumably arranged wakelock coverage for, without unlocking the wakelock. Am I missing the point or is some work needed to improve wakelock application for mmc stuff in common-android-3.0? -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog

13 years, 5 months

[PATCH 02/11] GPIO: DA9052 GPIO module v3

by ashishj3

DA9052 PMIC has 16 bit GPIO bus for peripheral control. This patch add support for the GPIO pins on the DA9052. Signed-off-by: David Dajun Chen <dchen(a)diasemi.com> Signed-off-by: Ashish Jangam <ashish.jangam(a)kpitcummins.com> CC: Arnd Bergmann <arnd(a)arndb.de> CC: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- Changes since v3: - Remove da9052 gpio header file Changes since v2: - change of file name - correct reference to irq_base in function to_irq() - remove pdata dependency --- drivers/gpio/Kconfig | 6 + drivers/gpio/Makefile | 1 + drivers/gpio/gpio-da9052.c | 279 ++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 286 insertions(+), 0 deletions(-) create mode 100755 drivers/gpio/gpio-da9052.c diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig index d3b2953..df510d4 100644 --- a/drivers/gpio/Kconfig +++ b/drivers/gpio/Kconfig @@ -65,6 +65,12 @@ config GPIO_SYSFS # put expanders in the right section, in alphabetical order +config GPIO_DA9052 + tristate "Dialog DA9052 GPIO" + depends on PMIC_DA9052 + help + Say yes here to enable the GPIO driver for the DA9052 chip. + config GPIO_MAX730X tristate diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile index becef59..cbee503 100644 --- a/drivers/gpio/Makefile +++ b/drivers/gpio/Makefile @@ -11,6 +11,7 @@ obj-$(CONFIG_GPIOLIB) += gpiolib.o obj-$(CONFIG_GPIO_ADP5520) += adp5520-gpio.o obj-$(CONFIG_GPIO_ADP5588) += adp5588-gpio.o obj-$(CONFIG_GPIO_BASIC_MMIO) += basic_mmio_gpio.o +obj-$(CONFIG_GPIO_DA9052) += gpio-da9052.o obj-$(CONFIG_GPIO_LANGWELL) += langwell_gpio.o obj-$(CONFIG_GPIO_MAX730X) += max730x.o obj-$(CONFIG_GPIO_MAX7300) += max7300.o diff --git a/drivers/gpio/gpio-da9052.c b/drivers/gpio/gpio-da9052.c new file mode 100755 index 0000000..5623369 --- /dev/null +++ b/drivers/gpio/gpio-da9052.c @@ -0,0 +1,279 @@ +/* + * GPIO Driver for Dialog DA9052 PMICs. + * + * Copyright(c) 2011 Dialog Semiconductor Ltd. + * + * Author: David Dajun Chen <dchen(a)diasemi.com> + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + * + */ +#include <linux/module.h> +#include <linux/fs.h> +#include <linux/uaccess.h> +#include <linux/platform_device.h> +#include <linux/gpio.h> +#include <linux/syscalls.h> +#include <linux/seq_file.h> + +#include <linux/mfd/da9052/da9052.h> +#include <linux/mfd/da9052/reg.h> +#include <linux/mfd/da9052/pdata.h> +#include <linux/mfd/da9052/gpio.h> + +#define DA9052_INPUT 1 +#define DA9052_OUTPUT_OPENDRAIN 2 +#define DA9052_OUTPUT_PUSHPULL 3 + +#define DA9052_SUPPLY_VDD_IO1 0 + +#define DA9052_DEBOUNCING_OFF 0 +#define DA9052_DEBOUNCING_ON 1 + +#define DA9052_OUTPUT_LOWLEVEL 0 + +#define DA9052_ACTIVE_LOW 0 +#define DA9052_ACTIVE_HIGH 1 + +#define DA9052_GPIO_MAX_PORTS_PER_REGISTER 8 +#define DA9052_GPIO_SHIFT_COUNT(no) (no%8) +#define DA9052_GPIO_MASK_UPPER_NIBBLE 0xF0 +#define DA9052_GPIO_MASK_LOWER_NIBBLE 0x0F +#define DA9052_GPIO_NIBBLE_SHIFT 4 + +struct da9052_gpio { + struct da9052 *da9052; + struct gpio_chip gp; +}; + +static inline struct da9052_gpio *to_da9052_gpio(struct gpio_chip *chip) +{ + return container_of(chip, struct da9052_gpio, gp); +} + +static unsigned char da9052_gpio_port_odd(unsigned offset) +{ + return offset % 2; +} + +static int da9052_gpio_get(struct gpio_chip *gc, unsigned offset) +{ + struct da9052_gpio *gpio = to_da9052_gpio(gc); + int da9052_port_direction = 0; + int ret; + + ret = da9052_reg_read(gpio->da9052, + DA9052_GPIO_0_1_REG + (offset >> 1)); + if (ret < 0) + return ret; + + if (da9052_gpio_port_odd(offset)) { + da9052_port_direction = ret & DA9052_GPIO_ODD_PORT_PIN; + da9052_port_direction >>= 4; + } else { + da9052_port_direction = ret & DA9052_GPIO_EVEN_PORT_PIN; + } + + switch (da9052_port_direction) { + case DA9052_INPUT: + if (offset < DA9052_GPIO_MAX_PORTS_PER_REGISTER) + ret = da9052_reg_read(gpio->da9052, + DA9052_STATUS_C_REG); + else + ret = da9052_reg_read(gpio->da9052, + DA9052_STATUS_D_REG); + if (ret < 0) + return ret; + if (ret & (1 << DA9052_GPIO_SHIFT_COUNT(offset))) + return 1; + else + return 0; + case DA9052_OUTPUT_PUSHPULL: + if (da9052_gpio_port_odd(offset)) + return ret & DA9052_GPIO_ODD_PORT_MODE; + else + return ret & DA9052_GPIO_EVEN_PORT_MODE; + default: + return -EINVAL; + } +} + +static void da9052_gpio_set(struct gpio_chip *gc, unsigned offset, int value) +{ + struct da9052_gpio *gpio = to_da9052_gpio(gc); + unsigned char register_value = 0; + int ret; + + if (da9052_gpio_port_odd(offset)) { + if (value) { + register_value = DA9052_GPIO_ODD_PORT_MODE; + ret = da9052_reg_update(gpio->da9052, (offset >> 1) + + DA9052_GPIO_0_1_REG, + DA9052_GPIO_ODD_PORT_MODE, + register_value); + if (ret != 0) + dev_err(gpio->da9052->dev, + "Failed to updated gpio odd reg,%d", + ret); + } + } else { + if (value) { + register_value = DA9052_GPIO_EVEN_PORT_MODE; + ret = da9052_reg_update(gpio->da9052, (offset >> 1) + + DA9052_GPIO_0_1_REG, + DA9052_GPIO_EVEN_PORT_MODE, + register_value); + if (ret != 0) + dev_err(gpio->da9052->dev, + "Failed to updated gpio even reg,%d", + ret); + } + } +} + +static int da9052_gpio_direction_input(struct gpio_chip *gc, unsigned offset) +{ + struct da9052_gpio *gpio = to_da9052_gpio(gc); + unsigned char register_value; + int ret; + + /* Format: function - 2 bits type - 1 bit mode - 1 bit */ + register_value = DA9052_INPUT | DA9052_ACTIVE_LOW << 2 | + DA9052_DEBOUNCING_ON << 3; + + if (da9052_gpio_port_odd(offset)) + ret = da9052_reg_update(gpio->da9052, (offset >> 1) + + DA9052_GPIO_0_1_REG, + DA9052_GPIO_MASK_UPPER_NIBBLE, + (register_value << + DA9052_GPIO_NIBBLE_SHIFT)); + else + ret = da9052_reg_update(gpio->da9052, (offset >> 1) + + DA9052_GPIO_0_1_REG, + DA9052_GPIO_MASK_LOWER_NIBBLE, + register_value); + + return ret; +} + +static int da9052_gpio_direction_output(struct gpio_chip *gc, + unsigned offset, int value) +{ + struct da9052_gpio *gpio = to_da9052_gpio(gc); + unsigned char register_value; + int ret; + + /* Format: Function - 2 bits Type - 1 bit Mode - 1 bit */ + register_value = DA9052_OUTPUT_PUSHPULL | DA9052_SUPPLY_VDD_IO1 << 2 | + value << 3; + + if (da9052_gpio_port_odd(offset)) + ret = da9052_reg_update(gpio->da9052, (offset >> 1) + + DA9052_GPIO_0_1_REG, + DA9052_GPIO_MASK_UPPER_NIBBLE, + (register_value << + DA9052_GPIO_NIBBLE_SHIFT)); + else + ret = da9052_reg_update(gpio->da9052, (offset >> 1) + + DA9052_GPIO_0_1_REG, + DA9052_GPIO_MASK_LOWER_NIBBLE, + register_value); + + return ret; +} + +static int da9052_gpio_to_irq(struct gpio_chip *gc, u32 offset) +{ + struct da9052_gpio *gpio = to_da9052_gpio(gc); + struct da9052 *da9052 = gpio->da9052; + + return da9052->irq_base + DA9052_IRQ_GPI0 + offset; +} + +static struct gpio_chip reference_gp{ + .label = "da9052-gpio", + .owner = THIS_MODULE, + .get = da9052_gpio_get, + .set = da9052_gpio_set, + .direction_input = da9052_gpio_direction_input, + .direction_output = da9052_gpio_direction_output, + .to_irq = da9052_gpio_to_irq, + .can_sleep = 1; +}; + +static int __devinit da9052_gpio_probe(struct platform_device *pdev) +{ + struct da9052_gpio *gpio; + struct da9052_pdata *pdata; + int ret; + + gpio = kzalloc(sizeof(*gpio), GFP_KERNEL); + if (gpio == NULL) + return -ENOMEM; + + gpio->da9052 = dev_get_drvdata(pdev->dev.parent); + pdata = gpio->da9052->dev->platform_data; + + gpio->da9052 = dev_get_drvdata(pdev->dev.parent); + gpio->gp = reference_gp; + gpio->gp.ngpio = 16; + if (pdata && pdata->gpio_base) + gpio->gp.base = pdata->gpio_base; + else + gpio->gp.base = -1; + + ret = gpiochip_add(&gpio->gp); + if (ret < 0) { + dev_err(&pdev->dev, "Could not register gpiochip, %d\n", ret); + goto err_mem; + } + + platform_set_drvdata(pdev, gpio); + + return 0; + +err_mem: + kfree(gpio); + return ret; +} + +static int __devexit da9052_gpio_remove(struct platform_device *pdev) +{ + struct da9052_gpio *gpio = platform_get_drvdata(pdev); + int ret; + + ret = gpiochip_remove(&gpio->gp); + if (ret == 0) + kfree(gpio); + + return ret; +} + +static struct platform_driver da9052_gpio_driver = { + .probe = da9052_gpio_probe, + .remove = __devexit_p(da9052_gpio_remove), + .driver = { + .name = "da9052-gpio", + .owner = THIS_MODULE, + }, +}; + +static int __init da9052_gpio_init(void) +{ + return platform_driver_register(&da9052_gpio_driver); +} +module_init(da9052_gpio_init); + +static void __exit da9052_gpio_exit(void) +{ + return platform_driver_unregister(&da9052_gpio_driver); +} +module_exit(da9052_gpio_exit); + +MODULE_AUTHOR("David Dajun Chen <dchen(a)diasemi.com>"); +MODULE_DESCRIPTION("DA9052 GPIO Device Driver"); +MODULE_LICENSE("GPL"); +MODULE_ALIAS("platform:da9052-gpio");

13 years, 5 months

CFP: Please test July 6th daily Images

by Tom Gall

All, We need your help. Over the weekend we "upgraded" our building of natty based images from using live-helper 2 to live-build 3. (same tool just slightly newer name and more shiny) It is possible that given evolutionary changes to the build tool that there maybe new and interesting bugs introduced. 11.07 isn't that far away so time spent testing NOW will mean less late night debug sessions later. Here's what you need to do. >From snapshots.linaro.org download a the July 6th build: one of alip, developer, nano or ubuntu-desktop and a hwpack for your board. Use linaro-media-create to get the image onto an SD. Boot said combination on your board and report the results on qatracker.linaro.org. Please take some time to DO THIS TODAY. The earlier we find regressions in what will be 11.07 the better. If you're able to test more than one image/hwpack combination, that's all the more awesome, with awesome sauce! Thanks! -- Regards, Tom "We want great men who, when fortune frowns will not be discouraged." - Colonel Henry Knox Linaro.org │ Open source software for ARM SoCs w) tom.gall att linaro.org w) tom_gall att vnet.ibm.com h) tom_gall att mac.com

13 years, 5 months

Updated armel cross toolchains for lucid/maverick/natty releases

by Marcin Juszkiewicz

Hi Linaro backport PPA [1] got updated to latest versions of armel cross toolchains -- oneiric packages were used as a base. What got changed: - gcc 4.4 was updated to 4.4.6-3ubuntu1 - gcc 4.5 was updated to 4.5.3-1ubuntu2 - binutils was updated to 2.21.52.20110606-1ubuntu1 - eglibc was updated to 2.13-6ubuntu2 - gcc 4.6 was provided as 4.6.0-14ubuntu1 in Maverick, Natty - gcc-defaults-armel-cross was updated to 1.6 in Maverick, Natty (uses gcc-4.6 as default) There is no gcc-4.6 for Lucid currently as it requires newer versions of few libraries (mpfr, mpc) and one of rule of this PPA is "do not update packages which may affect other packages". Please test them and report any bugs found. 1. https://launchpad.net/~linaro-maintainers/+archive/toolchain/

13 years, 5 months

[ACTIVITY] Frans Gifford 2011/6/26 to 2011/7/2

by Frans Gifford

== Frans Gifford <fgiff> == === Highlights === * Established weekly hacking sessions with LT. * Started working with LT to get Linaro android working with STE u-boot and kernel. * Continued discussions about connecting android-build.l.o and validation.l.o and sent first build script changes for review. === Plans === * Finalise android-build script. * Work with LT to get android working on Snowball. === Issues === * Need to get mumble working properly. * Need to source a MiniUSB-A to USB-A adapter so I can connect USB hub and then keyboard to Snowball. -- Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog

13 years, 5 months

[PATCH 9/11] Backlight: DA9052 Backlight driver v2

by ashishj3

DA9052 PMIC has capability to supply power for upto 3 banks of 6 white serial LEDS. It can also control intensity of independent banks and to drive these banks boost converter will provide up to 24V and forward current of max. 50mA. This patch allows to control intensity of the individual WLEDs bank through DA9052 PMIC. Signed-off-by: David Dajun Chen <dchen(a)diasemi.com> Signed-off-by: Ashish Jangam <ashish.jangam(a)kpitcummins.com> CC: Arnd Bergmann <arnd(a)arndb.de> --- Changes since v2: - Modify driver registrations to single. --- drivers/video/backlight/Kconfig | 6 + drivers/video/backlight/Makefile | 1 + drivers/video/backlight/da9052_bl.c | 205 +++++++++++++++++++++++++++++++++++ 3 files changed, 212 insertions(+), 0 deletions(-) create mode 100755 drivers/video/backlight/da9052_bl.c diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig index 0c9373b..023963f 100644 --- a/drivers/video/backlight/Kconfig +++ b/drivers/video/backlight/Kconfig @@ -237,6 +237,12 @@ config BACKLIGHT_DA903X If you have a LCD backlight connected to the WLED output of DA9030 or DA9034 WLED output, say Y here to enable this driver. +config BACKLIGHT_DA9052 + tristate "Dialog DA9052 WLED" + depends on PMIC_DA9052 + help + Enable the DA9052 Backlight Driver + config BACKLIGHT_MAX8925 tristate "Backlight driver for MAX8925" depends on MFD_MAX8925 diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile index b9ca849..5dd5ac6 100644 --- a/drivers/video/backlight/Makefile +++ b/drivers/video/backlight/Makefile @@ -26,6 +26,7 @@ obj-$(CONFIG_BACKLIGHT_PROGEAR) += progear_bl.o obj-$(CONFIG_BACKLIGHT_CARILLO_RANCH) += cr_bllcd.o obj-$(CONFIG_BACKLIGHT_PWM) += pwm_bl.o obj-$(CONFIG_BACKLIGHT_DA903X) += da903x_bl.o +obj-$(CONFIG_BACKLIGHT_DA9052) += da9052_bl.o obj-$(CONFIG_BACKLIGHT_MAX8925) += max8925_bl.o obj-$(CONFIG_BACKLIGHT_APPLE) += apple_bl.o obj-$(CONFIG_BACKLIGHT_TOSA) += tosa_bl.o diff --git a/drivers/video/backlight/da9052_bl.c b/drivers/video/backlight/da9052_bl.c new file mode 100755 index 0000000..6fcf741 --- /dev/null +++ b/drivers/video/backlight/da9052_bl.c @@ -0,0 +1,205 @@ +/* + * Backlight Driver for Dialog DA9052 PMICs + * + * Copyright(c) 2011 Dialog Semiconductor Ltd. + * + * Author: David Dajun Chen <dchen(a)diasemi.com> + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + */ + +#include <linux/backlight.h> +#include <linux/delay.h> +#include <linux/fb.h> +#include <linux/platform_device.h> + +#include <linux/mfd/da9052/da9052.h> +#include <linux/mfd/da9052/reg.h> + +#define DA9052_MAX_BRIGHTNESS 0xFF + +enum { + DA9052_WLEDS_OFF, + DA9052_WLEDS_ON, +}; + +enum { + DA9052_TYPE_WLED1, + DA9052_TYPE_WLED2, + DA9052_TYPE_WLED3, +}; + +static unsigned char wled_bank[] = { + DA9052_LED1_CONF_REG, + DA9052_LED2_CONF_REG, + DA9052_LED3_CONF_REG, +}; + +struct da9052_bl { + struct da9052 *da9052; + uint brightness; + uint state; + uint led_reg; +}; + +static int da9052_adjust_wled_brightness(struct da9052_bl *wleds) +{ + unsigned char boost_en; + unsigned char i_sink; + int ret; + + boost_en = 0x3F; + i_sink = 0xFF; + if (wleds->state == DA9052_WLEDS_OFF) { + boost_en = 0x00; + i_sink = 0x00; + } + + ret = da9052_reg_write(wleds->da9052, DA9052_BOOST_REG, boost_en); + if (ret < 0) { + dev_err(wleds->da9052->dev, + "Failed to write boost reg, %d\n", ret); + return ret; + } + + ret = da9052_reg_write(wleds->da9052, DA9052_LED_CONT_REG, i_sink); + if (ret < 0) { + dev_err(wleds->da9052->dev, + "Failed to write led cont reg, %d\n", ret); + return ret; + } + + ret = da9052_reg_write(wleds->da9052, wled_bank[wleds->led_reg], 0x0); + if (ret < 0) { + dev_err(wleds->da9052->dev, + "Failed to write led conf reg, %d", ret); + return ret; + } + + if (wleds->brightness) { + msleep(10); + ret = da9052_reg_write(wleds->da9052, wled_bank[wleds->led_reg], + wleds->brightness); + if (ret < 0) { + dev_err(wleds->da9052->dev, + "Failed to write led conf reg, %d", ret); + return ret; + } + } + + return 0; +} + +static int da9052_backlight_update_status(struct backlight_device *bl) +{ + int brightness = bl->props.brightness; + struct da9052_bl *wleds = bl_get_data(bl); + + wleds->brightness = brightness; + wleds->state = DA9052_WLEDS_ON; + + return da9052_adjust_wled_brightness(wleds); +} + +static int da9052_backlight_get_brightness(struct backlight_device *bl) +{ + struct da9052_bl *wleds = bl_get_data(bl); + + return wleds->brightness; +} + +static const struct backlight_ops da9052_backlight_ops = { + .update_status = da9052_backlight_update_status, + .get_brightness = da9052_backlight_get_brightness, +}; + +static int da9052_backlight_probe(struct platform_device *pdev) +{ + struct backlight_device *bl; + struct backlight_properties props; + static int led_reg_num; + struct da9052_bl *wleds; + + wleds = kzalloc(sizeof(struct da9052_bl), GFP_KERNEL); + if (!wleds) + return -ENOMEM; + + wleds->da9052 = dev_get_drvdata(pdev->dev.parent); + wleds->brightness = 0; + wleds->led_reg = platform_get_device_id(pdev)->driver_data; + wleds->state = DA9052_WLEDS_OFF; + + bl = backlight_device_register(pdev->name, wleds->da9052->dev, wleds, + &da9052_backlight_ops, &props); + if (IS_ERR(bl)) { + dev_err(&pdev->dev, "Failed to register backlight\n"); + kfree(wleds); + return PTR_ERR(bl); + } + + bl->props.max_brightness = DA9052_MAX_BRIGHTNESS; + bl->props.brightness = 0; + platform_set_drvdata(pdev, bl); + + return da9052_adjust_wled_brightness(wleds); +} + +static int da9052_backlight_remove(struct platform_device *pdev) +{ + struct backlight_device *bl = platform_get_drvdata(pdev); + struct da9052_bl *wleds = bl_get_data(bl); + + wleds->brightness = 0; + wleds->state = DA9052_WLEDS_OFF; + da9052_adjust_wled_brightness(wleds); + backlight_device_unregister(bl); + + return 0; +} + +static struct platform_device_id da9052_wled_ids[] = { + { + .name = "da9052-WLED1", + .driver_data = DA9052_TYPE_WLED1, + }, + { + .name = "da9052-WLED2", + .driver_data = DA9052_TYPE_WLED2, + }, + { + .name = "da9052-WLED3", + .driver_data = DA9052_TYPE_WLED3, + }, + {} +}; + +static struct platform_driver da9052_wled_driver = { + .probe = da9052_backlight_probe, + .remove = da9052_backlight_remove, + .id_table = da9052_wled_ids, + .driver = { + .name = "da9052-WLED", + .owner = THIS_MODULE, + }, +}; + +static int __init da9052_backlight_init(void) +{ + return platform_driver_register(&da9052_wled_driver); +} +module_init(da9052_backlight_init); + +static void __exit da9052_backlight_exit(void) +{ + platform_driver_unregister(&da9052_wled_driver); +} +module_exit(da9052_backlight_exit); + +MODULE_AUTHOR("David Dajun Chen <dchen(a)diasemi.com>"); +MODULE_DESCRIPTION("Backlight driver for DA9052 PMIC"); +MODULE_LICENSE("GPL"); +MODULE_ALIAS("platform:da9052-backlight");

13 years, 5 months

[ACTIVITY] Botao Sun 2011/06/30 to 2011/07/05.

by Botao Sun

Botao Sun <botao_sun> Highlights: 1. On-board to the Linaro Android Team. 2. Finished setup procedures. 3. Finished the latest Linaro build (11.06) installation on my own SD card, and updated the wiki page: https://wiki.linaro.org/Platform/Android/ImageInstallation?action=show&redi… 4. Preparing the UK business visit VISA. Plans: 1. Install the busybox on these 3 builds: https://android-build.linaro.org/builds/~linaro-android/panda/ https://android-build.linaro.org/builds/~linaro-android/leb-panda/ https://android-build.linaro.org/builds/~linaro-android/beagle/ 2. Contact Mr. Angus Ainslie to confirm a 4-hour hacking session per week on the Samsung Origen board Issues: 1. No panda board hardware (Zach will make an order for me) 2. Risk for my UK business VISA application: I haven't received the original invitation letter (required by my local UK embassy) although it has been sent out from UK on this Monday by courier. BR Botao Sun

13 years, 5 months

[PATCH v4] mmc: documentation of mmc non-blocking request usage and design.

by Per Forlin

Documentation about the background and the design of mmc non-blocking. Host driver guidelines to minimize request preparation overhead. Signed-off-by: Per Forlin <per.forlin(a)linaro.org> --- ChangeLog: v2: - Minor updates after proofreading comments from Chris v3: - Minor updates after more comments from Chris v4: - Minor updates after comments from Randy Documentation/mmc/00-INDEX | 2 + Documentation/mmc/mmc-async-req.txt | 86 +++++++++++++++++++++++++++++++++++ 2 files changed, 88 insertions(+), 0 deletions(-) create mode 100644 Documentation/mmc/mmc-async-req.txt diff --git a/Documentation/mmc/00-INDEX b/Documentation/mmc/00-INDEX index 93dd7a7..a9ba672 100644 --- a/Documentation/mmc/00-INDEX +++ b/Documentation/mmc/00-INDEX @@ -4,3 +4,5 @@ mmc-dev-attrs.txt - info on SD and MMC device attributes mmc-dev-parts.txt - info on SD and MMC device partitions +mmc-async-req.txt + - info on mmc asynchronous requests diff --git a/Documentation/mmc/mmc-async-req.txt b/Documentation/mmc/mmc-async-req.txt new file mode 100644 index 0000000..4877f29 --- /dev/null +++ b/Documentation/mmc/mmc-async-req.txt @@ -0,0 +1,86 @@ +Rationale +========= + +How significant is the cache maintenance overhead? +It depends. Fast eMMC and multiple cache levels with speculative cache +pre-fetch makes the cache overhead relatively significant. If the DMA +preparations for the next request are done in parallel with the current +transfer, the DMA preparation overhead would not affect the MMC performance. +The intention of non-blocking (asynchronous) MMC requests is to minimize the +time between when an MMC request ends and another MMC request begins. +Using mmc_wait_for_req(), the MMC controller is idle while dma_map_sg and +dma_unmap_sg are processing. Using non-blocking MMC requests makes it +possible to prepare the caches for next job in parallel with an active +MMC request. + +MMC block driver +================ + +The issue_rw_rq() in the MMC block driver is made non-blocking. +The increase in throughput is proportional to the time it takes to +prepare (major part of preparations are dma_map_sg and dma_unmap_sg) +a request and how fast the memory is. The faster the MMC/SD is +the more significant the prepare request time becomes. Roughly the expected +performance gain is 5% for large writes and 10% on large reads on a L2 cache +platform. In power save mode, when clocks run on a lower frequency, the DMA +preparation may cost even more. As long as these slower preparations are run +in parallel with the transfer performance wont be affected. + +Details on measurements from IOZone and mmc_test +================================================ + +https://wiki.linaro.org/WorkingGroups/Kernel/Specs/StoragePerfMMC-async-req + +MMC core API extension +====================== + +There is one new public function mmc_start_req(). +It starts a new MMC command request for a host. The function isn't +truly non-blocking. If there is on ongoing async request it waits +for completion of that request and starts the new one and returns. It +doesn't wait for the new request to complete. If there is no ongoing +request it starts the new request and returns immediately. + +MMC host extensions +=================== + +There are two optional hooks -- pre_req() and post_req() -- that the host +driver may implement in order to move work to before and after the actual +mmc_request function is called. In the DMA case pre_req() may do +dma_map_sg() and prepare the DMA descriptor, and post_req runs +the dma_unmap_sg. + +Optimize for the first request +============================== + +The first request in a series of requests can't be prepared in parallel with +the previous transfer, since there is no previous request. +The argument is_first_req in pre_req() indicates that there is no previous +request. The host driver may optimize for this scenario to minimize +the performance loss. A way to optimize for this is to split the current +request in two chunks, prepare the first chunk and start the request, +and finally prepare the second chunk and start the transfer. + +Pseudocode to handle is_first_req scenario with minimal prepare overhead: +if (is_first_req && req->size > threshold) + /* start MMC transfer for the complete transfer size */ + mmc_start_command(MMC_CMD_TRANSFER_FULL_SIZE); + + /* + * Begin to prepare DMA while cmd is being processed by MMC. + * The first chunk of the request should take the same time + * to prepare as the "MMC process command time". + * If prepare time exceeds MMC cmd time + * the transfer is delayed, guesstimate max 4k as first chunk size. + */ + prepare_1st_chunk_for_dma(req); + /* flush pending desc to the DMAC (dmaengine.h) */ + dma_issue_pending(req->dma_desc); + + prepare_2nd_chunk_for_dma(req); + /* + * The second issue_pending should be called before MMC runs out + * of the first chunk. If the MMC runs out of the first data chunk + * before this call, the transfer is delayed. + */ + dma_issue_pending(req->dma_desc); -- 1.7.4.1

13 years, 5 months

[PATCH v3] documentation of mmc non-blocking request

by Per Forlin

changes since v2: * Minor updates after more comments from Chris Per Forlin (1): mmc: documentation of mmc non-blocking request usage and design. Documentation/mmc/00-INDEX | 2 + Documentation/mmc/mmc-async-req.txt | 86 +++++++++++++++++++++++++++++++++++ 2 files changed, 88 insertions(+), 0 deletions(-) create mode 100644 Documentation/mmc/mmc-async-req.txt -- 1.7.4.1

13 years, 5 months

[PATCH v2] documentation of mmc non-blocking request

by Per Forlin

changes since v1: * Minor updates after proofreading comments from Chris Per Forlin (1): mmc: documentation of mmc non-blocking request usage and design. Documentation/mmc/00-INDEX | 2 + Documentation/mmc/mmc-async-req.txt | 86 +++++++++++++++++++++++++++++++++++ 2 files changed, 88 insertions(+), 0 deletions(-) create mode 100644 Documentation/mmc/mmc-async-req.txt -- 1.7.4.1

13 years, 5 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev July 2011