Pending March patches
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
From: "ext Dirk Behme" <[email protected]>
Subject: Pending March patches
Date: Sun, 01 Apr 2007 17:41:17 +0200
Quoted 11 lines
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
Hi,
Thanks again for the list, here are some comments on the status.
Quoted 6 lines · 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.
Quoted 6 lines
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.
Quoted 2 lines
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 :)
Quoted 2 lines
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.
Quoted 2 lines
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.
Quoted 3 lines
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?
Quoted 2 lines
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?
Quoted 2 lines
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?
Quoted 3 lines
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?
Quoted 6 lines
8. [PATCH] ARM: OMAP: Fix warnings in
devices.cfor 2430sdp config
http://linux.omap.com/pipermail/linux-omap-open-source/2007-March/009380.html9. [RFC/PATCH] ARM: OMAP: OneNAND support for 2430SDP
http://linux.omap.com/pipermail/linux-omap-open-source/2007-March/009386.html
Pushing today.
Quoted 8 lines
"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.html2. [PATCH] MUSB HDRC: RMMOD fixing
http://linux.omap.com/pipermail/linux-omap-open-source/2007-January/008853.html
Regards,
Tony
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
Quoted 15 lines
Quoted 3 lines
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.htmlShould be applied already in master branch, but probably buried under other changes. Hiroshi, can you please verify?
Quoted 2 lines
5. [PATCH 2/2] ARM: OMAP: Restructuring mailbox blk queues
http://linux.omap.com/pipermail/linux-omap-open-source/2007-March/009356.htmlShould be applied already, Hiroshi, can you verify?
Quoted 2 lines
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
Quoted 7 lines
Should be applied already, Hiroshi, can you verify?
Quoted 3 lines
7. [PATCH 2/2] OMAP: MBOX: N800: remaining updates for mailbox parts
http://linux.omap.com/pipermail/linux-omap-open-source/2007-March/009358.htmlShould be applied already, Hiroshi, can you verify?
Hiroshi DOYU
Hi,
Quoted 5 lines · 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(?).
OK, thanks for confirming.
Quoted 2 lines
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.
Quoted 2 lines
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
From: "ext Tony Lindgren" <[email protected]>
Subject: Re: Pending March patches
Date: Wed, 4 Apr 2007 09:04:51 -0400
Quoted 6 lines
Quoted 2 lines
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.
Quoted 8 lines
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/dspintegrated to the mainline. So the chances of getting it integrated would be better underdrivers/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
Quoted 12 lines · Hiroshi DOYU
From: "ext Tony Lindgren" <[email protected]>
Subject: Re: Pending March patches
Date: Wed, 4 Apr 2007 09:04:51 -0400Quoted 8 lines
Quoted 2 lines
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.
Quoted 8 lines
Quoted 6 lines
I don't think we can get the
arch/arm/plat-omap/dspintegrated to the mainline. So the chances of getting it integrated would be better underdrivers/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
Hi,
Quoted 10 lines
Quoted 4 lines
Quoted 2 lines
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 :)
Quoted 4 lines
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
Quoted 5 lines · Hiroshi DOYU
Quoted 5 lines
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 :)
Quoted 7 lines
Quoted 4 lines
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.
Quoted 8 lines
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.
Quoted 7 lines
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.
Quoted 1 line
- DSP TASK/NODE, STREAM management
This has to be platform specific.
Quoted 2 lines
- 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.
Quoted 6 lines
- 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).
Quoted 3 lines
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
Hi,
Quoted 8 lines · Paul Mundt
Quoted 7 lines · Hiroshi DOYU
Quoted 7 lines
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?
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
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.
Quoted 17 lines
Quoted 8 lines
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.
Quoted 2 lines
For "BASIC S/W COMPONENTS", at least, there may be following modules
Quoted 7 lines
Quoted 5 lines
- OMAP non-MPU MMU FW
- MAILBOX
- IPC message protocol
- Shared memory management
- DSP processor management/controlIt 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.
Quoted 16 lines
Quoted 1 line
- DSP TASK/NODE, STREAM management
This has to be platform specific.
Quoted 2 lines
- 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.
Quoted 6 lines
- 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)
Quoted 6 lines
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 :)
Quoted 8 lines
Quoted 3 lines
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