linaro-dev August 2011

linaro-dev@lists.linaro.org

126 participants
239 discussions

[REMINDER] Linaro 11.08 release dates and deliveries

by Fathi Boudra

Hi This is a mail sent to remind you the coming release dates: * WG components release is August 18th, 2011. * Linaro 11.08 RC images is August 22th, 2011. * Linaro 11.08 release is August 25th, 2011. The following components are planned to be delivered: * Graphics WG: compiz-plugins, compiz, glcompbench, glew-es, glmark2, nux, unity * Kernel WG: u-boot-linaro, linux-linaro * Landing Teams: linux-linaro-lt-freescale, linux-linaro-android-lt-ti, linux-linaro-lt-samsung, linux-linaro-lt-st-ericsson, linux-linaro-lt-ti * Multimedia WG: libjpeg-turbo * Platform Teams: lava-dashboard-tool, lava-dashboard, lava-dispatcher, lava-scheduler, lava-scheduler-tool, lava-server, lava-test, lava-tool, linaro-image-tools, svammel * Power Management WG: pm-qa, powerdebug, powertop * Toolchain WG: gdb-linaro, gcc-linaro 4.5, gcc-linaro 4.6, qemu-linaro Cheers, -- Fathi Boudra Linaro Release Manager | Platform Project Manager Linaro.org | Open source software for ARM SoCs

13 years, 4 months

[ACTIVITY] Graphics WG - status wk32.2011 (20110808 - 20110812)

by Ilias Biris

Status report: https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/WeeklyReport Weekly meeting minutes: https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/Notes/2011-08-10 Highlights: work is progressing well, please observe the dates for the release of the graphics components for 11.08 (18 August). 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

13 years, 4 months

[ACTIVITY] Status Report - OCTO - wk32.2011 (20110808-20110812)

by Ilias Biris

Status report is https://wiki.linaro.org/OfficeofCTO/WeeklyReport Weekly meeting minutes from wk 32: https://wiki.linaro.org/OfficeofCTO/2011-08-09 Highlights: - On Boot Architecture: the Connect meeting was quite useful (see minutes taken here https://wiki.linaro.org/OfficeofCTO/BootArchitecture/2011-08-05) helping to gauge the focus for the next 6 months. - On ArmHF: there is currently work undergoing to meet the 1108 work targets (more details for those in http://status.linaro.org/11.11/group/tr-octo-armhf.html) - OCTO team members are now looking for the future items - Preliminary ideas were collected during the weekly meeting see minutes at the top. Other items to note: - David Rusling and Grant Likely are attending the LinuxCon North America during 17-19 Aug 2011 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

13 years, 4 months

[PATCH v2] usb: musb: ux500: optimize DMA callback routine

by Per Forlin

