RTC的驱动移植和从底层到APP的执行过程

RTC的驱动移植和从底层到APP的执行过程

唠叨几句，本文目的是：

1>移植hym8563的rtc驱动，硬件板载是S905X，操作系统是Android7.1。

2>从drivers分析道DateTimeSetting.java的执行过程。

首先把hym8563的驱动加到rtc的位置，我放的位置则是./common/drivers/amlogic/rtc下，修改rtc下的Makefile文件和Kconfig文件，如下：

config HYM8563_RTC

    bool "hym8563 RTC support"

    depends on I2C && OF

    help

      This is the Hym8563  Real Time Clock driver.

obj-$(CONFIG_HYM8563_RTC)+= rtc_hym8563.o

然后在./common/arch/arm64/configs/meson_defconfig下的文件中加入CONFIG_HYM8563_RTC=y,

以上是驱动的加入过程，底下进入驱动的适配和调试环节，首先在dts里加入设备驱动文件，当然作为驱动工作者，从硬件工程师哪里获得相应的硬件信息是必须的，I2C的从机地址，挂载的I2C的核心，细节不在啰嗦，以结果为例。

i2c_ao: i2c@c8100500{ /*I2C-AO*/

                compatible = "amlogic, meson-i2c";

                dev_name = "i2c-AO";

                status = "okay";

                reg = <0x0 0xc8100500 0x0 0x1d>;

                device_id = <0>;

                pinctrl-names="default";

                pinctrl-0=<&ao_i2c_master>;

                #address-cells = <1>;

                #size-cells = <0>;

                use_pio = <0>;

                master_i2c_speed = <300000>;

                clocks = <&clock CLK_81>;

                clock-names = "clk_i2c";

                resets = <&clock GCLK_IDX_I2C>;

                hym8563: hym8563@51 {

                                compatible= "haoyu,hym8563";

                                reg = <0x51>;

                                interrupts = <0 66 1>;

                                i2c_bus = "i2c_bus_ao";

                                #clock-cells = <0>;

                                status = "okay";

                                };

}

这里分享个I2C器件地址获得小诀窍，根据IC的datasheet，获取设备的读或者写的从机地址，除以2，就是我们现在的0x51,至于为什么要除以2呢，则是跟设备器件地址的<<1是有关系的。

加入后编译，发现interrupt的request是报错的，但是由于我们的中断时悬空的，因此直接将驱动里的中断代码屏蔽，以后再做研究。然烧录后发现却没办法调用到外挂RTC，这里的JNI确实只是调用了aml_vrtc.c的驱动，一会给出问题出在哪里。

首先amlogic的代码真的必须被吐槽，编译适配感觉还是有点弱的感觉，举个例子，修改的地方编译老是有种写入文件虽然编译OK，但是编译结果却没有被编译到最后的aml_upgrade的文件里，最惹人烦的就是修改了uboot，但是一直没有打印添加的追踪打印代码，后来检查out下的打包时间，发现时间不一样，删掉uboot才打包OK，在这在编译使用hwclock时也出现，必须吐槽下。

s905x的RTC的驱动接口有两个，一个是rtc_dev.c，一个是aml_dev.c这里也许有amlogic的自己做个炉子的目的，但是rtc_dev.c做的确实比aml_dev.c好，这里就是为什么只能调用aml_vrtc，不能调用外部驱动了，在alarmtimer.c里定义了一个rtcdev的实体，

static struct rtc_device *rtcdev；

然后按照加载顺序，先是加载hym8564驱动，然后加载aml_vrtc所以，rtcdev的驱动实例是aml_vrtc，故JNI里执行时，获得实例对象是aml_vrtc，这里可以修改下，就可以执行到外部驱动了，我的修改办法则是创照一个结构体，用来放数据。

 static struct rtc_device{

int Val =0;

static struct rtc_device *rtcdev[3];

}rtc_sec;

在alarmtimer_rtc_add_device里加入：

rtc_sec.Val++;

rtc_sec.rtcdev[rtc_sec.Val] = rtc;

在alarmtimer_get_rtcdev里修改为

ret = rtc_sec.rtcdev[0];

