History log of /rk3399_ARM-atf/include/export/drivers/gpio_exp.h (Results 1 – 4 of 4)
Revision Date Author Comments
# 0ac23de9 04-Jan-2022 Manish Pandey <manish.pandey2@arm.com>

Merge "refactor(plat/rockchip/rk3399/drivers/gpio): reduce code duplication" into integration


# 9565962c 22-Dec-2020 Jona Stubbe <tf-a@jona-stubbe.de>

refactor(plat/rockchip/rk3399/drivers/gpio): reduce code duplication

Refactor the GPIO code to use a small lookup table instead of redundant or
repetitive code.

Signed-off-by: Jona Stubbe <tf-a@jon

refactor(plat/rockchip/rk3399/drivers/gpio): reduce code duplication

Refactor the GPIO code to use a small lookup table instead of redundant or
repetitive code.

Signed-off-by: Jona Stubbe <tf-a@jona-stubbe.de>
Change-Id: Icf60385095efc1f506e4215d497b60f90e16edfd
Signed-off-by: Jimmy Brisson <jimmy.brisson@arm.com>

show more ...


# d38613df 25-Jul-2019 Soby Mathew <soby.mathew@arm.com>

Merge changes I0d17ba6c,I540741d2,I9e6475ad,Ifd769320,I12c04a85, ... into integration

* changes:
plat/mediatek/mt81*: Use new bl31_params_parse() helper
plat/rockchip: Use new bl31_params_parse_

Merge changes I0d17ba6c,I540741d2,I9e6475ad,Ifd769320,I12c04a85, ... into integration

* changes:
plat/mediatek/mt81*: Use new bl31_params_parse() helper
plat/rockchip: Use new bl31_params_parse_helper()
Add helper to parse BL31 parameters (both versions)
Factor out cross-BL API into export headers suitable for 3rd party code
Use explicit-width data types in AAPCS parameter structs
plat/rockchip: Switch to use new common BL aux parameter library
Introduce lightweight BL platform parameter library

show more ...


# 57bf6057 29-May-2019 Julius Werner <jwerner@chromium.org>

Factor out cross-BL API into export headers suitable for 3rd party code

This patch adds a new include/export/ directory meant for inclusion in
third-party code. This is useful for cases where third-

Factor out cross-BL API into export headers suitable for 3rd party code

This patch adds a new include/export/ directory meant for inclusion in
third-party code. This is useful for cases where third-party code needs
to interact with TF-A interfaces and data structures (such as a custom
BL2-implementation like coreboot handing off to BL31). Directly
including headers from the TF-A repository avoids having to duplicate
all these definitions (and risk them going stale), but with the current
header structure this is not possible because handoff API definitions
are too deeply intertwined with other TF code/headers and chain-include
other headers that will not be available in the other environment.

The new approach aims to solve this by separating only the parts that
are really needed into these special headers that are self-contained and
will not chain-include other (non-export) headers. TF-A code should
never include them directly but should instead always include the
respective wrapper header, which will include the required prerequisites
(like <stdint.h>) before including the export header. Third-party code
can include the export headers via its own wrappers that make sure the
necessary definitions are available in whatever way that environment can
provide them.

Change-Id: Ifd769320ba51371439a8e5dd5b79c2516c3b43ab
Signed-off-by: Julius Werner <jwerner@chromium.org>

show more ...