13-I2C3-pcf8563rtc

Peripheral wiring

The peripheral pcf8563rtc is connected to the i2c in the expansion port

** Note: Our expansion port is not with pull, please add it in the external device. **

image-20250222151504558

Actual connection

image-20241101111421019

Device driver porting

​ The SDK of H618 comes with pcf8563 driver port by default, which is not introduced in detail here

​ Drive migration ​ Put the driver under h618-android12.0\longan\kernel\linux-5.4\drivers\rtc,

​ Modify the Makefile to add obj-$(CONFIG_RTC_DRV_PCF8563) += rtc-pcf8563.o ​ Modified Kconfig added

//make menuconfig options
config RTC_DRV_PCF8563
	tristate "Philips PCF8563/Epson RTC8564"
	help
	  If you say yes here you get support for the
	  Philips PCF8563 RTC chip. The Epson RTC8564
	  should work as well.

	  This driver can also be built as a module. If so, the module
	  will be called rtc-pcf8563.

Kernel enable

--- a/longan/kernel/linux-5.4/arch/arm64/configs/sun50iw9p1smp_h618_android_defconfig
+++ b/longan/kernel/linux-5.4/arch/arm64/configs/sun50iw9p1smp_h618_android_defconfig
@@ -463,7 +463,8 @@ CONFIG_MMC_BLOCK_MINORS=16
 CONFIG_MMC_SUNXI=y
 # CONFIG_MMC_SUNXI_V4P10X is not set
 CONFIG_RTC_CLASS=y
-CONFIG_RTC_DRV_SUNXI=y
+#CONFIG_RTC_DRV_SUNXI is not set
+CONFIG_RTC_DRV_PCF8563=y
 CONFIG_SUNXI_REBOOT_FLAG=y
 CONFIG_SUNXI_FAKE_POWEROFF=y
 CONFIG_DMADEVICES=y

An rtc node is added to the I2C3 device tree

--- a/longan/device/config/chips/h618/configs/p2/linux-5.4/board.dts
+++ b/longan/device/config/chips/h618/configs/p2/linux-5.4/board.dts
@@ -622,6 +622,14 @@
        pinctrl-names = "default", "sleep";
        twi_drv_used = <1>;
        status = "okay";
+
+    pcf8563:pcf8563@51 {
+        compatible = "nxp,pcf8563";
+        reg = <0x51>;  /* I2C address */
+
+        status = "okay";
+               #clock-cells = <0>;
+    };
 };

****【 Test whether the rtc driver works normally with date and hwclock 】 **** In general, the simplest step to test whether rtc is working properly is to load the rtc driver (or its own driver has been compiled into the kernel) :

1. Display the current Linux system time date [2] If the date is also out of whack, like 1970 or something, rather than my current time, like 2009, then manually set the correct time yourself date MMDDhhmm[[[YY]YY][.ss]][.ss]

2. Display the hardware rtc time hwclock Since this is the first time for the rtc driver to load, the correct time has not been set, so the time displayed at this time is mostly incorrect in 1969,1970.

3. Set the Linux system time to the hardware rtc hwclock -w

4. Check whether the hardware rtc time is the same as that in the system hwclcok If the driver is working correctly, the time shown here should be consistent with your current system time, which is the legendary time synchronization... Otherwise, it means that your driver is not working correctly, and the system time is not correctly set into the hardware rtc, so you have to go back to debugging the driver and find the reason.

5. Wait a few seconds and type again: hwclock If it is normal, you will see the time here, with the corresponding number of seconds added to the time shown in Step 5 That means the rtc is working properly.

RTC interrupt test:

set the alarm clock

echo 0 > /sys/class/rtc/rtc0/wakealarm  //empty

echo +60 > /sys/class/rtc/rtc0/wakealarm //set-up time 

View the rtc information

cat /proc/driver/rtc

img

Alarm clock time to RTC interrupt has printing (need to add yourself)

static irqreturn_t hym8563_irq(int irq, void *dev_id)
{
  struct hym8563 *hym8563 = (struct hym8563 *)dev_id;
  struct i2c_client *client = hym8563->client;
  struct mutex *lock = &hym8563->rtc->ops_lock;
  int data, ret;
  printk("kickpi %s %d\n",__FUNCTION__,__LINE__); //加的打印
  mutex_lock(lock);

  /* Clear the alarm flag */
  data = i2c_smbus_read_byte_data(client, HYM8563_CTL2);
  if (data < 0) {
    dev_err(&client->dev, "%s: error reading i2c data %d\n",
      __func__, data);
    goto out;
  }
  data &= ~HYM8563_CTL2_AF;
  
  ret = i2c_smbus_write_byte_data(client, HYM8563_CTL2, data);
  if (ret < 0) {
   dev_err(&client->dev, "%s: error writing i2c data %d\n",
     __func__, ret);
  }
out:
  mutex_unlock(lock);
  return IRQ_HANDLED;
}

The results are as follows:

img