I have to handle (i.e. turn on and off) my LCD Power Pin kernel and userspace both side.
We have configured the gpio pin in Mux.h,da850.c and board-da850-evm.c properly.
The problem is that when we configure this pin in kernel then this pin is not access by /sys/class/gpio.
We have configured this in in board-da850-evm.c as below,
ret = gpio_request(DA850_LCD_GP3, "LCD GP3");
if (ret)
pr_warning("Cannot open GPIO %d\n", DA850_LCD_GP3);
gpio_direction_output(DA850_LCD_GP3, 1);
gpio_set_value(DA850_LCD_GP3,1);
If we comment this section.and export from userspace then we used this pin form userspace successfully.
Is it possible to handle gpio form kernel and userspace?
Or do we need to write the gpio drive ?
Related
In my platform, there is a PCA9555 CMOS device which has 16 GPIO pins and a separate INT pin for interrupts. So long, my application was periodically reading a particular gpio pin. I need to change it to an interrupt driven way. From the spec : It has an open-drain interrupt pin which is activated when one of the 16 port pins changes state and the pin is configured as an input. A pin configured as an output cannot cause an interrupt.
None of the 16 pins have interrupt support themselves and I don't see edge sysfs in /sys/class/gpio/gpio/[pin_no]. So poll() on value file is not blocking. And I infer from the spec that an interrupt would be triggered to CPU if state of any of the input pins change. How do I catch this interrupt in userspace?
I see in gpiolib-cdev.c about line events.
static irqreturn_t lineevent_irq_handler(int irq, void *p)
Can I use /dev/gpiochip<n> character device and poll() for interrupts? or is this only supported for a gpio pin that supports interrupt?
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.
There is an external device (sensor keyboard) connected to processor thrue uart port (tx rx) and gpio interrupt line. Need to write driver for this keyboard (not standart own protocol, linux kernel 4.1).
I writed module whith a line discipline and requested irq on open() function (when open from user space /dev/ttymxc3). It's work, but line discipline structure has no released callbacks for suspend and resume functions.
It's need to release sleep keyboard when system is sleeping.
I try to write tty driver that use uart driver, but don't know how.
How to communicate from kernel module with external devices thrue uart port?
Thanks.
You can use uart device in kernel space
// call userspace
{
mm_segment_t fs;
fs=get_fs();
set_fs(get_ds());//KERNEL DS
handle = sys_open(UTS_UART_DEV_NAME, O_RDWR | O_NOCTTY | O_NONBLOCK, 0);
if( handle < 0 )
{
printk(KERN_INFO "UTS Port Open Fail [%s] \n ", UTS_UART_DEV_NAME);
return -1;
}
set_fs(fs);
}
// call userspace
I am writing a device driver for a PCIe card in Linux. I am trying to use interrupts in my driver.
Reading the "IRQ Line" section of the PCI configuration register (offset 0x3C) reports that the assigned IRQ line for the device is 11. lspci -b -vv also reports that my device's interrupt number is 11.
Heres where it gets weird... cat /sys/bus/pci/devices/<my_device>/irq reports that the interrupt number is 19. lspci -vv also reports that the interrupt number is 19.
Requesting 11 in my driver does not work. If I request 19 in the driver, I catch interrupts just fine.
What gives?
Thanks!!!
I believe that it has to do with the difference between "physical" and "virtual" IRQ lines. Because the processor has a limited number of physical IRQ lines it assigns virtual IRQ lines to allow the total number of PCI devices to exceed the number of physical lines.
In this instance, 19 is your virtual IRQ line (as recognized by the processor) while 11 is the physical line (as recognized by the PCI device).
By the way, you should probably really get the IRQ number from the struct pci_dev for that device since they're dynamically generated.
Sean's answer is easy to understand. However here I would try to make it more complete.
CPU's IRQ pin, almost always, isn't connected directly to a peripheral device, but via an programmable interrupt controller(PIC, e.g. Intel 8259A). This helps handling large device fan-out and also heterogeneous interrupt format (pin based v.s. message based as in PCIe).
If you run a recent version of lspci, it would print information like
Interrupt: pin A routed to IRQ 26
Here, pin A as 11 in OP, is the physical pin. This is something saved by the PCI device and used by the hardware to exchange between interrupts controller. From LDP:
The PCI set up code writes the pin number of the interrupt controller
into the PCI configuration header for each device. It determines the
interrupt pin (or IRQ) number using its knowledge of the PCI interrupt
routing topology together with the devices PCI slot number and which
PCI interrupt pin that it is using. The interrupt pin that a device
uses is fixed and is kept in a field in the PCI configuration header
for this device. It writes this information into the interrupt line
field that is reserved for this purpose. When the device driver runs,
it reads this information and uses it to request control of the
interrupt from the Linux kernel.
IRQ 26 as 19 in OP is something that kernel code and CPU deal with. According to Linux Documentation/IRQ.txt:
An IRQ number is a kernel identifier used to talk about a hardware
interrupt source. Typically this is an index into the global irq_desc
array, but except for what linux/interrupt.h implements the details
are architecture specific.
So the PCI first receives interrupts from device, translate interrupt source to a IRQ number and informs the CPU. CPU use IRQ number to look into Interrupt Descriptor Table(IDT) and find the correct software handler.
Ref:
http://www.tldp.org/LDP/tlk/dd/interrupts.html
http://www.brokenthorn.com/Resources/OSDevPic.html