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 normal regulator calls
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, which
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 of register
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
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:
/*
* In the case of DT, the PMIC and SR initialization
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 wherein
the voltages
are controlled
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 to
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 omap2_common_late_init() looks like
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 ba...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 9 +++--
1 file
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 ba...@ti.com
FWIW, Acked-by: Vaibhav Bedia vaibhav.be...@ti.com
--
To unsubscribe from this list: send the
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
wouldn't
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 error.
Suppose some init code to create cpsw
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
On Thu, Sep 06, 2012 at 09:26:07, Hiremath, Vaibhav wrote:
On 9/6/2012 4:48 AM, Tony Lindgren wrote:
Hi,
* AnilKumar Ch anilku...@ti.com [120905 04:14]:
Add of_dev_auxdata to pass d_can raminit callback APIs to initialize
d_can RAM. D_CAN RAM initialization bits are present in
Hi Matt,
On Thu, Oct 18, 2012 at 18:56:39, Porter, Matt wrote:
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
-
On Fri, Oct 19, 2012 at 16:45:58, Porter, Matt wrote:
On Fri, Oct 19, 2012 at 10:26:20AM +, Bedia, Vaibhav wrote:
[...]
I didn't see all the patches that you posted on edma-dmaengine-v3
but I do seem them on edma-dmaengine-am33xx-v3 branch.
I see I referenced the wrong branch
On Fri, Oct 19, 2012 at 22:16:15, Porter, Matt wrote:
On Fri, Oct 19, 2012 at 12:02:42PM +, Bedia, Vaibhav wrote:
On Fri, Oct 19, 2012 at 16:45:58, Porter, Matt wrote:
On Fri, Oct 19, 2012 at 10:26:20AM +, Bedia, Vaibhav wrote:
[...]
I didn't see all the patches that you
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
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 uImage
CHK include/generated/uapi/linux
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 from, the
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 unsubscribe linux
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 for
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 :)
Regards,
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 CPSW
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 clocksource. The
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 hvaib...@ti.com
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 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 vaibhav.be...@ti.com
Even simple patches need a simple changelog.
Again, sorry about this. Will take care in the future.
Regards,
Vaibhav
--
To unsubscribe
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 think about
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())
bit = mbox_read_reg(p-irqdisable) ~bit;
Do you mean
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
off with external
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 the
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 hvaib...@ti.com
The current OMAP timer code registers two timers -
one as clocksource and one as clockevent.
Actually OMAP also uses
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 vaibhav.be...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git
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.
I was just
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 looks really
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 it.
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-omap
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 a
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 message
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
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 hwmod
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_RT to ensure the omap hwmod code
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 corresponding
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 specific
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 vaibhav.be...@ti.com writes:
On Mon, Nov 05, 2012 at 20:23:11, Shilimkar, Santosh wrote
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 here?
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 linux/of_device.h
+#include linux/pinctrl/consumer.h
Pinctrl changes should be separate patch. Morevoer, you don't mention
that you making this change.
+
+#include tipwmss.h
/* EHRPWM registers and bits
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 something
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
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
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 the
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 =
On Tue, Nov 06, 2012 at 14:59:45, Hiremath, Vaibhav wrote:
[...]
Ok I checked this one. The change I made was indirectly fixing another
issue with the AM33xx hwmod data. am33xx_cpgmac0_addr_space[] has two
entries and the SYSC register is part of the second entry. The function
Hi Kevin,
On Mon, Nov 05, 2012 at 23:10:27, Kevin Hilman wrote:
[...]
First, some general comments. This is a big patch and probably should
be broken up a bit. I suspect it could be broken up a bit, maybe into
at least:
- EMIF interface
- SCM interface, new APIs
- assembly/OCM code
-
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 axelhas...@gmail.com
On OMAP4, there is no support to read previous logic state
Hi Tero,
On Fri, Apr 20, 2012 at 15:03:34, Kristo, Tero wrote:
From: Rajendra Nayak rna...@ti.com
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
On Wed, May 02, 2012 at 15:48:01, Shilimkar, Santosh wrote:
On Wed, May 2, 2012 at 3:40 PM, Bedia, Vaibhav vaibhav.be...@ti.com wrote:
Hi Tero,
On Fri, Apr 20, 2012 at 15:03:34, Kristo, Tero wrote:
From: Rajendra Nayak rna...@ti.com
SAR/ROM code restores only CORE DPLL to its original
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
though.
You
On Wed, May 02, 2012 at 17:16:19, Shilimkar, Santosh wrote:
On Wed, May 2, 2012 at 5:10 PM, Bedia, Vaibhav vaibhav.be...@ti.com wrote:
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
On Wed, May 02, 2012 at 17:17:08, Menon, Nishanth wrote:
On Wed, May 2, 2012 at 6:40 AM, Bedia, Vaibhav vaibhav.be...@ti.com wrote:
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
On Wed, May 02, 2012 at 17:28:17, Shilimkar, Santosh wrote:
On Wed, May 2, 2012 at 5:25 PM, Bedia, Vaibhav vaibhav.be...@ti.com wrote:
On Wed, May 02, 2012 at 17:17:08, Menon, Nishanth wrote:
On Wed, May 2, 2012 at 6:40 AM, Bedia, Vaibhav vaibhav.be...@ti.com
wrote:
On Wed, May 02
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)
+ if
On Thu, May 03, 2012 at 05:17:18, Mark A. Greer wrote:
From: Mark A. Greer mgr...@animalcreek.com
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 Thu, May 03, 2012 at 21:39:18, Mark A. Greer wrote:
On Thu, May 03, 2012 at 10:44:44AM +, Bedia, Vaibhav wrote:
On Thu, May 03, 2012 at 05:17:18, Mark A. Greer wrote:
From: Mark A. Greer mgr...@animalcreek.com
The davinci EMAC driver has been incorporated into the am35x
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 get certain
Hi Kevin,
On Fri, May 04, 2012 at 03:02:16, Hilman, Kevin wrote:
Ben Hutchings bhutchi...@solarflare.com writes:
On Thu, 2012-05-03 at 19:25 +, Bedia, Vaibhav wrote:
On Fri, May 04, 2012 at 00:16:32, Mark A. Greer wrote:
[...]
So, if I understood this correctly, it's
+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 and
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 handling
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
device creation. See usb_musb_init() in arch/arm/mach-omap2/usb
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
device creation. See usb_musb_init() in arch/arm/mach
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 merged?
Regards,
Vaibhav
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.
This is on an AM335x
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()
which
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 added.
Hi Tero,
On Fri, Apr 20, 2012 at 14:49:49, Kristo, Tero wrote:
From: Axel Haslam axelhas...@gmail.com
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
-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 flag
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 regulators calls
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 DVFS
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, true);
}
I
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 we
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 that as soon as
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 barriers
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.
Without
On Tue, Jan 10, 2012 at 20:43:33, Hilman, Kevin wrote:
Bedia, Vaibhav vaibhav.be...@ti.com writes:
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
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.
With such a check
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?
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 vaibhav.be...@ti.com wrote:
On Mon, Jan 23, 2012 at 16:43:07, Datta, Shubhrajyoti wrote:
This patch intends to implement the WDIOC_GETBOOTSTATUS ioctl
-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 register
-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: [RFC
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
Sent: Saturday, February 04, 2012 5:46 PM
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 vaibhav.be...@ti.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
Hi Tony,
On Fri, Feb 10, 2012 at 06:44:47, Tony Lindgren wrote:
* Bedia, Vaibhav vaibhav.be...@ti.com [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-by: Vaibhav Bedia vaibhav.be
On Mon, Feb 13, 2012 at 19:54:05, Peter Korsgaard wrote:
Afzal == Afzal Mohammed af...@ti.com writes:
Afzal From: Vaibhav Bedia vaibhav.be...@ti.com
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,
1 - 100 of 184 matches
Mail list logo
