The CM_CLKEN_PLL_IVA2 register was not being saved by the
current prcm save/restore code. This patch adds the proper
save/restore for that register.
Signed-off-by: Kalle Jokiniemi
---
arch/arm/mach-omap2/prcm.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm
I stumbled upon a register missing from the prcm save/restore
functions. The following patch fixes the issue. Applies on top of latest
pm-branch. Tested on rx-51.
Kalle Jokiniemi (1):
ARM: OMAP3: Add missing iva2 clken_pll save/restore
arch/arm/mach-omap2/prcm.c |5 +
1 files chang
* Kevin Hilman [090512 15:31]:
> Tony Lindgren writes:
>
> > Remove OMAP_PRM_REGADDR and use processor specific defines instead.
> > Also remove now unused OMAP2_PRM_BASE.
> >
>
> Tony,
>
> For clean PM branch integration, the patch below is needed on top of
> this one.
Thanks!
> The PM bra
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Kevin Hilman
> Sent: Tuesday, May 12, 2009 6:33 PM
> To: Hunter, Jon
> There was a thread a few weeks back where various folks had noticed
> this as well and we discovered using CodeSourcery 2008q3
Correspondence with the TI OMAP hardware team indicates that
SDRC_DLLA_CTRL.FIXEDDELAY should be initialized to 0x0f. This number
was apparently derived from process validation. This is only used
when the SDRC DLL is unlocked (e.g., SDRC clock frequency less than
83MHz).
This patch has been que
According to the 34xx TRM Rev. K section 11.2.4.4.11.1 "Purpose of the
DLL/CDL Module," the SDRC delay-locked-loop can be locked at any SDRC
clock frequency from 83MHz to 166MHz. CDP code unconditionally
unlocked the DLL whenever shifting to a lower SDRC speed, but this
seems unnecessary and error
Add more barriers in the SRAM CORE DPLL M2 divider change code.
- Add a DSB SY after the function's entry point to flush all cached
and buffered writes and wait for the interconnect to claim that they
have completed[1]. The idea here is to force all delayed write
traffic going to the SDRAM
Clear the SDRC_POWER.PWRENA bit before putting the SDRAM into self-refresh
mode. This prevents the SDRC from attempting to power off the SDRAM,
which can cause the system to hang.
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/sram34xx.S |7 ---
1 files changed, 4 insertions(+), 3
Rename clk_init_one() to clk_preinit() to distinguish its function
from clk_init() and the individual struct clk init functions.
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap1/clock.c |2 +-
arch/arm/mach-omap2/clock24xx.c |2 +-
arch/arm/mach-omap2/clock34xx.c
From: Artem Bityutskiy
On our system we see the following messages:
Disabling unused clock "gpt2_ick"
Disabling unused clock "gpt3_ick"
Disabling unused clock "gpt4_ick"
Disabling unused clock "gpt5_ick"
...
The messages have KERN_INFO level and if you have serial
console, they normally go ther
The CORE DPLL M2 frequency change code should use pr_debug(), not
pr_info(), for its debug messages. Same with
omap2_clksel_round_rate_div(). While here, convert a few printk(KERN_ERR ..
into pr_err().
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/clock.c | 12 ++--
arch/a
Initialize SDRC_POWER to a known-good setting when the kernel boots.
Necessary since some bootloaders don't initialize SDRC_POWER properly.
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/sdrc.c | 19 ++-
1 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/arch
Renumber registers in omap3_sram_configure_core_dpll() assembly code to
make space for additional parameters.
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/sram34xx.S | 114
1 files changed, 57 insertions(+), 57 deletions(-)
diff --git a/arch/arm
Where necessary, add interconnect barriers to force posted writes to
complete before continuing.
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/sram34xx.S |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/sram34xx.S b/arch/arm/mach-omap2/s
Mark the SRAM (aka OCM RAM) as Non-cacheable Normal memory[1]. This
is to prevent the ARM from evicting existing cache lines to SDRAM
while code is executing from the SRAM. Necessary since one of the
primary uses for the SRAM is to hold the code and data for the CORE
DPLL M2 divider reprogramming
Hello Russell,
This series contains OMAP clock and SDRAM controller patches against
v2.6.30-rc5. If you are happy with these, Tony will merge them into
his for-next branch for you to pull.
This series includes the clk_init_one() to clk_preinit() rename that
we've discussed recently. Most of the
"Hunter, Jon" writes:
> I have been doing some testing with the latest linux-omap kernel on
> the 3430sdp and the kernel appeared to hang on start-up during the
> delay loop calibration.
>
> After debugging this I found that this was being caused because
> there was a difference in the compilatio
On Tuesday 12 May 2009 02:06:58 am Jarkko Nikula wrote:
> On Sat, 9 May 2009 17:45:00 -0500
>
> "Luke-Jr" wrote:
> > Having trouble getting "2.6.30-rc4-omap1" to boot my US N810 (running
> > Gentoo). The initial problem appears to be related to /dev/mmcblk*
> > missing, but I can't debug it very f
Tony Lindgren writes:
> Remove OMAP_PRM_REGADDR and use processor specific defines instead.
> Also remove now unused OMAP2_PRM_BASE.
>
Tony,
For clean PM branch integration, the patch below is needed on top of
this one.
The PM branch code uses almost entirely the [cm|prm]_[read|write]_*
macros
Hi All,
I have been doing some testing with the latest linux-omap kernel on the 3430sdp
and the kernel appeared to hang on start-up during the delay loop calibration.
After debugging this I found that this was being caused because there was a
difference in the compilation flags being used when
On Tue, May 12, 2009 at 8:38 AM, Hiroshi DOYU wrote:
> From: "ext Kanigeri, Hari"
> Subject: RE: [PATCH 2/2] DSPBRIDGE: add checking 128 byte alignment for dsp
> cache line size
> Date: Mon, 11 May 2009 20:26:11 +0200
>
>> To summarize the discussion.
>
> Thanks
>
>> We need to have the check fo
On Tue, May 12, 2009 at 2:21 AM, Kanigeri, Hari wrote:
> Felipe,
>
>>
>> IMHO the only sensible way to approach this is to create a new ioctl
>> for a special restrictive mapping where user-space specifies if the
>> memory area is read-only or write-only and the size must be the real
>> size. This
This patch has been applied to the linux-omap
by youw fwiendly patch wobot.
Initial commit ID (Likely to change): 4d972088a40e3e51ef7ad790042b35f1cc97e35c
PatchWorks
http://patchwork.kernel.org/patch/19326/
Git (Likely to change, and takes a while to get mirrored)
http://git.kernel.org/?p=linux/
One correction:
On Tue, 12 May 2009, Paul Walmsley wrote:
> At least receive overruns are handled gracefully by the controller.
> Transmit FIFO underruns may be the more pressing problem.
Rather, transmit underruns are probably nonfatal in master mode also.
But both receive overruns and trans
On Tue, 12 May 2009, Woodruff, Richard wrote:
> > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> > ow...@vger.kernel.org] On Behalf Of Paul Walmsley
> > A brief update for anyone following along on the list:
> >
> > Aaro sent me a test-case. It seems that the receive overruns only a
* Jarkko Nikula [090506 22:16]:
> On Thu, 23 Apr 2009 20:06:39 +0300
> Kalle Valo wrote:
>
> > Jarkko Nikula writes:
> >
> > > Fix "tusb6010 init error 5, -19" and compilation warning from
> > > function tusb6010_platform_retime "warning: 'sysclk_ps' is used
> > > uninitialized in this functio
This patch has been applied to the linux-omap
by youw fwiendly patch wobot.
Initial commit ID (Likely to change): 7c8bb23f02911def7e5196fbd39f5c16d09dc635
PatchWorks
http://patchwork.kernel.org/patch/12500/
Git (Likely to change, and takes a while to get mirrored)
http://git.kernel.org/?p=linux/
This patch has been applied to the linux-omap
by youw fwiendly patch wobot.
Initial commit ID (Likely to change): 17178f265cbe2220fc437e93128fb0feea54c3fc
PatchWorks
http://patchwork.kernel.org/patch/19477/
Git (Likely to change, and takes a while to get mirrored)
http://git.kernel.org/?p=linux/
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Paul Walmsley
> A brief update for anyone following along on the list:
>
> Aaro sent me a test-case. It seems that the receive overruns only affect
> PM kernels. They are caused by the MPU going to
Paul Walmsley writes:
> On Tue, 12 May 2009, Kevin Hilman wrote:
>
>> As the OMAP4 patches are coming in, there seems to be a bit of variety
>> in the naming of functions/macros/variables etc.
>>
>> Could I propose that we just use omap4_* and OMAP4_* instead of
>> OMAP44XX_* or OMAP4_* etc.
Awhile back, support for OMAP MMC1/2/3 was added to
git.omapzoom.org/android-2.6.27...
(http://git.omapzoom.org/?p=repo/omapkernel.git;a=shortlog;h=refs/heads/android-2.6.27)
Would this be the most appropriate kernel to use to get MMC1/2/3
support, and also the latest OMAP PM and DSS support? Or
Hi Jon,
"Hunter, Jon" writes:
> I want to run some tests using the linux-omap pm branch on the omap3430 and
> had a couple questions...
>
> 1). What omap3430 board(s) are being using to validate the pm branch
> functionality?
I typically validate on Beagle, OMAP3EVM and RX51. Some folks in T
On Tue, 12 May 2009, Kevin Hilman wrote:
> As the OMAP4 patches are coming in, there seems to be a bit of variety
> in the naming of functions/macros/variables etc.
>
> Could I propose that we just use omap4_* and OMAP4_* instead of
> OMAP44XX_* or OMAP4_* etc.
>
> I know that OMAP2 and OMAP
> -Original Message-
> From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
> Sent: Tuesday, May 12, 2009 8:29 PM
> To: linux-omap@vger.kernel.org
> Cc: Shilimkar, Santosh
> Subject: OMAP4 naming conventions
>
> As the OMAP4 patches are coming in, there seems to be a bit of variety
>
* Premi, Sanjeev [090512 08:01]:
> > -Original Message-
> > From: linux-omap-ow...@vger.kernel.org
> > [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin Hilman
> > Sent: Tuesday, May 12, 2009 8:29 PM
> > To: linux-omap@vger.kernel.org
> > Cc: Shilimkar, Santosh
> > Subject: OMA
"Syed Rafiuddin" writes:
> This patch creates i2c-omap.h header and moves register and bit definition
> macros to it from i2c-omap.c
Please use the description to describe the motivation for the changes
and the problems it is addressing/fixing.
In other words, you described what your patch doe
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org
> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin Hilman
> Sent: Tuesday, May 12, 2009 8:29 PM
> To: linux-omap@vger.kernel.org
> Cc: Shilimkar, Santosh
> Subject: OMAP4 naming conventions
>
> As the OMAP4 patches
As the OMAP4 patches are coming in, there seems to be a bit of variety
in the naming of functions/macros/variables etc.
Could I propose that we just use omap4_* and OMAP4_* instead of
OMAP44XX_* or OMAP4_* etc.
I know that OMAP2 and OMAP3 have a variety of forms here too, but
those should pro
"Syed Rafiuddin" writes:
> This patch enables support for UART4 on OMAP4430 development platform.
>
> Signed-off-by: Syed Rafiuddin
> ---
> arch/arm/mach-omap2/board-4430sdp.c |2 +-
> arch/arm/mach-omap2/serial.c| 12
> 2 files changed, 13 insertions(+), 1 deletion(-)
> -Original Message-
> From: Hiroshi DOYU [mailto:hiroshi.d...@nokia.com]
> Sent: Tuesday, May 12, 2009 12:39 AM
> To: Kanigeri, Hari
> Cc: felipe.contre...@gmail.com; Menon, Nishanth;
> linux-omap@vger.kernel.org
> Subject: Re: [PATCH 2/2] DSPBRIDGE: add checking 128 byte
> alignment fo
On Tue, May 12, 2009 at 03:09:45PM +0200, ext Syed Rafiuddin wrote:
> This patch creates i2c-omap.h header and moves register and bit definition
> macros to it from i2c-omap.c
>
> Signed-off-by: Syed Rafiuddin
> Acked-by: Santosh Shilimkar
Any special need for that ? will those registers be acc
This patch creates i2c-omap.h header and moves register and bit definition
macros to it from i2c-omap.c
Signed-off-by: Syed Rafiuddin
Acked-by: Santosh Shilimkar
---
drivers/i2c/busses/i2c-omap.c | 120 --
drivers/i2c/busses/i2c-omap.h | 145 +++
This patch updates the platform dma.h with new dma request lines
for OMAP4 peripherals. Also additional hardware register of OMAP4
sDMA module are included.
Signed-off-by: Santosh Shilimkar
---
arch/arm/plat-omap/include/mach/dma.h | 65 -
1 files changed, 64 in
Following patch should apply on top of pm-branch. Build tested for rx-51.
Kalle Jokiniemi (1):
ARM:OMAP3: Fix PLL_MOD CLKEN offset in scratchpad
arch/arm/mach-omap2/control.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
--
To unsubscribe from this list: send the line "unsu
The CM_CLKEN_PLL register saved in scratchpad memory
was wrongly using offset of 0x0004 instead of 0x.
The effect of this was that boot ROM code would
restore the wrong value when waking up from off mode.
This wrong value, however, will be overwritten by
prcm context restore. Still, a short pe
Hi,
I am playing with OMAP 5910 based Amstrad E3 videophone (ams-delta)
machine. I am trying to expose GPIO 4, that hook switch hangs off, to
userspace.
I can successfully access the pin by exporting it using gpiolib sysfs. I
can check its value, following hook switch state changes. However,
Thanks,
Vaibhav Hiremath
Platform Support Products
Texas Instruments Inc
Ph: +91-80-25099927
> -Original Message-
> From: George.Qiao [mailto:qiao_shans...@visualon.com]
> Sent: Tuesday, May 12, 2009 1:35 PM
> To: Hiremath, Vaibhav
> Cc: Syed Mohammed, Khasim; Shah, Hardik; wan_jin...@vi
Hi Hiremath Vaibhav,
Thank you very much for v4l2 on beagle!
We want to use your branch to demo our video player, I can not enable
sound and usb-mouse in beagle board.
What's the difference between beagle kernel and your branch kernel for
sound and usb driver?
Thanks & Best Regards,
Georg
Hi Inki,
I was on vacation just came,
Below are my comments.
> -Original Message-
> From: InKi Dae [mailto:daei...@gmail.com]
> Sent: Thursday, April 30, 2009 6:19 PM
> To: Shah, Hardik
> Cc: tomi.valkei...@nokia.com; linux-me...@vger.kernel.org; linux-
> o...@vger.kernel.org; Jadav, Brij
On Sat, 9 May 2009 17:45:00 -0500
"Luke-Jr" wrote:
> Having trouble getting "2.6.30-rc4-omap1" to boot my US N810 (running
> Gentoo). The initial problem appears to be related to /dev/mmcblk*
> missing, but I can't debug it very far due to the second problem I
For me mmc is working. I'm booting
50 matches
Mail list logo