linaro-dev

linaro-dev@lists.linaro.org

4332 discussions

[PATCH 0/2] video: Make omap2 support conditional

by Tushar Behera

Currently drivers/video/omap2 is built by default with every configuration of the kernel. Current patchset makes the omap2 video support conditional on appropriate config option. [Patch 2/2] was first generated, but that resulted in a build error. [Patch 1/2] was created to fix that build error. These patches have only been tested for build consistency and have not been tested on any related hardware. Tushar Behera (2): config: omap2+: force fb and dss support as built-in video: omap2: Compile omap2 support only when needed arch/arm/configs/omap2plus_defconfig | 4 ++-- drivers/video/Makefile | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) -- 1.7.4.1

13 years, 11 months

[powerdebug 01/17] add a real mainloop

by Daniel Lezcano

Add a mainloop code with registering of the callbacks and co. Signed-off-by: Daniel Lezcano <daniel.lezcano(a)linaro.org> --- Makefile | 3 +- mainloop.c | 122 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ mainloop.h | 22 +++++++++++ 3 files changed, 146 insertions(+), 1 deletions(-) create mode 100644 mainloop.c create mode 100644 mainloop.h diff --git a/Makefile b/Makefile index 1a53121..8d41b24 100644 --- a/Makefile +++ b/Makefile @@ -4,7 +4,8 @@ MANDIR=/usr/share/man/man8 CFLAGS?=-O1 -g -Wall -Wshadow CC?=gcc -OBJS = powerdebug.o sensor.o clocks.o regulator.o display.o tree.o utils.o +OBJS = powerdebug.o sensor.o clocks.o regulator.o \ + display.o tree.o utils.o mainloop.o default: powerdebug diff --git a/mainloop.c b/mainloop.c new file mode 100644 index 0000000..d63d703 --- /dev/null +++ b/mainloop.c @@ -0,0 +1,122 @@ +/******************************************************************************* + * Copyright (C) 2010, Linaro Limited. + * + * This file is part of PowerDebug. + * + * All rights reserved. This program and the accompanying materials + * are made available under the terms of the Eclipse Public License v1.0 + * which accompanies this distribution, and is available at + * http://www.eclipse.org/legal/epl-v10.html + * + * Author: + * Daniel Lezcano <daniel.lezcano(a)linaro.org> + * + *******************************************************************************/ + +#include <stdlib.h> +#include <errno.h> +#include <unistd.h> +#include <sys/epoll.h> +#include "mainloop.h" + +static int epfd = -1; +static unsigned short nrhandler; + +struct mainloop_data { + mainloop_callback_t cb; + void *data; + int fd; +}; + +struct mainloop_data **mds; + +#define MAX_EVENTS 10 + +int _mainloop(unsigned int timeout) +{ + int i, nfds; + struct epoll_event events[MAX_EVENTS]; + struct mainloop_data *md; + + if (epfd < 0) + return -1; + + for (;;) { + + nfds = epoll_wait(epfd, events, MAX_EVENTS, timeout); + if (nfds < 0) { + if (errno == EINTR) + continue; + return -1; + } + + for (i = 0; i < nfds; i++) { + md = events[i].data.ptr; + + if (md->cb(md->fd, md->data) > 0) + return 0; + } + + } +} + +int mainloop_add(int fd, mainloop_callback_t cb, void *data) +{ + struct epoll_event ev = { + .events = EPOLLIN, + }; + + struct mainloop_data *md; + + if (fd >= nrhandler) { + mds = realloc(mds, sizeof(*mds) * (fd + 1)); + if (!mds) + return -1; + nrhandler = fd + 1; + } + + md = malloc(sizeof(*md)); + if (!md) + return -1; + + md->data = data; + md->cb = cb; + md->fd = fd; + + mds[fd] = md; + ev.data.ptr = md; + + if (epoll_ctl(epfd, EPOLL_CTL_ADD, fd, &ev) < 0) { + free(md); + return -1; + } + + return 0; +} + +int mainloop_del(int fd) +{ + if (fd >= nrhandler) + return -1; + + if (epoll_ctl(epfd, EPOLL_CTL_DEL, fd, NULL) < 0) + return -1; + + free(mds[fd]); + + return 0; +} + +int mainloop_init(void) +{ + epfd = epoll_create(2); + if (epfd < 0) + return -1; + + return 0; +} + +void mainloop_fini(void) +{ + close(epfd); +} diff --git a/mainloop.h b/mainloop.h new file mode 100644 index 0000000..3b4c253 --- /dev/null +++ b/mainloop.h @@ -0,0 +1,22 @@ +/******************************************************************************* + * Copyright (C) 2010, Linaro Limited. + * + * This file is part of PowerDebug. + * + * All rights reserved. This program and the accompanying materials + * are made available under the terms of the Eclipse Public License v1.0 + * which accompanies this distribution, and is available at + * http://www.eclipse.org/legal/epl-v10.html + * + * Author: + * Daniel Lezcano <daniel.lezcano(a)linaro.org> + * + *******************************************************************************/ + +typedef int (*mainloop_callback_t)(int fd, void *data); + +extern int _mainloop(unsigned int timeout); +extern int mainloop_add(int fd, mainloop_callback_t cb, void *data); +extern int mainloop_del(int fd); +extern int mainloop_init(void); +extern void mainloop_fini(void); -- 1.7.1

