gpio_test from PSP on DM365 - interrupt not serviced

I attach my wagon to this post because of problems on gpio_test.c in the PSP (examples for the dm365) I got to work on EVM for DM365.

I try to transform the gpio_test.c kernel module into a kernel module that exposes a dev interface to user. This is my interest in looking at this file.

While looking more precisely at this file I was wondering to see that all switching tests made on cpu type are made either on dm355, or dm644x, or dm6467 but NOT on dm365.

Is that a bug in the PSP I have on the dvsdk.

Maybe this is the source of the problem of interrupts on the post above

To verify and confirm here are my versions of sdk:

DVSDK : 2.10.01.18

PSP       :2.10.00.14

Thank you for your information

Thanks for response

I am also using DVSDK 2.10.01.18 as well as PSP 2.10.00.14.

It's disappointing to have Product Support Package but not ported to 365 and when tests not working its difficult to find problem but luckily I'm learning in this way also.

I wanted to use GPIO for external reference line doing video time checks.  Being a linux newbie I am learning kernel space user space stuff now and also busy making a module / driver to interface between spaces.  I checked all register addressing from gpio_test and saw 355 mapping is same as 365 so ported the switches to work for 365.  All seems to be OK theoretically running in irqk module when it is inserted - also seeing toggling of GPIO0 line (gpio_num=0 and irq_num=44) - but interrupt handler routine is not executing at all.

I found other small bugs on dvsdk but like I said everything looks OK now so I don't know if this is a bug or not.  You said you managed to get it working on dm365 - was that the gpio_test in kernel space actually servicing the interrupt?  If so, what was bugs/you fixed / changes you made?

I would be interested in some help creating the kernel module and found lots of literature on the net and currently reading about device drivers and looking at a template from captains universe where he gives a skeleton to do this.

Thanks

Jinh T

Jinh said:

It's disappointing to have Product Support Package but not ported to 365 and when tests not working its difficult to find problem but luckily I'm learning in this way also.

It is often the case when the product is relatievely new as the dm365 is.

A good starting point is to read the code as we did and try to understand, but what is more a problem is the time used to do this. And sometimes it is not planned.

Jinh said:

I wanted to use GPIO for external reference line doing video time checks.  Being a linux newbie I am learning kernel space user space stuff now and also busy making a module / driver to interface between spaces.  I checked all register addressing from gpio_test and saw 355 mapping is same as 365 so ported the switches to work for 365.  All seems to be OK theoretically running in irqk module when it is inserted - also seeing toggling of GPIO0 line (gpio_num=0 and irq_num=44) - but interrupt handler routine is not executing at all.

I think that in gpio_test, you should complement the tests switch (or at least try to do it) and add "cpu_is_dm365" when there is "cpu_is_dm355", and just try. At least for the Gpio since you said that the gpio are the same (i doubt the alternate peripheral functions on the gpio are all the same anyway)

Jinh said:

I found other small bugs on dvsdk but like I said everything looks OK now so I don't know if this is a bug or not.  You said you managed to get it working on dm365 - was that the gpio_test in kernel space actually servicing the interrupt?  If so, what was bugs/you fixed / changes you made?

I have not fixed any bugs about gpio for the moment, i just recovered code from different TI sources (on this forum); try to understand them, and now that there are understood finally conclude that i have to complete the driver to have a user dev interface. I need redevelopment and testing.

The changes that I will make is to create ioctl to make pins toggle.

Try to add the cpu_is_dm365 in your gpio_test.c driver file.

I hacked the gpio_test into irqk module that is inserted when loadmodules_sd.sh is executed as I wanted to have interrupt functionality while running my hacked encodedecode demo.  With this hack I removed all other switching and only have cpu_is_davinci_365.  the only change I "made" is when gpio_demux_pins is called where nothing is done as I understand it that GPIO0 is not routed through multiplexer - not necessary for what I want to do as servicing output interrupt should work when pin is toggled.  I checked addressing of gpio registers and mapping in header file between 355 and 365 and they are the same - for gpio at least like you said.

Can still not see interrupt being serviced in kernel space when insmod of irqk.o is executed.

I am also busy now to set up ioctl to make pins toggle from user space.  Did you execute gpio_test from kernel space successfully or will you only know once finished with driver to do ioctl and be able to toggle pins?

Lots to learn for me and as you say time is not waiting.

Thanks

Jinh said:

I hacked the gpio_test into irqk module that is inserted when loadmodules_sd.sh is executed as I wanted to have interrupt functionality while running my hacked encodedecode demo.  With this hack I removed all other switching and only have cpu_is_davinci_365.  the only change I "made" is when gpio_demux_pins is called where nothing is done as I understand it that GPIO0 is not routed through multiplexer - not necessary for what I want to do as servicing output interrupt should work when pin is toggled.  I checked addressing of gpio registers and mapping in header file between 355 and 365 and they are the same - for gpio at least like you said.

