I have developed a working driver for my custom_hardware that relies on the device tree. Because my driver may evolve, I do not want my driver to be part of the kernel (when I say 'be part of the kernel', I mean, to be compiled with the kernel during the kernel creation)
Here is a glimpse of my dts:
custom_hardware: custom_hardware#0x41006000 {
compatible = "mfg,custom";
reg = <0x41006000 0x1000>;
#interrupt-cells = <0x1>;
interrupt-controller;
};
existing_hardware: existing_hardward#41004000 {
compatible = "mfg,existing";
reg = <0x41004000 0x1000>;
interrupt-parent = <&custom_hardware>;
interrupts = <0>;
};
The existing_hardware's driver is already compiled with kernel (the existing_hardware's driver has been compiled with the kernel during the kernel creation).
What I would like to do is to append my custom_hardware's driver to the ramfs and let the kernel loads the custom_hardware's driver prior of the existing_hardware's driver.
This is important since the existing_hardware's driver requests a virq from the irq_domain of the custom_hardware's driver. In order to get the irq_domain, the custom_hardware's driver must be loaded first.
Note that the existing_hardware's driver gets loaded during the probing of the device tree which seems to happen in the early stage of the kernel booting sequence.
That is not the way to do. The order of the module/driver loading must not matter. What you need to do is return -EPROBE_DEFER when getting the IRQ fails in existing_hardware. Then it will get probed again at a later time, hopefully after custom_hardware got probed.
Also, you can apply that patch that will ensure that request_irq() fails because the domain is not present yet and return -EPROBE_DEFER in that case
https://lkml.org/lkml/2014/2/13/114
I had similar problem (probing order was wrong) and the only simple solution what I found is put the modules in the desired probing order into the Makefile.
I've found the solution here: What is the Linux built-in driver load order?
Related
I have a arm64 linux custom board with a spi-to-can chip, and the chip sometime is mcp2515, sometime is mcp2518fd.But they use different driver (mcp251x.ko/mcp25xxfd.ko).
This is my dts:
&spi4 {
status = "okay";
canfd#0 {
compatible = "microchip,mcp2515", "microchip,mcp2518fd";
reg = <0x0>;
clocks = <&clk20m>;
#interrupts = <&gpio3 RK_PB6 IRQ_TYPE_LEVEL_LOW>;
interrupt-parent = <&gpio3>;
interrupts = <RK_PB6 IRQ_TYPE_LEVEL_LOW>;
spi-max-frequency = <4000000>;
};
};
The question is if the chip is mcp2518fd, kernel only match the first compatible "microchip,mcp2515 and then the driver(mcp251x.ko) probe failed.
Can i modify dts or driver src to meet this demand? If driver probe failed and kernel match next compatible ?
Or the only solution is to merge two driver into one?
The compatible strings are supposed to be in hierarchical order from most specific to most general, e.g. specifying an ID for a specific chip, followed by an ID for a "family" of related chips with a common programming interface (that will usually have less features than the chip-specific programming interfaces). That does not apply in this case, because microchip,mcp2515 and microchip,mcp2518fd refer to different specific chips with no hierarchical relationship.
The device tree node needs to specify which type of SPI-to-CAN controller is fitted. That means you need to load a different .dtb file for each type of board, or have a base .dtb file and load a different "device tree overlay" (.dtbo) file on top of the base .dtb file. Different .dtb files could be chosen by the bootloader based on some stored setting in the bootloader. Different .dtbo files could be loaded by the bootloader or by the Linux operating system based on some stored setting in the bootloader or in the Linux operating system, respectively.
It is possible to load different device tree overlays at runtime in the Linux operating system using the "DT-Overlay configfs interface" (CONFIG_OF_CONFIGFS), but that requires patched kernel sources. The patches can be found at topic/overlays.
I have two device tree nodes, one sets a gpio pin and the other one configures one i2c bus, ex:
&gpio2 {
en-gpio {
gpio-hog;
gpios = <5 0>;
output-high;
};
};
&i2c1 {
gpiom1: gpio#27 {
compatible = "microchip,mcp23008";
gpio-controller;
#gpio-cells = <2>;
reg = <0x27>;
};
};
How can i add a dependency between the i2c node and gpio one?
What i want to achieve is that the gpio pin should be set before the devices on i2c are initialized.
Short answer
You can't provide dependency between nodes in this case. But most likely the correct order is already taken care of in your case, and GPIO pin will be set before I2C device initialization, thanks to earlier initcall used for GPIO controller driver, and because gpio-hog is used. If you want to check it for your platform to be sure -- below are details.
Nodes relationship
As stated in Device trees II: The harder parts LWN article:
Naturally, in each case the device which provides the interrupt or GPIO will need to be initialized before it can be found and used. It wasn't very many kernel versions ago that this was a real problem. However in the 3.4 kernel, drivers gained the ability for their initialization (or probe) routine to return the error EPROBE_DEFER which would cause the initialization to be tried again later. So if a driver finds that a GPIO line is listed in the devicetree, but no driver has registered GPIOs for the target node yet, it can fail with EPROBE_DEFER and know it can try again later. This can even be used to remove the need for callbacks and delayed registration in board files, but it is really essential for devicetree, and happily it works quite well.
Alas, in your case it's probably not possible to specify dependency between nodes, so that your i2c1 or gpiom1 depends on gpio2. At least I don't see any gpios properties for I2C controllers or GPIO controllers in Documentation/devicetree/bindings/, that can be used for referencing your en-gpio. So it seems like you should rely on drivers loading order.
Driver dependencies
There are two possible dependencies between drivers:
If drivers are built-in (inside of kernel image): drivers can be initialized at different initcalls, thus being loaded in correct order
If drivers are loadable (.ko files): drivers can have dependencies, defined in kernel build system
As you didn't mention your platform, let's see how it works using BeagleBone Black board for example. You can use this as a template to find out how it's done on your platform.
Static dependencies
Let's check drivers init order:
From am33xx-l4.dtsi file we can see that:
GPIO controller: compatible = "ti,omap4-gpio"
I2C controller: compatible = "ti,omap4-i2c"
I2C device: compatible = "microchip,mcp23008"
Corresponding drivers for those compatible strings are:
GPIO controller: drivers/gpio/gpio-omap.c
I2C controller: drivers/i2c/busses/i2c-omap.c
I2C device: drivers/pinctrl/pinctrl-mcp23s08.c
Those drivers are initialized on next initcalls:
GPIO controller: postcore_initcall (=2)
I2C controller: subsys_initcall (=4)
I2C device: subsys_initcall (=4)
So GPIO controller driver will be initialized before I2C drivers.
Dynamic dependencies
What about dynamic dependencies? From corresponding Makefile and Kconfig files we can see config options and dependencies:
GPIO controller: CONFIG_GPIO_OMAP, tristate, doesn't depend on I2C stuff
I2C controller: CONFIG_I2C_OMA, tristate, doesn't depend on GPIO stuff
I2C device: CONFIG_PINCTRL_MCP23S08, tristate, depends on I2C
So if drivers are loaded in user-space as .ko files, it all depends on the order of their loading, user must take care of it in rootfs. Usually GPIO and I2C controller drivers are built-in, so no need to discuss this further, but just FYI, here is how the order is defined for modprobe tool.
Kernel Configuration
To check how drivers are built (built-in or loadable), one can check .config file. E.g. if multi_v7_defconfig is used:
CONFIG_GPIO_OMAP=y
CONFIG_I2C_OMAP=y
In that case both drivers are built-in, and we know that GPIO driver has earlier initcall than I2C one.
GPIO hogging
You did the right thing by declaring your pin as gpio-hog. You probably already know what it means, but I'll reference the explanation here for everyone else who is interested. From Documentation/devicetree/bindings/gpio/gpio.txt:
The GPIO chip may contain GPIO hog definitions. GPIO hogging is a mechanism
providing automatic GPIO request and configuration as part of the
gpio-controller's driver probe function.
So this is as early as you can get. And if your GPIO controller driver is built-in and has initcall number smaller than one for I2C drivers, you can argue that your en-gpio pin will be set before I2C device driver init.
I am trying to port drivers from old kernel to new one on ARM based platform. While porting one of the drivers I have noticed that request_irq fails on new kernel. Actually, what this driver have is a number of hard coded irq numbers, and it tries to request_irq for this HW lines. I started to search what is the reason of request_irq failure, - the reason is that the appropriate IRQ descriptor (irq_desc) have IRQ_NOREQUEST flag set.
I started to search where this flag is cleared, and found that it happens here:
of_platform_populate
|
...
|
of_device_alloc
|
...
|
irq_of_parse_and_map
(some levels below this flag is dropped)
So that code is invoked from mach init code and parse DTB, all interrupt numbers that are mentioned in DTB would be mapped to irq virtual space and will be accessible through appropriate devices structures, for example:
irq = platform_get_irq(pdev, 0);
As I already said, this old - fashion drivers just have hard-coded irq numbers in include files, and they don't have no appropriate dtb entries.
The question is what is the right way, from the kernel perspective of view, to port this? Do I need to make this old driver a platform device (now it is just a char device) and create appropriate dtb description for it? Or I can just use some kernel API to mark this interrupts as available? Is it a common/normal style?
I am studying UART Driver in kernel code and want to know, who first comes into picture, device_register() or driver_register() call?
For difference between them follow this.
and in UART probing, we call
uart_register_driver(struct uart_driver *drv)
and after successfully registration,
uart_add_one_port(struct uart_driver *drv, struct uart_port *uport)
Please explain this in details.
That's actually two questions, but I'll try to address both of them.
who first comes into picture, device_register() or driver_register() call?
As it stated in Documentation/driver-model/binding.txt, it doesn't matter in which particular order you call device_register() and driver_register().
device_register() adds device to device list and iterates over driver list to find the match
driver_register() adds driver to driver list and iterates over device list to find the match
Once match is found, matched device and driver are binded and corresponding probe function is called in driver code.
If you are still curious which one is called first (because it doesn't matter) -- usually it's device_register(), because devices are usually being registered on initcalls from core_initcall to arch_initcall, and drivers are usually being registered on device_initcall, which executed later.
See also:
[1] From where platform device gets it name
[2] Who calls the probe() of driver
[3] module_init() vs. core_initcall() vs. early_initcall()
Difference between uart_register_driver and platform_driver_register?
As you noticed there are 2 drivers (platform driver and UART driver) for one device. But don't let this confuse you: those are just two driver APIs used in one (in fact) driver. The explanation is simple: UART driver API just lacks some functionality we need, and this functionality is implemented in platform driver API. Here is responsibility of each API in regular tty driver:
platform driver API is used for 3 things:
Matching device (described in device tree file) with driver; this way probe function will be executed for us by platform driver framework
Obtaining device information (reading from device tree)
Handling Power Management (PM) operations (suspend/resume)
UART driver API: handling actual UART functionality: read, write, etc.
Let's use drivers/tty/serial/omap-serial.c for driver reference and arch/arm/boot/dts/omap5.dtsi for device reference. Let's say, for example, we have next device described in device tree:
uart1: serial#4806a000 {
compatible = "ti,omap4-uart";
reg = <0x4806a000 0x100>;
interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>;
ti,hwmods = "uart1";
clock-frequency = <48000000>;
};
It will be matched with platform driver in omap-serial.c by "ti,omap4-uart" string (you can find it in driver code). Then, using that platform driver, we can read properties from device tree node above, and use them for some platform stuff (setting up clocks, handling UART interrupt, etc.).
But in order to expose our device as standard TTY device we need to use UART framework (all those uart_* functions). Hence 2 different APIs: platform driver and UART driver.
I am trying to learn User mode driver to receive interrupts of my Network Card.
I insmod two kernel components ${KSRC}/drivers/uio/uio.ko and ${KSRC}/drivers/uio/uio_pci_generic.ko.
But I donot see any device getting created which I can then mmap
Typically for UIO I would need something like "/dev/uio0" which I can open then mmap()
So how to go about using UIO framework?
Edit:
My network card is Marvell ethernet controller. My hardware is x86 Ubuntu. Linux kernel 3.13.11.11. So no device tree based.
First of all, the driver has to be compiled into the kernel. Either use menu config or add the following lines to a .cfg file. You can check that the driver has been compiled by looking in /lib/modules/<kernel-name>/modules.builtin.
CONFIG_UIO=y
CONFIG_UIO_PDRV_GENIRQ=y
The next step is to add the following entry to your device tree You can check that the driver has been compiled by looking in /lib/modules/<kernel-name>/modules.builtin.file. Where the middle number is the interrupt you are targeting -32. This means 0x1D == 29 and then add 32 for the interrupt number that is registered in the GIC (Generic Interrupt Controller on ARM systems).
spw0#7aa00000 {
compatible = "generic-uio";
reg = <0x7aa00000 0x10000>;
interrupts = <0x0 0x1D 0x4>;
interrupt-parent = <0x3>;
clocks = <0x1>;
};
and changing the bootargs to console=ttyPS0,115200 root=/dev/mmcblk0p1 rw rootwait earlyprintk uio_pdrv_genirq.of_id=generic-uio.
If everything goes well, you will see the /dev/uio0 device after booting up.