Hi Mark,
On Tue, Jun 28, 2011 at 00:01:41, Grosen, Mark wrote:
> > From: Nori, Sekhar
> > Sent: Friday, June 24, 2011 8:44 AM
> >
> > Hi Mark,
>
> Sekhar, thanks for your feedback and ideas. Comments below.
>
> Mark
>
> > Since procedure to set the boot address varies across DaVinci
> > platfo
Hi Mark,
On Tue, Jun 28, 2011 at 00:01:41, Grosen, Mark wrote:
> > From: Nori, Sekhar
> > Sent: Friday, June 24, 2011 8:44 AM
> > To assert/de-assert local reset when enabling or disabling PSC,
> > you could use a flag in the clock structure to indicate the need
> > for this. This way, if there i
Hello,
We have a custom designed based on the AM3505 and we wish to run a modern kernel
on it. Unfortunately, it seems a lot of efforts have been made to support other
OMAP chips and that some work is still required to support the AM3505/3517
completely. (does not boot as-is)
Is there anyone wo
Fix id.c to set CHIP_IS_AM35XX instead of CHIP_IS_OMAP3430ES3_1.
Then, in order to enable the same functionalities, we need to
add CHIP_IS_AM35XX where CHIP_IS_OMAP3430, was is used in
clockdomains2xxx_3xxx_data, omap_hwmod_3xxx_data,
powerdomains2xxx_3xxx_data and powerdomains3xxx_data.
Also in
In cpu.h, OMAP35XX_CLASS is currently defined as 0x3534.
the cpu_is_omap34xx() return 1 even on am3505 and am3517.
I'm not sure if the CPU class bits should be changed to 0x35
(redefining OMAP35XX_CLASS to 0x3535). So instead, I'm
adding code to explicitely ignore am3505 and am3517.
Signe
Create a CHIP_IS macro fore AM35xx CPUs.
Signed-off-by: Raphael Assenat
diff --git a/arch/arm/plat-omap/include/plat/cpu.h
b/arch/arm/plat-omap/include/plat/cpu.h
index 8198bb6..f3def59 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -439,6 +439
Add missing definitions for the AM3505/3517 UART4 such
as DMAs, INTs and base address.
Signed-of-by: Raphael Assenat
diff --git a/arch/arm/plat-omap/include/plat/dma.h
b/arch/arm/plat-omap/include/plat/dma.h
index d1c916f..dc562a5 100644
--- a/arch/arm/plat-omap/include/plat/dma.h
+++ b/arch/arm
Add support for the AM35xx UART4 fclk. Based on information
found on TI's E2E forum.
Signed-off-by: Raphael Assenat
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index 75b119b..3706aaa 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/ma
> From: Kevin Hilman
> Date: Fri, Jul 1, 2011 at 11:24 PM
> Subject: Re: [PATCHv4 0/3] OMAP: HSMMC: cleanup and runtime pm
> To: c...@laptop.org
> Cc: Balaji T K , linux-omap@vger.kernel.org,
> linux-...@vger.kernel.org, t...@atomide.com, madhu...@ti.com,
> b-cous...@ti.com, p...@pwsan.com, kishor
Hi Peter,
On Mon, Jul 04, 2011 at 05:08:17PM +0300, Péter Ujfalusi wrote:
> Hi Samuel,
>
> On Monday 04 July 2011 13:48:44 Samuel Ortiz wrote:
> > I don't see the value of those 3 inline functions. Removing them would make
> > the code actually more understandable (especially for the 2nd one).
>
Charulatha, Jon,
I want to write a client GPIO driver to handle IR device connecting to GPIO191
or GPIO154.
Based on http://omappedia.org/wiki/GPIO, arch/arm/plat-omap/gpio.c is a OMAP
core gpio driver, customer can write a client gpio driver on top of it to
select one GPIO pin such as GPIO19
Hi Keshava,
On Sat, Jul 02, 2011 at 12:24:28AM +0530, Keshava Munegowda wrote:
> From: Keshava Munegowda
>
> The Hwmod structures and Runtime PM features are implemented
> For EHCI and OHCI drivers of OMAP3 and OMAP4.
> The global suspend/resume of EHCI and OHCI
> is validated on OMAP3430 sdp bo
On Mon, 4 Jul 2011, Felipe Balbi wrote:
> sounds to me like a bug on pm runtime ? If you're calling
> pm_runtime_*_sync() family, shouldn't all calls be _sync() too ?
No. This was a deliberate design decision. It minimizes stack usage
and it gives a chance for some other child to resume before
On Mon, 4 Jul 2011, Partha Basak wrote:
> >I don't see any point in these routines (and likewise for
> >omap_ohci_suspend/resume). When the whole system is going to sleep
> >anyway, what reason is there for enabling runtime PM on the parent
> >device?
>
> Both for EHCI & OHCI, the clocks are own
From: Julia Lawall
At this point, the ioremap has taken place, so the error handling code at
the label err_iounmap should be used rather than returning directly.
The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)
//
@r@
identifier x;
@@
kfree(x)
@@
identif
Hi Samuel,
On Monday 04 July 2011 13:48:44 Samuel Ortiz wrote:
> I don't see the value of those 3 inline functions. Removing them would make
> the code actually more understandable (especially for the 2nd one).
Is it OK for you if I fix these as a follow-up series, so I do not need to
rewrite th
Hi,
On Mon, Jul 04, 2011 at 04:09:30PM +0300, Péter Ujfalusi wrote:
> Hi Felipe, Samuel,
>
> On Monday 04 July 2011 14:53:30 Balbi, Felipe wrote:
> > > + ret = twl6040_request_irq(twl6040, TWL6040_IRQ_READY,
> > > + twl6040_naudint_handler, 0,
> > > +
Hi Samuel,
On Monday 04 July 2011 13:48:44 Samuel Ortiz wrote:
> Hi Peter,
>
> On Tue, Jun 21, 2011 at 04:39:06PM +0300, Peter Ujfalusi wrote:
> > +int twl6040_is_powered(struct twl6040 *twl6040)
> > +{
> > + return twl6040->power_count;
> > +}
> > +EXPORT_SYMBOL(twl6040_is_powered);
>
> Do we
Hi Felipe, Samuel,
On Monday 04 July 2011 14:53:30 Balbi, Felipe wrote:
> > + ret = twl6040_request_irq(twl6040, TWL6040_IRQ_READY,
> > + twl6040_naudint_handler, 0,
> > + "twl6040_irq_ready", twl6040);
>
> why don'
hi,
On Tue, Jun 21, 2011 at 04:39:06PM +0300, Peter Ujfalusi wrote:
> +static int __devinit twl6040_probe(struct platform_device *pdev)
> +{
> + struct twl4030_audio_data *pdata = pdev->dev.platform_data;
> + struct twl6040 *twl6040;
> + struct mfd_cell *cell = NULL;
> + int ret, c
Hi Tony,
On Mon, Jun 27, 2011 at 11:17:21PM -0700, Tony Lindgren wrote:
> * Péter Ujfalusi [110627 07:25]:
> > Hi Tony,
> >
> > On Monday 27 June 2011 12:18:35 Tony Lindgren wrote:
> > > * Péter Ujfalusi [110627 02:39]:
> > >
> > > > Hi Tony, Samuel,
> > > >
> > > > Would you have time to tak
Hi Peter,
On Tue, Jun 21, 2011 at 04:39:06PM +0300, Peter Ujfalusi wrote:
> +int twl6040_is_powered(struct twl6040 *twl6040)
> +{
> + return twl6040->power_count;
> +}
> +EXPORT_SYMBOL(twl6040_is_powered);
Do we really need to export this one ?
> +static inline int twl6040_get_rev(struct twl6
Provide APIs to be used by the driver in order to modify AUTOIDLE
and SIDLE bits. These APIs in turn call hwmod APIs to modify the
SYSCONFIG register.
Signed-off-by: Kishon Vijay Abraham I
Signed-off-by: Benoit Cousson
Cc: Paul Walmsley
---
arch/arm/plat-omap/include/plat/omap_device.h |6
Provide APIs to be used by the omap_device layer in order to modify AUTOIDLE
and SIDLE bits.
Signed-off-by: Kishon Vijay Abraham I
Signed-off-by: Benoit Cousson
Cc: Paul Walmsley
---
arch/arm/mach-omap2/omap_hwmod.c | 93 ++
arch/arm/plat-omap/include/plat
Certain peripherals require autoidle bits to be disabled before performing
some operations. This patch series provides APIs in omap_device layer and
omap_hwmod layer to modify the SYSCONFIG register.
Since current implementation of PM run time framework does not support
changing sysconfig setting
>-Original Message-
>From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
>ow...@vger.kernel.org] On Behalf Of Felipe Balbi
>Sent: Monday, July 04, 2011 3:01 PM
>To: Partha Basak
>Cc: ba...@ti.com; Alan Stern; Keshava Munegowda; linux-
>u...@vger.kernel.org; linux-omap@vger.kernel.org
Hi,
On Mon, Jul 04, 2011 at 02:56:30PM +0530, Partha Basak wrote:
> >> Both for EHCI & OHCI, the clocks are owned by the parent (uhh-tll).
> >>
> >> Calling pm_runtime_put_sync(dev->parent) within omap_ehci_suspend will
> >> turn-off the parent clocks in the Suspend path.
> >>
> >> Similarly, call
>-Original Message-
>From: Felipe Balbi [mailto:ba...@ti.com]
>Sent: Monday, July 04, 2011 1:56 PM
>To: Partha Basak
>Cc: Alan Stern; Keshava Munegowda; linux-...@vger.kernel.org; linux-
>o...@vger.kernel.org; linux-ker...@vger.kernel.org; Felipe Balbi; Anand
>Gadiyar; sa...@linux.intel.com
On Fri, Jul 1, 2011 at 11:06 PM, Kevin Hilman wrote:
> From: Madhusudhan Chikkature
>
> Update the OMAP HS MMC entry from the MAINTAINERS file as I will
> no longer be able to maintain this driver.
>
> Signed-off-by: Madhusudhan Chikkature
> [khil...@ti.com: change to Orphan rather than complete
* Paul Walmsley [110702 17:58]:
> On some boards, it's not possible to reset certain IP blocks during
> kernel initialization. Some boards connect GPIO lines to external
> voltage controllers, so resetting them may cause voltage to drop on a
> critical supply[1]. Other boards connect GPIO lines
* Paul Walmsley [110702 21:09]:
> Hi Tony
>
> On Thu, 30 Jun 2011, Tony Lindgren wrote:
>
> > NAK for this patch. We don't want any of this in init_early.
> >
> > The problem is with hwmod core code that wrongly assumes it
> > can just reset all devices.
>
> I don't think the hwmod core code h
On Monday, July 04, 2011, Vishwanath Sripathy wrote:
> > -Original Message-
> > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> > ow...@vger.kernel.org] On Behalf Of Rafael J. Wysocki
> > Sent: Sunday, July 03, 2011 12:51 AM
> > To: jean.pi...@newoldbits.com
> > Cc: Paul Walmsl
Hi,
On Mon, Jul 04, 2011 at 10:36:54AM +0530, Partha Basak wrote:
> >-Original Message-
> >From: Alan Stern [mailto:st...@rowland.harvard.edu]
> >Sent: Saturday, July 02, 2011 12:37 AM
> >To: Keshava Munegowda
> >Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org; linux-
> >ker...@v
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Rafael J. Wysocki
> Sent: Sunday, July 03, 2011 12:51 AM
> To: jean.pi...@newoldbits.com
> Cc: Paul Walmsley; Kevin Hilman; Magnus Damm; Linux PM mailing list;
> linux-oma
34 matches
Mail list logo