Can still not see interrupt being serviced in kernel space when insmod of irqk.o is executed.

I guess you made the minimal verification : and for this test of course you garantee that your pin GPIO0 toggle ? Is the direction of this GPIO is set properly as input ?

Jinh said:

I am also busy now to set up ioctl to make pins toggle from user space.  Did you execute gpio_test from kernel space successfully or will you only know once finished with driver to do ioctl and be able to toggle pins?

gpio_test.ko is well inserted into the kernel except there is a Failure message on SET_RIS_TRIG not set to 1 for gpio 7 when init.

I have to change all this to make the gpio user selectable and remove all unnecessary stuff for my application.

My user driver is still to be programmed by difficulty is not here since it will be accessing a character driver. Tricky stuff is more in the driver itself. Like many other things expertise can only come from experience.

reda

Jinh said:

I hacked the gpio_test into irqk module that is inserted when loadmodules_sd.sh is executed as I wanted to have interrupt functionality while running my hacked encodedecode demo.  With this hack I removed all other switching and only have cpu_is_davinci_365.  the only change I "made" is when gpio_demux_pins is called where nothing is done as I understand it that GPIO0 is not routed through multiplexer - not necessary for what I want to do as servicing output interrupt should work when pin is toggled.  I checked addressing of gpio registers and mapping in header file between 355 and 365 and they are the same - for gpio at least like you said.

Can still not see interrupt being serviced in kernel space when insmod of irqk.o is executed.

I guess you made the minimal verification : and for this test of course you garantee that your pin GPIO0 toggle ? Is the direction of this GPIO is set properly as input ?

Jinh said:

I am also busy now to set up ioctl to make pins toggle from user space.  Did you execute gpio_test from kernel space successfully or will you only know once finished with driver to do ioctl and be able to toggle pins?

gpio_test.ko is well inserted into the kernel except there is a Failure message on SET_RIS_TRIG not set to 1 for gpio 7 when init.

I have to change all this to make the gpio user selectable and remove all unnecessary stuff for my application.

My user driver is still to be programmed by difficulty is not here since it will be accessing a character driver. Tricky stuff is more in the driver itself. Like many other things expertise can only come from experience.

reda

from configuration transferred from gpio_test, the GPIO0 is set up as output pin on int 44.  I can see line toggling on evalaution board when module is inserted but the printk in the interrupt handler is never executed.  The SET_RIS_TRIG failure or SET_FAL_TRIG does come up depending on the setting of the interrupt edge which I don't think should make a difference so the default setting from the gpio_test should work.

Good luck with the driver.  Please tell me if you got the gpio_test interrupt serviced from kernel space at all or do you first want to finish the driver?

hi~

you are doing what i exactly wanna do.

I also tested gpio_test with my 365EVM, but the interrupt handler never response.  and I read this page http://e2e.ti.com/support/dsp/davinci_digital_media_processors/dm3x/f/100/p/28116/98046.aspx#98046

 but it doesn't clear.

Do you have any idea to use gpio interrupts?

thanks.

Hi melon,

did you resolve this issue with gpio0?  I am on this issue again as I was busy with some other problems since I last posted.

Thanks, Jinh T

Hi Jinh.

I solve that issue  ^^;  just change related registers.

Thank you for your concerns.

melon.

Can you tell me which registers please?  I am also learning drivers to do user-kernel space interfacing.

Thanks, Jinh T.

Could somebody - preferably from TI- please explain how to get gpio_test for the evmdm365 board working.  There seem to be code in this module that was not ported for dm365 as current state of test code is only swithing for 355 and 644x.

Thanks, Jinh

Jinh said:

Can you tell me which registers please?  I am also learning drivers to do user-kernel space interfacing.

Hi Jinh T.

I attached the source code based on PSP. just change .txt to .c

I can't garuantee it but, you can reference the code.

it's working on MV kernel.

melon.

melon, thanks for the listing attached.  I compared with my setup and added some of your changes.  Code runs when module is inserted but I do not see the interrupt handler executing.  I only have terminal as debug tool and can see the io line toggle on the oscilloscope but not service routine execution.  Is there any other way I can determine if the service routine is running ( i have not figured out a way to control the LED's) ?  Anybody with some suggestions please as I am starting to believe it is the hardware and not my limited knowledge of linux that's causing me to struggle here.

Thanks, Jinh T.

1) What could change are the AINTC interrupt mapping and the Pin multiplexing (ie what peripherals use what pins).
I would have expected it to be the same on DM355 and DM365 as both are ARM926 devices but it is not the case.

