problem. One minor nit on a
comment below, otherwise:
Acked-by: Kevin Hilman khil...@linaro.org
+/**
+ * dev_pm_domain_sync - synchronise the PM domain state with its devices
+ * @dev: device corresponding with domain
+ *
+ * Synchronise the PM domain state with the recently probed device, which
Alexander Kochetkov al.koc...@gmail.com writes:
The first patch fix i2c-omap driver for omap2420, found by code review and
later reported by Tony Lindgren t...@atomide.com here[1].
Candidate for stable?
The second patch unhide the reson of system lockup.
The patch is rebased on branch
is rebased on branch 'i2c/for-next' of
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux
(6e79807443cba7397cd855ed29d6faba51d4c893)
Signed-off-by: Alexander Kochetkov al.koc...@gmail.com
Reported-by: Kevin Hilman khil...@kernel.org
Tested-by: Kevin Hilman khil...@kernel.org
Built
Alexander Kochetkov al.koc...@gmail.com writes:
25 нояб. 2014 г., в 22:13, Kevin Hilman khil...@kernel.org написал(а):
I'll test your patch on all my OMAP boards. Put whatever debug output
you want, and I'll send you links to all the boot output.
Hello, Kevin!
I've sent the patch[1
).
Signed-off-by: Alexander Kochetkov al.koc...@gmail.com
Fixes: 903c3859f77f9b0aace551da03267ef7a211dbc4
Reported-by: Kevin Hilman khil...@kernel.org
Tested-by: Tony Lindgren t...@atomide.com
Tested-by: Kevin Hilman khil...@linaro.org
I tested DT and legacy boot on 3430/n900, 3530/beagle
Alexander Kochetkov al.koc...@gmail.com writes:
25 нояб. 2014 г., в 17:19, Wolfram Sang w...@the-dreams.de написал(а):
I'll push out this evening to make the boot tests work again. If there
is more to be investigated, either hurry up and post v3 ;) or let me
know that you need more time.
On Sat, Nov 22, 2014 at 11:47 AM, Alexander Kochetkov
al.koc...@gmail.com wrote:
In a multimaster environment, after IP software reset, BB-bit value doesn't
correspond to the current bus state. It may happen what BB-bit will be 0,
while the bus is busy due to another I2C master activity.
Any
Ezequiel Garcia ezequ...@vanguardiasur.com.ar writes:
On 10/20/2014 06:07 PM, Kevin Hilman wrote:
Ezequiel Garcia ezequ...@vanguardiasur.com.ar writes:
The _noirq were previously chosen to make sure all the users of the
adapter were suspended by the time the adapter itself enters
Wenyou Yang wenyou.y...@atmel.com writes:
Add a changelog here describing what you're doing, and why.
Signed-off-by: Wenyou Yang wenyou.y...@atmel.com
---
drivers/i2c/busses/i2c-at91.c | 30 ++
1 file changed, 30 insertions(+)
diff --git
Wenyou Yang wenyou.y...@atmel.com writes:
Amend the i2c at91 pin controller to optionally take a pin control
handle and set the state of the pins to:
- default on boot, resume and before performing an transfer
- sleep on suspend()
This should make it possible to optimize energy usage for
Doug Anderson diand...@chromium.org writes:
[...]
On Fri, Jun 20, 2014 at 4:59 PM, Tomasz Figa tomasz.f...@gmail.com wrote:
I'm not sure noirq is going to work correctly, at least not with current
callbacks. I can see a call to clk_prepare_enable() there which needs to
acquire a mutex.
Doug Anderson diand...@chromium.org writes:
Kevin,
On Fri, Jun 20, 2014 at 4:13 PM, Kevin Hilman khil...@linaro.org wrote:
Doug Anderson diand...@chromium.org writes:
Kevin,
On Fri, Jun 20, 2014 at 2:48 PM, Kevin Hilman khil...@linaro.org wrote:
Hi Doug,
Doug Anderson diand
Doug Anderson diand...@chromium.org writes:
Kevin,
On Mon, Jun 23, 2014 at 3:23 PM, Kevin Hilman khil...@linaro.org wrote:
So I guess in this case the truly correct way to handle it is:
1. i2c controller should have Runtime PM even though (as per the code
now) there's nothing you can do
Tomasz Figa tomasz.f...@gmail.com writes:
On 24.06.2014 00:27, Doug Anderson wrote:
Kevin,
On Mon, Jun 23, 2014 at 3:19 PM, Kevin Hilman khil...@linaro.org wrote:
Doug Anderson diand...@chromium.org writes:
[...]
On Fri, Jun 20, 2014 at 4:59 PM, Tomasz Figa tomasz.f...@gmail.com wrote
Hi Doug,
Doug Anderson diand...@chromium.org writes:
On Thu, Jun 19, 2014 at 11:43 AM, Kevin Hilman khil...@linaro.org wrote:
Doug Anderson diand...@chromium.org writes:
The original code for the exynos i2c controller registered for the
noirq variants. However during review feedback
Doug Anderson diand...@chromium.org writes:
Kevin,
On Fri, Jun 20, 2014 at 2:48 PM, Kevin Hilman khil...@linaro.org wrote:
Hi Doug,
Doug Anderson diand...@chromium.org writes:
On Thu, Jun 19, 2014 at 11:43 AM, Kevin Hilman khil...@linaro.org wrote:
Doug Anderson diand...@chromium.org
Doug Anderson diand...@chromium.org writes:
The original code for the exynos i2c controller registered for the
noirq variants. However during review feedback it was moved to
SIMPLE_DEV_PM_OPS without anyone noticing that it meant we were no
longer actually noirq (despite functions named
, that would be great.
I applied this patch on top of next-20140207 and tested this on the
armada-xp openblocks ax3, which is where I was seeing the I2C timeouts.
I confirm it fixes the timeouts I was seeing.
Tested-by: Kevin Hilman khil...@linaro.org
Kevin
--
To unsubscribe from this list: send
Linus Walleij linus.wall...@linaro.org writes:
On Tue, Feb 4, 2014 at 8:22 PM, Kevin Hilman khil...@linaro.org wrote:
Ulf Hansson ulf.hans...@linaro.org writes:
Due to the available runtime PM callbacks, we are now able to put our
device into low power state at system suspend.
(...)
I'm
Ulf Hansson ulf.hans...@linaro.org writes:
Due to the available runtime PM callbacks, we are now able to put our
device into low power state at system suspend.
Earlier we could not accomplish this without trusting a power domain
for the device to take care of it. Now we are able to cope with
Mika Westerberg mika.westerb...@linux.intel.com writes:
On Thu, Sep 12, 2013 at 02:34:21PM -0700, Kevin Hilman wrote:
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index f32ca29..44374b4 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -248,11 +248,30
Mika Westerberg mika.westerb...@linux.intel.com writes:
On Fri, Sep 13, 2013 at 05:50:22PM +0300, Mika Westerberg wrote:
On Fri, Sep 13, 2013 at 07:30:55AM -0700, Kevin Hilman wrote:
Mika Westerberg mika.westerb...@linux.intel.com writes:
On Thu, Sep 12, 2013 at 02:34:21PM -0700, Kevin
Aaron Lu aaron...@intel.com writes:
On 09/11/2013 06:32 AM, Rafael J. Wysocki wrote:
On Tuesday, September 10, 2013 10:35:22 PM Mark Brown wrote:
On Tue, Sep 10, 2013 at 10:04:21PM +0200, Rafael J. Wysocki wrote:
On Tuesday, September 10, 2013 05:13:21 PM Mark Brown wrote:
OK, that is very
Mika Westerberg mika.westerb...@linux.intel.com writes:
From: Aaron Lu aaron...@intel.com
This patch adds runtime PM support for the I2C bus in a similar way that
has been done for PCI bus already. This means that the I2C bus core
prepares runtime PM for a client device just before a driver
On Thu, Sep 12, 2013 at 2:34 PM, Kevin Hilman khil...@linaro.org wrote:
Mika Westerberg mika.westerb...@linux.intel.com writes:
From: Aaron Lu aaron...@intel.com
This patch adds runtime PM support for the I2C bus in a similar way that
has been done for PCI bus already. This means
-by: Kevin Hilman khil...@linaro.org
---
Discovered in new build failure of iop32xx_defconfig with next-20130628
drivers/i2c/busses/i2c-iop3xx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-iop3xx.c b/drivers/i2c/busses/i2c-iop3xx.c
index bc99333..dd24aa0
Felipe Balbi ba...@ti.com writes:
[...]
If you have 200 pm_runtime_get() followed by 200 pm_runtime_put() (put
is called only after 200 gets, no put-get ping-pong), your
-runtime_resume() gets called once, your -runtime_suspend() gets
called once but your -runtime_idle() will get called 200
Grygorii Strashko grygorii.stras...@ti.com writes:
From: Kevin Hilman khil...@deeprootsystems.com
Currently, runtime PM is used to keep the device enabled only during
active transfers and for a configurable runtime PM autosuspend timout
after an xfer.
In addition to idling the device
Grygorii Strashko grygorii.stras...@ti.com writes:
Hi Kevin,
On 06/03/2013 11:59 PM, Kevin Hilman wrote:
Grygorii Strashko grygorii.stras...@ti.com writes:
The OMAP I2C driver has a relation to pinctrl-single driver. As result,
its probe will be deferred during system boot until late init
Wolfram Sang w...@the-dreams.de writes:
devm_ioremap_resource does sanity checks on the given resource. No need to
duplicate this in the driver.
Signed-off-by: Wolfram Sang w...@the-dreams.de
Acked-by: Kevin Hilman khil...@linaro.org # for i2c-omap.c
--
To unsubscribe from this list: send
Grygorii Strashko grygorii.stras...@ti.com writes:
The OMAP I2C driver has a relation to pinctrl-single driver. As result,
its probe will be deferred during system boot until late init time,
because the pinctrl-single is initizalized as moudle/device init time.
This, in turn, will delay
Oleksandr Dmytryshyn oleksandr.dmytrys...@ti.com writes:
On 05/30/2013 07:46 PM, Kevin Hilman wrote:
Oleksandr Dmytryshyn oleksandr.dmytrys...@ti.com writes:
If the i2c controller during suspend will generate an interrupt, it
can lead to unpredictable behaviour in the kernel.
Based
Hebbar Gururaja gururaja.heb...@ti.com writes:
Amend the I2C omap pin controller to optionally take a pin control
handle and set the state of the pins to:
- default on boot, resume and before performing an i2c transfer
- idle after initial default, after resume default, and after each
i2c
Oleksandr Dmytryshyn oleksandr.dmytrys...@ti.com writes:
I've just removed unnecessary Change-Id line.
If the i2c controller during suspend will generate an interrupt, it
can lead to unpredictable behaviour in the kernel.
Based on the logic of the kernel code interrupts from i2c should be
Oleksandr Dmytryshyn oleksandr.dmytrys...@ti.com writes:
On 05/29/2013 08:22 PM, Kevin Hilman wrote:
Oleksandr Dmytryshyn oleksandr.dmytrys...@ti.com writes:
Starting from the OMAP chips with version2 registers scheme there are
2 registers (I2C_IRQENABLE_SET and I2C_IRQENABLE_CLR) to manage
Oleksandr Dmytryshyn oleksandr.dmytrys...@ti.com writes:
If the i2c controller during suspend will generate an interrupt, it
can lead to unpredictable behaviour in the kernel.
Based on the logic of the kernel code interrupts from i2c should be
prohibited during suspend. Kernel writes 0 to
Oleksandr Dmytryshyn oleksandr.dmytrys...@ti.com writes:
Starting from the OMAP chips with version2 registers scheme there are
2 registers (I2C_IRQENABLE_SET and I2C_IRQENABLE_CLR) to manage
interrupts instead of the older OMAP chips with old scheme which have
only one register (I2C_IE). Now
+Paul
Felipe Balbi ba...@ti.com writes:
if we allow compiler reorder our writes, we could
fall into a situation where dev-buf_len is reset
for no apparent reason.
Any chance this would help with the bug Paul found with I2C timeouts on
beagle userspace startup?
Kevin
This bug was found
Peter Zijlstra pet...@infradead.org writes:
On Thu, 2012-10-18 at 08:51 +0300, Felipe Balbi wrote:
So the primary question remains: is RT runtime supposed to include the
time spent suspended? I suspect not.
you might be right there, though we need Thomas or Peter to answer :-s
re,
Felipe Balbi ba...@ti.com writes:
On Wed, Oct 17, 2012 at 05:00:02PM +0300, Felipe Balbi wrote:
On Tue, Oct 16, 2012 at 02:39:50PM -0700, Kevin Hilman wrote:
+ peterz, tglx
Felipe Balbi ba...@ti.com writes:
[...]
The problem I see is that even though we properly return
interrupt, and
SIHs have not been enabled yet, a flood of interrupts hangs
the device.
Fixed the issue by setting the SIH irqs with IRQF_EARLY_RESUME
flags, so they get enabled before the PIH.
Signed-off-by: Kalle Jokiniemi kalle.jokini...@jollamobile.com
Acked-by: Kevin Hilman khil...@ti.com
Kalle Jokiniemi kalle.jokini...@jollamobile.com writes:
Hi,
la, 2012-10-13 kello 01:00 +0530, Shubhrajyoti Datta kirjoitti:
On Sat, Oct 13, 2012 at 12:10 AM, Kevin Hilman
khil...@deeprootsystems.com wrote:
From: Kevin Hilman khil...@ti.com
Currently, runtime PM is used to keep
Strashko, Grygorii grygorii.stras...@ti.com writes:
Hi All,
Sorry, for the late reply.
+ CC Huzefa Kankroliwala - who is I2C driver owner on Android Kernel 3.4.
Hi Grygorii, thanks for reviewing. I was hoping you would have some
ideas here as this was sounding familiar to something you had
+Kalle, Grygorii, Huzefa
Shubhrajyoti D shubhrajy...@ti.com writes:
Enable the irq in the transfer and disable it after the
transfer is done.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
+Kalle, Grygorii, Huzefa
Shubhrajyoti D shubhrajy...@ti.com writes:
Enable the irq in the transfer and disable it after the
transfer is done.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
,
omap_i2c_runtime_resume, NULL)
};
- Grygorii
From: Kevin Hilman [khil...@deeprootsystems.com]
Sent: Friday, October 12, 2012 5:34 PM
To: Strashko, Grygorii
Cc: Kalle Jokiniemi; linux-i2c@vger.kernel.org; w.s...@pengutronix.de;
ben-li...@fluff.org; t
From: Kevin Hilman khil...@ti.com
Currently, runtime PM is used to keep the device enabled only during
active transfers and for a configurable runtime PM autosuspend timout
after an xfer.
In addition to idling the device, driver's -runtime_suspend() method
currently disables device interrupts
Shubhrajyoti Datta omaplinuxker...@gmail.com writes:
On Fri, Oct 12, 2012 at 10:13 PM, Kevin Hilman
khil...@deeprootsystems.com wrote:
Strashko, Grygorii grygorii.stras...@ti.com writes:
Hi Kevin,
yep, [1] is the same fix - thanks.
Hi Kalle,
i've applied these changes and PM runtime
on N9. Patch tested on N9.
Signed-off-by: Kalle Jokiniemi kalle.jokini...@jollamobile.com
This version looks good, thanks for the extra comments.
Reviewed-by: Kevin Hilman khil...@ti.com
Tested-by: Kevin Hilman khil...@ti.com
Wolfram, This should also probably be Cc'd to stable since
+Grygorii (who's been working on various I2C related suspend/resume
issues also)
Hi Kalle,
Kalle Jokiniemi kalle.jokini...@jollamobile.com writes:
The resume_noirq enables interrupts one-by-one starting from
first one. Now if the wake up event for suspend came from i2c
device, the
to
decide the next power state of the MPU subsystem.
The I2C device latency timing is derived from the FIFO size and the
clock speed and so is applicable to all OMAP SoCs.
Signed-off-by: Jean Pihet j-pi...@ti.com
Acked-by: Kevin Hilman khil...@ti.com
--
To unsubscribe from this list: send the line
Kevin Hilman khil...@deeprootsystems.com writes:
Kevin Hilman khil...@deeprootsystems.com writes:
[...]
Sorry to be late to the party (again), but still catching up after some
time off.
Unfortunately, this series causes PM regressions on several OMAP
platforms. I hope we can hold off
Felipe Balbi ba...@ti.com writes:
Hi,
On Thu, Sep 13, 2012 at 11:04:42AM -0700, Kevin Hilman wrote:
Kevin Hilman khil...@deeprootsystems.com writes:
Kevin Hilman khil...@deeprootsystems.com writes:
[...]
Sorry to be late to the party (again), but still catching up after some
time
Shubhrajyoti D shubhrajy...@ti.com writes:
[...]
This is the cleanup only series.
Tested on omap4sdp and 3430sdp.
It would be extremely helpful if you would describe how this was tested.
And for me, it would be a source of extreme joy if you described any PM
testing.
I gave this some
Wolfram Sang w.s...@pengutronix.de writes:
On Wed, Sep 12, 2012 at 04:27:54PM +0530, Shubhrajyoti D wrote:
[...]
This is the cleanup only series.
Tested on omap4sdp and 3430sdp.
The following changes since commit 55d512e245bc7699a8800e23df1a24195dd08217:
Linux 3.6-rc5 (2012-09-08
Shubhrajyoti D shubhrajy...@ti.com writes:
From: Felipe Balbi ba...@ti.com
this helps us reduce unnecessary pm transitions
in case we have another i2c message starting soon.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
I tracked the PM
Kevin Hilman khil...@deeprootsystems.com writes:
Wolfram Sang w.s...@pengutronix.de writes:
On Wed, Sep 12, 2012 at 04:27:54PM +0530, Shubhrajyoti D wrote:
[...]
This is the cleanup only series.
Tested on omap4sdp and 3430sdp.
The following changes since commit
Hi Wolfram,
Kevin Hilman khil...@ti.com writes:
In omap_i2c_xfer(), ensure pm_runtime_put() is called, even on
failure.
Without this, after a failed xfer, the runtime PM usecount will have
been incremented, but not decremented causing the usecount to never
reach zero after a failure
.
As this changes the error/failure path, please be specific about how
the failure modes were tested, and on which platforms.
Cc: Kevin Hilman khil...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |7 +++
1 files changed, 3 insertions(+), 4 deletions
Shubhrajyoti shubhrajy...@ti.com writes:
On Friday 29 June 2012 05:32 PM, Kevin Hilman wrote:
Shubhrajyoti D shubhrajy...@ti.com writes:
ensure pm_runtime_put() is called, on pm_runtime_get_sync()
failure.
Without this, after a failed call, the runtime PM usecount will have
Hi Shubhrajyoti,
Shubhrajyoti Datta omaplinuxker...@gmail.com writes:
Hi Kevin,
Thanks for the patch ,
a doubt below
Thanks for the review.
On Wed, Jun 27, 2012 at 7:15 AM, Kevin Hilman khil...@ti.com wrote:
In omap_i2c_xfer(), ensure pm_runtime_put() is called, even on
failure.
So
Shubhrajyoti D shubhrajy...@ti.com writes:
If PM runtime get_sync fails return with the error
so that no further reads/writes goes through the interface.
This will avoid possible abort. Add a error message in case
of failure with the cause of the failure.
Reviewed-by: Kevin Hilman khil
the enclosing power domain active, and prevents
full-chip retention/off from happening during idle.
Cc: Shubhrajyoti D shubhrajy...@ti.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
This patch applies to current i2c-embedded/for-next branch
drivers/i2c/busses/i2c-omap.c |2 +-
1 file
-by: Kevin Hilman khil...@ti.com
That being said, before this is merged, I woudl like to see some more
non-author Tested-bys. We've been having lots of regressions of late
from OMAP drivers that are not being sufficiently tested before
merging. We need to ensure proper testing before merge.
Other
.
So don't disable interrupts for I2C.
Acked-by: Kevin Hilman khil...@ti.com
Tested-by: Kevin Hilman khil...@ti.com
Signed-off-by: NeilBrown ne...@suse.de
---
drivers/i2c/busses/i2c-omap.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b
Datta, Shubhrajyoti shubhrajy...@ti.com writes:
Hi Kevin,
Hi Kevin,
Thanks for your review,
On Tue, Apr 17, 2012 at 7:15 PM, Kevin Hilman khil...@ti.com wrote:
Shubhrajyoti D shubhrajy...@ti.com writes:
Currently i2c register restore is done always.
Adding conditional restore
Shubhrajyoti D shubhrajy...@ti.com writes:
Currently i2c register restore is done always.
Adding conditional restore.
The i2c register restore is done only if the context is lost.
OK, minor comment below.
Also remove the definition of SYSS_RESETDONE_MASK and use the
one in
Shubhrajyoti shubhrajy...@ti.com writes:
On Thursday 12 January 2012 03:46 AM, Kevin Hilman wrote:
Shubhrajyoti D shubhrajy...@ti.com writes:
The functions omap_i2c_unidle/idle are called from omap_i2c_runtime_resume
and omap_i2c_runtime_suspend which is compiled for CONFIG_PM_RUNTIME.
Make
Shubhrajyoti D shubhrajy...@ti.com writes:
The functions omap_i2c_unidle/idle are called from omap_i2c_runtime_resume
and omap_i2c_runtime_suspend which is compiled for CONFIG_PM_RUNTIME.
Make the omap_i2c_unidle/idle also depend on CONFIG_PM_RUNTIME flag.
I probably should've done this when
registers to there original state as some OMAP generations do not
implement perform a soft-reset.
4. Clear the CON register after performing the bus clear, so when we call the
init function the controller is disabled and the init function will
re-enable later.
Cc: Kevin Hilman khil
Datta, Shubhrajyoti shubhrajy...@ti.com writes:
On Tue, Jan 10, 2012 at 11:53 AM, Datta, Shubhrajyoti
shubhrajy...@ti.com wrote:
On Fri, Dec 16, 2011 at 2:29 PM, Shubhrajyoti shubhrajy...@ti.com wrote:
Ben,
On Friday 16 December 2011 02:10 PM, Paul Walmsley wrote:
Hi
On Tue, 13
NeilBrown ne...@suse.de writes:
On Wed, 04 Jan 2012 14:19:48 -0800 Kevin Hilman khil...@ti.com wrote:
+Felipe
NeilBrown ne...@suse.de writes:
On a board with OMAP3 processor and TWL4030 Power management,
we need to talk to the TWL4030 during late suspend but cannot
because the I2C
Hi Ben,
Here's a few OMAP I2C updates for the v3.3 merge window.
Thanks,
Kevin
The following changes since commit 3f6b2a8bd6e4ff43269d89066a9fe06a0e5ba961:
I2C: OMAP: correct SYSC register offset for OMAP4 (2011-12-13 11:35:56 -0800)
are available in the git repository at:
+Felipe
NeilBrown ne...@suse.de writes:
On a board with OMAP3 processor and TWL4030 Power management,
we need to talk to the TWL4030 during late suspend but cannot
because the I2C interrupt is disabled (as late suspend disables
interrupt).
I'm not convinced this is the right solution to
Jean,
Could you pull the following I2C fixes for the OMAP platform for v3.2?
The first one belongs in stable (change log already Cc's sta...@vger.kernel.org)
Since this is an embedded platform, I have asked Ben Dooks a few times
but gotten no response, so am hoping you can queue these before
Shubhrajyoti shubhrajy...@ti.com writes:
On Friday 09 December 2011 01:01 AM, Jon Hunter wrote:
Hi Kevin,
On 12/8/2011 12:12, Kevin Hilman wrote:
Alexander Aringa.ar...@phytec.de writes:
Correct OMAP_I2C_SYSC_REG offset in omap4 register map.
Offset 0x20 is reserved and OMAP_I2C_SYSC_REG
Ben,
[...]
Shubhrajyoti/Jon, any objections to me queuing this fix for v3.2 (and
stable.) It would just mean rebasing your other fixes and cleanup
series on top of this.
I have no issue with that and I am in favour of getting the fix in now.
I too have no issues.
I've queued this fix in
Alexander Aring a.ar...@phytec.de writes:
Correct OMAP_I2C_SYSC_REG offset in omap4 register map.
Offset 0x20 is reserved and OMAP_I2C_SYSC_REG has 0x10 as offset.
Signed-off-by: Alexander Aring a.ar...@phytec.de
Thanks for the patch!
A different approach to fix this is being done by
-by: Shubhrajyoti D shubhrajy...@ti.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
Ben, can you queue this fix for v3.2-rc?
Patch applies to v3.2-rc4.
drivers/i2c/busses/i2c-omap.c | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c
Shubhrajyoti D shubhrajy...@ti.com writes:
On OMAP4 we were writing 1 to IRQENABLE_CLR which cleared only
the arbitration lost interrupt however for other ips (not
OMAP_I2C_IP_VERSION_2)
we clear all the interrupts at idle. The patch intends to fix the same by
writing 0 to the
IE
Shubhrajyoti D shubhrajy...@ti.com writes:
For OMAP4 Interrupt enable register is a legacy register.
I don't see anything in the docs mentioning this is legacy. In fact,
that register is used extensivly throughout the driver, even for OMAP4.
I think the CLR/SET registers were added to aid
Shubhrajyoti D shubhrajy...@ti.com writes:
The register IRQENABLE_CLR is a bit map of interrupt events.
All the bits have to be cleared to clear the interrupts.
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
Shubhrajyoti shubhrajy...@ti.com writes:
On Tuesday 08 November 2011 03:01 AM, David Anders wrote:
omap44xx i2c devices need to have the registers reset post idle
similar to omap3xxx devices. this adds the additional flag for
OMAP_I2C_FLAG_RESET_REGS_POSTIDLE to the omap44xx i2c_dev_attr.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
Acked-by: Kevin Hilman khil...@ti.com
Ben, please queue as a fix for the v3.2-rc. It applies cleanly to
v3.2-rc1.
If you prefer a branch:
https://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git
for_3.2/fixes/i2c
Thanks,
Kevin
Adding linux-omap and linux-davinci lists
Jean Delvare kh...@linux-fr.org writes:
Both bus drivers i2c-omap and i2c-davinci apparently handle 10-bit addresses:
(i2c-omap.c)
if (msg-flags I2C_M_TEN)
w |= OMAP_I2C_CON_XA;
(i2c-davinci.c)
/* if the slave address
Shubhrajyoti shubhrajy...@ti.com writes:
On Thursday 14 July 2011 12:50 AM, Ben Dooks wrote:
On Tue, Jul 05, 2011 at 05:01:01PM -0700, Kevin Hilman wrote:
Shubhrajyoti D shubhrajy...@ti.com writes:
Currently the fifo depth is set to zero for OMAP4 which disables
the FIFO usage. This patch
Ben Dooks ben-...@fluff.org writes:
On Mon, Sep 26, 2011 at 03:30:50PM -0700, Kevin Hilman wrote:
ping
On 09/06/2011 03:31 PM, Kevin Hilman wrote:
Hi Ben,
On 08/23/2011 05:10 PM, Kevin Hilman wrote:
Ben,
Here's one more I2C cleanup series for v3.2.
It applies on top of my for_3.2
ping
On 09/06/2011 03:31 PM, Kevin Hilman wrote:
Hi Ben,
On 08/23/2011 05:10 PM, Kevin Hilman wrote:
Ben,
Here's one more I2C cleanup series for v3.2.
It applies on top of my for_3.2/i2c-fixes branch just submitted.
Please pull into your tree for linux-next.
I see you pulled the other
Hi Ben,
On 08/23/2011 05:10 PM, Kevin Hilman wrote:
Ben,
Here's one more I2C cleanup series for v3.2.
It applies on top of my for_3.2/i2c-fixes branch just submitted.
Please pull into your tree for linux-next.
I see you pulled the other two, can you pull this one as well?
Since
Shubhrajyoti D shubhrajy...@ti.com writes:
Under some error conditions the i2c driver may do a reset.
Adding a reset field and support in the device-specific code.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
Needs update/rebase to apply against my for_3.2/i2c-cleanup branch...
[...]
Shubhrajyoti shubhrajy...@ti.com writes:
On Sunday 17 July 2011 06:13 PM, Shubhrajyoti D wrote:
Restore of context is not done for OMAP4. This patch
adds the OMAP_I2C_FLAG_RESET_REGS_POSTIDLE in the OMAP4
hwmod data which activates the restore for OMAP4.
Currently the OMAP4 does not hit
Ben Dooks ben-...@fluff.org writes:
On Tue, Aug 23, 2011 at 05:07:56PM -0700, Kevin Hilman wrote:
Hi Ben,
Initially, these fixes were planned to be queued for v3.1-rc, but since
the previous series from Andy didn't make it into v3.1, it should be
queued for v3.2.
This branch is based
-omap-pm.git
for_3.2/i2c-fixes
Kevin Hilman (1):
Revert i2c-omap: fix static suspend vs. runtime suspend
Shubhrajyoti D (1):
OMAP4: I2C: Enable the wakeup in I2C_WE
drivers/i2c/busses/i2c-omap.c | 34 ++
1 files changed, 2 insertions(+), 32 deletions
. runtime suspend (2011-08-23
10:51:58 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git
for_3.2/i2c-cleanup
Kevin Hilman (3):
I2C: OMAP: remove unneccesary use of pdev
I2C: OMAP: remove dev-idle, use usage
Felipe Balbi ba...@ti.com writes:
On Wed, Aug 03, 2011 at 10:59:39AM -0700, Kevin Hilman wrote:
This reverts commit adf6e07922255937c8bfeea777d19502b4c9a2be.
Remove system PM methods which can race with runtime PM methods.
Also, as of v3.1, the PM domain level code for OMAP handles device
the bus/pm_domain methods themselves.
Signed-off-by: Kevin Hilman khil...@ti.com
---
v2: updated changelog to remove cliff-hanger ending
drivers/i2c/busses/i2c-omap.c | 29 -
1 files changed, 0 insertions(+), 29 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b
Felipe Balbi ba...@ti.com writes:
Hi,
On Wed, Aug 03, 2011 at 11:09:20AM -0700, Kevin Hilman wrote:
Current usage of runtime PM is not quite correct. The actual
idle/unidle of the I2C hardware should not happen until the runtime PM
callbacks are called. Therefore, change omap_i2c_[un]idle
A pointer to the struct device associated with the i2c device is
already kept in the struct omap_i2c_dev, so use omap_i2c_device to
find the pointer to struct device.
Reviewed-by: Felipe Balbi ba...@ti.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 22
.)
Also, the runtime PM core does usage counting and replaces
functionality currently managed by the dev-idle flag. Remove usage
of dev-idle in favor of using runtime PM, and checking status using
pm_runtime_suspended().
Signed-off-by: Kevin Hilman khil...@ti.com
---
drivers/i2c/busses/i2c-omap.c
of my tree.
[1] git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git
Kevin Hilman (2):
I2C: OMAP: remove unneccesary use of pdev
I2C: OMAP: remove dev-idle, use usage counting provided by runtime
PM
drivers/i2c/busses/i2c-omap.c | 77
1 - 100 of 190 matches
Mail list logo
