Here are some basic OMAP test results for Linux v3.12-rc6.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.12-rc6/20131021185919/
Test summary
Build: uImage:
Pass (14/14): omap1_defconfig, omap1_defconfig_1510innovator_only
From: Mugunthan V N mugunthan...@ti.com
Date: Sun, 20 Oct 2013 12:32:26 +0530
When interrupt pacing is enabled, receive/transmit statistics are not
updated properly by hardware which leads to ISR return with IRQ_NONE
and inturn kernel disables the interrupt. This patch removed the checking
of
When interrupt pacing is enabled, receive/transmit statistics are not
updated properly by hardware which leads to ISR return with IRQ_NONE
and inturn kernel disables the interrupt. This patch removed the checking
of receive/transmit statistics from ISR.
This patch is verified with AM335x Beagle
Here are some basic OMAP test results for Linux v3.12-rc5.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.12-rc5/20131013203109/
Test summary
Build: uImage:
Pass (14/14): omap1_defconfig, omap1_defconfig_1510innovator_only
Here are some basic OMAP test results for Linux v3.12-rc4.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.12-rc4/20131007013715/
Test summary
Build: zImage:
Pass ( 2/ 2): omap2plus_defconfig, omap2plus_defconfig_am33xx_only
Build: uImage+dtb
Here are some basic OMAP test results for Linux v3.12-rc3.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.12-rc3/20130929171908/
Test summary
Build: uImage:
Pass (14/14): omap1_defconfig, omap1_defconfig_1510innovator_only
One of the changes to this testbed, starting with the v3.12-rc kernels, is
the addition of an OMAP4460-based Variscite VAR-SOM-OM DVK board,
graciously donated by Jeff Graham at Bruker Optics.
Right now, the bootloader and userspaces in use are the ones that came
with the board. So it should
Here are some basic OMAP test results for Linux v3.12-rc2.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.12-rc2/20130924152551/
Test summary
Build: zImage:
Pass ( 2/ 2): omap2plus_defconfig, omap2plus_defconfig_am33xx_only
Build: uImage+dtb
Here are some basic OMAP test results for Linux v3.12-rc1.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.12-rc1/20130922202452/
Test summary
Build: zImage:
Pass ( 2/ 2): omap2plus_defconfig, omap2plus_defconfig_am33xx_only
Build: uImage+dtb
Here are some basic OMAP test results for Linux v3.11.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.11/20130902150604/
Test summary
Build: zImage:
Pass ( 1/ 1): omap2plus_defconfig
Build: uImage:
Pass (14/14): n800_multi_omap2xxx, n800_only_a
Here are some basic OMAP test results for Linux v3.11-rc7.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.11-rc7/20130825195715/
Test summary
Build: uImage:
Pass (14/14): n800_multi_omap2xxx, n800_only_a, omap1_defconfig
Here are some basic OMAP test results for Linux v3.11-rc6.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.11-rc6/20130818180958/
Test summary
Build: uImage:
Pass (14/14): n800_multi_omap2xxx, n800_only_a, omap1_defconfig
Here are some basic OMAP test results for Linux v3.11-rc4.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.11-rc4/20130814082546/
I'm sorry to report that my second OMAP5912 OSK has bitten the dust. So
until I can get my hands on another one, I won't be able to boot
Here are some basic OMAP test results for Linux v3.11-rc5.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.11-rc5/20130814083603/
Test summary
Build: uImage:
Pass (14/14): n800_multi_omap2xxx, n800_only_a, omap1_defconfig
This is a test for Overo with Palo43 expansion, _not_ Tobi. Palo43
doesn't have a dts, but seems to work ok with omap3-tobi.dts, so I used
it as a test.
Not to be merged.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/boot/dts/omap3-tobi.dts | 33
Hi Will
On Mon, 29 Jul 2013, Will Deacon wrote:
I wouldn't worry about checking for CPU_V6. Besides, we probably need this
to be re-evaluated across barrier() when we get CPU migration on a
big-little platform anyway (we should probably also drop the
__attribute_const__ for that).
So you
that gcc 4.5 reorders the
extended CP15 read above the is_smp() test. This breaks ARM1136 r0
cores, since they don't support several CP15 registers that later ARM
cores do. ARM1136JF-S TRM section 3.2.1 Register allocation has the
details.
So mark the extended CP15 read as clobbering memory, which
from the CP15 read in
cache_ops_need_broadcast(). It turns out that gcc 4.5 reorders the
extended CP15 read above the is_smp() test. This breaks ARM1136 r0
cores, since they don't support several CP15 registers that later ARM
cores do. ARM1136JF-S TRM section 3.2.1 Register allocation has
trying to test is the kernel...
The kernel should be completely independent of the bootloader used.
And thus the chicken and egg problems we have today. The kernel should
be independent, but unless someone is also testing more recent U-Boots
as well, we may or may not have more hidden clock
On 07/30/2013 03:23 PM, Paul Walmsley wrote:
Do you know if anyone ever got serial cold-booting working well for, say,
OMAP3 and OMAP4 chips?
I had done configuration header based OMAP3 boot[1] once upon a time,
but serial boot straight to kernel, we need a second that gives control
there..
read in
cache_ops_need_broadcast(). It turns out that gcc reorders the
extended CP15 read above the is_smp() test. This breaks ARM1136 r0
cores, since they don't support several CP15 registers that later ARM
cores do. ARM1136JF-S TRM section 3.2.1 Register allocation has the
details.
So
developers should be testing their changes.
But most of the rest of us kernel folks don't want to deal with constantly
replacing bootloaders, and then dealing with the inevitable bootloader
regressions, when what we're really trying to test is the kernel...
The kernel should be completely independent
abort from the CP15 read in
cache_ops_need_broadcast(). It turns out that gcc reorders the
extended CP15 read above the is_smp() test. This breaks ARM1136 r0
cores, since they don't support several CP15 registers that later ARM
cores do. ARM1136JF-S TRM section 3.2.1 Register allocation has
exactly how bootloader developers should be testing their changes.
But most of the rest of us kernel folks don't want to deal with constantly
replacing bootloaders, and then dealing with the inevitable bootloader
regressions, when what we're really trying to test is the kernel...
The kernel
that gcc reorders the
extended CP15 read above the is_smp() test. This breaks ARM1136 r0
cores, since they don't support several CP15 registers that later ARM
cores do. ARM1136JF-S TRM section 3.2.1 Register allocation has the
details.
So, when the kernel is built for ARMv6 cores, mark the extended CP15
Here are some basic OMAP test results for Linux v3.11-rc3.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.11-rc3/20130728224046/
Test summary
Build: uImage:
Pass (14/14): n800_multi_omap2xxx, n800_only_a, omap1_defconfig
Here are some basic OMAP test results for Linux v3.11-rc1.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.11-rc1/20130721020309/
Test summary
Build: uImage:
Pass (14/14): n800_multi_omap2xxx, n800_only_a, omap1_defconfig
Here are some basic OMAP test results for Linux v3.11-rc2.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.11-rc2/20130721203314/
Test summary
Build: uImage:
Pass (14/14): n800_multi_omap2xxx, n800_only_a, omap1_defconfig
Here are some basic OMAP test results for Linux v3.10.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.10/20130717134228/
Test summary
Build: uImage:
Pass (16/16): am33xx_only, n800_multi_omap2xxx, n800_only_a,
omap1_defconfig
On 07/05/2013 01:48 AM, Rajendra Nayak wrote:
On Thursday 04 July 2013 11:42 PM, Paul Walmsley wrote:
On Wed, 3 Jul 2013, Paul Walmsley wrote:
As far as Lokesh's patch goes: it doesn't make sense to me to remove a
file during 'make clean' that the build process doesn't create. So while
I
On Fri, 5 Jul 2013, Rajendra Nayak wrote:
Grant already made it clear when he posted that patch that neither that nor
anything similar would be taken up mainline because the appended dtb was only
meant for folks stuck with legacy bootloaders and have no way to upgrade.
He's not the final
earlier test boots were with the am335x-boneblack.dtb from the
ti-linux-3.8.y tree from Vaibhav's github, since that was the only DTB
that I was able to get any kernel to boot with.
The am33xx_only/appended DTB issues don't apply to this board since it's
booted with detached DTB
On Thu, 4 Jul 2013, Paul Walmsley wrote:
So that's good, will switch to am335x-bone.dtb for the testing restate
jobs to be run for BeagleBone-white, and let's see what previous kernels
it boots with now...
Sorry, this was unclear. To rephrase, I will add
BeagleBone-black boot retest runs,
:
As mentioned in my earlier reply:
http://www.spinics.net/lists/arm-kernel/msg255055.html
my earlier test boots were with the am335x-boneblack.dtb from the
ti-linux-3.8.y tree from Vaibhav's github, since that was the only DTB
that I was able to get any kernel to boot with.
The am33xx_only/appended
On Wed, 3 Jul 2013, Paul Walmsley wrote:
As far as Lokesh's patch goes: it doesn't make sense to me to remove a
file during 'make clean' that the build process doesn't create. So while
I understand the motivation for the patch, and don't mind if upstream
takes it, I personally wouldn't
On Thursday 04 July 2013 11:42 PM, Paul Walmsley wrote:
On Wed, 3 Jul 2013, Paul Walmsley wrote:
As far as Lokesh's patch goes: it doesn't make sense to me to remove a
file during 'make clean' that the build process doesn't create. So while
I understand the motivation for the patch, and
, Tom; linux-
o...@vger.kernel.org; Balbi, Felipe; linux-arm-
ker...@lists.infradead.org
Subject: Re: OMAP baseline test results for v3.10-rc6
On Fri, 28 Jun 2013, Paul Walmsley wrote:
On Thu, 27 Jun 2013, Lokesh Vutla wrote:
Here is the catch..
Your dtb
-
ker...@lists.infradead.org
Subject: Re: OMAP baseline test results for v3.10-rc6
On Fri, 28 Jun 2013, Paul Walmsley wrote:
On Thu, 27 Jun 2013, Lokesh Vutla wrote:
Here is the catch..
Your dtb is generated in arch/arm/boot/dts/ folder(before V3.8 dtb
was
generated in arch/arm/boot).
Ugh
Hi,
On Mon, Jul 01, 2013 at 11:42:36PM +0300, Felipe Balbi wrote:
On Mon, Jul 01, 2013 at 07:48:50PM +, Paul Walmsley wrote:
Boot to userspace:
FAIL ( 2/12): 37xxevm, am335xbonelt
quoting part of [1]
| U-Boot# tftp 0x8200 am335x-boneblack.dtb
| link up on port 0, speed 100,
Here are some basic OMAP test results for Linux v3.10-rc7.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.10-rc7/20130630191558/
Special thanks to Lokesh Vutla, Vaibhav Hiremath, Kevin Hilman, and
Rajendra Nayak for helping unravel the Beaglebone-White test problems
Hi,
On Mon, Jul 01, 2013 at 07:48:50PM +, Paul Walmsley wrote:
Boot to userspace:
FAIL ( 2/12): 37xxevm, am335xbonelt
quoting part of [1]
| U-Boot# tftp 0x8200 am335x-boneblack.dtb
| link up on port 0, speed 100, full duplex
| Using cpsw device
| TFTP from server 192.168.57.1; our
baseline test results for v3.10-rc6
On Fri, 28 Jun 2013, Paul Walmsley wrote:
On Thu, 27 Jun 2013, Lokesh Vutla wrote:
Here is the catch..
Your dtb is generated in arch/arm/boot/dts/ folder(before V3.8 dtb
was
generated in arch/arm/boot).
Ugh... that's probably
. With this fixed, and with
CONFIG_MACH_OMAP_GENERIC=y in the v3.10-rc Kconfigs, the BeagleBone white
boots here now with v3.10-rc7. Will test the previous releases going back
to v3.8 and will update the web-linked READMEs as appropriate.
Thanks for the help and the fixes. Vaibhav and Rajendra, thanks
Hi Lokesh
On Thu, 27 Jun 2013, Lokesh Vutla wrote:
On Wednesday 26 June 2013 10:56 PM, Paul Walmsley wrote:
Here's how I do it:
ARCH=arm CROSS_COMPILE=${TOOLCHAIN_PATH}/bin/${TOOLCHAIN_PREFIX} nice make
-j$CORES zImage am335x-bone.dtb
cat arch/arm/boot/zImage
work, so there's a bug hiding
someplace that needs to be found fixed.
Since we've narrowed down what the problem is, someone can bisect it
now, yeah.
Can you guys update your tests to test appended DTB also?
What is the official position on appending DTBs?
If a platform goes from being
different folks who can't reproduce your bone
and bone black boot to userspace failures. I wonder how you're trying to
boot them.
Care to share your test scripts ?
Sure... the methodology is completely open and has been posted in the
online logs since the first test cycle. (For some reason
v2013.04.)
That being said, appended DTB should still work, so there's a bug hiding
someplace that needs to be found fixed.
Since we've narrowed down what the problem is, someone can bisect it
now, yeah.
Can you guys update your tests to test appended DTB also?
What is the official position
to test appended DTB also?
What is missing here is,
CONFIG_ARM_APPENDED_DTB = y
CONFIG_ARM_ATAG_DTB_COMPAT = y
And for the code which is required in case of appended DTB, please refer to
the code
arch/arm/boot/compressed/head.S
Please __NOTE__ that these options are not enabled
fixed.
Can you guys update your tests to test appended DTB also?
What is missing here is,
CONFIG_ARM_APPENDED_DTB = y
CONFIG_ARM_ATAG_DTB_COMPAT = y
And for the code which is required in case of appended DTB, please refer to
the code
arch/arm/boot/compressed/head.S
Please __NOTE__
On Wed, 26 Jun 2013, Hiremath, Vaibhav wrote:
That’s not quite true, I remember going through your log in detail multiple
Times.
The issue is, for appended DTB you must enable 2 config options,
CONFIG_ARM_APPENDED_DTB = y
CONFIG_ARM_ATAG_DTB_COMPAT = y
Maybe you should look again. Both
On Tue, 25 Jun 2013, Tom Rini wrote:
On 06/25/2013 02:20 PM, Paul Walmsley wrote:
BeagleBone-white has the additional complication that it is not easy
to automate, due to the way that power is delivered to the board, so
there is an extra dimension of difficulty there.
Ah-ha, I
On Wed, 26 Jun 2013, Rajendra Nayak wrote:
Apart from confirming if you are manually enabling these options, can you
also give some
details on how you append the dtb to the kernel image?
Most of us use an out-of-tree patch from Grant to do this, which I have
shared below [2]
Even
On Wed, 26 Jun 2013, Tom Rini wrote:
Yes, please confirm that they're being set.
For the Kconfig that I use to boot the BeagleBone-white, which is called
am33xx_only, yes, both of those are set.
Here's the v3.8-rc1 version of this Kconfig as an example:
Hi
On Wed, 26 Jun 2013, Lokesh Vutla wrote:
I checked your am33xx-only build config for v3.10-rc6 here:
http://www.pwsan.com/omap/testlogs/test_v3.10-rc6/20130616211951/build/am33xx_only/am33xx_only
I can see that you are disabling config MACH_OMAP_GENERIC
# CONFIG_MACH_OMAP_GENERIC is not
On Wed, 26 Jun 2013, Paul Walmsley wrote:
On Wed, 26 Jun 2013, Hiremath, Vaibhav wrote:
That’s not quite true, I remember going through your log in detail multiple
Times.
The issue is, for appended DTB you must enable 2 config options,
CONFIG_ARM_APPENDED_DTB = y
On 06/26/2013 01:28 PM, Paul Walmsley wrote:
On Wed, 26 Jun 2013, Tom Rini wrote:
Yes, please confirm that they're being set.
For the Kconfig that I use to boot the BeagleBone-white, which is called
am33xx_only, yes, both of those are set.
Here's the v3.8-rc1 version of this Kconfig
On Wed, 26 Jun 2013, Tom Rini wrote:
OK, is there a reason to not be using omap2plus_defconfig? My pass/fail
here is based on that config and enabling, or not, dtb append. Seems
like it would be one less thing to maintain on your end and it would be
on TIs end (roughly speaking) to make
On 06/26/2013 01:58 PM, Paul Walmsley wrote:
On Wed, 26 Jun 2013, Tom Rini wrote:
OK, is there a reason to not be using omap2plus_defconfig? My pass/fail
here is based on that config and enabling, or not, dtb append. Seems
like it would be one less thing to maintain on your end and it
in the box need to be factored into our test system setup so if folks
don't want to avail themselves of improvements, they still get a
functional system too.
--
Tom
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More
...@lists.infradead.org; Balbi, Felipe; Hiremath, Vaibhav
Subject: Re: OMAP baseline test results for v3.10-rc6
Tom Rini tr...@ti.com writes:
On 06/25/2013 02:20 PM, Paul Walmsley wrote:
+ Vaibhav and Kevin
Hi,
On Tue, 25 Jun 2013, Felipe Balbi wrote:
On Mon, Jun 17, 2013 at 05:23
Tom Rini tr...@ti.com writes:
On 06/26/2013 01:58 PM, Paul Walmsley wrote:
On Wed, 26 Jun 2013, Tom Rini wrote:
OK, is there a reason to not be using omap2plus_defconfig? My pass/fail
here is based on that config and enabling, or not, dtb append. Seems
like it would be one less thing to
Hi Paul,
On Wednesday 26 June 2013 10:56 PM, Paul Walmsley wrote:
On Wed, 26 Jun 2013, Rajendra Nayak wrote:
Apart from confirming if you are manually enabling these options, can you also
give some
details on how you append the dtb to the kernel image?
Most of us use an out-of-tree patch
.
Care to share your test scripts ?
Also, if you could share the entire thing, we will add your scripts to
our nightly tests as to try and avoid future regressions.
--
balbi
signature.asc
Description: Digital signature
boot to userspace failures. I wonder how you're trying to
boot them.
Care to share your test scripts ?
Sure... the methodology is completely open and has been posted in the
online logs since the first test cycle. (For some reason, almost no one
clicks through the test directory trees that I
who can't reproduce your bone
and bone black boot to userspace failures. I wonder how you're trying to
boot them.
Care to share your test scripts ?
Sure... the methodology is completely open and has been posted in the
online logs since the first test cycle. (For some reason, almost no one
have at least 2 different folks who can't reproduce your bone
and bone black boot to userspace failures. I wonder how you're trying to
boot them.
Care to share your test scripts ?
Sure... the methodology is completely open and has been posted in the
online logs since the first test cycle
): 37xxevm, am335xbone, am335xbonelt
Paul, we have at least 2 different folks who can't reproduce your bone
and bone black boot to userspace failures. I wonder how you're trying to
boot them.
Care to share your test scripts ?
Sure... the methodology is completely open and has been posted
Hi,
On Tue, Jun 25, 2013 at 06:20:51PM +, Paul Walmsley wrote:
Am certainly open to the idea that there's something wrong with the way
that I'm booting either of these. But AFAIK no one's been able to
identify exactly what it could be. I haven't had the time recently to
spend hours
; Hiremath, Vaibhav
Subject: Re: OMAP baseline test results for v3.10-rc6
Tom Rini tr...@ti.com writes:
On 06/25/2013 02:20 PM, Paul Walmsley wrote:
+ Vaibhav and Kevin
Hi,
On Tue, 25 Jun 2013, Felipe Balbi wrote:
On Mon, Jun 17, 2013 at 05:23:17AM +, Paul Walmsley wrote:
Boot
; khil...@ti.com
Subject: Re: OMAP baseline test results for v3.10-rc6
+ Vaibhav and Kevin
Hi,
On Tue, 25 Jun 2013, Felipe Balbi wrote:
On Mon, Jun 17, 2013 at 05:23:17AM +, Paul Walmsley wrote:
Boot to userspace:
FAIL ( 3/12): 37xxevm, am335xbone, am335xbonelt
Paul
Here are some basic OMAP test results for Linux v3.10-rc6.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.10-rc6/20130616211951/
Test summary
Build: uImage:
Pass (16/16): am33xx_only, n800_multi_omap2xxx, n800_only_a
Here are some basic OMAP test results for Linux v3.10-rc5.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.10-rc5/20130609031534/
Test summary
Build: uImage:
Pass (16/16): am33xx_only, n800_multi_omap2xxx, n800_only_a
On Tue, 21 May 2013, Kevin Hilman wrote:
I also just noticed that 3730beaglexm has stopped waking from suspend
via RTC (non-DT boot.) Waking from UART console still works.
Worked fine on v3.9, so there's a regressions somewhere.
Thanks Kevin, noted this in the logs. Please let me know
Here are some basic OMAP test results for Linux v3.10-rc2.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.10-rc2/20130527225935/
Test summary
Build: uImage:
Pass (16/16): am33xx_only, n800_multi_omap2xxx, n800_only_a
Here are some basic OMAP test results for Linux v3.10-rc3.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.10-rc3/20130603032237/
Test summary
Build: uImage:
Pass (16/16): am33xx_only, n800_multi_omap2xxx, n800_only_a
Here are some basic OMAP test results for Linux v3.10-rc4.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.10-rc4/20130603034317/
Test summary
Build: uImage:
Pass (16/16): am33xx_only, n800_multi_omap2xxx, n800_only_a
Paul Walmsley p...@pwsan.com writes:
[...]
PM: chip retention via suspend:
FAIL ( 4/ 6): 2430sdp, 37xxevm, 4430es2panda, 4460pandaes
Pass ( 2/ 6): 3530es3beagle, 3730beaglexm
FYI...
I also just noticed that 3730beaglexm has stopped waking from suspend
via RTC (non-DT boot.) Waking
Here are some basic OMAP test results for Linux v3.10-rc1.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.10-rc1/20130518212204/
Test summary
Build: uImage:
Pass (16/16): am33xx_only, n800_multi_omap2xxx, n800_only_a
Looks like a few messages were missed, so here's an updated version, along
with the size data.
- Paul
Here are some basic OMAP test results for Linux v3.10-rc1.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.10-rc1/20130518212204/
Test summary
Build
On Tue, 14 May 2013, Tony Lindgren wrote:
Thanks that explains. BTW, the PM off naming might make some
people think that CONFIG_PM is not set :)
That's a good point. Will rename that and probably split the 3730 Beagle
XM into its own testing category.
- Paul
--
To unsubscribe from this
Hi,
* Paul Walmsley p...@pwsan.com [130508 12:45]:
PM off, dynamic idle:
FAIL ( 2/ 5): 4430es2panda, 4460pandaes
Pass ( 3/ 5): 3530es3beagle, 3730beaglexm, 37xxevm
Looking at your pm logs, 3730beaglexm won't hit off-idle.
I've pasted the relevant lines from your logs below.
Is this
pasted the relevant lines from your logs below.
Is this a known issue?
Yes, the Beagle XM in my testbed is a 3630ES1.0. From the PM logs:
[ 63.154418] omap3_pm_off_mode_enable: Core OFF disabled due to errata
i583
I should probably clarify how this is reported in the test results.
- Paul
probably clarify how this is reported in the test results.
Thanks that explains. BTW, the PM off naming might make some
people think that CONFIG_PM is not set :)
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord
Here are some basic OMAP test results for Linux v3.9-rc8.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.9-rc8/20130422154921/
Test summary
Build:
FAIL ( 2/16): am33xx_only, omap2plus_defconfig_2430sdp_only
Pass (14/16): n800_multi_omap2xxx
Here are some basic OMAP test results for Linux v3.9.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.9/20130429104339/
Test summary
Build:
FAIL ( 2/16): am33xx_only, omap2plus_defconfig_2430sdp_only
Pass (14/16): n800_multi_omap2xxx, n800_only_a
Here are some basic OMAP test results for Linux v3.9-rc7.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.9-rc7/20130414220303/
Test summary
Build:
FAIL ( 2/16): am33xx_only, omap2plus_defconfig_2430sdp_only
Pass (14/16): n800_multi_omap2xxx
Here are some basic OMAP test results for Linux v3.9-rc6.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.9-rc6/20130410123059/
Test summary
Build:
FAIL ( 2/16): am33xx_only, omap2plus_defconfig_2430sdp_only
Pass (14/16): n800_multi_omap2xxx
Hi
On Wed, 27 Mar 2013, Tero Kristo wrote:
On Tue, 2013-03-26 at 18:43 +, Paul Walmsley wrote:
So what I'd like you to do is:
1. Determine what devices are remaining to be reset and idled on OMAP4
with the bootloader that I use. As far as I know, there are only four
* Tero Kristo t-kri...@ti.com [130327 02:15]:
On Tue, 2013-03-26 at 18:43 +, Paul Walmsley wrote:
So what I'd like you to do is:
1. Determine what devices are remaining to be reset and idled on OMAP4
with the bootloader that I use. As far as I know, there are only four
Here are some basic OMAP test results for Linux v3.9-rc5.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.9-rc5/20130331205513/
Test summary
Build:
FAIL ( 2/16): am33xx_only, omap2plus_defconfig_2430sdp_only
Pass (14/16): n800_multi_omap2xxx
This is a test for Overo with Palo43 expansion, _not_ Tobi. Palo43
doesn't have a dts, but seems to work ok with omap3-tobi.dts, so I used
it as a test.
Not to be merged.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/boot/dts/omap3-tobi.dts | 13 +
1 file
On Tue, 2013-03-26 at 18:43 +, Paul Walmsley wrote:
Hi.
On Tue, 19 Mar 2013, Tero Kristo wrote:
I think you should definitely upgrade your bootloader, the old one you
are using is prone to cause trouble due to bugs it has, and we have no
simple way to workaround the issues it
Here are some basic OMAP test results for Linux v3.9-rc4.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.9-rc4/20130324120244/
Test summary
Build:
FAIL ( 3/16): am33xx_only, omap1_defconfig_5912osk_only
Hi
On Tue, 19 Mar 2013, Santosh Shilimkar wrote:
On Monday 18 March 2013 09:08 PM, Paul Walmsley wrote:
Test summary
Thanks for the summary Paul. A usual, it is quite exhaustive.
Would that it were true. These tests are really only very superficial.
Here are some major
Hi.
On Tue, 19 Mar 2013, Tero Kristo wrote:
I think you should definitely upgrade your bootloader, the old one you
are using is prone to cause trouble due to bugs it has, and we have no
simple way to workaround the issues it causes on kernel side.
So, the kernel should be independent of the
...@lists.infradead.org
Subject: OMAP baseline test results for v3.9-rc1
Here are some basic OMAP test results for Linux v3.9-rc1.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.9-rc1/20130312100243/
Test summary
Build:
FAIL ( 4/16
+ Tero,
On Monday 18 March 2013 09:08 PM, Paul Walmsley wrote:
Here are some basic OMAP test results for Linux v3.9-rc3.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.9-rc3/20130314094808/
Test summary
Thanks for the summary Paul. A usual
On Tue, 2013-03-19 at 14:21 +0530, Santosh Shilimkar wrote:
+ Tero,
On Monday 18 March 2013 09:08 PM, Paul Walmsley wrote:
Here are some basic OMAP test results for Linux v3.9-rc3.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.9-rc3/20130314094808
Here are some basic OMAP test results for Linux v3.9-rc3.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.9-rc3/20130314094808/
Test summary
Build:
FAIL ( 3/16): am33xx_only, omap1_defconfig_5912osk_only
You are not planning any resources to solve this ?
You are listing this for a number of months now. It is time to solve them.
On Mon, Mar 18, 2013 at 5:38 PM, Paul Walmsley p...@pwsan.com wrote:
Here are some basic OMAP test results for Linux v3.9-rc3.
Logs and other details at:
http
201 - 300 of 662 matches
Mail list logo
