On 26.07.23 13:10, Nishanth Menon wrote: > On 00:35-20230726, Francesco Dolcini wrote: > [...] >>>> >>>> At least the ones we have currently (I am not sure about toradex, >>>> phytech etc), seem to operate the vdd_core at 0.85V .. (which is what >>>> USB is dependent upon). >>> >>> For Toradex, we do have the equivalent code in our board file, see >>> https://git.toradex.com/cgit/u-boot-toradex.git/tree/board/toradex/verdin-am62/verdin-am62.c?h=toradex_ti-u-boot-2023.04#n92 >>> >>> The 32kHz configuration is just different for us, we do not re-use the >>> same you have here. > > True, you are hitting the bypass control and not powering on the > oscillator control since the 32k is incoming from RTC, in my case, since > I have an actual 32k crystal, I am clearing the powerdown. > > >>> >>> The debounce conf registers I have no idea what they are about, >>> something we should have also on our board? Any additional details? >> >> So, I got curious and checked on the datasheet/TRM on this debounce. If >> I understood correctly this is to have debounce on GPIO and/or EQEP. > > Typically, yes - input signals more useful for eQEP or GPIO. but the > implementation is at pin level which, technically could be used for > other purposes (but I have'nt seen any). > >> >> However to my understanding this would need to have the corresponding >> DEBOUNCE_SEL register written on the pad configuration, and by default it's >> 0. >> >> What's the use case for this debounce configuration you have here? > > TRM was a bit of a crap (internal ticket was filed to improve), but long > story short: > * bootloader configures delays per index > * in the pinmux configuration, we pick which index to use for the pin > > On Beagleplay, for example, the HDMI hot plug detect GPIO benefited from > this[1]. Corresponding pinctrl.h macros were posted in [2]. > > Why do it in the bootloader? since gpio inputs could also used in u-boot > (e.g. MMC/CD) > > > All said, Tom's question is very valid - we'd rather not modify evm.c > for these specific configurations (popcorn as they might be), and we > need to figure out a better option to introduce this kind of variation > cleanly. For now, I will try dropping this patch. > > > [1] > https://git.beagleboard.org/beagleboard/linux/-/blob/v6.1.33-ti-rt-arm64-r6/arch/arm64/boot/dts/ti/k3-am625-beagleplay.dts#L311 > [2] https://lore.kernel.org/all/20230619131620.3286650-1...@ti.com/ >
What happened to this? I still need something like this patch (a version that has the CFG register writes correctly ordered) on top of current master in order to get WIFI on the Beagleplay. Jan