I have a MicroZed board with Xillinux 1.3 running on it. I wanted to interface an external SPI ADC to it, and write an application in linux to read values from the ADC. Zynq device's hardware SPI interface isn't enabled in Xillinux. How can I go about enabling it, I would have to recompile the FSBL and U-boot, but I don't know where to start. Can I just modify the Xillinux's Vivado design and proceed from there or will I have to start from scratch?
You should not have to modify FSBL or U-boot. You should only have to add the SPI controller to the device tree and update the programmable logic so that the SPI pins connect to your ADC.
Xilinx SDK has tools for creating the device tree file, described on the Build Device Tree Blob page.
I usually edit .dts files by hand, but you still need to run dtc to convert them to binary format as described on that page.
For an example, here is a .dts fragment for a zynq-zc770-xm013.dts board enabling SPI connected to a flash chip:
&spi0 {
status = "okay";
num-cs = <4>;
is-decoded-cs = <0>;
eeprom: at25#0 {
at25,byte-len = <8192>;
at25,addr-mode = <2>;
at25,page-size = <32>;
compatible = "atmel,at25";
reg = <2>;
spi-max-frequency = <1000000>;
};
};
you have to do 2 steps.
1- modify the hardware descriptor file (.h) of your board in your kernel sources and add the spi device. First, take a look at the schematic of the board and the datasheet of the processo to make sure to use the right device with the right name
2- add spidev on your kernel config
now build and boot the kernel, if you check on /dev/ you should find spidev** something.
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 a board, SoC running Linux 5+, with a electrical relay. The relay is triggered by a GPIO. I am looking for a good way to define a relay in a device tree file.
I define LEDs as
led {
compatible = "gpio-leds";
debug {
label = "debug";
gpios = ...
default-state = "off";
};
};
This results in
# ls /sys/class/leds/
debug
I would like to have the relay be something similar such as
# ls /sys/class/{relays,outputs,gpios}/
relay1
What is a good way to achieve this?
Since relay behaves as simply as GPIO output (or more precisely GPO), what you need is just name the corresponding line. It can be done by assigning gpio-line-names property of the GPIO controller in the ACPI or Device Tree. With a use of libgpiod tools (such as gpiofind, gpioinfo), that access GPIO controller via character device node, you may find your line and do the operations on it. Note, GPIO sysfs interface is deprecated and it will be removed from the kernel on a horizon of ~5 years or so.
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 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.
I'm trying to control (on/off) a voltage regulator that is mapped to a GPIO pin and powers an external device.
The device tree for the regulator has the following entry:
reg_usb1_vbus: usb1_vbus {
compatible = "regulator-fixed";
regulator-name = "usb1_vbus";
regulator-min-microvolt = <5000000>;
regulator-max-microvolt = <5000000>;
gpio = <&gpio3 28 0>;
enable-active-high;
};
As I read the documentation i got confused for it states:
Optional properties:
gpio: gpio to use for enable control
However, I can't export the sysfs interface of that GPIO and use it to control the power supply (just on/off) for the external device. In addition if I comment out the gpio = <&gpio3 28 0>; from the device tree, the external device gets no power (when it isn't commented the device is always powered).
The regulator has a sysfs interface exported:
80090000.usb-vbus power suspend_standby_state
device state type
microvolts subsystem uevent
name suspend_disk_state
num_users suspend_mem_state
however I can't write to any of the files.
What is the correct way to interpret the gpio: entry?
gpio to use for enable control
In which case I'm missing a mapping between a pin on which I want to have the regulator voltage.
gpio which will have the voltage from the regulator to power some external unit
In which case I'm missing a way to turn it on and off
I'm trying to control (on/off) a voltage regulator that is mapped to a GPIO pin and powers an external device.
...
What is the correct way to interpret the gpio: entry?
Seems like you're asking an XY question.
First the Y part regarding the GPIO.
The gpio DT entry you refer to would be for an enable/disable control by the regulator framework. It is intended for exclusive use by the regulator driver to control the (external?) regulator hardware. It is not intended for software control of the regulator outside the framework by the user (as you are trying to do).
This GPIO is defined as an output in drivers/regulator/core.c:
static int regulator_ena_gpio_request(struct regulator_dev *rdev,
const struct regulator_config *config)
{
...
ret = gpio_request_one(config->ena_gpio,
GPIOF_DIR_OUT | config->ena_gpio_flags,
rdev_get_name(rdev));
...
}
The GPIO pin is not read for "enable control", but has its value set in
regulator_ena_gpio_ctrl() in order to actively enable or disable the (external) regulator.
The inablity to export the same GPIO pin using sysfs when that pin is also declared in the Device Tree is easily explained. Once the driver acquires the specified GPIO for its use (through the DT), it is no longer unused, and you cannot export that GPIO through sysfs anymore.
GPIOs are a managed resource, and need to be allocated and freed (by a driver or sysfs) just like any other resource such as memory. If you were able to export this GPIO that was also used by the driver, then you would be able to put the GPIO into a state that was inconsistent with what the driver was doing. That in turn would lead to an unstable or misbehaving code.
In which case I'm missing a mapping between a pin on which I want to have the regulator voltage.
The GPIO pin specified in the Device Tree is a logic (i.e. digital) output. It is not the regulator output, which would be an analog output.
You should consult the schematic for your board to confirm that this GPIO is connected to a control input of a regulator.
As to the X part regarding enabling/disabling the regulator:
Software control of the regulator's output is documented in Documentation/power/regulator/consumer.txt
A consumer driver can get access to its supply regulator by calling :-
regulator = regulator_get(dev, "Vcc");
A consumer can enable its power supply by calling:-
int regulator_enable(regulator);
A consumer can disable its supply when no longer needed by calling :-
int regulator_disable(regulator);
The 'consumer" is an electronic device that is supplied power by a regulator.
Apparently the intended framework is have the "consumer driver" own and control its regulator, and not allow an external interface (e.g. sysfs) to interfere with this "consumer driver". If you insist on having userland control, then you could implement an ioctl() or sysfs interface to the "consumer driver" (to avoid conflict/contention with the regulator driver).
In which case I'm missing a way to turn it on and off
What you're really looking for seems to be (upper-layer) power management, and that has its own framework, of which regulators is a lower layer (which is normally not accessible for user control). You should study Documentation/driver-api/pm/devices.txt.
I am not extremely familiar with the regulator core in the kernel, but it seems to me that the regulator interface needs to give you access to the GPIO in a different way than the standad export GPIO method.
I have not looked into this, but it is possible the the regulator interface opens up a character device to userspace for control over the regulator. (Don't hold me to that)
I do see in the documentation and in the driver source code drivers/regulator/fixed.c that the GPIO is not a required DT attribute. You might be able to leave it out of the DT in which case the Driver will never acquire your GPIO, then you can manually control it through the standard export GPIO interface.