Re: [PATCH 7/7] arm: omap2: clksel: fix compile warning
On Mon, Jan 17, 2011 at 10:01, Felipe Balbi ba...@ti.com wrote:
Fix the following compile warning:
arch/arm/mach-omap2/clkt_clksel.c: In function '_get_div_and_fieldval':
arch/arm/mach-omap2/clkt_clksel.c:100:35: warning: 'max_clkr' may be
used uninitialized in this function
While at that, also add a check to avoid using max_clkr while NULL.
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap2/clkt_clksel.c | 5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/clkt_clksel.c
b/arch/arm/mach-omap2/clkt_clksel.c
index a781cd6..baf0b6b 100644
--- a/arch/arm/mach-omap2/clkt_clksel.c
+++ b/arch/arm/mach-omap2/clkt_clksel.c
@@ -97,7 +97,7 @@ static u8 _get_div_and_fieldval(struct clk *src_clk, struct
clk *clk,
u32 *field_val)
{
const struct clksel *clks;
- const struct clksel_rate *clkr, *max_clkr;
+ const struct clksel_rate *clkr, *max_clkr = NULL;
u8 max_div = 0;
clks = _get_clksel_by_parent(clk, src_clk);
@@ -123,6 +123,9 @@ static u8 _get_div_and_fieldval(struct clk *src_clk,
struct clk *clk,
}
}
+ if (!max_clkr)
+ return 0;
Would it be more appropriate to move this check after the if check
of max_div==0 and it's warning?
or add a warning before it returns?
+
if (max_div == 0) {
/* This indicates an error in the clksel data */
WARN(1, clock: Could not find divisor for clock %s parent %s
--
1.7.3.4.598.g85356
--
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 7/7] arm: omap2: clksel: fix compile warning
Hi,
On Mon, Jan 17, 2011 at 01:37:41PM +0530, Varadarajan, Charulatha wrote:
On Mon, Jan 17, 2011 at 10:01, Felipe Balbi ba...@ti.com wrote:
Fix the following compile warning:
arch/arm/mach-omap2/clkt_clksel.c: In function '_get_div_and_fieldval':
arch/arm/mach-omap2/clkt_clksel.c:100:35: warning: 'max_clkr' may be
used uninitialized in this function
While at that, also add a check to avoid using max_clkr while NULL.
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap2/clkt_clksel.c | 5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/clkt_clksel.c
b/arch/arm/mach-omap2/clkt_clksel.c
index a781cd6..baf0b6b 100644
--- a/arch/arm/mach-omap2/clkt_clksel.c
+++ b/arch/arm/mach-omap2/clkt_clksel.c
@@ -97,7 +97,7 @@ static u8 _get_div_and_fieldval(struct clk *src_clk,
struct clk *clk,
u32 *field_val)
{
const struct clksel *clks;
- const struct clksel_rate *clkr, *max_clkr;
+ const struct clksel_rate *clkr, *max_clkr = NULL;
u8 max_div = 0;
clks = _get_clksel_by_parent(clk, src_clk);
@@ -123,6 +123,9 @@ static u8 _get_div_and_fieldval(struct clk *src_clk,
struct clk *clk,
}
}
+ if (!max_clkr)
+ return 0;
Would it be more appropriate to move this check after the if check
of max_div==0 and it's warning?
or add a warning before it returns?
Maybe this return isn't even necessary. max_clkr will be true if max_div
is valid, so they cancel each other.
Tony ?
--
balbi
--
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] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)
On Sat, Jan 15, 2011 at 05:04:55PM +, Russell King - ARM Linux wrote: On Fri, Jan 14, 2011 at 04:37:34PM -0800, Tony Lindgren wrote: * Russell King - ARM Linux li...@arm.linux.org.uk [110114 16:24]: On Fri, Jan 14, 2011 at 04:12:55PM -0800, Tony Lindgren wrote: * Russell King - ARM Linux li...@arm.linux.org.uk [110114 15:58]: # ARMv6k config CPU_32v6K bool Support ARM V6K processor extensions if !SMP depends on CPU_V6 || CPU_V7 default y if SMP !(ARCH_MX3 || ARCH_OMAP2) OMAP2 prevents the selection of armv6k support. This is probably a very bad idea if you want to run the resulting kernel on SMP hardware as it removes a barrier in the spinlock code and disables the SMP-safe bitops. I have some ideas to fix this. Unfortunately it will be inefficient as spinlock.h can be included from modules too :( I was thinking we can implement dsb_sev in the proc-*.S functions for the unoptimized multi-arm builds. For spinlocks, the important thing is the barrier. The wfe/sev are an optimization. The barrier contained with the ifdef is a valid V6 instruction. OK, great it's just drain WB. Then we can do the ussual iffdeffery on it for multi-arm builds as it does not depend on the 6K extensions. I can do a patch for this on Monday, gotta run now. The original patch which started turning this off was from the MX3 stuff, but without explaination. However, OMAP extended this to disabling the select statement for CPU_32v6K even if CPU_V7 is set: config CPU_V7 bool Support ARM V7 processor if ARCH_INTEGRATOR || MACH_REALVIEW_EB |- select CPU_32v6K + select CPU_32v6K if !ARCH_OMAP2 Arguably, SMP _requires_ CPU_32v6K to be enabled for a safe kernel, and this patch should not have been merged. The only way we can fix that is do smp_on_up style rewriting of the assembly during init between CPUv6 and v6K. Want me to do a patch for that? The bitops code is quite different between the two versions, and I doubt the smp_on_up rewriting will look at all pretty. I think it needs an alternative idea - like not using the 'byte' operations at all. Whether we have any code which passes non-word aligned pointers to bitops isn't particularly known - in theory they should all be unsigned long *'s, so should be word-aligned. Who knows what filesystems do though... and such a change could be disasterous to peoples data if the block/inode bitmaps get corrupted. Hmm, how about emulation of those instructions for non-v6K ARMv6 processors? I guess we could do some address checking in the bitops functions too for multi-arm builds.. IOW, such a change needs testing on a box where a range of filesystems are used, and the filesystems can be thrown away if corrupted. Or we could patch in the address checking first and only disable it later if now warnings. Right, this is what I'm going to do - and it's going to *intentionally* break omap2plus_defconfig. Please see the commit comments for the reason why. We need to address the V6 issue properly without risking users data. To Sascha: this replaces the previous patch which I asked for your ack. Ack for this one aswell: Acked-by: Sascha Hauer s.ha...@pengutronix.de 8--- Subject: [PATCH] ARM: Do not disable CPU_32v6K based on platform selection CPU_32v6K controls whether we use the ARMv6K extension instructions in the kernel, and in some places whether we use SMP-safe code sequences (eg, bitops.) Having this configuration option disabled on a SMP supporting kernel results in a problem: the SMP-unsafe code sequences will be used, and as such the resulting kernel is not SMP safe. As the atomic bitops are used by filesystems (eg, ext2 - to manipulate the inode and block bitmaps) not having the SMP safe code sequences is fatal for filesystem data integrity. So running an SMP kernel without CPU_32v6K set is dangerous. MX3 prevents the selection of this option to ensure that it is not enabled for their CPU, which is ARMv6 only. MX3 folk need to ensure that their kernel is properly configured. OMAP prevents the selection of this option in an attempt to produce a kernel which runs on architectures from ARMv6 to ARMv7 MPCore. Balancing between oopsing on boot and filesystem corruption, it is far more preferable to oops on boot until the code sequences are sorted out properly. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- arch/arm/mm/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig index 49db8b3..d61af9c 100644 --- a/arch/arm/mm/Kconfig +++ b/arch/arm/mm/Kconfig @@ -405,7 +405,7 @@ config CPU_V6 config CPU_32v6K
Re: [RFC+CFT] Use word operations in bitops
On Sun, Jan 16, 2011 at 12:19:11PM +, Russell King - ARM Linux wrote: XXX WARNING: bitops are used heavily by filesystem code: there be dragons XXX I strongly suggest you ensure you have a copy of your filesystems before trying this patch. The patch below switches the bitops to use word loads/stores rather than byte operations - so that we can avoid using the ldrexb/strexb instructions which are only supported from ARMv6k and up. [...] This does need a fair amount of testing before it can be merged, so I'd like to see a number of Tested-by's against this patch. Please also indicate whether you tested on LE or BE or both, which filesystems, and whether they were read-only mounted or read-write mounted. Hi Russell, I've tested these on my picoxcell board (ARMv6K UP LE) with UBIFS, JFFS2 and NFS all mounted rw and haven't seen any problems. Our platforms aren't particulary FS intensive so I'll keep these patches applied to give them a bit more time. Tested-by: Jamie Iles ja...@jamieiles.com Jamie -- 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: State of SDP4430 platform
-Original Message- From: Santosh Shilimkar [mailto:santosh.shilim...@ti.com] Sent: Sunday, January 16, 2011 11:56 AM To: Paul Walmsley; Russell King - ARM Linux Cc: linux-omap@vger.kernel.org Subject: RE: State of SDP4430 platform -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Paul Walmsley Sent: Sunday, January 16, 2011 11:37 AM To: Russell King - ARM Linux Cc: linux-omap@vger.kernel.org Subject: Re: State of SDP4430 platform [.] Other stuff that shows in this boot log: ... - Bunch of regulators are returning errors (is this a problem?) - I2C timeouts which add quite a bit to the boot-time These two are probably related. Looks like something is wrong with communication with the TWL/TPS PMIC on that board. Those problems don't show up on the OMAP4430ES2 Panda here, so they are probably 4430SDP-specific. Actually I don't see these errors which ring a bell. There was an I2C pull related issue with ES1.0 silicon. I guess these timeouts would show up only on ES1.0 OMAP4 boards and not on ES2.0 boards. Monday I will check on my ES1.0 board and if needed send an updated bootloader ( setting up right pull values) or a patch to kernel. The I2C timeout issue I could reproduce on my ES1.0 board. It's ES1.0 specific issue because I2C burst mode wasn't fuctional on it. Twl RTC driver uses I2C burst mode and hence it times out. Other TWL I2C module has no such issue. The pull work-around we tried was not reliable hence it was dropped. In short the TWL RTC driver won't function on ES1.0. Apart from that rest of the I2C clients should work as usual. Regards, Santosh -- 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] arm: mach-omap2: potential NULL dereference
If kzalloc() failed, return -ENOMEM.
sr_dev_init() should signal by return value that there is an error.
Signed-off-by: Vasiliy Kulikov seg...@openwall.com
---
Cannot compile this driver, so it is not tested at all.
arch/arm/mach-omap2/sr_device.c | 19 +++
1 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/sr_device.c b/arch/arm/mach-omap2/sr_device.c
index b1e0af1..20fccfb 100644
--- a/arch/arm/mach-omap2/sr_device.c
+++ b/arch/arm/mach-omap2/sr_device.c
@@ -40,7 +40,7 @@ static struct omap_device_pm_latency omap_sr_latency[] = {
};
/* Read EFUSE values from control registers for OMAP3430 */
-static void __init sr_set_nvalues(struct omap_volt_data *volt_data,
+static int __init sr_set_nvalues(struct omap_volt_data *volt_data,
struct omap_sr_data *sr_data)
{
struct omap_sr_nvalue_table *nvalue_table;
@@ -51,6 +51,8 @@ static void __init sr_set_nvalues(struct omap_volt_data
*volt_data,
nvalue_table = kzalloc(sizeof(struct omap_sr_nvalue_table)*count,
GFP_KERNEL);
+ if (nvalue_table == NULL)
+ return -ENOMEM;
for (i = 0; i count; i++) {
u32 v;
@@ -75,6 +77,8 @@ static void __init sr_set_nvalues(struct omap_volt_data
*volt_data,
sr_data-nvalue_table = nvalue_table;
sr_data-nvalue_count = count;
+
+ return 0;
}
static int sr_dev_init(struct omap_hwmod *oh, void *user)
@@ -84,15 +88,18 @@ static int sr_dev_init(struct omap_hwmod *oh, void *user)
struct omap_volt_data *volt_data;
char *name = smartreflex;
static int i;
+ int err = 0;
sr_data = kzalloc(sizeof(struct omap_sr_data), GFP_KERNEL);
if (!sr_data) {
+ err = -ENOMEM;
pr_err(%s: Unable to allocate memory for %s sr_data.Error!\n,
__func__, oh-name);
- return -ENOMEM;
+ goto exit;
}
if (!oh-vdd_name) {
+ err = -EINVAL;
pr_err(%s: No voltage domain specified for %s.
Cannot initialize\n, __func__, oh-name);
goto exit;
@@ -104,6 +111,7 @@ static int sr_dev_init(struct omap_hwmod *oh, void *user)
sr_data-voltdm = omap_voltage_domain_lookup(oh-vdd_name);
if (IS_ERR(sr_data-voltdm)) {
+ err = PTR_ERR(sr_data-voltdm);
pr_err(%s: Unable to get voltage domain pointer for VDD %s\n,
__func__, oh-vdd_name);
goto exit;
@@ -111,12 +119,15 @@ static int sr_dev_init(struct omap_hwmod *oh, void *user)
omap_voltage_get_volttable(sr_data-voltdm, volt_data);
if (!volt_data) {
+ err = -EINVAL;
pr_warning(%s: No Voltage table registerd fo VDD%d.
Something really wrong\n\n, __func__, i + 1);
goto exit;
}
- sr_set_nvalues(volt_data, sr_data);
+ err = sr_set_nvalues(volt_data, sr_data);
+ if (err)
+ goto exit;
sr_data-enable_on_init = sr_enable_on_init;
@@ -129,7 +140,7 @@ static int sr_dev_init(struct omap_hwmod *oh, void *user)
exit:
i++;
kfree(sr_data);
- return 0;
+ return err;
}
/*
--
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: [RFC+CFT] Use word operations in bitops
Hello Russell, On Sun, Jan 16, 2011 at 12:19:11PM +, Russell King - ARM Linux wrote: This does need a fair amount of testing before it can be merged, so I'd like to see a number of Tested-by's against this patch. Please also indicate whether you tested on LE or BE or both, which filesystems, and whether they were read-only mounted or read-write mounted. You could make life a bit easier (at least for us at Pengutronix, probably more) if you had a branch with a defined name for patches like these. We could add that to our daily test then. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- 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] arm: mach-omap2: potential NULL dereference
kzalloc() may fail, if so return -ENOMEM.
Signed-off-by: Vasiliy Kulikov seg...@openwall.com
---
Cannot compile this driver, so it is not tested at all.
arch/arm/mach-omap2/smartreflex.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 77ecebf..871bca9 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -260,7 +260,10 @@ static int sr_late_init(struct omap_sr *sr_info)
if (sr_class-class_type == SR_CLASS2
sr_class-notify_flags sr_info-irq) {
+ ret = -ENOMEM;
name = kzalloc(SMARTREFLEX_NAME_LEN + 1, GFP_KERNEL);
+ if (name == NULL)
+ goto error;
strcpy(name, sr_);
strcat(name, sr_info-voltdm-name);
ret = request_irq(sr_info-irq, sr_interrupt,
--
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] Remove CPU_32v6K dependencies in asm/spinlock.h
On 15 January 2011 16:11, Russell King - ARM Linux li...@arm.linux.org.uk wrote: SMP requires at least the ARMv6K extensions to be present, so if we're running on SMP, the WFE and SEV instructions must be available. However, when we run on UP, the v6K extensions may not be available, and so we don't want WFE/SEV to be in the instruction stream. Use the SMP alternatives infrastructure to replace these instructions with NOPs if we build for SMP but run on UP. [...] --- a/arch/arm/include/asm/spinlock.h +++ b/arch/arm/include/asm/spinlock.h @@ -5,17 +5,36 @@ #error SMP not supported on pre-ARMv6 CPUs #endif +/* + * sev and wfe are ARMv6K extensions. Uniprocessor ARMv6 may not have the K + * extensions, so when running on UP, we have to patch these instructions away. + */ +#define ALT_SMP(smp, up) \ + 9998: smp \n \ + .pushsection \.alt.smp.init\, \a\\n \ + .long 9998b\n \ + up \n \ + .popsection\n + +#ifdef CONFIG_THUMB2_KERNEL +#define SEV ALT_SMP(sev.w, nop.w) +#define WFE(cond) ALT_SMP(wfe cond .w, nop.w) +#else +#define SEV ALT_SMP(sev, nop) +#define WFE(cond) ALT_SMP(wfe cond, nop) +#endif In the SEV macro definition, can you also include the dsb? This barrier is only there because of sev, otherwise we don't need it (we have a dmb prior to releasing the lock). -- Catalin -- 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: Open issues after 2.6.38 merge window
Tony, -Original Message- From: Santosh Shilimkar [mailto:santosh.shilim...@ti.com] Sent: Saturday, January 15, 2011 10:50 AM To: Tony Lindgren; linux-omap@vger.kernel.org Subject: RE: Open issues after 2.6.38 merge window -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Tony Lindgren Sent: Saturday, January 15, 2011 1:18 AM To: linux-omap@vger.kernel.org Subject: Open issues after 2.6.38 merge window Hi all, Before I update out master branch, let's try to summarize the open issues after the merge window. Here's a list of issues in omap-fixes-for-linus that I'm aware of: - omap4430 es1.0 hangs if L2X0 cache is enabled Will have look at this one on Monday I don't see the hang with L2X0 enable on my ES1.0 SDP with the latest Linus's head. (Mainline 'e78bf5e6cbe837' + Paul's sync timer fix) The kernel boots fine. Regards Santosh -- 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] Remove CPU_32v6K dependencies in asm/spinlock.h
On Mon, Jan 17, 2011 at 10:15:25AM +, Catalin Marinas wrote: On 15 January 2011 16:11, Russell King - ARM Linux li...@arm.linux.org.uk wrote: SMP requires at least the ARMv6K extensions to be present, so if we're running on SMP, the WFE and SEV instructions must be available. However, when we run on UP, the v6K extensions may not be available, and so we don't want WFE/SEV to be in the instruction stream. Use the SMP alternatives infrastructure to replace these instructions with NOPs if we build for SMP but run on UP. [...] --- a/arch/arm/include/asm/spinlock.h +++ b/arch/arm/include/asm/spinlock.h @@ -5,17 +5,36 @@ #error SMP not supported on pre-ARMv6 CPUs #endif +/* + * sev and wfe are ARMv6K extensions. Uniprocessor ARMv6 may not have the K + * extensions, so when running on UP, we have to patch these instructions away. + */ +#define ALT_SMP(smp, up) \ + 9998: smp \n \ + .pushsection \.alt.smp.init\, \a\\n \ + .long 9998b\n \ + up \n \ + .popsection\n + +#ifdef CONFIG_THUMB2_KERNEL +#define SEV ALT_SMP(sev.w, nop.w) +#define WFE(cond) ALT_SMP(wfe cond .w, nop.w) +#else +#define SEV ALT_SMP(sev, nop) +#define WFE(cond) ALT_SMP(wfe cond, nop) +#endif In the SEV macro definition, can you also include the dsb? No, you can't do preprocessor conditionals in the middle of a macro definition, and I don't want to have 4 versions of the SEV stuff. This barrier is only there because of sev, otherwise we don't need it (we have a dmb prior to releasing the lock). 1. Does it make sense to have sev and wfe instructions in non-SMP kernels? We now have in asm/system.h: #if __LINUX_ARM_ARCH__ = 7 || \ (__LINUX_ARM_ARCH__ == 6 defined(CONFIG_CPU_32v6K)) #define sev() __asm__ __volatile__ (sev : : : memory) #define wfe() __asm__ __volatile__ (wfe : : : memory) #define wfi() __asm__ __volatile__ (wfi : : : memory) #endif 2. Should we have a smp_dsb() which makes the dsb conditional elsewhere? 3. Do we always need a dsb prior to a sev? Maybe the SPEAR patches need another review to determine how they're using sev()? -- 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+CFT] Use word operations in bitops
On Mon, Jan 17, 2011 at 11:08:57AM +0100, Uwe Kleine-König wrote: Hello Russell, On Sun, Jan 16, 2011 at 12:19:11PM +, Russell King - ARM Linux wrote: This does need a fair amount of testing before it can be merged, so I'd like to see a number of Tested-by's against this patch. Please also indicate whether you tested on LE or BE or both, which filesystems, and whether they were read-only mounted or read-write mounted. You could make life a bit easier (at least for us at Pengutronix, probably more) if you had a branch with a defined name for patches like these. We could add that to our daily test then. No, because then it's not possible to properly tie down what has been tested and what hasn't. The advantage of emailed patches is that when people reply to them, you have a better idea that the patch to which they're replying to is the one they tested. Such as in this case where the follow-up patch hasn't received any replies, and so I can't add the one received tested-by to the follow-up patch. With the git approach, I wouldn't know what was tested unless you included the commit IDs each time. And let's face it - if it was tested daily, are you going to go through the hastle of digging out the commit IDs and emailing each day to say what was tested? That sounds to me like a _lot_ more work than testing the occasional emailed patch. -- 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] Remove CPU_32v6K dependencies in asm/spinlock.h
On Mon, Jan 17, 2011 at 10:37:39AM +, Russell King - ARM Linux wrote:
On Mon, Jan 17, 2011 at 10:15:25AM +, Catalin Marinas wrote:
On 15 January 2011 16:11, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
SMP requires at least the ARMv6K extensions to be present, so if we're
running on SMP, the WFE and SEV instructions must be available.
However, when we run on UP, the v6K extensions may not be available,
and so we don't want WFE/SEV to be in the instruction stream. Use the
SMP alternatives infrastructure to replace these instructions with NOPs
if we build for SMP but run on UP.
[...]
--- a/arch/arm/include/asm/spinlock.h
+++ b/arch/arm/include/asm/spinlock.h
@@ -5,17 +5,36 @@
#error SMP not supported on pre-ARMv6 CPUs
#endif
+/*
+ * sev and wfe are ARMv6K extensions. Uniprocessor ARMv6 may not have
the K
+ * extensions, so when running on UP, we have to patch these
instructions away.
+ */
+#define ALT_SMP(smp, up) \
+ 9998: smp \n \
+ .pushsection \.alt.smp.init\, \a\\n \
+ .long 9998b\n \
+ up \n \
+ .popsection\n
+
+#ifdef CONFIG_THUMB2_KERNEL
+#define SEV ALT_SMP(sev.w, nop.w)
+#define WFE(cond) ALT_SMP(wfe cond .w, nop.w)
+#else
+#define SEV ALT_SMP(sev, nop)
+#define WFE(cond) ALT_SMP(wfe cond, nop)
+#endif
In the SEV macro definition, can you also include the dsb?
No, you can't do preprocessor conditionals in the middle of a macro
definition, and I don't want to have 4 versions of the SEV stuff.
This barrier is only there because of sev, otherwise we don't need it
(we have a dmb prior to releasing the lock).
1. Does it make sense to have sev and wfe instructions in non-SMP kernels?
We now have in asm/system.h:
#if __LINUX_ARM_ARCH__ = 7 || \
(__LINUX_ARM_ARCH__ == 6 defined(CONFIG_CPU_32v6K))
#define sev() __asm__ __volatile__ (sev : : : memory)
#define wfe() __asm__ __volatile__ (wfe : : : memory)
#define wfi() __asm__ __volatile__ (wfi : : : memory)
#endif
2. Should we have a smp_dsb() which makes the dsb conditional elsewhere?
3. Do we always need a dsb prior to a sev? Maybe the SPEAR patches need
another review to determine how they're using sev()?
FYI, this is how the SPEAR patches use sev():
| +static void __init wakeup_secondary(void)
| +{
| + /* nobody is to be released from the pen yet */
| + pen_release = -1;
| +
| + /*
| + * Write the address of secondary startup into the system-wide
| + * location (presently it is in SRAM). The BootMonitor waits
| + * for this register to become non-zero.
| + * We must also send an sev to wake it up
| + */
| + __raw_writel(BSYM(virt_to_phys(spear13xx_secondary_startup)),
| + __io_address(SPEAR13XX_SYS_LOCATION));
| +
| + mb();
| +
| + /*
| + * Send a 'sev' to wake the secondary core from WFE.
| + */
| + sev();
| +}
so the dsb() is inside mb(), before the outer sync call.
There should be another version of this patch coming which updates the
way the pen_release stuff is done (I hope) for the changes I made in
other platforms pen_release handling, so the above may change.
--
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+CFT] Use word operations in bitops
On Sun, Jan 16, 2011 at 06:15:51PM +, Russell King - ARM Linux wrote: Revised patch - the previous one was slightly buggered for BE. We also don't need to touch the findbit operations at all, so that part has been dropped. This includes a patch by Akinobu Mita (arm: introduce little-endian bitops, v4). Oops, I hit reply to the wrong patch before. Sorry! Tested-by: Jamie Iles ja...@jamieiles.com Jamie -- 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: mach-omap2: potential NULL dereference
Am 17.01.2011 11:08, schrieb Vasiliy Kulikov:
kzalloc() may fail, if so return -ENOMEM.
Signed-off-by: Vasiliy Kulikov seg...@openwall.com
---
Cannot compile this driver, so it is not tested at all.
arch/arm/mach-omap2/smartreflex.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 77ecebf..871bca9 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -260,7 +260,10 @@ static int sr_late_init(struct omap_sr *sr_info)
if (sr_class-class_type == SR_CLASS2
sr_class-notify_flags sr_info-irq) {
+ ret = -ENOMEM;
name = kzalloc(SMARTREFLEX_NAME_LEN + 1, GFP_KERNEL);
+ if (name == NULL)
+ goto error;
strcpy(name, sr_);
strcat(name, sr_info-voltdm-name);
ret = request_irq(sr_info-irq, sr_interrupt,
maybe it is more readable to use:
kasprint(name,sr_%s,sr_info-voltdm-name);
re,
wh
--
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: Open issues after 2.6.38 merge window
Hi, On Fri, 14 Jan 2011, Tony Lindgren wrote: Before I update out master branch, let's try to summarize the open issues after the merge window. Here's a list of issues in omap-fixes-for-linus that I'm aware of: - NFS root oopses while mounting root - omap4430 es1.0 hangs if L2X0 cache is enabled - omap4 panda powers down after boot (watchdog?) - omap3 ldp board powers down after boot? Any other issues? Amstrad E3 fails during the boot. Bisection points to: commit 211baa7016894c02fc18693e21ca479cd08ac0c0 Author: Russell King rmk+ker...@arm.linux.org.uk Date: Tue Jan 11 16:23:04 2011 + ARM: sched_clock: allow init_sched_clock() to be called early The board does not have sched_clock(), although HAVE_SCHED_CLOCK is defined for all OMAP. A. -- 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: Open issues after 2.6.38 merge window
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Aaro Koskinen
Sent: Monday, January 17, 2011 5:07 PM
To: Tony Lindgren; rmk+ker...@arm.linux.org.uk
Cc: linux-omap@vger.kernel.org
Subject: Re: Open issues after 2.6.38 merge window
Hi,
On Fri, 14 Jan 2011, Tony Lindgren wrote:
Before I update out master branch, let's try to summarize the
open issues after the merge window. Here's a list of issues
in omap-fixes-for-linus that I'm aware of:
- NFS root oopses while mounting root
- omap4430 es1.0 hangs if L2X0 cache is enabled
- omap4 panda powers down after boot (watchdog?)
- omap3 ldp board powers down after boot?
Any other issues?
Amstrad E3 fails during the boot. Bisection points to:
commit 211baa7016894c02fc18693e21ca479cd08ac0c0
Author: Russell King rmk+ker...@arm.linux.org.uk
Date: Tue Jan 11 16:23:04 2011 +
ARM: sched_clock: allow init_sched_clock() to be called
early
The board does not have sched_clock(), although HAVE_SCHED_CLOCK is
defined for all OMAP.
I guess above is sorted out by the attached patch from Paul.
Regards,
Santosh
From 8a2d92faa2c21fda24124e75da3ba47930e1eaf6 Mon Sep 17 00:00:00 2001
From: Paul Walmsley p...@pwsan.com
Date: Sun, 16 Jan 2011 21:08:13 +0530
Subject: [PATCH] OMAP: counter_32k: init clocksource as part of machine
timer init
Linus's master branch, currently at commit
1b59be2a6cdcb5a12e18d8315c07c94a624de48f (Merge branch 'slab/urgent'
of git://git.kernel.org/pub/scm/linux/kernel/git/penberg/slab-2.6),
crashes during boot on OMAP4430 ES2.0 Panda:
[0.00] OMAP clockevent source: GPTIMER1 at 32768 Hz
[0.00] Unable to handle kernel NULL pointer dereference at virtual
address
[0.00] pgd = c0004000
[0.00] [] *pgd=
[0.00] Internal error: Oops: 8005 [#1] SMP
[0.00] last sysfs file:
[0.00] Modules linked in:
[0.00] CPU: 0Tainted: GW(2.6.37-07734-g2467802 #7)
[0.00] PC is at 0x0
[0.00] LR is at sched_clock_poll+0x2c/0x3c
[0.00] pc : []lr : [c0060b74]psr: 61d3
[0.00] sp : c058bfd0 ip : c058a000 fp :
[0.00] r10: r9 : 411fc092 r8 : 800330c8
[0.00] r7 : c05a08e0 r6 : c0034c48 r5 : c05ffc40 r4 : c0034c4c
[0.00] r3 : c05ffe6c r2 : c05a0bc0 r1 : c059f098 r0 :
[0.00] Flags: nZCv IRQs off FIQs off Mode SVC_32 ISA ARM
Segment kernel
[0.00] Control: 10c53c7f Table: 8000404a DAC: 0017
This is due to the recent ARM init_sched_clock() changes and the late
initialization of the counter_32k clock source:
http://marc.info/?l=linux-omapm=129513468605208w=2
Fix by initializing the counter_32k clocksource during the machine timer
initialization.
Reported-by: Russell King rmk+ker...@arm.linux.org.uk
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap1/time.c |7 +++
arch/arm/mach-omap2/timer-gp.c | 10 --
arch/arm/plat-omap/counter_32k.c |3 +--
arch/arm/plat-omap/include/plat/common.h |1 +
4 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap1/time.c b/arch/arm/mach-omap1/time.c
index ed7a61f..6ec65e5 100644
--- a/arch/arm/mach-omap1/time.c
+++ b/arch/arm/mach-omap1/time.c
@@ -244,6 +244,13 @@ static void __init omap_timer_init(void)
omap_init_mpu_timer(rate);
omap_init_clocksource(rate);
+ /*
+* XXX Since this file seems to deal mostly with the MPU timer,
+* this doesn't seem like the correct place for the sync timer
+* clocksource init.
+*/
+ if (!cpu_is_omap7xx() !cpu_is_omap15xx())
+ omap_init_clocksource_32k();
}
struct sys_timer omap_timer = {
diff --git a/arch/arm/mach-omap2/timer-gp.c
b/arch/arm/mach-omap2/timer-gp.c
index 4e48e78..57d53e0 100644
--- a/arch/arm/mach-omap2/timer-gp.c
+++ b/arch/arm/mach-omap2/timer-gp.c
@@ -42,6 +42,8 @@
#include timer-gp.h
+#include plat/common.h
+
/* MAX_GPTIMER_ID: number of GPTIMERs on the chip */
#define MAX_GPTIMER_ID 12
@@ -176,10 +178,14 @@ static void __init omap2_gp_clockevent_init(void)
/*
* When 32k-timer is enabled, don't use GPTimer for clocksource
* instead, just leave default clocksource which uses the 32k
- * sync counter. See clocksource setup in see plat-omap/common.c.
+ * sync counter. See clocksource setup in plat-omap/timer-32k.c
*/
-static inline void __init omap2_gp_clocksource_init(void) {}
+static void __init omap2_gp_clocksource_init(void)
+{
+ omap_init_clocksource_32k();
+}
+
#else
/*
* clocksource
diff --git a/arch/arm/plat-omap/counter_32k.c
b/arch/arm/plat-omap/counter_32k.c
index ea46440..0367998 100644
--- a/arch/arm/plat-omap/counter_32k.c
+++ b/arch/arm/plat-omap/counter_32k.c
@@ -160,7 +160,7 @@ void
Re: [PATCH] Remove CPU_32v6K dependencies in asm/spinlock.h
On Mon, 2011-01-17 at 10:37 +, Russell King - ARM Linux wrote: On Mon, Jan 17, 2011 at 10:15:25AM +, Catalin Marinas wrote: On 15 January 2011 16:11, Russell King - ARM Linux li...@arm.linux.org.uk wrote: SMP requires at least the ARMv6K extensions to be present, so if we're running on SMP, the WFE and SEV instructions must be available. However, when we run on UP, the v6K extensions may not be available, and so we don't want WFE/SEV to be in the instruction stream. Use the SMP alternatives infrastructure to replace these instructions with NOPs if we build for SMP but run on UP. [...] --- a/arch/arm/include/asm/spinlock.h +++ b/arch/arm/include/asm/spinlock.h @@ -5,17 +5,36 @@ #error SMP not supported on pre-ARMv6 CPUs #endif +/* + * sev and wfe are ARMv6K extensions. Uniprocessor ARMv6 may not have the K + * extensions, so when running on UP, we have to patch these instructions away. + */ +#define ALT_SMP(smp, up) \ + 9998: smp \n \ + .pushsection \.alt.smp.init\, \a\\n\ + .long 9998b\n\ + up \n \ + .popsection\n + +#ifdef CONFIG_THUMB2_KERNEL +#define SEVALT_SMP(sev.w, nop.w) +#define WFE(cond) ALT_SMP(wfe cond .w, nop.w) +#else +#define SEVALT_SMP(sev, nop) +#define WFE(cond) ALT_SMP(wfe cond, nop) +#endif In the SEV macro definition, can you also include the dsb? No, you can't do preprocessor conditionals in the middle of a macro definition, and I don't want to have 4 versions of the SEV stuff. This barrier is only there because of sev, otherwise we don't need it (we have a dmb prior to releasing the lock). 1. Does it make sense to have sev and wfe instructions in non-SMP kernels? We now have in asm/system.h: #if __LINUX_ARM_ARCH__ = 7 || \ (__LINUX_ARM_ARCH__ == 6 defined(CONFIG_CPU_32v6K)) #define sev() __asm__ __volatile__ (sev : : : memory) #define wfe() __asm__ __volatile__ (wfe : : : memory) #define wfi() __asm__ __volatile__ (wfi : : : memory) #endif The whole spinlock code doesn't make much sense. But the wfe/sev are usually no-ops if SMP isn't supported in hardware (though you still need ARMv6K not to undef). 2. Should we have a smp_dsb() which makes the dsb conditional elsewhere? We could do but I'm not sure how confusing it would be (yet another ARM-specific barrier). 3. Do we always need a dsb prior to a sev? Maybe the SPEAR patches need another review to determine how they're using sev()? We need a dsb to ensure that the prior STR completed before the sev, otherwise we notify the other CPU but the LDREX reads the locked value and goes into WFE again. The SPEAR code seems ok, though I would have used a dsb() to make it clear. -- Catalin -- 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: Open issues after 2.6.38 merge window
On Mon, Jan 17, 2011 at 05:29:01PM +0530, Santosh Shilimkar wrote: On Fri, 14 Jan 2011, Tony Lindgren wrote: Before I update out master branch, let's try to summarize the open issues after the merge window. Here's a list of issues in omap-fixes-for-linus that I'm aware of: - NFS root oopses while mounting root - omap4430 es1.0 hangs if L2X0 cache is enabled - omap4 panda powers down after boot (watchdog?) - omap3 ldp board powers down after boot? This doesn't happen for me. Any other issues? Amstrad E3 fails during the boot. Bisection points to: commit 211baa7016894c02fc18693e21ca479cd08ac0c0 Author: Russell King rmk+ker...@arm.linux.org.uk Date: Tue Jan 11 16:23:04 2011 + ARM: sched_clock: allow init_sched_clock() to be called early The board does not have sched_clock(), although HAVE_SCHED_CLOCK is defined for all OMAP. I guess above is sorted out by the attached patch from Paul. There's an issue missing from Tony's list: - running an omap2plus_defconfig kernel on SMP is unsafe to the point of being data corrupting for filesystems, especially for ext2/ext3 mounted read-write. This is because when CPU_32v6K is disabled - which is required to build a kernel to boot on ARMv6, it turns off the SMP safe bitops - the SMP safe bitops only use instructions available to ARMv6K and above. They are reduced to local-irq-disabling, plain byte loads and stores. So, running omap2plus_defconfig on SMP is risking filesystem corruption. Patches for this are being worked on, but they won't be ready for -rc1. I strongly suggest someone restores some kind of build or runtime error (eg, by removing CPU_32v6K's dependence on !OMAP2 - thereby _intentionally_ breaking omap2plus_defconfig) before someone ends up with a corrupted filesystem. Or just make sure that everyone is aware that omap2plus_defconfig can eat filesystems at the moment. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: -- 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] Remove CPU_32v6K dependencies in asm/spinlock.h
On 17 January 2011 10:53, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Mon, Jan 17, 2011 at 10:37:39AM +, Russell King - ARM Linux wrote:
3. Do we always need a dsb prior to a sev? Maybe the SPEAR patches need
another review to determine how they're using sev()?
FYI, this is how the SPEAR patches use sev():
| +static void __init wakeup_secondary(void)
| +{
| + /* nobody is to be released from the pen yet */
| + pen_release = -1;
| +
| + /*
| + * Write the address of secondary startup into the system-wide
| + * location (presently it is in SRAM). The BootMonitor waits
| + * for this register to become non-zero.
| + * We must also send an sev to wake it up
| + */
| + __raw_writel(BSYM(virt_to_phys(spear13xx_secondary_startup)),
| + __io_address(SPEAR13XX_SYS_LOCATION));
| +
| + mb();
| +
| + /*
| + * Send a 'sev' to wake the secondary core from WFE.
| + */
| + sev();
| +}
so the dsb() is inside mb(), before the outer sync call.
BTW, don't we need some cache flushing for the pen_release?
--
Catalin
--
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: Open issues after 2.6.38 merge window
-Original Message- From: Russell King [mailto:r...@arm.linux.org.uk] Sent: Monday, January 17, 2011 5:42 PM To: Santosh Shilimkar Cc: Aaro Koskinen; Tony Lindgren; linux-omap@vger.kernel.org Subject: Re: Open issues after 2.6.38 merge window On Mon, Jan 17, 2011 at 05:29:01PM +0530, Santosh Shilimkar wrote: On Fri, 14 Jan 2011, Tony Lindgren wrote: Before I update out master branch, let's try to summarize the open issues after the merge window. Here's a list of issues in omap-fixes-for-linus that I'm aware of: - NFS root oopses while mounting root - omap4430 es1.0 hangs if L2X0 cache is enabled - omap4 panda powers down after boot (watchdog?) - omap3 ldp board powers down after boot? This doesn't happen for me. Any other issues? Amstrad E3 fails during the boot. Bisection points to: commit 211baa7016894c02fc18693e21ca479cd08ac0c0 Author: Russell King rmk+ker...@arm.linux.org.uk Date: Tue Jan 11 16:23:04 2011 + ARM: sched_clock: allow init_sched_clock() to be called early The board does not have sched_clock(), although HAVE_SCHED_CLOCK is defined for all OMAP. I guess above is sorted out by the attached patch from Paul. There's an issue missing from Tony's list: - running an omap2plus_defconfig kernel on SMP is unsafe to the point of being data corrupting for filesystems, especially for ext2/ext3 mounted read-write. This is because when CPU_32v6K is disabled - which is required to build a kernel to boot on ARMv6, it turns off the SMP safe bitops - the SMP safe bitops only use instructions available to ARMv6K and above. They are reduced to local-irq-disabling, plain byte loads and stores. So, running omap2plus_defconfig on SMP is risking filesystem corruption. Patches for this are being worked on, but they won't be ready for - rc1. I strongly suggest someone restores some kind of build or runtime error (eg, by removing CPU_32v6K's dependence on !OMAP2 - thereby _intentionally_ breaking omap2plus_defconfig) before someone ends up with a corrupted filesystem. Or just make sure that everyone is aware that omap2plus_defconfig can eat filesystems at the moment. Thanks. I missed your other patch of removing !OMAP2 from CPU_32v6K config. Regards, Santosh -- 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: Open issues after 2.6.38 merge window
Hi, On Mon, 17 Jan 2011, Santosh Shilimkar wrote: Amstrad E3 fails during the boot. Bisection points to: commit 211baa7016894c02fc18693e21ca479cd08ac0c0 Author: Russell King rmk+ker...@arm.linux.org.uk Date: Tue Jan 11 16:23:04 2011 + ARM: sched_clock: allow init_sched_clock() to be called early The board does not have sched_clock(), although HAVE_SCHED_CLOCK is defined for all OMAP. I guess above is sorted out by the attached patch from Paul. I don't see how it could help? Amstrad E3 is OMAP 15xx. A. -- 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: Open issues after 2.6.38 merge window
On Mon, Jan 17, 2011 at 05:49:00PM +0530, Santosh Shilimkar wrote: -Original Message- From: Russell King [mailto:r...@arm.linux.org.uk] Sent: Monday, January 17, 2011 5:42 PM To: Santosh Shilimkar Cc: Aaro Koskinen; Tony Lindgren; linux-omap@vger.kernel.org Subject: Re: Open issues after 2.6.38 merge window On Mon, Jan 17, 2011 at 05:29:01PM +0530, Santosh Shilimkar wrote: On Fri, 14 Jan 2011, Tony Lindgren wrote: Before I update out master branch, let's try to summarize the open issues after the merge window. Here's a list of issues in omap-fixes-for-linus that I'm aware of: - NFS root oopses while mounting root - omap4430 es1.0 hangs if L2X0 cache is enabled - omap4 panda powers down after boot (watchdog?) - omap3 ldp board powers down after boot? This doesn't happen for me. Any other issues? Amstrad E3 fails during the boot. Bisection points to: commit 211baa7016894c02fc18693e21ca479cd08ac0c0 Author: Russell King rmk+ker...@arm.linux.org.uk Date: Tue Jan 11 16:23:04 2011 + ARM: sched_clock: allow init_sched_clock() to be called early The board does not have sched_clock(), although HAVE_SCHED_CLOCK is defined for all OMAP. I guess above is sorted out by the attached patch from Paul. There's an issue missing from Tony's list: - running an omap2plus_defconfig kernel on SMP is unsafe to the point of being data corrupting for filesystems, especially for ext2/ext3 mounted read-write. This is because when CPU_32v6K is disabled - which is required to build a kernel to boot on ARMv6, it turns off the SMP safe bitops - the SMP safe bitops only use instructions available to ARMv6K and above. They are reduced to local-irq-disabling, plain byte loads and stores. So, running omap2plus_defconfig on SMP is risking filesystem corruption. Patches for this are being worked on, but they won't be ready for - rc1. I strongly suggest someone restores some kind of build or runtime error (eg, by removing CPU_32v6K's dependence on !OMAP2 - thereby _intentionally_ breaking omap2plus_defconfig) before someone ends up with a corrupted filesystem. Or just make sure that everyone is aware that omap2plus_defconfig can eat filesystems at the moment. Thanks. I missed your other patch of removing !OMAP2 from CPU_32v6K config. With the problems addressed, I think that removal of !OMAP2 is not strictly required - but I don't like the idea of disabling CPU_32v6K in general as we can't ensure that this kind of thing doesn't happen in the future. Not disabling CPU_32v6K also fixes the swp_emulate build problem too (which is why I've never seen it here.) There are several V6K bits that need to be addressed (such as a single clrex vs two instruction strex) before we can properly build a kernel supporting V6 but also containing V6K extensions. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: -- 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] Remove CPU_32v6K dependencies in asm/spinlock.h
On Mon, Jan 17, 2011 at 12:12:55PM +, Catalin Marinas wrote:
On 17 January 2011 10:53, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Mon, Jan 17, 2011 at 10:37:39AM +, Russell King - ARM Linux wrote:
3. Do we always need a dsb prior to a sev? Maybe the SPEAR patches need
another review to determine how they're using sev()?
FYI, this is how the SPEAR patches use sev():
| +static void __init wakeup_secondary(void)
| +{
| + /* nobody is to be released from the pen yet */
| + pen_release = -1;
| +
| + /*
| + * Write the address of secondary startup into the system-wide
| + * location (presently it is in SRAM). The BootMonitor waits
| + * for this register to become non-zero.
| + * We must also send an sev to wake it up
| + */
| + __raw_writel(BSYM(virt_to_phys(spear13xx_secondary_startup)),
| + __io_address(SPEAR13XX_SYS_LOCATION));
| +
| + mb();
| +
| + /*
| + * Send a 'sev' to wake the secondary core from WFE.
| + */
| + sev();
| +}
so the dsb() is inside mb(), before the outer sync call.
BTW, don't we need some cache flushing for the pen_release?
Which is why I referred to updated patch - that's something which
all implementations suffered from until recently.
--
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: mach-omap2: potential NULL dereference
Hello.
On 17-01-2011 13:08, Vasiliy Kulikov wrote:
kzalloc() may fail, if so return -ENOMEM.
Signed-off-by: Vasiliy Kulikovseg...@openwall.com
[...]
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 77ecebf..871bca9 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -260,7 +260,10 @@ static int sr_late_init(struct omap_sr *sr_info)
if (sr_class-class_type == SR_CLASS2
sr_class-notify_flags sr_info-irq) {
+ ret = -ENOMEM;
name = kzalloc(SMARTREFLEX_NAME_LEN + 1, GFP_KERNEL);
+ if (name == NULL)
+ goto error;
Why not:
if (name == NULL) {
ret = -ENOMEM;
goto error;
}
WBR, Sergei
--
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: Open issues after 2.6.38 merge window
-Original Message- From: Aaro Koskinen [mailto:aaro.koski...@nokia.com] Sent: Monday, January 17, 2011 5:52 PM To: Santosh Shilimkar Cc: Aaro Koskinen; Tony Lindgren; rmk+ker...@arm.linux.org.uk; linux-omap@vger.kernel.org Subject: RE: Open issues after 2.6.38 merge window Hi, On Mon, 17 Jan 2011, Santosh Shilimkar wrote: Amstrad E3 fails during the boot. Bisection points to: commit 211baa7016894c02fc18693e21ca479cd08ac0c0 Author: Russell King rmk+ker...@arm.linux.org.uk Date: Tue Jan 11 16:23:04 2011 + ARM: sched_clock: allow init_sched_clock() to be called early The board does not have sched_clock(), although HAVE_SCHED_CLOCK is defined for all OMAP. I guess above is sorted out by the attached patch from Paul. I don't see how it could help? Amstrad E3 is OMAP 15xx. I read patch again and omap15xx is skipped. Not sure why 15xx is skipped. Regards, Santosh -- 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: Open issues after 2.6.38 merge window
On Mon, Jan 17, 2011 at 06:05:36PM +0530, Santosh Shilimkar wrote: -Original Message- From: Aaro Koskinen [mailto:aaro.koski...@nokia.com] Sent: Monday, January 17, 2011 5:52 PM To: Santosh Shilimkar Cc: Aaro Koskinen; Tony Lindgren; rmk+ker...@arm.linux.org.uk; linux-omap@vger.kernel.org Subject: RE: Open issues after 2.6.38 merge window Hi, On Mon, 17 Jan 2011, Santosh Shilimkar wrote: Amstrad E3 fails during the boot. Bisection points to: commit 211baa7016894c02fc18693e21ca479cd08ac0c0 Author: Russell King rmk+ker...@arm.linux.org.uk Date: Tue Jan 11 16:23:04 2011 + ARM: sched_clock: allow init_sched_clock() to be called early The board does not have sched_clock(), although HAVE_SCHED_CLOCK is defined for all OMAP. I guess above is sorted out by the attached patch from Paul. I don't see how it could help? Amstrad E3 is OMAP 15xx. I read patch again and omap15xx is skipped. Not sure why 15xx is skipped. EWW. This is horrible - and too far complicated. So if we build a kernel with OMAP730 or OMAP15xx support, the 32k counter support is disabled for every platform, which also removes sched_clock() support (as this uses the 32k timer). If CONFIG_OMAP_32K_TIMER is also true (eg, because you enabled OMAP16xx) then we won't have the GP clocksource code. So a kernel which is configured for OMAP15xx + OMAP16xx won't have any clocksource code at all. In effect, all this being done by _negative_ dependencies. As has been seen with deselecting the V6K configuration symbol, negative dependencies are Bad News(tm). This code needs to be restructured for positive dependencies and proper selection of the appopriate clock sources - which then needs to be coupled into sched_clock() properly so OMAP15xx can also benefit from sched_clock() support. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: -- 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] Remove CPU_32v6K dependencies in asm/spinlock.h
On Mon, Jan 17, 2011 at 10:15:25AM +, Catalin Marinas wrote: In the SEV macro definition, can you also include the dsb? This barrier is only there because of sev, otherwise we don't need it (we have a dmb prior to releasing the lock). I think until we have the whole SEV situation sorted out, it's best to leave it as-is. Leaving the dsb in there shouldn't cause a problem for a v6+v6k+v7 kernel, it just means we're wasting a few cycles stalling the instruction pipeline while the dsb completes, which we don't really need to do on v6. -- 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] OMAP: use fncpy to copy the PM code functions to SRAM
On Fri, Jan 14, 2011 at 6:34 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Fri, Jan 14, 2011 at 05:13:01PM +0100, Jean Pihet wrote: Is the name 'omap_sram_push' wrong then? What about the following? @@ -251,9 +251,8 @@ void * omap_sram_push(void * start, unsigned long size) omap_sram_ceil -= size; omap_sram_ceil = ROUND_DOWN(omap_sram_ceil, sizeof(void *)); - memcpy((void *)omap_sram_ceil, start, size); - flush_icache_range((unsigned long)omap_sram_ceil, - (unsigned long)(omap_sram_ceil + size)); - return (void *)omap_sram_ceil; + return fncpy((void *)omap_sram_ceil, start, size); It's more correct, but still missing out on the type safety which we've tried to provide with fncpy. IIUC the type of the function is propagated from the 2nd argument (funcp) to the return value, which is fine here. The (void)* is here only to avoid a warning thrown by memcpy. Note also the other issue with Dave Martin has raised though - this isn't ready for merging yet. Ok I am using the latest version now and will re-spin the patch. Regards, Jean -- 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] ARM: Thumb-2: Symbol manipulation macros for function body copying
On Fri, Jan 14, 2011 at 10:17 PM, Dave Martin dave.mar...@linaro.org wrote:
In low-level board support code, there is sometimes a need to
copy a function body to another location at run-time.
A straightforward call to memcpy doesn't work in Thumb-2,
because bit 0 of external Thumb function symbols is set to 1,
indicating that the function is Thumb. Without corrective
measures, this will cause an off-by-one copy, and the copy
may be called using the wrong instruction set.
This patch adds an fncpy() macro to help with such copies.
Particular care is needed, because C doesn't guarantee any
defined behaviour when casting a function pointer to any other
type. This has been observed to lead to strange optimisation
side-effects when doing the arithmetic which is required in
order to copy/move function bodies correctly in Thumb-2.
Thanks to Russell King and Nicolas Pitre for their input
on this patch.
Signed-off-by: Dave Martin dave.mar...@linaro.org
Tested-by: Jean Pihet j-pi...@ti.com
---
arch/arm/include/asm/fncpy.h | 96
++
1 files changed, 96 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/include/asm/fncpy.h
diff --git a/arch/arm/include/asm/fncpy.h b/arch/arm/include/asm/fncpy.h
new file mode 100644
index 000..8b94b5f
--- /dev/null
+++ b/arch/arm/include/asm/fncpy.h
@@ -0,0 +1,96 @@
+/*
+ * arch/arm/include/asm/fncpy.h - helper macros for function body copying
+ *
+ * Copyright (C) 2011 Linaro Limited
+ *
+ * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+/*
+ * These macros are intended for use when there is a need to copy a low-level
+ * function body into special memory.
+ *
+ * For example, when reconfiguring the SDRAM controller, the code doing the
+ * reconfiguration may need to run from SRAM.
+ *
+ * NOTE: that the copied function body must be entirely self-contained and
+ * position-independent in order for this to work properly.
+ *
+ * NOTE: in order for embedded literals and data to get referenced correctly,
+ * the alignment of functions must be preserved when copying. To ensure
this,
+ * the source and destination addresses for fncpy() must be aligned to a
+ * multiple of 8 bytes: you will be get a BUG() if this condition is not met.
+ * You will typically need a .align 3 directive in the assembler where the
+ * function to be copied is defined, and ensure that your allocator for the
+ * destination buffer returns 8-byte-aligned pointers.
Note that aligning the source and destination pointers to a multiple
of 8 bytes has an impact on the behavio(u)r and so must be carefully
thought and tested on OMAP1/2/3 platforms.
Regards,
Jean
+ *
+ * Typical usage example:
+ *
+ * extern int f(args);
+ * extern uint32_t size_of_f;
+ * int (*copied_f)(args);
+ * void *sram_buffer;
+ *
+ * copied_f = fncpy(sram_buffer, f, size_of_f);
+ *
+ * ... do any required D-side/I-side synchronisation ...
+ *
+ * ... later, call the function: ...
+ *
+ * copied_f(args);
+ *
+ * The size of the function to be copied can't be determined from C:
+ * this must be determined by other means, such as adding assmbler directives
+ * in the file where f is defined.
+ */
+
+#ifndef __ASM_FNCPY_H
+#define __ASM_FNCPY_H
+
+#include linux/types.h
+#include linux/string.h
+
+#include asm/bug.h
+#include asm/cacheflush.h
+
+/*
+ * Minimum alignment requirement for the source and destination addresses
+ * for function copying.
+ */
+#define FNCPY_ALIGN 8
+
+#define fncpy(dest_buf, funcp, size) ({
\
+ uintptr_t __funcp_address; \
+ typeof(funcp) __result; \
+ \
+ asm( : =r (__funcp_address) : 0 (funcp)); \
+ \
+ /* \
+ * Ensure alignment of source and destination addresses, \
+ * disregarding the function's Thumb bit: \
+ */ \
+ BUG_ON((uintptr_t)(dest_buf) (FNCPY_ALIGN - 1) ||
[PATCHv2 0/2] misc Devkit8000 fixes
Here is a set of misc fixes for the devkit8000. The only really notable one is the lcd enable gpio fix. It gets rid of some nasty low level twl4030 calls and replaces them with generic gpio calls. It also fixes a bug where the screen would not turn off when blanking. Changes from v1: Pull the indention fix into Change lcd power pin. Change the pin for lcd pwren. Fix the pullup/pulldown configuration after lcd prwen correction. Daniel Morsing (1): omap3: devkit8000: fix tps65930 pullup/pulldown configuration Thomas Weber (1): OMAP3: Devkit8000: Change lcd power pin arch/arm/mach-omap2/board-devkit8000.c | 10 +++--- 1 files changed, 3 insertions(+), 7 deletions(-) -- 1.7.4.rc2 -- 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
[PATCHv2 1/2] OMAP3: Devkit8000: Change lcd power pin
The reset_gpio pin for lcd is connected with TWL4030 LedA.
TWL4030 GPIO.1 has a not connected resistor.
Fix indention issue. The comment line uses 8 whitespaces.
Replaced with one tabulator.
Reported-by: Daniel Morsing daniel.mors...@gmail.com
Signed-off-by: Thomas Weber we...@corscience.de
---
arch/arm/mach-omap2/board-devkit8000.c |7 ++-
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 451e7ff..719f4e5 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -114,9 +114,6 @@ static struct omap2_hsmmc_info mmc[] = {
static int devkit8000_panel_enable_lcd(struct omap_dss_device *dssdev)
{
- twl_i2c_write_u8(TWL4030_MODULE_GPIO, 0x80, REG_GPIODATADIR1);
- twl_i2c_write_u8(TWL4030_MODULE_LED, 0x0, 0x0);
-
if (gpio_is_valid(dssdev-reset_gpio))
gpio_set_value_cansleep(dssdev-reset_gpio, 1);
return 0;
@@ -245,8 +242,8 @@ static int devkit8000_twl_gpio_setup(struct device *dev,
/* TWL4030_GPIO_MAX + 1 == ledB, PMU_STAT (out, active low LED) */
gpio_leds[2].gpio = gpio + TWL4030_GPIO_MAX + 1;
-/* gpio + 1 is LCD_PWREN (out, active high) */
- devkit8000_lcd_device.reset_gpio = gpio + 1;
+ /* TWL4030_GPIO_MAX + 0 is LCD_PWREN (out, active high) */
+ devkit8000_lcd_device.reset_gpio = gpio + TWL4030_GPIO_MAX + 0;
gpio_request(devkit8000_lcd_device.reset_gpio, LCD_PWREN);
/* Disable until needed */
gpio_direction_output(devkit8000_lcd_device.reset_gpio, 0);
--
1.7.4.rc2
--
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
[PATCHv2 2/2] omap3: devkit8000: fix tps65930 pullup/pulldown configuration
From: Daniel Morsing daniel.mors...@gmail.com
gpio7 on the tps65930 is used as an output on the devkit8000 and gpio1
is not connected. Remove gpio7 and change gpio1 to pulldown
Signed-off-by: Daniel Morsing daniel.mors...@gmail.com
---
arch/arm/mach-omap2/board-devkit8000.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 719f4e5..9fb416b 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -262,8 +262,7 @@ static struct twl4030_gpio_platform_data
devkit8000_gpio_data = {
.irq_base = TWL4030_GPIO_IRQ_BASE,
.irq_end= TWL4030_GPIO_IRQ_END,
.use_leds = true,
- .pullups= BIT(1),
- .pulldowns = BIT(2) | BIT(6) | BIT(7) | BIT(8) | BIT(13)
+ .pulldowns = BIT(1) | BIT(2) | BIT(6) | BIT(8) | BIT(13)
| BIT(15) | BIT(16) | BIT(17),
.setup = devkit8000_twl_gpio_setup,
};
--
1.7.4.rc2
--
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 0/6] OMAP: McSPI: Hwmod adaptation + runtime conversion
Changes invloves: 1) Addition of hwmod data for omap2/3/4. 2) McSPI driver hwmod adaptation with cleanup of base address macros and using omap-device API's. 3) Runtime Conversion of McSPI driver. Changes from v2: --- 1) Fixing minor comments and adding ack from Grant Likely. https://patchwork.kernel.org/patch/371321/ https://patchwork.kernel.org/patch/371331/ Changes from v1: --- 1) Fixing patch 5/5 comments for hwmod+runtime Split the patch 5/5 to hwmod adaptation and then runtime conversion http://www.mail-archive.com/linux-omap@vger.kernel.org/msg33387.html Testing Updates: Was tested using data transfer test module available at: http://dev.omapzoom.org/?p=richo/device_driver_test.git;a=blob;f=mcspi/test_code/ utils/mcspi_modules/omap_mcspi_datatest.c; h=e42ec10c5c844abdde6a7175a268b379fbbdb655; hb=5d9a755d50e58de861c5e8991f2f607bc49b5dc3 This test basically involves MISO -- MOSI lines looped and data transfer test done using the above test module. System wide suspend and ret/off counts observation, ensured that no behavioral difference with and without this patch series. Charulatha V (1): OMAP: devices: Modify McSPI device to adapt to hwmod framework Govindraj.R (5): OMAP2420: hwmod data: Add McSPI OMAP2430: hwmod data: Add McSPI OMAP3: hwmod data: Add McSPI OMAP4: hwmod data: Add McSPI OMAP: runtime: McSPI driver runtime conversion arch/arm/mach-omap2/devices.c | 187 --- arch/arm/mach-omap2/omap_hwmod_2420_data.c | 156 arch/arm/mach-omap2/omap_hwmod_2430_data.c | 219 ++ arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 280 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 266 ++ arch/arm/plat-omap/include/plat/mcspi.h| 11 + drivers/spi/omap2_mcspi.c | 224 +++--- 7 files changed, 1043 insertions(+), 300 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 v3 1/6] OMAP2420: hwmod data: Add McSPI
Update the omap2420 hwmod data with the McSPI info.
Add a device attribute structure which will be used
for passing number of chipselects from hwmod data.
Add revision macros to be passed from rev field from
hwmod.
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
Acked-by: Grant Likely grant.lik...@secretlab.ca
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 156
arch/arm/plat-omap/include/plat/mcspi.h|8 ++
2 files changed, 164 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index b85c630..27c00be 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -18,6 +18,7 @@
#include plat/serial.h
#include plat/i2c.h
#include plat/gpio.h
+#include plat/mcspi.h
#include omap_hwmod_common_data.h
@@ -44,6 +45,8 @@ static struct omap_hwmod omap2420_gpio2_hwmod;
static struct omap_hwmod omap2420_gpio3_hwmod;
static struct omap_hwmod omap2420_gpio4_hwmod;
static struct omap_hwmod omap2420_dma_system_hwmod;
+static struct omap_hwmod omap2420_mcspi1_hwmod;
+static struct omap_hwmod omap2420_mcspi2_hwmod;
/* L3 - L4_CORE interface */
static struct omap_hwmod_ocp_if omap2420_l3_main__l4_core = {
@@ -88,6 +91,42 @@ static struct omap_hwmod omap2420_uart3_hwmod;
static struct omap_hwmod omap2420_i2c1_hwmod;
static struct omap_hwmod omap2420_i2c2_hwmod;
+/* l4 core - mcspi1 interface */
+static struct omap_hwmod_addr_space omap2420_mcspi1_addr_space[] = {
+ {
+ .pa_start = 0x48098000,
+ .pa_end = 0x480980ff,
+ .flags = ADDR_TYPE_RT,
+ },
+};
+
+static struct omap_hwmod_ocp_if omap2420_l4_core__mcspi1 = {
+ .master = omap2420_l4_core_hwmod,
+ .slave = omap2420_mcspi1_hwmod,
+ .clk= mcspi1_ick,
+ .addr = omap2420_mcspi1_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap2420_mcspi1_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4 core - mcspi2 interface */
+static struct omap_hwmod_addr_space omap2420_mcspi2_addr_space[] = {
+ {
+ .pa_start = 0x4809a000,
+ .pa_end = 0x4809a0ff,
+ .flags = ADDR_TYPE_RT,
+ },
+};
+
+static struct omap_hwmod_ocp_if omap2420_l4_core__mcspi2 = {
+ .master = omap2420_l4_core_hwmod,
+ .slave = omap2420_mcspi2_hwmod,
+ .clk= mcspi2_ick,
+ .addr = omap2420_mcspi2_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap2420_mcspi2_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* L4_CORE - L4_WKUP interface */
static struct omap_hwmod_ocp_if omap2420_l4_core__l4_wkup = {
.master = omap2420_l4_core_hwmod,
@@ -864,6 +903,119 @@ static struct omap_hwmod omap2420_dma_system_hwmod = {
.flags = HWMOD_NO_IDLEST,
};
+/*
+ * 'mcspi' class
+ * multichannel serial port interface (mcspi) / master/slave synchronous serial
+ * bus
+ */
+
+static struct omap_hwmod_class_sysconfig omap2420_mcspi_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_CLOCKACTIVITY | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
+ SYSC_HAS_AUTOIDLE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap2420_mcspi_class = {
+ .name = mcspi,
+ .sysc = omap2420_mcspi_sysc,
+ .rev = OMAP2_MCSPI_REV,
+};
+
+/* mcspi1 */
+static struct omap_hwmod_irq_info omap2420_mcspi1_mpu_irqs[] = {
+ { .irq = 65 },
+};
+
+static struct omap_hwmod_dma_info omap2420_mcspi1_sdma_reqs[] = {
+ { .name = tx0, .dma_req = 35 }, /* DMA_SPI1_TX0 */
+ { .name = rx0, .dma_req = 36 }, /* DMA_SPI1_RX0 */
+ { .name = tx1, .dma_req = 37 }, /* DMA_SPI1_TX1 */
+ { .name = rx1, .dma_req = 38 }, /* DMA_SPI1_RX1 */
+ { .name = tx2, .dma_req = 39 }, /* DMA_SPI1_TX2 */
+ { .name = rx2, .dma_req = 40 }, /* DMA_SPI1_RX2 */
+ { .name = tx3, .dma_req = 41 }, /* DMA_SPI1_TX3 */
+ { .name = rx3, .dma_req = 42 }, /* DMA_SPI1_RX3 */
+};
+
+static struct omap_hwmod_ocp_if *omap2420_mcspi1_slaves[] = {
+ omap2420_l4_core__mcspi1,
+};
+
+static struct omap2_mcspi_dev_attr omap_mcspi1_dev_attr = {
+ .num_chipselect = 4,
+};
+
+static struct omap_hwmod omap2420_mcspi1_hwmod = {
+ .name = mcspi1_hwmod,
+ .mpu_irqs = omap2420_mcspi1_mpu_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap2420_mcspi1_mpu_irqs),
+ .sdma_reqs = omap2420_mcspi1_sdma_reqs,
+ .sdma_reqs_cnt = ARRAY_SIZE(omap2420_mcspi1_sdma_reqs),
+
[PATCH v3 2/6] OMAP2430: hwmod data: Add McSPI
Update the 2430 hwmod data file with McSPI info.
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
Acked-by: Grant Likely grant.lik...@secretlab.ca
---
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 219
1 files changed, 219 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 8ecfbcd..9bf9dbe 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -18,6 +18,7 @@
#include plat/serial.h
#include plat/i2c.h
#include plat/gpio.h
+#include plat/mcspi.h
#include omap_hwmod_common_data.h
@@ -45,6 +46,9 @@ static struct omap_hwmod omap2430_gpio3_hwmod;
static struct omap_hwmod omap2430_gpio4_hwmod;
static struct omap_hwmod omap2430_gpio5_hwmod;
static struct omap_hwmod omap2430_dma_system_hwmod;
+static struct omap_hwmod omap2430_mcspi1_hwmod;
+static struct omap_hwmod omap2430_mcspi2_hwmod;
+static struct omap_hwmod omap2430_mcspi3_hwmod;
/* L3 - L4_CORE interface */
static struct omap_hwmod_ocp_if omap2430_l3_main__l4_core = {
@@ -223,6 +227,60 @@ static struct omap_hwmod_ocp_if *omap2430_l4_wkup_slaves[]
= {
static struct omap_hwmod_ocp_if *omap2430_l4_wkup_masters[] = {
};
+/* l4 core - mcspi1 interface */
+static struct omap_hwmod_addr_space omap2430_mcspi1_addr_space[] = {
+ {
+ .pa_start = 0x48098000,
+ .pa_end = 0x480980ff,
+ .flags = ADDR_TYPE_RT,
+ },
+};
+
+static struct omap_hwmod_ocp_if omap2430_l4_core__mcspi1 = {
+ .master = omap2430_l4_core_hwmod,
+ .slave = omap2430_mcspi1_hwmod,
+ .clk= mcspi1_ick,
+ .addr = omap2430_mcspi1_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap2430_mcspi1_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4 core - mcspi2 interface */
+static struct omap_hwmod_addr_space omap2430_mcspi2_addr_space[] = {
+ {
+ .pa_start = 0x4809a000,
+ .pa_end = 0x4809a0ff,
+ .flags = ADDR_TYPE_RT,
+ },
+};
+
+static struct omap_hwmod_ocp_if omap2430_l4_core__mcspi2 = {
+ .master = omap2430_l4_core_hwmod,
+ .slave = omap2430_mcspi2_hwmod,
+ .clk= mcspi2_ick,
+ .addr = omap2430_mcspi2_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap2430_mcspi2_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4 core - mcspi3 interface */
+static struct omap_hwmod_addr_space omap2430_mcspi3_addr_space[] = {
+ {
+ .pa_start = 0x480b8000,
+ .pa_end = 0x480b80ff,
+ .flags = ADDR_TYPE_RT,
+ },
+};
+
+static struct omap_hwmod_ocp_if omap2430_l4_core__mcspi3 = {
+ .master = omap2430_l4_core_hwmod,
+ .slave = omap2430_mcspi3_hwmod,
+ .clk= mcspi3_ick,
+ .addr = omap2430_mcspi3_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap2430_mcspi3_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* L4 WKUP */
static struct omap_hwmod omap2430_l4_wkup_hwmod = {
.name = l4_wkup,
@@ -919,6 +977,162 @@ static struct omap_hwmod omap2430_dma_system_hwmod = {
.flags = HWMOD_NO_IDLEST,
};
+/*
+ * 'mcspi' class
+ * multichannel serial port interface (mcspi) / master/slave synchronous serial
+ * bus
+ */
+
+static struct omap_hwmod_class_sysconfig omap2430_mcspi_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_CLOCKACTIVITY | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
+ SYSC_HAS_AUTOIDLE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap2430_mcspi_class = {
+ .name = mcspi,
+ .sysc = omap2430_mcspi_sysc,
+ .rev = OMAP2_MCSPI_REV,
+};
+
+/* mcspi1 */
+static struct omap_hwmod_irq_info omap2430_mcspi1_mpu_irqs[] = {
+ { .irq = 65 },
+};
+
+static struct omap_hwmod_dma_info omap2430_mcspi1_sdma_reqs[] = {
+ { .name = tx0, .dma_req = 35 }, /* DMA_SPI1_TX0 */
+ { .name = rx0, .dma_req = 36 }, /* DMA_SPI1_RX0 */
+ { .name = tx1, .dma_req = 37 }, /* DMA_SPI1_TX1 */
+ { .name = rx1, .dma_req = 38 }, /* DMA_SPI1_RX1 */
+ { .name = tx2, .dma_req = 39 }, /* DMA_SPI1_TX2 */
+ { .name = rx2, .dma_req = 40 }, /* DMA_SPI1_RX2 */
+ { .name = tx3, .dma_req = 41 }, /* DMA_SPI1_TX3 */
+ { .name = rx3, .dma_req = 42 }, /* DMA_SPI1_RX3 */
+};
+
+static struct omap_hwmod_ocp_if *omap2430_mcspi1_slaves[] = {
+
[PATCH v3 3/6] OMAP3: hwmod data: Add McSPI
Update omap3 hwmod data file with McSPI info.
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
Acked-by: Grant Likely grant.lik...@secretlab.ca
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 280
1 files changed, 280 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 8d81813..8c27567 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -22,6 +22,7 @@
#include plat/i2c.h
#include plat/gpio.h
#include plat/smartreflex.h
+#include plat/mcspi.h
#include omap_hwmod_common_data.h
@@ -55,6 +56,10 @@ static struct omap_hwmod omap3xxx_gpio5_hwmod;
static struct omap_hwmod omap3xxx_gpio6_hwmod;
static struct omap_hwmod omap34xx_sr1_hwmod;
static struct omap_hwmod omap34xx_sr2_hwmod;
+static struct omap_hwmod omap34xx_mcspi1;
+static struct omap_hwmod omap34xx_mcspi2;
+static struct omap_hwmod omap34xx_mcspi3;
+static struct omap_hwmod omap34xx_mcspi4;
static struct omap_hwmod omap3xxx_dma_system_hwmod;
@@ -1356,6 +1361,275 @@ static struct omap_hwmod omap36xx_sr2_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3630ES1),
};
+/* l4 core - mcspi1 interface */
+static struct omap_hwmod_addr_space omap34xx_mcspi1_addr_space[] = {
+ {
+ .pa_start = 0x48098000,
+ .pa_end = 0x480980ff,
+ .flags = ADDR_TYPE_RT,
+ },
+};
+
+static struct omap_hwmod_ocp_if omap34xx_l4_core__mcspi1 = {
+ .master = omap3xxx_l4_core_hwmod,
+ .slave = omap34xx_mcspi1,
+ .clk= mcspi1_ick,
+ .addr = omap34xx_mcspi1_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap34xx_mcspi1_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4 core - mcspi2 interface */
+static struct omap_hwmod_addr_space omap34xx_mcspi2_addr_space[] = {
+ {
+ .pa_start = 0x4809a000,
+ .pa_end = 0x4809a0ff,
+ .flags = ADDR_TYPE_RT,
+ },
+};
+
+static struct omap_hwmod_ocp_if omap34xx_l4_core__mcspi2 = {
+ .master = omap3xxx_l4_core_hwmod,
+ .slave = omap34xx_mcspi2,
+ .clk= mcspi2_ick,
+ .addr = omap34xx_mcspi2_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap34xx_mcspi2_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4 core - mcspi3 interface */
+static struct omap_hwmod_addr_space omap34xx_mcspi3_addr_space[] = {
+ {
+ .pa_start = 0x480b8000,
+ .pa_end = 0x480b80ff,
+ .flags = ADDR_TYPE_RT,
+ },
+};
+
+static struct omap_hwmod_ocp_if omap34xx_l4_core__mcspi3 = {
+ .master = omap3xxx_l4_core_hwmod,
+ .slave = omap34xx_mcspi3,
+ .clk= mcspi3_ick,
+ .addr = omap34xx_mcspi3_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap34xx_mcspi3_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4 core - mcspi4 interface */
+static struct omap_hwmod_addr_space omap34xx_mcspi4_addr_space[] = {
+ {
+ .pa_start = 0x480ba000,
+ .pa_end = 0x480ba0ff,
+ .flags = ADDR_TYPE_RT,
+ },
+};
+
+static struct omap_hwmod_ocp_if omap34xx_l4_core__mcspi4 = {
+ .master = omap3xxx_l4_core_hwmod,
+ .slave = omap34xx_mcspi4,
+ .clk= mcspi4_ick,
+ .addr = omap34xx_mcspi4_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap34xx_mcspi4_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/*
+ * 'mcspi' class
+ * multichannel serial port interface (mcspi) / master/slave synchronous serial
+ * bus
+ */
+
+static struct omap_hwmod_class_sysconfig omap34xx_mcspi_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_CLOCKACTIVITY | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
+ SYSC_HAS_AUTOIDLE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap34xx_mcspi_class = {
+ .name = mcspi,
+ .sysc = omap34xx_mcspi_sysc,
+ .rev = OMAP3_MCSPI_REV,
+};
+
+/* mcspi1 */
+static struct omap_hwmod_irq_info omap34xx_mcspi1_mpu_irqs[] = {
+ { .name = irq, .irq = 65 },
+};
+
+static struct omap_hwmod_dma_info omap34xx_mcspi1_sdma_reqs[] = {
+ { .name = tx0, .dma_req = 35 },
+ { .name = rx0, .dma_req = 36 },
+ { .name = tx1, .dma_req = 37 },
+ { .name = rx1, .dma_req = 38 },
+ { .name = tx2,
[PATCH v3 4/6] OMAP4: hwmod data: Add McSPI
Update omap4 hwmod file with McSPI info.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
Acked-by: Grant Likely grant.lik...@secretlab.ca
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 266
1 files changed, 266 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index c2806bd..d4cd695 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -24,6 +24,7 @@
#include plat/cpu.h
#include plat/gpio.h
#include plat/dma.h
+#include plat/mcspi.h
#include omap_hwmod_common_data.h
@@ -2001,6 +2002,265 @@ static struct omap_hwmod omap44xx_wd_timer3_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
};
+/*
+ * 'mcspi' class
+ * multichannel serial port interface (mcspi) / master/slave synchronous serial
+ * bus
+ */
+
+static struct omap_hwmod_class_sysconfig omap44xx_mcspi_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_EMUFREE |
+ SYSC_HAS_SOFTRESET | SYSC_HAS_RESET_STATUS),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class omap44xx_mcspi_hwmod_class = {
+ .name = mcspi,
+ .sysc = omap44xx_mcspi_sysc,
+ .rev = OMAP4_MCSPI_REV,
+};
+
+/* mcspi1 */
+static struct omap_hwmod omap44xx_mcspi1_hwmod;
+static struct omap_hwmod_irq_info omap44xx_mcspi1_irqs[] = {
+ { .irq = 65 + OMAP44XX_IRQ_GIC_START },
+};
+
+static struct omap_hwmod_dma_info omap44xx_mcspi1_sdma_reqs[] = {
+ { .name = tx0, .dma_req = 34 + OMAP44XX_DMA_REQ_START },
+ { .name = rx0, .dma_req = 35 + OMAP44XX_DMA_REQ_START },
+ { .name = tx1, .dma_req = 36 + OMAP44XX_DMA_REQ_START },
+ { .name = rx1, .dma_req = 37 + OMAP44XX_DMA_REQ_START },
+ { .name = tx2, .dma_req = 38 + OMAP44XX_DMA_REQ_START },
+ { .name = rx2, .dma_req = 39 + OMAP44XX_DMA_REQ_START },
+ { .name = tx3, .dma_req = 40 + OMAP44XX_DMA_REQ_START },
+ { .name = rx3, .dma_req = 41 + OMAP44XX_DMA_REQ_START },
+};
+
+static struct omap_hwmod_addr_space omap44xx_mcspi1_addrs[] = {
+ {
+ .pa_start = 0x48098000,
+ .pa_end = 0x480981ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_per - mcspi1 */
+static struct omap_hwmod_ocp_if omap44xx_l4_per__mcspi1 = {
+ .master = omap44xx_l4_per_hwmod,
+ .slave = omap44xx_mcspi1_hwmod,
+ .clk= l4_div_ck,
+ .addr = omap44xx_mcspi1_addrs,
+ .addr_cnt = ARRAY_SIZE(omap44xx_mcspi1_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* mcspi1 slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_mcspi1_slaves[] = {
+ omap44xx_l4_per__mcspi1,
+};
+
+static struct omap2_mcspi_dev_attr omap_mcspi1_dev_attr = {
+ .num_chipselect = 4,
+};
+
+static struct omap_hwmod omap44xx_mcspi1_hwmod = {
+ .name = mcspi1,
+ .class = omap44xx_mcspi_hwmod_class,
+ .mpu_irqs = omap44xx_mcspi1_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_mcspi1_irqs),
+ .sdma_reqs = omap44xx_mcspi1_sdma_reqs,
+ .sdma_reqs_cnt = ARRAY_SIZE(omap44xx_mcspi1_sdma_reqs),
+ .main_clk = mcspi1_fck,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_reg = OMAP4430_CM_L4PER_MCSPI1_CLKCTRL,
+ },
+ },
+ .slaves = omap44xx_mcspi1_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap44xx_mcspi1_slaves),
+ .dev_attr = omap_mcspi1_dev_attr,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+};
+
+/* mcspi2 */
+static struct omap_hwmod omap44xx_mcspi2_hwmod;
+static struct omap_hwmod_irq_info omap44xx_mcspi2_irqs[] = {
+ { .irq = 66 + OMAP44XX_IRQ_GIC_START },
+};
+
+static struct omap_hwmod_dma_info omap44xx_mcspi2_sdma_reqs[] = {
+ { .name = tx0, .dma_req = 42 + OMAP44XX_DMA_REQ_START },
+ { .name = rx0, .dma_req = 43 + OMAP44XX_DMA_REQ_START },
+ { .name = tx1, .dma_req = 44 + OMAP44XX_DMA_REQ_START },
+ { .name = rx1, .dma_req = 45 + OMAP44XX_DMA_REQ_START },
+};
+
+static struct omap_hwmod_addr_space omap44xx_mcspi2_addrs[] = {
+ {
+ .pa_start = 0x4809a000,
+ .pa_end = 0x4809a1ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_per - mcspi2 */
+static struct omap_hwmod_ocp_if omap44xx_l4_per__mcspi2 = {
+ .master = omap44xx_l4_per_hwmod,
+ .slave = omap44xx_mcspi2_hwmod,
+ .clk= l4_div_ck,
+ .addr = omap44xx_mcspi2_addrs,
+ .addr_cnt =
[PATCH v3 5/6] OMAP: devices: Modify McSPI device to adapt to hwmod framework
Cleans up all base address definitions for omap_mcspi
and adapts the device registration and driver to hwmod framework.
Changes involves:
1) Removing all base address macro defines.
2) Using omap-device layer to register device and utilizing data from
hwmod data file for base address, dma channel number, Irq_number,
device attribute(number of chipselect).
3) Appending base address with pdata reg_offset for omap4 boards.
For omap4 all regs used in driver deviate with reg_offset_macros
defined with an value of 0x100. So pass this offset through pdata
and append the same to base address retrieved from hwmod data file
and we are not mapping *_HL_* regs which are not used in driver.
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
Acked-by: Grant Likely grant.lik...@secretlab.ca
Reviewed-by: Partha Basak p-bas...@ti.com
---
arch/arm/mach-omap2/devices.c | 187 +++
arch/arm/plat-omap/include/plat/mcspi.h |3 +
drivers/spi/omap2_mcspi.c | 110 +--
3 files changed, 71 insertions(+), 229 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 381f4eb..8cfc654 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -15,6 +15,7 @@
#include linux/io.h
#include linux/clk.h
#include linux/err.h
+#include linux/slab.h
#include mach/hardware.h
#include mach/irqs.h
@@ -279,163 +280,55 @@ static inline void omap_init_audio(void) {}
#include plat/mcspi.h
-#define OMAP2_MCSPI1_BASE 0x48098000
-#define OMAP2_MCSPI2_BASE 0x4809a000
-#define OMAP2_MCSPI3_BASE 0x480b8000
-#define OMAP2_MCSPI4_BASE 0x480ba000
-
-#define OMAP4_MCSPI1_BASE 0x48098100
-#define OMAP4_MCSPI2_BASE 0x4809a100
-#define OMAP4_MCSPI3_BASE 0x480b8100
-#define OMAP4_MCSPI4_BASE 0x480ba100
-
-static struct omap2_mcspi_platform_config omap2_mcspi1_config = {
- .num_cs = 4,
-};
-
-static struct resource omap2_mcspi1_resources[] = {
- {
- .start = OMAP2_MCSPI1_BASE,
- .end= OMAP2_MCSPI1_BASE + 0xff,
- .flags = IORESOURCE_MEM,
- },
-};
-
-static struct platform_device omap2_mcspi1 = {
- .name = omap2_mcspi,
- .id = 1,
- .num_resources = ARRAY_SIZE(omap2_mcspi1_resources),
- .resource = omap2_mcspi1_resources,
- .dev= {
- .platform_data = omap2_mcspi1_config,
- },
-};
-
-static struct omap2_mcspi_platform_config omap2_mcspi2_config = {
- .num_cs = 2,
-};
-
-static struct resource omap2_mcspi2_resources[] = {
- {
- .start = OMAP2_MCSPI2_BASE,
- .end= OMAP2_MCSPI2_BASE + 0xff,
- .flags = IORESOURCE_MEM,
- },
-};
-
-static struct platform_device omap2_mcspi2 = {
- .name = omap2_mcspi,
- .id = 2,
- .num_resources = ARRAY_SIZE(omap2_mcspi2_resources),
- .resource = omap2_mcspi2_resources,
- .dev= {
- .platform_data = omap2_mcspi2_config,
- },
-};
-
-#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP3) || \
- defined(CONFIG_ARCH_OMAP4)
-static struct omap2_mcspi_platform_config omap2_mcspi3_config = {
- .num_cs = 2,
-};
-
-static struct resource omap2_mcspi3_resources[] = {
- {
- .start = OMAP2_MCSPI3_BASE,
- .end= OMAP2_MCSPI3_BASE + 0xff,
- .flags = IORESOURCE_MEM,
- },
-};
-
-static struct platform_device omap2_mcspi3 = {
- .name = omap2_mcspi,
- .id = 3,
- .num_resources = ARRAY_SIZE(omap2_mcspi3_resources),
- .resource = omap2_mcspi3_resources,
- .dev= {
- .platform_data = omap2_mcspi3_config,
- },
-};
-#endif
-
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
-static struct omap2_mcspi_platform_config omap2_mcspi4_config = {
- .num_cs = 1,
-};
-
-static struct resource omap2_mcspi4_resources[] = {
- {
- .start = OMAP2_MCSPI4_BASE,
- .end= OMAP2_MCSPI4_BASE + 0xff,
- .flags = IORESOURCE_MEM,
- },
-};
-
-static struct platform_device omap2_mcspi4 = {
- .name = omap2_mcspi,
- .id = 4,
- .num_resources = ARRAY_SIZE(omap2_mcspi4_resources),
- .resource = omap2_mcspi4_resources,
- .dev= {
- .platform_data = omap2_mcspi4_config,
+struct omap_device_pm_latency omap_mcspi_latency[] = {
+ [0] = {
+ .deactivate_func = omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
+
[PATCH v3 6/6] OMAP: runtime: McSPI driver runtime conversion
McSPI runtime conversion.
Changes involves:
1) remove clock framework apis to use runtime framework apis.
2) context restore from runtime resume which is a callback for get_sync.
3) Remove SYSCONFIG(sysc) register handling
(a) Remove context save and restore of sysc reg and remove soft reset
done from sysc reg as this will be done with hwmod framework.
(b) Also cleanup sysc reg bit macros.
4) Rename the omap2_mcspi_reset function to omap2_mcspi_master_setup
function as with hwmod changes soft reset will be done in
hwmod framework itself and use the return value from clock
enable function to return for failure scenarios.
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
Acked-by: Grant Likely grant.lik...@secretlab.ca
Reviewed-by: Partha Basak p-bas...@ti.com
---
drivers/spi/omap2_mcspi.c | 120 +---
1 files changed, 46 insertions(+), 74 deletions(-)
diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
index 6018fe4..6a202a1 100644
--- a/drivers/spi/omap2_mcspi.c
+++ b/drivers/spi/omap2_mcspi.c
@@ -33,6 +33,7 @@
#include linux/clk.h
#include linux/io.h
#include linux/slab.h
+#include linux/pm_runtime.h
#include linux/spi/spi.h
@@ -46,7 +47,6 @@
#define OMAP2_MCSPI_MAX_CTRL 4
#define OMAP2_MCSPI_REVISION 0x00
-#define OMAP2_MCSPI_SYSCONFIG 0x10
#define OMAP2_MCSPI_SYSSTATUS 0x14
#define OMAP2_MCSPI_IRQSTATUS 0x18
#define OMAP2_MCSPI_IRQENABLE 0x1c
@@ -63,13 +63,6 @@
/* per-register bitmasks: */
-#define OMAP2_MCSPI_SYSCONFIG_SMARTIDLEBIT(4)
-#define OMAP2_MCSPI_SYSCONFIG_ENAWAKEUPBIT(2)
-#define OMAP2_MCSPI_SYSCONFIG_AUTOIDLE BIT(0)
-#define OMAP2_MCSPI_SYSCONFIG_SOFTRESETBIT(1)
-
-#define OMAP2_MCSPI_SYSSTATUS_RESETDONEBIT(0)
-
#define OMAP2_MCSPI_MODULCTRL_SINGLE BIT(0)
#define OMAP2_MCSPI_MODULCTRL_MS BIT(2)
#define OMAP2_MCSPI_MODULCTRL_STESTBIT(3)
@@ -122,13 +115,12 @@ struct omap2_mcspi {
spinlock_t lock;
struct list_headmsg_queue;
struct spi_master *master;
- struct clk *ick;
- struct clk *fck;
/* Virtual base address of the controller */
void __iomem*base;
unsigned long phys;
/* SPI1 has 4 channels, while SPI2 has 2 */
struct omap2_mcspi_dma *dma_channels;
+ struct device *dev;
};
struct omap2_mcspi_cs {
@@ -144,7 +136,6 @@ struct omap2_mcspi_cs {
* corresponding registers are modified.
*/
struct omap2_mcspi_regs {
- u32 sysconfig;
u32 modulctrl;
u32 wakeupenable;
struct list_head cs;
@@ -268,9 +259,6 @@ static void omap2_mcspi_restore_ctx(struct omap2_mcspi
*mcspi)
mcspi_write_reg(spi_cntrl, OMAP2_MCSPI_MODULCTRL,
omap2_mcspi_ctx[spi_cntrl-bus_num - 1].modulctrl);
- mcspi_write_reg(spi_cntrl, OMAP2_MCSPI_SYSCONFIG,
- omap2_mcspi_ctx[spi_cntrl-bus_num - 1].sysconfig);
-
mcspi_write_reg(spi_cntrl, OMAP2_MCSPI_WAKEUPENABLE,
omap2_mcspi_ctx[spi_cntrl-bus_num - 1].wakeupenable);
@@ -280,20 +268,12 @@ static void omap2_mcspi_restore_ctx(struct omap2_mcspi
*mcspi)
}
static void omap2_mcspi_disable_clocks(struct omap2_mcspi *mcspi)
{
- clk_disable(mcspi-ick);
- clk_disable(mcspi-fck);
+ pm_runtime_put_sync(mcspi-dev);
}
static int omap2_mcspi_enable_clocks(struct omap2_mcspi *mcspi)
{
- if (clk_enable(mcspi-ick))
- return -ENODEV;
- if (clk_enable(mcspi-fck))
- return -ENODEV;
-
- omap2_mcspi_restore_ctx(mcspi);
-
- return 0;
+ return pm_runtime_get_sync(mcspi-dev);
}
static int mcspi_wait_for_reg_bit(void __iomem *reg, unsigned long bit)
@@ -819,8 +799,9 @@ static int omap2_mcspi_setup(struct spi_device *spi)
return ret;
}
- if (omap2_mcspi_enable_clocks(mcspi))
- return -ENODEV;
+ ret = omap2_mcspi_enable_clocks(mcspi);
+ if (ret 0)
+ return ret;
ret = omap2_mcspi_setup_transfer(spi, NULL);
omap2_mcspi_disable_clocks(mcspi);
@@ -863,10 +844,11 @@ static void omap2_mcspi_work(struct work_struct *work)
struct omap2_mcspi *mcspi;
mcspi = container_of(work, struct omap2_mcspi, work);
- spin_lock_irq(mcspi-lock);
- if (omap2_mcspi_enable_clocks(mcspi))
- goto out;
+ if (omap2_mcspi_enable_clocks(mcspi) 0)
+ return;
+
+ spin_lock_irq(mcspi-lock);
/* We only enable one channel at a time -- the one whose message is
* at the head of the queue -- although this controller would gladly
@@ -979,10 +961,9 @@ static void omap2_mcspi_work(struct work_struct *work)
Re: [PATCHv2 1/2] OMAP3: Devkit8000: Change lcd power pin
Hello. Thomas Weber wrote: The reset_gpio pin for lcd is connected with TWL4030 LedA. TWL4030 GPIO.1 has a not connected resistor. Fix indention issue. Indentation. The comment line uses 8 whitespaces. Replaced with one tabulator. Reported-by: Daniel Morsing daniel.mors...@gmail.com Signed-off-by: Thomas Weber we...@corscience.de WBR, Sergei -- 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] ARM: Thumb-2: Symbol manipulation macros for function body copying
Hi, On Mon, Jan 17, 2011 at 2:02 PM, Jean Pihet jean.pi...@newoldbits.com wrote: [...] Note that aligning the source and destination pointers to a multiple of 8 bytes has an impact on the behavio(u)r and so must be carefully thought and tested on OMAP1/2/3 platforms. Do you have any specific concerns regarding this? Currently, the only issue I can think of is that the need to allocate aligned memory from the SRAM will increase the total amount allocated, which could be a problem if we end up overflowing the available SRAM. This does not appear to happen in the case I've tested -- I currently round up the amount allocated in omap_sram_push to be a multiple of 8 bytes. This, combined with a couple of .align 3 directives, is enough to get me a booting system on omap3... but I haven't tested exhaustively. 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 0/6] OMAP: McSPI: Hwmod adaptation + runtime conversion
On Mon, Jan 17, 2011 at 7:23 AM, Govindraj.R govindraj.r...@ti.com wrote: Changes invloves: 1) Addition of hwmod data for omap2/3/4. 2) McSPI driver hwmod adaptation with cleanup of base address macros and using omap-device API's. 3) Runtime Conversion of McSPI driver. Changes from v2: --- 1) Fixing minor comments and adding ack from Grant Likely. https://patchwork.kernel.org/patch/371321/ https://patchwork.kernel.org/patch/371331/ Hi Govindraj, My comment still stands that it looks like a lot of duplicate data is being generated, which makes this patch set larger than it appears to need to be, but those files aren't in a directory that I maintain so it's not my call. :-) Tony, I'm okay with your merging this series through your tree. g. Changes from v1: --- 1) Fixing patch 5/5 comments for hwmod+runtime Split the patch 5/5 to hwmod adaptation and then runtime conversion http://www.mail-archive.com/linux-omap@vger.kernel.org/msg33387.html Testing Updates: Was tested using data transfer test module available at: http://dev.omapzoom.org/?p=richo/device_driver_test.git;a=blob;f=mcspi/test_code/ utils/mcspi_modules/omap_mcspi_datatest.c; h=e42ec10c5c844abdde6a7175a268b379fbbdb655; hb=5d9a755d50e58de861c5e8991f2f607bc49b5dc3 This test basically involves MISO -- MOSI lines looped and data transfer test done using the above test module. System wide suspend and ret/off counts observation, ensured that no behavioral difference with and without this patch series. Charulatha V (1): OMAP: devices: Modify McSPI device to adapt to hwmod framework Govindraj.R (5): OMAP2420: hwmod data: Add McSPI OMAP2430: hwmod data: Add McSPI OMAP3: hwmod data: Add McSPI OMAP4: hwmod data: Add McSPI OMAP: runtime: McSPI driver runtime conversion arch/arm/mach-omap2/devices.c | 187 --- arch/arm/mach-omap2/omap_hwmod_2420_data.c | 156 arch/arm/mach-omap2/omap_hwmod_2430_data.c | 219 ++ arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 280 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 266 ++ arch/arm/plat-omap/include/plat/mcspi.h | 11 + drivers/spi/omap2_mcspi.c | 224 +++--- 7 files changed, 1043 insertions(+), 300 deletions(-) -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- 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] ARM: Thumb-2: Symbol manipulation macros for function body copying
Hi Dave, On Mon, Jan 17, 2011 at 4:35 PM, Dave Martin dave.mar...@linaro.org wrote: Hi, On Mon, Jan 17, 2011 at 2:02 PM, Jean Pihet jean.pi...@newoldbits.com wrote: [...] Note that aligning the source and destination pointers to a multiple of 8 bytes has an impact on the behavio(u)r and so must be carefully thought and tested on OMAP1/2/3 platforms. Do you have any specific concerns regarding this? Currently, the only issue I can think of is that the need to allocate aligned memory from the SRAM will increase the total amount allocated, which could be a problem if we end up overflowing the available SRAM. Agree. It does not look like there are SRAM overflows today. Note that in that case you will get warned soon enough by the 'Not enough space in SRAM' message. One could think about some nasty side-effects bugs like badly written PIC code, hardcoded addresses... that appear to work with the current version. In short this needs to be thoroughly tested on OMAP1/2/3 platforms. This does not appear to happen in the case I've tested -- I currently round up the amount allocated in omap_sram_push to be a multiple of 8 bytes. This, combined with a couple of .align 3 directives, is enough to get me a booting system on omap3... but I haven't tested exhaustively. That is OK. I have a patch ready for OMAP1/2/3, tested on OMAP3 only. Cheers ---Dave Thanks, Jean -- 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] OMAP: use fncpy to copy the PM code functions to SRAM
On Mon, Jan 17, 2011 at 2:01 PM, Jean Pihet jean.pi...@newoldbits.com wrote: On Fri, Jan 14, 2011 at 6:34 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Fri, Jan 14, 2011 at 05:13:01PM +0100, Jean Pihet wrote: Is the name 'omap_sram_push' wrong then? What about the following? @@ -251,9 +251,8 @@ void * omap_sram_push(void * start, unsigned long size) omap_sram_ceil -= size; omap_sram_ceil = ROUND_DOWN(omap_sram_ceil, sizeof(void *)); - memcpy((void *)omap_sram_ceil, start, size); - flush_icache_range((unsigned long)omap_sram_ceil, - (unsigned long)(omap_sram_ceil + size)); - return (void *)omap_sram_ceil; + return fncpy((void *)omap_sram_ceil, start, size); It's more correct, but still missing out on the type safety which we've tried to provide with fncpy. IIUC the type of the function is propagated from the 2nd argument (funcp) to the return value, which is fine here. The (void)* is here only to avoid a warning thrown by memcpy. I think Russell's argument was that the compiler will not notice if you mismatch the return type and the function to be copied, because the casts to/from void * make the compiler blind to the real types involved. So: int f(int); size_t size_of_f; void *buffer; int (*_copied_f1)(int); char *(*_copied_f2)(char *); _copied_f1 = fncpy(buffer, f, size_of_f); /* OK */ _copied_f2 = fncpy(buffer, f, size_of_f); /* compile error */ _copied_f1 = omap_sram_push(f, size_of_f); /* OK */ _copied_f2 = opam_sram_push(f, size_of_f); /* type mismatch, but compilation succeeds */ One way to work around this is would be to make omap_sram_push() a macro: #define omap_sram_push(funcp, size) \ (typeof(funcp))_do_omap_sram_push((void *)(funcp), size) ... where the definition of _do_omap_sram_push() is the same is the existing definition of omap_sram_push(). Providing _do_omap_sram_push() is not called directly, this should now be type-safe. 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] ARM: Thumb-2: Symbol manipulation macros for function body copying
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Dave Martin Sent: Monday, January 17, 2011 9:06 PM To: Jean Pihet Cc: linux-arm-ker...@lists.infradead.org; linux- o...@vger.kernel.org; Jean Pihet Subject: Re: [PATCH v4] ARM: Thumb-2: Symbol manipulation macros for function body copying Hi, On Mon, Jan 17, 2011 at 2:02 PM, Jean Pihet jean.pi...@newoldbits.com wrote: [...] Note that aligning the source and destination pointers to a multiple of 8 bytes has an impact on the behavio(u)r and so must be carefully thought and tested on OMAP1/2/3 platforms. Do you have any specific concerns regarding this? Currently, the only issue I can think of is that the need to allocate aligned memory from the SRAM will increase the total amount allocated, which could be a problem if we end up overflowing the available SRAM. This does not appear to happen in the case I've tested -- I currently round up the amount allocated in omap_sram_push to be a multiple of 8 bytes. This, combined with a couple of .align 3 directives, is enough to get me a booting system on omap3... but I haven't tested exhaustively. I don't think there can be overflow issue considering it's current use and available SRAM on OMAP. How much additional memory you will need to take care of alignment. Max additional memory = total fns * ( 8 + 8) = ~ 10 * 16 = 160 bytes. Should be ok. Regards, Santosh -- 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 0/6] OMAP: McSPI: Hwmod adaptation + runtime conversion
Hi Grant, On 1/17/2011 4:47 PM, Grant Likely wrote: On Mon, Jan 17, 2011 at 7:23 AM, Govindraj.Rgovindraj.r...@ti.com wrote: Changes invloves: 1) Addition of hwmod data for omap2/3/4. 2) McSPI driver hwmod adaptation with cleanup of base address macros and using omap-device API's. 3) Runtime Conversion of McSPI driver. Changes from v2: --- 1) Fixing minor comments and adding ack from Grant Likely. https://patchwork.kernel.org/patch/371321/ https://patchwork.kernel.org/patch/371331/ Hi Govindraj, My comment still stands that it looks like a lot of duplicate data is being generated, which makes this patch set larger than it appears to need to be, but those files aren't in a directory that I maintain so it's not my call. :-) As Paul said in a previous email, we are well aware of that issue. This is something I will work on for the future OMAP4 variants. Since these files are manually done on OMAP2 3 and generated for OMAP4, it will require some time and a bunch of scripts to manage easily the delta between OMAP2, 3 and 4. It should be much more straightforward for OMAP4 and beyond. Regards, Benoit Tony, I'm okay with your merging this series through your tree. g. Changes from v1: --- 1) Fixing patch 5/5 comments for hwmod+runtime Split the patch 5/5 to hwmod adaptation and then runtime conversion http://www.mail-archive.com/linux-omap@vger.kernel.org/msg33387.html Testing Updates: Was tested using data transfer test module available at: http://dev.omapzoom.org/?p=richo/device_driver_test.git;a=blob;f=mcspi/test_code/ utils/mcspi_modules/omap_mcspi_datatest.c; h=e42ec10c5c844abdde6a7175a268b379fbbdb655; hb=5d9a755d50e58de861c5e8991f2f607bc49b5dc3 This test basically involves MISO-- MOSI lines looped and data transfer test done using the above test module. System wide suspend and ret/off counts observation, ensured that no behavioral difference with and without this patch series. Charulatha V (1): OMAP: devices: Modify McSPI device to adapt to hwmod framework Govindraj.R (5): OMAP2420: hwmod data: Add McSPI OMAP2430: hwmod data: Add McSPI OMAP3: hwmod data: Add McSPI OMAP4: hwmod data: Add McSPI OMAP: runtime: McSPI driver runtime conversion arch/arm/mach-omap2/devices.c | 187 --- arch/arm/mach-omap2/omap_hwmod_2420_data.c | 156 arch/arm/mach-omap2/omap_hwmod_2430_data.c | 219 ++ arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 280 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 266 ++ arch/arm/plat-omap/include/plat/mcspi.h| 11 + drivers/spi/omap2_mcspi.c | 224 +++--- 7 files changed, 1043 insertions(+), 300 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
Re: [PATCH v4] ARM: Thumb-2: Symbol manipulation macros for function body copying
On Mon, Jan 17, 2011 at 03:02:20PM +0100, Jean Pihet wrote: On Fri, Jan 14, 2011 at 10:17 PM, Dave Martin dave.mar...@linaro.org wrote: + * These macros are intended for use when there is a need to copy a low-level + * function body into special memory. + * + * For example, when reconfiguring the SDRAM controller, the code doing the + * reconfiguration may need to run from SRAM. + * + * NOTE: that the copied function body must be entirely self-contained and + * position-independent in order for this to work properly. + * + * NOTE: in order for embedded literals and data to get referenced correctly, + * the alignment of functions must be preserved when copying. To ensure this, + * the source and destination addresses for fncpy() must be aligned to a + * multiple of 8 bytes: you will be get a BUG() if this condition is not met. + * You will typically need a .align 3 directive in the assembler where the + * function to be copied is defined, and ensure that your allocator for the + * destination buffer returns 8-byte-aligned pointers. Note that aligning the source and destination pointers to a multiple of 8 bytes has an impact on the behavio(u)r and so must be carefully thought and tested on OMAP1/2/3 platforms. OMAP3 is ARMv7, so is EABI. EABI requires 64-bit data to be aligned to natural 64-bit boundaries, so architecturally it's correct. Nevertheless, the code may not be using 64-bit data, so that doesn't apply - but fncpy() can't know that. -- 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 4/6] OMAP4: hwmod data: Add McSPI
Govindraj.R govindraj.r...@ti.com writes:
Update omap4 hwmod file with McSPI info.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
Acked-by: Grant Likely grant.lik...@secretlab.ca
Shouldn't Benoit be the author of this patch?
Kevin
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 266
1 files changed, 266 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index c2806bd..d4cd695 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -24,6 +24,7 @@
#include plat/cpu.h
#include plat/gpio.h
#include plat/dma.h
+#include plat/mcspi.h
#include omap_hwmod_common_data.h
@@ -2001,6 +2002,265 @@ static struct omap_hwmod omap44xx_wd_timer3_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
};
+/*
+ * 'mcspi' class
+ * multichannel serial port interface (mcspi) / master/slave synchronous
serial
+ * bus
+ */
+
+static struct omap_hwmod_class_sysconfig omap44xx_mcspi_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_EMUFREE |
+SYSC_HAS_SOFTRESET | SYSC_HAS_RESET_STATUS),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class omap44xx_mcspi_hwmod_class = {
+ .name = mcspi,
+ .sysc = omap44xx_mcspi_sysc,
+ .rev = OMAP4_MCSPI_REV,
+};
+
+/* mcspi1 */
+static struct omap_hwmod omap44xx_mcspi1_hwmod;
+static struct omap_hwmod_irq_info omap44xx_mcspi1_irqs[] = {
+ { .irq = 65 + OMAP44XX_IRQ_GIC_START },
+};
+
+static struct omap_hwmod_dma_info omap44xx_mcspi1_sdma_reqs[] = {
+ { .name = tx0, .dma_req = 34 + OMAP44XX_DMA_REQ_START },
+ { .name = rx0, .dma_req = 35 + OMAP44XX_DMA_REQ_START },
+ { .name = tx1, .dma_req = 36 + OMAP44XX_DMA_REQ_START },
+ { .name = rx1, .dma_req = 37 + OMAP44XX_DMA_REQ_START },
+ { .name = tx2, .dma_req = 38 + OMAP44XX_DMA_REQ_START },
+ { .name = rx2, .dma_req = 39 + OMAP44XX_DMA_REQ_START },
+ { .name = tx3, .dma_req = 40 + OMAP44XX_DMA_REQ_START },
+ { .name = rx3, .dma_req = 41 + OMAP44XX_DMA_REQ_START },
+};
+
+static struct omap_hwmod_addr_space omap44xx_mcspi1_addrs[] = {
+ {
+ .pa_start = 0x48098000,
+ .pa_end = 0x480981ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_per - mcspi1 */
+static struct omap_hwmod_ocp_if omap44xx_l4_per__mcspi1 = {
+ .master = omap44xx_l4_per_hwmod,
+ .slave = omap44xx_mcspi1_hwmod,
+ .clk= l4_div_ck,
+ .addr = omap44xx_mcspi1_addrs,
+ .addr_cnt = ARRAY_SIZE(omap44xx_mcspi1_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* mcspi1 slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_mcspi1_slaves[] = {
+ omap44xx_l4_per__mcspi1,
+};
+
+static struct omap2_mcspi_dev_attr omap_mcspi1_dev_attr = {
+ .num_chipselect = 4,
+};
+
+static struct omap_hwmod omap44xx_mcspi1_hwmod = {
+ .name = mcspi1,
+ .class = omap44xx_mcspi_hwmod_class,
+ .mpu_irqs = omap44xx_mcspi1_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_mcspi1_irqs),
+ .sdma_reqs = omap44xx_mcspi1_sdma_reqs,
+ .sdma_reqs_cnt = ARRAY_SIZE(omap44xx_mcspi1_sdma_reqs),
+ .main_clk = mcspi1_fck,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_reg = OMAP4430_CM_L4PER_MCSPI1_CLKCTRL,
+ },
+ },
+ .slaves = omap44xx_mcspi1_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap44xx_mcspi1_slaves),
+ .dev_attr = omap_mcspi1_dev_attr,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+};
+
+/* mcspi2 */
+static struct omap_hwmod omap44xx_mcspi2_hwmod;
+static struct omap_hwmod_irq_info omap44xx_mcspi2_irqs[] = {
+ { .irq = 66 + OMAP44XX_IRQ_GIC_START },
+};
+
+static struct omap_hwmod_dma_info omap44xx_mcspi2_sdma_reqs[] = {
+ { .name = tx0, .dma_req = 42 + OMAP44XX_DMA_REQ_START },
+ { .name = rx0, .dma_req = 43 + OMAP44XX_DMA_REQ_START },
+ { .name = tx1, .dma_req = 44 + OMAP44XX_DMA_REQ_START },
+ { .name = rx1, .dma_req = 45 + OMAP44XX_DMA_REQ_START },
+};
+
+static struct omap_hwmod_addr_space omap44xx_mcspi2_addrs[] = {
+ {
+ .pa_start = 0x4809a000,
+ .pa_end = 0x4809a1ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_per - mcspi2 */
+static struct omap_hwmod_ocp_if omap44xx_l4_per__mcspi2 = {
+ .master = omap44xx_l4_per_hwmod,
+ .slave = omap44xx_mcspi2_hwmod,
+ .clk
RE: [PATCH] omap: wd_timer: Fix crash frm wdt_probe when !CONFIG_RUNTIME_PM
-Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Thursday, January 06, 2011 11:56 PM To: Santosh Shilimkar Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: Re: [PATCH] omap: wd_timer: Fix crash frm wdt_probe when !CONFIG_RUNTIME_PM Hi Santosh, On Wed, 5 Jan 2011, Santosh Shilimkar wrote: Commit ff2516fb 'wd_timer: disable on boot via hwmod postsetup mechanism' introduced watchdog timer state state management using postsetup_state. This was done to allow some board files to support watchdog coverage throughout kernel initialization and it work as intended when RUNTIME_PM is enabled. With !CONFIG_RUNTIME_PM and no board is specifically requests watchdog to remain enabled the omap_wdt_probe crashesh. This is because hwmod in absense of runtime PM unable to turn watchdog clocks because it's state is set to be disabled. For rest of the device, the state is set as enabled in absense of RUNTIME_PM [1.372558] Unhandled fault: imprecise external abort (0x1406) at 0xad733eeb [1.379913] Internal error: : 1406 [#1] SMP [1.384277] last sysfs file: [1.387359] Modules linked in: [1.390563] CPU: 0Tainted: GW(2.6.37-rc7-00265- g4298a4c-dirty #23) [1.398468] PC is at omap_wdt_disable+0x2c/0x3c [1.403198] LR is at omap_wdt_probe+0x124/0x1e0 [1.407928] pc : [c02f5bf4]lr : [c03be10c]psr: 6013 [1.407958] sp : df833f00 ip : fp : [1.419921] r10: c0ac57ac r9 : df959e00 r8 : [1.425384] r7 : df959e08 r6 : df8000c0 r5 : df95bebc r4 : df87dde0 [1.432189] r3 : fc314000 r2 : r1 : fc314034 r0 : df87dde0 This patch make the default watchdog state to be enabled in case of !CONFIG_RUNTIME_PM. This fixes the crash Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Cc: Paul Walmsley p...@pwsan.com --- Paul, I am not too sure if it breaks your _shutdown idea of watchdog timer. Maybe. What happens in a case where the bootloader enables the watchdog, but the booting kernel is compiled with !CONFIG_OMAP_WATCHDOG and !CONFIG_PM_RUNTIME? Won't the watchdog reset the MPU unexpectedly in that case? Or am I missing something... I tried this scenario and some how the WDT isn't reseting MPU with my patch. Actually I was expecting it should reset but it didn't. Regards, Santosh -- 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: [PATCHv2 1/2] OMAP3: Devkit8000: Change lcd power pin
On Mon, 2011-01-17 at 15:11 +0100, Thomas Weber wrote:
The reset_gpio pin for lcd is connected with TWL4030 LedA.
TWL4030 GPIO.1 has a not connected resistor.
Fix indention issue. The comment line uses 8 whitespaces.
Replaced with one tabulator.
Reported-by: Daniel Morsing daniel.mors...@gmail.com
Signed-off-by: Thomas Weber we...@corscience.de
---
arch/arm/mach-omap2/board-devkit8000.c |7 ++-
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 451e7ff..719f4e5 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -114,9 +114,6 @@ static struct omap2_hsmmc_info mmc[] = {
static int devkit8000_panel_enable_lcd(struct omap_dss_device *dssdev)
{
- twl_i2c_write_u8(TWL4030_MODULE_GPIO, 0x80, REG_GPIODATADIR1);
- twl_i2c_write_u8(TWL4030_MODULE_LED, 0x0, 0x0);
-
if (gpio_is_valid(dssdev-reset_gpio))
gpio_set_value_cansleep(dssdev-reset_gpio, 1);
return 0;
@@ -245,8 +242,8 @@ static int devkit8000_twl_gpio_setup(struct device *dev,
/* TWL4030_GPIO_MAX + 1 == ledB, PMU_STAT (out, active low LED) */
gpio_leds[2].gpio = gpio + TWL4030_GPIO_MAX + 1;
-/* gpio + 1 is LCD_PWREN (out, active high) */
- devkit8000_lcd_device.reset_gpio = gpio + 1;
+ /* TWL4030_GPIO_MAX + 0 is LCD_PWREN (out, active high) */
+ devkit8000_lcd_device.reset_gpio = gpio + TWL4030_GPIO_MAX + 0;
gpio_request(devkit8000_lcd_device.reset_gpio, LCD_PWREN);
/* Disable until needed */
gpio_direction_output(devkit8000_lcd_device.reset_gpio, 0);
Hey Thomas.
Only real issue I can see is that fact that the commit message doesn't
mention the removal of the low level twl4030 calls. They are essentially
non-functional in their current state and mentioning that and why they
were removed would help in any future code archaeology.
Regards,
Daniel
--
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
Creating a uboot script that will write MLO only once to NAND
Hi,
I'm trying to develop a microSD card image that will allow batch
programming of beagleboard NAND devices for a production environment.
My problem is MLO. As I understand, it needs to be written to NAND from u-boot
with HW ECC turned on. I tried at the kernel level, after ensuring that it is
writable from the kernel, by modifying board-omap3beagle.c, but for some reason
MLO written to NAND in that manner didn't work. Is this a constraint, that MLO
must be written from u-boot itself.
What I proceeded to do next is to create a boot.scr to automate the process.
mmc init
fatload mmc 0:1 8000 MLO
nandecc hw
nand erase 0 8
nand write 8000 0 8
setenv bootcmd 'if mmc init ${mmcdev}; then if run loadbootscript; then run
bootscript; else if run loaduimage; then run mmcboot; else run nandboot; fi;
fi; else run nandboot; fi'
setenv bootdelay '3'
setenv baudrate '115200'
setenv loadaddr '0x8200'
setenv usbtty 'cdc_acm'
setenv console ttyS2,115200n8
setenv mpurate '500'
setenv buddy 'none'
setenv vram '12M'
setenv dvimode '480x272MR-16@60'
setenv defaultdisplay 'dvi'
setenv mmcdev '1'
setenv mmcroot '/dev/mmcblk0p2 rw'
setenv mmcrootfstype 'ext3 rootwait'
setenv nandroot '/dev/mtdblock5 rw'
setenv nandrootfstype 'yaffs2 rootwait'
setenv nandargs 'setenv bootargs androidboot.console=ttyS2 console=${console}
root=${nandroot} rootfstype=${nandrootfstype} vram=${vram} omapfb.vram=0:4M
omapfb.mode=${dvimode} omapdss.def_disp=${defaultdisplay} omapfb.debug=y
omapdss.debug=y init=/init'
setenv loadbootscript 'fatload mmc ${mmcdev} ${loadaddr} boot.scr'
setenv bootscript 'echo Running bootscript from mmc ...; source ${loadaddr}'
setenv loaduimage 'fatload mmc ${mmcdev} ${loadaddr} uImage'
setenv mmcboot 'echo Booting from mmc ...; run mmcargs; bootm ${loadaddr}'
setenv nandboot 'echo Booting from nand ...; run nandargs; nand read
${loadaddr} 28 40; bootm ${loadaddr}'
setenv mmcargs 'setenv bootargs androidboot.console=ttyS2 console=${console}
root=${mmcroot} rootfstype=${mmcrootfstype} vram=${vram} omapfb.vram=0:4M
omapfb.mode=${dvimode} omapdss.def_disp=${defaultdisplay} omapfb.debug=y
omapdss.debug=y init=/init'
saveenv
boot
However it keeps running forever in a loop.
Hit any key to stop autoboot: 0
mmc1 is available
reading boot.scr
1679 bytes read
Running bootscript from mmc ...
## Executing script at 8200
mmc1 is available
reading MLO
24296 bytes read
HW ECC selected
NAND erase: device 0 offset 0x0, size 0x8
Erasing at 0x6 -- 100% complete.
OK
NAND write: device 0 offset 0x0, size 0x8
524288 bytes written: OK
## Switch baudrate to 115200 bps and press ENTER ...
Saving Environment to NAND...
Erasing Nand...
Erasing at 0x26 -- 100% complete.
Writing to Nand... done
mmc1 is available
reading boot.scr
1679 bytes read
Running bootscript from mmc ...
## Executing script at 8200
mmc1 is available
reading MLO
24296 bytes read
HW ECC selected
NAND erase: device 0 offset 0x0, size 0x8
Erasing at 0x6 -- 100% complete.
OK
How can I create a u-boot script that will only write MLO once to NAND? and
then proceed with uboot and kernel load to flash the rest of the NAND
partitions?
At the moment, as soon as it writes MLO to NAND, it requests for a restart.
Since the boot.scr it in the microSD card, it keeps writing to MLO in a loop.
One solution is to use two microSD cards, one to flash MLO. and the other to
update u-boot environment variables, and then proceed with flashing the kernel
and rootfile system.
However, its quite inefficient to have two microSD cards, and would prefer to
do it in one shot.
Best regards,
Elvis
Hi,
I'm trying to develop a microSD card image that will allow batch
programming of beagleboard NAND devices for a production environment.
My problem is MLO. As I understand, it needs to be written to NAND from u-boot
with HW ECC turned on. I tried at the kernel level, after ensuring that it is
writable from the kernel, by modifying board-omap3beagle.c, but for some reason
MLO written to NAND in that manner didn't work. Is this a constraint, that MLO
must be written from u-boot itself.
What I proceeded to do next is to create a boot.scr to automate the process.
mmc init
fatload mmc 0:1 8000 MLO
nandecc hw
nand erase 0 8
nand write 8000 0 8
setenv bootcmd 'if mmc init ${mmcdev}; then if run loadbootscript; then run
bootscript; else if run loaduimage; then run mmcboot; else run nandboot; fi;
fi; else run nandboot; fi'
setenv bootdelay '3'
setenv baudrate '115200'
setenv loadaddr '0x8200'
setenv usbtty 'cdc_acm'
setenv console ttyS2,115200n8
setenv mpurate '500'
setenv buddy 'none'
setenv vram '12M'
setenv dvimode '480x272MR-16@60'
setenv defaultdisplay 'dvi'
setenv mmcdev '1'
setenv mmcroot '/dev/mmcblk0p2 rw'
setenv mmcrootfstype 'ext3 rootwait'
setenv nandroot '/dev/mtdblock5 rw'
setenv nandrootfstype 'yaffs2 rootwait'
setenv nandargs 'setenv bootargs
Re: State of LDP3430 platform
* Woodruff, Richard r-woodru...@ti.com [110115 15:48]: From: Tony Lindgren [mailto:t...@atomide.com] Sent: Friday, January 14, 2011 6:03 PM I've been seeing this on my omap4 panda. While debugging it, I left u-boot console only running for a few minutes to see if that stays up. It did.. And after doing that somehow now my panda boots all the way and stays up. Weird. That is a bit weird. U-boot doesn't do much of anything but spin waiting for characters on serial. The watchdog normally isn't used. Thinking back I have experienced goofiness along these lines before. This had to do with some bad timer initial state assumptions. The timer's count values and states entering the kernel have caused a trip up. I had fixed some of these years back. Its possible some could have snuck back with all the recoding. Many times the simple have some unanticipated twist. The watchdog is something which the old kernel used to fall on also. There were a couple simple trip ups: -1- people forgot to turn clock on all together -2- next, it was touched before clock frame work was initialized -1+2- some code only 'wrote' to watchdog registers. When memory attribute is device, generally the imprecise abort is ignored by the arm. But some times weirdness slipped in around memory weak memory attribute mishandling. Sounds like a fun bug/puzzle which good ole Lauterbach would help in. This happened for a few days both with 2.6.37 and current mainline kernel. After I started debugging it went away with no changes to anything.. So can't debug any further at this point unfortunately. Regards, Tony -- 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: Creating a uboot script that will write MLO only once to NAND
Hi,
I trimmed down the boot script so that it doesn't set the debug console
baud rate. Now I don't get the set baud rate and press enter message, but the
system still keeps re-reading the boot.scr script forever, in a loop.
889 bytes read
Running bootscript from mmc ...
## Executing script at 8200
Saving Environment to NAND...
Erasing Nand...
Erasing at 0x26 -- 100% complete.
Writing to Nand... done
mmc1 is available
reading boot.scr
889 bytes read
Running bootscript from mmc ...
## Executing script at 8200
Saving Environment to NAND...
Erasing Nand...
Erasing at 0x26 -- 100% complete.
Writing to Nand... done
mmc1 is available
reading boot.scr
Here is what my boot script looks like:
setenv bootdelay 3
setenv console 'ttyS2,115200n8'
setenv vram '12M'
setenv dvimode '480x272MR-16@60'
setenv defaultdisplay 'dvi'
setenv mmcdev '1'
setenv mmcroot '/dev/mmcblk0p2 rw'
setenv mmcrootfstype 'ext3 rootwait'
setenv nandroot '/dev/mtdblock5 rw'
setenv nandrootfstype 'yaffs2 rootwait'
setenv nandargs 'setenv bootargs androidboot.console=ttyS2 console=${console}
root=${nandroot} rootfstype=${nandrootfstype} vram=${vram} omapfb.vram=0:4M
omapfb.mode=${dvimode} omapdss.def_disp=${defaultdisplay} omapfb.debug=y
omapdss.debug=y init=/init'
setenv mmcargs 'setenv bootargs androidboot.console=ttyS2 console=${console}
root=${mmcroot} rootfstype=${mmcrootfstype} vram=${vram} omapfb.vram=0:4M
omapfb.mode=${dvimode} omapdss.def_disp=${defaultdisplay} omapfb.debug=y
omapdss.debug=y init=/init'
saveenv
boot
Elvis Dowson
--
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: State of LDP3430 platform
From: Tony Lindgren [mailto:t...@atomide.com] Sent: Monday, January 17, 2011 11:35 AM This happened for a few days both with 2.6.37 and current mainline kernel. After I started debugging it went away with no changes to anything.. So can't debug any further at this point unfortunately. Odd. You might experiment with cold reset vs. warm reset for booting. Initial values of some blocks will be different. Reset tree is something not usually considered. The behavior depends on what level and when it is asserted. Software tends to act like all resets have same effect and this is not the case. I've seen folks burned in PM context several times at both OMAP and PMIC level. Also... something happen behind your back. You can program up the PMIC to take a softreset and issue a hardreset. Regards, Richard W. -- 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: Creating a uboot script that will write MLO only once to NAND
Hi, saveenv boot Fixed it, I should have had the following lines in the boot script... saveenv run loaduimage run mmcboot Elvis Dowson -- 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: Open issues after 2.6.38 merge window
* Russell King r...@arm.linux.org.uk [110117 04:49]: On Mon, Jan 17, 2011 at 06:05:36PM +0530, Santosh Shilimkar wrote: -Original Message- From: Aaro Koskinen [mailto:aaro.koski...@nokia.com] Sent: Monday, January 17, 2011 5:52 PM To: Santosh Shilimkar Cc: Aaro Koskinen; Tony Lindgren; rmk+ker...@arm.linux.org.uk; linux-omap@vger.kernel.org Subject: RE: Open issues after 2.6.38 merge window Hi, On Mon, 17 Jan 2011, Santosh Shilimkar wrote: Amstrad E3 fails during the boot. Bisection points to: commit 211baa7016894c02fc18693e21ca479cd08ac0c0 Author: Russell King rmk+ker...@arm.linux.org.uk Date: Tue Jan 11 16:23:04 2011 + ARM: sched_clock: allow init_sched_clock() to be called early The board does not have sched_clock(), although HAVE_SCHED_CLOCK is defined for all OMAP. I guess above is sorted out by the attached patch from Paul. I don't see how it could help? Amstrad E3 is OMAP 15xx. I read patch again and omap15xx is skipped. Not sure why 15xx is skipped. EWW. This is horrible - and too far complicated. So if we build a kernel with OMAP730 or OMAP15xx support, the 32k counter support is disabled for every platform, which also removes sched_clock() support (as this uses the 32k timer). If CONFIG_OMAP_32K_TIMER is also true (eg, because you enabled OMAP16xx) then we won't have the GP clocksource code. So a kernel which is configured for OMAP15xx + OMAP16xx won't have any clocksource code at all. In effect, all this being done by _negative_ dependencies. As has been seen with deselecting the V6K configuration symbol, negative dependencies are Bad News(tm). This code needs to be restructured for positive dependencies and proper selection of the appopriate clock sources - which then needs to be coupled into sched_clock() properly so OMAP15xx can also benefit from sched_clock() support. I'll take a look at fixing this. Sounds like we need both MPU timer and the 32K timer compiled in, then enable the right one based on runtime checks. Regards, Tony -- 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: Open issues after 2.6.38 merge window
* Russell King r...@arm.linux.org.uk [110117 04:24]: On Mon, Jan 17, 2011 at 05:49:00PM +0530, Santosh Shilimkar wrote: -Original Message- From: Russell King [mailto:r...@arm.linux.org.uk] Sent: Monday, January 17, 2011 5:42 PM To: Santosh Shilimkar Cc: Aaro Koskinen; Tony Lindgren; linux-omap@vger.kernel.org Subject: Re: Open issues after 2.6.38 merge window On Mon, Jan 17, 2011 at 05:29:01PM +0530, Santosh Shilimkar wrote: On Fri, 14 Jan 2011, Tony Lindgren wrote: Before I update out master branch, let's try to summarize the open issues after the merge window. Here's a list of issues in omap-fixes-for-linus that I'm aware of: - NFS root oopses while mounting root - omap4430 es1.0 hangs if L2X0 cache is enabled - omap4 panda powers down after boot (watchdog?) - omap3 ldp board powers down after boot? This doesn't happen for me. OK, good to hear that's a separate issue and fixed. Any other issues? Amstrad E3 fails during the boot. Bisection points to: commit 211baa7016894c02fc18693e21ca479cd08ac0c0 Author: Russell King rmk+ker...@arm.linux.org.uk Date: Tue Jan 11 16:23:04 2011 + ARM: sched_clock: allow init_sched_clock() to be called early The board does not have sched_clock(), although HAVE_SCHED_CLOCK is defined for all OMAP. I guess above is sorted out by the attached patch from Paul. There's an issue missing from Tony's list: - running an omap2plus_defconfig kernel on SMP is unsafe to the point of being data corrupting for filesystems, especially for ext2/ext3 mounted read-write. This is because when CPU_32v6K is disabled - which is required to build a kernel to boot on ARMv6, it turns off the SMP safe bitops - the SMP safe bitops only use instructions available to ARMv6K and above. They are reduced to local-irq-disabling, plain byte loads and stores. So, running omap2plus_defconfig on SMP is risking filesystem corruption. Patches for this are being worked on, but they won't be ready for - rc1. I strongly suggest someone restores some kind of build or runtime error (eg, by removing CPU_32v6K's dependence on !OMAP2 - thereby _intentionally_ breaking omap2plus_defconfig) before someone ends up with a corrupted filesystem. Or just make sure that everyone is aware that omap2plus_defconfig can eat filesystems at the moment. Thanks. I missed your other patch of removing !OMAP2 from CPU_32v6K config. With the problems addressed, I think that removal of !OMAP2 is not strictly required - but I don't like the idea of disabling CPU_32v6K in general as we can't ensure that this kind of thing doesn't happen in the future. For the current -rc cycle, is the spinlock fix is enough while keeping CPU_32v6K disabled? Not disabling CPU_32v6K also fixes the swp_emulate build problem too (which is why I've never seen it here.) There are several V6K bits that need to be addressed (such as a single clrex vs two instruction strex) before we can properly build a kernel supporting V6 but also containing V6K extensions. I agree building in the V6K extensions would the best solution in the long run. Regards, Tony -- 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: Passing mem=1G to kernel on Panda, system is unstable.
On Fri, Jan 14, 2011 at 11:12 AM, Bryan Wu bryan...@canonical.com wrote: On Fri, Jan 14, 2011 at 4:12 PM, Santosh Shilimkar santosh.shilim...@ti.com wrote: Bryan, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Bryan Wu Sent: Tuesday, January 11, 2011 10:22 PM To: linux-omap@vger.kernel.org; Ricardo Salveti de Araujo Subject: Passing mem=1G to kernel on Panda, system is unstable. Hi folks, We are trying to build kernel package or GCC natively on OMAP4 panda board. With the mainline 2.6.37 kernel or Ubuntu Natty 2.6.35 based kernel, we met same instabilities on the system when we try to use mem=1G on the board. Please find our bug tracker here: https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/633227 and I think another bug is also related: https://bugs.launchpad.net/ubuntu/+source/linux-ti- omap4/+bug/690370. System will freeze at all when building GCC natively on Panda. Did any folks meet this issue? or we need more simple test case to catch the root cause of this issue. Haven't seen this issue on my SDP with 2.6.37. Do you have Panda for testing? I don't have SDP. Maybe Sebastien can help to verify on SDP. I reproduced the issue on my Blaze board, confirming that this issue is not specific to panda. Have you enabled HIGHMEM, when tried mem = 1G on 2.6.37 ? Yeah, CONFIG_HIGHMEM=y for this mainline testing. Please use this kernel config file: http://launchpadlibrarian.net/62061659/mainline_config So far, I have not been able to reproduce the issue with CONFIG_HIGHMEM option deactivated (I am cleaning/building kernels for more than 24 hours now), and mem=1G. I will keep my test run, but it seems that deactivating highmem at least hides the issue. -- 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 00/14] Fix issues with ARMv6+v6k+v7 kernels
This patch series reworks the ARMv6/ARMv6K support options, code selection, and bit operations such that it's possible to safely build a kernel which supports ARMv6, ARMv6K, ARMv7 and ARMv7 SMP in one image. Currently, we use CPU_V6 for both ARMv6 and ARMv6K, setting CPU_32v6K if we have the K extensions. CPU_32v6K directly controlled whether we should include the ARMv6K instructions (clrex, load/store exclusive byte, half-word, double). As the bitops code uses the load/store exclusive byte operations, unsetting CPU_32v6K results in these falling back to their non-SMP local-irq-disabling variants. These are only safe in uniprocessor environments. So, the first two patches convert the bitops to use the ARMv6 load/store exclusive word operations - and ensuring correctness by ensuring that the pointer passed in is word-aligned. We then introduce a new CPU_V6K which indicates that we're including an ARMv6K CPU in the build, which frees up CPU_V6 to mean that we're including an ARMv6 non-K CPU. We can then use CPU_V6 to ensure that the non-v6K code paths which are still SMP safe are selected. Without this patch set, such a kernel will be unsafe when run on SMP platforms as it omits necessary SMP code to ensure that bit operations are safe. -- 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 01/14] ARM: bitops: ensure set/clear/change bitops take a word-aligned pointer
Add additional instructions to our assembly bitops functions to ensure that they only operate on word-aligned pointers. This will be necessary when we switch these operations to use the word-based exclusive operations. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- arch/arm/lib/bitops.h |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/arch/arm/lib/bitops.h b/arch/arm/lib/bitops.h index d422529..910d599 100644 --- a/arch/arm/lib/bitops.h +++ b/arch/arm/lib/bitops.h @@ -1,6 +1,8 @@ #if __LINUX_ARM_ARCH__ = 6 defined(CONFIG_CPU_32v6K) .macro bitop, instr + tst r1, #3 + strne r1, [r1, -r1] @ assert word-aligned mov r2, #1 and r3, r0, #7 @ Get bit offset add r1, r1, r0, lsr #3 @ Get byte offset @@ -14,6 +16,8 @@ .endm .macro testop, instr, store + tst r1, #3 + strne r1, [r1, -r1] @ assert word-aligned and r3, r0, #7 @ Get bit offset mov r2, #1 add r1, r1, r0, lsr #3 @ Get byte offset @@ -32,6 +36,8 @@ .endm #else .macro bitop, instr + tst r1, #3 + strne r1, [r1, -r1] @ assert word-aligned and r2, r0, #7 mov r3, #1 mov r3, r3, lsl r2 @@ -52,6 +58,8 @@ * to avoid dirtying the data cache. */ .macro testop, instr, store + tst r1, #3 + strne r1, [r1, -r1] @ assert word-aligned add r1, r1, r0, lsr #3 and r3, r0, #7 mov r0, #1 -- 1.6.2.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
[PATCH 03/14] ARM: v6k: remove CPU_32v6K dependencies in asm/spinlock.h
SMP requires at least the ARMv6K extensions to be present, so if we're
running on SMP, the WFE and SEV instructions must be available.
However, when we run on UP, the v6K extensions may not be available,
and so we don't want WFE/SEV to be in the instruction stream. Use the
SMP alternatives infrastructure to replace these instructions with NOPs
if we build for SMP but run on UP.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/include/asm/spinlock.h | 37 +
1 files changed, 25 insertions(+), 12 deletions(-)
diff --git a/arch/arm/include/asm/spinlock.h b/arch/arm/include/asm/spinlock.h
index 17eb355..da1af52 100644
--- a/arch/arm/include/asm/spinlock.h
+++ b/arch/arm/include/asm/spinlock.h
@@ -5,17 +5,36 @@
#error SMP not supported on pre-ARMv6 CPUs
#endif
+/*
+ * sev and wfe are ARMv6K extensions. Uniprocessor ARMv6 may not have the K
+ * extensions, so when running on UP, we have to patch these instructions away.
+ */
+#define ALT_SMP(smp, up) \
+ 9998: smp \n \
+ .pushsection \.alt.smp.init\, \a\\n\
+ .long 9998b\n\
+ up \n \
+ .popsection\n
+
+#ifdef CONFIG_THUMB2_KERNEL
+#define SEVALT_SMP(sev.w, nop.w)
+#define WFE(cond) ALT_SMP(wfe cond .w, nop.w)
+#else
+#define SEVALT_SMP(sev, nop)
+#define WFE(cond) ALT_SMP(wfe cond, nop)
+#endif
+
static inline void dsb_sev(void)
{
#if __LINUX_ARM_ARCH__ = 7
__asm__ __volatile__ (
dsb\n
- sev
+ SEV
);
-#elif defined(CONFIG_CPU_32v6K)
+#else
__asm__ __volatile__ (
mcr p15, 0, %0, c7, c10, 4\n
- sev
+ SEV
: : r (0)
);
#endif
@@ -46,9 +65,7 @@ static inline void arch_spin_lock(arch_spinlock_t *lock)
__asm__ __volatile__(
1:ldrex %0, [%1]\n
teq %0, #0\n
-#ifdef CONFIG_CPU_32v6K
- wfene\n
-#endif
+ WFE(ne)
strexeq %0, %2, [%1]\n
teqeq %0, #0\n
bne 1b
@@ -107,9 +124,7 @@ static inline void arch_write_lock(arch_rwlock_t *rw)
__asm__ __volatile__(
1:ldrex %0, [%1]\n
teq %0, #0\n
-#ifdef CONFIG_CPU_32v6K
- wfene\n
-#endif
+ WFE(ne)
strexeq %0, %2, [%1]\n
teq %0, #0\n
bne 1b
@@ -176,9 +191,7 @@ static inline void arch_read_lock(arch_rwlock_t *rw)
1:ldrex %0, [%2]\n
adds%0, %0, #1\n
strexpl %1, %0, [%2]\n
-#ifdef CONFIG_CPU_32v6K
- wfemi\n
-#endif
+ WFE(mi)
rsbpls %0, %1, #0\n
bmi 1b
: =r (tmp), =r (tmp2)
--
1.6.2.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
[PATCH 05/14] ARM: v6k: Realview EB 11MPCore and PB11MPCore use V6K architecture CPUs
Make Realview EB ARM11MPCore and PB11MPCore select the new V6K CPU option. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- arch/arm/mach-realview/Kconfig |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-realview/Kconfig b/arch/arm/mach-realview/Kconfig index b4575ae..e219459 100644 --- a/arch/arm/mach-realview/Kconfig +++ b/arch/arm/mach-realview/Kconfig @@ -17,7 +17,7 @@ config REALVIEW_EB_A9MP config REALVIEW_EB_ARM11MP bool Support ARM11MPCore tile depends on MACH_REALVIEW_EB - select CPU_V6 + select CPU_V6K select ARCH_HAS_BARRIERS if SMP help Enable support for the ARM11MPCore tile on the Realview platform. @@ -33,7 +33,7 @@ config REALVIEW_EB_ARM11MP_REVB config MACH_REALVIEW_PB11MP bool Support RealView/PB11MPCore platform - select CPU_V6 + select CPU_V6K select ARM_GIC select HAVE_PATA_PLATFORM select ARCH_HAS_BARRIERS if SMP @@ -42,6 +42,7 @@ config MACH_REALVIEW_PB11MP PB11MPCore is a platform with an on-board ARM11MPCore and has support for PCI-E and Compact Flash. +# ARMv6 CPU without K extensions, but does have the new exclusive ops config MACH_REALVIEW_PB1176 bool Support RealView/PB1176 platform select CPU_V6 -- 1.6.2.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
[PATCH 08/14] ARM: v6k: select cmpxchg code sequences according to V6 variants
If CONFIG_CPU_V6 is enabled, we must avoid the byte/halfword/doubleword
exclusive operations, which aren't implemented before V6K. Use the
generic versions (or omit them) instead.
If CONFIG_CPU_V6 is not set, but CONFIG_CPU_32v6K is enabled, we have
the K extnesions, so use these new instructions.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/include/asm/system.h | 17 +
1 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/arch/arm/include/asm/system.h b/arch/arm/include/asm/system.h
index 97f6d60..9a87823 100644
--- a/arch/arm/include/asm/system.h
+++ b/arch/arm/include/asm/system.h
@@ -347,6 +347,7 @@ void cpu_idle_wait(void);
#include asm-generic/cmpxchg-local.h
#if __LINUX_ARM_ARCH__ 6
+/* min ARCH ARMv6 */
#ifdef CONFIG_SMP
#error SMP is not supported on this platform
@@ -365,7 +366,7 @@ void cpu_idle_wait(void);
#include asm-generic/cmpxchg.h
#endif
-#else /* __LINUX_ARM_ARCH__ = 6 */
+#else /* min ARCH = ARMv6 */
extern void __bad_cmpxchg(volatile void *ptr, int size);
@@ -379,7 +380,7 @@ static inline unsigned long __cmpxchg(volatile void *ptr,
unsigned long old,
unsigned long oldval, res;
switch (size) {
-#ifdef CONFIG_CPU_32v6K
+#ifndef CONFIG_CPU_V6 /* min ARCH = ARMv6K */
case 1:
do {
asm volatile(@ __cmpxchg1\n
@@ -404,7 +405,7 @@ static inline unsigned long __cmpxchg(volatile void *ptr,
unsigned long old,
: memory, cc);
} while (res);
break;
-#endif /* CONFIG_CPU_32v6K */
+#endif
case 4:
do {
asm volatile(@ __cmpxchg4\n
@@ -450,12 +451,12 @@ static inline unsigned long __cmpxchg_local(volatile void
*ptr,
unsigned long ret;
switch (size) {
-#ifndef CONFIG_CPU_32v6K
+#ifdef CONFIG_CPU_V6 /* min ARCH == ARMv6 */
case 1:
case 2:
ret = __cmpxchg_local_generic(ptr, old, new, size);
break;
-#endif /* !CONFIG_CPU_32v6K */
+#endif
default:
ret = __cmpxchg(ptr, old, new, size);
}
@@ -469,7 +470,7 @@ static inline unsigned long __cmpxchg_local(volatile void
*ptr,
(unsigned long)(n), \
sizeof(*(ptr
-#ifdef CONFIG_CPU_32v6K
+#ifndef CONFIG_CPU_V6 /* min ARCH = ARMv6K */
/*
* Note : ARMv7-M (currently unsupported by Linux) does not support
@@ -524,11 +525,11 @@ static inline unsigned long long __cmpxchg64_mb(volatile
void *ptr,
(unsigned long long)(o), \
(unsigned long long)(n)))
-#else /* !CONFIG_CPU_32v6K */
+#else /* min ARCH = ARMv6 */
#define cmpxchg64_local(ptr, o, n) __cmpxchg64_local_generic((ptr), (o), (n))
-#endif /* CONFIG_CPU_32v6K */
+#endif
#endif /* __LINUX_ARM_ARCH__ = 6 */
--
1.6.2.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
[PATCH 02/14] ARM: bitops: switch set/clear/change bitops to use ldrex/strex
Switch the set/clear/change bitops to use the word-based exclusive operations, which are only present in a wider range of ARM architectures than the byte-based exclusive operations. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- arch/arm/include/asm/bitops.h | 60 +++-- arch/arm/kernel/armksyms.c| 18 arch/arm/lib/bitops.h | 38 + arch/arm/lib/changebit.S | 10 +- arch/arm/lib/clearbit.S | 11 +-- arch/arm/lib/setbit.S | 11 +-- arch/arm/lib/testchangebit.S |9 ++ arch/arm/lib/testclearbit.S |9 ++ arch/arm/lib/testsetbit.S |9 ++ 9 files changed, 63 insertions(+), 112 deletions(-) diff --git a/arch/arm/include/asm/bitops.h b/arch/arm/include/asm/bitops.h index 7b1bb2b..af54ed1 100644 --- a/arch/arm/include/asm/bitops.h +++ b/arch/arm/include/asm/bitops.h @@ -149,14 +149,18 @@ atomic_test_and_change_bit(unsigned int bit, volatile unsigned long *p) */ /* + * Native endian assembly bitops. nr = 0 - word 0 bit 0. + */ +extern void _set_bit(int nr, volatile unsigned long * p); +extern void _clear_bit(int nr, volatile unsigned long * p); +extern void _change_bit(int nr, volatile unsigned long * p); +extern int _test_and_set_bit(int nr, volatile unsigned long * p); +extern int _test_and_clear_bit(int nr, volatile unsigned long * p); +extern int _test_and_change_bit(int nr, volatile unsigned long * p); + +/* * Little endian assembly bitops. nr = 0 - byte 0 bit 0. */ -extern void _set_bit_le(int nr, volatile unsigned long * p); -extern void _clear_bit_le(int nr, volatile unsigned long * p); -extern void _change_bit_le(int nr, volatile unsigned long * p); -extern int _test_and_set_bit_le(int nr, volatile unsigned long * p); -extern int _test_and_clear_bit_le(int nr, volatile unsigned long * p); -extern int _test_and_change_bit_le(int nr, volatile unsigned long * p); extern int _find_first_zero_bit_le(const void * p, unsigned size); extern int _find_next_zero_bit_le(const void * p, int size, int offset); extern int _find_first_bit_le(const unsigned long *p, unsigned size); @@ -165,12 +169,6 @@ extern int _find_next_bit_le(const unsigned long *p, int size, int offset); /* * Big endian assembly bitops. nr = 0 - byte 3 bit 0. */ -extern void _set_bit_be(int nr, volatile unsigned long * p); -extern void _clear_bit_be(int nr, volatile unsigned long * p); -extern void _change_bit_be(int nr, volatile unsigned long * p); -extern int _test_and_set_bit_be(int nr, volatile unsigned long * p); -extern int _test_and_clear_bit_be(int nr, volatile unsigned long * p); -extern int _test_and_change_bit_be(int nr, volatile unsigned long * p); extern int _find_first_zero_bit_be(const void * p, unsigned size); extern int _find_next_zero_bit_be(const void * p, int size, int offset); extern int _find_first_bit_be(const unsigned long *p, unsigned size); @@ -180,33 +178,26 @@ extern int _find_next_bit_be(const unsigned long *p, int size, int offset); /* * The __* form of bitops are non-atomic and may be reordered. */ -#defineATOMIC_BITOP_LE(name,nr,p) \ - (__builtin_constant_p(nr) ? \ -atomic_##name(nr, p) : \ -_##name##_le(nr,p)) - -#defineATOMIC_BITOP_BE(name,nr,p) \ - (__builtin_constant_p(nr) ? \ -atomic_##name(nr, p) : \ -_##name##_be(nr,p)) +#define ATOMIC_BITOP(name,nr,p)\ + (__builtin_constant_p(nr) ? atomic_##name(nr, p) : _##name(nr,p)) #else -#define ATOMIC_BITOP_LE(name,nr,p) _##name##_le(nr,p) -#define ATOMIC_BITOP_BE(name,nr,p) _##name##_be(nr,p) +#define ATOMIC_BITOP(name,nr,p)_##name(nr,p) #endif -#define NONATOMIC_BITOP(name,nr,p) \ - (nonatomic_##name(nr, p)) +/* + * Native endian atomic definitions. + */ +#define set_bit(nr,p) ATOMIC_BITOP(set_bit,nr,p) +#define clear_bit(nr,p)ATOMIC_BITOP(clear_bit,nr,p) +#define change_bit(nr,p) ATOMIC_BITOP(change_bit,nr,p) +#define test_and_set_bit(nr,p) ATOMIC_BITOP(test_and_set_bit,nr,p) +#define test_and_clear_bit(nr,p) ATOMIC_BITOP(test_and_clear_bit,nr,p) +#define test_and_change_bit(nr,p) ATOMIC_BITOP(test_and_change_bit,nr,p) #ifndef __ARMEB__ /* * These are the little endian, atomic definitions. */ -#define set_bit(nr,p) ATOMIC_BITOP_LE(set_bit,nr,p) -#define clear_bit(nr,p)ATOMIC_BITOP_LE(clear_bit,nr,p) -#define change_bit(nr,p) ATOMIC_BITOP_LE(change_bit,nr,p) -#define test_and_set_bit(nr,p) ATOMIC_BITOP_LE(test_and_set_bit,nr,p) -#define test_and_clear_bit(nr,p) ATOMIC_BITOP_LE(test_and_clear_bit,nr,p) -#define test_and_change_bit(nr,p) ATOMIC_BITOP_LE(test_and_change_bit,nr,p) #define
[PATCH 09/14] ARM: v6k: select generic atomic64 code according to V6 variants
If CONFIG_CPU_V6 is enabled, avoid using the double-word exclusive instructions in the kernel's atomic implementations as these are not supported. Fall back to the generic spinlock code instead. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- arch/arm/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 95ba92f..283d7b9 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -7,7 +7,7 @@ config ARM select HAVE_MEMBLOCK select RTC_LIB select SYS_SUPPORTS_APM_EMULATION - select GENERIC_ATOMIC64 if (!CPU_32v6K || !AEABI) + select GENERIC_ATOMIC64 if (CPU_V6 || !CPU_32v6K || !AEABI) select HAVE_OPROFILE if (HAVE_PERF_EVENTS) select HAVE_ARCH_KGDB select HAVE_KPROBES if (!XIP_KERNEL !THUMB2_KERNEL) -- 1.6.2.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
[PATCH 11/14] ARM: v6k: use CPU domain feature if we include support for arch ARMv6K
Rather than turning off CPU domain switching when the build architecture includes ARMv6K, thereby causing problems for ARMv6-supporting kernels, turn it on when it's required to support a CPU architecture. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- arch/arm/mm/Kconfig |7 +-- 1 files changed, 5 insertions(+), 2 deletions(-) diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig index 22a3f4a..29215f5 100644 --- a/arch/arm/mm/Kconfig +++ b/arch/arm/mm/Kconfig @@ -435,25 +435,30 @@ config CPU_32v3 bool select TLS_REG_EMUL if SMP || !MMU select NEEDS_SYSCALL_FOR_CMPXCHG if SMP + select CPU_USE_DOMAINS if MMU config CPU_32v4 bool select TLS_REG_EMUL if SMP || !MMU select NEEDS_SYSCALL_FOR_CMPXCHG if SMP + select CPU_USE_DOMAINS if MMU config CPU_32v4T bool select TLS_REG_EMUL if SMP || !MMU select NEEDS_SYSCALL_FOR_CMPXCHG if SMP + select CPU_USE_DOMAINS if MMU config CPU_32v5 bool select TLS_REG_EMUL if SMP || !MMU select NEEDS_SYSCALL_FOR_CMPXCHG if SMP + select CPU_USE_DOMAINS if MMU config CPU_32v6 bool select TLS_REG_EMUL if !CPU_32v6K !MMU + select CPU_USE_DOMAINS if CPU_V6 MMU config CPU_32v6K bool Support ARM V6K processor extensions if !SMP @@ -620,8 +625,6 @@ config CPU_CP15_MPU config CPU_USE_DOMAINS bool - depends on MMU - default y if !CPU_32v6K help This option enables or disables the use of domain switching via the set_fs() function. -- 1.6.2.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
[PATCH 12/14] ARM: v6k: do not disable CPU_32v6K based on platform selection
CPU_32v6K controls whether we use the ARMv6K extension instructions in the kernel, and in some places whether we use SMP-safe code sequences (eg, bitops.) MX3 prevents the selection of this option to ensure that it is not enabled for their CPU, which is ARMv6 only. Now that we've split the CPU_V6 option, V6K support won't be offered for MX3 anymore. OMAP prevents the selection of this option in an attempt to produce a kernel which runs on architectures from ARMv6 to ARMv7 MPCore. We now achieve this in a different way (see the previous patches). As such, we no longer need to offer this as a configuration option to the user. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- arch/arm/mm/Kconfig | 14 +++--- 1 files changed, 3 insertions(+), 11 deletions(-) diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig index 29215f5..ca1238b 100644 --- a/arch/arm/mm/Kconfig +++ b/arch/arm/mm/Kconfig @@ -405,7 +405,7 @@ config CPU_V6 config CPU_V6K bool Support ARM V6K processor if ARCH_INTEGRATOR || MACH_REALVIEW_EB || MACH_REALVIEW_PBX select CPU_32v6 - select CPU_32v6K if !ARCH_OMAP2 + select CPU_32v6K select CPU_ABRT_EV6 select CPU_PABRT_V6 select CPU_CACHE_V6 @@ -418,7 +418,7 @@ config CPU_V6K # ARMv7 config CPU_V7 bool Support ARM V7 processor if ARCH_INTEGRATOR || MACH_REALVIEW_EB || MACH_REALVIEW_PBX - select CPU_32v6K if !ARCH_OMAP2 + select CPU_32v6K select CPU_32v7 select CPU_ABRT_EV7 select CPU_PABRT_V7 @@ -461,15 +461,7 @@ config CPU_32v6 select CPU_USE_DOMAINS if CPU_V6 MMU config CPU_32v6K - bool Support ARM V6K processor extensions if !SMP - depends on CPU_V6 || CPU_V6K || CPU_V7 - default y if SMP !(ARCH_MX3 || ARCH_OMAP2) - help - Say Y here if your ARMv6 processor supports the 'K' extension. - This enables the kernel to use some instructions not present - on previous processors, and as such a kernel build with this - enabled will not boot on processors with do not support these - instructions. + bool config CPU_32v7 bool -- 1.6.2.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
[PATCH 06/14] ARM: v6k: Dove platforms use V6K architecture CPUs
Make Dove platforms select the new V6K CPU option. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- arch/arm/mach-dove/Kconfig |4 +++- arch/arm/mm/Kconfig|4 ++-- 2 files changed, 5 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-dove/Kconfig b/arch/arm/mach-dove/Kconfig index a4ed390..822439a 100644 --- a/arch/arm/mach-dove/Kconfig +++ b/arch/arm/mach-dove/Kconfig @@ -5,12 +5,14 @@ menu Marvell Dove Implementations config MACH_DOVE_DB bool Marvell DB-MV88AP510 Development Board select I2C_BOARDINFO + select CPU_V6K help Say 'Y' here if you want your kernel to support the Marvell DB-MV88AP510 Development Board. - config MACH_CM_A510 +config MACH_CM_A510 bool CompuLab CM-A510 Board + select CPU_V6K help Say 'Y' here if you want your kernel to support the CompuLab CM-A510 Board. diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig index 559e933..22a3f4a 100644 --- a/arch/arm/mm/Kconfig +++ b/arch/arm/mm/Kconfig @@ -390,7 +390,7 @@ config CPU_PJ4 # ARMv6 config CPU_V6 - bool Support ARM V6 processor if ARCH_INTEGRATOR || MACH_REALVIEW_EB || MACH_REALVIEW_PBX || ARCH_DOVE + bool Support ARM V6 processor if ARCH_INTEGRATOR || MACH_REALVIEW_EB || MACH_REALVIEW_PBX select CPU_32v6 select CPU_ABRT_EV6 select CPU_PABRT_V6 @@ -403,7 +403,7 @@ config CPU_V6 # ARMv6k config CPU_V6K - bool Support ARM V6K processor if ARCH_INTEGRATOR || MACH_REALVIEW_EB || MACH_REALVIEW_PBX || ARCH_DOVE + bool Support ARM V6K processor if ARCH_INTEGRATOR || MACH_REALVIEW_EB || MACH_REALVIEW_PBX select CPU_32v6 select CPU_32v6K if !ARCH_OMAP2 select CPU_ABRT_EV6 -- 1.6.2.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
[PATCH 14/14] ARM: v6k: only allow SMP if we have v6k or v7 CPU
SMP extensions are only supported on ARMv6k or ARMv7 architectures, so only offer the option if we're building for such an architecture. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- arch/arm/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 283d7b9..ba304a3 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1250,6 +1250,7 @@ source kernel/time/Kconfig config SMP bool Symmetric Multi-Processing (EXPERIMENTAL) depends on EXPERIMENTAL + 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 || \ -- 1.6.2.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
[PATCH 10/14] ARM: v6k: select TLS register code according to V6 variants
If CONFIG_CPU_V6 is enabled, we may or may not have the TLS register. Use the conditional code which copes with this variability. Otherwise, if CONFIG_CPU_32v6K is set, we know we have the TLS register on all supported CPUs, so use it unconditionally. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- arch/arm/include/asm/tls.h | 11 +-- 1 files changed, 5 insertions(+), 6 deletions(-) diff --git a/arch/arm/include/asm/tls.h b/arch/arm/include/asm/tls.h index e71d6ff..60843eb 100644 --- a/arch/arm/include/asm/tls.h +++ b/arch/arm/include/asm/tls.h @@ -28,15 +28,14 @@ #define tls_emu1 #define has_tls_reg1 #define set_tlsset_tls_none -#elif __LINUX_ARM_ARCH__ = 7 || \ - (__LINUX_ARM_ARCH__ == 6 defined(CONFIG_CPU_32v6K)) -#define tls_emu0 -#define has_tls_reg1 -#define set_tlsset_tls_v6k -#elif __LINUX_ARM_ARCH__ == 6 +#elif defined(CONFIG_CPU_V6) #define tls_emu0 #define has_tls_reg(elf_hwcap HWCAP_TLS) #define set_tlsset_tls_v6 +#elif defined(CONFIG_CPU_32v6K) +#define tls_emu0 +#define has_tls_reg1 +#define set_tlsset_tls_v6k #else #define tls_emu0 #define has_tls_reg0 -- 1.6.2.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
[PATCH 13/14] ARM: v6k: allow swp emulation again when ARMv7 is enabled
Now that we build a v6+v6k+v7 kernel with -march=armv6k for everything, we don't need to disable swp emulation to work around the build problem with OMAP. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- arch/arm/mm/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig index ca1238b..843bc8c 100644 --- a/arch/arm/mm/Kconfig +++ b/arch/arm/mm/Kconfig @@ -652,7 +652,7 @@ config ARM_THUMBEE config SWP_EMULATE bool Emulate SWP/SWPB instructions - depends on CPU_V7 !CPU_V6 + depends on CPU_V7 select HAVE_PROC_CPU if PROC_FS default y if SMP help -- 1.6.2.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
[PATCH 07/14] ARM: v6k: select clear exclusive code seqences according to V6 variants
If CONFIG_CPU_V6 is enabled, then the kernel must support ARMv6 CPUs
which don't have the V6K extensions implemented. Always use the
dummy store-exclusive method to ensure that the exclusive monitors are
cleared.
If CONFIG_CPU_V6 is not set, but CONFIG_CPU_32v6K is enabled, then we
have the K extensions available on all CPUs we're building support for,
so we can use the new clear-exclusive instruction.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/kernel/entry-header.S | 14 +++---
arch/arm/mm/abort-ev6.S|6 +++---
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/arm/kernel/entry-header.S b/arch/arm/kernel/entry-header.S
index ae94649..051166c 100644
--- a/arch/arm/kernel/entry-header.S
+++ b/arch/arm/kernel/entry-header.S
@@ -76,13 +76,13 @@
#ifndef CONFIG_THUMB2_KERNEL
.macro svc_exit, rpsr
msr spsr_cxsf, \rpsr
-#if defined(CONFIG_CPU_32v6K)
- clrex @ clear the exclusive monitor
- ldmia sp, {r0 - pc}^ @ load r0 - pc, cpsr
-#elif defined (CONFIG_CPU_V6)
+#if defined(CONFIG_CPU_V6)
ldr r0, [sp]
strex r1, r2, [sp]@ clear the exclusive monitor
ldmib sp, {r1 - pc}^ @ load r1 - pc, cpsr
+#elif defined(CONFIG_CPU_32v6K)
+ clrex @ clear the exclusive monitor
+ ldmia sp, {r0 - pc}^ @ load r0 - pc, cpsr
#else
ldmia sp, {r0 - pc}^ @ load r0 - pc, cpsr
#endif
@@ -92,10 +92,10 @@
ldr r1, [sp, #\offset + S_PSR] @ get calling cpsr
ldr lr, [sp, #\offset + S_PC]! @ get pc
msr spsr_cxsf, r1 @ save in spsr_svc
-#if defined(CONFIG_CPU_32v6K)
- clrex @ clear the exclusive monitor
-#elif defined (CONFIG_CPU_V6)
+#if defined(CONFIG_CPU_V6)
strex r1, r2, [sp]@ clear the exclusive monitor
+#elif defined(CONFIG_CPU_32v6K)
+ clrex @ clear the exclusive monitor
#endif
.if \fast
ldmdb sp, {r1 - lr}^ @ get calling r1 - lr
diff --git a/arch/arm/mm/abort-ev6.S b/arch/arm/mm/abort-ev6.S
index f332df7..1478aa5 100644
--- a/arch/arm/mm/abort-ev6.S
+++ b/arch/arm/mm/abort-ev6.S
@@ -20,11 +20,11 @@
*/
.align 5
ENTRY(v6_early_abort)
-#ifdef CONFIG_CPU_32v6K
- clrex
-#else
+#ifdef CONFIG_CPU_V6
sub r1, sp, #4 @ Get unused stack location
strex r0, r1, [r1]@ Clear the exclusive monitor
+#elif defined(CONFIG_CPU_32v6K)
+ clrex
#endif
mrc p15, 0, r1, c5, c0, 0 @ get FSR
mrc p15, 0, r0, c6, c0, 0 @ get FAR
--
1.6.2.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
[PATCH 04/14] ARM: v6k: introduce CPU_V6K option
Introduce a CPU_V6K configuration option for platforms to select if they
have a V6K CPU core. This allows us to identify whether we need to
support ARMv6 CPUs without the V6K SMP extensions at build time.
Currently CPU_V6K is just an alias for CPU_V6, and all places which
reference CPU_V6 are replaced by (CPU_V6 || CPU_V6K).
Select CPU_V6K from platforms which are known to be V6K-only.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/Kconfig | 10
arch/arm/Makefile |1 +
arch/arm/boot/compressed/head.S |2 +-
arch/arm/boot/compressed/misc.c |2 +-
arch/arm/include/asm/cacheflush.h |5 ++-
arch/arm/include/asm/proc-fns.h |2 +-
arch/arm/kernel/debug.S |2 +-
arch/arm/kernel/perf_event_v6.c |4 +-
arch/arm/mm/Kconfig | 47 +++-
arch/arm/mm/Makefile |1 +
arch/arm/mm/mmap.c|2 +-
11 files changed, 47 insertions(+), 31 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 5cff165..95ba92f 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -24,7 +24,7 @@ config ARM
select HAVE_PERF_EVENTS
select PERF_USE_VMALLOC
select HAVE_REGS_AND_STACK_ACCESS_API
- select HAVE_HW_BREAKPOINT if (PERF_EVENTS (CPU_V6 || CPU_V7))
+ select HAVE_HW_BREAKPOINT if (PERF_EVENTS (CPU_V6 || CPU_V6K ||
CPU_V7))
select HAVE_C_RECORDMCOUNT
select HAVE_GENERIC_HARDIRQS
select HAVE_SPARSE_IRQ
@@ -1048,7 +1048,7 @@ config XSCALE_PMU
default y
config CPU_HAS_PMU
- depends on (CPU_V6 || CPU_V7 || XSCALE_PMU) \
+ depends on (CPU_V6 || CPU_V6K || CPU_V7 || XSCALE_PMU) \
(!ARCH_OMAP3 || OMAP3_EMU)
default y
bool
@@ -1064,7 +1064,7 @@ endif
config ARM_ERRATA_411920
bool ARM errata: Invalidation of the Instruction Cache operation can
fail
- depends on CPU_V6
+ depends on CPU_V6 || CPU_V6K
help
Invalidation of the Instruction Cache operation can
fail. This erratum is present in 1136 (before r1p4), 1156 and 1176.
@@ -1361,7 +1361,7 @@ config HZ
config THUMB2_KERNEL
bool Compile the kernel in Thumb-2 mode (EXPERIMENTAL)
- depends on CPU_V7 !CPU_V6 EXPERIMENTAL
+ depends on CPU_V7 !CPU_V6 !CPU_V6K EXPERIMENTAL
select AEABI
select ARM_ASM_UNIFIED
help
@@ -1852,7 +1852,7 @@ config FPE_FASTFPE
config VFP
bool VFP-format floating point maths
- depends on CPU_V6 || CPU_ARM926T || CPU_V7 || CPU_FEROCEON
+ depends on CPU_V6 || CPU_V6K || CPU_ARM926T || CPU_V7 || CPU_FEROCEON
help
Say Y to include VFP support code in the kernel. This is needed
if your hardware includes a VFP unit.
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index c22c1ad..9c43052 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -89,6 +89,7 @@ tune-$(CONFIG_CPU_XSCALE) :=$(call
cc-option,-mtune=xscale,-mtune=strongarm110)
tune-$(CONFIG_CPU_XSC3):=$(call
cc-option,-mtune=xscale,-mtune=strongarm110) -Wa,-mcpu=xscale
tune-$(CONFIG_CPU_FEROCEON):=$(call
cc-option,-mtune=marvell-f,-mtune=xscale)
tune-$(CONFIG_CPU_V6) :=$(call
cc-option,-mtune=arm1136j-s,-mtune=strongarm)
+tune-$(CONFIG_CPU_V6K) :=$(call
cc-option,-mtune=arm1136j-s,-mtune=strongarm)
ifeq ($(CONFIG_AEABI),y)
CFLAGS_ABI :=-mabi=aapcs-linux -mno-thumb-interwork
diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index 7193884..91f20f0 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -21,7 +21,7 @@
#if defined(CONFIG_DEBUG_ICEDCC)
-#ifdef CONFIG_CPU_V6
+#if defined(CONFIG_CPU_V6) || defined(CONFIG_CPU_V6K)
.macro loadsp, rb, tmp
.endm
.macro writeb, ch, rb
diff --git a/arch/arm/boot/compressed/misc.c b/arch/arm/boot/compressed/misc.c
index e653a6d..4657e87 100644
--- a/arch/arm/boot/compressed/misc.c
+++ b/arch/arm/boot/compressed/misc.c
@@ -36,7 +36,7 @@ extern void error(char *x);
#ifdef CONFIG_DEBUG_ICEDCC
-#ifdef CONFIG_CPU_V6
+#if defined(CONFIG_CPU_V6) || defined(CONFIG_CPU_V6K)
static void icedcc_putc(int ch)
{
diff --git a/arch/arm/include/asm/cacheflush.h
b/arch/arm/include/asm/cacheflush.h
index 3acd8fa..7d0614f 100644
--- a/arch/arm/include/asm/cacheflush.h
+++ b/arch/arm/include/asm/cacheflush.h
@@ -116,7 +116,7 @@
# define MULTI_CACHE 1
#endif
-#if defined(CONFIG_CPU_V6)
+#if defined(CONFIG_CPU_V6) || defined(CONFIG_CPU_V6K)
//# ifdef _CACHE
# define MULTI_CACHE 1
//# else
@@ -316,7 +316,8 @@ extern void copy_to_user_page(struct vm_area_struct *,
struct page *,
* Optimized __flush_icache_all for the common cases. Note that UP ARMv7
* will fall through to use __flush_icache_all_generic.
*/
-#if (defined(CONFIG_CPU_V7)
How to flash NAND over debug serial console
Hi, Is there a way I can flash NAND partitions (xloader, uboot, kernel and rootfilesystem) directly using the debug serial port, rather than using a microSD card, for batch programming of beagleboard devices? Elvis Dowson -- 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: Open issues after 2.6.38 merge window
On Mon, 17 Jan 2011, Aaro Koskinen wrote: On Mon, 17 Jan 2011, Santosh Shilimkar wrote: Amstrad E3 fails during the boot. Bisection points to: commit 211baa7016894c02fc18693e21ca479cd08ac0c0 Author: Russell King rmk+ker...@arm.linux.org.uk Date: Tue Jan 11 16:23:04 2011 + ARM: sched_clock: allow init_sched_clock() to be called early The board does not have sched_clock(), although HAVE_SCHED_CLOCK is defined for all OMAP. I guess above is sorted out by the attached patch from Paul. I don't see how it could help? Amstrad E3 is OMAP 15xx. OMAP15xx uses the MPU timer for its clocksource, since OMAP15xx doesn't have GPTIMERs or the 32k sync timer, and the MPU timer code in mach-omap1/time.c wasn't updated for sched_clock() support. Adding an init_fixed_sched_clock() into omap_init_clocksource() should fix the boot on OMAP15xx/7xx. - 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: Open issues after 2.6.38 merge window
On Mon, Jan 17, 2011 at 01:31:47PM -0700, Paul Walmsley wrote: On Mon, 17 Jan 2011, Aaro Koskinen wrote: On Mon, 17 Jan 2011, Santosh Shilimkar wrote: Amstrad E3 fails during the boot. Bisection points to: commit 211baa7016894c02fc18693e21ca479cd08ac0c0 Author: Russell King rmk+ker...@arm.linux.org.uk Date: Tue Jan 11 16:23:04 2011 + ARM: sched_clock: allow init_sched_clock() to be called early The board does not have sched_clock(), although HAVE_SCHED_CLOCK is defined for all OMAP. I guess above is sorted out by the attached patch from Paul. I don't see how it could help? Amstrad E3 is OMAP 15xx. OMAP15xx uses the MPU timer for its clocksource, since OMAP15xx doesn't have GPTIMERs or the 32k sync timer, and the MPU timer code in mach-omap1/time.c wasn't updated for sched_clock() support. Adding an init_fixed_sched_clock() into omap_init_clocksource() should fix the boot on OMAP15xx/7xx. No, it needs fixing properly. There's no reason the gpt clocksource can't be used for sched_clock. We just need to switch to the variable rate implementation rather than the fixed rate if we include OMAP15xx/7xx support. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: -- 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: Open issues after 2.6.38 merge window
On Mon, 17 Jan 2011, Russell King wrote: On Mon, Jan 17, 2011 at 01:31:47PM -0700, Paul Walmsley wrote: OMAP15xx uses the MPU timer for its clocksource, since OMAP15xx doesn't have GPTIMERs or the 32k sync timer, and the MPU timer code in mach-omap1/time.c wasn't updated for sched_clock() support. Adding an init_fixed_sched_clock() into omap_init_clocksource() should fix the boot on OMAP15xx/7xx. No, it needs fixing properly. There's no reason the gpt clocksource can't be used for sched_clock. There's a very good reason why it can't on OMAP15xx/7xx. GPTIMER/DMTIMER IP blocks are only present on OMAP1610 and later[1]. Nor is a SYNCTIMER_32K IP block present on OMAP15xx/7xx[2]. That said, the clocksource code in the OMAP tree could definitely use some cleanup. The SYNCTIMER_32K/counter_32k clocksource should be registered from the plat-omap/counter_32k.c. And your point about the compile-time negative dependencies is also a good one, now that omap1_defconfig exists. - Paul 1. Current mainline source code for arch/arm/plat-omap/dmtimer.c, line 168: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/arm/plat-omap/dmtimer.c;h=1d706cf63ca0e697521d38ab814d9889a1b70435;hb=refs/heads/master#l168 2. Current mainline source code for arch/arm/plat-omap/counter_32k.c, line 39: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/arm/plat-omap/counter_32k.c;h=ea4644021fb9c0867c2e4ca4bd4bcb118e863f80;hb=refs/heads/master#l39 3. ibid. -- 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: Open issues after 2.6.38 merge window
On Mon, Jan 17, 2011 at 02:00:17PM -0700, Paul Walmsley wrote:
On Mon, 17 Jan 2011, Russell King wrote:
On Mon, Jan 17, 2011 at 01:31:47PM -0700, Paul Walmsley wrote:
OMAP15xx uses the MPU timer for its clocksource, since OMAP15xx doesn't
have GPTIMERs or the 32k sync timer, and the MPU timer code in
mach-omap1/time.c wasn't updated for sched_clock() support.
Adding an init_fixed_sched_clock() into omap_init_clocksource() should
fix the boot on OMAP15xx/7xx.
No, it needs fixing properly. There's no reason the gpt clocksource
can't be used for sched_clock.
There's a very good reason why it can't on OMAP15xx/7xx. GPTIMER/DMTIMER
IP blocks are only present on OMAP1610 and later[1]. Nor is a
SYNCTIMER_32K IP block present on OMAP15xx/7xx[2].
Yes I realise that. That doesn't negate what I said though. Let me
show you how to do it:
static DEFINE_CLOCK_DATA(cd);
static inline u32 32k_read_cycles(void)
{
...
}
static inline u32 gpt_read_cycles(void)
{
...
}
#if defined(GPTIMER) defined(32KTIMER)
static u32 (*omap_read_cycles)(void);
#elif defined(32KTIMER)
#define SC_MULT 40u
#define SC_SHIFT17
#define omap_read_cycles32k_read_cycles
#else
#define SC_MULT gpt_value_if_fixed
#define SC_SHIFTgpt_value_if_fixed
#define omap_read_cyclesgpt_read_cycles
#endif
unsigned long long notrace sched_clock(void)
{
u32 cyc = omap_read_cycles();
#ifdef SC_MULT
return cyc_to_fixed_sched_clock(cd, cyc, (u32)~0, SC_MULT, SC_SHIFT);
#else
return cyc_to_sched_clock(cd, cyc, (u32)~0);
#endif
}
static void notrace omap_update_sched_clock(void)
{
u32 cyc = omap_read_cycles();
update_sched_clock(cd, cyc, (u32)~0);
}
void omap_init_sched_clock(int gpt)
{
unsigned long rate;
#ifndef omap_read_cycles
omap_read_cycles = gpt ? gpt_read_cycles : 32k_read_cycles;
#endif
if (gpt)
rate = gpt_rate;
else
rate = 32768;
#ifdef SC_MULT
init_fixed_sched_clock(cd, omap_update_sched_clock, 32, rate
SC_MULT, SC_SHIFT);
#else
init_sched_clock(cd, omap_update_sched_clock, 32, rate);
#endif
}
Both a GPT _and_ 32K sched_clock implementation together, selectable
at runtime or build time depending on what is selected. I'll give you
that it isn't nice code, but it does what's required.
--
Russell King
Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
--
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] omap2-beagle: Depend upon CONFIG_GPIO_TWL4030
Some very basic setup (i.e. MMC) is done in the beagleboard's setup callback for the TWL4030's gpio driver, causing a kernel without this support to fail to find its root filesystem. I can't imagine why one would want to build a kernel for this board without this driver, so I think it's worthwhile to explicitly depend on it. Signed-Off-By: Ben Gamari bgamari.f...@gmail.com --- arch/arm/mach-omap2/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index ab784bf..74173f1 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -120,6 +120,7 @@ config MACH_OMAP_2430SDP config MACH_OMAP3_BEAGLE bool OMAP3 BEAGLE board depends on ARCH_OMAP3 + depends on GPIO_TWL4030 default y select OMAP_PACKAGE_CBB -- 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 11/14] ARM: v6k: use CPU domain feature if we include support for arch ARMv6K
On Mon, 17 Jan 2011, Russell King - ARM Linux wrote: Rather than turning off CPU domain switching when the build architecture includes ARMv6K, thereby causing problems for ARMv6-supporting kernels, turn it on when it's required to support a CPU architecture. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk Acked-by: Nicolas Pitre nicolas.pi...@linaro.org --- arch/arm/mm/Kconfig |7 +-- 1 files changed, 5 insertions(+), 2 deletions(-) diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig index 22a3f4a..29215f5 100644 --- a/arch/arm/mm/Kconfig +++ b/arch/arm/mm/Kconfig @@ -435,25 +435,30 @@ config CPU_32v3 bool select TLS_REG_EMUL if SMP || !MMU select NEEDS_SYSCALL_FOR_CMPXCHG if SMP + select CPU_USE_DOMAINS if MMU config CPU_32v4 bool select TLS_REG_EMUL if SMP || !MMU select NEEDS_SYSCALL_FOR_CMPXCHG if SMP + select CPU_USE_DOMAINS if MMU config CPU_32v4T bool select TLS_REG_EMUL if SMP || !MMU select NEEDS_SYSCALL_FOR_CMPXCHG if SMP + select CPU_USE_DOMAINS if MMU config CPU_32v5 bool select TLS_REG_EMUL if SMP || !MMU select NEEDS_SYSCALL_FOR_CMPXCHG if SMP + select CPU_USE_DOMAINS if MMU config CPU_32v6 bool select TLS_REG_EMUL if !CPU_32v6K !MMU + select CPU_USE_DOMAINS if CPU_V6 MMU config CPU_32v6K bool Support ARM V6K processor extensions if !SMP @@ -620,8 +625,6 @@ config CPU_CP15_MPU config CPU_USE_DOMAINS bool - depends on MMU - default y if !CPU_32v6K help This option enables or disables the use of domain switching via the set_fs() function. -- 1.6.2.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 00/14] Fix issues with ARMv6+v6k+v7 kernels
* Russell King - ARM Linux li...@arm.linux.org.uk [110117 11:20]: This patch series reworks the ARMv6/ARMv6K support options, code selection, and bit operations such that it's possible to safely build a kernel which supports ARMv6, ARMv6K, ARMv7 and ARMv7 SMP in one image. Currently, we use CPU_V6 for both ARMv6 and ARMv6K, setting CPU_32v6K if we have the K extensions. CPU_32v6K directly controlled whether we should include the ARMv6K instructions (clrex, load/store exclusive byte, half-word, double). As the bitops code uses the load/store exclusive byte operations, unsetting CPU_32v6K results in these falling back to their non-SMP local-irq-disabling variants. These are only safe in uniprocessor environments. So, the first two patches convert the bitops to use the ARMv6 load/store exclusive word operations - and ensuring correctness by ensuring that the pointer passed in is word-aligned. We then introduce a new CPU_V6K which indicates that we're including an ARMv6K CPU in the build, which frees up CPU_V6 to mean that we're including an ARMv6 non-K CPU. We can then use CPU_V6 to ensure that the non-v6K code paths which are still SMP safe are selected. Without this patch set, such a kernel will be unsafe when run on SMP platforms as it omits necessary SMP code to ensure that bit operations are safe. Amazing, based on a quick test this series boots just fine on non-v6K omap2420 using omap2plus_defconfig :) Tony -- 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 10/14] ARM: v6k: select TLS register code according to V6 variants
On Mon, 17 Jan 2011, Russell King - ARM Linux wrote: If CONFIG_CPU_V6 is enabled, we may or may not have the TLS register. Use the conditional code which copes with this variability. Otherwise, if CONFIG_CPU_32v6K is set, we know we have the TLS register on all supported CPUs, so use it unconditionally. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk Acked-by: Nicolas Pitre nicolas.pi...@linaro.org Note: this is becoming a bit confusing and prone to mistake when we have: CONFIG_CPU_V6 CONFIG_CPU_V6K CONFIG_CPU_32v6 CONFIG_CPU_32v6K I don't know what to suggest for a less similar naming scheme between the CPU design and the allowed instruction set though. --- arch/arm/include/asm/tls.h | 11 +-- 1 files changed, 5 insertions(+), 6 deletions(-) diff --git a/arch/arm/include/asm/tls.h b/arch/arm/include/asm/tls.h index e71d6ff..60843eb 100644 --- a/arch/arm/include/asm/tls.h +++ b/arch/arm/include/asm/tls.h @@ -28,15 +28,14 @@ #define tls_emu 1 #define has_tls_reg 1 #define set_tls set_tls_none -#elif __LINUX_ARM_ARCH__ = 7 || \ - (__LINUX_ARM_ARCH__ == 6 defined(CONFIG_CPU_32v6K)) -#define tls_emu 0 -#define has_tls_reg 1 -#define set_tls set_tls_v6k -#elif __LINUX_ARM_ARCH__ == 6 +#elif defined(CONFIG_CPU_V6) #define tls_emu 0 #define has_tls_reg (elf_hwcap HWCAP_TLS) #define set_tls set_tls_v6 +#elif defined(CONFIG_CPU_32v6K) +#define tls_emu 0 +#define has_tls_reg 1 +#define set_tls set_tls_v6k #else #define tls_emu 0 #define has_tls_reg 0 -- 1.6.2.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 10/14] ARM: v6k: select TLS register code according to V6 variants
On Mon, Jan 17, 2011 at 05:23:43PM -0500, Nicolas Pitre wrote: On Mon, 17 Jan 2011, Russell King - ARM Linux wrote: If CONFIG_CPU_V6 is enabled, we may or may not have the TLS register. Use the conditional code which copes with this variability. Otherwise, if CONFIG_CPU_32v6K is set, we know we have the TLS register on all supported CPUs, so use it unconditionally. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk Acked-by: Nicolas Pitre nicolas.pi...@linaro.org Note: this is becoming a bit confusing and prone to mistake when we have: Agreed. CONFIG_CPU_V6 CONFIG_CPU_V6K CONFIG_CPU_32v6 CONFIG_CPU_32v6K I don't know what to suggest for a less similar naming scheme between the CPU design and the allowed instruction set though. It's best to consider CONFIG_CPU_V6/CONFIG_CPU_V6K/CONFIG_CPU_V7 in the same light as CONFIG_CPU_ARM926T etc. It selects a specific CPU core (or family of CPU cores) rather than an architecture - the fact that it _may_ tie up with an architecture is incidental. The CPU_32vX selects the major architecture version. 32vXletter selects sub-options of the architecture. It may be better at some point to get rid of the CPU_32v* and replace them with CPU_ARCH_V* instead, which makes it clear that these ones definitely refer to the architecture versions. The last point while we're here is I don't think it helps to have the conditionals spread between the Kconfig files and this file - I'd much rather see them all in Kconfig so we can see exactly how we end up with each option (TLS_EMUL, TLS_V6, TLS_V6K) in one place. -- 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: Open issues after 2.6.38 merge window
On Mon, 17 Jan 2011, Russell King wrote: On Mon, Jan 17, 2011 at 02:00:17PM -0700, Paul Walmsley wrote: On Mon, 17 Jan 2011, Russell King wrote: On Mon, Jan 17, 2011 at 01:31:47PM -0700, Paul Walmsley wrote: OMAP15xx uses the MPU timer for its clocksource, since OMAP15xx doesn't have GPTIMERs or the 32k sync timer, and the MPU timer code in mach-omap1/time.c wasn't updated for sched_clock() support. Adding an init_fixed_sched_clock() into omap_init_clocksource() should fix the boot on OMAP15xx/7xx. No, it needs fixing properly. There's no reason the gpt clocksource can't be used for sched_clock. There's a very good reason why it can't on OMAP15xx/7xx. GPTIMER/DMTIMER IP blocks are only present on OMAP1610 and later[1]. Nor is a SYNCTIMER_32K IP block present on OMAP15xx/7xx[2]. Yes I realise that. That doesn't negate what I said though. Let me show you how to do it: ... Both a GPT _and_ 32K sched_clock implementation together, selectable at runtime or build time depending on what is selected. I'll give you that it isn't nice code, but it does what's required. Right. I agree that it is possible to support both GPTIMER and 32KiHz clocksources at runtime. But there should be a third case in that code also, a case for the OMAP1 MPU Timer IP blocks. Of course, it would be technically possible to define GPT/GPTIMER to mean MPU Timer on OMAP15xx/OMAP7xx. However, later OMAP1 chips contain all three of the above-mentioned timer IP blocks: GPTIMERs[1], a SYNCTIMER_32K[2], and the MPU Timers[3]. Each of these timers also has distinct power, interconnect, and register access properties. So it seems less confusing to keep the MPU Timer case distinct from the GPTIMER/GPT case. - Paul 1. OMAP1611/12 Multimedia Processor Technical Reference Manual [SWPU066B], section 13.5, Dual-Mode Timer 2. OMAP1611/12 Multimedia Processor Technical Reference Manual [SWPU066B], section 13.6, 32-kHz Synchronized Timer 3. OMAP1611/12 Multimedia Processor Technical Reference Manual [SWPU066B], section 13.4, OMAP3.2 Operating System Timer -- 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 10/14] ARM: v6k: select TLS register code according to V6 variants
On Mon, Jan 17, 2011 at 10:36:35PM +, Russell King - ARM Linux wrote: It may be better at some point to get rid of the CPU_32v* and replace them with CPU_ARCH_V* instead, which makes it clear that these ones definitely refer to the architecture versions. Last point on this is that I think we want to sanitize PJ4. If we think about CPU_V7 as being the selection of ARM CPUs which are V7 architectures, CPU_PJ4 should be a separate config option selecting all the same symbols which CPU_V7 does - and that should also select proc-v7.S for building. I'm not sure it makes sense to have (eg) the V7 perf events available on PJ4 or the ARM errata for their V7 cores? Does PJ4 have VFPv3? Is Neon available on PJ4? What about the DCC debug registers? 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 04/14] ARM: v6k: introduce CPU_V6K option
* Russell King - ARM Linux li...@arm.linux.org.uk [110117 11:29]: Introduce a CPU_V6K configuration option for platforms to select if they have a V6K CPU core. This allows us to identify whether we need to support ARMv6 CPUs without the V6K SMP extensions at build time. Currently CPU_V6K is just an alias for CPU_V6, and all places which reference CPU_V6 are replaced by (CPU_V6 || CPU_V6K). Select CPU_V6K from platforms which are known to be V6K-only. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk Acked-by: Tony Lindgren t...@atomide.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 07/14] ARM: v6k: select clear exclusive code seqences according to V6 variants
* Russell King - ARM Linux li...@arm.linux.org.uk [110117 11:27]: If CONFIG_CPU_V6 is enabled, then the kernel must support ARMv6 CPUs which don't have the V6K extensions implemented. Always use the dummy store-exclusive method to ensure that the exclusive monitors are cleared. If CONFIG_CPU_V6 is not set, but CONFIG_CPU_32v6K is enabled, then we have the K extensions available on all CPUs we're building support for, so we can use the new clear-exclusive instruction. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk Acked-by: Tony Lindgren t...@atomide.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 08/14] ARM: v6k: select cmpxchg code sequences according to V6 variants
* Russell King - ARM Linux li...@arm.linux.org.uk [110117 11:23]: If CONFIG_CPU_V6 is enabled, we must avoid the byte/halfword/doubleword exclusive operations, which aren't implemented before V6K. Use the generic versions (or omit them) instead. If CONFIG_CPU_V6 is not set, but CONFIG_CPU_32v6K is enabled, we have the K extnesions, so use these new instructions. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk Acked-by: Tony Lindgren t...@atomide.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: State of SDP4430 platform
On Mon, 17 Jan 2011, Santosh Shilimkar wrote:
The I2C timeout issue I could reproduce on my ES1.0 board. It's ES1.0
specific issue because I2C burst mode wasn't fuctional on it. Twl RTC
driver uses I2C burst mode and hence it times out. Other TWL I2C
module has no such issue.
The pull work-around we tried was not reliable hence it was dropped.
In short the TWL RTC driver won't function on ES1.0. Apart from that
rest of the I2C clients should work as usual.
Looks like the IRQ handling code uses it too:
$ egrep -r 'twl_i2c_(write|read)\(' drivers/ | egrep -v twl-core | egrep -v 4030
drivers/mfd/twl6030-irq.c: ret = twl_i2c_read(TWL_MODULE_PIH,
sts.bytes,
drivers/mfd/twl6030-irq.c: ret = twl_i2c_write(TWL_MODULE_PIH,
sts.bytes,
drivers/mfd/twl6030-irq.c: ret = twl_i2c_write(TWL_MODULE_PIH, mask[0],
drivers/mfd/twl6030-irq.c: ret = twl_i2c_write(TWL_MODULE_PIH, mask[0],
drivers/mfd/twl6030-irq.c: ret = twl_i2c_write(TWL_MODULE_PIH, mask[0],
drivers/rtc/rtc-twl.c: ret = twl_i2c_read(TWL_MODULE_RTC, rtc_data,
drivers/rtc/rtc-twl.c: ret = twl_i2c_write(TWL_MODULE_RTC, rtc_data,
drivers/rtc/rtc-twl.c: ret = twl_i2c_read(TWL_MODULE_RTC, rtc_data,
drivers/rtc/rtc-twl.c: ret = twl_i2c_write(TWL_MODULE_RTC, alarm_data,
$
I'd assume this also would affect other, non-TWL, I2C endpoints, no?
Sounds like a platform_data flag should be passed into the I2C driver code
to indicate that burst transactions are buggy on OMAP4430ES1.
- 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 09/14] ARM: v6k: select generic atomic64 code according to V6 variants
* Russell King - ARM Linux li...@arm.linux.org.uk [110117 11:23]: If CONFIG_CPU_V6 is enabled, avoid using the double-word exclusive instructions in the kernel's atomic implementations as these are not supported. Fall back to the generic spinlock code instead. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk Acked-by: Tony Lindgren t...@atomide.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 10/14] ARM: v6k: select TLS register code according to V6 variants
* Nicolas Pitre n...@fluxnic.net [110117 14:22]: On Mon, 17 Jan 2011, Russell King - ARM Linux wrote: If CONFIG_CPU_V6 is enabled, we may or may not have the TLS register. Use the conditional code which copes with this variability. Otherwise, if CONFIG_CPU_32v6K is set, we know we have the TLS register on all supported CPUs, so use it unconditionally. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk Acked-by: Nicolas Pitre nicolas.pi...@linaro.org Acked-by: Tony Lindgren t...@atomide.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 11/14] ARM: v6k: use CPU domain feature if we include support for arch ARMv6K
* Nicolas Pitre n...@fluxnic.net [110117 14:02]: On Mon, 17 Jan 2011, Russell King - ARM Linux wrote: Rather than turning off CPU domain switching when the build architecture includes ARMv6K, thereby causing problems for ARMv6-supporting kernels, turn it on when it's required to support a CPU architecture. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk Acked-by: Nicolas Pitre nicolas.pi...@linaro.org Acked-by: Tony Lindgren t...@atomide.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 12/14] ARM: v6k: do not disable CPU_32v6K based on platform selection
* Russell King - ARM Linux li...@arm.linux.org.uk [110117 11:24]: CPU_32v6K controls whether we use the ARMv6K extension instructions in the kernel, and in some places whether we use SMP-safe code sequences (eg, bitops.) MX3 prevents the selection of this option to ensure that it is not enabled for their CPU, which is ARMv6 only. Now that we've split the CPU_V6 option, V6K support won't be offered for MX3 anymore. OMAP prevents the selection of this option in an attempt to produce a kernel which runs on architectures from ARMv6 to ARMv7 MPCore. We now achieve this in a different way (see the previous patches). As such, we no longer need to offer this as a configuration option to the user. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk Tested-by: Tony Lindgren t...@atomide.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 13/14] ARM: v6k: allow swp emulation again when ARMv7 is enabled
* Russell King - ARM Linux li...@arm.linux.org.uk [110117 11:26]: Now that we build a v6+v6k+v7 kernel with -march=armv6k for everything, we don't need to disable swp emulation to work around the build problem with OMAP. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk Glad to see this issue sorted out. Tested-by: Tony Lindgren t...@atomide.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 14/14] ARM: v6k: only allow SMP if we have v6k or v7 CPU
* Russell King - ARM Linux li...@arm.linux.org.uk [110117 11:25]: SMP extensions are only supported on ARMv6k or ARMv7 architectures, so only offer the option if we're building for such an architecture. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk Acked-by: Tony Lindgren t...@atomide.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 06/14] ARM: v6k: Dove platforms use V6K architecture CPUs
On Mon, 17 Jan 2011, Russell King - ARM Linux wrote: Make Dove platforms select the new V6K CPU option. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk Tested-by: Nicolas Pitre nicolas.pi...@linaro.org I'd suggest doing the following instead of attaching the selection to each individual board target , as the whole Dove architecture is V6K: diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index ba304a3..d3f5674 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -457,6 +457,7 @@ config ARCH_IXP4XX config ARCH_DOVE bool Marvell Dove + select CPU_V6K select PCI select ARCH_REQUIRE_GPIOLIB select GENERIC_CLOCKEVENTS diff --git a/arch/arm/mach-dove/Kconfig b/arch/arm/mach-dove/Kconfig index 822439a..dd937c5 100644 --- a/arch/arm/mach-dove/Kconfig +++ b/arch/arm/mach-dove/Kconfig @@ -5,14 +5,12 @@ menu Marvell Dove Implementations config MACH_DOVE_DB bool Marvell DB-MV88AP510 Development Board select I2C_BOARDINFO - select CPU_V6K help Say 'Y' here if you want your kernel to support the Marvell DB-MV88AP510 Development Board. config MACH_CM_A510 bool CompuLab CM-A510 Board - select CPU_V6K help Say 'Y' here if you want your kernel to support the CompuLab CM-A510 Board. --- arch/arm/mach-dove/Kconfig |4 +++- arch/arm/mm/Kconfig|4 ++-- 2 files changed, 5 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-dove/Kconfig b/arch/arm/mach-dove/Kconfig index a4ed390..822439a 100644 --- a/arch/arm/mach-dove/Kconfig +++ b/arch/arm/mach-dove/Kconfig @@ -5,12 +5,14 @@ menu Marvell Dove Implementations config MACH_DOVE_DB bool Marvell DB-MV88AP510 Development Board select I2C_BOARDINFO + select CPU_V6K help Say 'Y' here if you want your kernel to support the Marvell DB-MV88AP510 Development Board. - config MACH_CM_A510 +config MACH_CM_A510 bool CompuLab CM-A510 Board + select CPU_V6K help Say 'Y' here if you want your kernel to support the CompuLab CM-A510 Board. diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig index 559e933..22a3f4a 100644 --- a/arch/arm/mm/Kconfig +++ b/arch/arm/mm/Kconfig @@ -390,7 +390,7 @@ config CPU_PJ4 # ARMv6 config CPU_V6 - bool Support ARM V6 processor if ARCH_INTEGRATOR || MACH_REALVIEW_EB || MACH_REALVIEW_PBX || ARCH_DOVE + bool Support ARM V6 processor if ARCH_INTEGRATOR || MACH_REALVIEW_EB || MACH_REALVIEW_PBX select CPU_32v6 select CPU_ABRT_EV6 select CPU_PABRT_V6 @@ -403,7 +403,7 @@ config CPU_V6 # ARMv6k config CPU_V6K - bool Support ARM V6K processor if ARCH_INTEGRATOR || MACH_REALVIEW_EB || MACH_REALVIEW_PBX || ARCH_DOVE + bool Support ARM V6K processor if ARCH_INTEGRATOR || MACH_REALVIEW_EB || MACH_REALVIEW_PBX select CPU_32v6 select CPU_32v6K if !ARCH_OMAP2 select CPU_ABRT_EV6 -- 1.6.2.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 v4 1/4] TI816X: Update common omap platform files
Hello Hemant, On Mon, 10 Jan 2011, Hemant Pedanekar wrote: 2) OMAP3 only build with CONFIG_SOC_OMAPTI816X: This will build TI816X optimized kernel. May not boot on other OMAP3 SoCs. ... Note that OMAP3 only build with support for OMAP3 SoCs as well as TI816X is not possible. Could you explain a little bit why this is not possible? Naïvely, to me, it seems that it should be possible. - Paul
RE: [PATCH v4 1/4] TI816X: Update common omap platform files
Paul Walmsley wrote on Tuesday, January 18, 2011 5:38 AM: Hello Hemant, On Mon, 10 Jan 2011, Hemant Pedanekar wrote: 2) OMAP3 only build with CONFIG_SOC_OMAPTI816X: This will build TI816X optimized kernel. May not boot on other OMAP3 SoCs. ... Note that OMAP3 only build with support for OMAP3 SoCs as well as TI816X is not possible. Could you explain a little bit why this is not possible? Naïvely, to me, it seems that it should be possible. - Paul Hi Paul, You are correct, the OMAP3 only kernel built with TI816X also boots on OMAP3 EVM. But my main concern is with cpu_is_ti816x becoming true for this build (optimized build for TI816X only), some of the OMAP3 related part will be skipped. E.g., - if (omap_rev() = OMAP3430_REV_ES2_0) + if (!cpu_is_ti816x() (omap_rev() = OMAP3430_REV_ES2_0)) omap3_clk_lock_dpll5(); Thanks - Hemant -- 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: State of LDP3430 platform
Hi,
* Paul Walmsley p...@pwsan.com [110115 20:31]:
--- a/arch/arm/mach-omap1/time.c
+++ b/arch/arm/mach-omap1/time.c
@@ -244,6 +244,13 @@ static void __init omap_timer_init(void)
omap_init_mpu_timer(rate);
omap_init_clocksource(rate);
+ /*
+ * XXX Since this file seems to deal mostly with the MPU timer,
+ * this doesn't seem like the correct place for the sync timer
+ * clocksource init.
+ */
+ if (!cpu_is_omap7xx() !cpu_is_omap15xx())
+ omap_init_clocksource_32k();
}
struct sys_timer omap_timer = {
To me it looks like the omap_init_clocksource_32k() call should be
in arch/arm/mach-omap1/timer32k.c instead.
Regards,
Tony
--
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
