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
s3c24xx_i2c_parse_dt_gpio is called when cfg_gpio is not defined
in the platform data of the i2c device. When DT is not enabled,
the above function always returns -EINVAL. Since there can be
some i2c devices which don't need to configure any gpio lines,
the probe of such devices would fail here. Changing the default
return value to success would fix this issue.
Signed-off-by: Tushar Behera <tushar.behera(a)linaro.org>
---
This patch is rebased on Kukjin's for-next branch.
d3d936c "Merge branch 'samsung-fixes-2' into for-next"
drivers/i2c/busses/i2c-s3c2410.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c
index 2754cef..b5caa42 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -786,7 +786,7 @@ static void s3c24xx_i2c_dt_gpio_free(struct s3c24xx_i2c *i2c)
#else
static int s3c24xx_i2c_parse_dt_gpio(struct s3c24xx_i2c *i2c)
{
- return -EINVAL;
+ return 0;
}
static void s3c24xx_i2c_dt_gpio_free(struct s3c24xx_i2c *i2c)
--
1.7.4.1
Konstantinos Margaritis wrote:
>> Does anyone know what the impact of renaming these to use a REG_ prefix like
>> i386, amd64 and sparc do* would be?
>>at worst the packages that had to be workaround on arm* for this, can
>have the workaround removed.
I have prepared a patch (attatched) that eliminates the dependency on
sys/procfs.h and renames R? to REG_R?. I have tested it by modifying the
header locally. I am now attempting to rebuild glibc with the patch.
After rebuilding glibc I will install it and attempt to rebuild GDB.
Please comment on the patch and advise on the best route for submission
(that is should I go through debian, through eglibc or direct to glibc?)
>Since you're in the process of fixing things for glibc/arm
Note that I am not a glibc developer nor am I a dd (and even if I was a
dd I don't think I would NMU glibc). I'm just a user with an interest
in the future of debian on arm.
>would you
>mind also looking at WCHAR_MIN/MAX undefined for arm?
>
>http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=598937
They most certainly are defined. The trouble is that WCHAR_MAX is defined
in a strange way.
#define __WCHAR_MAX ( (wchar_t) - 1 )
This definition is fine for normal c or c++ code but
it cannot be properly evaluated in the context of a
preprocessor conditional.
The bug report has a patch (actually a replacement for
an existing patch) which looks fine to me.
