Re: [PATCH 3/5] omap3: cm-t3517: add support for usb host.
On Thu, Sep 16, 2010 at 04:12:06AM -0500, Igor Grinberg wrote: Yes it will, but even if the hub reset gpio is for some reason unavailable, we don't want to disable ehci completely... then you should set the gpio to an invalid number, otherwise you might cause lots of WARN() to appear due to fiddling with unrequested gpio. -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 00/11] OMAP2/TWL: Fix Sparse warnings
Tony, > -Original Message- > From: Tony Lindgren [mailto:t...@atomide.com] > Sent: Friday, September 17, 2010 1:04 AM > To: G, Manjunath Kondaiah > Cc: linux-omap@vger.kernel.org; Menon, Nishanth > Subject: Re: [PATCH 00/11] OMAP2/TWL: Fix Sparse warnings > > * G, Manjunath Kondaiah [100826 13:50]: > > This patch series fixes sparse warnings for OMAP and TWL code. > > For better readabilty the patches are categorised based on type of > > sparse warnigns. > > > > The sparse warning logs are embedded with each patch > followed by fix. > > > > Build and boot tested on omap3 with omap3_defconfig. > > > > Manjunatha GK (11): > > OMAP: mach-omap2: Fix incorrect assignment warnings > > OMAP: mach-omap2: Fix static declaration warnings > > OMAP: mach-omap2: Fix static function warnings > > OMAP: mach-omap2: Fix miscellaneous sparse warnings > > OMAP: plat-omap: Fix static function warnings > > OMAP: McBSP: Fix static function warning > > OMAP: HSMMC: Fix unused variable warning > > OMAP: NAND: Fix static declaration warning > > TWL CORE: Fix sparse warning > > TWL IRQ: Fix fucntion declaration warnings > > TWL4030: Codec: Fix fucntion declaration error > > Looks like these are almost ready to go. Please repost against > v2.6.36-rc4 with linux-arm-kernel list Cc'd. Also check that > the related driver list is Cc'd. > > Then, assuming no more comments, can you set up a git branch > somewhere for me to pull? For more info, see "Merging patches > using git" at: > > http://www.elinux.org/OMAP_patch_merging_process#Patch_submiss > ion_checklist Ok. I will do that along with v2 version of this patch series. -Manjunath-- 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 04/11] OMAP: mach-omap2: Fix miscellaneous sparse warnings
> -Original Message-
> From: Tony Lindgren [mailto:t...@atomide.com]
> Sent: Friday, September 17, 2010 12:58 AM
> To: G, Manjunath Kondaiah
> Cc: linux-omap@vger.kernel.org; Menon, Nishanth
> Subject: Re: [PATCH 04/11] OMAP: mach-omap2: Fix
> miscellaneous sparse warnings
>
> * G, Manjunath Kondaiah [100826 13:50]:
> > From: Manjunatha GK
...
> > I2C_BOARD_INFO("s35390a", 0x30),
> > - .type = "s35390a",
> > },
> > };
>
> OK, I2C_BOARD_INFO sets it too.
>
> > diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
> > index 26aeef5..02fd942 100644
> > --- a/arch/arm/mach-omap2/irq.c
> > +++ b/arch/arm/mach-omap2/irq.c
> > @@ -47,7 +47,7 @@ static struct omap_irq_bank { } __attribute__
> > ((aligned(4))) irq_banks[] = {
> > {
> > /* MPU INTC */
> > - .base_reg = 0,
> > + .base_reg = (void __iomem *)0,
> > .nr_irqs= 96,
> > },
> > };
>
> The base_reg line you can remove, the static data area gets
> zeroed during init.
Ok.
-Manjunath
--
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
How to enable sys_clkout1 for use by brf6300
All, I have a brf6300 that requires sys_clkout1, and I have it working fine right now, but if I enable CONFIG_OMAP_RESET_CLOCKS, then sys_clkou1 is disabled. How do I tell the system that I need sys_clkout1 enabled for the brf6300 chip to work? Should I use "clk = clk_get(NULL, "sys_clkout1"); clk_enable(clk)'"? Thanks in advance! -- 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 v.4] omap: hwspinlock: Added hwspinlock driver
Hi Hari,
On Thu, Aug 12, 2010 at 12:44 AM, Kanigeri, Hari wrote:
>> > +/* Attempt to acquire a spinlock once */
>> > +int hwspinlock_trylock(struct hwspinlock *handle)
>> > +{
>> > + int retval = 0;
>> > +
>> > + if (WARN_ON(handle == NULL))
>> > + return -EINVAL;
>> > +
>> > + if (WARN_ON(in_irq()))
>> > + return -EPERM;
>> > +
>> > + if (pm_runtime_get(&handle->pdev->dev) < 0)
>> > + return -ENODEV;
>> > +
>> > + /* Attempt to acquire the lock by reading from it */
>> > + retval = readl(handle->lock_reg);
>> > +
>> > + if (retval == HWSPINLOCK_BUSY)
>> > + pm_runtime_put(&handle->pdev->dev);
>> Any reason for using pm_runtime_put instead of pm_runtime_put_sync?
>>
>> Using pm_runtime_gett_sync & pm_runtime_put_sync have been recommended by
>> Kevin Hilman.
>
> Actually is there a need to call pm_runtime_put_sync for hwspinlock ?
> Spinlocks are used by the co-processors and we have to ensure that the device
> doesn't enter some low power mode without the knowledge of Co-processor. I
> don't think run time PM is needed for hwspinlock.
>
> Just doing pm_runtime_get_sync at probe time for all the spinlock instances
> should be good.
It would probably make more sense to call pm_runtime_get_sync during
hwspinlock_request{_specific}, and then call pm_runtime_put during
hwspinlock_free.
This way the runtime PM's usage_count will reflect the number of locks
that are actually used, and if that number drops to (or never go
beyond) zero, it is desirable to have the hwspinlock's clock disabled.
This is also safe since no other core will use the hwspinlock if it
wasn't requested by the MPU beforehand (and if it does, we better know
about it and fix it).
Thanks,
Ohad.
--
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 3/5] omap3: cm-t3517: add support for usb host.
On 09/16/10 19:48, Tony Lindgren wrote: > * Igor Grinberg [100916 02:04]: >> Hi, >> >> On 09/16/10 11:00, Felipe Balbi wrote: >>> Hi, >>> >>> On Thu, Sep 16, 2010 at 03:54:39AM -0500, Igor Grinberg wrote: >>> >>> put a description here. >> This is a relatively small patch, is the subject not descriptive enough? > In that case just copy the subject (without the [PATCH] part) to the > description for all of your patches. Ok, will do and re-spin. Thanks > Regards, > > Tony > -- Regards, Igor. -- 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 1/5] omap3: Introduce CompuLab CM-T3517 module.
On 09/16/10 19:53, Tony Lindgren wrote: > * Igor Grinberg [100916 01:46]: >> Add basic suppot, enable uart and led. >> >> Signed-off-by: Igor Grinberg >> --- >> arch/arm/mach-omap2/Kconfig |7 ++ >> arch/arm/mach-omap2/Makefile |1 + >> arch/arm/mach-omap2/board-cm-t3517.c | 109 >> ++ >> 3 files changed, 117 insertions(+), 0 deletions(-) >> create mode 100644 arch/arm/mach-omap2/board-cm-t3517.c > Looks like you're missing the debug uart entry for > arch/arm/plat-omap/include/plat/uncompress.h? > > You can test this by enabling DEBUG_LL and EARLY_PRINTK > in your .config, then pass earlyprintk in the kernel > cmdline. Might become handy for debugging the early > init process for your board. Indeed can be useful. Thanks. > 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 > -- Regards, Igor. -- 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
