On Thu, 18 Oct 2012, Paul Walmsley wrote:
Here are some basic OMAP test results for Linux v3.7-rc1.
Logs and other details at http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/
A few additional observations missing from the original message.
Failing tests: needing investigation
ke, 2012-10-17 kello 19:02 +0300, Felipe Balbi kirjoitti:
Hi,
On Thu, Oct 11, 2012 at 02:08:25PM -0700, Kevin Hilman wrote:
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
On Tuesday 16 October 2012 04:35 AM, Paul Walmsley wrote:
Move the low-level SoC-specific powerdomain control functions into
prm*.c. For example, OMAP2xxx low-level powerdomain functions go into
prm2xxx.c. Then remove the unnecessary powerdomain*xxx*.c files.
The objective is to centralize
On Tuesday 16 October 2012 04:35 AM, Paul Walmsley wrote:
Move the low-level SoC-specific clockdomain control functions into
cm*.c and prm*.c. For example, OMAP2xxx low-level clockdomain
functions go into cm2xxx.c. Then remove the unnecessary
clockdomain*xxx*.c files.
The objective is to
Hi,
On Thu, Oct 18, 2012 at 09:51:13AM +0300, Kalle Jokiniemi wrote:
ke, 2012-10-17 kello 19:02 +0300, Felipe Balbi kirjoitti:
Hi,
On Thu, Oct 11, 2012 at 02:08:25PM -0700, Kevin Hilman wrote:
Hi Kalle,
Kalle Jokiniemi kalle.jokini...@jollamobile.com writes:
The
On 10/17/2012 11:33 PM, Russell King - ARM Linux :
On Wed, Oct 17, 2012 at 11:28:48PM +0300, Phil Carmody wrote:
So, what to do? It can and has been used sensibly, so I don't think removing
it is the best option.
Well, the first thing that needs to be done is a full review of every user
and
Hi Anil,
On 10/18/2012 07:46 AM, AnilKumar, Chimata wrote:
On Fri, Sep 21, 2012 at 21:19:11, AnilKumar, Chimata wrote:
Add tsl2550 ambient light sensor DT data to am335x-evm.dts. In AM335x
EVM tsl2550 ambient light sensor is connected to I2C2 bus. So this patch
adds child node inside i2c2
Op 18 okt. 2012, om 05:06 heeft Richard Cochran richardcoch...@gmail.com het
volgende geschreven:
On Wed, Oct 17, 2012 at 04:50:46PM -0700, Tony Lindgren wrote:
* Paul Walmsley p...@pwsan.com [121017 16:39]:
Hi Richard
On Wed, 17 Oct 2012, Richard Cochran wrote:
Would you please take
On Thu, 2012-10-18 at 06:48 +, Paul Walmsley wrote:
On Thu, 18 Oct 2012, Paul Walmsley wrote:
Here are some basic OMAP test results for Linux v3.7-rc1.
Logs and other details at http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/
A few additional observations missing from the original
Tero, paul,
On Thursday 18 October 2012 02:07 PM, Tero Kristo wrote:
On Thu, 2012-10-18 at 06:48 +, Paul Walmsley wrote:
On Thu, 18 Oct 2012, Paul Walmsley wrote:
Here are some basic OMAP test results for Linux v3.7-rc1.
Logs and other details at
On Tue, Oct 16, 2012 at 6:59 PM, Igor Grinberg grinb...@compulab.co.il wrote:
On 10/12/12 09:11, Srinivas KANDAGATLA wrote:
From: Srinivas Kandagatla srinivas.kandaga...@st.com
This patch removes some code duplication by using
module_platform_driver.
Signed-off-by: Srinivas Kandagatla
Hi,
Changes compared to previous version:
- rebased on top of 3.7-rc1
- applies on top of latest func pwrst code (v6)
- added back patch #1 to this set (it wasn't queued yet after all)
- added patch #7 for fixing a bug in the functional pwrst code
- added patch #8 for fixing a regression with
From: Rajendra Nayak rna...@ti.com
OMAP4 has module specific context lost registers which makes it now
possible to have module level context loss count, instead of relying
on the powerdomain level context count.
Add 2 private hwmod api's to update/clear the hwmod/module specific
context lost
Added similar PM errata flag support as omap3 has. This should be used
in similar manner, set the flags during init time, and check the flag
values during runtime.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/pm.h |7 +++
arch/arm/mach-omap2/pm44xx.c |1 +
2
From: Rajendra Nayak rna...@ti.com
Remove the FIXME's in the suspend sequence since
we now intend to support system level RET support.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Tero Kristo t-kri...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
---
Currently OMAP4 suspend puts all power domains to CSWR. OSWR is a deeper
state that saves more power, but has higher latencies also. As suspend
is considered a high-latency operation, OSWR is appropriate here.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/pm44xx.c |2 +-
From: Santosh Shilimkar santosh.shilim...@ti.com
On OMAP4+ devices, GIC register context is lost when MPUSS hits
the OSWR(Open Switch Retention). On the CPU wakeup path, ROM code
gets executed and one of the steps in it is to restore the
saved context of the GIC. The ROM Code GIC distributor
As the code within pwrdm_set_fpwrst is updating powerstate and logic
states according to powerdomain capabilities, it may alter the target
fpwrst also. Update the target fpwrst status according to these checks,
otherwise rest of the code in this function will malfunction.
Signed-off-by: Tero
From: Colin Cross ccr...@android.com
'Workaround for ROM bug because of CA9 r2pX gic control'
register change disables the gic distributor while the secondary
cpu is being booted. If a localtimer interrupt on the primary cpu
occurs when the distributor is turned off, the interrupt is lost,
and
Commit c9e4412ab8eb8ef82d645d8749c4ce96ad490007 removed all of the USB
PHY functions for OMAP4, but this causes a problem with core retention
as the MUSB module remains enabled if omap-usb2 phy driver is not used.
This keeps the USB DPLL enabled and prevents l3_init pwrdm from idling.
Fixed by
Fixes the following errors:
[2.318084] omap-mcbsp 49022000.mcbsp: invalid rx DMA channel
[2.324432] omap-mcbsp 49024000.mcbsp: invalid rx DMA channel
Which is because we failed to link the sidetone hwmod for McBSP2/3. The
missing sidetone hwmod link will prevent omap_device_alloc() to
On 10/18/2012 11:25 AM, Peter Ujfalusi wrote:
Fixes the following errors:
[2.318084] omap-mcbsp 49022000.mcbsp: invalid rx DMA channel
[2.324432] omap-mcbsp 49024000.mcbsp: invalid rx DMA channel
Which is because we failed to link the sidetone hwmod for McBSP2/3. The
missing
On 2012-10-17 17:38, Archit Taneja wrote:
Hi,
On Wednesday 17 October 2012 04:50 PM, Tomi Valkeinen wrote:
-if (r)
-DSSERR(failed to register FRAMEDONE isr\n);
+/* if we couldn't register for framedone, just sleep and exit */
+if (r) {
+msleep(200);
Hi,
On Thu, Oct 18, 2012 at 12:20:10PM +0300, Tero Kristo wrote:
Commit c9e4412ab8eb8ef82d645d8749c4ce96ad490007 removed all of the USB
PHY functions for OMAP4, but this causes a problem with core retention
as the MUSB module remains enabled if omap-usb2 phy driver is not used.
This keeps the
+Grant, DTML
On Thu, Oct 18, 2012 at 13:38:30, Cousson, Benoit wrote:
Hi Anil,
On 10/18/2012 07:46 AM, AnilKumar, Chimata wrote:
On Fri, Sep 21, 2012 at 21:19:11, AnilKumar, Chimata wrote:
Add tsl2550 ambient light sensor DT data to am335x-evm.dts. In AM335x
EVM tsl2550 ambient light
On Mon, Oct 15, 2012 at 4:05 PM, Paul Walmsley p...@pwsan.com wrote:
Move OMAP3xxx-specific CM functions macros into cm3xxx.[ch] and
OMAP2xxx-specific macros into cm2xxx.[ch]. Move basic CM register
access functions into static inline functions in cm2xxx_3xxx.h,
leaving only OMAP2/3
On Mon, Oct 15, 2012 at 4:05 PM, Paul Walmsley p...@pwsan.com wrote:
Move the low-level SoC-specific clockdomain control functions into
cm*.c and prm*.c. For example, OMAP2xxx low-level clockdomain
functions go into cm2xxx.c. Then remove the unnecessary
clockdomain*xxx*.c files.
The
On Thu, 2012-10-18 at 13:33 +0300, Felipe Balbi wrote:
Hi,
On Thu, Oct 18, 2012 at 12:20:10PM +0300, Tero Kristo wrote:
Commit c9e4412ab8eb8ef82d645d8749c4ce96ad490007 removed all of the USB
PHY functions for OMAP4, but this causes a problem with core retention
as the MUSB module remains
On Tuesday 16 October 2012 04:35 AM, Paul Walmsley wrote:
Consolidate and remove some PRM/CM code in preparation for a future move
into drivers/:
- Remove some obsolete weak functions that allowed old OMAP4 code to
reference OMAP2/3 PRM functions
- Split many of the functions in
On 2012-10-17 21:29, Tony Lindgren wrote:
* Tomi Valkeinen tomi.valkei...@ti.com [121017 03:27]:
Hi Tony,
I have pushed this vrfb series and the omapdss version series to:
git://gitorious.org/linux-omap-dss2/linux.git 3.8/dss-version
I used this branch up to commit
Enable TI EDMA option on OMAP.
Signed-off-by: Matt Porter mpor...@ti.com
---
drivers/dma/Kconfig |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 677cd6e..eaea1c2 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@
The binding definition is based on the generic DMA request binding.
Signed-off-by: Matt Porter mpor...@ti.com
---
Documentation/devicetree/bindings/spi/omap-spi.txt | 27 +++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git
Adds AM33XX SPI support for am335x-bone and am335x-evm.
Signed-off-by: Matt Porter mpor...@ti.com
---
arch/arm/boot/dts/am335x-bone.dts | 17 +++
arch/arm/boot/dts/am335x-evm.dts |9
arch/arm/boot/dts/am33xx.dtsi | 43 +
3
Convert dmaengine channel requests to use
dma_request_slave_channel_compat(). This supports the DT case of
platforms requiring channel selection from either the OMAP DMA or
the EDMA engine. AM33xx only boots from DT and is the only user
implementing EDMA so in the !DT case we can default to the
The binding definition is based on the generic DMA request binding.
Signed-off-by: Matt Porter mpor...@ti.com
---
.../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 25 +++-
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git
Adds AM33XX EDMA support to the am33xx.dtsi as documented in
Documentation/devicetree/bindings/dma/ti-edma.txt
Signed-off-by: Matt Porter mpor...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi | 31 +++
1 file changed, 31 insertions(+)
diff --git
Adds AM33XX MMC support for am335x-bone and am335x-evm.
Signed-off-by: Matt Porter mpor...@ti.com
---
arch/arm/boot/dts/am335x-bone.dts |6 ++
arch/arm/boot/dts/am335x-evm.dts |6 ++
arch/arm/boot/dts/am33xx.dtsi | 27 +++
3 files changed, 39
The EDMA DMAC has a hardware limitation that prevents supporting
scatter gather lists with any number of segments. Since the EDMA
DMA Engine driver sets the maximum segments to 16, we do the
same.
TODO: this will be replaced once the DMA Engine API supports an
API to query the DMAC's segment size
Convert dmaengine channel requests to use
dma_request_slave_channel_compat(). This supports the DT case of
platforms requiring channel selection from either the OMAP DMA or
the EDMA engine. AM33xx only boots from DT and is the only user
implementing EDMA so in the !DT case we can default to the
The binding definition is based on the generic DMA controller
binding.
Signed-off-by: Matt Porter mpor...@ti.com
---
Documentation/devicetree/bindings/dma/ti-edma.txt | 51 +
1 file changed, 51 insertions(+)
create mode 100644
Changes since v2:
- Rebased on 3.7-rc1
- Fixed bug in DT/pdata parsing first found by Gururaja
that turned out to be masked by some toolchains
- Dropped unused mach-omap2/devices.c hsmmc patch
- Added AM33XX crossbar DMA event mux support
- Added
The edma_slave_config() implementation depends on the
direction field such that it will not properly configure
a slave channel when called without direction set.
This fixes the implementation so that the slave config
is copied as is and prep_slave_sg() handles the
direction dependent handling.
Fix build on OMAP, the irqs are undefined on AM33xx.
These error interrupt handlers were hardcoded as disabled
so since they are unused code, simply remove them.
Signed-off-by: Matt Porter mpor...@ti.com
---
arch/arm/common/edma.c | 37 -
1 file changed, 37
Move mach-davinci/dma.c to common/edma.c so it can be used
by OMAP (specifically AM33xx) as well. This just moves the
private EDMA API but does not support OMAP.
Signed-off-by: Matt Porter mpor...@ti.com
---
arch/arm/Kconfig |1 +
arch/arm/common/Kconfig
Adds a dma_request_slave_channel_compat() wrapper which accepts
both the arguments from dma_request_channel() and
dma_request_slave_channel(). Based on whether the driver is
instantiated via DT, the appropriate channel request call will be
made.
This allows for a much cleaner migration of drivers
Adds support for the per-EDMA channel event mux. This is required
for any peripherals using DMA crossbar mapped events.
Signed-off-by: Matt Porter mpor...@ti.com
---
arch/arm/common/edma.c | 63 +++-
include/linux/platform_data/edma.h |1 +
2
Adds support for parsing the TI EDMA DT data into the required
EDMA private API platform data.
Calls runtime PM API only in the DT case in order to unidle the
associated hwmods on AM33XX.
Signed-off-by: Matt Porter mpor...@ti.com
---
arch/arm/common/edma.c | 255
From: Miguel Vadillo vadi...@ti.com
Since CAM domain (ISS) has no module wake-up dependency
with any other clock domain of the device and the dynamic
dependency from L3_main_2 is always disabled, the domain
needs to be in force wakeup in order to be able to access
it for configure (sysconfig) it
Hi,
On Monday 15 October 2012 17:36:40 Tony Lindgren wrote:
From: Ido Yariv i...@wizery.com
Move iommu/iovmm headers from plat/ to platform_data/ as part of the
single zImage work.
Is that really where those headers belong ? iommu-omap.h contains far more
than platform data, and
Hi Tony,
On Tuesday 16 October 2012 16:51:40 Laurent Pinchart wrote:
Hi Sakari,
Thanks for the patches.
For the whole series,
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Tony, do you want to take patch 1/3 in your tree, or can I push the whole
series through mine ?
hi,
On Thu, Oct 18, 2012 at 03:18:04PM +0300, Tero Kristo wrote:
+static int __init omap4430_phy_power_down(void)
+{
+ void __iomem *ctrl_base;
+
+ if (!cpu_is_omap44xx())
+ return 0;
+
+ ctrl_base = ioremap(OMAP443X_SCM_BASE, SZ_1K);
+ if (!ctrl_base) {
+
Hi Jon,
This looks good to me, I just have a minor nit comment.
On 10/17/2012 08:33 PM, Jon Hunter wrote:
Adds the counter-32k timers nodes present in OMAP2/3/4 devices and
device-tree binding documentation for OMAP counter-32k.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
On 10/18/2012 09:23 AM, Benoit Cousson wrote:
Hi Jon,
This looks good to me, I just have a minor nit comment.
On 10/17/2012 08:33 PM, Jon Hunter wrote:
Adds the counter-32k timers nodes present in OMAP2/3/4 devices and
device-tree binding documentation for OMAP counter-32k.
On Thu, 2012-10-18 at 16:53 +0300, Felipe Balbi wrote:
hi,
On Thu, Oct 18, 2012 at 03:18:04PM +0300, Tero Kristo wrote:
+static int __init omap4430_phy_power_down(void)
+{
+ void __iomem *ctrl_base;
+
+ if (!cpu_is_omap44xx())
+ return 0;
+
On Thu, 18 Oct 2012, Benoit Cousson wrote:
From: Miguel Vadillo vadi...@ti.com
Since CAM domain (ISS) has no module wake-up dependency
with any other clock domain of the device and the dynamic
dependency from L3_main_2 is always disabled, the domain
needs to be in force wakeup in order to
On Thu, Oct 18, 2012 at 05:39:59PM +0300, Tero Kristo wrote:
On Thu, 2012-10-18 at 16:53 +0300, Felipe Balbi wrote:
hi,
On Thu, Oct 18, 2012 at 03:18:04PM +0300, Tero Kristo wrote:
+static int __init omap4430_phy_power_down(void)
+{
+ void __iomem *ctrl_base;
+
On Tue, Oct 16, 2012 at 12:59:33PM +0300, Felipe Balbi wrote:
Hi,
+#ifdef CONFIG_PM_SLEEP
+static int xhci_plat_suspend(struct device *dev)
+{
+ struct usb_hcd *hcd= dev_get_drvdata(dev);
+ struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+
+ /* Make sure that the HCD Core
On Tue, Oct 16, 2012 at 04:53:28PM +0300, Felipe Balbi wrote:
Hi,
On Tue, Oct 16, 2012 at 05:10:39PM +0530, Vikas Sajjan wrote:
Hi Felipe,
...
did you have a transfer going through when you suspended ? If you
didn't, then you haven't stressed well enough.
2) We tested by running
* Laurent Pinchart laurent.pinch...@ideasonboard.com [121018 06:46]:
Hi Tony,
On Tuesday 16 October 2012 16:51:40 Laurent Pinchart wrote:
Hi Sakari,
Thanks for the patches.
For the whole series,
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Tony, do you
The same IP is found on AM33xx as well, so let users select it.
Signed-off-by: Daniel Mack zon...@gmail.com
---
drivers/rtc/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 19c03ab..5cb5be7 100644
---
This is needed as preparation for platforms where using pm runtime usage
is mandatory.
Signed-off-by: Daniel Mack zon...@gmail.com
---
drivers/rtc/rtc-omap.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index 0b614e3..baa876e
This adds bindings for the OMAP RTC driver.
There are currently two compatible string it matches, ti,omap-rtc and
ti,am33xx-rtc. This is done because the AM33xx needs extra registers
to be written in order to unlock the register set.
Also, the OMAP_RTC_OSC_REG can be set up via DT, in particular
On 10/18/2012 9:23 PM, Daniel Mack wrote:
This is needed as preparation for platforms where using pm runtime usage
is mandatory.
Signed-off-by: Daniel Mack zon...@gmail.com
It looks like, you just duplicated effort here.
RTC patches have been already submitted quite some time back for
Hi Gururaja,
On 10/18/2012 12:31 AM, Hebbar, Gururaja wrote:
Jon,
On Thu, Oct 18, 2012 at 02:42:01, Hunter, Jon wrote:
[snip]
My doubt/questions are
1. Why should debounce registers be updated only when it's accessed
previously?
If debounce is not being used by any of the gpios, then
On Wed, Oct 17, 2012 at 01:17:56, Hunter, Jon wrote:
On 10/15/2012 02:16 PM, Richard Cochran wrote:
From: hvaib...@ti.com hvaib...@ti.com
With recent changes in omap gpmc driver code, in case of DT
boot mode, where bootloader does not configure gpmc cs space
will result into kernel
On 18.10.2012 18:12, Vaibhav Hiremath wrote:
On 10/18/2012 9:23 PM, Daniel Mack wrote:
This is needed as preparation for platforms where using pm runtime usage
is mandatory.
Signed-off-by: Daniel Mack zon...@gmail.com
It looks like, you just duplicated effort here.
RTC patches have
* Laurent Pinchart laurent.pinch...@ideasonboard.com [121018 06:45]:
Hi,
On Monday 15 October 2012 17:36:40 Tony Lindgren wrote:
From: Ido Yariv i...@wizery.com
Move iommu/iovmm headers from plat/ to platform_data/ as part of the
single zImage work.
Is that really where those
Felipe Balbi ba...@ti.com writes:
current implementation doesn't take care about
drivers which don't provide *_noirq methods
The generic ops handle this. See below.
and we could fall into a situation where we would suspend/resume
devices even though they haven't asked for it.
The
On Thu, Oct 18, 2012 at 21:49:44, Daniel Mack wrote:
On 18.10.2012 18:12, Vaibhav Hiremath wrote:
On 10/18/2012 9:23 PM, Daniel Mack wrote:
This is needed as preparation for platforms where using pm runtime usage
is mandatory.
Signed-off-by: Daniel Mack zon...@gmail.com
It
Currently we use CK_446X etc to differentiate which clk needs to be registered
on which SoC.
The following patch series removes that requirement, instead SoC and SoC
variants are
detected on the fly and only the required clocks are registered in the system.
This will help to remove the CK_XYZ
Now the cpu_mask is used to differentiate clocks per each OMAP
platform, SoC version or revision. Such approach has few disadvantages:
- the specific CK_XXX flag need to be added and maintained for each OMAP
SoC;
- it's difficult to update clock tree data in case of differences
between OMAP SoC
Remove OMAP443x and OMAP446x specific clocks from omap44xx_clks
array and add corresponding set of clocks per each SoC:
- struct omap_clk omap44xx_clks[]; - common clocks set for all OMAP4
- struct omap_clk omap443x_clks[]; - specific clocks set for OMAP443x
- struct omap_clk omap446x_clks[]; -
On 10/18/2012 11:16 AM, Hiremath, Vaibhav wrote:
On Wed, Oct 17, 2012 at 01:17:56, Hunter, Jon wrote:
On 10/15/2012 02:16 PM, Richard Cochran wrote:
From: hvaib...@ti.com hvaib...@ti.com
With recent changes in omap gpmc driver code, in case of DT
boot mode, where bootloader does not
On Thu, 18 Oct 2012, Sarah Sharp wrote:
For system suspend while the DW3 hardware is in host mode, doesn't the
USB core prevent drivers from submitting URBs just before the
PCI/platform suspend is called? Alan?
Sure it does.
Alan Stern
--
To unsubscribe from this list: send the line
Hi Igor,
On Wed, Oct 17, 2012 at 2:43 PM, Igor Grinberg grinb...@compulab.co.il wrote:
You are adding declarations inside the common-board-devices.h,
but the implementation inside the devices.c.
I can see that devices.c has only on-soc devices in it.
So, I would expect to have the
Felipe Balbi ba...@ti.com writes:
device drivers should be smart enough to provide
-suspend/-resume callbacks when needed and they
should take care of doing whatever needs to be
done in order to allow a device to be suspended.
Calling pm_runtime_* from system suspend isn't
the right way to
Hi,
On Thu, Oct 18, 2012 at 09:34:15AM -0700, Kevin Hilman wrote:
Felipe Balbi ba...@ti.com writes:
current implementation doesn't take care about
drivers which don't provide *_noirq methods
The generic ops handle this. See below.
and we could fall into a situation where we would
Felipe Balbi ba...@ti.com writes:
current omap_device PM implementation defines
omap-specific *_noirq methods but uses the
generic versions for all other PM methods.
As it turns out, if a device decides to implement
non-runtime PM callbacks, we might fall into a
situation where the hwmod
Felipe Balbi ba...@ti.com writes:
OMAP I2C driver will re-enable IRQs right after
masking them during suspend.
That's not what we want. We want to keep IRQs
masked until our resume method is called.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 10
Hi,
On Thu, Oct 18, 2012 at 10:01:00AM -0700, Kevin Hilman wrote:
Felipe Balbi ba...@ti.com writes:
device drivers should be smart enough to provide
-suspend/-resume callbacks when needed and they
should take care of doing whatever needs to be
done in order to allow a device to be
Hi,
On Thu, Oct 18, 2012 at 10:07:31AM -0700, Kevin Hilman wrote:
Felipe Balbi ba...@ti.com writes:
current omap_device PM implementation defines
omap-specific *_noirq methods but uses the
generic versions for all other PM methods.
As it turns out, if a device decides to implement
On Thu, Oct 18, 2012 at 10:10:06AM -0700, Kevin Hilman wrote:
Felipe Balbi ba...@ti.com writes:
OMAP I2C driver will re-enable IRQs right after
masking them during suspend.
That's not what we want. We want to keep IRQs
masked until our resume method is called.
Signed-off-by:
Hi,
On Thu, Oct 18, 2012 at 08:06:40PM +0300, Felipe Balbi wrote:
Hi,
On Thu, Oct 18, 2012 at 10:07:31AM -0700, Kevin Hilman wrote:
Felipe Balbi ba...@ti.com writes:
current omap_device PM implementation defines
omap-specific *_noirq methods but uses the
generic versions for all
Hi,
On Thu, Oct 18, 2012 at 12:44:50PM -0400, Alan Stern wrote:
On Thu, 18 Oct 2012, Sarah Sharp wrote:
For system suspend while the DW3 hardware is in host mode, doesn't the
USB core prevent drivers from submitting URBs just before the
PCI/platform suspend is called? Alan?
Sure it
Hi,
On Thu, Oct 18, 2012 at 07:59:56AM -0700, Sarah Sharp wrote:
On Tue, Oct 16, 2012 at 12:59:33PM +0300, Felipe Balbi wrote:
Hi,
+#ifdef CONFIG_PM_SLEEP
+static int xhci_plat_suspend(struct device *dev)
+{
+ struct usb_hcd *hcd= dev_get_drvdata(dev);
+ struct xhci_hcd
Felipe Balbi ba...@ti.com writes:
Hi,
On Thu, Oct 18, 2012 at 09:34:15AM -0700, Kevin Hilman wrote:
Felipe Balbi ba...@ti.com writes:
current implementation doesn't take care about
drivers which don't provide *_noirq methods
The generic ops handle this. See below.
and we could
Quoting Grygorii Strashko (2012-10-18 09:38:17)
Remove OMAP443x and OMAP446x specific clocks from omap44xx_clks
array and add corresponding set of clocks per each SoC:
- struct omap_clk omap44xx_clks[]; - common clocks set for all OMAP4
- struct omap_clk omap443x_clks[]; - specific clocks
Hi,
On Thu, Oct 18, 2012 at 10:42:37AM -0700, Kevin Hilman wrote:
Felipe Balbi ba...@ti.com writes:
Hi,
On Thu, Oct 18, 2012 at 09:34:15AM -0700, Kevin Hilman wrote:
Felipe Balbi ba...@ti.com writes:
current implementation doesn't take care about
drivers which don't provide
On Thu, Oct 18, 2012 at 22:12:07, Hunter, Jon wrote:
On 10/18/2012 11:16 AM, Hiremath, Vaibhav wrote:
On Wed, Oct 17, 2012 at 01:17:56, Hunter, Jon wrote:
On 10/15/2012 02:16 PM, Richard Cochran wrote:
From: hvaib...@ti.com hvaib...@ti.com
With recent changes in omap gpmc driver
On Thu, Oct 18, 2012 at 03:46:15AM +, Paul Walmsley wrote:
It doesn't necessarily mean that the driver is usable in that kernel
release.
Well, it should. We have staging for half-baked stuff.
Either way, the patch is likely to make it into the mainline kernel.
It's just that it will
On 10/18/2012 01:04 PM, Hiremath, Vaibhav wrote:
On Thu, Oct 18, 2012 at 22:12:07, Hunter, Jon wrote:
...
Yes, but do you also see the bug that is hiding in gpmc_mem_init()?
My point is to highlight this and not hide it, so that we can fix it
now. Otherwise if we wait until we enable the
On Fri, Oct 19, 2012 at 00:00:31, Hunter, Jon wrote:
On 10/18/2012 01:04 PM, Hiremath, Vaibhav wrote:
On Thu, Oct 18, 2012 at 22:12:07, Hunter, Jon wrote:
...
Yes, but do you also see the bug that is hiding in gpmc_mem_init()?
My point is to highlight this and not hide it, so that
Felipe Balbi ba...@ti.com writes:
Hi,
On Thu, Oct 18, 2012 at 10:42:37AM -0700, Kevin Hilman wrote:
Felipe Balbi ba...@ti.com writes:
Hi,
On Thu, Oct 18, 2012 at 09:34:15AM -0700, Kevin Hilman wrote:
Felipe Balbi ba...@ti.com writes:
current implementation doesn't take care
On Thu, 18 Oct 2012, Richard Cochran wrote:
I *do* mind if y'all go merging all kinds of code that has never been
tested. Those who submit and their reviewers should ensure that the
code is actually working. Before buying hardware or starting projects,
I often check what is in mainline. I
On Thu, Oct 18, 2012 at 03:46:15AM +, Paul Walmsley wrote:
Probably the driver was submitted before any SoC integration support was
available. Grepping for 'cpsw' under arch/ turns up only AM33xx. AM335x
didn't have device enumeration support in the mainline kernel until 3.7,
via
On 10/18/2012 01:39 PM, Hiremath, Vaibhav wrote:
On Fri, Oct 19, 2012 at 00:00:31, Hunter, Jon wrote:
On 10/18/2012 01:04 PM, Hiremath, Vaibhav wrote:
On Thu, Oct 18, 2012 at 22:12:07, Hunter, Jon wrote:
...
Yes, but do you also see the bug that is hiding in gpmc_mem_init()?
My point is
On Thu, 18 Oct 2012, Richard Cochran wrote:
You say it will be working in 3.8, after 3.7 comes out, in about
December.
I wrote that we'll schedule the SoC integration patch for sending upstream
for 3.8. This does not necessarily mean that our upstreams will take it,
or that it will result
Hi,
On Thu, Oct 18, 2012 at 11:42:33AM -0700, Kevin Hilman wrote:
Again, this is required because system suspend disables runtime PM
transitions at a certain point, if the device is used after that point,
there is *no other way* for the driver to properly manage the idle
transition (or,
Hi all,
Here's this one again fixed with the issues Laurent noticed.
Regards,
Tony
---
Ido Yariv (3):
ARM: OMAP: Merge iommu2.h into iommu.h
ARM: OMAP2+: Move iopgtable header to drivers/iommu/
ARM: OMAP2+: Make some definitions local
Tony Lindgren (3):
ARM: OMAP2+:
From: Ido Yariv i...@wizery.com
The iopgtable header file is only used by the iommu iovmm drivers, so
move it to drivers/iommu/, as part of the single zImage effort.
Cc: Joerg Roedel joerg.roe...@amd.com
Cc: Ohad Ben-Cohen o...@wizery.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
1 - 100 of 128 matches
Mail list logo
