Currently restore is done always.
Adding conditional restore.The restore is done only if the context is lost.
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c | 29 +
1 files changed, 21 insertions(+), 8 deletions(-)
diff --git a/drivers/i2c/busses/i
The SYSC register should not accessed in the driver removing the
define from the driver.
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index
The reset in the driver at init is not needed
anymore as the hwmod framework takes care of
reseting it.
Signed-off-by: Shubhrajyoti D
---
drivers/i2c/busses/i2c-omap.c | 57 +++--
1 files changed, 15 insertions(+), 42 deletions(-)
diff --git a/drivers/i2c/b
Under some error conditions the i2c driver may do a reset
adding support in the platform.
Signed-off-by: Shubhrajyoti D
---
arch/arm/plat-omap/i2c.c | 18 ++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
ind
Under some conditions the driver may want to do a reset
of the device. Adding a reset field field to the platform
data.
Signed-off-by: Shubhrajyoti D
---
include/linux/i2c-omap.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/linux/i2c-omap.h b/include/linux/i2c
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.
- Restore the context only if the context is lost.
Shubhrajyoti D (5):
OMAP: I2C: Add a device reset field to platform data
OMAP:
My mailer seems to have goofed the from email-id. Pls ignore this email. I
have sent another patch correcting the same.
Vishwa
> -Original Message-
> From: y...@dbdp31.itg.ti.com [mailto:y...@dbdp31.itg.ti.com]
> Sent: Thursday, July 21, 2011 10:23 AM
> To: linux-omap@vger.kernel.org
> Cc:
From: Sripathy, Vishwanath
Add OMAP4460 OPP definitions for voltage and frequencies based on
OMAP4460 ES1.0 DM Operating Condition Addendum Version 0.1
The following exceptions are present:
* Smartreflex support is still on experimental mode: the gains and min
limits are currently pending char
Vishwa,
Vishwanath Sripathy writes:
[...]
>> A quick glance now suggests it has a few minor problems.
>>
>> - patch was not Cc's to linux-arm-kernel
>> - uses 44XX naming which is not used in l-o master
> Sorry I did not get this point. What do you mean by 44XX naming?
> I applied this patch ag
On Wed, Jul 20, 2011 at 4:33 PM, Shawn Guo wrote:
> On Wed, Jul 20, 2011 at 12:55:13PM -0600, Grant Likely wrote:
>> On Wed, Jul 20, 2011 at 07:04:20PM +0800, Shawn Guo wrote:
>> > > Mostly consistency. Most of the experience we have with the flattened
>> > > device tree up to this point hasn't b
On Wed, Jul 20, 2011 at 12:55:13PM -0600, Grant Likely wrote:
> On Wed, Jul 20, 2011 at 07:04:20PM +0800, Shawn Guo wrote:
> > > Mostly consistency. Most of the experience we have with the flattened
> > > device tree up to this point hasn't bothered with the 'status'
> > > property. It is only wh
On Wed, Jul 20, 2011 at 07:04:20PM +0800, Shawn Guo wrote:
> > Mostly consistency. Most of the experience we have with the flattened
> > device tree up to this point hasn't bothered with the 'status'
> > property. It is only when AMP and hypervisors cam online that it
> > became important to use
Kevin,
> -Original Message-
> From: Kevin Hilman [mailto:khil...@ti.com]
> Sent: Tuesday, July 19, 2011 8:47 PM
> To: Vishwanath Sripathy
> Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Nishanth Menon
> Subject: Re: [PATCHV2] OMAP4: OPP: add OMAP4460 definitions
>
> Vishwanath Sripathy
On Tue, Jul 19, 2011 at 10:53 PM, Jassi Brar wrote:
>
> On Wed, Jul 20, 2011 at 11:15 AM, Pandita, Vikram
> wrote:
> > On Tue, Jul 19, 2011 at 10:34 PM, Jassi Brar
> > wrote:
> >>
> >> On Wed, Jul 20, 2011 at 10:41 AM, Vikram Pandita
> >> wrote:
> >> > From: Anand Gadiyar
> >> >
> >> > This
Laurent Pinchart wrote:
> Hi everybody,
>
> Here are the OMAP3 ISP patches in my queue for v3.1. I'll send a pull request
> in a couple of days if there's no objection.
>
> Kalle Jokiniemi (2):
> OMAP3: ISP: Add regulator control for omap34xx
> OMAP3: RX-51: define vdds_csib regulator supply
On Wed, Jul 20, 2011 at 11:26:13AM +0200, Jean Pihet wrote:
> Hi Rafael,
>
> 2011/7/2 Rafael J. Wysocki :
> > Hi,
> >
> > On Thursday, June 30, 2011, jean.pi...@newoldbits.com wrote:
> >> From: Jean Pihet
> >>
> >> This patch set is in an RFC state, for review and comments.
> >
> > First off, I'm
On Wed, Jul 06, 2011 at 06:12:49PM -0600, Grant Likely wrote:
> On Wed, Jul 6, 2011 at 5:26 PM, Stephen Warren wrote:
> > Grant Likely wrote at Wednesday, July 06, 2011 12:56 PM:
> >> On Thu, Jun 30, 2011 at 03:07:23PM +0500, G, Manjunath Kondaiah wrote:
> >> > Add I2C and it's child device nodes
[...]
> >
> > + /*
> > +* If this is the first gpio_request for the bank,
> > +* enable the bank module.
> > +*/
> > + if (!bank->mod_usage) {
> > + if (IS_ERR_VALUE(pm_runtime_get_sync(bank->dev) < 0)) {
> > + dev_err(bank->dev, "%s: GPIO bank %d "
> > +
[...]
> Let's say GPIO 1 and 2 belong to the same GPIO module.
> Driver A uses GPIO 1 and driver B uses GPIO 2.
> A is just blinking an LED every second whereas B uses GPIO 2 as input.
>
> both drivers will keep the GPIOs requested as long as they are loaded.
> Why can't you turn off the clocks wh
On 07/20/2011 12:28 PM, DebBarma, Tarun Kanti wrote:
[...]
From this patch it seems that the GPIO module is kept active as long as
one of its GPIOs is requested. This is not optimal.
Yes, but...
The GPIO needs to be active only when accessing its registers e.g.
during gpio_get or gpio_set
[...]
> From this patch it seems that the GPIO module is kept active as long as
> one of its GPIOs is requested. This is not optimal.
Yes, but...
>
> The GPIO needs to be active only when accessing its registers e.g.
> during gpio_get or gpio_set. The rest of the time it can be suspended.
A GPIO
Hi Rafael,
2011/7/2 Rafael J. Wysocki :
> Hi,
>
> On Thursday, June 30, 2011, jean.pi...@newoldbits.com wrote:
>> From: Jean Pihet
>>
>> This patch set is in an RFC state, for review and comments.
>
> First off, I'm sorry I couldn't review the patchset earlier.
Thank you very much for reviewing t
Hi Rafael,
2011/7/2 Rafael J. Wysocki :
> Hi,
>
> On Thursday, June 30, 2011, jean.pi...@newoldbits.com wrote:
>> From: Jean Pihet
>>
>> The devices wake-up latency constraints class of PM QoS is
>> storing the constraints list using the device pm_info struct.
>>
>> This patch adds the init and d
Hi Rafael, Mark,
- Looping in Mark for the user space API
2011/7/2 Rafael J. Wysocki :
> Hi,
>
> On Thursday, June 30, 2011, jean.pi...@newoldbits.com wrote:
>> From: Jean Pihet
>>
>> - add a new PM QoS class PM_QOS_DEV_WAKEUP_LATENCY for device wake-up
>> constraints. Due to the per-device natu
Hi Rafael,
2011/7/2 Rafael J. Wysocki :
> Hi,
>
> On Thursday, June 30, 2011, jean.pi...@newoldbits.com wrote:
...
>> @@ -462,6 +463,7 @@ struct dev_pm_info {
>> unsigned long accounting_timestamp;
>> void *subsys_data; /* Owned by the subsystem. */
>> #
use MTD_NAND_OMAP2 also for OMAP4 arch.
testes wit omap4430
Signed-off-by: Jan Weitzel
---
v2: add menuconfig description
drivers/mtd/nand/Kconfig |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 4c34252..2a
[...]
> > static int __init omap16xx_gpio_init(void)
> > {
> > int i;
> > + void __iomem *base;
> > + struct resource *res;
> > + struct platform_device *pdev;
> > + struct omap_gpio_platform_data *pdata;
> >
> > if (!cpu_is_omap16xx())
> > return -EINVAL;
> >
> > -
27 matches
Mail list logo
