linaro-dev August 2011

linaro-dev@lists.linaro.org

126 participants
239 discussions

[Patch v2 08/11] Touch: DA9052 touchscreen driver

by ashishj3

This driver add support for DA9052 4-wire resistive ADC interfaced touchscreen controller. DA9052 is a MFD therefore this driver depends on DA9052 core driver for core functionalities. Signed-off-by: David Dajun Chen <dchen(a)diasemi.com> Signed-off-by: Ashish Jangam <ashish.jangam(a)kpitcummins.com> --- Changes since v2: - Replace kthreads with workqueue - Remove kfifos - Remove extra struct memebers - Taken care for bus type - Replace da9052_set/clear function with da9052_reg_update ( as DA9052 MFD got modified) - Add open and close functionality --- drivers/input/touchscreen/Kconfig | 7 + drivers/input/touchscreen/Makefile | 1 + drivers/input/touchscreen/da9052_tsi.c | 400 ++++++++++++++++++++++++++++++++ 3 files changed, 408 insertions(+), 0 deletions(-) create mode 100755 drivers/input/touchscreen/da9052_tsi.c diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig index cabd9e5..a5d2e7b 100644 --- a/drivers/input/touchscreen/Kconfig +++ b/drivers/input/touchscreen/Kconfig @@ -144,6 +144,13 @@ config TOUCHSCREEN_DA9034 Say Y here to enable the support for the touchscreen found on Dialog Semiconductor DA9034 PMIC. +config TOUCHSCREEN_DA9052 + tristate "Dialog DA9052 TSI" + depends on PMIC_DA9052 + help + Say y here to support the touchscreen found on + Dialog Semiconductor DA9052 PMIC + config TOUCHSCREEN_DYNAPRO tristate "Dynapro serial touchscreen" select SERIO diff --git a/drivers/input/touchscreen/Makefile b/drivers/input/touchscreen/Makefile index 282d6f7..a4aeb25 100644 --- a/drivers/input/touchscreen/Makefile +++ b/drivers/input/touchscreen/Makefile @@ -18,6 +18,7 @@ obj-$(CONFIG_TOUCHSCREEN_BITSY) += h3600_ts_input.o obj-$(CONFIG_TOUCHSCREEN_BU21013) += bu21013_ts.o obj-$(CONFIG_TOUCHSCREEN_CY8CTMG110) += cy8ctmg110_ts.o obj-$(CONFIG_TOUCHSCREEN_DA9034) += da9034-ts.o +obj-$(CONFIG_TOUCHSCREEN_DA9052) += da9052_tsi.o obj-$(CONFIG_TOUCHSCREEN_DYNAPRO) += dynapro.o obj-$(CONFIG_TOUCHSCREEN_HAMPSHIRE) += hampshire.o obj-$(CONFIG_TOUCHSCREEN_GUNZE) += gunze.o diff --git a/drivers/input/touchscreen/da9052_tsi.c b/drivers/input/touchscreen/da9052_tsi.c new file mode 100755 index 0000000..1b31dd1 --- /dev/null +++ b/drivers/input/touchscreen/da9052_tsi.c @@ -0,0 +1,400 @@ +/* + * TSI driver for Dialog DA9052 + * + * 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/input.h> +#include <linux/delay.h> +#include <linux/platform_device.h> + +#include <linux/mfd/da9052/reg.h> +#include <linux/mfd/da9052/da9052.h> + +struct da9052_tsi_reg { + u16 x; + u16 y; + u16 z; +}; + +struct da9052_tsi { + struct da9052 *da9052; + struct input_dev *dev; + struct workqueue_struct *ts_workq; + struct work_struct ts_report_penup; + int irq_pendwn; + int irq_datardy; + int pendown; + int workschd; + uint8_t lsb; +}; + +static int da9052_ts_start(struct da9052_tsi *tsi) +{ + return da9052_reg_update(tsi->da9052, DA9052_TSI_CONT_A_REG, + 1 << 0, 1 << 0); +} + +static int da9052_ts_stop(struct da9052_tsi *tsi) +{ + return da9052_reg_update(tsi->da9052, DA9052_TSI_CONT_A_REG, 1 << 0, 0); +} + +static irqreturn_t da9052_ts_pendwn_irq(int irq, void *data) +{ + struct da9052_tsi *tsi = (struct da9052_tsi *)data; + struct da9052 *da9052 = tsi->da9052; + int ret; + + /* Mask PEN_DOWN event and unmask TSI_READY event */ + da9052->events_mask |= DA9052_E_PEN_DOWN; + da9052->events_mask &= ~DA9052_E_TSI_READY; + ret = da9052_reg_update(da9052, DA9052_IRQ_MASK_B_REG, 0x80, 0x40); + if (ret < 0) + return IRQ_NONE; + + da9052_ts_start(tsi); + tsi->pendown = 1; + + input_report_key(tsi->dev, BTN_TOUCH, 1); + + return IRQ_HANDLED; +} + +static int da9052_ts_read(struct da9052_tsi *tsi) +{ + struct da9052_tsi_reg co_ord = {0, 0, 0}; + int ret; + uint8_t _x, _y, _z, _v; + + ret = da9052_reg_read(tsi->da9052, DA9052_TSI_X_MSB_REG); + if (ret < 0) + return ret; + + _x = (uint8_t) ret; + + ret = da9052_reg_read(tsi->da9052, DA9052_TSI_Y_MSB_REG); + if (ret < 0) + return ret; + + _y = (uint8_t) ret; + + ret = da9052_reg_read(tsi->da9052, DA9052_TSI_Z_MSB_REG); + if (ret < 0) + return ret; + + _z = (uint8_t) ret; + + ret = da9052_reg_read(tsi->da9052, DA9052_TSI_LSB_REG); + if (ret < 0) + return ret; + + _v = tsi->lsb = (uint8_t) ret; + + co_ord.x = ((_x << 2) & 0x3fc) | (_v & 0x3); + co_ord.y = ((_y << 2) & 0x3fc) | ((_v & 0xc) >> 2); + co_ord.z = ((_z << 2) & 0x3fc) | ((_v & 0x30) >> 4); + + input_report_abs(tsi->dev, ABS_X, co_ord.x); + input_report_abs(tsi->dev, ABS_Y, co_ord.y); + input_report_abs(tsi->dev, ABS_PRESSURE, co_ord.z); + input_report_key(tsi->dev, BTN_TOUCH, 1); + input_sync(tsi->dev); + + return 0; +} + +static irqreturn_t da9052_ts_datardy_irq(int irq, void *data) +{ + struct da9052_tsi *tsi = (struct da9052_tsi *)data; + + /* Avoid multiple schedule of queue */ + if (tsi->pendown && !tsi->workschd) + queue_work(tsi->ts_workq, &tsi->ts_report_penup); + return IRQ_HANDLED; +} + +static void da9052_ts_report_penup(struct work_struct *work) +{ + struct da9052_tsi *tsi = container_of(work, struct da9052_tsi, + ts_report_penup); + struct input_dev *ip_dev = tsi->dev; + struct da9052 *da9052 = tsi->da9052; + + /* Work queue is scheduled */ + tsi->workschd = 1; + + do { + da9052_ts_read(tsi); + + /* FixMe: At times TSI RDY IRQ does not get cleared causing + * toss to the PEN Detect Circuitry. Its safe to clear event + * here. + */ + da9052_reg_update(tsi->da9052, DA9052_EVENT_B_REG, 0x80, 0x80); + + } while (tsi->lsb & 0x40); + + /* Pen up Detected */ + tsi->pendown = 0; + /* Leaving work queue */ + tsi->workschd = 0 ; + + da9052_ts_stop(tsi); + + /* Unmask PEN_DOWN event */ + da9052->events_mask &= ~DA9052_E_PEN_DOWN; + da9052_reg_update(da9052, DA9052_IRQ_MASK_B_REG, 0x40, 0); + + input_report_abs(ip_dev, ABS_PRESSURE, 0); + input_report_key(ip_dev, BTN_TOUCH, 0); + input_sync(ip_dev); +} + +static int da9052_ts_configure_gpio(struct da9052 *da9052) +{ + int ret; + + ret = da9052_reg_update(da9052, DA9052_GPIO_2_3_REG, 0x30, 0); + if (ret < 0) + return ret; + + ret = da9052_reg_update(da9052, DA9052_GPIO_4_5_REG, 0x33, 0); + if (ret < 0) + return ret; + + ret = da9052_reg_update(da9052, DA9052_GPIO_6_7_REG, 0x33, 0); + + return ret; +} + +static int __init da9052_configure_tsi(struct da9052_tsi *tsi) +{ + ssize_t ret; + struct da9052 *da9052 = tsi->da9052; + + ret = da9052_ts_configure_gpio(tsi->da9052); + if (ret < 0) + return ret; + + /* Measure TSI sample every 1ms */ + ret = da9052_reg_update(tsi->da9052, DA9052_ADC_CONT_REG, + 1 << 6, 1 << 6); + if (ret < 0) + return ret; + + /* TSI_DELAY: 3 slots, TSI_SKIP: 0 slots, TSI_MODE: XYZP */ + ret = da9052_reg_update(tsi->da9052, DA9052_TSI_CONT_A_REG, 0xFC, 0xC0); + if (ret < 0) + return ret; + + /* Mask TSI_READY event */ + da9052->events_mask |= DA9052_E_TSI_READY; + ret = da9052_reg_update(da9052, DA9052_IRQ_MASK_B_REG, 0, 0x80); + if (ret < 0) + return ret; + + /*Supply TSIRef through LD09 */ + ret = da9052_reg_write(tsi->da9052, DA9052_LDO9_REG, 0x59); + + return ret; +} + +static int da9052_ts_input_open(struct input_dev *input_dev) +{ + struct da9052_tsi *tsi = input_get_drvdata(input_dev); + + /* Enable Pen Detect Circuit */ + return da9052_reg_update(tsi->da9052, DA9052_TSI_CONT_A_REG, + 1 << 1, 1 << 1); +} + +static void da9052_ts_input_close(struct input_dev *input_dev) +{ + struct da9052_tsi *tsi = input_get_drvdata(input_dev); + + /* Disable Pen Detect Circuit */ + da9052_reg_update(tsi->da9052, DA9052_TSI_CONT_A_REG, 1 << 1, 0); +} + +static s32 __devinit da9052_ts_probe(struct platform_device *pdev) +{ + struct da9052_tsi *tsi; + struct input_dev *input_dev; + struct da9052 *da9052; + int ret; + + tsi = kzalloc(sizeof(struct da9052_tsi), GFP_KERNEL); + if (!tsi) + return -ENOMEM; + + da9052 = dev_get_drvdata(pdev->dev.parent); + if (da9052 == NULL) { + dev_err(tsi->da9052->dev, "Failed to get driver's data\n"); + ret = -EINVAL; + goto err_mem; + } + + input_dev = input_allocate_device(); + if (!input_dev) { + dev_err(tsi->da9052->dev, "Failed to allocate input device\n"); + ret = -ENOMEM; + goto err_mem; + } + + tsi->ts_workq = create_singlethread_workqueue("kda9052"); + if (tsi->ts_workq == NULL) { + dev_err(tsi->da9052->dev, "Failed to create workqueue\n"); + ret = -EINVAL; + goto err_input; + } + + INIT_WORK(&tsi->ts_report_penup, da9052_ts_report_penup); + + tsi->da9052 = da9052; + + input_dev->id.version = 0x0101; + input_dev->id.vendor = 0x15B6; + input_dev->id.product = 0x9052; + input_dev->id.bustype = tsi->da9052->bustype; + input_dev->name = "Dialog DA9052 TouchScreen Driver"; + input_dev->dev.parent = &pdev->dev; + input_dev->open = da9052_ts_input_open; + input_dev->close = da9052_ts_input_close; + __set_bit(EV_ABS, input_dev->evbit); + __set_bit(EV_KEY, input_dev->evbit); + __set_bit(BTN_TOUCH, input_dev->keybit); + __set_bit(ABS_X, input_dev->absbit); + __set_bit(ABS_Y, input_dev->absbit); + __set_bit(ABS_PRESSURE, input_dev->absbit); + + input_set_abs_params(input_dev, ABS_X, 0, 1023, 0, 0); + input_set_abs_params(input_dev, ABS_Y, 0, 1023, 0, 0); + input_set_abs_params(input_dev, ABS_PRESSURE, 0, 1023, 0, 0); + + tsi->dev = input_dev; + input_set_drvdata(input_dev, tsi); + + tsi->pendown = tsi->workschd = 0; + + tsi->irq_pendwn = platform_get_irq_byname(pdev, "PENDWN"); + if (tsi->irq_pendwn < 0) { + ret = tsi->irq_pendwn; + goto err_workq; + } + + ret = request_threaded_irq(tsi->da9052->irq_base + tsi->irq_pendwn, + NULL, da9052_ts_pendwn_irq, + IRQF_TRIGGER_LOW | IRQF_ONESHOT, + "PENDWN", tsi); + if (ret < 0) { + dev_err(tsi->da9052->dev, + "Failed to register %s IRQ %d, error = %d\n", "PENDWN", + tsi->da9052->irq_base + tsi->irq_pendwn, ret); + goto err_workq; + } + + tsi->irq_datardy = platform_get_irq_byname(pdev, "TSIRDY"); + if (tsi->irq_datardy < 0) { + ret = tsi->irq_datardy; + goto err_pendwn_irq; + } + + ret = request_threaded_irq(tsi->da9052->irq_base + tsi->irq_datardy, + NULL, da9052_ts_datardy_irq, + IRQF_TRIGGER_LOW | IRQF_ONESHOT, + "TSIRDY", tsi); + if (ret < 0) { + dev_err(tsi->da9052->dev, + "Failed to register %s IRQ %d, error = %d\n", "TSIRDY", + tsi->da9052->irq_base + tsi->irq_datardy, ret); + goto err_pendwn_irq; + } + + ret = da9052_configure_tsi(tsi); + if (ret < 0) + goto err_datardy_irq; + + ret = input_register_device(tsi->dev); + if (ret < 0) + goto err_datardy_irq; + + platform_set_drvdata(pdev, tsi); + + return 0; + +err_datardy_irq: + free_irq(tsi->da9052->irq_base + tsi->irq_datardy, tsi); +err_pendwn_irq: + free_irq(tsi->da9052->irq_base + tsi->irq_pendwn, tsi); +err_workq: + destroy_workqueue(tsi->ts_workq); +err_input: + input_free_device(input_dev); +err_mem: + kfree(tsi); + return ret; +} + +static int __devexit da9052_ts_remove(struct platform_device *pdev) +{ + struct da9052_tsi *tsi = platform_get_drvdata(pdev); + s32 ret; + + ret = da9052_reg_update(tsi->da9052, DA9052_TSI_CONT_A_REG, 1 << 0, 0); + if (ret < 0) + return ret; + + ret = da9052_reg_write(tsi->da9052, DA9052_LDO9_REG, 0x19); + if (ret < 0) + return ret; + + cancel_work_sync(&tsi->ts_report_penup); + destroy_workqueue(tsi->ts_workq); + + free_irq(tsi->da9052->irq_base + tsi->irq_pendwn, tsi); + free_irq(tsi->da9052->irq_base + tsi->irq_datardy, tsi); + + input_unregister_device(tsi->dev); + + platform_set_drvdata(pdev, NULL); + + kfree(tsi); + + return 0; +} + +static struct platform_driver da9052_tsi_driver = { + + .probe = da9052_ts_probe, + .remove = __devexit_p(da9052_ts_remove), + .driver = { + .name = "da9052-tsi", + .owner = THIS_MODULE, + }, +}; + +static int __init da9052_ts_init(void) +{ + return platform_driver_register(&da9052_tsi_driver); +} +module_init(da9052_ts_init); + +static void __exit da9052_ts_exit(void) +{ + platform_driver_unregister(&da9052_tsi_driver); +} +module_exit(da9052_ts_exit); + +MODULE_DESCRIPTION("Touchscreen driver for Dialog Semiconductor DA9052"); +MODULE_AUTHOR("David Dajun Chen <dchen(a)diasemi.com>"); +MODULE_LICENSE("GPL"); +MODULE_ALIAS("platform:da9052-tsi");

