Mon petit coin de oueb

Nous voici dans l’écriture proprement dite du driver. Comme expliqué auparavant, nous allons nous inspirer du driver du ds1374. La stratégie consiste à 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 ds1374 par mcp7940x dans le fichier rtc-mcp7940x.c nouvellement créé. Ce qui se fait dans vim par la commande :%s/ds1374/mcp7940x/g

Une fois cela fait on va pouvoir commencer à adapter notre driver. 

Notre chip mcp7940x est un composant qui se connecte sur le bus I²C pour «exporter» une interface d’horloge nommé RTC. Le rôle du driver est donc de faire le liens entre le bus i²c et la RTC. On peut résumer cela visuellement avec l’image suivante

On commence toujours la lecture d’un driver par la fin, passons sur le nom de l’auteur et la licence. Et intéressons nous à la connexion au bus.

On charge le driver en le connectant au bus i²c, pour se faire, on utilise la structure i2c_driver que l’on ajoute sur le bus au moment du chargement du driver:

static int __init mcp7940x_init(void)
{
    return i2c_add_driver(&mcp7940x_driver);
}

Structure que l’on supprime au déchargement du driver bien évidemment:

static void __exit mcp7940x_exit(void)
{
    i2c_del_driver(&mcp7940x_driver);
}

Cette structure déclare un certain nombre de fonctions et de structures propres au mcp7940x:

static struct i2c_driver mcp7940x_driver = {
    .driver = {
        .name = "rtc-mcp7940x",
        .owner = THIS_MODULE,
    },
    .probe = mcp7940x_probe,
    .suspend = mcp7940x_suspend,
    .resume = mcp7940x_resume,
    .remove = __devexit_p(mcp7940x_remove),
    .id_table = mcp7940x_id,
};

Ce qui nous intéresse particulièrement pour l’instant c’est le probe et le driver.name. En effet c’est tout simplement le point d’entrée de notre driver. Une fois le driver chargé dans le kernel, Linux observe le bus i²c et guette le nom des périphériques (struct devices) que l’on charge dessus. Dès qu’un périphériques avec le nom « rtc-mcp7940x » se pointe, le kernel appel la fonction de probe mcp7940x_probe.

La structure de description du périphérique présent physiquement sur le bus est quelques chose qui doit être chargé dans le noyau. En règle générale les périphériques du bus i²c ne sont pas plug&play et sont donc présent sur la carte électronique dès le démarrage du kernel.

C’est pour cette raison qu’on a l’habitude de charger les devices dans le fichier dit de «plate-forme». Dans le cas de l’apf51dev, ce fichier de plate-forme se nomme apf51dev-baseboard.c et se trouve dans le répertoire

buildroot/output/build/linux-2.6.38.8/arch/arm/mach-mx5/

Dans ce fichier, le device se déclare simplement avec sont adresse sur le bus, et son nom bien sur:

static struct i2c_board_info apf51dev_i2c2_devices[] __initdata = {
    {
        I2C_BOARD_INFO("mcp79400", 0x6f),
    },
};

