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
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
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
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
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.
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
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
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
