Hi all!
In the commit https://review.coreboot.org/c/coreboot/+/33565, I tried to rewrite the PCH GPIOs configuration using macros instead of raw values of the DW0 and DW1 registers.
However, macros from src/soc/intel/common/block/include/intelblocks/gpio_defs.h can't determine the setting for each pads.
1) Why do the standard macros (like PAD_CFG_NF, PAD_CFG_GPO, ...) set RX Level/Edge Configuration (RXEVCFG bit[26:25] DW0 register) to 0? From Doc(1) RXEVCFG = 0 -> "determines if the internal RX pad state should be passed on to the next logic stage as is, as level signal". Is this correct if the pad is used as a functional output, PAD_CFG_NF()?
At the same time, after resetting, by default, the RXEVCFG field is set to 2h = Drive '0'. If I understood correctly, this means that the pad state will not be transmitted to the next logic block and the interrupt controller will not receive signal from the pad. Maybe this setting will be better for PAD_CFG_NF() or PAD_CFG_GPO()? See https://review.coreboot.org/c/coreboot/+/34144
[1] p1429, Intel 100/C230 Series Chipset Family PCH Volume 2 (February 2019)
2) The macros PAD_CFG_NF() and PAD_CFG_GPO() are defined correctly. In this case, I mast to add new macros, how this is done in commit https://review.coreboot.org/c/coreboot/+/33565.
I think adding new macros with strange names isn't the best way. But only in this case, I can set the GPIOs configuration, which fully corresponds to the inteltool log. On the other hand, if I ignore the PAD_CFG0_TRIG_OFF setting (set RX Level/Edge Configuration (RXEVCFG) to 0 = Level), then I need only 2 macros: PAD_CFG_NF_TX_DIS and PAD_CFG_NF_RX_DIS. All Chromebooks install RXEVCFG to 0 and it works.
The motherboard works well in both cases.
I would like to get your opinion on this. So, maybe I should ignore Drive '0' setting for Level/Edge Configuration (bit[26:25] DW0 register) and use standard macros?
Information about GPIOs was obtained from the inteltool log. My motherboard is asrock-h110m-dvs with Intel Skylake/Kaby Lake CPU.
Thanks!
Hi all!
In the commit https://review.coreboot.org/c/coreboot/+/33565, I tried to rewrite the Sunruse PCH GPIOs configuration using macros instead of raw values of the DW0 and DW1 registers. However, macros from src/soc/intel/common/block/include/intelblocks/gpio_defs.h can't define the configuration for each pads.
1) Why do the standard macros (like PAD_CFG_NF, PAD_CFG_GPO, ...) set RX Level/Edge Configuration (RXEVCFG bit[26:25] DW0 register) to 0? From Doc(1) RXEVCFG = 0 -> "determines if the internal RX pad state should be passed on to the next logic stage as is, as level signal". Is this correct if the pad is used as a functional output, PAD_CFG_NF()?
At the same time, after resetting, by default, the RXEVCFG field is set to 2h = Drive '0'. If I understood correctly, this means that the pad state will not be transmitted to the next logic block and the interrupt controller will not receive signal from the pad. Maybe this setting will be better for PAD_CFG_NF() or PAD_CFG_GPO()? See https://review.coreboot.org/c/coreboot/+/34144
[1] p1431, Intel 100/C230 Series Chipset Family PCH Volume 2 (February 2019)
2) The macros PAD_CFG_NF() and PAD_CFG_GPO() are defined correctly. In this case, I have to add new macros, like in the commit https://review.coreboot.org/c/coreboot/+/33565.
I think adding new macros with strange names isn't the best way. But only in this case, I can set the GPIOs configuration, which fully corresponds to the inteltool log. On the other hand, if I ignore the PAD_CFG0_TRIG_OFF setting (set RX Level/Edge Configuration (RXEVCFG) to 0 = Level), then I need only 2 macros: PAD_CFG_NF_TX_DIS and PAD_CFG_NF_RX_DIS.
The motherboard works well in both cases.
I would like to get your opinion on this. So, maybe I should ignore Drive '0' setting for Level/Edge Configuration (bit[26:25] DW0 register) and use standard macros? Information about GPIOs was obtained from the inteltool log.
My motherboard is asrock-h110m-dvs with Intel Skylake/Kaby Lake CPU.
Thanks!
// Regards, // Max
-
Maxim Poliakov -
Maxim Polyakov