linaro-dev December 2011

linaro-dev@lists.linaro.org

139 participants
148 discussions

[PATCH] ohci-hcd: ohci-hcd: use usleep_range() instead of mdelay()

by Dmitry Antipov

From ac60fe289eef3d81009f2b14a12acbac3e71878b Mon Sep 17 00:00:00 2001 From: Dmitry Antipov <dmitry.antipov(a)linaro.org> Date: Wed, 21 Dec 2011 11:05:27 +0400 Subject: [PATCH] ohci-hcd: use usleep_range() instead of mdelay() --- drivers/usb/host/ohci-hcd.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c index b263919..a6d58da 100644 --- a/drivers/usb/host/ohci-hcd.c +++ b/drivers/usb/host/ohci-hcd.c @@ -574,6 +574,7 @@ static int ohci_run (struct ohci_hcd *ohci) u32 mask, val; int first = ohci->fminterval == 0; struct usb_hcd *hcd = ohci_to_hcd(ohci); + unsigned long usecs; disable (ohci); @@ -724,7 +725,8 @@ retry: spin_unlock_irq (&ohci->lock); // POTPGT delay is bits 24-31, in 2 ms units. - mdelay ((val >> 23) & 0x1fe); + usecs = ((val >> 23) & 0x1fe) * USEC_PER_MSEC; + usleep_range(usecs, usecs + 1000); hcd->state = HC_STATE_RUNNING; if (quirk_zfmicro(ohci)) { -- 1.7.7.4

12 years, 10 months

audio support for pandboard on Linaro release 11.11/12

by Yuping Luo

Hi, I have one pandboard (4430), however, it's said the audio and audiohw not supported in the Linaro android release 11.11 or 11.12, so is there one way to add the support manually ? if yes, where to begin ? I am also interested in enabling the video hw support for the board, but no idea until now. Thanks. Yuping Luo

12 years, 10 months

[PATCH V3 0/7] add a generic cpufreq driver

by Richard Zhao

The driver support single core and multi core ARM SoCs. For multi core, it assume all cores share the same clock and voltage. TODO: - Add each core seperate freq/volt support (MSM). Changes in v3: - move adjusting smp loops_per_jiffy to arm common code, and also adjust global loops_per_jiffy. - remove adjusting loops_per_jiffy in imx and omap cpufreq drivers. - check compatible "generic-cpufreq" when module_init - change printk to pr_xxx - add generic-cpufreq DT binding doc Changes in v2: - add volatage change support - change '_' in property name to '-' - use initial value to calculate loops_per_jiffy - fix reading cpu_volts property bug - let cpufreq_frequency_table_cpuinfo routines handle cpu_freq_khz_max/min - don't change freq in arm_cpufreq_exit, because every core share the same freq. - use unsigned long describe frequency as much as possible. Because clk use unsigned long, but cpufreq use unsigned int. [PATCH V3 1/7] ARM: add cpufreq transiton notifier to adjust [PATCH V3 2/7] arm/imx: cpufreq: remove loops_per_jiffy recalculate [PATCH V3 3/7] cpufreq: OMAP: remove loops_per_jiffy recalculate for [PATCH V3 4/7] cpufreq: add generic cpufreq driver [PATCH V3 5/7] dts/imx6q: add cpufreq property [PATCH V3 6/7] arm/imx6q: register arm_clk as cpu to clkdev [PATCH V3 7/7] arm/imx6q: select ARCH_HAS_CPUFREQ

12 years, 10 months

[PATCH] drm: fix compilation warning with i386_defconfig

by Tushar Behera

The patch d795e2c "Adding omap_gpu drm display driver" introduces following compilation warning when the kernel is compiled for x86 architecture (i386_defconfig). Also the kernel compilation is unsuccessful because of calls to omap specific platform header files. warning: (VIDEO_OMAP2_VOUT && DRM_OMAP) selects OMAP2_DSS which has unmet direct dependencies (HAS_IOMEM && ARCH_OMAP2PLUS) The problem is fixed by making DRM_OMAP depend on ARCH_OMAP2. Signed-off-by: Tushar Behera <tushar.behera(a)linaro.org> --- drivers/gpu/drm/Kconfig | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index fdef87b..0949995 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -169,7 +169,7 @@ config DRM_SAVAGE config DRM_OMAP tristate "OMAP GPU (EXPERIMENTAL)" - depends on DRM && !CONFIG_FB_OMAP2 + depends on DRM && ARCH_OMAP2 && !CONFIG_FB_OMAP2 select DRM_KMS_HELPER select OMAP2_VRAM select OMAP2_DSS -- 1.7.1

12 years, 10 months

CMA vs HIGHMEM issue

by Andy Green

