Pending March patches

Pending March patches

[Dirk Behme]

Please find below my list of pending OMAP patches for March 
2007. As ususal, if you think anything is wrong, missing or 
already applied, please correct.


Pending OMAP patches March 2007
-------------------------------

1. [PATCH] Display Controller Library for OMAP2420/2430/3430 
platforms.
http://linux.omap.com/pipermail/linux-omap-open-source/2007-March/009182.html

2. [PATCH] add ssi/Kconfig to arch/arm/Kconfig
http://linux.omap.com/pipermail/linux-omap-open-source/2007-March/009220.html

2. [PATCH] ARM: OMAP: MMC performance upgrade on OMAP2
http://linux.omap.com/pipermail/linux-omap-open-source/2007-March/009290.html

3. [PATCH 1/1] OMAP: Add TWL support for omap mmu framework
http://linux.omap.com/pipermail/linux-omap-open-source/2007-March/009313.html

4. [PATCH 1/2] ARM:OMAP: Integrated blk request queues for 
mbox fwk
http://linux.omap.com/pipermail/linux-omap-open-source/2007-March/009355.html

5. [PATCH 2/2] ARM: OMAP: Restructuring mailbox blk queues
http://linux.omap.com/pipermail/linux-omap-open-source/2007-March/009356.html

6. [PATCH 1/2] OMAP: DSP: N800: remaining updates for dsp parts
http://linux.omap.com/pipermail/linux-omap-open-source/2007-March/009359.html

7. [PATCH 2/2] OMAP: MBOX: N800: remaining updates for 
mailbox parts
http://linux.omap.com/pipermail/linux-omap-open-source/2007-March/009358.html

8. [PATCH] ARM: OMAP: Fix warnings in devices.c for 2430sdp 
config
http://linux.omap.com/pipermail/linux-omap-open-source/2007-March/009380.html

9. [RFC/PATCH] ARM: OMAP: OneNAND support for 2430SDP
http://linux.omap.com/pipermail/linux-omap-open-source/2007-March/009386.html


"Dave, can you have a look" patches ;)
--------------------------------------

1. [review] OMAP2 USB device DMA support
http://linux.omap.com/pipermail/linux-omap-open-source/2006-November/008342.html

2. [PATCH] MUSB HDRC: RMMOD fixing
http://linux.omap.com/pipermail/linux-omap-open-source/2007-January/008853.html



Best regards

Dirk

Re: Pending March patches

[Hiroshi DOYU]

From: "ext Dirk Behme" <dirk.behme@googlemail.com>
Subject: Pending March patches
Date: Sun, 01 Apr 2007 17:41:17 +0200

> 
> Please find below my list of pending OMAP patches for March 
> 2007. As ususal, if you think anything is wrong, missing or 
> already applied, please correct.
> 
> 
> Pending OMAP patches March 2007
> -------------------------------
> 
> 3. [PATCH 1/1] OMAP: Add TWL support for omap mmu framework
> http://linux.omap.com/pipermail/linux-omap-open-source/2007-March/009313.html

This is being rewritten to use ARM MMU mechanism because their logic
is almost same as ARM MMU and "mm_struct" and "vm_area_struct" can be
used to manage virtual address for omap mmu framework. This would be
much simpler and better. I will re-send the patch later.

  Hiroshi DOYU

Re: Pending March patches

[Tony Lindgren]

Hi,

Thanks again for the list, here are some comments on the status.

* Dirk Behme <dirk.behme@googlemail.com> [070401 11:43]:
> 
> Please find below my list of pending OMAP patches for March 
> 2007. As ususal, if you think anything is wrong, missing or 
> already applied, please correct.
> 
> 
> Pending OMAP patches March 2007
> -------------------------------
> 
> 1. [PATCH] Display Controller Library for OMAP2420/2430/3430 
> platforms.
> http://linux.omap.com/pipermail/linux-omap-open-source/2007-March/009182.html

This is still pending comments from Imre, and possibly regarding V4L
from Mauro.

> 2. [PATCH] add ssi/Kconfig to arch/arm/Kconfig
> http://linux.omap.com/pipermail/linux-omap-open-source/2007-March/009220.html

I already nuked the drivers/ssi :)

> 2. [PATCH] ARM: OMAP: MMC performance upgrade on OMAP2
> http://linux.omap.com/pipermail/linux-omap-open-source/2007-March/009290.html

Carlos should test this on various boards.

