[platform-bus][aml-canvas] Add support for proxying SOC-specific protocols

This change adds support to the platform bus driver for proxying
SOC-specific protocols to platform devices without modifying the
platform bus source code. It also removes support for the Amlogic canvas
protocol from the platform bus driver and uses this new proxying support instead.

The Amlogic canvas driver is now split into two drivers:
the canvas implementation driver and the canvas proxy driver.
The implementation driver runs in the platform bus devhost and implements the main
functionality of the driver. The proxy driver runs in the devhosts of the
drivers that are clients of the canvas protocol and is responsible for proxying
the canvas protocol to the implementation driver.

To make this work we add a new protocol ZX_PROTOCOL_PLATFORM_PROXY
and add new support to ZX_PROTOCOL_PLATFORM_BUS.
In ZX_PROTOCOL_PLATFORM_BUS, the pbus_register_protocol() API now adds an
optional callback of type platform_proxy_cb_t. This callback handles
RPCs from a protocol proxy driver.

The new protocol ZX_PROTOCOL_PLATFORM_PROXY is used for protocol proxy drivers
to communicate with the platform bus in the client devhosts.
When the proxy driver loads, it calls platform_proxy_register_protocol()
to register its protocol implementation with the platform bus proxy driver.
When the client driver calls a protocol API implemented by the proxy driver,
the proxy driver calls platform_proxy_proxy() to proxy the protocol
to the implementation driver in the platform device devhost, via the channel
that connects the two devhosts.

Support for proxying the Amlogic canvas protocol is now removed from the
platform bus driver, since we are using this new mechanism instead.

Within the platform bus driver, we add a new class ProxyClient.
This is a subclass of ddk::Device that is used for binding the
protocol proxy drivers. In the case where a platform device relies on
SOC-specific protocols implemented using this new mechanism,
the platform bus proxy driver creates a PlatformProxyClient for each
of the protocols and waits for them all to register their protocols
via the ZX_PROTOCOL_PLATFORM_PROXY protocol before creating the
ProxyDevice object to bind the platform device driver.

Below illustrates the parts of the device tree is changed by this CL:

BEFORE:
[04:02:1] pid=1785 /boot/driver/platform-bus.so
<04:02:1> pid=2881 /boot/driver/platform-bus.proxy.so
[vim2-display] pid=2881 /boot/driver/vim-display.so
[display-controller] pid=2881 /boot/driver/display.so

AFTER:
[04:02:1] pid=1850 /boot/driver/platform-bus.so
<04:02:1> pid=3024 /boot/driver/platform-bus.proxy.so
[ProxyClient[7043414e]] pid=3024 /boot/driver/platform-bus.proxy.so
[aml-canvas-proxy] pid=3024 /boot/driver/aml-canvas.proxy.so
[ProxyDevice] pid=3024 /boot/driver/platform-bus.proxy.so
[vim2-display] pid=3024 /boot/driver/vim-display.so
[display-controller] pid=3024 /boot/driver/display.so

In the AFTER subtree, the platform proxy driver inserts a new root device that has
both the aml-canvas and vim2-display drivers as children.

TEST: manual testing on VIM2 and astro

Change-Id: Ibfa925948491fb3793dd934ee5737ace7903edb9

[dev][platform-bus] Use separate classes for platform devices and protocol implementation devices

The class PlatformDevice in the platform bus driver was used for two purposes:

1) To implement platform devices, which run in separate devhosts.
In this role the class did not need to implement the platform device protocol,
but instead responded to proxied requests via the rxrpc callback from the PlatformProxy
class in the other devhost.

2) To bind platform protocol implementation drivers, which run in the same devhost and do require
a local platform device protocol implementation.

To simplify the code, the PlatformDevice class implements use case 1), and a new class called
ProtocolDevice implements use case 2.

In addition, protocol implementation drivers are now given a restricted version of the
platform bus protocol that disables pbus_device_add() and pbus_protocol_device_add().
There is no good use case for protocol implementation drivers to use these,
so lets not allow it.

TEST: manual testing on qemu, VIM2 and gauss.

Change-Id: I2cbe1bf0d47fac00f37093275eee4db450776f78