13 years, 11 months

[ACTIVITY] Multimedia status - 20110613-20110617

by Ilias Biris

A bit delayed report, but nevertheless I hope it is useful: Links: Weekly meetings (IRC logs) TUE: https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/Notes/2011-06-14 THU: http://salemcenter.dyndns.org/~fboudra/linarobot/linaro-multimedia/2011/lin… Status link is : https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/Status/2011-06-… Highlights: * 11.06 release: libjpeg-turbo release activity ongoing - libjpeg-turbo and the new patches applied from android work. * Going through past TRs which are not closed in order to reframe their scope within the 11.11 cycle. Definition of TRs for 11.11 public plan review, identification of engineering (work) blueprints and specs. Team to populate the specifications. Priority given to o openmax (krtaylor - to identify the Khronos representatives for the survey, and to set up call with Jim and Thierry to define OpenMAX colaboration model) as well as all member company reps from MMWG need to find their OMX IL code and share o memory management - robclark and benjiG to prioritize Mem Mgmt actions from summit * Then priority work involves o Audio - start looking at ASoC and UCM - specifically at the panda UCM definitions o Codecs, libjpeg-turbo work o NEON optimization forum: identify some topic areas and work with kiko and krtaylor to help kick off NEON optimization forum * Team wiki redesigned. Notable additions: glossary section - get your self acquainted with multimedia lingo! Upcoming Deliverables * Draft for the public plan review * TRs for the perusal of the team * 11.06 release for the libjpeg-turbo work BR, -- Ilias Biris, Aallonkohina 2D 19, 02320 Espoo, Finland Tel: +358 50 4839608 (mobile) Email: ilias dot biris at linaro dot org Skype: ilias_biris

13 years, 11 months

[GIT PULL] fix for bug 754254

by Shawn Guo

