Add MFD Support for Motorola mc146818 RTC, Counter, and BBRAM #91751

akanisetti · 2025-06-17T08:22:12Z

This PR introduces support for the Motorola mc146818 RTC and its associated functionalities through a Multi-Function Device (MFD) framework. The following key changes are included:

MFD Driver: Added and enabled the motorola, mc146818 MFD driver to manage RTC read/write operations and ensure data integrity through synchronized access.
RTC Driver: Enabled MFD support in the existing RTC driver for mc146818.
Counter Driver: Integrated MFD support into the CMOS counter driver.
BBRAM Driver: Enabled access to RTC RAM via a new BBRAM driver under the MFD hierarchy.
Device Tree Updates: Modified relevant .dtsi files to support the mc146818 MFD, including RTC, Counter, and BBRAM components.

These changes collectively enable full support for the mc146818 device and its subcomponents in a modular and maintainable way.

Signed-off-by: Anisetti Avinash Krishna anisetti.avinash.krishna@intel.com

Copilot

Pull Request Overview

This PR enables the Motorola MC146818 RTC’s 241 byte battery-backed RAM (BBRAM) as a child device of the MC146818 RTC on Raptor Lake-S platforms.

Extracts and centralizes the RTC driver’s data structure into a shared header.
Adds device-tree nodes and bindings for the MC146818 BBRAM.
Introduces and integrates a new bbram_mc146818 driver, plus corresponding Kconfig and build files.

Reviewed Changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
include/zephyr/drivers/rtc/mc146818.h	Define shared `rtc_mc146818_data` struct
dts/x86/intel/raptor_lake_s.dtsi	Add `bbram@72` node under RTC for battery-backed RAM
dts/bindings/memory-controllers/motorola,mc146818-bbram.yaml	Create binding for `motorola,mc146818-bbram`
drivers/rtc/rtc_mc146818.c	Remove duplicate struct, include new header
drivers/bbram/bbram_mc146818.c	New driver implementation for MC146818 BBRAM
drivers/bbram/Kconfig.mc146818	Add Kconfig option for MC146818 BBRAM
drivers/bbram/Kconfig	Include the new Kconfig file
drivers/bbram/CMakeLists.txt	Add `bbram_mc146818.c` to library sources
boards/intel/rpl/intel_rpl_s_crb.dts	Alias `bbram` to the new BBRAM node

drivers/bbram/bbram_mc146818.c

dts/x86/intel/raptor_lake_s.dtsi

bjarki-andreasen

