Re: [GIT PULL] mailbox driver framework for v3.10 merge window
On Sun, Jun 16, 2013 at 03:14:01PM -0500, Suman Anna wrote: Hi Tan, On 06/14/2013 04:32 AM, LF.Tan wrote: Hi Suman Thanks for your reply. I have took a look the patches you've mentioned in [1]. It is totally new framework from what is located in linux-next git tree now. Yes, that is correct. The framework is different, but functionality wise, you should be able to achieve the same (and a bit more). I noticed that we had accidentally merged the previous version of the framework, since it was never intended to sit in linux-next given the redesign underway. I dropped it on Friday, so it wasn't included in the latest build of linux-next, and should not be part of it from here on out. -Olof -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] mailbox driver framework for v3.10 merge window
Hi Tan, On 06/14/2013 04:32 AM, LF.Tan wrote: Hi Suman Thanks for your reply. I have took a look the patches you've mentioned in [1]. It is totally new framework from what is located in linux-next git tree now. Yes, that is correct. The framework is different, but functionality wise, you should be able to achieve the same (and a bit more). Is this going to be final version for the framework? I am going to start to develop the mailbox driver soon and I hope I can use the framework which is stable (at least not the major changes). Do you think I should start development based on [1]? Jassi is working through a newer version of the patches, so there would be minor changes once the newer patchset is ready, but the core framework/functionality shouldn't change much from above. Do take a look at the framework (much of the explaination in header files) and see how it fits your driver needs. regards Suman On Thu, Jun 13, 2013 at 11:59 PM, Suman Anna s-a...@ti.com mailto:s-a...@ti.com wrote: Tan, On 06/13/2013 06:01 AM, LF.Tan wrote: Hi I would like to add a new mailbox driver with this mailbox framework. May I know this mailbox framework will available in kernel v3.10 or it is pushed to v3.11? Thanks. This framework is dropped from v3.10 as this is being reworked and will be replaced with a different one that adds atomic context and tx callback support [1]. Jassi is working on a newer patchset currently for this, but you should be able to get started using [1]. regards Suman [1] http://marc.info/?l=linux-kernelm=136782509309470w=2 On Friday 03 May 2013 15:39:42 Linus Walleij wrote: On Fri, May 3, 2013 at 3:25 PM, Arnd Bergmann a...@arndb.de mailto:a...@arndb.de mailto:a...@arndb.de mailto:a...@arndb.de wrote: On Thursday 02 May 2013 17:09:07 Suman Anna wrote: I do not know how much of an impact it is for the ST driver as the series adds the driver, and would have to wait until the RFC is sorted out otherwise. I think I'd prefer to drop the branch from the 3.10 queue then and let you all work out a common approach for 3.11. Olof, any other input? This will block all refactoring of the PRCMU driver, which Loic is working on, and also Ulf Hansson's clock driver. It is basically the key to breaking that driver apart and distributing it out into the proper subsystems. Loic has a big patch series for that for next merge window which will then have to be postponed, or queued on top of the mailbox work when finished. But maybe it's the right thing to do if the subsystem needs more work? I have no clear opinion on this, Loic, Ulf? I think we can queue them together. I'm certainly fine with the mailbox subsystem getting merged through both the mfd and arm-soc trees to avoid conflicts. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] mailbox driver framework for v3.10 merge window
Tan, On 06/13/2013 06:01 AM, LF.Tan wrote: Hi I would like to add a new mailbox driver with this mailbox framework. May I know this mailbox framework will available in kernel v3.10 or it is pushed to v3.11? Thanks. This framework is dropped from v3.10 as this is being reworked and will be replaced with a different one that adds atomic context and tx callback support [1]. Jassi is working on a newer patchset currently for this, but you should be able to get started using [1]. regards Suman [1] http://marc.info/?l=linux-kernelm=136782509309470w=2 On Friday 03 May 2013 15:39:42 Linus Walleij wrote: On Fri, May 3, 2013 at 3:25 PM, Arnd Bergmann a...@arndb.de mailto:a...@arndb.de wrote: On Thursday 02 May 2013 17:09:07 Suman Anna wrote: I do not know how much of an impact it is for the ST driver as the series adds the driver, and would have to wait until the RFC is sorted out otherwise. I think I'd prefer to drop the branch from the 3.10 queue then and let you all work out a common approach for 3.11. Olof, any other input? This will block all refactoring of the PRCMU driver, which Loic is working on, and also Ulf Hansson's clock driver. It is basically the key to breaking that driver apart and distributing it out into the proper subsystems. Loic has a big patch series for that for next merge window which will then have to be postponed, or queued on top of the mailbox work when finished. But maybe it's the right thing to do if the subsystem needs more work? I have no clear opinion on this, Loic, Ulf? I think we can queue them together. I'm certainly fine with the mailbox subsystem getting merged through both the mfd and arm-soc trees to avoid conflicts. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] mailbox driver framework for v3.10 merge window
On Thursday 02 May 2013 17:09:07 Suman Anna wrote: On 04/28/2013 11:07 PM, Jassi Brar wrote: Now, we could either call it (effectively the TI's framework with quirks for STE) as the Common API and then dismantle and convert it patch by patch (authors and I seem to agree many things need to be changed and implemented). OR we do it reasonably right the first time even if that means yet another release. IMHO we should go for slow but steady thing. I think it is your call here, either of the above approaches would definitely involve some rework on the framework as well as both the OMAP ST mailboxes. Atleast for OMAP, the code exists in kernel but disabled currently due to the multi-platform support. It is pending on the move to drivers/mailbox folder, and can be enabled just with the first 3 patches (and another one for renaming generic mailbox.c/.h back to omap_mailbox.c/.h files if we go the RFC approach) in the series (irrespective of the framework). TI DSP/Bridge would remain broken because of the omap dmtimer api dependencies on multi-platform. I do not know how much of an impact it is for the ST driver as the series adds the driver, and would have to wait until the RFC is sorted out otherwise. I think I'd prefer to drop the branch from the 3.10 queue then and let you all work out a common approach for 3.11. Olof, any other input? Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] mailbox driver framework for v3.10 merge window
On Fri, May 3, 2013 at 3:25 PM, Arnd Bergmann a...@arndb.de wrote: On Thursday 02 May 2013 17:09:07 Suman Anna wrote: I do not know how much of an impact it is for the ST driver as the series adds the driver, and would have to wait until the RFC is sorted out otherwise. I think I'd prefer to drop the branch from the 3.10 queue then and let you all work out a common approach for 3.11. Olof, any other input? This will block all refactoring of the PRCMU driver, which Loic is working on, and also Ulf Hansson's clock driver. It is basically the key to breaking that driver apart and distributing it out into the proper subsystems. Loic has a big patch series for that for next merge window which will then have to be postponed, or queued on top of the mailbox work when finished. But maybe it's the right thing to do if the subsystem needs more work? I have no clear opinion on this, Loic, Ulf? Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] mailbox driver framework for v3.10 merge window
On Friday 03 May 2013 15:39:42 Linus Walleij wrote: On Fri, May 3, 2013 at 3:25 PM, Arnd Bergmann a...@arndb.de wrote: On Thursday 02 May 2013 17:09:07 Suman Anna wrote: I do not know how much of an impact it is for the ST driver as the series adds the driver, and would have to wait until the RFC is sorted out otherwise. I think I'd prefer to drop the branch from the 3.10 queue then and let you all work out a common approach for 3.11. Olof, any other input? This will block all refactoring of the PRCMU driver, which Loic is working on, and also Ulf Hansson's clock driver. It is basically the key to breaking that driver apart and distributing it out into the proper subsystems. Loic has a big patch series for that for next merge window which will then have to be postponed, or queued on top of the mailbox work when finished. But maybe it's the right thing to do if the subsystem needs more work? I have no clear opinion on this, Loic, Ulf? I think we can queue them together. I'm certainly fine with the mailbox subsystem getting merged through both the mfd and arm-soc trees to avoid conflicts. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] mailbox driver framework for v3.10 merge window
On 05/02/2013 09:37 PM, Jassi Brar wrote: On 3 May 2013 03:39, Suman Anna s-a...@ti.com wrote: Hi Arnd, On 04/28/2013 11:07 PM, Jassi Brar wrote: Not to mean only talk and no do, I prepared another proposal that addressed all the concerns shared so far in the RFC http://www.spinics.net/lists/kernel/msg1523873.html (its not ready for primetime yet) And also converted the PL320 driver to the new API, unlike the pulled patchset which leaves that out in the cold. http://www.spinics.net/lists/kernel/msg1523874.html Yes, the current code is mainly interrupt-driven and supports only non-atomic context. We have a need to support atomic contexts and ipc controllers that do not have interrupt-based triggering. Supporting poll and client driven TX and atomic context is going to need big chunks of changes which we can avoid by doing them already. Plus a bottleneck with PL320, as Mark pointed out they can't afford any bigger latency, which will come from RX via notifier path. As Jassi pointed out, the RFC is not ready yet and there are still some contention points that needs to be sorted out (especially to maintain OMAP mailbox functionality). Apart from a few checkpatch fixes, a missing timer delete call and some testing with dummy client and controller drivers for various usecases, it's ready from my side. It worked at least as good as your API in our internal testing. Please do let me know which OMAP functionality are you worried about, I believe it could all still be done above this api. Mainly the splitting of bottom-half responsibility of the controller driver between mailbox and the client (or another in-between layer between my existing client (remoteproc driver), because of the support for only atomic context. Now, we could either call it (effectively the TI's framework with quirks for STE) as the Common API and then dismantle and convert it patch by patch (authors and I seem to agree many things need to be changed and implemented). OR we do it reasonably right the first time even if that means yet another release. IMHO we should go for slow but steady thing. I think it is your call here, either of the above approaches would definitely involve some rework on the framework as well as both the OMAP ST mailboxes. I am interested to know what changes do you anticipate in my proposed API. Not to mean it's perfect, but I thought I provided for all practical use-cases. I will provide feedback on the RFC thread, and we can continue the discussion on that thread. I will also share the link to my current work-in-progress branch so that you can see the design approach that I have taken. Yes, TI and STE would need re-work, but then as of now they are their own APIs upstream. And even with your proposal they would still need to be changed if we are to implement the desired features. What about PL320? The pl320_transmit function is identical to the present mailbox_msg_send_receive_no_irq, but that is a non-factor anyway since we would have changed the API. regards Suman -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] mailbox driver framework for v3.10 merge window
Hi Arnd, On 04/28/2013 11:07 PM, Jassi Brar wrote: Hello Arnd, On 9 April 2013 16:25, Arnd Bergmann a...@arndb.de wrote: On Thursday 04 April 2013, Anna, Suman wrote: OMAP and ST-Ericsson platforms are both using mailbox to communicate with some coprocessors. This series creates a consolidated framework, living under drivers/mailbox. The changes mainly contain: - create a mailbox framework independent from OMAP h/w - creates dbx500 mailbox driver for ST-Ericsson platforms - move the omap mailbox out of plat-omap/mach-omapX adapting to the new framework. - minor bug fixes in mailbox code Pulled into a new next/mailbox branch, to keep it separate from the existing subsystems. I am going to be a heavy user of the Mailbox API. And I have reviewed this API quite in detail. I pointed out many aspects that might have worked for TI's usage but are not going to be work on many platforms (including one of mine). Suman and Loic also acknowledged most (if not all) from 'generic' POV. Here is the thread ... http://www.spinics.net/lists/arm-kernel/msg239433.html Not to mean only talk and no do, I prepared another proposal that addressed all the concerns shared so far in the RFC http://www.spinics.net/lists/kernel/msg1523873.html (its not ready for primetime yet) And also converted the PL320 driver to the new API, unlike the pulled patchset which leaves that out in the cold. http://www.spinics.net/lists/kernel/msg1523874.html Yes, the current code is mainly interrupt-driven and supports only non-atomic context. We have a need to support atomic contexts and ipc controllers that do not have interrupt-based triggering. As Jassi pointed out, the RFC is not ready yet and there are still some contention points that needs to be sorted out (especially to maintain OMAP mailbox functionality). Now, we could either call it (effectively the TI's framework with quirks for STE) as the Common API and then dismantle and convert it patch by patch (authors and I seem to agree many things need to be changed and implemented). OR we do it reasonably right the first time even if that means yet another release. IMHO we should go for slow but steady thing. I think it is your call here, either of the above approaches would definitely involve some rework on the framework as well as both the OMAP ST mailboxes. Atleast for OMAP, the code exists in kernel but disabled currently due to the multi-platform support. It is pending on the move to drivers/mailbox folder, and can be enabled just with the first 3 patches (and another one for renaming generic mailbox.c/.h back to omap_mailbox.c/.h files if we go the RFC approach) in the series (irrespective of the framework). TI DSP/Bridge would remain broken because of the omap dmtimer api dependencies on multi-platform. I do not know how much of an impact it is for the ST driver as the series adds the driver, and would have to wait until the RFC is sorted out otherwise. regards Suman -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] mailbox driver framework for v3.10 merge window
On 3 May 2013 03:39, Suman Anna s-a...@ti.com wrote: Hi Arnd, On 04/28/2013 11:07 PM, Jassi Brar wrote: Not to mean only talk and no do, I prepared another proposal that addressed all the concerns shared so far in the RFC http://www.spinics.net/lists/kernel/msg1523873.html (its not ready for primetime yet) And also converted the PL320 driver to the new API, unlike the pulled patchset which leaves that out in the cold. http://www.spinics.net/lists/kernel/msg1523874.html Yes, the current code is mainly interrupt-driven and supports only non-atomic context. We have a need to support atomic contexts and ipc controllers that do not have interrupt-based triggering. Supporting poll and client driven TX and atomic context is going to need big chunks of changes which we can avoid by doing them already. Plus a bottleneck with PL320, as Mark pointed out they can't afford any bigger latency, which will come from RX via notifier path. As Jassi pointed out, the RFC is not ready yet and there are still some contention points that needs to be sorted out (especially to maintain OMAP mailbox functionality). Apart from a few checkpatch fixes, a missing timer delete call and some testing with dummy client and controller drivers for various usecases, it's ready from my side. It worked at least as good as your API in our internal testing. Please do let me know which OMAP functionality are you worried about, I believe it could all still be done above this api. Now, we could either call it (effectively the TI's framework with quirks for STE) as the Common API and then dismantle and convert it patch by patch (authors and I seem to agree many things need to be changed and implemented). OR we do it reasonably right the first time even if that means yet another release. IMHO we should go for slow but steady thing. I think it is your call here, either of the above approaches would definitely involve some rework on the framework as well as both the OMAP ST mailboxes. I am interested to know what changes do you anticipate in my proposed API. Not to mean it's perfect, but I thought I provided for all practical use-cases. Yes, TI and STE would need re-work, but then as of now they are their own APIs upstream. And even with your proposal they would still need to be changed if we are to implement the desired features. What about PL320? Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] mailbox driver framework for v3.10 merge window
Hello Arnd, On 9 April 2013 16:25, Arnd Bergmann a...@arndb.de wrote: On Thursday 04 April 2013, Anna, Suman wrote: OMAP and ST-Ericsson platforms are both using mailbox to communicate with some coprocessors. This series creates a consolidated framework, living under drivers/mailbox. The changes mainly contain: - create a mailbox framework independent from OMAP h/w - creates dbx500 mailbox driver for ST-Ericsson platforms - move the omap mailbox out of plat-omap/mach-omapX adapting to the new framework. - minor bug fixes in mailbox code Pulled into a new next/mailbox branch, to keep it separate from the existing subsystems. I am going to be a heavy user of the Mailbox API. And I have reviewed this API quite in detail. I pointed out many aspects that might have worked for TI's usage but are not going to be work on many platforms (including one of mine). Suman and Loic also acknowledged most (if not all) from 'generic' POV. Here is the thread ... http://www.spinics.net/lists/arm-kernel/msg239433.html Not to mean only talk and no do, I prepared another proposal that addressed all the concerns shared so far in the RFC http://www.spinics.net/lists/kernel/msg1523873.html (its not ready for primetime yet) And also converted the PL320 driver to the new API, unlike the pulled patchset which leaves that out in the cold. http://www.spinics.net/lists/kernel/msg1523874.html Now, we could either call it (effectively the TI's framework with quirks for STE) as the Common API and then dismantle and convert it patch by patch (authors and I seem to agree many things need to be changed and implemented). OR we do it reasonably right the first time even if that means yet another release. IMHO we should go for slow but steady thing. Hi Suman, Hi Loic, Please feel free to object to anything you think I might have misrepresented. I am OK if you are not sure about my implementation either - we could co-work on a new one. Regards, -Jassi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] mailbox driver framework for v3.10 merge window
On Thursday 04 April 2013, Anna, Suman wrote: OMAP and ST-Ericsson platforms are both using mailbox to communicate with some coprocessors. This series creates a consolidated framework, living under drivers/mailbox. The changes mainly contain: - create a mailbox framework independent from OMAP h/w - creates dbx500 mailbox driver for ST-Ericsson platforms - move the omap mailbox out of plat-omap/mach-omapX adapting to the new framework. - minor bug fixes in mailbox code Pulled into a new next/mailbox branch, to keep it separate from the existing subsystems. As a note for you: when you send a pull request, please make sure that you use a tag that includes the changeset text (your description above), so I don't have to copy it from the email. I noticed that you do have a tag mailbox-for-v3.10 in your tree, but the pull request was for the branch with the same contents. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [GIT PULL] mailbox driver framework for v3.10 merge window
On Thursday 04 April 2013, Anna, Suman wrote: OMAP and ST-Ericsson platforms are both using mailbox to communicate with some coprocessors. This series creates a consolidated framework, living under drivers/mailbox. The changes mainly contain: - create a mailbox framework independent from OMAP h/w - creates dbx500 mailbox driver for ST-Ericsson platforms - move the omap mailbox out of plat-omap/mach-omapX adapting to the new framework. - minor bug fixes in mailbox code Pulled into a new next/mailbox branch, to keep it separate from the existing subsystems. As a note for you: when you send a pull request, please make sure that you use a tag that includes the changeset text (your description above), so I don't have to copy it from the email. I noticed that you do have a tag mailbox-for-v3.10 in your tree, but the pull request was for the branch with the same contents. Thanks Arnd. Yes, the tag is for the same SHA, and has the same comments as above. I understood the process only a bit later. Regards Suman -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] mailbox driver framework for v3.10 merge window
The following changes since commit f6161aa153581da4a3867a2d1a7caf4be19b6ec9: Linux 3.9-rc2 (2013-03-10 16:54:19 -0700) are available in the git repository at: git://github.com/sumananna/mailbox.git dbx500-prcmu-mailbox for you to fetch changes up to c497eba5247728c67ba0e0de0907723dd114134a: mailbox: fix invalid use of sizeof in mailbox_msg_send() (2013-03-23 15:04:14 +0800) -- OMAP and ST-Ericsson platforms are both using mailbox to communicate with some coprocessors. This series creates a consolidated framework, living under drivers/mailbox. The changes mainly contain: - create a mailbox framework independent from OMAP h/w - creates dbx500 mailbox driver for ST-Ericsson platforms - move the omap mailbox out of plat-omap/mach-omapX adapting to the new framework. - minor bug fixes in mailbox code This series is needed for the work currently being done on the PRCMU driver. -- Loic Pallardy (7): mailbox: rename omap_mbox in mailbox mailbox: create opened message type mailbox: change protection mechanisms mailbox: add shared memory mailbox type mailbox: add IRQF_NO_SUSPEND flag mailbox: add no_irq send message mailbox: create dbx500 mailbox driver Omar Ramirez Luna (2): mailbox: OMAP: introduce mailbox framework mailbox: split internal header from API header Suman Anna (5): mailbox: rename pl320-ipc specific mailbox.h ARM: OMAP2+: mbox: remove dependencies with soc.h mailbox/omap: check iomem resource before dereferencing it mailbox: check for NULL nb in mailbox_put mailbox: call request_irq after mbox queues are allocated Wei Yongjun (1): mailbox: fix invalid use of sizeof in mailbox_msg_send() .../devicetree/bindings/mailbox/dbx500-mailbox.txt | 27 + arch/arm/configs/omap1_defconfig | 3 +- arch/arm/mach-omap1/Makefile | 4 - arch/arm/mach-omap1/mailbox.c | 199 --- arch/arm/mach-omap2/Makefile | 3 - arch/arm/mach-omap2/devices.c | 13 +- arch/arm/mach-omap2/mailbox.c | 430 -- arch/arm/mach-omap2/omap_hwmod_2420_data.c | 12 + arch/arm/mach-omap2/omap_hwmod_2430_data.c | 11 + arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 11 + arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 13 + arch/arm/plat-omap/Kconfig | 16 - arch/arm/plat-omap/Makefile| 3 - arch/arm/plat-omap/include/plat/mailbox.h | 105 arch/arm/plat-omap/mailbox.c | 435 -- drivers/cpufreq/highbank-cpufreq.c | 2 +- drivers/mailbox/Kconfig| 41 ++ drivers/mailbox/Makefile | 5 + drivers/mailbox/mailbox-dbx500.c | 648 + drivers/mailbox/mailbox-omap1.c| 229 drivers/mailbox/mailbox-omap2.c| 370 drivers/mailbox/mailbox.c | 552 ++ drivers/mailbox/mailbox_internal.h | 70 +++ drivers/mailbox/pl320-ipc.c| 2 +- drivers/remoteproc/Kconfig | 3 +- drivers/remoteproc/omap_remoteproc.c | 36 +- drivers/staging/tidspbridge/Kconfig| 3 +- drivers/staging/tidspbridge/core/_tiomap.h | 2 +- drivers/staging/tidspbridge/core/chnl_sm.c | 8 +- drivers/staging/tidspbridge/core/io_sm.c | 5 +- drivers/staging/tidspbridge/core/tiomap3430.c | 6 +- drivers/staging/tidspbridge/core/tiomap3430_pwr.c | 6 +- drivers/staging/tidspbridge/core/tiomap_io.c | 9 +- .../tidspbridge/include/dspbridge/host_os.h| 2 +- include/linux/mailbox.h| 52 +- include/linux/pl320-ipc.h | 17 + include/linux/platform_data/mailbox-dbx500.h | 12 + include/linux/platform_data/mailbox-omap.h | 53 ++ 38 files changed, 2170 insertions(+), 1248 deletions(-) create mode 100644 Documentation/devicetree/bindings/mailbox/dbx500-mailbox.txt delete mode 100644 arch/arm/mach-omap1/mailbox.c delete mode 100644 arch/arm/mach-omap2/mailbox.c delete mode 100644 arch/arm/plat-omap/include/plat/mailbox.h delete mode 100644 arch/arm/plat-omap/mailbox.c create mode 100644 drivers/mailbox/mailbox-dbx500.c create mode 100644 drivers/mailbox/mailbox-omap1.c create mode 100644 drivers/mailbox/mailbox-omap2.c create mode 100644 drivers/mailbox/mailbox.c create mode 100644 drivers/mailbox/mailbox_internal.h create mode 100644 include/linux/pl320-ipc.h create mode 100644 include/linux/platform_data/mailbox-dbx500.h create mode 100644
