I have been trying to reach you
I have an Urgent Business Proposal for you. If interested please reply me so that I can give you more details about the business. Thanks, Col.Martin Kelly. Email: kellymar...@qq.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/5] spi: introduce flag for memory mapped read
On 8/6/2015 23:33, Russell King - ARM Linux wrote: On Thu, Aug 06, 2015 at 06:14:00PM +0200, Geert Uytterhoeven wrote: Irrespective of the dummy bytes. What if the spi device is not a FLASH ROM, but some other device, which receives a data packet that accidentally looks like an m25p80 READ command? Well, for the most part it looks like it should still work, but there could be a gotcha, but first, let's get rid of a myth there. The QSPI is _not_ specific to the M25P80. The manual says nothing about being specific to that device. What it says is that it's for SPI NOR memory. It will work with bus widths of 1, 2 or 4 data lines, so it probably works with non-M25P80 SPI NOR devices too - and the fact that the read and write commands are completely programmable suggests that using it with SPI NOR devices which do not use the M25P80 read command value is intended. The SFI is a state machine based translator which sits behind the SPI interface (look at the manual). It sequence sthe SPI bus through a series of standard SPI states which happen to be the states I detailed above. Now, the first byte of the SFI-generated SPI message can be programmed to any 8 bit value. So the first byte of the SPI message is totally under software control. The next one to four bytes which comprise the address can be controlled to by deciding where in the memory map to start reading from. Hence, the value of those bytes is also totally under software control. The number of dummy bytes can be programmed too. So far so good. So, if we know that we have a SPI message which says send 0x01 0x20 0x30, send one dummy byte, read 32 bytes, if we program the SFI to send a read command as 0x01, program an address length of 2 bytes with one dummy byte, and then read the next 32 bytes at the appropriate offset in the memory mapping to cause the next two bytes to be 0x20, 0x30, then what we end up with on the bus is: send 0x01, 0x20, 0x30 send one dummy byte That much is good, but now is the problem - how does the SFI know that we're going to require to read 32 bytes? I think the answer to that is that it doesn't know, so it probably just reads the number of bytes which the access on the SoC bus is asking for, which makes it indeterminant from a software point of view to control how many bytes will be read without provoking another send 0x01, next address, dummy byte sequence. So, I'm now on the side of not parsing commands in the SPI driver, and back on the idea that this needs to be handled in some other manner which doesn't involve polluting the SPI core with flag-hacks. So I see 2 distinct options: Have the nor driver modified to run SPI commands and then ask the SPI framework (and driver) to switch into mmap mode: Would probably look something like this inside the nor driver: /* lock spi bus for other activities */ spi_bus_lock(spi); /* send the configuration for mmap */ t[0].tx_buf = flash-command; t[0].len = m25p_cmdsz(nor); spi_message_add_tail(t[0], m); t[1].tx_buf = dummy_buffer; t[1].len = dummy; spi_message_add_tail(t[1], m); spi_sync(spi, m); /* switch to mmap mode */ spi-mode |= SPI_MMAP; spi_setup(spi); /* run the mmapped transfers bypassing the spi-layer */ memcpy(...) /* open questions here: which address range * and how to detect if transfer is done */ /* restore back to normal mode */ spi-mode = ~SPI_MMAP; spi_setup(spi); /* unlock spi bus for other activities */ spi_bus_unlock(spi); The downside is that it requires modification in several places (nor-framework, spi-framework plus the driver) and it would not be generic enough... IMO such a situation is feasible if we only got a single device on the spi-bus, but leaves a lot of questions open... Alternatively we could create an additional api. On the other end of spectrum could be a solution where the spi-master driverwould have the opportunity to query the device-tree for specific propertiesduring the spi_add_device phase - in this case querying the followingproperty in the device-tree: spi-master-XXX,use-mmap-cmd-mode = 0x08 0x38; to implement mmap-mode for commands 0x08 and 0x38. Maybe we would want to also encode the number of address bytes to send per command without hardcoding those values explicitly: so maybe something like: spi-master-XXX,use-mmap-cmd-mode = 0x08 2 0x38 3; Obviously these would need to get documented in the bindings documentation of that driver. Alternatively we could also introduce generic alternate modes for the driver(similar to GPIO - ALT modes), but that would be less transparent and more hard-coded... In the end this would mean that from the nor framework side therewould be no change at all - it still would be issuing something like this: /* send the normal block read command */ t[0].tx_buf = flash-command; /* note that the address would be encoded here */ t[0].len = m25p_cmdsz(nor); spi_message_add_tail(t[0], m);
Re: [RFC] Fix omap3 booting with thumb2 compiled kernel
On Thu, May 28, 2015 at 07:55:16PM +0100, Arnd Bergmann wrote: On Thursday 28 May 2015 09:36:05 Tony Lindgren wrote: * Dave Martin dave.mar...@arm.com [150528 09:19]: On Thu, May 28, 2015 at 07:21:25AM -0700, Tony Lindgren wrote: --- a/arch/arm/mach-omap2/sleep34xx.S +++ b/arch/arm/mach-omap2/sleep34xx.S @@ -203,23 +203,8 @@ save_context_wfi: */ ldr r1, kernel_flush blx r1 - /* -* The kernel doesn't interwork: v7_flush_dcache_all in particluar will -* always return in Thumb state when CONFIG_THUMB2_KERNEL is enabled. -* This sequence switches back to ARM. Note that .align may insert a -* nop: bx pc needs to be word-aligned in order to work. -*/ - THUMB(.thumb ) - THUMB(.align ) - THUMB(bx pc ) - THUMB(nop ) - .arm - ^ This looks unrelated to the issue? This code is simply unnecessary after Russell introduced the ret macro in commit 6ebbf2ce43. That made v7_flush_dcache_all do a proper interworking return. It should probably be in a separate commit, or at least mentioned explicitly in the commit log. Thanks, I've updated the description with the commit info above. I'll keep the removal of the duplicate code in this patch, as it's all related to the mode switching and we don't want to do it twice. I would have thought that the change is actually necessary after 6ebbf2ce43, because it now returns in ARM mode, which will cause the bx pc; nop thumb instruction sequence be misinterpreted as an ARM instruction. Arnd You're right. The THUMB2_KERNEL indeed won't work without deleting this code. Cheers ---Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Fix omap3 booting with thumb2 compiled kernel
On Thu, May 28, 2015 at 09:36:05AM -0700, Tony Lindgren wrote: * Dave Martin dave.mar...@arm.com [150528 09:19]: On Thu, May 28, 2015 at 07:21:25AM -0700, Tony Lindgren wrote: --- a/arch/arm/mach-omap2/sleep34xx.S +++ b/arch/arm/mach-omap2/sleep34xx.S @@ -203,23 +203,8 @@ save_context_wfi: */ ldr r1, kernel_flush blx r1 - /* - * The kernel doesn't interwork: v7_flush_dcache_all in particluar will - * always return in Thumb state when CONFIG_THUMB2_KERNEL is enabled. - * This sequence switches back to ARM. Note that .align may insert a - * nop: bx pc needs to be word-aligned in order to work. - */ - THUMB( .thumb ) - THUMB( .align ) - THUMB( bx pc ) - THUMB( nop ) - .arm - ^ This looks unrelated to the issue? This code is simply unnecessary after Russell introduced the ret macro in commit 6ebbf2ce43. That made v7_flush_dcache_all do a proper interworking return. It should probably be in a separate commit, or at least mentioned explicitly in the commit log. Thanks, I've updated the description with the commit info above. I'll keep the removal of the duplicate code in this patch, as it's all related to the mode switching and we don't want to do it twice. b omap3_do_wfi - -/* - * Local variables - */ ^ Likewise this is just tidyup, not bug fixing. Will keep that too, the local variables comments are now just too confusing while reading the code after adding the ENDPROC. And that too is just removal. I have no objection to tidyups ;) So long as the commit message is clear about which parts are bugfix and which parts are tidyup, I'm fine with that. Cheers ---Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Fix omap3 booting with thumb2 compiled kernel
On Thu, May 28, 2015 at 07:21:25AM -0700, Tony Lindgren wrote:
* Grazvydas Ignotas nota...@gmail.com [150528 04:45]:
On Thu, May 28, 2015 at 1:55 AM, Tony Lindgren t...@atomide.com wrote:
8 --
From: Tony Lindgren t...@atomide.com
Date: Wed, 27 May 2015 15:33:57 -0700
Subject: [PATCH] ARM: OMAP3: Fix booting with thumb2 kernel
We get a NULL pointer dereference on omap3 for thumb2 compiled kernels:
Internal error: Oops: 8005 [#1] SMP THUMB2
...
[c046497b] (_raw_spin_unlock_irqrestore) from [c0024375]
(omap3_enter_idle_bm+0xc5/0x178)
[c0024375] (omap3_enter_idle_bm) from [c0374e63]
(cpuidle_enter_state+0x77/0x27c)
[c0374e63] (cpuidle_enter_state) from [c00627f1]
(cpu_startup_entry+0x155/0x23c)
[c00627f1] (cpu_startup_entry) from [c06b9a47]
(start_kernel+0x32f/0x338)
[c06b9a47] (start_kernel) from [8000807f] (0x8000807f)
The power management related assembly on moaps needs to interact with
moaps - omaps
Thanks, fixed now. I also added a link for why ENDPROC is needed to the
description. I'll apply the patch below into fixes today.
Regards,
Tony
8 --
From: Tony Lindgren t...@atomide.com
Date: Wed, 27 May 2015 15:33:57 -0700
Subject: [PATCH] ARM: OMAP3: Fix booting with thumb2 kernel
We get a NULL pointer dereference on omap3 for thumb2 compiled kernels:
Internal error: Oops: 8005 [#1] SMP THUMB2
...
[c046497b] (_raw_spin_unlock_irqrestore) from [c0024375]
(omap3_enter_idle_bm+0xc5/0x178)
[c0024375] (omap3_enter_idle_bm) from [c0374e63]
(cpuidle_enter_state+0x77/0x27c)
[c0374e63] (cpuidle_enter_state) from [c00627f1]
(cpu_startup_entry+0x155/0x23c)
[c00627f1] (cpu_startup_entry) from [c06b9a47]
(start_kernel+0x32f/0x338)
[c06b9a47] (start_kernel) from [8000807f] (0x8000807f)
The power management related assembly on omaps needs to interact with
ARM mode bootrom code, so we need to keep most of the related assembly
in ARM mode.
Turns out this error is because of missing ENDPROC for assembly code
as suggested by Stephen Boyd sb...@codeaurora.org. Let's add the
missing ENDPROC in two places to sleep34xx.S, and also remove the
earlier mystery code that was probably also caused by missing ENDPROC
for earlier kernels.
The reason why ENDPROC makes a difference is it sets .type and then
the compiler knows what to do with the thumb bit as explained at:
https://wiki.ubuntu.com/ARM/Thumb2PortingHowto
Reported-by: Kevin Hilman khil...@kernel.org
Tested-by: Kevin Hilman khil...@linaro.org
Signed-off-by: Tony Lindgren t...@atomide.com
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
@@ -203,23 +203,8 @@ save_context_wfi:
*/
ldr r1, kernel_flush
blx r1
- /*
- * The kernel doesn't interwork: v7_flush_dcache_all in particluar will
- * always return in Thumb state when CONFIG_THUMB2_KERNEL is enabled.
- * This sequence switches back to ARM. Note that .align may insert a
- * nop: bx pc needs to be word-aligned in order to work.
- */
- THUMB( .thumb )
- THUMB( .align )
- THUMB( bx pc )
- THUMB( nop )
- .arm
-
^ This looks unrelated to the issue? This code is simply unnecessary
after Russell introduced the ret macro in commit 6ebbf2ce43. That
made v7_flush_dcache_all do a proper interworking return.
It should probably be in a separate commit, or at least mentioned
explicitly in the commit log.
b omap3_do_wfi
-
-/*
- * Local variables
- */
^ Likewise this is just tidyup, not bug fixing.
+ENDPROC(omap34xx_cpu_suspend)
omap3_do_wfi_sram_addr:
.word omap3_do_wfi_sram
kernel_flush:
@@ -364,10 +349,7 @@ exit_nonoff_modes:
* ===
*/
ldmfd sp!, {r4 - r11, pc} @ restore regs and return
-
-/*
- * Local variables
- */
+ENDPROC(omap3_do_wfi)
The ENDPROC()s look appropriate here.
[...]
Cheers
---Dave
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFI] OMAP4 ISS: l3_interrupt_handler Errors due to wrong initialized iss_fck?
Hi,
I am trying to get both CSI2 interfaces up and running through the ISS
on the v3.16 kernel for the TI OMAP4 Blaze platform (omap4430 ES 2.3
revision).
Trough a omap_device_build() call (using the iss omap_hwmod) I call the
iss_probe function. It devm_clk_get's both the iss_ctrlclk and the iss_fck.
Since I am building the kernel with the omap4-sdp-es23plus device tree
appended, I figured I need to define the iss_fck in the omap44xx-clocks.dtsi
file, right after the iss_ctrlclk, as following:
iss_fck: iss_fck {
#clock-cells = 0;
compatible = ti,gate-clock;
clocks = ducati_clk_mux_ck;
ti,bit-shift = 1;
reg = 0x1020;
};
For that, I used the information in [1], the TI clock tree tool and the
Linux documentation.
Now the omap4iss_get() call throws L3 Standard Errors, right after the first
time the interrupts, set in iss_enable_interrupts, occur. I am pretty sure the
cause for that is a wrong initialization of the iss_fck (since I haven't
changed much more), even though the kernel runs through and the
cat clk_summary ¦ grep iss command in /sys/kernel/debug/clk/ writes:
iss_ctrlclk 019600 0
iss_fck 01 4 0
Could there be an error in the device tree entry stated above? Or might I be
missing something else? Has anyone ever enabled iss_fck through device tree?
BTW I've also added iss_fck as an opt_clk in omap_hwmod_44xx_data and added
the clock to the ti_dt_clk struct.
Thanks,
Martin
[1] http://www.ti.com/pdfs/wtbu/OMAP4430_ES2.x_PUBLIC_TRM_vAJ.zip
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
hang-ups, using SanDisk Extreme Pro microSD cards
Dear All, I am using a ISEE Igepv2 CPU board, booting from microSD card. I am using SanDisk Extreme Pro 8GByte cards. I experience occasional hang-ups of the Linux system in different severity: 1.) System seems to hang for some seconds, but afterwards continues work with no kernel messages in this case 2.) kernel is putting out message: [ 4211.686096] mmcblk0: error -110 sending read/write command, response 0x900, card status 0xe00 [ 4211.701538] mmcblk0: error -110 transferring data, sector 674693, nr 42, card status 0xc00 Afterwards the Linux system is completely dead - no SSH, no ping, nothing. The problem occurs quite often - every 4rd to 5th reboot after a few minutes working time. I have used the ISEE Igepv2 kernel 2.6.37-8 and Igep X-Loader 2.6.0-1 in this case with igep00x0-defconfig. Linux system is compiled, using the Pengutronix PTXDist 2011-11-0 cross compile environment I tried afterwards on same CPU board with Transcend Premium 8GByte cards with no problems. I tried with mainline kernel 3.15-rc4 and u-boot-2014-04 afterwards. Here I do not get the above messages, but still with some SanDisk cards I get a complete system hang-up. Same, with Transcend cards, or even some other SanDisk cards I do not have problems. The Linux images are duplicated using a script with parted, mkfs and tar to copy the images. Does anybody else already had such problems? best regards, Martin Wilde-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP5: Redo THUMB mode switch on secondary CPU
On Tue, Apr 29, 2014 at 09:53:47PM -0500, Joel Fernandes wrote: Here's a redo of the patch [1] that effectively does the same thing but is the right way to do things by using ENDPROC instead. The firmware correctly switches to THUMB before entry. The patch applies ontop of the earlier patch [1]. [1] https://lkml.org/lkml/2014/4/22/1044 Suggested-by: Dave Martin dave.mar...@arm.com Cc: Dave Martin dave.mar...@arm.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Russell King li...@arm.linux.org.uk Cc: Nishanth Menon n...@ti.com Cc: Tony Lindgren t...@atomide.com Signed-off-by: Joel Fernandes jo...@ti.com Looks OK to me. This also makes omap5 consistent with omap3/4 here. Reviewed-by: Dave Martin dave.mar...@arm.com --- Tony, the earlier patch went into your fixes, and can remain. This patch is just a simple redo of the same and can go in for v3.16, no problem. Thanks. arch/arm/mach-omap2/omap-headsmp.S |6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/arch/arm/mach-omap2/omap-headsmp.S b/arch/arm/mach-omap2/omap-headsmp.S index 1809dce..bf36f26 100644 --- a/arch/arm/mach-omap2/omap-headsmp.S +++ b/arch/arm/mach-omap2/omap-headsmp.S @@ -31,10 +31,6 @@ * register AuxCoreBoot0. */ ENTRY(omap5_secondary_startup) -.arm -THUMB( adr r9, BSYM(wait) ) @ CPU may be entered in ARM mode. -THUMB( bx r9 ) @ If this is a Thumb-2 kernel, -THUMB( .thumb ) @ switch to Thumb now. wait:ldr r2, =AUX_CORE_BOOT0_PA @ read from AuxCoreBoot0 ldr r0, [r2] mov r0, r0, lsr #5 @@ -43,7 +39,7 @@ wait: ldr r2, =AUX_CORE_BOOT0_PA @ read from AuxCoreBoot0 cmp r0, r4 bne wait b secondary_startup -END(omap5_secondary_startup) +ENDPROC(omap5_secondary_startup) /* * OMAP4 specific entry point for secondary CPU to jump from ROM * code. This routine also provides a holding flag into which -- 1.7.9.5 ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP5: Switch to THUMB mode if needed on secondary CPU
On Mon, Apr 28, 2014 at 06:21:49PM +0100, Joel Fernandes wrote: On 04/28/2014 12:20 PM, Joel Fernandes wrote: On 04/28/2014 11:43 AM, Dave Martin wrote: On Tue, Apr 22, 2014 at 01:31:46PM -0500, Joel Fernandes wrote: On my DRA7 system, when the kernel is built in THUMB mode, the secondary CPU (Cortex A15) fails to come up causing SMP boot on second CPU to timeout. This seems to be because the CPU is in ARM mode once the ROM hands over control to the kernel. Switch to THUMB mode if required once the kernel is control of secondary CPU. On OMAP4 on the other hand, it appears to be in THUMB mode on entry so this is not required and SMP boot works as is. Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Russell King li...@arm.linux.org.uk Cc: Nishanth Menon n...@ti.com Cc: Tony Lindgren t...@atomide.com Signed-off-by: Joel Fernandes jo...@ti.com --- arch/arm/mach-omap2/omap-headsmp.S |8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/omap-headsmp.S b/arch/arm/mach-omap2/omap-headsmp.S index 75e9295..1809dce 100644 --- a/arch/arm/mach-omap2/omap-headsmp.S +++ b/arch/arm/mach-omap2/omap-headsmp.S @@ -1,7 +1,7 @@ /* * Secondary CPU startup routine source file. * - * Copyright (C) 2009 Texas Instruments, Inc. + * Copyright (C) 2014 Texas Instruments, Inc. * * Author: * Santosh Shilimkar santosh.shilim...@ti.com @@ -28,9 +28,13 @@ * code. This routine also provides a holding flag into which * secondary core is held until we're ready for it to initialise. * The primary core will update this flag using a hardware -+ * register AuxCoreBoot0. + * register AuxCoreBoot0. */ ENTRY(omap5_secondary_startup) Are you sure this problem is not caused by the missing ENDPROC() for omap5_secondary_startup? You have END() instead (which may have been accidental). Without ENDPROC(), the symbol is not marked as a function and so the Thumb bit won't be set when taking a pointer -- so the kernel is actually telling the firmware to enter in ARM state. Try changing END() to ENDPROC() without this patch, and see if it makes a difference. If it still doesn't work, then the firmware either doesn't support entering in ARM, or is buggy. Thanks for the suggestion. I'm guessing what you mean is with ENDPROC, interworking code uses bx instead of bl to set thumb mode. But ROM/firmware doesn't have access to symbol table, how would it know the type of the symbol to be ARM or THUMB before it branches? Sorry what I meant is, say its of Type function. What tells the firmware to switch to THUMB? What's typically done is a boot address register is written by the kernel, and the firmware jumps to it after WFE. Using ENTRY(x) ... ENDPROC(x) causes the symbol seen by the linker for x to have the Thumb bit set if the code is Thumb. This means that any reference the linker fixes up for that symbol will have the Thumb bit set appropriately. This applies to any kind of reference, so code in another file that takes the address of the symbol and then passes that address to the firmware should result in the firmware getting an address with the Thumb bit. From the firmware's point of view it just gets a raw address, but the Thumb bit will now be set. The firmware still needs to handle this correctly when jumping, but from the look of the code this may already work on omap3/4. It would be interesting to know whether it works on omap5. Cheers ---Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP5: Switch to THUMB mode if needed on secondary CPU
On Tue, Apr 29, 2014 at 05:36:30PM +0100, Joel Fernandes wrote: [...] Sorry what I meant is, say its of Type function. What tells the firmware to switch to THUMB? What's typically done is a boot address register is written by the kernel, and the firmware jumps to it after WFE. Using ENTRY(x) ... ENDPROC(x) causes the symbol seen by the linker for x to have the Thumb bit set if the code is Thumb. This means that any reference the linker fixes up for that symbol will have the Thumb bit set appropriately. This applies to any kind of reference, so code in another file that takes the address of the symbol and then passes that address to the firmware should result in the firmware getting an address with the Thumb bit. From the firmware's point of view it just gets a raw address, but the Thumb bit will now be set. The firmware still needs to handle this correctly when jumping, but from the look of the code this may already work on omap3/4. It would be interesting to know whether it works on omap5. Thanks a lot for the explanation. That makes perfect sense. I will try it and let you know if it works on OMAP5. ARM/thumb interworking making perfect sense? I'll have to frame that and put it on the wall :) objdump and nm conveniently mask off the Thumb bit from all function addresses they print out, but if you show the symbols using readelf instead you'll see addresses with bit 0 set for Thumb functions. It's possible that the firmware still doesn't handle branching to Thumb correctly, but if it does it would be nice to remove the requirement to build an odd piece of a Thumb-2 kernel in ARM. Cheers ---Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP5: Switch to THUMB mode if needed on secondary CPU
On Tue, Apr 22, 2014 at 01:31:46PM -0500, Joel Fernandes wrote: On my DRA7 system, when the kernel is built in THUMB mode, the secondary CPU (Cortex A15) fails to come up causing SMP boot on second CPU to timeout. This seems to be because the CPU is in ARM mode once the ROM hands over control to the kernel. Switch to THUMB mode if required once the kernel is control of secondary CPU. On OMAP4 on the other hand, it appears to be in THUMB mode on entry so this is not required and SMP boot works as is. Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Russell King li...@arm.linux.org.uk Cc: Nishanth Menon n...@ti.com Cc: Tony Lindgren t...@atomide.com Signed-off-by: Joel Fernandes jo...@ti.com --- arch/arm/mach-omap2/omap-headsmp.S |8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/omap-headsmp.S b/arch/arm/mach-omap2/omap-headsmp.S index 75e9295..1809dce 100644 --- a/arch/arm/mach-omap2/omap-headsmp.S +++ b/arch/arm/mach-omap2/omap-headsmp.S @@ -1,7 +1,7 @@ /* * Secondary CPU startup routine source file. * - * Copyright (C) 2009 Texas Instruments, Inc. + * Copyright (C) 2014 Texas Instruments, Inc. * * Author: * Santosh Shilimkar santosh.shilim...@ti.com @@ -28,9 +28,13 @@ * code. This routine also provides a holding flag into which * secondary core is held until we're ready for it to initialise. * The primary core will update this flag using a hardware -+ * register AuxCoreBoot0. + * register AuxCoreBoot0. */ ENTRY(omap5_secondary_startup) Are you sure this problem is not caused by the missing ENDPROC() for omap5_secondary_startup? You have END() instead (which may have been accidental). Without ENDPROC(), the symbol is not marked as a function and so the Thumb bit won't be set when taking a pointer -- so the kernel is actually telling the firmware to enter in ARM state. Try changing END() to ENDPROC() without this patch, and see if it makes a difference. If it still doesn't work, then the firmware either doesn't support entering in ARM, or is buggy. Cheers ---Dave +.arm +THUMB( adr r9, BSYM(wait) ) @ CPU may be entered in ARM mode. +THUMB( bx r9 ) @ If this is a Thumb-2 kernel, +THUMB( .thumb ) @ switch to Thumb now. wait:ldr r2, =AUX_CORE_BOOT0_PA @ read from AuxCoreBoot0 ldr r0, [r2] mov r0, r0, lsr #5 -- 1.7.9.5 ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HYP Kernel boot requirements
On Tue, Nov 26, 2013 at 09:47:13AM -0500, Santosh Shilimkar wrote: On Tuesday 26 November 2013 09:13 AM, Catalin Marinas wrote: On Mon, Nov 25, 2013 at 07:44:08PM +, Santosh Shilimkar wrote: On Monday 25 November 2013 12:28 PM, Catalin Marinas wrote: On Mon, Nov 25, 2013 at 04:59:16PM +, Santosh Shilimkar wrote: What I am saying is the platforms like OMAP5 already support PM in mainline kernel and we can't break that for KVM. Boot-loaders would be thrashed after boot so you need something which runs in Kernel or along with Kernel to have equivalent of hyp switching. Am not challenging the agreed direction but we need to solve the PM problem as well before making all CPU runs boot-loader for HYP kernels as a must have. At least its is a change in boot strategy from existing kernels. Of course I recommend PSCI which covers both hotplug and suspend ;), but I guess it's not the case for OMAP5. Since OMAP has its own secondary booting protocol and CPU hotplug re-entry, can you not just use different entry point when the primary CPU was initially started in Hyp mode (e.g. omap5_hyp_secondary_startup)? How will that solve the guest secondary boot failure case when using the same kernel binary for guest-boot ? Even for primary CPU which will be suspended it needs to resume already in HYP mode and its not going to go through boot-loader. So the low power code needs to have HYP switch code so that CPU resumes in HYP mode. Is it late to rewrite the OMAP5 firmware? Well its ROM'ed unfortunately so no choice. OMAP5 ROM did implement a secure API which lets you enter into HYP mode and thats the only thing can be used. If the ROM is capable of loading some additional signed Secure World firmware after the ROM itself has booted, PSCI could be implemented in the second, resident firmware payload. Some SoCs ship with boot ROMs that can do that -- is this not the case for OMAP5? Cheers ---Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 00/11] Embeddable Position Independent Executable
from the PIE and then importing them into vmlinux at final link time. Because the PIE is loaded dynamically at runtime, any access to PIE functions or data must pass through special accessor macros that apply the necessary offset. Code within the PIE does not have access to symbols outside of the PIE, but it still can access code and data outside the PIE so long as it is passed pointers to that code/data. The PIE executable is provided its own set of functions required by gcc, such as memcpy, memmove, etc. The different PIE sections are collected together in the linker script as an overlay so that the kernel only needs one copy of these functions. When the PIE is loaded, the library functions and appropriate sections are copied into a genalloc pool (in the case of the example, backed by SRAM). The PIE code then applies the necessary relocations to the loaded code. Because the relocations are just relative offsets to pointers, the relocations can be reapplied to allow the code to run with the MMU enabled or disabled. This patchset is a complete rethinking of an earlier patchset [1]. Ard Biesheuvel provided the suggestion to use the PIE executable format for storing the relocatable code within the kernel. Russell King and Dave Martin pointed out the shortcomings of my initial naive approach. This patchset depends on Rajendra Nayak's SRAM DT-ification patch series [2], Suman Anna's am335x mailbox series [3], and a portion of Dave Gerlach's am335x suspend/resume patchset [4]. I've collected together the necessary dependances and applied this patch series on top of them here [5]. Because special ioremap variants are required on ARM for io mappings that allow code execution, the first two patches provide generic accessors for those variants. The third patch provides a DT and pdata method for instructing misc/sram to map the memory in such a way that allows code execution. The 4th patch provides a generic set of functions for handling function pointers as addresses and vice versa. This is necessary on ARM because of the way that Thumb2 function pointers are handled by gcc. The PIE framework requires this functionality because it performs translations of function pointers. The 5th patch is the general PIE framework. The 6th patch is the addition of ARM support for PIE. The 7th patch provides the ability of ARM to fixup PIE code on the fly. This is necessary since at suspend time the MMU will be working, but at resume time, it will be off. The 8th patch provides a predefined trampoline that utilizes the on the fly fixup. The 9th patch configures the SRAM DT entries for am335x so that they can be easily found by the PM code, and so that they are mapped with exec enabled. The 10th patch adds PIE entries for am335x, and the 11th patch finally adds suspend/resume support for am33xx utilizing C code for suspend/resume paths. [1] http://www.spinics.net/lists/arm-kernel/msg271525.html [2] http://comments.gmane.org/gmane.linux.ports.arm.omap/103774 [3] http://www.spinics.net/lists/devicetree/msg00227.html [4] http://www.spinics.net/lists/linux-omap/msg95305.html [5] https://github.com/russdill/linux/commits/sram Russ Dill (10): asm-generic: io: Add exec versions of ioremap lib: devres: Add exec versions of devm_ioremap_resource and friends misc: SRAM: Add option to map SRAM to allow code execution asm-generic: fncpy: Add function copying macros PIE: Support embedding position independent executables ARM: PIE: Add position independent executable embedding to ARM ARM: PIE: Add support for updating PIE relocations ARM: PIE: Add macro for generating PIE resume trampoline ARM: dts: AM33XX: Associate SRAM with MPU and mark it exec ARM: OMAP2+: AM33XX: Add PIE support for AM33XX Vaibhav Bedia (1): ARM: OMAP2+: AM33XX: Basic suspend resume support Documentation/devicetree/bindings/misc/sram.txt | 4 + Documentation/pie.txt | 167 Makefile| 17 +- arch/alpha/include/asm/fncpy.h | 1 + arch/arc/include/asm/fncpy.h| 1 + arch/arm/Kconfig| 1 + arch/arm/Makefile | 5 + arch/arm/boot/dts/am33xx.dtsi | 2 + arch/arm/configs/omap2plus_defconfig| 1 + arch/arm/include/asm/elf.h | 1 + arch/arm/include/asm/fncpy.h| 76 +--- arch/arm/include/asm/io.h | 2 + arch/arm/include/asm/pie.h | 42 ++ arch/arm/include/asm/suspend.h | 25 ++ arch/arm/kernel/.gitignore | 1 + arch/arm/kernel/Makefile| 4 +- arch/arm/kernel/pie.c | 92 + arch/arm/kernel/pie.lds.S | 41 ++ arch/arm/kernel/vmlinux.lds.S
Re: [PATCH v4 1/2] ARM: OMAP: Add secure function omap_smc3() which calling instruction smc #1
On Sat, Sep 14, 2013 at 10:37:12AM +0100, Pali Rohár wrote:
On Sunday 08 September 2013 09:43:29 Pali Rohár wrote:
Here is new version (v4) of omap secure part patch:
Other secure functions omap_smc1() and omap_smc2() calling
instruction smc #0 but Nokia RX-51 board needs to call smc #1
for PPA access.
Signed-off-by: Ivaylo Dimitrov freemangor...@abv.bg
Signed-off-by: Pali Rohár pali.ro...@gmail.com
---
diff --git a/arch/arm/mach-omap2/omap-secure.h
b/arch/arm/mach-omap2/omap-secure.h index 0e72917..c4586f4
100644
--- a/arch/arm/mach-omap2/omap-secure.h
+++ b/arch/arm/mach-omap2/omap-secure.h
@@ -51,6 +51,7 @@
extern u32 omap_secure_dispatcher(u32 idx, u32 flag, u32
nargs, u32 arg1, u32 arg2, u32 arg3, u32 arg4);
extern u32 omap_smc2(u32 id, u32 falg, u32 pargs);
+extern u32 omap_smc3(u32 id, u32 process, u32 flag, u32
pargs); extern phys_addr_t
omap_secure_ram_mempool_base(void); extern int
omap_secure_ram_reserve_memblock(void);
diff --git a/arch/arm/mach-omap2/omap-smc.S
b/arch/arm/mach-omap2/omap-smc.S index f6441c1..fd90125
100644
--- a/arch/arm/mach-omap2/omap-smc.S
+++ b/arch/arm/mach-omap2/omap-smc.S
@@ -1,9 +1,11 @@
/*
- * OMAP44xx secure APIs file.
+ * OMAP34xx and OMAP44xx secure APIs file.
*
* Copyright (C) 2010 Texas Instruments, Inc.
* Written by Santosh Shilimkar santosh.shilim...@ti.com
*
+ * Copyright (C) 2012 Ivaylo Dimitrov freemangor...@abv.bg
+ * Copyright (C) 2013 Pali Rohár pali.ro...@gmail.com
*
* This program is free software,you can redistribute it
and/or modify * it under the terms of the GNU General Public
License version 2 as @@ -54,6 +56,23 @@ ENTRY(omap_smc2)
ldmfd sp!, {r4-r12, pc}
ENDPROC(omap_smc2)
+/**
+ * u32 omap_smc3(u32 service_id, u32 process_id, u32 flag,
u32 pargs) + * Low level common routine for secure HAL and
PPA APIs via smc #1 + * r0 - @service_id: Secure Service ID
+ * r1 - @process_id: Process ID
+ * r2 - @flag: Flag to indicate the criticality of operation
+ * r3 - @pargs: Physical address of parameter list
+ */
+ENTRY(omap_smc3)
+ stmfd sp!, {r4-r11, lr}
+ mov r12, r0 @ Copy the secure service ID
+ mov r6, #0xff @ Indicate new Task call
+ dsb @ Memory Barrier (not sure if needed, copied
from
omap_smc2) +smc #1 @ Call PPA service
+ ldmfd sp!, {r4-r11, pc}
+ENDPROC(omap_smc3)
+
ENTRY(omap_modify_auxcoreboot0)
stmfd sp!, {r1-r12, lr}
ldr r12, =0x104
Dave, it is ok now?
Yes, that's sufficient to warn people to stop and think (at least, if
someone copy-pastes it, they will likely highlight the possible error by
copy-pasting the comment too). Thanks.
Acked-by: Dave Martin dave.mar...@arm.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/4] Create infrastructure for running C code from SRAM.
On Fri, Sep 06, 2013 at 12:14:08PM +0100, Russell King - ARM Linux wrote: On Wed, Sep 04, 2013 at 02:47:51PM -0700, Russ Dill wrote: I think this is already taken care of by the way sram.c is using genalloc. The allocation returned should be aligned to 32 bytes. The thumb bit shouldn't be an issue as code is copied based on the start and end makers made by the linker. I may need to add .align statements in the linker so that the start and end markers for the copied code are aligned to at least 8 bytes. I think you need to read up on what fncpy does... there's more to it than just merely copying code at an appropriate alignment. The technique of putting each loadable blob in a specific vmlinux section, and then adjusting entry-point symbols by adding/subtracting the appropriate offset, probably does work. This relies on the functions' code alignment requirement being honoured by both the vmlinux link map, and the allocator used to find SRAM space to copy the functions to. Searching the entire list of known blobs every time we want to convert a symbol seems unnecessary though. Surely the caller could know the blob-symbol mapping anyway? One thing fncpy() doesn't provide is a way to copy groups of functions that call each other, if vmlinux needs to know about any symbol other than the one at the start. We might need a better mechanism if that is needed. I actually wonder whether fncpy() contains a buglet, whereby flush_icache_range() is used instead of coherent_kern_range(). The SRAM is probably not mapped cached, but at least a DSB would be needed before flushing the relevant lines from the I-cache. However, flush_icache_range() seems to be implemented by a call to coherent_kern_range() anyway, so perhaps that's not a problem. Cheers ---Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/4] Create infrastructure for running C code from SRAM.
On Fri, Sep 06, 2013 at 12:12:21PM +0100, Russell King - ARM Linux wrote:
On Tue, Sep 03, 2013 at 09:44:21AM -0700, Russ Dill wrote:
SRAM handling code is in the process of being moved from arch directories
into drivers/misc/sram.c using device tree and genalloc [1] [2]. This RFC
patchset builds on that, including the limitation that the SRAM address is
not known at compile time. Because the SRAM address is not known at compile
time, the code that runs from SRAM must be compiled with -fPIC. Even if
the code were loaded to a fixed virtual address, portions of the code must
often be run with the MMU disabled.
What are you doing about the various gcc utility functions that may be
implicitly called from C code such as memcpy and memset?
The general idea is that for each SRAM user (such as an SoC specific
suspend/resume mechanism) to create a group of sections. The section group
is created with a single macro for each user, but end up looking like this:
.sram.am33xx : AT(ADDR(.sram.am33xx) - 0) {
__sram_am33xx_start = .;
*(.sram.am33xx.*)
__sram_am33xx_end = .;
}
Any data or functions that should be copied to SRAM for this use should be
maked with an appropriate __section() attribute. A helper is then added for
translating between the original kernel symbol, and the address of that
function or variable once it has been copied into SRAM. Once control is
passed to a function within the SRAM section grouping, it can access any
variables or functions within that same SRAM section grouping without
translation.
What about the relocations which will need to be fixed up - eg, addresses
in the literal pool, the GOT table contents, etc? You say nothing about
this.
I was also thinking about this, and there are more problems.
As well as what has already been mentioned:
* Calls from inside the SRAM code to vmlinux (including lib1funcs etc.)
will typically break, except on architectures where function calls are
(absolute by default not ARM).
* The compiler/linker won't detect unsafe constructs or code generation,
because it assumes that anything built with -fPIC is going to be patched
up later by ld.so or equivalent.
* The GOT is generated by the linker, and is a single table. Yet each
SRAM blob needs to be able to refer to its own GOT entries position-
independently. Moving the blobs independently won't work.
In other words: -fPIC does not generate position-independent code.
It generates position-dependent code that is easier to move around than
non-fPIC code, but you still need a dynamic linker (or equivalent) to
make it all work.
There are various correct ways to handle this, the simplest of which
is probably to build each SRAM blob as a kernel module, embed the result
in the kernel somehow, and then use the module loader infrastructure
to handle fixing the module up to the right address.
But this is still likely to be overkill, given the small scale of the
SRAM code.
Restricting such code to carefully-written assembler (as now) may be
the more practical approrach, unless there's a good example of somewhere
that C code would provide a big benefit.
Cheers
---Dave
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/2] ARM: OMAP: Add secure function omap_smc3() which calling instruction smc #1
On Wed, Sep 04, 2013 at 10:10:29AM +0200, Pali Rohár wrote:
On Sunday 11 August 2013 20:36:40 Ивайло Димитров wrote:
Оригинално писмо
От: Dave Martin
Относно: Re: [PATCH v3 1/2] ARM: OMAP: Add secure function
omap_smc3() which
calling instruction smc #1
До: Pali Rohár
Изпратено на: Понеделник, 2013, Август 5 16:29:44 EEST
On Sun, Aug 04, 2013 at 10:45:00AM +0200, Pali Rohár wrote:
Here is new version (v3) of omap secure part patch:
Other secure functions omap_smc1() and omap_smc2() calling
instruction smc #0 but Nokia RX-51 board needs to call
smc #1 for PPA access.
Signed-off-by: Ivaylo Dimitrov
Signed-off-by: Pali Rohár
---
diff --git a/arch/arm/mach-omap2/omap-secure.h
b/arch/arm/mach-omap2/omap-secure.h index
0e72917..c4586f4 100644
--- a/arch/arm/mach-omap2/omap-secure.h
+++ b/arch/arm/mach-omap2/omap-secure.h
@@ -51,6 +51,7 @@
extern u32 omap_secure_dispatcher(u32 idx, u32 flag, u32
nargs,
u32 arg1, u32 arg2, u32 arg3, u32 arg4);
extern u32 omap_smc2(u32 id, u32 falg, u32 pargs);
+extern u32 omap_smc3(u32 id, u32 process, u32 flag, u32
pargs);
extern phys_addr_t omap_secure_ram_mempool_base(void);
extern int omap_secure_ram_reserve_memblock(void);
diff --git a/arch/arm/mach-omap2/omap-smc.S
b/arch/arm/mach-omap2/omap-smc.S index f6441c1..7bbc043
100644
--- a/arch/arm/mach-omap2/omap-smc.S
+++ b/arch/arm/mach-omap2/omap-smc.S
@@ -1,9 +1,11 @@
/*
- * OMAP44xx secure APIs file.
+ * OMAP34xx and OMAP44xx secure APIs file.
*
* Copyright (C) 2010 Texas Instruments, Inc.
* Written by Santosh Shilimkar
*
+ * Copyright (C) 2012 Ivaylo Dimitrov
+ * Copyright (C) 2013 Pali Rohár
*
* This program is free software,you can redistribute it
and/or modify * it under the terms of the GNU General
Public License version 2 as
@@ -54,6 +56,23 @@ ENTRY(omap_smc2)
ldmfd sp!, {r4-r12, pc}
ENDPROC(omap_smc2)
+/**
+ * u32 omap_smc3(u32 service_id, u32 process_id, u32
flag, u32 pargs) + * Low level common routine for secure
HAL and PPA APIs via smc #1 + * r0 - @service_id: Secure
Service ID
+ * r1 - @process_id: Process ID
+ * r2 - @flag: Flag to indicate the criticality of
operation + * r3 - @pargs: Physical address of parameter
list + */
+ENTRY(omap_smc3)
+ stmfd sp!, {r4-r11, lr}
+ mov r12, r0 @ Copy the secure service ID
+ mov r6, #0xff @ Indicate new Task call
+ dsb @ Memory Barrier
Can you explain _why_ the barrier is there? The reader
doesn't need to be told that a barrier instruction is a
barrier instruction.
Cheers
---Dave
Hi Dave,
Would quoting Santosh's explanation DSBs were needed on OMAP
for power sequencing. do the job? Something like @ Needed
on OMAP for power sequencing instead of @ Memory Barrier.
I want to be sure I correctly understand your requirement.
Regards,
Ivo
Hello,
I'd like to know what happened with this patch? What is needed
for including it into mainline? Note that without with this patch
series Thumb-2 user space binaries crashing.
Apologies, it looks like I missed the previous reply somehow.
Needed for power sequencing is not a good explanation, because
DSB has no direct role in power sequencing.
I'm guessing that the reason for its being needed is either not well
understood (otherwise someone would have offered a real explanation by
now), or it is a secret (errata, whatever) or related to something so
obscure it's likely to be of any interest or use to anyone anyway.
In the former case, just document the uncertainty.
In the latter case, at least document that the reasons are specific to
that platform and probably not applicable to other situations: this
warns someone maintaining or copying the code later that it may not make
sense for them, and they should stop and think. It also avoids people
reading the code for educational purposes and learning incorrect lessons
from it.
I've seen a mail thread where precisely this bad education happened:
someone is trying to figure out whether they need a DSB before every SVC
after reading the mach-omap2 SMC code.
The same goes for the disabling of interrupts around the call in
rx51_secure_dispatcher(). Even if the Secure World might write into the
params struct during the SMC, making the params cacheline_aligned
should be sufficient to avoid the possibility of incoherent S/NS aliases
of the same cacheline clobbering each other. SMC disables all
interrupts on entry to the Secure World anyway, so I can't see what else
the interrupt disabling achieves unless there are platform-specific
Re: [PATCH v3 1/2] ARM: OMAP: Add secure function omap_smc3() which calling instruction smc #1
On Sun, Aug 04, 2013 at 10:45:00AM +0200, Pali Rohár wrote:
Here is new version (v3) of omap secure part patch:
Other secure functions omap_smc1() and omap_smc2() calling instruction smc #0
but Nokia RX-51 board needs to call smc #1 for PPA access.
Signed-off-by: Ivaylo Dimitrov freemangor...@abv.bg
Signed-off-by: Pali Rohár pali.ro...@gmail.com
---
diff --git a/arch/arm/mach-omap2/omap-secure.h
b/arch/arm/mach-omap2/omap-secure.h
index 0e72917..c4586f4 100644
--- a/arch/arm/mach-omap2/omap-secure.h
+++ b/arch/arm/mach-omap2/omap-secure.h
@@ -51,6 +51,7 @@
extern u32 omap_secure_dispatcher(u32 idx, u32 flag, u32 nargs,
u32 arg1, u32 arg2, u32 arg3, u32 arg4);
extern u32 omap_smc2(u32 id, u32 falg, u32 pargs);
+extern u32 omap_smc3(u32 id, u32 process, u32 flag, u32 pargs);
extern phys_addr_t omap_secure_ram_mempool_base(void);
extern int omap_secure_ram_reserve_memblock(void);
diff --git a/arch/arm/mach-omap2/omap-smc.S b/arch/arm/mach-omap2/omap-smc.S
index f6441c1..7bbc043 100644
--- a/arch/arm/mach-omap2/omap-smc.S
+++ b/arch/arm/mach-omap2/omap-smc.S
@@ -1,9 +1,11 @@
/*
- * OMAP44xx secure APIs file.
+ * OMAP34xx and OMAP44xx secure APIs file.
*
* Copyright (C) 2010 Texas Instruments, Inc.
* Written by Santosh Shilimkar santosh.shilim...@ti.com
*
+ * Copyright (C) 2012 Ivaylo Dimitrov freemangor...@abv.bg
+ * Copyright (C) 2013 Pali Rohár pali.ro...@gmail.com
*
* This program is free software,you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
@@ -54,6 +56,23 @@ ENTRY(omap_smc2)
ldmfd sp!, {r4-r12, pc}
ENDPROC(omap_smc2)
+/**
+ * u32 omap_smc3(u32 service_id, u32 process_id, u32 flag, u32 pargs)
+ * Low level common routine for secure HAL and PPA APIs via smc #1
+ * r0 - @service_id: Secure Service ID
+ * r1 - @process_id: Process ID
+ * r2 - @flag: Flag to indicate the criticality of operation
+ * r3 - @pargs: Physical address of parameter list
+ */
+ENTRY(omap_smc3)
+ stmfd sp!, {r4-r11, lr}
+ mov r12, r0 @ Copy the secure service ID
+ mov r6, #0xff @ Indicate new Task call
+ dsb @ Memory Barrier
Can you explain _why_ the barrier is there? The reader doesn't need to
be told that a barrier instruction is a barrier instruction.
Cheers
---Dave
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: Update SMP_ON_UP code to detect A9MPCore with 1 CPU devices
On Thu, Aug 01, 2013 at 02:17:13PM -0400, Santosh Shilimkar wrote: From: Vaibhav Bedia vaibhav.be...@ti.com The generic code is well equipped to differentiate between SMP and UP configurations.However, there are some devices which use Cortex-A9 MP core IP with 1 CPU as configuration. To let these SOCs to co-exist in a CONFIG_SMP=y build by leveraging the SMP_ON_UP support, we need to additionally check the number the cores in Cortex-A9 MPCore configuration. Without such a check in place, the startup code tries to execute ALT_SMP() set of instructions which lead to CPU faults. The issue was spotted on TI's Aegis device and this patch makes now the device work with omap2plus_defconfig which enables SMP by default. The change is kept limited to only Cortex-A9 MPCore detection code. Is there a specific reason why this can't happen for other processors such as A5/7/15? Cheers ---Dave Cc: Will Deacon will.dea...@arm.com Cc: Russell King li...@arm.linux.org.uk Acked-by: Sricharan R r.sricha...@ti.com Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/kernel/head.S | 18 +- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S index 9cf6063..4924b11 100644 --- a/arch/arm/kernel/head.S +++ b/arch/arm/kernel/head.S @@ -486,7 +486,23 @@ __fixup_smp: mrc p15, 0, r0, c0, c0, 5 @ read MPIDR and r0, r0, #0xc000 @ multiprocessing extensions and teq r0, #0x8000 @ not part of a uniprocessor system? - moveq pc, lr @ yes, assume SMP + bne__fixup_smp_on_up@ no, assume UP + + @ Core indicates it is SMP. Check for Aegis SOC where a single + @ Cortex-A9 CPU is present but SMP operations fault. + mov r4, #0x4100 + orr r4, r4, #0xc000 + orr r4, r4, #0x0090 + teq r3, r4 @ Check for ARM Cortex-A9 + movne pc, lr @ Not ARM Cortex-A9, + + mrc p15, 4, r0, c15, c0 @ get SCU base address + teq r0, #0x0@ '0' on actual UP A9 hardware + beq __fixup_smp_on_up @ So its an A9 UP + ldr r0, [r0, #4]@ read SCU Config + and r0, r0, #0x3@ number of CPUs + teq r0, #0x0@ is 1? + movne pc, lr __fixup_smp_on_up: adr r0, 1f -- 1.7.9.5 ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] ARM: OMAP: Add secure function omap_smc3() which calling instruction smc #1
On Thu, Jul 11, 2013 at 03:54:34PM -0400, Santosh Shilimkar wrote:
On Thursday 11 July 2013 03:43 PM, Ивайло Димитров wrote:
Оригинално писмо
От: Dave Martin
Относно: Re: [PATCH v2 1/2] ARM: OMAP: Add secure function omap_smc3()
which
calling instruction smc #1
До: Pali Rohár
Изпратено на: Сряда, 2013, Юли 10 20:45:26 EEST
On Wed, Jul 10, 2013 at 02:59:04PM +0200, Pali Rohár wrote:
Other secure functions omap_smc1() and omap_smc2() calling instruction
smc #0
but Nokia RX-51 board needs to call smc #1 for PPA access.
Signed-off-by: Ivaylo Dimitrov
Signed-off-by: Pali Rohár
---
arch/arm/mach-omap2/omap-secure.h |1 +
arch/arm/mach-omap2/omap-smc.S| 22 +-
2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap-secure.h
b/arch/arm/mach-omap2/omap-secure.h
index 0e72917..c4586f4 100644
--- a/arch/arm/mach-omap2/omap-secure.h
+++ b/arch/arm/mach-omap2/omap-secure.h
@@ -51,6 +51,7 @@
extern u32 omap_secure_dispatcher(u32 idx, u32 flag, u32 nargs,
u32 arg1, u32 arg2, u32 arg3, u32 arg4);
extern u32 omap_smc2(u32 id, u32 falg, u32 pargs);
+extern u32 omap_smc3(u32 id, u32 process, u32 flag, u32 pargs);
extern phys_addr_t omap_secure_ram_mempool_base(void);
extern int omap_secure_ram_reserve_memblock(void);
diff --git a/arch/arm/mach-omap2/omap-smc.S
b/arch/arm/mach-omap2/omap-smc.S
index f6441c1..5c02b8d 100644
--- a/arch/arm/mach-omap2/omap-smc.S
+++ b/arch/arm/mach-omap2/omap-smc.S
@@ -1,9 +1,11 @@
/*
- * OMAP44xx secure APIs file.
+ * OMAP34xx and OMAP44xx secure APIs file.
*
* Copyright (C) 2010 Texas Instruments, Inc.
* Written by Santosh Shilimkar
*
+ * Copyright (C) 2012 Ivaylo Dimitrov
+ * Copyright (C) 2013 Pali Rohár
*
* This program is free software,you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
@@ -54,6 +56,24 @@ ENTRY(omap_smc2)
ldmfd sp!, {r4-r12, pc}
ENDPROC(omap_smc2)
+/**
+ * u32 omap_smc3(u32 service_id, u32 process_id, u32 flag, u32 pargs)
+ * Low level common routine for secure HAL and PPA APIs via smc #1
+ * r0 - @service_id: Secure Service ID
+ * r1 - @process_id: Process ID
+ * r2 - @flag: Flag to indicate the criticality of operation
+ * r3 - @pargs: Physical address of parameter list
+ */
+ENTRY(omap_smc3)
+ stmfd sp!, {r4-r12, lr}
You don't need to save/restore r12. The ABI allows it to be clobbered
across function calls.
+ mov r12, r0 @ Copy the secure service ID
+ mov r6, #0xff @ Indicate new Task call
+ dsb
+ dmb
dsb synchronises a superset of what dmb synchronises, so the dmb here is
not useful.
In any case, any code calling this must flush the region addressed by
r3 beforehand anyway, which will include a dsb as part of its semantics
-- this is how you call it from rx51_secure_dispatcher().
So I think the dsb may not be needed here (?)
Cheers
---Dave
Could be, but I wonder why almost all the kernel code(I am aware of) that
uses SMC and is written by TI, is storing r12 and is using both DSB and
DMB. See arch/arm/mach-omap2/sleep34xx.S or arch/arm/mach-omap2/omap-smc.S
for examples. I'd rather play it safe and leave it that way, unless someone
confirms the other code using SMC has extra DSB/DMB instructions too. I
wouldn't risk passing invalid/stale data to the Secure Monitor to just save
8 bytes and barriers in a performance non-critical code which will be
called only a couple of times during the boot-up process. r12 save/restore
is a legacy from omap_smc2 in omap-smc.S, so I guess it can go away without
much of a trouble.
Dave pointed out about the dsb and r12 to me in another thread. R12 can be
easily removed
but the DSB's were needed on OMAP for power sequencing. Without those, we
have seen
many issues. So you can leave the dsb's to be consistent with rest of the
code.
Consistency is a perfectly good reason, especially in code like this
where a certain code sequence has been proven, but it's preferable to
include brief comments to explain nonetheless.
Difficulty in explaining precisely why something is needed should be a
warning flag that a comment is needed.
Cheers
---Dave
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Latest build results - errors/warnings - lots of them
On Thu, May 02, 2013 at 10:46:21AM +0100, Russell King - ARM Linux wrote: On Thu, May 02, 2013 at 09:34:30AM +0100, Russell King - ARM Linux wrote: On Tue, Apr 30, 2013 at 02:18:42PM -0400, Nicolas Pitre wrote: On Tue, 30 Apr 2013, Dave Martin wrote: On Tue, Apr 30, 2013 at 11:12:12AM -0400, Nicolas Pitre wrote: On Tue, 30 Apr 2013, Dave Martin wrote: On Tue, Apr 30, 2013 at 01:04:20PM +0200, Arnd Bergmann wrote: On Tuesday 30 April 2013, Russell King - ARM Linux wrote: Latest nightly build of 3.9+my for-next+arm-soc's for-next results in a great load of new warnings and errors. arch/arm/common/mcpm_head.S, arch/arm/common/mcpm_platsmp.c, arch/arm/common/vlock.S are the biggest source of errors. [...] arch/arm/common/mcpm_head.S:39: Error: selected processor does not support ARM mode `ubfx r9,r0,#0,#8' arch/arm/common/mcpm_head.S:40: Error: selected processor does not support ARM mode `ubfx r10,r0,#8,#8' arch/arm/common/mcpm_head.S:100: Error: selected processor does not support ARM mode `dmb' arch/arm/common/mcpm_head.S:115: Error: selected processor does not support ARM mode `dmb' arch/arm/common/mcpm_head.S:127: Error: selected processor does not support ARM mode `dmb' arch/arm/common/mcpm_head.S:131: Error: selected processor does not support ARM mode `dmb' arch/arm/common/mcpm_head.S:138: Error: selected processor does not support ARM mode `dsb' arch/arm/common/mcpm_head.S:152: Error: selected processor does not support ARM mode `dmb' arch/arm/common/mcpm_head.S:161: Error: selected processor does not support ARM mode `dmb' arch/arm/common/mcpm_head.S:175: Error: selected processor does not support ARM mode `dmb' arch/arm/common/vlock.S:62: Error: selected processor does not support ARM mode `dmb' arch/arm/common/vlock.S:72: Error: selected processor does not support ARM mode `dmb' arch/arm/common/vlock.S:72: Error: selected processor does not support ARM mode `dsb' arch/arm/common/vlock.S:89: Error: selected processor does not support ARM mode `dmb' arch/arm/common/vlock.S:95: Error: selected processor does not support ARM mode `dmb' arch/arm/common/vlock.S:95: Error: selected processor does not support ARM mode `dsb' arch/arm/common/vlock.S:102: Error: selected processor does not support ARM mode `dmb' arch/arm/common/vlock.S:105: Error: selected processor does not support ARM mode `dsb' Right, the problem here is that the code was never tested with an ARMv6+ARMv7 config. We can either fix it up by adding .arch armv7-a in the assembly files, or by doing the same in the Makefile: AFLAGS_vlock.S += -march=armv7-a AFLAGS_mcpm_head.S += -march=armv7-a Hmmm, this code was tested with ARCH_MULTIPLATFORM, but it looks like no v6 boards were configured in when testing that... Assuming people are OK with the Makefile route, here's a patch for that, build-tested with a v6+v7 ARCH_MULTIPLATFORM config. Isn't the .arch armv7-a route a bit cleaner? That would have been my choice, although I don't feel strongly about it. I don't feel strongly either. We already have the CFLAGS_DISABLE stuff, so it didn't feel that unnatural to add this in the Makefile; but .arch would work equally well. If somebody wants to change it, it's not a problem for me, but I didn't want to create extra disruption by proposing a different patch... Fair enough. Acked-by: Nicolas Pitre n...@linaro.org I see Dave Martin has sent a patch for this without your ack. Was that a mistake? My bad -- Nico asked me to send you the patch, but I neglected to add his ack. ... and the patch in the patch system doesn't apply anyway because its against some other tree. I've no idea what it's against, it's not as the version on the patch advertises (v3.9-rc7) and not even the build tree has the three additional FIQ lines at the end (so it's not in arm-soc): obj-$(CONFIG_PCI_HOST_ITE8152) += it8152.o obj-$(CONFIG_ARM_TIMER_SP804) += timer-sp.o obj-$(CONFIG_MCPM) += mcpm_head.o mcpm_entry.o mcpm_platsmp.o vlock... +AFLAGS_mcpm_head.o := -march=armv7-a +AFLAGS_vlock.o := -march=armv7-a CFLAGS_REMOVE_mcpm_entry.o = -pg obj-$(CONFIG_FIQ_GLUE) += fiq_glue.o fiq_glue_setup.o obj-$(CONFIG_FIQ_DEBUGGER) += fiq_debugger.o So, this is unapplyable. ...and this was a plain screwup up my part. v3.9* could not possibly contain the relevant patches, but somehow I convinced myself I
Re: Latest build results - errors/warnings - lots of them
On Tue, Apr 30, 2013 at 01:04:20PM +0200, Arnd Bergmann wrote: On Tuesday 30 April 2013, Russell King - ARM Linux wrote: Latest nightly build of 3.9+my for-next+arm-soc's for-next results in a great load of new warnings and errors. arch/arm/common/mcpm_head.S, arch/arm/common/mcpm_platsmp.c, arch/arm/common/vlock.S are the biggest source of errors. [...] arch/arm/common/mcpm_head.S:39: Error: selected processor does not support ARM mode `ubfx r9,r0,#0,#8' arch/arm/common/mcpm_head.S:40: Error: selected processor does not support ARM mode `ubfx r10,r0,#8,#8' arch/arm/common/mcpm_head.S:100: Error: selected processor does not support ARM mode `dmb' arch/arm/common/mcpm_head.S:115: Error: selected processor does not support ARM mode `dmb' arch/arm/common/mcpm_head.S:127: Error: selected processor does not support ARM mode `dmb' arch/arm/common/mcpm_head.S:131: Error: selected processor does not support ARM mode `dmb' arch/arm/common/mcpm_head.S:138: Error: selected processor does not support ARM mode `dsb' arch/arm/common/mcpm_head.S:152: Error: selected processor does not support ARM mode `dmb' arch/arm/common/mcpm_head.S:161: Error: selected processor does not support ARM mode `dmb' arch/arm/common/mcpm_head.S:175: Error: selected processor does not support ARM mode `dmb' arch/arm/common/vlock.S:62: Error: selected processor does not support ARM mode `dmb' arch/arm/common/vlock.S:72: Error: selected processor does not support ARM mode `dmb' arch/arm/common/vlock.S:72: Error: selected processor does not support ARM mode `dsb' arch/arm/common/vlock.S:89: Error: selected processor does not support ARM mode `dmb' arch/arm/common/vlock.S:95: Error: selected processor does not support ARM mode `dmb' arch/arm/common/vlock.S:95: Error: selected processor does not support ARM mode `dsb' arch/arm/common/vlock.S:102: Error: selected processor does not support ARM mode `dmb' arch/arm/common/vlock.S:105: Error: selected processor does not support ARM mode `dsb' Right, the problem here is that the code was never tested with an ARMv6+ARMv7 config. We can either fix it up by adding .arch armv7-a in the assembly files, or by doing the same in the Makefile: AFLAGS_vlock.S += -march=armv7-a AFLAGS_mcpm_head.S += -march=armv7-a Hmmm, this code was tested with ARCH_MULTIPLATFORM, but it looks like no v6 boards were configured in when testing that... Assuming people are OK with the Makefile route, here's a patch for that, build-tested with a v6+v7 ARCH_MULTIPLATFORM config. Cheers ---Dave From 193f254689beaa1612d29bcc5ba004a933b37d95 Mon Sep 17 00:00:00 2001 From: Dave Martin dave.mar...@linaro.org Date: Tue, 30 Apr 2013 12:25:04 +0100 Subject: [PATCH 1/3] ARM: mcpm: Add explicit AFLAGS to support v6/v7 multiplatform kernels The full mcpm layer is not likely to be relevant to v6 based platforms, so a multiplatform kernel won't use that code if booted on v6 hardware. This patch modifies the AFLAGS for affected mcpm .S files to specify armv7-a explicitly for that code. Signed-off-by: Dave Martin dave.mar...@linaro.org --- arch/arm/common/Makefile |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/common/Makefile b/arch/arm/common/Makefile index 546a932..d65a0a8 100644 --- a/arch/arm/common/Makefile +++ b/arch/arm/common/Makefile @@ -12,6 +12,8 @@ obj-$(CONFIG_SHARP_SCOOP) += scoop.o obj-$(CONFIG_PCI_HOST_ITE8152) += it8152.o obj-$(CONFIG_ARM_TIMER_SP804) += timer-sp.o obj-$(CONFIG_MCPM) += mcpm_head.o mcpm_entry.o mcpm_platsmp.o vlock.o +AFLAGS_mcpm_head.o := -march=armv7-a +AFLAGS_vlock.o := -march=armv7-a CFLAGS_REMOVE_mcpm_entry.o = -pg obj-$(CONFIG_FIQ_GLUE) += fiq_glue.o fiq_glue_setup.o obj-$(CONFIG_FIQ_DEBUGGER) += fiq_debugger.o -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Latest build results - errors/warnings - lots of them
On Tue, Apr 30, 2013 at 11:12:12AM -0400, Nicolas Pitre wrote: On Tue, 30 Apr 2013, Dave Martin wrote: On Tue, Apr 30, 2013 at 01:04:20PM +0200, Arnd Bergmann wrote: On Tuesday 30 April 2013, Russell King - ARM Linux wrote: Latest nightly build of 3.9+my for-next+arm-soc's for-next results in a great load of new warnings and errors. arch/arm/common/mcpm_head.S, arch/arm/common/mcpm_platsmp.c, arch/arm/common/vlock.S are the biggest source of errors. [...] arch/arm/common/mcpm_head.S:39: Error: selected processor does not support ARM mode `ubfx r9,r0,#0,#8' arch/arm/common/mcpm_head.S:40: Error: selected processor does not support ARM mode `ubfx r10,r0,#8,#8' arch/arm/common/mcpm_head.S:100: Error: selected processor does not support ARM mode `dmb' arch/arm/common/mcpm_head.S:115: Error: selected processor does not support ARM mode `dmb' arch/arm/common/mcpm_head.S:127: Error: selected processor does not support ARM mode `dmb' arch/arm/common/mcpm_head.S:131: Error: selected processor does not support ARM mode `dmb' arch/arm/common/mcpm_head.S:138: Error: selected processor does not support ARM mode `dsb' arch/arm/common/mcpm_head.S:152: Error: selected processor does not support ARM mode `dmb' arch/arm/common/mcpm_head.S:161: Error: selected processor does not support ARM mode `dmb' arch/arm/common/mcpm_head.S:175: Error: selected processor does not support ARM mode `dmb' arch/arm/common/vlock.S:62: Error: selected processor does not support ARM mode `dmb' arch/arm/common/vlock.S:72: Error: selected processor does not support ARM mode `dmb' arch/arm/common/vlock.S:72: Error: selected processor does not support ARM mode `dsb' arch/arm/common/vlock.S:89: Error: selected processor does not support ARM mode `dmb' arch/arm/common/vlock.S:95: Error: selected processor does not support ARM mode `dmb' arch/arm/common/vlock.S:95: Error: selected processor does not support ARM mode `dsb' arch/arm/common/vlock.S:102: Error: selected processor does not support ARM mode `dmb' arch/arm/common/vlock.S:105: Error: selected processor does not support ARM mode `dsb' Right, the problem here is that the code was never tested with an ARMv6+ARMv7 config. We can either fix it up by adding .arch armv7-a in the assembly files, or by doing the same in the Makefile: AFLAGS_vlock.S += -march=armv7-a AFLAGS_mcpm_head.S += -march=armv7-a Hmmm, this code was tested with ARCH_MULTIPLATFORM, but it looks like no v6 boards were configured in when testing that... Assuming people are OK with the Makefile route, here's a patch for that, build-tested with a v6+v7 ARCH_MULTIPLATFORM config. Isn't the .arch armv7-a route a bit cleaner? That would have been my choice, although I don't feel strongly about it. I don't feel strongly either. We already have the CFLAGS_DISABLE stuff, so it didn't feel that unnatural to add this in the Makefile; but .arch would work equally well. If somebody wants to change it, it's not a problem for me, but I didn't want to create extra disruption by proposing a different patch... Cheers ---Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/7] ARM: virt: allow the kernel to be entered in HYP mode
On Sat, Oct 06, 2012 at 09:00:32AM -0700, Tony Lindgren wrote: * Marc Zyngier marc.zyng...@arm.com [121006 03:19]: If so, that indicates some side effect of the safe_svcmode_maskall macro, and I suspect the movs pc, lr bit. Can you try the attached patch? It basically falls back to the previous behaviour if not entered in HYP mode. ... diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h index 658a15d..b21b97f 100644 --- a/arch/arm/include/asm/assembler.h +++ b/arch/arm/include/asm/assembler.h @@ -254,16 +254,17 @@ mov lr , \reg and lr , lr , #MODE_MASK cmp lr , #HYP_MODE - orr \reg , \reg , #PSR_A_BIT | PSR_I_BIT | PSR_F_BIT + orr \reg , \reg , #PSR_I_BIT | PSR_F_BIT bic \reg , \reg , #MODE_MASK orr \reg , \reg , #SVC_MODE THUMB( orr \reg , \reg , #PSR_T_BIT) - msr spsr_cxsf, \reg - adr lr, BSYM(2f) bne 1f + orr \reg, \reg, #PSR_A_BIT + adr lr, BSYM(2f) + msr spsr_cxsf, \reg __MSR_ELR_HYP(14) __ERET -1: movspc, lr +1: msr cpsr_c, \reg 2: .endm The minimal version of this that still boots on my n800 is just the last change of the above patch: --- a/arch/arm/include/asm/assembler.h +++ b/arch/arm/include/asm/assembler.h @@ -263,7 +263,7 @@ THUMB(orr \reg , \reg , #PSR_T_BIT) bne 1f __MSR_ELR_HYP(14) __ERET -1: movspc, lr +1: msr cpsr_c, \reg 2: .endm In an attempt to narrow this down... Can you follow this (i.e., _after_ a known successful switch to SVC mode) (a) mrs \reg, cpsr msr spsr_cxsf, \reg adr \reg, 3f movspc, lr 3: and (b) mrs \reg, cpsr orr \reg, \reg, #CPSR_A_BIT msr cpsr_cxsf, \reg and (c) mrs \reg, cpsr orr \reg, \reg, #CPSR_A_BIT msr spsr_cxsf, \reg adr \reg, 3f movspc, lr 3: If only (a) works, this would suggest that the attempt to set the A bit is causing the problem. If only (b) works, this suggests that the A bit is OK but that some invalid hardware state, or something else we don't understand, is causing exception returns to fail in general. If (a) and (b) work but (c) fails, this suggests that specifically trying to set the A bit via an exception return is problematic. If all of them work then this suggests some invalid hardware state or something else we don't understand, but which is cleared by the initial msr cpsr_c which clobbers the processor mode. Cheers ---Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/7] ARM: virt: allow the kernel to be entered in HYP mode
On Mon, Oct 08, 2012 at 12:01:09PM +0100, Dave Martin wrote: On Sat, Oct 06, 2012 at 09:00:32AM -0700, Tony Lindgren wrote: * Marc Zyngier marc.zyng...@arm.com [121006 03:19]: If so, that indicates some side effect of the safe_svcmode_maskall macro, and I suspect the movs pc, lr bit. Can you try the attached patch? It basically falls back to the previous behaviour if not entered in HYP mode. ... diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h index 658a15d..b21b97f 100644 --- a/arch/arm/include/asm/assembler.h +++ b/arch/arm/include/asm/assembler.h @@ -254,16 +254,17 @@ mov lr , \reg and lr , lr , #MODE_MASK cmp lr , #HYP_MODE - orr \reg , \reg , #PSR_A_BIT | PSR_I_BIT | PSR_F_BIT + orr \reg , \reg , #PSR_I_BIT | PSR_F_BIT bic \reg , \reg , #MODE_MASK orr \reg , \reg , #SVC_MODE THUMB( orr \reg , \reg , #PSR_T_BIT) - msr spsr_cxsf, \reg - adr lr, BSYM(2f) bne 1f + orr \reg, \reg, #PSR_A_BIT + adr lr, BSYM(2f) + msr spsr_cxsf, \reg __MSR_ELR_HYP(14) __ERET -1: movspc, lr +1: msr cpsr_c, \reg 2: .endm The minimal version of this that still boots on my n800 is just the last change of the above patch: --- a/arch/arm/include/asm/assembler.h +++ b/arch/arm/include/asm/assembler.h @@ -263,7 +263,7 @@ THUMB( orr \reg , \reg , #PSR_T_BIT) bne 1f __MSR_ELR_HYP(14) __ERET -1: movspc, lr +1: msr cpsr_c, \reg 2: .endm In an attempt to narrow this down... Can you follow this (i.e., _after_ a known successful switch to SVC mode) (a) mrs \reg, cpsr msr spsr_cxsf, \reg adr \reg, 3f movspc, lr 3: and (b) mrs \reg, cpsr orr \reg, \reg, #CPSR_A_BIT msr cpsr_cxsf, \reg and (c) mrs \reg, cpsr orr \reg, \reg, #CPSR_A_BIT msr spsr_cxsf, \reg adr \reg, 3f movspc, lr 3: If only (a) works, this would suggest that the attempt to set the A bit is causing the problem. If only (b) works, this suggests that the A bit is OK but that some invalid hardware state, or something else we don't understand, is causing exception returns to fail in general. If (a) and (b) work but (c) fails, this suggests that specifically trying to set the A bit via an exception return is problematic. If all of them work then this suggests some invalid hardware state or something else we don't understand, but which is cleared by the initial msr cpsr_c which clobbers the processor mode. Marc Z also just pointed out to me that there is one architecturally valid explanation for why the movs route could fail: if the kernel is entered in System mode for some reason -- this causes msr spsr and movs pc to become UNPREDICTABLE. If this is the explanation, then (a), (b) and (c) should all work, provided the CPU has already been forced out of System mode. Of course, we're not supposed to be entered in System mode ... but since the whole purpose of this code is to force us into a sane state, we should work around it anyway. I think Marc is busy rolling a patch for that. Cheers ---Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v2 2/5] ARM: mm: rename jump labels in v7_flush_dcache_all function
On Thu, Sep 20, 2012 at 11:32:12AM +0100, Lorenzo Pieralisi wrote: On Wed, Sep 19, 2012 at 02:51:56PM +0100, Dave Martin wrote: On Tue, Sep 18, 2012 at 05:35:32PM +0100, Lorenzo Pieralisi wrote: This patch renames jump labels in v7_flush_dcache_all in order to define a specific flush cache levels entry point. TODO: factor out the level flushing loop if considered worthwhile and define the input registers requirements. In the context of this series, this patch seems to do nothing at all (?) Agreed, it is just replacing some labels. I thought that something like: b flush_levels is clearer than: b loop1 If I manage to factor out the cache level flushing loop I think things are even better, I just did not want to change v7_flush_dcache_all, I would avoid doing that, unless, as I mentioned, it is considered worthwhile. Maybe it would make sense to defer this patch until you post something that uses it. v7_flush_dcache_louis uses it, I have no problem in deferring it though. I don't think it's necessary to defer it -- I just wanted to understand whether there was some context here I wasn't aware of. Cheers ---Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v2 3/5] ARM: kernel: update cpu_suspend code to use cache LoUIS operations
On Thu, Sep 20, 2012 at 11:25:14AM +0100, Lorenzo Pieralisi wrote: On Wed, Sep 19, 2012 at 02:46:58PM +0100, Dave Martin wrote: On Tue, Sep 18, 2012 at 05:35:33PM +0100, Lorenzo Pieralisi wrote: In processors like A15/A7 L2 cache is unified and integrated within the processor cache hierarchy, so that it is not considered an outer cache anymore. For processors like A15/A7 flush_cache_all() ends up cleaning all cache levels up to Level of Coherency (LoC) that includes the L2 unified cache. When a single CPU is suspended (CPU idle) a complete L2 clean is not required, so generic cpu_suspend code must clean the data cache using the newly introduced cache LoUIS function. For patches 3-5 in this series, we know that the assumption that flushing LoUIS is sufficient for safely powering the CPU down is not valid in the general case, though we've agreed it's a sensible compromise for the CPU variants we know about today. I agree, but we should also keep in mind that there are suspend and hotplug finishers where platform specific code can (and should sometimes) carry out the required operations, if flushing to LoUIS is not sufficient. Patch 3-5 are there to avoid carrying out heavy cache operations that are not needed, not to define LoUIS as a sufficient cache level for powering down a CPU. Your concern is shared, though. I think we do need to document this assumption, though. At this point I don't mind whether it appears in code comments or in the commit messages. It is a fair point. I will improve comments in the code and commit logs for next version. That should be fine. Since the commit messages use quite precise terminology, I was worried that they could be misinterpreted as stating the correct architectural solution unless we point out that platform code maintainers still need to pay attention to ensure that the correct levels are flushed for their hardware. Cheers ---Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v2 3/5] ARM: kernel: update cpu_suspend code to use cache LoUIS operations
On Tue, Sep 18, 2012 at 05:35:33PM +0100, Lorenzo Pieralisi wrote:
In processors like A15/A7 L2 cache is unified and integrated within the
processor cache hierarchy, so that it is not considered an outer cache
anymore. For processors like A15/A7 flush_cache_all() ends up cleaning
all cache levels up to Level of Coherency (LoC) that includes
the L2 unified cache.
When a single CPU is suspended (CPU idle) a complete L2 clean is not
required, so generic cpu_suspend code must clean the data cache using the
newly introduced cache LoUIS function.
For patches 3-5 in this series, we know that the assumption that
flushing LoUIS is sufficient for safely powering the CPU down is not
valid in the general case, though we've agreed it's a sensible
compromise for the CPU variants we know about today.
I think we do need to document this assumption, though.
At this point I don't mind whether it appears in code comments or in the
commit messages.
Cheers
---Dave
The context and stack pointer (context pointer) are cleaned to main memory
using cache area functions that operate on MVA and guarantee that the data
is written back to main memory (perform cache cleaning up to the Point of
Coherency - PoC) so that the processor can fetch the context when the MMU
is off in the cpu_resume code path.
outer_cache management remains unchanged.
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
---
arch/arm/kernel/suspend.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/arch/arm/kernel/suspend.c b/arch/arm/kernel/suspend.c
index 1794cc3..358bca3 100644
--- a/arch/arm/kernel/suspend.c
+++ b/arch/arm/kernel/suspend.c
@@ -17,6 +17,8 @@ extern void cpu_resume_mmu(void);
*/
void __cpu_suspend_save(u32 *ptr, u32 ptrsz, u32 sp, u32 *save_ptr)
{
+ u32 *ctx = ptr;
+
*save_ptr = virt_to_phys(ptr);
/* This must correspond to the LDM in cpu_resume() assembly */
@@ -26,7 +28,20 @@ void __cpu_suspend_save(u32 *ptr, u32 ptrsz, u32 sp, u32
*save_ptr)
cpu_do_suspend(ptr);
- flush_cache_all();
+ flush_cache_louis();
+
+ /*
+ * flush_cache_louis does not guarantee that
+ * save_ptr and ptr are cleaned to main memory,
+ * just up to the Level of Unification Inner Shareable.
+ * Since the context pointer and context itself
+ * are to be retrieved with the MMU off that
+ * data must be cleaned from all cache levels
+ * to main memory using area cache primitives.
+ */
+ __cpuc_flush_dcache_area(ctx, ptrsz);
+ __cpuc_flush_dcache_area(save_ptr, sizeof(*save_ptr));
+
outer_clean_range(*save_ptr, *save_ptr + ptrsz);
outer_clean_range(virt_to_phys(save_ptr),
virt_to_phys(save_ptr) + sizeof(*save_ptr));
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v2 2/5] ARM: mm: rename jump labels in v7_flush_dcache_all function
On Tue, Sep 18, 2012 at 05:35:32PM +0100, Lorenzo Pieralisi wrote: This patch renames jump labels in v7_flush_dcache_all in order to define a specific flush cache levels entry point. TODO: factor out the level flushing loop if considered worthwhile and define the input registers requirements. In the context of this series, this patch seems to do nothing at all (?) Maybe it would make sense to defer this patch until you post something that uses it. Given that I have a fair expectation that you will build something useful on top of this in the near future, I don't have a strong feeling about it, though. Cheers ---Dave Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com --- arch/arm/mm/cache-v7.S | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/arch/arm/mm/cache-v7.S b/arch/arm/mm/cache-v7.S index d1fa2f6..140b294 100644 --- a/arch/arm/mm/cache-v7.S +++ b/arch/arm/mm/cache-v7.S @@ -48,7 +48,7 @@ ENTRY(v7_flush_dcache_louis) mov r3, r3, lsr #20 @ r3 = LoUIS * 2 moveq pc, lr @ return if level == 0 mov r10, #0 @ r10 (starting level) = 0 - b loop1 @ start flushing cache levels + b flush_levels@ start flushing cache levels ENDPROC(v7_flush_dcache_louis) /* @@ -67,7 +67,7 @@ ENTRY(v7_flush_dcache_all) mov r3, r3, lsr #23 @ left align loc bit field beq finished@ if loc is 0, then no need to clean mov r10, #0 @ start clean at cache level 0 -loop1: +flush_levels: add r2, r10, r10, lsr #1@ work out 3x current cache level mov r1, r0, lsr r2 @ extract cache type bits from clidr and r1, r1, #7 @ mask of the bits for current cache only @@ -89,9 +89,9 @@ loop1: clz r5, r4 @ find bit position of way size increment ldr r7, =0x7fff andsr7, r7, r1, lsr #13 @ extract max number of the index size -loop2: +loop1: mov r9, r4 @ create working copy of max way size -loop3: +loop2: ARM(orr r11, r10, r9, lsl r5) @ factor way and cache number into r11 THUMB( lsl r6, r9, r5 ) THUMB( orr r11, r10, r6) @ factor way and cache number into r11 @@ -100,13 +100,13 @@ loop3: THUMB( orr r11, r11, r6) @ factor index number into r11 mcr p15, 0, r11, c7, c14, 2 @ clean invalidate by set/way subsr9, r9, #1 @ decrement the way - bge loop3 - subsr7, r7, #1 @ decrement the index bge loop2 + subsr7, r7, #1 @ decrement the index + bge loop1 skip: add r10, r10, #2@ increment cache number cmp r3, r10 - bgt loop1 + bgt flush_levels finished: mov r10, #0 @ swith back to cache level 0 mcr p15, 2, r10, c0, c0, 0 @ select current cache level in cssr -- 1.7.12 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/6] ARM: mm: define LoUIS API for cache maintenance ops
On Thu, Sep 13, 2012 at 11:20:46AM +0100, Lorenzo Pieralisi wrote:
ARM v7 architecture introduced the concept of cache levels and related
coherency requirements. New processors like A7 and A15 embed an
L2 unified cache controller that becomes part of the cache level
hierarchy. Some operations in the kernel like cpu_suspend and __cpu_disable
does not require a flush of the entire cache hierarchy to DRAM but just the
cache levels belonging to the Level of Unification Inner Shareable (LoUIS),
which in most of ARM v7 systems correspond to L1.
The current cache flushing API used in cpu_suspend and __cpu_disable,
flush_cache_all(), ends up flushing the whole cache hierarchy since for
v7 it cleans and invalidates all cache levels up to Level of Coherency
(LoC) which cripples system performance when used in hot paths like hotplug
and cpuidle.
Therefore a new kernel cache maintenance API must be added to the
cpu_cache_fns structure of pointers to cope with latest ARM system
requirements.
This patch adds flush_cache_louis() to the ARM kernel cache maintenance API.
This function cleans and invalidates all data cache levels up to the
level of unification inner shareable (LoUIS) and invalidates the instruction
cache.
The cpu_cache_fns struct reflects this change by adding a new function pointer
that is initialized by arch specific assembly files.
By default, all existing ARM archs do not instantiate any cache LoUIS function
pointer, and flush_dcache_louis just falls back to flush_kern_all.
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
---
arch/arm/include/asm/cacheflush.h | 17 +
arch/arm/mm/proc-macros.S | 7 ++-
2 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/cacheflush.h
b/arch/arm/include/asm/cacheflush.h
index c6e2ed9..7683316 100644
--- a/arch/arm/include/asm/cacheflush.h
+++ b/arch/arm/include/asm/cacheflush.h
@@ -50,6 +50,13 @@
*
* Unconditionally clean and invalidate the entire cache.
*
+ * flush_kern_cache_louis()
+ *
+ * Flush data cache levels up to the level of unification
+ * inner shareable and invalidate the I-cache.
+ * Only needed from v7 onwards, falls back to flush_cache_all()
+ * for all other processor versions.
+ *
* flush_user_all()
*
* Clean and invalidate all user space cache entries
@@ -98,6 +105,7 @@
struct cpu_cache_fns {
void (*flush_icache_all)(void);
void (*flush_kern_all)(void);
+ void (*flush_kern_cache_louis)(void);
void (*flush_user_all)(void);
void (*flush_user_range)(unsigned long, unsigned long, unsigned int);
@@ -200,6 +208,15 @@ extern void copy_to_user_page(struct vm_area_struct *,
struct page *,
#define __flush_icache_preferred __flush_icache_all_generic
#endif
+/*
+ * Flush caches up to Level of Unification Inner Shareable
+ */
+#ifdef MULTI_CACHE
+#define flush_cache_louis() cpu_cache.flush_kern_cache_louis()
+#else
+#define flush_cache_louis() __cpuc_flush_kern_all()
+#endif
So, without MULTI_CACHE, we always fall back to flush_kern_all.
I'm guessing this is done because CPUs can't be relied on to provide
flush_kern_cache_louis. Shouldn't this be handled directly?
We could introduce something like CONFIG_ARM_HAVE_CACHEFLUSH_LOUIS, and
do:
asm/glue-cache.h
#ifndef MULTI_CACHE
#ifdef CONFIG_HAVE_ARM_CACHEFLUSH_LOUIS
#define __cpuc_flush_kern_cache_louis __glue(_CACHE,_flush_kern_cache_louis)
#else
#define __cpuc_flush_kern_cache_louis __glue(_CACHE,_flush_kern_all)
#endif
#endif
asm/cacheflush.h
#ifdef MULTI_CACHE
#define flush_cache_louis() cpu_cache.flush_kern_cache_louis()
#else
#define flush_cache_louis() __cpuc_flush_kern_cache_louis()
#endif
Any good?
Then the only question is whether this is worth the complexity.
This only works if the __cpuc_ aliases are not used from assembler.
That seems wrong anyway, since on a MULTI_CACHE kernel those would turn
into C struct member references which wouldn't be valid in assembler
anyway.
Cheers
---Dave
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 4/6] ARM: kernel: update cpu_suspend code to use cache LoUIS operations
On Thu, Sep 13, 2012 at 11:20:49AM +0100, Lorenzo Pieralisi wrote:
In processors like A15/A7 L2 cache is unified and integrated within the
processor cache hierarchy, so that it is not considered an outer cache
anymore. For processors like A15/A7 flush_cache_all() ends up cleaning
all cache levels up to Level of Coherency (LoC) that includes
the L2 unified cache.
When a single CPU is suspended (CPU idle) a complete L2 clean is not
required, so generic cpu_suspend code must clean the data cache using the
newly introduced cache LoUIS function.
The context and stack pointer (context pointer) are cleaned to main memory
using cache area functions that operate on MVA and guarantee that the data
is written back to main memory (perform cache cleaning up to the Point of
Coherency - PoC) so that the processor can fetch the context when the MMU
is off in the cpu_resume code path.
outer_cache management remains unchanged.
LoUIS matches the power domain affected by turning a single CPU off
on most (all?) current v7 SoCs where this matters, but only by coincidence.
There is no guarantee of that.
The _louis() API is useful, because this is exactly what you need to to
I-/D-/TLB synchronisation in an SMP OS. Using it as preparation for
powering a CPU off feels like misuse, at least in theory.
For powerdown, we would logically need a separate function,
flush_cache_cpu() or something, whose job is precisely to flush those
levels which will be affected by the powerdown if that single CPU.
In a multi-cluster system, it's possible that the architectural cache
level this corresponds to is not even the same across all clusters (though
for the foreseeable future it probably will be -- at least for all clusters
participating in SMP).
I don't know how urgent it is to fix this if there are just a few call
sites for flush_cache_louis(). My worry would be that misuse of these
functions propagates before we find that this needs cleaning up...
Cheers
---Dave
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
---
arch/arm/kernel/suspend.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/arch/arm/kernel/suspend.c b/arch/arm/kernel/suspend.c
index 1794cc3..358bca3 100644
--- a/arch/arm/kernel/suspend.c
+++ b/arch/arm/kernel/suspend.c
@@ -17,6 +17,8 @@ extern void cpu_resume_mmu(void);
*/
void __cpu_suspend_save(u32 *ptr, u32 ptrsz, u32 sp, u32 *save_ptr)
{
+ u32 *ctx = ptr;
+
*save_ptr = virt_to_phys(ptr);
/* This must correspond to the LDM in cpu_resume() assembly */
@@ -26,7 +28,20 @@ void __cpu_suspend_save(u32 *ptr, u32 ptrsz, u32 sp, u32
*save_ptr)
cpu_do_suspend(ptr);
- flush_cache_all();
+ flush_cache_louis();
+
+ /*
+ * flush_cache_louis does not guarantee that
+ * save_ptr and ptr are cleaned to main memory,
+ * just up to the Level of Unification Inner Shareable.
+ * Since the context pointer and context itself
+ * are to be retrieved with the MMU off that
+ * data must be cleaned from all cache levels
+ * to main memory using area cache primitives.
+ */
+ __cpuc_flush_dcache_area(ctx, ptrsz);
+ __cpuc_flush_dcache_area(save_ptr, sizeof(*save_ptr));
+
outer_clean_range(*save_ptr, *save_ptr + ptrsz);
outer_clean_range(virt_to_phys(save_ptr),
virt_to_phys(save_ptr) + sizeof(*save_ptr));
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/6] ARM: mm: define LoUIS API for cache maintenance ops
On Thu, Sep 13, 2012 at 02:03:34PM +0100, Russell King - ARM Linux wrote:
On Thu, Sep 13, 2012 at 12:39:49PM +0100, Dave Martin wrote:
We could introduce something like CONFIG_ARM_HAVE_CACHEFLUSH_LOUIS, and
do:
asm/glue-cache.h
#ifndef MULTI_CACHE
#ifdef CONFIG_HAVE_ARM_CACHEFLUSH_LOUIS
#define __cpuc_flush_kern_cache_louis __glue(_CACHE,_flush_kern_cache_louis)
#else
#define __cpuc_flush_kern_cache_louis __glue(_CACHE,_flush_kern_all)
#endif
#endif
asm/cacheflush.h
#ifdef MULTI_CACHE
#define flush_cache_louis() cpu_cache.flush_kern_cache_louis()
#else
#define flush_cache_louis() __cpuc_flush_kern_cache_louis()
#endif
No, this is stupidly complicated and is fragile. Just alias the
functions, like we do in cache-v4wt.S:
.globl v4wt_dma_flush_range
.equv4wt_dma_flush_range, v4wt_dma_inv_range
except, you'll need:
.globl v4wt_flush_kern_cache_louis
.equv4wt_flush_kern_cache_louis, v4wt_flush_kern_cache_all
You can do it automatically, using the attached sedscript and this bit
of shell:
$ for f in $(grep -l define_cache_functions arch/arm/mm/*.S ); do
sed -if sedscript $f
git add $f
done
$ git commit -s
Do that first, and then go over those which you need to add a real
flush_kern_cache_louis function to.
Sure, that works better.
I was trying to think of a more localised way to do it, but the result
was admittedly rather ugly (and not that localised once we select
HAVE_ARM_CACHEFLUSH_LOUIS all over the place).
Cheers
---Dave
1,/__INITDATA\|define struct cpu_cache_fns/ {
/ENTRY.*flush_kern_cache_all/ {
h
s/.*(\([^_]*\)_.*/\t.globl\t\1_flush_kern_cache_louis\n\t.equ\t\1_flush_kern_cache_louis,
\1_flush_kern_cache_all\n/
x
}
/__INITDATA\|define struct cpu_cache_fns/ {
H
g
}
}
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
The linux-input mailing list has been moved
The linux-input mailing list has been moved to vger.kernel.org. See http://vger.kernel.org/vger-lists.html for information on the new list server (or consult your local oracle). Yours virtually, Martin Mares -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4] arm: omap3evm: Add support for an MT9M032 based camera board.
Adds board support for an MT9M032 based camera to omap3evm.
Signed-off-by: Martin Hostettler mar...@neutronstar.dyndns.org
---
arch/arm/mach-omap2/Makefile|3 +-
arch/arm/mach-omap2/board-omap3evm-camera.c | 159 +++
arch/arm/mach-omap2/board-omap3evm.c|4 +
3 files changed, 165 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-omap3evm-camera.c
Changes in V4
* Fix includes
* Add comment to clearify that the mux is a seperate gpio controlled chip.
* remove useless variable initialisation.
Changes in V3
* Added missing copyright and attribution.
* switched to gpio_request_array for gpio init.
* removed device_initcall and added call to omap3_evm_camera_init into
omap3_evm_init
Changes in V2:
* ported to current mainline
* Style fixes
* Fix error handling
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index b009f17..6045789 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -196,7 +196,8 @@ obj-$(CONFIG_MACH_OMAP3530_LV_SOM) +=
board-omap3logic.o
obj-$(CONFIG_MACH_OMAP3_TORPEDO)+= board-omap3logic.o
obj-$(CONFIG_MACH_ENCORE) += board-omap3encore.o
obj-$(CONFIG_MACH_OVERO) += board-overo.o
-obj-$(CONFIG_MACH_OMAP3EVM)+= board-omap3evm.o
+obj-$(CONFIG_MACH_OMAP3EVM)+= board-omap3evm.o \
+ board-omap3evm-camera.o
obj-$(CONFIG_MACH_OMAP3_PANDORA) += board-omap3pandora.o
obj-$(CONFIG_MACH_OMAP_3430SDP)+= board-3430sdp.o
obj-$(CONFIG_MACH_NOKIA_N8X0) += board-n8x0.o
diff --git a/arch/arm/mach-omap2/board-omap3evm-camera.c
b/arch/arm/mach-omap2/board-omap3evm-camera.c
new file mode 100644
index 000..82a4ec2
--- /dev/null
+++ b/arch/arm/mach-omap2/board-omap3evm-camera.c
@@ -0,0 +1,159 @@
+/*
+ * Copyright (C) 2011 Texas Instruments Inc
+ * Copyright (C) 2010-2011 Lund Engineering
+ * Contact: Gil Lund gwl...@lundeng.com
+ * Authors:
+ *Vaibhav Hiremath hvaib...@ti.com
+ *Martin Hostettler mar...@neutronstar.dyndns.org
+ *
+ * Board intregration for a MT9M032 camera connected to IMAGE_CONN and I2C Bus
2
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ */
+
+#include linux/i2c.h
+#include linux/init.h
+#include linux/platform_device.h
+
+#include linux/gpio.h
+#include plat/mux.h
+#include mux.h
+
+#include media/omap3isp.h
+#include media/mt9m032.h
+
+#include devices.h
+
+#define EVM_TWL_GPIO_BASE OMAP_MAX_GPIO_LINES
+#define GPIO98_VID_DEC_RES 98
+#define nCAM_VD_SEL157
+
+#define MT9M032_I2C_BUS_NUM2
+
+
+enum omap3evmdc_mux {
+ MUX_TVP5146,
+ MUX_CAMERA_SENSOR,
+ MUX_EXP_CAMERA_SENSOR,
+};
+
+/**
+ * omap3evm_set_mux - Sets mux to enable signal routing to
+ * different peripherals present on new EVM board
+ * @mux_id: enum, mux id to enable
+ *
+ * Returns 0 for success or a negative error code
+ */
+static int omap3evm_set_mux(enum omap3evmdc_mux mux_id)
+{
+ /*
+* The video mux on the EVM board is controlled by various
+* GPIO pins.
+ */
+ /* Set GPIO6 = 1 */
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 6, 1);
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 0);
+
+ switch (mux_id) {
+ case MUX_TVP5146:
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 0);
+ gpio_set_value(nCAM_VD_SEL, 1);
+ break;
+
+ case MUX_CAMERA_SENSOR:
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 0);
+ gpio_set_value(nCAM_VD_SEL, 0);
+ break;
+
+ case MUX_EXP_CAMERA_SENSOR:
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 1);
+ break;
+
+ default:
+ pr_err(omap3evm-camera: Invalid mux id #%d\n, mux_id);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static struct mt9m032_platform_data mt9m032_platform_data = {
+ .ext_clock = 1350,
+ .pll_pre_div = 6,
+ .pll_mul = 120,
+ .pll_out_div = 5,
+ .invert_pixclock = 1,
+};
+
+static struct i2c_board_info camera_i2c_devices[] = {
+ {
+ I2C_BOARD_INFO(MT9M032_NAME, MT9M032_I2C_ADDR),
+ .platform_data = mt9m032_platform_data
[PATCH v5 REPOST 3/5] omap4: Unconditionally require l2x0 L2 cache controller support
If running in the Normal World on a TrustZone-enabled SoC, Linux does not have complete control over the L2 cache controller configuration. The kernel cannot work reliably on such platforms without the l2x0 cache support code built in. This patch unconditionally enables l2x0 support for the OMAP4 SoCs. Thanks to Rob Herring for this suggestion. [1] [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074495.html Signed-off-by: Dave Martin dave.mar...@linaro.org Acked-by: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap2/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index bb1b670..94e568a 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -41,11 +41,11 @@ config ARCH_OMAP4 bool TI OMAP4 default y depends on ARCH_OMAP2PLUS + select CACHE_L2X0 select CPU_V7 select ARM_GIC select HAVE_SMP select LOCAL_TIMERS if SMP - select MIGHT_HAVE_CACHE_L2X0 select PL310_ERRATA_588369 select PL310_ERRATA_727915 select ARM_ERRATA_720789 -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 REPOST 5/5] imx6q: Remove unconditional dependency on l2x0 L2 cache support
On Thu, Dec 15, 2011 at 09:54:15AM +0800, Richard Zhao wrote: On Thu, Dec 15, 2011 at 09:46:20AM +0800, Shawn Guo wrote: On Thu, Dec 15, 2011 at 09:02:20AM +0800, Richard Zhao wrote: On Wed, Dec 14, 2011 at 03:01:19PM +, Dave Martin wrote: On Wed, Dec 14, 2011 at 10:05:04PM +0800, Richard Zhao wrote: On Wed, Dec 14, 2011 at 09:26:24PM +0800, Shawn Guo wrote: Hi Dave, Sorry for that I did not look into previous post to point it out. On Wed, Dec 14, 2011 at 11:39:41AM +, Dave Martin wrote: The i.MX6 Quad SoC will work without the l2x0 L2 cache controller support built into the kernel, so this patch removes the dependency on CACHE_L2X0 and selects MIGHT_HAVE_CACHE_L2X0 instead. This makes the l2x0 support optional, so that it can be turned off when desired for debugging purposes etc. Thanks to Shawn Guo for this suggestion. [1] Signed-off-by: Dave Martin dave.mar...@linaro.org [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074602.html --- arch/arm/mach-imx/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig index 29a3d61..1fb93f2 100644 --- a/arch/arm/mach-imx/Kconfig +++ b/arch/arm/mach-imx/Kconfig @@ -609,13 +609,13 @@ comment i.MX6 family: config SOC_IMX6Q bool i.MX6 Quad support select ARM_GIC - select CACHE_L2X0 select CPU_V7 select HAVE_ARM_SCU select HAVE_IMX_GPC select HAVE_IMX_MMDC select HAVE_IMX_SRC select HAVE_SMP + select MIGHT_HAVE_CACHE_L2X0 The option SOC_IMX6Q is only available when ARCH_IMX_V6_V7 is selected. Since MIGHT_HAVE_CACHE_L2X0 has been selected by ARCH_IMX_V6_V7 in patch #1, this line seems redundant here. Would it be better keep this one and remove patch #1 one? imx5 doesn't have l2x0. Do you mean to remove MIGHT_HAVE_CACHE_L2X0 from ARCH_IMX_V6_V7, and select it only from SOC_IMX6Q? Yes, I think it's more precise. Shawn? No. * imx5 hardware does have L2, and it's just not set up in the kernel (I do not know why). * Currently, ARCH_IMX_V6_V7 only covers imx3 and imx6, and both are calling l2x0 init function to set L2 up. * When we merge mach-mx5 into mach-imx to have ARCH_IMX_V6_V7 cover imx3, imx5 and imx6, there is no reason for us to not set L2 up for imx5 too. So MIGHT_HAVE_CACHE_L2X0 really should be selected by ARCH_IMX_V6_V7. mx5/cortex-a8 don't use L2X0. But that's ok. MIGHT_HAVE_CACHE_L2X0 is just a hint. Please Shawn's suggestion. OK, my local series has what I believe to be the correct change; I will repost based on that. Cheers ---Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 0/5] Refactor common Kconfigs for easier maintenance
Common Kconfig options which depend on a long list of board- and SoC- specific Kconfigs can be cumbersome to maintain, leading to annoying merge conflicts (although rather trivial ones). This series factors out the dependencies of CACHE_L2X0 and SMP so that the knowledge about when these can be enabled is moved to the relevant board/SoC Kconfig files instead. New MIGHT_HAVE_CACHE_L2X0 and HAVE_SMP options are defined to mediate the dependencies. This series has been substantially reworked compared with the previous post, and is now in two parts: * The first two patches simply refactor the way the Kconfig options for CACHE_L2X0 and SMP are implemented, without making any other changes. * The final three patches apply functional changes suggested by the contributors to this series, to make the config dependencies more correct for some specific boards. Thanks to Rob Herring, Shawn Guo and Russell King for their contributions to this series. Thanks also to David Brown for pointing out the lack of a comprehensive CC list. I have briefly build-tested on some of the affected boards, but any further reviews or Tested-Bys would be much appreciated. Dave Martin (5): ARM: l2x0/pl310: Refactor Kconfig to be more maintainable ARM: SMP: Refactor Kconfig to be more maintainable omap4: Unconditionally require l2x0 L2 cache controller support highbank: Unconditionally require l2x0 L2 cache controller support imx6q: Remove unconditional dependency on l2x0 L2 cache support arch/arm/Kconfig | 26 ++ arch/arm/mach-exynos/Kconfig |2 ++ arch/arm/mach-imx/Kconfig |2 +- arch/arm/mach-msm/Kconfig |1 + arch/arm/mach-omap2/Kconfig|2 ++ arch/arm/mach-realview/Kconfig |9 + arch/arm/mach-vexpress/Kconfig |2 ++ arch/arm/mm/Kconfig| 23 --- arch/arm/plat-mxc/Kconfig |1 + 9 files changed, 56 insertions(+), 12 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 1/5] ARM: l2x0/pl310: Refactor Kconfig to be more maintainable
Making CACHE_L2X0 depend on (huge list of MACH_ and ARCH_ configs) is bothersome to maintain and likely to lead to merge conflicts. This patch moves the knowledge of which platforms have a L2x0 or PL310 cache controller to the individual machines. To enable this, a new MIGHT_HAVE_CACHE_L2X0 config option is introduced to allow machines to indicate that they may have such a cache controller independently of each other. Boards/SoCs which cannot reliably operate without the L2 cache controller support will need to select CACHE_L2X0 directly from their own Kconfigs instead. This applies to some TrustZone-enabled boards where Linux runs in the Normal World, for example. Signed-off-by: Dave Martin dave.mar...@linaro.org Acked-by: Anton Vorontsov cbouatmai...@gmail.com (for cns3xxx) Acked-by: Tony Lindgren t...@atomide.com (for omap) --- Changes: v5: Minor change to the Kconfig help text to make it more informative. arch/arm/Kconfig |8 arch/arm/mach-exynos/Kconfig |1 + arch/arm/mach-omap2/Kconfig|1 + arch/arm/mach-realview/Kconfig |5 + arch/arm/mach-vexpress/Kconfig |1 + arch/arm/mm/Kconfig| 23 --- arch/arm/plat-mxc/Kconfig |1 + 7 files changed, 33 insertions(+), 7 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 44789ef..16a4b9e 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -344,6 +344,7 @@ config ARCH_HIGHBANK select CPU_V7 select GENERIC_CLOCKEVENTS select HAVE_ARM_SCU + select MIGHT_HAVE_CACHE_L2X0 select USE_OF help Support for the Calxeda Highbank SoC based boards. @@ -361,6 +362,7 @@ config ARCH_CNS3XXX select CPU_V6K select GENERIC_CLOCKEVENTS select ARM_GIC + select MIGHT_HAVE_CACHE_L2X0 select MIGHT_HAVE_PCI select PCI_DOMAINS if PCI help @@ -381,6 +383,7 @@ config ARCH_PRIMA2 select GENERIC_CLOCKEVENTS select CLKDEV_LOOKUP select GENERIC_IRQ_CHIP + select MIGHT_HAVE_CACHE_L2X0 select USE_OF select ZONE_DMA help @@ -633,6 +636,7 @@ config ARCH_TEGRA select GENERIC_GPIO select HAVE_CLK select HAVE_SCHED_CLOCK + select MIGHT_HAVE_CACHE_L2X0 select ARCH_HAS_CPUFREQ help This enables support for NVIDIA Tegra based systems (Tegra APX, @@ -703,6 +707,7 @@ config ARCH_SHMOBILE select CLKDEV_LOOKUP select HAVE_MACH_CLKDEV select GENERIC_CLOCKEVENTS + select MIGHT_HAVE_CACHE_L2X0 select NO_IOPORT select SPARSE_IRQ select MULTI_IRQ_HANDLER @@ -904,6 +909,7 @@ config ARCH_U8500 select CLKDEV_LOOKUP select ARCH_REQUIRE_GPIOLIB select ARCH_HAS_CPUFREQ + select MIGHT_HAVE_CACHE_L2X0 help Support for ST-Ericsson's Ux500 architecture @@ -914,6 +920,7 @@ config ARCH_NOMADIK select CPU_ARM926T select CLKDEV_LOOKUP select GENERIC_CLOCKEVENTS + select MIGHT_HAVE_CACHE_L2X0 select ARCH_REQUIRE_GPIOLIB help Support for the Nomadik platform by ST-Ericsson @@ -973,6 +980,7 @@ config ARCH_ZYNQ select ARM_GIC select ARM_AMBA select ICST + select MIGHT_HAVE_CACHE_L2X0 select USE_OF help Support for Xilinx Zynq ARM Cortex A9 Platform diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig index 724ec0f..7f2347b 100644 --- a/arch/arm/mach-exynos/Kconfig +++ b/arch/arm/mach-exynos/Kconfig @@ -17,6 +17,7 @@ choice config ARCH_EXYNOS4 bool SAMSUNG EXYNOS4 + select MIGHT_HAVE_CACHE_L2X0 help Samsung EXYNOS4 SoCs based systems diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 5034147..c841578 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -44,6 +44,7 @@ config ARCH_OMAP4 select CPU_V7 select ARM_GIC select LOCAL_TIMERS if SMP + select MIGHT_HAVE_CACHE_L2X0 select PL310_ERRATA_588369 select PL310_ERRATA_727915 select ARM_ERRATA_720789 diff --git a/arch/arm/mach-realview/Kconfig b/arch/arm/mach-realview/Kconfig index dba6d0c..3dd620f 100644 --- a/arch/arm/mach-realview/Kconfig +++ b/arch/arm/mach-realview/Kconfig @@ -12,6 +12,7 @@ config REALVIEW_EB_A9MP bool Support Multicore Cortex-A9 Tile depends on MACH_REALVIEW_EB select CPU_V7 + select MIGHT_HAVE_CACHE_L2X0 help Enable support for the Cortex-A9MPCore tile fitted to the Realview(R) Emulation Baseboard platform. @@ -21,6 +22,7 @@ config REALVIEW_EB_ARM11MP depends on MACH_REALVIEW_EB select CPU_V6K select ARCH_HAS_BARRIERS if SMP + select MIGHT_HAVE_CACHE_L2X0 help Enable support for the ARM11MPCore tile fitted to the Realview(R
[PATCH v5 2/5] ARM: SMP: Refactor Kconfig to be more maintainable
Making SMP depend on (huge list of MACH_ and ARCH_ configs) is bothersome to maintain and likely to lead to merge conflicts. This patch moves the knowledge of which platforms are SMP-capable to the individual machines. To enable this, a new HAVE_SMP config option is introduced to allow machines to indicate that they can run in a SMP configuration. Signed-off-by: Dave Martin dave.mar...@linaro.org Acked-by: Linus Walleij linus.wall...@linaro.org (for nomadik, ux500) Acked-by: Tony Lindgren t...@atomide.com (for omap) --- Changes: v5: Minor change to the Kconfig help text to make it more informative. arch/arm/Kconfig | 18 ++ arch/arm/mach-exynos/Kconfig |1 + arch/arm/mach-imx/Kconfig |1 + arch/arm/mach-msm/Kconfig |1 + arch/arm/mach-omap2/Kconfig|1 + arch/arm/mach-realview/Kconfig |4 arch/arm/mach-vexpress/Kconfig |1 + 7 files changed, 23 insertions(+), 4 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 16a4b9e..eca82f9 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -344,6 +344,7 @@ config ARCH_HIGHBANK select CPU_V7 select GENERIC_CLOCKEVENTS select HAVE_ARM_SCU + select HAVE_SMP select MIGHT_HAVE_CACHE_L2X0 select USE_OF help @@ -636,6 +637,7 @@ config ARCH_TEGRA select GENERIC_GPIO select HAVE_CLK select HAVE_SCHED_CLOCK + select HAVE_SMP select MIGHT_HAVE_CACHE_L2X0 select ARCH_HAS_CPUFREQ help @@ -706,6 +708,7 @@ config ARCH_SHMOBILE select HAVE_CLK select CLKDEV_LOOKUP select HAVE_MACH_CLKDEV + select HAVE_SMP select GENERIC_CLOCKEVENTS select MIGHT_HAVE_CACHE_L2X0 select NO_IOPORT @@ -909,6 +912,7 @@ config ARCH_U8500 select CLKDEV_LOOKUP select ARCH_REQUIRE_GPIOLIB select ARCH_HAS_CPUFREQ + select HAVE_SMP select MIGHT_HAVE_CACHE_L2X0 help Support for ST-Ericsson's Ux500 architecture @@ -1430,14 +1434,20 @@ menu Kernel Features source kernel/time/Kconfig +config HAVE_SMP + bool + help + This option should be selected by machines which have an SMP- + capable CPU. + + The only effect of this option is to make the SMP-related + options available to the user for configuration. + config SMP bool Symmetric Multi-Processing depends on CPU_V6K || CPU_V7 depends on GENERIC_CLOCKEVENTS - depends on REALVIEW_EB_ARM11MP || REALVIEW_EB_A9MP || \ -MACH_REALVIEW_PB11MP || MACH_REALVIEW_PBX || ARCH_OMAP4 || \ -ARCH_EXYNOS4 || ARCH_TEGRA || ARCH_U8500 || ARCH_VEXPRESS_CA9X4 || \ -ARCH_MSM_SCORPIONMP || ARCH_SHMOBILE || ARCH_HIGHBANK || SOC_IMX6Q + depends on HAVE_SMP depends on MMU select USE_GENERIC_SMP_HELPERS select HAVE_ARM_SCU if !ARCH_MSM_SCORPIONMP diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig index 7f2347b..e1efbca 100644 --- a/arch/arm/mach-exynos/Kconfig +++ b/arch/arm/mach-exynos/Kconfig @@ -17,6 +17,7 @@ choice config ARCH_EXYNOS4 bool SAMSUNG EXYNOS4 + select HAVE_SMP select MIGHT_HAVE_CACHE_L2X0 help Samsung EXYNOS4 SoCs based systems diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig index 5f7f9c2..29a3d61 100644 --- a/arch/arm/mach-imx/Kconfig +++ b/arch/arm/mach-imx/Kconfig @@ -615,6 +615,7 @@ config SOC_IMX6Q select HAVE_IMX_GPC select HAVE_IMX_MMDC select HAVE_IMX_SRC + select HAVE_SMP select USE_OF help diff --git a/arch/arm/mach-msm/Kconfig b/arch/arm/mach-msm/Kconfig index ebde97f..e6beaff 100644 --- a/arch/arm/mach-msm/Kconfig +++ b/arch/arm/mach-msm/Kconfig @@ -67,6 +67,7 @@ config MSM_SOC_REV_A bool config ARCH_MSM_SCORPIONMP bool + select HAVE_SMP config ARCH_MSM_ARM11 bool diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index c841578..bb1b670 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -43,6 +43,7 @@ config ARCH_OMAP4 depends on ARCH_OMAP2PLUS select CPU_V7 select ARM_GIC + select HAVE_SMP select LOCAL_TIMERS if SMP select MIGHT_HAVE_CACHE_L2X0 select PL310_ERRATA_588369 diff --git a/arch/arm/mach-realview/Kconfig b/arch/arm/mach-realview/Kconfig index 3dd620f..c593be4 100644 --- a/arch/arm/mach-realview/Kconfig +++ b/arch/arm/mach-realview/Kconfig @@ -12,6 +12,7 @@ config REALVIEW_EB_A9MP bool Support Multicore Cortex-A9 Tile depends on MACH_REALVIEW_EB select CPU_V7 + select HAVE_SMP select MIGHT_HAVE_CACHE_L2X0 help Enable support for the Cortex-A9MPCore tile fitted to the @@ -22,6 +23,7 @@ config REALVIEW_EB_ARM11MP depends
[PATCH v5 3/5] omap4: Unconditionally require l2x0 L2 cache controller support
If running in the Normal World on a TrustZone-enabled SoC, Linux does not have complete control over the L2 cache controller configuration. The kernel cannot work reliably on such platforms without the l2x0 cache support code built in. This patch unconditionally enables l2x0 support for the OMAP4 SoCs. Thanks to Rob Herring for this suggestion. [1] [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074495.html Signed-off-by: Dave Martin dave.mar...@linaro.org Acked-by: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap2/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index bb1b670..94e568a 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -41,11 +41,11 @@ config ARCH_OMAP4 bool TI OMAP4 default y depends on ARCH_OMAP2PLUS + select CACHE_L2X0 select CPU_V7 select ARM_GIC select HAVE_SMP select LOCAL_TIMERS if SMP - select MIGHT_HAVE_CACHE_L2X0 select PL310_ERRATA_588369 select PL310_ERRATA_727915 select ARM_ERRATA_720789 -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 4/5] highbank: Unconditionally require l2x0 L2 cache controller support
If running in the Normal World on a TrustZone-enabled SoC, Linux does not have complete control over the L2 cache controller configuration. The kernel cannot work reliably on such platforms without the l2x0 cache support code built in. This patch unconditionally enables l2x0 support for the Highbank SoC. Thanks to Rob Herring for this suggestion. [1] [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074495.html Signed-off-by: Dave Martin dave.mar...@linaro.org Acked-by: Rob Herring rob.herr...@calxeda.com --- arch/arm/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index eca82f9..1792146 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -340,12 +340,12 @@ config ARCH_HIGHBANK select ARM_AMBA select ARM_GIC select ARM_TIMER_SP804 + select CACHE_L2X0 select CLKDEV_LOOKUP select CPU_V7 select GENERIC_CLOCKEVENTS select HAVE_ARM_SCU select HAVE_SMP - select MIGHT_HAVE_CACHE_L2X0 select USE_OF help Support for the Calxeda Highbank SoC based boards. -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 5/5] imx6q: Remove unconditional dependency on l2x0 L2 cache support
The i.MX6 Quad SoC will work without the l2x0 L2 cache controller support built into the kernel, so this patch removes the dependency on CACHE_L2X0. This makes the l2x0 support optional, so that it can be turned off when desired for debugging purposes etc. Since SOC_IMX6Q already depends on ARCH_IMX_V6_V7 and ARCH_IMX_V6_V7 selects MIGHT_HAVE_CACHE_L2X0, there is no need to select that option explicitly from SOC_IMX6Q. Thanks to Shawn Guo for this suggestion. [1] [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074602.html Signed-off-by: Dave Martin dave.mar...@linaro.org --- Changes: v5: Don't select MIGHT_HAVE_CACHE_L2X0 directly from SOC_IMX6Q, but instead select implicitly via ARCH_IMX_V6_V7 (which we expect to be selected by other relevant SoCs). Thanks to Shawn for this suggestion. arch/arm/mach-imx/Kconfig |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig index 29a3d61..1530678 100644 --- a/arch/arm/mach-imx/Kconfig +++ b/arch/arm/mach-imx/Kconfig @@ -609,7 +609,6 @@ comment i.MX6 family: config SOC_IMX6Q bool i.MX6 Quad support select ARM_GIC - select CACHE_L2X0 select CPU_V7 select HAVE_ARM_SCU select HAVE_IMX_GPC -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 REPOST 0/5] Refactor common Kconfigs for easier maintenance
Common Kconfig options which depend on a long list of board- and SoC- specific Kconfigs can be cumbersome to maintain, leading to annoying merge conflicts (although rather trivial ones). This series factors out the dependencies of CACHE_L2X0 and SMP so that the knowledge about when these can be enabled is moved to the relevant board/SoC Kconfig files instead. New MIGHT_HAVE_CACHE_L2X0 and HAVE_SMP options are defined to mediate the dependencies. This series has been substantially reworked compared with the previous post, and is now in two parts: * The first two patches simply refactor the way the Kconfig options for CACHE_L2X0 and SMP are implemented, without making any other changes. * The final three patches apply functional changes suggested by the contributors to this series, to make the config dependencies more correct for some specific boards. Thanks to Rob Herring, Shawn Guo and Russell King for their contributions to this series. Thanks also to David Brown for pointing out the lack of a comprehensive CC list. I have briefly build-tested on some of the affected boards, but any further reviews or Tested-Bys would be much appreciated. Dave Martin (5): ARM: l2x0/pl310: Refactor Kconfig to be more maintainable ARM: SMP: Refactor Kconfig to be more maintainable omap4: Unconditionally require l2x0 L2 cache controller support highbank: Unconditionally require l2x0 L2 cache controller support imx6q: Remove unconditional dependency on l2x0 L2 cache support arch/arm/Kconfig | 23 +++ arch/arm/mach-exynos/Kconfig |2 ++ arch/arm/mach-imx/Kconfig |3 ++- arch/arm/mach-msm/Kconfig |1 + arch/arm/mach-omap2/Kconfig|2 ++ arch/arm/mach-realview/Kconfig |9 + arch/arm/mach-vexpress/Kconfig |2 ++ arch/arm/mm/Kconfig| 15 --- arch/arm/plat-mxc/Kconfig |1 + 9 files changed, 46 insertions(+), 12 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 REPOST 1/5] ARM: l2x0/pl310: Refactor Kconfig to be more maintainable
Making CACHE_L2X0 depend on (huge list of MACH_ and ARCH_ configs) is bothersome to maintain and likely to lead to merge conflicts. This patch moves the knowledge of which platforms have a L2x0 or PL310 cache controller to the individual machines. To enable this, a new MIGHT_HAVE_CACHE_L2X0 config option is introduced to allow machines to indicate that they may have such a cache controller independently of each other. Boards/SoCs which cannot reliably operate without the L2 cache controller support will need to select CACHE_L2X0 directly from their own Kconfigs instead. This applies to some TrustZone-enabled boards where Linux runs in the Normal World, for example. Signed-off-by: Dave Martin dave.mar...@linaro.org --- arch/arm/Kconfig |8 arch/arm/mach-exynos/Kconfig |1 + arch/arm/mach-omap2/Kconfig|1 + arch/arm/mach-realview/Kconfig |5 + arch/arm/mach-vexpress/Kconfig |1 + arch/arm/mm/Kconfig| 15 --- arch/arm/plat-mxc/Kconfig |1 + 7 files changed, 25 insertions(+), 7 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 44789ef..16a4b9e 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -344,6 +344,7 @@ config ARCH_HIGHBANK select CPU_V7 select GENERIC_CLOCKEVENTS select HAVE_ARM_SCU + select MIGHT_HAVE_CACHE_L2X0 select USE_OF help Support for the Calxeda Highbank SoC based boards. @@ -361,6 +362,7 @@ config ARCH_CNS3XXX select CPU_V6K select GENERIC_CLOCKEVENTS select ARM_GIC + select MIGHT_HAVE_CACHE_L2X0 select MIGHT_HAVE_PCI select PCI_DOMAINS if PCI help @@ -381,6 +383,7 @@ config ARCH_PRIMA2 select GENERIC_CLOCKEVENTS select CLKDEV_LOOKUP select GENERIC_IRQ_CHIP + select MIGHT_HAVE_CACHE_L2X0 select USE_OF select ZONE_DMA help @@ -633,6 +636,7 @@ config ARCH_TEGRA select GENERIC_GPIO select HAVE_CLK select HAVE_SCHED_CLOCK + select MIGHT_HAVE_CACHE_L2X0 select ARCH_HAS_CPUFREQ help This enables support for NVIDIA Tegra based systems (Tegra APX, @@ -703,6 +707,7 @@ config ARCH_SHMOBILE select CLKDEV_LOOKUP select HAVE_MACH_CLKDEV select GENERIC_CLOCKEVENTS + select MIGHT_HAVE_CACHE_L2X0 select NO_IOPORT select SPARSE_IRQ select MULTI_IRQ_HANDLER @@ -904,6 +909,7 @@ config ARCH_U8500 select CLKDEV_LOOKUP select ARCH_REQUIRE_GPIOLIB select ARCH_HAS_CPUFREQ + select MIGHT_HAVE_CACHE_L2X0 help Support for ST-Ericsson's Ux500 architecture @@ -914,6 +920,7 @@ config ARCH_NOMADIK select CPU_ARM926T select CLKDEV_LOOKUP select GENERIC_CLOCKEVENTS + select MIGHT_HAVE_CACHE_L2X0 select ARCH_REQUIRE_GPIOLIB help Support for the Nomadik platform by ST-Ericsson @@ -973,6 +980,7 @@ config ARCH_ZYNQ select ARM_GIC select ARM_AMBA select ICST + select MIGHT_HAVE_CACHE_L2X0 select USE_OF help Support for Xilinx Zynq ARM Cortex A9 Platform diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig index 724ec0f..7f2347b 100644 --- a/arch/arm/mach-exynos/Kconfig +++ b/arch/arm/mach-exynos/Kconfig @@ -17,6 +17,7 @@ choice config ARCH_EXYNOS4 bool SAMSUNG EXYNOS4 + select MIGHT_HAVE_CACHE_L2X0 help Samsung EXYNOS4 SoCs based systems diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 5034147..c841578 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -44,6 +44,7 @@ config ARCH_OMAP4 select CPU_V7 select ARM_GIC select LOCAL_TIMERS if SMP + select MIGHT_HAVE_CACHE_L2X0 select PL310_ERRATA_588369 select PL310_ERRATA_727915 select ARM_ERRATA_720789 diff --git a/arch/arm/mach-realview/Kconfig b/arch/arm/mach-realview/Kconfig index dba6d0c..3dd620f 100644 --- a/arch/arm/mach-realview/Kconfig +++ b/arch/arm/mach-realview/Kconfig @@ -12,6 +12,7 @@ config REALVIEW_EB_A9MP bool Support Multicore Cortex-A9 Tile depends on MACH_REALVIEW_EB select CPU_V7 + select MIGHT_HAVE_CACHE_L2X0 help Enable support for the Cortex-A9MPCore tile fitted to the Realview(R) Emulation Baseboard platform. @@ -21,6 +22,7 @@ config REALVIEW_EB_ARM11MP depends on MACH_REALVIEW_EB select CPU_V6K select ARCH_HAS_BARRIERS if SMP + select MIGHT_HAVE_CACHE_L2X0 help Enable support for the ARM11MPCore tile fitted to the Realview(R) Emulation Baseboard platform. @@ -39,6 +41,7 @@ config MACH_REALVIEW_PB11MP select CPU_V6K select ARM_GIC select HAVE_PATA_PLATFORM + select MIGHT_HAVE_CACHE_L2X0 select
[PATCH v4 REPOST 2/5] ARM: SMP: Refactor Kconfig to be more maintainable
Making SMP depend on (huge list of MACH_ and ARCH_ configs) is bothersome to maintain and likely to lead to merge conflicts. This patch moves the knowledge of which platforms are SMP-capable to the individual machines. To enable this, a new HAVE_SMP config option is introduced to allow machines to indicate that they can run in a SMP configuration. Signed-off-by: Dave Martin dave.mar...@linaro.org --- arch/arm/Kconfig | 15 +++ arch/arm/mach-exynos/Kconfig |1 + arch/arm/mach-imx/Kconfig |1 + arch/arm/mach-msm/Kconfig |1 + arch/arm/mach-omap2/Kconfig|1 + arch/arm/mach-realview/Kconfig |4 arch/arm/mach-vexpress/Kconfig |1 + 7 files changed, 20 insertions(+), 4 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 16a4b9e..d33eb39 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -344,6 +344,7 @@ config ARCH_HIGHBANK select CPU_V7 select GENERIC_CLOCKEVENTS select HAVE_ARM_SCU + select HAVE_SMP select MIGHT_HAVE_CACHE_L2X0 select USE_OF help @@ -636,6 +637,7 @@ config ARCH_TEGRA select GENERIC_GPIO select HAVE_CLK select HAVE_SCHED_CLOCK + select HAVE_SMP select MIGHT_HAVE_CACHE_L2X0 select ARCH_HAS_CPUFREQ help @@ -706,6 +708,7 @@ config ARCH_SHMOBILE select HAVE_CLK select CLKDEV_LOOKUP select HAVE_MACH_CLKDEV + select HAVE_SMP select GENERIC_CLOCKEVENTS select MIGHT_HAVE_CACHE_L2X0 select NO_IOPORT @@ -909,6 +912,7 @@ config ARCH_U8500 select CLKDEV_LOOKUP select ARCH_REQUIRE_GPIOLIB select ARCH_HAS_CPUFREQ + select HAVE_SMP select MIGHT_HAVE_CACHE_L2X0 help Support for ST-Ericsson's Ux500 architecture @@ -1430,14 +1434,17 @@ menu Kernel Features source kernel/time/Kconfig +config HAVE_SMP + bool + help + This option should be selected by machines which have an SMP- + capable CPU. + config SMP bool Symmetric Multi-Processing depends on CPU_V6K || CPU_V7 depends on GENERIC_CLOCKEVENTS - depends on REALVIEW_EB_ARM11MP || REALVIEW_EB_A9MP || \ -MACH_REALVIEW_PB11MP || MACH_REALVIEW_PBX || ARCH_OMAP4 || \ -ARCH_EXYNOS4 || ARCH_TEGRA || ARCH_U8500 || ARCH_VEXPRESS_CA9X4 || \ -ARCH_MSM_SCORPIONMP || ARCH_SHMOBILE || ARCH_HIGHBANK || SOC_IMX6Q + depends on HAVE_SMP depends on MMU select USE_GENERIC_SMP_HELPERS select HAVE_ARM_SCU if !ARCH_MSM_SCORPIONMP diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig index 7f2347b..e1efbca 100644 --- a/arch/arm/mach-exynos/Kconfig +++ b/arch/arm/mach-exynos/Kconfig @@ -17,6 +17,7 @@ choice config ARCH_EXYNOS4 bool SAMSUNG EXYNOS4 + select HAVE_SMP select MIGHT_HAVE_CACHE_L2X0 help Samsung EXYNOS4 SoCs based systems diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig index 5f7f9c2..29a3d61 100644 --- a/arch/arm/mach-imx/Kconfig +++ b/arch/arm/mach-imx/Kconfig @@ -615,6 +615,7 @@ config SOC_IMX6Q select HAVE_IMX_GPC select HAVE_IMX_MMDC select HAVE_IMX_SRC + select HAVE_SMP select USE_OF help diff --git a/arch/arm/mach-msm/Kconfig b/arch/arm/mach-msm/Kconfig index ebde97f..e6beaff 100644 --- a/arch/arm/mach-msm/Kconfig +++ b/arch/arm/mach-msm/Kconfig @@ -67,6 +67,7 @@ config MSM_SOC_REV_A bool config ARCH_MSM_SCORPIONMP bool + select HAVE_SMP config ARCH_MSM_ARM11 bool diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index c841578..bb1b670 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -43,6 +43,7 @@ config ARCH_OMAP4 depends on ARCH_OMAP2PLUS select CPU_V7 select ARM_GIC + select HAVE_SMP select LOCAL_TIMERS if SMP select MIGHT_HAVE_CACHE_L2X0 select PL310_ERRATA_588369 diff --git a/arch/arm/mach-realview/Kconfig b/arch/arm/mach-realview/Kconfig index 3dd620f..c593be4 100644 --- a/arch/arm/mach-realview/Kconfig +++ b/arch/arm/mach-realview/Kconfig @@ -12,6 +12,7 @@ config REALVIEW_EB_A9MP bool Support Multicore Cortex-A9 Tile depends on MACH_REALVIEW_EB select CPU_V7 + select HAVE_SMP select MIGHT_HAVE_CACHE_L2X0 help Enable support for the Cortex-A9MPCore tile fitted to the @@ -22,6 +23,7 @@ config REALVIEW_EB_ARM11MP depends on MACH_REALVIEW_EB select CPU_V6K select ARCH_HAS_BARRIERS if SMP + select HAVE_SMP select MIGHT_HAVE_CACHE_L2X0 help Enable support for the ARM11MPCore tile fitted to the Realview(R) @@ -41,6 +43,7 @@ config MACH_REALVIEW_PB11MP select CPU_V6K select ARM_GIC select HAVE_PATA_PLATFORM
[PATCH v4 REPOST 4/5] highbank: Unconditionally require l2x0 L2 cache controller support
If running in the Normal World on a TrustZone-enabled SoC, Linux does not have complete control over the L2 cache controller configuration. The kernel cannot work reliably on such platforms without the l2x0 cache support code built in. This patch unconditionally enables l2x0 support for the Highbank SoC. Thanks to Rob Herring for this suggestion. [1] Signed-off-by: Dave Martin dave.mar...@linaro.org [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074495.html --- arch/arm/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index d33eb39..744296d 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -340,12 +340,12 @@ config ARCH_HIGHBANK select ARM_AMBA select ARM_GIC select ARM_TIMER_SP804 + select CACHE_L2X0 select CLKDEV_LOOKUP select CPU_V7 select GENERIC_CLOCKEVENTS select HAVE_ARM_SCU select HAVE_SMP - select MIGHT_HAVE_CACHE_L2X0 select USE_OF help Support for the Calxeda Highbank SoC based boards. -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 REPOST 3/5] omap4: Unconditionally require l2x0 L2 cache controller support
If running in the Normal World on a TrustZone-enabled SoC, Linux does not have complete control over the L2 cache controller configuration. The kernel cannot work reliably on such platforms without the l2x0 cache support code built in. This patch unconditionally enables l2x0 support for the OMAP4 SoCs. Thanks to Rob Herring for this suggestion. [1] Signed-off-by: Dave Martin dave.mar...@linaro.org [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074495.html --- arch/arm/mach-omap2/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index bb1b670..94e568a 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -41,11 +41,11 @@ config ARCH_OMAP4 bool TI OMAP4 default y depends on ARCH_OMAP2PLUS + select CACHE_L2X0 select CPU_V7 select ARM_GIC select HAVE_SMP select LOCAL_TIMERS if SMP - select MIGHT_HAVE_CACHE_L2X0 select PL310_ERRATA_588369 select PL310_ERRATA_727915 select ARM_ERRATA_720789 -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 REPOST 5/5] imx6q: Remove unconditional dependency on l2x0 L2 cache support
The i.MX6 Quad SoC will work without the l2x0 L2 cache controller support built into the kernel, so this patch removes the dependency on CACHE_L2X0 and selects MIGHT_HAVE_CACHE_L2X0 instead. This makes the l2x0 support optional, so that it can be turned off when desired for debugging purposes etc. Thanks to Shawn Guo for this suggestion. [1] Signed-off-by: Dave Martin dave.mar...@linaro.org [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074602.html --- arch/arm/mach-imx/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig index 29a3d61..1fb93f2 100644 --- a/arch/arm/mach-imx/Kconfig +++ b/arch/arm/mach-imx/Kconfig @@ -609,13 +609,13 @@ comment i.MX6 family: config SOC_IMX6Q bool i.MX6 Quad support select ARM_GIC - select CACHE_L2X0 select CPU_V7 select HAVE_ARM_SCU select HAVE_IMX_GPC select HAVE_IMX_MMDC select HAVE_IMX_SRC select HAVE_SMP + select MIGHT_HAVE_CACHE_L2X0 select USE_OF help -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 REPOST 4/5] highbank: Unconditionally require l2x0 L2 cache controller support
On Wed, Dec 14, 2011 at 07:37:32AM -0600, Rob Herring wrote: On 12/14/2011 05:39 AM, Dave Martin wrote: If running in the Normal World on a TrustZone-enabled SoC, Linux does not have complete control over the L2 cache controller configuration. The kernel cannot work reliably on such platforms without the l2x0 cache support code built in. This patch unconditionally enables l2x0 support for the Highbank SoC. Thanks to Rob Herring for this suggestion. [1] Signed-off-by: Dave Martin dave.mar...@linaro.org [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074495.html Doesn't this need to be above the SOB? Otherwise: You may be right ... certainly I see no reason _not_ to change it. So I'll change it. Acked-by: Rob Herring rob.herr...@calxeda.com Thanks ---Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 REPOST 5/5] imx6q: Remove unconditional dependency on l2x0 L2 cache support
On Wed, Dec 14, 2011 at 10:05:04PM +0800, Richard Zhao wrote: On Wed, Dec 14, 2011 at 09:26:24PM +0800, Shawn Guo wrote: Hi Dave, Sorry for that I did not look into previous post to point it out. On Wed, Dec 14, 2011 at 11:39:41AM +, Dave Martin wrote: The i.MX6 Quad SoC will work without the l2x0 L2 cache controller support built into the kernel, so this patch removes the dependency on CACHE_L2X0 and selects MIGHT_HAVE_CACHE_L2X0 instead. This makes the l2x0 support optional, so that it can be turned off when desired for debugging purposes etc. Thanks to Shawn Guo for this suggestion. [1] Signed-off-by: Dave Martin dave.mar...@linaro.org [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074602.html --- arch/arm/mach-imx/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig index 29a3d61..1fb93f2 100644 --- a/arch/arm/mach-imx/Kconfig +++ b/arch/arm/mach-imx/Kconfig @@ -609,13 +609,13 @@ comment i.MX6 family: config SOC_IMX6Q bool i.MX6 Quad support select ARM_GIC - select CACHE_L2X0 select CPU_V7 select HAVE_ARM_SCU select HAVE_IMX_GPC select HAVE_IMX_MMDC select HAVE_IMX_SRC select HAVE_SMP + select MIGHT_HAVE_CACHE_L2X0 The option SOC_IMX6Q is only available when ARCH_IMX_V6_V7 is selected. Since MIGHT_HAVE_CACHE_L2X0 has been selected by ARCH_IMX_V6_V7 in patch #1, this line seems redundant here. Would it be better keep this one and remove patch #1 one? imx5 doesn't have l2x0. Do you mean to remove MIGHT_HAVE_CACHE_L2X0 from ARCH_IMX_V6_V7, and select it only from SOC_IMX6Q? Cheers ---Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] arm: omap3evm: Add support for an MT9M032 based camera board.
On Wed, Dec 14, 2011 at 11:31:35AM +0200, Igor Grinberg wrote:
Hi Martin,
On 12/14/11 03:25, Martin Hostettler wrote:
Adds board support for an MT9M032 based camera to omap3evm.
Signed-off-by: Martin Hostettler mar...@neutronstar.dyndns.org
---
arch/arm/mach-omap2/Makefile|3 +-
arch/arm/mach-omap2/board-omap3evm-camera.c | 155
+++
arch/arm/mach-omap2/board-omap3evm.c|4 +
3 files changed, 161 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-omap3evm-camera.c
Changes in V3
* Added missing copyright and attribution.
* switched to gpio_request_array for gpio init.
* removed device_initcall and added call to omap3_evm_camera_init into
omap3_evm_init
Changes in V2:
* ported to current mainline
* Style fixes
* Fix error handling
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index b009f17..6045789 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -196,7 +196,8 @@ obj-$(CONFIG_MACH_OMAP3530_LV_SOM) +=
board-omap3logic.o
obj-$(CONFIG_MACH_OMAP3_TORPEDO)+= board-omap3logic.o
obj-$(CONFIG_MACH_ENCORE) += board-omap3encore.o
obj-$(CONFIG_MACH_OVERO) += board-overo.o
-obj-$(CONFIG_MACH_OMAP3EVM)+= board-omap3evm.o
+obj-$(CONFIG_MACH_OMAP3EVM)+= board-omap3evm.o \
+ board-omap3evm-camera.o
obj-$(CONFIG_MACH_OMAP3_PANDORA) += board-omap3pandora.o
obj-$(CONFIG_MACH_OMAP_3430SDP)+= board-3430sdp.o
obj-$(CONFIG_MACH_NOKIA_N8X0) += board-n8x0.o
diff --git a/arch/arm/mach-omap2/board-omap3evm-camera.c
b/arch/arm/mach-omap2/board-omap3evm-camera.c
new file mode 100644
index 000..bffd5b8
--- /dev/null
+++ b/arch/arm/mach-omap2/board-omap3evm-camera.c
@@ -0,0 +1,155 @@
+/*
+ * Copyright (C) 2011 Texas Instruments Inc
+ * Copyright (C) 2010-2011 Lund Engineering
+ * Contact: Gil Lund gwl...@lundeng.com
+ * Authors:
+ *Vaibhav Hiremath hvaib...@ti.com
+ *Martin Hostettler mar...@neutronstar.dyndns.org
+ *
+ * Board intregration for a MT9M032 camera connected to IMAGE_CONN and I2C
Bus 2
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ */
+
+#include linux/i2c.h
+#include linux/init.h
+#include linux/platform_device.h
+
+#include linux/gpio.h
+#include plat/mux.h
+#include mux.h
+
+#include ../../../drivers/media/video/omap3isp/isp.h
Laurent,
In one of the previous reviews, you stated:
I'll probably split it and move the part required by board files to
include/media/omap3isp.h.
Is there any progress on that?
+#include media/mt9m032.h
+
+#include devices.h
+
+#define EVM_TWL_GPIO_BASE OMAP_MAX_GPIO_LINES
+#define GPIO98_VID_DEC_RES 98
+#define nCAM_VD_SEL157
+
+#define MT9M032_I2C_BUS_NUM2
+
+
+enum omap3evmdc_mux {
+ MUX_TVP5146,
+ MUX_CAMERA_SENSOR,
+ MUX_EXP_CAMERA_SENSOR,
+};
+
+/**
+ * omap3evm_set_mux - Sets mux to enable signal routing to
+ * different peripherals present on new EVM board
+ * @mux_id: enum, mux id to enable
+ *
+ * Returns 0 for success or a negative error code
+ */
+static int omap3evm_set_mux(enum omap3evmdc_mux mux_id)
+{
+ /* Set GPIO6 = 1 */
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 6, 1);
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 0);
+
+ switch (mux_id) {
+ case MUX_TVP5146:
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 0);
+ gpio_set_value(nCAM_VD_SEL, 1);
+ break;
+
+ case MUX_CAMERA_SENSOR:
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 0);
+ gpio_set_value(nCAM_VD_SEL, 0);
+ break;
+
+ case MUX_EXP_CAMERA_SENSOR:
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 1);
+ break;
+
+ default:
+ pr_err(omap3evm-camera: Invalid mux id #%d\n, mux_id);
+ return -EINVAL;
+ }
+
+ return 0;
+}
I don't really care about that, but I don't see any mux
being set in the above function so the name and comments
are misleading.
There's are video
Re: [PATCH v3] arm: omap3evm: Add support for an MT9M032 based camera board.
On Wed, Dec 14, 2011 at 02:15:22PM +0100, Laurent Pinchart wrote: Hi Igor, On Wednesday 14 December 2011 10:31:35 Igor Grinberg wrote: On 12/14/11 03:25, Martin Hostettler wrote: Adds board support for an MT9M032 based camera to omap3evm. Signed-off-by: Martin Hostettler mar...@neutronstar.dyndns.org [snip] diff --git a/arch/arm/mach-omap2/board-omap3evm-camera.c b/arch/arm/mach-omap2/board-omap3evm-camera.c new file mode 100644 index 000..bffd5b8 --- /dev/null +++ b/arch/arm/mach-omap2/board-omap3evm-camera.c @@ -0,0 +1,155 @@ [snip] +#include linux/i2c.h +#include linux/init.h +#include linux/platform_device.h + +#include linux/gpio.h +#include plat/mux.h +#include mux.h + +#include ../../../drivers/media/video/omap3isp/isp.h Laurent, In one of the previous reviews, you stated: I'll probably split it and move the part required by board files to include/media/omap3isp.h. Is there any progress on that? Yes, it has been half-fixed in mainline. Half only because all the structures and macros that should be used by board code are now in media/omap3isp.h, but some boards need to access OMAP3 ISP internals from board code, which still requires drivers/media/video/omap3isp/isp.h. This will eventually be fixed, when the generic struct clk object will be available. After a quick look at this patch it seems that media/omap3isp.h should be enough here. Almost. The code uses ISPCTRL_PAR_BRIDGE_DISABLE which is only available from drivers/media/video/omap3isp/ispreg.h. So i'd say it's better to keep that include than to duplicate this constant in the code. What do you think? By the way, it seems drivers/media/video/omap3isp/ispvideo.c is missing a #include linux/module.h at the moment. I had to patch that line in to get omap3isp to compile as module. +#include media/mt9m032.h And this should be media/mt9m032.h I'll change this. Regards, - Martin Hostettler +#include devices.h -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 REPOST 3/5] omap4: Unconditionally require l2x0 L2 cache controller support
On Wed, Dec 14, 2011 at 10:14:25AM -0800, Tony Lindgren wrote: * Dave Martin dave.mar...@linaro.org [111214 03:08]: If running in the Normal World on a TrustZone-enabled SoC, Linux does not have complete control over the L2 cache controller configuration. The kernel cannot work reliably on such platforms without the l2x0 cache support code built in. There are HS and GP omaps (High Security and General Purpose). GP omaps do have full control of the L2. Also HS omaps most likely provide control over enabling and disabling L2 depending how the secure code is implemented. BTW, the real problem is that because the secure code is implemented in various ways, we don't really have any handling for it in Linux. The SMI instruction numbers don't seem to be standardized at all, and can mean different things on different boards, even different board versions :( Sounds like devicetree is the only safe way to deal with the L2 control options. Regards, Tony This patch unconditionally enables l2x0 support for the OMAP4 SoCs. Thanks to Rob Herring for this suggestion. [1] Signed-off-by: Dave Martin dave.mar...@linaro.org [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074495.html --- arch/arm/mach-omap2/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index bb1b670..94e568a 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -41,11 +41,11 @@ config ARCH_OMAP4 bool TI OMAP4 default y depends on ARCH_OMAP2PLUS + select CACHE_L2X0 select CPU_V7 select ARM_GIC select HAVE_SMP select LOCAL_TIMERS if SMP - select MIGHT_HAVE_CACHE_L2X0 select PL310_ERRATA_588369 select PL310_ERRATA_727915 select ARM_ERRATA_720789 -- 1.7.4.1 To clarify, are you suggesting we retain this patch, or not? (If we only know what l2x0 support will be needed once the dts is parsed at runtime, there could be an argument for keeping the select CACHE_L2X0 here -- unless we have specific kconfigs for the different security variants of omap.) Cheers ---Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] arm: omap3evm: Add support for an MT9M032 based camera board.
Adds board support for an MT9M032 based camera to omap3evm.
Signed-off-by: Martin Hostettler mar...@neutronstar.dyndns.org
---
arch/arm/mach-omap2/Makefile|3 +-
arch/arm/mach-omap2/board-omap3evm-camera.c | 155 +++
arch/arm/mach-omap2/board-omap3evm.c|4 +
3 files changed, 161 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-omap3evm-camera.c
Changes in V3
* Added missing copyright and attribution.
* switched to gpio_request_array for gpio init.
* removed device_initcall and added call to omap3_evm_camera_init into
omap3_evm_init
Changes in V2:
* ported to current mainline
* Style fixes
* Fix error handling
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index b009f17..6045789 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -196,7 +196,8 @@ obj-$(CONFIG_MACH_OMAP3530_LV_SOM) +=
board-omap3logic.o
obj-$(CONFIG_MACH_OMAP3_TORPEDO)+= board-omap3logic.o
obj-$(CONFIG_MACH_ENCORE) += board-omap3encore.o
obj-$(CONFIG_MACH_OVERO) += board-overo.o
-obj-$(CONFIG_MACH_OMAP3EVM)+= board-omap3evm.o
+obj-$(CONFIG_MACH_OMAP3EVM)+= board-omap3evm.o \
+ board-omap3evm-camera.o
obj-$(CONFIG_MACH_OMAP3_PANDORA) += board-omap3pandora.o
obj-$(CONFIG_MACH_OMAP_3430SDP)+= board-3430sdp.o
obj-$(CONFIG_MACH_NOKIA_N8X0) += board-n8x0.o
diff --git a/arch/arm/mach-omap2/board-omap3evm-camera.c
b/arch/arm/mach-omap2/board-omap3evm-camera.c
new file mode 100644
index 000..bffd5b8
--- /dev/null
+++ b/arch/arm/mach-omap2/board-omap3evm-camera.c
@@ -0,0 +1,155 @@
+/*
+ * Copyright (C) 2011 Texas Instruments Inc
+ * Copyright (C) 2010-2011 Lund Engineering
+ * Contact: Gil Lund gwl...@lundeng.com
+ * Authors:
+ *Vaibhav Hiremath hvaib...@ti.com
+ *Martin Hostettler mar...@neutronstar.dyndns.org
+ *
+ * Board intregration for a MT9M032 camera connected to IMAGE_CONN and I2C Bus
2
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ */
+
+#include linux/i2c.h
+#include linux/init.h
+#include linux/platform_device.h
+
+#include linux/gpio.h
+#include plat/mux.h
+#include mux.h
+
+#include ../../../drivers/media/video/omap3isp/isp.h
+#include media/mt9m032.h
+
+#include devices.h
+
+#define EVM_TWL_GPIO_BASE OMAP_MAX_GPIO_LINES
+#define GPIO98_VID_DEC_RES 98
+#define nCAM_VD_SEL157
+
+#define MT9M032_I2C_BUS_NUM2
+
+
+enum omap3evmdc_mux {
+ MUX_TVP5146,
+ MUX_CAMERA_SENSOR,
+ MUX_EXP_CAMERA_SENSOR,
+};
+
+/**
+ * omap3evm_set_mux - Sets mux to enable signal routing to
+ * different peripherals present on new EVM board
+ * @mux_id: enum, mux id to enable
+ *
+ * Returns 0 for success or a negative error code
+ */
+static int omap3evm_set_mux(enum omap3evmdc_mux mux_id)
+{
+ /* Set GPIO6 = 1 */
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 6, 1);
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 0);
+
+ switch (mux_id) {
+ case MUX_TVP5146:
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 0);
+ gpio_set_value(nCAM_VD_SEL, 1);
+ break;
+
+ case MUX_CAMERA_SENSOR:
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 0);
+ gpio_set_value(nCAM_VD_SEL, 0);
+ break;
+
+ case MUX_EXP_CAMERA_SENSOR:
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 1);
+ break;
+
+ default:
+ pr_err(omap3evm-camera: Invalid mux id #%d\n, mux_id);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static struct mt9m032_platform_data mt9m032_platform_data = {
+ .ext_clock = 1350,
+ .pll_pre_div = 6,
+ .pll_mul = 120,
+ .pll_out_div = 5,
+ .invert_pixclock = 1,
+};
+
+static struct i2c_board_info camera_i2c_devices[] = {
+ {
+ I2C_BOARD_INFO(MT9M032_NAME, MT9M032_I2C_ADDR),
+ .platform_data = mt9m032_platform_data,
+ },
+};
+
+static struct isp_subdev_i2c_board_info camera_i2c_subdevs[] = {
+ {
+ .board_info = camera_i2c_devices[0],
+ .i2c_adapter_id = MT9M032_I2C_BUS_NUM,
+ },
+ {},
+};
+
+static
Re: [PATCH v2] arm: omap3evm: Add support for an MT9M032 based camera board.
On Sun, Sep 18, 2011 at 11:58:55PM +0200, Laurent Pinchart wrote: Hi Martin, On Saturday 17 September 2011 11:34:57 Martin Hostettler wrote: Adds board support for an MT9M032 based camera to omap3evm. Sigend-off-by: Martin Hostettler mar...@neutronstar.dyndns.org --- arch/arm/mach-omap2/Makefile|1 + arch/arm/mach-omap2/board-omap3evm-camera.c | 183 +++ 2 files changed, 184 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-omap2/board-omap3evm-camera.c Changes in V2: * ported to current mainline * Style fixes * Fix error handling diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index f343365..8ae3d25 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile + return 0; + +err_8: + gpio_free(EVM_TWL_GPIO_BASE + 8); +err_2: + gpio_free(EVM_TWL_GPIO_BASE + 2); +err_vdsel: + gpio_free(nCAM_VD_SEL); +err: + return ret; +} + +device_initcall(camera_init); Please don't use device_initcall(), but call the function directly from the OMAP3 EVM init handler. Otherwise camera_init() will be called if OMAP3 EVM support is compiled in the kernel, regardless of the board the kernel runs on. Ok, will do. In which header should the prototyp of that function go? Or can i just add a prototyp to board-omap3evm.c directly? I couldn't find anything that looked right, this is rather board specific after all. - Martin Hostettler -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] arm: omap3evm: Add support for an MT9M032 based camera board.
On Mon, Sep 19, 2011 at 11:37:37AM +0530, Hiremath, Vaibhav wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Laurent Pinchart Sent: Monday, September 19, 2011 3:29 AM To: Martin Hostettler Cc: Tony Lindgren; linux-omap@vger.kernel.org; linux- me...@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: Re: [PATCH v2] arm: omap3evm: Add support for an MT9M032 based camera board. Hi Martin, On Saturday 17 September 2011 11:34:57 Martin Hostettler wrote: Adds board support for an MT9M032 based camera to omap3evm. Sigend-off-by: Martin Hostettler mar...@neutronstar.dyndns.org --- arch/arm/mach-omap2/Makefile|1 + arch/arm/mach-omap2/board-omap3evm-camera.c | 183 +++ 2 files changed, 184 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-omap2/board-omap3evm-camera.c Changes in V2: * ported to current mainline * Style fixes * Fix error handling diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index f343365..8ae3d25 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -202,6 +202,7 @@ obj-$(CONFIG_MACH_OMAP3_TORPEDO)+= board-omap3logic.o \ obj-$(CONFIG_MACH_OVERO) += board-overo.o \ hsmmc.o obj-$(CONFIG_MACH_OMAP3EVM) += board-omap3evm.o \ +board-omap3evm-camera.o \ hsmmc.o obj-$(CONFIG_MACH_OMAP3_PANDORA) += board-omap3pandora.o \ hsmmc.o diff --git a/arch/arm/mach-omap2/board-omap3evm-camera.c b/arch/arm/mach-omap2/board-omap3evm-camera.c new file mode 100644 index 000..be987d9 --- /dev/null +++ b/arch/arm/mach-omap2/board-omap3evm-camera.c @@ -0,0 +1,183 @@ +/* + * Copyright (C) 2010-2011 Lund Engineering + * Contact: Gil Lund gwl...@lundeng.com + * Author: Martin Hostettler mar...@neutronstar.dyndns.org + * [Hiremath, Vaibhav] The file below seems copied from (which is coming from all older releases of TI) http://arago-project.org/git/projects/?p=linux-omap3.git;a=blob;f=arch/arm/mach-omap2/board-omap3evm-camera.c;h=2e6ccfef69027dee880d507b98b5a7998d4bbe7e;hb=adcd067326836777c049e3cb32a5b7d9d401fc31 So I would appreciate if you keep original copyright and authorship of the file and add your sign-off to the patch. First of all i don't have any problem Adding your name and the TI copyright. Maybe i should have been more careful when looking at and adeption omap3evm_set_mux as i really took that from the TI code. I honestly don't remember if i took any other code from that file or not. It ends up doing what the hardware needs anyway. For me it doesn't matter with such trival things, but i should have been more careful. Do you consider it resolved if use the following at the start? /* * Copyright (C) 2010 Texas Instruments Inc * Copyright (C) 2010-2011 Lund Engineering * Contact: Gil Lund gwl...@lundeng.com * Authors: *Vaibhav Hiremath hvaib...@ti.com *Martin Hostettler mar...@neutronstar.dyndns.org */ But then again the copy on my harddisk has these too... * Contributors: * Anuj Aggarwal anuj.aggar...@ti.com * Sivaraj R siva...@ti.com Maybe i should add them too. Not sure really... - Martin Hostettler -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] arm: omap3evm: Add support for an MT9M032 based camera board.
On Sat, Sep 17, 2011 at 01:24:29PM -0700, Joe Perches wrote:
On Sat, 2011-09-17 at 11:34 +0200, Martin Hostettler wrote:
Adds board support for an MT9M032 based camera to omap3evm.
All of the logging messages could be
prefixed by the printk subsystem if you
add #define pr_fmt before any #include
Ah, i didn't really knew about that feature yet. I really have to keep
that in mind when grepping for error messages in the future.
But i don't think it would help much, as i now reducted the total number
of pr_err calls to 2 in this patch.
Thanks for the idea anyway.
- Martin Hostettler
diff --git a/arch/arm/mach-omap2/board-omap3evm-camera.c
b/arch/arm/mach-omap2/board-omap3evm-camera.c
[]
#define pr_fmt(fmt) KBUILD_MODNAME : fmt
[]
+static int omap3evm_set_mux(enum omap3evmdc_mux mux_id)
[]
+ switch (mux_id) {
[]
+ default:
+ pr_err(omap3evm-camera: Invalid mux id #%d\n, mux_id);
pr_err(Invalid mux id #%d\n, mux_id);
[]
+static int __init camera_init(void)
[]
+ if (gpio_request(nCAM_VD_SEL, nCAM_VD_SEL) 0) {
+ pr_err(omap3evm-camera: Failed to get GPIO nCAM_VD_SEL(%d)\n,
+ nCAM_VD_SEL);
pr_err(Failed to get GPIO nCAM_VD_SEL(%d)\n,
nCAM_VD_SEL);
etc.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] arm: omap3evm: Add support for an MT9M032 based camera board.
On Sun, Sep 18, 2011 at 12:08:20AM +0200, Laurent Pinchart wrote:
On Sunday 18 September 2011 00:00:16 Sylwester Nawrocki wrote:
On 09/17/2011 11:34 AM, Martin Hostettler wrote:
Adds board support for an MT9M032 based camera to omap3evm.
...
+
+static int __init camera_init(void)
+{
+ int ret = -EINVAL;
+
+ omap_mux_init_gpio(nCAM_VD_SEL, OMAP_PIN_OUTPUT);
+ if (gpio_request(nCAM_VD_SEL, nCAM_VD_SEL) 0) {
+ pr_err(omap3evm-camera: Failed to get GPIO nCAM_VD_SEL(%d)\n,
+nCAM_VD_SEL);
+ goto err;
+ }
+ if (gpio_direction_output(nCAM_VD_SEL, 1) 0) {
+ pr_err(omap3evm-camera: Failed to set GPIO nCAM_VD_SEL(%d)
direction\n, + nCAM_VD_SEL);
+ goto err_vdsel;
+ }
How about replacing gpio_request + gpio_direction_output with:
gpio_request_one(nCAM_VD_SEL, GPIOF_OUT_INIT_HIGH, nCAM_VD_SEL);
I'd even propose gpio_request_array().
Nice interface. Apart from a bit less detailed error reporting it nicely
simplifies the code. I'll make a new patch using that soon.
- Martin Hostettler
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] arm: omap3evm: Add support for an MT9M032 based camera board.
Adds board support for an MT9M032 based camera to omap3evm.
Sigend-off-by: Martin Hostettler mar...@neutronstar.dyndns.org
---
arch/arm/mach-omap2/Makefile|1 +
arch/arm/mach-omap2/board-omap3evm-camera.c | 183 +++
2 files changed, 184 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-omap3evm-camera.c
Changes in V2:
* ported to current mainline
* Style fixes
* Fix error handling
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index f343365..8ae3d25 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -202,6 +202,7 @@ obj-$(CONFIG_MACH_OMAP3_TORPEDO)+=
board-omap3logic.o \
obj-$(CONFIG_MACH_OVERO) += board-overo.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP3EVM)+= board-omap3evm.o \
+ board-omap3evm-camera.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP3_PANDORA) += board-omap3pandora.o \
hsmmc.o
diff --git a/arch/arm/mach-omap2/board-omap3evm-camera.c
b/arch/arm/mach-omap2/board-omap3evm-camera.c
new file mode 100644
index 000..be987d9
--- /dev/null
+++ b/arch/arm/mach-omap2/board-omap3evm-camera.c
@@ -0,0 +1,183 @@
+/*
+ * Copyright (C) 2010-2011 Lund Engineering
+ * Contact: Gil Lund gwl...@lundeng.com
+ * Author: Martin Hostettler mar...@neutronstar.dyndns.org
+ *
+ * Board intregration for a MT9M032 camera connected to IMAGE_CONN and I2C Bus
2
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ */
+
+#include linux/i2c.h
+#include linux/init.h
+#include linux/platform_device.h
+
+#include linux/gpio.h
+#include plat/mux.h
+#include mux.h
+
+#include ../../../drivers/media/video/omap3isp/isp.h
+#include media/mt9m032.h
+
+#include devices.h
+
+#define EVM_TWL_GPIO_BASE OMAP_MAX_GPIO_LINES
+#define GPIO98_VID_DEC_RES 98
+#define nCAM_VD_SEL157
+
+#define MT9M032_I2C_BUS_NUM2
+
+
+enum omap3evmdc_mux {
+ MUX_TVP5146,
+ MUX_CAMERA_SENSOR,
+ MUX_EXP_CAMERA_SENSOR,
+};
+
+/**
+ * omap3evm_set_mux - Sets mux to enable signal routing to
+ * different peripherals present on new EVM board
+ * @mux_id: enum, mux id to enable
+ *
+ * Returns 0 for success or a negative error code
+ */
+static int omap3evm_set_mux(enum omap3evmdc_mux mux_id)
+{
+ /* Set GPIO6 = 1 */
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 6, 1);
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 0);
+
+ switch (mux_id) {
+ case MUX_TVP5146:
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 0);
+ gpio_set_value(nCAM_VD_SEL, 1);
+ break;
+
+ case MUX_CAMERA_SENSOR:
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 0);
+ gpio_set_value(nCAM_VD_SEL, 0);
+ break;
+
+ case MUX_EXP_CAMERA_SENSOR:
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 1);
+ break;
+
+ default:
+ pr_err(omap3evm-camera: Invalid mux id #%d\n, mux_id);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static struct mt9m032_platform_data mt9m032_platform_data = {
+ .ext_clock = 1350,
+ .pll_pre_div = 6,
+ .pll_mul = 120,
+ .pll_out_div = 5,
+ .invert_pixclock = 1,
+};
+
+static struct i2c_board_info camera_i2c_devices[] = {
+ {
+ I2C_BOARD_INFO(MT9M032_NAME, MT9M032_I2C_ADDR),
+ .platform_data = mt9m032_platform_data,
+ },
+};
+
+static struct isp_subdev_i2c_board_info camera_i2c_subdevs[] = {
+ {
+ .board_info = camera_i2c_devices[0],
+ .i2c_adapter_id = MT9M032_I2C_BUS_NUM,
+ },
+ {},
+};
+
+static struct isp_v4l2_subdevs_group camera_subdevs[] = {
+ {
+ .subdevs = camera_i2c_subdevs,
+ .interface = ISP_INTERFACE_PARALLEL,
+ .bus = {
+ .parallel = {
+ .data_lane_shift = 1,
+ .clk_pol = 0,
+ .bridge = ISPCTRL_PAR_BRIDGE_DISABLE,
+ }
+ },
+ },
+ {},
+};
+
+static struct
Re: cpuidle status in mainline for Beagleboard xM
On 2 September 2011 19:14, Kevin Hilman khil...@ti.com wrote: javier Martin javier.mar...@vista-silicon.com writes: On 2 September 2011 08:05, Jarkko Nikula jarkko.nik...@bitmer.com wrote: Other usual things to check that display is off (echo 1 /sys/class/graphics/fb0/blank) and no cable to musb/otg port. Haven't tried myself with recent kernel but does EHCI and hub on XM let to idle cpu at all? At least on one board having on-board hub I had to disable or unload ehci module in order to hit the retention. I've checked that too and I've even disabled USB support in the kernel just to be sure. But still nothing: root@beagleboard:~# powertop -d -t 100 PowerTOP 1.12 (C) 2007, 2008 Intel Corporation Collecting data for 100 seconds Cn Avg residency C0 (cpu running) ( 0.0%) C0 58.5ms (100.0%) C1 0.0ms ( 0.0%) C2 0.0ms ( 0.0%) C3 0.0ms ( 0.0%) C4 0.0ms ( 0.0%) C5 0.0ms ( 0.0%) C6 0.0ms ( 0.0%) Even when CPU has been idle 100% of the time it doesn't hit any state deeper than C0. Did you allow the UARTs to idle: Yes I did: root@beagleboard:/sys/devices/system/cpu/cpu0/cpuidle# echo 5 /sys/devices/platform/omap/omap_uart.0/sleep_timeout root@beagleboard:/sys/devices/system/cpu/cpu0/cpuidle# echo 5 /sys/devices/platform/omap/omap_uart.1/sleep_timeout root@beagleboard:/sys/devices/system/cpu/cpu0/cpuidle# echo 5 /sys/devices/platform/omap/omap_uart.2/sleep_timeout root@beagleboard:/sys/devices/system/cpu/cpu0/cpuidle# echo 5 /sys/devices/platform/omap/omap_uart.3/sleep_timeout [ 65.853820] omap_device: omap_uart.3: new worst case activate latency 0: 30517 [ 65.944366] omap_device: omap_uart.2: new worst case deactivate latency 0: 30517 # UART timeouts: omap-serial (4th UART only on OMAP36xx and OMAP4) echo 5 /sys/devices/platform/omap/omap_uart.0/sleep_timeout echo 5 /sys/devices/platform/omap/omap_uart.1/sleep_timeout echo 5 /sys/devices/platform/omap/omap_uart.2/sleep_timeout echo 5 /sys/devices/platform/omap/omap_uart.3/sleep_timeout I just tested this using today's linux-omap master branch (+ merged v3.1-rc4 which includes a fix for a bootup problem.) I booted my Beagle XM with a busybox rootfs on MMC and it worked fine for me. I don't have powertop on the rootfs, but I manually dumped the sysfs files that powertop reads, so I can see the state times. After allowing the UARTs to idle, I see: # cd /sys/devices/system/cpu/cpu0 /sys/devices/system/cpu/cpu0/cpuidle # cat state?/time 43531831 8997 157215 0 3467925 0 0 OK, I've just tried with the same kernel as you did (linux-omap master + v3.1-rc4 merge) and I can't get any other state than 0: root@beagleboard:/sys/devices/system/cpu/cpu0/cpuidle# cat state?/time 162570397 0 0 0 0 0 0 Just one question. Do you access the shell through UART? What I do is waiting for 20 seconds to allow the UART to suspend and then see state reports. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cpuidle status in mainline for Beagleboard xM
On 2 September 2011 08:05, Jarkko Nikula jarkko.nik...@bitmer.com wrote: Other usual things to check that display is off (echo 1 /sys/class/graphics/fb0/blank) and no cable to musb/otg port. Haven't tried myself with recent kernel but does EHCI and hub on XM let to idle cpu at all? At least on one board having on-board hub I had to disable or unload ehci module in order to hit the retention. I've checked that too and I've even disabled USB support in the kernel just to be sure. But still nothing: root@beagleboard:~# powertop -d -t 100 PowerTOP 1.12 (C) 2007, 2008 Intel Corporation Collecting data for 100 seconds CnAvg residency C0 (cpu running)( 0.0%) C0 58.5ms (100.0%) C10.0ms ( 0.0%) C20.0ms ( 0.0%) C30.0ms ( 0.0%) C40.0ms ( 0.0%) C50.0ms ( 0.0%) C60.0ms ( 0.0%) Even when CPU has been idle 100% of the time it doesn't hit any state deeper than C0. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cpuidle status in mainline for Beagleboard xM
Hi Kevin, thanks for your help. CPU is staying in C0 probably because UARTs are not being idled, so SoC cannot hit deeper idle states. Try the following at the command line to to enable UART idle timeouts, so the SoC can attempt idle after the timeout period # UART timeouts: omap-serial (4th UART only on OMAP36xx and OMAP4) echo 5 /sys/devices/platform/omap/omap_uart.0/sleep_timeout echo 5 /sys/devices/platform/omap/omap_uart.1/sleep_timeout echo 5 /sys/devices/platform/omap/omap_uart.2/sleep_timeout echo 5 /sys/devices/platform/omap/omap_uart.3/sleep_timeout After 5 seconds of inactivity on the UARTs, you should see the SoC hitting deeper C-states. I've tried that but it still doesn't hit any C-state deeper than 0. I'll try the same test using your pm branch you pointed me out and post the results. Regards. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 00/18] OMAP4: PM data big spring cleanup and fixes
Do we really need to do that patching right now to add base 4460 support? It should be done sometime, but I see no need for it to be right now. If we're just doing a bunch of renames all over the place to add support for a new processor variant, something is wrong. This is exactly the kind of crazy churn Linus was complaining about. In this case the crazy churn is let's rename 4430 to 44XX all over the place. To me, this is not 'crazy churn', but rather, correcting an earlier oversight. I did not understand Linus to say never fix a naming oversight, but don't change names without a good reason. To me it's sane to assume that we can have most of 4430 features on 4460 and don't need to rename 4430 to 44XX for that. Adding 4460 should be just add few new 4460 defines, then do an arch_initcall to fixup things between 4430 and 4460. This is a topic upon which mileage varies. My experience has made we wary of making such assumptions, because too often they have turned out to be wrong. It is much better to make it clear that the same code supports both than to leave people guessing. Saying so in the filename is useful. It is also consistent with the naming scheme used in much of the kernel. I don't feel a sense of urgency to correct this, nor a need to hit a merge window, but from my mileage, I would prefer that it be corrected within a reasonable time frame. It seems to me that there is also a bullet to bite here. To achieve the sort of rationalization across the arm architecture that is envisioned, inconsistencies in naming styles between platforms will have to be reconciled and resolved, lest the habit continue.-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 00/18] OMAP4: PM data big spring cleanup and fixes
From: Tony Lindgren [t...@atomide.com] * Martin Fouts mfo...@sta.samsung.com [110707 10:20]: From: Tony Lindgren [t...@atomide.com] If we're just doing a bunch of renames all over the place to add support for a new processor variant, something is wrong. This is exactly the kind of crazy churn Linus was complaining about. In this case the crazy churn is let's rename 4430 to 44XX all over the place. To me, this is not 'crazy churn', but rather, correcting an earlier oversight. I did not understand Linus to say never fix a naming oversight, but don't change names without a good reason. I think this is crazy churn. It does not fix the problem we have, which is how can we support lots of SoCs in a sane way. It just postpones fixing the problem until the next SoC variant comes around. And now we already have the exact same problem with both the am3505 support and 4460 support. We are looking at different aspects of the problem. How can we support lots of SoCs in a sane way is obviously the key problem. I was referring to the smaller, ongoing problem that every device dependent piece of code has: how do we best communicate what variants are supported by this code. The second problem we have here is why does adding 4460 support depend on a cosmetic clean-up patch. That dependency should not exist at all as it seems the 4460 patches should work even without this patch. I agree. Had the original submitter had the foresight to realize that the code should work for all 44xx family processors, we would have no issue at all. Do we promulgate that oversight and introduce ambiguity about what is really supported in those files, or do we correct it? It seems to me that there is also a bullet to bite here. To achieve the sort of rationalization across the arm architecture that is envisioned, inconsistencies in naming styles between platforms will have to be reconciled and resolved, lest the habit continue. Sure things should be fixed, but things should be fixed properly. Here we are repeating the CHIP_IS flag in hundreds of places where it really should be only checked once after SoC is detected. And then based on that a SoC specifc list of devices can then be initialized. Yes. I was unclear. I didn't mean we should duplicate the 4430 code and make small changes to it, to create nearly identical 4460 code. I only meant that the unified code that works for 4430 and 4460 should not rely on names that make it appear that one SoC is supported but not the other. I do not feel that the later is cosmetic, although I agree it can be postponed.-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
tidspbridge: problems executing sample apps
Hi, we have a Beagleboard xM (DM3730) and we are currently working with stable kernel 2.6.39 and we have compiled the tisdpbridge in the staging directory. In order to test basic DSP functionality we are using userspace-dspbridge from git repository git://dev.omapzoom.org/pub/scm/tidspbridge/userspace-dspbridge.git and commit 9c64192758fd066d1a3f50867919e7aa21f04387 And the following version of needed packages are being used: bios_5_41_07_24 TI_CGT_C6000_6.1.17 xdctools_3_20_06_81 1- If I try prebuilt binaries (both for DSP side and userspace) I get an execution error: root@beagleboard:/dspbridge# ./ping.out DSP device detected !! DSPNode[ 30.530944] DSPTrace: PING: **PING_TI_create: retval = 0x0 ** [ 30.530975] PING: PING_TI_execute: Entered ... [ 30.530975] Create succeeded[ 30.545135] DSPTrace: PING: PING_TI_execute: Received ping from GPP: cmd = 0xbebe0001; cnt = 0x200596aa [ 30.545166] DSPNode_registerNotify succeeded DSPNode_run succeeded Ping: Id 1.00 Msg 0.00 Mem 15408.00 DSPNode_GetMessage failed: 0xffc2 Ping: Id 1.00 Msg 1.00 Mem 15408.00 DSPNode_GetMessage failed: 0xffc2 2- If I compile only MPU samples and use DSP prebuilt binaries it works fine. 3- If I compile both DSP side and MPU side samples it also gives an execution error: root@beagleboard:/dspbridge# ./cexec.out ddspbase_tiomap3430.dof64P DSP device detected !! [ 45.862640] proc_load: Processor Loaded ddspbase_tiomap3430.dof64P [ 45.876892] proc_start: dsp in running state DSPProcessor_Sta[ 45.881927] procwrap_detach: deprecated dspbridge ioctl rt succeeded. Hit any key to terminate cexec. root@beagleboard:/dspbridge# ./ping.out DSP device detec[ 64.484649] procwrap_detach: deprecated dspbridge ioctl ted !! DSPNode_Create failed: 0xffe3 In order to achieve option (3) I had to apply the attached patch to fix some build errors and I had to copy libstdc++.so.5 to /usr/lib32/ since I am on a 64bit machine http://mirror.ovh.net/ubuntu//pool/universe/g/gcc-3.3/libstdc++5_3.3.6-15ubuntu4_i386.deb Do you know what combination of DSP bios, TI CGT and xdctools is most suitable for using with tidspbridge in kernel 2.6.39? Thank you. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com diff --git a/source/product.mak b/source/product.mak index 892faf5..1996366 100755 --- a/source/product.mak +++ b/source/product.mak @@ -13,12 +13,12 @@ # # DSP BIOS -SABIOS_VER = 5.33.04 -SABIOS_VER_2 = 5_33_04 +SABIOS_VER = 5.41.07.24 +SABIOS_VER_2 = 5_41_07_24 # CodeGen Tools CGT55_VER = 3.2.2 -CGT6X_VER = 6.0.7 +CGT6X_VER = 6.1.17 # Framework components FC_VER = 1_10_04 diff --git a/source/samplemakefile b/source/samplemakefile index 4d11610..ac9f772 100755 --- a/source/samplemakefile +++ b/source/samplemakefile @@ -83,8 +83,8 @@ BRIDGE_EXPORT_PACKAGES = dsp/ti/dspbridge/dsp/bridge_product SAMPLE_PACKAGES = samples/dsp -DLL_FILES=$(wildcard $(SAMPLE_PACKAGES)/*.dll64P)) -DOF_FILES=$(wildcard $(SAMPLE_PACKAGES)/*.dof64P)) +DLL_FILES=$(wildcard $(SAMPLE_PACKAGES)/*.dll64P) +DOF_FILES=$(wildcard $(SAMPLE_PACKAGES)/*.dof64P) .samples: .bridge_samples @@ -144,7 +144,7 @@ ifneq ($(DLL_FILES),) $(CP) -f $(DLL_FILES) $(TARGETDIR)/dspbridge/ endif ifneq ($(DOF_FILES),) - $(CP) -f $(DOF_FILES)/ $(TARGETDIR)/dspbridge/ + $(CP) -f $(DOF_FILES) $(TARGETDIR)/dspbridge/ endif #.execute_version_script: version.ksh $(VERSION_FILE) diff --git a/source/samples/dsp/ddspbase.tci b/source/samples/dsp/ddspbase.tci index 1746adc..d968cab 100755 --- a/source/samples/dsp/ddspbase.tci +++ b/source/samples/dsp/ddspbase.tci @@ -19,6 +19,8 @@ * */ +var chipType = environment[config.chipType]; + /* bridge default is 512, that's not enough sometimes */ var traceSize = 512;
Re: [PATCH v2 2/2] OMAP3BEAGLE: Add support for mt9p031 sensor driver.
On 22 May 2011 15:49, Igor Grinberg grinb...@compulab.co.il wrote:
Hi Javier,
linux-omap should be CC'ed - added.
In addition to Koen's comments, some comments below.
On 05/20/11 16:47, Javier Martin wrote:
isp.h file has to be included as a temporal measure
since clocks of the isp are not exposed yet.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
arch/arm/mach-omap2/board-omap3beagle.c | 127
++-
1 files changed, 123 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 33007fd..f52e6ae 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -24,15 +24,20 @@
#include linux/input.h
#include linux/gpio_keys.h
#include linux/opp.h
+#include linux/i2c.h
+#include linux/mm.h
+#include linux/videodev2.h
#include linux/mtd/mtd.h
#include linux/mtd/partitions.h
#include linux/mtd/nand.h
#include linux/mmc/host.h
-
+#include linux/gpio.h
Why include this for second time?
Good catch, I'll fix it.
[snip]
@@ -309,6 +357,15 @@ static int beagle_twl_gpio_setup(struct device *dev,
pr_err(%s: unable to configure EHCI_nOC\n, __func__);
}
+ if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
+ /*
+ * Power on camera interface - only on pre-production, not
+ * needed on production boards
+ */
+ gpio_request(gpio + 2, CAM_EN);
+ gpio_direction_output(gpio + 2, 1);
Why not gpio_request_one()?
Just to follow the same approach as in the rest of the code.
Maybe a further patch could change all gpio_request() uses to
gpio_request_one().
+ }
+
/*
* TWL4030_GPIO_MAX + 0 == ledA, EHCI nEN_USB_PWR (out, XM active
* high / others active low)
@@ -451,6 +508,8 @@ static struct twl4030_platform_data beagle_twldata = {
.vsim = beagle_vsim,
.vdac = beagle_vdac,
.vpll2 = beagle_vpll2,
+ .vaux3 = beagle_vaux3,
+ .vaux4 = beagle_vaux4,
};
static struct i2c_board_info __initdata beagle_i2c_boardinfo[] = {
@@ -463,15 +522,16 @@ static struct i2c_board_info __initdata
beagle_i2c_boardinfo[] = {
};
static struct i2c_board_info __initdata beagle_i2c_eeprom[] = {
- {
- I2C_BOARD_INFO(eeprom, 0x50),
- },
+ {
+ I2C_BOARD_INFO(eeprom, 0x50),
+ },
};
This part of the hunk is not related to the patch
and should be in a separate (cleanup) patch.
Sure, I'll fix it.
static int __init omap3_beagle_i2c_init(void)
{
omap_register_i2c_bus(1, 2600, beagle_i2c_boardinfo,
ARRAY_SIZE(beagle_i2c_boardinfo));
+ omap_register_i2c_bus(2, 100, NULL, 0); /* Enable I2C2 for camera */
/* Bus 3 is attached to the DVI port where devices like the pico DLP
* projector don't work reliably with 400kHz */
omap_register_i2c_bus(3, 100, beagle_i2c_eeprom,
ARRAY_SIZE(beagle_i2c_eeprom));
@@ -654,6 +714,60 @@ static void __init beagle_opp_init(void)
return;
}
+static int beagle_cam_set_xclk(struct v4l2_subdev *subdev, int hz)
+{
+ struct isp_device *isp = v4l2_dev_to_isp_device(subdev-v4l2_dev);
+ int ret;
+
+ ret = isp-platform_cb.set_xclk(isp, hz, MT9P031_XCLK);
+ return 0;
+}
Why do you need ret variable here, if you always return zero?
You are right, it's not needed any longer.
+
+static int beagle_cam_reset(struct v4l2_subdev *subdev, int active)
+{
+ /* Set RESET_BAR to !active */
+ gpio_set_value(MT9P031_RESET_GPIO, !active);
+
+ return 0;
+}
+
+static struct mt9p031_platform_data beagle_mt9p031_platform_data = {
+ .set_xclk = beagle_cam_set_xclk,
+ .reset = beagle_cam_reset,
+};
+
+static struct i2c_board_info mt9p031_camera_i2c_device = {
+ I2C_BOARD_INFO(mt9p031, 0x48),
+ .platform_data = beagle_mt9p031_platform_data,
+};
+
+static struct isp_subdev_i2c_board_info mt9p031_camera_subdevs[] = {
+ {
+ .board_info = mt9p031_camera_i2c_device,
+ .i2c_adapter_id = 2,
+ },
+ { NULL, 0, },
+};
+
+static struct isp_v4l2_subdevs_group beagle_camera_subdevs[] = {
+ {
+ .subdevs = mt9p031_camera_subdevs,
+ .interface = ISP_INTERFACE_PARALLEL,
+ .bus = {
+ .parallel = {
+ .data_lane_shift = 0,
+ .clk_pol = 1,
+ .bridge = ISPCTRL_PAR_BRIDGE_DISABLE,
+ }
+ },
+ },
+ { },
+};
+
+static struct isp_platform_data beagle_isp_platform_data = {
+ .subdevs = beagle_camera_subdevs,
+};
+
static void __init omap3_beagle_init(void
Re: [PATCH] arm: omap2: enable smc instruction for sleep34xx
On Tue, Apr 19, 2011 at 12:13:26PM +0200, Anderö, Oskar wrote: Ping! Anyone else that gets bitten by the following when compiling omap2plus_defconfig with gcc 4.5: arch/arm/mach-omap2/sleep34xx.S:150: Error: selected processor does not support ARM mode `smc #1' -Oskar I can report that I get the exact same compile error as this. OP patch worked beautifully. -Alex Can you check what options are being passed to the compiler and the assembler, and check for .arch / .arch_extension directives in the assembler input? i.e., make V=1 CFLAGS_KERNEL='-v -save-temps' arch/arm/mach-omap2/sleep34xx.o ...and look at the output and the generated sleep34xx.s Maybe the options being passed to the compiler/assembler are wrong somewhere along the line. Yes, the +sec extension of armv7-a (i.e. -march=armv7-a+sec) is missing and hence the smc instruction can't be used. This is what my patch fixes. I guess earlier versions of binutils silently ignored this. It's not visible in my patch, but plus_sec is declared as: plus_sec := $(call as-instr,.arch_extension sec,+sec) Ah right, I was slightly confused by the context. You're right -- sleep34xx.S also needs this change in the Makefile, as per your patch. This isn't new; the original patch focused on omap4, so I guess this file was just missed. Cheers ---Dave The following patch added the same extension for some of the other files, but I guess sleep34xx.S was missed or maybe added later: commit fe297dde5ae8f8bf67d3a87759289a99b48ecb2c Author: John Rigby john.ri...@linaro.org Date: Wed Dec 1 05:57:51 2010 + OMAP4: enable smc instruction in new assembler versions New assemblers need -march=armv7-a+sec on command line or .arch_extension sec inline to enable use of the smc instruction. snip -Oskar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cpufreq support for the Beagleboard.
Hi, thank you for your fast answer. I've been testing the repository you pointed me and I found that only 300MHz and 600MHz can be selected in the Beagleboard xM. Couldn't we work until 1000MHz? Do you know what's left for those patches to enter mainline? Is anybody working on it? Thanks. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] omap3: beaglexm: fix user button.
User push button in Beagleboard xM is 4 instead of 7.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
arch/arm/mach-omap2/board-omap3beagle.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 46d814a..abf87d1 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -615,6 +615,10 @@ static void __init omap3_beagle_init(void)
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
omap3_beagle_init_rev();
omap3_beagle_i2c_init();
+ /* xM version uses pin 4 instead of 7 for user button */
+ if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
+ gpio_buttons[0].gpio = 4;
+ }
platform_add_devices(omap3_beagle_devices,
ARRAY_SIZE(omap3_beagle_devices));
omap_serial_init();
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 REPOST 0/5] ARM: omap[34]: Thumb-2 compatibility fixes
On Fri, Mar 4, 2011 at 9:42 PM, Kevin Hilman khil...@ti.com wrote: Dave Martin dave.mar...@linaro.org writes: On Fri, Mar 4, 2011 at 5:47 PM, Tony Lindgren t...@atomide.com wrote: * Santosh Shilimkar santosh.shilim...@ti.com [110304 09:36]: Following up on this, it looks like I have some locally-recorded acks which didn't make it into my posting ... To me looks like this is ready to go, but I'd like to see Kevin's acks on this one as this touches the PM code. Or if Kevin wants to take the series, here's my ack for the series: Acked-by: Tony Lindgren t...@atomide.com Yeah, I'll queue this series. Thanks -- I'll wait for Kevin to comment also. I have to give one more round of sanity testing to this series, but otherwise I have no outstanding issues. I also need to coordinate with Santosh on this because he has an additional cleanup series that touches the same code. Dave, just to confirm something The outstanding toolchain bugs only affect compiling in Thumb-2 mode, right? IOW, if I merge just this series (without having the other toolchain workaround patches) we should still be able to compile/run fine in ARM mode, correct? Yes, that's right. Cheers ---Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 REPOST 0/5] ARM: omap[34]: Thumb-2 compatibility fixes
This set of patches, along with some other patches under discussion on alkml, should enable omap3 and omap4 kernels to be built with CONFIG_THUMB2_KERNEL. This patch set builds on recent cleanup done by the omap maintainers. At least some of this code definitely works, most features have been tested successfully. Further testing, especially of Thumb-2 behaviour, is still welcome. In particular, I still have no Ack/Tested-by on the following patches, so it would be great if anyone who has an opportunity to do a final review / re-test can do so. * ARM: omap3: Convert END() to ENDPROC() for correct linkage with CONFIG_THUMB2_KERNEL * ARM: omap3: Thumb-2 compatibility for sram34xx.S * ARM: omap3: Thumb-2 compatibility for sleep34xx.S Seems to work with CONFIG_SMP_ON_UP and CONFIG_THUMB2_KERNEL enabled on Beagle xM A2 and Panda A1. Thanks also to Santosh Shilimkar and Kevin Hilman for their help with testing so far. v3: * make SMC instruction syntax more consistent * remove do_wfi() in favour of the generic wfi() macro v4: * revert to the OMAP-specific do_wfi() implementation, pending discussion of how generic macros can/should be provided v5: * use ARM for low-level code in mach-omap2/*34xx.S, for correct interoperation with non-Thumb-capable firmware. I've stripped the Acked/Tested-bys from the major patches to mach-omap2/*34xx.S, since the reversion to ARM constitutes a significant change -- I would be grateful if people could re- test / re-review if they have the chance. For best future compatibility, I've left the changes which avoid architecturally deprecated features. Details below. Cheers, Dave The patches can be found, along with a buildable working tree, in the following repo: git://git.linaro.org/people/dmart/linux-2.6-arm.git * arm/omap-thumb2: has the patches proposed here * arm/omap-thumb2+merged: additionally has some patches cherry- picked from other trees which are needed in order for the patches on arm/omap-thumb2 to work usefully. * dirty/arm/omap-thumb2+merged: buildable test tree, which adds 2 local patches to work around a toolchain bug. A working kernel config for this tree is here: http://people.linaro.org/~dmart/arm_omap-thumb2+v2_config : CONFIG_SMP_ON_UP=y CONFIG_THUMB2_KERNEL=y CONFIG_SERIAL_OMAP=y (to avoid garbage on xM; for Panda use console=ttyS2) (The config is derived from the linaro omap config and so turns on loads of modules -- don't feel you have to build them all...) Cherry-picked patches originated from Russell's devel tree and Tony Lindgren's omap-testing tree: http://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cur/linux-2.6-arm.git devel git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git omap-testing This series also depends on one un-merged patch to generic-ise the wfi() macro: git://git.linaro.org/people/dmart/linux-2.6-arm.git arm/wfi-macro Dave Martin (5): ARM: omap4: Provide do_wfi() for Thumb-2 ARM: omap4: Convert END() to ENDPROC() for correct linkage with CONFIG_THUMB2_KERNEL ARM: omap3: Remove hand-encoded SMC instructions ARM: omap3: Thumb-2 compatibility for sram34xx.S ARM: omap3: Thumb-2 compatibility for sleep34xx.S arch/arm/mach-omap2/include/mach/omap4-common.h |4 ++ arch/arm/mach-omap2/omap-headsmp.S |2 +- arch/arm/mach-omap2/omap44xx-smc.S |8 ++-- arch/arm/mach-omap2/sleep34xx.S | 62 ++ arch/arm/mach-omap2/sram34xx.S | 36 ++--- 5 files changed, 87 insertions(+), 25 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 1/5] ARM: omap4: Provide do_wfi() for Thumb-2
For CONFIG_THUMB2_KERNEL, the existing definition of do_wfi() will insert invalid code into the instruction stream. Any assembler which can assemble Thumb-2 is guaranteed to accept the wfi mnemonic, so for the Thumb-2 case, just use the mnemonic. The ARM case is left as-is. Signed-off-by: Dave Martin dave.mar...@linaro.org --- arch/arm/mach-omap2/include/mach/omap4-common.h |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/include/mach/omap4-common.h b/arch/arm/mach-omap2/include/mach/omap4-common.h index 5b0270b..de441c0 100644 --- a/arch/arm/mach-omap2/include/mach/omap4-common.h +++ b/arch/arm/mach-omap2/include/mach/omap4-common.h @@ -17,8 +17,12 @@ * wfi used in low power code. Directly opcode is used instead * of instruction to avoid mulit-omap build break */ +#ifdef CONFIG_THUMB2_KERNEL +#define do_wfi() __asm__ __volatile__ (wfi : : : memory) +#else #define do_wfi() \ __asm__ __volatile__ (.word0xe320f003 : : : memory) +#endif #ifdef CONFIG_CACHE_L2X0 extern void __iomem *l2cache_base; -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 2/5] ARM: omap4: Convert END() to ENDPROC() for correct linkage with CONFIG_THUMB2_KERNEL
Code marked with ENTRY() also needs a matching ENDPROC() directive,
in order to ensure that the type and instruction set of the
symbol are correctly annotated.
ENDPROC() tags the affected symbol as a function symbol, which will
ensure that link-time fixups don't accidentally switch to the
wrong instruction set.
Signed-off-by: Dave Martin dave.mar...@linaro.org
Tested-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/omap-headsmp.S |2 +-
arch/arm/mach-omap2/omap44xx-smc.S |8
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-headsmp.S
b/arch/arm/mach-omap2/omap-headsmp.S
index 6ae937a..4ee6aec 100644
--- a/arch/arm/mach-omap2/omap-headsmp.S
+++ b/arch/arm/mach-omap2/omap-headsmp.S
@@ -45,5 +45,5 @@ hold: ldr r12,=0x103
* should now contain the SVC stack for this core
*/
b secondary_startup
-END(omap_secondary_startup)
+ENDPROC(omap_secondary_startup)
diff --git a/arch/arm/mach-omap2/omap44xx-smc.S
b/arch/arm/mach-omap2/omap44xx-smc.S
index 1980dc3..e69d37d 100644
--- a/arch/arm/mach-omap2/omap44xx-smc.S
+++ b/arch/arm/mach-omap2/omap44xx-smc.S
@@ -29,7 +29,7 @@ ENTRY(omap_smc1)
dsb
smc #0
ldmfd sp!, {r2-r12, pc}
-END(omap_smc1)
+ENDPROC(omap_smc1)
ENTRY(omap_modify_auxcoreboot0)
stmfd sp!, {r1-r12, lr}
@@ -37,7 +37,7 @@ ENTRY(omap_modify_auxcoreboot0)
dsb
smc #0
ldmfd sp!, {r1-r12, pc}
-END(omap_modify_auxcoreboot0)
+ENDPROC(omap_modify_auxcoreboot0)
ENTRY(omap_auxcoreboot_addr)
stmfd sp!, {r2-r12, lr}
@@ -45,7 +45,7 @@ ENTRY(omap_auxcoreboot_addr)
dsb
smc #0
ldmfd sp!, {r2-r12, pc}
-END(omap_auxcoreboot_addr)
+ENDPROC(omap_auxcoreboot_addr)
ENTRY(omap_read_auxcoreboot0)
stmfd sp!, {r2-r12, lr}
@@ -54,4 +54,4 @@ ENTRY(omap_read_auxcoreboot0)
smc #0
mov r0, r0, lsr #9
ldmfd sp!, {r2-r12, pc}
-END(omap_read_auxcoreboot0)
+ENDPROC(omap_read_auxcoreboot0)
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 4/5] ARM: omap3: Thumb-2 compatibility for sram34xx.S
* Build unconditionally as ARM for correct interoperation with OMAP firmware. * Remove deprecated PC-relative stores * Add the required ENDPROC() directive for each ENTRY(). * .align before data words Signed-off-by: Dave Martin dave.mar...@linaro.org --- arch/arm/mach-omap2/sram34xx.S | 36 1 files changed, 28 insertions(+), 8 deletions(-) diff --git a/arch/arm/mach-omap2/sram34xx.S b/arch/arm/mach-omap2/sram34xx.S index 7f893a2..fd1531c 100644 --- a/arch/arm/mach-omap2/sram34xx.S +++ b/arch/arm/mach-omap2/sram34xx.S @@ -34,6 +34,12 @@ #include sdrc.h #include cm2xxx_3xxx.h +/* + * This file needs be built unconditionally as ARM to interoperate correctly + * with non-Thumb-2-capable firmware. + */ + .arm + .text /* r1 parameters */ @@ -116,24 +122,36 @@ ENTRY(omap3_sram_configure_core_dpll) @ pull the extra args off the stack @ and store them in SRAM + +/* + * PC-relative stores are deprecated in ARMv7 and lead to undefined behaviour + * in Thumb-2: use a r7 as a base instead. + * Be careful not to clobber r7 when maintaing this file. + */ + THUMB(adr r7, omap3_sram_configure_core_dpll ) + .macro strtext Rt:req, label:req + ARM( str \Rt, \label ) + THUMB(str \Rt, [r7, \label - omap3_sram_configure_core_dpll] ) + .endm + ldr r4, [sp, #52] - str r4, omap_sdrc_rfr_ctrl_0_val + strtext r4, omap_sdrc_rfr_ctrl_0_val ldr r4, [sp, #56] - str r4, omap_sdrc_actim_ctrl_a_0_val + strtext r4, omap_sdrc_actim_ctrl_a_0_val ldr r4, [sp, #60] - str r4, omap_sdrc_actim_ctrl_b_0_val + strtext r4, omap_sdrc_actim_ctrl_b_0_val ldr r4, [sp, #64] - str r4, omap_sdrc_mr_0_val + strtext r4, omap_sdrc_mr_0_val ldr r4, [sp, #68] - str r4, omap_sdrc_rfr_ctrl_1_val + strtext r4, omap_sdrc_rfr_ctrl_1_val cmp r4, #0 @ if SDRC_RFR_CTRL_1 is 0, beq skip_cs1_params @ do not use cs1 params ldr r4, [sp, #72] - str r4, omap_sdrc_actim_ctrl_a_1_val + strtext r4, omap_sdrc_actim_ctrl_a_1_val ldr r4, [sp, #76] - str r4, omap_sdrc_actim_ctrl_b_1_val + strtext r4, omap_sdrc_actim_ctrl_b_1_val ldr r4, [sp, #80] - str r4, omap_sdrc_mr_1_val + strtext r4, omap_sdrc_mr_1_val skip_cs1_params: mrc p15, 0, r8, c1, c0, 0 @ read ctrl register bic r10, r8, #0x800 @ clear Z-bit, disable branch prediction @@ -271,6 +289,7 @@ skip_cs1_prog: ldr r12, [r11] @ posted-write barrier for SDRC bx lr + .align omap3_sdrc_power: .word OMAP34XX_SDRC_REGADDR(SDRC_POWER) omap3_cm_clksel1_pll: @@ -319,6 +338,7 @@ omap3_sdrc_dlla_ctrl: .word OMAP34XX_SDRC_REGADDR(SDRC_DLLA_CTRL) core_m2_mask_val: .word 0x07FF +ENDPROC(omap3_sram_configure_core_dpll) ENTRY(omap3_sram_configure_core_dpll_sz) .word . - omap3_sram_configure_core_dpll -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 5/5] ARM: omap3: Thumb-2 compatibility for sleep34xx.S
* Build unconditionally as ARM for correct interoperation with
OMAP firmware.
* Fix an out-of-range ADR when building for ARM.
* Remove deprecated PC-relative stores.
* Add the required ENDPROC() directive for each ENTRY().
* .align before data words.
* Handle non-interworking return from v7_flush_dcache_all.
Signed-off-by: Dave Martin dave.mar...@linaro.org
---
arch/arm/mach-omap2/sleep34xx.S | 48 ++
1 files changed, 43 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
index a05c348..f377724 100644
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
@@ -64,6 +64,11 @@
#define SDRC_DLLA_STATUS_V OMAP34XX_SDRC_REGADDR(SDRC_DLLA_STATUS)
#define SDRC_DLLA_CTRL_V OMAP34XX_SDRC_REGADDR(SDRC_DLLA_CTRL)
+/*
+ * This file needs be built unconditionally as ARM to interoperate correctly
+ * with non-Thumb-2-capable firmware.
+ */
+ .arm
/*
* API functions
@@ -82,6 +87,8 @@ ENTRY(get_restore_pointer)
stmfd sp!, {lr} @ save registers on stack
adr r0, restore
ldmfd sp!, {pc} @ restore regs and return
+ENDPROC(get_restore_pointer)
+ .align
ENTRY(get_restore_pointer_sz)
.word . - get_restore_pointer
@@ -91,6 +98,8 @@ ENTRY(get_omap3630_restore_pointer)
stmfd sp!, {lr} @ save registers on stack
adr r0, restore_3630
ldmfd sp!, {pc} @ restore regs and return
+ENDPROC(get_omap3630_restore_pointer)
+ .align
ENTRY(get_omap3630_restore_pointer_sz)
.word . - get_omap3630_restore_pointer
@@ -100,6 +109,8 @@ ENTRY(get_es3_restore_pointer)
stmfd sp!, {lr} @ save registers on stack
adr r0, restore_es3
ldmfd sp!, {pc} @ restore regs and return
+ENDPROC(get_es3_restore_pointer)
+ .align
ENTRY(get_es3_restore_pointer_sz)
.word . - get_es3_restore_pointer
@@ -113,8 +124,10 @@ ENTRY(enable_omap3630_toggle_l2_on_restore)
stmfd sp!, {lr} @ save registers on stack
/* Setup so that we will disable and enable l2 */
mov r1, #0x1
- str r1, l2dis_3630
+ adrlr2, l2dis_3630 @ may be too distant for plain adr
+ str r1, [r2]
ldmfd sp!, {pc} @ restore regs and return
+ENDPROC(enable_omap3630_toggle_l2_on_restore)
.text
/* Function to call rom code to save secure ram context */
@@ -139,12 +152,14 @@ ENTRY(save_secure_ram_context)
nop
nop
ldmfd sp!, {r1-r12, pc}
+ .align
sram_phy_addr_mask:
.word SRAM_BASE_P
high_mask:
.word 0x
api_params:
.word 0x4, 0x0, 0x0, 0x1, 0x1
+ENDPROC(save_secure_ram_context)
ENTRY(save_secure_ram_context_sz)
.word . - save_secure_ram_context
@@ -279,8 +294,18 @@ clean_l2:
* - 'might' have to copy address, load and jump to it
*/
ldr r1, kernel_flush
- mov lr, pc
- bx r1
+ blx r1
+ /*
+* The kernel doesn't interwork: v7_flush_dcache_all in particluar will
+* always return in Thumb state when CONFIG_THUMB2_KERNEL is enabled.
+* This sequence switches back to ARM. Note that .align may insert a
+* nop: bx pc needs to be word-aligned in order to work.
+*/
+ THUMB(.thumb )
+ THUMB(.align )
+ THUMB(bx pc )
+ THUMB(nop )
+ .arm
omap3_do_wfi:
ldr r4, sdrc_power @ read the SDRC_POWER register
@@ -438,6 +463,7 @@ skipl2dis:
#endif
b logic_l1_restore
+ .align
l2_inv_api_params:
.word 0x1, 0x00
l2_inv_gp:
@@ -607,6 +633,7 @@ usettbr0:
/* This function implements the erratum ID i443 WA, applies to 34xx = ES3.0 */
.text
+ .align 3
ENTRY(es3_sdrc_fix)
ldr r4, sdrc_syscfg @ get config addr
ldr r5, [r4]@ get value
@@ -634,6 +661,7 @@ ENTRY(es3_sdrc_fix)
str r5, [r4]@ kick off refreshes
bx lr
+ .align
sdrc_syscfg:
.word SDRC_SYSCONFIG_P
sdrc_mr_0:
@@ -648,6 +676,7 @@ sdrc_emr2_1:
.word SDRC_EMR2_1_P
sdrc_manual_1:
.word SDRC_MANUAL_1_P
+ENDPROC(es3_sdrc_fix)
ENTRY(es3_sdrc_fix_sz)
.word . - es3_sdrc_fix
@@ -682,6 +711,12 @@ wait_sdrc_ready:
bic r5, r5, #0x40
str r5, [r4]
+/*
+ * PC-relative stores lead to undefined behaviour in Thumb-2: use a r7 as a
+ * base instead.
+ * Be careful not to clobber r7 when maintaing this code.
+ */
+
is_dll_in_lock_mode:
/* Is dll in lock mode? */
ldr r4, sdrc_dlla_ctrl
@@ -689,10 +724,11 @@ is_dll_in_lock_mode:
tst r5, #0x4
bxnelr @ Return if locked
/* wait till dll locks */
+ adr
Re: [PATCH v5 REPOST 0/5] ARM: omap[34]: Thumb-2 compatibility fixes
On Fri, Mar 4, 2011 at 3:33 PM, Dave Martin dave.mar...@linaro.org wrote: This set of patches, along with some other patches under discussion on alkml, should enable omap3 and omap4 kernels to be built with CONFIG_THUMB2_KERNEL. This patch set builds on recent cleanup done by the omap maintainers. At least some of this code definitely works, most features have been tested successfully. Further testing, especially of Thumb-2 behaviour, is still welcome. In particular, I still have no Ack/Tested-by on the following patches, so it would be great if anyone who has an opportunity to do a final review / re-test can do so. * ARM: omap3: Convert END() to ENDPROC() for correct linkage with CONFIG_THUMB2_KERNEL * ARM: omap3: Thumb-2 compatibility for sram34xx.S * ARM: omap3: Thumb-2 compatibility for sleep34xx.S Following up on this, it looks like I have some locally-recorded acks which didn't make it into my posting ... The one patch I currently have no feedback on is this one: * ARM: omap4: Provide do_wfi() for Thumb-2 Cheers ---Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 REPOST 0/5] ARM: omap[34]: Thumb-2 compatibility fixes
On Fri, Mar 4, 2011 at 5:47 PM, Tony Lindgren t...@atomide.com wrote: * Santosh Shilimkar santosh.shilim...@ti.com [110304 09:36]: Following up on this, it looks like I have some locally-recorded acks which didn't make it into my posting ... To me looks like this is ready to go, but I'd like to see Kevin's acks on this one as this touches the PM code. Or if Kevin wants to take the series, here's my ack for the series: Acked-by: Tony Lindgren t...@atomide.com Thanks -- I'll wait for Kevin to comment also. Cheers ---Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: Avoid discarding sections that might have SMP_ON_UP fixups
Hi Russell, On Wed, Feb 16, 2011 at 4:35 PM, Dave Martin dave.mar...@linaro.org wrote: Hi, On Fri, Feb 11, 2011 at 04:32:47PM +, Russell King - ARM Linux wrote: [...] diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S index 45b5651..343d29f 100644 --- a/arch/arm/kernel/vmlinux.lds.S +++ b/arch/arm/kernel/vmlinux.lds.S @@ -21,6 +21,12 @@ #define ARM_CPU_KEEP(x) #endif +#if defined(CONFIG_SMP_ON_UP) !defined(CONFIG_DEBUG_SPINLOCK) +#define ARM_EXIT_KEEP(x) x +#else +#define ARM_EXIT_KEEP(x) +#endif + OUTPUT_ARCH(arm) ENTRY(stext) @@ -43,6 +49,7 @@ SECTIONS _sinittext = .; HEAD_TEXT INIT_TEXT + ARM_EXIT_KEEP(EXIT_TEXT) _einittext = .; ARM_CPU_DISCARD(PROC_INFO) __arch_info_begin = .; @@ -71,6 +78,7 @@ SECTIONS #ifndef CONFIG_XIP_KERNEL __init_begin = _stext; INIT_DATA + ARM_EXIT_KEEP(EXIT_DATA) #endif } @@ -166,6 +174,7 @@ SECTIONS . = ALIGN(PAGE_SIZE); __init_begin = .; INIT_DATA + ARM_EXIT_KEEP(EXIT_DATA) . = ALIGN(PAGE_SIZE); __init_end = .; #endif ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel This works for me in a case known to fail without the patch. Tested-by: Dave Martin dave.mar...@linaro.org I still don't quite understand the intricacies of how vmlinux is laid out, but the patch looks sensible. Do you need anything more from me on this? If not, I will throw away my patch and replace it with yours. Are you still intending to merge your patch here? I don't see it anywhere yet, but I would like to get rid of my hack (which is rather messy). Cheers ---Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 0/5] ARM: omap[34]: Thumb-2 compatibility fixes
This set of patches, along with some other patches under discussion on alkml, should enable omap3 and omap4 kernels to be built with CONFIG_THUMB2_KERNEL. This patch set builds on recent cleanup done by the omap maintainers. At least some of this code definitely works, most features have been tested successfully. Further testing, especially of Thumb-2 behaviour, is still welcome. Seems to work with CONFIG_SMP_ON_UP and CONFIG_THUMB2_KERNEL enabled on Beagle xM A2 and Panda A1. Thanks also to Santosh Shilimkar and Kevin Hilman for their help with testing. v3: * make SMC instruction syntax more consistent * remove do_wfi() in favour of the generic wfi() macro v4: * revert to the OMAP-specific do_wfi() implementation, pending discussion of how generic macros can/should be provided v5: * use ARM for low-level code in mach-omap2/*34xx.S, for correct interoperation with non-Thumb-capable firmware. I've stripped the Acked/Tested-bys from the major patches to mach-omap2/*34xx.S, since the reversion to ARM constitutes a significant change -- I would be grateful if people could re- test / re-review if they have the chance. For best future compatibility, I've left the changes which avoid architecturally deprecated features. Details below. Cheers, Dave The patches can be found, along with a buildable working tree, in the following repo: git://git.linaro.org/people/dmart/linux-2.6-arm.git * arm/omap-thumb2: has the patches proposed here * arm/omap-thumb2+merged: additionally has some patches cherry- picked from other trees which are needed in order for the patches on arm/omap-thumb2 to work usefully. * dirty/arm/omap-thumb2+merged: buildable test tree, which adds 2 local patches to work around a toolchain bug. A working kernel config for this tree is here: http://people.linaro.org/~dmart/arm_omap-thumb2+v2_config : CONFIG_SMP_ON_UP=y CONFIG_THUMB2_KERNEL=y CONFIG_SERIAL_OMAP=y (to avoid garbage on xM; for Panda use console=ttyS2) (The config is derived from the linaro omap config and so turns on loads of modules -- don't feel you have to build them all...) Cherry-picked patches originated from Russell's devel tree and Tony Lindgren's omap-testing tree: http://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cur/linux-2.6-arm.git devel git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git omap-testing This series also depends on one un-merged patch to generic-ise the wfi() macro: git://git.linaro.org/people/dmart/linux-2.6-arm.git arm/wfi-macro Dave Martin (5): ARM: omap4: Provide do_wfi() for Thumb-2 ARM: omap4: Convert END() to ENDPROC() for correct linkage with CONFIG_THUMB2_KERNEL ARM: omap3: Remove hand-encoded SMC instructions ARM: omap3: Thumb-2 compatibility for sram34xx.S ARM: omap3: Thumb-2 compatibility for sleep34xx.S arch/arm/mach-omap2/include/mach/omap4-common.h |4 ++ arch/arm/mach-omap2/omap-headsmp.S |2 +- arch/arm/mach-omap2/omap44xx-smc.S |8 ++-- arch/arm/mach-omap2/sleep34xx.S | 62 ++ arch/arm/mach-omap2/sram34xx.S | 36 ++--- 5 files changed, 87 insertions(+), 25 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 1/5] ARM: omap4: Provide do_wfi() for Thumb-2
For CONFIG_THUMB2_KERNEL, the existing definition of do_wfi() will insert invalid code into the instruction stream. Any assembler which can assemble Thumb-2 is guaranteed to accept the wfi mnemonic, so for the Thumb-2 case, just use the mnemonic. The ARM case is left as-is. Signed-off-by: Dave Martin dave.mar...@linaro.org --- arch/arm/mach-omap2/include/mach/omap4-common.h |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/include/mach/omap4-common.h b/arch/arm/mach-omap2/include/mach/omap4-common.h index 5b0270b..de441c0 100644 --- a/arch/arm/mach-omap2/include/mach/omap4-common.h +++ b/arch/arm/mach-omap2/include/mach/omap4-common.h @@ -17,8 +17,12 @@ * wfi used in low power code. Directly opcode is used instead * of instruction to avoid mulit-omap build break */ +#ifdef CONFIG_THUMB2_KERNEL +#define do_wfi() __asm__ __volatile__ (wfi : : : memory) +#else #define do_wfi() \ __asm__ __volatile__ (.word0xe320f003 : : : memory) +#endif #ifdef CONFIG_CACHE_L2X0 extern void __iomem *l2cache_base; -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 2/5] ARM: omap4: Convert END() to ENDPROC() for correct linkage with CONFIG_THUMB2_KERNEL
Code marked with ENTRY() also needs a matching ENDPROC() directive,
in order to ensure that the type and instruction set of the
symbol are correctly annotated.
ENDPROC() tags the affected symbol as a function symbol, which will
ensure that link-time fixups don't accidentally switch to the
wrong instruction set.
Signed-off-by: Dave Martin dave.mar...@linaro.org
Tested-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/omap-headsmp.S |2 +-
arch/arm/mach-omap2/omap44xx-smc.S |8
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-headsmp.S
b/arch/arm/mach-omap2/omap-headsmp.S
index 6ae937a..4ee6aec 100644
--- a/arch/arm/mach-omap2/omap-headsmp.S
+++ b/arch/arm/mach-omap2/omap-headsmp.S
@@ -45,5 +45,5 @@ hold: ldr r12,=0x103
* should now contain the SVC stack for this core
*/
b secondary_startup
-END(omap_secondary_startup)
+ENDPROC(omap_secondary_startup)
diff --git a/arch/arm/mach-omap2/omap44xx-smc.S
b/arch/arm/mach-omap2/omap44xx-smc.S
index 1980dc3..e69d37d 100644
--- a/arch/arm/mach-omap2/omap44xx-smc.S
+++ b/arch/arm/mach-omap2/omap44xx-smc.S
@@ -29,7 +29,7 @@ ENTRY(omap_smc1)
dsb
smc #0
ldmfd sp!, {r2-r12, pc}
-END(omap_smc1)
+ENDPROC(omap_smc1)
ENTRY(omap_modify_auxcoreboot0)
stmfd sp!, {r1-r12, lr}
@@ -37,7 +37,7 @@ ENTRY(omap_modify_auxcoreboot0)
dsb
smc #0
ldmfd sp!, {r1-r12, pc}
-END(omap_modify_auxcoreboot0)
+ENDPROC(omap_modify_auxcoreboot0)
ENTRY(omap_auxcoreboot_addr)
stmfd sp!, {r2-r12, lr}
@@ -45,7 +45,7 @@ ENTRY(omap_auxcoreboot_addr)
dsb
smc #0
ldmfd sp!, {r2-r12, pc}
-END(omap_auxcoreboot_addr)
+ENDPROC(omap_auxcoreboot_addr)
ENTRY(omap_read_auxcoreboot0)
stmfd sp!, {r2-r12, lr}
@@ -54,4 +54,4 @@ ENTRY(omap_read_auxcoreboot0)
smc #0
mov r0, r0, lsr #9
ldmfd sp!, {r2-r12, pc}
-END(omap_read_auxcoreboot0)
+ENDPROC(omap_read_auxcoreboot0)
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 3/5] ARM: omap3: Remove hand-encoded SMC instructions
For various reasons, Linux now only officially supports being built with tools which are new enough to understand the SMC instruction. Replacing the hand-encoded instructions when the mnemonic also allows for correct assembly in Thumb-2 (otherwise, the result is random data in the middle of the code). The Makefile already ensures that this file is built with a high enough gcc -march= flag (armv7-a). Signed-off-by: Dave Martin dave.mar...@linaro.org Tested-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/mach-omap2/sleep34xx.S | 14 +++--- 1 files changed, 7 insertions(+), 7 deletions(-) diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S index 98d8232..a05c348 100644 --- a/arch/arm/mach-omap2/sleep34xx.S +++ b/arch/arm/mach-omap2/sleep34xx.S @@ -133,7 +133,7 @@ ENTRY(save_secure_ram_context) mov r6, #0xff mcr p15, 0, r0, c7, c10, 4 @ data write barrier mcr p15, 0, r0, c7, c10, 5 @ data memory barrier - .word 0xE1600071 @ call SMI monitor (smi #1) + smc #1 @ call SMI monitor (smi #1) nop nop nop @@ -408,7 +408,7 @@ skipl2dis: adr r3, l2_inv_api_params @ r3 points to dummy parameters mcr p15, 0, r0, c7, c10, 4 @ data write barrier mcr p15, 0, r0, c7, c10, 5 @ data memory barrier - .word 0xE1600071 @ call SMI monitor (smi #1) + smc #1 @ call SMI monitor (smi #1) /* Write to Aux control register to set some bits */ mov r0, #42 @ set service ID for PPA mov r12, r0 @ copy secure Service ID in r12 @@ -419,7 +419,7 @@ skipl2dis: ldr r3, [r4, #0xBC] @ r3 points to parameters mcr p15, 0, r0, c7, c10, 4 @ data write barrier mcr p15, 0, r0, c7, c10, 5 @ data memory barrier - .word 0xE1600071 @ call SMI monitor (smi #1) + smc #1 @ call SMI monitor (smi #1) #ifdef CONFIG_OMAP3_L2_AUX_SECURE_SAVE_RESTORE /* Restore L2 aux control register */ @@ -434,7 +434,7 @@ skipl2dis: addsr3, r3, #8 @ r3 points to parameters mcr p15, 0, r0, c7, c10, 4 @ data write barrier mcr p15, 0, r0, c7, c10, 5 @ data memory barrier - .word 0xE1600071 @ call SMI monitor (smi #1) + smc #1 @ call SMI monitor (smi #1) #endif b logic_l1_restore @@ -443,18 +443,18 @@ l2_inv_api_params: l2_inv_gp: /* Execute smi to invalidate L2 cache */ mov r12, #0x1 @ set up to invalidate L2 - .word 0xE1600070@ Call SMI monitor (smieq) + smc #0 @ Call SMI monitor (smieq) /* Write to Aux control register to set some bits */ ldr r4, scratchpad_base ldr r3, [r4,#0xBC] ldr r0, [r3,#4] mov r12, #0x3 - .word 0xE1600070 @ Call SMI monitor (smieq) + smc #0 @ Call SMI monitor (smieq) ldr r4, scratchpad_base ldr r3, [r4,#0xBC] ldr r0, [r3,#12] mov r12, #0x2 - .word 0xE1600070 @ Call SMI monitor (smieq) + smc #0 @ Call SMI monitor (smieq) logic_l1_restore: ldr r1, l2dis_3630 cmp r1, #0x1@ Test if L2 re-enable needed on 3630 -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 4/5] ARM: omap3: Thumb-2 compatibility for sram34xx.S
* Build unconditionally as ARM for correct interoperation with OMAP firmware. * Remove deprecated PC-relative stores * Add the required ENDPROC() directive for each ENTRY(). * .align before data words Signed-off-by: Dave Martin dave.mar...@linaro.org --- arch/arm/mach-omap2/sram34xx.S | 36 1 files changed, 28 insertions(+), 8 deletions(-) diff --git a/arch/arm/mach-omap2/sram34xx.S b/arch/arm/mach-omap2/sram34xx.S index 7f893a2..fd1531c 100644 --- a/arch/arm/mach-omap2/sram34xx.S +++ b/arch/arm/mach-omap2/sram34xx.S @@ -34,6 +34,12 @@ #include sdrc.h #include cm2xxx_3xxx.h +/* + * This file needs be built unconditionally as ARM to interoperate correctly + * with non-Thumb-2-capable firmware. + */ + .arm + .text /* r1 parameters */ @@ -116,24 +122,36 @@ ENTRY(omap3_sram_configure_core_dpll) @ pull the extra args off the stack @ and store them in SRAM + +/* + * PC-relative stores are deprecated in ARMv7 and lead to undefined behaviour + * in Thumb-2: use a r7 as a base instead. + * Be careful not to clobber r7 when maintaing this file. + */ + THUMB(adr r7, omap3_sram_configure_core_dpll ) + .macro strtext Rt:req, label:req + ARM( str \Rt, \label ) + THUMB(str \Rt, [r7, \label - omap3_sram_configure_core_dpll] ) + .endm + ldr r4, [sp, #52] - str r4, omap_sdrc_rfr_ctrl_0_val + strtext r4, omap_sdrc_rfr_ctrl_0_val ldr r4, [sp, #56] - str r4, omap_sdrc_actim_ctrl_a_0_val + strtext r4, omap_sdrc_actim_ctrl_a_0_val ldr r4, [sp, #60] - str r4, omap_sdrc_actim_ctrl_b_0_val + strtext r4, omap_sdrc_actim_ctrl_b_0_val ldr r4, [sp, #64] - str r4, omap_sdrc_mr_0_val + strtext r4, omap_sdrc_mr_0_val ldr r4, [sp, #68] - str r4, omap_sdrc_rfr_ctrl_1_val + strtext r4, omap_sdrc_rfr_ctrl_1_val cmp r4, #0 @ if SDRC_RFR_CTRL_1 is 0, beq skip_cs1_params @ do not use cs1 params ldr r4, [sp, #72] - str r4, omap_sdrc_actim_ctrl_a_1_val + strtext r4, omap_sdrc_actim_ctrl_a_1_val ldr r4, [sp, #76] - str r4, omap_sdrc_actim_ctrl_b_1_val + strtext r4, omap_sdrc_actim_ctrl_b_1_val ldr r4, [sp, #80] - str r4, omap_sdrc_mr_1_val + strtext r4, omap_sdrc_mr_1_val skip_cs1_params: mrc p15, 0, r8, c1, c0, 0 @ read ctrl register bic r10, r8, #0x800 @ clear Z-bit, disable branch prediction @@ -271,6 +289,7 @@ skip_cs1_prog: ldr r12, [r11] @ posted-write barrier for SDRC bx lr + .align omap3_sdrc_power: .word OMAP34XX_SDRC_REGADDR(SDRC_POWER) omap3_cm_clksel1_pll: @@ -319,6 +338,7 @@ omap3_sdrc_dlla_ctrl: .word OMAP34XX_SDRC_REGADDR(SDRC_DLLA_CTRL) core_m2_mask_val: .word 0x07FF +ENDPROC(omap3_sram_configure_core_dpll) ENTRY(omap3_sram_configure_core_dpll_sz) .word . - omap3_sram_configure_core_dpll -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 5/5] ARM: omap3: Thumb-2 compatibility for sleep34xx.S
* Build unconditionally as ARM for correct interoperation with
OMAP firmware.
* Fix an out-of-range ADR when building for ARM.
* Remove deprecated PC-relative stores.
* Add the required ENDPROC() directive for each ENTRY().
* .align before data words.
* Handle non-interworking return from v7_flush_dcache_all.
Signed-off-by: Dave Martin dave.mar...@linaro.org
---
arch/arm/mach-omap2/sleep34xx.S | 48 ++
1 files changed, 43 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
index a05c348..f377724 100644
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
@@ -64,6 +64,11 @@
#define SDRC_DLLA_STATUS_V OMAP34XX_SDRC_REGADDR(SDRC_DLLA_STATUS)
#define SDRC_DLLA_CTRL_V OMAP34XX_SDRC_REGADDR(SDRC_DLLA_CTRL)
+/*
+ * This file needs be built unconditionally as ARM to interoperate correctly
+ * with non-Thumb-2-capable firmware.
+ */
+ .arm
/*
* API functions
@@ -82,6 +87,8 @@ ENTRY(get_restore_pointer)
stmfd sp!, {lr} @ save registers on stack
adr r0, restore
ldmfd sp!, {pc} @ restore regs and return
+ENDPROC(get_restore_pointer)
+ .align
ENTRY(get_restore_pointer_sz)
.word . - get_restore_pointer
@@ -91,6 +98,8 @@ ENTRY(get_omap3630_restore_pointer)
stmfd sp!, {lr} @ save registers on stack
adr r0, restore_3630
ldmfd sp!, {pc} @ restore regs and return
+ENDPROC(get_omap3630_restore_pointer)
+ .align
ENTRY(get_omap3630_restore_pointer_sz)
.word . - get_omap3630_restore_pointer
@@ -100,6 +109,8 @@ ENTRY(get_es3_restore_pointer)
stmfd sp!, {lr} @ save registers on stack
adr r0, restore_es3
ldmfd sp!, {pc} @ restore regs and return
+ENDPROC(get_es3_restore_pointer)
+ .align
ENTRY(get_es3_restore_pointer_sz)
.word . - get_es3_restore_pointer
@@ -113,8 +124,10 @@ ENTRY(enable_omap3630_toggle_l2_on_restore)
stmfd sp!, {lr} @ save registers on stack
/* Setup so that we will disable and enable l2 */
mov r1, #0x1
- str r1, l2dis_3630
+ adrlr2, l2dis_3630 @ may be too distant for plain adr
+ str r1, [r2]
ldmfd sp!, {pc} @ restore regs and return
+ENDPROC(enable_omap3630_toggle_l2_on_restore)
.text
/* Function to call rom code to save secure ram context */
@@ -139,12 +152,14 @@ ENTRY(save_secure_ram_context)
nop
nop
ldmfd sp!, {r1-r12, pc}
+ .align
sram_phy_addr_mask:
.word SRAM_BASE_P
high_mask:
.word 0x
api_params:
.word 0x4, 0x0, 0x0, 0x1, 0x1
+ENDPROC(save_secure_ram_context)
ENTRY(save_secure_ram_context_sz)
.word . - save_secure_ram_context
@@ -279,8 +294,18 @@ clean_l2:
* - 'might' have to copy address, load and jump to it
*/
ldr r1, kernel_flush
- mov lr, pc
- bx r1
+ blx r1
+ /*
+* The kernel doesn't interwork: v7_flush_dcache_all in particluar will
+* always return in Thumb state when CONFIG_THUMB2_KERNEL is enabled.
+* This sequence switches back to ARM. Note that .align may insert a
+* nop: bx pc needs to be word-aligned in order to work.
+*/
+ THUMB(.thumb )
+ THUMB(.align )
+ THUMB(bx pc )
+ THUMB(nop )
+ .arm
omap3_do_wfi:
ldr r4, sdrc_power @ read the SDRC_POWER register
@@ -438,6 +463,7 @@ skipl2dis:
#endif
b logic_l1_restore
+ .align
l2_inv_api_params:
.word 0x1, 0x00
l2_inv_gp:
@@ -607,6 +633,7 @@ usettbr0:
/* This function implements the erratum ID i443 WA, applies to 34xx = ES3.0 */
.text
+ .align 3
ENTRY(es3_sdrc_fix)
ldr r4, sdrc_syscfg @ get config addr
ldr r5, [r4]@ get value
@@ -634,6 +661,7 @@ ENTRY(es3_sdrc_fix)
str r5, [r4]@ kick off refreshes
bx lr
+ .align
sdrc_syscfg:
.word SDRC_SYSCONFIG_P
sdrc_mr_0:
@@ -648,6 +676,7 @@ sdrc_emr2_1:
.word SDRC_EMR2_1_P
sdrc_manual_1:
.word SDRC_MANUAL_1_P
+ENDPROC(es3_sdrc_fix)
ENTRY(es3_sdrc_fix_sz)
.word . - es3_sdrc_fix
@@ -682,6 +711,12 @@ wait_sdrc_ready:
bic r5, r5, #0x40
str r5, [r4]
+/*
+ * PC-relative stores lead to undefined behaviour in Thumb-2: use a r7 as a
+ * base instead.
+ * Be careful not to clobber r7 when maintaing this code.
+ */
+
is_dll_in_lock_mode:
/* Is dll in lock mode? */
ldr r4, sdrc_dlla_ctrl
@@ -689,10 +724,11 @@ is_dll_in_lock_mode:
tst r5, #0x4
bxnelr @ Return if locked
/* wait till dll locks */
+ adr
Re: [PATCH] ARM: Avoid discarding sections that might have SMP_ON_UP fixups
Hi, On Fri, Feb 11, 2011 at 04:32:47PM +, Russell King - ARM Linux wrote: [...] diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S index 45b5651..343d29f 100644 --- a/arch/arm/kernel/vmlinux.lds.S +++ b/arch/arm/kernel/vmlinux.lds.S @@ -21,6 +21,12 @@ #define ARM_CPU_KEEP(x) #endif +#if defined(CONFIG_SMP_ON_UP) !defined(CONFIG_DEBUG_SPINLOCK) +#define ARM_EXIT_KEEP(x) x +#else +#define ARM_EXIT_KEEP(x) +#endif + OUTPUT_ARCH(arm) ENTRY(stext) @@ -43,6 +49,7 @@ SECTIONS _sinittext = .; HEAD_TEXT INIT_TEXT + ARM_EXIT_KEEP(EXIT_TEXT) _einittext = .; ARM_CPU_DISCARD(PROC_INFO) __arch_info_begin = .; @@ -71,6 +78,7 @@ SECTIONS #ifndef CONFIG_XIP_KERNEL __init_begin = _stext; INIT_DATA + ARM_EXIT_KEEP(EXIT_DATA) #endif } @@ -166,6 +174,7 @@ SECTIONS . = ALIGN(PAGE_SIZE); __init_begin = .; INIT_DATA + ARM_EXIT_KEEP(EXIT_DATA) . = ALIGN(PAGE_SIZE); __init_end = .; #endif ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel This works for me in a case known to fail without the patch. Tested-by: Dave Martin dave.mar...@linaro.org I still don't quite understand the intricacies of how vmlinux is laid out, but the patch looks sensible. Do you need anything more from me on this? If not, I will throw away my patch and replace it with yours. Cheers ---Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/5] ARM: omap[34]: Thumb-2 compatibility fixes
On Mon, Feb 14, 2011 at 11:15 PM, Kevin Hilman khil...@ti.com wrote: Hi Dave, Dave Martin dave.mar...@linaro.org writes: On Mon, Feb 14, 2011 at 10:00:23AM -0500, Nicolas Pitre wrote: On Mon, 14 Feb 2011, Dave Martin wrote: @@ -289,8 +297,20 @@ clean_l2: * - should be faster and will change with kernel * - 'might' have to copy address, load and jump to it */ +#ifdef CONFIG_THUMB2_KERNEL + /* kernel is non-interworking : must do this from Thumb */ + adr r1, . + 1 + bx r1 + .thumb +#endif ldr r1, kernel_flush Didn't you mean this instead: /* kernel is non-interworking : must do this from Thumb */ adr r1, 1f + 1 bx r1 .thumb 1: ldr r1, kernel_flush ... Note that this is intended as an experimental hack, not a real patch (apologies if I didn't make that clear...) Well, actually I meant add r1, pc, #1 ... which means I was too busy trying to be clever... oops! That is of course exactly equivalent to your code... ? blx r1 +#ifdef CONFIG_THUMB2_KERNEL + .align + bx pc + nop + .arm Also here, the .align has the potential to introduce a zero halfword in the instruction stream before the bx. What about: adr r3, 1f bx r3 .align .arm 1: ... .align inserts a 16-bit nop when misaligned in Thumb in a text section, and a word-aligned bx pc is a specific architecturally allowed way to do an inline switch to ARM. The linker uses this trick for PLT veneers etc. A nicer fix for doing this sort of call from low-level code which might be ARM is to convert arch/arm/mm/*-v7.S to use bx lr to return. Generally, we can do this for all arches = v5, without any incompatibility. However, since the need for it will be rare and it will generate patch noise for not much real benefit, I haven't proposed this. Updated patch below. I tested the updated patch on top of your dirty branch I tested with last week, and now see off-mode working just fine. Thanks for testing-- that's great news. I will have a think about whether the patch can be tidied up to revert most of the code back to Thumb, though that isn't essential. If I've understood what's going on correctly, I think only the restore entry points, SMC call sites and the entry to omap3_sram_configure_core_dpll could need to be ARM; the rest shouldn't really make any difference... Cheers ---Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/5] ARM: omap[34]: Thumb-2 compatibility fixes
On Fri, Feb 11, 2011 at 03:31:20PM -0800, Kevin Hilman wrote: Hi Dave, Dave Martin dave.mar...@linaro.org writes: This set of patches, along with some other patches under discussion on alkml, should enable omap3 and omap4 kernels to be built with CONFIG_THUMB2_KERNEL. OK, I tried some more testing with your 'dirty' branch merged with my PM branch. Compiled in ARM mode, everything worked as expected on my 3530/omap3evm, including off-mode (in suspend and idle). My 3630 (Zoom3) also can't do CORE off due to i583, but MPU, PER etc. all can hit off. To rebuild in Thumb-2 mode, I disabled OMAP2 support and added Thumb-2 mode: CONFIG_ARCH_OMAP2=n CONFIG_THUMB2_KERNEL=y then tested on 3530/omap3evm. Testing suspend/resume to retention seemed to work fine. However, enabling retention during idle[1] hung someplace (didn't debug further.) I also tried off-mode, and suspend/resume to off didn't even work. I didn't have time to debug this any further, so this is just to report raw test results. Thanks, that's a useful step forward anyhow. A possibility is that the Secure firmware can't cope with interoperating with Thumb-2 code in the kernel, so that wakeup entry points the SMC call sites may need to be ARM code. If you get a moment, if would be interesting to see if this patch makes a difference ... in the meantime, I'll see if I can get my hands on an EVM from somewhere. Cheers ---Dave diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S index a204c78..ee1edb1 100644 --- a/arch/arm/mach-omap2/sleep34xx.S +++ b/arch/arm/mach-omap2/sleep34xx.S @@ -32,6 +32,14 @@ #include sdrc.h #include control.h +#undef ARM +#undef THUMB +#undef BSYM +#define ARM(x...) x +#define THUMB(x...) +#define BSYM(x) (x) + .arm + /* * Registers access definitions */ @@ -289,8 +297,20 @@ clean_l2: * - should be faster and will change with kernel * - 'might' have to copy address, load and jump to it */ +#ifdef CONFIG_THUMB2_KERNEL + /* kernel is non-interworking : must do this from Thumb */ + adr r1, . + 1 + bx r1 + .thumb +#endif ldr r1, kernel_flush blx r1 +#ifdef CONFIG_THUMB2_KERNEL + .align + bx pc + nop + .arm +#endif omap3_do_wfi: ldr r4, sdrc_power @ read the SDRC_POWER register diff --git a/arch/arm/mach-omap2/sram34xx.S b/arch/arm/mach-omap2/sram34xx.S index 829d235..64faab8 100644 --- a/arch/arm/mach-omap2/sram34xx.S +++ b/arch/arm/mach-omap2/sram34xx.S @@ -34,6 +34,14 @@ #include sdrc.h #include cm2xxx_3xxx.h +#undef ARM +#undef THUMB +#undef BSYM +#define ARM(x...) x +#define THUMB(x...) +#define BSYM(x) (x) + .arm + .text /* r1 parameters */ -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/5] ARM: omap[34]: Thumb-2 compatibility fixes
On Mon, Feb 14, 2011 at 10:00:23AM -0500, Nicolas Pitre wrote: On Mon, 14 Feb 2011, Dave Martin wrote: @@ -289,8 +297,20 @@ clean_l2: * - should be faster and will change with kernel * - 'might' have to copy address, load and jump to it */ +#ifdef CONFIG_THUMB2_KERNEL + /* kernel is non-interworking : must do this from Thumb */ + adr r1, . + 1 + bx r1 + .thumb +#endif ldr r1, kernel_flush Didn't you mean this instead: /* kernel is non-interworking : must do this from Thumb */ adr r1, 1f + 1 bx r1 .thumb 1:ldr r1, kernel_flush ... Note that this is intended as an experimental hack, not a real patch (apologies if I didn't make that clear...) Well, actually I meant add r1, pc, #1 ... which means I was too busy trying to be clever... oops! That is of course exactly equivalent to your code... ? blx r1 +#ifdef CONFIG_THUMB2_KERNEL + .align + bx pc + nop + .arm Also here, the .align has the potential to introduce a zero halfword in the instruction stream before the bx. What about: adr r3, 1f bx r3 .align .arm 1:... .align inserts a 16-bit nop when misaligned in Thumb in a text section, and a word-aligned bx pc is a specific architecturally allowed way to do an inline switch to ARM. The linker uses this trick for PLT veneers etc. A nicer fix for doing this sort of call from low-level code which might be ARM is to convert arch/arm/mm/*-v7.S to use bx lr to return. Generally, we can do this for all arches = v5, without any incompatibility. However, since the need for it will be rare and it will generate patch noise for not much real benefit, I haven't proposed this. Updated patch below. Cheers ---Dave diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S index a204c78..6ae8a92 100644 --- a/arch/arm/mach-omap2/sleep34xx.S +++ b/arch/arm/mach-omap2/sleep34xx.S @@ -32,6 +32,14 @@ #include sdrc.h #include control.h +#undef ARM +#undef THUMB +#undef BSYM +#define ARM(x...) x +#define THUMB(x...) +#define BSYM(x) (x) + .arm + /* * Registers access definitions */ @@ -289,8 +297,20 @@ clean_l2: * - should be faster and will change with kernel * - 'might' have to copy address, load and jump to it */ - ldr r1, kernel_flush +#ifdef CONFIG_THUMB2_KERNEL + /* kernel is non-interworking : must do this from Thumb */ + adr r1, 1f + 1 + bx r1 + .thumb +#endif +1: ldr r1, kernel_flush blx r1 +#ifdef CONFIG_THUMB2_KERNEL + .align + bx pc + nop + .arm +#endif omap3_do_wfi: ldr r4, sdrc_power @ read the SDRC_POWER register diff --git a/arch/arm/mach-omap2/sram34xx.S b/arch/arm/mach-omap2/sram34xx.S index 829d235..64faab8 100644 --- a/arch/arm/mach-omap2/sram34xx.S +++ b/arch/arm/mach-omap2/sram34xx.S @@ -34,6 +34,14 @@ #include sdrc.h #include cm2xxx_3xxx.h +#undef ARM +#undef THUMB +#undef BSYM +#define ARM(x...) x +#define THUMB(x...) +#define BSYM(x) (x) + .arm + .text /* r1 parameters */ -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: Avoid discarding sections that might have SMP_ON_UP fixups
On Thu, Feb 10, 2011 at 7:11 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Thu, Feb 10, 2011 at 06:29:41PM +, Dave Martin wrote: On Thu, Feb 10, 2011 at 2:46 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Thu, Feb 10, 2011 at 02:13:13PM +, Dave Martin wrote: Note that this tree contains some extra patches (though I believe nothing is there which should cause the problem), and does not contain everything from rmk/devel -- so it's possible this has been fixed in the meantime or no longer occurs for some other reason... No need - I now have some modules which contain SMP alternatives, so we do need to fix the module loader for this, and keep the SMP alternatives replacement code around. It's not worth eliminating the code as if we include an informative printk() to say why we're refusing to load the module, the string would be larger than the code it eliminates. So, I think we need to merge the patch below to avoid run-time problems. I thought the problem was not caused by removal of the fixup code, but rather by the removal of code referenced by fixups? It is. But: arm-linux-objdump -h sound/core/snd-timer.ko sound/core/snd-timer.ko: file format elf32-littlearm Sections: Idx Name Size VMA LMA File off Algn 0 .text 2f34 0034 2**2 CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE 1 .exit.text 0070 2f68 2**2 CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE 2 .init.text 01b4 2fd8 2**2 CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE 3 .rodata 00bc 318c 2**2 CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA 4 .rodata.str1.1 0156 3248 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 5 .alt.smp.init 0088 339e 2**0 CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA ... Here we have a module which contains the spin_unlock assembly, which contains the SMP alternatives. If we insert that into a kernel also built with SMP alternatives support, but which is running on a UP system, we need to run these fixups as well when the module is loaded. Agreed -- actually, I suspected we might need to support this. But I don't think solving this problem (= keeping the fixup implementation in memory and enhancing the module loader) solved the fixups-referencing-sections-discarded-from-vmlinux problem. These seem to be two separate issues. I am filing to understand something? Cheers ---Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/5] ARM: omap[34]: Thumb-2 compatibility fixes
On Thu, Feb 10, 2011 at 9:38 PM, Kevin Hilman khil...@ti.com wrote: Santosh Shilimkar santosh.shilim...@ti.com writes: [...] The SD card gets suspended, but nothing else seems to happen, and I can't resume the system. Am I doing something wrong? MMC suspend is broken. I use ramdisk-ext3 or NFS for my testing Just to clarify, MMC suspend is not broken. It's a feature the MMC core. See the help text of the following Kconfig option, and ensure that it's enabled: config MMC_UNSAFE_RESUME bool Assume MMC/SD cards are non-removable (DANGEROUS) help If you say Y here, the MMC layer will assume that all cards stayed in their respective slots during the suspend. The normal behaviour is to remove them at suspend and redetecting them at resume. Breaking this assumption will in most cases result in data corruption. This option is usually just for embedded systems which use a MMC/SD card for rootfs. Most people should say N here. This option sets a default which can be overridden by the module parameter removable=0 or removable=1. Looking at Dave's .config, this option is disabled, so suspend will hang when rootfs is on MMC. Thanks for the clarification. For simplicity, and since Thumb-2 should be unrelated to the MMC subsystem, I've been testing suspend from the initramfs instead ... which sidesteps the MMC issue. Power-off-suspend does still have some weird problems when CONFIG_THUMB2_KERNEL is enabled; I'm still investigating this. Cheers ---Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 5/5] ARM: omap3: Thumb-2 compatibility for sleep34xx.S
On Thu, Feb 10, 2011 at 10:17 PM, Kevin Hilman khil...@ti.com wrote: Dave Martin dave.mar...@linaro.org writes: * Use BSYM() to get the correct Thumb branch address for adr Rd, label * Fix an out-of-range ADR when building for ARM * Correctly call es3_sdrc_fix as Thumb when copied to SRAM. * Remove deprecated/undefined PC-relative stores * Add the required ENDPROC() directive for each ENTRY(). * .align before data words Signed-off-by: Dave Martin dave.mar...@linaro.org I'm attempting to test this series with OMAP PM, but some changes here don't compile for me. My toolchain is: gcc version 4.5.1 (Sourcery G++ Lite 2010.09-50) First, I merged your arm/omap-thumb2+merged branch with my pm branch from git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git There were some minor conflicts here, but they looked simple enough and I just resolved in favor of your branch. Thanks for giving it a try. Trying to build with CONFIG_THUMB2_KERNEL=y, I ran into a compile problem... [...] + adr r0, es3_sdrc_fix @ Not using BSYM clears the Thumb bit. This fails to compile: /work/kernel/omap/pm/arch/arm/mach-omap2/sleep34xx.S: Assembler messages: /work/kernel/omap/pm/arch/arm/mach-omap2/sleep34xx.S:361: Error: invalid immediate for address calculation (value = 0x0004) Unfortunately, this is caused by a bug in the assembler. arch/arm/kernel/relocate_kernel.S also suffers from the same bug when built with CONFIG_THUMB2_KERNEL. If you had got as far a linking, it's likely you would hit a 'reference to discarded section problem' error in the linker, due to discarding of some sections referenced by SMP_ON_UP fixups. If you merge the 3 extra patches from dirty/arm/omap-thumb2+merged it should resolve these issues, but how to fix these things upstream is still under discussion. Cheers ---Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: Avoid discarding sections that might have SMP_ON_UP fixups
On Fri, Feb 11, 2011 at 10:13 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Fri, Feb 11, 2011 at 09:33:56AM +, Dave Martin wrote: Agreed -- actually, I suspected we might need to support this. But I don't think solving this problem (= keeping the fixup implementation in memory and enhancing the module loader) solved the fixups-referencing-sections-discarded-from-vmlinux problem. These seem to be two separate issues. I am filing to understand something? They are separate, but related issues. They both ultimately have the same cause - the placement of the spinlock code inline rather than out of line, resulting in fixups appearing all over the place rather than just in kernel/spinlock.o. I guess what I want to understand is whether I (or someone) still need(s) to sort out the vmlinux.lds issue. If we're keeping inline spinlocks (I currently assume yes), then the vmlinux.lds issue still needs fixing. Is that correct? However, if we get rid of inline spinlocks we won't have the problem, though there may be some performance impact -- hard to judge how significant. Apologies if I'm being dense here... Cheers ---Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 5/5] ARM: omap3: Thumb-2 compatibility for sleep34xx.S
On Fri, Feb 11, 2011 at 12:07 AM, Kevin Hilman khil...@ti.com wrote: Kevin Hilman khil...@ti.com writes: Dave Martin dave.mar...@linaro.org writes: * Use BSYM() to get the correct Thumb branch address for adr Rd, label * Fix an out-of-range ADR when building for ARM * Correctly call es3_sdrc_fix as Thumb when copied to SRAM. * Remove deprecated/undefined PC-relative stores * Add the required ENDPROC() directive for each ENTRY(). * .align before data words Signed-off-by: Dave Martin dave.mar...@linaro.org I'm attempting to test this series with OMAP PM, but some changes here don't compile for me. My toolchain is: gcc version 4.5.1 (Sourcery G++ Lite 2010.09-50) First, I merged your arm/omap-thumb2+merged branch with my pm branch from git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git Sorry for the confusion, this patch should've been in reply to your v4 version, since I merged with your 'arm/omap-thumb2+merged' branch from today. If you are able to test off mode with CONFIG_THUMB2_KERNEL enabled, that would be great. I have some evidence that the resume path may be working in Thumb-2, but I think I'm being bitten by erratum i583 (I have to disable the workaround to even attempt to test off mode on Beagle xM) Cheers ---Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: Avoid discarding sections that might have SMP_ON_UP fixups
On Fri, Feb 11, 2011 at 4:05 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Fri, Feb 11, 2011 at 10:52:17AM +, Dave Martin wrote: On Fri, Feb 11, 2011 at 10:13 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Fri, Feb 11, 2011 at 09:33:56AM +, Dave Martin wrote: Agreed -- actually, I suspected we might need to support this. But I don't think solving this problem (= keeping the fixup implementation in memory and enhancing the module loader) solved the fixups-referencing-sections-discarded-from-vmlinux problem. These seem to be two separate issues. I am filing to understand something? They are separate, but related issues. They both ultimately have the same cause - the placement of the spinlock code inline rather than out of line, resulting in fixups appearing all over the place rather than just in kernel/spinlock.o. I guess what I want to understand is whether I (or someone) still need(s) to sort out the vmlinux.lds issue. Yes we do - if you build your kernel you should find that your link fails because of discarded sections being referenced. Yep -- I'm still applying my original patch to work around that, but it sounds like I need to tidy that up. Can you elaborate on what you meant by defining a KEEP_EXIT macro to handle this? If we're keeping inline spinlocks (I currently assume yes), then the vmlinux.lds issue still needs fixing. Is that correct? However, if we get rid of inline spinlocks we won't have the problem, though there may be some performance impact -- hard to judge how significant. I don't see that we can get rid of inline spinlocks - it's controlled by stuff external to the arch. That's fine -- just wanted to make sure I had the right understanding. Cheers ---Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: Avoid discarding sections that might have SMP_ON_UP fixups
On Thu, Feb 10, 2011 at 12:56 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Wed, Feb 09, 2011 at 02:22:11PM +, Russell King - ARM Linux wrote: On Wed, Jan 26, 2011 at 05:25:35PM +, Dave P. Martin wrote: SMP_ON_UP fixups lead to vmlinux link errors if those sections are discarded at link-time. In particular this may happen for built-in __exit stuff. This patch modifies the vmlinux linker script to reduce the amount of discarded sections, and tries to make sure that __exit sections are kept in. This is a hack and probably wrong! Further discussion is needed. Can you send the configuration which you see this problem with? I've tried to build a kernel which inlines the spinlocks, but I find that's not possible, so I'm doubting whether any fix is required for mainline. Any news on this, or can it not be reproduced? Hi, apologies-- didn't see my mail for a bit. I get the problem with this tree and config (which builds with SMP_ON_UP and THUMB2_KERNEL for omap3/4): Tree: git://git.linaro.org/people/dmart/linux-2.6-arm.git dirty/arm/omap-thumb2+merged Config: http://people.linaro.org/~dmart/arm_omap-thumb2+v2_config I haven't identified the precise combination of options which causes the problem, and I don't really understand what the clean solution would be -- it's on my list of stuff to look at, but not at the top. Other people not enabling THUMB2_KERNEL have also had the problem (though I guess that shouldn't make a difference anyway). I suggested a patch on the binutils mailing list to add a way for putting fixups in separate, sensibly-named sections which would allow for a proper fix to this class of problem, but I haven't had any significant feedback on that ... anyway, that would not be available on most people's toolchains for a while even if it got accepted -- see: http://cygwin.com/ml/binutils/2011-02/msg4.html Cheers ---Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: Avoid discarding sections that might have SMP_ON_UP fixups
On Thu, Feb 10, 2011 at 2:11 PM, Dave Martin dave.mar...@linaro.org wrote: On Thu, Feb 10, 2011 at 12:56 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Wed, Feb 09, 2011 at 02:22:11PM +, Russell King - ARM Linux wrote: On Wed, Jan 26, 2011 at 05:25:35PM +, Dave P. Martin wrote: SMP_ON_UP fixups lead to vmlinux link errors if those sections are discarded at link-time. In particular this may happen for built-in __exit stuff. This patch modifies the vmlinux linker script to reduce the amount of discarded sections, and tries to make sure that __exit sections are kept in. This is a hack and probably wrong! Further discussion is needed. Can you send the configuration which you see this problem with? I've tried to build a kernel which inlines the spinlocks, but I find that's not possible, so I'm doubting whether any fix is required for mainline. Any news on this, or can it not be reproduced? Hi, apologies-- didn't see my mail for a bit. I get the problem with this tree and config (which builds with SMP_ON_UP and THUMB2_KERNEL for omap3/4): Tree: git://git.linaro.org/people/dmart/linux-2.6-arm.git dirty/arm/omap-thumb2+merged Config: http://people.linaro.org/~dmart/arm_omap-thumb2+v2_config Note that this tree contains some extra patches (though I believe nothing is there which should cause the problem), and does not contain everything from rmk/devel -- so it's possible this has been fixed in the meantime or no longer occurs for some other reason... Cheers ---Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: Avoid discarding sections that might have SMP_ON_UP fixups
On Thu, Feb 10, 2011 at 2:46 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Thu, Feb 10, 2011 at 02:13:13PM +, Dave Martin wrote: On Thu, Feb 10, 2011 at 2:11 PM, Dave Martin dave.mar...@linaro.org wrote: Hi, apologies-- didn't see my mail for a bit. I get the problem with this tree and config (which builds with SMP_ON_UP and THUMB2_KERNEL for omap3/4): Tree: git://git.linaro.org/people/dmart/linux-2.6-arm.git dirty/arm/omap-thumb2+merged Config: http://people.linaro.org/~dmart/arm_omap-thumb2+v2_config Thanks for the config. Note that this tree contains some extra patches (though I believe nothing is there which should cause the problem), and does not contain everything from rmk/devel -- so it's possible this has been fixed in the meantime or no longer occurs for some other reason... No need - I now have some modules which contain SMP alternatives, so we do need to fix the module loader for this, and keep the SMP alternatives replacement code around. It's not worth eliminating the code as if we include an informative printk() to say why we're refusing to load the module, the string would be larger than the code it eliminates. So, I think we need to merge the patch below to avoid run-time problems. I thought the problem was not caused by removal of the fixup code, but rather by the removal of code referenced by fixups? Cheers ---Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
On Wed, Feb 9, 2011 at 6:04 AM, Santosh Shilimkar santosh.shilim...@ti.com wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Tony Lindgren Sent: Wednesday, February 09, 2011 6:06 AM To: Nicolas Pitre Cc: Santosh Shilimkar; Russell King - ARM Linux; linux- o...@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: Re: [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels * Nicolas Pitre n...@fluxnic.net [110208 12:41]: On Tue, 8 Feb 2011, Santosh Shilimkar wrote: I think it's probably going to be better to _purposely_ break the OMAP build when it covers v6 and v7 CPUs in these kernels as I don't think it's sanely fixable given where we are. Agreed. At least making SMP unavailable when both v6 and v7 are configured should be small and good enough for 2.6.38-rc5. That's probably the best solution as then we can still do boot testing on all omap2plus_defconfig boards. Just to be clear, are we saying disable SMP from omap2plus build. If the v6, v7 is not fixable then, we also need a SMP config for OMAP. Just boot test with SMP disable config for OMAP4 is not enough. You could also have a v7+ unified kernel -- i.e., supporting OMAP3+4+SMP. This is what we currently do in Linaro, since we're focusing on v7 and above. Cheers ---Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/5] ARM: omap[34]: Thumb-2 compatibility fixes
On Wed, Feb 9, 2011 at 5:45 AM, Santosh Shilimkar santosh.shilim...@ti.com wrote: -Original Message- From: Dave Martin [mailto:dave.mar...@linaro.org] Sent: Tuesday, February 08, 2011 11:11 PM To: Santosh Shilimkar Cc: linux-arm-ker...@lists.infradead.org; Tony Lindgren; Jean Pihet- XID; linux-omap@vger.kernel.org; Nicolas Pitre Subject: Re: [PATCH v2 0/5] ARM: omap[34]: Thumb-2 compatibility fixes Hi Santosh, [...] I'm still having problems testing basic power management... I'm using this config: http://people.linaro.org/~dmart/arm_omap-thumb2+v2_config ... and Kevin's pm tree with my patches on top. However, even building without CONFIG_THUMB2_KERNEL, Beagle xM doesn't seem to suspend properly: Linux xm-1 2.6.38-rc2+ #19 SMP Tue Feb 8 14:02:24 GMT 2011 armv7l GNU/Linux # # [ 302.446228] SysRq : Changing Loglevel [ 302.449951] Loglevel set to 9 echo mem /sys/power/state [1] 545 # [ 306.525177] PM: Syncing filesystems ... done. [ 308.989715] mmc0: card 1234 removed # # # # # # jobs [1]+ Running echo mem /sys/power/state # The SD card gets suspended, but nothing else seems to happen, and I can't resume the system. Am I doing something wrong? MMC suspend is broken. I use ramdisk-ext3 or NFS for my testing Ah, right -- I'll try without MMC. Thanks ---Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 0/5] ARM: omap[34]: Thumb-2 compatibility fixes
This set of patches, along with some other patches under discussion on alkml, should enable omap3 and omap4 kernels to be built with CONFIG_THUMB2_KERNEL. This patch set builds on recent cleanup done by the omap maintainers. All affected low-level code is now built in Thumb-2. At least some of this code definitely works, most features have been tested successfully. Further testing, especially of Thumb-2 behaviour, is still welcome. Seems to work with CONFIG_SMP_ON_UP and CONFIG_THUMB2_KERNEL enabled on Beagle xM A2 and Panda A1. Thanks also to Santosh Shilimkar santosh.shilim...@ti.com for his help with testing. v3: * make SMC instruction syntax more consistent * remove do_wfi() in favour of the generic wfi() macro v4: * revert to the OMAP-specific do_wfi() implementation, pending discussion of how generic macros can/should be provided Details below. Cheers, Dave The patches can be found, along with a buildable working tree, in the following repo: git://git.linaro.org/people/dmart/linux-2.6-arm.git * arm/omap-thumb2: has the patches proposed here * arm/omap-thumb2+merged: additionally has some patches cherry- picked from other trees which are needed in order for the patches on arm/omap-thumb2 to work usefully. * dirty/arm/omap-thumb2+merged: buildable test tree, which adds 2 local patches to work around a toolchain bug. A working kernel config for this tree is here: http://people.linaro.org/~dmart/arm_omap-thumb2+v2_config : CONFIG_SMP_ON_UP=y CONFIG_THUMB2_KERNEL=y CONFIG_SERIAL_OMAP=n (to avoid garbage on xM; for Panda use console=ttyS2) (The config is derived from the linaro omap config and so turns on loads of modules -- don't feel you have to build them all...) Cherry-picked patches originated from Russell's devel tree and Tony Lindgren's omap-testing tree: http://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cur/linux-2.6-arm.git devel git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git omap-testing This series also depends on one un-merged patch to generic-ise the wfi() macro: git://git.linaro.org/people/dmart/linux-2.6-arm.git arm/wfi-macro Dave Martin (5): ARM: omap4: Provide do_wfi() for Thumb-2 ARM: omap4: Convert END() to ENDPROC() for correct linkage with CONFIG_THUMB2_KERNEL ARM: omap3: Remove hand-encoded SMC instructions ARM: omap3: Thumb-2 compatibility for sram34xx.S ARM: omap3: Thumb-2 compatibility for sleep34xx.S arch/arm/mach-omap2/include/mach/omap4-common.h |4 ++ arch/arm/mach-omap2/omap-headsmp.S |2 +- arch/arm/mach-omap2/omap44xx-smc.S |8 ++-- arch/arm/mach-omap2/sleep34xx.S | 56 --- arch/arm/mach-omap2/sram34xx.S | 28 --- 5 files changed, 68 insertions(+), 30 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