From: Per Forlin <per.forlin(a)linaro.org> Skip the use of work queue and call musb_dma_completion() directly from DMA callback context. Here follows measurements on a Snowball board with ondemand governor active. Performance using work queue: (105 MB) copied, 6.23758 s, 16.8 MB/s (105 MB) copied, 5.7151 s, 18.3 MB/s (105 MB) copied, 5.83583 s, 18.0 MB/s (105 MB) copied, 5.93611 s, 17.7 MB/s Performance without work queue (105 MB) copied, 5.62173 s, 18.7 MB/s (105 MB) copied, 5.61811 s, 18.7 MB/s (105 MB) copied, 5.57817 s, 18.8 MB/s (105 MB) copied, 5.58549 s, 18.8 MB/s Signed-off-by: Per Forlin <per.forlin(a)linaro.org> Acked-by: Mian Yousaf Kaukab<mian.yousaf.kaukab(a)stericsson.com> --- Change log. v2: remove cast for void pointer drivers/usb/musb/ux500_dma.c | 43 ++--------------------------------------- 1 files changed, 3 insertions(+), 40 deletions(-) diff --git a/drivers/usb/musb/ux500_dma.c b/drivers/usb/musb/ux500_dma.c index ef4333f..2402f6e 100644 --- a/drivers/usb/musb/ux500_dma.c +++ b/drivers/usb/musb/ux500_dma.c @@ -37,7 +37,6 @@ struct ux500_dma_channel { struct dma_channel channel; struct ux500_dma_controller *controller; struct musb_hw_ep *hw_ep; - struct work_struct channel_work; struct dma_chan *dma_chan; unsigned int cur_len; dma_cookie_t cookie; @@ -56,52 +55,21 @@ struct ux500_dma_controller { dma_addr_t phy_base; }; -/* Work function invoked from DMA callback to handle tx transfers. */ -static void ux500_tx_work(struct work_struct *data) -{ - struct ux500_dma_channel *ux500_channel = container_of(data, - struct ux500_dma_channel, channel_work); - struct musb_hw_ep *hw_ep = ux500_channel->hw_ep; - struct musb *musb = hw_ep->musb; - unsigned long flags; - - dev_dbg(musb->controller, "DMA tx transfer done on hw_ep=%d\n", - hw_ep->epnum); - - spin_lock_irqsave(&musb->lock, flags); - ux500_channel->channel.actual_len = ux500_channel->cur_len; - ux500_channel->channel.status = MUSB_DMA_STATUS_FREE; - musb_dma_completion(musb, hw_ep->epnum, - ux500_channel->is_tx); - spin_unlock_irqrestore(&musb->lock, flags); -} - -/* Work function invoked from DMA callback to handle rx transfers. */ -static void ux500_rx_work(struct work_struct *data) +void ux500_dma_callback(void *private_data) { - struct ux500_dma_channel *ux500_channel = container_of(data, - struct ux500_dma_channel, channel_work); + struct dma_channel *channel = private_data; + struct ux500_dma_channel *ux500_channel = channel->private_data; struct musb_hw_ep *hw_ep = ux500_channel->hw_ep; struct musb *musb = hw_ep->musb; unsigned long flags; - dev_dbg(musb->controller, "DMA rx transfer done on hw_ep=%d\n", - hw_ep->epnum); - spin_lock_irqsave(&musb->lock, flags); ux500_channel->channel.actual_len = ux500_channel->cur_len; ux500_channel->channel.status = MUSB_DMA_STATUS_FREE; musb_dma_completion(musb, hw_ep->epnum, ux500_channel->is_tx); spin_unlock_irqrestore(&musb->lock, flags); -} - -void ux500_dma_callback(void *private_data) -{ - struct dma_channel *channel = (struct dma_channel *)private_data; - struct ux500_dma_channel *ux500_channel = channel->private_data; - schedule_work(&ux500_channel->channel_work); } static bool ux500_configure_channel(struct dma_channel *channel, @@ -330,7 +298,6 @@ static int ux500_dma_controller_start(struct dma_controller *c) void **param_array; struct ux500_dma_channel *channel_array; u32 ch_count; - void (*musb_channel_work)(struct work_struct *); dma_cap_mask_t mask; if ((data->num_rx_channels > UX500_MUSB_DMA_NUM_RX_CHANNELS) || @@ -347,7 +314,6 @@ static int ux500_dma_controller_start(struct dma_controller *c) channel_array = controller->rx_channel; ch_count = data->num_rx_channels; param_array = data->dma_rx_param_array; - musb_channel_work = ux500_rx_work; for (dir = 0; dir < 2; dir++) { for (ch_num = 0; ch_num < ch_count; ch_num++) { @@ -374,15 +340,12 @@ static int ux500_dma_controller_start(struct dma_controller *c) return -EBUSY; } - INIT_WORK(&ux500_channel->channel_work, - musb_channel_work); } /* Prepare the loop for TX channels */ channel_array = controller->tx_channel; ch_count = data->num_tx_channels; param_array = data->dma_tx_param_array; - musb_channel_work = ux500_tx_work; is_tx = 1; } -- 1.7.4.1

13 years, 4 months

Re: jpeg files cannot be displayed clearly with libjpeg-turbo

by Zach Pfeffer

Chao, Put this info and patches into a bug please so we can track it. -Zach On 12 August 2011 15:09, Chao Yang <chao.yang(a)linaro.org> wrote: > Hi Tom, > As communicated before, I've committed the libjpeg-turbo to > linaro-android-2.3.4. The wallpaper display problem is fixed by the patch > enclosed. > However, there are some problems with jpeg picture decoding, e.g. the > wallpaper file: the picture cannot be displayed clearly. Please refer to > libjpeg-turbo.jpg in the zip file enclosed. > I pulled down the latest code from branch 1.1.1_linaro_android which > integrated Mans Rullgard's patches. But with these patches, the jpeg file > cannot be decoded correctly. Please also refer to with_patches.jpg in the > zip file enclosed. I suppose the patches are not fully tested yet. > The wallpaper original source file is enclosed for your reference. I am > wondering if you have any clue on the issues above? Any update will be > highly appreciated. Many thanks. > Best regards > -- > > Chao Yang > Android Platform Team > Linaro.org │ Open source software for ARM SoCs > Follow Linaro: > http://www.facebook.com/pages/Linaro/155974581091106 > http://twitter.com/#!/linaroorg > http://www.linaro.org/linaro-blog/ >

13 years, 4 months

Marking a toolchain or build releasable - for saving.

by Zach Pfeffer

Paul, I was wondering if we could make a small change to android-build. I just recently tested: https://android-build.linaro.org/builds/~linaro-android/leb-panda/#build=166 It works great and I'd like to move it to a first 11.08 release. Its based on toolchain: https://android-build.linaro.org/jenkins/job/linaro-android_toolchain-4.6-2… I'd like to simply mark this build as "releasable" and have it save the toolchain and commit the pinned-manifest.xml to 11.08. Any thoughts? -Zach

13 years, 4 months

[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");

13 years, 4 months

[ANN] Linaro Android tree hosting switched to Gerrit

by Paul Sokolovsky

[originally sent from wrong email, so not sure if got thru] Hello, Linaro Android codebase migration to Gerrit, which was announced at Linaro Connect, happened today. From now, Linaro Android is available via: http://android.git.linaro.org/ Accompanied by Gerrit frontend at: http://review.android.git.linaro.org/ It is recommended to perform a fresh checkout of the tree. To do that, run: repo init -u git://android.git.linaro.org/platform/manifest.git \ -b <branch> \ -m <manifest> <branch> and <manifest> are those you used before. E.g. repo init -u git://android.git.linaro.org/platform/manifest.git \ -b linaro_android_2.3.4 \ -m default.xml The official Linaro builds at https://android-build.linaro.org/ were converted to use new manifest location, and I'd like to ask other developers to convert their personal builds (I'm not trying to automate this so far, to make that everyone was in loop on what changed and how). To update, just change in a build config: MANIFEST_REPO=git://git.linaro.org/android/platform/manifest.git to MANIFEST_REPO=git://android.git.linaro.org/platform/manifest.git Old tree (git.linaro.org/android/*) was made inaccessible for the time being to help with updating all references to it. It should be back up shortly in read-only mode. (If there're immediate concerns, it's at git.linaro.org/android-old/ now and can be renamed back by anyone with git.linaro.org access). With the spirit of making one change at time, all developers still should have permissions similar to what they had before: anyone can still create branches and push changes directly to them (*1). However, once we finish updating build configs and docs for new tree location, the next step will be setting up a workflow based on mandatory code review, so I'd like to invite all developers to practice that right away. Details on how to submit change for review are given at https://wiki.linaro.org/Platform/Android/Gerrit (in particular, repo upload works now). (*1) The remote for such commits is different now of course, like this: ssh://pfalcon@android.git.linaro.org:29418/platform/build . Replace "pfalcon" with you gerrit username and platform/build is the component you need. Please share any issues, concerns, and questions you may have related to this migration. -- Best Regards, Paul Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

13 years, 4 months

Re: trouble with should-be-bootable SD cards and kernel versions

by AJ ONeal

> > Were you using Linaro-media-create to put things onto the SD card or > some other route? > > Yes. created the master card using `linaro-media-create` booted it once and added some secret sauce to it. duplicated that card to 20 cards using `sfdisk` and `partimage`. (Half of those cards did not boot) used `gparted` to create a new partition table on one of the failed cards (the new second master) used `rsync` to copy the contents of the first master to a second master reran the duplication process repeated the step above for the remaining failed cards ended up with 3 master cards with the exact same filesystem contents and very nearly identical partition tables, but different disk geometries (head, cyl, sector). AJ ONeal On Wed, Jun 29, 2011 at 12:48 PM, AJ ONeal <coolaj86(a)gmail.com> wrote: > > I have a few inter-related issues: > > > > Why would one kernel boot a card that another kernel can't? > > Why would a card's disk geometry matter for boot? > > Who is a good manufacturer for getting hardware-identical cards in bulk? > > How can I probe the actual "disk geometry" of an sd card? > > > > I bought 100 Transcend SD cards a little while ago and duplicated them > with > > an OpenEmbedded-based filesystem (linux-2.6.36). > > There were a few "bad" cards that I threw out, but the success rate was > > acceptable. > > > > In the next round of 40 SD cards I used a Linaro-based filesystem > > (linux-2.6.39) and had about a 50% failure rate when testing that the > cards > > would boot, which is absurd. > > There kernel reports: [ 1.003204] mmcblk0: unknown partition table > > However, the cards would mount and show files just fine. > > I reduplicated one of the non-booting cards with an OpenEmbedded > filesystem > > and then it booted. Weird! > > > > After some investigation I found that using `gparted` (instead of > `fdisk`) > > to create a new partition table and then `rsync`ing the contents of the > > original filesystem resulted in a booting Linaro card. > > Rinse and repeat and I ended up with 3 images which only vary by the disk > > geometry as reported by `fdisk -l`: > > > > 50% -- 255 heads, 63 sectors/track, 974 cylinders > > 40% -- 2 heads, 4 sectors/track, 1957632 cylinders > > 10% -- 247 heads, 62 sectors/track, 1022 cylinders > > 1 card still didn't boot > > > > I'm lost. Please advise. > > AJ ONeal > > > > > > > > Non-booting kernel message > > [ 0.923309] Waiting for root device /dev/mmcblk0p2... > > [ 0.957885] mmc0: host does not support reading read-only switch. > > assuming write-enable. > > [ 0.982025] mmc0: new high speed SDHC card at address b368 > > [ 0.988494] mmcblk0: mmc0:b368 USD 7.46 GiB > > [ 0.993957] mmcblk0: detected capacity change from 0 to 8018460672 > > [ 1.003204] mmcblk0: unknown partition table > > [ 1.036926] VFS: Cannot open root device "mmcblk0p2" or > > unknown-block(179,2) > > [ 1.044433] Please append a correct "root=" boot option; here are the > > available partitions: > > [ 1.053344] b300 7830528 mmcblk0 driver: mmcblk > > [ 1.058959] Kernel panic - not syncing: VFS: Unable to mount root fs > on > > unknown-block(179,2) > > > > Booting kernel message > > [ 1.122070] mmc0: host does not support reading read-only switch. > > assuming write-enable. > > [ 1.146087] mmc0: new high speed SDHC card at address b368 > > [ 1.152557] mmcblk0: mmc0:b368 USD 7.46 GiB > > [ 1.158020] mmcblk0: detected capacity change from 0 to 8018460672 > > [ 1.166351] mmcblk0: p1 p2 p3 > > [ 1.259674] EXT3-fs: barriers not enabled > > [ 1.265411] kjournald starting. Commit interval 5 seconds > > [ 1.271331] EXT3-fs (mmcblk0p2): mounted filesystem with ordered data > > mode > > [ 1.278686] VFS: Mounted root (ext3 filesystem) readonly on device > 179:2. > > _______________________________________________ > > linaro-dev mailing list > > linaro-dev(a)lists.linaro.org > > http://lists.linaro.org/mailman/listinfo/linaro-dev > > > > > > > > -- > 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, 4 months

[PATCH] ARM: EXYNOS4: Enable MFC on Samsung SMDKV310

by Sachin Kamat

Signed-off-by: Sachin Kamat <sachin.kamat(a)linaro.org> --- This patch is based on Kukjin's for-arm-soc branch. arch/arm/mach-exynos4/Kconfig | 1 + arch/arm/mach-exynos4/mach-smdkv310.c | 11 +++++++++++ 2 files changed, 12 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig index 9d62e13..8da2960 100644 --- a/arch/arm/mach-exynos4/Kconfig +++ b/arch/arm/mach-exynos4/Kconfig @@ -139,6 +139,7 @@ config MACH_SMDKV310 select S3C_DEV_RTC select S3C_DEV_WDT select S3C_DEV_I2C1 + select S5P_DEV_MFC select S3C_DEV_HSMMC select S3C_DEV_HSMMC1 select S3C_DEV_HSMMC2 diff --git a/arch/arm/mach-exynos4/mach-smdkv310.c b/arch/arm/mach-exynos4/mach-smdkv310.c index ea41495..2a128f4 100644 --- a/arch/arm/mach-exynos4/mach-smdkv310.c +++ b/arch/arm/mach-exynos4/mach-smdkv310.c @@ -32,6 +32,7 @@ #include <plat/pd.h> #include <plat/gpio-cfg.h> #include <plat/backlight.h> +#include <plat/mfc.h> #include <mach/map.h> @@ -177,6 +178,9 @@ static struct platform_device *smdkv310_devices[] __initdata = { &exynos4_device_ac97, &exynos4_device_i2s0, &samsung_device_keypad, + &s5p_device_mfc, + &s5p_device_mfc_l, + &s5p_device_mfc_r, &exynos4_device_pd[PD_MFC], &exynos4_device_pd[PD_G3D], &exynos4_device_pd[PD_LCD0], @@ -233,6 +237,11 @@ static void __init smdkv310_map_io(void) s3c24xx_init_uarts(smdkv310_uartcfgs, ARRAY_SIZE(smdkv310_uartcfgs)); } +static void __init smdkv310_reserve(void) +{ + s5p_mfc_reserve_mem(0x43000000, 8 << 20, 0x51000000, 8 << 20); +} + static void __init smdkv310_machine_init(void) { s3c_i2c1_set_platdata(NULL); @@ -250,6 +259,7 @@ static void __init smdkv310_machine_init(void) samsung_bl_set(&smdkv310_bl_gpio_info, &smdkv310_bl_data); platform_add_devices(smdkv310_devices, ARRAY_SIZE(smdkv310_devices)); + s5p_device_mfc.dev.parent = &exynos4_device_pd[PD_MFC].dev; } MACHINE_START(SMDKV310, "SMDKV310") @@ -260,4 +270,5 @@ MACHINE_START(SMDKV310, "SMDKV310") .map_io = smdkv310_map_io, .init_machine = smdkv310_machine_init, .timer = &exynos4_timer, + .reserve = &smdkv310_reserve, MACHINE_END -- 1.7.4.1

13 years, 4 months

← Newer
1
...
16
17
18
19
20
21
22
23
24
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev August 2011