Re: [RFC PATCH] ARM: omap2plus_defconfig: Switch over to using 8250 driver
[ +Sebastian, +Tony ] On 04/10/2015 02:18 PM, Nishanth Menon wrote: 8250 driver should be relatively feature complete. It can co-exist with omap-serial driver Not really; if the omap_8250 is selected then it is probed first and will be the only driver claiming omap UART ports. omap-serial would just be dead-weight. , so just enable 8250 OMAP layer driver and route all ttyOx references to ttySx through the standard 8250 driver to ensure no breakage of userspace occurs. Not quite; the only automatic handling is for console only, not for userspace. Expect lots of userspace breakage. Regards, Peter Hurley Signed-off-by: Nishanth Menon n...@ti.com --- Current upstream next-20150410 status: (all boards pass without this patch) Test is a basic boot test (using omap2plus_defconfig ofcourse).. Ofcourse: [0.001035] WARNING: Your 'console=ttyO0' has been replaced by 'ttyS0' does not help userspace when they are not able to dynamically handle switch. Just curious if folks feel we are ready for this switch yet... ttyS-change 1: am335x-evm: BOOT: PASS: http://paste.ubuntu.org.cn/2551733 2: am335x-sk: BOOT: FAIL: http://paste.ubuntu.org.cn/2551734 3: am3517-evm: BOOT: FAIL: http://paste.ubuntu.org.cn/2551735 4: am37x-evm: BOOT: FAIL: http://paste.ubuntu.org.cn/2551736 5: am437x-sk: BOOT: FAIL: http://paste.ubuntu.org.cn/2551737 6:am43xx-epos: BOOT: FAIL: http://paste.ubuntu.org.cn/2551738 7: am43xx-gpevm: BOOT: PASS: http://paste.ubuntu.org.cn/2551739 8: BeagleBoard-XM: BOOT: FAIL: http://paste.ubuntu.org.cn/2551740 9:beagleboard-vanilla: BOOT: FAIL: http://paste.ubuntu.org.cn/2551741 10: beaglebone-black: BOOT: PASS: http://paste.ubuntu.org.cn/2551742 11: beaglebone: BOOT: FAIL: http://paste.ubuntu.org.cn/2551743 12: craneboard: BOOT: FAIL: http://paste.ubuntu.org.cn/2551744 13: dra72x-evm: BOOT: FAIL: http://paste.ubuntu.org.cn/2551745 14: dra7xx-evm: BOOT: FAIL: http://paste.ubuntu.org.cn/2551746 15: OMAP3430-Labrador(LDP): BOOT: FAIL: http://paste.ubuntu.org.cn/2551747 16: n900: BOOT: FAIL: http://paste.ubuntu.org.cn/2551748 17: omap5-evm: BOOT: FAIL: http://paste.ubuntu.org.cn/2551749 18: pandaboard-es: BOOT: FAIL: http://paste.ubuntu.org.cn/2551750 19: pandaboard-vanilla: BOOT: FAIL: http://paste.ubuntu.org.cn/2551751 20:sdp2430: BOOT: FAIL: http://paste.ubuntu.org.cn/2551752 21:sdp3430: BOOT: FAIL: http://paste.ubuntu.org.cn/2551753 22:sdp4430: BOOT: FAIL: http://paste.ubuntu.org.cn/2551754 TOTAL = 22 boards, Booted Boards = 3, No Boot boards = 19 arc/arm/configs/omap2plus_defconfig |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 9ff7b54b2a83..6ef76856ac8e 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -220,6 +220,8 @@ CONFIG_SERIAL_8250_MANY_PORTS=y CONFIG_SERIAL_8250_SHARE_IRQ=y CONFIG_SERIAL_8250_DETECT_IRQ=y CONFIG_SERIAL_8250_RSA=y +CONFIG_SERIAL_8250_OMAP=y +CONFIG_SERIAL_8250_OMAP_TTYO_FIXUP=y CONFIG_SERIAL_OF_PLATFORM=y CONFIG_SERIAL_OMAP=y CONFIG_SERIAL_OMAP_CONSOLE=y -- 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] [media] omap4iss: avoid broken OMAP4 dependency
The omap4iss driver uses an interface that used to be provided
by OMAP4 but has now been removed and replaced with a WARN_ON(1)
statement, which likely broke the iss_csiphy code at runtime.
It also broke compiling the driver when CONFIG_ARCH_OMAP2PLUS
is set, which is implied by OMAP4:
drivers/staging/media/omap4iss/iss_csiphy.c: In function
'omap4iss_csiphy_config':
drivers/staging/media/omap4iss/iss_csiphy.c:167:2: error: implicit declaration
of function 'omap4_ctrl_pad_writel' [-Werror=implicit-function-declaration]
omap4_ctrl_pad_writel(cam_rx_ctrl,
In turn, this broke ARM allyesconfig builds. Replacing the
omap4_ctrl_pad_writel call with WARN_ON(1) won't make the
situation any worse than it already is, but fixes the build
problem.
Signed-off-by: Arnd Bergmann a...@arndb.de
Fixes: efde234674d9 (ARM: OMAP4+: control: remove support for legacy pad
read/write)
---
diff --git a/drivers/staging/media/omap4iss/iss_csiphy.c
b/drivers/staging/media/omap4iss/iss_csiphy.c
index 7c3d55d811ef..24f56ed90ac3 100644
--- a/drivers/staging/media/omap4iss/iss_csiphy.c
+++ b/drivers/staging/media/omap4iss/iss_csiphy.c
@@ -140,9 +140,7 @@ int omap4iss_csiphy_config(struct iss_device *iss,
* - bit [18] : CSIPHY1 CTRLCLK enable
* - bit [17:16] : CSIPHY1 config: 00 d-phy, 01/10 ccp2
*/
- cam_rx_ctrl = omap4_ctrl_pad_readl(
- OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_CAMERA_RX);
-
+ cam_rx_ctrl = WARN_ON(1);
if (subdevs-interface == ISS_INTERFACE_CSI2A_PHY1) {
cam_rx_ctrl = ~(OMAP4_CAMERARX_CSI21_LANEENABLE_MASK |
@@ -166,8 +164,7 @@ int omap4iss_csiphy_config(struct iss_device *iss,
cam_rx_ctrl |= OMAP4_CAMERARX_CSI22_CTRLCLKEN_MASK;
}
- omap4_ctrl_pad_writel(cam_rx_ctrl,
-OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_CAMERA_RX);
+ WARN_ON(1);
/* Reset used lane count */
csi2-phy-used_data_lanes = 0;
--
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: dts: am437x-gp-evm: add DT nodes for ov2659 sensor
Hi Tony, On Tue, Mar 17, 2015 at 2:23 AM, Tony Lindgren t...@atomide.com wrote: * Lad, Prabhakar prabhakar.cse...@gmail.com [150316 18:20]: Hi Tony, On Mon, Mar 16, 2015 at 10:17 PM, Tony Lindgren t...@atomide.com wrote: * Lad Prabhakar prabhakar.cse...@gmail.com [150312 16:38]: From: Lad, Prabhakar prabhakar.cse...@gmail.com this patch does the following: 1: adds DT node for fixed oscillator. 2: adds DT node entries for ov2659 sensor 3: adds remote-endpoint entry for VPFE. Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com Applying into omap-for-v4.1/dt thanks. I would like to get this one in via media tree to avoid dependency as I am still waiting for Acks from DT maintainers for the sensor driver. OK dropping it. If I can get your Ack on this I'll queue it up along with sensor driver via media tree. Sorry the chances are too big for pointless merge conflicts with these files with constant patching going on. Please just resend this patch alone again to me later on once the driver changes are merged into Linux next and on their way to the mainline kernel. the sensor driver is now present in linux-next and the same patch applies cleanly, can you pick up the same or do you want me to resend the patch ? Cheers, --Prabhakar Lad -- 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: [rtc-linux] [PATCH] rtc: OMAP: Add external 32k clock feature
On Fri, 10 Apr 2015 13:56:54 +0530 Keerthy a0393...@ti.com wrote: How do we know that all systems have this external clock and that it works OK? AM335 and AM43X have the external clock feature which we choose using RTC_OSC_REG. I verified it works OK by seeing the RTC seconds ticking even after switching the source to the external 32k Clock. AFAIU, this is related to the external (outside of SoC) oscillator, right? If so, there is a possibility to not assemble it on the board (at least on AM335) and use the internal clock source instead. Yes. The register 'OMAP_RTC_OSC_REG' is part of the RTC IP register set so i assumed that it would be with the RTCs of those particular SoCs. I'm a bit lost here. AFAICT there's a risk that some manufacturers have not wired up the external oscillator, so this patch will break those systems. Do we know for sure that this cannot be the case? Is there any way in which we can get all systems working properly? If there's no way of auto-detecting an external oscillator then perhaps a module parameter is needed. If so, it would be better if the driver were to default to internal oscillator (ie: current behaviour), and the module parameter selects the external oscillator. This way, existing systems are unaffected by the kernel upgrade. -- 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] i2c: omap: implement bus recovery
On Thu, Feb 19, 2015 at 12:06:49PM -0600, Felipe Balbi wrote: If either SCL or SDA are stuck low, we need to recover the bus using the procedure described on section 3.1.16 of the I2C specification. Note that we're trying to implement the procedure exactly as described by that section. First we check which line is stuck low, then implement one or the other procedure. If SDA recovery procedure fails, we reset our IP in an attempt to make it work. Signed-off-by: Felipe Balbi ba...@ti.com As Grygorii already mentioned: can you convert it to the standard i2c bus recovery mechanism? And is the timeout you replace with the recovery caused by SDA stuck high (check the thread starting with http://thread.gmane.org/gmane.linux.kernel/1841371/focus=22435) Thanks, Wolfram signature.asc Description: Digital signature
Re: ARM errata 430973 on multi platform kernels
On Fri, Apr 10, 2015 at 1:44 AM, Tony Lindgren t...@atomide.com wrote: * Grazvydas Ignotas nota...@gmail.com [150409 15:37]: On Tue, Apr 7, 2015 at 5:23 AM, Tony Lindgren t...@atomide.com wrote: * Matthijs van Duin matthijsvand...@gmail.com [150406 11:15]: On 6 April 2015 at 19:42, Tony Lindgren t...@atomide.com wrote: Hmm but it still seems to do something also on cortex-a8 r3p2 that is supposedly not affected by 430973.. Based on my tests so far, at least armhf running cpuburn-a8 in the background and doing apt-get update segfaults constantly without flush BTAC/BTB. This seems to be the case no matter how the aux ctrl reg bits are set.. That sounds really odd. The TRM is fairly explicit about BTB flush executing as nop when IBE is not set. Of course the TRM is not exactly flawless, but still... Oops, sorry user error.. I was trying to clear IBE as a banked register like L2 enable bit and of course it did not get cleared.. Clearing it with a smc call really clears it. And in that case my test case seems to work reliably on r3p2 without erratum 430973 enabled. May I ask how do you perform the smc call? I wanted to clear IBE too to experiment, but it just hangs my board, even if I just write back the same value. Here is what I do: asm (mrc p15, 0, %0, c1, c0, 1 : =r(val)); asm (.arch_extension sec\n\t mov r0, %0\n mov r12, #3\n smc #0\n :: r(val) : r0, r12); I just run this from a sysfs write handler, does it need to be run on SRAM or something? Best done in the bootloader.. I just hacked it into the restore from off-idle to test, see below. But for that you naturally need to have a device with working idle and it's usable for just testing for lazy people. Regards, Tony --- a/arch/arm/mach-omap2/sleep34xx.S +++ b/arch/arm/mach-omap2/sleep34xx.S @@ -516,6 +516,7 @@ l2_inv_gp: ldr r4, scratchpad_base ldr r3, [r4,#0xBC] ldr r0, [r3,#4] + bic r0, r1, #(1 6) Hmm did you mean r0 instead of r1 here? I hope your test results didn't come from some other random bit from r1 being written to aux_ctrl. And according to readback this doesn't seem to work for me, even when my board has idle working. Or is it not supposed to be visible in readback? Anyway I've managed to clear that damn bit in the bootloader, but failed to measure any performance impact from clearing this bit and getting rid of BTB flush mcr in cpu_v7_switch_mm() (this is on DM3730 with r3p2 A8). My test was to simply run 2 processes that would spin a counter (running more processes doesn't seem to increase context switches per second, so running 2 seemed enough). GraÅžvydas -- 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] usb: phy/isp1301: work around tps65010 dependency
The isp1301-omap driver contains special hooks for the TPS65010
power management controller. It provides its own 'tps65010_set_vbus_draw'
wrapper in case that driver is not enabled through Kconfig, but
fails to handle the case where isp1301-omap is built-in but TPS65010
is a loadable module, which currently results in a link error:
drivers/built-in.o: In function `isp1301_set_power':
:(.text+0x14e188): undefined reference to `tps65010_set_vbus_draw'
This is a workaround to use the same trick as before also when
tps65010 is a module. Doing a proper fix would require much larger
changes to the driver that is not really worth it when the usb-phy
drivers are going to eventually get replaced with generic-phy
drivers.
Signed-off-by: Arnd Bergmann a...@arndb.de
diff --git a/drivers/usb/phy/phy-isp1301-omap.c
b/drivers/usb/phy/phy-isp1301-omap.c
index 1e0e10dd6ba5..3af263cc0caa 100644
--- a/drivers/usb/phy/phy-isp1301-omap.c
+++ b/drivers/usb/phy/phy-isp1301-omap.c
@@ -94,7 +94,7 @@ struct isp1301 {
#if defined(CONFIG_MACH_OMAP_H2) || defined(CONFIG_MACH_OMAP_H3)
-#ifdefined(CONFIG_TPS65010) || defined(CONFIG_TPS65010_MODULE)
+#ifdefined(CONFIG_TPS65010) || (defined(CONFIG_TPS65010_MODULE)
defined(MODULE))
#include linux/i2c/tps65010.h
--
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: [rtc-linux] [PATCH] rtc: OMAP: Add external 32k clock feature
On 10/04/2015 at 13:37:30 -0700, Andrew Morton wrote : Is there any way in which we can get all systems working properly? If there's no way of auto-detecting an external oscillator then perhaps a module parameter is needed. If so, it would be better if the driver were to default to internal oscillator (ie: current behaviour), and the module parameter selects the external oscillator. This way, existing systems are unaffected by the kernel upgrade. Actually, I would use the common clock framework, allowing to chose between the internal and an external clock source by using the clocks property. This would also allow to have the correct reference count on that 32k internal clock. It may not matter now but for example, not doing so became a problem on at91. As a fallback, if no clocks property is available, I would use the internal 32k to keep DT ABI backward compatibility. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.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 v3] ARM: AM43xx: hwmod: add VPFE hwmod entries
Hi Paul, On Tue, Feb 10, 2015 at 11:10 PM, Paul Walmsley p...@pwsan.com wrote: On Wed, 28 Jan 2015, Benoit Parrot wrote: Suspend/resume is functional with this patch. Tested-by: Benoit Parrot bpar...@ti.com Thanks folks, queued for v3.21. I see that this patch is not into linux-next yet. Cheers, --Prabhakar Lad -- 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: AM43xx: hwmod: add VPFE hwmod entries
Hi Prabhakar On Fri, 10 Apr 2015, Lad, Prabhakar wrote: Hi Paul, On Tue, Feb 10, 2015 at 11:10 PM, Paul Walmsley p...@pwsan.com wrote: On Wed, 28 Jan 2015, Benoit Parrot wrote: Suspend/resume is functional with this patch. Tested-by: Benoit Parrot bpar...@ti.com Thanks folks, queued for v3.21. I see that this patch is not into linux-next yet. thanks for the ping. This slipped through the cracks here due to the kernel version number change from 3.21 to 4.1 :-( Sorry about that; I will requeue for either 4.1-rc or 4.2. Unfortunately I don't have an AM43xx board. Is suspend/resume broken without this patch? If so, then v4.1-rc seems like the appropriate target. - Paul -- 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: AM43xx: hwmod: add VPFE hwmod entries
Hi Paul, On Fri, Apr 10, 2015 at 11:51 PM, Paul Walmsley p...@pwsan.com wrote: Hi Prabhakar On Fri, 10 Apr 2015, Lad, Prabhakar wrote: Hi Paul, On Tue, Feb 10, 2015 at 11:10 PM, Paul Walmsley p...@pwsan.com wrote: On Wed, 28 Jan 2015, Benoit Parrot wrote: Suspend/resume is functional with this patch. Tested-by: Benoit Parrot bpar...@ti.com Thanks folks, queued for v3.21. I see that this patch is not into linux-next yet. thanks for the ping. This slipped through the cracks here due to the kernel version number change from 3.21 to 4.1 :-( Sorry about that; I will requeue for either 4.1-rc or 4.2. Unfortunately I don't have an AM43xx board. Is suspend/resume broken without this patch? If so, then v4.1-rc seems like the appropriate target. there is kernel soft crashes without this patch, so this needs to go in for v4.1-rc. Cheers, --Prabhakar Lad -- 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: AM43xx: hwmod: add VPFE hwmod entries
On Fri, 10 Apr 2015, Lad, Prabhakar wrote: On Fri, Apr 10, 2015 at 11:51 PM, Paul Walmsley p...@pwsan.com wrote: Hi Prabhakar On Fri, 10 Apr 2015, Lad, Prabhakar wrote: Hi Paul, On Tue, Feb 10, 2015 at 11:10 PM, Paul Walmsley p...@pwsan.com wrote: On Wed, 28 Jan 2015, Benoit Parrot wrote: Suspend/resume is functional with this patch. Tested-by: Benoit Parrot bpar...@ti.com Thanks folks, queued for v3.21. I see that this patch is not into linux-next yet. thanks for the ping. This slipped through the cracks here due to the kernel version number change from 3.21 to 4.1 :-( Sorry about that; I will requeue for either 4.1-rc or 4.2. Unfortunately I don't have an AM43xx board. Is suspend/resume broken without this patch? If so, then v4.1-rc seems like the appropriate target. there is kernel soft crashes without this patch, so this needs to go in for v4.1-rc. Could you provide some further detail? Does it crash during boot, or during suspend, or ... ? Also could you describe what you mean by soft crash ? - Paul -- 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: ARM errata 430973 on multi platform kernels
* Grazvydas Ignotas nota...@gmail.com [150410 15:06]:
On Fri, Apr 10, 2015 at 1:44 AM, Tony Lindgren t...@atomide.com wrote:
* Grazvydas Ignotas nota...@gmail.com [150409 15:37]:
On Tue, Apr 7, 2015 at 5:23 AM, Tony Lindgren t...@atomide.com wrote:
* Matthijs van Duin matthijsvand...@gmail.com [150406 11:15]:
On 6 April 2015 at 19:42, Tony Lindgren t...@atomide.com wrote:
Hmm but it still seems to do something also on cortex-a8 r3p2 that
is supposedly not affected by 430973.. Based on my tests so far, at
least
armhf running cpuburn-a8 in the background and doing apt-get update
segfaults constantly without flush BTAC/BTB. This seems to be the case
no matter how the aux ctrl reg bits are set..
That sounds really odd. The TRM is fairly explicit about BTB
flush executing as nop when IBE is not set. Of course the TRM is not
exactly flawless, but still...
Oops, sorry user error.. I was trying to clear IBE as a banked register
like L2 enable bit and of course it did not get cleared.. Clearing it
with a smc call really clears it. And in that case my test case seems to
work reliably on r3p2 without erratum 430973 enabled.
May I ask how do you perform the smc call? I wanted to clear IBE too
to experiment, but it just hangs my board, even if I just write back
the same value. Here is what I do:
asm (mrc p15, 0, %0, c1, c0, 1 : =r(val));
asm (.arch_extension sec\n\t
mov r0, %0\n
mov r12, #3\n
smc #0\n
:: r(val) : r0, r12);
I just run this from a sysfs write handler, does it need to be run on
SRAM or something?
Best done in the bootloader.. I just hacked it into the restore from
off-idle to test, see below. But for that you naturally need to have
a device with working idle and it's usable for just testing for lazy
people.
Regards,
Tony
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
@@ -516,6 +516,7 @@ l2_inv_gp:
ldr r4, scratchpad_base
ldr r3, [r4,#0xBC]
ldr r0, [r3,#4]
+ bic r0, r1, #(1 6)
Hmm did you mean r0 instead of r1 here? I hope your test results
didn't come from some other random bit from r1 being written to
aux_ctrl.
Oh right sorry, yeah it should be r0 above. Luck based coding :)
And according to readback this doesn't seem to work for me, even when
my board has idle working. Or is it not supposed to be visible in
readback?
Hmm I've verified between apps segfaulting depending on how bit 6
is set on r3p2.
Anyways, did a retry just in case, below is an updated test patch.
For me aux ctrl changes after enabling idle stuff:
aux ctrl: 0x00e2
...
aux ctrl: 0x00a2
Did you enable the UART timeout etc so it really hits off mode
when testing?
Anyway I've managed to clear that damn bit in the bootloader, but
failed to measure any performance impact from clearing this bit and
getting rid of BTB flush mcr in cpu_v7_switch_mm() (this is on DM3730
with r3p2 A8). My test was to simply run 2 processes that would spin a
counter (running more processes doesn't seem to increase context
switches per second, so running 2 seemed enough).
Well that's a good test result :) It means it's OK to keep the
430973 enabled without a performance impatct.
Regards,
Tony
8 -
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -93,6 +93,7 @@ static int pwrdm_dbg_show_counter(struct powerdomain *pwrdm,
void *user)
{
struct seq_file *s = (struct seq_file *)user;
int i;
+ u32 val;
if (strcmp(pwrdm-name, emu_pwrdm) == 0 ||
strcmp(pwrdm-name, wkup_pwrdm) == 0 ||
@@ -116,6 +117,9 @@ static int pwrdm_dbg_show_counter(struct powerdomain
*pwrdm, void *user)
seq_printf(s, \n);
+ asm (mrc p15, 0, %0, c1, c0, 1 : =r(val));
+ seq_printf(s, aux ctrl: 0x%08x\n, val);
+
return 0;
}
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
@@ -516,6 +516,7 @@ l2_inv_gp:
ldr r4, scratchpad_base
ldr r3, [r4,#0xBC]
ldr r0, [r3,#4]
+ bic r0, r0, #(1 6)
mov r12, #0x3
smc #0 @ Call SMI monitor (smieq)
ldr r4, scratchpad_base
--
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