> 3. [PATCH 1/1] OMAP: Add TWL support for omap mmu framework
> http://linux.omap.com/pipermail/linux-omap-open-source/2007-March/009313.html

Being reworked as mentioned by Hiroshi.

> 4. [PATCH 1/2] ARM:OMAP: Integrated blk request queues for 
> mbox fwk
> http://linux.omap.com/pipermail/linux-omap-open-source/2007-March/009355.html

Should be applied already in master branch, but probably buried under
other changes. Hiroshi, can you please verify?

> 5. [PATCH 2/2] ARM: OMAP: Restructuring mailbox blk queues
> http://linux.omap.com/pipermail/linux-omap-open-source/2007-March/009356.html

Should be applied already, Hiroshi, can you verify?

> 6. [PATCH 1/2] OMAP: DSP: N800: remaining updates for dsp parts
> http://linux.omap.com/pipermail/linux-omap-open-source/2007-March/009359.html

Should be applied already, Hiroshi, can you verify?

> 7. [PATCH 2/2] OMAP: MBOX: N800: remaining updates for 
> mailbox parts
> http://linux.omap.com/pipermail/linux-omap-open-source/2007-March/009358.html

Should be applied already, Hiroshi, can you verify?

> 8. [PATCH] ARM: OMAP: Fix warnings in devices.c for 2430sdp 
> config
> http://linux.omap.com/pipermail/linux-omap-open-source/2007-March/009380.html
> 
> 9. [RFC/PATCH] ARM: OMAP: OneNAND support for 2430SDP
> http://linux.omap.com/pipermail/linux-omap-open-source/2007-March/009386.html

Pushing today.

> "Dave, can you have a look" patches ;)
> --------------------------------------
> 
> 1. [review] OMAP2 USB device DMA support
> http://linux.omap.com/pipermail/linux-omap-open-source/2006-November/008342.html
> 
> 2. [PATCH] MUSB HDRC: RMMOD fixing
> http://linux.omap.com/pipermail/linux-omap-open-source/2007-January/008853.html

Regards,

Tony

Re: Pending March patches

[Hiroshi DOYU]

Tony,

I confirmed that everything is in "master" branch and the other
branches have not been updated yet, which are related to "mmu
fw"/mailbox/dspgw(?).

Though I don't know how to deal with dspgw code, I guess, at least,
"mailbox" and "mmu fw" can be merged into mainline?

Also there's something strange. There's just small part of dsp code in
"omap-drivers", but it's only a few files, they are not enough.

If this is just a queuing matter(sooner or later), or just on the way,
please ignore this e-mail.

Anyway, it is not so critical at this point. Basically I can use
"master" branch as it is.

		Hiroshi DOYU

> > 4. [PATCH 1/2] ARM:OMAP: Integrated blk request queues for 
> > mbox fwk
> > http://linux.omap.com/pipermail/linux-omap-open-source/2007-March/009355.html
> 
> Should be applied already in master branch, but probably buried under
> other changes. Hiroshi, can you please verify?
>
> > 5. [PATCH 2/2] ARM: OMAP: Restructuring mailbox blk queues
> > http://linux.omap.com/pipermail/linux-omap-open-source/2007-March/009356.html
> 
> Should be applied already, Hiroshi, can you verify?
>
> > 6. [PATCH 1/2] OMAP: DSP: N800: remaining updates for dsp parts
> > http://linux.omap.com/pipermail/linux-omap-open-source/2007-March/009359.html
> 
> Should be applied already, Hiroshi, can you verify?
> 
> > 7. [PATCH 2/2] OMAP: MBOX: N800: remaining updates for 
> > mailbox parts
> > http://linux.omap.com/pipermail/linux-omap-open-source/2007-March/009358.html
> 
> Should be applied already, Hiroshi, can you verify?


  Hiroshi DOYU

Re: Pending March patches

[Tony Lindgren]

Hi,

* Hiroshi DOYU <Hiroshi.DOYU@nokia.com> [070404 03:17]:
> Tony,
> 
> I confirmed that everything is in "master" branch and the other
> branches have not been updated yet, which are related to "mmu
> fw"/mailbox/dspgw(?).

OK, thanks for confirming.

> Though I don't know how to deal with dspgw code, I guess, at least,
> "mailbox" and "mmu fw" can be merged into mainline?

Yes, ideally we would have DSP power on/off, mailbox, mmu fw in
plat-omap.

Then I suggest we move the rest of the DSP code into drivers/dsp/omap.