Please check out how the ds3231 is implemented, moving common functions of the "parent" device to include/zephyr/drivers/mfd and implementation of common code to zephyr/drivers/mfd, while keeping the bbram and rtc partial drivers isolated (not sharing data structures between one or the other.

akanisetti · 2025-06-27T07:01:52Z

Please check out how the ds3231 is implemented, moving common functions of the "parent" device to include/zephyr/drivers/mfd and implementation of common code to zephyr/drivers/mfd, while keeping the bbram and rtc partial drivers isolated (not sharing data structures between one or the other.

Sure, I will add the modifications suggested. With this approach the intension is to avoid data structures between BBRAM and RTC, but they will be two independent drivers under one MFD driver as its child nodes in DTS. Please confirm if my understanding is correct.

bjarki-andreasen · 2025-06-27T08:11:38Z

Please check out how the ds3231 is implemented, moving common functions of the "parent" device to include/zephyr/drivers/mfd and implementation of common code to zephyr/drivers/mfd, while keeping the bbram and rtc partial drivers isolated (not sharing data structures between one or the other.

Sure, I will the modifications suggested. With this approach the intension is to avoid data structures between BBRAM and RTC, but they will be two independent drivers under one MFD driver as its child nodes in DTS. Please confirm if my understanding is correct.

That is correct :) It should be possible to enable only BBRAM, and only RTC parts of the device. That means, using kconfig to describe it, you should have

config MFD_MC146818
        bool
        help
          common code required by bbram and rtc, which will likely be a locking mechanism and a bus transfer,
          so both RTC and BBRAM can set/get regs on the "bus/device" safely and independently. The MC146818
          may not actually need this if the registers can be and will be interacted with independently, this would be
          for a i2c or spi attached device for example

config RTC_MC146818
        bool "RTC driver part"
        select MFD_MC146818
        depends on RTC

config BBRAM_MC146818
        bool "BBRAM driver part"
        select MFD_MC146818
        depends on BBRAM

akanisetti · 2025-06-30T07:00:03Z

Please check out how the ds3231 is implemented, moving common functions of the "parent" device to include/zephyr/drivers/mfd and implementation of common code to zephyr/drivers/mfd, while keeping the bbram and rtc partial drivers isolated (not sharing data structures between one or the other.

Sure, I will the modifications suggested. With this approach the intension is to avoid data structures between BBRAM and RTC, but they will be two independent drivers under one MFD driver as its child nodes in DTS. Please confirm if my understanding is correct.

That is correct :) It should be possible to enable only BBRAM, and only RTC parts of the device. That means, using kconfig to describe it, you should have
config MFD_MC146818
        bool
        help
          common code required by bbram and rtc, which will likely be a locking mechanism and a bus transfer,
          so both RTC and BBRAM can set/get regs on the "bus/device" safely and independently. The MC146818
          may not actually need this if the registers can be and will be interacted with independently, this would be
          for a i2c or spi attached device for example

config RTC_MC146818
        bool "RTC driver part"
        select MFD_MC146818
        depends on RTC

config BBRAM_MC146818
        bool "BBRAM driver part"
        select MFD_MC146818
        depends on BBRAM

A small query regarding counter, using this method COUNTER_CMOS will also have dependency on MFD_MC146818.

bjarki-andreasen · 2025-06-30T09:44:34Z

Please check out how the ds3231 is implemented, moving common functions of the "parent" device to include/zephyr/drivers/mfd and implementation of common code to zephyr/drivers/mfd, while keeping the bbram and rtc partial drivers isolated (not sharing data structures between one or the other.

Sure, I will the modifications suggested. With this approach the intension is to avoid data structures between BBRAM and RTC, but they will be two independent drivers under one MFD driver as its child nodes in DTS. Please confirm if my understanding is correct.

That is correct :) It should be possible to enable only BBRAM, and only RTC parts of the device. That means, using kconfig to describe it, you should have
config MFD_MC146818
        bool
        help
          common code required by bbram and rtc, which will likely be a locking mechanism and a bus transfer,
          so both RTC and BBRAM can set/get regs on the "bus/device" safely and independently. The MC146818
          may not actually need this if the registers can be and will be interacted with independently, this would be
          for a i2c or spi attached device for example

config RTC_MC146818
        bool "RTC driver part"
        select MFD_MC146818
        depends on RTC

config BBRAM_MC146818
        bool "BBRAM driver part"
        select MFD_MC146818
        depends on BBRAM
A small query regarding counter, using this method COUNTER_CMOS will also have dependency on MFD_MC146818.

Sort if, COUNTER_CMOS and RTC_MC146818 are mutually exclusive, COUNTER_CMOS is just there for legacy reasons, you could refactor it to work with MFD_MC146818 yes, but unless you have a usecase specifically for COUNTER_CMOS I would leave it alone :)

akanisetti · 2025-06-30T09:49:14Z

Please check out how the ds3231 is implemented, moving common functions of the "parent" device to include/zephyr/drivers/mfd and implementation of common code to zephyr/drivers/mfd, while keeping the bbram and rtc partial drivers isolated (not sharing data structures between one or the other.

Sure, I will the modifications suggested. With this approach the intension is to avoid data structures between BBRAM and RTC, but they will be two independent drivers under one MFD driver as its child nodes in DTS. Please confirm if my understanding is correct.

That is correct :) It should be possible to enable only BBRAM, and only RTC parts of the device. That means, using kconfig to describe it, you should have
config MFD_MC146818
        bool
        help
          common code required by bbram and rtc, which will likely be a locking mechanism and a bus transfer,
          so both RTC and BBRAM can set/get regs on the "bus/device" safely and independently. The MC146818
          may not actually need this if the registers can be and will be interacted with independently, this would be
          for a i2c or spi attached device for example

config RTC_MC146818
        bool "RTC driver part"
        select MFD_MC146818
        depends on RTC

config BBRAM_MC146818
        bool "BBRAM driver part"
        select MFD_MC146818
        depends on BBRAM
A small query regarding counter, using this method COUNTER_CMOS will also have dependency on MFD_MC146818.
Sort if, COUNTER_CMOS and RTC_MC146818 are mutually exclusive, COUNTER_CMOS is just there for legacy reasons, you could refactor it to work with MFD_MC146818 yes, but unless you have a usecase specifically for COUNTER_CMOS I would leave it alone :)

Okay, I will update the PR accordingly

bjarki-andreasen

Fantastic work! I have a few improvements but overall the addition is great!

bjarki-andreasen · 2025-07-18T10:21:53Z

drivers/rtc/rtc_mc146818.c

