diff for duplicates of <51778C3B.7010501@st.com> diff --git a/a/1.txt b/N1/1.txt index 6a9e006..89e8839 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -109,7 +109,7 @@ with all platforms. >> .tx_done(mssg) on the client. If some h/w doesn't have RTR assertion interrupt, >> the API should provide optional feature to poll the controller periodically. > -> Some of these are already part of the mailbox ops. FWIW, I don?t see a need for a .tx_done callback, as this state can really be maintained by the driver implementation itself. The mailbox_msg_send can return an error appropriately based on whether the h/w is ready or not. The current code has the support for queuing up a certain number of messages in case the h/w is busy, but I am planning to change this to a device-based property so that they can choose if it needs that support or not. +> Some of these are already part of the mailbox ops. FWIW, I don’t see a need for a .tx_done callback, as this state can really be maintained by the driver implementation itself. The mailbox_msg_send can return an error appropriately based on whether the h/w is ready or not. The current code has the support for queuing up a certain number of messages in case the h/w is busy, but I am planning to change this to a device-based property so that they can choose if it needs that support or not. > >> >> (d) The 'struct mailbox_msg' should be just an opaque void* - the client/protocol @@ -139,4 +139,4 @@ Loic > This series missed the 3.9 merge window, and is currently slated for getting merged into 3.10. The PL320 made it into 3.9 itself (I wasn't aware of it until I saw it in mainline) and created the drivers/mailbox folder. I would think it would be relatively straight-forward to adopt it to the mailbox API, as it has only 3 API. We should be doing incremental changes on top of this series, as most of the base API would still be the same. The current series is helping out with couple of efforts, the breaking up of the PRCMU code and on the multiplatform support for OMAP with mailbox enabled. We can definitely collaborate on the improvements. Andy Green would also be interested, as he is also looking into adopting the mailbox API. > > Regards -> Suman +> Sumanÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a¢f£¢·hšïêÿ‘êçz_è®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨èÚ&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥ diff --git a/a/content_digest b/N1/content_digest index 96e1fcc..332d6fc 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -3,10 +3,24 @@ "ref\037C860A02101E749A747FA2D3C1E3C504A5DF7@DLEE11.ent.ti.com\0" "ref\0CABb+yY1x4x_A+QtGG9ohsLPgs8c3nEVnd_ExJBGOOR8=6YLPFA@mail.gmail.com\0" "ref\037C860A02101E749A747FA2D3C1E3C504A63B4@DLEE11.ent.ti.com\0" - "From\0loic.pallardy@st.com (Loic PALLARDY)\0" - "Subject\0[PATCHv3 00/14] drivers: mailbox: framework creation\0" + "From\0Loic PALLARDY <loic.pallardy@st.com>\0" + "Subject\0Re: [PATCHv3 00/14] drivers: mailbox: framework creation\0" "Date\0Wed, 24 Apr 2013 09:39:39 +0200\0" - "To\0linux-arm-kernel@lists.infradead.org\0" + "To\0Anna" + " Suman <s-anna@ti.com>\0" + "Cc\0Jassi Brar <jassisinghbrar@gmail.com>" + Linux Kernel Mailing List <linux-kernel@vger.kernel.org> + linux-arm-kernel@lists.infradead.org <linux-arm-kernel@lists.infradead.org> + Greg Kroah-Hartman <gregkh@linuxfoundation.org> + Linus Walleij <linus.walleij@linaro.org> + Russell King <linux@arm.linux.org.uk> + Arnd Bergmann <arnd@arndb.de> + Tony Lindgren <tony@atomide.com> + Rafael J. Wysocki <rafael.j.wysocki@intel.com> + Stephen Rothwell <sfr@canb.auug.org.au> + Andy Green (andy.green@linaro.org) <andy.green@linaro.org> + Ohad Ben-Cohen (ohad@wizery.com) <ohad@wizery.com> + " Omar Ramirez Luna (omar.ramirez@copitl.com) <omar.ramirez@copitl.com>\0" "\00:1\0" "b\0" "Hi Jassi, Suman,\n" @@ -120,7 +134,7 @@ ">> .tx_done(mssg) on the client. If some h/w doesn't have RTR assertion interrupt,\n" ">> the API should provide optional feature to poll the controller periodically.\n" ">\n" - "> Some of these are already part of the mailbox ops. FWIW, I don?t see a need for a .tx_done callback, as this state can really be maintained by the driver implementation itself. The mailbox_msg_send can return an error appropriately based on whether the h/w is ready or not. The current code has the support for queuing up a certain number of messages in case the h/w is busy, but I am planning to change this to a device-based property so that they can choose if it needs that support or not.\n" + "> Some of these are already part of the mailbox ops. FWIW, I don\303\242\302\200\302\231t see a need for a .tx_done callback, as this state can really be maintained by the driver implementation itself. The mailbox_msg_send can return an error appropriately based on whether the h/w is ready or not. The current code has the support for queuing up a certain number of messages in case the h/w is busy, but I am planning to change this to a device-based property so that they can choose if it needs that support or not.\n" ">\n" ">>\n" ">> (d) The 'struct mailbox_msg' should be just an opaque void* - the client/protocol\n" @@ -150,6 +164,6 @@ "> This series missed the 3.9 merge window, and is currently slated for getting merged into 3.10. The PL320 made it into 3.9 itself (I wasn't aware of it until I saw it in mainline) and created the drivers/mailbox folder. I would think it would be relatively straight-forward to adopt it to the mailbox API, as it has only 3 API. We should be doing incremental changes on top of this series, as most of the base API would still be the same. The current series is helping out with couple of efforts, the breaking up of the PRCMU code and on the multiplatform support for OMAP with mailbox enabled. We can definitely collaborate on the improvements. Andy Green would also be interested, as he is also looking into adopting the mailbox API.\n" ">\n" "> Regards\n" - > Suman + "> Suman\303\277\303\264\303\250\302\272{.n\303\207+\302\211\302\267\302\237\302\256\302\211\302\255\302\206+%\302\212\303\213\303\277\302\261\303\251\303\235\302\266\027\302\245\302\212w\303\277\302\272{.n\303\207+\302\211\302\267\302\245\302\212{\302\261\303\276G\302\253\302\235\303\251\303\277\302\212{ay\302\272\035\303\212\302\207\303\232\302\231\303\253,j\a\302\255\302\242f\302\243\302\242\302\267h\302\232\302\217\303\257\302\201\303\252\303\277\302\221\303\252\303\247z_\303\250\302\256\003(\302\255\303\251\302\232\302\216\302\212\303\235\302\242j\"\302\235\303\272\032\302\266\033m\302\247\303\277\303\277\302\276\a\302\253\303\276G\302\253\302\235\303\251\303\277\302\242\302\270?\302\231\302\250\303\250\302\255\303\232&\302\243\303\270\302\247~\302\217\303\241\302\266iO\302\225\303\246\302\254z\302\267\302\232v\303\230^\024\004\032\302\266\033m\302\247\303\277\303\277\303\203\f\303\277\302\266\303\254\303\277\302\242\302\270?\302\226I\302\245" -0d908c1e5ab209e45bee934645d39eed0f31602222a95874dcd669f0cade7f6d +1957018648670368709d462767f27c00f6f703b57badb507d27068d21b63b2e8
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.