#
6c2ccb39 |
|
19-Sep-2018 |
Mike Voydanoff <voydanoff@google.com> |
[gpio] Refactor the GPIO protocol This is a first step in a move toward using protocols to represent individual resources. A similar change will be made to the I2C protocol to bring it in line with how I2C is used on x86 platforms. From the client's point of view, an instance of the ZX_PROTOCOL_GPIO protocol now represents a single pin. The protocol remains the same, except the "uint32_t index" has been removed from all the protocol functions. For devices that have only one GPIO resource assigned to them, the driver can simply call device_get_protocol() to access the GPIO protocol for the pin. To for devices with more than one GPIO pins, a new API in the platform bus called pdev_get_protocol() must be used instead. In addition, we add a new protocol ZX_PROTOCOL_GPIO_IMPL, which is now implemented by the GPIO drivers. This protocol is essentially the same as the old GPIO protocol, except "index" has been renamed "pin". Board drivers may use this protocol directly when doing low level system configuration, specifying pin numbers directly. TEST: Booted on VIM2 and Hikey. On VIM2, USB, display, ethernet and the GPIO test driver are working properly On Hikey, the system boots and USB is functional. Change-Id: I44f1bc11ad9793543361a2d19d7a2de4458c334b
|
#
ba063a75 |
|
17-Sep-2018 |
Mike Voydanoff <voydanoff@google.com> |
[dev][platform-bus] Clean up proxy error reporting The platform_proxy_cb_t callback now has void return type, since the status is already included in the platform_proxy_rsp_t struct ZX-2602 #done TEST: manual testing on VIM2. Change-Id: I642542fcf5d8aa5c1a7cef45f92222871341f7cf
|
#
ea3daa68 |
|
06-Sep-2018 |
Andres Oportus <andresoportus@google.com> |
[ddk][i2c] Add arbitrary number of RWs support to I2C protocol Augment the I2C protocol transact function to allow more than 2 write and/or read operations in one transaction. Rename the old transact to write_read. Test: Astro light sensor (uses I2C based interface) readings work Change-Id: I3c83025b7ca697551638ed9824cb7547e37afc4b
|
#
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
|
#
85d438b9 |
|
26-Aug-2018 |
Mike Voydanoff <voydanoff@google.com> |
[ddk] Rename ZX_PROTOCOL_CANVAS to ZX_PROTOCOL_AMLOGIC_CANVAS To make it clear that this is an SOC-specific protocol TEST: boot on VIM2 Change-Id: I0b6c785f77980524d5921fb2a2feda1a8984f8ce
|
#
21c26dc0 |
|
24-Aug-2018 |
Mike Voydanoff <voydanoff@google.com> |
[platform-bus] Remove proxying of USB mode switch protocol This protocol is only being used for Hikey960, which needs to change some GPIOs when switching USB mode. But now that we have support for child platform devices, this logic can be pushed out of the board driver and into a platform device driver which has the dwc3 driver as a child. TEST: manual testing on hikey960 and imx8m-evk Change-Id: Ia3c1b9540d0813d3d873f22007e3e22efb219975
|
#
592487b5 |
|
23-Aug-2018 |
Mike Voydanoff <voydanoff@google.com> |
[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
|
#
0d71f953 |
|
21-Aug-2018 |
Mike Voydanoff <voydanoff@google.com> |
[dev][platform-bus] Clean-up and simplify platform bus protocol: - Remove "flags" parameter from pbus_device_add(). Now platform devices can only be started in new devhosts. - Add new API pbus_protocol_device_add(), for binding drivers that implement platform bus protocols like GPIO and I2C_IMPL. pbus_protocol_device_add() is equivalent to pbus_device_add(PDEV_ADD_PBUS_DEVHOST) followed by pbus_wait_protocol(). - Remove pbus_wait_protocol(). pbus_protocol_device_add() does the wait for you automatically. - Rename pbus_set_protocol() to pbus_register_protocol() These changes will hopefully make the platform bus protocol easier to understand and use. I found two places where people accidentally using PDEV_ADD_PBUS_DEVHOST inappropriately (probably copy & paste errors), which resulted in the entire network stack and storage stack running in the platform bus devhost. Hopefully this change will make it impossible for mistakes like that to happen again. While doing this I also noticed that the gauss nand driver and vim2 ethernet driver were running in the platform bus devhost. This change fixes that. Also removed some remnants of the pbus_device_enable() API, which has been removed previously. TEST: boot up on qemu, VIM2, gauss and astro and verified platform devices all start up properly Change-Id: I580269bc6f53a63348ba8ab580259b1ba56dd393
|
#
6f750465 |
|
20-Aug-2018 |
Mike Voydanoff <voydanoff@google.com> |
[dev][platform-bus] clang format, and remove obsolete comment TEST: boot VIM2 successfully Change-Id: Idc2aed5c649a929bf3baaf9ceb5c82dbaae2182e
|
#
1687d015 |
|
19-Aug-2018 |
Mike Voydanoff <voydanoff@google.com> |
[dev][platform-bus] Remove support for proxying the SCPI protocol The aml-scpi driver now runs in the same devhost as the vim-thermal driver, so this proxying is no longer necessary. TEST: manual testing on VIM2. Thermal driver loads and initializes properly. Change-Id: Idea760b43ea1463cdeebe41b06affa37b9fe7aa7
|
#
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
|
#
fd05dc6b |
|
08-Aug-2018 |
Mike Voydanoff <voydanoff@google.com> |
[dev][platform-bus] Refactor proxying protocol Proxy request and response structs are now broken up by protocol, with common headers. This is first step in modularizing platform bus support for protocol proxying. TESTS: manual testing on vim2, gauss and qemu Change-Id: Ic42ac51a03d608cbd481c00a8bcf6e191690c2e7
|
#
d5267c7c |
|
08-Aug-2018 |
Mike Voydanoff <voydanoff@google.com> |
[dev][platform-bus] Add platform device support for board info pdev_get_board_info() returns board vendor and product IDs, board name, and a board revision number optionally set by the board driver. TEST: Added test to VIM2 display driver. ZX-2452 #done Change-Id: Ia417acc3afede145a7a256ab3d71415c236d8230
|
#
8292ac6c |
|
31-Jul-2018 |
Mike Voydanoff <voydanoff@google.com> |
[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
|
#
d184543e |
|
26-Jul-2018 |
Mike Voydanoff <voydanoff@google.com> |
[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
|
#
babe1cf5 |
|
25-Jul-2018 |
Adam Barth <abarth@chromium.org> |
[sync] Apply C API rubric to libsync Test: No behavior change Change-Id: I30a413f7fb5d3f4e741e5204532b82e73595c086
|
#
350aac28 |
|
28-Jun-2018 |
Mike Voydanoff <voydanoff@google.com> |
[ddk][platform-bus] Misc driver metadata cleanup Rename "boot_metadata" to "metadata" in the plaform bus and device protocols, since not all metadata provided by the platform bus comes from the bootloader. Rename DEVICE_METADATA_DRIVER_DATA to DEVICE_METADATA_PRIVATE to clarify that this signifies that the metadata type is local to a particular driver or protocol. Remove unused pbus_publish_boot_metadata() from platform bus protocol Test: manual testing on VIM2 Change-Id: If969bb0005da7cb66901a796effc8231a8cb2ebe
|
#
6bd61ec7 |
|
22-Jun-2018 |
Brijen Raval <braval@google.com> |
[amlogic][canvas] Add canvas driver for AMLOGIC - Added a canvas protocol - Modified the VIM2 display driver to use the canvas protocol instead of local canvas driver - Removed local vim2 canvas driver ZX-2154 #done Test: Boot up on VIM2 board with HDMI monitor attached Change-Id: I9e2328513fafecd1a440985f84ee41fce0c35ab9
|
#
92773b9b |
|
06-Jun-2018 |
Mike Voydanoff <voydanoff@google.com> |
[dev] Switch drivers to use <zircon/boot/image.h> instead of deprecated bootdata.h Tested on VIM2 and x86 qemu Change-Id: I5d22e3ccf0389e05eb77fd3d3810a4e993c85767
|
#
c09e0551 |
|
09-May-2018 |
Brijen Raval <braval@google.com> |
[vim2][mailbox][scpi] Introduce Mailbox & SCPI Protocol Breaking down the fan-control thermal prototype driver into 3 parts. 1st layer would be the Mailbox driver which would provide communication between the two on-board processors. 2nd layer would be the SCPI driver (System Control and Power Interface) which would use the mailbox protocol to set/get system configuration such as frequency/voltage and thermal parameters. 3rd layer would be the Fan-control driver which uses the SCPI protocol to get the temperature and controls the fan via the GPIO protocol based on it. (TODO): Expose the fan-ctl & SCPI interface as IOCTL's in a later CL Change-Id: Ia0175fdfe76048d7cb789e3898e50d9cffb3cee3
|
#
d541a432 |
|
23-Apr-2018 |
Mike Voydanoff <voydanoff@google.com> |
[dev][platform-bus] Add support for extracting device metadata from bootdata BOOTDATA_PARTITION_MAP and BOOTDATA_MAC_ADDRESS records in the bootdata can now be added as device metadata via two different mechanisms: 1) Add a pbus_boot_metadata_t containing matching information to the pbus_dev_t passed to pbus_device_add() 2) Call pbus_publish_boot_metadata() to publish a bootdata record to the specified device path. Change-Id: I18b6972a2f536fc84135649ba6401bed627c9311
|
#
66c6488e |
|
28-Mar-2018 |
Mike Voydanoff <voydanoff@google.com> |
[devmgr][platform-bus] Pass bootdata VMO handle to platform bus driver platform-bus now extracts bootdata_platform_id from the bootdata itself instead of having devmgr pass it in the driver create arguments. This will allow us to pass other information to the platform bus driver in the future. Change-Id: I4ea011608173632d389623d865e09cc9a26e323b
|
#
466813a0 |
|
12-Mar-2018 |
Mike Voydanoff <voydanoff@google.com> |
[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
|
#
db7c4fd3 |
|
11-Mar-2018 |
Mike Voydanoff <voydanoff@google.com> |
[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
|
#
e2d7091b |
|
08-Mar-2018 |
Mike Voydanoff <voydanoff@google.com> |
[ddk][serial] Rename ZX_PROTOCOL_SERIAL_DRIVER to ZX_PROTOCOL_SERIAL_IMPL Change-Id: Ic0766df427c649c39483c35d6bc2c2838e7d08a5
|
#
57eac337 |
|
07-Mar-2018 |
Mike Voydanoff <voydanoff@google.com> |
[dev][platform-bus] Add IOMMU support Add a new ZX_PROTOCOL_IOMMU, which platform board drivers can use to implement platform specific IOMMU functionality. If no IOMMU protocol is set by the board driver, the platform bus uses a default implementation based on a dummy IOMMU. Platform device drivers can now access BTIs via the pdev_get_bti() API in the platform device protocol. Similarly, board drivers can assign BTIs to the platform devices they create via the pbus_dev_t struct passed to pbus_device_add(). Also modified the vim, hikey and gauss board drivers to assign BTIs to all platform devices where the the driver will need to perform DMA. ZX-693 Change-Id: Id3decaba2ad5bda2c2dc49280e94e674bee1ae56
|
#
b6fd5830 |
|
13-Feb-2018 |
Gurjant Kalsi <gkalsi@google.com> |
[ddk][clk][protocol] Initial Clock Protocol Initial implementation for a platform clock protocol. Only implements enable/disable for now. Change-Id: If74b24ca6dd59ad7e7b437b15582b700fa5548ac
|
#
9003e692 |
|
02-Feb-2018 |
Mike Voydanoff <voydanoff@google.com> |
[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
|
#
b2eddf49 |
|
24-Jan-2018 |
Mike Voydanoff <voydanoff@google.com> |
[dev][platform-bus] Add support for binding platform devices in platform bus devhost Passing the PDEV_ADD_PBUS_DEVHOST flag to pbus_device_add() will create a platform device node in the platform bus's devhost rather than creating a new devhost. These devices have access to the ZX_PROTOCOL_PLATFORM_BUS protocol in addition to ZX_PROTOCOL_PLATFORM_DEV. The standard separate devhost case remains unchanged. Change-Id: Iea54655e6f5cded475e044655347d9ec0d8cbdee
|
#
ecab9d84 |
|
18-Jan-2018 |
Mike Voydanoff <voydanoff@google.com> |
[dev][platform-bus] Replace pbus_set_interface with pbus_set_protocol The interface provided by the board driver to the platform bus only supports retrieving protocols from the board driver, so it is simpler to just have the board drivers set protocols on the platform bus driver instead. Change-Id: I2d0a04504102c4a49082b3d4eeba3cf4380dacab
|
#
3d6efb68 |
|
29-Oct-2017 |
Mike Voydanoff <voydanoff@google.com> |
[dev][platform-bus] Add support for proxying the i2c protocol to platform devices Change-Id: I5d76a551a9ad77481a20d9d8fe4313761347dee8
|
#
2e1680da |
|
14-Oct-2017 |
Mike Voydanoff <voydanoff@google.com> |
[platform][gpio] Use device relative indices for GPIOs This insulates generic drivers from the platform's GPIO numbering and also restricts drivers from accessing GPIOs that are not assigned to them by the platform bus. Also removed unused id fields from pbus_mmio_t and pbus_irq_t. Change-Id: I9be4fdbe5d5447a0eb689a5c5715f22fa1e2f820
|
#
8e4df676 |
|
13-Oct-2017 |
Mike Voydanoff <voydanoff@google.com> |
[dev][platform-bus] Add proxying support for the GPIO protocol Change-Id: I3b0e005fce841a9e21f393be70f235d481f27c8a
|
#
b51ece4e |
|
14-Oct-2017 |
Mike Voydanoff <voydanoff@google.com> |
[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
|
#
90b89950 |
|
13-Oct-2017 |
Mike Voydanoff <voydanoff@google.com> |
[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
|
#
242ccb4f |
|
27-Sep-2017 |
Mike Voydanoff <voydanoff@google.com> |
[ddk][platform-bus] Add API for reading the platform's board name SOC drivers might need this to handle board specific differences Change-Id: I9442203b8e6773fc2b22075c9bd7ee790663bb12
|
#
437c0616 |
|
26-Sep-2017 |
Mike Voydanoff <voydanoff@google.com> |
[dev][platform-bus] Remove most of the MDI support We are now only using MDI to retrieve the platform VID and PID, and that will be going away soon too. Also removed unnecessary creation of child resources for MMIOs and IRQs Change-Id: I3186a6ef392b167f022a2dddaa69e860600060a3
|
#
baadb88a |
|
26-Sep-2017 |
Mike Voydanoff <voydanoff@google.com> |
[dev][platform-bus] Support for programatic creation of platform devices Adds support for platform bus implementor driver creating platform devices rather than using the MDI. Change-Id: Ie685085c96a034050b001b423b2a410125896063
|
#
ce3304fa |
|
26-Sep-2017 |
Mike Voydanoff <voydanoff@google.com> |
[ddk][platform-bus] Add platform bus protocol Currently the platform device protocol ZX_PROTOCOL_PLATFORM_DEV is used for binding both platform device drivers as well as drivers implementing platform bus functionality. In this change we add a new protocol ZX_PROTOCOL_PLATFORM_BUS for binding platform bus implementor drivers. APIs specific to platform bus implementors has moved from the platform device protocol to the new platform bus protocol. Change-Id: I7ba90cb888206f28a1a2fe2d0edff52bbe4f22b1
|
#
ee665c3d |
|
20-Sep-2017 |
Mike Voydanoff <voydanoff@google.com> |
[dev][platform-bus] Fix problem disabling and re-enabling platform devices Remove platform_dev_release() and clean-up devices when platform bus unbinds rather than when a platform device is removed. Otherwise it is impossible to re-enable the device. Change-Id: I6a2927e8bab12aedfba914f4d87d4fa60ab0f1e6
|
#
7952bd67 |
|
18-Sep-2017 |
Mike Voydanoff <voydanoff@google.com> |
[dev][platform-bus] Add support for dynamically enabling and disabling platform devices The platform bus implementation driver can now enable or disable a platform device using the new pdev_device_enable() API. This will add or remove the DDK device for a platform device. A new "enabled" flag in the MDI can be used to specify that a platform device not be enabled at startup. We will use this to dynamically add and remove the platform device for XHCI when switching between USB host and peripheral roles. Change-Id: I126ea70b0dba6573230528899a00fd21320ee6ea
|
#
dacc1d80 |
|
12-Sep-2017 |
Mike Voydanoff <voydanoff@google.com> |
[dev] Rename "mxdev" to "zxdev" in ddktl and various drivers. Change-Id: I000e42c26d9f8379de40447690694a35f6be93e2
|
#
f3e2126c |
|
12-Sep-2017 |
Roland McGrath <mcgrathr@google.com> |
[zx] Magenta -> Zircon The Great Renaming is here! Change-Id: I3229bdeb2a3d0e40fb4db6fec8ca7d971fbffb94
|
#
85dfaba5 |
|
18-Jul-2017 |
Mike Voydanoff <voydanoff@google.com> |
[dev][platform-bus] Add support for GPIOs The platform bus driver can now read configuration information for GPIO drivers and passes this information to the platform bus driver via pbus_interface_t. This allows platform bus implementation drivers to implement GPIO support and make it available to platform devices via Platform devices can then access the pdev_get_protocol() API. Change-Id: I505bccb9bace5f99eadd511fe877fb7c24457131
|
#
2fc695cd |
|
12-Jul-2017 |
Mike Voydanoff <voydanoff@google.com> |
[dev][platform-bus] Fold platform bus protocol into the platform device protocol The platform device protocol is now used for the device specific bus driver to bind to the platform bus. Now this driver to MX_PROTOCOL_PLATFORM_DEV with special device ID PDEV_BUS_IMPLEMENTOR_DID Change-Id: I6151310b1a6e787825d9731fb1b93d0edc91e792
|
#
95e27c63 |
|
11-Jul-2017 |
Mike Voydanoff <voydanoff@google.com> |
[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
|