+	RTC_MC146818_INIT_FN_DEFINE(inst)					   \
+	DEVICE_DT_INST_DEFINE(inst, &rtc_mc146818_init##inst, NULL,		   \
+			      &rtc_mc146818_data##inst, &rtc_mc146818_config##inst,\
+			      POST_KERNEL, CONFIG_RTC_INIT_PRIORITY,		   \


Here, update the CONFIG_RTC_INIT_PRIORITY to UTIL_INC(CONFIG_MFD_MOTOROLA_MC146818_INIT_PRIORITY). This will ensure the RTC is always initialized right after the parent :)

do the same for the counter based driver :)

bjarki-andreasen · 2025-07-18T10:22:31Z

drivers/bbram/bbram_mc146818.c

+	DEVICE_DT_INST_DEFINE(n, &bbram_mc146818_init, NULL,		\
+				&bbram_data_##n, &bbram_config_##n,	\
+				POST_KERNEL,				\
+				CONFIG_KERNEL_INIT_PRIORITY_DEVICE,	\


UTIL_INC(CONFIG_MFD_MOTOROLA_MC146818_INIT_PRIORITY)

bjarki-andreasen · 2025-07-18T10:24:37Z

dts/x86/intel/alder_lake.dtsi

+		mfd: mfd@70 {
+			compatible = "motorola,mc146818-mfd";
+			reg = <0x70 0x01 0x71 0x01 0x72 0x01 0x73 0x01>;
+
+			rtc: counter: rtc {
+				compatible = "motorola,mc146818";
+				interrupts = <8 IRQ_TYPE_LOWEST_EDGE_RISING 3>;
+				interrupt-parent = <&intc>;
+				alarms-count = <1>;
+
+				status = "okay";
+			};
+
+			bbram: bbram {
+				compatible = "motorola,mc146818-bbram";
+				size = <241>;
+				status = "okay";
+			};


add this as an example snippet to the description of the binding for "motorola,mc146818-mfd". That way it is clear to users how the MFD is supposed to be added to an soc :)

bjarki-andreasen · 2025-07-18T10:25:42Z

dts/bindings/mfd/motorola,mc146818-mfd.yaml

+
+compatible: "motorola,mc146818-mfd"
+
+include: base.yaml


add the following entry here

bus: mc146818-mfd

then extend the bindings for the child devices with on-bus: mc146818-mfd to help users know the child bindings belong to this parent mfd :)

Enabled Motorola, mc146818 MFD, which implements RTC read/write operations and prevents data corruption by synchronizing these operations. Signed-off-by: Anisetti Avinash Krishna <anisetti.avinash.krishna@intel.com>

Enabled support for motorola mc146818 RTC driver. Signed-off-by: Anisetti Avinash Krishna <anisetti.avinash.krishna@intel.com>

Enabled support for MFD in CMOS counter. Signed-off-by: Anisetti Avinash Krishna <anisetti.avinash.krishna@intel.com>

Enables bbram driver for motorola, mc146818 under its MFD to access the RAM of the RTC. Signed-off-by: Anisetti Avinash Krishna <anisetti.avinash.krishna@intel.com>

Added required modifications to dtsi files to support Motorola, mc146818 MFD, Counter, RTC, and BBRAM (for supported devices). Signed-off-by: Anisetti Avinash Krishna <anisetti.avinash.krishna@intel.com>

bjarki-andreasen

Nice!

sonarqubecloud · 2025-07-18T12:31:10Z

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

akanisetti · 2025-07-18T13:25:27Z

Hi @yperess, could you please review the PR

yperess · 2025-07-18T13:49:28Z

Hi @yperess, could you please review the PR

Please fix the checks, whatever review I give will be dismissed automatically even if it's just a lint check that's failing.

akanisetti · 2025-07-18T13:53:18Z

Hi @yperess, could you please review the PR

Please fix the checks, whatever review I give will be dismissed automatically even if it's just a lint check that's failing.

The check failure is not related to this PR and has to be fixed by another PR. So please continue with the review as I am working on fixing it through another PR.

akanisetti · 2025-07-21T07:22:36Z

PR has been created to resolve the twister issue #93403

seov-nordic

Looks good!

akanisetti requested a review from Copilot June 18, 2025 05:54

Copilot AI reviewed Jun 18, 2025

View reviewed changes

drivers/bbram/bbram_mc146818.c Outdated Show resolved Hide resolved

drivers/bbram/bbram_mc146818.c Show resolved Hide resolved

dts/x86/intel/raptor_lake_s.dtsi Outdated Show resolved Hide resolved

akanisetti force-pushed the bbram_mc141618 branch from b21938c to c4d4ff9 Compare June 24, 2025 04:35

akanisetti marked this pull request as ready for review June 24, 2025 05:19

github-actions bot added platform: X86 x86 and x86-64 area: MEMC area: RTC Real Time Clock area: Battery Backed RAM (bbram) labels Jun 24, 2025