Hi Nicolas, Could you pull the fix for [Bug 754254] imx51 randomly truncates serial input at 31 characters? It extends the card CD/WP support for mx5 platforms, and adds the board level configuration for mx51evk to fix bug 754254 on this particular board. Other boards need to add their board level configuration to actually enable the support. The following changes since commit dcd71f6729fbee40d28a99cb645c979c3db7b545 ARM: footbridge: fix clock event support are available in the git repository at: git://git.linaro.org/people/shawnguo/linux-2.6.git fix-754254 Chris Ball (2): mmc: Replace SDHCI_QUIRK_FORCE_BLK_SZ_2048 with a platform hook. mmc: Replace SDHCI_QUIRK_NO_MULTIBLOCK with a platform hook. Shawn Guo (9): mmc: sdhci: make sdhci-pltfm device drivers self registered mmc: sdhci: eliminate sdhci_of_host and sdhci_of_data mmc: sdhci: make sdhci-of device drivers self registered mmc: sdhci: merge two sdhci-pltfm.h into one mmc: sdhci: change sdhci-pltfm into a module * mmc: sdhci: fix interrupt storm from card detection * mmc: sdhci-esdhc-imx: SDHCI_CARD_PRESENT does not get cleared * mmc: sdhci-esdhc-imx: remove "WP" from flag ESDHC_FLAG_GPIO_FOR_CD_WP * mmc: sdhci-esdhc-imx: extend card_detect and write_protect support for mx5 [ The last four patches marked with '*' are the actual fixing, and the others are prerequisite patches from mmc-next tree. ] arch/arm/mach-imx/eukrea_mbimxsd25-baseboard.c | 3 +- arch/arm/mach-imx/eukrea_mbimxsd35-baseboard.c | 3 +- arch/arm/mach-imx/mach-mx25_3ds.c | 2 + arch/arm/mach-imx/mach-pcm043.c | 2 + arch/arm/mach-mx5/board-mx51_babbage.c | 24 ++- .../plat-mxc/devices/platform-sdhci-esdhc-imx.c | 12 + arch/arm/plat-mxc/include/mach/esdhc.h | 25 ++- drivers/mmc/host/Kconfig | 49 ++-- drivers/mmc/host/Makefile | 18 +- drivers/mmc/host/sdhci-cns3xxx.c | 44 ++++- drivers/mmc/host/sdhci-dove.c | 43 ++++- drivers/mmc/host/sdhci-esdhc-imx.c | 218 ++++++++++++----- drivers/mmc/host/sdhci-esdhc.h | 3 +- drivers/mmc/host/sdhci-of-core.c | 253 -------------------- drivers/mmc/host/sdhci-of-esdhc.c | 93 ++++++-- drivers/mmc/host/sdhci-of-hlwd.c | 67 +++++- drivers/mmc/host/sdhci-of.h | 42 ---- drivers/mmc/host/sdhci-pltfm.c | 216 ++++++++--------- drivers/mmc/host/sdhci-pltfm.h | 90 +++++++- drivers/mmc/host/sdhci-tegra.c | 117 +++++++--- drivers/mmc/host/sdhci.c | 32 ++- drivers/mmc/host/sdhci.h | 2 + include/linux/mmc/sdhci-pltfm.h | 35 --- include/linux/mmc/sdhci.h | 8 +- 24 files changed, 763 insertions(+), 638 deletions(-)

13 years, 11 months

Re: [PATCHv3 5/11 ] Regulator: Fixed DA9052 _sel() functions

by Mark Brown

On Mon, Jun 20, 2011 at 05:33:12PM +0530, ashishj3 wrote: > --- a/drivers/regulator/da9052-regulator.c > +++ b/drivers/regulator/da9052-regulator.c > @@ -24,7 +24,7 @@ > #include <linux/mfd/da9052/reg.h> > #include <linux/mfd/da9052/pdata.h> > > -/* Buck step size Macros */ > +/* Buck step size */ > #define DA9052_BUCK_PERI_3uV_STEP 100000 > #define DA9052_BUCK_PERI_REG_MAP_UPTO_3uV 24 > #define DA9052_CONST_3uV 3000000 This appears to be an incremental patch against some previous version of the driver. Since this driver is not yet part of Linux you need to send it as a new patch, as a result I've not read the rest of the patch and must once more urge you to read and follow the instructions in SubmittingPatches. Given the very substantial problems that this process appears to be causing you I strongly urge you to accept the offers of help that the Linaro team have made recently.

13 years, 11 months

[ACTIVITY] Graphics WG status - 20110613-20110617

by Ilias Biris