Revenons à notre probe

 static int mcp7940x_probe(struct i2c_client *client,
            const struct i2c_device_id *id)
{
    struct mcp7940x *mcp7940x;
    int ret;

    mcp7940x = kzalloc(sizeof(struct mcp7940x), GFP_KERNEL);
    if (!mcp7940x)
        return -ENOMEM;

C’est la fonction d’initialisation de notre driver. C’est dans cette fonction que l’on va démarrer le mcp7940x et allouer la mémoire pour la structure mcp7940x. C’est aussi dans cette fonction que l’on va rattacher notre driver à l’interface RTC.

L’interface Linux pour la RTC est extrêmement simpliste dans notre cas. En effet on cherche juste à lire l’heure et la date dans le composant et à l’écrire (Le mcp7940x à plein d’autre fonctionnalités mais mon besoin n’est que l’heure). Nous n’aurons donc que les fonctions read_time et set_time à écrire dans la structure rtc_class_ops du driver:

static const struct rtc_class_ops mcp7940x_rtc_ops = {
    .read_time = mcp7940x_read_time,
    .set_time = mcp7940x_set_time,
};

Structure que l’on enregistre à la fin de la fonction probe:

    mcp7940x->rtc = rtc_device_register(client->name, &client->dev,
                                      &mcp7940x_rtc_ops, THIS_MODULE);
    if (IS_ERR(mcp7940x->rtc)) {
        ret = PTR_ERR(mcp7940x->rtc);
        dev_err(&client->dev, "unable to register the class device\n");
        goto out_free;
    }

L’écriture de la fonction read_time se résume ensuite à lire les valeurs des registres du composant au moyen de la fonction i2c_smbus_read_byte_data() et de renseigner la structure rtc_time passée en paramètre.

Et pour la fonction set_time on fait l’inverse. On récupère les valeurs se trouvant dans la structure rtc_time passée en paramètre et on écrit les valeurs dans le composant au moyen de la fonction i2c_smbus_write_byte_data().

Et voila !

En réalité le driver n’est que partiellement écrit vu que le composant dispose de bien plus de fonctionnalités que simplement lire/écrire l’heure. Le driver pourrait notament être étendu pour gérer les deux alarmes, la gestion du signal de clock de sortie et surtout la SRAM, qui permet de stocker des variables quand l’appareil est éteint.

Et non ça n’est pas terminé ! Il reste encore à publier ce driver pour armadeus, et plus (mainline kernel) si affinité !

Maintenant publions le tout

Maintenant que nous avons écrit notre driver, l’objectif va être de le publier sur le git Armadeus. Pour cela il faut que nous finalisions le patch que nous avions commencé dans la partie 2 de cet article. Si tout a bien été fait dans la partie 2 il n’y a plus qu’à rafraichir le patch quilt:

$ cd buildroot/output/build/linux-2.6.38.8/
$ quilt refresh
Refreshed patch 450-armadeus-add_mcp7940x_rtc_driver.patch

Puis modifier l'entête du patch pour y mettre son nom (pour qu'on connaisse le coupable :

$ vim patches/450-armadeus-add_mcp7940x_rtc_driver.patch

et

Add mcp79400 Linux driver


Signed-off-by: Fabien Marteau fabien.marteau@armadeus.com



Index: linux-2.6.38.8/drivers/rtc/Kconfig
...

Notre patch est prêt, on peut maintenant le proposer à la communauté Armadeus en le postant sur la liste de diffusion armadeus-forum@lists.sourceforge.net.

Bon j'avoue, vu que j'ai les droits sur le git je l'ai commité directement Mais, pour ceux qui n'ont pas les droits, c'est la procédure qu'il faudrait respecter. Du coup pour voir le code complet du driver c'est par là

Nous voici dans l’écriture proprement dite du driver. Comme expliqué auparavant, nous allons nous inspirer du driver du ds1374. La stratégie consiste à copier/coller le code rtc-ds1374.c puis en modifier...

Dans l’épisode précédent nous avons pu démontrer fonctionnement du MCP79400 sur une AFP51, nous allons maintenant pouvoir l’intégrer au kernel Linux avec un driver adequate.

Plongée dans l’univers du kernel: fouinons !

L’idée consiste à écrire le moins possible de code et à copier au maximum ce qui existe déjà dans le kernel. Pour cela un petit tour dans le code de Linux s’impose. Dans le cas d’Armadeus le code du kernel (patché pour le projet se trouve dans le répertoire buildroot/output/build/linux-2.6.38.8 on peut aussi browser le net à la recherche de driver similaire, mais il est important d’essayer de coller au kernel utilisé.

Le MCP79400 est une RTC, et nous avons de la chance l’api RTC est déjà supporté depuis longtemps dans Linux, donc nous avons une bonne documentation dans le code : Documentation/rtc.txt

Mais comme on ne veut surtout pas se fouler, l’objectif est de trouver un composant très proche du notre et de le recopier à coup de cherher/remplacer.

Résumons:

• Notre composant est une rtc: allons voir dans le répertoire Drivers/rtc/ si nous n’y trouverions pas notre bonheurs.

$ ls linux-2.6.38.8/drivers/rtc
class.c           rtc-ds1511.c    rtc-max8998.c       rtc-rs5c313.c
hctosys.c         rtc-ds1553.c    rtc-mc13xxx.c       rtc-rs5c348.c
rtc-ab8500.c      rtc-ds3232.c    rtc-mpc5121.c       rtc-rx8581.c
rtc-at32ap700x.c  rtc-ds3234.c    rtc-mrst.c          rtc-s35390a.c
rtc-at91rm9200.c  rtc-efi.c       rtc-msm6242.c       rtc-s3c.c
rtc-at91sam9.c    rtc-ep93xx.c    rtc-mv.c            rtc-sa1100.c
rtc-au1xxx.c      rtc-fm3130.c    rtc-mxc.c           rtc-sh.c
rtc-bfin.c        rtc-generic.c   rtc-mxc_v2.c        rtc-starfire.c
rtc-bq32k.c       rtc-imxdi.c     rtc-nuc900.c        rtc-stk17ta8.c
rtc-bq4802.c      rtc-isl12022.c  rtc-omap.c          rtc-stmp3xxx.c
rtc-cmos.c        rtc-isl1208.c   rtc-pcap.c          rtc-sun4v.c
rtc-coh901331.c   rtc-jz4740.c    rtc-pcf2123.c       rtc-sysfs.c
rtc-davinci.c     rtc-lib.c       rtc-pcf50633.c      rtc-test.c
rtc-dev.c         rtc-lpc32xx.c   rtc-pcf8563.c       rtc-twl.c
rtc-dm355evm.c    rtc-m41t80.c    rtc-pcf8583.c       rtc-tx4939.c
rtc-ds1216.c      rtc-m41t94.c    rtc-pl030.c         rtc-v3020.c
rtc-ds1286.c      rtc-m48t35.c    rtc-pl031.c         rtc-vr41xx.c
rtc-ds1302.c      rtc-m48t59.c    rtc-proc.c          rtc-wm831x.c
rtc-ds1305.c      rtc-m48t86.c    rtc-ps3.c           rtc-wm8350.c
rtc-ds1307.c      rtc-max6900.c   rtc-pxa.c           rtc-x1205.c
rtc-ds1374.c      rtc-max6902.c   rtc-r9701.c
rtc-ds1390.c      rtc-max8925.c   rtc-rp5c01.c

• Le nombre de composant supporté est relativement élevé, voyons voir ceux qui sont piloté par bus i²c comme le notre :

$ grep -Rn "i2c.h" *
rtc-bq32k.c:12:#include  <linux/i2c.h>
rtc-ds1307.c:16:#include <linux/i2c.h>
rtc-ds1374.c:23:#include <linux/i2c.h>
rtc-ds1672.c:12:#include <linux/i2c.h>
rtc-ds3232.c:21:#include <linux/i2c.h>
rtc-fm3130.c:13:#include <linux/i2c.h>
rtc-isl12022.c:14:#include <linux/i2c.h>
rtc-isl1208.c:14:#include <linux/i2c.h>
rtc-m41t80.c:17:#include <linux/i2c.h>
rtc-max6900.c:15:#include <linux/i2c.h>
rtc-max8925.c:13:#include <linux/i2c.h>
rtc-max8998.c:16:#include <linux/i2c.h>
rtc-pcf8563.c:17:#include <linux/i2c.h>
rtc-pcf8583.c:16:#include <linux/i2c.h>
rtc-rs5c372.c:13:#include <linux/i2c.h>
rtc-rx8025.c:26:#include <linux/i2c.h>
rtc-rx8581.c:16:#include <linux/i2c.h>
rtc-s35390a.c:14:#include <linux/i2c.h>
rtc-x1205.c:20:#include <linux/i2c.h>

• Cela réduit déjà le nombre cela reste élevé. Le composant de chez Dallas DS1374 semble néanmoins assez intéressant car il est court et surtout il est déjà utilisé dans certain projet Armadeus donc bien connu.

Notre nouveau driver devrait donc pouvoir s’insérer dans ce répertoire sans problème, appelons le rtc-mcp7940x.c histoire de coller aux autres. Pour l’ajouter, trois fichiers doivent-être modifiés:

• drivers/rtc/KConfig: Pour ajouter le driver dans le menuconfig de linux

[...]
      watchdog timer in the ST M41T60 and M41T80 RTC chips series.

config RTC_DRV_MCP7940X
    tristate "Microchip MCP7940X"
    depends on RTC_CLASS && I2C
    help
      If you say yes here you get support for Microchip
      MCP7940x real-time clock chips.
      The alarm functionality is not supported.

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

config RTC_DRV_BQ32K
[...]    

• drivers/rtc/Makefile:

[...]
obj-$(CONFIG_RTC_DRV_MC13XXX)   += rtc-mc13xxx.o
obj-$(CONFIG_RTC_DRV_MCP7940X)  += rtc-mcp7940x.o
obj-$(CONFIG_RTC_DRV_MSM6242)   += rtc-msm6242.o
[...]

• drivers/rtc/rtc-mcp7940x.c: le source du driver proprement dit

Un bon développeur kernel porte le quilt chez Armadeus.

On vient juste de voir quels fichiers il était nécessaire de modifier pour ajouter notre driver, néanmoins notre objectif final est quand même de partager ce driver et, dans un premier temps, de le proposer à la communautée d’Armadeus Project. Pour cela nous allons avoir besoin de réaliser un patch.

Le kernel utilisé pour le projet armadeus est déjà noyé de patches, si bien qu’il est difficile de gérer son pauvre petit patches parmis les autres. Il est donc conseillé d’utiliser le programme Quilt pour gérer des piles de patche.

quilt est relativement bien intégré au projet; pour s’en servir il est nécessaire de quiltifier Linux avec la commande suivante à la racine du projet :

$ ./scripts/quiltify
--- What do you want to quiltify today ?  
1) Linux
2) Buildroot
3) U-Boot
> 1

