Any examples on how to modify the .dts (device tree) source for custom hardware?

[EdSutter]

I've been working with hardware that is similar to the SABRESDB iMX6 board.

My next step is to redefine a few interfaces that are custom to my board.

For starters, I'd like to just tweek my GPIO configuration, by undoing some of

the GPIO setup that was used by SABRESDB and establish my own GPIO

configuration based on my schematic.

Maybe I'm just tired, or maybe this is just hard...

I'm not having much luck figuring out how to modify the .dts files that are used with

the sabresd board.

I'm currently reading the Documentation/devicetree stuff and A Tutorial on the Device Tree (Zynq) -- Part I .

Is there any other examples or good documentation that discusses this?

Ed 

[angelo_d]

Well, as far as i understand, the unsanswered Ed question, and very interested from all, is :

How can be set the direction of a gpio pin from devicetree ?

It is clear:

- how to associate a function to a pad, like MX6QDL_PAD_GPIO_0__GPIO1_IO00  0x80000000

- how to configure pin special features (pull up(down ohm value etc)

Is is still not clear if is possible to set the direction, and how.

I suspect it is simply not possible from dts.

[ivannikolaenko]

Hi Angelo!

If You still interested, You can refer to this document to get answers, it helped me a lot:  Definitive GPIO guide - Studio Kousagi Wiki

Best Regards.

[AnsonHuang]

Hi, Ed

     We have may GPIO use case in our dts, please refer to arch/arm/boot/dts/imx6qdl-sabresd.dtsi, grep charger-led or other GPIO settings. Also, there is device tree binding DOC you can refer to, Documentation/devicetree/bindings/gpio/gpio.txt, all other GPIO related feature are in same folder.

[EdSutter]

Just to get a little bit more specific to my problem...

I am trying to use GPIO_4 simply as a gpio output.

On the SABRESD board is a volume control button. 

Is there anything else I need to change in the imx6qdl-sabresd.dtsi file besides comment out the gpio-keys node?

[EdSutter]

Replying to my own question here, but I'd love to hear from someone else on this...

I managed to get the GPIO_4 issue resolved.  Turns out that uboot was configuring

this pin to be an input (because that's how it was used on sabresd).  As soon as I

changed uboot, then these commands (at the unix prompt) worked..

echo 4 >/sys/class/gpio/export

echo out >/sys/class/gpio/gpio4/direction

echo 1 >/sys/class/gpio/gpio4/value

echo 0 >/sys/class/gpio/gpio4/value

This makes me wonder what (if anything) is done by the first

two lines (which supposedly configured the direction to be output)...

Can anyone explain this?

[peteewg]

Hi Ed,

Line 1, exports the pin. i.e initialises the hardware register, checks for conflicts such as if it's been configured for another function e.g a serial port. It also exposes the sysfs functionality. If you look at the gpio directory before and after you export you'll see a new folder containing the sysfs functions gets created (gpio4 or similar). These functions then update the appropriate registers but with a common Linux interface.

All gpios are set as inputs to begin with for safety so you don't accidentally drive into another output on your hardware, if one was driving high waggle the other low, damage could occur. So you must explicitly set it to output.

Also after use you should unexport the pin to tidy everything up.

With regards to the .dts (device tree specification) file you'll probably see it inherits from one or two other files. One thing to look out for is the pin ctrl. This is not to be confused with the pin, it is a hardware block in its own right and therefore has its own entry in the dts (which is a description of each hardware block in the system). So you'll need to define this to allow your pin to be a gpio as well as adding the pin itself.

I think I'm about 3 days ahead of you in my own development for an imx28 board, so if any experts would like to add anything, or rubbish the above explanation, be my guest.

[EdSutter]

Peter,

Thanks for the clarification; however, my fundamental problem is that this line

echo out >/sys/class/gpio/gpio4/direction

had no effect.  I would have thought that anything uboot did to the pin would

have been overridden; but that was not the case.  When I changed uboot so

that it configured the pin as ouput, then I was able to use

echo 1 >/sys/class/gpio/gpio4/value

echo 0 >/sys/class/gpio/gpio4/value

to toggle the GPIO level.  That is still a mystery to me.  Note that this is

with a MUCH newer kernel (3.12) than what is in YOCTO/LTIB, so I am starting to

conclude that I may need to step back to something that is a bit more

supported in the iMX community.  Unfortunately, I think that means a kernel

that is pre-dts.  I spent the time getting to know this (a bit); so I hate to have

to do that.

Ed

[fabio_estevam]

How did you configure the GPIO in the dts?

Regards,

Fabio Estevam

[EdSutter]

Fabio,

That's the part that I don't get!

How do I configure the GPIO in the dts?

I see the use of "gpio" all over the place, but I just wanna allocate a couple

of pins as basic GPIO pins (some input, some output) so that I can then use

/sys/class/gpio to monitor and/or modify them.

I have not seen any examples of this that make any sense to me.

For example:

Say I want to configure pad GPIO_0 as GPIO1_IO00 (ALT5), and use it as an input; and I

want to configure pad GPIO_1 as GPIO1_IO01 (ALT5), and use it as an output.

How would I do that with the DTS file so that I could then access these pins with

/sys/class/gpio/gpio0 and /sys/class/gpio/gpio1?

Ed

[fabio_estevam]

Every pin needs to have its PAD configured in the dts file. For example:

MX6QDL_PAD_GPIO_0__CCM_CLKO1      0x130b0

MX6QDL_PAD_GPIO_2__GPIO1_IO02     0x80000000

The explanation of what these values mean is available at:

Documentation/devicetree/bindings/pinctrl/fsl,imx6q-pinctrl.txt

and

Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt

The 0x80000000 means that the kernel will not touch the PAD settings and it will use whatever comes from default (or from U-boot in case it was previously configured in U-boot).

Regards,

Fabio Estevam

[sebimohan]

Hi Fabio Estevam,

I am trying to configure my mx6 gpio pins with a 3.10.17 kernel. Basically my idea is to set direction and export to user space for each gpio pin in the dts(i) files. Is there any way that it can be done from dts(i) files? or Is it true that a gpio can be configured as output only in userspace with sysfs?Please confirm.

Thanks

Sebi

[EdSutter]

I've been reading through that stuff, but something just isn't sinking in.

Bear with me here (thanks for your patience)...

If I have this in my .dts file...

&iomuxc {

    pinctrl-names = "default";

    pinctrl-0 = <&pinctrl_hog_1>;

    hog {

        pinctrl_hog_1: hoggrp-1 {

            fsl,pins = <

                MX6QDL_PAD_GPIO_0__GPIO1_IO00  0x80000000

                MX6QDL_PAD_GPIO_1__GPIO1_IO01  0x80000000

                ...

            >;

        }

    }

}

and I've got these two pins configured in uboot, the way I want them (GPIO_0=out, GPIO_1=in)

shouldn't I be able to access them as regular GPIO using /sys/class/gpio?

I know they are configured correctly in uboot because I can access them there and they do what

I expect; however when I try to read the input line (/sys/class/gpio/gpio1/value) its not reading

back the value on the bit.

Note, I realize that GPIO_1 *could* be allocated to usbotg, but I don't have USB on

this board; so that node is removed from my dts file.

Ed

[YixingKong]

Ed

Has your issue got resolved? If not, please reply with an update here, otherwise we would like to close the DI in 3 days..

Regards,

Yixing

[EdSutter]

Yixing,

No it hasn't been resolved.  The connection between device tree and the underlying kernel drivers; specifically those unique to iMX6, is still somewhat of a mystery to me.  I understand the device tree concept (I'm using it); but I still have not had time to dig into the code to really see the connection between the iMX6-specific hooks and the entries in the device tree .dts file(s). I can hack my way through it, but would like to have a better understanding of it.  Sooner or later I'll just dig into the code and figure it out.  Meanwhile, if for some reason you need to close this discussion, go for it.

What's the point here?  Why does this need to be closed?

Ed

[YixingKong]

Ed

This discussion is closed since no activity. If you still need help, please feel free to reply with an update to this discussion, or create another discussion.

Thanks,

Regards,

Yixing

[EdSutter]

No problem...

>

[YixingKong]

Ed, if your issue/question is still there, I will leave the discussion open. Please do not leave the discussion here withno action and keep exchanging emails with our engineers so that you could get response quicker.

Thanks,

Yixing

[fabio_estevam · Accepted solution]

I think you would need to register your input GPIO as 'gpio-keys' in the dts.

Please see sabresd for reference.

Regards,

Fabio Estevam

[YixingKong]

Ed

Had your issue got resolved? If yes, we are going to close the discussion in 3 days. If you still need help please feel

free to contact Freescale.

Thanks,
Yixing

[EdSutter]

Yixing,

No this has not been resolved.  The device tree in general I understand; however, its direct connection to

iMX6 device interfaces is still a mystery to me. 

Ed