Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <d54ccc35-8670-15b7-ecd3-e77772001c81@ti.com>
Date:   Wed, 9 Nov 2022 15:22:51 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Subject: Re: [PATCH v3 2/2] arm64: dts: ti: k3-am625-sk: mark MCU watchdog as
 reserved
Content-Language: en-US
To:     Julien Panis <jpanis@baylibre.com>, <nm@ti.com>, <vigneshr@ti.com>,
        <kristo@kernel.org>, <robh+dt@kernel.org>,
        <krzysztof.kozlowski+dt@linaro.org>,
        <linux-arm-kernel@lists.infradead.org>
CC:     <devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>
References: <20221109093026.103790-1-jpanis@baylibre.com>
 <20221109093026.103790-3-jpanis@baylibre.com>
From:   Andrew Davis <afd@ti.com>
In-Reply-To: <20221109093026.103790-3-jpanis@baylibre.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 11/9/22 3:30 AM, Julien Panis wrote:
> MCU wdt is typically used by M4F.
> 

See it's this "typically" part I'm concerned about.

It depends on the firmware which peripherals will be used. The firmware
doesn't communicate this to Linux, and Linux doesn't give the firmware
permissions to use one of these peripherals.

We only keep from stepping on the firmware by changing device tree to
never use peripherals that are often used by firmware, and that is not a
hardware description, nor complete when a remote core firmware can use any
device in our systems.

What happens when I change firmware? How do we power sequence this? Who
controls the clocks and clock parents if shared for this peripheral?

I'm thinking we can used something like "application nodes"[0] here. These
are basically DT nodes for a specific firmware application. The nodes
describe the firmware and all hardware it uses (in the linked example,
the remote core to run on, DMAs, SRAM, PHYs). All these devices are under
exclusive control of the application node. So while Linux will still
handle power/clock/state control, no driver will be bound. This also
handles the power sequencing question above, sub-devices need to be active
before starting the firmware, and firmware needs to go down before the
controlled peripherals.

These nodes could be loaded/unloaded as DT overlays, along with the
firmware. So resources are only "reserved" for firmware when
the firmware is actually active.

Thoughts?

Andrew

[0] https://www.spinics.net/lists/netdev/msg823883.html

> Signed-off-by: Julien Panis <jpanis@baylibre.com>
> ---
>   arch/arm64/boot/dts/ti/k3-am625-sk.dts | 5 +++++
>   1 file changed, 5 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/ti/k3-am625-sk.dts b/arch/arm64/boot/dts/ti/k3-am625-sk.dts
> index 93a5f0817efc..089970b304cf 100644
> --- a/arch/arm64/boot/dts/ti/k3-am625-sk.dts
> +++ b/arch/arm64/boot/dts/ti/k3-am625-sk.dts
> @@ -503,6 +503,11 @@ &main_mcan0 {
>   	status = "disabled";
>   };
>   
> +&mcu_rti0 {
> +	/* MCU RTI0 is used by M4F firmware */
> +	status = "reserved";
> +};
> +
>   &epwm0 {
>   	status = "disabled";
>   };