14 years, 10 months

Re: Linaro 11.08 released

by Dave Martin

Hi there A few questions-- a) Is the omission of the "Developers and Community Builds" links from http://www.linaro.org/downloads/ intentional? This is a concern, because these links contain the _only_ deliverables for certain platform and filesystem combinations. The wiki release page itself is not easily findable without going to the wiki. b) The release page on the wiki contains important information like the list of known issues. Shouldn't this page be linked from http://www.linaro.org/downloads/ or some other prominent location? I don't see how to get to it at present. A visitor won't know that they have to go to the wiki for this information. c) The known issues list on the wiki release page doesn't seem include all the issues reported during testing. Will these get propagated, or is it the responsibility of testers to add the relevant information to the known issues list themselves? d) For vexpress specifically, there is no link from the release pages or downloads to the specific installation instructions applicable to this board. Even I find these difficult to find without bookmarking. Because that information is very board-specific, I don't think it needs to be included on https://wiki.linaro.org/Platform/DevPlatform/Ubuntu/ImageInstallation -- but can we at least have a link on there pointing to the appropriate page? Cheers ---Dave On Fri, Aug 26, 2011 at 3:04 AM, Fathi Boudra <fathi.boudra(a)linaro.org> wrote: > Hi, > > The Linaro Team is pleased to announce the release of Linaro 11.08. > > 11.08 is the Linaro’s third release delivered on the new monthly cadence. > Once again, this release includes components delivered by all Working Groups, > Landing Teams and Platform Teams, bringing the best of Linaro Technology > integrated on top of Android and Ubuntu based images. > > In total this makes an impressive thirty components and two platform builds > from all Linaro engineering teams in one shot. And again, most of this comes > nicely integrated into Android and Ubuntu platform builds. This release made > it again hard to select a handful of highlights from a list of roughly > 80 deliverables that went into this release. > > However, if we had to choose we would like to emphasize the update of > linux-linaro to the 3.0.3 stable kernel including the merge of 3.1-rc1 core ARM > updates, Linaro GCC 4.6 2011.08 release based on latest upstream version, and > Linaro Cross Toolchain 2011.07 builds. In addition, the Android Team delivers > the enablement of all of our primary boards, compiled with the Linaro 11.08 > toolchain release based on GCC 4.6 and running Android 2.3.5. > > We encourage everybody to use the 11.08 release. The download links for all > images and components are available on our release page: > > http://wiki.linaro.org/Cycles/1108/Release > > See the detailed highlights of this release to get a better overview of what > was done by the individual teams. The release details are linked from > the "Details" column for each release artifact on the release information: > > http://wiki.linaro.org/Cycles/1108/Release#Release_Information > > Using the Android-based images > ============================== > > The Android-based images come in three parts: system, userdata and boot. > These need to be combined to form a complete Android install. For an > explanation of how to do this please see: > > http://wiki.linaro.org/Platform/Android/ImageInstallation > > If you are interested in getting the source and building these images > yourself please see the following pages: > > http://wiki.linaro.org/Platform/Android/GetSource > http://wiki.linaro.org/Platform/Android/BuildSource > > Using the Ubuntu-based images > ============================= > > The Ubuntu-based images consist of two parts. The first part is a hardware > pack, which can be found under the hwpacks directory and contains hardware > specific packages (such as the kernel and bootloader). The second part is > the rootfs, which is combined with the hardware pack to create a complete > image. For more information on how to create an image please see: > > http://wiki.linaro.org/Platform/DevPlatform/Ubuntu/ImageInstallation > > Getting involved > ================ > > More information on Linaro can be found on our websites: > > * Homepage: http://www.linaro.org > * Wiki: http://wiki.linaro.org > > Also subscribe to the important Linaro mailing lists and join our IRC > channels to stay on top of Linaro developments: > > * Announcements: > http://lists.linaro.org/mailman/listinfo/linaro-announce > * Development: > http://lists.linaro.org/mailman/listinfo/linaro-dev > * IRC: > #linaro on irc.linaro.org or irc.freenode.net > #linaro-android irc.linaro.org or irc.freenode.net > > Known issues with this release > ============================== > > For any errata issues, please see: > > http://wiki.linaro.org/Cycles/1108/Release#Known_Issues > > Bug reports for this release should be filed in Launchpad against the > individual packages that are affected. If a suitable package cannot be > identified, feel free to assign them to: > > http://www.launchpad.net/linaro > > Cheers, > > -- > Fathi Boudra, on behalf of the Release Team > Linaro Release Manager | Platform Project Manager > Linaro.org | Open source software for ARM SoCs > > _______________________________________________ > linaro-announce mailing list > linaro-announce(a)lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-announce > -- Dave Martin <dave.martin(a)linaro.org> Linaro Kernel Working Group -- http://www.linaro.org/ -- Open source software for ARM SoCs http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg http://www.linaro.org/linaro-blog/

