I am new to device driver writing and I need to write a SPI driver to access flash memory for a embedded linux running on ARM.
What I don't understand is, do I need to register the driver with a major and minor number? Or do platform device drivers also need a major and minor number?
If yes, When and How to assign it?
I guess, I'll be using platform_driver_register() for registering the driver.
You don't have to register major or minor numbers. Your question is actually not precise enough. Do you want to write a driver for a specific SPI flash or a driver for an SPI host?
If this is an SPI flash, what you want is to register your driver using a struct spi_driver with module_spi_driver() then in the probe, register your device in the MTD susbsystem using mtd_device_parse_register. The MTD susbsystem will register the major and minors for you.
If you need to write a driver for the host, then you will register your driver using a struct platform_driver and module_platform_driver(). In your probee you will register your hosts using spi_register_master
You should probably read a bit about the Linux device model for further explanations.
Related
I want to read the CAN bus and get the data from a specific device on the CAN bus. I have implemented this previously using the Socket communication api that is available in the user space (sys/socket).
I now have a similar requirement but this time working on device drivers which work in the kernel space. The same socket communication is i suppose not available in the kernel space which is why i guess i am not able to compile the kernel module with #include .
An approach i have come up to is to create a device driver for device creation and a supporting user-space program to interact it and provide CAN data by using socket communication. If there is any better approach please suggest me.
A device driver is a component that Windows uses to interact with a hardware device, such as a modem or network adapter. Rather than access the device directly, Windows loads device drivers and calls functions in the drivers to carry out actions on the device but how windows know which functions are available and how to call them?
As far as the first part of your question, on a modern system that supports ACPI (also see OSDev Wiki's page) Windows (or any other OS worth its salt) uses that to detect devices via the tables that are loaded by the BIOS (e.g. the DSDT).
ALSA or libusb api are two choices; both are new to me; its been years since I wrote a device driver and it was for Unix back in the 80's, but I do know I can figure out how, once I know what tools to use, which I'm guessing both use C still; I have looked at the libusb api; very nice; but I have no idea about ALSA project; seems they are geared into getting modules into the kernel to achieve this.
This is a generic question, but the Device I'm interested in is the Roland GR-55; it has MIDI and Audio from the same USB connection; it has Windows and MAC Drivers but no Linux.
Which libraries or tools do you prefer to use?
Do I write a Device Driver or Loadable Kernel Modules (LKM)?
libusb is useful and easy to get up and running. I would suggest that you start there, especially if you haven't written Linux drivers in a while. Use libusb to understand what the signalling protocol is for the Roland GR-55 and do some experiments.
USB supports several types of logical connections over the same physical wire. There will likely be DATA and CONTROL pipes available from the device and you will need to map that out before starting on a proper driver.
As I said, libusb is easy to get going and you could have something useful in a few days if you just want to write a control interface and store raw data from the device. However, ALSA is the way to go if you want to use the device with existing music software. Also, by updating ALSA you would be supporting the larger community because you could merge your work in to the ALSA project.
Writing a kernel module from scratch could be fun, but USB is a bit of a beast and would probably not be an ideal one to start with. With ALSA you will have a framework to guide you and won't need to worry so much about defining your own APIs.
As commented above, check out Linux Device Drivers http://lwn.net/Kernel/LDD3/ chapter 13 talks specifically about USB drivers. For development it's easier to write your driver as a kernel module because then you don't need to recompile the kernel when you make a change.
No need for writing a new driver - ALSA already has support for that since a while. See commit https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0ef283247a0cf0fd2e8370ee467030292eb3129e
Since you probably want to hear sound on your sound card, you should opt for ALSA. That way after you are done you are done. If you write libusb driver, then you would have to write your own user space tools for feeding that sound card sound for playing.
I have two devices that are interfaced with PCI. I also have code for both devices that uses generic socket code. (The devices were originally connected by MII/Ethernet.)
Now, I need to write a PCI device driver to transport packets back and forth between the two devices.
How do I access the file descriptors opened by the socket code? Is this the same as accessing a character device file?
The PCI driver has to somehow capture packets from read() and write() in the code.
Thanks!
The answers to your questions are: (1) You don't, and (2) no.
File descriptors are a user-space concept, and kernel drivers don't interact with user-space concepts. (Yes, they're implemented by the kernel, but other device drivers don't get to play with them directly, and shouldn't play with them even indirectly.)
What you do is implement methods that will receive data that is buffered in a kernel-accessible memory space, and send that to your hardware, and then receive data from your hardware and write it (when asked) to a buffer in kernel-accessible memory.
You'll do this by implementing the character device driver APIs as well as the PCI device driver APIs and then registering your driver as a PCI device, and then a character device. While some of these methods may refer to file structures, they will not be the user-land structures that you know and love.
For devices that implement the Ethernet protocols, life is easier because you implement the Net Device Interface instead. This way all you have to write is the parts necessary to get data to and from your hardware.
What you'll need is specifications for the device hardware, how you control the hardware using PCI registers and regions.
The good news is, you don't have to do this alone -- there's a large community of kernel developers, and several good (and current) books on developing for the Linux kernel (see below).
References
Understanding the Linux Kernel
Linux Device Drivers
Essential Linux Device Drivers
I am currently dealing with two devices connected to the I2C bus within an embedded system running Linux. I am using an exisiting driver for the first device, a camera. For the second device, I have successfully implemented a userspace program with which I can communicate with the second device. So far, both devices seem to coexist happily. However, almost all I2C devices have their own driver module. Thus, I am wondering what the advantages of a driver module are. I had a look at the following thread...
When should I write a Linux kernel module?
... but without conclusion.
Thus, what would be the advantage of writing a I2C driver module over a userspace implementation?
Regards,
Stefan
In your situation, you probably don't have much use for a I2C driver module. If it ain't broke....
The main reason I would include a kernel module driver is when another kernel mode driver is a I2C client, or benefits from tight integration with the kernel. One example of this is the WM8350 audio codec, which is communicates audio data over an audio bus (I2S or AC97) and configuration (e.g. volume level) over I2C.
A power management IC is another example of a chip that you would want the kernel to directly control.
Finally, I will note that there are multiple kinds of I2C drivers. (See Documentation/i2c/summary.) In some cases your hardware might require an I2C bus adapter driver, to teach how to communicate over I2C. That would require a kernel mode driver.