Linux input system and keypad driver on i.mx6

Refer to below, register gpio keypad to a  gpio-keys
https://community.nxp.com/thread/343346

Declare keys in device tree

 
keys{
        compatible = "gpio-keys";
        #address-cells = <1>;
        #size-cells = <0>;
        autorepeat;
        keypad-01{
            label = "keypad-01";
            gpios = <&gpio4 30 1>;
            linux,code = <2>; /* KEY_RESERVED  */
        };
        keypad-02{
            label = "keypad-02";
            gpios = <&gpio4 31 1>;
            linux,code = <3>; /* KEY_RESERVED  */
        };
};   

Note: 若設置autorepeat那按下key不放時, input event會一直發. 若沒設定時就只會發一次, 但是Yocto OS在沒收到release event之前會自動做autorepeat的動作.

宣告為"gpio-keys" 或是 "gpio-keys-polled" keypad都可以正常動作. 差異在"gpio-keys-polled"需多定義"poll-interval". 還有在register input device的時候一個是register成input device, 另一個是register成input polled device. 資料結構不同. 以及一個是使用interupt方式, 另一個則是polling mode.


根據以下兩張圖, linux input system 主要分為三個部分, input core, input device driver, input event driver. Input device driver負責control各interface的hardware device. Input event driver負責處理傳入的事件以及向上傳到application. Input core負責串起device driver以及event driver.

Event driver (Ex: evdev.c) init時, 會註冊一個input handler到input system list.

 
static int __init evdev_init(void)
{
	return input_register_handler(&evdev_handler);
}

Device probe時, 會註冊一個device到input system list.

 
error = input_register_polled_device(poll_dev);
if (error) {
	dev_err(dev, "unable to register polled device, err=%d\n",
		error);
	goto err_free_gpio;
}

當device以及handler做register時, input core都會使用input_attach_handler 來搜尋相對應的device以及handler. 若是有找到相對應的device以及handler, 則建出一個input handle供以後使用.
當有找到相對應的device以及handler時, 會調用handler的connect function, 以evdev來說, 就會在connect function當中建出/dev/input/eventX
便可以將event與device driver串在一起.

 
input.c
int input_register_handler(struct input_handler *handler)
{
	struct input_dev *dev;
	int error;

	error = mutex_lock_interruptible(&input_mutex);
	if (error)
		return error;

	INIT_LIST_HEAD(&handler->h_list);

	list_add_tail(&handler->node, &input_handler_list);

	list_for_each_entry(dev, &input_dev_list, node)
		input_attach_handler(dev, handler);

	input_wakeup_procfs_readers();

	mutex_unlock(&input_mutex);
	return 0;
}

int input_register_device(struct input_dev *dev)
{
…
	list_add_tail(&dev->node, &input_dev_list);

	list_for_each_entry(handler, &input_handler_list, node)
		input_attach_handler(dev, handler);

	input_wakeup_procfs_readers();

	mutex_unlock(&input_mutex);
…
}

static int input_attach_handler(struct input_dev *dev, struct input_handler *handler)
{
	const struct input_device_id *id;
	int error;

	id = input_match_device(handler, dev);
	if (!id)
		return -ENODEV;

	error = handler->connect(handler, dev, id); //匹配成功就调用handler的connect函数 
	if (error && error != -ENODEV)
		pr_err("failed to attach handler %s to device %s, error: %d\n",
		       handler->name, kobject_name(&dev->dev.kobj), error);

	return error;
}

evdev.c
static int evdev_connect(struct input_handler *handler, struct input_dev *dev,
			 const struct input_device_id *id)
{
…
	dev_set_name(&evdev->dev, "event%d", dev_no);

	evdev->handle.dev = input_get_device(dev);
	evdev->handle.name = dev_name(&evdev->dev);
	evdev->handle.handler = handler;
	evdev->handle.private = evdev;
	
	evdev->dev.devt = MKDEV(INPUT_MAJOR, minor);
	evdev->dev.class = &input_class;
	evdev->dev.parent = &dev->dev;
	evdev->dev.release = evdev_free;
	device_initialize(&evdev->dev);

	error = input_register_handle(&evdev->handle);
	if (error)
		goto err_free_evdev;

	cdev_init(&evdev->cdev, &evdev_fops);
…
}

到這邊串起之後, 便可以將input device產生的訊息(touch screen座標, key-code…etc)傳給input handler. 或是將input handler的訊息交給input device(如鼠标的闪灯命令).

