Question OMAP3 and PM
I'm interested in the PM branch latest and greatest that is working for the beagleboard and the omap3evm. I clone these git for master branch (2.6.30-rc7) and compile and try without success. http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=summary http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=summary Beagleboard image was freezing after displaying uncompressed with success for both branch. Mistral image was displaying more stuff but no success. I will email the output later if asking. First, I'm interested to know which tag/branch should I use? kernel.org is at 2.6.29.4 for stable? since rc is dev tag I imagine that the one I'm looking for is v2.6.29-omap1. Do that branch have the OFF mode, smartrelfex and suspend and resume working? I want to measure the power consumption of those 2 board. Thx for helping me out. Best Regards kap -- 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
OMAP: sporadic hard lock-up when GPIO interrupts occur too fast (with preempt-RT and PREEMPT_HARDIRQ)
Hi everyone, I'm trying to debug a problem with GPIO interrupts on my OMAP3503 (Gumstix Overo) platform with kernel 2.6.29.4-rt16-omap1. While this is a sporadic lock-up, I haven't been able to reproduce it when PREEMPT_HARDIRQ is disabled. I think it might have something to do with this patch (which is applied BTW): http://patchwork.kernel.org/patch/16046/ And see this thread: http://markmail.org/message/aaqpk5jztrrypsxz Sometimes, I see a spurious IRQ message like this: Spurious irq 95: 0xffdf, please flush posted write for irq 31 that the above patch is supposed to fix, just before the system locks up. Is it possible that the interrupt handler is getting preempted between acknowledging the interrupt and the 'flush posted write', and meanwhile another interrupt from the same bank occurs? To check this hypothesis, I built the kernel with CONFIG_PREEMPT_DESKTOP=y # CONFIG_PREEMPT_RT is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_SOFTIRQS=y CONFIG_PREEMPT_HARDIRQS=y which gives a /proc/irq///threaded flag. When I tried disabling threading on irqs 246-249 (which are the virtual irqs for the problematic GPIO interrupts), the problem still occured. I'm not sure how to disable threading or preemption on the intermediate ISR (gpio_irq_handler() at arch/arm/plat-omap/gpio.c:959) which determines which GPIO in the bank caused the interrupt and spawns the virtual interrupts. Any ideas for debugging or narrowing down on the cause? Many thanks, Hugo -- 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: LDP support
* Russell King - ARM Linux [090603 15:34]: > On Thu, Jun 04, 2009 at 12:39:55AM +0300, Imre Deak wrote: > > I updated the omapfb-upstream branch on > > git://koowaldah.org/people/imre/linux-2.6-fb, > > if these are ok with you I'll post them on the fb list. > > Just be aware that Linus released -rc8 on Tuesday, and said that will > be the final rc before the merge window opens. So I reckon there's less > than a week to the merge window opening. Imre, few comments after browsing through your patches: "omapfb: Add support for MIPI-DCS compatible LCDs" seems to depend on drivers/cbus which is not yet merged. Please leave out those parts so it compiles. Then we can add the missing functions once drivers/cbus is merged in the future. "omapfb: dispc: Add OMAP3 support" should no longer be needed, this got already fixed with clkdev patch 005187eecaa400b4b43d9f640fbde9fcc50f37c1 in mainline. "omapfb: Fix coding style / remove dead line" has a typo in Russell's name. > That's not a suggestion that people should panic and sent their half > complete patches out for merging. [for the wider audience] Looking > at the amount of unread email from the last two days, I think I have > sufficient quantity to keep me occupied until the merge window does > open. Just FYI, I don't think we have much anything more heading your way this merge window from the omap land. Just the second clock fixes series from Paul, and the omap4 SMP patches are still pending. Regards, Tony -- 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: LDP support
On Thu, Jun 04, 2009 at 12:39:55AM +0300, Imre Deak wrote: > I updated the omapfb-upstream branch on > git://koowaldah.org/people/imre/linux-2.6-fb, > if these are ok with you I'll post them on the fb list. Just be aware that Linus released -rc8 on Tuesday, and said that will be the final rc before the merge window opens. So I reckon there's less than a week to the merge window opening. That's not a suggestion that people should panic and sent their half complete patches out for merging. [for the wider audience] Looking at the amount of unread email from the last two days, I think I have sufficient quantity to keep me occupied until the merge window does open. -- 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
[ANNOUNCE] TI dspbridge Omapzoom tree
Hi, The new dspbridge omapzoom tree has been set in place, you can clone it from: git://dev.omapzoom.org/pub/scm/tidspbridge/kernel-dspbridge.git or http://dev.omapzoom.org/pub/scm/tidspbridge/kernel-dspbridge.git In this tree you will find the latest set of TI DSP BRIDGE patches, which are based on linux-omap kernel tree. The branch layout is as follows: mastertracking L-O master bridge-pm-2.6.28 branched from omap-2.6.28, pulled linux-omap-pm pm-2.6.28 on top, + bridge patches bridge-pm-2.6.29 branched from L-O pm branch + bridge patches Special thanks to Hiroshi Doyu and Ameya Palande, and to all who have contributed with comments and patches. For the new dspbridge tree, I took the logical set of patches which was ported long time back[1] along with the new stuff, reworked what we had to migrate to this baseline and already sent the patches to the list, those patches can be found in the new tree. Best Regards, Omar --- [1] http://marc.info/?l=linux-omap&m=121878286205991&w=2 -- 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] OMAP2/3 Avoid GPIO pending irq status been set after irq_disable
Kevin, See below for more comments/explanations: > > I still think there at least a couple different problems going on and > I think you are addressing some symptoms but not the root cause. > I understand that combine these two changes in one patch may cause Some confusion, so this time I separate into two patchs and they are attached. I agree that I didn't describe the issue more in detail, but I think the Second patch (also the original one I intended to make) does address The root cause and not workaround the symptoms. See below for the problem in detail. > It would help if you described in more detail the problem(s) you are > having and which part of this patch fixes which part of your > problem(s). > I met this problem when I am using a touch controller that has a firmware That does not work in a graceful way, the controller seems to report Touch event very frequently and seems the HW is too sensitive, this does not mean the issue Is caused by the controller, I think this just make the issue exposed more easily. The controller is using a GPIO to assert interrupt to OMAP, the interrupt Line will be dirven low until the OMAP driver reads out the data through I2C. On OMAP side, we configure the GPIO interrupt pin to be low level detect, The issue is, after the touch driver calls irq_disable, since it is empty unless Set the IRQ_DISABLED flag, so next time only the generic handler function handle_level_irq is called, this handler just ack to OMAP GPIO IRQ that is To clear the IRQ status and mask the GPIO on OMAP side, but since NO Touch driver IRQ action is called, so the touch Controller can not gets acknowledged, then the interrupt line will be always driven low by the external controller, if we check the IRQ status for that GPIO pin, we will find The IRQ is always set. This will prevent PER enterring RET/OFF state since GPIO Will not acknowledge the IDLE request. The main purpose of the second patch Is to clear the level/edge detect registers for OMAP GPIO when their IRQ is Disabled, this can ensure the GPIO IRQ status will not be set and prevent LPM. > This GPIO interrupt handling code is very sensitive to changes so we > need to really understand your problem before making changes here. > I totally undersand this and I am glad to have a thorough understanding By everyone and maybe we can find a better solution for this issue. But now seems I need make you guys understand the issue first. :-) > Also it's quite possible there are bugs in your driver as well. Is > there any chance you can reproduce this on a public platform such as > the 3430SDP using the PM branch? > > If I use the PM branch on SDP, enable the touchscreen and go into > suspend, I do not see the GPIO driver keeping the system out of > retention. In addition, if I add > > enable_irq_wake(gpio_to_irq(ts_gpio)); > > to the board init code, I can also use the touchscreen as a wakeup > source and it does not prevent retention so you should be able to > reproduce there. You can say that my touch controller is somehow buggy since it reports Events very frequently and will always keep the interrupt line low unless it is Acknowledged by the touch driver, but I think more important is we can not Expect and *assume* all the peripherals to work as well as we expected, The OMAP GPIO framework should be robust enough to handle such cases Since it will act as a risky hole for PM on OMAP. I understand that this will be hard to reproduce if the Touch controller works Very gracefully, even for us, we do not see the problem on some other HWs Since the controller will not report events/interupts so frequently. Enable_irq_wake and disable_irq_wake is working regardless of irq enabled or disabled Since on OMAP3, they are using IOPAD wakeup(If PER is in RET/OFF) or module level wakeup(if PER is ACTIVE), and the code is handled by gpio suspend/resume functions, see more below. > > 1: irq mask/unmask are typically used by the IRQ handling framework > > or CHIP IRQ handler to disable and enable IRQ during the IRQ handing > > procedure; > > The mask/unmask are also used by the lazy disable feature of the > generic IRQ code. More on this below... I tried to figureout but didn't find any comment on what is the issue fixed By this lazy irq disable or what we can benefit from this lazy irq disable, Seems the change is mainly for x86. > > The driver's ISR should *never* be called after disable_irq(). > However, the actual interrupt may still fire. Here is what is > _supposed_ to happen. > snipped. > You could try the patch below[1] which will warn if the triggering > is not setup properly for a given GPIO IRQ. This would result > in a broken lazy disable. > I can confirm, the irq actions is not called in my case after irq_disabled Is called even without my patch, but the patch is not related With the IRQ handling, what it tries to do is to simply find a place To clear the level/edge detect settings. > Thi
Re: LDP support
On Mon, Jun 01, 2009 at 06:00:33PM +0200, ext Tony Lindgren wrote: > * Russell King - ARM Linux [090531 14:25]: > > On Tue, Apr 28, 2009 at 03:42:37PM -0700, Tony Lindgren wrote: > > > * Russell King - ARM Linux [090428 15:07]: > > > > Tony, et.al., > > > > > > > > Any ideas when more LDP support will be pushed into mainline (such as > > > > the framebuffer support)? > > > > > > I'll be looking at the board-*.c patches for the next merge window > > > hopefully this week or next week. > > > > > > Looks like LDP keyboard, touchscreen & RTC are pretty much ready > > > to go. Then the MMC has some regulator updates, but AFAIK the MMC > > > should work OK already. > > > > > > For the framebuffer, Imre and Tomi know the status the best, so > > > I've added them to Cc. > > > > > > Imre has been meaning to send a bunch of drivers/video/omap changes > > > to the fbdev list for a while now and LDP framebuffer may depend on > > > those. Imre, any news on the status of sending the fb patches > > > upstream? > > > > > > Then there are the upcoming DSS patches from Tomi, but those still > > > need some work before they're ready to go. > > > > Okay, now that I've merged your tree, we've moved a few steps forward but > > a couple of steps backward with LDP support: > > > > 1. LDP LCD platform device added > > 2. GPIO keyboard platform data added > > 3. TWL4030 keyboard platform data added > > 4. TSC2046 touchscreen platform data added > > 5. MMC has regressed - no sign of the driver initializing, not even an > >error message from it, so I can't boot to check what the status of > >these are. > > Do you have CONFIG_REGULATOR set in your .config? That seems to be missing > from arch/arm/configs/omap_ldp_defconfig. > > > 6. do ___NOT___ (underscored in triplicate and 500ft high letters) enable > >ARM errata 460075 - it solidly prevents the kernel booting on LDP. > >(it's taken many hours to debug that.) > > > > However, things that still seem to be missing: > > > > 1. GPIO keyboard (presumably) needs to be enabled in omap_ldp_defconfig > > Anybody with an LDP care to update the omap_ldp_defconfig? No LDP here. > > > 2. No TWL4030 keyboard driver merged (not even in linux-next) > > 3. No LDP LCD driver merged > > 4. No OMAP3 video driver > > For 3 & 4, I know Imre has the patches ready to go.. Imre, have they been > posted to the fb list? Not yet, I updated the patches, removing the board file changes as we agreed. Also they don't include the latest HWA742 clock changes, which should be already in the omap-fixes queue. Other than these the patches have the following changes based on the omap-fixes version of the driver: - checkpatch fixes - logically related commits merged, keeping the authorship info - commit removed: omapfb: remove wrong scale call for gfx_plane This can't be correct, as it disables scaling completely. I updated the omapfb-upstream branch on git://koowaldah.org/people/imre/linux-2.6-fb, if these are ok with you I'll post them on the fb list. --Imre -- 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/RFC] ARM: OMAP: Initialize MADC clock divider and clock
* Steve Sakoman [090603 13:10]: > Tony, > > I noticed your comment requesting all twl4030 patches be submitted to > mainline. I assume this patch falls into that category too? Yeah, we should try to make all the patches against mainline now. > Also for those listening in -- no comments on this patch yet! Does > that mean it looks good? ;-) You should send it to: $ grep -a7 "MULTIFUNCTION DEVICES" MAINTAINERS P: Samuel Ortiz M: sa...@linux.intel.com L: linux-ker...@vger.kernel.org T: git git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6.git S: Supported F: drivers/mfd/ Tony > Steve > > On Sat, May 30, 2009 at 6:40 AM, Steve Sakoman wrote: > > Though the comment in clocks_init claims to initialize the MADC > > clocks, it wasn't actually being done. This patch implements minimal > > MADC clock initialization. > > > > Compile/run tested on Overo (prior to patch MADC access would always > > timeout) > > > > diff --git a/drivers/mfd/twl4030-core.c b/drivers/mfd/twl4030-core.c > > index 769b34b..c5ca36d 100644 > > --- a/drivers/mfd/twl4030-core.c > > +++ b/drivers/mfd/twl4030-core.c > > @@ -159,6 +159,7 @@ > > > > /* Few power values */ > > #define R_CFG_BOOT 0x05 > > +#define R_GPBR1 0x0C > > #define R_PROTECT_KEY 0x0E > > > > /* access control values for R_PROTECT_KEY */ > > @@ -166,6 +167,10 @@ > > #define KEY_UNLOCK2 0xec > > #define KEY_LOCK 0x00 > > > > +/* MADC clock values for R_GPBR1 */ > > +#define MADC_HFCLK_EN 0x80 > > +#define DEFAULT_MADC_CLK_EN 0x10 > > + > > /* some fields in R_CFG_BOOT */ > > #define HFCLK_FREQ_19p2_MHZ (1 << 0) > > #define HFCLK_FREQ_26_MHZ (2 << 0) > > @@ -717,6 +722,11 @@ static void __init clocks_init(struct device *dev) > > ctrl |= HIGH_PERF_SQ; > > e |= unprotect_pm_master(); > > /* effect->MADC+USB ck en */ > > + > > + if (twl_has_madc()) > > + e |= twl4030_i2c_write_u8(TWL4030_MODULE_INTBR, > > + MADC_HFCLK_EN | DEFAULT_MADC_CLK_EN, > > R_GPBR1); > > + > > e |= twl4030_i2c_write_u8(TWL4030_MODULE_PM_MASTER, ctrl, > > R_CFG_BOOT); > > e |= protect_pm_master(); > > -- 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/RFC] ARM: OMAP: Initialize MADC clock divider and clock
Tony, I noticed your comment requesting all twl4030 patches be submitted to mainline. I assume this patch falls into that category too? Also for those listening in -- no comments on this patch yet! Does that mean it looks good? ;-) Steve On Sat, May 30, 2009 at 6:40 AM, Steve Sakoman wrote: > Though the comment in clocks_init claims to initialize the MADC > clocks, it wasn't actually being done. This patch implements minimal > MADC clock initialization. > > Compile/run tested on Overo (prior to patch MADC access would always timeout) > > diff --git a/drivers/mfd/twl4030-core.c b/drivers/mfd/twl4030-core.c > index 769b34b..c5ca36d 100644 > --- a/drivers/mfd/twl4030-core.c > +++ b/drivers/mfd/twl4030-core.c > @@ -159,6 +159,7 @@ > > /* Few power values */ > #define R_CFG_BOOT 0x05 > +#define R_GPBR1 0x0C > #define R_PROTECT_KEY 0x0E > > /* access control values for R_PROTECT_KEY */ > @@ -166,6 +167,10 @@ > #define KEY_UNLOCK2 0xec > #define KEY_LOCK 0x00 > > +/* MADC clock values for R_GPBR1 */ > +#define MADC_HFCLK_EN 0x80 > +#define DEFAULT_MADC_CLK_EN 0x10 > + > /* some fields in R_CFG_BOOT */ > #define HFCLK_FREQ_19p2_MHZ (1 << 0) > #define HFCLK_FREQ_26_MHZ (2 << 0) > @@ -717,6 +722,11 @@ static void __init clocks_init(struct device *dev) > ctrl |= HIGH_PERF_SQ; > e |= unprotect_pm_master(); > /* effect->MADC+USB ck en */ > + > + if (twl_has_madc()) > + e |= twl4030_i2c_write_u8(TWL4030_MODULE_INTBR, > + MADC_HFCLK_EN | DEFAULT_MADC_CLK_EN, R_GPBR1); > + > e |= twl4030_i2c_write_u8(TWL4030_MODULE_PM_MASTER, ctrl, R_CFG_BOOT); > e |= protect_pm_master(); > -- 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: [APPLIED] [RFC][PATCH] Add support for hook switch on ams-delta
Wednesday 03 June 2009 18:36:52 Tony Lindgren napisał(a): > * Janusz Krzysztofik [090603 01:01]: > > Tuesday 02 June 2009 20:27:50 Tony Lindgren napisał(a): > > > * Tony Lindgren [090602 11:23]: > > > > This patch has been applied to the linux-omap > > > > by youw fwiendly patch wobot. > > > > > > > > Initial commit ID (Likely to change): > > > > 89c6da9692bb04ce6221c371d3161f9722005e99 > > > > > > > > PatchWorks > > > > http://patchwork.kernel.org/patch/26069/ > > > > > > > > Git (Likely to change, and takes a while to get mirrored) > > > > http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a > > > >=com mit;h=89c6da9692bb04ce6221c371d3161f9722005e99 > > > > > > Argh, this is missing Signed-off-by too, please reply with your > > > Signed-off-by. Or repost with proper description. > > > > Tony, > > > > I'm sorry, I'm new here and did not realise that my message would ever be > > processed by a "fwiendly patch wobot". Was this because of the [PATCH] > > label I had put into subject line? > > > > > > Signed-off-by: Janusz Krzysztofik > > Well sounds like further changes are needed, I did not push it yet > so please resubmit. > > Tony OK, I will, thanks, 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
[APPLIED] [PATCH] [PATCH] twl4030: Add some error checking to twl4030 init
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Initial commit ID (Likely to change): 944f94235969c15b3012aa4dc832ed3e2f08e4da PatchWorks http://patchwork.kernel.org/patch/22012/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=944f94235969c15b3012aa4dc832ed3e2f08e4da -- 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] [PATCH] twl4030: Add some error checking to twl4030 init
* Amit Kucheria [090603 01:51]:
> Bump..
>
> This patch was acked by David Brownell earlier in the thread.
OK, I add it, but will reset all the twl stuff to mainline after 2.6.30.
These patches need to get submitted to mainline, all the other twl code is
there already.
Tony
> Regards,
> Amit
>
> On Wed, May 06, 2009 at 03:03:38PM +0300, Amit Kucheria wrote:
> > Check for return values of i2c read/write operations and size of scripts
> > being
> > uploaded to TWL4030
> >
> > (Removed the unrelated string changes based on David Brownell's comment)
> >
> > Signed-off-by: Amit Kucheria
> > ---
> > drivers/mfd/twl4030-power.c | 52
> > +++---
> > 1 files changed, 38 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
> > index 9dc493b..8f5d149 100644
> > --- a/drivers/mfd/twl4030-power.c
> > +++ b/drivers/mfd/twl4030-power.c
> > @@ -257,36 +257,40 @@ static int __init config_warmreset_sequence(u8
> > address)
> > return err;
> > }
> >
> > -void twl4030_configure_resource(struct twl4030_resconfig *rconfig)
> > +static int __init twl4030_configure_resource(struct twl4030_resconfig
> > *rconfig)
> > {
> > int rconfig_addr;
> > + int err;
> > u8 type;
> >
> > if (rconfig->resource > NUM_OF_RESOURCES) {
> > printk(KERN_ERR
> > "TWL4030 Resource %d does not exist\n",
> > rconfig->resource);
> > - return;
> > + return -EINVAL;
> > }
> >
> > rconfig_addr = res_config_addrs[rconfig->resource];
> >
> > /* Set resource group */
> > -
> > if (rconfig->devgroup >= 0)
> > - twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
> > + err = twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
> > rconfig->devgroup << 5,
> > rconfig_addr + DEVGROUP_OFFSET);
> > + if (err < 0) {
> > + printk(KERN_ERR
> > + "TWL4030 failed to program devgroup");
> > + return err;
> > + }
> >
> > /* Set resource types */
> > -
> > - if (twl4030_i2c_read_u8(TWL4030_MODULE_PM_RECEIVER,
> > - &type,
> > - rconfig_addr + TYPE_OFFSET) < 0) {
> > + err = twl4030_i2c_read_u8(TWL4030_MODULE_PM_RECEIVER, &type,
> > + rconfig_addr + TYPE_OFFSET);
> > + if (err < 0) {
> > printk(KERN_ERR
> > - "TWL4030 Resource %d type could not read\n",
> > - rconfig->resource);
> > - return;
> > + "TWL4030 Resource %d type could not be read\n",
> > + rconfig->resource);
> > + return err;
> > }
> >
> > if (rconfig->type >= 0) {
> > @@ -299,8 +303,15 @@ void twl4030_configure_resource(struct
> > twl4030_resconfig *rconfig)
> > type |= rconfig->type2 << 3;
> > }
> >
> > - twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
> > + err = twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
> > type, rconfig_addr + TYPE_OFFSET);
> > + if (err < 0) {
> > + printk(KERN_ERR
> > + "TWL4030 failed to program resource type");
> > + return err;
> > + }
> > +
> > + return 0;
> >
> > }
> >
> > @@ -309,6 +320,12 @@ static int __init load_triton_script(struct
> > twl4030_script *tscript)
> > u8 address = triton_next_free_address;
> > int err;
> >
> > + /* Make sure the script isn't going beyond last valid address */
> > + if ((address + tscript->size) > (END_OF_SCRIPT-1)) {
> > + printk(KERN_ERR "TWL4030 script too big error\n");
> > + return -EINVAL;
> > + }
> > +
> > err = twl4030_write_script(address, tscript->script, tscript->size);
> > if (err)
> > return err;
> > @@ -346,15 +363,22 @@ void __init twl4030_power_init(struct
> > twl4030_power_data *triton2_scripts)
> >
> > for (i = 0; i < triton2_scripts->size; i++) {
> > err = load_triton_script(triton2_scripts->scripts[i]);
> > - if (err)
> > + if (err < 0) {
> > + printk(KERN_ERR "TWL4030 failed to load scripts");
> > break;
> > + }
> > }
> >
> > resconfig = triton2_scripts->resource_config;
> > if (resconfig) {
> > while (resconfig->resource) {
> > - twl4030_configure_resource(resconfig);
> > + err = twl4030_configure_resource(resconfig);
> > resconfig++;
> > + if (err < 0) {
> > + printk(KERN_ERR
> > + "TWL4030 failed to configure resource");
> > + break;
> > + }
> > }
> > }
> >
> > --
> > 1.6.0.4
> >
> > --
> > To unsub
Re: [PATCH] ARM: Move clk_add_alias() to arch/arm/common/clkdev.c (Re: [PATCH 05/10] ARM: OMAP1: Make 770 LCD work)
* Tony Lindgren [090528 14:05]:
> * Russell King - ARM Linux [090528 12:53]:
> > On Thu, May 28, 2009 at 11:20:48AM -0700, Tony Lindgren wrote:
> > > > +int clk_add_alias(const char *alias, const char *alias_dev_name, char
> > > > *id,
> > > > + struct device *dev)
> > > > +{
> > > > + struct clk *r = clk_get(dev, id);
> > > > + struct clk_lookup *l;
> > > > +
> > > > + if (!r)
> > > > + return -ENODEV;
> > > > +
> > > > + l = clkdev_alloc(r, alias, alias_dev_name);
> > > > + clk_put(r);
> > > > + if (!l)
> > > > + return -ENODEV;
> > > > + clkdev_add(l);
> > > > + return 0;
> > > > +}
> > > > +EXPORT_SYMBOL(clk_add_alias);
> >
> > Oh, and a really good thing to do would be to fix the error checking and
> > returning in there (why did I miss it in the original PXA version...)
>
> How about this? The prototype is in clk.h now, is that OK?
Added to patch tracking as 5536/1.
> Tony
> From e4e651822967b0530a9d092894c04149e28efe39 Mon Sep 17 00:00:00 2001
> From: Tony Lindgren
> Date: Thu, 28 May 2009 13:24:12 -0700
> Subject: [PATCH] ARM: Move clk_add_alias() to arch/arm/common/clkdev.c
>
> This can be used for other arm platforms too as discussed
> on the linux-arm-kernel list.
>
> Also check the return value with IS_ERR and return PTR_ERR
> as suggested by Russell King.
>
> Signed-off-by: Tony Lindgren
>
> diff --git a/arch/arm/common/clkdev.c b/arch/arm/common/clkdev.c
> index 5589444..f37afd9 100644
> --- a/arch/arm/common/clkdev.c
> +++ b/arch/arm/common/clkdev.c
> @@ -135,6 +135,24 @@ struct clk_lookup *clkdev_alloc(struct clk *clk, const
> char *con_id,
> }
> EXPORT_SYMBOL(clkdev_alloc);
>
> +int clk_add_alias(const char *alias, const char *alias_dev_name, char *id,
> + struct device *dev)
> +{
> + struct clk *r = clk_get(dev, id);
> + struct clk_lookup *l;
> +
> + if (IS_ERR(r))
> + return PTR_ERR(r);
> +
> + l = clkdev_alloc(r, alias, alias_dev_name);
> + clk_put(r);
> + if (!l)
> + return -ENODEV;
> + clkdev_add(l);
> + return 0;
> +}
> +EXPORT_SYMBOL(clk_add_alias);
> +
> /*
> * clkdev_drop - remove a clock dynamically allocated
> */
> diff --git a/arch/arm/mach-pxa/clock.c b/arch/arm/mach-pxa/clock.c
> index db52d2c..49ae382 100644
> --- a/arch/arm/mach-pxa/clock.c
> +++ b/arch/arm/mach-pxa/clock.c
> @@ -86,20 +86,3 @@ void clks_register(struct clk_lookup *clks, size_t num)
> for (i = 0; i < num; i++)
> clkdev_add(&clks[i]);
> }
> -
> -int clk_add_alias(const char *alias, const char *alias_dev_name, char *id,
> - struct device *dev)
> -{
> - struct clk *r = clk_get(dev, id);
> - struct clk_lookup *l;
> -
> - if (!r)
> - return -ENODEV;
> -
> - l = clkdev_alloc(r, alias, alias_dev_name);
> - clk_put(r);
> - if (!l)
> - return -ENODEV;
> - clkdev_add(l);
> - return 0;
> -}
> diff --git a/include/linux/clk.h b/include/linux/clk.h
> index 1db9bbf..1d37f42 100644
> --- a/include/linux/clk.h
> +++ b/include/linux/clk.h
> @@ -142,4 +142,17 @@ struct clk *clk_get_parent(struct clk *clk);
> */
> struct clk *clk_get_sys(const char *dev_id, const char *con_id);
>
> +/**
> + * clk_add_alias - add a new clock alias
> + * @alias: name for clock alias
> + * @alias_dev_name: device name
> + * @id: platform specific clock name
> + * @dev: device
> + *
> + * Allows using generic clock names for drivers by adding a new alias.
> + * Assumes clkdev, see clkdev.h for more info.
> + */
> +int clk_add_alias(const char *alias, const char *alias_dev_name, char *id,
> + struct device *dev);
> +
> #endif
--
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] OMAP3 Overo: add EXPORT_SYMBOLs for Overo ASoC audio to be built as a module.
* Jarkko Nikula [090603 06:20]:
> On Tue, 2 Jun 2009 10:35:43 -0700
> Tony Lindgren wrote:
>
> > * Hugo Vincent [090601 18:03]:
> > > I'm pretty new to kernel development, so I don't know any potential
> > > problems with doing this, but without this, audio/ASoC support must be
> > > built into the kernel (modpost fails when trying to build as modules),
> > > whereas with this patch, it can be built and used as a module.
> > >
> > > Comments?
> >
> > To me it looks like we should rather fix sound/soc/omap/omap-mcbsp.c
> > to use the clock framework rather than access omap_ctrl_read/write
> > directly.
> >
> Yeah, I have something like below in my mind.
>
> I don't know is this idea working but at least I know there is need to define
> McBSP FCLK parent clocks for 24xx similar way as they are defined for
> 34xx and to figure out something for the FIXMEs. McBSP module is
> enabling the clocks at request time but fclk must be off in order to change
> its parent.
Sounds like you might be able to fix this easily with clk_add_alias()
like what's queued up for 770 framebuffer:
http://patchwork.kernel.org/patch/26796/
This patch to make clk_add_alias() common is not merged yet though.
Tony
> --
> Jarkko
>
> diff --git a/arch/arm/plat-omap/include/mach/mcbsp.h
> b/arch/arm/plat-omap/include/mach/mcbsp.h
> index bb154ea..3ebbe3f 100644
> --- a/arch/arm/plat-omap/include/mach/mcbsp.h
> +++ b/arch/arm/plat-omap/include/mach/mcbsp.h
> @@ -389,6 +389,7 @@ int omap_mcbsp_request(unsigned int id);
> void omap_mcbsp_free(unsigned int id);
> void omap_mcbsp_start(unsigned int id);
> void omap_mcbsp_stop(unsigned int id);
> +int omap_mcbsp_set_fclk_src(unsigned int id, const char *clk_name);
> void omap_mcbsp_xmit_word(unsigned int id, u32 word);
> u32 omap_mcbsp_recv_word(unsigned int id);
>
> diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
> index efa0e01..f36c6a6 100644
> --- a/arch/arm/plat-omap/mcbsp.c
> +++ b/arch/arm/plat-omap/mcbsp.c
> @@ -398,6 +398,30 @@ void omap_mcbsp_stop(unsigned int id)
> }
> EXPORT_SYMBOL(omap_mcbsp_stop);
>
> +int omap_mcbsp_set_fclk_src(unsigned int id, const char *clk_name)
> +{
> + struct omap_mcbsp *mcbsp;
> + struct clk *fclk_src;
> + int err;
> +
> + if (!omap_mcbsp_check_valid_id(id)) {
> + printk(KERN_ERR "%s: Invalid id (%d)\n", __func__, id + 1);
> + return -ENODEV;
> + }
> +
> + mcbsp = id_to_mcbsp_ptr(id);
> + fclk_src = clk_get(mcbsp->dev, clk_name);
> + if (IS_ERR(fclk_src))
> + return PTR_ERR(fclk_src);
> + clk_disable(mcbsp->fclk); /* FIXME, Hack! */
> + err = clk_set_parent(mcbsp->fclk, fclk_src);
> + clk_enable(mcbsp->fclk); /* FIXME, Hack! */
> + clk_put(fclk_src);
> +
> + return err;
> +}
> +EXPORT_SYMBOL(omap_mcbsp_set_fclk_src);
> +
> /* polled mcbsp i/o operations */
> int omap_mcbsp_pollwrite(unsigned int id, u16 buf)
> {
> diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
> index 9126142..d03a3c0 100644
> --- a/sound/soc/omap/omap-mcbsp.c
> +++ b/sound/soc/omap/omap-mcbsp.c
> @@ -397,8 +397,7 @@ static int omap_mcbsp_dai_set_clkdiv(struct snd_soc_dai
> *cpu_dai,
> static int omap_mcbsp_dai_set_clks_src(struct omap_mcbsp_data *mcbsp_data,
> int clk_id)
> {
> - int sel_bit;
> - u16 reg, reg_devconf1 = OMAP243X_CONTROL_DEVCONF1;
> + const char *clks_src;
>
> if (cpu_class_is_omap1()) {
> /* OMAP1's can use only external source clock */
> @@ -408,43 +407,16 @@ static int omap_mcbsp_dai_set_clks_src(struct
> omap_mcbsp_data *mcbsp_data,
> return 0;
> }
>
> - if (cpu_is_omap2420() && mcbsp_data->bus_id > 1)
> - return -EINVAL;
> -
> - if (cpu_is_omap343x())
> - reg_devconf1 = OMAP343X_CONTROL_DEVCONF1;
> -
> - switch (mcbsp_data->bus_id) {
> - case 0:
> - reg = OMAP2_CONTROL_DEVCONF0;
> - sel_bit = 2;
> - break;
> - case 1:
> - reg = OMAP2_CONTROL_DEVCONF0;
> - sel_bit = 6;
> - break;
> - case 2:
> - reg = reg_devconf1;
> - sel_bit = 0;
> - break;
> - case 3:
> - reg = reg_devconf1;
> - sel_bit = 2;
> - break;
> - case 4:
> - reg = reg_devconf1;
> - sel_bit = 4;
> - break;
> - default:
> - return -EINVAL;
> + if (clk_id == OMAP_MCBSP_SYSCLK_CLKS_FCLK) {
> + if (cpu_is_omap24xx())
> + clks_src = "func_96m_ck";
> + if (cpu_is_omap343x())
> + clks_src = "core_96m_fck";
> + } else {
> + clks_src = "mcbsp_clks";
> }
>
> - if (clk_id == OMAP_MCBSP_SYSCLK_CLKS_FCLK)
> - omap_ctrl_writel(omap_ctrl_readl(reg) & ~(1 << sel_bit), reg);
> - else
> - omap_
Re: [PATCH] [MTD] [NAND] Add prefetch and dma support for omap2/3 NAND driver
* Singh, Vimal
[090602
23:46]:
>
> On Wed, Jun 3, 2009 at 2:06 AM, Tony Lindgren wrote:
> > * vimal singh [090602 05:40]:
> >> This patch adds prefetch support to access nand flash in both mpu and dma
> >> mode.
> >> This patch also adds 8-bit nand support (omap_read/write_buf8).
> >> Prefetch can be used for both 8- and 16-bit devices.
> >
> > This should be reviewed on the linux-omap@vger.kernel.org list for sure.
> > One other comment below.
> >
> >> Signed-off-by: Vimal Singh
> >> ---
> >> I prepared this patch on top of "OMAP2 / OMAP3 NAND driver" patch:
> >> http://lists.infradead.org/pipermail/linux-mtd/2009-May/025562.html
> >>
> >> ---
> >> arch/arm/mach-omap2/gpmc.c | 102 ++
> >> arch/arm/plat-omap/include/mach/gpmc.h |4
> >> drivers/mtd/nand/Kconfig | 17 +
> >> drivers/mtd/nand/omap2.c | 308
> >> -
> >> 4 files changed, 422 insertions(+), 9 deletions(-)
> >>
> >> Index: mtd-2.6/arch/arm/mach-omap2/gpmc.c
> >> ===
> >> --- mtd-2.6.orig/arch/arm/mach-omap2/gpmc.c
> >> +++ mtd-2.6/arch/arm/mach-omap2/gpmc.c
> >> @@ -54,6 +54,12 @@
> >> #define GPMC_CHUNK_SHIFT 24 /* 16 MB */
> >> #define GPMC_SECTION_SHIFT 28 /* 128 MB */
> >>
> >> +#ifdef CONFIG_MTD_NAND_OMAP_PREFETCH
> >> +#define CS_NUM_SHIFT 24
> >> +#define ENABLE_PREFETCH 7
> >> +#define DMA_MPU_MODE 2
> >> +#endif
> >> +
> >> static struct resource gpmc_mem_root;
> >> static struct resource gpmc_cs_mem[GPMC_CS_NUM];
> >> static DEFINE_SPINLOCK(gpmc_mem_lock);
> >> @@ -383,6 +389,99 @@ void gpmc_cs_free(int cs)
> >> }
> >> EXPORT_SYMBOL(gpmc_cs_free);
> >>
> >> +#ifdef CONFIG_MTD_NAND_OMAP_PREFETCH
> >> +/**
> >> + * gpmc_prefetch_init - configures default configuration for prefetch
> >> engine
> >> + */
> >> +static void gpmc_prefetch_init(void)
> >> +{
> >> + /* Setting the default threshold to 64 */
> >> + gpmc_write_reg(GPMC_PREFETCH_CONTROL, 0x0);
> >> + gpmc_write_reg(GPMC_PREFETCH_CONFIG1, 0x40 << 8);
> >> + gpmc_write_reg(GPMC_PREFETCH_CONFIG2, 0x0);
> >> +}
> >
> > Why would you want to have NAND specific init code int gpmc.c?
> >
> > The purpose if gpmc.c is to provide access to configuring the
> > General Purpose Memory Controller (GPMC). You should just provide
> > functions in gpmc.c for the platform init code to use, and then
> > the drivers can stay platform independent.
>
> In my understanding, this 'prefetch' engine is part of GPMC itself, it is a
> kind of feature provided by GPMC which can be utilized by NAND driver.
> So, to me, it makes sens to get initialized prefetch by GPMC itself so that
> NAND driver can use it.
But it should not have a dependency to NAND.
> Another reason was that all read / write to GPMC register are done by
> functions 'gpmc_read_reg' / 'gpmc_write_reg', which have been made
> 'static' in nature.
That's why you need to provide a generic function in gpmc.c to enable
prefetch that the platform code for any driver can use.
Tony
--
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: [APPLIED] [RFC][PATCH] Add support for hook switch on ams-delta
* Janusz Krzysztofik [090603 01:01]: > Tuesday 02 June 2009 20:27:50 Tony Lindgren napisał(a): > > * Tony Lindgren [090602 11:23]: > > > This patch has been applied to the linux-omap > > > by youw fwiendly patch wobot. > > > > > > Initial commit ID (Likely to change): > > > 89c6da9692bb04ce6221c371d3161f9722005e99 > > > > > > PatchWorks > > > http://patchwork.kernel.org/patch/26069/ > > > > > > Git (Likely to change, and takes a while to get mirrored) > > > http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=com > > >mit;h=89c6da9692bb04ce6221c371d3161f9722005e99 > > > > Argh, this is missing Signed-off-by too, please reply with your > > Signed-off-by. Or repost with proper description. > > Tony, > > I'm sorry, I'm new here and did not realise that my message would ever be > processed by a "fwiendly patch wobot". Was this because of the [PATCH] label > I had put into subject line? > > > Signed-off-by: Janusz Krzysztofik > Well sounds like further changes are needed, I did not push it yet so please resubmit. Tony -- 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] DSPBRIDGE: Revert removing all resources on proc detach
This patch changes removing all resources for the process
context on processor detach, it only frees the dmm resources
and let resource cleanup take care of the rest.
This regression was introduced with the following patch:
DSPBRIDGE: base image reload support after DSP error
Signed-off-by: Omar Ramirez Luna
Acked-by: Hari Kanigeri
---
drivers/dsp/bridge/rmgr/proc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/dsp/bridge/rmgr/proc.c b/drivers/dsp/bridge/rmgr/proc.c
index d4d20ae..43f2d29 100644
--- a/drivers/dsp/bridge/rmgr/proc.c
+++ b/drivers/dsp/bridge/rmgr/proc.c
@@ -659,7 +659,7 @@ DSP_STATUS PROC_Detach(DSP_HPROCESSOR hProcessor)
(struct DRV_OBJECT *)hDRVObject, &pPctxt,
NULL, 0);
if (pPctxt != NULL) {
- DRV_RemoveAllResources(pPctxt);
+ DRV_ProcFreeDMMRes(pPctxt);
pPctxt->hProcessor = NULL;
}
}
--
1.6.2.4
--
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
DSS2: Compilation Error on Git tree http://www.bat.org/~tomba/git/linux-omap-dss.git
Hi Tomi, I did git pull to update my tree, later compiling code for LDP, I am getting compilation error as show below. I see that I am missing declaration of struct omap_dss_display_config in display.h file, could you please comment on it... arch/arm/mach-omap2/board-ldp.c:368: warning: 'struct omap_display' declared inside parameter list arch/arm/mach-omap2/board-ldp.c:368: warning: its scope is only this definition or declaration, which is probably not what you want arch/arm/mach-omap2/board-ldp.c:383: warning: 'struct omap_display' declared inside parameter list arch/arm/mach-omap2/board-ldp.c:393: error: variable 'omap_ldp_display_data_tv' has initializer but incomplete type arch/arm/mach-omap2/board-ldp.c:394: error: unknown field 'type' specified in initializer arch/arm/mach-omap2/board-ldp.c:394: warning: excess elements in struct initializer arch/arm/mach-omap2/board-ldp.c:394: warning: (near initialization for 'omap_ldp_display_data_tv') arch/arm/mach-omap2/board-ldp.c:395: error: unknown field 'name' specified in initializer arch/arm/mach-omap2/board-ldp.c:395: warning: excess elements in struct initializer arch/arm/mach-omap2/board-ldp.c:395: warning: (near initialization for 'omap_ldp_display_data_tv') arch/arm/mach-omap2/board-ldp.c:396: error: unknown field 'u' specified in initializer arch/arm/mach-omap2/board-ldp.c:396: warning: excess elements in struct initializer arch/arm/mach-omap2/board-ldp.c:396: warning: (near initialization for 'omap_ldp_display_data_tv') arch/arm/mach-omap2/board-ldp.c:397: error: unknown field 'panel_enable' specified in initializer arch/arm/mach-omap2/board-ldp.c:397: warning: excess elements in struct initializer arch/arm/mach-omap2/board-ldp.c:397: warning: (near initialization for 'omap_ldp_display_data_tv') arch/arm/mach-omap2/board-ldp.c:398: error: unknown field 'panel_disable' specified in initializer arch/arm/mach-omap2/board-ldp.c:398: warning: excess elements in struct initializer arch/arm/mach-omap2/board-ldp.c:398: warning: (near initialization for 'omap_ldp_display_data_tv') arch/arm/mach-omap2/board-ldp.c:401: warning: 'struct omap_display' declared inside parameter list arch/arm/mach-omap2/board-ldp.c:425: warning: 'struct omap_display' declared inside parameter list arch/arm/mach-omap2/board-ldp.c:435: error: variable 'omap_ldp_display_data_lcd' has initializer but incomplete type arch/arm/mach-omap2/board-ldp.c:436: error: unknown field 'type' specified in initializer arch/arm/mach-omap2/board-ldp.c:436: warning: excess elements in struct initializer arch/arm/mach-omap2/board-ldp.c:436: warning: (near initialization for 'omap_ldp_display_data_lcd') arch/arm/mach-omap2/board-ldp.c:437: error: unknown field 'name' specified in initializer arch/arm/mach-omap2/board-ldp.c:437: warning: excess elements in struct initializer arch/arm/mach-omap2/board-ldp.c:437: warning: (near initialization for 'omap_ldp_display_data_lcd') Regards, Subbu-- 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] OMAP3 Overo: add EXPORT_SYMBOLs for Overo ASoC audio to be built as a module.
On Tue, 2 Jun 2009 10:35:43 -0700
Tony Lindgren wrote:
> * Hugo Vincent [090601 18:03]:
> > I'm pretty new to kernel development, so I don't know any potential
> > problems with doing this, but without this, audio/ASoC support must be
> > built into the kernel (modpost fails when trying to build as modules),
> > whereas with this patch, it can be built and used as a module.
> >
> > Comments?
>
> To me it looks like we should rather fix sound/soc/omap/omap-mcbsp.c
> to use the clock framework rather than access omap_ctrl_read/write
> directly.
>
Yeah, I have something like below in my mind.
I don't know is this idea working but at least I know there is need to define
McBSP FCLK parent clocks for 24xx similar way as they are defined for
34xx and to figure out something for the FIXMEs. McBSP module is
enabling the clocks at request time but fclk must be off in order to change
its parent.
--
Jarkko
diff --git a/arch/arm/plat-omap/include/mach/mcbsp.h
b/arch/arm/plat-omap/include/mach/mcbsp.h
index bb154ea..3ebbe3f 100644
--- a/arch/arm/plat-omap/include/mach/mcbsp.h
+++ b/arch/arm/plat-omap/include/mach/mcbsp.h
@@ -389,6 +389,7 @@ int omap_mcbsp_request(unsigned int id);
void omap_mcbsp_free(unsigned int id);
void omap_mcbsp_start(unsigned int id);
void omap_mcbsp_stop(unsigned int id);
+int omap_mcbsp_set_fclk_src(unsigned int id, const char *clk_name);
void omap_mcbsp_xmit_word(unsigned int id, u32 word);
u32 omap_mcbsp_recv_word(unsigned int id);
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index efa0e01..f36c6a6 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -398,6 +398,30 @@ void omap_mcbsp_stop(unsigned int id)
}
EXPORT_SYMBOL(omap_mcbsp_stop);
+int omap_mcbsp_set_fclk_src(unsigned int id, const char *clk_name)
+{
+ struct omap_mcbsp *mcbsp;
+ struct clk *fclk_src;
+ int err;
+
+ if (!omap_mcbsp_check_valid_id(id)) {
+ printk(KERN_ERR "%s: Invalid id (%d)\n", __func__, id + 1);
+ return -ENODEV;
+ }
+
+ mcbsp = id_to_mcbsp_ptr(id);
+ fclk_src = clk_get(mcbsp->dev, clk_name);
+ if (IS_ERR(fclk_src))
+ return PTR_ERR(fclk_src);
+ clk_disable(mcbsp->fclk); /* FIXME, Hack! */
+ err = clk_set_parent(mcbsp->fclk, fclk_src);
+ clk_enable(mcbsp->fclk); /* FIXME, Hack! */
+ clk_put(fclk_src);
+
+ return err;
+}
+EXPORT_SYMBOL(omap_mcbsp_set_fclk_src);
+
/* polled mcbsp i/o operations */
int omap_mcbsp_pollwrite(unsigned int id, u16 buf)
{
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index 9126142..d03a3c0 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -397,8 +397,7 @@ static int omap_mcbsp_dai_set_clkdiv(struct snd_soc_dai
*cpu_dai,
static int omap_mcbsp_dai_set_clks_src(struct omap_mcbsp_data *mcbsp_data,
int clk_id)
{
- int sel_bit;
- u16 reg, reg_devconf1 = OMAP243X_CONTROL_DEVCONF1;
+ const char *clks_src;
if (cpu_class_is_omap1()) {
/* OMAP1's can use only external source clock */
@@ -408,43 +407,16 @@ static int omap_mcbsp_dai_set_clks_src(struct
omap_mcbsp_data *mcbsp_data,
return 0;
}
- if (cpu_is_omap2420() && mcbsp_data->bus_id > 1)
- return -EINVAL;
-
- if (cpu_is_omap343x())
- reg_devconf1 = OMAP343X_CONTROL_DEVCONF1;
-
- switch (mcbsp_data->bus_id) {
- case 0:
- reg = OMAP2_CONTROL_DEVCONF0;
- sel_bit = 2;
- break;
- case 1:
- reg = OMAP2_CONTROL_DEVCONF0;
- sel_bit = 6;
- break;
- case 2:
- reg = reg_devconf1;
- sel_bit = 0;
- break;
- case 3:
- reg = reg_devconf1;
- sel_bit = 2;
- break;
- case 4:
- reg = reg_devconf1;
- sel_bit = 4;
- break;
- default:
- return -EINVAL;
+ if (clk_id == OMAP_MCBSP_SYSCLK_CLKS_FCLK) {
+ if (cpu_is_omap24xx())
+ clks_src = "func_96m_ck";
+ if (cpu_is_omap343x())
+ clks_src = "core_96m_fck";
+ } else {
+ clks_src = "mcbsp_clks";
}
- if (clk_id == OMAP_MCBSP_SYSCLK_CLKS_FCLK)
- omap_ctrl_writel(omap_ctrl_readl(reg) & ~(1 << sel_bit), reg);
- else
- omap_ctrl_writel(omap_ctrl_readl(reg) | (1 << sel_bit), reg);
-
- return 0;
+ return omap_mcbsp_set_fclk_src(mcbsp_data->bus_id, clks_src);
}
static int omap_mcbsp_dai_set_dai_sysclk(struct snd_soc_dai *cpu_dai,
--
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-in
Re: [RFC][PATCH] Add support for hook switch on ams-delta
Hi Jonathan,
Wednesday 03 June 2009 00:04:33 Jonathan McDowell napisał(a):
> I'm obviously too late as I've seen the "Applied" mail,
No problem, I'm glad to hear from you.
> but some
> comments:
>
> * I don't think SW_HEADPHONE_INSERT is appropriate. input guys, is it
> not reasonable to have SW_PHONE_HOOK or similar?
I do share you point of view. However, I didn't want to start a discussion if
there is a need for another symbol or not before the patch got any
acceptance.
> * We assume the bootloader does the appropriate GPIO pin setup for us,
> so I don't think your omap_cfg_reg is required but it doesn't hurt in
> the unlikely event we ever replace the Amstrad PBL.
OK, let it stay there. Do you see a need for replaceing it with a new
ams_delta_hook_switch_init() function call that just calls omap_cfg_reg()?
> * The commented out code to include the GPIO status in sysfs shouldn't
> be included.
Yes, I put it there to get a feedback.
> Does the input layer not provide a way to obtain the
> state of the switch?
Yes, it does, with EVIOCGSW ioctl()[1]. I personally don't like this way of
getting the switch status and would rather see it available over sysfs.
However, input guys may have their own preferences and gpio-keys driver
belongs to them.
Thanks,
Janusz
[1] http://www.spinics.net/lists/linux-input/msg03482.html
P.S. I include my Signed-off-by, as Tony have requested, to avoid the code
without one floating around.
Signed-off-by: Janusz Krzysztofik
> > diff -Npru a/arch/arm/mach-omap1/board-ams-delta.c
> > b/arch/arm/mach-omap1/board-ams-delta.c ---
> > a/arch/arm/mach-omap1/board-ams-delta.c 2009-05-17 17:58:18.0
> > +0200 +++ b/arch/arm/mach-omap1/board-ams-delta.c 2009-05-17
> > 16:22:59.0 +0200 @@ -15,6 +15,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> >
> > #include
> > @@ -213,10 +214,35 @@ static struct platform_device ams_delta_
> > .id = -1
> > };
> >
> > +static struct gpio_keys_button ams_delta_gpio_keys_buttons[] = {
> > + [0] = {
> > + .desc = "hook_switch",
> > + .type = EV_SW,/* or EV_KEY ? */
> > + .code = SW_HEADPHONE_INSERT, /* or a new one ? */
> > + .active_low = 1,
> > + .gpio = AMS_DELTA_GPIO_PIN_HOOK_SWITCH,
> > + .debounce_interval = 10,
> > + },
> > +};
> > +
> > +static struct gpio_keys_platform_data ams_delta_gpio_keys = {
> > + .buttons= ams_delta_gpio_keys_buttons,
> > + .nbuttons = ARRAY_SIZE(ams_delta_gpio_keys_buttons),
> > +};
> > +
> > +static struct platform_device ams_delta_gpio_keys_device = {
> > + .name = "gpio-keys",
> > + .id = -1,
> > + .dev= {
> > + .platform_data = &ams_delta_gpio_keys,
> > + },
> > +};
> > +
> > static struct platform_device *ams_delta_devices[] __initdata = {
> > &ams_delta_kp_device,
> > &ams_delta_lcd_device,
> > &ams_delta_led_device,
> > + &ams_delta_gpio_keys_device,
> > };
> >
> > static void __init ams_delta_init(void)
> > @@ -233,6 +259,13 @@ static void __init ams_delta_init_irq(vo
> >
> > omap_usb_init(&ams_delta_usb_config);
> > platform_add_devices(ams_delta_devices, ARRAY_SIZE(ams_delta_devices));
> > +
> > + omap_cfg_reg(P20_1610_GPIO4); /* is this required? */
> > +
> > + /* The hook switch state could be exposed over sysfs with
> > gpio_export(). + * This should be done after the gpio-keys driver calls
> > gpio_request(), +* but I don't know how to do this from outside of the
> > driver. */ +/* gpio_export(AMS_DELTA_GPIO_PIN_HOOK_SWITCH, 0); */
> > }
> >
> > static void __init ams_delta_map_io(void)
>
> J.
--
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] [PATCH] twl4030: Add some error checking to twl4030 init
Bump..
This patch was acked by David Brownell earlier in the thread.
Regards,
Amit
On Wed, May 06, 2009 at 03:03:38PM +0300, Amit Kucheria wrote:
> Check for return values of i2c read/write operations and size of scripts being
> uploaded to TWL4030
>
> (Removed the unrelated string changes based on David Brownell's comment)
>
> Signed-off-by: Amit Kucheria
> ---
> drivers/mfd/twl4030-power.c | 52 +++---
> 1 files changed, 38 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
> index 9dc493b..8f5d149 100644
> --- a/drivers/mfd/twl4030-power.c
> +++ b/drivers/mfd/twl4030-power.c
> @@ -257,36 +257,40 @@ static int __init config_warmreset_sequence(u8 address)
> return err;
> }
>
> -void twl4030_configure_resource(struct twl4030_resconfig *rconfig)
> +static int __init twl4030_configure_resource(struct twl4030_resconfig
> *rconfig)
> {
> int rconfig_addr;
> + int err;
> u8 type;
>
> if (rconfig->resource > NUM_OF_RESOURCES) {
> printk(KERN_ERR
> "TWL4030 Resource %d does not exist\n",
> rconfig->resource);
> - return;
> + return -EINVAL;
> }
>
> rconfig_addr = res_config_addrs[rconfig->resource];
>
> /* Set resource group */
> -
> if (rconfig->devgroup >= 0)
> - twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
> + err = twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
> rconfig->devgroup << 5,
> rconfig_addr + DEVGROUP_OFFSET);
> + if (err < 0) {
> + printk(KERN_ERR
> +"TWL4030 failed to program devgroup");
> + return err;
> + }
>
> /* Set resource types */
> -
> - if (twl4030_i2c_read_u8(TWL4030_MODULE_PM_RECEIVER,
> - &type,
> - rconfig_addr + TYPE_OFFSET) < 0) {
> + err = twl4030_i2c_read_u8(TWL4030_MODULE_PM_RECEIVER, &type,
> + rconfig_addr + TYPE_OFFSET);
> + if (err < 0) {
> printk(KERN_ERR
> - "TWL4030 Resource %d type could not read\n",
> - rconfig->resource);
> - return;
> +"TWL4030 Resource %d type could not be read\n",
> +rconfig->resource);
> + return err;
> }
>
> if (rconfig->type >= 0) {
> @@ -299,8 +303,15 @@ void twl4030_configure_resource(struct twl4030_resconfig
> *rconfig)
> type |= rconfig->type2 << 3;
> }
>
> - twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
> + err = twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
> type, rconfig_addr + TYPE_OFFSET);
> + if (err < 0) {
> + printk(KERN_ERR
> +"TWL4030 failed to program resource type");
> + return err;
> + }
> +
> + return 0;
>
> }
>
> @@ -309,6 +320,12 @@ static int __init load_triton_script(struct
> twl4030_script *tscript)
> u8 address = triton_next_free_address;
> int err;
>
> + /* Make sure the script isn't going beyond last valid address */
> + if ((address + tscript->size) > (END_OF_SCRIPT-1)) {
> + printk(KERN_ERR "TWL4030 script too big error\n");
> + return -EINVAL;
> + }
> +
> err = twl4030_write_script(address, tscript->script, tscript->size);
> if (err)
> return err;
> @@ -346,15 +363,22 @@ void __init twl4030_power_init(struct
> twl4030_power_data *triton2_scripts)
>
> for (i = 0; i < triton2_scripts->size; i++) {
> err = load_triton_script(triton2_scripts->scripts[i]);
> - if (err)
> + if (err < 0) {
> + printk(KERN_ERR "TWL4030 failed to load scripts");
> break;
> + }
> }
>
> resconfig = triton2_scripts->resource_config;
> if (resconfig) {
> while (resconfig->resource) {
> - twl4030_configure_resource(resconfig);
> + err = twl4030_configure_resource(resconfig);
> resconfig++;
> + if (err < 0) {
> + printk(KERN_ERR
> +"TWL4030 failed to configure resource");
> + break;
> + }
> }
> }
>
> --
> 1.6.0.4
>
> --
> 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
--
-
Amit Kucheria, Kernel Developer, Verdure
Re: *SPAM* Re: Please help in adding ams-delta support to ASoC
Wednesday 03 June 2009 07:28:06 Peter Ujfalusi napisał(a):
> Looking at the code at commit: d8376cc482b241701f7606c81ad578b90853e175 on
> l-o the comment about the need for the call the omap_stop_dma puzzled me.
Peter,
It was omap_stop_alsa_sound_dma(), not just omap_stop_dma(), the was needed.
In my opinion, the reason for that was not because it was calling
omap_stop_dma(), but because it was clearing the audio_stream.started flag.
That way, subsequent audio_start_dma_chain() would not jump over
omap_start_dma(). From my experience with the original driver, it worked much
better when calling omap_start_dma() unconditionally from
audio_start_dma_chain() instead of doing this with that
omap_stop_alsa_sound_dma() trick.
> Can you try something like this:
>
> diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c
> index 6454e15..2df1792 100644
> --- a/sound/soc/omap/omap-pcm.c
> +++ b/sound/soc/omap/omap-pcm.c
> @@ -67,6 +67,7 @@ static void omap_pcm_dma_irq(int ch, u16 stat, void
> *data) spin_lock_irqsave(&prtd->lock, flags);
> if (prtd->period_index >= 0) {
> if (++prtd->period_index == runtime->periods) {
> + omap_stop_dma(prtd->dma_ch);
> prtd->period_index = 0;
> omap_start_dma(prtd->dma_ch);
> }
> @@ -191,6 +192,7 @@ static int omap_pcm_trigger(struct snd_pcm_substream
> *substream, int cmd)
> case SNDRV_PCM_TRIGGER_START:
> case SNDRV_PCM_TRIGGER_RESUME:
> case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
> + omap_stop_dma(prtd->dma_ch);
> prtd->period_index = 0;
> omap_start_dma(prtd->dma_ch);
> break;
Never hurts. Unfortunatelly, it did not help, no single DMA interrupt again.
Thanks,
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
Re: [APPLIED] [RFC][PATCH] Add support for hook switch on ams-delta
Tuesday 02 June 2009 20:27:50 Tony Lindgren napisał(a): > * Tony Lindgren [090602 11:23]: > > This patch has been applied to the linux-omap > > by youw fwiendly patch wobot. > > > > Initial commit ID (Likely to change): > > 89c6da9692bb04ce6221c371d3161f9722005e99 > > > > PatchWorks > > http://patchwork.kernel.org/patch/26069/ > > > > Git (Likely to change, and takes a while to get mirrored) > > http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=com > >mit;h=89c6da9692bb04ce6221c371d3161f9722005e99 > > Argh, this is missing Signed-off-by too, please reply with your > Signed-off-by. Or repost with proper description. Tony, I'm sorry, I'm new here and did not realise that my message would ever be processed by a "fwiendly patch wobot". Was this because of the [PATCH] label I had put into subject line? Signed-off-by: Janusz Krzysztofik -- 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: Please help in adding ams-delta support to ASoC
Hi,
Tuesday 02 June 2009 19:32:14 Jarkko Nikula wrote:
> > It is not clear for me if MCLK
> > is really used by the codec, or it is possible that it gets its
> > master clock from an other, modem related source, and if this does
> > really matter.
>
> Hmm. Are there any possibility that ams_delta_latch2_write requires
> working MCLK for latch change?
Looks like it doesn't. See below.
> Probably you could use also older implementation to find out is the
> MCLK required for codec by commenting out vc_mclk control.
Thanks! The origial driver with commented out clk_enable(vc_clk) and
clk_disable(vc_clk) still works for me, so MCLK is not required! If I only
knew what to do with this finding...
> Just hack the same "static struct omap_mcbsp_reg_cfg mcbsp_regs =
> { ..." in omap-mcbsp.c and pass that structure instead of
> &mcbsp_data->regs to omap_mcbsp_config in omap_mcbsp_dai_hw_params.
Done. Did not help. Again, I really don't know how to make use of this finding
except for looking in a different place.
I tried to disassemble one of my deltas to get to those pins, but did not yet
find a way to do it without breaking its case. I'll ask at E3-hacking list.
Thanks,
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
Re: [RFC][PATCH] OMAP3: add support for 2 SDRAM chip selects (was: Re: Beagleboard rev C memory timings & suspend/resume)
Hi Paul, OK I will rework the code and send a patch when done. Regards, Jean On Wednesday 03 June 2009 01:40:13 Paul Walmsley wrote: > Hi Jean, > > a minor request: it is easier to comment on these patches if they are > included inline in the E-mail message, rather than attached. That way > code comments can be inlined in the reply. > > On Tue, 26 May 2009, Jean Pihet wrote: > > Here is a patch for the SDRC 2nd CS support. It applies on top of the > > current pm branch. > > Thanks for doing this work. > > > I have some questions: > > - Is it OK to copy the micron sdram params file to a new file with the 2 > > CSes params? One could use a unique file with #ifdef SDRC_SUPPORT_2_CSES. > > Is it possible for the SDRAM parameter files to remain unchanged, and to > simply pass two struct omap_sdrc_params * to omap2_init_common_hw() and > then to omap2_sdrc_init()? Boards with only CS0 in use should pass NULL > for the second omap_sdrc_params *. > > So something like this (I realize the PM branch has additional parameters > here also): > > void __init omap2_init_common_hw(struct omap_sdrc_params *sdrc_cs0, > struct omap_sdrc_params *sdrc_cs1) > > Then: > > void __init omap2_sdrc_init(struct omap_sdrc_params *sdrc_cs0, > struct omap_sdrc_params *sdrc_cs1) > > I would prefer that approach. > > It would also be good to avoid changing the SDRC CS1 parameters in the > SRAM code if the board does not use CS1. Maybe pass in a flag that > indicates whether CS1 is in use, and if not, avoid programming those > registers? The (admittedly minor) overhead of loading the CS1 registers > off the stack would be nice to avoid also. > > > - Does the RX51 board have 2 sdram parts? If so I need to update the > > board file as well. > > Probably best if someone from Nokia handles this. > > > - Paul -- 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
