linaro-dev

linaro-dev@lists.linaro.org

4332 discussions

RFC: ARM: Support for VFP/NEON registers in coredumps

by Dave Martin

Hi all, Considering how to add the VFP/NEON register state to Coredumps, there's no single obvious solution, so I'd like to put this out for people's comments. Currently, the coredump consists of several notes, the interesting ones currently being: * NT_PRSTATUS - general process status, including the integer registers * NT_FPREGSET - the FPA registers (only present if FPA is in use) These notes are duplicated per thread when a multithreaded process dumps core. There are few options I see: a) Dump the VFP/NEON state in NT_FPREGSET. This could be appended to, or in place of the legacy FPA regs, with flags in a header or (struct elf_prstatus).pr_fpvalid to describe what was dumped. Old gdb etc. may read the resulting information as random FPA register contents; this could perhaps be avoided by always dumping a dummy FPA regs structure at the start of this note, though this seems wasteful. Possibly, gdb may explode if the NT_FPREGSET note is larger then expected. I've not investigated this. b) Dump the VFP/NEON regs in a note of type NT_PRXFPREG. This avoids defining a new note type; however, this note type is really for x86 -- so overloading it in this way may just be nonsensical / confusing. c) Create a new note type specially for this, and dump the VFP/NEON regs in there. This is closest to the model followed by ptrace, where PTRACE_GETREGS, PTRACE_GETFPREGS and PTRAGE_GETVFPREGS are all distinct. Going for (c) seems sanest to me, and also means that old gdb will just ignore the new data; this is probably what we want. Comments are welcome. Cheers ---Dave

14 years, 1 month

[PATCH 0/5] make sdhci device drivers self registered

by Shawn Guo

This patch set is to take sdhci device driver specific things out from sdhci-pltfm.c and make them self registered. Here are the differences it makes. * Get the sdhci device driver follow the Linux trend that driver take the registration by its own * sdhci-pltfm.c becomes significantly simpler and only has common support functions there * All sdhci device specific stuff are going back its own driver * The dt and non-dt support share the same pair of .probe and .remove hooks. The first one patch adds common support function into sdhci-pltfm.c when changing sdhci-esdhc-imx driver, while the last one cleans up sdhci-pltfm.c when changing sdhci-tegra driver. Only the patch of sdhci-esdhc-imx are tested on hardware, and others are just build tested. And it is based on the tree below. git://git.secretlab.ca/git/linux-2.6.git devicetree/test Comments are welcomed and appreciated. Regards, Shawn Shawn Guo (5): mmc: sdhci: make sdhci-esdhc-imx driver self registered mmc: sdhci: make sdhci-cns3xxx driver self registered mmc: sdhci: make sdhci-dove driver self registered mmc: sdhci: make sdhci-tegra driver self registered mmc: sdhci: update Makefile/Kconfig for sdhci_pltfm change drivers/mmc/host/Kconfig | 24 +++-- drivers/mmc/host/Makefile | 11 +- drivers/mmc/host/sdhci-cns3xxx.c | 68 +++++++++++++- drivers/mmc/host/sdhci-dove.c | 70 +++++++++++++- drivers/mmc/host/sdhci-esdhc-imx.c | 98 +++++++++++++++---- drivers/mmc/host/sdhci-pltfm.c | 165 ++----------------------------- drivers/mmc/host/sdhci-pltfm.h | 14 ++- drivers/mmc/host/sdhci-tegra.c | 189 +++++++++++++++++++++---------------

14 years, 1 month

Re: [powerdebug V2: 01/14] encapsulate the options code

by Amit Kucheria