實際在使用時, 如果按下一個key, 不管是interupt或是polling mode, 都是在收到動作之後, 透過input_event來向input handler傳遞type, code, value這三項內容. 然後便可以從cat /dev/input/eventX 或是調用evdev的read function來得到輸入的資料.

open /dev/input/eventX 之後便可使用evdev_fops的read/write/ioctl function, Yocto在進入os時有open device, 並且read device. 但是還沒找到Yocto在哪邊做open及read.

到這邊就可以完成按下gpio keypad發出一個linux standard keycode.


Reference:
https://blog.csdn.net/yueqian_scut/article/details/47903853
https://blog.csdn.net/yueqian_scut/article/details/48026955
https://blog.csdn.net/qq_695538007/article/details/9153099
https://blog.csdn.net/qq_695538007/article/details/9153135
http://www.jollen.org/blog/2009/04/linux_input_device_apis.html
https://patchwork.kernel.org/patch/2848259/
https://community.nxp.com/thread/343346

i.mx6 LVDS clock structure

Dump all clock source data command
#cat /sys/kernel/debug/clk/clk_summary

LDB clock use path LDB_DI1_IPU -->ldb_di1_ipu_div -->ldb_di1_clk_sel

從ldb_di1_clk_sel過來的clock固定只能 /3.5(lvds split mode) or /7(lvds non-split mode)

在ldb_di1_clk_sel則可以選擇5個不同clock source

其中PLL2 PFD0/PLL2 PFD2/pll3_sw_clk往前都沒有其他的clock select或是divider.

mmdc_ch1 clock如下圖則還有clock select以及divider

黃色標出的部分都可以再尋找register做clock source以及divider的設定

pll5 clock set

pll5 clock可分為兩個部分.

1. 從24MHz OSC出來計算PLL5的clock, 參考公式如下圖

Fref = 24Mhz

DIV_SELECT = CCM_ANALOG_PLL_VIDEOn offset 0-6, range 27-54

NUM = CCM_ANALOG_PLL_AUDIO_NUM offset 0-29

DENOM = CCM_ANALOG_PLL_AUDIO_DENOM offset 0-29

NUM must less than DENOM.

Example

24MHz * (29 + 8666666 /10000000 ) = 716.79984MHz

716MHz = pll5 = pll5_bypass = pll5_video

2. 由第一步計算出的PLL5 clock, 再經由2個2bit divider, 可以 /1 /2 /4 /8 /16來產生出最終的pll5_main_clk

總結:

由ldb_di1_clk_sel當中選擇出的clock, 再根據split mode來決定/3.5 or /7就可算出最終ldb輸出的clock frequency.

mtd device for spi nor flash

spi flash不是直接access到spi flash, 而是透過mtd再往下

                   MTD
         ------------------------
              SPI NOR framework
         ------------------------
                  m25p80
         ------------------------
      SPI bus driver
         ------------------------
      SPI NOR chip

在i.mx cpu下的架構會略有不同

                   MTD
         ------------------------
              SPI NOR framework
         ------------------------
                fsl-quadSPI
         ------------------------
      SPI NOR chip

但是從log來看fsl-quadSPI還是有用到m25p80這隻driver

m25p80目前看來可以通用在所有的spi nor flash, 要新增只要把id相關瑱入table中就好

目前spi nor flash不透過spidev這個device來access, 所以不需要掛spidev在spi device下.

spidev目前看來是直接access spi device的, 如果有需要透過spidev直接control device才需加入device tree

http://blog.5ibc.net/p/14266.html

git branch have diverged

============ 當 Conflict when git pull =====================

如果 git pull 時發現有 Conflict, 但你又明明沒有加入任何 commit,
有可能是因為原來的 branch 已經走到分支出去了,
你可以打入 git status

# On branch master

# Your branch and 'origin/master' have diverged,

# and have 32 and 83 different commit(s) each, respectively.

#




第一個數字 32 代表著你比 origin/master 多了 32 個 patch, 第二個數字 83 代表著你比 origin/master 少了 83 個 patch 如果你很有興趣知道是那一些可以利用 git cherry origin/master 來看

1. 執行 git reset --hard HEAD^ 一直到你可以做 fast-forwarded

2. 直接執行 git pull --rebase origin/master

http://pjack1981.blogspot.tw/2012/03/git.html

https://github.com/zlargon/git-tutorial/blob/master/remote/sync.md

Android propery

Android property 與BIOS的variable感覺相當類似, 都是可以作為一些變數往後傳遞.
但是property更簡單的是因為他是用檔案形式, 所以要驗證的時候開檔案來看就好.

