| Message ID | 20250120-rtc-v1-0-08c50830bac9@nxp.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | rtc/scmi: Support multiple RTCs | expand |
Hello, On 20/01/2025 10:25:32+0800, Peng Fan (OSS) wrote: > i.MX95 System Manager(SM) BBM protocol exports two RTCs for EVK board. > one RTC is SoC internal RTC, the other is board RTC. > > The current driver only use the 1st RTC. With this patchset, both RTCs > could be used in Linux. To achieve this: > > 1. Support more event sources for BBM protocol > 2. Add bbm_info hook to let users could query the number of RTCs > 3. Introduce devm_rtc_allocate_device_priv to support setting rtc device > private information > 4. Update rtc-imx-sm-bbm.c to register both RTCs > I'm sorry but no, you have to register two RTCs like any other system would do. > Signed-off-by: Peng Fan <peng.fan@nxp.com> > --- > Peng Fan (4): > firmware: arm_scmi: imx: Support more event sources > firmware: arm_scmi: imx: Introduce bbm_info hook > rtc: Introduce devm_rtc_allocate_device_priv > rtc: imx-sm-bbm: Support multiple RTCs > > drivers/firmware/arm_scmi/vendors/imx/imx-sm-bbm.c | 33 ++++++++++- > drivers/rtc/class.c | 9 ++- > drivers/rtc/dev.c | 8 ++- > drivers/rtc/interface.c | 16 ++--- > drivers/rtc/proc.c | 2 +- > drivers/rtc/rtc-imx-sm-bbm.c | 69 ++++++++++++++-------- > include/linux/rtc.h | 2 + > include/linux/scmi_imx_protocol.h | 2 + > 8 files changed, 100 insertions(+), 41 deletions(-) > --- > base-commit: e7bb221a638962d487231ac45a6699fb9bb8f9fa > change-id: 20250116-rtc-3834e01786a8 > > Best regards, > -- > Peng Fan <peng.fan@nxp.com> >
Hi Alexandre > Subject: Re: [PATCH 0/4] rtc/scmi: Support multiple RTCs > > Hello, > > On 20/01/2025 10:25:32+0800, Peng Fan (OSS) wrote: > > i.MX95 System Manager(SM) BBM protocol exports two RTCs for EVK > board. > > one RTC is SoC internal RTC, the other is board RTC. > > > > The current driver only use the 1st RTC. With this patchset, both RTCs > > could be used in Linux. To achieve this: > > > > 1. Support more event sources for BBM protocol 2. Add bbm_info > hook to > > let users could query the number of RTCs 3. Introduce > > devm_rtc_allocate_device_priv to support setting rtc device > > private information > > 4. Update rtc-imx-sm-bbm.c to register both RTCs > > > > I'm sorry but no, you have to register two RTCs like any other system > would do. It is the i.MX SCMI Protocol exports two RTCs using one protocol. Two RTC devices are created, but share one parent device. Do you mean each RTC device should have a unique parent device? Thanks, Peng. > > > Signed-off-by: Peng Fan <peng.fan@nxp.com> > > --- > > Peng Fan (4): > > firmware: arm_scmi: imx: Support more event sources > > firmware: arm_scmi: imx: Introduce bbm_info hook > > rtc: Introduce devm_rtc_allocate_device_priv > > rtc: imx-sm-bbm: Support multiple RTCs > > > > drivers/firmware/arm_scmi/vendors/imx/imx-sm-bbm.c | 33 > ++++++++++- > > drivers/rtc/class.c | 9 ++- > > drivers/rtc/dev.c | 8 ++- > > drivers/rtc/interface.c | 16 ++--- > > drivers/rtc/proc.c | 2 +- > > drivers/rtc/rtc-imx-sm-bbm.c | 69 ++++++++++++++------- > - > > include/linux/rtc.h | 2 + > > include/linux/scmi_imx_protocol.h | 2 + > > 8 files changed, 100 insertions(+), 41 deletions(-) > > --- > > base-commit: e7bb221a638962d487231ac45a6699fb9bb8f9fa > > change-id: 20250116-rtc-3834e01786a8 > > > > Best regards, > > -- > > Peng Fan <peng.fan@nxp.com> > > > > -- > Alexandre Belloni, co-owner and COO, Bootlin > Embedded Linux and Kernel engineering > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > bootlin.com%2F&data=05%7C02%7Cpeng.fan%40nxp.com%7C7b5c28 > 0a03ee47dea25f08dd393c2e53%7C686ea1d3bc2b4c6fa92cd99c5c30 > 1635%7C0%7C0%7C638729652821885462%7CUnknown%7CTWFpbG > Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXa > W4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata > =xL23vC4m%2BtiTN8eNs8QptUHgfo%2FuHEUcEewGMdeYWYo%3D&r > eserved=0
Hi Alexandre, On Tue, Jan 21, 2025 at 02:31:55PM +0000, Peng Fan wrote: >Hi Alexandre > >> Subject: Re: [PATCH 0/4] rtc/scmi: Support multiple RTCs >> >> Hello, >> >> On 20/01/2025 10:25:32+0800, Peng Fan (OSS) wrote: >> > i.MX95 System Manager(SM) BBM protocol exports two RTCs for EVK >> board. >> > one RTC is SoC internal RTC, the other is board RTC. >> > >> > The current driver only use the 1st RTC. With this patchset, both RTCs >> > could be used in Linux. To achieve this: >> > >> > 1. Support more event sources for BBM protocol 2. Add bbm_info >> hook to >> > let users could query the number of RTCs 3. Introduce >> > devm_rtc_allocate_device_priv to support setting rtc device >> > private information >> > 4. Update rtc-imx-sm-bbm.c to register both RTCs >> > >> >> I'm sorry but no, you have to register two RTCs like any other system >> would do. > >It is the i.MX SCMI Protocol exports two RTCs using one protocol. > >Two RTC devices are created, but share one parent device. > >Do you mean each RTC device should have a unique parent device? Could you please share your ideas on this? Thanks, Peng > >Thanks, >Peng. > > > > >> >> > Signed-off-by: Peng Fan <peng.fan@nxp.com> >> > --- >> > Peng Fan (4): >> > firmware: arm_scmi: imx: Support more event sources >> > firmware: arm_scmi: imx: Introduce bbm_info hook >> > rtc: Introduce devm_rtc_allocate_device_priv >> > rtc: imx-sm-bbm: Support multiple RTCs >> > >> > drivers/firmware/arm_scmi/vendors/imx/imx-sm-bbm.c | 33 >> ++++++++++- >> > drivers/rtc/class.c | 9 ++- >> > drivers/rtc/dev.c | 8 ++- >> > drivers/rtc/interface.c | 16 ++--- >> > drivers/rtc/proc.c | 2 +- >> > drivers/rtc/rtc-imx-sm-bbm.c | 69 ++++++++++++++------- >> - >> > include/linux/rtc.h | 2 + >> > include/linux/scmi_imx_protocol.h | 2 + >> > 8 files changed, 100 insertions(+), 41 deletions(-) >> > --- >> > base-commit: e7bb221a638962d487231ac45a6699fb9bb8f9fa >> > change-id: 20250116-rtc-3834e01786a8 >> > >> > Best regards, >> > -- >> > Peng Fan <peng.fan@nxp.com> >> > >> >> -- >> Alexandre Belloni, co-owner and COO, Bootlin >> Embedded Linux and Kernel engineering >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >> bootlin.com%2F&data=05%7C02%7Cpeng.fan%40nxp.com%7C7b5c28 >> 0a03ee47dea25f08dd393c2e53%7C686ea1d3bc2b4c6fa92cd99c5c30 >> 1635%7C0%7C0%7C638729652821885462%7CUnknown%7CTWFpbG >> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXa >> W4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata >> =xL23vC4m%2BtiTN8eNs8QptUHgfo%2FuHEUcEewGMdeYWYo%3D&r >> eserved=0
On Tue, Jan 21, 2025 at 02:31:55PM +0000, Peng Fan wrote: > > It is the i.MX SCMI Protocol exports two RTCs using one protocol. > > Two RTC devices are created, but share one parent device. > > Do you mean each RTC device should have a unique parent device? > Can you point where is this check for unique parent ? I am not so familiar with RTC but I couldn't find myself with quick search.
On Tue, Feb 11, 2025 at 04:59:53PM +0000, Sudeep Holla wrote: >On Tue, Jan 21, 2025 at 02:31:55PM +0000, Peng Fan wrote: >> >> It is the i.MX SCMI Protocol exports two RTCs using one protocol. >> >> Two RTC devices are created, but share one parent device. >> >> Do you mean each RTC device should have a unique parent device? >> > >Can you point where is this check for unique parent ? I am not so familiar >with RTC but I couldn't find myself with quick search. The RTC ops takes the rtc parent as input parameter https://elixir.bootlin.com/linux/v6.13.2/source/drivers/rtc/interface.c#L94 "err = rtc->ops->read_time(rtc->dev.parent, tm);" So in the rtc device driver, there is no way to know which rtc it is just from the parent 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. Regards Peng > >-- >Regards, >Sudeep
On Wed, Feb 12, 2025 at 02:35:32PM +0800, Peng Fan wrote: > On Tue, Feb 11, 2025 at 04:59:53PM +0000, Sudeep Holla wrote: > >On Tue, Jan 21, 2025 at 02:31:55PM +0000, Peng Fan wrote: > >> > >> It is the i.MX SCMI Protocol exports two RTCs using one protocol. > >> > >> Two RTC devices are created, but share one parent device. > >> > >> Do you mean each RTC device should have a unique parent device? > >> > > > >Can you point where is this check for unique parent ? I am not so familiar > >with RTC but I couldn't find myself with quick search. > > The RTC ops takes the rtc parent as input parameter > https://elixir.bootlin.com/linux/v6.13.2/source/drivers/rtc/interface.c#L94 > "err = rtc->ops->read_time(rtc->dev.parent, tm);" > > So in the rtc device driver, there is no way to know which rtc it is just > from the parent device. > If that is the expectation, you could create a platform or normal device per instance of RTC on your platform and slap them as parent device. 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 assume something like my suggestion above. -- Regards, Sudeep
On 12/02/2025 10:43:24+0000, Sudeep Holla wrote: > On Wed, Feb 12, 2025 at 02:35:32PM +0800, Peng Fan wrote: > > On Tue, Feb 11, 2025 at 04:59:53PM +0000, Sudeep Holla wrote: > > >On Tue, Jan 21, 2025 at 02:31:55PM +0000, Peng Fan wrote: > > >> > > >> It is the i.MX SCMI Protocol exports two RTCs using one protocol. > > >> > > >> Two RTC devices are created, but share one parent device. > > >> > > >> Do you mean each RTC device should have a unique parent device? > > >> > > > > > >Can you point where is this check for unique parent ? I am not so familiar > > >with RTC but I couldn't find myself with quick search. > > > > The RTC ops takes the rtc parent as input parameter > > https://elixir.bootlin.com/linux/v6.13.2/source/drivers/rtc/interface.c#L94 > > "err = rtc->ops->read_time(rtc->dev.parent, tm);" > > > > So in the rtc device driver, there is no way to know which rtc it is just > > from the parent device. > > > > If that is the expectation, you could create a platform or normal device > per instance of RTC on your platform and slap them as parent device. This would seem like the proper solution, why not using an MFD or auxiliary bus ? > > 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?
On Wed, Feb 12, 2025 at 06:01:47PM +0100, Alexandre Belloni wrote: >On 12/02/2025 10:43:24+0000, Sudeep Holla wrote: >> On Wed, Feb 12, 2025 at 02:35:32PM +0800, Peng Fan wrote: >> > On Tue, Feb 11, 2025 at 04:59:53PM +0000, Sudeep Holla wrote: >> > >On Tue, Jan 21, 2025 at 02:31:55PM +0000, Peng Fan wrote: >> > >> >> > >> It is the i.MX SCMI Protocol exports two RTCs using one protocol. >> > >> >> > >> Two RTC devices are created, but share one parent device. >> > >> >> > >> Do you mean each RTC device should have a unique parent device? >> > >> >> > > >> > >Can you point where is this check for unique parent ? I am not so familiar >> > >with RTC but I couldn't find myself with quick search. >> > >> > The RTC ops takes the rtc parent as input parameter >> > https://elixir.bootlin.com/linux/v6.13.2/source/drivers/rtc/interface.c#L94 >> > "err = rtc->ops->read_time(rtc->dev.parent, tm);" >> > >> > So in the rtc device driver, there is no way to know which rtc it is just >> > from the parent device. >> > >> >> If that is the expectation, you could create a platform or normal device >> per instance of RTC on your platform and slap them as parent device. thanks for the proposal, Sudeep. > >This would seem like the proper solution, why not using an MFD or >auxiliary bus ? Not sure which is better. I need give a look which is simpiler for current BBM RTC. > >> >> 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. The firmware itself does not serve Linux. And we not know others how to use the protocol. So the firmware will not be updated for only Linux. I got your point to keep changes local to the rtc bbm driver, I will give a look on how to achieve this. Thanks, Peng > > >-- >Alexandre Belloni, co-owner and COO, Bootlin >Embedded Linux and Kernel engineering >https://bootlin.com
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? What would someone do if RTC0 and RTC1 don't agree on the time?
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. Thanks, Peng > >-- >Alexandre Belloni, co-owner and COO, Bootlin >Embedded Linux and Kernel engineering >https://bootlin.com
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.
On 13/02/2025 21:35:50+0800, Peng Fan wrote: > >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. > This doesn't make any sense, this limitation is on your firmware side, either RTC1 has alarm support and the firmware can set the alarm for linux or it doesn't and then, the firmware must set the time and alarm on RTC0.
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
On Thu, Feb 13, 2025 at 01:54:42PM +0100, Alexandre Belloni wrote: >On 13/02/2025 21:35:50+0800, Peng Fan wrote: >> >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. >> > >This doesn't make any sense, this limitation is on your firmware side, >either RTC1 has alarm support and the firmware can set the alarm for >linux or it doesn't and then, the firmware must set the time and alarm >on RTC0. ok. I thought to export both RTCs to Linux if both are configured for linux usage. From the discussion, I suppose you prefer linux only use one RTC. Let me try to update the rtc bbm driver to use RTC1 when RTC1 is exposed to Linux for usage. If RTC1 is not exposed for Linux, use RTC0. Regards Peng. > >-- >Alexandre Belloni, co-owner and COO, Bootlin >Embedded Linux and Kernel engineering >https://bootlin.com
i.MX95 System Manager(SM) BBM protocol exports two RTCs for EVK board. one RTC is SoC internal RTC, the other is board RTC. The current driver only use the 1st RTC. With this patchset, both RTCs could be used in Linux. To achieve this: 1. Support more event sources for BBM protocol 2. Add bbm_info hook to let users could query the number of RTCs 3. Introduce devm_rtc_allocate_device_priv to support setting rtc device private information 4. Update rtc-imx-sm-bbm.c to register both RTCs Signed-off-by: Peng Fan <peng.fan@nxp.com> --- Peng Fan (4): firmware: arm_scmi: imx: Support more event sources firmware: arm_scmi: imx: Introduce bbm_info hook rtc: Introduce devm_rtc_allocate_device_priv rtc: imx-sm-bbm: Support multiple RTCs drivers/firmware/arm_scmi/vendors/imx/imx-sm-bbm.c | 33 ++++++++++- drivers/rtc/class.c | 9 ++- drivers/rtc/dev.c | 8 ++- drivers/rtc/interface.c | 16 ++--- drivers/rtc/proc.c | 2 +- drivers/rtc/rtc-imx-sm-bbm.c | 69 ++++++++++++++-------- include/linux/rtc.h | 2 + include/linux/scmi_imx_protocol.h | 2 + 8 files changed, 100 insertions(+), 41 deletions(-) --- base-commit: e7bb221a638962d487231ac45a6699fb9bb8f9fa change-id: 20250116-rtc-3834e01786a8 Best regards,