Aim was to get omap_type() function work on omap4.
In doing so, fixing an issue with is_sram_locked() function.
Patches tested/verified on omap4 sdp.
Patches based of latest linus commit: e467e10
Vikram Pandita (3):
omap: sram: fix is_sram_locked check
omap4: fix omap_type() function
On OMAP4 the SRAM configuration is:
GP Device:
Start Address: 0x4030
Size: 0xE000 (56KB)
EMU/HS Device:
Start Address: 0x4030 4000
Size: 0xA000 (40KB)
Implement this mapping in the sram file
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
---
Following patch added the omap_type() functionality for omap4
737daa03: omap4: Fix omap_type() for omap4
However the omap_type() function would not work as:
1) the base address for CONTROL_STATUS register is wrongly mapped
2) Not yet supported check for omap4 needs to be removed
For OMAP24xx/34xx/44xx: omap_type() returns the correct type:
OMAP2_DEVICE_TYPE_TEST
OMAP2_DEVICE_TYPE_EMU
OMAP2_DEVICE_TYPE_SEC
OMAP2_DEVICE_TYPE_GP
OMAP2_DEVICE_TYPE_BAD
In current implementation there are two problems:
Problem 1:
For 34xx, the current if check will never return true.
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Pandita, Vikram
Sent: Saturday, July 10, 2010 12:39 PM
To: linux-omap@vger.kernel.org
Cc: Pandita, Vikram
Subject: [PATCH 2/3] omap4: fix omap_type() function
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Vikram Pandita
Sent: Saturday, July 10, 2010 12:39 PM
To: linux-omap@vger.kernel.org
Cc: Pandita, Vikram
Subject: [PATCH 3/3] omap4: SRAM start and size change for
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Pandita, Vikram
Sent: Saturday, July 10, 2010 12:39 PM
To: linux-omap@vger.kernel.org
Cc: Pandita, Vikram
Subject: [PATCH 1/3] omap: sram: fix is_sram_locked check
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Pandita, Vikram
Sent: Saturday, July 10, 2010 12:39 PM
To: linux-omap@vger.kernel.org
Cc: Pandita, Vikram
Subject: [PATCH 0/3] Fix omap_type() function
Aim was to get
-Original Message-
From: Shilimkar, Santosh
Sent: Saturday, July 10, 2010 2:32 AM
To: Pandita, Vikram; linux-omap@vger.kernel.org
Subject: RE: [PATCH 0/3] Fix omap_type() function
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
On Fri, Jul 02, 2010 at 12:09:02AM -0700, Zach Pfeffer wrote:
Hari Kanigeri wrote:
He demonstrated the usage of his code in one of the emails he sent out
initially. Did you go over that, and what (or how many) step would you
use with the current code to do the same thing?
-- So is this
On Thu, Jul 01, 2010 at 03:00:17PM -0700, Zach Pfeffer wrote:
Additionally, the current IOMMU interface does not allow users to
associate one page table with multiple IOMMUs [...]
Thats not true. Multiple IOMMUs are completly handled by the IOMMU
drivers. In the case of the IOMMU-API backend
On Fri, Jul 02, 2010 at 12:33:51AM -0700, Zach Pfeffer wrote:
Daniel Walker wrote:
So if we include this code which map implementations could you
collapse into this implementations ? Generally , what currently existing
code can VCMM help to eliminate?
In theory, it can eliminate all
On Thu, Jul 01, 2010 at 11:17:34PM -0700, Zach Pfeffer wrote:
Andi Kleen wrote:
Hmm? dma_map_* does not change any CPU mappings. It only sets up
DMA mapping(s).
Sure, but I was saying that iommu_map() doesn't just set up the IOMMU
mappings, its sets up both the iommu and kernel buffer
The proximity sensor is registered as a gpio-key
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c | 43 +++
1 files changed, 43 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
14 matches
Mail list logo
