diff for duplicates of <51779304.4040003@st.com> diff --git a/a/1.txt b/N1/1.txt index 7910451..9fc675b 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -52,7 +52,7 @@ changed... >>> .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. >> > Not really. The TI's api does buffer requests from a client but it > does not tell the client when the message is actually sent to the diff --git a/a/content_digest b/N1/content_digest index 762635d..6d6553f 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -4,10 +4,25 @@ "ref\0CABb+yY1x4x_A+QtGG9ohsLPgs8c3nEVnd_ExJBGOOR8=6YLPFA@mail.gmail.com\0" "ref\037C860A02101E749A747FA2D3C1E3C504A63B4@DLEE11.ent.ti.com\0" "ref\0CAJe_ZhehnniZd730jjiOLrHozq8TOJZgFYLqUe4KqgBiQEu8PA@mail.gmail.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 10:08:36 +0200\0" - "To\0linux-arm-kernel@lists.infradead.org\0" + "To\0Jassi Brar <jaswinder.singh@linaro.org>\0" + "Cc\0Anna" + Suman <s-anna@ti.com> + Jassi Brar <jassisinghbrar@gmail.com> + Ohad Ben-Cohen (ohad@wizery.com) <ohad@wizery.com> + Stephen Rothwell <sfr@canb.auug.org.au> + Andy Green (andy.green@linaro.org) <andy.green@linaro.org> + Russell King <linux@arm.linux.org.uk> + Arnd Bergmann <arnd@arndb.de> + Tony Lindgren <tony@atomide.com> + Greg Kroah-Hartman <gregkh@linuxfoundation.org> + Linus Walleij <linus.walleij@linaro.org> + Rafael J. Wysocki <rafael.j.wysocki@intel.com> + Linux Kernel Mailing List <linux-kernel@vger.kernel.org> + Omar Ramirez Luna (omar.ramirez@copitl.com) <omar.ramirez@copitl.com> + " linux-arm-kernel@lists.infradead.org <linux-arm-kernel@lists.infradead.org>\0" "\00:1\0" "b\0" "Hi Jassi,\n" @@ -64,7 +79,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\342\200\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" "> Not really. The TI's api does buffer requests from a client but it\n" "> does not tell the client when the message is actually sent to the\n" @@ -138,4 +153,4 @@ "> Regards,\n" > Jassi -19c6360a1d1af1fa10d623730cce68078d3913deda6276143e4fdf60f968240c +a9508e28458bb3b997ec41e7e85767618571b239dd2d34f203bc72f87868d4ad
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.