[dev][platform-bus] Provide platform bus resources platform device children

Currently the platform bus allows creating a list of platform devices,
each running in a separate devhost.
These devices are provided by the bus with various resources
(MMIO buffers, interrupt handles, GPIOs, I2C channels, etc).
However we have use cases where a platform device may have child devices
that also need resources from the platform bus.

This change allows children of platform devices to access platform bus resources.
To do this, the board driver can pass a list of child devices via the pbus_dev_t
structure passed via pbus_device_add(). These children can also have children,
allowing for a tree of platform devices in the same devhost, rather than just one.
To facilitate this, a platform device must use a new platform device protocol
pdev_device_add() to create the child device rather than calling the DDK
device_add() directly.
The behavior of pdev_device_add() is the same as device_add(), except it inserts
a layer between the parent and child device to allow device_get_protocol()
to return protocols that are implemented by the platform bus
(for example, ZX_PROTOCOL_PLATFORM_DEV, ZX_PROTOCOL_GPIO, etc.)
This allows the children of of platform devices to also be platform devices,
while simultaneously allowing access to the protocol(s) implemented by the
parent device.

This change also adds four drivers to the qemu build to test this new functionality.
The qemu-bus board driver adds a platform device called "parent".
"parent" then creates a child device called "child-1", which in turn has
two children called "child-2" and "child-3".
All of these devices are platform devices and all four of the corresponding drivers
test to make sure that they can access the platform device protocol and map
their own unique MMIO regions.

TEST: manual testing on qemu, vim2 and gauss

Change-Id: Iaa4cd2afb06512dd0a9f9e06ca91c84c348e352f

[dev][platform-bus] Refactor proxying code into a separate class

The PlatformProxy class handles proxying the various protocols
to the parent devhost. PlatformProxy is reference counted to allow
for the future existence of multiple ProxyDevice instances.

This is a step toward having multiple platform devices in the same devhost
(breaking up a larger CL into more easily reviewable chunks).

TEST: manual testing on vim2 and qemu

Change-Id: Ie14b3dde1cd335010f661a28127ee496fbf36844

[dev][platform-bus] Finish port to C++

The remainder of the driver now uses ddktl and other C++ features.

TEST: running on qemu, VIM2 and gauss
Change-Id: Icd1825baa8e76f60e78a9014d95b2a753db7be25

[dev][platform-bus] Continue port to C++

The proxy side of the platform bus now uses ddktl for all its protocols,
fbl::Vector for its arrays and libzx to manage its handles.
The other half of the platform bus will be ported in a separate CL.

TEST: booting on VIM2 and qemu

Change-Id: Ie843aecffe1df74aa1d74843d4bdb71eb8d52344

[dev][platform-bus] Compile in C++

Minimal changes to compile in C++ instead of C
Subsequent CLs will actually start using C++ language features.

TEST: Boot on VIM2

Change-Id: I9ea5f93b7c4ff2ecb51056d6d2504a207fdac775

[ddk][serial] Move serial protocol support out of platform bus driver

Instead of implementing UARTs as platform device resources in platform bus,
We now have a generic serial driver that implements ZX_PROTOCOL_SERIAL
on top of the lower level ZX_PROTOCOL_SERIAL_IMPL protocol.
This allows the possibility of using the generic seral protocol support
on x86 as well as SOC based platforms.

In order to make this work, we add some new generic device properties to our binding rules:
BIND_DEVICE_VID, BIND_DEVICE_PID and BIND_DEVICE_CLASS.
In this CL we use BIND_DEVICE_CLASS to specify the serial port type
(for example Bluetooth HCI versus generic serial port)
and BIND_DEVICE_VID and BIND_DEVICE_PID to specify which Bluetooth firmware
to use in the case of HCI.

We also simplify the serial protocols by eliminating port numbers from the APIs.
Now serial drivers support only one serial port each, so we now have separate
driver instances per serial port.
This is necessary to maintain the flexibility of running serial port clients
in separate devhosts after decoupling from the platform bus.

Change-Id: Ife2c611a1340ec99440595e45d79bdcf63979644

