V3:
Picard: "Let's make sure history never forgets the name ... Enterprise."
Drop gb_operation_cancel_async. The sync version works just as well - Johan
V2:
Scotty : "What are you standing around for - do you not know a jailbreak
when you see one" ?
Making sure to run format-patch against the right tree this time..
Updated meta-comments to highlight adding a generic async timeout - Johan
Captured the result code of schedule_work/queue_work - Bryan
Drop reference count on failure to submit schedule_work/queue_work - Bryan
Added timeout suffix back to new gb_operation_request_send - Johan/Greg
Updated Signed-off-by to my nexus-software.ie address - Bryan
Iterated requisite Star Trek Quote - Bryan/Johan
V4-private -> V1-public:
McCOY: You've got him, Jim! You've got him where you want him.
This patchset adds async operations to greybus-core. Rather than have
different drivers do variations on the same theme of launching and timing
out asynchronous operations, it makes sense instead to provide this
functionality via greybus-core.
This patchset makes it possible to launch asynchronous operations and have
the completion callback for an operation indicate -ETIMEDOUT for timeouts
without drivers having to manage that locally. This set doesn't convert the
existing synchronous operations away from
wait_for_completion_interruptible_timeout() since that would involve adding
an extra work-queue item to each synchronous call, with no added benefit
for synchronous operations. Synchronous operations can already detect
-ETIMEDOUT by blocking on the synchronous send operations, asynchronous
operations and the driver associated with those operations OTOH must
implement a completion handler. The main improvement this patchset makes is
to pass the -ETIMEDOUT completion status into that completion handler -
hiding the setup/timeout of operations away from a driver-level and into a
core-level set of logic.
Loopback as an example can have lots and lots of redundant code removed and
given we previously had some in-flight effort to add asynchronous
operations to SDIO it makes sense to move the generic types of things we
need to do on the asynchronous path into greybus-core so that SDIO and
other bundle drivers can reuse instead of reimplement asynchronous
operations.
Note: we had approximately three internal versions of this on Project-Ara.
Here's the log for completeness.
V3-private -> V4-private:
Fix bug in loopback conversion - Mitch Tasman
V2-private -> V3-private:
remotes/ara-main/sandbox/bodonoghue/ara-main-current+async_op3
Drop patch #6 converting sync operations to new t/o structure. Johan had a
concern about doing an in-depth analysis on that change and considering our
compressed timelines now, this analysis won't happen. OTOH the new async
API is the right thing for loopback and for potential later greybus
users/implementers to reuse.
Although it wasn't part of the motive for this change - I observe slightly
better performance than baseline with loopback tests with this change in
place - which shouldn't be surprising since we have less aggregate context
switching for operation timeouts.
V1-private -> V2-private:
Rename async_private => private - Greg
gb_operation_request_send_async_timeout ->
gb_operation_request_send_async() - Greg
Using existing gb_operation_completion_wq - Viresh
Split out gb_operation_cancel() - timeout need not wait synchronously on
cancellation queue - Bryan
Move timeout to work-queue - Greg/Viresh
cancel timeout workqueue @ operation completion point - Viresh/Bryan
Bryan O'Donoghue (4):
staging: greybus: operation: add generic asynchronous timeout
operation support
staging: greybus: operation: add private data with get/set accessors
staging: greybus: loopback: convert loopback to use generic async
operations
staging: greybus: loopback: convert to use msecs internally
drivers/staging/greybus/loopback.c | 181 ++++++++----------------------------
drivers/staging/greybus/operation.c | 66 +++++++++++++
drivers/staging/greybus/operation.h | 18 ++++
3 files changed, 123 insertions(+), 142 deletions(-)
--
2.7.4
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