Meeting minutes https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/Notes/2011-06-15 Status summary https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/Status/2011-06-15 Highlights: * Unity/NUX: getting along pretty good. Sorted out the GL errors experienced before. Working now on bug https://bugs.launchpad.net/unity-gles/+bug/798829. Jesse will setup a meeting with Jay Taoko for NUX (where we are and what happens next, syncup type of meeting). Other issue still happening is blend not working properly - Travis has a workaround. Also a nice to have would be the build system for unity to turn GLES on/off as necessary. * discussed the code freeze prior to the milestone release: a maturization period may be needed, but the duration needs to be checked project by project. Certainly not all components need a week of freeze. * Also discussed: the location of our releases was discussed: tarball or debian packages. Debian packages in fact need a tarball as starting point. Absences this running week: Sumit will be on training 23-28 June Ilias will be on vac on Friday June 24 -- Ilias Biris, Aallonkohina 2D 19, 02320 Espoo, Finland Tel: +358 50 4839608 (mobile) Email: ilias dot biris at linaro dot org Skype: ilias_biris

13 years, 11 months

Getting rid of alignment faults in userspace

by Dave Martin

Hi all, I've recently become aware that a few packages are causing alignment faults on ARM, and are relying on the alignment fixup emulation code in the kernel in order to work. Such faults are very expensive in terms of CPU cycles, and can generally only result from wrong code (for example, C/C++ code which violates the relevant language standards, assembler which makes invalid assumptions, or functions called with misaligned pointers due to other bugs). Currently, on a natty Ubuntu desktop image I observe no faults except from firefox and mono-based apps (see below). As part of the general effort to make open source on ARM better, I think it would be great if we can disable the alignment fixups (or at least enable logging) and work with upstreams to get the affected packages fixed. For release images we might want to be more forgiving, but for development we have the option of being more aggressive. The number of affected packages and bugs appears small enough for the fixing effort to be feasible, without temporarily breaking whole distros. For ARM, we can achieve the goal by augmenting the default kernel command- line options: either alignment=3 Fix up each alingment fault, but also log the faulting address and name of the offending process to dmesg. alignment=5 Pass each alignment fault to the user process as SIGBUS (fatal by default) and log the faulting address and name of the offending process to dmesg. Fault statistics cat also be obtained at runtime by reading /proc/cpu/alignment. For other architectures, there may be other arch-specific ways of achieving something similar. I'd be interested in people's views on this. Cheers ---Dave More background: Two known instances of misbehaving userland apps are: 1) firefox-4.x (bug report pending) A char array declared as a container for C++ objects is cast directly to an object pointer type and deferenced, without ensuring proper alignment. By sheer luck, the presence of an extra member in the containing class in firefox-3.x means that the char array has a different alignment and so the faults don't occur. 2) gtk-sharp2 (https://bugs.launchpad.net/bugs/798315) (affecting mono-based GUI apps such as banshee and tomboy) char pointers are cast to 64-bit integer pointers and deferenced, as an attempt at comparing string prefixes faster. These apps typically generate hundreds or thousands of faults per session, but not millions, but it's still quite a lot of noise in syslog. I think these are likely to be representative of typical causes of alignment faults: i.e., attempted optimisations which break the rules of the language, and which only show in certain builds, or as side-effects of routine maintenance. Code like that is going to be a massive own goal for performance on ARM and other architectures which fault unaligned accesses, since the resulting faults are likely to cost thousands of cycles per instance.

13 years, 11 months

I'm unable to connect to IRC (xchat-gnome crashes)

by Zygmunt Krynicki

Hi everyone. I'm online but my xchat-gnome is crashing on startup. I'm trying to figure out what might be causing this. zyga@W510:~$ gdb xchat-gnome GNU gdb (Ubuntu/Linaro 7.2-1ubuntu11) 7.2 Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /usr/bin/xchat-gnome...(no debugging symbols found)...done. (gdb) r Starting program: /usr/bin/xchat-gnome [Thread debugging using libthread_db enabled] [New Thread 0x7fffed6fe700 (LWP 5355)] [New Thread 0x7fffe2f8f700 (LWP 5356)] XChat CRITICAL *** default event text failed to build! Program received signal SIGABRT, Aborted. 0x00007ffff3f65d05 in raise () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) bt #0 0x00007ffff3f65d05 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007ffff3f69ab6 in abort () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x000000000045cfc0 in pevent_make_pntevts () #3 0x0000000000460a0f in ?? () #4 0x0000000000461535 in main () (gdb) Best regards ZK

13 years, 11 months

[PATCH RESEND] omap_hsmmc: use original sg_len for dma_unmap_sg

