On Fri, Jun 18, 2010 at 1:57 AM, Andrew Morton
wrote:
> On Thu, 17 Jun 2010 20:57:19 +0530 (IST)
> "kishore kadiyala" wrote:
>
>> Adding card detect callback function which gives the status of
>> the card .For MMC1 Controller, Card detect interrupt source is
>> twl6030 and card present/absent sta
On Fri, 2010-06-18 at 18:57 +0200, ext Aguirre, Sergio wrote:
> Senthil,
>
> > -Original Message-
> > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> > ow...@vger.kernel.org] On Behalf Of Koen Kooi
> > Sent: Monday, May 10, 2010 3:03 AM
> > To: Guruswamy, Senthilvadivu
> > Cc:
> -Original Message-
> From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com]
> Sent: Monday, June 21, 2010 2:08 PM
> To: Aguirre, Sergio
> Cc: Koen Kooi; Guruswamy, Senthilvadivu;
> linux-omap@vger.kernel.org;
> linux-fbdev-de...@lists.sourceforge.net; t...@atomide.com;
> Hiremath,
On Thu, 2010-06-17 at 14:45 +0200, ext Guruswamy Senthilvadivu wrote:
> From: Senthilvadivu Guruswamy
>
> config VRFB should depend on ARCH_OMAP2 or ARCH_OMAP3.
>
> Signed-off-by: Senthilvadivu Guruswamy
> ---
> drivers/video/omap2/Kconfig|4
> drivers/video/omap2/omapfb/K
> -Original Message-
> From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com]
> Sent: Monday, June 21, 2010 2:21 PM
> To: Guruswamy, Senthilvadivu
> Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org; t...@atomide.com;
> Hiremath, Vaibhav
> Subject: Re: [PATCH v3 2/3] OMAP: DSS2: OMA
> -Original Message-
> From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com]
> Sent: Monday, June 21, 2010 2:21 PM
> To: Guruswamy, Senthilvadivu
> Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org;
> t...@atomide.com; Hiremath, Vaibhav
> Subject: Re: [PATCH v3 2/3] OMAP: DSS2
> -Original Message-
> From: Hiremath, Vaibhav
> Sent: Monday, June 21, 2010 2:27 PM
> To: Tomi Valkeinen; Guruswamy, Senthilvadivu
> Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org;
> t...@atomide.com
> Subject: RE: [PATCH v3 2/3] OMAP: DSS2: OMAPFB: make VRFB
> depends on
Generation of 1ms granular GPTIMER events using 32KHz or system
clocks as inputs does not have whole number count value to load
into the register. This inaccurate count value with respect to 1ms
period leads to time drift subsequently. OMAP3 and later silicons
have dedicated registers for GPTIMER1,
NAK - my prev comments are not fixed here either.
On 06/21/2010 03:23 PM, Tarun Kanti DebBarma wrote:
Generation of 1ms granular GPTIMER events using 32KHz or system
clocks as inputs does not have whole number count value to load
into the register. This inaccurate count value with respect to 1ms
> -Original Message-
> From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
> Sent: Friday, June 18, 2010 1:54 AM
> To: Varadarajan, Charulatha
> Cc: davi...@pacbell.net; broo...@opensource.wolfsonmicro.com;
> a...@linux-foundation.org; linux-omap@vger.kernel.org;
> p...@pwsan.com;
In the case of a dispc framedone timeout, we should set the LCD_EN
bit in DISPC_CONTROL to 0 and reset the dsi tx fifo so that the next
panel update call goes through cleanly.
With the new way of handling dispc framedone interrupts, since everything
is handled in irq context, the only reason a dis
On Mon, 2010-06-21 at 11:17 +0200, ext Guruswamy, Senthilvadivu wrote:
> > This is second patch set marked as v3. Please update the version for
> > every patch set.
> [Senthil] With this comment the patch would really become v3.
> Do you mean to say that the 1/3 should be of v1, and 2/3 of v3 a
Nishant,
> -Original Message-
> From: Nishanth Menon [mailto:menon.nisha...@gmail.com]
> Sent: Monday, June 21, 2010 4:15 PM
> To: DebBarma, Tarun Kanti
> Cc: linux-omap@vger.kernel.org; R, Sricharan
> Subject: Re: [PATCH v2] OMAP:GPTIMER:1ms tick generation correction
>
> NAK - my prev c
DebBarma, Tarun Kanti had written, on 06/21/2010 07:51 AM, the following:
Nishant,
-Original Message-
From: Nishanth Menon [mailto:menon.nisha...@gmail.com]
Sent: Monday, June 21, 2010 4:15 PM
To: DebBarma, Tarun Kanti
Cc: linux-omap@vger.kernel.org; R, Sricharan
Subject: Re: [PATCH v2]
> -Original Message-
> From: Menon, Nishanth
> Sent: Monday, June 21, 2010 6:27 PM
> To: DebBarma, Tarun Kanti
> Cc: linux-omap@vger.kernel.org; R, Sricharan
> Subject: Re: [PATCH v2] OMAP:GPTIMER:1ms tick generation correction
>
> DebBarma, Tarun Kanti had written, on 06/21/2010 07:51 AM
DebBarma, Tarun Kanti had written, on 06/21/2010 08:19 AM, the following:
[...]
---
arch/arm/plat-omap/dmtimer.c | 131
+
arch/arm/plat-omap/include/plat/dmtimer.h |1 +
2 files changed, 96 insertions(+), 36 deletions(-)
diff --git a/arch/arm/p
> -Original Message-
> From: Menon, Nishanth
> Sent: Monday, June 21, 2010 6:56 PM
> To: DebBarma, Tarun Kanti
> Cc: linux-omap@vger.kernel.org; R, Sricharan
> Subject: Re: [PATCH v2] OMAP:GPTIMER:1ms tick generation correction
>
> DebBarma, Tarun Kanti had written, on 06/21/2010 08:19 AM
(CC Tomi)
On Thu, Jun 17, 2010 at 12:43 AM, Zygo Blaxell
wrote:
> The TRM and the OMAP FB driver have different ideas about the widths
> of various bit fields in the DISPC_TIMING_{H,V} registers. This patch
> is based on what the TRM (TI document SPRUF98G) says.
>
> Note: this patch changes the
when sending DSS patches, CC Tomi and fbdev.
On Thu, Jun 17, 2010 at 8:12 AM, Nagarajan, Rajkumar wrote:
>
> When switching between clocks, The new functional clock is
> effective when the next vertical blanking interval occurs.
> GOLCD bit has to be set for the new clock to take effect.
>
> Sign
Hi all,
Here is an updated version of the earlier patch for the TLS [1], and a related
patch for VFPv3 and NEON. Sorry it took a while before I got around updating
this patch.
This series allows booting ARMv6 and 7 with the same kernel binary, such as
omap24xx (ARMv6), omap34xx (ARMv7) and omap44
The TLS register is only available on ARM1136 r1p0 and later.
Set HWCAP_TLS flags if hardware TLS is available.
Note that we now use 0x0ff4 for flagging software TLS to
__kuser_get_tls, and 0x0ff8 for storing the software TLS value.
Signed-off-by: Tony Lindgren
---
arch/arm/include/asm/
MVFR0 and MVFR1 are only available starting with ARM1136 r1p0 release
according to "B.5 VFP changes" in DDI0211F_arm1136_r1p0_trm.pdf. This is
also when TLS register got added, so we can use HAS_TLS also to test for
MVFR0 and MVFR1.
Otherwise VFPFMRX and VFPFMXR access fails and we get:
Internal
Doesn't the generic clock code have logic
to handle such rounding issues? I'm pretty
sure I remember dealing with that issue for
32K timers on AT91 processors. If so that
means the setup is done wrong, and is fixable.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
David,
> -Original Message-
> From: David Brownell [mailto:davi...@pacbell.net]
> Sent: Monday, June 21, 2010 7:51 PM
> To: DebBarma, Tarun Kanti; Nishanth Menon
> Cc: linux-omap@vger.kernel.org; R, Sricharan
> Subject: Re: [PATCH v2] OMAP:GPTIMER:1ms tick generation correction
>
> Doesn'
Anand Gadiyar writes:
> We need to wait on the IDLEST bit after the clocks are enabled
> before attempting to access any register.
>
> Currently, the USBTLL i-clock ops uses the clkops_omap2_dflt_wait,
> while the USBTLL f-clock ops uses clkops_omap2_dflt. If the
> i-clock is enabled first, the c
On Tue, 1 Jun 2010, Kevin Hilman wrote:
> "Nayak, Rajendra" writes:
>
> [...]
>
> >> diff --git a/arch/arm/mach-omap2/pm_bus.c
> >> b/arch/arm/mach-omap2/pm_bus.c
> >> index 69acaa5..3787da8 100644
> >> --- a/arch/arm/mach-omap2/pm_bus.c
> >> +++ b/arch/arm/mach-omap2/pm_bus.c
> >> @@ -70,3 +7
> -Original Message-
> From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
> Sent: Thursday, June 17, 2010 10:05 PM
> To: Varadarajan, Charulatha
> Cc: Cousson, Benoit; t...@atomide.com; davi...@pacbell.net;
> broo...@opensource.wolfsonmicro.com;
> a...@linux-foundation.org; linux
Tarun Kanti DebBarma writes:
> Generation of 1ms granular GPTIMER events using 32KHz or system
> clocks as inputs does not have whole number count value to load
> into the register. This inaccurate count value with respect to 1ms
> period leads to time drift subsequently. OMAP3 and later silicons
> [snip]
>
>
> > +static inline int init_gpio_info(struct platform_device *pdev)
> > +{
> > + gpio_bank = kzalloc(gpio_bank_count * sizeof(struct gpio_bank),
> > + GFP_KERNEL);
>
> This is the real issue with the gpio_bank_count.
>
> You are creating a globa
Paul Walmsley writes:
> On Tue, 1 Jun 2010, Kevin Hilman wrote:
>
>> "Nayak, Rajendra" writes:
>>
>> [...]
>>
>> >> diff --git a/arch/arm/mach-omap2/pm_bus.c
>> >> b/arch/arm/mach-omap2/pm_bus.c
>> >> index 69acaa5..3787da8 100644
>> >> --- a/arch/arm/mach-omap2/pm_bus.c
>> >> +++ b/arch/arm/
Hey there,
I am seeing some discrepancies between the Overo (I believe I have a
Water) and the Beagleboard (I have a Rev. B5) when resuming after a
suspend to RAM.
The setup: My kernel is built from the latest commit (commit ID
305f453e897e4673dd4c2b52ec7e2c4be2e2b035 [1]) of the branch named pm
Peter Tseng writes:
> I am seeing some discrepancies between the Overo (I believe I have a
> Water) and the Beagleboard (I have a Rev. B5) when resuming after a
> suspend to RAM.
Not that it is much comfort, but I have the same problem on Overo but
don't see it on any other OMAP3 board.
I have
kishore kadiyala wrote:
Adding card detect callback function which gives the status of
the card .For MMC1 Controller, Card detect interrupt source is
twl6030 and card present/absent status is provided by MMCCTRL
register of twl6030.
Signed-off-by: Kishore Kadiyala
---
arch/arm/mach-omap2/board
>From f9f553588f8e3bf391bab72e59ee2593ee5f5f9b Mon Sep 17 00:00:00 2001
From: armando uribe
Date: Wed, 16 Jun 2010 20:15:04 -0500
Subject: [PATCH] DSPBRIDGE: decrease message pending in case of timeout
In the function bridge_msg_put() the pending message counter was not being
drecreased in case
On Mon, Jun 21, 2010 at 04:34:33PM +0300, Grazvydas Ignotas wrote:
> (CC Tomi)
>
> On Thu, Jun 17, 2010 at 12:43 AM, Zygo Blaxell
> wrote:
> > The TRM and the OMAP FB driver have different ideas about the widths
> > of various bit fields in the DISPC_TIMING_{H,V} registers. This patch
> > is bas
On Mon, 21 Jun 2010, Kevin Hilman wrote:
> Paul Walmsley writes:
>
> > As far as I can tell, it's not safe for upper-layer code to idle a device
> > like this. The driver itself needs to be aware of the device's idle
> > state.
>
> The driver is made aware using the standard dev_pm_ops cal
On Sat, 19 Jun 2010, Gadiyar, Anand wrote:
> Gadiyar, Anand wrote:
> > We need to wait on the IDLEST bit after the clocks are enabled
> > before attempting to access any register.
> >
> > Currently, the USBTLL i-clock ops uses the clkops_omap2_dflt_wait,
> > while the USBTLL f-clock ops uses clko
Remove unnecessary volatile variables; use accessor
functions __raw_readl/__raw_writel instead when applicable.
Signed-off-by: Ernesto Ramos
---
drivers/dsp/bridge/core/tiomap3430.c |8
drivers/dsp/bridge/dynload/tramp.c |4 ++--
drivers/dsp/bridge/pmgr/cmm.c|7 +++
Replace simple_strtoul by strict_strtoul in atoi function.
Signed-off-by: Ernesto Ramos
---
drivers/dsp/bridge/rmgr/dbdcd.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/dsp/bridge/rmgr/dbdcd.c b/drivers/dsp/bridge/rmgr/dbdcd.c
index e014600..ae85dc2 10064
Remove function delete_strm_mgr in strm.c and
use kfree instead.
Signed-off-by: Ernesto Ramos
---
drivers/dsp/bridge/rmgr/strm.c | 16 ++--
1 files changed, 2 insertions(+), 14 deletions(-)
diff --git a/drivers/dsp/bridge/rmgr/strm.c b/drivers/dsp/bridge/rmgr/strm.c
index e537ee8.
Remove unused typedefs in dspbridge.
Signed-off-by: Ernesto Ramos
---
arch/arm/plat-omap/include/dspbridge/dbtype.h |1 -
drivers/dsp/bridge/core/_tiomap.h |2 --
2 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/dbtype.h
b/a
Remove unnecessary check for NULL pointer in cmm.c.
Signed-off-by: Ernesto Ramos
---
drivers/dsp/bridge/pmgr/cmm.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/dsp/bridge/pmgr/cmm.c b/drivers/dsp/bridge/pmgr/cmm.c
index 7aa4ca4..1134193 100644
--- a/drivers
>
> /* Macro's */
> -#define REG16(A)(*(reg_uword16 *)(A))
> -
> #define CLEAR_BIT(reg, mask) (reg &= ~mask)
> #define SET_BIT(reg, mask) (reg |= mask)
>
-- Another candidate for cleanup :)
> --
> 1.5.4.5
>
> --
> To unsubscribe from this list: send the line "u
Paul Walmsley writes:
> On Mon, 21 Jun 2010, Kevin Hilman wrote:
>
>> Paul Walmsley writes:
>>
>> > As far as I can tell, it's not safe for upper-layer code to idle a device
>> > like this. The driver itself needs to be aware of the device's idle
>> > state.
>>
>> The driver is made aware
Kevin,
> -Original Message-
> From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
> Sent: Monday, June 21, 2010 9:24 PM
> To: DebBarma, Tarun Kanti
> Cc: linux-omap@vger.kernel.org; R, Sricharan
> Subject: Re: [PATCH v2] OMAP:GPTIMER:1ms tick generation correction
>
> Tarun Kanti DebB
45 matches
Mail list logo