omap l138 gpio driver

The newer Linux kernels have had a GPIO interface for a while. Search for "/sys/class/gpio" in this forum or on the internet. The GPIO capabilities of your specific kernel is the kernel source "Documentation/gpio.txt". The latest kernels also have edge detection. You'll need to enable GPIO file system in the kernel configuration.

If you are using the older MonteVista 2.6.18 kernel, I believe it has an deprecated interface using "/dev/gpio". That interface never made it into the mainline kernel.

I haven't seen any userspace control of the pinmux. A post by N.S.SriHarsha made this suggestion to check the MUX settings.

mount -t debugfs debug /sys/kernel/debug
cd /sys/kernel/debug/omap_mux

Never used it myself. I don't know if that interface allows changing the MUX. No doc.

The MUX config is Linux for TI's processors are in one of the arch/arm/mach-davinci/dm*.c files. Check for the ".o" files to see which one got compiled in. Assumes you are letting Linux do the MUX config. On my board it is CONFIG_DAVINCI_MUX. On others it could be CONFIG_OMAP_MUX.

I tend to avoid using mmap unless there is no other way built into the kernel or if speed is an issue. Modifying registers without the kernel's knowledge can be risky. I can see a situation where the kernel and userspace mmap both are doing get/modify/set operation at the same time.

I know how to change the pinmux in kernel but just don't wanna put it in kernel, it messes things. TI's engineer did not suggest to do that because there is KICK0/KICK1 locking the system registers.

for the way you posted, I don't see any codes that could change PINMUX for user, so I think it's not working. we did it before is to put PINMUX changing code into some other driver together and add an IOCTL to do it.

mmap is for debug in user space(something like devmem2), a lot faster than making modules and re-compile kernels.

Hi, Mr. Wong, 

do you have any clue how to rewrite SPI MTD block in linux user space? gmail.com  account  powerpan  is my e-mail address, could you drop me a mail?

my try to access mtd* all failed with permission denied.

flash_eraseall: /dev/mtd3: Permission denied

Best regards,

Power Pan

I don't have much experience with the MTD device interface. The limit of of my knowldege is programming in u-boot, kernel or file system images. An example:

flash_erase_all -j /dev/mtd4
flashcp -v filesystem.jffs2 /dev/mtd4

If I am programming the file system itself, I do this in "/tmp" to avoid overwriting myself. It's all a bit dangreous. You can "brick" your board and be forced to JTAG in stuff.

Assumes that your Linux kernel has the MTD driver for your SPI flash and that the MTD partitions have been setup. Also assumes that the utilities flash_eraseall and flashcp are already on your fille system. In other threads in this forum, people mount the MTD partition and use it like drive.

Hi, Norman, 

I really have trouble in file system, just wanna make a simple and clean file system but don't familiar with scripts, so, a little bit hard for me to make the system boot in a fast way.

hope you could guide me to do that. so, drop me a mail if you like or just ignore it.

Power Pan

I think we're in the same boat. Your knowledge of Linux exceeds mine. I have a system that takes more than 50 seconds to boot. This thread has a few suggestions:

http://e2e.ti.com/support/embedded/f/354/t/110696.aspx

Sites on the internet give general rules for speeding boot like avoiding loadable modules, static devices instead of using udev, etc. My project is currently on hold. If it becomes active again, I'll will also be looking for boot speed up tricks.

our engineer use mdev with busybox, boot up just like 8 seconds from booting kernel (3s to load ubl and u-boot, 1s delay in u-boot, 2s to read kernel, 3s to extract kernel) altogether not more then 20S to system.

but just basic mdev.

my knowledge of Linux is quite limited cause I just start getting into a little bit of kernel 2 months ago, a quite newbie, I'm working as system architecture, had to do this because our software/hardware engineer could not debug problems in driver level(deep involve with software/hardware). I made the new board changed a lots of parts on it, kinda risk but it all work fine now.