Re: PM error: Powerdomain (core_pwddm) didn't enter target state 1
Op 6 jun 2009, om 02:44 heeft Rebecca Schultz Zavin het volgende geschreven: On Fri, Jun 5, 2009 at 10:49 AM, Kevin Hilmankhil...@deeprootsystems.com wrote: Elvis Dowson elvis.dow...@mac.com writes: Hi Kevin, On Jun 5, 2009, at 7:53 PM, Kevin Hilman wrote: It's pretty difficult for me to know what you are actually running by the description above. You've taken a bunch of stuff, put them together in some unspecified way, and are using an unspecified config. Sorry about that, I'm working on an android port to the gumstix overo earth platform. I'm trying to incorporate patches from the android-2.6.29 kernel, tomi's latest dss2 patches and your pm patches, to the linux-omap-2.6 master branch. For initial PM debugging, I highly recommend something closer to what others are developing and testing against. Using the PM branch patches on top of linux-omap master is not yet tested and validated, so I can't give you any support there. For example, you might start from the Android OMAP kernel which is 2.6.29 based and includes the PM branch already. http://android.git.kernel.org/?p=kernel/omap.git Then you'd just have to add your dss2 and Overo stuff there. Dss2 is already there as are Kevin's pm patches. We're actively debugging pm issues there as well. We're happy to take patches against that branch if you feel like contributing back. Ehm, Isn't google supposed to 'contribute back' instead of the original authors? regards, Koen PGP.sig Description: Dit deel van het bericht is digitaal ondertekend
Where do the extra #include mach/board-overo.h come from in linux-omap3-2.6.29.bb recipe?
Hi,
I am using the overo-oe repository.
I have a linux-omap3-2.6.29.bb recipe that pulls in the sources from
the master branch of the linux-omap-2.6 repository, as follows:
SRC_URI = git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-
omap-2.6.git;branch=master;protocol=git \
file://defconfig \
If I run the bitbake linux-omap3-2.6.29 command in the /tool/overo-oe/
tmp/work/overo-angstrom-linux-gnueabi/linux-omap3-2.6.29-r41/git/arch/
arm/mach-omap2/board-overo.c file,
on line 41, there is a #include mach/board-overo.h entry as shown
below.
39 #include asm/mach/map.h
40
41 #include mach/board-overo.h
42 #include mach/board.h
Now, I have in a separate folder, cloned the same repository using the
following command:
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-
omap-2.6.git
However, when I look at arch/arm/mach-omap2/board-overo.c file, the
#include mach/board-overo.h entry is missing
39 #include asm/mach/map.h
40
41 #include mach/board.h
What task is contributing to this extra code, when I run the bitbake
recipe, compared to the original linux-omap-2.6 master branch?
I'm trying to patch in Tomi's DSS2 and Kevin's PM patches, for the
Overo by modifying the linux-omap3-2.6.29.bb recipe. I'm getting stuck
because of this apparent difference, and cannot make modifications to
Tomi's patch files without first being able to manually fast forward
to the appropriate state.
Best regards,
Elvis
# Linux OMAP3 2.6.29 recipie
DEFAULT_PREFERENCE = 1
# Required packages
require linux.inc
# Package information
DESCRIPTION = Linux kernel for OMAP3 processors
KERNEL_IMAGETYPE = uImage
COMPATIBLE_MACHINE = beagleboard|omap3evm|overo
SRCREV = 90e758af52ba803cba233fabee81176d99589f09
PN = linux-omap3
PV = 2.6.29
PR = r41
SRC_URI = git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-
omap-2.6.git;branch=master;protocol=git \
file://defconfig \
SRC_URI_append = \
SRC_URI_append_beagleboard = \
file://beagle-ehci.patch;patch=1 \
SRC_URI_append_omap3evm = \
SRC_URI_append_overo = \
S = ${WORKDIR}/git
--
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
n800 can't mount rootfs
Hello, I tested linux-omap (commit 151c7a7fc) on n800 and it can't mount rootfs anymore. Below is the full bootlog. Unfortunately I don't have time to debug this right now, but I can test patches if needed. [0.00] Linux version 2.6.30-rc8-omap1 (kv...@tikku) (gcc version 4.3.2 (Sourcery G++ Lite 2008q3-66) ) #2 Sat Jun 6 10:28:29 EEST 2009 [0.00] CPU: ARMv6-compatible processor [4107b362] revision 2 (ARMv6TEJ), cr=00c5387f [0.00] CPU: VIPT aliasing data cache, VIPT aliasing instruction cache [0.00] Machine: Nokia N800 [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] OMAP24206 [0.00] SRAM: Mapped pa 0x4020 to va 0xe300 size: 0x10 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 [0.00] Kernel command line: root=1f03 rootfstype=jffs2 [0.00] NR_IRQS:368 [0.00] Clocking rate (Crystal/DPLL/MPU): 19.2/658/329 MHz [0.00] GPMC revision 2.0 [0.00] IRQ: Found an INTC at 0xd80fe000 (revision 2.0) with 96 interrupts [0.00] Total of 96 interrupts on 1 active controller [0.00] OMAP242x GPIO hardware version 1.8 [0.00] PID hash table entries: 512 (order: 9, 2048 bytes) [0.00] OMAP clockevent source: GPTIMER1 at 32000 Hz [0.00] Console: colour dummy device 80x30 [0.00] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) [0.00] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) [0.00] Memory: 64MB 64MB = 128MB total [0.00] Memory: 126392KB available (2896K code, 238K data, 120K init, 0K highmem) [0.00] Calibrating delay loop... 320.37 BogoMIPS (lpj=1253376) [0.00] Security Framework initialized [0.00] Mount-cache hash table entries: 512 [0.00] CPU: Testing write buffer coherency: ok [0.00] net_namespace: 668 bytes [0.00] NET: Registered protocol family 16 [0.00] TUSB 6010 [0.00] kobject (c031e048): tried to init an initialized object, something is seriously wrong. [0.00] [c002c674] (unwind_backtrace+0x0/0xdc) from [c0103654] (kobject_init+0x38/0x70) [0.00] [c0103654] (kobject_init+0x38/0x70) from [c013fbfc] (device_initialize+0x20/0x70) [0.00] [c013fbfc] (device_initialize+0x20/0x70) from [c0143408] (platform_device_register+0x10/0x1c) [0.00] [c0143408] (platform_device_register+0x10/0x1c) from [c000e7a0] (gpmc_onenand_init+0x4c/0x74) [0.00] [c000e7a0] (gpmc_onenand_init+0x4c/0x74) from [c000b13c] (customize_machine+0x18/0x24) [0.00] [c000b13c] (customize_machine+0x18/0x24) from [c00262bc] (do_one_initcall+0x54/0x194) [0.00] [c00262bc] (do_one_initcall+0x54/0x194) from [c00083b8] (kernel_init+0x70/0xe4) [0.00] [c00083b8] (kernel_init+0x70/0xe4) from [c004d498] (do_exit+0x0/0x580) [0.00] [c004d498] (do_exit+0x0/0x580) from [0001] (0x1) [0.00] [ cut here ] [0.00] WARNING: at fs/sysfs/dir.c:487 sysfs_add_one+0x68/0x90() [0.00] sysfs: cannot create duplicate filename '/devices/platform/omap2-onenand' [0.00] Modules linked in: [0.00] [c002c674] (unwind_backtrace+0x0/0xdc) from [c004a974] (warn_slowpath_common+0x48/0x60) [0.00] [c004a974] (warn_slowpath_common+0x48/0x60) from [c004a9c4] (warn_slowpath_fmt+0x24/0x30) [0.00] [c004a9c4] (warn_slowpath_fmt+0x24/0x30) from [c00cfd3c] (sysfs_add_one+0x68/0x90) [0.00] [c00cfd3c] (sysfs_add_one+0x68/0x90) from [c00d02e4] (create_dir+0x48/0x98) [0.00] [c00d02e4] (create_dir+0x48/0x98) from [c00d036c] (sysfs_create_dir+0x38/0x54) [0.00] [c00d036c] (sysfs_create_dir+0x38/0x54) from [c0103948] (kobject_add_internal+0xb8/0x18c) [0.00] [c0103948] (kobject_add_internal+0xb8/0x18c) from [c0103b94] (kobject_add+0x4c/0x5c) [0.00] [c0103b94] (kobject_add+0x4c/0x5c) from [c013ffa4] (device_add+0xac/0x554) [0.00] [c013ffa4] (device_add+0xac/0x554) from [c01433a0] (platform_device_add+0xec/0x144) [0.00] [c01433a0] (platform_device_add+0xec/0x144) from [c000e7a0] (gpmc_onenand_init+0x4c/0x74) [0.00] [c000e7a0] (gpmc_onenand_init+0x4c/0x74) from [c000b13c] (customize_machine+0x18/0x24) [0.00] [c000b13c] (customize_machine+0x18/0x24) from [c00262bc] (do_one_initcall+0x54/0x194) [0.00] [c00262bc] (do_one_initcall+0x54/0x194) from [c00083b8] (kernel_init+0x70/0xe4) [0.00] [c00083b8] (kernel_init+0x70/0xe4) from [c004d498] (do_exit+0x0/0x580) [0.00] [c004d498] (do_exit+0x0/0x580) from [0001] (0x1) [0.00] ---[ end trace 1b75b31a2719ed1c ]--- [0.00] kobject_add_internal failed for omap2-onenand with -EEXIST, don't try to register things with the same name in the same directory. [0.00] [c002c674] (unwind_backtrace+0x0/0xdc) from [c01039d4] (kobject_add_internal+0x144/0x18c) [0.00] [c01039d4]
Re: [RFC][PATCH] OMAP3: add support for 2 SDRAM chip selects (was: Re: Beagleboard rev C memory timings suspend/resume)
On Fri, Jun 5, 2009 at 10:14 PM, Paul Walmsleyp...@pwsan.com wrote: Hi Jean, On Fri, 5 Jun 2009, Jean Pihet wrote: Some notes: - all calls to omap2_init_common_hw have been adapted in the board files. it looks like 2430SDP and Pandora board files are broken since they use only one param. Can that be checked on those boards? Yep, builds with those two boards are broken on the PM branch, and it looks like your patch fixes both. Gražyvdas, looks like Pandora might use 2 SDRAM chipselects also? Yes it does, it uses different part than Beagle rev C (256/512 RAM/NAND instead of 256/256), but RAM portion should be identical I guess. Gražvydas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] Please help in adding ams-delta support to ASoC
Hi Mark, Saturday 06 June 2009 00:45:34 Mark Brown napisał(a): On Sat, Jun 06, 2009 at 12:28:00AM +0200, Janusz Krzysztofik wrote: On the codec frame sync output, I can see ~10kHz symmetric square wave (filled by 50%), the same on modem frame sync input, mcbsp1 status unknown. This shape suggests I2S protocol, not DSP_B as we deduced from the original driver code. Not that this seems like an unreasonable conclusion but it's worth pointing out that the DSP modes only require the leading edge of the frame clock and that the falling edge can occur at any point before the next rising edge is due. Right, thanks. I'm not sure how that could happen, but I was wrong with some of those figures. After looking at the scope several more times I can only confirm that master clock really runs at 2MHz (0,5µs period). Frame sync is rather closer to 8kHz (~125µs period) than previously estimated 10kHz, with the same symmetric (50% fill) shape as before. But bit clock is very different from what I have seen before. It runs at 2MHz in 9µs long packets (18 periods), those are repeated every half period of frame sync (~62µs / 16kHz), ie every frame sync edge, both rising and falling. There is also a signal present on codec data output: 4µs long packets (8 bits each?) every ~62µs (16 kHz). Is it possible that the codec speeks I2S, with 8-bit word, 1 word per frame, 2 channels at 8kHz each? Or 1 channel at 16 kHz? From what I can read in modem documentation, this should rather be one 8-bit channel at 8kHz. Anyway, can the transmission format I have seen ont the oscilloscope be matched against any format that mcbsp can be set with current code? I'm still far from understanding mcbsp, but I wonder what happens if the bit clock stops ater 18th bit while maybe mcbsp expects more. Perhaps this is the cause of dma interrupts not being generated? ... My last idea was to create a generic test driver that would not use any external clocks, ie configured with OMAP_MCBSP_SYSCLK_CLK and SND_SOC_DAIFMT_CBS_CFS, right? That way, it should just work without any hardware support except for mcbsp and maybe we could then definitelly verify if current mcbsp and dma code works on omap1510 or not. Trying to select a template driver to base the test driver on, I felt into these troubles with more and more questions coming on mind... That approach is one I use all the time in driver development - isolate the device as much as possible and confirm that it can at least interoperate with itself. Thanks, I'll follow that way as soon as I get a hint from mcbsp experts. Cheers, Janusz -- 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
Problem creating an openembedded recipe for linux-omap3-2.6.30-rc8
Hi, I'm trying to create a recipe to for linux-omap3-2.6.30-rc6. But I get a fatal: Not a git repository error each time. I've based this off the linux-omap3_git.bb recipe. # Linux OMAP3 2.6.30 recipie DEFAULT_PREFERENCE = 1 # Required packages require linux.inc # Package information DESCRIPTION = Linux kernel for OMAP3 processors KERNEL_IMAGETYPE = uImage COMPATIBLE_MACHINE = beagleboard|omap3evm|overo # Specify the source revision tag SRCREV = 151c7a7fc30cceb58e7999adbf3ad5e0c734b4a7 PN = linux-omap3 PV = 2.6.30 PR = r01 SRC_URI = git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux- omap-2.6.git;branch=master;protocol=git \ file://defconfig \ What am I doing wrong? How do I get the correct SRCREV? If I substitute it with SRCREV=90e758af52ba803cba233fabee81176d99589f09 which corresponds to the linux-omap3-2.6.29, it works, but when I replace it with the commit id, ie. SRCREV = 151c7a7fc30cceb58e7999adbf3ad5e0c734b4a7, from http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=151c7a7fc30cceb58e7999adbf3ad5e0c734b4a7 it doesn't work. Best regards, Elvis -- 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
Solution: N810 keyboard regression
Found the problem with the 2.6.29 N810 keyboard regression in this commit: commit c83702a764c3099df50f215b8e79e07344e34a1a Author: Felipe Balbi felipe.ba...@nokia.com Date: Thu Feb 19 12:29:40 2009 + input: lm8323: get rid of useless debug macro we can use dev_vdbg() which is only true when VERBOSE is enabled. Part of this commit removed the default values for platform parameters, but set the N810's size_y to 8 instead of the earlier default of 12. Changing this to 12 (patch to follow) fixes the keyboard regression. Note, the total keys on the N810 is in fact under 64, so 8x8 seems correct. Not sure why it doesn't work like that in practise. I did notice a curious line in the driver that might (or might not) be related/wrong... drivers/input/keyboard/lm8323.c line 353: int keysize = (lm-size_x 4) | lm-size_y; Shouldn't this be lm-size_x * lm-size_y? Luke -- 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: omap: n810: set lm8323 size_y to 12
From de992fa168685ddd608fca0f54fcfbce2afc2963 Mon Sep 17 00:00:00 2001
From: Luke Dashjr l...@dashjr.org
Date: Sat, 6 Jun 2009 16:35:03 -0500
Subject: [PATCH] arm: omap: n810: set lm8323 size_y to 12
For some reason, this is needed for the shift keys and fghjvbnm
Signed-off-by: Luke Dashjr l...@dashjr.org
---
arch/arm/mach-omap2/board-n800.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-n800.c b/arch/arm/mach-omap2/board-
n800.c
index cb32b61..0a50fd3 100644
--- a/arch/arm/mach-omap2/board-n800.c
+++ b/arch/arm/mach-omap2/board-n800.c
@@ -115,7 +115,7 @@ static struct lm8323_platform_data lm8323_pdata = {
.repeat = 0, /* Repeat is handled in userspace for now. */
.keymap = rx44_keymap,
.size_x = 8,
- .size_y = 8,
+ .size_y = 12,
.debounce_time = 12,
.active_time= 500,
--
1.6.0.6
--
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: Solution: N810 keyboard regression
On Sat, Jun 06, 2009 at 11:51:34PM +0200, ext Luke-Jr wrote: Found the problem with the 2.6.29 N810 keyboard regression in this commit: commit c83702a764c3099df50f215b8e79e07344e34a1a Author: Felipe Balbi felipe.ba...@nokia.com Date: Thu Feb 19 12:29:40 2009 + input: lm8323: get rid of useless debug macro we can use dev_vdbg() which is only true when VERBOSE is enabled. Part of this commit removed the default values for platform parameters, but set the N810's size_y to 8 instead of the earlier default of 12. Changing this to 12 (patch to follow) fixes the keyboard regression. Note, the total keys on the N810 is in fact under 64, so 8x8 seems correct. Not sure why it doesn't work like that in practise. I did notice a curious line in the driver that might (or might not) be related/wrong... drivers/input/keyboard/lm8323.c line 353: int keysize = (lm-size_x 4) | lm-size_y; Shouldn't this be lm-size_x * lm-size_y? Are you sure that was the commit that changed it ? that commit is only getting rid of the debug() macro and making use of dev_vdbg(). If you had just followed git blame you'd see that was already the default value on n810's lm8323 platform_data since the initial import of that code into linux-omap. I do recall testing my patches on n810 before sending them upstream and they were working. How are you testing this ? which tree are you using ? did you try changing that keysize calculation ? Do you see irqs comming? Any debugging messages ? -- 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: Problem creating an openembedded recipe for linux-omap3-2.6.30-rc8
On Sat, Jun 6, 2009 at 11:21 PM, Elvis Dowsonelvis.dow...@mac.com wrote: Hi, I'm trying to create a recipe to for linux-omap3-2.6.30-rc6. But I get a fatal: Not a git repository error each time. How do I get the correct SRCREV? That's not pertinent in linux-omap, ask OE guys: http://wiki.openembedded.net/index.php/Mailing_lists -- Felipe Contreras -- 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: Solution: N810 keyboard regression
On Saturday 06 June 2009 05:42:04 pm Felipe Balbi wrote: Are you sure that was the commit that changed it ? that commit is only getting rid of the debug() macro and making use of dev_vdbg(). Oops, looks like I put the wrong commit at fault. The correct one is: http://git.kernel.org/?p=linux/kernel/git/tmlind/linux- omap-2.6.git;a=commit;h=bb739803dce613ed58e8b35ae52af439ab7496bf If you had just followed git blame you'd see that was already the default value on n810's lm8323 platform_data since the initial import of that code into linux-omap. According to the removed code in the above commit, the default value (outside of and not specified in n810's lm8323 platform_data) was 12. I do recall testing my patches on n810 before sending them upstream and they were working. How are you testing this ? which tree are you using ? I am testing the latest Linux-OMAP kernel on my N810 with Nokia's flasher and --load --boot options. (Userspace is Gentoo) did you try changing that keysize calculation ? No, I wanted to get the opinion of someone who knows how that code actually is supposed to work before I try randomly changing things I don't understand. Do you see irqs comming? Any debugging messages ? There were no debugging messages when the broken keys were pressed, nor did a dbg I added to the driver get triggered for them. Luke -- 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
