On Fri, Dec 16, 2016 at 04:22:02PM +0000, Bryan O'Donoghue wrote: > 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 ? Yes, but that was also in the module->AP direction, as a means to describe non-discoverable buses on the module (e.g. sensors on an i2c bus). Johan _______________________________________________ greybus-dev mailing list greybus-dev@xxxxxxxxxxxxxxxx https://lists.linaro.org/mailman/listinfo/greybus-dev
|