свой драйвер АЦП, два пути Опции

[TigerSHARC]

Надобно написать драйвер(модуль ядра) АЦП.

Прочитав Linux Device Drevers вижу очевидный путь: пишу модуль ядра, который представляет собой standalone программу, принимающую данные от АЦП поп рерыванию от АЦП(сигнал когда данные готовы), и оформленную как собственно модуль/драйвер для Linux (благо доступ к регистрам есть из пространства ядра)

Но! Вижу что устройства "по-хорошему" регистрируются в sysfs, а вот этот путь не совсем понятен.

Вопрос: чем чреват первый путь и и как писать для второго(статейки может какие есть с примерами...)?

Сообщение отредактировал TigerSHARC - Jun 13 2013, 11:30

[Hoodwin]

С sysfs пробовал немного, все же это не совсем файловая система, это скорее некая обертка для kernel objects. А с procfs все достаточно просто.
Сначала нужно в своем модуле в методе init зарегистрировать драйвер устройства. Проще всего это сделать для platform_bus, так как для этой шины правило соответствия довольно простое - одинаковые имена у драйвера и устройства. Итого:

Код

static int __init my_driver_init(void)
{
    int rc;

    my_proc_dir = proc_mkdir("my_dir", 0);
    if (!my_proc_dir)
        bail_out...

    rc = platform_driver_register(&my_driver);
    if (rc!=0)
        bail_out...

    // тут же можно зарегистрировать и само устройство, если нет более подходящего места.
    // вообще говоря, LDM подразумевает, что устройство регистрируется на шине неким сканером шины
    // для реализации механизма plug and play, но это необязательно.

    return 0;
}

В данном коде все довольно просто, системе зарегистрировали базовый каталог в proc и драйвер для устройства. Драйвер устройства теперь будет проверяться всякий раз, когда в системе происходят изменения на шине platform_bus. Если драйвер найдет устройство, то будет вызван метод probe драйвера, где он сможет устройство взять под свой контроль. Там же происходит инициализация рабочих структур управления устройством: выделение памяти, ремаппинг адресного пространства ввода-вывода, назначение irq, а также регистрация в procfs файлов для управления устройством из пользовательского приложения. Вот примерно так:

Код

static int my_driver_probe(struct platform_device *pdev)
{
        struct resource  *r_mem, *r_irq;
        my_device_t       *ctx;
        int               rc;

        pdev_info(pdev, "starting device...\n");

        r_mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
        r_irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
        if (!r_mem || !r_irq)
                return -EINVAL;

        ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
        if (!ctx)
                return -ENOMEM;

        platform_set_drvdata(pdev, ctx);
        ctx->pdev = pdev;

        /* check the resources */
        ctx->irq = r_irq->start;
        ctx->mem_base = r_mem->start;
        ctx->mem_size = r_mem->end - r_mem->start + 1;

        /* registering module base directory */
        snprintf(ctx->name_base, sizeof(ctx->name_base), "%u", pdev->id);
        ctx->proc_base = proc_mkdir(ctx->name_base, my_proc_dir);
        if (!ctx->proc_base) {
                rc = -ENOMEM;
                goto fail_proc_base;
        }

        /* registering interface to work with ADC */
        ctx->proc_adc = create_proc_entry("adc_data", 0644, ctx->proc_base);
        if (!ctx->proc_adc) {
                rc = -ENOMEM;
                goto fail_proc_adc;
        } else {
                /* fill in the table of registers operations */
                extern struct file_operations  mors8_registers_fops;

                ctx->proc_regs->data = ctx;
                ctx->proc_regs->size = 256;  // размер файла АЦП, если имеет смысл
                ctx->proc_regs->proc_fops = &my_adc_fops;
                atomic_set(&ctx->open_adc, 0);
        }

        // аналогично создаем прочие файловые интерфейсы к драйверу
        ...

        /* now register irq handler */
        rc = request_irq(ctx->irq, my_interrupt_handler, IRQF_SHARED, "my_adc", ctx);
        if (rc) {
                pdev_err(pdev, "unable to set up irq %d, error %d\n", ctx->irq, rc );
                goto fail_irq;
        } else {
                /* setup interrupt enable for the device */
        }

        return 0;

fail_irq:
fail_proc_adc:
        remove_proc_entry(ctx->name_base, my_proc_base);
fail_proc_base:
        return rc;
}