[ddk][i2c] Phase 1 of i2c protocol clean-up

- Add new protocol ZX_PROTOCOL_I2C_IMPL for i2c drivers to implement
This is a simpler protocol to implement than the existing ZX_PROTOCOL_I2C protocol

- Convert the aml-i2c and dw-i2c drivers to implement ZX_PROTOCOL_I2C_IMPL
instead of the higher level ZX_PROTOCOL_I2C protocol

- Move logic for queueing i2c transactions from the i2c drivers
to the platform bus driver

Change-Id: Ic16d18ec331f73cfccce560c1423a1db78472670

[dev][platform-bus] Add support for new serial protocols

The socket based ZX_PROTOCOL_SERIAL is implemented on top of the
lower level ZX_PROTOCOL_SERIAL_DRIVER protocol in platform-serial.c
and is proxied across devhost boundaries to platform devices.

Change-Id: Ib19c4cba16cabbb259600d6af0b0c864105f9551

[ddk][i2c] Add helper for synchronous i2c transfers

Change-Id: I885bfc8df72617571d5ea8ca030362d459ed3efe

[dev][platform-bus] Remove MDI dependency from rules.mk

Change-Id: I3920eb00b0adce675aa9776857570380873279dc

[dev][platform-bus] Simplify storage of platform device resources

The previous method of storing them all at the end of the
platform_dev_t struct wouldn't scale well as we add more resource types
to the platform device protocol.

Change-Id: Id3e40b42eac9aebbe8565fc73214a26e53501376

[dev][platform-bus] Run platform devices in separate devhosts

The platform bus driver now proxies the platform device
and USB mode switch protocols.
usb_mode_switch_get_initial_mode() now returns a zx_status_t.

Still to do: proxy the GPIO protocol

Change-Id: If989338bd77299b2797e83e9121a856fe00ace5a

[zx] Magenta -> Zircon

The Great Renaming is here!

Change-Id: I3229bdeb2a3d0e40fb4db6fec8ca7d971fbffb94

[dev][platform-bus] Start on device specific implementation support

The platform bus driver provides generic support for loading a number
of platform devices and can provide MMIO regions and IRQs to these
devices based on information in the MDI.
This change takes the first step toward expanding this to support
platform specific services like GPIOs, clocks, I2C etc.

To do this, the platform bus driver will require a platform specific
driver to bind against it. This driver will make these additional services
available to the platform bus driver, which will then make them available
to platform devices via the platform device protocol.

In this change we are mostly just adding the skeleton for this new structure.
APIs for GPIOs, I2Cs, etc. will be added in subsequent changes.

The platform specific implementation driver binds to the platform bus driver
by matching against the MX_PROTOCOL_PLATFORM_BUS protocol and the
BIND_PLATFORM_DEV_VID property.
In this change, the bcm-mailbox driver now binds as the platorm specific
bus driver rather than as a platform device.
In subsequent changes, the BCM GPIO and I2C suppport to the mailbox driver.

As soon as the platform specific driver binds, it registers a pbus_interface_t
protocol with the platform bus driver, which will be used for providing
all its platform specific services to platform devices.
The platform bus driver will wait until the pbus_interface_t is registered
before adding the platform devices to ensure that all necessary services
are available when drivers bind to the platform devices.

The platform bus driver can also provide MMIO and IRQ resources to the
platform specific driver. This is done by specifying them in a new "bus" node
in the MDI.

This change also refactors the platform bus driver into multiple source files
and replaces the platform device register_protocol/find_protocol mechanism
with a get_protocol API in the pbus_interface_t protocol.
The bcm-mailbox driver now uses this for providing the bcm bus protocol
to the BCM platform drivers.

Change-Id: Ibfe5caeae425d9d97edd20760d3d7724e8d4f1bb

[udev][platform-bus] Fix name of platform bus driver

devmgr is looking for this at /boot/driver/platform-bus.so

Change-Id: I3348d3cb95824d0604939d35cd3b6ae1688e434e

[udev][platform] rename udev/platform-bus bus/platform

Change-Id: I6104bce6ccd27886c0dc030c6015bc7646932176