On Wed, Nov 25, 2015 at 02:24:16PM -0600, Rob Herring wrote: > On Wed, Nov 25, 2015 at 11:59:37AM -0800, Jin Qian wrote: > > From: Greg Hackmann <ghackmann@xxxxxxxxxx> > > > > Signed-off-by: Greg Hackmann <ghackmann@xxxxxxxxxx> > > (cherry picked from commit 3c56d07eb796066530e93a40e74dea3bc59bf4cf) > > Signed-off-by: Jin Qian <jinqian@xxxxxxxxxxx> > > --- > > Documentation/devicetree/bindings/goldfish/pipe.txt | 17 +++++++++++++++++ > > drivers/platform/goldfish/goldfish_pipe.c | 10 +++++++++- > > 2 files changed, 26 insertions(+), 1 deletion(-) > > create mode 100644 Documentation/devicetree/bindings/goldfish/pipe.txt > > > > diff --git a/Documentation/devicetree/bindings/goldfish/pipe.txt b/Documentation/devicetree/bindings/goldfish/pipe.txt > > new file mode 100644 > > index 0000000..6d3801e > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/goldfish/pipe.txt > > @@ -0,0 +1,17 @@ > > +Android Goldfish QEMU Pipe > > + > > +Andorid pipe virtual device generated by android emulator. > > The binding may be trivial, but there's a bigger question of whether > this is the right long term direction. For example is upstream QEMU > going to take all the Android pipe stuff? Couldn't virtio be used here > as the transport? > The Android Pipe is not a very likely candidate for upstream QEMU, no. We are working on a TCG implementation of virtio-vsock (http://qemu-project.org/Features/VirtioVsock) which we think should be a suitable drop-in replacement for the Android pipe. We have yet to measure performance differences between the two, especially in the context of 3D graphics, though. But I wonder if that should really block this from being merged? The support may not be in QEMU but it's in the Android emulator and it would be a less broken implementation with these patches in the kernel than without, I think. -Christoffer -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html