I don't think we can get the arch/arm/plat-omap/dsp integrated to
the mainline. So the chances of getting it integrated would be better
under drivers/dsp/omap.

What are your thoughts on that? I'm thinking that we could do it few
weeks after 2.6.21 after a stable 2.6.21-omap release.

> Also there's something strange. There's just small part of dsp code in
> "omap-drivers", but it's only a few files, they are not enough.

OK, that needs to be checked. Sounds like they should be only in master,
except for DSP power on/off, mailbox and  mmu fw. And those should be
in omap-upstream.

Regards,

Tony

Re: Pending March patches

[Hiroshi DOYU]

From: "ext Tony Lindgren" <tony@atomide.com>
Subject: Re: Pending March patches
Date: Wed, 4 Apr 2007 09:04:51 -0400

> > Though I don't know how to deal with dspgw code, I guess, at least,
> > "mailbox" and "mmu fw" can be merged into mainline?
> 
> Yes, ideally we would have DSP power on/off, mailbox, mmu fw in
> plat-omap.
> 
> Then I suggest we move the rest of the DSP code into drivers/dsp/omap.
> 
> I don't think we can get the arch/arm/plat-omap/dsp integrated to
> the mainline. So the chances of getting it integrated would be better
> under drivers/dsp/omap.
> 
> What are your thoughts on that? I'm thinking that we could do it few
> weeks after 2.6.21 after a stable 2.6.21-omap release.

Agreed. It would be cleaner and easy to handle other implementation also.

   Hiroshi DOYU

Re: Pending March patches

[Tony Lindgren]

* Hiroshi DOYU <Hiroshi.DOYU@nokia.com> [070404 10:06]:
> From: "ext Tony Lindgren" <tony@atomide.com>
> Subject: Re: Pending March patches
> Date: Wed, 4 Apr 2007 09:04:51 -0400
> 
> > > Though I don't know how to deal with dspgw code, I guess, at least,
> > > "mailbox" and "mmu fw" can be merged into mainline?
> > 
> > Yes, ideally we would have DSP power on/off, mailbox, mmu fw in
> > plat-omap.
> > 
> > Then I suggest we move the rest of the DSP code into drivers/dsp/omap.
> > 
> > I don't think we can get the arch/arm/plat-omap/dsp integrated to
> > the mainline. So the chances of getting it integrated would be better
> > under drivers/dsp/omap.
> > 
> > What are your thoughts on that? I'm thinking that we could do it few
> > weeks after 2.6.21 after a stable 2.6.21-omap release.
> 
> Agreed. It would be cleaner and easy to handle other implementation also.

OK. I'll drop the "ARM: OMAP: Add DSP common code" patch from
omap-upstream for now. Then we can put together the minimal DSP init
patch later on for 2.6.23 or something. The omap-upstream queue is
already painfully big :)

What do you think we should keep in plat-omap?

Maybe just something to power up and idle the DSP, and allow using McBSP
for audio?

Tony

Re: Pending March patches -- OMAP DPSGW code migration

[Hiroshi DOYU]

Hi,

> > > What are your thoughts on that? I'm thinking that we could do it few
> > > weeks after 2.6.21 after a stable 2.6.21-omap release.
> >
> > Agreed. It would be cleaner and easy to handle other implementation also.
>
> OK. I'll drop the "ARM: OMAP: Add DSP common code" patch from
> omap-upstream for now. Then we can put together the minimal DSP init
> patch later on for 2.6.23 or something. The omap-upstream queue is
> already painfully big :)
>
> What do you think we should keep in plat-omap?
>
> Maybe just something to power up and idle the DSP, and allow using McBSP
> for audio?

Yes, it may be like that.

I think that it is time to consider DSPGW implementation again to
support multiple bridge implementation and H/W combination at this
transition.

"DSPGW" was originally designed to support just ARM+C55x on OMAP1,
only one combination, then OMAP2 now. It is composed of MPU side
S/W(kernel/userland) and DSP side S/W(including DSP/BIOS).

Now there are some H/W combinations coming, like ARM+IVA1, ARM?+IVA2,
, OMAP730, ARM?+?. Also there exists TI's S/W bridge implementation
and TI's middlewares on the top of that. All of them uses the same
kind of "interrupt based mailbox", "shared memory" and "MMU control"
to communicate between MPU and DSP, though their implementations are
somewhat different. So, now the situation is getting complicated
because there are the several kind of S/W and H/W combinations.

