From: Hebbar Gururaja
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
CC: mark.rutl...@arm.com
---
Changes in V4:
- No change.
Changes in V3
[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: omap: update of_device_id to reflect latest ip revisions
arch/arm/boot/dts/am33xx.dtsi |2 +-
drivers/rtc/rtc-omap.c
compatibility.
ex:
compatible = "ti,am3352-rtc", "ti,da830-rtc";
Signed-off-by: Hebbar, Gururaja
CC: mark.rutl...@arm.com
---
Changes in V4:
- Rebased on latest linux-next (as on 160813).
- Correct a type AM335X --> AM3352
Changes in v3:
- ne
From: Hebbar Gururaja
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
CC: mark.rutl...@arm.com
---
Changes in V3:
- Instead of replacing the old
compatibility.
ex:
compatible = "ti,am3352-rtc", "ti,da830-rtc";
Signed-off-by: Hebbar, Gururaja
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 c
ompatible to existing one so that when driver
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: updat
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
---
:100644 100644 77aa1b0... dde180a... M arch/arm/boot/dts/am33xx.dtsi
y are available
to the user else 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: upd
a wakeup source
Signed-off-by: Hebbar Gururaja
Acked-by: Kevin Hilman
Acked-by: Sekhar Nori
Cc: Russell King
---
Changes in V2:
- Coding style corrections (remove extra space)
- use prefix ARM: for commit subject keeping with arch/arm convention
:100644 100644 bf57252
ux.
davincidsp.com/msg26077.html
Signed-off-by: Hebbar Gururaja
Acked-by: Kevin Hilman
Cc: Alessandro Zummo
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/driver
ned-off-by: Hebbar Gururaja
Acked-by: Kevin Hilman
Acked-by: Sekhar Nori
Cc: Grant Likely
Cc: Rob Herring
Cc: Rob Landley
Cc: Alessandro Zummo
Cc: rtc-li...@googlegroups.com
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
---
Changes in V2:
- Coding style corrections
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
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.
> >
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.
> >
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 reg
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 fo
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 bas
On Tue, Jul 02, 2013 at 05:45:01, Kevin Hilman wrote:
> Hebbar Gururaja 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
On Tue, Jul 02, 2013 at 05:37:43, Kevin Hilman wrote:
> Hebbar Gururaja 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 par
ned-off-by: Hebbar Gururaja
Cc: Grant Likely
Cc: Rob Herring
Cc: Rob Landley
Cc: Sekhar Nori
Cc: Kevin Hilman
Cc: Alessandro Zummo
Cc: rtc-li...@googlegroups.com
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
---
:100644 100644 b47aa41... 5a0f02d... M
Documentation/
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
Cc: Tony Lindgren
Cc: Sekhar Nori
Cc: Kevin Hilman
Cc: b-cous...@ti.com
-
ux.
davincidsp.com/msg26077.html
Signed-off-by: Hebbar Gururaja
Cc: Alessandro Zummo
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/rtc-omap.c b/driv
a wakeup source
Signed-off-by: Hebbar Gururaja
Cc: Sekhar Nori
Cc: Kevin Hilman
Cc: Russell King
---
:100644 100644 bf57252... 85a900c... M arch/arm/mach-davinci/devices-da8xx.c
arch/arm/mach-davinci/devices-da8xx.c |9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff
/
[2]
http://www.mail-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: A
On Wed, Jun 26, 2013 at 06:55:01, Fernandes, Joel wrote:
> From: Joel A Fernandes
>
> 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 associated
Bind
On Fri, May 31, 2013 at 23:04:59, Kevin Hilman wrote:
> Hebbar Gururaja 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 perfo
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
On Tue, Jun 04, 2013 at 12:49:57, Linus Walleij wrote:
> On Tue, Jun 4, 2013 at 9:11 AM, Linus Walleij
> wrote:
> > On Fri, May 31, 2013 at 12:13 PM, Hebbar Gururaja
> > wrote:
> >
> >> Amend the hsmmc controller to optionally take a pin control handle and
On Fri, May 31, 2013 at 23:37:02, Kevin Hilman wrote:
> +Linus Walleij (pinctrl maintainer)
>
> Hebbar Gururaja writes:
>
> > Amend the I2C omap pin controller to optionally take a pin control
> > handle and set the state of the pins to:
> >
> > - "defau
ain drops the
domain regulator.
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
Cc: Balaji
f certain pin-states are not available, to remove this warning message
pass respective state name with null phandler.
(Changes based on i2c-nomadik.c)
Signed-off-by: Hebbar Gururaja
Cc: Tony Lindgren
Cc: Wolfram Sang
Cc: linux-omap@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
:100644 1
On Thu, May 23, 2013 at 12:27:41, David Miller wrote:
> From: Mugunthan V N
> Date: Tue, 21 May 2013 15:24:58 +0530
>
> > + priv->pins_default = pinctrl_lookup_state(priv->pinctrl,
> > + PINCTRL_STATE_DEFAULT);
>
> This is not indented correctl
On Fri, May 10, 2013 at 15:26:29, Mark Brown wrote:
> On Tue, May 07, 2013 at 10:47:31AM +0000, 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
> >
On Tue, May 07, 2013 at 14:25:35, Mark Brown wrote:
> On Tue, May 07, 2013 at 03:56:09AM +0000, 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 Pinct
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 plac
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 c
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
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 Guru
register offset at 0x00.
Signed-off-by: Hebbar Gururaja
---
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/cm33xx.c b/arch/arm/mach
struct omap_hwmod records belonging to wkup m3 domain is missing
HWMOD_NO_IDLEST flags; add them.
Signed-off-by: Hebbar Gururaja
---
Change in v2:
- new patch
:100644 100644 646c14d... 1ab693e... M
arch/arm/mach-omap2/omap_hwmod_33xx_data.c
arch/arm/mach-omap2/omap_hwmod_33xx_data.c
On Thu, Jan 31, 2013 at 12:58:36, Koen Kooi wrote:
>
> Op 30 jan. 2013, om 15:39 heeft Hebbar Gururaja het
> volgende geschreven:
>
> > am33xx_cm_wait_module_ready() checks if register offset is NULL.
> >
> > int am33xx_cm_wait_module_ready(u16 inst
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
register offset at 0x00.
Signed-off-by: Hebbar Gururaja
---
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 name
Changes in v2
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
> >
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
> ---
> Documentation/devicetree/bindings/dma/ti-edma.txt | 51
> +
> 1 file changed, 51 insertions(+)
> create
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
> ---
> arch/arm/Kconfig
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"
> >
> > omap4_cminst_wait_module_ready() checks if register offset is NULL.
> >
> > int omap4_cminst_w
From: "Hebbar, Gururaja"
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)
return 0
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"
> >
> > omap4_cminst_wait_module_ready() checks if register offset is NULL.
> >
> >
From: "Hebbar, Gururaja"
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)
return 0
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 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
> >&g
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 wrote:
> > > Hi,
> > >
> > > On Wed, Oct 31, 2012 at 05:27:36PM +0530,
off-by: Hebbar, Gururaja
---
Rebased on mmc-next (v3.7.0-rc1)
Only Build tested since EDMA support for AM335x is not yet added
Changes in V2
- Added note in commit message about code re-use
- replaced ((a & BIT(n) == BIT(n))) with (a & BIT(n)) since
effectively
off-by: Hebbar, Gururaja
---
Rebased on mmc-next (v3.7.0-rc1)
Only Build tested since EDMA support for AM335x is not yet added
Changes in V2
- Added note in commit message about code re-use
- replaced ((a & BIT(n) == BIT(n))) with (a & BIT(n)) since
effectively
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
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
> wrote:
> > Matt,
> >
> > On Wed, Oct 10, 2012 at 20:00:49, Porter, Matt wrote:
> >> 6ea74cb ARM: OMAP2+: hwmod: get rid of all
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 dep
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 d
Bit 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
---
Rebased on mmc-next (v3.7.0-rc1)
Only Build tested since EDMA suppo
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
> ---
> arch/arm/common/edma.c | 63
> ++
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.
>
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 driver
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.
>
> Signed-of
On Sat, Oct 06, 2012 at 02:58:26, Porter, Matt wrote:
> On Fri, Oct 05, 2012 at 04:43:56AM +0000, 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 w
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_
On Thu, Sep 27, 2012 at 16:31:14, Koen Kooi wrote:
>
> Op 26 sep. 2012, om 13:37 heeft "Hebbar, Gururaja"
> 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 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
> > wrote:
> > > HSMMC IP on AM33xx need a special setting to handle High-speed cards.
> > > O
On Fri, Sep 21, 2012 at 23:52:11, Porter, Matt wrote:
> On Fri, Sep 21, 2012 at 08:27:07AM +0000, 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 ED
On Fri, Sep 21, 2012 at 23:52:11, Porter, Matt wrote:
> On Fri, Sep 21, 2012 at 08:27:07AM +0000, 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 ED
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
> ---
> arch/arm/Kconfig
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 suppor
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
> ---
> arch
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
> ---
> Documentation/devicetree/bindings/dma/ti-edma.txt | 49
> +
> 1 file changed, 49 insertions(+)
> create
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.
>
> T
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
> ---
> arch/arm/Kconfig
On Tue, Sep 11, 2012 at 11:13:26, S, Venkatraman wrote:
> On Tue, Sep 4, 2012 at 6:38 PM, Hebbar, Gururaja
> wrote:
> > From: Vaibhav Bedia
> >
> > In some cases mmc_suspend_host() is not able to claim the
> > host and proceed with the suspend process. The core
still fail 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
Signed-off-by: Hebbar, Gururaja
---
Changes from V1:
- Instead of forcibly returning -EBUSY on err, retain old
status
On Wed, Sep 12, 2012 at 14:19:51, S, Venkatraman wrote:
> On Tue, Sep 4, 2012 at 6:39 PM, 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 Wed, Sep 12, 2012 at 14:51:34, Krishnamoorthy, Balaji T wrote:
> On Tue, Sep 4, 2012 at 6:39 PM, 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 Tue, Sep 11, 2012 at 11:13:26, S, Venkatraman wrote:
> On Tue, Sep 4, 2012 at 6:38 PM, Hebbar, Gururaja
> wrote:
> > From: Vaibhav Bedia
> >
> > 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 AM335
Bit 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
---
:100644 100644 be76a23... ed271fc... M
Documentation/devicetree/bi
and the user can try
suspending the system again.
Signed-off-by: Vaibhav Bedia
Signed-off-by: Hebbar, Gururaja
---
:100644 100644 9afdd20... c3e96a2... M drivers/mmc/host/omap_hsmmc.c
drivers/mmc/host/omap_hsmmc.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers
On Tue, Aug 14, 2012 at 19:48:56, Datta, Shubhrajyoti wrote:
> From: Felipe Balbi
>
> 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
> Signed-of
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.
> Cur
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
On Wed, Apr 11, 2012 at 17:40:58, Balbi, Felipe wrote:
> On Wed, Apr 11, 2012 at 12:09:22PM +0000, 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, Shu
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
> > ---
> > drivers/i2c/busses/i2c-omap.c | 11 ---
> > 1 f
On Thu, Mar 22, 2012 at 19:57:16, S, Venkatraman wrote:
> On Thu, Mar 22, 2012 at 6:50 PM, Bedia, Vaibhav wrote:
> > On Thu, Mar 22, 2012 at 09:53:23, Bedia, Vaibhav wrote:
> >> Hi,
> >>
> >> I am trying to do suspend-resume test with a file copy on MMC/SD going on
> >> in the background. The test
On Fri, Mar 16, 2012 at 19:09:01, S, Venkatraman wrote:
> From: Felipe Balbi
>
> 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 accesses to
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
>
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
> wrote:
>
>
> Tarun,
>
> I am interested in testing these patches on AM335x. Do you have
> a tree with these
> 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):
>
(host->base, SYSCTL) | ICE);
> --
> 1.7.1
>
> --
> 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
>
Tested on AM33
Hi all,
I am trying to understand data timeout value (dto) calculation done in omap
hsmmc driver (omap_hsmmc.c)
I summed my understanding & my doubts in below code [GH].
Can someone help me in understanding the code
Thanks in advance.
Regards
Gururaja
static void set_data_timeout(struct om
Hi all,
Hi all,
We are porting existing OMAP HSMMC driver (omap_hsmmc.c) to an upcoming SOC.
The HSMMC IP is same as the one found in DM814x which uses the IP CD pins to
detect MMC card insertion/removal rather than using gpio pins.
When testing the driver with SanDisk 16GB SDHC Card (SanDisk
Hi all,
We are porting existing OMAP HSMMC driver (omap_hsmmc.c) to an upcoming SOC.
When testing the driver with SanDisk 16GB SDHC Card (SanDisk Extreme HD Video
16GB 20Mb/s), we observed that the card doesn't switch to High Speed mode.
The card shows that it is compatible with SDA spec3.
Hi all,
We are porting existing OMAP HSMMC driver (omap_hsmmc.c) to an upcoming SOC.
When testing the driver with SanDisk 16GB SDHC Card (SanDisk Extreme HD Video
16GB 20Mb/s), we observed that the card doesn't switch to High Speed mode.
The card shows that it is compatible with SDA spec3.
100 matches
Mail list logo
