[PATCH 0/3] OMAP MMU framework patches

[PATCH 0/3] OMAP MMU framework patches

[Trilok Soni]

These three patches adds OMAP MMU framework developed by Paul Mundt,
Doyu-San and Toshihiro San. Let me know if there are any changes
required to it.

I have just continued the jihad of "struct class_device" to "struct
device" conversion and made it compile :-)

-- 
--Trilok Soni

Re: [PATCH 0/3] OMAP MMU framework patches

[Hiroshi DOYU]

[-- Attachment #1: Type: text/plain, Size: 1126 bytes --]

Hi Soni,

On Tue, 20 Feb 2007 12:21:41 +0530
"ext Trilok Soni" <soni.trilok@gmail.com> wrote:

> These three patches adds OMAP MMU framework developed by Paul Mundt,
> Doyu-San and Toshihiro San. Let me know if there are any changes
> required to it.

I guess that there are 3 points to check before merging into public
tree.

First off, though this code was enough tested with N800(omap2), it can
_break_ omap1 compatibility. So we should make sure that this would work
fine with omap1, at least with some dspgw test programs, preferably N770.

Secondly, this MMU framework can be used with iva and camera
driver. So kernel config should be separated as CONFIG_OMAP_MMU_FRW or
something.

Thirdly, it's necessary to make sure that this can be compiled as
kernel module, along with dspgw and mailbox compiled as kernel module.

For reference I've attached the patch for omap1, but I havn't had
enough time to test this with N770, probably something is still
missing.

	Hiroshi DOYU

> 
> I have just continued the jihad of "struct class_device" to "struct
> device" conversion and made it compile :-)
> 
> -- 
> --Trilok Soni

[-- Attachment #2: commit-101fe44 --]
[-- Type: application/octet-stream, Size: 1938 bytes --]

commit 101fe44d9677f2fd64112e8ddac847527027b78d
Author: Hiroshi DOYU <Hiroshi.DOYU@nokia.com>
Date:   Wed Oct 11 10:22:43 2006 +0300

    temp
    
    Signed-off-by: Hiroshi DOYU <Hiroshi.DOYU@nokia.com>

diff --git a/arch/arm/mach-omap1/mmu.h b/arch/arm/mach-omap1/mmu.h
index 31ce3b8..3acbb84 100644
--- a/arch/arm/mach-omap1/mmu.h
+++ b/arch/arm/mach-omap1/mmu.h
@@ -107,13 +107,13 @@ struct omap_mmu_tlb_entry {
 static inline unsigned short
 omap_mmu_read_reg(struct omap_mmu *mmu, unsigned long reg)
 {
-	return omap_readw(mmu->base + reg);
+	return __raw_readw(mmu->base + reg);
 }
 
 static void omap_mmu_write_reg(struct omap_mmu *mmu,
 			       unsigned short val, unsigned long reg)
 {
-	omap_writew(val, mmu->base + reg);
+	__raw_writew(val, mmu->base + reg);
 }
 
 int omap_dsp_request_mem(void);
diff --git a/arch/arm/plat-omap/dsp/mmu.h b/arch/arm/plat-omap/dsp/mmu.h
index d61fd09..21fb5f4 100644
--- a/arch/arm/plat-omap/dsp/mmu.h
+++ b/arch/arm/plat-omap/dsp/mmu.h
@@ -7,7 +7,7 @@
 struct omap_mmu dsp_mmu = {
 	.name		= "dsp",
 	.type		= OMAP_MMU_DSP,
-	.base		= OMAP15XX_DSP_START,
+	.base		= DSP_MMU_BASE,
 	.membase	= OMAP15XX_DSP_BASE,
 	.memsize	= OMAP15XX_DSP_SIZE,
 	.nr_tlb_entries	= 32,
@@ -19,7 +19,7 @@ struct omap_mmu dsp_mmu = {
 struct omap_mmu dsp_mmu = {
 	.name		= "dsp",
 	.type		= OMAP_MMU_DSP,
-	.base		= OMAP16XX_DSP_START,
+	.base		= DSP_MMU_BASE,
 	.membase	= OMAP16XX_DSP_BASE,
 	.memsize	= OMAP16XX_DSP_SIZE,
 	.nr_tlb_entries	= 32,
diff --git a/arch/arm/plat-omap/dsp/omap1_dsp.h b/arch/arm/plat-omap/dsp/omap1_dsp.h
index 8dfe4d6..45fdb50 100644
--- a/arch/arm/plat-omap/dsp/omap1_dsp.h
+++ b/arch/arm/plat-omap/dsp/omap1_dsp.h
@@ -103,7 +103,7 @@
 /*
  * DSP MMU
  */
-#define DSP_MMU_BASE			(0xfffed200)
+#define DSP_MMU_BASE			(0xfefed200)
 #define DSP_MMU_PREFETCH		(DSP_MMU_BASE + 0x00)
 #define DSP_MMU_WALKING_ST		(DSP_MMU_BASE + 0x04)
 #define DSP_MMU_CNTL			(DSP_MMU_BASE + 0x08)


[-- Attachment #3: Type: text/plain, Size: 0 bytes --]

Re: [PATCH 0/3] OMAP MMU framework patches

[Trilok Soni]

Doyu-San,

On 2/20/07, Hiroshi DOYU <Hiroshi.DOYU@nokia.com> wrote:

> First off, though this code was enough tested with N800(omap2), it can
> _break_ omap1 compatibility. So we should make sure that this would work
> fine with omap1, at least with some dspgw test programs, preferably N770.

I don't have access to OMAP1 or N770. I only have H4, 2430 and soon OMAP3.

>
> Secondly, this MMU framework can be used with iva and camera
> driver. So kernel config should be separated as CONFIG_OMAP_MMU_FRW or
> something.

Yes, I am aware of this. It is on my TO-DO list, including seq_bit
simplification.

>
> Thirdly, it's necessary to make sure that this can be compiled as
> kernel module, along with dspgw and mailbox compiled as kernel module.

Yes, I wanted to push this drivers to mailing list so that others can
start reviewing it, but again I am going to make it compile as module.
So, expect patches on above items.

>
> For reference I've attached the patch for omap1, but I havn't had
> enough time to test this with N770, probably something is still
> missing.

Thanx. Let's see what Tony suggest. If he wants to me to integrate all
above changes and re-produce the patches OR submit them as incremental
patches.

-- 
--Trilok Soni

Re: [PATCH 0/3] OMAP MMU framework patches

[Trilok Soni]

On 2/20/07, Trilok Soni <soni.trilok@gmail.com> wrote:
>
> >
> > For reference I've attached the patch for omap1, but I havn't had
> > enough time to test this with N770, probably something is still
> > missing.
>
> Thanx. Let's see what Tony suggest. If he wants to me to integrate all
> above changes and re-produce the patches OR submit them as incremental
> patches.
>

OK. I have decided to re-submit this patchset with new changes as
suggested by Doyu-San along with his patch changes for OMAP1. I will
do this by probably end of this week. BTW, changes for mmu fwk to
built as module are already finished in my git tree.

-- 
--Trilok Soni

Re: [PATCH 0/3] OMAP MMU framework patches

[Tony Lindgren]

* Trilok Soni <soni.trilok@gmail.com> [070221 21:27]:
> On 2/20/07, Trilok Soni <soni.trilok@gmail.com> wrote:
> >
> >>
> >> For reference I've attached the patch for omap1, but I havn't had
> >> enough time to test this with N770, probably something is still
> >> missing.
> >
> >Thanx. Let's see what Tony suggest. If he wants to me to integrate all
> >above changes and re-produce the patches OR submit them as incremental
> >patches.
> >
> 
> OK. I have decided to re-submit this patchset with new changes as
> suggested by Doyu-San along with his patch changes for OMAP1. I will
> do this by probably end of this week. BTW, changes for mmu fwk to
> built as module are already finished in my git tree.

OK, that sounds good to me and should take care of the omap1 testing
then.

Tony

RE: [PATCH 0/3] OMAP MMU framework patches

[Zhang, Jian]

Trilock, Toshihiro and Paul,

I need to enable camera-isp MMU in my 3430 project and hence am looking
at the MMU framework code posted by Trilock. There are a few questions
that I like to discuss with you.

- omap_mmu_exmap(): It either maps a physically contiguous buffer to a
virtually contiguous space (when type!=EXMAP_TYPE_MEM), or allocates a
set of 1M/64K/4K buffers and maps these buffers to a virtually
contiguous space (when type==EXMAP_TYPE_MEM). It doesn't seem to me that
this API can map a set of dis-contiguous pages to a contiguous virtual
space. The typical camera use case is that we need to map a
scatter-gather list to a contiguous virtual space. I don't see this is
supported. Do I miss something here?

- The same API also checks the TLB. A mapping request is denied if TLB
is full. Camera MMU has only 8 TLB entries. TLB-only approach is almost
certainly impossible. Is the framework allowing the underlying MMU
driver to use table walking logic? This is not clear to me as the struct
omap_mmu_ops doesn't have enough comments. 

- Can you send me the driver code that actually calls omap_mmu_register?
Knowing how a mmu driver should be written definitely helps
understanding this mmu framework.      


Regards,
Jian
 
> 
> -----Original Message-----
> From: linux-omap-open-source-bounces@linux.omap.com
> [mailto:linux-omap-open-source-bounces@linux.omap.com] On Behalf Of
> Trilok Soni
> Sent: Tuesday, February 20, 2007 2:21 AM
> To: Hiroshi DOYU
> Cc: linux-omap-open-source@linux.omap.com
> Subject: Re: [PATCH 0/3] OMAP MMU framework patches
> 
> Doyu-San,
> 
> On 2/20/07, Hiroshi DOYU <Hiroshi.DOYU@nokia.com> wrote:
> 
> > First off, though this code was enough tested with N800(omap2), it
can
> > _break_ omap1 compatibility. So we should make sure that this would
> work
> > fine with omap1, at least with some dspgw test programs, preferably
> N770.
> 
> I don't have access to OMAP1 or N770. I only have H4, 2430 and soon
> OMAP3.
> 
> >
> > Secondly, this MMU framework can be used with iva and camera
> > driver. So kernel config should be separated as CONFIG_OMAP_MMU_FRW
or
> > something.
> 
> Yes, I am aware of this. It is on my TO-DO list, including seq_bit
> simplification.
> 
> >
> > Thirdly, it's necessary to make sure that this can be compiled as
> > kernel module, along with dspgw and mailbox compiled as kernel
module.
> 
> Yes, I wanted to push this drivers to mailing list so that others can
> start reviewing it, but again I am going to make it compile as module.
> So, expect patches on above items.
> 
> >
> > For reference I've attached the patch for omap1, but I havn't had
> > enough time to test this with N770, probably something is still
> > missing.
> 
> Thanx. Let's see what Tony suggest. If he wants to me to integrate all
> above changes and re-produce the patches OR submit them as incremental
> patches.
> 
> --
> --Trilok Soni
> _______________________________________________
> Linux-omap-open-source mailing list
> Linux-omap-open-source@linux.omap.com
> http://linux.omap.com/mailman/listinfo/linux-omap-open-source

Re: [PATCH 0/3] OMAP MMU framework patches

[Trilok Soni]

On 3/6/07, Zhang, Jian <jzhang@ti.com> wrote:
> Trilock, Toshihiro and Paul,
>
> I need to enable camera-isp MMU in my 3430 project and hence am looking
> at the MMU framework code posted by Trilock. There are a few questions
> that I like to discuss with you.
>
> - omap_mmu_exmap(): It either maps a physically contiguous buffer to a
> virtually contiguous space (when type!=EXMAP_TYPE_MEM), or allocates a
> set of 1M/64K/4K buffers and maps these buffers to a virtually
> contiguous space (when type==EXMAP_TYPE_MEM). It doesn't seem to me that
> this API can map a set of dis-contiguous pages to a contiguous virtual
> space. The typical camera use case is that we need to map a
> scatter-gather list to a contiguous virtual space. I don't see this is
> supported. Do I miss something here?

Yes, it doesn't handle all the use cases. Take a different case of
IVA1.0 with TI like IVA framework running on co-processors. In that
case we might need to support the memory "malloced" in userspace and
then passed on to gateway which pins down those pages with
"get_user_pages" like call and then maps to IVA MMU. The current MMU
fwk is highly tied to DSP's requirement. You are free to change it to
suite your case.

>
> - The same API also checks the TLB. A mapping request is denied if TLB
> is full. Camera MMU has only 8 TLB entries. TLB-only approach is almost
> certainly impossible. Is the framework allowing the underlying MMU
> driver to use table walking logic? This is not clear to me as the struct
> omap_mmu_ops doesn't have enough comments.

True. Again in case of IVA we have tried TWL and it was working, but
the code was in very much preliminary stages and not clean. Yes, 32
TLB entries in case of DSP and IVA is also not enough as we could
easily run out of it so the current approach is not scalable.

>
> - Can you send me the driver code that actually calls omap_mmu_register?
> Knowing how a mmu driver should be written definitely helps
> understanding this mmu framework.

Please check my patches on MMU framework - dsp_mem.c

-- 
--Trilok Soni

Re: [PATCH 0/3] OMAP MMU framework patches

[Hiroshi DOYU]

From: "ext Trilok Soni" <soni.trilok@gmail.com>
Subject: Re: [PATCH 0/3] OMAP MMU framework patches
Date: Tue, 6 Mar 2007 11:15:03 +0530

> On 3/6/07, Zhang, Jian <jzhang@ti.com> wrote:
> > Trilock, Toshihiro and Paul,
> >
> > I need to enable camera-isp MMU in my 3430 project and hence am looking
> > at the MMU framework code posted by Trilock. There are a few questions
> > that I like to discuss with you.
> >
> > - omap_mmu_exmap(): It either maps a physically contiguous buffer to a
> > virtually contiguous space (when type!=EXMAP_TYPE_MEM), or allocates a
> > set of 1M/64K/4K buffers and maps these buffers to a virtually
> > contiguous space (when type==EXMAP_TYPE_MEM). It doesn't seem to me that
> > this API can map a set of dis-contiguous pages to a contiguous virtual
> > space. The typical camera use case is that we need to map a
> > scatter-gather list to a contiguous virtual space. I don't see this is
> > supported. Do I miss something here?
> 
> Yes, it doesn't handle all the use cases. Take a different case of
> IVA1.0 with TI like IVA framework running on co-processors. In that
> case we might need to support the memory "malloced" in userspace and
> then passed on to gateway which pins down those pages with
> "get_user_pages" like call and then maps to IVA MMU. The current MMU

Also I guess that it is possible to use "mlock()" in userland after
"malloc()", instead of calling "get_user_pages()" directly in kernel
code. And then, mmu framework will just take care of the above
obtained physically discontinous pages to be mapped correctly.

> fwk is highly tied to DSP's requirement. You are free to change it to
> suite your case.
>
> > - The same API also checks the TLB. A mapping request is denied if TLB
> > is full. Camera MMU has only 8 TLB entries. TLB-only approach is almost
> > certainly impossible. Is the framework allowing the underlying MMU
> > driver to use table walking logic? This is not clear to me as the struct
> > omap_mmu_ops doesn't have enough comments.
> 
> True. Again in case of IVA we have tried TWL and it was working, but
> the code was in very much preliminary stages and not clean. Yes, 32
> TLB entries in case of DSP and IVA is also not enough as we could
> easily run out of it so the current approach is not scalable.
> 
> >
> > - Can you send me the driver code that actually calls omap_mmu_register?
> > Knowing how a mmu driver should be written definitely helps
> > understanding this mmu framework.
> 
> Please check my patches on MMU framework - dsp_mem.c
>
> 
> -- 
> --Trilok Soni
> _______________________________________________
> Linux-omap-open-source mailing list
> Linux-omap-open-source@linux.omap.com
> http://linux.omap.com/mailman/listinfo/linux-omap-open-source