property service是在init.c當中啟動.
1）间接调用__system_property_area_init()：打开属性共享内存，并记入__system_property_area变量；
2）间接调用init_workspace()：只读打开属性共享内存，并记入环境变量；
3）根据init.rc，异步激发property_service_init_action()，该函数中会：
    l  加载若干属性文本文件，将具体属性、属性值记入属性共享内存；
    l  创建并监听socket；
4）根据init.rc，异步激发queue_property_triggers_action()，将刚刚加载的属性对应的激发动作，推入action列表。

接著則是在init.rc中會看到一段
on load_all_props_action
    load_all_props
這邊其實才會真正的load file system中的properties
從keywords.h中可以看到
    KEYWORD(load_all_props,        COMMAND, 0, do_load_all_props)

所以去看在do_load_all_props在property_service.c中

    load_properties_from_file(PROP_PATH_SYSTEM_BUILD, NULL);

    load_properties_from_file(PROP_PATH_SYSTEM_DEFAULT, NULL);

    load_properties_from_file(PROP_PATH_VENDOR_BUILD, NULL);

    load_properties_from_file(PROP_PATH_FACTORY, "ro.*");

這邊就會實際的去抓file system中的property files.

有個需注意的部份是在這邊的property_set中會將ro.開頭的property set都擋掉

if(!strncmp(name, "ro.", 3)) return -1;

所以若是在跑到load_all_props之前都還可以set ro.開頭的property, 但是在load_all_props之後ro.xxx就真的變成read only的property了.

參考資料:

http://www.jcodecraeer.com/a/anzhuokaifa/androidkaifa/2015/0322/2632.html

http://www.iloveandroid.net/2015/09/26/Android_property_1/

Android wifi related

Android 5.1.1

1. Android 網路連線機制並不允許同時有兩個device連外, Ethernet > wifi > mobile network. 會有一個評分機制在連線時決定哪個interface可以連線, 其他的連線則會被斷掉. 但是如果在user space使用command方式連線, 是可以看到一個以上的interface 拿到ip, 但是推測從android端連線出去時, 仍只會從priority高的device連出去.

frameworks/base/services/Java/com/android/server/ConnectivityService.java 將以下選項打開
  private static final boolean DBG = true;
  private static final boolean VDBG = true;
  private static final boolean LOGD_RULES = true;
在log中就可以看到相關評分以及切換網路的動作, 可再往下追code.

參考以下網站將相關的code mark掉的話, 先連上wifi 再接上ethernet, 那wifi並不會強制斷線.但是若先接ethernet再接wifi, 那wifi也還是無法連上, 因為這邊只能將已連上的連線不斷線, 並不能搶走舊的連線.
https://stackoverflow.com/questions/37715525/use-multiple-network-interfaces-in-an-app
https://github.com/CyanogenMod/android_frameworks_base/blob/e49d5ea0858a765c22d8aa96cc660d4708a413fb/services/core/java/com/android/server/ConnectivityService.java#L4264
評分機制ethernet固定是150, wifi則根據RSSI來決定分數, 最高不超過100. 若兩者同分, 則以先連線的interface為主.


通過ConnectivityService之後, 如果是wifi連線, 接著會到WifiStatemachine

wifi state machine就會在各個state中切換, 來完成連線的各個動作, 這部份尚待研究.
接著往下會到JNI部份 frameworks/base/core/jni/android_net_wifi_Wifi.cpp
再往下就到wifi hardware部份 hardware/libhardware_legacy/wifi/wifi.c
在wifi.c時會根據傳入的參數來知道是要sta mode, ap mode or p2p mode. 根據知道是什麼mode之後會去reload相對應的fw.
以下是別人寫的ap mode啟動流程.
Setting->WifiManger->WifiService->WifiController->NetworkManagementService(wifiFirmwareReload)->NativeDaemonConnector(execute)->CommandListener->SoftapController(fwReloadSoftap)->wifi_get_fw_path

接著則會根據是什麼mode來決定要使用什麼tool以及讀取或create相關的conf檔案.
如果是sta mode的話, 就使用wpa_supplicant, ap mode則使用hostapd.


參考資料:
http://blog.csdn.net/kangear/article/details/14446527
http://blog.csdn.net/u010961631/article/details/48629601
http://blog.csdn.net/tankai19880619/article/details/42146287
http://blog.csdn.net/myarrow/article/details/8129607
http://blog.csdn.net/xusiwei1236/article/details/48495485
http://blog.sina.com.cn/s/blog_67e1c5cc0101ttqd.html

Uboot passes arguments to kernel

u-boot 要傳參數到kernel可使用 setenv bootargs
cmd line sample
# setenv bootargs androidboot.selinux=disable
# saveenv