14 years, 10 months

Fwd: Would you send me your hard float experiment results you presented in Budapest?

by Zach Pfeffer

Steve, I'd like you to meet Jim who did the initial hardfloat work. This email contains the results that Jim produced. I believe that the conclusion was that skia and webkit may benefit, but that such benefits would impose an undue burden on Android's distribution model which tries to create libs that can run on as many architectures as possible. -Zach ---------- Forwarded message ---------- From: Jim Huang <jserv(a)0xlab.org> Date: 7 August 2011 18:01 Subject: Re: Would you send me your hard float experiment results you presented in Budapest? To: Zach Pfeffer <zach.pfeffer(a)linaro.org> 2011/8/7 Zach Pfeffer <zach.pfeffer(a)linaro.org>: > Jim, > > Thanks. Would it be possible to post them by the end of the day? skia -> Switch from VFP back to fixed scalar based calculation Previous configuration enabled ARM VFP for scalar float, but VFP on ARM11 is not as powerful as VFPv3 or NEON. Reference benchmark: Item Fixed based VFP-based ------------ ----------- --------- Draw Canvas 58.37 fps 58.40 fps Draw Circle 37.48 fps 22.93 fps Draw Circle2 17.14 fps 18.31 fps Draw Rect 17.62 fps 20.69 fps Draw Arc 24.79 fps 27.45 fps Draw Image 19.08 fps 18.73 fps Draw Text 29.22 fps 25.79 fps > > Also, have you sync'd up with Mike? He wants to negotiate on your contract. I sent mail to Mike already. I don't know how to proceed. Thanks, -jserv

