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.
Related
If we have a particular ARM-based SOC which has a physical I2C controller included on it, and the intention is to run Embedded Linux on this SOC.
Now we have a separate off-board I2C slave chip connected to this I2C bus from the SOC. For argument's sake, let's say that it's an RTC chip.
The kernel driver for this external RTC chip would more than likely be developed by the RTC chip vendor. Would this vendor need to know about the exact register addresses on the SOC chip in order to write to and read from, or is there other architecture specific code for the chip that the kernel driver can link to?
The memory map of the peripherals are defined by the chipset. However, modern operating systems like linux and Windows can boot from pretty much every chip (if compiled for the right architecture). As far as I know, the memory mapped devices like the USB Host are not included in the architecture standard. How can the OS still boot, load the drivers, and function? I suppose there must be some specification where the chipset is described.
Formulated a little different: How does the identification of the chipset work, what standards define the communication between the chipset and the processor so that it works on different hardwares and how does the kernel know the right physical addresses for the different peripherals?
Open systems typically use a device tree, which is a specification of the attached hardware, and how it is attached. There is another system, ACPI which supports legacy PCs. Either system permits an OS to locate and configure the buses and associated peripherals it needs.
It is never 100% as easy as that. For example, it is fine for the OS to know there is a scsi controller on bus 1 at address 1000; but if the code for the scsi driver isn't in the loaded os image, then this knowledge is of little use, as it has no way to load the driver.
The intel specification for ACPI attempts to fix this by having tiny driver implementations baked into the firmware of either the platform, the device itself, or both. Since the device doesn't necessarily know what sort of cpu it will run on, these mini drivers are written in a virtual instruction set which the host OS requires an interpreter for.
UEFI provides an alternate way have addressing the boot dependency via a more generic mechanism to use mini-boot drivers for the same purpose.
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.
I am porting an I2C driver to Linux-4. This device provides multiple I2C addresses for different function simultaneously.
For example:
address 0xAA is for access of SPI flash.
address 0xA0 is for access of EEPROM.
address 0x60 is for normal access (control purpose).
Is it possible to support access of different I2C address in single-one I2C device driver?
Any help appreciated,
Thanks
I think it is possible. Using i2c_transfer() you are giving particular address in i2c_msg structure of the device you want to communicate with. So your driver will be able to communicate with all of the functions of your i2c device.
Depends on what type of I2C driver you are talking about, bus(adapter) or chip(client) driver?
i2c-dev.c is a kind of bus driver with character device interface which exports kernel low level I2C API to userspace.
For each registered I2C adapter Kernel will add i2c-N device node in /devuserspace interface.
But you can't read/write EEPROM chip attached to /dev/i2c-N like simple character device or file. You need to write some utility program regarding chip protocol.
But in Linux there is are special EEPROM chip drivers like eeprom.c or at24.c for registering I2C EEPROM devices with addresses of 0x50..0x57(if I'm not wrong) to Kernel and creating files in /sys userspace interface.
You can access them as a file in:/sys/bus/i2c/devices/0-005x/eeprom
Thanks for Dražen Grašovec and user2699113 's help.
I am porting a I2C device driver (chip, client) to Linux-4.9.
This chip accepts different I2C device address for different purpose.
My goal is to create only one I2C device on Linux device tree file (.dts)
I resolved my issue by using i2c_new_dummy().
In driver probe function,
I made two i2c_new_dummy() to create two additional i2c clients.
One(client#1) is for accessing of I2C address 0xAA, another(client#2) is for I2C address 0xA0.
So I can use client#1 to communicate with its SPI flash and use client#2 to access it EEPROM.
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