On Tue, Dec 18, 2012 at 11:54:50AM +0200, Felipe Balbi wrote:
damn, this is still part of our v3.7-rc kernel. Original commit was done
with no testing whatsoever and caused a big regression to (at least)
TI's WiFi driver which depend on SDIO to function.
Too bad things break and even when
On 12/19/2012 10:45 AM, Mark Brown wrote:
On Tue, Dec 18, 2012 at 11:54:50AM +0200, Felipe Balbi wrote:
damn, this is still part of our v3.7-rc kernel. Original commit was done
with no testing whatsoever and caused a big regression to (at least)
TI's WiFi driver which depend on SDIO to
Hi Kevin,
2012/12/18 Kevin Liu keyuan@gmail.com:
2012/12/18 Johan Rudholm johan.rudh...@stericsson.com:
...
+ host-ios.signal_voltage = signal_voltage;
err = host-ops-start_signal_voltage_switch(host,
host-ios);
- mmc_host_clk_release(host);
On Wed, Dec 19, 2012 at 12:01:57PM +0200, Luciano Coelho wrote:
I think one of the reasons not many people use the mainline with TWL is
exactly because something seems to break on every new kernel release.
I'm one of those who care and report things when I see them.
Well, it's a recursive
On Wed, 2012-12-19 at 10:28 +, Mark Brown wrote:
On Wed, Dec 19, 2012 at 12:01:57PM +0200, Luciano Coelho wrote:
I think one of the reasons not many people use the mainline with TWL is
exactly because something seems to break on every new kernel release.
I'm one of those who care and
On 12/19/2012 11:45 AM, Luciano Coelho wrote:
Well, we still haven't got the foggiest idea what the actual problem is
beyond that it's probably related to the 32kHz clock in some way (unless
it was one of the other reverts that coincidentally made a difference,
but we don't know what they
On 12/19/2012 11:56 AM, Peter Ujfalusi wrote:
BTW: have you happened to ubdate u-boot recently? There is a nice easter egg
added there:
f3f98bb ARM: OMAP4/5: Do not configure non essential pads, clocks, dplls.
Which means that _essential_ clocks and pads are no longer configured.
Meanwhile
On Wed, 2012-12-19 at 11:56 +0100, Peter Ujfalusi wrote:
On 12/19/2012 11:45 AM, Luciano Coelho wrote:
Well, we still haven't got the foggiest idea what the actual problem is
beyond that it's probably related to the 32kHz clock in some way (unless
it was one of the other reverts that
Not to disable SD Host IRQ during suspend if it is wake up source.
Enable wakeup event during suspend.
Signed-off-by: Jialing Fu j...@marvell.com
Signed-off-by: Kevin Liu kl...@marvell.com
---
drivers/mmc/host/sdhci.c | 60 -
1 files changed, 42
Signed-off-by: Jialing Fu j...@marvell.com
Signed-off-by: Kevin Liu kl...@marvell.com
---
drivers/mmc/host/sdhci-pxav3.c |7 +++
include/linux/platform_data/pxa_sdhci.h |2 ++
2 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/host/sdhci-pxav3.c
Sdio device may trigger interrupt after its function suspended
while system not suspended yet.
This patch handle above cases by below two methods:
1. For multiple sdio_funcs, abort suspend if interrupt happen after
its func suspended while some other funcs not suspended yet.
2. If interrupt
This patchset aim to enhance sdio irq handling during suspend/resume so as to
wakeup host system with sdio card interrupt.
Kevin Liu (2):
mmc: sdio: defer sdio irq handling when host suspended
mmc: sdio: handle interrupt corner case during suspend
drivers/mmc/core/sdio.c | 59
If sdio host can wakeup system, its interrupt will _NOT_ be disabled
during suspending. So when card interrupt happens, the sdio irq thread
will be woken up.
Claim the host to avoid sdio irq thread handling the pending interrupt
while sdio host suspended. The pending interrupt will be handled
Hi,
+Sricharan who commited that
On Wed, Dec 19, 2012 at 11:56:20AM +0100, Peter Ujfalusi wrote:
On 12/19/2012 11:45 AM, Luciano Coelho wrote:
Well, we still haven't got the foggiest idea what the actual problem is
beyond that it's probably related to the 32kHz clock in some way (unless
On 12/19/2012 02:01 PM, Felipe Balbi wrote:
Hi,
+Sricharan who commited that
On Wed, Dec 19, 2012 at 11:56:20AM +0100, Peter Ujfalusi wrote:
On 12/19/2012 11:45 AM, Luciano Coelho wrote:
Well, we still haven't got the foggiest idea what the actual problem is
beyond that it's probably
Hi,
On Wed, Dec 19, 2012 at 02:51:14PM +0100, Benoit Cousson wrote:
On 12/19/2012 02:01 PM, Felipe Balbi wrote:
Hi,
+Sricharan who commited that
On Wed, Dec 19, 2012 at 11:56:20AM +0100, Peter Ujfalusi wrote:
On 12/19/2012 11:45 AM, Luciano Coelho wrote:
Well, we still haven't
On Wed, Dec 19, 2012 at 02:51:14PM +0100, Benoit Cousson wrote:
Regarding the 32k clock, I noticed as well that the OMAP4460 panda
u-boot is the only one to enable it at boot time, and thus this is the
only board that can probe the wilink chip properly as of today.
Well, there was nothing in
On 12/19/2012 02:58 PM, Luciano Coelho wrote:
On Wed, 2012-12-19 at 14:51 +0100, Benoit Cousson wrote:
On 12/19/2012 02:01 PM, Felipe Balbi wrote:
On Wed, Dec 19, 2012 at 11:56:20AM +0100, Peter Ujfalusi wrote:
BTW: have you happened to ubdate u-boot recently? There is a nice easter
egg
* Peter Ujfalusi peter.ujfal...@ti.com [121219 02:20]:
On 12/19/2012 11:09 AM, Mark Brown wrote:
On Wed, Dec 19, 2012 at 11:00:32AM +0100, Peter Ujfalusi wrote:
I don't know the state of the common clock framework for OMAPs. Is it
already
up in 3.7? Or going for 3.8? 3.9? 3.10?...
Chris,
On Fri, Nov 30, 2012 at 3:57 AM, Seungwon Jeon tgih@samsung.com wrote:
Doug, Thanks to work.
Looks good to me with other patches.
Acked-by: Seungwon Jeon tgih@samsung.com
Does this series look reasonable to you? I can check back later when
things are less hectic, but I wanted
On Wednesday, December 19, 2012, Konstantin Dorfman wrote:
On 12/17/2012 02:26 PM, Seungwon Jeon wrote:
Hi, Konstantin.
I added comments more below.
I've answered below.
On Wednesday, December 12, 2012, Seungwon Jeon wrote:
On Monday, December 10, 2012, Konstantin Dorfman wrote:
21 matches
Mail list logo