14 years, 10 months

[PATCH] ARM: EXYNOS4: ADD USB EHCI device to SMDKV310

by Sachin Kamat

Signed-off-by: Bhuvana Kakunoori <bhuvana.kakunoori(a)linaro.org> Signed-off-by: Pankaj Dubey <pankaj.dubey(a)samsung.com> Signed-off-by: Sachin Kamat <sachin.kamat(a)linaro.org> --- arch/arm/mach-exynos4/Kconfig | 2 ++ arch/arm/mach-exynos4/mach-smdkv310.c | 16 ++++++++++++++++ 2 files changed, 18 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig index bb29d51..cc97d23 100644 --- a/arch/arm/mach-exynos4/Kconfig +++ b/arch/arm/mach-exynos4/Kconfig @@ -136,6 +136,7 @@ config MACH_SMDKV310 bool "SMDKV310" select CPU_EXYNOS4210 select S5P_DEV_FIMD0 + select S5P_DEV_USB_EHCI select S3C_DEV_RTC select S3C_DEV_WDT select S3C_DEV_I2C1 @@ -151,6 +152,7 @@ config MACH_SMDKV310 select SAMSUNG_DEV_PWM select EXYNOS4_DEV_SYSMMU select EXYNOS4_SETUP_FIMD0 + select EXYNOS4_SETUP_USB_PHY select EXYNOS4_SETUP_I2C1 select EXYNOS4_SETUP_KEYPAD select EXYNOS4_SETUP_SDHCI diff --git a/arch/arm/mach-exynos4/mach-smdkv310.c b/arch/arm/mach-exynos4/mach-smdkv310.c index 5f62b2b..b6c28ea 100644 --- a/arch/arm/mach-exynos4/mach-smdkv310.c +++ b/arch/arm/mach-exynos4/mach-smdkv310.c @@ -33,6 +33,8 @@ #include <plat/gpio-cfg.h> #include <plat/backlight.h> #include <plat/mfc.h> +#include <plat/ehci.h> +#include <plat/clock.h> #include <mach/map.h> @@ -167,6 +169,16 @@ static struct i2c_board_info i2c_devs1[] __initdata = { {I2C_BOARD_INFO("wm8994", 0x1a),}, }; +/* USB EHCI */ +static struct s5p_ehci_platdata smdkv310_ehci_pdata; + +static void __init smdkv310_ehci_init(void) +{ + struct s5p_ehci_platdata *pdata = &smdkv310_ehci_pdata; + + s5p_ehci_set_platdata(pdata); +} + static struct platform_device *smdkv310_devices[] __initdata = { &s3c_device_hsmmc0, &s3c_device_hsmmc1, @@ -175,6 +187,7 @@ static struct platform_device *smdkv310_devices[] __initdata = { &s3c_device_i2c1, &s3c_device_rtc, &s3c_device_wdt, + &s5p_device_ehci, &exynos4_device_ac97, &exynos4_device_i2s0, &samsung_device_keypad, @@ -258,6 +271,9 @@ static void __init smdkv310_machine_init(void) samsung_bl_set(&smdkv310_bl_gpio_info, &smdkv310_bl_data); + smdkv310_ehci_init(); + clk_xusbxti.rate = 24000000; + platform_add_devices(smdkv310_devices, ARRAY_SIZE(smdkv310_devices)); s5p_device_mfc.dev.parent = &exynos4_device_pd[PD_MFC].dev; } -- 1.7.4.1