You need to double check:
a) ARM926 interrupt source:
The DM365 ARM sub system - sprufg5a page 88 gives the AINTC table. There are 8 distinct GPIO interrupt numbers that can be used.

b) Device Pin Multiplexing:
Even ifthe PINMUX registers are located at the same address the DM365 and DM355 pin multiplexing are different.
See for example for PINMUX3:
    DM365 ARM sub system - sprufg5a section 9.12.5.
    DM355 ARM sub system - SPRUFB3 section 9.10.5
    

2) To debug further you could look at the nFIQ/nIRQ register to see if an event reached the interrupt controller at all.

The memory map is shown in section 2.6 of the DM365 datasheet - SPRS457C. It gives the base address of the Interrupt controller (INTC).
The DM365 ARM sub system - sprufg5a section 8.4 gives the address of the different INTC registers.

- You can read the register via the user's space using the code mentionned in this post:
http://www.mail-archive.com/davinci-linux-open-source@linux.davincidsp.com/msg03798.html
It is likely that you will need to modify it to add the INTC registers.

Hi melon , Jinh and all friends:

Can anyone help me! I have use 3 weeks on this problem:

I only  want to set  GPIO79 GPIO80 toggle to High(3.3V),but CPU's 79 pin or 80pin
is keep low(0.0V) all the time.I also try GPIO50 to GPIO100,CPU's pin is low all the time;

I change the "gpio_test.c" :

//static int gpio_num = 0;
static int gpio_num = 79; //or 80;

void gpio_write(void)
{
 int i, j;
 int toggle = 0;
 int gpio;
  //for(i=50;i<100;i++)//try gpio 50 to gpio 100
   // {
 gpio = (dir == GPIO_DIR_IN) ? gpio_src : gpio_num;

 printk("<1> \n");
 printk("<1> Toggle gpio %d \n", gpio);

        gpio_set_value(gpio, 0);
        msleep(5000);//sleep 5 second
        gpio_set_value(gpio, 1);
        msleep(5000);//sleep 5 second

        gpio_direction_output(gpio, 0);
        msleep(5000);//sleep 5 second
        gpio_direction_output(gpio, 1);
        msleep(5000);//sleep 5 second
      //}
}

Thanks for sharing this post. This is a very helpful and informative material. Good post and keep it up. mcdst are always helpful in one way or the other, that’s cool stuff, anyways, a good way to get started to renovate your dreams into the world of reality.

Are you using evmdm365 board?

I would think you must go check out port settings (in/out) and if pinmuxing is applicable/correct.  I only used gpio0 and toggling was working first time but gpio0 is not influenced by pinmux but also wired to cpld on evmdm365 but I changed configuration inside cpld and am using gpio0 pin now as input and am handling interrupt on received falling edges that is triggered by sw5.2.

How you get it fixed! Jinh T.

My board is evmdm365 rev c ,sdk version is dvsdk_2_10_01_18 ,linux kernel version is 2.16.18_pro500;PSP version is PSP_02_10_00_14;

I have chaged the code in gpio_test.c like cpld.c  :

gpio_write()

{

cpld_base_addr = ioremap_nocache(DM365_CPLD_BASE_ADDR,
      DM365_CPLD_ADDR_SIZE);
__raw_writeb(0xff, cpld_base_addr + 0x10);

msleep(5000);

__raw_writeb(0x0, cpld_base_addr + 0x10);

}

// why DM365_CPLD_BASE_ADDR is 0x4000000 ???????

I think the GPIO_base is  right ? and the ptr is right?

if (gpio < 32)
  ptr = (void *__iomem)IO_ADDRESS(gpio_bank->base + 0x10);
 else if (gpio < 64)
  ptr = (void *__iomem)IO_ADDRESS(gpio_bank->base + 0x38);
 else if (gpio < 96)
  ptr = (void *__iomem)IO_ADDRESS(gpio_bank->base + 0x60);
 else
  ptr = (void *__iomem)IO_ADDRESS(gpio_bank->base + 0x88);
 return ptr;

some years ago I use ATMEL ARM926 , all gpio control is very simple .

then the LED DS2~DS9 change also J14.63~J14.65  J14.14 ...is high after 5 second  the pin is low ,

but  J18 24 pin ,J18 8pin J19 2pin 6pin 10pin ... all GPIO pin is low.

I only want to chage gpio78~85 to high.

I will test the gpio0 for a monent!

Hello friends: I have resolved the problem of "set a gpio pin to high or low". the gpio_direction_output, gpio_set_value,gpio_get_value have no problem, have no bug! thanks all !