At the point of MPU(ARM) side bridge S/W, it may be better that OMAP
DSP bridge driver provides a collection of "BASIC S/W COMPONENTS" at
first, and then builds up several kind of "USER INTERFACE" on the top
of them, in order to support multiple H/W and S/W combinations,
sharing their code as much as possible.

For "BASIC S/W COMPONENTS", at least, there may be following modules

  - OMAP non-MPU MMU FW
  - MAILBOX
  - IPC message protocol
  - Shared memory management
  - DSP processor management/control
  - DSP TASK/NODE, STREAM management
  - DSP COFF/DOFF loader

Basically each of them should be _independent_ and just provides its
basic feature for their users as APIs, though some of them have to be
stacked as layer.

For "USER INTERFACE", there are/will be some implementations
below. They are just interfaces to make use of/be composed of, some or
all of the above BASIC COMPONENTS. User can choose any interface among
them. In other words, these user interfaces may be exclusive.

  - character device interface "/dev/dsptask?"	(ex: DSPGW)
  - user defined "ioctl()" messages		(ex: TI's bridge)
  - DSP specified filesystem, "DSPFS"		(most reasonable one)
  - userland device driver
  - nice fancy interfaces?                      (no idea for me, now)

The above interfaces can be wrapped by userland library API to keep
the compatibility for the existing middleware interfaces.

Also there may be a trade-off that how much work userland application
take care of. For example, userland application can be something like
just "userland device driver" which just uses "MAILBOX" and "MMU FW"
interfaces to control "DSP". Or most of the work can be done within
kernel module.

So I think that, once the above "BASIC S/W COMPONENTS" are implemented,
it would be easier to implement another interfaces on the top of them,
because an interface can choose some/all of components which it
requires to build their interface/API for users.

Now the problem is current DSPGW's components are a little bit too
related each other to support multiple
combinations/implementations. Along with this DSPGW code migration, we
had better solve this complexity, at least some extent;) to introduce
further/another implementations later.

Any comments would be appreciated.

    Hiroshi DOYU

Re: Pending March patches -- OMAP DPSGW code migration

[Paul Mundt]

On Tue, Apr 10, 2007 at 10:36:25AM +0300, Hiroshi DOYU wrote:
> > OK. I'll drop the "ARM: OMAP: Add DSP common code" patch from
> > omap-upstream for now. Then we can put together the minimal DSP init
> > patch later on for 2.6.23 or something. The omap-upstream queue is
> > already painfully big :)
> >
> > What do you think we should keep in plat-omap?
> >
> > Maybe just something to power up and idle the DSP, and allow using McBSP
> > for audio?
> 
> Yes, it may be like that.
> 
It's probably worth pushing the MMU framework bits also, since it will
also be required for things like the camera MMU. Though it's not worth
pushing infrastructure if there are no in-tree users.

> Now there are some H/W combinations coming, like ARM+IVA1, ARM?+IVA2,
> , OMAP730, ARM?+?. Also there exists TI's S/W bridge implementation
> and TI's middlewares on the top of that. All of them uses the same
> kind of "interrupt based mailbox", "shared memory" and "MMU control"
> to communicate between MPU and DSP, though their implementations are
> somewhat different. So, now the situation is getting complicated
> because there are the several kind of S/W and H/W combinations.
> 
The other thing to consider also is how generic these sorts of things can
be made. We're in a position now where both spufs and dspgw take very
different approaches to a fairly common problem. Trying to maintain API
or ABI compatability with the old code is likely not worth the trouble in
the long run, particularly as that's not something that has a lot of
chance of being merged upstream.

> For "BASIC S/W COMPONENTS", at least, there may be following modules
> 
>   - OMAP non-MPU MMU FW
>   - MAILBOX
>   - IPC message protocol
>   - Shared memory management
>   - DSP processor management/control

It should be possible to do these generically from an API level at least.

>   - DSP TASK/NODE, STREAM management

This has to be platform specific.

>   - DSP COFF/DOFF loader
> 
And this can mostly be in userspace. Other platforms for instance do use
in-kernel loaders, but generally only for ELF. The MIPS VPEs are an
example of this, albeit for a slightly different usecase.