Re'adding linaro-dev On 11 Mar 25, Yong Shen wrote: > On Fri, Mar 25, 2011 at 2:48 PM, Amit Kucheria <amit.kucheria(a)linaro.org>wrote: > > > On Fri, Mar 25, 2011 at 4:10 AM, Yong Shen <yong.shen(a)linaro.org> wrote: > > > > > Hi Daniel, > > > Yes. I had started the work for several days. > > > Previously, every time when clock info is refreshed, the data structure > > will > > > be reallocated as if it is the first time of building up clock info. The > > > goal is only allocating memory once, which means less system call made by > > > malloc and also reducing potential memory fragment. > > > I am coding and debuging right now, hoping it comes out soon. > > > Yong > > > > So as to avoid the (inevitable) conflicts, may I propose that I first > > apply Yong's patch sent last week to add inotify support. It is not a > > very invasive patch. > > > No, Amit, no need apply the patch I post last time. It will be involved in > my coming patch(s) Ahh, ok. I was just about to start fixing up your patch to apply after Daniel's changes. > > > > Yong, for the mem allocation work, perhaps it is best if we wait for > > Daniel to send his latest series and work on top of that. > > > No problem for me. Alright. So let's wait a day or so for Daniel to post his series and review it. /Amit

14 years, 1 month

[PATCH] ARM: EXYNOS4: Fix addruart macro

by Thomas Abraham

Fix incorrect conditional execution of ldr instructions in addruart macro. Signed-off-by: Thomas Abraham <thomas.abraham(a)samsung.com> Signed-off-by: Abhilash Kesavan <a.kesavan(a)samsung.com> --- arch/arm/mach-exynos4/include/mach/debug-macro.S | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-exynos4/include/mach/debug-macro.S b/arch/arm/mach-exynos4/include/mach/debug-macro.S index 58bbd04..a442ef8 100644 --- a/arch/arm/mach-exynos4/include/mach/debug-macro.S +++ b/arch/arm/mach-exynos4/include/mach/debug-macro.S @@ -21,8 +21,8 @@ */ .macro addruart, rp, rv - ldreq \rp, = S3C_PA_UART - ldrne \rv, = S3C_VA_UART + ldr \rp, = S3C_PA_UART + ldr \rv, = S3C_VA_UART #if CONFIG_DEBUG_S3C_UART != 0 add \rp, \rp, #(0x10000 * CONFIG_DEBUG_S3C_UART) add \rv, \rv, #(0x10000 * CONFIG_DEBUG_S3C_UART) -- 1.6.6.rc2

14 years, 1 month

[powerdebug V2: 01/14] encapsulate the options code

by Daniel Lezcano

