[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250213133550.GA1208@localhost.localdomain>
Date: Thu, 13 Feb 2025 21:35:50 +0800
From: Peng Fan <peng.fan@....nxp.com>
To: Alexandre Belloni <alexandre.belloni@...tlin.com>
Cc: Sudeep Holla <sudeep.holla@....com>, Peng Fan <peng.fan@....com>,
"cristian.marussi@....com" <cristian.marussi@....com>,
Shawn Guo <shawnguo@...nel.org>,
Sascha Hauer <s.hauer@...gutronix.de>,
Pengutronix Kernel Team <kernel@...gutronix.de>,
Fabio Estevam <festevam@...il.com>,
"arm-scmi@...r.kernel.org" <arm-scmi@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>,
"imx@...ts.linux.dev" <imx@...ts.linux.dev>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-rtc@...r.kernel.org" <linux-rtc@...r.kernel.org>
Subject: Re: [PATCH 0/4] rtc/scmi: Support multiple RTCs
On Thu, Feb 13, 2025 at 12:26:05PM +0100, Alexandre Belloni wrote:
>On 13/02/2025 18:52:57+0800, Peng Fan wrote:
>> On Thu, Feb 13, 2025 at 09:20:32AM +0100, Alexandre Belloni wrote:
>> >On 13/02/2025 11:30:33+0800, Peng Fan wrote:
>> >> >> IIUC on any pure DT based system, a device node exists per RTC and hence
>> >> >> platform device associated with it. And the RTC devices are created with
>> >> >> parent pointing to unique platform device.
>> >> >>
>> >> >> > However i.MX SCMI BBM exports two RTCs(id: 0, id: 1), so to make it work for
>> >> >> > current RTC framework, we could only pick one RTC and pass the id to BBM
>> >> >> > server side.
>> >> >> >
>> >> >> > I am not sure whether Alexandre wanna me to update the code following each
>> >> >> > parent could only support one RTC or else.
>> >> >> >
>> >> >
>> >> >I want you to keep your changes local to your driver. I already stated
>> >> >back in 2018 that you were on your own with the imx-sc driver and that I
>> >> >don't like seeing multiple abstractions for existing RTCs. What is the
>> >> >actual use case behind needing to access both RTCs using Linux?
>> >> >Shouldn't this be handled on your firmware side?
>> >>
>> >> The firmware exports two RTCs, RTC0 could be handled by Linux, RTC1
>> >> could only be read by Linux and configuable by M7 per current i.MX95 EVK
>> >> firmware.
>> >
>> >This doesn't answer the main question, why is this useful? Where is the
>> >time of RTC1 coming from and why would linux set a different time on
>> >RTC0 ? Can't the firwmare just set the same time on both RTC0 and RTC1?
>>
>> To current i.MX95 EVK SCMI firmware, RTC0 is SoC internal RTC, RTC1 is
>> board level RTC which is more acurrate.
>>
>> There are safety island in i.MX95, M7 safety core is assigned owner of
>> RTC1. Linux non-safety is assigned owner of RTC0, but Linux could read RTC1
>> time, Linux not able to set alarm of RTC1.
>>
>> I need ask firmware developer to see whether RTC1 time could be synced to
>> RTC0 from firmware level. But considering RTC1 is more accurate, should we
>> use RTC1?
>>
>> The current firmware design is RTC0 is always there and exported, because
>> it is SoC internal RTC. RTC1 is board level one, it could be optional per
>> board design and firmware design.
>>
>> The firmware could update to only export RTC1 if no safety need it,
>> but this needs big change to the firmware BBM part, I need check with
>> firmware developer. But things may not change.
>>
>> >What would someone do if RTC0 and RTC1 don't agree on the time?
>>
>> RTC1 is more accurate if it is there.
>>
>
>Well, yes, you have your answer here, if the firmware knows RTC1 is more
>accurate and will be your source of truth, then simply use this one.
But issue is RTC1 is only readable to Linux non-safety, Linux not able
to set alarm. Linux could only use RTC0 for alarm with current i.MX95 EVK
firmware.
If RTC1 could be exported to linux for control, we could for sure
switch to using RTC1 without caring about RTC0. But this is not true.
RTC0 is free for linux to control, RTC1 not. Switching to RTC1 will make
us lose RTC alarm to wake up linux feature.
Thanks,
Peng
>
>
>--
>Alexandre Belloni, co-owner and COO, Bootlin
>Embedded Linux and Kernel engineering
>https://bootlin.com
Powered by blists - more mailing lists