[PATCH v2 1/1] arm64: dts: ti: k3-am62-wakeup: Configure ti-sysc for wkup_uart0

[Kevin Hilman]

Tony Lindgren <tony at atomide.com> writes:

> * Kevin Hilman <khilman at kernel.org> [231208 17:13]:
>> Tony Lindgren <tony at atomide.com> writes:
>> 
>> > * Kevin Hilman <khilman at kernel.org> [231205 18:14]:
>> >> I'm a little confused why these power-domain and clocks stay here and
>> >> are not moved under the wkup_uart0 node... 
>> >
>> > The resources are also needed by the interconnect target module. It's the
>> > wrapper IP for the child device(s). In this case there's one chip 8250 IP
>> > instance. In some other devices there can be multiple child IP devices
>> > wired to one target module.
>> >
>> >> > -		clock-names = "fclk";
>> >> > -		status = "disabled";
>> >> > +		clock-names = "fck";
>> >> > +		#address-cells = <1>;
>> >> > +		#size-cells = <1>;
>> >> > +		ranges = <0 0 0x2b300000 0x100000>;
>> >> > +
>> >> > +		wkup_uart0: serial at 2b300000 {
>> >> > +			compatible = "ti,am64-uart", "ti,am654-uart";
>> >> > +			reg = <0 0x100>;
>> >> > +			interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>;
>> >> > +			status = "disabled";
>> >> 
>> >> ...here.
>> >> 
>> >> The SCI device ID 114 is specifically for wkup_uart0[1], so it seems to
>> >> me those should be in the wkup_uart0 node.
>> >
>> > Those resources are also needed for the parent target module for revision
>> > detection, quirks, reset, idle register configuration, and to probe the
>> > child devices.
>> >
>> > Here the 8250 IP can be set to status = "reserved" when used by the
>> > firmware, and 8250 not touched by Linux. However, the parent interconnect
>> > target module still needs to be configured for idle registers and wake-up
>> > path register bit so the wake-up from deeper suspend states works.
>> 
>> OK, makes sense.  Thanks for the clarification.
>
> One more thing to clarify, there's nothing stopping also mapping the needed
> resources for the child IP too if needed by the driver or the dts binding.
> The calls for resources by the 8250 driver just won't do anything as the
> resources are already enabled by the parent.

OK, thanks.

>> In that case, shouldn't the same be done for the other wakeup sources
>> there (e.g. wkup_rtc0) ?
>
> Yes it should be done for devices with the wake-up path wired like
> wkup_rtc0.

OK, in that case, this all makes sense to me.

Reviewed-by: Kevin Hilman <khilman at baylibre.com>

Kevin