GPIO32

The GIO32 pin (W2 pin on DM365) is fed into CPLD; looking at the CPLD firmware available at http://support.spectrumdigital.com/boards/evmdm365/revc/, it appears GPIO32 is routed to both R0_GIO32  and CPLD.CONN.GIO32; however, R0_GIO32  is only programmed as an output pin only while CPLD.CONN.GIO32 will allow you to treat GPIO32 as input or output.

Thank you Juan for the replay,

So , i must use CPLD.CONN.GIO32 to test the GIO32 as input and output .

In my program i use the value 32 to configure and set the GPIO32 , i want to mean that the GPIO32 of the borad is the same GPIO32 of the dm365? , because i have a driver to do this with value 32 and no thing happen ! , i can't set the pin or read a value in the board.

Thank you .

The GIO32 pin (W2 pin on DM365) should come out to CPLD.CONN.GIO32. 

As a quick test, I would configure DM365 GIO32 as output, set GIO32 pin to 1 and 0, verifying changes took effect.  You should be able to do this simple test (contained completely in DM365) regardless if GPI32 pin is properly mapped to CPLD.CONN.GIO32 or not, allowing us to eliminate this variable temporarily and focus ironing out any issues there may be with program.  This divide and coquer approach should help us get to a solution faster by eliminating the number of variables we deal with concurrently.

My goal is to test one GPIO as input or output , so not necessarily GIO32 because i want to validate my driver GPIO , so what GIO you can  board me to do this test and in which connector in the EVM DM365

Thank you.

Hello Juan,

It seems that GIO32 pin drives the J24 DILC connector on pin SPI2_SCLK_DILC and not the CPLD.CONN.GIO32 (according to the VHDL file and schematics).

The CPLD.CONN.GIO32 output on connector J23 is set according to CPLD IO register writing.

Can you confirm ?

Just to jump on the GPIO on DVEVM 365 question.

I have written a piece of gpio driver (that uses kernel gpio directive) and its userspace interface. But it looks the pin are not activated even though i am setting the CPLD registers properly (since my pins are mapped to the Imager connector interface J10).

My question is : is there demuxing to do on the gpio pins ?

In the exemple located in the psp, there is gpio_demux only if using the interrupts.

Thanks for your info

GIO32 and SPI2_SCLK_DILC are both mapped to same physical pin (W2) on the chip; therefore, they are essentially the same.  As you suggested these pins are multiplexed and configured via PINMUX4 reister (see ARM Subsystem UG)

OK. Thank you.

But for demuxing IO, has TI already proposed something in its LSP ? I have read that some PSP use gpio_request foncton in the driver before calling gpio_direction, etc...

I guess these function call demuxing.  But where to find clear info about the demuxing and its link with software  ? there is the arm subsystem doc, but it only relates to hardware.

thank you

I do not believe that there is a central place in the software where pinmux registers are configured.  My understanding is that each driver that is enabled in the kernel will make the necessary configuration it needs during its init phase (last peripheral to load wins); therefore, GIO32 is the defult for pin W2, but if you have SPI driver enabled, then this driver will likely change the pinmux4 register to get control of the pin...  before we make any assumptions, I would try to read the value of PINMUX4 register, and see how it is configured.  If you need to change it, the you can cosider disabling certain drivers in kernel (safe approach) or go hunting where this is set so you can override it (must consider what may happen as a result of overriding it).

Hi Juan,

I have looked into kernel sources dedicated to dvevm365 and dm365 in general.

Indeed the only example of demuxing is done for a GPIO20 to be able to use the I2C.

There is a function that sets the pinmux :

davinci_cfg_reg(DM365_GPIO20, PINMUX_RESV);

but for this it uses the DM365_GPIO20 define.

I was looking for this define into the source code to see that only few GPIO were defined here. So I have to redefine the ones i use, and for this the userspace driver cannot be generic. The unique solution to this would be that on shared pins, gpios are set by default. This does not match my hardware unless the alternate peripheral  is 'on' in the board init procedures. I will check this.

Just one point : gpio configuration on this platform is hell as no dedicated driver documentation exists. and there is no user interface in userspace. I suggest this point should be better processed for next psp release: a simple generic userspace gpio driver. A simple (basic) operation needs hours of struggling and search.

thanks

I hear you load and clear and will keep providing this feedback.

Thank you Juan.

In my gpio driver module i have printed the pinmux registers at module load owed to the primitives existing in io.h _REG and here is what I get for the 5 PINMUX registers

I did it after reset, and i work on a dvevm365 revE. I have loaded the module manually.

PINMUX0  : 0x00FD0000

PINMUX1  : 0x00145555