Create a single structure for powerdebug options. Signed-off-by: Daniel Lezcano <daniel.lezcano(a)free.fr> --- powerdebug.c | 173 +++++++++++++++++++++++++++++++++------------------------- 1 files changed, 98 insertions(+), 75 deletions(-) diff --git a/powerdebug.c b/powerdebug.c index 3f4d60c..efdb1a2 100644 --- a/powerdebug.c +++ b/powerdebug.c @@ -19,7 +19,6 @@ int dump; int highlighted_row; int selectedwindow = -1; -double ticktime = 10.0; /* in seconds */ char *win_names[TOTAL_FEATURE_WINS] = { "Clocks", @@ -45,119 +44,143 @@ void usage(void) " -s)\n"); printf(" -V, --version Show Version\n"); printf(" -h, --help Help\n"); - - exit(0); } void version() { printf("powerdebug version %s\n", VERSION); - exit(0); } -int main(int argc, char **argv) -{ - int c, i; - int firsttime[TOTAL_FEATURE_WINS]; - int enter_hit = 0, verbose = 0, findparent_ncurses = 0, refreshwin = 0; - int regulators = 0, sensors = 0, clocks = 0, findparent = 0; - char clkarg[64], clkname_str[64]; +/* + * Options: + * -r, --regulator : regulator + * -s, --sensor : sensors + * -c, --clock : clocks + * -p, --findparents : clockname whose parents have to be found + * -t, --time : ticktime + * -d, --dump : dump + * -v, --verbose : verbose + * -V, --version : version + * -h, --help : help + * no option / default : show usage! + */ + +static struct option long_options[] = { + { "regulator", 0, 0, 'r' }, + { "sensor", 0, 0, 's' }, + { "clock", 0, 0, 'c' }, + { "findparents", 1, 0, 'p' }, + { "time", 1, 0, 't' }, + { "dump", 0, 0, 'd' }, + { "verbose", 0, 0, 'v' }, + { "version", 0, 0, 'V' }, + { "help", 0, 0, 'h' }, + { 0, 0, 0, 0 } +}; - for (i = 0; i < TOTAL_FEATURE_WINS; i++) - firsttime[i] = 1; +struct powerdebug_options { + int findparent; + int verbose; + int regulators; + int sensors; + int clocks; + int ticktime; + char clkarg[64]; +}; + +int getoptions(int argc, char *argv[], struct powerdebug_options *options) +{ + int c; - /* - * Options: - * -r, --regulator : regulator - * -s, --sensor : sensors - * -c, --clock : clocks - * -p, --findparents : clockname whose parents have to be found - * -t, --time : ticktime - * -d, --dump : dump - * -v, --verbose : verbose - * -V, --version : version - * -h, --help : help - * no option / default : show usage! - */ + memset(options, 0, sizeof(*options)); + options->ticktime = 10; while (1) { int optindex = 0; - static struct option long_options[] = { - {"regulator", 0, 0, 'r'}, - {"sensor", 0, 0, 's'}, - {"clock", 0, 0, 'c'}, - {"findparents", 1, 0, 'p'}, - {"time", 1, 0, 't'}, - {"dump", 0, 0, 'd'}, - {"verbose", 0, 0, 'v'}, - {"version", 0, 0, 'V'}, - {"help", 0, 0, 'h'}, - {0, 0, 0, 0} - }; - - c = getopt_long(argc, argv, "rscp:t:dvVh", long_options, &optindex); + + c = getopt_long(argc, argv, "rscp:t:dvVh", + long_options, &optindex); if (c == -1) break; switch (c) { case 'r': - regulators = 1; + options->regulators = 1; selectedwindow = REGULATOR; break; case 's': - sensors = 1; + options->sensors = 1; selectedwindow = SENSOR; break; case 'c': - clocks = 1; + options->clocks = 1; selectedwindow = CLOCK; break; case 'p': - findparent = 1; - strcpy(clkarg, optarg); + options->findparent = 1; + strcpy(options->clkarg, optarg); break; case 't': - ticktime = strtod(optarg, NULL); + options->ticktime = strtod(optarg, NULL); break; case 'd': dump = 1; break; case 'v': - verbose = 1; + options->verbose = 1; break; case 'V': version(); break; - case 'h': - usage(); - break; case '?': - fprintf (stderr, "%s: Unknown option %c'.\n", + fprintf(stderr, "%s: Unknown option %c'.\n", argv[0], optopt); - exit(1); default: - usage(); - break; + return -1; } } - if (dump && !(regulators || clocks || sensors)) { - //fprintf(stderr, "Dump mode (-d) supported only with -c, -r " - // "or -s ..\n"); - //usage(); - // By Default lets show everything we have! - regulators = clocks = sensors = 1; + if (dump && !(options->regulators || + options->clocks || options->sensors)) { + /* By Default lets show everything we have */ + options->regulators = options->clocks = options->sensors = 1; } - if (findparent && (!clocks || !dump)) { + if (options->findparent && (!options->clocks || !dump)) { fprintf(stderr, "-p option passed without -c and -d." " Exiting...\n"); - usage(); + return -1; } if (!dump && selectedwindow == -1) selectedwindow = CLOCK; + return 0; +} + +int main(int argc, char **argv) +{ + int i; + int findparent_ncurses = 0, refreshwin = 0; + int enter_hit = 0; + int firsttime[TOTAL_FEATURE_WINS]; + char clkname_str[64]; + struct powerdebug_options *options; + + for (i = 0; i < TOTAL_FEATURE_WINS; i++) + firsttime[i] = 1; + + options = malloc(sizeof(*options)); + if (!options) { + fprintf(stderr, "failed to allocated memory\n"); + return -1; + } + + if (getoptions(argc, argv, options)) { + usage(); + return 1; + } + init_regulator_ds(); while (1) { @@ -172,17 +195,17 @@ int main(int argc, char **argv) show_header(); } - if (regulators || selectedwindow == REGULATOR) { + if (options->regulators || selectedwindow == REGULATOR) { read_regulator_info(); if (!dump) { create_selectedwindow(); - show_regulator_info(verbose); + show_regulator_info(options->verbose); } else - print_regulator_info(verbose); + print_regulator_info(options->verbose); } - if (clocks || selectedwindow == CLOCK) { + if (options->clocks || selectedwindow == CLOCK) { int ret = 0; if (firsttime[CLOCK]) { ret = init_clock_details(); @@ -202,7 +225,7 @@ int main(int argc, char **argv) if (refreshwin) command = REFRESH_WINDOW; hrow = read_and_print_clock_info( - verbose, + options->verbose, highlighted_row, command); highlighted_row = hrow; @@ -212,19 +235,19 @@ int main(int argc, char **argv) enter_hit); } if (!ret && dump) { - if (findparent) - read_and_dump_clock_info_one(clkarg); + if (options->findparent) + read_and_dump_clock_info_one(options->clkarg); else - read_and_dump_clock_info(verbose); + read_and_dump_clock_info(options->verbose); } } - if (sensors || selectedwindow == SENSOR) { + if (options->sensors || selectedwindow == SENSOR) { if (!dump) { create_selectedwindow(); print_sensor_header(); } else - read_and_print_sensor_info(verbose); + read_and_print_sensor_info(options->verbose); } if (dump) @@ -232,8 +255,8 @@ int main(int argc, char **argv) FD_ZERO(&readfds); FD_SET(0, &readfds); - tval.tv_sec = ticktime; - tval.tv_usec = (ticktime - tval.tv_sec) * 1000000; + tval.tv_sec = options->ticktime; + tval.tv_usec = (options->ticktime - tval.tv_sec) * 1000000; key = select(1, &readfds, NULL, NULL, &tval); @@ -308,7 +331,7 @@ int main(int argc, char **argv) exit(0); if (keychar == 'R') { refreshwin = 1; - ticktime = 3; + options->ticktime = 3; } else refreshwin = 0; } -- 1.7.1

14 years, 1 month

[Paul Wise] ARM support to be removed from IcedTea

by James Westby

Hi, Just making sure that Linaro people have seen this. Thanks, James

14 years, 1 month

ARM support to be removed from IcedTea

by Paul Wise

http://gbenson.net/?p=257 http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2011-March/012556.html http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2011-March/013044.html http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2011-March/013059.html -- bye, pabs http://wiki.debian.org/PaulWise

14 years, 1 month

How do you see a patch series?

by Guilherme Salgado

Hi there, I'm currently working on the PatchTracking[1] spec and, wrt patch series, I'm wondering whether you consider the patches that are part of a series to be separate or the series to be a single entity? Thanks! [1] https://wiki.linaro.org/Platform/Infrastructure/Specs/PatchTracking -- Guilherme Salgado <https://launchpad.net/~salgado>

14 years, 1 month

how to sync with mainline

by Barry Song

Hi All, I am a freshman to linaro. I found people sent some patches to linaro-dev(a)lists.linaro.org. Here I have 2 questions: 1. Whether will linaro send those patches based on newest tree to Linus' mainline or not? Or developers need to send those patches to mainline by themselves? Is there any document to describe how linaro contribute patches to mainline? 2. If other SoC companies work based on linaro's linux-linaro-next.git, whether it will not need to work based on Linus' tree since linux-linaro-next.git will sync with mainline? Thanks Barry

14 years, 1 month

Re: Future desktop on dumb frame buffers?

by Robert Fekete

On 21 March 2011 21:08, Alex Deucher <alexdeucher(a)gmail.com> wrote: > On Mon, Mar 21, 2011 at 3:50 PM, Geert Uytterhoeven > <geert(a)linux-m68k.org> wrote: >> On Mon, Mar 21, 2011 at 20:25, Jesse Barnes <jbarnes(a)virtuousgeek.org> wrote: >>> On Mon, 21 Mar 2011 19:19:43 +0000 >>> timofonic timofonic <timofonic(a)gmail.com> wrote: >>>> So if KMS is so cool and provides many advantages over fbdev and >>>> such... Why isn't more widely used intead of still relying on fbdev? >>>> Why still using fbdev emulation (that is partial and somewhat broken, >>>> it seems) instead using KMS directly? >>> >>> Used by what? All three major GPU device classes have KMS support >>> (Intel, ATI, and nVidia). If you want it for a particular device, you >>> can always port it over. >> >> The three major GPU device classes on PC... > > Sadly it gets worse. A lot of the SoC vendors are adding an fbdev > emulation layer on top of v4l rather than using fbdev directly or > using KMS and v4l has grown it's own edid, hdmi, and cec handling. > I agree, it is sad that as a SoC vendor there are different kernel/user API's(v4l2/fbdev/drm) to choose from when implementing say a Display controller driver. One must also remember that there are big differences between a desktop/PC multimedia/graphics system and the ones present on an embedded SoC. It is two very different cultures and HW designs now trying to merge into one Linux Kernel. Of course there will be some overlaps but I believe it can be sorted out as soon as we understand each others different possibilities/limitations. Doing duplicate work like HDMI will not benefit any party. Just to list some of the differences. - Developments within V4L2 has mainly been driven by embedded devices while DRM is a result of desktop Graphics cards. And for some extent also solving different problems. - Embedded devices usually have several different hw IP's managing displays, hdmi, camera/ISP, video codecs(h264 accellerators), DSP's, 2D blitters, Open GL ES hw, all of which have a separate device/driver in the kernel, while on a desktop nowadays all this functionality usually resides on ONE graphics card, hence one DRM device for all. - DRM is closely developed in conjunction with desktop/Xorg, while X11 on an embedded device is not very 2011...wayland on the other hand is :-), but do wayland really need the full potential of DRM/DRI or just parts of it. - Copying buffers is really bad for embedded devices due to lower memory bandwidth and power consumption while on a Desktop memory bandwidth is from an other galaxy (copying still bad but accepted it seems), AND embedded devices of today records and plays/displays 1080p content as well. - Not all embedded devices have MMU's for each IP requiring physical contiguous memory, while on a desktop MMU's have been present for ages. - Embedded devices are usually ARM based SoCs while x86 dominates the Desktop/Laptop market, and functionality provided is soon the very same. - yada yada....The list can grow very long....There are also similarities of course. The outcome is that SoC vendors likes the embedded friendliness of v4l2 and fbdev while "we" also glance at the DRM part due to its de-facto standard on desktop environments. But from an embedded point of view DRM lacks the support for interconnecting multiple devices/drivers mentioned above, GEM/TTM is valid within a DRM device, the execution/context management is not needed,, no overlays(or similar), the coupling to DRI/X11 not wanted. SoCs like KMS/GEM but the rest of DRM will likely not be heavily used on SoCs unless running X11 as well. Most likely this worked on as well within the DRI community. I can see good features all over the place(sometimes duplicated) but not find one single guideline/API that solves all the embedded SoC problems (which involves use-cases optimized for no-copy cross media/drivers). Last but not least... On Linaro there is already discussions ongoing to solve one of the biggest issues from a SoC point of view and that is a "System Wide Memory manager" which manages buffer sharing and resolves no-copy use cases between devices/drivers. Read more on the following thread: http://lists.linaro.org/pipermail/linaro-dev/2011-March/003053.html. BR /Robert Fekete st-ericsson

14 years, 1 month

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev