Hi,
On Thursday, May 26, 2011 4:08 PM, Bedia, Vaibhav wrote:
> The call to pwrdm_wait_transition() in clkdm_clk_enable() is
> redundant since the function pwrdm_clkdm_state_switch() which
> is called next also does the same thing.
>
Any comments on this patch? Can it be merg
Hi,
On Thu, Nov 17, 2011 at 21:58:23, Bedia, Vaibhav wrote:
> TI processors in TI81x and AM33x family work with PMICs like
> TPS65910/1 which are not part of the TWL series. These processors
> also do not have a voltage controller/processor module.
>
> In order to invoke the n
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Kristo, Tero
> Sent: Monday, November 28, 2011 8:23 PM
> To: linux-omap@vger.kernel.org
> Cc: sa...@linux.intel.com; broo...@opensource.wolfsonmicro.com;
> Girdwood, Liam;
On Tue, Nov 29, 2011 at 16:49:49, Kristo, Tero wrote:
[...]
> >
> > Other TI PMICs like TPS65910 also have two I2C interfaces. Since
> > the datasheets refers to these as Control (CTL) and SmartReflex (SR)
> > interfaces,
> > instead of the OMAP specific TWL_VP_SMPS_MODE, how about renaming the
Hi Kevin,
On Sat, Dec 03, 2011 at 03:57:57, Hilman, Kevin wrote:
[...]
> >
> > Any comments on this approach?
>
> Sorry, I didn't see this patch before, and I don't see it in the
> linux-omap archives either. Not sure what happened there...
>
> > This enables us to make use of generic regulato
On Tue, Dec 06, 2011 at 00:37:38, Hilman, Kevin wrote:
[...]
> >
> > We want to use the existing OMAP implementation of cpufreq (and DVFS) on
> > the devices which do not have VC/VP.
> >
> > The current OMAP cpufreq code under drivers/ invokes clk_set_rate().
> >
> > We had a look at the future DV
Hello,
On Fri, Nov 11, 2011 at 15:31:52, R, Govindraj wrote:
[...]
>
> - if ((cpu_is_omap34xx() || cpu_is_omap44xx()) && bdata->pads)
> + if (((cpu_is_omap34xx() || cpu_is_omap44xx()) && bdata->pads)
> + && !uart_debug)
> device_init_wakeup(&pdev->dev, t
Hi Govindraj,
On Mon, Jan 02, 2012 at 16:00:37, Govindraj wrote:
>
> currently runtime pm is available from omap-serial device and not from
> tty_dev.
> Setting tty_dev wakeup is to use irq_wakeup from suspend available
> from serail_core layer which I think we are not using for omap-uart
> and
On Tue, Jan 03, 2012 at 16:01:52, Govindraj wrote:
> >
> > I have basic suspend-resume working on it. Strangely this works irrespective
> > of the value of tty_dev wakeup entry. Do you know if this is expected on
> > OMAP?
> >
>
> AFAIK yes.
Ok.
>
> > The other issue concerning runtime PM is t
Hi Paul,
On Fri, Dec 16, 2011 at 03:06:09, Paul Walmsley wrote:
> Hi,
>
> This is a repost of Tero's PRCM chain handler patch set with a few changes:
>
> - A new mux patch has been added to place hwmod mux entries with
> OMAP_DEVICE_PAD_WAKEUP set into the dynamic list
>
> - Several OCP barri
Hi Kevin,
On Tue, Jan 10, 2012 at 06:49:52, Hilman, Kevin wrote:
[...]
> >
> > 1. IO and wakeup events are not supported on AM33XX. Since cpu_is_34xx()
> > holds true for AM33XX I ended up adding a !cpu_is_am33xx() check in
> > omap3xxx_prcm_init() to bypass the chain handler registration.
>
> >
On Tue, Jan 10, 2012 at 20:43:33, Hilman, Kevin wrote:
> "Bedia, Vaibhav" writes:
>
> > Hi Kevin,
> >
> > On Tue, Jan 10, 2012 at 06:49:52, Hilman, Kevin wrote:
> > [...]
> >> >
> >> > 1. IO and wakeup events are not supported on
On Thu, Jan 19, 2012 at 17:16:38, Bedia, Vaibhav wrote:
> The current DPLL code enables and disables autoidle features
> without checking whether the autoidle register is available.
> Fix this by putting a check for the existence of the autoidle
> register in the DPLL data.
>
>
Hi Omar,
On Tue, May 01, 2012 at 23:17:38, Omar Ramirez Luna wrote:
> To allow mailbox driver to function with device tree.
>
> Tested in OMAP4 and OMAP3. OMAP2 untested.
>
I think the mailbox code needs a cleanup similar to what you
had proposed earlier [1] before the device tree support is add
Hi Tero,
On Fri, Apr 20, 2012 at 14:49:49, Kristo, Tero wrote:
> From: Axel Haslam
>
> On OMAP4, there is no support to read previous logic state
> or previous memory state achieved when a power domain transitions
> to RET. Instead there are module level context registers.
>
> In order to suppo
On Wed, May 02, 2012 at 14:50:21, Kristo, Tero wrote:
> On Wed, 2012-05-02 at 10:45 +0200, Bedia, Vaibhav wrote:
> > Hi Tero,
> >
> > On Fri, Apr 20, 2012 at 14:49:49, Kristo, Tero wrote:
> > > From: Axel Haslam
> > >
> > > On OMAP4, there is
Hi Tero,
On Fri, Apr 20, 2012 at 15:03:34, Kristo, Tero wrote:
> From: Rajendra Nayak
>
> SAR/ROM code restores only CORE DPLL to its original state
> post wakeup from OFF mode.
> The rest of the DPLL's in OMAP4 platform (MPU/IVA/ABE/USB/PER)
> are saved and restored here during an OFF transitio
On Wed, May 02, 2012 at 15:48:01, Shilimkar, Santosh wrote:
> On Wed, May 2, 2012 at 3:40 PM, Bedia, Vaibhav wrote:
> > Hi Tero,
> >
> > On Fri, Apr 20, 2012 at 15:03:34, Kristo, Tero wrote:
> >> From: Rajendra Nayak
> >>
> >> SAR/ROM code restore
On Wed, May 02, 2012 at 16:30:26, Shilimkar, Santosh wrote:
[...]
> >> How ?
> >> SRAM is sower memory than DDR so I don't see how it
> >> will reduce latency.
> >>
> >
> > I am just guessing if that's indeed the case ;)
> > Haven't done any measurements to really check if that's indeed the case
On Wed, May 02, 2012 at 17:16:19, Shilimkar, Santosh wrote:
> On Wed, May 2, 2012 at 5:10 PM, Bedia, Vaibhav wrote:
> > On Wed, May 02, 2012 at 16:30:26, Shilimkar, Santosh wrote:
> > [...]
> >
> >> >> How ?
> >> >> SRAM is sower memory than DD
On Wed, May 02, 2012 at 17:17:08, Menon, Nishanth wrote:
> On Wed, May 2, 2012 at 6:40 AM, Bedia, Vaibhav wrote:
> >
> > On Wed, May 02, 2012 at 16:30:26, Shilimkar, Santosh wrote:
> > [...]
> >
> > > >> How ?
> > > >> SRAM is sower m
On Wed, May 02, 2012 at 17:28:17, Shilimkar, Santosh wrote:
> On Wed, May 2, 2012 at 5:25 PM, Bedia, Vaibhav wrote:
> > On Wed, May 02, 2012 at 17:17:08, Menon, Nishanth wrote:
> >> On Wed, May 2, 2012 at 6:40 AM, Bedia, Vaibhav
> >> wrote:
> >> >
On Tue, May 01, 2012 at 21:07:39, Hunter, Jon wrote:
[...]
> > int pwrdm_read_pwrst(struct powerdomain *pwrdm)
> > {
> > - int ret = -EINVAL;
> > + int pwrst, ret = -EINVAL;
> >
> > if (!pwrdm)
> > return -EINVAL;
> >
> > - if (arch_pwrdm && arch_pwrdm->pwrdm_read_pwrst)
On Thu, May 03, 2012 at 05:17:18, Mark A. Greer wrote:
> From: "Mark A. Greer"
>
> The davinci EMAC driver has been incorporated into the am35x
> family of SoC's which is OMAP-based. The incorporation is
> incomplete in that the EMAC cannot unblock the [ARM] core if
> its blocked on a 'wfi' inst
On Thu, May 03, 2012 at 21:39:18, Mark A. Greer wrote:
> On Thu, May 03, 2012 at 10:44:44AM +0000, Bedia, Vaibhav wrote:
> > On Thu, May 03, 2012 at 05:17:18, Mark A. Greer wrote:
> > > From: "Mark A. Greer"
> > >
> > > The davinci EMAC driver has be
On Fri, May 04, 2012 at 00:16:32, Mark A. Greer wrote:
[...]
> >
> > So, if I understood this correctly, it's effectively like blocking a low
> > power
> > state transition (here wfi execution) when EMAC is active?
>
> Assuming "it" is my patch, correct.
>
Recently I was thinking about how to
Hi Kevin,
On Fri, May 04, 2012 at 03:02:16, Hilman, Kevin wrote:
> Ben Hutchings writes:
>
> > On Thu, 2012-05-03 at 19:25 +0000, Bedia, Vaibhav wrote:
> >> On Fri, May 04, 2012 at 00:16:32, Mark A. Greer wrote:
> >> [...]
> >> > >
> >> &g
On Mon, Jan 23, 2012 at 16:43:07, Datta, Shubhrajyoti wrote:
> This patch intends to implement the WDIOC_GETBOOTSTATUS ioctl
> for the omap3 and omap4.
>
Instead of just returning the register content why not parse
the RSTST register value and check if it's really a watchdog
reset or not?
> Sig
Hi Shubhrajyoti,
On Tue, Jan 24, 2012 at 11:40:43, Shubhrajyoti Datta wrote:
> Hi Vaibhav,
>
> On Tue, Jan 24, 2012 at 10:32 AM, Bedia, Vaibhav wrote:
> > On Mon, Jan 23, 2012 at 16:43:07, Datta, Shubhrajyoti wrote:
> >> This patch intends to implement the WDIOC_GETBOOTS
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org
> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Henry Chan
> Sent: Tuesday, February 07, 2012 11:27 PM
> To: linux-omap@vger.kernel.org
> Subject: Incorrect Register Offsets in OMAP Mailbox
>
> Hi,
>
> Looks like the
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org
> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of V, Aneesh
> Sent: Saturday, February 04, 2012 5:46 PM
> To: linux-omap@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org; a...@linux-foundation.org; V, Aneesh
> Subject:
On Thu, Feb 09, 2012 at 19:50:30, V, Aneesh wrote:
> On Thursday 09 February 2012 04:55 PM, Bedia, Vaibhav wrote:
> >> -Original Message-
> >> From: linux-omap-ow...@vger.kernel.org
> >> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of V, Aneesh
&g
On Thu, Feb 09, 2012 at 23:17:10, Tony Lindgren wrote:
> Care to reply with Acked-by/Tested-by so I can queue this into fixes?
>
Acked-by: Vaibhav Bedia
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo i
Hi Tony,
On Fri, Feb 10, 2012 at 06:44:47, Tony Lindgren wrote:
> * Bedia, Vaibhav [120209 09:27]:
> > On Thu, Feb 09, 2012 at 23:17:10, Tony Lindgren wrote:
> > > Care to reply with Acked-by/Tested-by so I can queue this into fixes?
> > >
> >
> > Acked
On Mon, Feb 13, 2012 at 19:54:05, Peter Korsgaard wrote:
> > "Afzal" == Afzal Mohammed writes:
>
> Afzal> From: Vaibhav Bedia
> Afzal> Update SRAM start & size for am33xx SoC's.
>
This is a really awkward quoting style :|
>
> I don't particular know the omap sram stuff, but doesn't the
Hi Benoit,
On Fri, Feb 17, 2012 at 18:51:35, Cousson, Benoit wrote:
> Hi Vaibhav,
>
> On 2/17/2012 1:24 PM, Vaibhav Hiremath wrote:
> > In case of AM33xx family of devices (like cpsw) have different sysc
> > bit field offsets defined,
>
> It is really used by several IPs, or it is just an unique
On Thu, Feb 23, 2012 at 14:23:35, Ohad Ben-Cohen wrote:
[...]
>
> Which happens on CONFIG_ARCH_OMAP2 && !CONFIG_SOC_OMAP2420, due to
> missing omap2_mboxes declaration.
>
[...]
>
> -struct omap_mbox *omap2_mboxes[] = { &mbox_dsp_info, &mbox_iva_info, NULL };
> +#ifdef CONFIG_ARCH_OMAP2
> +struc
Hi,
I am trying to do suspend-resume test with a file copy on MMC/SD going on
in the background. The test involves simply copying a 450MB file on an ext3
partition to the same partition under a different name.
This is on an AM335x board which uses the omap_hsmmc driver.
The kernel is v3.2 and I
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 involves simply copying a 450MB file on an ext3
> partition to the same partition under a different name.
>
On Thu, Mar 22, 2012 at 19:57:16, S, Venkatraman wrote:
[...]
>
> I see (in 3.3) that the host controller driver does a "return ret" and
> that means the errors is propagated.
> Where is the return code lost /overridden ?
>
The return code gets overridden due to the call to host->pdata->resume()
On Thu, Mar 22, 2012 at 21:36:36, S, Venkatraman wrote:
> On Thu, Mar 22, 2012 at 8:13 PM, Bedia, Vaibhav wrote:
> > On Thu, Mar 22, 2012 at 19:57:16, S, Venkatraman wrote:
> > [...]
> >>
> >> I see (in 3.3) that the host controller driver does a "return
+Paul, Benoit and Kevin
On Wed, Jun 27, 2012 at 11:11:32, N, Mugunthan V wrote:
> > -Original Message-
> > From: N, Mugunthan V
> > Sent: Thursday, June 07, 2012 9:52 PM
> > To: 'linux-omap@vger.kernel.org'
> > Cc: 'linux-arm-ker...@lists.infradead.org'
> > Subject: how to specify dma_mask
Hi Paul,
On Thu, Jun 28, 2012 at 21:22:54, Paul Walmsley wrote:
[...]
>
> dma_mask and coherent_dma_mask can be specified during
> device creation. See usb_musb_init() in arch/arm/mach-omap2/usb-musb.c
> for an example.
>
Thanks for pointing this out. Should omap_device_build() start handlin
On Thu, Jun 28, 2012 at 22:02:46, Paul Walmsley wrote:
> On Thu, 28 Jun 2012, Bedia, Vaibhav wrote:
>
> > On Thu, Jun 28, 2012 at 21:22:54, Paul Walmsley wrote:
> > [...]
> > >
> > > dma_mask and coherent_dma_mask can be specified during
> > > devi
Hi Paul,
On Thu, Jun 28, 2012 at 22:02:46, Paul Walmsley wrote:
> On Thu, 28 Jun 2012, Bedia, Vaibhav wrote:
>
> > On Thu, Jun 28, 2012 at 21:22:54, Paul Walmsley wrote:
> > [...]
> > >
> > > dma_mask and coherent_dma_mask can be specified during
> >
Hello,
On Wed, Jul 04, 2012 at 21:24:01, Zumeng Chen wrote:
> Does the following fix make sense?
>
> WDIOC_GETBOOTSTATUS always return 0 even if the machine
> comes from omap-wdt reboot. Because WKUP_MOD is not right
> for OMAP3, so give the right addr 0xA00 of PRM_RSTST for
> get_reset_sources,
Hi Santosh,
On Fri, Jul 06, 2012 at 12:51:03, Shilimkar, Santosh wrote:
[...]
> >
> > A few questions based on the description given in the commit message.
> >
> >> 1. On OMAP4 SYSCLK can't be gated, because of issue with WDTIMER2 module,
> >> which constantly stays in "in transition" state. Value
Hi,
I am looking at adding PM support for AM335x based on l-o/master.
arch/arm/mach-omap2/pm.c has the following comment:
/*
* In the case of DT, the PMIC and SR initialization will be done using
* a completely different mechanism.
* Disable this part if a DT blob is available.
*/
if (of_have
Hi Paul,
On Wed, Jul 18, 2012 at 02:03:04, Paul Walmsley wrote:
> On Tue, 17 Jul 2012, Bedia, Vaibhav wrote:
>
> > I am looking at adding PM support for AM335x based on l-o/master.
> > arch/arm/mach-omap2/pm.c has the following comment:
> >
> > /*
> >
On Wed, Jul 18, 2012 at 21:52:41, Paul Walmsley wrote:
> On Wed, 18 Jul 2012, Bedia, Vaibhav wrote:
>
> > I checked the different inits which get skipped right now. I think
> > _init_voltages()
> > should not really be dependent on the DT check to cover the cases w
On Fri, Jul 20, 2012 at 10:09:43, Nayak, Rajendra wrote:
> On Thursday 19 July 2012 05:38 PM, Vaibhav Bedia wrote:
> > As per the comment in omap2_common_late_init() looks like the
> > original intent of the DT check was to treat only the PMIC
> > and SR initialization differently. Recent changes t
On Fri, Jul 20, 2012 at 10:42:53, Nayak, Rajendra wrote:
> On Friday 20 July 2012 10:31 AM, Bedia, Vaibhav wrote:
> > On Fri, Jul 20, 2012 at 10:09:43, Nayak, Rajendra wrote:
> >> On Thursday 19 July 2012 05:38 PM, Vaibhav Bedia wrote:
> >>> As per the comment in
On Tue, Aug 07, 2012 at 17:41:08, Balbi, Felipe wrote:
> this helps us reduce unnecessary pm transitions
> in case we have another i2c message been started
> soon.
>
s/been started/starting ?
> Signed-off-by: Felipe Balbi
> ---
> drivers/i2c/busses/i2c-omap.c | 9 +++--
> 1 file changed, 7
On Tue, Aug 07, 2012 at 18:08:07, Balbi, Felipe wrote:
> this helps us reduce unnecessary pm transitions
> in case we have another i2c message starting soon.
>
> Signed-off-by: Felipe Balbi
FWIW, Acked-by: Vaibhav Bedia
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" i
Hi Paul,
On Wed, Aug 08, 2012 at 19:35:50, Paul Walmsley wrote:
[...]
> It doesn't seem to me that this would necessarily always be an error.
> Suppose some init code to create cpsw devices is running on an OMAP3430.
> Then a omap_hwmod_for_each_by_class() that doesn't locate anything
> would
Hi Paul,
On Thu, Aug 09, 2012 at 01:49:34, Paul Walmsley wrote:
> Hi Vaibhav
>
> On Wed, 8 Aug 2012, Bedia, Vaibhav wrote:
>
> > On Wed, Aug 08, 2012 at 19:35:50, Paul Walmsley wrote:
> >
> > > It doesn't seem to me that this would necessarily always be an
Hi Paul,
[...]
> > > On Wed, Aug 08, 2012 at 19:35:50, Paul Walmsley wrote:
> > >
> > > > It doesn't seem to me that this would necessarily always be an error.
> > > > Suppose some init code to create cpsw devices is running on an
> > > > OMAP3430.
> > > > Then a omap_hwmod_for_each_by_class
On Thu, Jul 04, 2013 at 21:30:14, Mark Jackson wrote:
> On 04/07/13 16:14, Mark Jackson wrote:
> > On 04/07/13 14:25, Mark Jackson wrote:
> >> Our custom AM335x board has been booting just fine under 3.10.0-rc4.
> >>
> >> I've just done a git pull to update to 3.10 (now that it's released)
> >> and
Hi Tony,
On Fri, Jul 05, 2013 at 17:29:59, Tony Lindgren wrote:
> * Bedia, Vaibhav [130705 01:17]:
> >
> > I just checked the behavior on my AM335x-EVM. Current mainline boots fine
> > provided I don't use earlyprintk. The offending patch [1] in this case is
> &g
On Fri, Jul 05, 2013 at 18:50:10, Bedia, Vaibhav wrote:
> Hi Tony,
>
> On Fri, Jul 05, 2013 at 17:29:59, Tony Lindgren wrote:
> > * Bedia, Vaibhav [130705 01:17]:
> > >
> > > I just checked the behavior on my AM335x-EVM. Current mainline boots fine
> > &
Hi,
Compiling the current linus/master (2ab3f29) using omap2plus_defconfig
throws up the following error
$make -j7 uImage
CHK include/generated/uapi/linux/version.h
CHK include/generated/utsrelease.h
make[1]: `include/generated/mach-types.h' is up to date.
CC arch/arm/kernel/as
On Fri, Oct 26, 2012 at 14:29:28, Shilimkar, Santosh wrote:
> On Friday 26 October 2012 01:18 PM, Bedia, Vaibhav wrote:
> > Hi,
> >
> > Compiling the current linus/master (2ab3f29) using omap2plus_defconfig
> > throws up the following error
> >
> > $make -j7
On Mon, Oct 29, 2012 at 00:49:19, Daniel Mack wrote:
> [Cc Tony]
>
> On 28.10.2012 19:17, Daniel Mack wrote:
> > This patch adds the ability to reboot am33xx-based systems.
>
> Sorry, I lacked to investigate on the attribution here. According to
> "git blame" of a BSP kernel I got these lines fro
On Fri, Nov 02, 2012 at 18:02:46, Bedia, Vaibhav wrote:
[...]
> +int wkup_mbox_msg(struct notifier_block *self, unsigned long len, void *msg)
> +{
> + return 0;
> +}
This should have been static. Will change in the next version.
--
To unsubscribe from this list: send the line
Hi Tony,
On Sat, Nov 03, 2012 at 00:30:04, Tony Lindgren wrote:
[...]
>
> Patches have been posted to move the mailbox related
> files out of arch/arm, so you'll have to update those
> for that. Please see thread "[PATCH 0/2] ARM: OMAP:
> mailbox out of plat code" for more information.
>
Thanks
Hi Russ,
On Sat, Nov 03, 2012 at 05:44:21, Russ Dill wrote:
[...]
> > - if (!cpu_is_omap44xx())
> > + if (!cpu_is_omap44xx() || !soc_is_am33xx())
> > bit = mbox_read_reg(p->irqdisable) & ~bit;
>
> Do you mean &&?
>
I didn't change that line but it looks ok to me :)
Hi Daniel,
On Sat, Nov 03, 2012 at 03:46:53, Daniel Mack wrote:
[...]
>
> What event did you use to bring the system back to life? I tried a GPIO
> button which has "linux,wakeup" set and is connected to GPIO bank 0, but
> without success.
I used uart wakeup in my testing. I see that you have CP
Hi Kevin,
On Sat, Nov 03, 2012 at 17:13:54, Kevin Hilman wrote:
> On 11/02/2012 01:32 PM, Vaibhav Bedia wrote:
> > AM33XX has only one usable timer in the WKUP domain.
> > Currently the timer instance in WKUP domain is used
> > as the clockevent and the timer in non-WKUP domain
> > as the clocksou
On Sat, Nov 03, 2012 at 17:45:03, Kevin Hilman wrote:
> On 11/02/2012 01:32 PM, Vaibhav Bedia wrote:
> > From: Vaibhav Hiremath
> >
> > The current OMAP timer code registers two timers -
> > one as clocksource and one as clockevent.
> > AM33XX has only one usable timer in the WKUP domain
> > so on
On Sat, Nov 03, 2012 at 17:46:06, Kevin Hilman wrote:
> On 11/02/2012 01:32 PM, Vaibhav Bedia wrote:
> > Signed-off-by: Vaibhav Bedia
>
> Even simple patches need a simple changelog.
Again, sorry about this. Will take care in the future.
Regards,
Vaibhav
--
To unsubscribe from this list: sen
On Sat, Nov 03, 2012 at 17:50:25, Kevin Hilman wrote:
> On 11/02/2012 01:32 PM, Vaibhav Bedia wrote:
> > AM33XX PM code depends on Mailbox module for IPC
> > between MPU and WKUP_M3.
>
> OK, but what if I try to build for AM33xx without starting from
> omap2plus_defconfig?
I honestly didn't thin
On Sat, Nov 03, 2012 at 14:06:38, Bedia, Vaibhav wrote:
> Hi Russ,
>
> On Sat, Nov 03, 2012 at 05:44:21, Russ Dill wrote:
> [...]
> > > - if (!cpu_is_omap44xx())
> > > + if (!cpu_is_omap44xx() || !soc_is_am33xx())
> > > bi
On Sat, Nov 03, 2012 at 18:34:30, Kevin Hilman wrote:
[...]
> >>
> >> Doesn't this also mean that you won't get timer wakeups
> >> in idle? Or are you keeping the domain where the clockevent is
> >> on during idle?
> >>
> >
> > The lowest idle state that we are targeting will have MPU powered
> >
On Sat, Nov 03, 2012 at 19:11:54, Kevin Hilman wrote:
[...]
>
> Yes, please try with that. Won't that be necessary anyways for situations
> where the powerdomain goes off?
>
Yes, we probably got lucky with the minimal resume routine.
Regards,
Vaibhav
--
To unsubscribe from this list: send th
Hi Santosh,
On Sat, Nov 03, 2012 at 21:22:04, Shilimkar, Santosh wrote:
> On Friday 02 November 2012 06:02 PM, Vaibhav Bedia wrote:
> > From: Vaibhav Hiremath
> >
> > The current OMAP timer code registers two timers -
> > one as clocksource and one as clockevent.
> Actually OMAP also uses only on
On Sat, Nov 03, 2012 at 21:24:14, Shilimkar, Santosh wrote:
> On Friday 02 November 2012 06:02 PM, Vaibhav Bedia wrote:
> > Signed-off-by: Vaibhav Bedia
> > ---
> > arch/arm/boot/dts/am33xx.dtsi | 11 +++
> > 1 files changed, 11 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/
On Sat, Nov 03, 2012 at 21:33:47, Shilimkar, Santosh wrote:
[...]
> > +static int omap2_mbox_fifo_needs_flush(struct omap_mbox *mbox)
> > +{
> > + struct omap_mbox2_fifo *fifo =
> > + &((struct omap_mbox2_priv *)mbox->priv)->tx_fifo;
> type casting is generally avoided in linux code.
On Sat, Nov 03, 2012 at 21:40:37, Shilimkar, Santosh wrote:
[...]
> > +#if defined(CONFIG_SOC_AM33XX)
> > + else if (soc_is_am33xx()) {
> > + list = am33xx_mboxes;
> > +
> > + list[0]->irq = platform_get_irq(pdev, 0);
> > + }
> > +#endif
> #ifdef in middle of the function l
On Sat, Nov 03, 2012 at 21:46:46, Shilimkar, Santosh wrote:
> On Friday 02 November 2012 06:02 PM, Vaibhav Bedia wrote:
> > The hwmod data for OCMCRAM in AM33XX was commented out.
> > This data is needed by the power management code, hence
> > uncomment the same and register the OCP interface for i
On Sat, Nov 03, 2012 at 21:45:29, Shilimkar, Santosh wrote:
[...]
> >
> You are adding reset bit in this patch but using it in 4/15. Probably
> you can re-order it to keep git bisect happy.
>
Ok. Will reorder.
Regards,
Vaibhav
--
To unsubscribe from this list: send the line "unsubscribe linux-
On Sat, Nov 03, 2012 at 21:48:48, Shilimkar, Santosh wrote:
> On Friday 02 November 2012 06:02 PM, Vaibhav Bedia wrote:
> > The first entry for CPGMAC0 should be ADDR_MAP_ON_INIT
> > instead of ADDR_TYPE_RT to ensure the omap hwmod code
> > maps the memory space at init and writes to the SYSCONFIG
On Sat, Nov 03, 2012 at 21:59:55, Shilimkar, Santosh wrote:
> On Friday 02 November 2012 06:02 PM, Vaibhav Bedia wrote:
> > Get rid of some unnecessary header file inclusions
> > and also use __ASSEMBLER__ macros to allow the
> > various register offsets from PM assembly code
> > which be added in
On Sat, Nov 03, 2012 at 22:01:46, Shilimkar, Santosh wrote:
> >
> As mentioned on other patch comment, I think this might break your
> SOC idle.
>
Unfortunately we don't have SOC idle.
Regards,
Vaibhav
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a me
On Sat, Nov 03, 2012 at 22:27:19, Shilimkar, Santosh wrote:
[...]
> >
> Nice descriptive change log Vaibhav.
Thanks :)
>
[...]
> > +#include "soc.h"
> > +
> In case not checked yet, see if you need
> all above headers.
>
Will double-check, I know it's a long list of includes.
> > +void (*am
Hi Kevin,
On Sat, Nov 03, 2012 at 21:52:00, Kevin Hilman wrote:
> On 11/02/2012 12:32 PM, Vaibhav Bedia wrote:
> > AM33XX has only one usable timer in the WKUP domain.
>
> After reading the TRM, it seems there are two: DMTIMER0 and DMTIMER1.
>
> Looking at the hwmod data though, I don't see a hw
On Sun, Nov 04, 2012 at 20:54:17, Bedia, Vaibhav wrote:
> On Sat, Nov 03, 2012 at 21:48:48, Shilimkar, Santosh wrote:
> > On Friday 02 November 2012 06:02 PM, Vaibhav Bedia wrote:
> > > The first entry for CPGMAC0 should be ADDR_MAP_ON_INIT
> > > instead of ADDR_TYPE_
On Mon, Nov 05, 2012 at 12:53:59, Hiremath, Vaibhav wrote:
>
> Can you cut-n-paste the ocmcram hwmod entry outside of #if and resubmit
> it again?
>
Ok. Will do that in the next version.
Regards,
Vaibhav
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a
On Mon, Nov 05, 2012 at 20:23:11, Shilimkar, Santosh wrote:
[...]
> >
> On OMAP the OCMC RAM is always clocked and doesn't need any special
> clock enable. CM_L3_2_OCMC_RAM_CLKCTRL module mode field is read only.
> Isn't it same on AMXX ?
>
On AM33xx, OCMC RAM is in PER domain and the correspondi
On Mon, Nov 05, 2012 at 12:28:36, Hiremath, Vaibhav wrote:
[...]
> > - u32 mask = 1 << shift;
> > -
> > - /* Check the current status to avoid de-asserting the line twice */
> > - if (am33xx_prm_is_hardreset_asserted(shift, inst, rstctrl_offs) == 0)
> > - return -EEXIST;
>
> Any s
On Tue, Nov 06, 2012 at 03:15:10, Shilimkar, Santosh wrote:
> On Tuesday 06 November 2012 02:49 AM, Santosh Shilimkar wrote:
> > On Tuesday 06 November 2012 12:59 AM, Kevin Hilman wrote:
> >> "Bedia, Vaibhav" writes:
> >>
> >>> On Mon, N
On Mon, Nov 05, 2012 at 15:12:27, AnilKumar, Chimata wrote:
[...]
>
> +#define SHUTDOWN_TIME_SEC2
> +#define SECS_IN_MIN 60
> +#define WAIT_AFTER (SECS_IN_MIN - SHUTDOWN_TIME_SEC)
> +#define WAIT_TIME_MS (SHUTDOWN_TIME_SEC * 1000)
> +
On Mon, Nov 05, 2012 at 14:42:22, Philip, Avinash wrote:
[...]
> +pwmss0: pwmss@4830 {
> + compatible = "ti,am33xx-pwmss";
> + reg = <0x4830 0x10
> + 0x48300100 0x80
> + 0x48300180 0x80
> + 0x48300200 0x80>;
Do you really need the 4 address ranges
On Mon, Nov 05, 2012 at 14:42:29, Philip, Avinash wrote:
[...]
> + am33xx_pinmux: pinmux@44e10800 {
> + ecap0_pins: backlight_pins {
> + pinctrl-single,pins = <
> + 0x164 0x0 /*
> eCAP0_in_PWM0_out.eCAP0_in_PWM0_out MODE0 */
>
On Mon, Nov 05, 2012 at 14:42:27, Philip, Avinash wrote:
[...]
> + /* Some platforms require explicit tbclk gating */
> + if (of_property_read_bool(pdev->dev.of_node, "tbclkgating")) {
> + pc->tbclk = clk_get(&pdev->dev, "tbclk");
> + if (IS_ERR(pc->tbclk)) {
> +
On Mon, Nov 05, 2012 at 14:42:26, Philip, Avinash wrote:
[...]
> +#include
> +#include
Pinctrl changes should be separate patch. Morevoer, you don't mention
that you making this change.
> +
> +#include "tipwmss.h"
>
> /* EHRPWM registers and bits definitions */
>
> @@ -107,6 +111,10 @@
>
On Tue, Nov 06, 2012 at 11:36:20, Hiremath, Vaibhav wrote:
[...]
>
> The code is checking whether the line is already de-asserted (== 0), so I am
> not sure how this will change if hardreset line is asserted during bootup.
You are right. I just checked the behavior since I recall seeing somethi
Hi Jon,
On Tue, Nov 06, 2012 at 02:34:05, Hunter, Jon wrote:
[...]
> > static struct clock_event_device clockevent_gpt = {
> > .name = "gp_timer",
> > .features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
> > @@ -142,6 +171,8 @@ static struct clock_event_device clo
Hi Jon,
On Tue, Nov 06, 2012 at 02:50:50, Hunter, Jon wrote:
[...]
>
> Why is this? How is the dmtimer TIOCP_CFG register configured on AM33xx?
> Is it using smart-idle?
>
Yes, it is set to smart-idle with wakeup capable mode. (this needs a fixup
since this timer is not wakeup capable) but unfo
On Tue, Nov 06, 2012 at 13:42:21, N, Mugunthan V wrote:
[...]
> +struct omap_hwmod_addr_space am33xx_mdio_addr_space[] = {
> + {
> + .pa_start = 0x4A101000,
> + .pa_end = 0x4A101000 + SZ_256 - 1,
> + .flags = ADDR_MAP_ON_INIT,
Based on
On Mon, Nov 05, 2012 at 14:42:24, Philip, Avinash wrote:
[...]
> +
> +static struct omap_hwmod_ocp_if am33xx_epwmss0__ecap0 = {
> + .master = &am33xx_epwmss0_hwmod,
> + .slave = &am33xx_ecap0_hwmod,
> + .clk= "l4ls_gclk",
> + .addr = am33xx_ec
1 - 100 of 185 matches
Mail list logo
