#
5c6d16a0 |
|
29-Aug-2018 |
Mike Voydanoff <voydanoff@google.com> |
[dev][platform-bus] separate regular metadata from bootloader metadata In the platform bus protocol, we use the pbus_metadata_t struct for board drivers to pass metadata to the platform devices. Instead of overloading this struct to work both for immediately provided metadata and metadata passed from the bootloader, we now have a separate struct pbus_boot_metadata_t used for specifying bootloader metadata to be assigned to a platform device. ZX-2513 #in progress TEST: booted VIM2, astro and gauss and verified that drivers that use metadata started up successfully. Change-Id: I7065fd497646f386987cb5dc317d1c66daa8df0a
|
#
fd3d6217 |
|
25-Aug-2018 |
Mike Voydanoff <voydanoff@google.com> |
[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
|
#
5cfd5b91 |
|
07-Aug-2018 |
Mike Voydanoff <voydanoff@google.com> |
[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
|