sysfs of GPIO is broken after the slaveloader execution to load vpss

Rick,

GPIO 10 and 17 must be muxed pins shared with video function. so the M3 firmware changee those pin to either input or output function instead of GPIO. You can refer to DM814X TRM to get more information about PIN MUX.

Regards,

yihe

Thank you, yihe,

I searched the vpss, hdmi and Cortex-M3 MPU subsystem chapters in 8148 TRM, but still don't get the information about what pins are used on what component.

Beside the video component, I will also use the DSP component.

So I think I must check if all the gpio I need won't be muxed during the system operation.

Would you please provide me more clue? Thank you very much.

Hi Chen,

I attached the GPIO1.GEL file that work on our EVM for your reference.  Please let me know if you have any question.

• These are the steps:

1.       GPIO_ClkEnable()

2.       GPIO1_EnableLvcmosPadN_PadPReceiver()

3.       GPIO_SelectGPIO_0and1_Pinmux()

4.       GPIO1_OutputEnable_High()  è for HIGH

5.       GPIO1_OutputEnable_Low()   è for LOW

BR,

Viet

the device Pins information are described in DM8148 Data sheet, Chapter 3. Pleaes refer to that,

Regards,

yihe

Thank you  yihe and Viet,

We've tried some other gpio pins including the gpio1 pad and got the same result.

The led always off after the execution of slaveloader,

We noticed that the tested pins contain the VIN* muxmode.

Does this means all the VIN* pins is muxed when the vpss m3 is awaken, and all the VIN* pins should be avoid when choosing a gpio to control power LED?

It is really up to how your system works? if you do not need all video function, Just do not configure the VIN pin to video function.

Hi Yihe and Viet

I have a question regarding GPIO and pinmux control. I need to use GPIO0[25] and GPIO0[19]. So, I followed GPIO1.gel configuration - from Viet Dinh above  on u-boot and the GPIO0[25] works on sysfs - gpio25 has been created with output direction but the other - GPIO0[19] doesn't work at all. Even though I try to change it by devmem2 application like below the change is not made either. 

root@dm814x-evm:~# ./devmem2 0x48140a90 w 0x00060080
/dev/mem opened.
Memory mapped at address 0x402e7000.
Value at address 0x48140A90 (0x402e7a90): 0x00050001
Written 0x60080; readback 0x50001

Basically, I don't load HDVICP2 and HDVPSS firmware so I guess there is no potential pinmux conflict between GPIO and VID(camera I/F) but it doesn't allow any modification. Do I miss something or misunderstand how the gpio works ? 

Another question is what the MLBP_SIG_IO_CTRL_FOR_GPb7b8 and MLBP_SIG_IO_CTRL_FOR_GPb9b10 registers are. On my testing, any GIO doesn't work without them.  I couldn't find in any datasheet or this forum. 

Best Regards,

SK

Hi Seungsik Kwak,

1. Through devmem2 we can not change the PINMUX value because those registers are in supervisor mode.

2. There is a possibility of setting the same line for some other module in Kernel

You should add these settings in kernel, devices file (arch/arm/mach-omap2/devices.c), similar to

omap_mux_init_signal("mmc2_dat4.gpio1_22", TI814X_PULL_UP);

Sample:-

You can add any one of these depends on your usage

omap_mux_init_signal("vin0_de1.gpio0_19_mux0", TI814X_PULL_UP); or

omap_mux_init_signal("mcasp3_axr1.gpio0_19_mux1", TI814X_PULL_UP);

Regards

AnilKumar

Please mark this Forum post as answered via the Verify Answer button below if it helps answer your question.  Thanks!

Hi All,

What i understood from the above discussion is that pinmux settings gets changed once you load the binary. Simple solution to this problem is to set the pin mux in any of the modules which are loaded after binary like vpss.ko, ti81xxhdmi.ko etc. You can add above lines in init function of the vpss or ti81xxfb to revert it back to original.

Regards,

Hardik shah

Hi  HardiskShah and Anil,

Thank you guys for the suggestion. I believe that I have done most of way which you guys recommends. What I have done so far are below.

1. Stay second u-boot and change all GPIOs needed and let linux kernel boot which doesn't have any video related function enabled --> fails, once linux kernel starts, the GPIOes mode changes. I have checked them out using LED GPIO pins.

2. Add GPIO mode into board_mux[] in board-ti8148evm.c or omap_mux_init_signal function being used and linux kernel doesn't have any video frontend(camera I/F), backend (display I/F) and firmware loaded to M3 processors. --> doesn't work either.

Only different thing between video feature enabled and disabled is a change from pull-up to pull-down - something like below.

./devmem2 0x48140a90
/dev/mem opened.
Memory mapped at address 0x40252000.
Value at address 0x48140A90 (0x40252a90): 0x00050001

After being changed

./devmem2 0x48140a90
/dev/mem opened.
Memory mapped at address 0x40252000.
Value at address 0x48140A90 (0x40252a90): 0x00060001

Also, no matter what I do - enable and disable, if I don't set up two mysterious registers - MLBP_SIG_IO_CTRL_FOR_GPb7b8 and MLBP_SIG_IO_CTRL_FOR_GPb9b10, GPIO function doesn't work at all.

I'm really curious what those registers are for. 

Any suggestion or mistake I have made ?

Best Regards,

Seungsik Kwak.

Hi all,

Finally, I got some GPIOs working. I forgot to add magic and mysterious registers called MLBP_SIG_IO_CTRL_FOR_GPb7b8(0x48140E18) and MLBP_SIG_IO_CTRL_FOR_GPb9b10(0x48140E1C). Once they are added on board-ti8148evm.c, LEDs starts working. Thank you guys for the advice and information.

I'm still wondering what those registers are. Anyone knows them ?

Best Regards,

SK.

Hi Seungsik Kwak,

What values are you writing to those registers or what code you add to board file.

Regards

AnilKumar

Please mark this Forum post as answered via the Verify Answer button below if it helps answer your question.  Thanks!

Hi,

vpss.ko is not touching pin muxing. But pin muxing is touched by binary you load on VPSS-M3. Can you please let us know which binary are you trying to load.

Regards,

Hardik shah