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,
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:
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
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
-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:
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,
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
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
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
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:
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.
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
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
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
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
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
-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
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
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
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
-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
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:
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
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
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
---
-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, 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;
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
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)
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
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:
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
---
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
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
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
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
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
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
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
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
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
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
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.
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
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?
-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
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
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
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
-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
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
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
* 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
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
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.
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
* 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;
* 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
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
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
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
---
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
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
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
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
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
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
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
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
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
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
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(-)
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
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
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
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
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
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
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
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
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
* 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
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
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
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
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
* 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
* 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
* 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
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
* 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
* 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
* 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
* 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
* 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
* 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
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
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
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
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
1 - 100 of 132 matches
Mail list logo
