This patch creates McBSP support on OMAP4430 development platform.
This patch includes corresponding base address changes for OMAP4.
Signed-off-by: Syed Rafiuddin rafiuddin.s...@ti.com
---
arch/arm/mach-omap2/mcbsp.c | 46
This patch series enables McBSP and UART4 support for OMAP4430 development
platform.
The series contains:
[PATCH 1/2]OMAP4: McBSP support for OMAP4430
[PATCH 2/2]OMAP4: UART4 support for OMAP4430
Regards,
Syed Rafiuddin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
This patch enables support for UART4 on OMAP4430 development platform.
Signed-off-by: Syed Rafiuddin rafiuddin.s...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c |2 +-
arch/arm/mach-omap2/serial.c| 12
2 files changed, 13 insertions(+), 1 deletion(-)
Index:
On Tue, May 12, 2009 at 11:50 AM, Syed Rafiuddin rafiuddin.s...@ti.com wrote:
This patch enables support for UART4 on OMAP4430 development platform.
Signed-off-by: Syed Rafiuddin rafiuddin.s...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c |2 +-
arch/arm/mach-omap2/serial.c|
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Syed Rafiuddin
Sent: Tuesday, May 12, 2009 11:50 AM
To: linux-arm-ker...@lists.arm.linux.org.uk
Cc: linux-omap@vger.kernel.org
Subject: [PATCH 1/2][RFC] OMAP4: McBSP
On Tue, May 12, 2009 at 11:49 AM, Syed Rafiuddin rafiuddin.s...@ti.com wrote:
This patch creates McBSP support on OMAP4430 development platform.
This patch includes corresponding base address changes for OMAP4.
Signed-off-by: Syed Rafiuddin rafiuddin.s...@ti.com
---
Both patches looks independent. In that case this need not be a series.
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Syed Rafiuddin
Sent: Tuesday, May 12, 2009 11:51 AM
To: linux-arm-ker...@lists.arm.linux.org.uk
On Sat, 9 May 2009 17:45:00 -0500
Luke-Jr l...@dashjr.org 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
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, Brijesh
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,
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;
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.
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
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
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 santosh.shilim...@ti.com
---
arch/arm/plat-omap/include/mach/dma.h | 65
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 rafiuddin.s...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 120 --
-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 for dsp
Syed Rafiuddin rafiuddin.s...@ti.com writes:
This patch enables support for UART4 on OMAP4430 development platform.
Signed-off-by: Syed Rafiuddin rafiuddin.s...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c |2 +-
arch/arm/mach-omap2/serial.c| 12
2 files
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
-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 are
Syed Rafiuddin rafiuddin.s...@ti.com 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
* Premi, Sanjeev pr...@ti.com [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:
-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
in the
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 OMAP3 have
Hi Jon,
Hunter, Jon jon-hun...@ti.com 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
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
Paul Walmsley p...@pwsan.com 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_*
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
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)
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)
* Jarkko Nikula jhnik...@gmail.com [090506 22:16]:
On Thu, 23 Apr 2009 20:06:39 +0300
Kalle Valo kalle.v...@iki.fi wrote:
Jarkko Nikula jarkko.nik...@nokia.com writes:
Fix tusb6010 init error 5, -19 and compilation warning from
function tusb6010_platform_retime warning: 'sysclk_ps'
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 affect
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
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)
On Tue, May 12, 2009 at 8:38 AM, Hiroshi DOYU hiroshi.d...@nokia.com wrote:
From: ext Kanigeri, Hari h-kanige...@ti.com
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
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
Tony Lindgren t...@atomide.com 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
On Tuesday 12 May 2009 02:06:58 am Jarkko Nikula wrote:
On Sat, 9 May 2009 17:45:00 -0500
Luke-Jr l...@dashjr.org 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
Hunter, Jon jon-hun...@ti.com 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
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
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
Where necessary, add interconnect barriers to force posted writes to
complete before continuing.
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/sram34xx.S |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/sram34xx.S
Renumber registers in omap3_sram_configure_core_dpll() assembly code to
make space for additional parameters.
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/sram34xx.S | 114
1 files changed, 57 insertions(+), 57 deletions(-)
diff
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 p...@pwsan.com
---
arch/arm/mach-omap2/sdrc.c | 19 ++-
1 files changed, 18 insertions(+), 1 deletions(-)
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 p...@pwsan.com
---
arch/arm/mach-omap2/clock.c | 12
From: Artem Bityutskiy artem.bityuts...@nokia.com
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,
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
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
48 matches
Mail list logo
