"G, Manjunath Kondaiah" writes:
> On Wed, Jul 27, 2011 at 02:45:33PM -0700, Hilman, Kevin wrote:
>> Hi Manjunath,
>>
>> On Wed, Jul 27, 2011 at 7:04 AM, G, Manjunath Kondaiah
>> wrote:
>> > Kevin,
>> >
>> > On Thu, Jul 21, 2011 at 04:52:10PM -0700, Kevin Hilman wrote:
>> >> Here's a first whac
On Fri, Jul 29, 2011 at 09:05, Felipe Balbi wrote:
>
>> +}
>> +EXPORT_SYMBOL(omap_hwmod_name_get_odev);
>
> maybe EXPORT_SYMBOL_GPL() ?? Not sure we want non-GPL code to access
> this ;-)
Sure.. but is this the way we want to go? if yes, I can post the
series in a formal way to the list.
Regards
On Thursday, July 28, 2011, jean.pi...@newoldbits.com wrote:
> From: Jean Pihet
>
> Extend the PM QoS kernel API:
> - add a new PM QoS class PM_QOS_DEV_LATENCY for device wake-up latency
> constraints
> - make the pm_qos_add_request API more generic by using a parameter of
> type struct pm_qos_pa
On Thursday, July 28, 2011, jean.pi...@newoldbits.com wrote:
> From: Jean Pihet
>
> The PM QoS implementation files are better named
> kernel/pm_qos.c and include/linux/pm_qos.h.
>
> Signed-off-by: Jean Pihet
> ---
> arch/arm/mach-msm/clock.c |2 +-
> drivers/acpi/processor_id
On Thursday, July 28, 2011, jean.pi...@newoldbits.com wrote:
> From: Jean Pihet
>
> Add the field latency_constraints in the struct dev_pm_info
> and the initialization of the plist in device_pm_init.
>
> This enables the implementation of per-device constraints in
> PM QoS.
>
> Signed-off-by:
On Friday, July 29, 2011, mark gross wrote:
> On Fri, Jul 29, 2011 at 10:37:52AM +0200, Jean Pihet wrote:
> > Mark,
> >
> > On Thu, Jul 28, 2011 at 3:14 PM, mark gross wrote:
> > > On Thu, Jul 28, 2011 at 10:30:07AM +0200, jean.pi...@newoldbits.com wrote:
> > >> From: Jean Pihet
> > >>
> > >> Th
On Thursday, July 28, 2011, jean.pi...@newoldbits.com wrote:
> From: Jean Pihet
>
> This patch set is in an RFC state, for review and comments.
>
> High level implementation:
>
> 1. Add a new PM QoS class for device wake-up constraints (PM_QOS_DEV_LATENCY).
> . Define a pm_qos_constraints struc
On Friday, July 29, 2011, Pavel Machek wrote:
> Hi!
>
> > > > Actually, it just occurred to me that if we're waiting for a system
> > > > timer and can hand that off to a suitable timer in the PMIC then we can
> > > > do a suspend to RAM for the deep idle state from the hardware point of
> > > > v
On Fri, Jul 29, 2011 at 10:47:43AM +0200, Jean Pihet wrote:
> On Fri, Jul 29, 2011 at 9:59 AM, Todd Poynor wrote:
...
> > All min_latency != PM_QOS_DEV_LAT_DEFAULT_VALUE paths need
> > free_new_user = 1.
> free_new_user = 1 is only needed if no existing constraint has been
> found, i.e. user stays
Currently for OMAP4 the I2C_WE is not programmed.
This patch enables the programming for OMAP4.
This patch fixes a bad conflict resolution.
This effectively restores the following commit
Commit 120bdaa47[i2c-omap: Program I2C_WE on OMAP4 to enable i2c wakeup]
which got changed by
Commit a3a7ac
On Fri, Jul 29, 2011 at 7:32 PM, Felipe Balbi wrote:
> Hi,
>
> On Fri, Jul 29, 2011 at 06:28:32PM +0530, Govindraj wrote:
>> On Fri, Jul 29, 2011 at 5:49 PM, Felipe Balbi wrote:
>> > On Fri, Jul 29, 2011 at 05:29:12PM +0530, Govindraj wrote:
>> >> Yes fine, But there are scenarios even before fir
On Fri, Jul 29, 2011 at 10:37:52AM +0200, Jean Pihet wrote:
> Mark,
>
> On Thu, Jul 28, 2011 at 3:14 PM, mark gross wrote:
> > On Thu, Jul 28, 2011 at 10:30:07AM +0200, jean.pi...@newoldbits.com wrote:
> >> From: Jean Pihet
> >>
> >> This patch set is in an RFC state, for review and comments.
>
Hi,
On Fri, Jul 29, 2011 at 07:33:39PM +0530, Datta, Shubhrajyoti wrote:
>On Fri, Jul 29, 2011 at 7:11 PM, Shubhrajyoti <[1]shubhrajy...@ti.com>
>wrote:
>
> On Friday 29 July 2011 06:07 PM, Felipe Balbi wrote:
>
>Hi,
>
>On Fri, Jul 29, 2011 at 01:28:12PM +0100, "And
hi,
On Fri, Jul 29, 2011 at 08:49:34AM -0500, Nishanth Menon wrote:
> From f03490456e24f72ca5272303c95a6f0b212494d5 Mon Sep 17 00:00:00 2001
> From: Nishanth Menon
> Date: Wed, 27 Jul 2011 15:02:32 -0500
> Subject: [PATCH 1/2] OMAP: PM: omap_device: add omap_hwmod_name_get_odev
>
> An API which
Hi,
On Fri, Jul 29, 2011 at 07:11:34PM +0530, Shubhrajyoti wrote:
> On Friday 29 July 2011 06:07 PM, Felipe Balbi wrote:
> >Hi,
> >
> >On Fri, Jul 29, 2011 at 01:28:12PM +0100, "Andy Green (林安廸)" wrote:
> >>On 07/29/2011 01:07 PM, Somebody in the thread at some point said:
> >>
> >>Hi -
> >>
> >>>
Hi,
On Fri, Jul 29, 2011 at 06:28:32PM +0530, Govindraj wrote:
> On Fri, Jul 29, 2011 at 5:49 PM, Felipe Balbi wrote:
> > On Fri, Jul 29, 2011 at 05:29:12PM +0530, Govindraj wrote:
> >> Yes fine, But there are scenarios even before first runtime_suspend
> >> happens,
> >>
> >> ex: uart_port_conf
On 08:31-20110728, Menon, Nishanth wrote:
> On Thu, Jul 28, 2011 at 07:57, Cousson, Benoit wrote:
> [...]
> >> diff --git a/arch/arm/mach-omap2/omap_hwmod.c
> >> b/arch/arm/mach-omap2/omap_hwmod.c
> >> index 293fa6c..77d01a2 100644
> >> --- a/arch/arm/mach-omap2/omap_hwmod.c
> >> +++ b/arch/arm/ma
On Friday 29 July 2011 06:07 PM, Felipe Balbi wrote:
Hi,
On Fri, Jul 29, 2011 at 01:28:12PM +0100, "Andy Green (林安廸)" wrote:
On 07/29/2011 01:07 PM, Somebody in the thread at some point said:
Hi -
- omap_i2c_write_reg(dev, OMAP_I2C_WE_REG, dev->westate);
+
Hi!
> > > Actually, it just occurred to me that if we're waiting for a system
> > > timer and can hand that off to a suitable timer in the PMIC then we can
> > > do a suspend to RAM for the deep idle state from the hardware point of
> > > view.
> >
> > Yep. At LinuxCon Cambridge two years ago, w
On Fri, Jul 29, 2011 at 5:49 PM, Felipe Balbi wrote:
> Hi,
>
> On Fri, Jul 29, 2011 at 05:29:12PM +0530, Govindraj wrote:
>> Yes fine, But there are scenarios even before first runtime_suspend happens,
>>
>> ex: uart_port_configure -> get_sync -> pm_generic_runtime_resume
>> (omap_device_enable in
On 07/29/2011 01:07 PM, Somebody in the thread at some point said:
Hi -
- omap_i2c_write_reg(dev, OMAP_I2C_WE_REG, dev->westate);
+ if (dev->rev< OMAP_I2C_REV_ON_3530_4430)
+ omap_i2c_write_reg(dev, OMAP_I2C_WE_REG,
+
This patch adds the NAND support on OMAP3EVM board and also allocates
five partitions on NAND.
Referred to file: arch/arm/mach-omap2/board-omap3beagle.c
Signed-off-by: Vaibhav Hiremath
Signed-off-by: Sanjeev Premi
Signed-off-by: Hrishikesh Bhandiwad
---
arch/arm/mach-omap2/board-omap3evm.c |
Hi,
On Fri, Jul 29, 2011 at 01:28:12PM +0100, "Andy Green (林安廸)" wrote:
> On 07/29/2011 01:07 PM, Somebody in the thread at some point said:
>
> Hi -
>
> >- omap_i2c_write_reg(dev, OMAP_I2C_WE_REG,
> >dev->westate);
> >+ if (dev->rev< OMAP_I2C_REV_ON
Hi,
On Fri, Jul 29, 2011 at 05:29:12PM +0530, Govindraj wrote:
> Yes fine, But there are scenarios even before first runtime_suspend happens,
>
> ex: uart_port_configure -> get_sync -> pm_generic_runtime_resume
> (omap_device_enable in this case) debug printk -> console_write -> get_sync.
>
> th
Hi,
On Fri, Jul 29, 2011 at 05:18:42PM +0530, Shubhrajyoti D wrote:
> Currently for OMAP4 the I2C_WE is not programmed.
> This patch enables the programming for OMAP4.
>
> Reported-by: Santosh Shilimkar
> Signed-off-by: Shubhrajyoti D
> ---
> TODO:
> Currently all the wakeup sources are enabled
On Fri, Jul 29, 2011 at 5:07 PM, Felipe Balbi wrote:
> Hi,
>
> On Fri, Jul 29, 2011 at 04:54:44PM +0530, Govindraj wrote:
>> On Fri, Jul 29, 2011 at 3:25 PM, Felipe Balbi wrote:
>> > Hi,
>> >
>>
>> Thanks for replying.
>>
>> > On Thu, Jul 28, 2011 at 02:59:55PM +0530, Govindraj.R wrote:
>> >> Pro
Currently for OMAP4 the I2C_WE is not programmed.
This patch enables the programming for OMAP4.
Reported-by: Santosh Shilimkar
Signed-off-by: Shubhrajyoti D
---
TODO:
Currently all the wakeup sources are enabled.
There is scope of optimising the same. Will revisit it.
Rebased on Kevin's wip/i2c
Hi,
On Fri, Jul 29, 2011 at 04:54:44PM +0530, Govindraj wrote:
> On Fri, Jul 29, 2011 at 3:25 PM, Felipe Balbi wrote:
> > Hi,
> >
>
> Thanks for replying.
>
> > On Thu, Jul 28, 2011 at 02:59:55PM +0530, Govindraj.R wrote:
> >> Proposal:
> >>
> >> 1. For the UART, follow the curre
On Thursday 21 July 2011 04:57 PM, Santosh Shilimkar wrote:
Thanks for your review.
On 7/21/2011 4:39 PM, Shubhrajyoti D wrote:
+/*
+ * Enabling all wakup sources to stop I2C freezing on
+ * WFI instruction.
+ * REVISIT: Some wkup sources might not be needed.
+
On Fri, Jul 29, 2011 at 3:25 PM, Felipe Balbi wrote:
> Hi,
>
Thanks for replying.
> On Thu, Jul 28, 2011 at 02:59:55PM +0530, Govindraj.R wrote:
>> Proposal:
>>
>> 1. For the UART, follow the current approach of locking the console in
>> Idle/Suspend path before cutting t
[...]
> To be clear, it seems like resetting irqenable settings should be a
> one-time action at probe time. The power management actions such as
Looking at it again, well we could probably avoid *_mod_init() in request.
I will test and confirm. Thanks.
--
Tarun
[...]
>
> Anyhow, mainly wanted to
[...]
> > > Looking at omap_gpio_mod_init() it seems like much of its processing
> > > could probably be done once at probe time (or at pm_runtime_get_sync
> > > time) as well, namely setting the IRQ enable masks.
> > This must be called at the beginning of bank access to get reset state.
> > Other
The series attempts to do the following
- The reset should not be done in the driver
have support for the same.
- Remove the sysc register access in the driver.
version 2
- Fix the indentation.
- Restore in the error path is not needed as we are
doing a init.
version 3
- Combine the pat
- The reset in the driver at init is not needed anymore as the
hwmod framework takes care of reseting it.
- Reset is removed from omap_i2c_init, which was called
not only during probe, but also after time out and error handling.
device_reset were added in those places to effect the reset
The SYSC register should not accessed in the driver removing the
define from the driver.
Also clean up the syscstate from the omap_i2c_dev struct.
Acked-by: Santosh Shilimkar
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c |5 -
1 files changed, 0 insertions(+), 5 deleti
Under some error conditions the i2c driver may do a reset.
Adding a reset field and support in the platform.
Signed-off-by: Shubhrajyoti D
---
arch/arm/plat-omap/i2c.c | 18 ++
include/linux/i2c-omap.h |1 +
2 files changed, 19 insertions(+), 0 deletions(-)
diff --git a
2011/7/29 Tapani Utriainen :
> On Thu, 28 Jul 2011 16:18:51 +0200
> Arno Steffen wrote:
>
>> That has been good points. I've tried both, but with no result so far.
>>
>
> Try appending earlyprintk=${console} to your bootargs (where ${console}
> is your console string, e.g. ttyO0,115200n8 )
>
> ---
Hi,
On Thu, Jul 28, 2011 at 02:59:55PM +0530, Govindraj.R wrote:
> Proposal:
>
> 1. For the UART, follow the current approach of locking the console in
> Idle/Suspend path before cutting the clock but using
> pm_runtime_putsync.
> That is, continue using the prepa
On Thu, Jul 28, 2011 at 02:48:57PM +0300, Tero Kristo wrote:
> OMAP SMPS regulator driver provides access to OMAP voltage processor
> controlled regulators. These include VDD_MPU and VDD_CORE for OMAP3 and
> additionally VDD_IVA for OMAP4. SMPS regulators use the OMAP voltage
> layer for the actual
Hi,
On Thu, Jul 14, 2011 at 01:34:54PM +0200, Enric Balletbò i Serra wrote:
> Playing with USB ethernet gadget on IGEP boards with mainline kernel
> (Linux 3.0.0-rc7) I observed one strange behavior. The ethernet gadget
> works with one board with OMAP3530 but it doesn't with another one
> with DM
On Fri, Jul 29, 2011 at 10:08 AM, Todd Poynor wrote:
> On Thu, Jul 28, 2011 at 10:30:14AM +0200, jean.pi...@newoldbits.com wrote:
>> From: Jean Pihet
>>
>> The powerdomains next states are initialized in pwrdms_setup as a
>> late_initcall. Because the PM QoS devices constraint can be requested
>>
Todd,
On Fri, Jul 29, 2011 at 9:59 AM, Todd Poynor wrote:
> On Thu, Jul 28, 2011 at 10:30:15AM +0200, jean.pi...@newoldbits.com wrote:
> ...
>> +int pwrdm_set_wkup_lat_constraint(struct powerdomain *pwrdm, void *cookie,
>> + long min_latency)
>> +{
>> + struct pw
Mark,
On Thu, Jul 28, 2011 at 3:14 PM, mark gross wrote:
> On Thu, Jul 28, 2011 at 10:30:07AM +0200, jean.pi...@newoldbits.com wrote:
>> From: Jean Pihet
>>
>> This patch set is in an RFC state, for review and comments.
>>
>> High level implementation:
>>
...
>> 7. Misc fixes to improve code re
On Thu, Jul 28, 2011 at 10:30:14AM +0200, jean.pi...@newoldbits.com wrote:
> From: Jean Pihet
>
> The powerdomains next states are initialized in pwrdms_setup as a
> late_initcall. Because the PM QoS devices constraint can be requested
> early in the boot sequence, the power domains next states c
On Thu, Jul 28, 2011 at 10:30:15AM +0200, jean.pi...@newoldbits.com wrote:
...
> +int pwrdm_set_wkup_lat_constraint(struct powerdomain *pwrdm, void *cookie,
> + long min_latency)
> +{
> + struct pwrdm_wkup_constraints_entry *user = NULL;
> + struct pwrdm_wkup_c
45 matches
Mail list logo