by Per Forlin

Don't use the returned sg_len from dma_map_sg() as inparameter to dma_unmap_sg(). Use the original sg_len for both dma_map_sg and dma_unmap_sg according to the documentation in DMA-API.txt. Signed-off-by: Per Forlin <per.forlin(a)linaro.org> Reviewed-by: Venkatraman S <svenkatr(a)ti.com> --- drivers/mmc/host/omap_hsmmc.c | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index 259ece0..ad3731a 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -959,7 +959,8 @@ static void omap_hsmmc_dma_cleanup(struct omap_hsmmc_host *host, int errno) spin_unlock(&host->irq_lock); if (host->use_dma && dma_ch != -1) { - dma_unmap_sg(mmc_dev(host->mmc), host->data->sg, host->dma_len, + dma_unmap_sg(mmc_dev(host->mmc), host->data->sg, + host->data->sg_len, omap_hsmmc_get_dma_dir(host, host->data)); omap_free_dma(dma_ch); } @@ -1343,7 +1344,7 @@ static void omap_hsmmc_dma_cb(int lch, u16 ch_status, void *cb_data) return; } - dma_unmap_sg(mmc_dev(host->mmc), data->sg, host->dma_len, + dma_unmap_sg(mmc_dev(host->mmc), data->sg, data->sg_len, omap_hsmmc_get_dma_dir(host, data)); req_in_progress = host->req_in_progress; -- 1.7.4.1

13 years, 11 months

[PATCH v5 00/12] mmc: use nonblock mmc requests to minimize latency

by Per Forlin

How significant is the cache maintenance over head? It depends, the eMMC are much faster now compared to a few years ago and cache maintenance cost more due to multiple cache levels and speculative cache pre-fetch. In relation the cost for handling the caches have increased and is now a bottle neck dealing with fast eMMC together with DMA. The intention for introducing none blocking mmc requests is to minimize the time between a mmc request ends and another mmc request starts. In the current implementation the MMC controller is idle when dma_map_sg and dma_unmap_sg is processing. Introducing none blocking mmc request makes it possible to prepare the caches for next job parallel with an active mmc request. This is done by making the issue_rw_rq() none blocking. The increase in throughput is proportional to the time it takes to prepare (major part of preparations is 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. Measurements on U5500 and Panda on eMMC and SD shows significant performance gain for large reads when running DMA mode. In the PIO case the performance is unchanged. 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. Details on measurements from IOZone and mmc_test: https://wiki.linaro.org/WorkingGroups/Kernel/Specs/StoragePerfMMC-async-req Changes since v4: * rebase on top of linux 3.0 Per Forlin (12): mmc: add none blocking mmc request function omap_hsmmc: use original sg_len for dma_unmap_sg omap_hsmmc: add support for pre_req and post_req mmci: implement pre_req() and post_req() mmc: mmc_test: add debugfs file to list all tests mmc: mmc_test: add test for none blocking transfers mmc: add member in mmc queue struct to hold request data mmc: add a block request prepare function mmc: move error code in mmc_block_issue_rw_rq to a separate function. mmc: add a second mmc queue request member mmc: test: add random fault injection in core.c mmc: add handling for two parallel block requests in issue_rw_rq drivers/mmc/card/block.c | 534 ++++++++++++++++++++++++----------------- drivers/mmc/card/mmc_test.c | 361 +++++++++++++++++++++++++++- drivers/mmc/card/queue.c | 184 +++++++++----- drivers/mmc/card/queue.h | 33 ++- drivers/mmc/core/core.c | 165 ++++++++++++- drivers/mmc/core/debugfs.c | 5 + drivers/mmc/host/mmci.c | 146 ++++++++++- drivers/mmc/host/mmci.h | 8 + drivers/mmc/host/omap_hsmmc.c | 90 +++++++- include/linux/mmc/core.h | 6 +- include/linux/mmc/host.h | 24 ++ lib/Kconfig.debug | 11 + 12 files changed, 1237 insertions(+), 330 deletions(-) -- 1.7.4.1

13 years, 11 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev