greybus-dev

greybus-dev@lists.linaro.org

5 participants
687 discussions

[PATCH 0/2] staging: greybus: loopback fixes and updates

by Bryan O'Donoghue

Two simple patches here resulting from using greybus on gbsim and developing support for async. I found a bug in the user-space tool and while doing that decided to update the kernel thread to be better behaved when waiting for test completions. Bryan O'Donoghue (2): staging: greybus: loopback: use gb_loopback_async_wait_all don't spin staging: greybus: loopback_test: Fix race preventing test completion drivers/staging/greybus/loopback.c | 12 ++++++++++++ drivers/staging/greybus/tools/loopback_test.c | 10 +--------- 2 files changed, 13 insertions(+), 9 deletions(-) -- 2.7.4

9 years, 1 month

New Development

by Alex Elder

OK now that we have lists and IRC in place, it's time to start using them. Bryan (at least) has posted some patches for review but if Greybus is going to provide some greater long-term usefulness it will need to be adapted to be more easily used in contexts outside Project Ara. There was some informal conversation about this at ELCE. I have a few of my own thoughts but mainly I just want to get some discussion started to see if we have some pieces we can agree on, and take things from there. Here's a short summary of what's below: - Retargeting Greybus for use in IoT seems reasonable - We will need to adjust the abstract model currently implemented for Greybus to match the new target - Certain core functionality should be useful as-is; but some other features will need to be re-thought and redefined. - We will need to evolve the Greybus kernel code to define what is truly "core" functionality, and what that core needs from its environment. - We will need to ensure the Greybus API is stable, and that our versioning design is sound. One thing that came up multiple times in October was the notion that Greybus could serve as the basis for communication among entities in an Internet of Things system. I agree with this, at least in part. We have set up a system with some well-defined mechanisms for encapsulating messages, along with a model of remote procedure calls that provide a pretty robust way of getting things done across a network. The core code implements a lot of features (like timeouts and message cancellation) that are very useful, and which should really be done in a generic way. We've got code and conventions in the existing protocol drivers that provide good examples of how to use the core functionality. I think it's reasonable to pursue adapting Greybus to be usable in IoT environments. In any case, one thing that occurred to me during that week and those discussions was that we really need to define a new *target* for Greybus. That is, we no longer have the Ara phone as the hardware target, and we need to somehow define another ultimate goal for the hardware or environment in which Greybus operates. This should be more abstract than a hardware definition; instead it ought to define properties of and services provided by the entities communicating in a Greybus system. In some ways we already have that (Interfaces and Modules are abstract, but the details of what they represent may no longer match what is required). I think the things that Greybus defines now that can be pretty universally useful are the core concepts: - generic Greybus host device driver interface - connections with fixed protocols that define how messages carried over them are interpreted - the format of messages, and the generic message header - the overall messaging model, including sending, receiving cancelling messages - the operations RPC model, including completion semantics (asynchronous completion, unidirectional operations, first error result prevails, and the ability to have multiple outstanding operations) >From there we get into some things that are almost certainly useful, but there may need to be some changes: - The grouping of connections into bundles, which attach to Linux device drivers. (I think we need this, but there remains some work to do, especially in relation to the next item.) - Manifests to describe module/interface functionality - Control connection and how it's used And we can keep going into other things that become more and more likely to be unnecessary or just plain wrong when we are targeting something different from an Ara phone: - SVC and the SVC protocol The above is not at all exhaustive; I just wanted to try to identify a few specific things we can maybe start to agree on. Currently, the control protocol and SVC protocol are very much biased toward the Ara hardware. (Other protocols are too, like time sync and maybe firmware update.) Furthermore, pieces of these have necessarily made their way into core Greybus code. As we define a new non-Ara target, we need to figure out what parts really belong in the Greybus core, and which things need to be supplied either by external entities or by protocol drivers. One way to do that might be to implement the core code as a library, but to be honest I think the real work lies in teasing things apart so the core can be defined to supply certain well-known services, with hooks to allow other capabilities. For a (contrived) example of what I mean, we may need to provide hooks for setting up connection routing rather than implementing it in the core code. In any case, I think we need to look at what constitutes the true "core" of Greybus services and what that core needs from its environment in order to be used. If Greybus is going to provide a more general service we need to ensure it provides a stable API. We have structured things this way since the beginning, but I fear we may have gotten sloppy because we basically always packaged everything together. As it is, all the versioning is in place but to my knowledge we've never really tested it to make sure it works. I had another point which I've now forgotten... In any case, I really just hope to get some conversation going. What do you think? -Alex

9 years, 1 month

Android Things

by Karim Yaghmour

JFYI: https://developer.android.com/things/index.html There's no reason those APIs aren't tunneled over Greybus: https://developer.android.com/things/sdk/pio/index.html Oh wait, I've seen that somewhere before. -- Karim Yaghmour CEO - Opersys inc. / www.opersys.com http://twitter.com/karimyaghmour

9 years, 1 month

[PATCH 0/5] buildroot-overlay: Add loopback test utility support to buildroot overlay

by Bryan O'Donoghue

