3

I am writing a simple UART device driver. I have been referring omap-serial.c as the device driver is for omap-4460 processor.

Can i write it using a simple > open,close,write,read and ioctl functions?

It is because I did not see these functions in the omap-serial.c, Instead in the init function,it was platform_driver_register function which inturn is pointing to probe,remove functions

Evgenii Gostiukhin
  • 970
  • 4
  • 8
ddpd
  • 603
  • 1
  • 10
  • 25
  • It looks like the OMAP UART driver has implemented I/O and other handling via the standard UART class driver. – Peter L. Apr 01 '14 at 18:00
  • What do you mean by standard UART class driver?Can you please refer to any link? – ddpd Apr 02 '14 at 03:46
  • 1
    Since there are many similarities between types of drivers, much of the features and functionality will be implemented together in shared code. This UART device will use uart_register_driver (http://lxr.free-electrons.com/source/drivers/tty/serial/omap-serial.c?a=arm#L1936) and platform_register_driver() to hook into this common functionality as a UART/TTY device. The device-specific code is defined in members of common structures, such as dispatch functions and device parameters. – Peter L. Apr 02 '14 at 15:46
  • @PeterL. since UART driver is a char driver I am willing to use alloc_chrdev_reg() and cdev_add function in initialisation.These functions could be related to uart_register_driver function.But I cannot relate the function platform_register_driver().Also I see that platform_register_driver() is in turn related to driver_register function in chapter 14 of LDD. But there araised one more doubt related to device_register function.Is it necessary to use in my code? The reason for not going with uart_register_driver() is because it uses tty functions which I am not familiar with. Please help – ddpd Apr 02 '14 at 17:27
  • Is your device intended to function as a TTY? If so, consider using the existing framework. It is possible to not use platform_register_driver(), but best to use it as this is the new way of integrating driver code with the kernel (new being since several years ago). Most new drivers, unless they are *completely* unique, fit within an existing model. There are many advantages in going with this. – Peter L. Apr 02 '14 at 17:31
  • @PeterL.thanks for your advice.As I said I am not familiar with TTY function. I do not have an idea of how my device is going to function using TTY. My intention is to develop UART driver in a very simple and basic manner. – ddpd Apr 03 '14 at 01:41
  • 1
    Ok, I think I understand your intentions now. You might want to start with your own skeleton driver and just implement open/close/read/write. You can add it to the kernel by including it in a Makefile. I'd recommend drivers/char/Makefile and put your skeleton driver in that dir. Once you can verify that the dispatch calls are being made as you expect, you can add the code to control the UART hardware. – Peter L. Apr 03 '14 at 04:34
  • @PeterL. Can you please answer this question [link](http://stackoverflow.com/questions/22809480/sdifference-between-device-register-and-driver-register). – ddpd Apr 03 '14 at 05:38
  • Gautham seems to answer the question well. You will need to have a device major/minor number to identify the device from user space. Search the kernel source to see how other drivers have used driver_register(). This one looks similar to what you are trying to do: http://lxr.free-electrons.com/source/drivers/hwmon/ibmaem.c – Peter L. Apr 03 '14 at 15:22
  • @PeterL.Can you please answer this [question](http://stackoverflow.com/questions/23078968/call-to-request-mem-region-fails) – ddpd Apr 15 '14 at 10:25
  • Krzysztof added some good comments. It is not a good idea to reuse IO memory that has been designated for another driver. The ioremap() call is implemented here: http://lxr.free-electrons.com/source/arch/arm/mm/ioremap.c?v=2.6.34#L257 That's for ARM on Linux 2.6.34. – Peter L. Apr 15 '14 at 17:39

0 Answers0