RE: [RFC][PATCH] omapfb: Condition mutex acquisition
Aguirre Rodriguez, Sergio Alberto wrote: And then, inside that function, an attempt of acquiring a mutex failed, because it wasn't initialized before trying it: mutex_lock(fbi-mm_lock); I would like to stress that this does cause the kernel to crash during boot up because this is mutex not initialised before it is used. BTW, this problem is found on current Linus tree, and in current l-o tree aswell, and i saw it on my 3430SDP VG5.0.1. I am seeing this too on the beagle-board and so it appears to impact a few omap3 boards. Cheers Jon-- 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: Is there anyway to know the way OMAP got reset
Not sure about the OMAP5912, but at least on the OMAP3430, there is a register (PRM_RSTST) that can logs the global reset sources. Reading this register after the reset should tell you the cause of the last reset. Maybe there is something similar in the OMAP5912. You can look at the ARM_SYSST register on the 5912. This should tell you the source on the reset (external, watchdog, software, etc) that occured. Jon-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 4/4] I2C: OMAP3: PM: (re)init for every transfer to support off-mode
Hi Kevin, Jon, thanks for the clarification. I will fold this change into the upstream-bound I2C changes. Thanks. Tao, in the future please be sure to cite original authors and/or sources when submitting patches to the list. Actually, I should point out that Hu Tao and I worked on this together originally for the omapzoom.org tree. So I should have added Hu Tao's name to this when submitting originally to omapzoom.org. So we should give credit to Hu Tao on this. Sorry about that. Cheers, Jon-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 4/4] I2C: OMAP3: PM: (re)init for every transfer to support off-mode
Hi Kevin, Shouldn't you do a read-modify-write of I2C_CON_REG here? Otherwise, you're loosing any of the other settings in I2C_CON_REG. Not being an expert in the I2C hardware, I'm not sure if it matters, but this doesn't seem quite right due to possible side effects. This is a good question and this exact same issue came up on the omapzoom tree. For the omapzoom tree we ended up not implementing a read-modify-write here. The reason being that omap_i2c_unidle is called at the beginning of every transfer and we are re-configuring the I2C_CON register for every transfer. So when consulting with the TI linux team they said that it is ok to simply write 0 and clear the register here so we start over fresh for each transfer. I was trying to think if there would be any harm in doing a read-modify-write here. Probably not. You would not want the STT bit (generate a start command) to get set, however, this bit should not be set in the first place when entering this function. This change has been implemented in the omapzoom tree and so for you reference please see: http://git.omapzoom.org/?p=repo/omapkernel.git;a=commit;h=ec70a0af52df54638a4fa33fc0dc3d24b1f893f1 Cheers Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 08/11] ARM: OMAP2/3: GPIO: do not attempt to wake-enable
Hi Kevin,
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/plat-omap/gpio.c | 14 --
1 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index d3fa41e..210a1c0 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -921,13 +921,10 @@ static int _set_gpio_wakeup(struct gpio_bank *bank,
int gpio, int enable)
case METHOD_MPUIO:
case METHOD_GPIO_1610:
spin_lock_irqsave(bank-lock, flags);
- if (enable) {
+ if (enable)
bank-suspend_wakeup |= (1 gpio);
- enable_irq_wake(bank-irq);
- } else {
- disable_irq_wake(bank-irq);
+ else
bank-suspend_wakeup = ~(1 gpio);
- }
spin_unlock_irqrestore(bank-lock, flags);
return 0;
#endif
@@ -940,13 +937,10 @@ static int _set_gpio_wakeup(struct gpio_bank *bank,
int gpio, int enable)
return -EINVAL;
}
spin_lock_irqsave(bank-lock, flags);
- if (enable) {
+ if (enable)
bank-suspend_wakeup |= (1 gpio);
- enable_irq_wake(bank-irq);
- } else {
- disable_irq_wake(bank-irq);
+ else
bank-suspend_wakeup = ~(1 gpio);
- }
spin_unlock_irqrestore(bank-lock, flags);
return 0;
#endif
I have been looking into an issue that appears to be related to this. I have
the following questions with regard to this patch.
1). Although, I agree with the above change was there any reason why we did not
add some code to set/clear the appropriate bit in the WKUENA register in this
function? If this function is called via a call to set_irq_wake it will not
modify the WKUENA register. Therefore, we were thinking of something along the
lines of:
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index 17d7afe..895c548 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -941,10 +941,13 @@ static int _set_gpio_wakeup(struct gpio_bank *bank, int
gpio, int enable)
return -EINVAL;
}
spin_lock_irqsave(bank-lock, flags);
- if (enable)
+ if (enable) {
bank-suspend_wakeup |= (1 gpio);
- else
+ __raw_writel(1 gpio, bank-base +
OMAP24XX_GPIO_SETWKUENA);
+ } else {
+ __raw_writel(1 gpio, bank-base +
OMAP24XX_GPIO_CLEARWKUENA);
bank-suspend_wakeup = ~(1 gpio);
+ }
spin_unlock_irqrestore(bank-lock, flags);
return 0;
#endif
2). We have found that a call to request_irq results in a call to the function
set_24xx_gpio_triggering() (for OMAP3430). In addition to configuring the
triggering for a given GPIO, this function is also programming the WKUENA
register. Hence, the wake-up enable is enabled for GPIO without calling
set_irq_wake().
I am not sure if this is the intended behaviour or if drivers should explicitly
be calling set_irq_wake to enable/disable the wake-up.
The other problem with this is that once request_irq is called for a gpio, then
even if we call disable_irq the wake-up event is not cleared. So this means
that a gpio event will still wake-up the device without the gpio being enabled
and because the gpio is disabled the event will never be cleared and hence will
prevent retention.
So should the wake-up event only be enabled/disabled by a call to
set_irq_wake() or should we make sure that calling disable_irq in turn calls
gpio_mask_irq and make sure this clears the wake-up event?
Cheers
Jon
--
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: ARM: CONFIG_FRAME_POINTER
Hi Kevin, Did a similar patch for ARM get you a booting kernel using 2007q3? Yes, the changes needed are the following to get it booting with 2007q3 on the omap3430sdp were the following. Unfortunately it took 4 hours to figure this out and so wanted to share. Do you think that the below change should be incorporate in the arch/arm/Kconfig? Cheers Jon diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 079aa6a..c61bafb 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -18,6 +18,7 @@ config ARM select HAVE_KRETPROBES if (HAVE_KPROBES) select HAVE_FUNCTION_TRACER if (!XIP_KERNEL) select HAVE_GENERIC_DMA_COHERENT + select ARCH_WANT_FRAME_POINTERS help The ARM series is a line of low-power-consumption RISC chip designs licensed by ARM Ltd and targeted at embedded applications and diff --git a/arch/arm/configs/omap_3430sdp_defconfig b/arch/arm/configs/omap_3430sdp_defconfig index b686f34..1bff450 100644 --- a/arch/arm/configs/omap_3430sdp_defconfig +++ b/arch/arm/configs/omap_3430sdp_defconfig @@ -1387,6 +1387,7 @@ CONFIG_DEBUG_INFO=y # CONFIG_DEBUG_MEMORY_INIT is not set # CONFIG_DEBUG_LIST is not set # CONFIG_DEBUG_SG is not set +CONFIG_ARCH_WANT_FRAME_POINTERS=y CONFIG_FRAME_POINTER=y # CONFIG_BOOT_PRINTK_DELAY is not set # CONFIG_RCU_TORTURE_TEST is not set -- 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: ARM: CONFIG_FRAME_POINTER
Hi Richard, If you follow the link and look at attached png you clearly see compiler issue. I also provided a hack which allowed it to work. Probably FRAME pointer changes code generation to get rid of issue. Right, with CONFIG_FRAME_POINTER defined the following compiler flags are defined in the top-level Makefile. ifdef CONFIG_FRAME_POINTER KBUILD_CFLAGS += -fno-omit-frame-pointer -fno-optimize-sibling-calls else KBUILD_CFLAGS += -fomit-frame-pointer Endif I believe that this was the difference. Cheers Jon -- 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: ARM: CONFIG_FRAME_POINTER
Hi Richard, Ok so -fno-optimize-sibling-calls is busted in older compiler. I am not sure that -fno-optimize-sibling-calls is busted as it appears that with this option it worked with the old compiler. However, I should note that I never confirmed if the issue was caused by having -fno-omit-frame-pointer versus -fomit-frame-pointer or the omission of the option -fno-optimize-sibling-calls. So basically, I am saying that having the following allows it to work. KBUILD_CFLAGS += -fno-omit-frame-pointer -fno-optimize-sibling-calls Cheers Jon -- 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: ARM: CONFIG_FRAME_POINTER
Hi Kevin, Yes. Do you mind sending a patch to linux-arm-kernel? Sure. Does Russell King maintain a git tree for linux-arm or do you have any advice which tree I should use to base a patch on for the linux-arm folks? Cheers Jon -- 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: ARM: CONFIG_FRAME_POINTER
Hi Kevin, Just base it at Linus' master branch or the latest -rc tag. Thanks. Patch sent. My post appears to be in a holding location as I am not a member of the linux-arm mailing list. I will let you know if I get any feedback. By the way, I found out that the real culprit of this problem was the following change: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=64dec40ddee9d36d7b83f8a0513fdeaffe260a0e;hp=a3c6018e565dc07cf3738ace6bbe412f97b1bba8 Cheers Jon -- 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
ARM: CONFIG_FRAME_POINTER
Hi All, I have been doing some testing with the latest linux-omap kernel on the 3430sdp and the kernel appeared to hang on start-up during the delay loop calibration. After debugging this I found that this was being caused because there was a difference in the compilation flags being used when compiling this kernel version and an earlier kernel version. Please note that I am using the code sourcery arm2007q3 compiler version (gcc 4.2.1) which is old I know! Investigating further I noticed that the source of the different kernel compilation flags was due to the fact that kernel option CONFIG_FRAME_POINTER was missing from the .config. Although this is declared in the defconfig for the 3430sdp but it was not getting copied over to the .config. Looking at the lib/Kconfig.debug it appears that there is a new option added back in January called ARCH_WANT_FRAME_POINTERS [1]. And only if this new option is defined in the ARCH Kconfig will CONFIG_FRAME_POINTER be used. Today this is not defined for ARM. I know this is the linux-omap list and not linux-arm but wanted to see if anyone had any comments/inputs about this and whether I should be using a newer compiler. [1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=64dec40ddee9d36d7b83f8a0513fdeaffe260a0e;hp=a3c6018e565dc07cf3738ace6bbe412f97b1bba8 Cheers Jon -- 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: linux-omap pm branch
Hi Sanjeev, 1). What omap3430 board(s) are being using to validate the pm branch functionality? [sp] I believe most common are omap3evm and beagle. Do you know if we are doing any validation on the SDP3430 or Zoom boards? Using defconfig for the SDP3430 the kernel failed to boot. I found that this was due to the MUSB driver and SmartReflex. Disabling these allows it to boot. 2). Is there a list of pm features are currently supported/functional for omap3430? For example, cpuidle, cpufreq, retention, off-mode, smart-reflex, suspend/restore, etc. [sp] All of above - though all drivers may not support power management. Hence you may see some failures scenarios esp. with off mode. Off mode does not appear to be working currently on the SDP. It hangs when enabled. Is off-mode stable on any of the boards? 3). Are there any userspace tools (such as powertop) that are recommended for monitoring power states? [sp] You can definitely use powertop. Is this what everyone is using or is there any other diagnostics available through the proc or sys file-systems? Powertop is fine but I am curious how people are validating which c-states are being entered. Cheers Jon -- 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: OMAP1: mcbsp clocks
Russell King wrote on : A question about OMAP1 mcbsp clocks. From what I understand from the OMAP5912 clock architecture documentation, mcbsp1 and mcbsp3 have two clocks: 1. interface clock switchable between DSPPER_CK and DSPXOR_CK. 2. a function clock which could be DSPXOR_CK (mcbsp3), and CK_DPLL1OUT or MCBS1_CLKS (mcbsp1). However, the code in mach-omap1/mcbsp.c associates both mcbsp1 and 3 unconditionally with all of: DSP_CK, API_CK and DSPXOR_CK. As far as I can see, DSP_CK (for the DSP processor) and API_CK (for system dma) have nothing to do with mcbsp1,3. So, the question is why is it this way, and what would be the effect of correcting this so that both of these mcbsp units are associated with their proper interface and function clocks? On the OMAP1 architecture there are peripherals that are located on the ARM peripheral bus and peripherals that are located on the DSP bus. The McBSP1 and McBSP3 are located on the DSP peripheral bus and McBSP2 is located on the ARM peripheral bus. The ARM has access to some of the DSP peripherals via the MPUI (aka API - the name was changed to avoid confusion with sofware term). The API or 'ARM Peripheral Interface' (if I recall the abbreviation correctly) is really just the ARM's internal interface to peripherals on the DSP's bus. However, in order for the ARM to access peripherals via the MPUI, the MPUI clock (API_CK) must be enabled. This is the difference between McBSP2 and McBSP1/3. So for McBSP1/3 you definitely need to have the MPUI clock enabled. On OMAP2/3 devices the internal bus architecture was change significantly so you don't have as many crazy dependencies. Hope this helps. Cheers Jon -- 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: OMAP1: mcbsp clocks
Tony Lindgren wrote on Friday, January 23, 2009 11:54 AM: * Russell King - ARM Linux li...@arm.linux.org.uk [090123 09:43]: On Thu, Jan 22, 2009 at 05:17:28PM -0800, Tony Lindgren wrote: Basically we currently cannot use virtual clocks because of this and the fact that the parent of the virtual clock may not be known as pointed out by Paul Walmsley. One other thing I'd like to confirm is how the kernel treats the OMAP5912. OMAP5912 is interesting to me at the moment because it seems that all the information on it is freely available. I don't know about the others. However, it would be useful to know how the kernel treats this - iow, which of the four categories for OMAP1 SoCs - 310, 730, 1510, 1610. 5912 = 1611b = 16xx. Then 1710 is quite similar. Right, the OMAP5912 started off life as the 1611, but 1611 involved into the 1621. So really 5912 = 1621. There are a couple differences between the 1610 and 1621, one of the main being the size of the internal RAM. Of course, if someone knows (or can send me, maybe Richard W?) where there's a similar document to spru751a for the clock architecture for these other CPUs (and OMAP2420, OMAP2430, OMAP3430, etc) it would be most useful. Unfortunately, most of the original devices have NDA restrictions which is a royal pain in the neck especially for people in the open-source community who would like to develop with these. I am sure this infuriates many. Please don't shoot the messenger! I am disappointed it is still that way for some of these parts. The good news is that for OMAP3 we appear to be getting our act together here. I have some links on my webpage to the docs: http://www.muru.com/linux/omap/ Tony, I see you have a link on your website to the OMAP3525. The OMAP3530 == OMAP3430, I would recommend that you point people to the following product folder for documentation: http://focus.ti.com/docs/prod/folders/print/omap3530.html The OMAP3525 has a reduced feature set...see the following page for an overview of the OMAP35xx series: http://wiki.omap.com/index.php?title=OMAP3_Overview Cheers Jon -- 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: OMAP1: mcbsp clocks
Alejandro Blanca G wrote on : First, I'm relatively new to the list and I'm still catching up with the etiquette to follow. So, if I break it somehow, please do let me know. It's not my intention to do so. No problem, but you may wish to post under a new subject, although I guess we did go off the main topic :-) Now, I know that the OMAP16xx line of processors is composed (as far as I know) by the following: * 1610 * 1611 * 1621 * 1623 Does anybody know about the differences between them and / or about a document explaining them? This is testing my memory now, but here is the way I recall it... OMAP1610 was the original device and to be honest all these devices have the same peripheral features. The OMAP1610 only has 16KB of internal RAM where as the other 3 (1611, 1621, 1623) all have 250KB of internal RAM. The OMAP1611 was rev'ed and a few improvements were made. Now from the user point of view not too many changes were made (ie. no new peripherals that I recall) but there were some new registers added in some modules. The OMAP1611 became the OMAP1621 after it was revised. So if you have a OMAP1611 this was the original device. The OMAP1623 is simply a OMAP1621 with stacked DDR memory. Hope this helps. Jon -- 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: OMAP1: mcbsp clocks
Alejandro Blanca G wrote on : So, if I understood correctly, the internal RAM you're talking about is the one coming with the OMAP itself. Additionally, you could count on the RAM coming with the board and the internal caches available, right? Or are you using the term internal RAM to refer to the L1 / L2 caches (if any)? Yes, the internal RAM being the SRAM inside the OMAP. The SRAM is accessible by the ARM and DSP cores. This is should not be confused with the ARM or DSP caches, these are separate. Regarding peripheral support, then this means that the driver support should be basically the same among revisions, right? Yes they will be pretty much the same. Actually, here is what I recommend... The initial OMAP5912 devices were in fact OMAP1611 and the production version is a OMAP1621. If you refer to the OMAP5912 documentation on the below webpage, you will see in some documents that it states not available on XOMAP5912 or POMAP5912 in certain areas. The XOMAP5912 and POMAP5912 are indeed OMAP1611 devices. So if OMAP1611 is what you have then anything that says not available on XOMAP5912 or POMAP5912 will also be not available on the OMAP1611. You will find some examples of this in the OMAP5912 Subsystem User Guide: http://focus.ti.com/dsp/docs/dspsupporttechdocsc.tsp?sectionId=3tabId=409familyId=325abstractName=spru749b All OMAP5912 documentation can be found here: http://focus.ti.com/docs/prod/folders/print/omap5912.html Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC] Port TI DSP BRIDGE for a new dedicated branch in linux-omap
Hi Felipe, What TI has offered so far is code, and the comments have been on this code. You seem to want maintainers to understand that this is code that works today, but I don't think the code can be tested right now since the tools (CE/Link) are not available out in the open. Err, I got confused about the CE/Link, I meant the xdctools... or whatever is needed to compile DSP nodes. AFAIK the DSP compiler is not enough. Yes, today certain components (such as codec-engine, dspbios) do require the xdctools. There are a couple components that don't (such as DSPLink) but these will probably use xdctools in the future too. Anyway, just in case you have not seen there is a TI DSP Wiki page now for all things DSP and a lot of the tools/software are available through here. However, not all is source. See below: TI DSP Wiki http://tiexpressdsp.com/ With regard to the xdctools, TI has kicked off an open-source project to for these. Details can be found here: http://wiki.eclipse.org/DSDP/RTSC It may seem a bit messy right now (with bridge, link, etc), but hopefully all of this will get straighten out as we progress. Cheers Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP5912: Fix omap5912 osk alsa driver [1/2]
Hi Tony, Jarkko, Let's rather get rid of the direct mcbsp register tinkering from drivers and use following instead: Workaround for omap_mcbsp3_aic23_clock_init not adding new McBSP API would be to put those registers into struct omap_mcbsp_reg_cfg and call omap_mcbsp_config. You know I am curious which omap board this function was added for? Going back and reviewing the OMAP5912 OSK schematics the 12MHz clock for the aic23 is provided from the OMAP5912 MCLK and not the McBSP3. So my feeling is that short term this should definitely be moved from the aic23 driver to a board specific file because I am not sure that this is even necessary for OMAP5912. And, really the best solution would be to add support to sound/soc/omap/ for various codecs rather than try to keep the old drivers working. I propose this as well. Luckily it seems that someone is already developing ASoC driver for TLV320AIC23B. Then native ALSA SoC support for OSK require only to develope new machine driver in sound/soc/omap/. Sounds good. Forgive me here as I am not familiar with how the organisation is planned. So my original patches were to just resolve compiler issues...quick but dirty. However, this seems much nicer long-term. Cheers Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: OMAP AIC23
Look like this should be doable. but we will have two read/write defs in header. one will be Macro and other will be function, both mapping to same code. Correct. As well as moving the macro definition, I did add a prototype for the read and write function to the header too. Check out the patch I submitted. Compiling fine now for me. Cheers Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: OMAP AIC23
Hi Chandra, i have a question, why a client is modifying mcbsp registers. There is a mcbsp config function (omap_mcbsp_config) exported which you can use to configure mcbsp registers. if its an absolute necessity you can use omap_mcbsp_read and omap_mcbsp_write function. which are defined in arch/arm/plat-omap/mcbsp.c. but you need to pass full register name, like OMAP_MCBSP_REG_SPCR1 instead of just SPCR1 ( 'SPCR1' undeclared error). Looking at the source file drivers/i2c/chips/tlv320aic23.c the function omap_mcbsp3_aic23_clock_init() is enabling the McBSP sample rate generator in order to generate the 12MHz system clock to the aic23. I believe that this needs to be done in order to configure the aic23. The good news is that there appears to be a simple fix. All we need to do is move the definitions of the macros OMAP_MCBSP_READ and OMAP_MCBSP_WRITE from mcbsp.c to the header include/asm-arm/arch-omap/mcbsp.h Doing this and making a couple other minor changes I am now able to build the alsa driver successfully for the omap5912 osk. I will submit a patch to the list. Let me know what you think. Cheers Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP5912: Fix omap5912 osk alsa driver [0/2]
This patch series fixes the omap5912 osk alsa driver. --- arch/arm/plat-omap/mcbsp.c|5 - include/asm-arm/arch-omap/mcbsp.h |8 sound/arm/omap/omap-alsa-dma.c|2 +- 3 files changed, 9 insertions(+), 6 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP5912: Fix omap5912 osk alsa driver [1/2]
Move OMAP_MCBSP_READ and OMAP_MCBSP_WRITE macro definitions from arch/arm/plat-omap/mcbsp.c to include/asm-arm/arch-omap/mcbsp.h. Signed-off-by: Jon Hunter [EMAIL PROTECTED] --- arch/arm/plat-omap/mcbsp.c|5 - include/asm-arm/arch-omap/mcbsp.h |8 2 files changed, 8 insertions(+), 5 deletions(-) diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c index 70944a5..214136e 100644 --- a/arch/arm/plat-omap/mcbsp.c +++ b/arch/arm/plat-omap/mcbsp.c @@ -46,11 +46,6 @@ int omap_mcbsp_read(u32 io_base, u16 reg) return __raw_readl(io_base + reg); } -#define OMAP_MCBSP_READ(base, reg) \ - omap_mcbsp_read(base, OMAP_MCBSP_REG_##reg) -#define OMAP_MCBSP_WRITE(base, reg, val) \ - omap_mcbsp_write(base, OMAP_MCBSP_REG_##reg, val) - #define omap_mcbsp_check_valid_id(id) (id omap_mcbsp_count) #define id_to_mcbsp_ptr(id)mcbsp_ptr[id]; diff --git a/include/asm-arm/arch-omap/mcbsp.h b/include/asm-arm/arch-omap/mcbsp.h index 8fa89c2..cf39ef1 100644 --- a/include/asm-arm/arch-omap/mcbsp.h +++ b/include/asm-arm/arch-omap/mcbsp.h @@ -50,6 +50,14 @@ #define OMAP34XX_MCBSP4_BASE 0x49026000 #define OMAP34XX_MCBSP5_BASE 0x48096000 +void omap_mcbsp_write(u32 io_base, u16 reg, u32 val); +int omap_mcbsp_read(u32 io_base, u16 reg); + +#define OMAP_MCBSP_READ(base, reg) \ + omap_mcbsp_read(base, OMAP_MCBSP_REG_##reg) +#define OMAP_MCBSP_WRITE(base, reg, val) \ + omap_mcbsp_write(base, OMAP_MCBSP_REG_##reg, val) + #if defined(CONFIG_ARCH_OMAP15XX) || defined(CONFIG_ARCH_OMAP16XX) || defined(CONFIG_ARCH_OMAP730) #define OMAP_MCBSP_REG_DRR20x00 -- 1.4.4.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP5912: Fix omap5912 osk alsa driver [2/2]
Corrected header file path in file sound/arm/omap/omap-alsa-dma.c. Signed-off-by: Jon Hunter [EMAIL PROTECTED] --- sound/arm/omap/omap-alsa-dma.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sound/arm/omap/omap-alsa-dma.c b/sound/arm/omap/omap-alsa-dma.c index d263933..baafacf 100644 --- a/sound/arm/omap/omap-alsa-dma.c +++ b/sound/arm/omap/omap-alsa-dma.c @@ -64,9 +64,9 @@ #include linux/dma-mapping.h #include linux/io.h #include linux/uaccess.h +#include linux/semaphore.h #include asm/hardware.h -#include asm/semaphore.h #include asm/arch/dma.h #include asm/arch/mcbsp.h #include asm/arch/omap-alsa.h -- 1.4.4.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: undefined instruction
then i changed the filename and the tftpboot transfer started. But on the mid-way it complains undefined instruction. could some one please tell me where the problem is? thank you. How big is the file that you are attempting to download over tftp? U-boot executes in the upper part of the RAM and so if your file is too big, then there is a good chance you are overwriting u-boot which would cause u-boot to crash eventually. U-boot does not protect against this. This would be a potential cause of an undefined instruction exception. Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Latest git kernel won't build with muru.com N8x0 patch 2
CC drivers/cbus/retu-wdt.o drivers/cbus/retu-wdt.c: In function 'retu_wdt_ioctl': drivers/cbus/retu-wdt.c:204: error: implicit declaration of function 'omap_readw' make[2]: *** [drivers/cbus/retu-wdt.o] Error 1 make[1]: *** [drivers/cbus] Error 2 make: *** [drivers] Error 2 An implicit declaration of function error would imply that you are missing the appropriate header function. Hence, the compiler sees this as a declaration of a new function, instead of a function that has already been defined elsewhere. I removed lines 203-205 of drivers/cbus/retu-wdt.c (after patching); it seems to have fixed the problem for me. Instead of removing the above lines, try including the header asm/io.h in the file drivers/cbus/retu-wdt.c. For example: #include asm/io.h Cheers Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Booting OMAP5912 with 2.6.8 kernel
My intension here is to use filesystem flashed onto the flash memory at 0x100 location. When tried booting with Montavista kernel which comes with CD, it works fine. But fails when tried booting with custom kernel compiled using 2.6.8-rc3_080804.tar.bz2 package from TI site. True that it could not find root file system which is placed at 0x100 of flash. But what could be the root value to make it work? does manual partition of the FLASH memory is required ? If you are trying to use the 2.6.8 kernel with the default file-system that comes with the OSK, I don't believe this will work. The montavista kernel that comes with the OSK is a 2.4 kernel and not 2.6. Therefore, you should create a new flash file-system for the 2.6.8 kernel. Check out the OSK wiki page: http://elinux.org/OSK In particular see the OSK5912 Newbie Guide that provides details on how to create a flash file-system. http://www.capgo.com/Resources/SoftwareDev/osk-newbie-guide.pdf Also, please copy the list. You can also search the mailing list on the following page, as there has been a lot of discussion with regard to the OSK in the past. http://dir.gmane.org/gmane.linux.ports.arm.omap Cheers Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