static int my_driver_remove(struct platform_device *pdev)
{
        my_device_t *ctx;

        ctx = platform_get_drvdata(pdev);

        pdev_info(pdev, "stopping device...\n");

        /* removing interrupt handler */
        free_irq(ctx->irq, ctx);                    /* free handler */

        /* removing file adc_data */
        if (ctx->proc_adc)
                remove_proc_entry("adc_data", ctx->proc_base);

        return 0;
}

Дальше нужно описать файловый интерфейс управления АЦП. Приведу лишь только процедуру чтения и структуру дескриптора:

Код

static int fops_adc_read(struct file *f, char __user *buf, size_t n, loff_t *pos)
{
        my_device_t *ctx = (my_device_t *) f->private_data;
        loff_t      offs = (*pos) & ~3;
        size_t      total = 0;

        if (offs >= ctx->proc_adc->size)
                return 0;

        if (offs + n >= ctx->proc_adc->size )
                n = ctx->proc_adc->size - offs;

        n &= ~3;

        while(n > 0) {
                u32 data;
                int rc;

                rc = my_read_adc (ctx, &data);
                if (rc)
                        break;

                // copy data to user
                copy_to_user(buf, &data, 4);

                // take next word
                buf   += 4;
                offs  += 4;
                total += 4;
                n -= 4;
        }

        *pos = offs;

        return total;
}


struct file_operations my_adc_fops = {
        .owner =        THIS_MODULE,
        .open =         fops_adc_open,
        .release =      fops_adc_close,
        .read =         fops_adc_read,
        .write =        fops_adc_write,
        .ioctl =        fops_adc_ioctl,
        .llseek =       fops_adc_seek,
};

Собственно и все. После insmod такого драйвера в системе появится "файл" в пути /proc/my_dir/0/adc_data, который можно открыть и читать любыми средствами, доступными в линукс. Например, можно сделать dd if=/proc/my_dir/0/adc_data of=/mnt/nfs/test bs=512 count=1, и тогда можно скинуть в файлик на NFS результаты АЦП, и потом их глазками быстро посмотреть, скажем в mc или через QUI.

Сообщение отредактировал Hoodwin - Jun 14 2013, 06:58

[Муравей]

Собственно и все. После insmod такого драйвера в системе появится "файл" в пути /proc/my_dir/0/adc_data, который можно открыть и читать любыми средствами, доступными в линукс. Например, можно сделать dd if=/proc/my_dir/0/adc_data of=/mnt/nfs/test bs=512 count=1, и тогда можно скинуть в файлик на NFS результаты АЦП, и потом их глазками быстро посмотреть, скажем в mc или через QUI.

Тоже задумался над написанием драйвера , который будет принимать поток с 8 каналов АЦП по msasp в режиме tdm на пладе Beaglebone. Вроде бы понятно как создать устройство в /proc, создать файловый интерфейс для записи чтения.
Предполагаю, что из буфера DMA буду пихать данные в большой промежуточный циклический буфер, а при вызове read() брать сколько есть, но не более чем указанное количество значений из буфера.
Остался один не понятный момент, как внутри драйвера организовать функцию, в которой постоянно будет проверяться сколько в буфере DMA есть данных . Как в драйвере можно организовать функцию, в которую гарантированно буду попадать не реже ~10 ms? Какие есть стандартные средства для этого?

И ещё вопрос. Возможен ли такой вариант: в драйвере заряжаю DMA на определённую область памяти и уже из USER_SPACE получаю доступ к ней. А информацию по поводу по какому адресу делать mmap зачитаваю из файла устройства в /proc. Так же из файлов читаю текущее положение кольцевых указателей.

Заранее спасибо за ответы.

Сообщение отредактировал Муравей - Jul 12 2013, 11:27