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

[Nishanth Menon <nm@ti.com>]

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/

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D