>   - character device interface "/dev/dsptask?"	(ex: DSPGW)
>   - user defined "ioctl()" messages		(ex: TI's bridge)
>   - DSP specified filesystem, "DSPFS"		(most reasonable one)
>   - userland device driver
>   - nice fancy interfaces?                      (no idea for me, now)
> 
I would like to see a consolidation between dspfs and process context as
per the RidgeRun TaskBridge. Rolling a special library and interfaces
makes little sense for places where regular system calls will suffice
just fine. The SPU libraries end up doing this via pthreads, but I
suppose kernel threads will be required for most of these cases (this is
what TaskBridge did also).

> The above interfaces can be wrapped by userland library API to keep
> the compatibility for the existing middleware interfaces.
> 
That's another problem entirely. Writing userspace wrappers around this
stuff for API compatability is of course an option, but it's not worth
carrying extra weight around on the kernel side to try and accomodate
this sort of thing, especially if there's a better way to do codec
manipulation.

Re: Pending March patches -- OMAP DPSGW code migration

[Tony Lindgren]

Hi,

* Paul Mundt <lethal@linux-sh.org> [070410 20:00]:
> On Tue, Apr 10, 2007 at 10:36:25AM +0300, Hiroshi DOYU wrote:
> > > OK. I'll drop the "ARM: OMAP: Add DSP common code" patch from
> > > omap-upstream for now. Then we can put together the minimal DSP init
> > > patch later on for 2.6.23 or something. The omap-upstream queue is
> > > already painfully big :)
> > >
> > > What do you think we should keep in plat-omap?
> > >
> > > Maybe just something to power up and idle the DSP, and allow using McBSP
> > > for audio?
> > 
> > Yes, it may be like that.
> > 
> It's probably worth pushing the MMU framework bits also, since it will
> also be required for things like the camera MMU. Though it's not worth
> pushing infrastructure if there are no in-tree users.

Yeah, the MMU framework could be pushed after 2.6.22.

> > Now there are some H/W combinations coming, like ARM+IVA1, ARM?+IVA2,
> > , OMAP730, ARM?+?. Also there exists TI's S/W bridge implementation
> > and TI's middlewares on the top of that. All of them uses the same
> > kind of "interrupt based mailbox", "shared memory" and "MMU control"
> > to communicate between MPU and DSP, though their implementations are
> > somewhat different. So, now the situation is getting complicated
> > because there are the several kind of S/W and H/W combinations.
> > 
> The other thing to consider also is how generic these sorts of things can
> be made. We're in a position now where both spufs and dspgw take very
> different approaches to a fairly common problem. Trying to maintain API
> or ABI compatability with the old code is likely not worth the trouble in
> the long run, particularly as that's not something that has a lot of
> chance of being merged upstream.
> 
> > For "BASIC S/W COMPONENTS", at least, there may be following modules
> > 
> >   - OMAP non-MPU MMU FW
> >   - MAILBOX
> >   - IPC message protocol
> >   - Shared memory management
> >   - DSP processor management/control
> 
> It should be possible to do these generically from an API level at least.

I'd say let's only keep the minimum to boot omap under
arch/arm/plat-omap:

- Minimal DSP support to idle the DSP
- Support for enabling audio McBSP clocks
- MMU framework as it is shared with camera

The rest can go to drivers/dsp/omap.

> >   - DSP TASK/NODE, STREAM management
> 
> This has to be platform specific.
> 
> >   - DSP COFF/DOFF loader
> > 
> And this can mostly be in userspace. Other platforms for instance do use
> in-kernel loaders, but generally only for ELF. The MIPS VPEs are an
> example of this, albeit for a slightly different usecase.
> 
> >   - character device interface "/dev/dsptask?"	(ex: DSPGW)
> >   - user defined "ioctl()" messages		(ex: TI's bridge)
> >   - DSP specified filesystem, "DSPFS"		(most reasonable one)
> >   - userland device driver
> >   - nice fancy interfaces?                      (no idea for me, now)
> > 
> I would like to see a consolidation between dspfs and process context as
> per the RidgeRun TaskBridge. Rolling a special library and interfaces
> makes little sense for places where regular system calls will suffice
> just fine. The SPU libraries end up doing this via pthreads, but I
> suppose kernel threads will be required for most of these cases (this is
> what TaskBridge did also).

As far as I remember, the RidgeRun bridge had a cool feature of piping
data to the DSP processes :)

> > The above interfaces can be wrapped by userland library API to keep
> > the compatibility for the existing middleware interfaces.
> > 
> That's another problem entirely. Writing userspace wrappers around this
> stuff for API compatability is of course an option, but it's not worth
> carrying extra weight around on the kernel side to try and accomodate
> this sort of thing, especially if there's a better way to do codec
> manipulation.

Regards,

Tony