Le script va empiler tous les patches nécessaire au projet armadeus puis recompiler Linux. Une fois fait nous n’avons plus qu’à nous rendre dans l’arborescence du code:

$ cd buildroot/output/build/linux-2.6.38.8
buildroot/output/build/linux-2.6.38.8$ quilt applied
[...]
442-freescale-0034-ENGR00126692-3-1-add_drivers_mxc_directory.patch
442-freescale-0034-ENGR00126692-3-add_hw-events_and_srtc_drivers.patch
442-freescale-0034-ENGR00126692-3-add_hw-vpu_driver.patch
442-freescale-0034-ENGR00126692-3-add_iim_driver.patch
442-freescale-0034-ENGR00126692-3-add_mx23_mx25_mx28_security_stuff.patch
442-freescale-0197-ENGR00131650-add_scc2_and_sahara_drivers_without_rng.patch
442-freescale-0535-ENGR00136875-1-Add-function-pgprot_writethru.patch
442-freescale-0536-ENGR00136875-2-make-video-buffer-cacheable-to-improv.patch
444-armadeus-sunrpc-silent_annoying_svc_message_when_mounting_NFS_drives.patch
445-armadeus-add_freescale_mxc_dvfs_driver.patch
446-armadeus-add_freescale_ipu3_driver.patch
447-armadeus-add_freescale_ipu_based_framebuffer_driver.patch
448-armadeus-pps51-adding_HX8369_display_driver.patch
449-armadeus-add_pps51_baseboard.patch
[...]

La commande quilt applied affiche tous les patches appliqués au noyau. Pour ajouter notre driver nous allons donc créer un nouveau patche:

$ quilt new 450-armadeus-add_mcp7940x_rtc_driver.patch

Et ajouter les fichiers que nous allons modifier avant de les modifier.

$ quilt add drivers/rtc/Makefile
$ quilt add drivers/rtc/Kconfig
$ quilt add drivers/rtc-mcp7940x.c

Nous sommes maintenant prêt à écrire le code proprement dit, comme nous allons le voir dans le prochain épisode

[À suivre ...]

Dans l’épisode précédent nous avons pu démontrer fonctionnement du MCP79400 sur une AFP51, nous allons maintenant pouvoir l’intégrer au kernel Linux avec un driver adequate. Plongée dans l’univers du kernel:...