github-actions bot requested review from bjarki-andreasen, ceolin, dcpleung, edersondisouza, najumon1980, teburd and yperess June 24, 2025 05:20

github-actions bot assigned yperess Jun 24, 2025

bjarki-andreasen requested changes Jun 24, 2025

View reviewed changes

akanisetti force-pushed the bbram_mc141618 branch from c4d4ff9 to 5f1f6b3 Compare July 18, 2025 07:45

zephyrbot added the platform: Intel Intel Corporation label Jul 18, 2025

akanisetti force-pushed the bbram_mc141618 branch from 5f1f6b3 to d38e461 Compare July 18, 2025 07:46

zephyrbot added area: MFD area: Counter labels Jul 18, 2025

akanisetti changed the title ~~drivers: bbram: Enable bbram driver for MC146818~~ Add MFD Support for Motorola mc146818 RTC, Counter, and BBRAM Jul 18, 2025

zephyrbot requested review from aasinclair and nordic-auko July 18, 2025 07:47

zephyrbot requested review from nordic-krch and seov-nordic July 18, 2025 07:47

akanisetti force-pushed the bbram_mc141618 branch 2 times, most recently from fa69ee0 to 9ec3de2 Compare July 18, 2025 10:12

bjarki-andreasen requested changes Jul 18, 2025

View reviewed changes

akanisetti added 5 commits July 18, 2025 16:46

drivers: mfd: Enabled motorola,mc146818 MFD

1112f04

Enabled Motorola, mc146818 MFD, which implements RTC read/write operations and prevents data corruption by synchronizing these operations. Signed-off-by: Anisetti Avinash Krishna <anisetti.avinash.krishna@intel.com>

drivers: rtc: Enabled MFD support for RTC mc146818

ff34ca5

Enabled support for motorola mc146818 RTC driver. Signed-off-by: Anisetti Avinash Krishna <anisetti.avinash.krishna@intel.com>

drivers: counter: Enables support for MFD in counter

de736cd

Enabled support for MFD in CMOS counter. Signed-off-by: Anisetti Avinash Krishna <anisetti.avinash.krishna@intel.com>

drivers: bbram: Enables bbram driver for motorola, mc146818

bb75220

Enables bbram driver for motorola, mc146818 under its MFD to access the RAM of the RTC. Signed-off-by: Anisetti Avinash Krishna <anisetti.avinash.krishna@intel.com>

dts: x86: Added required modifications to support RTC MFD

bd736c3

Added required modifications to dtsi files to support Motorola, mc146818 MFD, Counter, RTC, and BBRAM (for supported devices). Signed-off-by: Anisetti Avinash Krishna <anisetti.avinash.krishna@intel.com>

akanisetti force-pushed the bbram_mc141618 branch from 9ec3de2 to bd736c3 Compare July 18, 2025 12:06

bjarki-andreasen approved these changes Jul 18, 2025

View reviewed changes

seov-nordic approved these changes Jul 21, 2025

View reviewed changes


		compatible: "motorola,mc146818-mfd"

		include: base.yaml

Add MFD Support for Motorola mc146818 RTC, Counter, and BBRAM #91751

Are you sure you want to change the base?

Add MFD Support for Motorola mc146818 RTC, Counter, and BBRAM #91751

Uh oh!

Conversation

akanisetti commented Jun 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull Request Overview

Reviewed Changes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

bjarki-andreasen left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

akanisetti commented Jun 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

bjarki-andreasen commented Jun 27, 2025

Uh oh!

akanisetti commented Jun 30, 2025

Uh oh!

bjarki-andreasen commented Jun 30, 2025

Uh oh!

akanisetti commented Jun 30, 2025

Uh oh!

bjarki-andreasen left a comment

Choose a reason for hiding this comment

Uh oh!

bjarki-andreasen Jul 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bjarki-andreasen Jul 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bjarki-andreasen left a comment

Choose a reason for hiding this comment

Uh oh!

sonarqubecloud bot commented Jul 18, 2025

Quality Gate passed

Uh oh!

akanisetti commented Jul 18, 2025

Uh oh!

yperess commented Jul 18, 2025

Uh oh!

akanisetti commented Jul 18, 2025

Uh oh!

akanisetti commented Jul 21, 2025

Uh oh!

seov-nordic left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

akanisetti commented Jun 17, 2025 •

edited

Loading

bjarki-andreasen left a comment •

edited

Loading

akanisetti commented Jun 27, 2025 •

edited

Loading

bjarki-andreasen Jul 18, 2025 •

edited

Loading

bjarki-andreasen Jul 18, 2025 •

edited

Loading