这样也有个问题就是如果rtc驱动超过三个或者第一个rtc驱动不能实现功能怎么办，这个确实想到了，但是编程量太大，项目时间紧迫，就没有深入继续写。但是如果按照amlogic的加载顺序，只要是外部rtc首选加载，加载驱动不超过三个，就不会有问题。当然这只是一个解决办法，随着分析的继续，在JNI里也会给出另外一种解决办法。

简单分析下aml-dev.c和rtc-dev.c

首先分析aml-dev.c这里的代码时amlogic官方的配置墙时间和闹钟的入口，当然也是一file_ops的作为入口分析，对驱动有一定的研究的都知道驱动API，这里不做细节分析，只是简单讲下这个文件怎么执行到hym8563的。

static const struct file_operations alarm_fops = {

.owner = THIS_MODULE,

.unlocked_ioctl = alarm_ioctl,

.open = alarm_open,

.release = alarm_release,

#ifdef CONFIG_COMPAT

.compat_ioctl = alarm_compat_ioctl,

#endif

};

这个是驱动API，分析ioctl函数：这里只分析set时间和get时间，闹钟过程，其他的copy_to_user等代码不在分析。

逻辑进入到alarm_do_ioctl这个函数。点入到这个函数发现：如下

switch (ANDROID_ALARM_BASE_CMD(cmd)) {

case ANDROID_ALARM_CLEAR(0):

alarm_clear(alarm_type);

break;

case ANDROID_ALARM_SET(0):

alarm_set(alarm_type, ts);

break;

case ANDROID_ALARM_SET_AND_WAIT(0):

alarm_set(alarm_type, ts);

/* fall though */

case ANDROID_ALARM_WAIT:

rv = alarm_wait();

break;

case ANDROID_ALARM_SET_RTC:

rv = alarm_set_rtc(ts);

break;

case ANDROID_ALARM_GET_TIME(0):

rv = alarm_get_time(alarm_type, ts);

break;

 

default:

rv = -EINVAL;

}

这里就是我们的rtc时间设置，获得，闹钟的设置。这里只分析alarm_set_rtc。其他都一样。

进入到alarm_set_rtc，这里有两个函数指的关注：

rtc_dev = alarmtimer_get_rtcdev();这里就是执行不到外部驱动RTC的罪恶之地。此时在alarmtimer.c里

{

ret =rtcdev;

}

而rtcdev则是在驱动挂载时adddevice的。因为aml_vrtc是最后一个加载，而这里的只是定义了一个rtcdev，因此后来者把前者覆盖，故执行不到hym8563里。希望amlogic的官方可以看到。

rv = rtc_set_time(rtc_dev, &new_rtc_tm);这里进入到interface.c的代码里。

rtc_set_time

-> err = rtc->ops->set_time(rtc->dev.parent, tm);这里就执行到hym8563的驱动了。

而rtc_dev.c的案例与这里类似，都是走到interface.c中，只是如果你选择open /dev/alarm则是这条路线，如果你选择open /dev/rtc0，则是走的是rtc-dev.c的这个执行逻辑。

 

下面分析JNI的执行逻辑：

frameworks\base\services\core\jni\com_android_server_AlarmManagerService.cpp这里是rtc的native层。

具体函数如下：

static const JNINativeMethod sMethods[] = {

     /* name, signature, funcPtr */

    {"init", "()J", (void*)android_server_AlarmManagerService_init},

    {"close", "(J)V", (void*)android_server_AlarmManagerService_close},

    {"set", "(JIJJ)V", (void*)android_server_AlarmManagerService_set},

    {"waitForAlarm", "(J)I", (void*)android_server_AlarmManagerService_waitForAlarm},

    {"setKernelTime", "(JJ)I", (void*)android_server_AlarmManagerService_setKernelTime},

    {"setKernelTimezone", "(JI)I", (void*)android_server_AlarmManagerService_setKernelTimezone},

};

这里细节不在分析，此处是分析RTC的，具体为什么如此，不清楚请看JNI的细节。

我们这里看到是setKernelTime和setKernelTImeZone等函数，这里是被AlarmManagerService调用的，由于代码量太大，因此分析时也是以setKernelTime为主线，其他一个流程。

进入到android_server_AlarmManagerService_setKernelTime这个函数分析，这里只分析函数进入退出接口，具体数据处理细节不做分析：

ret = impl->setTime(&tv);这里执行的是

