On 16/12/16 16:10, Johan Hovold wrote: > On Fri, Dec 16, 2016 at 03:55:07PM +0000, Bryan O'Donoghue wrote: >> On 16/12/16 15:00, Johan Hovold wrote: >>> But in a static setup, you control what firmware you load, so you don't >>> need it to be self-describing. >> That depends. >> >> Right now I don't see a good method for kernel and a firmware to agree >> on ownership of GPIOs (and other shared resources) for example. I know >> virtio/rproc (or some combination of the two) is supposed to be able to >> do this. >> >> Just transmitting a manifest over an RPC link seems much simpler than >> what I've seen of virtio/rproc so far - and I'm not convinced the two >> together can describe as much as a manifest file. > But remember that manifests come *from* the firmware (remote entity, > module), but here it sounds like you want to be able pass a device-tree > fragment or similar *to* the firmware. Manifests are used to describe > what resources the modules provide, which wouldn't necessarily help in > this case which seems to be about configuring the module (co-processor). > Another way to do what we want to do is to tell a firmware which pins it owns (consuming dts) yes absolutely, fair point. I was thinking of the problem from the perspective of a firmware engineer who would want to write his/her software - have it launch and then request the resources it was assigned. For people doing projects with these types of boards they are typically breaking out to these co-processors to do 'real time' applications (meaning they want it done fast - maybe even on a deadline :) ) and those types of development patterns would probably just want to assign a few pins in their firmware, load the image and have the kernel/firmware negotiate. I completely concede another approach (and a more Linuxly way of doing it) is to describe the resource allocation in devicetree. Didn't we have some sort of plan to unify manifests and device-tree overlays ? _______________________________________________ greybus-dev mailing list greybus-dev@xxxxxxxxxxxxxxxx https://lists.linaro.org/mailman/listinfo/greybus-dev