summaryrefslogtreecommitdiff
path: root/Documentation/getting_started/gpio.md
AgeCommit message (Collapse)Author
2021-05-11docs: add recommendation for gpios regarding soft strapsMichael Niewöhner
Soft straps, that can be configured by the vendor in the Intel Flash Image Tool (FIT), can influence some pads' default state. It is possible to select either a native function or GPIO mode for some pads on non-server SoCs, while on server SoCs most pads can be controlled. Thus, add a recommendation to always configure all pads for a board to guarantee integrity between different board or vendor firmware revisions where the soft straps might have been changed. Change-Id: I33063a3f6a1c9cd5267d85f7da84deb554489a26 Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/52297 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
2021-05-11docs: correct and rewrite documentation regarding n/c / unused padsMichael Niewöhner
Intel PDGs starting from Skylake / Sunrise Point state that, different from the general recommendation in digital electronics, unconnected GPIOs defaulting to GPIO mode do explicitly not require termination. The reason for this is, that these GPIOs have the `GPIORXDIS` bit set, which effectively disconnects the pad from the internal logic by disabling the input buffer. This bit - besides `GPIOTXDIS` - can also be set explicitly by using the gpio macro `PAD_NC(pad, NONE)`. In some cases, a pull resistor may be required due to bad board design or when a vendor sets the RX/TX disable bits together with a pull resistor and schematics are not available to check if the pad is really unconnected or just unused. In this case the pull resistor should be kept. Pads defaulting to native functions usually don't need special handling. However, when pads requiring external pull-ups are missing these due to bad board design, they should be configured with `PAD_NC` to disconnect them internally. Rewrite the documentation to reflect these new findings. Also clarify the comment in soc/intel gpio code accordingly. Change-Id: Id01b197ebe8f2b8bb4ecf3d119ec2298b26d9be0 Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/52139 Reviewed-by: Tim Crawford <tcrawford@system76.com> Reviewed-by: Felix Singer <felixsinger@posteo.net> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-01-23soc/intel/apl: drop LPC pad configuration codeMichael Niewöhner
Drop LPC pad configuration code since all boards now do pad configuration on their own. The comment about LPC_CLKRUNB when using eSPI is moved to `Documentation/getting_started/gpio.md`. Change-Id: I710d6aee8c3b2c8282cd321cd0688b9b26abea07 Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/49410 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-07-26soc/intel/common/gpio_defs: Remove PAD_CFG_NF_BUF_TRIGMaxim Polyakov
This macro is not correct because the RX Level/Edge Configuration (trig) and the GPIO Tx/Rx Buffer Disable (bufdis) fields in DW0 register do not affect on the pad in the native function mode. This is part of the patch set "src/mb/*, src/soc/intel/common/gpio: Remove PAD_CFG_NF_BUF_TRIG ": CB:43455 - cedarisland: undo set trig and bufdis for NF pads CB:43454 - tiogapass: undo set trig and bufdis for NF pads CB:43561 - h110m: undo set trig and bufdis for NF pads CB:43569 - soc/intel/common/gpio_defs: Remove PAD_CFG_NF_BUF_TRIG Change-Id: Ic0416e3f67016c648f0886df73f585e8a08d4e92 Signed-off-by: Maxim Polyakov <max.senia.poliak@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/43569 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Lance Zhao Reviewed-by: Michael Niewöhner
2020-02-24Documentation: getting_started/gpio.md: fix markupIvan Labáth
Change-Id: I2c61770d60a4f290fd8d516850f16bc3808ad48d Signed-off-by: Ivan Labáth <iger@labo.rs> Reviewed-on: https://review.coreboot.org/c/coreboot/+/39082 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-01-18documentation: Add documentation on setting up mainboard GPIOsTim Wawrzynczak
The new documentation describes typical ways that mainboards will set up their GPIOs, as well as the distinction between "early" and "normal" GPIOs. It also describes the typical properties that GPIO configuration will cover. Change-Id: I279eec4ed2bb0248a2bdb363fb73b40b8272267f Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/37802 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Justin TerAvest <teravest@chromium.org>