#
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
|
#
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
|
#
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
|
#
92a197f6 |
|
20-Aug-2018 |
Mike Voydanoff <voydanoff@google.com> |
[dev][platform-bus] Use metadata for serial_port_info_t If we had metadata support earlier we would have done it this way from the beginning. Simplifies the platform bus and platform device protocols a bit. TEST: Manual testing on VIM2. Drivers load properly for both UARTs. Change-Id: Id60a0de95e1092fb5284ebbe9d1ca5666755482d
|
#
d0a0db64 |
|
26-Jul-2018 |
Mike Voydanoff <voydanoff@google.com> |
[astro][bluetooth] Add delay after resetting the Bluetooth chip and move Bluetooth initialization to the end of the start thread to avoid slowing down the rest of the boot process. TEST: manual testing on astro Change-Id: I5f301bd7546ed8d3a32c5755abe0963c9e44be15
|
#
077c9205 |
|
29-Jun-2018 |
Mike Voydanoff <voydanoff@google.com> |
[board][astro] Bluetooth support: - Configure Bluetooth UART - Turn on Bluetooth enable GPIO - Enable 32K clock for BT/Wifi module Test: Manual on astro. UART and BT HCI drivers load, HCI reset command is sent, UART is successfully switched to high speed. Bug: NET-1005 # in progress Change-Id: I5d8facfbeae4f8806aefe82c4e39c1d7bb52ef55
|