trying to access i.MX25 GPIO pins

[albert_arquer]

Hello again, I am now trying to access de GPIO pins of the i.MX25 PDK through the sysfs system.

(By the way, I would really appreciate it if someone could refer me to some document/tutorial explaining the working principle of this method since it is a bit of a mystery for me)

I am doing this on a i.MX25 PDK board (not actually the PDK from freescale but an almost identical one) and for starters, I would like to claim pin D12.

The thing is that I have seen in the u-boot code (board_init fuction to be precise) that this pin is actually declared as GPIO even though it is used for the FEC reset or power enable (I don't remember right now). On the board I am using, this pin is left unconnected but the code from u-boot has not been modified so it is still declared as GPIOs.

Well they thing is that I tried to use the pin using the typical method using as export index (4-1)*32 + 8 = 104 since the D12 pin is GPIO4[8] and I have not been able to write anything to it (even though the u-boot code really does modify it's value at boot time by asserting a low pulse for 20 us approximately, this indicates me that the pin is free to move up and down as is not a hardware problem).

What am i missing? I though about using the mxc_gpio_request function but since I have read on the source code that it is optional and that would require compiling an application I though I would try to avoid using it if possible.

Do I have to modify the boot loader code? is the FECs driver interfering with my calls? (I don't thing so since I really doubt those pins are actually controlled by the FEC module). 

Any ideas?

Thanks a lot!

[albert_arquer]

Hi, sorry but stopped trying tompull out all of this a while ago... In my opinion it is all very caothic and I have never finded a complete guide on it for dummies... In our vase we were interested on reading many different interfaces from many different ADCs (some of them not very standard) so the speed was also very important, since it was all so obscure and the speed turnd all to be so slow (at least we didn't manage to make it run faster) we are finally using an Spartan6 FPGA with a MicroBlaze processor. I guess that if it was to be done with an embedded CPU it should be done without an OS running since this drastically slows it down, however you would not be using any of the other periferals.... Maybe a multicore ARM one with linux and one without could also work.

[jose]

@Jill

Thanks for the info, appreciated.

[jlu]

I hope you all have figured the problem out. For imx25 3stack board, there is an error in the mx25 head file. The base address of GPIO3 is wrong. I had hard time figuring it out and pointed it out to Freescale months ago.

[jose]

May I ask the update of this?

@Albert:

Have you solve your prob? maybe you could share it to us?

I'm also familiarizing the imx53 platform, by the way this is my first board.

[albert_arquer]

Help please... I just whant to know if using the "gpio_request" "gpio_set_value" etc.. are the best way of interacting with the IC's GPIO pins... I mean, is this way the fastests the i.mx25 can go? or would it be faster to implement a driver which wrote directlly to the GPIO memory space...

any help will be appreciated.

Thanks

[albert_arquer]

Hello... I have been working on this for two days and I finally got the pin D12 on the i.mx25 to move up and down.... However the method I am using seems caothic... I will describe it now:

I have added the following item to the mxc_iomux_pin[] in the /arch/arm/mach-mx25/mx25_3stack_gpio.c 

{    MX25_PIN_D12, MUX_CONFIG_ALT5,     PAD_CTL_SRE_FAST | PAD_CTL_DRV_HIGH | 

PAD_CTL_DRV_3_3V | PAD_CTL_HYS_CMOS |    PAD_CTL_47K_PU | PAD_CTL_PUE_PULL | 

PAD_CTL_ODE_CMOS | PAD_CTL_PKE_ENABLE,    },

Then I have added this code in the mx25_3stack_gpio_init() function in the same file:

a = gpio_request(IOMUX_TO_GPIO(MX25_PIN_D12), "d12");

b = gpio_direction_output(IOMUX_TO_GPIO(MX25_PIN_D12), 0);

printk(KERN_ERR "\n\r ------------------------------ TRYING TO REQUEST GPIOs ------------------------\n\r");

printk(KERN_ERR "gpio_request(IOMUX_TO_GPIO(MX25_PIN_D12),NULL) = %d", a);

printk(KERN_ERR "\n\rgpio_direction_output(IOMUX_TO_GPIO(MX25_PIN_D12), 0) = %d", b);

    for (i=0;i<10;i++) {       

printk(KERN_ERR "\n\r-------->SWITCHING D12");

gpio_set_value(IOMUX_TO_GPIO(MX25_PIN_D12), 0);

gpio_set_value(IOMUX_TO_GPIO(MX25_PIN_D12), 1);    }

  a = gpio_request(IOMUX_TO_GPIO(MX25_PIN_D11), "d11");

b = gpio_direction_output(IOMUX_TO_GPIO(MX25_PIN_D11), 0);

printk(KERN_ERR "\n\r ------------------------------ TRYING TO REQUEST GPIOs ------------------------\n\r");

printk(KERN_ERR "gpio_request(IOMUX_TO_GPIO(MX25_PIN_D11),NULL) = %d", a);

printk(KERN_ERR "\n\rgpio_direction_output(IOMUX_TO_GPIO(MX25_PIN_D11), 0) = %d", b);

    for (i=0;i<10;i++) {

printk(KERN_ERR "\n\r-------->SWITCHING D11");

gpio_set_value(IOMUX_TO_GPIO(MX25_PIN_D11), 0);

gpio_set_value(IOMUX_TO_GPIO(MX25_PIN_D11), 1);    }

I inserted this text right after the for loop which seems to initialise the iomux block and the pads.

Ironically, D12 throws out a -16 error (which means the resource is busy) and D11 does not give me an error (returns 0), however, D12 actually works and goes up and down evey time I reboot and D11 does not....

I am sorry but this is so caothic for me... how can I know wether this pin is beeing used by another driver/code/whatever ?

If I where to compile an application, could I still invoke these functions (gpio_set_value, gpio_request, gpio_direction_outpu....) from the application? is this a good way to move the gpio pins? I mean, I observed with an oscilloscope and the pins are moving at 250ns.. isn't that a bit slow? is there a way to improve it by writing directly to the GPIOC registers from a driver?

Could someone explain to me or refer me to some document explaining the exact procedure to move gpio pins up and down? I don't only mean the standard linux part of it (which I understand is the part involving the calls to gpio_request, gpio_set_value etc... please correct me if I am wrong) but the platform specific procedure....

i don't know, anyone who can drop me a line with some knowledge on the topic will be of help in getting a more complete view of the problem.

Thanks a lot.

[Don_ng]

Here is the link

http://imxcommunity.org/forum/topics/need-info-on?commentId=4103961%3AComment%3A17102&xg_source=acti...

See this posting [ Reply by Bryan JI on June 10, 2011 at 1:16am ]

I guess it makes sense now that I've re-read this for the hundredth time.  I don't want the BSP or u-boot to control the pin, I want sysfs to control it so I can access it via userspace. 

[Don_ng]

It was CAN_RX1.   No, as far as I could tell, it also was not initialized in u-boot.  I did see a discussion in another thread about the imx51 (i think) and someone said that if you want the pins as GPIO, you don't initialize them.  If I can find it again, I'll post it.  It didn't make much sense why you would NOT initialize the pins as GPIO in the kernel, but it seems to work if you don't.

[albert_arquer]

Hi Don, thanks for replying, I'm glad you got it working. It would be very helpful to me if you could answer me just one question. What pin did you use? was this pin initialized in u-boot and the BSP as GPIO?

It's odd that you could use it without requesting it to the gpio module, I guess it is a pin that is truly not used by any other driver and maybe you did have some CAN driver being compiled in that was claiming the pin before you... I don't know, I'm just guessing.

I would be very grateful if you could provide me a little more details and specially if you could answer my previous question about the specific pins you are using.

Thanks a lot!

[Don_ng]

Albert

Was finally able to do it, but had to use a different pin.  The "echo 1 > value" and  "echo 0 > value" do indeed work.  However, I had to use a different pin that what I originally used.

As for your questions :

1. I did place my code there.  It didn't seem to want to work when I had my code there.   It only work after I removed by code

2.  No I did not.  I'm not sure to what array he was referring to.  I couldn't find in it the PDK BSP or the PDK u-boot code.

[albert_arquer]

Hi Don, sorry I had not seen your reply! It seems we are trying to do things pretty similar. Unfortunatelly I can't really help you, the only idea I have is to check that some other module is not claming the pins before you and that you could try and figure out what that error code (-16) means by looking at the implementation of "gpio_request" routine.

Could yo please answer me a couple of questions?

1.This code you pasted, did you add it to the mx25_3stack_gpio_init routine inside arch/arm/mach-mx25/mx25_3stack_gpio.c? (sorry if the path is not precise but I am writing from home and I don't have the BSP accessible right now).

2. Did you add your pins to the array that Paul Fertser was referring to? If so, where did you find the array??!

Thanks in advanced.

[PaulFertser]

Well,  using an old weird kernel fork doesn't sound right to me. How can it be any better than working on (and improving) upstream? You can also use some online Linux-Cross-Reference resource to speed up the code comprehension. I'm unsure how can i help you, sorry :(

As to the array, of course it's not described in gpio.txt because this gpio documentation is generic and the array is imx-specific way to configure the iomux module and the pad control.

[albert_arquer]

I don't get it... I am using the BSP downloaded from freescale and I don't have any directory called "mach-imx" under "arm".... I have been unable to find any similar array in the BSP using grep....

All I have found are two functions called "gpio_fec_active" and "gpio_fec_incative" function called in "arch/arm/mach-mx25/mx25_3stack_gpio.c" which seem to claim the pads and GPIOs just like u-boot does at boot time, so if these functions where actually called they could be the problem since they would take away those pins I guess. However I have been unable to find any call to them from inside the kernel.....If i run "grep -r "gpio_fec_active" *" from the souce directory I only find the function itself in the file mx25_3stack_gpio.c but no other calls.....

I know I look pretty lost but I'm trying.... I just don't know where to get this info from and all I see are a millions of files with lots of code from which is pretty hard to get a working perspective... for example, this array I have to modify appears nowhere on the gpio.txt documentation right?

Help please :(

[Don_ng]

I'm running into the same exact issue, but I am trying to use GPIO4_6, the CAN_PWDN pin since we are not using CAN.  I am using the PDK boards, completely unmodified, but always get a return value of -146 from gpio_request. 

I have the pin set up as MUX_CONFIG_ALT5, as seen in the code here :

i = mxc_request_iomux(MX25_PIN_D14, MUX_CONFIG_ALT5);    // this successeds

mxc_iomux_set_pad(MX25_PIN_D14, PAD_CTL_DRV_3_3V | PAD_CTL_PKE_NONE | PAD_CTL_ODE_CMOS | PAD_CTL_DRV_NOIRMAL | PAD_CTL_SRE_SLOW);

i = gpioi_reqest(IOMUX_TO_GPIO(MX25_PIN_D14),  NULL);  // fails with -16

i =  gpio_direction_output(IOMUX_TO_GPIO(MX25_PIN_D14),  0);  // succeeds

gpio_set_value((IOMUX_TO_GPIO(MX25_PIN_D14),  0);

This is all called from mx25_3stack_gpio_init.   I see the gpio pin folders under /sys/class/spio like I am supposed to so I think that is all working.

From the command line on the PDK I so

echo 102 > export

folder gpio102 is created

then echo out > direction   from /sys/class/gpio/gpio102  and this succeeds

then echo 1 > value  but the value never changes.  Probing the pin confirms this. 

Any ideas ?  I have also turned all touchscreen, all video related, and all FlexCAN features off in the kernel so that there are no conflicts .

Any ideas what I could be doing wrong ?

[PaulFertser]

http://git.pengutronix.de/?p=imx/linux-2.6.git;a=blob;f=arch/arm/mach-imx/mach-mx25_3ds.c;h=7f66a91d...

By adding the value to the array you make Linux configure IOMUX accordingly on boot. You need it configured to GPIO to actually have any control over it.

[albert_arquer]

Sorry again but I am having the hardest time trying to figure out what file you refer to. I don't know if you are talking about the u-boot code or the linux code.... I tried running grep on both root directories (u-boot's and linux's) and found nothing with the name mach-mx25_3ds....

I know I am probably a big pain but could you elaborate a bit more on you reply? what file am I looking for? what am I doing by adding that value to the array?

Thanks a lot.

[PaulFertser]

"Sysfs Interface for Userspace section" in Documentation/gpio.txt, and it's easy to understand.

When i say adding MX25_PAD_D12__GPIO_4_8 to the array i mean ``mx25pdk_pads'' array in arch/arm/mach-imx/mach-mx25_3ds.c (or the same for your particular machine).

[albert_arquer]

Hi Paul, the directories do appear in sysfs. Where can I get this gpio documentation which you are referring to??

Also, what do you mean when you say adding MX25_PAD_D12__GPIO_4_8 to the array? what array? how do I do this?

I have been trying to read the documentation gpio.txt but I find it very hard to understand, I just whant to know the various steps needed to use some pin as GPIO as I though I only had to configure de IOMUX module correctly at boottime (modifying u-boot's code) and then have some driver writting to the corresonding memory address and now I find that many other steps are required.....

Thanks a lot for your time.

[PaulFertser]

Does the corresponding directory appear in sysfs after you're exporting the pin? It should. Please reread the sysfs gpio documentation, it should be really simple to use it (if you do not have that pin claimed by some kernel driver), also do not forget to add MX25_PAD_D12__GPIO_4_8 to the initialisation array.

HTH

[robby]

I'm not working on MX25.

My suggestion is to read doc Documentation/gpio.txt in Linux kernel directory first, and see whether the driver has already implemented the feature you need. If not, try to do it.