[PATCH 3/6] board: ti: am62x: Add basic initialization for usb voltage, 32k crystal, debounce

[Jan Kiszka]

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-nm@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