Hi - I recently brought in v 15 (and then v 17) of the CMA patches on tilt-tracking and backported to tilt-3.1 in order to support Panda onboard camera. Without any highmem, stuff is working great, but with HIGHMEM, inclusion of either v15 and v17 CMA consistently blows chunks during DMA init like this --> [ 0.517761] Enabling ERRATA 751472 [ 0.521392] OMAP4: Map 0xafe00000 to 0xfe600000 for dram barrier [ 0.529510] print_constraints: dummy: [ 0.534973] NET: Registered protocol family 16 [ 0.550659] Unable to handle kernel NULL pointer dereference at virtual address 00000000 [ 0.559082] pgd = c0004000 [ 0.561950] [00000000] *pgd=00000000 [ 0.565734] Internal error: Oops: 805 [#1] PREEMPT SMP [ 0.571136] Modules linked in: [ 0.574371] CPU: 0 Tainted: G W (3.1.0-panda_tilt-3.1+ #2) [ 0.581268] PC is at __memzero+0x24/0x80 [ 0.585388] LR is at 0x0 [ 0.588073] pc : [<c0298ea4>] lr : [<00000000>] psr: 20000013 [ 0.588104] sp : ef833f54 ip : 00000000 fp : 00000000 [ 0.600067] r10: c0838c80 r9 : 00000000 r8 : 00000000 [ 0.605560] r7 : ef833f84 r6 : c14ac000 r5 : 00040000 r4 : 00000000 [ 0.612335] r3 : 00000000 r2 : 00000000 r1 : 0003ffc0 r0 : 00000000 [ 0.619140] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [ 0.626770] Control: 10c5387f Table: 8000404a DAC: 00000015 [ 0.632751] Process swapper (pid: 1, stack limit = 0xef8322f8) [ 0.638854] Stack: (0xef833f54 to 0xef834000) [ 0.643432] 3f40: c001df04 c0d3c000 00040000 [ 0.651947] 3f60: 00000647 c001dfa4 c08910a4 00040000 0000045f 00000000 00000000 c0838cc0 [ 0.660461] 3f80: 00000000 00000000 c08710cc c08ed640 ef832000 c0008900 0000009f c009e3c8 [ 0.668975] 3fa0: 0000009f c0838c80 c00145ec 00393531 00000000 c0140000 00000000 c08abcf4 [ 0.677459] 3fc0: 0000019a c08710cc c087186c c00145ec 00000013 00000000 00000000 00000000 [ 0.685974] 3fe0: 00000000 c0834874 00000000 00000000 c08347e8 c00145ec 37a42f33 10139e95 [ 0.694488] Code: e52de004 e1a0c002 e1a0e002 e2511040 (a8a0500c) [ 0.700866] ---[ end trace 1b75b31a2719ed1d ]--- [ 0.705749] Kernel panic - not syncing: Attempted to kill init! [ 0.711944] CPU1: stopping [ 0.714843] [<c001a524>] (unwind_backtrace+0x0/0xf8) from [<c000865c>] (do_IPI+0xf0/0x118) [ 0.723449] [<c000865c>] (do_IPI+0xf0/0x118) from [<c05d8ff4>] (__irq_svc+0x34/0xd0) [ 0.731506] Exception stack(0xef873f90 to 0xef873fd8) [ 0.736785] 3f80: ffffffed 00ce3000 ef873fd8 00000000 [ 0.745300] 3fa0: ef872000 c08ed704 c05e2a8c c0890754 c0890914 411fc092 00000000 00000000 [ 0.753814] 3fc0: 00000001 ef873fd8 c0014648 c001464c 60000113 ffffffff [ 0.760742] [<c05d8ff4>] (__irq_svc+0x34/0xd0) from [<c001464c>] (default_idle+0x24/0x28) [ 0.769256] [<c001464c>] (default_idle+0x24/0x28) from [<c001489c>] (cpu_idle+0xfc/0x11c) [ 0.777770] [<c001489c>] (cpu_idle+0xfc/0x11c) from [<805d1954>] (0x805d1954) Is it expected CMA and high memory should work OK? I see there's a note in the CMA log about "implement support for contiguous memory areas placed in HIGHMEM zone", but it's ambiguous if it should be ignoring highmem or is expected to blow chunks. If it's expected to blow chunks, is there a hack or workaround that will allow us to have both HIGHMEM and CMA on OMAP4? -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog

12 years, 10 months

[patch] reduce namespace polloution from sys/ucontext.h on arm

by peter green

On arm linux sys/ucontext.h heavilly polloutes the global namespace firstly by including sys/user.h (which defines among other things a type called "struct user" and secondly by defining symbols and #defines named R? to represent the processor registers. That issue in itself is nothing new but fairly recently* signal.h started including sys/ucontext.h by default causing programs that (quite reasonable IMO) used those names for their own symbols to fail to build on arm. This has been especially noticable recently because debian is trying to build the new "armhf" port. After discussions on debian-arm/debian-glibc/linaro-dev (I do not know which responders came from which list) I was given the following advice on the "struct user" issue by Ulrich Weigand. >Now, glibc also provides a file <sys/ucontext.h> that defines >layouts of register sets for use with signal handlers as well >as the makecontext/setcontext/getcontext family of routines. > >Usually, those layouts tend to be in fact identical to the >layouts described in <sys/user.h> / <sys/procfs.h>. Apparently, >whoever implemented the ARM version of <sys/ucontext.h> was >trying to avoid some seemingly unnecessary code duplication >by making <sys/ucontext.h> *include* <sys/procfs.h> and using >the information from there directly. This is not done on other >platforms, for precisely the reason that the <sys/procfs.h> >and <sys/user.h> headers do pollute the name space ... > >So I think the right thing to do in the short term would be to >stop <sys/ucontext.h> including <sys/procfs.h>, and instead add the >register set information there directly, even if that means some >duplication of code. (Again, since this is never-changing ABI, >duplication isn't actually all that bad. Also, all the other >platforms do it that way too, so why should ARM be different ...) On the issue of the R? definitions I proposed renaming them to REG_R?. The use of a REG_ prefix is consistent with x86, x64 and sparc (I couldn't find any comparable definitions at all on other architectures I looked at) I asked what the impact of this change would be on the aforementioned mailing lists and got the following reply from Konstantinos Margaritis >at worst the packages that had to be workaround on arm* for this, can >have the workaround removed. The attached patch implements these changes. My tests do not show any new failures in the libc testsuite (though I do get failures that debian considers "unexpected" regardless of whether this patch is applied or not) * I have not investigated exactly when this change occoured but it was somewhere between the version in debian squeeze and the version in debian wheezy.

12 years, 10 months

[PATCH v2 0/3] Device tree support for TWL regulators

by Rajendra Nayak

This series adds DT support for TWL regulator driver and passes regulator data for two OMAP4 boards (OMAP4 panda and OMAP4 sdp) from device tree. Patches are based on for-next of the regulator tree[1] with omap i2c/twl DT adaptation patches[2] from Benoit pulled in and are available here: git://gitorious.org/omap-pm/linux.git for-dt/regulator-twl regards, Rajendra [1] git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next [2] git://gitorious.org/omap-pm/linux.git for_3.3/3_omap_dt_i2c_twl Rajendra Nayak (3): regulator: twl: adapt twl-regulator driver to dt ARM: omap4-sdp: Pass regulator data from dt omap4: panda: Pass regulator data from dt .../bindings/regulator/twl-regulator.txt | 57 +++++++++ arch/arm/boot/dts/omap4-panda.dts | 24 ++++ arch/arm/boot/dts/omap4-sdp.dts | 36 ++++++ drivers/regulator/twl-regulator.c | 128 +++++++++++++------- 4 files changed, 199 insertions(+), 46 deletions(-) create mode 100644 Documentation/devicetree/bindings/regulator/twl-regulator.txt

12 years, 10 months

Writing to the ACTLR register on Cortex a9

by X Y

Hi, I am trying to modify the ACTLR register. But it is not possible because Linux kernel is booting in non-secure mode. For the same reason I cannot fix some errata by writing to the diagnostic register. I am using Snowball board. A very simple question I have: Is it possible to call secure monitor (SMC command) to perform simple writings to the registers? Or somehow boot Linux in secure mode? Thanks

12 years, 10 months

Weird, weird Linux on ARM, a LinuxCon presentation

by Christian Robottom Reis

I did a presentation this November at LinuxCon Brazil called "The Wierd World of Linux on ARM (featuring Android)": https://events.linuxfoundation.org/events/linuxcon-brasil/programacao I thought the slides might be interesting, so I posted them here: https://wiki.linaro.org/ChristianReis Linus didn't ask me any questions, so your comments are even more welcome than usual. Thanks! -- Christian Robottom Reis, Engineering VP Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935 Linaro.org: Open Source Software for ARM SoCs

12 years, 10 months

[PATCH 0/2] Exynos Related fixes

by Chander Kashyap

Chander Kashyap (2): Exynos: PWM: Add TCMPB3 field in pwm structure Exynos: Fix ARM Clock frequency calculation arch/arm/cpu/armv7/exynos/clock.c | 9 ++++++--- arch/arm/include/asm/arch-exynos/pwm.h | 2 +- 2 files changed, 7 insertions(+), 4 deletions(-) -- 1.7.5.4

12 years, 10 months

← Newer
1
2
3
4
5
6
7
8
...
15
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev December 2011