$ cp linux-2.6.38.8\/drivers\/rtc\/rtc-ds1374.c\r\nlinux-2.6.38.8\/drivers\/rtc\/rtc-mcp7940x.c <\/code><\/pre>\nPuis chercher\/remplacer tous les ds1374<\/em> par mcp7940x<\/em> dans
\nle fichier rtc-mcp7940x.c nouvellement cr\u00e9\u00e9. Ce qui se fait dans vim par la
\ncommande :%s\/ds1374\/mcp7940x\/g<\/samp><\/p>\nUne fois cela fait on va pouvoir commencer \u00e0 adapter notre driver.\u202f<\/p>\n
Notre chip mcp7940x est un composant qui se connecte sur le bus I\u00b2C pour
\n\u00abexporter\u00bb une interface d’horloge nomm\u00e9 RTC. Le r\u00f4le du driver est donc de
\nfaire le liens entre le bus i\u00b2c et la RTC. On peut r\u00e9sumer cela visuellement
\navec l’image suivante<\/p>\n
![\"Dessin](\"http:\/\/www.martoni.fr\/documents\/images_articles\/dessin_driver.jpg\")
<\/p>\n
On commence toujours la lecture d’un driver par la fin, passons sur le nom
\nde l’auteur et la licence. Et int\u00e9ressons nous \u00e0 la connexion au bus.<\/p>\n
On charge le driver en le connectant au bus i\u00b2c, pour se faire, on utilise
\nla structure i2c_driver<\/samp> que l’on ajoute sur le bus au moment du
\nchargement du driver:<\/p>\n\r\nstatic int __init mcp7940x_init(void)\r\n{\r\n\treturn i2c_add_driver(&mcp7940x_driver);\r\n}\r\n<\/code><\/pre>\nStructure que l’on supprime au d\u00e9chargement du driver bien \u00e9videmment:<\/p>\n
\r\nstatic void __exit mcp7940x_exit(void)\r\n{\r\n\ti2c_del_driver(&mcp7940x_driver);\r\n}\r\n<\/code><\/pre>\nCette structure d\u00e9clare un certain nombre de fonctions et de structures
\npropres au mcp7940x:<\/p>\n
\r\nstatic struct i2c_driver mcp7940x_driver = {\r\n\t.driver = {\r\n\t\t.name = \"rtc-mcp7940x\",\r\n\t\t.owner = THIS_MODULE,\r\n\t},\r\n\t.probe = mcp7940x_probe,\r\n\t.suspend = mcp7940x_suspend,\r\n\t.resume = mcp7940x_resume,\r\n\t.remove = __devexit_p(mcp7940x_remove),\r\n\t.id_table = mcp7940x_id,\r\n};\r\n<\/code><\/pre>\nCe qui nous int\u00e9resse particuli\u00e8rement pour l’instant c’est le
\nprobe<\/samp> et le driver.name<\/samp>. En effet c’est tout
\nsimplement le point d’entr\u00e9e de notre driver. Une fois le driver charg\u00e9 dans
\nle kernel, Linux observe le bus i\u00b2c et guette le nom des p\u00e9riph\u00e9riques (struct
\ndevices) que l’on charge dessus. D\u00e8s qu’un p\u00e9riph\u00e9riques avec le nom
\n\u00ab\u00a0rtc-mcp7940x\u00a0\u00bb se pointe, le kernel appel la fonction de probe
\nmcp7940x_probe<\/samp>.<\/p>\nLa structure de description du p\u00e9riph\u00e9rique pr\u00e9sent physiquement sur le bus
\nest quelques chose qui doit \u00eatre charg\u00e9 dans le noyau. En r\u00e8gle g\u00e9n\u00e9rale les
\np\u00e9riph\u00e9riques du bus i\u00b2c ne sont pas plug&play et sont donc pr\u00e9sent sur la
\ncarte \u00e9lectronique d\u00e8s le d\u00e9marrage du kernel.<\/p>\n
C’est pour cette raison qu’on a l’habitude de charger les devices dans le
\nfichier dit de \u00abplate-forme\u00bb. Dans le cas de l’apf51dev, ce fichier de
\nplate-forme se nomme apf51dev-baseboard.c<\/samp> et se trouve dans le
\nr\u00e9pertoire <\/p>\nbuildroot\/output\/build\/linux-2.6.38.8\/arch\/arm\/mach-mx5\/<\/code><\/pre>\nDans ce fichier, le device se d\u00e9clare simplement avec sont adresse sur le
\nbus, et son nom bien sur:<\/p>\n
\r\nstatic struct i2c_board_info apf51dev_i2c2_devices[] __initdata = {\r\n\t{\r\n\t\tI2C_BOARD_INFO(\"mcp79400\", 0x6f),\r\n\t},\r\n};\r\n<\/code><\/pre>\nRevenons \u00e0 notre probe <\/p>\n
static int mcp7940x_probe(struct i2c_client *client,\r\n\t\t\tconst struct i2c_device_id *id)\r\n{\r\n\tstruct mcp7940x *mcp7940x;\r\n\tint ret;\r\n\r\n\tmcp7940x = kzalloc(sizeof(struct mcp7940x), GFP_KERNEL);\r\n\tif (!mcp7940x)\r\n\t\treturn -ENOMEM;\r\n\r\n<\/code><\/pre>\nC’est la fonction d’initialisation de notre driver. C’est dans cette
\nfonction que l’on va d\u00e9marrer le mcp7940x et allouer la m\u00e9moire pour la
\nstructure mcp7940x. C’est aussi dans cette fonction que l’on va rattacher
\nnotre driver \u00e0 l’interface RTC.<\/p>\n
L’interface Linux pour la RTC est extr\u00eamement simpliste dans notre cas. En
\neffet on cherche juste \u00e0 lire l’heure et la date dans le composant et \u00e0
\nl’\u00e9crire (Le mcp7940x \u00e0 plein d’autre fonctionnalit\u00e9s mais mon besoin n’est
\nque l’heure). Nous n’aurons donc que les fonctions read_time<\/samp> et
\nset_time<\/samp> \u00e0 \u00e9crire dans la structure rtc_class_ops<\/a>
\ndu driver:<\/p>\n\r\nstatic const struct rtc_class_ops mcp7940x_rtc_ops = {\r\n\t.read_time = mcp7940x_read_time,\r\n\t.set_time = mcp7940x_set_time,\r\n};\r\n<\/code><\/pre>\nStructure que l’on enregistre \u00e0 la fin de la fonction probe:<\/p>\n
\r\n\tmcp7940x->rtc = rtc_device_register(client->name, &client->dev,\r\n\t &mcp7940x_rtc_ops, THIS_MODULE);\r\n\tif (IS_ERR(mcp7940x->rtc)) {\r\n\t\tret = PTR_ERR(mcp7940x->rtc);\r\n\t\tdev_err(&client->dev, \"unable to register the class device\\n\");\r\n\t\tgoto out_free;\r\n\t}\r\n<\/code><\/pre>\nL’\u00e9criture de la fonction read_time<\/samp> se r\u00e9sume ensuite \u00e0 lire
\nles valeurs des registres du composant au moyen de la fonction
\ni2c_smbus_read_byte_data()<\/samp> et de renseigner la structure
\nrtc_time<\/a> pass\u00e9e en param\u00e8tre.<\/p>\nEt pour la fonction set_time<\/samp> on fait l’inverse. On r\u00e9cup\u00e8re
\nles valeurs se trouvant dans la structure rtc_time<\/a>
\npass\u00e9e en param\u00e8tre et on \u00e9crit les valeurs dans le composant au moyen de la
\nfonction i2c_smbus_write_byte_data()<\/samp>.<\/p>\nEt voila !<\/h3>\n
En r\u00e9alit\u00e9 le driver n’est que partiellement \u00e9crit vu que le composant
\ndispose de bien plus de fonctionnalit\u00e9s que simplement lire\/\u00e9crire l’heure.
\nLe driver pourrait notament \u00eatre \u00e9tendu pour g\u00e9rer les deux alarmes, la
\ngestion du signal de clock de sortie et surtout la SRAM, qui permet de stocker
\ndes variables quand l’appareil est \u00e9teint.<\/p>\n
Et non \u00e7a n’est pas termin\u00e9 ! Il reste encore \u00e0 publier ce driver pour
\narmadeus, et plus (mainline kernel) si affinit\u00e9 !<\/p>\n
Maintenant publions le tout<\/h3>\n
Maintenant que nous avons \u00e9crit notre driver, l’objectif va \u00eatre de le publier sur le git Armadeus. Pour cela il faut que nous finalisions le patch que nous avions commenc\u00e9 dans la partie 2 de cet article. Si tout a bien \u00e9t\u00e9 fait dans la partie 2 il n’y a plus qu’\u00e0 rafraichir le patch quilt:<\/p>\n
$ cd buildroot\/output\/build\/linux-2.6.38.8\/\r\n$ quilt refresh\r\nRefreshed patch 450-armadeus-add_mcp7940x_rtc_driver.patch\r\n<\/pre>\n<\/code><\/p>\n
Puis modifier l'ent\u00eate du patch pour y mettre son nom (pour qu'on connaisse le coupable ;):<\/p>\n
\r\n$ vim patches\/450-armadeus-add_mcp7940x_rtc_driver.patch\r\n<\/pre>\n<\/code><\/p>\n
et <\/p>\n
\r\nAdd mcp79400 Linux driver\r\n\r\nSigned-off-by: Fabien Marteau \r\n\r\n---\r\n\r\nIndex: linux-2.6.38.8\/drivers\/rtc\/Kconfig\r\n...\r\n<\/pre>\n<\/code><\/p>\n
Notre patch est pr\u00eat, on peut maintenant le proposer \u00e0 la communaut\u00e9 Armadeus en le postant sur la liste de diffusion
\narmadeus-forum@lists.sourceforge.net<\/a>.<\/p>\nBon j'avoue, vu que j'ai les droits sur le git je l'ai commit\u00e9 directement \ud83d\ude09 Mais, pour ceux qui n'ont pas les droits, c'est la proc\u00e9dure qu'il faudrait respecter. Du coup pour voir le code complet du driver c'est par l\u00e0<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"Nous voici dans l’\u00e9criture proprement dite du driver. Comme expliqu\u00e9 auparavant, nous allons nous inspirer du driver du ds1374. La strat\u00e9gie consiste \u00e0 copier\/coller le code rtc-ds1374.c puis en modifier le code: $ cp linux-2.6.38.8\/drivers\/rtc\/rtc-ds1374.c linux-2.6.38.8\/drivers\/rtc\/rtc-mcp7940x.c Puis chercher\/remplacer tous les … Continuer la lecture