Looks like linux-next as of today is broken on at least OMAP4.
Turning on earlyprintk, I get a crash in omap_init_mcspi. Disabling
CONFIG_SPI_OMAP24XX gets me as far as the following lines from my
bootup log, but I haven't attempted to debug further.
If there are any patches out there to fix
Koyamangalath, Abhilash wrote:
There is this boot-time message on the am3517evm (and possibly
other omap 35xx based boards as well)
[0.00] _omap_mux_init_gpio: Multiple gpio paths
(2) for gpio126
I realized that this happens due to dual mappings for
gpio_126 in
Hi all,
On 22.02.2011 02:43, Dave Hylands wrote:
Hi guys,
There is a bug in the kernel workqueues. I observed it in 2.6.36.3 (it
seems to have been introduced in 2.6.36 and is still in 2.6.37.1), One
of my colleagues was investigating and contacted the author of the
workqueue code (Tejun
Hi Tony,
The following mach-omap2 patches have been reviewed and are in DSS tree,
but cause easily conflicts with linux-omap tree.
Would it be possible for you to pull these into linux-omap?
The patches are based on today's linux-omap/master.
Tomi
The following changes since commit
On Tue, Feb 22, 2011 at 3:19 PM, Anand Gadiyar gadi...@ti.com wrote:
Looks like linux-next as of today is broken on at least OMAP4.
Turning on earlyprintk, I get a crash in omap_init_mcspi. Disabling
CONFIG_SPI_OMAP24XX gets me as far as the following lines from my
bootup log, but I haven't
Govindraj wrote:
On Tue, Feb 22, 2011 at 3:19 PM, Anand Gadiyar gadi...@ti.com wrote:
Looks like linux-next as of today is broken on at least OMAP4.
Turning on earlyprintk, I get a crash in omap_init_mcspi. Disabling
CONFIG_SPI_OMAP24XX gets me as far as the following lines from my
On Tue, 2011-02-22 at 10:41 +0530, Anand Gadiyar wrote:
I'm trying to boot up the mainline kernel on an n800 device. I don't have
a functional UART up and running - so I cannot see any console messages.
I don't know about the n800, but for the n810 there are quite some
patches needed to get it
Hi there,
I was wondering if somebody was working on mainline integration of the
cbus code.
That probably is a major effort, as it needs a rewrite in some parts,
but I'm certainly interested in getting it mainlined, because I'm
currently developing a driver on top of it.
It's a battery management
I'm trying to boot up the mainline kernel on an n800 device. I don't have
a functional UART up and running - so I cannot see any console messages.
Does anyone have instructions or pointers to any patches that may be
needed to get the mainline linux kernel booting to the UI on this
platform?
Hi,
On Tue, Feb 22, 2011 at 11:48:12AM +0100, Michael Büsch wrote:
I was wondering if somebody was working on mainline integration of the
cbus code.
just look at the cbus from on linux-omap tree:
Alexander Shishkin (1):
cbus: fix comilation breakage
Felipe Balbi (85):
cbus:
On Tue, 2011-02-22 at 13:05 +0200, Felipe Balbi wrote:
That probably is a major effort, as it needs a rewrite in some parts,
but I'm certainly interested in getting it mainlined, because I'm
currently developing a driver on top of it.
We're almost there actually. Retu is in great shape
On Tue, Feb 22, 2011 at 12:12:07PM +0100, Michael Büsch wrote:
On Tue, 2011-02-22 at 13:05 +0200, Felipe Balbi wrote:
That probably is a major effort, as it needs a rewrite in some parts,
but I'm certainly interested in getting it mainlined, because I'm
currently developing a driver on
Hi Anand,
On 2/22/2011 10:49 AM, Gadiyar, Anand wrote:
Looks like linux-next as of today is broken on at least OMAP4.
Turning on earlyprintk, I get a crash in omap_init_mcspi. Disabling
CONFIG_SPI_OMAP24XX gets me as far as the following lines from my
bootup log, but I haven't attempted to
When omapfb.mode is passed through bootargs, when omapfb is setting mode,
it would check if timings passed are fine for panel attached to it.
It makes use of check_timing API provided by the panel.
In current code if check_timing API is not available for attached panel,
OMAPFB would return
Hi Paul,
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Monday, February 21, 2011 10:25 PM
To: Cousson, Benoit; Nayak, Rajendra
Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Subject: Re: [PATCH 0/3] OMAP2+ hwmod fixes
Hello Benoît,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Cousson, Benoit
Sent: Tuesday, February 22, 2011 6:22 PM
To: Gadiyar, Anand
Cc: linux-omap
Subject: Re: Linux-next as of 20110222 broken on OMAP4
Hi Anand,
On 2/22
On 2/21/2011 4:41 PM, Premi, Sanjeev wrote:
[...]
The comment is already there BTW, so you just have to replace that by some
real code:-)
[sp] I have already added real code, but the problem lies here:
On same file (few lines up) omap_chip.oc is assigned value of
I posted as part of the Linux-next as of
20110222 broken on OMAP4 thread.
arch/arm/mach-omap2/omap_hwmod.c |3 +--
arch/arm/mach-omap2/timer-gp.c |4 +++-
arch/arm/plat-omap/include/plat/omap_hwmod.h |1 +
3 files changed, 5 insertions(+), 3 deletions
On Mon, Feb 21, 2011 at 7:27 PM, Oleg Nesterov o...@redhat.com wrote:
On 02/21, Oleg Nesterov wrote:
On 02/21, Peter Zijlstra wrote:
afaict its needed because struct signal_struct and struct sighand_struct
include a wait_queue_head_t. The inclusion seems to come through
completion.h,
OMAP35xx, AM35xx, AM37xx families hve multiple
variants that differ from each other based on
features and peripherals.
This patch defines a simple framework to keep
the HWMOD database to be a generic superset and
then allow runtime selection and deselection of
HWMODs corresponding to detected
* Santosh Shilimkar santosh.shilim...@ti.com [110222 06:35]:
To adhere to recent early_init changes, commit '44dc0' made
omap_hwmod_late_init() to core_initcall to avoid ioremap() failures.
Later 'e7c7d7' removed _mpu_rt_va population omap_hwmod_late_init()
So now if we move the
* Michael Büsch m...@bu3sch.de [110222 02:33]:
On Tue, 2011-02-22 at 10:41 +0530, Anand Gadiyar wrote:
I'm trying to boot up the mainline kernel on an n800 device. I don't have
a functional UART up and running - so I cannot see any console messages.
I don't know about the n800, but for
On Mon, 21 Feb 2011, Cousson, Benoit wrote:
Meanwhile, the following will just prevent the fmwk to reset and idle the
timer during hwmod_init.
Regards,
Benoit
Looks okay to me for the time being.
Acked-by: Paul Walmsley p...@pwsan.com
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
Hi,
* Tomi Valkeinen tomi.valkei...@ti.com [110222 02:07]:
Hi Tony,
The following mach-omap2 patches have been reviewed and are in DSS tree,
but cause easily conflicts with linux-omap tree.
Would it be possible for you to pull these into linux-omap?
Sure, but see below.
The patches
* Felipe Balbi ba...@ti.com [110217 23:33]:
Hi Tony,
Here's a pull request for the changes we need to get into the upcoming
merge window. These have been tested overnight on pandaboard.
I also checked that it merges cleanly with your omap-for-linus branch.
Thanks pulled. Looks like there
Hi Rajendra
On Tue, 22 Feb 2011, Rajendra Nayak wrote:
The original behavior of the iterators, to terminate upon
encountering an error, seems fine to me. The only problem
I faced was that they fail silently and go undetected, unless
their user catches the return value and WARN's, which I
* Cousson, Benoit b-cous...@ti.com [110222 04:50]:
Hi Anand,
On 2/22/2011 10:49 AM, Gadiyar, Anand wrote:
Looks like linux-next as of today is broken on at least OMAP4.
Turning on earlyprintk, I get a crash in omap_init_mcspi. Disabling
CONFIG_SPI_OMAP24XX gets me as far as the
Commit 06824ba824b3e9f2fedb38bee79af0643198ed7f
(ARM: tlb: delay page freeing for SMP and ARMv7 CPUs) causes
the following compile error for at least omap1_defconfig:
In file included from arch/arm/mm/init.c:27:
arch/arm/include/asm/tlb.h: In function 'tlb_flush_mmu':
Hello.
Tony Lindgren wrote:
Commit 06824ba824b3e9f2fedb38bee79af0643198ed7f
(ARM: tlb: delay page freeing for SMP and ARMv7 CPUs) causes
the following compile error for at least omap1_defconfig:
In file included from arch/arm/mm/init.c:27:
arch/arm/include/asm/tlb.h: In function
On Tue, Feb 22, 2011 at 11:43:32AM -0800, Tony Lindgren wrote:
Commit 06824ba824b3e9f2fedb38bee79af0643198ed7f
(ARM: tlb: delay page freeing for SMP and ARMv7 CPUs) causes
the following compile error for at least omap1_defconfig:
In file included from arch/arm/mm/init.c:27:
On Tue, Feb 22, 2011 at 10:51:53PM +0300, Sergei Shtylyov wrote:
Hello.
Tony Lindgren wrote:
Commit 06824ba824b3e9f2fedb38bee79af0643198ed7f
(ARM: tlb: delay page freeing for SMP and ARMv7 CPUs) causes
the following compile error for at least omap1_defconfig:
I't not omap1_defconfig only,
On Tue, 2011-02-22 at 11:01 -0800, Tony Lindgren wrote:
* Felipe Balbi ba...@ti.com [110217 23:33]:
Hi Tony,
Here's a pull request for the changes we need to get into the upcoming
merge window. These have been tested overnight on pandaboard.
I also checked that it merges cleanly
Hello Russell,
On Tue, Feb 22, 2011 at 07:59:29PM +, Russell King - ARM Linux wrote:
Note that arch/x86/mm/init.c and arch/x86/mm/pgtable.c both include
asm/tlb.h without linux/pagemap.h, and use the generic version. I bet
no one's tried building x86 with CONFIG_SWAP=n yet...
I did, and
On Tue, Feb 22, 2011 at 09:10:47PM +0100, Uwe Kleine-König wrote:
Hello Russell,
On Tue, Feb 22, 2011 at 07:59:29PM +, Russell King - ARM Linux wrote:
Note that arch/x86/mm/init.c and arch/x86/mm/pgtable.c both include
asm/tlb.h without linux/pagemap.h, and use the generic version. I
* Russell King - ARM Linux li...@arm.linux.org.uk [110222 11:57]:
On Tue, Feb 22, 2011 at 11:43:32AM -0800, Tony Lindgren wrote:
Commit 06824ba824b3e9f2fedb38bee79af0643198ed7f
(ARM: tlb: delay page freeing for SMP and ARMv7 CPUs) causes
the following compile error for at least
Commit
06824ba (ARM: tlb: delay page freeing for SMP and ARMv7 CPUs)
introduced a build failure for builds with CONFIG_SWAP=n:
In file included from arch/arm/mm/init.c:27:
arch/arm/include/asm/tlb.h: In function 'tlb_flush_mmu':
arch/arm/include/asm/tlb.h:101:
Hello,
I've designed an OMAP3530 board without a PMIC.
While trying to boot, the kernel cannot locate the rootfs on
/dev/mmcblk0p2.
The kernel fails to locate the block device when calling
blk_lookup_devt() in genhd.c.
The twl regulator support must be compiled in to support the MMC
* Uwe Kleine-König u.kleine-koe...@pengutronix.de [110222 12:25]:
Commit
06824ba (ARM: tlb: delay page freeing for SMP and ARMv7 CPUs)
introduced a build failure for builds with CONFIG_SWAP=n:
In file included from arch/arm/mm/init.c:27:
arch/arm/include/asm/tlb.h: In
On Fri, Feb 18, 2011 at 01:12:37PM +0200, Felipe Balbi wrote:
On Fri, Feb 18, 2011 at 04:39:48PM +0530, Koyamangalath, Abhilash wrote:
I understand, but is there a subtle reason why are starting from
an erroneous-looking -1 rather than a more natural 0 (or 1 ?).
-1 means no ID. The IDs are
On Tue, Feb 22, 2011 at 03:41:39PM -0500, Boswell, Patrick wrote:
The twl regulator support must be compiled in to support the MMC reader.
How do I go about
creating an always on or not managed VMMC so that the device
operates properly?
Use a fixed voltage regulator, or if you don't have any
Looks good. Can you stick it in the patch system please?
On Tue, Feb 22, 2011 at 09:26:42PM +0100, Uwe Kleine-König wrote:
Commit
06824ba (ARM: tlb: delay page freeing for SMP and ARMv7 CPUs)
introduced a build failure for builds with CONFIG_SWAP=n:
In file included from
On Tue, 2011-02-22 at 09:18 -0800, Tony Lindgren wrote:
* Michael Büsch m...@bu3sch.de [110222 02:33]:
On Tue, 2011-02-22 at 10:41 +0530, Anand Gadiyar wrote:
I'm trying to boot up the mainline kernel on an n800 device. I don't have
a functional UART up and running - so I cannot see any
On Tue, Feb 22, 2011 at 10:26:28PM +, Russell King - ARM Linux wrote:
Looks good. Can you stick it in the patch system please?
done as
http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=6757/1
Best regards
Uwe
--
Pengutronix e.K. | Uwe
On 2/22/2011 2:48 PM, Premi, Sanjeev wrote:
On 2/21/2011 4:41 PM, Premi, Sanjeev wrote:
[...]
The comment is already there BTW, so you just have to replace that by some
real code:-)
[sp] I have already added real code, but the problem lies here:
On same file (few lines up)
On Wed, Feb 16, 2011 at 1:35 PM, David Cohen daco...@gmail.com wrote:
Add support to register an isr for IOMMU fault situations and adapt it
to allow such (*isr)() to be used as fault callback. Drivers using IOMMU
module might want to be informed when errors happen in order to debug it
or
OMAP2+ kernels built without CONFIG_OMAP_32K_TIMER crash on boot after the
2.6.38 sched_clock changes:
[0.00] OMAP clockevent source: GPTIMER1 at 1300 Hz
[0.00] Unable to handle kernel NULL pointer dereference at virtual
address
[0.00] pgd = c0004000
[
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Tony Lindgren
Sent: Wednesday, February 23, 2011 12:44 AM
To: Cousson, Benoit
Cc: Gadiyar, Anand; linux-omap
Subject: Re: Linux-next as of 20110222 broken on OMAP4
Hi Benoit,
-Original Message-
From: Cousson, Benoit [mailto:b-cous...@ti.com]
Sent: Monday, February 21, 2011 8:10 PM
To: Shilimkar, Santosh
Cc: linux-omap@vger.kernel.org; Balbi, Felipe; R, Sricharan
Subject: Re: [PATCH 4/6] omap4: hwmod_data: Add l3 errorlog data to hwmod
database.
Hi
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Tony Lindgren
Sent: Tuesday, February 22, 2011 10:19 PM
To: Santosh Shilimkar
Cc: linux-omap@vger.kernel.org; Paul Walmsley; Kevin Hilman; Benoit
Cousson
Subject: Re:
On Sat, Feb 19, 2011 at 01:44:32PM +0530, Datta, Shubhrajyoti wrote:
On Sat, Feb 19, 2011 at 11:01 AM, Dmitry Torokhov dmitry.torok...@gmail.com
wrote:
Hi Shubhrajyoti,
On Sat, Feb 19, 2011 at 08:37:15AM +0530, Shubhrajyoti wrote:
Hello Dmitry,
If there are no further comments.
-Original Message-
From: Nishanth Menon [mailto:n...@ti.com]
Sent: Sunday, February 20, 2011 10:20 AM
To: Vishwanath Sripathy
Cc: linux-omap; Tony Lindgren; Kevin Hilman
Subject: Re: [PATCH 15/19] omap3+: sr: introduce notifier_control
Vishwanath Sripathy wrote, on 02/19/2011 07:10
-Original Message-
From: Nishanth Menon [mailto:n...@ti.com]
Sent: Sunday, February 20, 2011 10:42 AM
To: Vishwanath Sripathy
Cc: linux-omap; Tony Lindgren; Kevin Hilman
Subject: Re: [PATCH 03/19] omap3+: voltage: remove initial voltage
Vishwanath Sripathy wrote, on 02/19/2011
Hello,
This series adds the ability to late-initialize individual
hwmods. The goal here is for clockevent (and eventually
clocksource) hwmods to be late-initialized individually, and
right before they are needed, in the timer init code. Then
omap_hwmod_late_init(), which late-inits the rest of
Move the code that looks for the MPU initiator hwmod to run during
the individual hwmod _register() function. (Previously, it ran after
all hwmods were registered in the omap_hwmod_late_init() function.)
This is done so code can late-initialize a few individual hwmods --
for example, for the
From: Thara Gopinath th...@ti.com
Add dmtimer data.
Signed-off-by: Thara Gopinath th...@ti.com
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Acked-by: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 634
From: Thara Gopinath th...@ti.com
Add dmtimer data.
Signed-off-by: Thara Gopinath th...@ti.com
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Acked-by: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 649
1 files changed,
There's no longer any reason why we should prevent multiple
calls to omap_hwmod_init(). It is now simply used to register an
array of hwmods.
This should allow a subset of hwmods (e.g., hwmods
handling the system clocksource and clockevents) to be registered
earlier than the remaining mass of
From: Thara Gopinath th...@ti.com
Add dmtimer data.
Signed-off-by: Thara Gopinath th...@ti.com
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Acked-by: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 633
1 files changed,
Late-initialize the GPTIMER hwmod used for the clockevent source immediately
before it is used. This avoids the need to late-initialize all of the hwmods
until the boot process is further along. (In general, we want to defer
as much as possible until late in the boot process.)
Signed-off-by:
Add omap_hwmod_late_init_one(), which is intended for use early in
boot to selectively init the hwmods needed for system clocksources
and clockevents, and any other hwmod that is needed in early boot.
omap_hwmod_late_init() can then be called later in the boot process.
The point is to minimize the
Previously, if a hwmod had already been late-initialized, and the code
attempted to late-initialize the hwmod again, an error would be
returned. This is not really useful behavior if we wish to allow the
OMAP core code to late-init the hwmods needed for the Linux
clocksources and clockevents
Hi Santosh,
On Tue, 22 Feb 2011, Santosh Shilimkar wrote:
To adhere to recent early_init changes, commit '44dc0' made
omap_hwmod_late_init() to core_initcall to avoid ioremap() failures.
Later 'e7c7d7' removed _mpu_rt_va population omap_hwmod_late_init()
So now if we move the
On Tue, 2011-02-22 at 13:01 -0600, Tony Lindgren wrote:
Hi,
* Tomi Valkeinen tomi.valkei...@ti.com [110222 02:07]:
Hi Tony,
The following mach-omap2 patches have been reviewed and are in DSS tree,
but cause easily conflicts with linux-omap tree.
Would it be possible for you to
Hi Alan,
1) make sure that we have the new watchdog core infrastructure going in for
2.6.32.
This new core integrates the common code that we use over and over again. I
once
wrote code for it and then Alan had different ideas and thoughts and wrote
his updated
code. I reviewed
64 matches
Mail list logo