14 years, 10 months

Tracking Android kernel tips and Android builds

by Zach Pfeffer

Now that we have an Android build for every board and Gerrit and LAVA I'd like to unify how we handle kernels for each so that we can work more efficiently, start to unify the kernels and provide a means for external Android users to start to improve these trees. First, since we control the kernels that go into our Android builds I'd like to follow AOSP convention and have: kernel/common.git (john's tree) kernel/imx53.git kernel/omap.git kernel/origen.git kernel/snowball.git (right now we have: panda, beagle <remote name="linaro-other" fetch="git://git.linaro.org/"/> <project path="kernel" name="people/jstultz/android" revision="linaro-android-3.0" remote="linaro-other"/> panda-leb <remote name="linaro-other" fetch="git://git.linaro.org/"/> <project path="kernel" name="people/andygreen/kernel-tilt" revision="tilt-jstultz-linaro-android-3.0" remote="linaro-other"/> leb-snowball <remote name="linaro-other" fetch="git://git.linaro.org/"/> <project path="kernel" name="bsp/st-ericsson/linux-3.0-android-ux500" revision="master" remote="linaro-other"/> leb-origen <remote name="linaro-other" fetch="git://git.linaro.org/"/> <project path="kernel" name="people/angus/linux-linaro-3.0" remote="linaro-other" revision="android"/> leb-imx53 <remote fetch="git://git.linaro.org/" name="linaro-other"/> <project name="people/bernhardrosenkranzer/android-kernel-iMX53" path="kernel" remote="linaro-other" revision="3d981d9418c53e3e1a079582088121c641588791"/> ) I'd like these to be at git://android.git.linaro.org/. I'd like to not mirror. Each tree would accept patches via Gerrit and be maintainable through standard git by the tree maintainers. This should allow upgrades to each, without needing to push all the upgrade patches through Gerrit. Next, we'd like to point to a tip branch for each of these trees. This branch would be were development would be happening. Tracking tip is fundamental to continuous integration, if its broken then the primary job of everyone should be getting it going again. I'd like to suggest the branches be named the same and follow John's branch naming convention: linaro-android-3.0...etc Lastly, I'd like to request (and we may be able to automate this once all the kernels are co-located) that once a pinned-manifest.xml comes out, referencing a specific sha1, I'd like to lay a tag on that sha so it sticks around. Its better to tag after the fact because it saves having to do another build/test/qa cycle and will ensure that our pinned-manifest.xml continue to work. I suspect a few growing pains, but I think this is going to be great. Once the kernels are co-located we should be able to look at Gerrit extensions that allow easier upstream patch submission and tracking. We should also be able to more easily refactor things. Using the Gerrit flow and extending it to support Android upstreaming is exactly the thing Linaro was built for. Since Gerrit is such an integral part of Android development, extensions to allow patch propagation would allow a lot of the good work to flow back into the mainline kernel. -Zach

14 years, 10 months

[ACTIVITY] Graphics WG status report - wk34.2011 (20110822-20110826)

by Ilias Biris

Status: https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/WeeklyReport Last meeting minutes: https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/Notes/2011-08-24 Highlights: Milestones for 1109 deliverables: - https://launchpad.net/unity-gles/+milestone/2011.09 - https://launchpad.net/glcompbench/+milestone/2011.09 - https://launchpad.net/linaro-graphics-misc/+milestone/2011.09 - https://launchpad.net/glmark2/+milestone/2011.09 - https://launchpad.net/glproxy/+milestone/2011.09 - https://launchpad.net/linaro-mm-sig/+milestone/2011.09 (memory management work) Today (31Aug) we will discuss how to make available the unity/nux on 1109. I will update the milestone page once the decision is taken. Also note the development on MM: Jesse is preparing a GIT tree to contain the patches available, including components from the Video-Multimedia side (eg OMAP DRM driver (maybe others too), xf86-video-omap open source xorg driver). The tree can be made available as a meta-pkg for the Linaro main release in September (add-on "use at own risk" since all this is work still in progress and not upstreamed completely). Details on the tree and how to use it will come during September. BR, -- Ilias Biris ilias.biris(a)linaro.org Project Manager, Linaro M: +358504839608, IRC: ibiris Skype: ilias_biris Linaro.org│ Open source software for ARM SoCs

14 years, 10 months

[PATCH 0/3] Extend SDHCI support for Origen board

by Tushar Behera

Patch 1: It fixes the incorrect card detection type. Patch 2: It enables secondary MMC port. Patch 3: It extends support of 8-bit bus width The patches are rebased to for-next branch of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git Tushar Behera (3): ARM: EXYNOS4: Fix sdhci card detection for ORIGEN ARM: EXYNOS4: Add support for secondary MMC port on ORIGEN ARM: EXYNOS4: Add support for 8-bit bus width in SDHCI for ORIGEN arch/arm/mach-exynos4/Kconfig | 1 + arch/arm/mach-exynos4/mach-origen.c | 19 ++++++++++++++++--- 2 files changed, 17 insertions(+), 3 deletions(-) -- 1.7.4.1

14 years, 10 months

11.07 oprofile on panda busted?

by Tom Gall

Hi all, Say has anyone else run oprofile on recent builds on panda? By recent I mean say anything since 11.07? Reason for asking is I'm seeing basically a very very small number of samples being recorded... as in there's no way this is right. Log: root@linaro-desktop:/home/linaro/ltj-1.1.90-d# opcontrol --reset Signalling daemon... done root@linaro-desktop:/home/linaro/ltj-1.1.90-d# opcontrol --start Profiler running. root@linaro-desktop:/home/linaro/ltj-1.1.90-d# ./djpeg ~linaro/Saturn.jpg > /dev/null Decoding took 1216 ms root@linaro-desktop:/home/linaro/ltj-1.1.90-d# ./djpeg ~linaro/Saturn.jpg > /dev/null Decoding took 1206 ms root@linaro-desktop:/home/linaro/ltj-1.1.90-d# root@linaro-desktop:/home/linaro/ltj-1.1.90-d# ./djpeg ~linaro/Saturn.jpg > /dev/null Decoding took 1207 ms root@linaro-desktop:/home/linaro/ltj-1.1.90-d# ./djpeg ~linaro/Saturn.jpg > /dev/null Decoding took 1212 ms root@linaro-desktop:/home/linaro/ltj-1.1.90-d# opcontrol --stop Stopping profiling. root@linaro-desktop:/home/linaro/ltj-1.1.90-d# opreport -l ./djpeg Overflow stats not available CPU: CPU with timer interrupt, speed 0 MHz (estimated) Profiling through timer interrupt samples % symbol name 1 100.000 put_pixel_rows I'll pull the latest and retry still, this I think is the11.07 ubuntu-desktop LEB release for panda (or pretty close) uname -a Linux linaro-desktop 3.0.0-1001-linaro-omap #1~ppa~natty-Ubuntu SMP PREEMPT Mon Jul 25 22:44:36 UTC 2011 armv7l armv7l armv7l GNU/Linux 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

14 years, 10 months

Preliminary wiki starting page for i.MX53 QuickStart board

by Eric Miao

https://wiki.linaro.org/Boards/MX53QuickStart Sorry guys, although been pushed and pinged several times by various people we are finally able to come up with a preliminary starting page for i.MX53 QuickStart board. It's currently very simple, and hopefully we'll get it more detailed in the future. Feedback is welcome! Thanks - eric

14 years, 10 months

11.08 Pre-built Images

by Andy Doan

The 11.08 release includes some commonly used pre-built images. This mean you can now download a single file and "dd" it to your SD card without having to use linaro-media-create. The images just use the l-m-c defaults. ie, there's no pre-built image that uses BTRFS. The downloads are: - Nano: http://releases.linaro.org/images/linaro-n/nano/11.08/ - ALIP: http://releases.linaro.org/images/linaro-n/alip/11.08/ - Ubuntu Desktop: http://releases.linaro.org/images/linaro-n/ubuntu-desktop/11.08/ Each link includes some brief instructions on what to do. Need help understanding what to download for a given SoC? Take a look at the mapping we've put together here: https://wiki.linaro.org/Boards -andy

14 years, 10 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev August 2011