Intel chipset - GPIO programming

Question

From the spec, I knew the following information:

JGPIO1 PIN# :10

SoC GPIO # : 71 

USE select: IO 0x532[7] ( 0 = native function, 1 = GPIO )

IO select: IO 0x536[7] (0 = output, 1 = input )

Level: IO 0x540[7] ( 0 = low, 1= high )

In this case, I want to program GPIO pin # 10. Is there any example or sample code I can refer to ?

I can do this thorugh RW-everything [1]. However, this is in Windows.

I want to do this in C and in linux environment.

Please advise.

===============================================================

For example, If I want to set

The 7th bit to 1 at 0x532

The 7th bit to 0 at 0x536

The 7th bit to 1 at 0x540.

Oblast

"I want to program GPIO..." -- In kernel or user space? "those seem to be different with what I expect to have" -- What do you "expect to have" (whatever that means)? What do you actually have? – Marelda

@Marelda 1. In user space 2. Should I have a function which needs the parameters include the address and bit ? 3. I thought the above information is enough to do the GPIO programming, are those not enough ? what else I should provide ? – Oblast

@Marelda questions updated. Please if it is still unclear to you. It's my first GPIO programming so that still need something to learn. – Oblast

Linux user-space programs typically access GPIOs using sysfs. Have you looked at that? – Marelda

@Marelda Do you mean /sys/class/gpio ? – Oblast

Yes, sysfs refers to the special filesystem mounted at /sys – Marelda

@Marelda yea, I went through this before. black-swift.com/wiki/index.php?title=Working_with_GPIOs_%28C/… – Oblast

It mentions to use echo first. "echo "27" > /sys/class/gpio/export" . So in my case, should I echo "10" or "71" in my experiment. – Oblast

Study Documentation/gpio/sysfs.txt. You need to map the pins you want to use with the pins in registers named as /sys/class/gpio/gpiochipN – Marelda

@Marelda you can reply as the answer so that I can check your reply. – Oblast

Let us continue this discussion in chat. – Oblast

Answer 1

In Linux userspace the typical method used to access GPIOs is the through the /sys pseudo-filesystem (aka sysfs). This offers a somewhat-portable interface that tries to minimize hardware dependencies and avoid conflicts with device drivers.

To determine the GPIO numbers that you want to access on your board, you will have to consult your SoC documentation. The directory names in /sys/class/gpio/ need to be identified with their hardware register counterparts. These directory names will have the form gpiochipN, where N is for the base GPIO number in that register. The file gpiochipN/label should help identify the register, e.g. by its (memory or port) address.

Note that N may not start with 0. An Intel BayTrail system might have gpiochip82 as its first directory, so the lowest-numbered GPIO would be 82. The bit number of the register should be added to the base number to obtain the GPIO number.

Refer to Sysfs Interface for Userspace for formal documentation.

I can do this thorugh RW-everything 1. However, this is in Windows.

A similar program could probably be written to execute under Linux. However Linux programs (unlike Windows which is x86-centric) should be portable to other architectures, so such a program that needs to know low-level hardware details is near-impossible to write/maintain. One purpose of device drivers is to isolate/modularize such HW details, and such a program is trying to circumvent those drivers!

Additionally using such a program could make a system unstable or malfunction. Mucking around memory and/or device registers is unsafe on a running system. FWIW I have written a utility that reports the configuration of the pins for one specific SoC, but that only reads the registers and never modifies any setting.

Note that most SoC documentation (as well as Linux) treat pin control and configuration as a separate (but closely related if not overlapping) subsystem to GPIOs. Pin control and configuration typically includes:

• multiplexing the pin for different peripherals/functionality,
• directionality (i.e. input or output),
• connecting pull-up or pull-down resistors,
• input filtering (i.e. de-glitching),
• output drive (e.g. open drain), and
• interrupt control.

The GPIO subsystem typically handles:

• directionality,
• pin state, and
• interrupt control.

Marelda

sysfs approach is quite outdated (however still enabled). – Emlen

Answer 2

Many embedded boards come with support for the EAPI Library - "Embedded Application Programming Interface". The base spec was developed by the PICMG. Here's the doc.

If you want to control and/or detect GPIO pins from a user-space program, this API probably gives you the easiest and quickest solution.

Here's a code fragment using EAPI to turn on/off an arbitrary GPO pin. (pin numbering on the device itself usually doesn't match the pin numbers on the header connector on your board so you need to translate "external" vs "internal" pin numbers.

bool
DvmA44I2CGPI::setOutput(int pinNum, bool pinOn)
{
    if (pinNum > NUMPINS)
        return false;

    bool     pinPhyVal = (mReversePolarity) ? !pinOn : pinOn;
    uint32_t       val = (pinPhyVal) ? EAPI_GPIO_HIGH : EAPI_GPIO_LOW;

    uint32_t inputs, outputs;
    EApiStatus_t rc;

    if ((rc = EApiGPIOGetDirectionCaps(EAPI_ID_GPIO_BANK00, &inputs, &outputs)) != EAPI_STATUS_SUCCESS)
    {
        fprintf(stderr, "EApiGPIOGetDirectionCaps() Get Direction Failed: ");
        printStatus(rc);
        return false;
    }


    if ((rc = EApiGPIOSetLevel(mPinMap[pinNum-1], outputs, val)) != EAPI_STATUS_SUCCESS)
    {
        fprintf(stderr, "EApiGPIOSetLevel() Set Level Failed: ");
        printStatus(rc);
        return false;
    }

    return true;
}

Qoph