I've got a PCIe board with a FPGA and my own kernel device driver.
After the FPGA has been loaded, I need to rescan the PCIe tree.
I used the regular /sys/bus/pci/devices/xxx/remove + /sys/bus/pci/rescan to do that.
The access to these files must be done with root privileges and it could be a pain.
Is it possible to do the rescan from my kernel device driver ?
I tried to call pci_remove_bus () + pci_rescan_bus () in the open call but I've got a kernel panic.
Where can I find an example of pci_remove_bus () + pci_rescan_bus () use ?
Thanks,
Fred
Related
How does Linux Kernel or BIOS map the PCIe endpoint device memory into systems MMIO space ? Is there any API to achieve it ?
Lets assume that when writing a Linux device driver for a PCIe endpoint device, How can we map PCIe device memory into MMIO space ? Or Is it true that the device is already mapped into MMIO by BIOS during enumeration and what I would need to do it just remap the device MMIO into the kernel virtual address space using ioremap() ?
Platform : Linux on x86
There are two parts to this answer
Role of the BIOS
The BIOS (typically UEFI based) will do some sort of Depth-First Search (DFS) and enumerate all the children as PCIe is a self-enumerating bus. Since it has the view of the world (device, buses, processors) it will write an address to the BAR registers (could be BAR0 and or multiple of them). This will be the address the system will use and it will actually route these requests from the Host Agent (HA on x86/Intel platforms) to the Root Port to a PCIe switch all the way to the end point.
Each of these elements track what address ranges belong to themselves or one of their child devices (example a Switch may be the child of a Root Port)
Role of the Device Driver
The OS/Kernel will provide a toolkit of helper routines that the driver authors will use to access the device registers. Typically a driver may follow the folling routines
This is some sample driver pseudo-code, just to help illustrate the idea
1. pci_resource_flags(pdev, 0) & IORESOURCE_MEM
Check if a resource region is valid, here check for BAR 0
2. pci_request_regions(pdev, "region")
Take ownership of the resource/region
3. drv->registers = pci_iomap(pdev, 0, SIZE_YOU_WANT_TO_MAP)
This will give you kernel virtual address to device register mapping
Note : In case the BIOS does not enumerate, through Linux one can rescan the PCIe tree to see if a device can be seen or not.
I'd like to access to PCIe IO from userland.
In the module driver, I'm able to write/read using the pointer returned by ioremap () without any problem.
From userland, I want to use the pointer returned by mmap () but the host hangs whatever I write or read on the PCIe bus.
I implemented the mmap call in the file operation structure which calls io_remap_pfn_range(vma, vma->vm_start, start >> PAGE_SHIFT, vma->vm_end - vma->vm_start, vma->vm_page_prot); where start is the value returned by pci_resource_start ().
What did I miss ?
Note that my module works fine on x86.
Thanks,
Fred
The POWER architecture does not support PCIe IO accesses; you'll need to use PCIe memory cycles instead. It's likely that your PCIe device has a corresponding resource for MMIO space, perhaps you can use that.
Also, depending on your usage, you may want to perform accesses on the resource<N> files in sysfs, under /sys/bus/pci/devices/<id>. This might mean that you don't need any kernel code at all.
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 have an Intel systems. I am trying to load at24.ko and i2c-mux-pca9541.ko.
both modules have probe functions which are not being called.
according to the Documentation, i need to call i2c_registetr_board_info in the arch_init.
but I am not sure where to do that for the Intel system (ie which files).
I do not see any examples anywhere on the internet.
can someone provide a pointer to the file that i add this call.
if this is not the right approach, please let me know.
thank you in advance.
The probe is not called because a "matching" device is not found by the kernel that could be associated with the driver. There are different ways to provide the device information to the kernel. They are discussed as follows :
If this is for testing purpose, you can probe the i2c devices through sysfs :
echo <device_name> <i2c_address> > /sys/bus/i2c/devices/i2c-0/new_device
device_name : name of the i2c device. Should be the one used in the driver.
i2c_address : Address of the i2c device as per the device datasheet
The above command assumes that the i2c bus '0' is the one where the device is attached.
Apart from this, there are some other ways to probe your device. You might specify the device info through a device tree or by calling i2c_register_board_info(). You could create a simple module that creates the i2c_board_info structure and registers it using i2c_register_board_info(), and then insert the module such that the device would be "known" to the kernel and binds the device with its driver. It need not be in the board init codes.
I recommend you to go through the following documentation on probing i2c devices : http://lxr.free-electrons.com/source/Documentation/i2c/instantiating-devices
I have developed a SPI platform driver for a single SPI device.Which SPI device we are using,that configuration can be given in Device Tree.probe() function of SPI platform driver is called when name matching happens with name give in driver and the same present in DT.
In SPI platform driver module_init() method, we register SPI device structure (struct spi_driver spidev_spi_driver) with function call: spi_register_driver().
Please refer to the (static struct spi_driver spidev_spi_driver) in below link for example.
Link: http://lxr.free-electrons.com/source/drivers/spi/spidev.c#L664
Here Probe() is one important method registered in this call.
When probe function is called, kernel passes pointer of SPI device (e.g struct spi_device *spi) in probe() function which is further utilized in read and write operation with SPI device.
All the above procedure happens only once for a single SPI device.
Now I have query here that if I want to use more than one SPI device present in my micro controller e.g. imx6 then how I will handle this situation?
How will I receive SPI device pointers in this case?
Is the probe function will be called twice (bcoz here only I get SPI device pointers from kernel)?
Do I need to create entries such as done in spidev_dt_ids:
http://lxr.free-electrons.com/source/drivers/spi/spidev.c#L657
I haven't worked on specifically spi device, but I think I might give you some basic idea. The logic is that probe is called whenever there is matching between device->name and device_driver->name. So 2 devices can use same driver but 2 drivers should not be there for same device.
For configuring 2 devices to same driver, the 2 device will be registered on same name and hence same probe will be called. But then in probe you can differentiate. You will have access to the device struct of spi which you can use to set one parameter to distinguish and set the relevant parameters.
One more approach is like using core framework used by i2c in which general functionality functions are made and used by client driver whenever needed.
I hope this helps.