On Thu, Jun 17, 2010 at 12:40:35PM +0200, ext Ajay Kumar Gupta wrote:
From: Sergei Shtylyov sshtyl...@ru.mvista.com
Attempt to build MUSB driver with CONFIG_PM=y (e.g. in the OTG mode) on DaVinci
results in these link errors:
drivers/built-in.o: In function `musb_restore_context':
On Thu, Jun 17, 2010 at 12:40:36PM +0200, ext Ajay Kumar Gupta wrote:
+#ifdef CONFIG_USB_MUSB_HDRC_HCD
+ void __iomem*mbase = musb-mregs;
+#endif
then you add another ifdef to this file, which is already insane. I'd
rather see you either keep the local variables and just fix what
Paul Walmsley wrote:
On Mon, 21 Jun 2010, Paul Walmsley wrote:
On Sat, 19 Jun 2010, Gadiyar, Anand wrote:
Gadiyar, Anand wrote:
We need to wait on the IDLEST bit after the clocks are enabled
before attempting to access any register.
Currently, the USBTLL i-clock ops uses the
On Thu, Jun 17, 2010 at 12:40:37PM +0200, ext Ajay Kumar Gupta wrote:
From: Jon Povey jon.po...@racelogic.co.uk
Wrap flags with uninitialized_var() to suppress this:
drivers/usb/musb/cppi_dma.c:1158: warning: 'flags' may be used uninitialized
in this function
Signed-off-by: Jon Povey
On Thu, Jun 17, 2010 at 12:40:38PM +0200, ext Ajay Kumar Gupta wrote:
From: Mike Frysinger vap...@gentoo.org
The new ulpi code defines fallback stubs for the Blackfin arch, but does
so incorrectly leading to a build failure:
drivers/usb/musb/musb_core.c:227: error: 'musb_ulpi_read' undeclared
On Thu, Jun 17, 2010 at 12:40:39PM +0200, ext Ajay Kumar Gupta wrote:
From: Hema HK hem...@ti.com
Setting MUSB Burst Mode 3 automatically enables support for
lower burst modes (BURST4, BURST8, BURST16 or bursts of unspecified
length). There is no need to set these burst modes based on the
Felipe Balbi wrote:
On Thu, Jun 17, 2010 at 12:40:40PM +0200, ext Ajay Kumar Gupta wrote:
From: Anand Gadiyar gadi...@ti.com
This pin-muxing is best done in the board files. The driver should
not do this explicitly.
Also, this code causes a warning to be thrown when OMAP2430 and OMAP3/4
On Thu, Jun 17, 2010 at 12:40:34PM +0200, ext Ajay Kumar Gupta wrote:
From: Sergei Shtylyov sshtyl...@ru.mvista.com
Commit 1c25fda4a09e8229800979986ef399401053b46e (usb: musb: handle irqs in the
order dictated by programming guide) forgot to get rid of the old 'STAGE0_MASK'
filter for calling
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Wednesday, June 23, 2010 11:17 PM
To: Gopinath, Thara
Cc: linux-omap@vger.kernel.org; Menon, Nishanth; Cousson, Benoit
Subject: Re: [PATCH 05/12] OMAP: create omap_devices for MPU, DSP, L3
Gopinath, Thara
Hi Kevin,
some comments below -
On Wed, 23 Jun 2010, Kevin Hilman wrote:
Create simple omap_devices for the main processors and busses.
This is required to support the forth-coming device-based OPP
approach, where OPPs are managed and tracked at the device level.
So that these primary
Hi Tony,
what do you think on this one? -rc or .36?
- Paul
On Thu, 24 Jun 2010, Gadiyar, Anand wrote:
Paul Walmsley wrote:
On Mon, 21 Jun 2010, Paul Walmsley wrote:
On Sat, 19 Jun 2010, Gadiyar, Anand wrote:
Gadiyar, Anand wrote:
We need to wait on the IDLEST bit after the
Hi Kevin,
aside from these comments:
http://marc.info/?l=linux-omapm=127735008820992w=2
one other minor issue -
On Wed, 23 Jun 2010, Kevin Hilman wrote:
Hook into the platform bus methods for suspend and resume and
use the omap_device API to automatically idle and enable the
device on
Hi Kevin,
one other thought.
On Thu, 24 Jun 2010, Paul Walmsley wrote:
On Wed, 23 Jun 2010, Kevin Hilman wrote:
Create simple omap_devices for the main processors and busses.
This is required to support the forth-coming device-based OPP
approach, where OPPs are managed and tracked
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Paul
Walmsley
Sent: Thursday, June 24, 2010 11:57 AM
To: Kevin Hilman
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH 11/13] OMAP: create omap_devices for MPU, DSP,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Varadarajan, Charulatha
Sent: Tuesday, June 22, 2010 8:32 PM
To: linux-omap@vger.kernel.org
Cc: khil...@deeprootsystems.com; p...@pwsan.com; t...@atomide.com; Nayak,
One correction here:
On Wed, 23 Jun 2010, Paul Walmsley wrote:
On Mon, 21 Jun 2010, Kevin Hilman wrote:
Just to clarify. The functions I'm overriding here is the bus
functions (bus-pm-[suspend|resume]_noirq(), not any driver functions
OK, I see that now - this code was confusing in
On Wed, Jun 23, 2010 at 6:43 PM, Andy Shevchenko
andy.shevche...@gmail.com wrote:
... I could prepare patch in standard form, if you want to
That could be great, thanks !
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
On Thu, 24 Jun 2010, Shilimkar, Santosh wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Paul
Walmsley
Sent: Thursday, June 24, 2010 11:57 AM
+struct device *omap_get_mpu_device(void)
+{
+ mpu_dev
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Thursday, June 24, 2010 12:50 PM
To: Shilimkar, Santosh
Cc: Kevin Hilman; linux-omap@vger.kernel.org
Subject: RE: [PATCH 11/13] OMAP: create omap_devices for MPU, DSP, L3
On Thu, 24 Jun 2010, Shilimkar, Santosh
Define a new module parameter 'macaddr' to override the MAC address
fetched either from eeprom, or randomly generated.
The expected MAC address shall be in the 01:23:45:67:89:AB format.
Signed-off-by: Sebastien Jan s-...@ti.com
---
drivers/net/usb/smsc95xx.c | 56
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Varadarajan, Charulatha
Sent: Tuesday, June 15, 2010 8:36 PM
To: davi...@pacbell.net; broo...@opensource.wolfsonmicro.com; a...@linux-
foundation.org;
Hello.
Felipe Balbi wrote:
From: Jon Povey jon.po...@racelogic.co.uk
Wrap flags with uninitialized_var() to suppress this:
drivers/usb/musb/cppi_dma.c:1158: warning: 'flags' may be used
uninitialized
in this function
Signed-off-by: Jon Povey jon.po...@racelogic.co.uk
Signed-off-by:
AM3505/3517 don't have IO wakeup capability, so we don not need to set
the bit OMAP3430_EN_IO and the bit OMAP3430_EN_IO_CHAIN in the register
PM_WKEN_WKUP when the system enters retention.
Signed-off-by: Stanley.Miao stanley.m...@windriver.com
---
arch/arm/mach-omap2/id.c |2 ++
Zach Pfeffer zpfef...@codeaurora.org writes:
This patch contains the documentation for and the main header file of
the API, termed the Virtual Contiguous Memory Manager. Its use would
allow all of the IOMMU to VM, VM to device and device to IOMMU
interoperation code to be refactored into
On Thu, 2010-06-17 at 07:12 +0200, ext Nagarajan, Rajkumar wrote:
When switching between clocks, The new functional clock is
effective when the next vertical blanking interval occurs.
GOLCD bit has to be set for the new clock to take effect.
Where did you encounter this problem?
On Tue, Jun 22, 2010 at 7:43 PM, Ghorai, Sukumar s-gho...@ti.com wrote:
-Original Message-
From: zhangfei gao [mailto:zhangfei@gmail.com]
Sent: Tuesday, June 22, 2010 4:51 PM
To: Chikkature Rajashekar, Madhusudhan
Cc: Tony Lindgren; Menon, Nishanth; Ghorai, Sukumar; linux-
+#ifdef CONFIG_USB_MUSB_HDRC_HCD
+void __iomem*mbase = musb-mregs;
+#endif
then you add another ifdef to this file, which is already insane. I'd
rather see you either keep the local variables and just fix what needs
to be fixed,
or use musb-mregs directly.
This one seems to be a
Hi Paul,
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Thursday, June 24, 2010 7:05 AM
Benoît,
one minor comment here:
On Wed, 23 Jun 2010, Kevin Hilman wrote:
From: Benoit Cousson b-cous...@ti.com
In the lastest OMAP4 hwmod data file, the _hwmod was removed
in order to save some
-Original Message-
From: zhangfei gao [mailto:zhangfei@gmail.com]
Sent: Thursday, June 24, 2010 4:26 PM
To: Ghorai, Sukumar
Cc: Chikkature Rajashekar, Madhusudhan; Tony Lindgren; Menon, Nishanth;
linux-omap@vger.kernel.org; linux-...@vger.kernel.org
Subject: Re: [PATCH]
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Paul Walmsley
Sent: Thursday, June 24, 2010 10:39 AM
To: Kevin Hilman
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH 06/13] OMAP: hwmod: add non-locking versions
Hello.
Gupta, Ajay Kumar wrote:
+#ifdef CONFIG_USB_MUSB_HDRC_HCD
+ void __iomem*mbase = musb-mregs;
+#endif
then you add another ifdef to this file, which is already insane. I'd
rather see you either keep the local variables and just fix what needs
to be fixed,
or use
From: Omar Ramirez Luna omar.rami...@ti.com
Add Kconfig + Makefile for TI's DSP Bridge driver
and expose it to the staging menu.
For now, have tidspbridge depend on ARCH_OMAP3.
That dependency should be relaxed as soon as required cleanups are applied.
Signed-off-by: Omar Ramirez Luna
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Thursday, June 24, 2010 12:11 AM
To: Nayak, Rajendra
Cc: Kevin Hilman; linux-omap@vger.kernel.org; Cousson, Benoit
Subject: Re: [PATCH 08/13] OMAP4: hwmod: Enable omap_device build for OMAP4
Hi Rajendra
On
then you add another ifdef to this file, which is already insane. I'd
rather see you either keep the local variables and just fix what needs
to be fixed,
or use musb-mregs directly.
This one seems to be a much better one. Copying the v-3 with this fix
below.
I don't see how
-Original Message-
From: Gadiyar, Anand
Sent: Wednesday, June 23, 2010 6:03 PM
To: Koen Kooi; Kevin Hilman; Hunter, Jon
Cc: Anders, David; linux-...@vger.kernel.org; linux-omap@vger.kernel.org;
Gupta, Ajay Kumar; felipe.ba...@nokia.com
Subject: RE: [PATCH] select NOP_USB_XCEIV for
Kevin,
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Friday, June 18, 2010 8:29 PM
To: Kalliguddi, Hema
Cc: Cousson, Benoit; Basak, Partha; p...@pwsan.com; Nayak,
Rajendra; linux-omap@vger.kernel.org
Subject: Re: On the APIs for Enabling and Disabling
Kevin,
Replying on top of latest chin.
Thanks,
Hema
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Thursday, June 24, 2010 2:01 AM
To: Basak, Partha
Cc: Kalliguddi, Hema; Cousson, Benoit; p...@pwsan.com; Nayak,
Rajendra; linux-omap@vger.kernel.org
We are implementing a driver for our camera device attached through USB
through the extansion connector. The device+driver seems to be working
well on a PC platform using the kernel version 2.6.24. When we try to
move to a labrador, omap device the camera stops working.
The camera sends the
Looks good.
Iommu get has similar signature, probably we could change that too to take the
mmu fault notification function as a function argument.
Thank you,
Best regards,
Hari
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On
Kevin,
Thanks
Partha
-Original Message-
From: Kalliguddi, Hema
Sent: Thursday, June 24, 2010 8:25 PM
To: Kevin Hilman; Basak, Partha
Cc: Cousson, Benoit; p...@pwsan.com; Nayak, Rajendra; linux-
o...@vger.kernel.org; Gadiyar, Anand; Kamat, Nishant
Subject: RE: On the APIs for
Ohad,
mbox_configured is global and therefore does not support
concurrent usage of multiple mailbox instances.
-- Why do you say that it doesn't support concurrent usage of multiple mailbox
instances ? If you take example of OMAP4, we have 2 mailbox instances, one
talking to DSP and other to
Anders, David wrote:
-Original Message-
From: Gadiyar, Anand
Sent: Wednesday, June 23, 2010 6:03 PM
To: Koen Kooi; Kevin Hilman; Hunter, Jon
Cc: Anders, David; linux-...@vger.kernel.org; linux-omap@vger.kernel.org;
Gupta, Ajay Kumar; felipe.ba...@nokia.com
Subject: RE:
On Thu, Jun 24, 2010 at 09:01:51AM +0300, Felipe Balbi wrote:
On Thu, Jun 17, 2010 at 12:40:34PM +0200, ext Ajay Kumar Gupta wrote:
From: Sergei Shtylyov sshtyl...@ru.mvista.com
Commit 1c25fda4a09e8229800979986ef399401053b46e (usb: musb: handle irqs in
the
order dictated by programming
-Original Message-
From: Gadiyar, Anand
Sent: Thursday, June 24, 2010 10:53 AM
To: Anders, David; Koen Kooi; Kevin Hilman; Hunter, Jon
Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org; Gupta, Ajay
Kumar; felipe.ba...@nokia.com
Subject: RE: [PATCH] select NOP_USB_XCEIV for
Paul Walmsley p...@pwsan.com writes:
On Mon, 21 Jun 2010, Kevin Hilman wrote:
Paul Walmsley p...@pwsan.com writes:
I guess the intent of your patch is to avoid having to patch in
omap_device_{idle,enable}() into a bunch of driver DPM suspend/resume
callbacks?
Partially.
On Thu, 24 Jun 2010, Paul Walmsley wrote:
Sorry, misread this also. Indeed, something like this is necessary in
your platform bus override code - so please ignore this part of the
comments.
By the way, I owe you a more general apology, Kevin, that some of these
comments have been
Paul Walmsley p...@pwsan.com writes:
Hi Kevin,
aside from these comments:
http://marc.info/?l=linux-omapm=127735008820992w=2
one other minor issue -
On Wed, 23 Jun 2010, Kevin Hilman wrote:
Hook into the platform bus methods for suspend and resume and
use the omap_device API to
Paul Walmsley p...@pwsan.com writes:
Hi Kevin,
something doesn't make sense in this patch...
On Wed, 23 Jun 2010, Kevin Hilman wrote:
If an omap_hwmod is setup using HWMOD_INIT_NO_IDLE flag, there is
currently way to idle it since omap_hwmod_idle() requires the hwmod to
be in the enabled
Nayak, Rajendra rna...@ti.com writes:
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Thursday, June 24, 2010 12:11 AM
To: Nayak, Rajendra
Cc: Kevin Hilman; linux-omap@vger.kernel.org; Cousson, Benoit
Subject: Re: [PATCH 08/13] OMAP4: hwmod: Enable omap_device
Paul Walmsley p...@pwsan.com writes:
Hi Kevin
On Wed, 23 Jun 2010, Kevin Hilman wrote:
Some hwmods may need to be idled/enabled in atomic context, so
non-locking versions of these functions are required.
Most users should not need these and usage of theses should be
controlled to
Basak, Partha p-bas...@ti.com writes:
[...]
/**
* omap_hwmod_idle - idle an omap_hwmod
* @oh: struct omap_hwmod *
@@ -1319,9 +1345,7 @@ int omap_hwmod_idle(struct omap_hwmod *oh)
if (!oh)
return -EINVAL;
- mutex_lock(omap_hwmod_mutex);
- _idle(oh);
-
Paul Walmsley p...@pwsan.com writes:
Hi Kevin,
one other thought.
On Thu, 24 Jun 2010, Paul Walmsley wrote:
On Wed, 23 Jun 2010, Kevin Hilman wrote:
Create simple omap_devices for the main processors and busses.
This is required to support the forth-coming device-based OPP
On Thu, 24 Jun 2010, Kevin Hilman wrote:
Paul Walmsley p...@pwsan.com writes:
Hi Kevin,
A few comments:
Your add runtime PM support at bus-level series has a unstated
dependency on this patch. If you fix one minor issue (below), it's
probably easiest if you merge it with that
Gopinath, Thara th...@ti.com writes:
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Wednesday, June 23, 2010 11:17 PM
To: Gopinath, Thara
Cc: linux-omap@vger.kernel.org; Menon, Nishanth; Cousson, Benoit
Subject: Re: [PATCH 05/12] OMAP: create omap_devices
Paul Walmsley p...@pwsan.com writes:
On Thu, 24 Jun 2010, Kevin Hilman wrote:
Paul Walmsley p...@pwsan.com writes:
Hi Kevin,
A few comments:
Your add runtime PM support at bus-level series has a unstated
dependency on this patch. If you fix one minor issue (below), it's
Anders, David x0132...@ti.com writes:
-Original Message-
From: Gadiyar, Anand
Sent: Wednesday, June 23, 2010 6:03 PM
To: Koen Kooi; Kevin Hilman; Hunter, Jon
Cc: Anders, David; linux-...@vger.kernel.org; linux-omap@vger.kernel.org;
Gupta, Ajay Kumar; felipe.ba...@nokia.com
Subject:
Hi Kevin,
On Wed, 23 Jun 2010, Kevin Hilman wrote:
Add a new hwmod class for DSP devices. To be used when hwmods
are created for DSP on OMAP3 (a.k.a. IVA2.)
I guess this patch is not needed any more? But if it is, it might be best
to name the class iva2 or something like that, since the
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Thursday, June 24, 2010 12:52 PM
To: Nayak, Rajendra
Cc: Paul Walmsley; linux-omap@vger.kernel.org; Cousson, Benoit
Subject: Re: [PATCH 08/13] OMAP4: hwmod: Enable omap_device build for OMAP4
Nayak,
Add initial support for the OMAP4 based Panda Board.
Signed-off-by: David Anders x0132...@ti.com
---
arch/arm/mach-omap2/Kconfig|4 +
arch/arm/mach-omap2/Makefile |2 +
arch/arm/mach-omap2/board-omap4panda.c | 305
3 files changed,
On Thu, Jun 24, 2010 at 6:10 PM, Kanigeri, Hari h-kanige...@ti.com wrote:
Ohad,
mbox_configured is global and therefore does not support
concurrent usage of multiple mailbox instances.
-- Why do you say that it doesn't support concurrent usage of multiple
mailbox instances ? If you take
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Ohad Ben-Cohen
Sent: Tuesday, June 22, 2010 7:12 PM
To: linux-omap@vger.kernel.org
Cc: Hiroshi Doyu; Ramirez Luna, Omar; Ohad Ben-Cohen
Subject: [PATCH 1/4] omap
Paul Walmsley p...@pwsan.com writes:
Hi Kevin,
On Wed, 23 Jun 2010, Kevin Hilman wrote:
Add a new hwmod class for DSP devices. To be used when hwmods
are created for DSP on OMAP3 (a.k.a. IVA2.)
I guess this patch is not needed any more? But if it is, it might be best
to name the class
Kevin Hilman khil...@deeprootsystems.com writes:
Add hwmod data for DSP on OMAP3 (a.k.a. IVA2.)
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
Also changing the name here from dsp to iva2.
Kevin
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |
Kevin Hilman khil...@deeprootsystems.com writes:
Paul Walmsley p...@pwsan.com writes:
Hi Kevin,
On Wed, 23 Jun 2010, Kevin Hilman wrote:
Add a new hwmod class for DSP devices. To be used when hwmods
are created for DSP on OMAP3 (a.k.a. IVA2.)
I guess this patch is not needed any more?
omap_change_voltscale_method is to be used by board files
to choose which mechanism they would prefer to do update
of voltage to thier PMIC. unless we expose it, they cant
use it.
This also fixes sparse warning:
arch/arm/mach-omap2/voltage.c:1046:6: warning: symbol
'omap_change_voltscale_method'
This series removes few of the sparse warnings I found. This series
probably should be squashed with other patches in pm-sr branch
Nishanth Menon (4):
omap: sr: export sr_dbg_dir
omap3: sr: sr_exit should be static
omap3: voltage: make required variables static
omap3: voltage: expose
sr_dbg_dir is currently used privately in smartreflex.c, however,
smartreflex class drivers could store their own debugfs entries there
as well.
This also fixes the sparse warning:
arch/arm/mach-omap2/smartreflex.c:44:15: warning: symbol 'sr_dbg_dir' was not
declared. Should it be static?
Cc:
sr_exit has no business being a public function.
fixes sparse:
arch/arm/mach-omap2/smartreflex.c:959:13: warning: symbol 'sr_exit' was not
declared. Should it be static?
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Thara Gopinath th...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
debugfs voltage_dir - used only by voltage layer and no reason for
others to add data to it, so make it static. omap3_vp_offs,
volt_mod have no business being exposed as global. make them static
This fixes sparse warnings:
arch/arm/mach-omap2/voltage.c:42:15: warning: symbol 'voltage_dir' was
Kevin Hilman khil...@deeprootsystems.com writes:
Kevin Hilman khil...@deeprootsystems.com writes:
Paul Walmsley p...@pwsan.com writes:
Hi Kevin,
On Wed, 23 Jun 2010, Kevin Hilman wrote:
Add a new hwmod class for DSP devices. To be used when hwmods
are created for DSP on OMAP3 (a.k.a.
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Ohad Ben-Cohen
Sent: Thursday, June 24, 2010 3:23 PM
To: Kanigeri, Hari
Cc: linux-omap@vger.kernel.org; Hiroshi Doyu; Ramirez Luna, Omar
Subject: Re: [PATCH 3/4] omap
On 6/24/2010 10:43 PM, Kevin Hilman wrote:
Kevin Hilmankhil...@deeprootsystems.com writes:
Add hwmod data for DSP on OMAP3 (a.k.a. IVA2.)
Cc: Paul Walmsleyp...@pwsan.com
Signed-off-by: Kevin Hilmankhil...@deeprootsystems.com
Also changing the name here from dsp to iva2.
You should just
Nayak, Rajendra rna...@ti.com writes:
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Thursday, June 24, 2010 12:52 PM
To: Nayak, Rajendra
Cc: Paul Walmsley; linux-omap@vger.kernel.org; Cousson, Benoit
Subject: Re: [PATCH 08/13] OMAP4: hwmod: Enable
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of C.A,
Subramaniam
Sent: Thursday, June 24, 2010 4:36 PM
To: Ohad Ben-Cohen; Kanigeri, Hari
Cc: linux-omap@vger.kernel.org; Hiroshi Doyu; Ramirez Luna, Omar
Subject:
Replace all the struct that contain l3 with l3_main in order
to be consistent with the OMAP4 naming convention.
Replace iva2 by iva for the same reason.
This patch is based on the latest-latest (45 min ago) pm-wip/hwmods
branch from Kevin's tree.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Hi Ohad,
-Original Message-
From: C.A, Subramaniam
Sent: Thursday, June 24, 2010 5:24 PM
To: C.A, Subramaniam; Ohad Ben-Cohen; Kanigeri, Hari; Gupta, Ramesh
Cc: linux-omap@vger.kernel.org; Hiroshi Doyu; Ramirez Luna, Omar
Subject: RE: [PATCH 3/4] omap mailbox: remove
Govindraj.R govindraj.r...@ti.com writes:
Avoid using hwmod lookup using name string rather
retreive port info using the hwmod class interface.
Aviod populating uart_list in early init phase,
leave the uart_list empty and keep the omap hwmod info
in a seperate uart_oh list and if board file
Benoit Cousson b-cous...@ti.com writes:
Replace all the struct that contain l3 with l3_main in order
to be consistent with the OMAP4 naming convention.
Replace iva2 by iva for the same reason.
This patch is based on the latest-latest (45 min ago) pm-wip/hwmods
branch from Kevin's tree.
Thara Gopinath th...@ti.com writes:
This patch series introduces smartreflex and voltage driver support
for OMAP3430 and OMAP3630. SmartReflex modules do adaptive voltage
control for real-time voltage adjustments.
Originally all the functionalities introduced in this patch
were present in
This series introduces runtime PM support at the platform bus level
for OMAP.
In a nutshell, when using the runtime PM API for any device with an
assocated omap_device (and hwmod), the omap device API will be used to
handle the hardware-level power management of that device, including
managing
Implement the new runtime PM framework as a thin layer on top of the
omap_device API. Since we don't have an OMAP-specific bus, override
the runtime PM hooks for the platform_bus for the OMAP specific
implementation.
While the runtime PM API has three main states (idle, suspend, resume)
This
Hook into the platform bus methods for suspend and resume and use the
runtime PM API to allow the OMAP runtime PM core (based on
omap_device) to automatically idle and enable the device on suspend
and resume.
This allows device drivers to get rid of direct management of their
clocks in their
On OMAP1, we do not have omap_device + omap_hwmod to manage the
device-specific idle, enable and shutdown. Instead, just
enable/disable device clocks automatically at the runtime PM level.
This allows drivers to not have any OMAP1 specific clock management
and allows them to simply use the
This is a series of fixes updates mostly to hwmod and omap_device
that are required for the on-going hwmod conversions and runtime PM
conversion of drivers.
While some of these are fixes, they are not urgent for 2.6.35 and can
wait until the next merge window.
This series applies on top of the
On OMAP24xx, the polarity for the IDLEST bits is opposite of OMAP3.
The mask used to check this was using the bit position instead of the
bit mask.
This patch fixes the problem by using the bit mask instead of the bit
field.
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Kevin Hilman
If an omap_hwmod is setup using HWMOD_INIT_NO_IDLE flag, there is
currently way to idle it since omap_hwmod_idle() requires the hwmod to
be in the enabled state.
This patch adds a check to omap_hwmod_idle() so if the hwmod was has
the INIT_NO_IDLE flag, calling omap_hwmod_idle() will still
Since these hwmods do not have IDLEST, set the HWMOD_NO_IDLEST flag,
otherwise _enable() will fail due to failing _wait_target_ready().
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c |9 ++---
From: Benoit Cousson b-cous...@ti.com
As reported by Sergei, a couple of braces were missing after
the WARM removal patch.
[07/22] OMAP: hwmod: Replace WARN by pr_warning if clock lookup failed
https://patchwork.kernel.org/patch/100756/
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Paul
From: Benoit Cousson b-cous...@ti.com
In the lastest OMAP4 hwmod data file, the _hwmod was removed
in order to save some memory space and because it does not
bring a lot.
Align OMAP2420, 2430 and 3430 data files with the same convention.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Paul
Some hwmods may need to be idled/enabled in atomic context, so
non-locking versions of these functions are required.
Most users should not need these and usage of theses should be
controlled to understand why access is being done in atomic context.
For this reason, the non-locking functions are
From: Rajendra Nayak rna...@ti.com
Enable omap_device layer support for OMAP4, so that drivers can
use them to enable/idle/shutdown devices.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Kevin Hilman
The omap_hwmod struct has a field to track the omap_device that is
attached to it, but it was not being assigned. Fix by assigning omap_device
pointer when omap_device is built.
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
Add a new hwmod class for IVA devices. To be used when hwmods
are created for IVA2 on OMAP3.
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/omap_hwmod_common_data.c |3 +++
arch/arm/mach-omap2/omap_hwmod_common_data.h |1
Replace all the struct that contain l3 with l3_main in order
to be consistent with the OMAP4 naming convention.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c |
Add hwmod data for IVA2 module on OMAP3.
Naming of iva instead of iva2 to be aligned with OMAP4 naming done
by Benoit Cousson.
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
Create simple omap_devices for the main processors and busses.
This is required to support the forth-coming device-based OPP
approach, where OPPs are managed and tracked at the device level.
So that these primary devices are available for early PM initialization,
they are created as early
Hi,
We are introducing a kernel driver for hardware spinlock, called hwspinlock.
It is designed to interface with the OMAP4 hardware spinlock module. This
driver supports:
- Reserved spinlocks for internal use
- Dynamic allocation of unreserved locks
- Lock, unlock, and trylock functions, with
Hi,
We are introducing a kernel driver for hardware spinlock, called hwspinlock.
It is designed to interface with the OMAP4 hardware spinlock module. This
driver supports:
- Reserved spinlocks for internal use
- Dynamic allocation of unreserved locks
- Lock, unlock, and trylock functions, with
Que, Simon would like to recall the message, [RFC] omap: .--
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
Ohad,
On Thu, Jun 24, 2010 at 6:02 PM, Kanigeri, Hari h-kanige...@ti.com
wrote:
Looks good.
PCMIIW: from your other mail, I now understand that on OMAP4 you call
omap_mbox_get several times to allow several concurrent mbox senders.
I don't know what PCMIIW stands for :). omap_mbox_get
1 - 100 of 102 matches
Mail list logo
