#
5a9d8c6d |
|
25-Sep-2018 |
Andres Oportus <andresoportus@google.com> |
[dev][i2c][intel-i2c] Use I2C protocol instead of I2C get IRQ IOCTL The Intel I2C driver supports IOCTLs that are used by other drivers, this change replaces drivers calls to IOCTL_I2C_SLAVE_IRQ with a new I2C protocol call i2c_get_interrupt(). This is a step towards removing IOCTL based communication between drivers. ZX-2621 #comment Use I2C protocol instead of I2C get IRQ IOCTL Test: 'hidtouch' in Acer12 (touch panel HID support gets an I2C IRQ) Change-Id: I742201ce81ed20b84622e736df4ca29804a37e65
|
#
c7b206a9 |
|
20-Sep-2018 |
Suraj Malhotra <surajmalhotra@google.com> |
[ddk][platform-device] Add new get_mmio API. First part of migration away from io_buffer_t. Tested: It compiles. Change-Id: I0a1f8e91d66ad1279f6ea2292700c8061e0abe57
|
#
3ab16f4f |
|
19-Sep-2018 |
Andres Oportus <andresoportus@google.com> |
[ddk][i2c] Refactor the I2C protocol This change is similar to "[gpio] Refactor the GPIO protocol" but for I2C channels: https://fuchsia-review.googlesource.com/c/zircon/+/199400 After this change an instance of the ZX_PROTOCOL_I2C protocol now represents a single I2C channel. The protocol remains the same, except the "uint32_t index" has been removed from all the protocol functions. For devices that have only one I2C channel assigned to them, the driver can simply call device_get_protocol() to access the I2C protocol for the channel. To support multiple channel, a new API in the platform bus called pdev_get_protocol() allows accessing the I2C channels protocols by index. ZX-2621 #comment Refactor the I2C protocol removing index. Test: Boot and I2C transactions work on astro and NXP IMX8 Change-Id: I55d08aa3d82024f6977646425fd3d75a378f2740
|
#
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
|
#
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
|
#
2d20e548 |
|
04-Sep-2018 |
Mike Voydanoff <voydanoff@google.com> |
[ddk][gpio] Break gpio_config() API into two functions gpio_config_in() is used to configure a pin for input, while gpio_config_out() is used to configure a pin for output. gpio_config_out() now takes an initial value for the pin, so the configuration and value can be set atomically to avoid a race condition or glitch between setting it as output and writing the value. Also removed some unnecessary GPIO configuration flags. Now we only have flags for configuring the pull-up in gpio_config_in(). gpio_get_interrupt() uses interrupt handle flags for configuring edge vs level triggered, so we don't need GPIO_* flags for these. TEST: manual testing on VIM2, astro and gauss ZX-2564 #in progress ZX-2465 #in progress Change-Id: I280c489ba951ca5953c0a2d57135c3482dd96c37
|
#
fce347fc |
|
30-Aug-2018 |
Mike Voydanoff <voydanoff@google.com> |
[dev][platform-bus] Set correct proto_id in pdev_device_add() The ddktl DdkAdd() was ignoring the provided proto_id and replacing it with ZX_PROTOCOL_PLATFORM_DEV. TEST: manual testing on astro Change-Id: I252869b9075751b2ce5c84a666326e86822390bb
|
#
989ee4e8 |
|
13-Jun-2018 |
David Moore <davemoore@google.com> |
[syscalls] Change vmar_... calls - Create zx_vm_option_t type - Change ZX_VM_FLAG_... to ZX_VM_... and make them new type. - Change int32_t flags parameters to zx_vm_option_t options - Make the options parameter be second. - Modify vmar_..._old functions to keep other repos working. Once they've all been updated these functions will go away. ZX-2264 Test:CQ Change-Id: I1faf4cc4e1e4dabf3d8ef680e398d83a545b0f09
|
#
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
|
#
8a38cf65 |
|
23-Aug-2018 |
Mike Voydanoff <voydanoff@google.com> |
[ddktl][platform-bus] Fix ddktl headers used by the platform bus driver Most ddktl classes subclass from internal::base_protocol, which requires its subclasses to implement exactly one protocol. But the ProxyDevice class in the platform bus driver needs to implement several protocols, so the ddktl headers for canvas, clk, gpio, i2c-impl, i2c and usb-mode-switch were written to not inherit from internal::base_protocol to work around this limitation. Unfortunately that makes it harder for people to use ddktl to implement these protocols for writing other drivers. This CL changes the ddktl headers for these protocols to use internal::base_protocol and changes the platform bus driver to no longer use ddktl for these protocols. TEST: Manual testing on VIM2 Change-Id: Ie41452f5bc1bed3a1b154155d03a73ec8a083881
|
#
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
|
#
72c7a4b6 |
|
19-Aug-2018 |
Mike Voydanoff <voydanoff@google.com> |
[dev][platform-bus] Add metadata support for children of platform devices ZX-2500 #done TEST: manual testing on VIM2 via another CL that will be out for review son. Change-Id: Ibe873700a02bfd9baaadee6c25149b2c9f4990a6
|
#
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
|
#
9b1d42b6 |
|
13-Aug-2018 |
Mike Voydanoff <voydanoff@google.com> |
[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
|