This set of changes adds support for building the greybus loopback_test utility from drivers/staging/greybus/tools, adds support for starting gbsim in loopback mode with associated shortcuts/manifests and enables building of the greybus loopback_test utility by default in the buildroot overlay. For simplicity I've setup a branch on github and already sent Rui a pull request. https://github.com/bryanodonoghue/ara_buildroot_x86_64/tree/master%2Bloopba… Bryan O'Donoghue (5): package: add greybus_loopback_test package bin: Add a loopback shortcut to /bin manifest: add loopback to the set of manifest files defconfig: enable loopback_test in the staging defconfig readme: add loopback to the set of listed commands Config.in | 1 + README.md | 1 + board/ara/overlay/bin/loopback | 1 + .../etc/manifests/simple-loopback-module.mnfb | Bin 0 -> 132 bytes configs/ara_qemu_x86_64_staging_next_defconfig | 1 + package/greybus_loopback_test/Config.in | 6 +++++ .../greybus_loopback_test/greybus_loopback_test.mk | 25 +++++++++++++++++++++ 7 files changed, 35 insertions(+) create mode 120000 board/ara/overlay/bin/loopback create mode 100644 board/ara/overlay/etc/manifests/simple-loopback-module.mnfb create mode 100644 package/greybus_loopback_test/Config.in create mode 100644 package/greybus_loopback_test/greybus_loopback_test.mk -- 2.7.4

9 years, 2 months

Re: [greybus-dev] Greybus Future

by Alex Elder

On 10/31/2016 08:50 AM, Alex Elder wrote: > The Greybus kernel code, developed as part of Google's Project Ara, > is in the upstream Linux kernel tree (under drivers/staging). The > cancellation of that project makes the future for Greybus a bit less > certain. There is interest among the core developers of Greybus > (and others) to do what we can to preserve the value of the Greybus > implementation for use beyond its original target platform. For > that to have any chance of success, we need to establish some > organization, and basically form a community of developers and > interested parties. At long last I can tell you I've arranged to get a mailing list and IRC channel set up for Greybus development. The e-mail address is: greybus-dev(a)lists.linaro.org This list is intended to handle all development discussion for Greybus and related topics (like gbsim and manifesto), and this includes patch traffic. Please add yourself to the mailing list here: https://lists.linaro.org/mailman/listinfo/greybus-dev Archives of traffic on the list will be maintained here: https://lists.linaro.org/pipermail/greybus-dev The IRC channel is on Freenode, named #greybus. I believe it too is logged (and if it is not now, we'll arrange for it to be). We will continue to use the git repositories on Github: https://github.com/projectara There is no Wiki or other web page, nor other resources like bug tracking or a patchwork instance. In time we may add these. For anyone previously associated with Project Ara, please note that the old e-mail lists and IRC channel will be shut down at some future date (perhaps at the end of this year). Any questions, please contact me. Thanks. -Alex > I'm proposing below a few things, which I'll implement this week > unless I hear people express strong opposition (or clearly better > suggestions). If you have comments, please say something. > > Git repositories. Public git repositories related to Project Ara > are all hosted here: > https://github.com/projectara > At this time I see no reason to move away from this, but it would > not surprise me if we decided to host the code and documentation > somewhere else at some future date. > > Mailing List. Because the Greybus kernel code sits in the staging > tree, mail about it should go to the driver-devel mailing list > (devel(a)driverdev.osuosl.org). I know that some people prefer better > mail filters rather than more mailing lists, but I think Greybus > discussion warrants a separate list. Its code spans multiple code > bases, and I think we're going to need some dedicated and ongoing > strategy and design discussions. So I'd like to create a Greybus > mailing list as a home for all Greybus-related discussion, including > patch traffic. My suggestion is to create a majordomo list: > greybus(a)kernel.org > > Patchwork. In the past I have found Patchwork to be a very useful > tool in managing incoming patches. I'd like to set up a patchwork > instance for Greybus, monitoring the greybus mailing list, again > at kernel.org. > > Wiki page. If we want a Wiki page, we could set one up at > kernel.org. Thoughts? > > Web home page. I have secured the "greybus.org" domain, so if there > is any value in populating that page it could serve as the home page > for the project. It currently has no content. > > Are there any other important resources I've missed? Once we get > a list going (or not) I've got a few other things to talk about. > > Thanks. > > -Alex > > PS I have addressed this message to a set of interested people > whose e-mail addresses I knew; the set is definitely incomplete. > This will form the initial membership of the mailing list. If > you do not want to be on that list, or if you know others I > should include, please send me contact information by private > message. >

9 years, 2 months

[PATCH 0/6] drivers/staging/greybus: add async operations

by Bryan O'Donoghue

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-V4: Fix bug in loopback conversion - Mitch Tasman V2-V3: 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-V2: 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 (6): staging: greybus/operation: add delayed worker for async timeouts staging: greybus/operation: add generic asynchronous operation support staging: greybus/operation: add async_private data with get/set accessors staging: greybus/loopback: convert loopback to use generic async operations staging: greybus/loopback: convert to use msecs internally staging: greybus/loopback: Hold gb->mutex across loopback operations drivers/staging/greybus/loopback.c | 190 ++++++++---------------------------- drivers/staging/greybus/operation.c | 65 ++++++++++++ drivers/staging/greybus/operation.h | 18 ++++ 3 files changed, 126 insertions(+), 147 deletions(-) -- 2.7.4

9 years, 2 months

Welcome!

by Alex Elder

Hi there. This is Eddie, your shipboard computer, and I'm feeling just great, guys, and I know I'm just going to get a bundle of kicks out of any program you care to run through me.

9 years, 2 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

greybus-dev