PINMUX2  : 0x000000DA

PINMUX3  : 0x375AFFFF

PINMUX4  : 0x55554555

On PINMUX4 we get the bits 11-10 set to 01=> GPIO32 is indeed SPI2_CLK

I also needed GPIO31 and 37 (also on PINMUX4) and all have their bits  set at '01' meaning SPI2 or SPI4 alternate functions.

I guess that it explains why I have no signals on the pins when I try to toggle the gpio through my driver.

What is lacking is a user space ioctl that demux the gpio pins easily. It has to be rewritten by me! and there are a lot of cases when you look at the ARM subsystem specification of pinmux registers.

Juan can you confim ?

---------------------------------

The code to get these registers :

#include <asm/io.h>

#define REG_PINMUX0     __REG(PINMUX0)
#define REG_PINMUX1     __REG(PINMUX1)
#define REG_PINMUX2     __REG(PINMUX2)
#define REG_PINMUX3     __REG(PINMUX3)
#define REG_PINMUX4     __REG(PINMUX4)

.....

in the device init code:

        printk(KERN_ALERT "REG_PINMUX0 was set to 0x%08X \n",REG_PINMUX0);
        printk(KERN_ALERT "REG_PINMUX1 was set to 0x%08X \n",REG_PINMUX1);
        printk(KERN_ALERT "REG_PINMUX2 was set to 0x%08X \n",REG_PINMUX2);
        printk(KERN_ALERT "REG_PINMUX3 was set to 0x%08X \n",REG_PINMUX3);
        printk(KERN_ALERT "REG_PINMUX4 was set to 0x%08X \n",REG_PINMUX4);

Hello Juan,

Just to confirm my experiment. On DVEVM365, by default some GPIO pins (by lack of luck it was the ones I used) that go to the CPLD to be resent to the Imager Connector are not configured at boot to be gpio but instead they  are configured to their alternate functions.

By playing in the gpio driver, with the PINMUX registers, I could demux the pins from their alternate functons and control the state of the pin in userspace.

I think it is the same problem with the GPIO32. It has first to be demuxed (but not sure, not having tested it).

For the final application of the device, i will embed the gpio control into the device with no userspace control of the gpio directly itself but rather the triggering of pulse or functionnality.

So now, i have to look to a complete userspace gpio driver from TI which enables pin configuration and muxing or demuxing (irq are not mandatory). At least for testing.

If there was something like that existing for DM365, it would be good.

Thank you for the support. Keep us aware of the existence of such userspace driver in the following psp.

Any chance of this gpio driver by anybody?

When encodedecode demo executes it sets up something on GPIO40 but this also kills my interrupt on GPIO0 which I set up when I do a ./loadmodules_sd.sh in irq.k.  Does anybody know if there is a mask that's used that I need to change or where to go and search for?

Thanks, Jinh T.

Hello Jinh

Did you verify the PINMUX register value for the pins you used ?

