supports enhanced features of hardware, they are available
to the user else the basic functionality still works
[2]
https://lkml.org/lkml/2013/7/3/74
[1]
https://lkml.org/lkml/2013/8/1/442
Hebbar Gururaja (1):
ARM: dts: AM33XX: update rtc node compatibility
Hebbar, Gururaja (1):
rtc
compatibility.
ex:
compatible = ti,am3352-rtc, ti,da830-rtc;
Signed-off-by: Hebbar, Gururaja gururaja.heb...@ti.com
CC: mark.rutl...@arm.com
---
Changes in v3:
- new patch
:100644 100644 dc62cc3... 2f0968c... M drivers/rtc/rtc-omap.c
drivers/rtc/rtc-omap.c |6 +++---
1 files
From: Hebbar Gururaja gururaja.heb...@ti.com
Since AM33xx RTC IP has RTC_IRQWAKEEN to support Alarm Wake-up, update
the rtc compatible property to enable handling of this feature inside
rtc-omap driver.
Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com
CC: mark.rutl...@arm.com
---
Changes
compatibility.
ex:
compatible = ti,am3352-rtc, ti,da830-rtc;
Signed-off-by: Hebbar, Gururaja gururaja.heb...@ti.com
CC: mark.rutl...@arm.com
---
Changes in V4:
- Rebased on latest linux-next (as on 160813).
- Correct a type AM335X -- AM3352
Changes in v3:
- new patch
/2013/8/1/442
Hebbar Gururaja (1):
ARM: dts: AM33XX: update rtc node compatibility
Hebbar, Gururaja (1):
rtc: omap: update of_device_id to reflect latest ip revisions
arch/arm/boot/dts/am33xx.dtsi |2 +-
drivers/rtc/rtc-omap.c|6 +++---
2 files changed, 4 insertions(+), 4
From: Hebbar Gururaja gururaja.heb...@ti.com
Since AM33xx RTC IP has RTC_IRQWAKEEN to support Alarm Wake-up, update
the rtc compatible property to enable handling of this feature inside
rtc-omap driver.
Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com
CC: mark.rutl...@arm.com
---
Changes
-by: Hebbar Gururaja gururaja.heb...@ti.com
Acked-by: Kevin Hilman khil...@linaro.org
Acked-by: Sekhar Nori nsek...@ti.com
Cc: Grant Likely grant.lik...@linaro.org
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
Cc: Alessandro Zummo a.zu...@towertech.it
Cc: rtc-li...@googlegroups.com
/msg26077.html
Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com
Acked-by: Kevin Hilman khil...@linaro.org
Cc: Alessandro Zummo a.zu...@towertech.it
Cc: rtc-li...@googlegroups.com
---
:100644 100644 b0ba3fc... 761919d... M drivers/rtc/rtc-omap.c
drivers/rtc/rtc-omap.c |2 ++
1 file changed
-l1: mark RTC as a wakeup source
Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com
Acked-by: Kevin Hilman khil...@linaro.org
Acked-by: Sekhar Nori nsek...@ti.com
Cc: Russell King li...@arm.linux.org.uk
---
Changes in V2:
- Coding style corrections (remove extra space)
- use prefix
Since AM33xx RTC IP has RTC_IRQWAKEEN to support Alarm Wake-up.
Update the rtc compatible property to ti,am3352-rtc to enable handling
of this feature inside rtc-omap driver.
Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com
---
:100644 100644 77aa1b0... dde180a... M arch/arm/boot/dts
the basic functionality still works
Hebbar Gururaja (4):
rtc: omap: restore back (hard-code) wakeup support
ARM: Davinci: da8xx/omap-l1: Remove hard coding of rtc device wakeup
rtc: omap: add rtc wakeup support to alarm events
ARM: dts: AM33XX: update rtc node compatibility
Documentation
On Tue, Jul 02, 2013 at 11:32:34, Nori, Sekhar wrote:
On 6/28/2013 3:05 PM, Hebbar Gururaja wrote:
On some platforms (like AM33xx), a special register (RTC_IRQWAKEEN)
is available to enable Alarm Wakeup feature. This register needs to be
properly handled for the rtcwake to work properly
On Tue, Jul 02, 2013 at 11:39:28, Nori, Sekhar wrote:
On 7/2/2013 11:34 AM, Hebbar, Gururaja wrote:
On Tue, Jul 02, 2013 at 11:32:34, Nori, Sekhar wrote:
On 6/28/2013 3:05 PM, Hebbar Gururaja wrote:
On some platforms (like AM33xx), a special register (RTC_IRQWAKEEN)
is available to enable
On Tue, Jul 02, 2013 at 11:42:49, Nori, Sekhar wrote:
Changing to Benoit's gmail id since he apparently wont access TI mail
anymore.
On 6/28/2013 3:05 PM, Hebbar Gururaja wrote:
Since AM33xx RTC IP has RTC_IRQWAKEEN to support Alarm Wake-up.
Update the rtc compatible property to ti
On Tue, Jul 02, 2013 at 11:42:49, Nori, Sekhar wrote:
Changing to Benoit's gmail id since he apparently wont access TI mail
anymore.
On 6/28/2013 3:05 PM, Hebbar Gururaja wrote:
Since AM33xx RTC IP has RTC_IRQWAKEEN to support Alarm Wake-up.
Update the rtc compatible property to ti
Hi all,
Kindly ignore this message. It was sent in wrong format.
Sorry for the noise
Regards,
Gururaja
On Wed, Jul 03, 2013 at 10:26:57, Hebbar, Gururaja wrote:
Below is the code snippet I was referring to
From drivers/rtc/rtc-omap.c
static struct platform_device_id
On Tue, Jul 02, 2013 at 05:37:43, Kevin Hilman wrote:
Hebbar Gururaja gururaja.heb...@ti.com writes:
Since now rtc-omap driver itself calls deice_init_wakeup(dev, true),
duplicate call from the rtc device registration can be removed.
This is basically a partial revert of the prev commit
On Tue, Jul 02, 2013 at 05:45:01, Kevin Hilman wrote:
Hebbar Gururaja gururaja.heb...@ti.com writes:
On some platforms (like AM33xx), a special register (RTC_IRQWAKEEN)
is available to enable Alarm Wakeup feature. This register needs to be
properly handled for the rtcwake to work properly
On Tue, Jul 02, 2013 at 11:10:14, Nori, Sekhar wrote:
On 6/28/2013 3:05 PM, Hebbar Gururaja wrote:
Since now rtc-omap driver itself calls deice_init_wakeup(dev, true),
duplicate call from the rtc device registration can be removed.
This is basically a partial revert of the prev commit
-archive.com/davinci-linux-open-source@linux.
davincidsp.com/msg26077.html
Hebbar Gururaja (4):
rtc: omap: restore back (hard-code) wakeup support
davinci: da8xx/omap-l1: Remove hard coding of rtc device wakeup
rtc: omap: add rtc wakeup support to alarm events
ARM: dts: AM33XX: update rtc node
-l1: mark RTC as a wakeup source
Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com
Cc: Sekhar Nori nsek...@ti.com
Cc: Kevin Hilman khil...@linaro.org
Cc: Russell King li...@arm.linux.org.uk
---
:100644 100644 bf57252... 85a900c... M arch/arm/mach-davinci/devices-da8xx.c
arch/arm/mach-davinci
/msg26077.html
Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com
Cc: Alessandro Zummo a.zu...@towertech.it
Cc: rtc-li...@googlegroups.com
---
:100644 100644 b0ba3fc... 761919d... M drivers/rtc/rtc-omap.c
drivers/rtc/rtc-omap.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/rtc
-by: Hebbar Gururaja gururaja.heb...@ti.com
Cc: Grant Likely grant.lik...@linaro.org
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
Cc: Sekhar Nori nsek...@ti.com
Cc: Kevin Hilman khil...@linaro.org
Cc: Alessandro Zummo a.zu...@towertech.it
Cc: rtc-li...@googlegroups.com
Cc
Since AM33xx RTC IP has RTC_IRQWAKEEN to support Alarm Wake-up.
Update the rtc compatible property to ti,am3352-rtc to enable handling
of this feature inside rtc-omap driver.
Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Sekhar Nori nsek...@ti.com
On Wed, Jun 26, 2013 at 06:55:01, Fernandes, Joel wrote:
From: Joel A Fernandes agnel.j...@gmail.com
A new reg-offset property was added to account for register offsets
in some omap-hsmmc's. Document the new property.
Small nitpick
I usually get feedback that any driver DT changes and the
On Fri, May 31, 2013 at 20:25:38, Strashko, Grygorii wrote:
On 05/31/2013 01:13 PM, Hebbar Gururaja wrote:
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
On Fri, May 31, 2013 at 23:04:59, Kevin Hilman wrote:
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
On Fri, May 31, 2013 at 23:37:02, Kevin Hilman wrote:
+Linus Walleij (pinctrl maintainer)
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
On Tue, Jun 04, 2013 at 12:49:57, Linus Walleij wrote:
On Tue, Jun 4, 2013 at 9:11 AM, Linus Walleij linus.wall...@linaro.org
wrote:
On Fri, May 31, 2013 at 12:13 PM, Hebbar Gururaja
gururaja.heb...@ti.com wrote:
Amend the hsmmc controller to optionally take a pin control handle
this warning message
pass respective state name with null phandler.
(Changes based on i2c-nomadik.c)
Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Wolfram Sang w...@the-dreams.de
Cc: linux-omap@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
:100644
.
If any of the above pin states are missing in dt, a warning message
about the missing state is displayed.
If certain pin-states are not available, to remove this warning message
pass respective state name with null phandler.
Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com
Cc: Balaji T K balaj
On Thu, May 23, 2013 at 12:27:41, David Miller wrote:
From: Mugunthan V N mugunthan...@ti.com
Date: Tue, 21 May 2013 15:24:58 +0530
+ priv-pins_default = pinctrl_lookup_state(priv-pinctrl,
+ PINCTRL_STATE_DEFAULT);
This is not indented
On Fri, May 10, 2013 at 15:26:29, Mark Brown wrote:
On Tue, May 07, 2013 at 10:47:31AM +, Hebbar, Gururaja wrote:
On Tue, May 07, 2013 at 14:25:35, Mark Brown wrote:
There's also been some discussion about factoring out the suspend/resume
code since it's going to get equally
On Tue, May 07, 2013 at 14:25:35, Mark Brown wrote:
On Tue, May 07, 2013 at 03:56:09AM +, Hebbar, Gururaja wrote:
There are cases where driver('s) needs to place pin-mux's to sleep on
suspend
default/idle on resume. For such cases Pinctrl needs to be handled inside
the driver
On Tue, May 07, 2013 at 01:06:38, Mark Brown wrote:
Since commit ab78029 (drivers/pinctrl: grab default handles from device
core) we can rely on device core for handling pinctrl so remove
devm_pinctrl_get_select_default() from the driver.
NACK.
There are cases where driver('s) needs to place
On Thu, Jan 31, 2013 at 12:58:36, Koen Kooi wrote:
Op 30 jan. 2013, om 15:39 heeft Hebbar Gururaja gururaja.heb...@ti.com het
volgende geschreven:
am33xx_cm_wait_module_ready() checks if register offset is NULL.
int am33xx_cm_wait_module_ready(u16 inst, s16 cdoffs, u16 clkctrl_offs
struct omap_hwmod records belonging to wkup m3 domain is missing
HWMOD_NO_IDLEST flags; add them.
Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com
---
Change in v2:
- new patch
:100644 100644 646c14d... 1ab693e... M
arch/arm/mach-omap2/omap_hwmod_33xx_data.c
arch/arm/mach-omap2
register offset at 0x00.
Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com
---
Change in v2:
- No change
:100644 100644 058ce3c... 325a515... M arch/arm/mach-omap2/cm33xx.c
arch/arm/mach-omap2/cm33xx.c |3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/mach-omap2
1. Add add missing HWMOD_NO_IDLEST flags
2. Fix register offset NULL check bug
Changes in v2:
- As per Paul's suggestion 1st add HWMOD_NO_IDLEST flag where
it is necessary and then correct the clock control register
offset check bug.
Hebbar Gururaja (2):
ARM: OMAP2
On Thu, Jan 31, 2013 at 20:58:24, Paul Walmsley wrote:
Hi
On Thu, 31 Jan 2013, Hebbar Gururaja wrote:
struct omap_hwmod records belonging to wkup m3 domain is missing
HWMOD_NO_IDLEST flags; add them.
Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com
I've modified this patch
On Thu, Jan 31, 2013 at 21:00:32, Paul Walmsley wrote:
+ Koen
Hi
On Thu, 31 Jan 2013, Hebbar Gururaja wrote:
am33xx_cm_wait_module_ready() checks if register offset is NULL.
int am33xx_cm_wait_module_ready(u16 inst, s16 cdoffs, u16 clkctrl_offs)
{
int i = 0
On Thu, Dec 20, 2012 at 13:05:27, Paul Walmsley wrote:
On Thu, 20 Dec 2012, Hebbar, Gururaja wrote:
On Wed, Dec 19, 2012 at 07:43:50, Paul Walmsley wrote:
We've got a few hwmods on OMAP44xx that don't have clkctrl_offs registers
listed in the hwmod data, and which are not marked
register offset at 0x00.
Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com
---
Changes in v3:
- Since now there is separate cm33xx.c file which handles module
ready checking for am33xx platform, use the same for the fix.
- Also update subject to indicate am33xx platform
On Wed, Jan 30, 2013 at 22:09:51, Paul Walmsley wrote:
On Wed, 30 Jan 2013, Hebbar, Gururaja wrote:
On Thu, Dec 20, 2012 at 13:05:27, Paul Walmsley wrote:
On Thu, 20 Dec 2012, Hebbar, Gururaja wrote:
On Wed, Dec 19, 2012 at 07:43:50, Paul Walmsley wrote:
We've got a few
On Fri, Jan 11, 2013 at 11:18:37, Porter, Matt wrote:
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 and enables it to build on OMAP.
Signed-off-by: Matt Porter mpor...@ti.com
---
arch/arm/Kconfig
On Fri, Jan 11, 2013 at 11:18:41, Porter, Matt wrote:
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(+)
Matt,
On Thu, Oct 18, 2012 at 18:56:52, Porter, Matt wrote:
Adds AM33XX MMC support for am335x-bone and am335x-evm.
I want to test Suspend/Resume feature on omap hsmmc driver.
Do you any tree based on mainline kernel v3.8-rc1 with these edma mmc
patches.
Signed-off-by: Matt Porter
On Wed, Dec 19, 2012 at 07:43:50, Paul Walmsley wrote:
On Tue, 18 Dec 2012, Hebbar Gururaja wrote:
From: Hebbar, Gururaja gururaja.heb...@ti.com
omap4_cminst_wait_module_ready() checks if register offset is NULL.
int omap4_cminst_wait_module_ready(u8 part, u16 inst, s16 cdoffs
From: Hebbar, Gururaja gururaja.heb...@ti.com
omap4_cminst_wait_module_ready() checks if register offset is NULL.
int omap4_cminst_wait_module_ready(u8 part, u16 inst, s16 cdoffs,
u16 clkctrl_offs)
{
int i = 0;
if (!clkctrl_offs
On Tue, Dec 18, 2012 at 18:01:43, Balbi, Felipe wrote:
Hi,
On Tue, Dec 18, 2012 at 06:02:09PM +0530, Hebbar Gururaja wrote:
From: Hebbar, Gururaja gururaja.heb...@ti.com
omap4_cminst_wait_module_ready() checks if register offset is NULL.
int omap4_cminst_wait_module_ready(u8 part
From: Hebbar, Gururaja gururaja.heb...@ti.com
omap4_cminst_wait_module_ready() checks if register offset is NULL.
int omap4_cminst_wait_module_ready(u8 part, u16 inst, s16 cdoffs,
u16 clkctrl_offs)
{
int i = 0;
if (!clkctrl_offs
On Thu, Oct 18, 2012 at 18:56:39, Porter, Matt wrote:
...snip...
...snip...
...snip...
This series adds DMA Engine support for AM33xx, which uses
an EDMA DMAC. The EDMA DMAC has been previously supported by only
a private API implementation (much like the situation with OMAP
DMA) found on
On Thu, Oct 18, 2012 at 21:44:56, Hunter, Jon wrote:
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
On Thu, Nov 01, 2012 at 01:46:26, Balbi, Felipe wrote:
Hi,
On Thu, Nov 01, 2012 at 01:21:36AM +0530, Venkatraman S wrote:
On Wed, Oct 31, 2012 at 5:56 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Wed, Oct 31, 2012 at 05:27:36PM +0530, Hebbar, Gururaja wrote:
HSMMC IP on AM33xx
On Wed, Oct 31, 2012 at 11:14:28, Balbi, Felipe wrote:
Hi,
On Wed, Oct 31, 2012 at 06:17:02AM +0100, Hebbar, Gururaja wrote:
On Mon, Oct 29, 2012 at 21:47:19, Balbi, Felipe wrote:
Hi,
On Mon, Oct 29, 2012 at 06:26:48PM +0530, Hebbar, Gururaja wrote:
HSMMC IP on AM33xx need
and
- Controller should not be using DDR Mode and
- Controller should advertise that it supports High Speed in
capabilities register and
- MMC/SD clock coming out of controller 25MHz
Note:
The implementation reuses the output of calc_divisor() so as to reduce
code addition.
Signed-off-by: Hebbar
and
- Controller should not be using DDR Mode and
- Controller should advertise that it supports High Speed in
capabilities register and
- MMC/SD clock coming out of controller 25MHz
Note:
The implementation reuses the output of calc_divisor() so as to reduce
code addition.
Signed-off-by: Hebbar
On Mon, Oct 29, 2012 at 21:47:19, Balbi, Felipe wrote:
Hi,
On Mon, Oct 29, 2012 at 06:26:48PM +0530, Hebbar, Gururaja wrote:
HSMMC IP on AM33xx need a special setting to handle High-speed cards.
Other platforms like TI81xx, OMAP4 may need this as-well. This depends
on the HSMMC IP timing
On Wed, Oct 31, 2012 at 01:58:32, Joel A Fernandes wrote:
Hi Gururaja,
On Mon, Oct 29, 2012 at 10:45 AM, Hebbar, Gururaja
gururaja.heb...@ti.com wrote:
Matt,
On Wed, Oct 10, 2012 at 20:00:49, Porter, Matt wrote:
6ea74cb ARM: OMAP2+: hwmod: get rid of all omap_clk_get_by_name usage
and
- Controller should not be using DDR Mode and
- Controller should advertise that it supports High Speed in
capabilities register and
- MMC/SD clock coming out of controller 25MHz
Signed-off-by: Hebbar, Gururaja gururaja.heb...@ti.com
---
Rebased on mmc-next (v3.7.0-rc1)
Only Build tested
Matt,
On Wed, Oct 10, 2012 at 20:00:49, Porter, Matt wrote:
6ea74cb ARM: OMAP2+: hwmod: get rid of all omap_clk_get_by_name usage
exposes a bug in the AM33XX clock data for mcasp. After moving to
clk_get() usage, the _init() of all registered hwmods fails on mcasp0
due to incorrect clock data
On Thu, Oct 18, 2012 at 18:56:44, Porter, Matt wrote:
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
Hi,
I came across a peculiar issue while updating GPIO debounce registers on
OMAP platform.
According to mainline commit ae547354a8ed59f19b57f7e1de9c7816edfc3537
gpio/omap: save and restore debounce registers
GPIO debounce registers need to be saved and restored for proper functioning
of
Jon,
On Thu, Oct 18, 2012 at 02:42:01, Hunter, Jon wrote:
Hi Gururaja,
On 10/17/2012 01:13 AM, Hebbar, Gururaja wrote:
Hi,
I came across a peculiar issue while updating GPIO debounce registers on
OMAP platform.
According to mainline commit
Matt
On Fri, Oct 12, 2012 at 00:34:33, Porter, Matt wrote:
AM33xx requires special handling in hsmmc initialization
platform glue.
Since AM335x boots mainly through DT, do we still need this patch.
This function will be called in case of initializing hsmmc with
Platform data.
On Sat, Oct 06, 2012 at 02:58:26, Porter, Matt wrote:
On Fri, Oct 05, 2012 at 04:43:56AM +, Hebbar, Gururaja wrote:
Matt,
On Wed, Oct 03, 2012 at 20:30:58, Porter, Matt wrote:
On Fri, Sep 28, 2012 at 03:37:45PM -0400, Matt Porter wrote:
Changes since v1:
- Replaced
Matt,
On Wed, Oct 03, 2012 at 20:30:58, Porter, Matt wrote:
On Fri, Sep 28, 2012 at 03:37:45PM -0400, Matt Porter wrote:
Changes since v1:
- Replaced uio_pruss private SRAM API use with genalloc
- Added DA850 platform device and clock support
- Added DA850 L3 RAM gen_pool
On Thu, Sep 27, 2012 at 16:31:14, Koen Kooi wrote:
Op 26 sep. 2012, om 13:37 heeft Hebbar, Gururaja gururaja.heb...@ti.com
het volgende geschreven:
On Wed, Sep 12, 2012 at 17:32:38, Hebbar, Gururaja wrote:
On Wed, Sep 12, 2012 at 14:19:51, S, Venkatraman wrote:
On Tue, Sep 4, 2012
On Fri, Sep 21, 2012 at 23:52:11, Porter, Matt wrote:
On Fri, Sep 21, 2012 at 08:27:07AM +, Hebbar, Gururaja wrote:
On Thu, Sep 20, 2012 at 20:13:33, Porter, Matt wrote:
This series adds DMA Engine support for AM33xx, which uses
an EDMA DMAC. The EDMA DMAC has been previously
On Wed, Sep 12, 2012 at 17:32:38, Hebbar, Gururaja wrote:
On Wed, Sep 12, 2012 at 14:19:51, S, Venkatraman wrote:
On Tue, Sep 4, 2012 at 6:39 PM, Hebbar, Gururaja gururaja.heb...@ti.com
wrote:
HSMMC IP on AM33xx need a special setting to handle High-speed cards.
Other platforms like
On Fri, Sep 21, 2012 at 23:52:11, Porter, Matt wrote:
On Fri, Sep 21, 2012 at 08:27:07AM +, Hebbar, Gururaja wrote:
On Thu, Sep 20, 2012 at 20:13:33, Porter, Matt wrote:
This series adds DMA Engine support for AM33xx, which uses
an EDMA DMAC. The EDMA DMAC has been previously
On Thu, Sep 20, 2012 at 20:13:34, Porter, Matt wrote:
Move mach-davinci/dma.c to common/edma.c so it can be used
by OMAP (specifically AM33xx atm) 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
On Thu, Sep 20, 2012 at 20:13:34, Porter, Matt wrote:
Move mach-davinci/dma.c to common/edma.c so it can be used
by OMAP (specifically AM33xx atm) 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
On Thu, Sep 20, 2012 at 20:13:33, Porter, Matt wrote:
This series adds DMA Engine support for AM33xx, which uses
an EDMA DMAC. The EDMA DMAC has been previously supported by only
a private API implementation (much like the situation with OMAP
DMA) found on the DaVinci family of SoCs.
There
On Thu, Sep 20, 2012 at 20:13:38, Porter, Matt wrote:
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 | 49
+
1 file changed, 49 insertions(+)
On Thu, Sep 20, 2012 at 20:13:36, Porter, Matt wrote:
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 AM335x.
Signed-off-by: Matt Porter mpor...@ti.com
---
On Fri, Sep 21, 2012 at 14:59:23, Russell King - ARM Linux wrote:
On Thu, Sep 20, 2012 at 10:43:34AM -0400, Matt Porter wrote:
Move mach-davinci/dma.c to common/edma.c so it can be used
by OMAP (specifically AM33xx atm) as well. This just moves
the private EDMA API but does not support
but it does not end up making the
system unusable. Suspend gets aborted and the user can try
suspending the system again.
Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
Signed-off-by: Hebbar, Gururaja gururaja.heb...@ti.com
---
Changes from V1:
- Instead of forcibly returning -EBUSY on err
On Tue, Sep 11, 2012 at 11:13:26, S, Venkatraman wrote:
On Tue, Sep 4, 2012 at 6:38 PM, Hebbar, Gururaja gururaja.heb...@ti.com
wrote:
From: Vaibhav Bedia vaibhav.be...@ti.com
In some cases mmc_suspend_host() is not able to claim the
host and proceed with the suspend process. The core
On Tue, Sep 04, 2012 at 18:39:11, Hebbar, Gururaja wrote:
HSMMC IP on AM33xx need a special setting to handle High-speed cards.
Other platforms like TI81xx, OMAP4 may need this as-well. This depends
on the HSMMC IP timing closure done for the high speed cards.
From AM335x TRM (SPRUH73F
On Tue, Sep 11, 2012 at 11:13:26, S, Venkatraman wrote:
On Tue, Sep 4, 2012 at 6:38 PM, Hebbar, Gururaja gururaja.heb...@ti.com
wrote:
From: Vaibhav Bedia vaibhav.be...@ti.com
In some cases mmc_suspend_host() is not able to claim the
host and proceed with the suspend process. The core
On Wed, Sep 12, 2012 at 14:51:34, Krishnamoorthy, Balaji T wrote:
On Tue, Sep 4, 2012 at 6:39 PM, Hebbar, Gururaja gururaja.heb...@ti.com
wrote:
HSMMC IP on AM33xx need a special setting to handle High-speed cards.
Other platforms like TI81xx, OMAP4 may need this as-well. This depends
On Wed, Sep 12, 2012 at 14:19:51, S, Venkatraman wrote:
On Tue, Sep 4, 2012 at 6:39 PM, Hebbar, Gururaja gururaja.heb...@ti.com
wrote:
HSMMC IP on AM33xx need a special setting to handle High-speed cards.
Other platforms like TI81xx, OMAP4 may need this as-well. This depends
on the HSMMC
. Suspend gets aborted and the user can try
suspending the system again.
Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
Signed-off-by: Hebbar, Gururaja gururaja.heb...@ti.com
---
:100644 100644 9afdd20... c3e96a2... M drivers/mmc/host/omap_hsmmc.c
drivers/mmc/host/omap_hsmmc.c |1 +
1 files
and
- Controller should not be using DDR Mode and
- Controller should advertise that it supports High Speed in
capabilities register and
- MMC/SD clock coming out of controller 25MHz
Signed-off-by: Hebbar, Gururaja gururaja.heb...@ti.com
---
:100644 100644 be76a23... ed271fc... M
Documentation
On Tue, Aug 14, 2012 at 19:48:56, Datta, Shubhrajyoti wrote:
From: Felipe Balbi ba...@ti.com
otherwise we could get our IRQ line disabled due
to many spurious IRQs.
Patch description should be readable by itself. It is not a continuation of
subject line.
Signed-off-by: Felipe Balbi
Ping... any updates please
On Fri, Jul 13, 2012 at 15:25:11, Hebbar, Gururaja wrote:
Hi,
I have started working on Audio support for TI AM335x SOC.
It uses the same McASP IP as in Davinci platform.
The mcasp driver (davinci-pcm) uses SRAM api's.
Currently OMAP Davinci have their own
Hi,
I have started working on Audio support for TI AM335x SOC.
It uses the same McASP IP as in Davinci platform.
The mcasp driver (davinci-pcm) uses SRAM api's.
Currently OMAP Davinci have their own allocation systems, and both with
their own ways of copying functions into the SRAM.
A Patch
Bablpi,
On Wed, Apr 11, 2012 at 17:05:38, Balbi, Felipe wrote:
On Wed, Apr 11, 2012 at 04:42:52PM +0530, Shubhrajyoti D wrote:
Use SET_RUNTIME_PM_OPS macro to set runtime functions.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 11 ---
On Wed, Apr 11, 2012 at 17:40:58, Balbi, Felipe wrote:
On Wed, Apr 11, 2012 at 12:09:22PM +, Hebbar, Gururaja wrote:
Bablpi,
On Wed, Apr 11, 2012 at 17:05:38, Balbi, Felipe wrote:
On Wed, Apr 11, 2012 at 04:42:52PM +0530, Shubhrajyoti D wrote:
Use SET_RUNTIME_PM_OPS macro to set
On Fri, Mar 16, 2012 at 19:09:01, S, Venkatraman wrote:
From: Felipe Balbi ba...@ti.com
a bunch of non-functional cleanups to the omap_hsmmc
driver.
It basically decreases indentation level, drop unneeded
s/unneeded/unneeded. Better to use unnecessary
dereferences and drop unneded
Hi,
I am interested in testing these patches on AM335x. Do you have a tree with
these
patches applied so that I can pull.
On Fri, Feb 10, 2012 at 19:29:55, Datta, Shubhrajyoti wrote:
This patch series colates the various i2c updates into
a series. Since it is collection of various patches
Tarun,
I am interested in testing these patches on AM335x. Do you have a tree with
these
patches applied so that I can pull.
On Thu, Feb 02, 2012 at 23:00:26, DebBarma, Tarun Kanti wrote:
The following changes since commit 62aa2b537c6f5957afd98e29f96897419ed5ebab:
Linus Torvalds (1):
Hi,
On Fri, Feb 03, 2012 at 15:29:49, DebBarma, Tarun Kanti wrote:
On Fri, Feb 3, 2012 at 2:51 PM, Hebbar, Gururaja
gururaja.heb...@ti.com wrote:
Tarun,
I am interested in testing these patches on AM335x. Do you have
a tree with these
patches applied so that I
-info.html
Tested on AM335x platform.
Tested-by: Hebbar, Gururaja gururaja.heb...@ti.com
Regards,
Gururaja
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
95 matches
Mail list logo