int AlarmImplAlarmDriver::setTime(struct timeval *tv)

看到 res = ioctl(fds[0], ANDROID_ALARM_SET_RTC, &ts);这个对于驱动工作者来说，熟悉而狂喜，终于对接上kernel了。话不多说，继续分析。

在init函数里

static jlong android_server_AlarmManagerService_init(JNIEnv*, jobject)

{

    jlong ret = init_alarm_driver();

    if (ret) {

        return ret;

    }

 

    return init_timerfd();

}

有init_alarm_driver，这里就是open /dev/alarm。

static jlong init_alarm_driver()

{

    int fd = open("/dev/alarm", O_RDWR);

    if (fd < 0) {

        ALOGV("opening alarm driver failed: %s", strerror(errno));

        return 0;

    }

    AlarmImpl *ret = new AlarmImplAlarmDriver(fd);

    return reinterpret_cast(ret);

}

这里/dev/alarm的过程分析到此，下面给出另外一种open /dev/rtc的解决方法。时间问题，代码写的些微粗糙，请见谅：

在AlarmImplTimerFd的public里加入

static int setTime_Zone(struct timeval *tv);

实现过程

int AlarmImplTimerFd::setTime_Zone(struct timeval *tv)

{

    struct rtc_time rtc;

    struct tm tm, *gmtime_res;

    int fd;

    int res;

    ALOGW("setTime_Zone");

 res = settimeofday(tv, NULL);

    if (res < 0) {

        ALOGV("settimeofday() failed: %s\n", strerror(errno));

        return -1;

    }

 

    fd = open("/dev/rtc0", O_RDWR);

    if (fd < 0) {

        ALOGV("Unable to open %s\n",strerror(errno));

        return res;

    }

    gmtime_res = gmtime_r(&tv->tv_sec, &tm);

    if (!gmtime_res) {

        ALOGV("gmtime_r() failed: %s\n", strerror(errno));

        res = -1;

        goto done;

    }

 

    memset(&rtc, 0, sizeof(rtc));

    rtc.tm_sec = tm.tm_sec;

    rtc.tm_min = tm.tm_min;

    rtc.tm_hour = tm.tm_hour;

    rtc.tm_mday = tm.tm_mday;

    rtc.tm_mon = tm.tm_mon;

    rtc.tm_year = tm.tm_year;

    rtc.tm_wday = tm.tm_wday;

    rtc.tm_yday = tm.tm_yday;

    rtc.tm_isdst = tm.tm_isdst;

    ALOGW("sec= %d min = %d,hour =%d,mday =%d,mom =%d,year =%d\n",rtc.tm_sec,rtc.tm_min,rtc.tm_hour,rtc.tm_mday,rtc.tm_mon,rtc.tm_year);

    res = ioctl(fd, RTC_SET_TIME, &rtc);

    if (res < 0)

        ALOGV("RTC_SET_TIME ioctl failed: %s\n", strerror(errno));

done:

    close(fd);

    return res;

}

这里copy的setTime的代码，做了些微修改。

然后在android_server_AlarmManagerService_setKernelTime里。

 //ret = impl->setTime(&tv);

ret = AlarmImplTimerFd::setTime(&tv,1);/*zwh add by*/

也可以直接来用，但时间关系这种比较简单，匆匆写了测试代码，后期会完善。

这里我们不得不佩服Google优美的软件设计思想，我们研究代码时不要只是关注功能实现，优美的设计思想也是我们要欣赏的，做一行爱一行，不是吗？

请记住init close 和set setTime setTimeZone这几个接口，即将进入到JAVA世界AlarmManagerService.java。

这里与大多数的server一样，会在开机的时候，会被servicemanager的addservice函数加入，

这里加入过程其实就是一个binder的实例，具体binder机制，内容量太大。这里不啰嗦。

    private native long init();

    private native void close(long nativeData);

    private native void set(long nativeData, int type, long seconds, long nanoseconds);

    private native int waitForAlarm(long nativeData);

    private native int setKernelTime(long nativeData, long millis);

private native int setKernelTimezone(long nativeData, int minuteswest);