code sample
setenv("bootargs", "androidboot.selinux=disable");

但是在android時, 會在image-android.c中的android_image_get_kernel讀取boot.img中的bootargs
boot.img的bootargs放在 BOARD_KERNEL_CMDLINE
BOARD_KERNEL_CMDLINE := console=ttymxc4,115200 init=/init

需注意的是如果code當中有設bootargs的話, 那在android_image_get_kernel就不會使用BOARD_KERNEL_CMDLINE設定的bootargs

 
int len = 0;
if (*hdr->cmdline) {
 len += strlen(hdr->cmdline);
}

char *bootargs = getenv("bootargs");
if (bootargs)
 len += strlen(bootargs);

char *newbootargs = malloc(len + 2);
if (!newbootargs) {
 puts("Error: malloc in android_image_get_kernel failed!\n");
 return -ENOMEM;
}
*newbootargs = '\0';

if (bootargs) {
 strcpy(newbootargs, bootargs);
} else if (*hdr->cmdline) {
 strcat(newbootargs, hdr->cmdline);
}

接著bootargs會傳到proc/cmdline, 可使用cat來確認傳入的parameter.
若要再交給android做為properties使用, 那可以在bootargs增加androidboot.xxx=xxx
在system/core/init/init.c當中會去處理bootargs.

static void process_kernel_cmdline(void)
{
    /* don't expose the raw commandline to nonpriv processes */

    chmod("/proc/cmdline", 0440);

    /* first pass does the common stuff, and finds if we are in qemu.
     * second pass is only necessary for qemu to export all kernel params
     * as props.
     */

    import_kernel_cmdline(0, import_kernel_nv); //read kernel parameter here

    if (qemu[0])
        import_kernel_cmdline(1, import_kernel_nv);

    /* now propogate the info given on command line to internal variables
     * used by init as well as the current required properties
     */
    export_kernel_boot_props();
}

void import_kernel_cmdline(int in_qemu,
                           void (*import_kernel_nv)(char *name, int in_qemu))
{
    char cmdline[2048];
    char *ptr;
    int fd;

    fd = open("/proc/cmdline", O_RDONLY);

    if (fd >= 0) {
        int n = read(fd, cmdline, sizeof(cmdline) - 1);
        if (n < 0) n = 0;
        /* get rid of trailing newline, it happens */
        if (n > 0 && cmdline[n-1] == '\n') n--;
        cmdline[n] = 0;

        close(fd);

    } else {
        cmdline[0] = 0;
    }

    ptr = cmdline;
    while (ptr && *ptr) {
        char *x = strchr(ptr, ' ');
        if (x != 0) *x++ = 0;
        import_kernel_nv(ptr, in_qemu);

        ptr = x;
    }
}

在import_kernel_nv當中會將androidboot.xxx都換成ro.boot.xxx

static void import_kernel_nv(char *name, int for_emulator)
{
    char *value = strchr(name, '=');
    int name_len = strlen(name);

    if (value == 0) return;
    *value++ = 0;

    if (name_len == 0) return;

    if (for_emulator) {
        /* in the emulator, export any kernel option with the
         * ro.kernel. prefix */
        char buff[PROP_NAME_MAX];
        int len = snprintf( buff, sizeof(buff), "ro.kernel.%s", name );

        if (len < (int)sizeof(buff))
            property_set( buff, value );

        return;
    }

    if (!strcmp(name,"qemu")) {
        strlcpy(qemu, value, sizeof(qemu));
    } else if (!strncmp(name, "androidboot.", 12) && name_len > 12) {
        const char *boot_prop_name = name + 12;
        char prop[PROP_NAME_MAX];
        int cnt;

        cnt = snprintf(prop, sizeof(prop), "ro.boot.%s", boot_prop_name); //change to ro.boot.xxx here

        if (cnt < PROP_NAME_MAX)
            property_set(prop, value);

    }
}

所以如果一開始有設置androidboot.selinux=disable的話, 在經過這邊之後會被換成ro.boot.selinux=disable, boot進android之後使用getprop就可以看到了.

另外一些特定的properties則會經過export_kernel_boot_props再parsing一次.

    struct {
        const char *src_prop;
        const char *dest_prop;
        const char *def_val;
    } prop_map[] = {
        { "ro.boot.serialno", "ro.serialno", "", },
        { "ro.boot.mode", "ro.bootmode", "unknown", },
        { "ro.boot.baseband", "ro.baseband", "unknown", },
        { "ro.boot.bootloader", "ro.bootloader", "unknown", },
    };