(Anyway GPIO0 is not muxed with another signal so it won't appear in the PINMUX registers bank)

Maybe there is also a problem of priority of interrupts as defined in the file  linux-2.6.18_pro500/arch/arm/mach-davinci/board-dm365-evm.c as shown below :

*************************************

/* FIQ are pri 0-1; otherwise 2-7, with 7 lowest priority */
static const u8 dm365_default_priorities[DAVINCI_N_AINTC_IRQ] = {
    [IRQ_DM3XX_VPSSINT0]    = 2,
    [IRQ_DM3XX_VPSSINT1]    = 6,
    [IRQ_DM3XX_VPSSINT2]    = 6,
    [IRQ_DM3XX_VPSSINT3]    = 6,
    [IRQ_DM3XX_VPSSINT4]    = 6,
    [IRQ_DM3XX_VPSSINT5]    = 6,
    [IRQ_DM3XX_VPSSINT6]    = 6,
    [IRQ_DM3XX_VPSSINT7]    = 7,
    [IRQ_DM3XX_VPSSINT8]    = 6,
    [IRQ_ASQINT]        = 6,
    [IRQ_DM365_IMXINT0]    = 6,
    [IRQ_DM3XX_IMCOPINT]    = 6,
    [IRQ_USBINT]        = 4,
    [IRQ_DM3XX_RTOINT]    = 4,
    [IRQ_DM3XX_TINT5]    = 7,
    [IRQ_DM3XX_TINT6]    = 7,
    [IRQ_CCINT0]        = 5,    /* dma */
    [IRQ_DM3XX_SPINT1_0]    = 5,    /* dma */
    [IRQ_DM3XX_SPINT1_1]    = 5,    /* dma */
    [IRQ_DM3XX_SPINT2_0]    = 5,    /* dma */
    [IRQ_DM365_PSCINT]    = 7,
    [IRQ_DM3XX_SPINT2_1]    = 7,
    [IRQ_DM3XX_TINT7]    = 4,
    [IRQ_DM3XX_SDIOINT0]    = 7,
    [IRQ_DM365_MBXINT]    = 7,
    [IRQ_DM365_MBRINT]    = 7,
    [IRQ_DM3XX_MMCINT0]    = 7,
    [IRQ_DM3XX_MMCINT1]    = 7,
    [IRQ_DM3XX_PWMINT3]    = 7,
    [IRQ_DM365_DDRINT]    = 7,
    [IRQ_DM365_AEMIFINT]    = 7,
    [IRQ_DM3XX_SDIOINT1]    = 4,
    [IRQ_DM365_TINT0]    = 2,    /* clockevent */
    [IRQ_DM365_TINT1]    = 2,    /* clocksource */
    [IRQ_DM365_TINT2]    = 7,    /* DSP timer */
    [IRQ_DM365_TINT3]    = 7,    /* system tick */
    [IRQ_PWMINT0]        = 7,
    [IRQ_PWMINT1]        = 7,
    [IRQ_DM365_PWMINT2]    = 7,
    [IRQ_DM365_IICINT]    = 3,
    [IRQ_UARTINT0]        = 3,
    [IRQ_UARTINT1]        = 3,
    [IRQ_DM3XX_SPINT0_0]    = 3,
    [IRQ_DM3XX_SPINT0_1]    = 3,
    [IRQ_DM3XX_GPIO0]    = 3,
    [IRQ_DM3XX_GPIO1]    = 7,
    [IRQ_DM3XX_GPIO2]    = 4,
    [IRQ_DM3XX_GPIO3]    = 4,
    [IRQ_DM3XX_GPIO4]    = 7,
    [IRQ_DM3XX_GPIO5]    = 7,
    [IRQ_DM3XX_GPIO6]    = 7,
    [IRQ_DM3XX_GPIO7]    = 7,
    [IRQ_DM3XX_GPIO8]    = 7,
    [IRQ_DM3XX_GPIO9]    = 7,
    [IRQ_DM365_GPIO10]    = 7,
    [IRQ_DM365_GPIO11]    = 7,
    [IRQ_DM365_GPIO12]    = 7,
    [IRQ_DM365_GPIO13]    = 7,
    [IRQ_DM365_GPIO14]    = 7,
    [IRQ_DM365_GPIO15]    = 7,
    [IRQ_DM365_KEYINT]    = 7,
    [IRQ_DM365_COMMTX]    = 7,
    [IRQ_DM365_COMMRX]    = 7,
    [IRQ_EMUINT]        = 7,
};

*************************************

also you can check how irq priorities and irq have been initialiazed in the file :

linux-2.6.18_pro500/arch/arm/mach-davinci/irq.c

good luck for this, reading you, it looks like tricky.

Hi Jinh,

Jinh said:

Any chance of this gpio driver by anybody?

The GPIO support on DM365 follows the kernel framework provided in drivers/gpio/gpiolib.c which does not have any user space interface.

Jinh said:

When encodedecode demo executes it sets up something on GPIO40 but this also kills my interrupt on GPIO0 which I set up when I do a ./loadmodules_sd.sh in irq.k.  Does anybody know if there is a mask that's used that I need to change or where to go and search for?

I am not really sure what could be causing an issue here. Have you checked the interrupt status reflected in INTSTAT register of GPIO controller (http://focus.ti.com/lit/ug/sprufh8b/sprufh8b.pdf). Also, the bank 0 interrupt should be enabled in BINTEN register. You can use the devmem2 utility for dumping registers from user space for such debugging.

Thanks,

Sekhar

I have managed to change the CPLD on the evmdm365 board to route SW5.2 to gpio0 and get stable interrupts now.  Does anybody know what the MSP430_INT net in the CPLD is for?  Spectrum Digital themselves seems hesitant to tell me and doesn't sound happy that I change stuff on the board......

I have al added another case in the switch in irqk's ioctl to interface to my interrupt from userspace and I can now poll my interrupts that are coming in at 1Hz with every frame I receive in the display module of the encodedecode demo.  After changing the CPLD my interrupt was still functional inside the app and gpio40 didn't have anything to do with it as I hoped.  Does anybody have ideas how to connect my external 1Hz TTL reference pulse to the EVMDM365 without blowing it up to void my warantee or causing liability issues?  My need is to measure the field delay/offste between the camera sync on the outside that is linked to the 1pps reference and the processing inside the dm365.

Thanks, Jinh T.