看到这里又到了我们那熟悉地方，这里是JAVA调用native的函数入口。沿着这里的调用过程封装接口如下：这里依然只是给出setTIme的实例，其他的一样的执行逻辑。

  public boolean setTime(long millis) {

getContext().enforceCallingOrSelfPermission( "android.permission.SET_TIME","setTime");

   if (mNativeData == 0) {

        Slog.w(TAG, "Not setting time since no alarm driver is available.");

        return false;

    }

    synchronized (mLock) {

    return setKernelTime(mNativeData, millis) == 0;

    }

  }

这里的mNativeData是init的返回值

我们发现当寻找setTime调用入口时发现迷茫了，因为代码里只是找到了alarmmanager的调用，但还是调用的IalarmManager的调用，这里就是就是Android的著名的binder机制，这是一个让人很头疼也让人很佩服的机制，研究后真心佩服有这么优秀的设计思想。

我们可以找到Ialarmmnager.java的代码来自IAlarmManager.aidl。这里是Google为了降低开发者的难度，而做的一个模板，这里其实就是JAVA设计里的代理思想。会有两个重要的类，proxy和stub类，通过stub类获得proxy实例，再通过proxy的transmit函数执行Parcel的数据解析和写入，

_data.writeInterfaceToken(DESCRIPTOR);

_data.writeLong(millis);

mRemote.transact(Stub.TRANSACTION_setTime, _data, _reply, 0);

_reply.readException();

_result = (0!=_reply.readInt());

然后在binder机制下执行到stub里的onTransact

onTransact里的this.setTime就是执行AlarmManagerService的setTime函数，奇妙的世界，这里binder机制不做详细讲解，水平有限，几页纸也讲不清楚。后续会根据时间来补充博客。

boolean _result = this.setTime(_arg0);

这里似乎完整的解释了怎么执行的。然谁调用的alarmmanager的接口呢？

这里继续分析，我们知道在Framework.jar里，都是系统架构的接口，有著名的activity.java等，这里也是alarmmanager.java就在Framework.jar里，因此在DateTimeSetting.java会调用到此，DateTimeSetting.java在如下路径。

packages\apps\Settings\src\com\android\settings\DateTimeSettings.java

这里调用过程如下：

onDateSet 和onTimeSet是我们设置时间的控件函数。

分别执行 setTime(activity, hourOfDay, minute);和setDate(activity, year, month, day);

这里的函数分别执行

  /* package */ static void setDate(Context context, int year, int month, int day) {

        Calendar c = Calendar.getInstance();

        c.set(Calendar.YEAR, year);

        c.set(Calendar.MONTH, month);

        c.set(Calendar.DAY_OF_MONTH, day);

        long when = Math.max(c.getTimeInMillis(), MIN_DATE);

        if (when / 1000 < Integer.MAX_VALUE) {

   ((AlarmManager) context.getSystemService(Context.ALARM_SERVICE)).setTime(when);

        }

    }

wow 又到了开心的时刻，这里找到了alarmmanager的调用入口。

((AlarmManager) context.getSystemService(Context.ALARM_SERVICE)).setTime(when);

注册机制就是刚才提到的在servicemanager 的addservice，SystemServiceRegistry.java的registerService里的注册alarmmanager实例。

这里的serviceManager的add过程不是我们常见的systemserver里的addservice.如下流程：

AlarmManagerService.java的onstart函数：

  publishBinderService(Context.ALARM_SERVICE, mService);

  publishLocalService(LocalService.class, new LocalService());

执行到SystemService.java的函数如下。

ServiceManager.addService(name, service, allowIsolated);

 

frameworks\base\core\java\android\app\SystemServiceRegistry.java

    registerService(Context.ALARM_SERVICE, AlarmManager.class,

                new CachedServiceFetcher() {

            @Override

            public AlarmManager createService(ContextImpl ctx) {

                IBinder b = ServiceManager.getService(Context.ALARM_SERVICE);

                IAlarmManager service = IAlarmManager.Stub.asInterface(b);

                return new AlarmManager(service, ctx);

            }});

这里用到的是servicemanager的服务的add和get的细节，具体可以分析servicemanager的技术细节，真心感到Android的博大精深，这里只是RTC的分析过程，因此很多技术细节没有设计，毕竟这些技术细节一本书也未必写完，这里仅是自己的一个随笔。后期会慢慢分享其他的技术细节。