[OMAP3530] Need help with a display Driver

Hi Jeremy,

It's hard to read the map you are using and also there is some information missing from the display you are using to know how to properly connect the system. It seems to me you have a parallel RGB screen, and you need to put the Display subsystem on LCD by-pass mode (MIPI DPI protocol), but depending on your screen specification you may need to adjust the wiring.

If you send me the information on the screen I can give you a hand on figuring out the right connection and will be up to you to modify the driver to properly drive the configuration. Our company offers driver development services for OMAP so if you are interested we can do the driver modification for you, or provide you support services if you are a Linux beginner.

The driver for screen is a standard framebuffer driver for Linux, which means you have a /dev/fb0 file that you can open,close,read,write with standard linux calls, but that's a bit too low for most graphic applications and you may want to use some other stack like DirectFB.

We would be glad to help you as you go through the process of driver development, it sounds like you are off to a fine start. My initial suggestion would be to start with the existing LCD drivers that are included with the and start making modifications to them to fit your particular display as you suggest. Using a third party like RidgeRun above can also be helpful particularly if you are new to driver development. Feel free to post any particular questions you have during the process.

Jeremy,

As Diego suggested, a standard Linux frame buffer driver is provided.  Since you mentioned you are somewhat new to drivers and Linux, I just wanted to make sure that you understand that most drivers provided in OMAP (such as frame buffer driver for video display) are based on standard Linux APIs.  I have not installed the OMAP DVSDK yet, but there is usually a 'docs' or 'documents' folder in the root kernel directory that has documentation on most of the standard Linux APIs. 

However, as Diego also suggested, drivers are only part of the software stack; in addition, at the user level, there are Linux standardized graphics libraries, window manager, desktop environments.... that can allow a user to program complex GUI applications in a simple manner as opposed to interfacing with drivers directly.  All these software components have their own APIs which you can program to depending how low or high in the software stack you like to program at; Linux gives users this flexibility. 

Anyway, I hope this helps and feel free to post additional questions.

Hello everyone,

Thanks for the quick response, but this has only confused me a little bit more.  I am use to using small micro's where you say write porte value. If I understand correctly, the kernal should have the functions available for me to open the new display, and write the configuration data to the new display, and this should be able to be done in a user program, with out having to change the frame buffer driver?

As mentioned previously the chart for wiring should have looked like this

DSS_DO to DSS_D7        D0 to D7

DSS_ HSYNC  (B41)       CS

T2_GPIO.1   (B6)        Reset

DSS_ACBIAS  (B38)       Address

DSS_VSYNC   (B40)       Write

DSS_PCLK    (B39)       Read

Currently I am only trying to turn the display on and get the pixel color to change.  Once I have accomplished that then I will look at getting more complex.

Thanks

Jeremy

Jeremy,

Your interpretation is correct that you can write a small user program to accomplish the task you described (no need to change driver), but please keep in mind that these parts are much more complex (and powerful) than the small micros you may have worked with in the past; this means the software required to manage the extra resources in the OMAP family of parts also increases in complexity.  At the user interface level, details such as pixel clock, vynsc, hsync.... are hidden from you.  You basically make calls like open() to open handle to driver, ioctl to send request to driver, and close to close handle to driver.  If you look at the demos folder included with the DVSDK installation, you should get a good feel of what a user application should look like (although you can probably write a simpler app to do your task).

So I have written a test program that opens the frame buffer, is there anyway to upload the program to the EVM without having to recompile the kernel, currently I am not connected to the ethernet port, is this required or can I use a different method?

Thanks

Jeremy

The ethernet port is probably the easiest method (via NFS you can share a directory with your host PC), but there are other options, such as if you have a SD card, or if you have a USB adapter you could use a USB flash drive or even a USB hard drive. Note that the drive has to have a filesystem the kernel supports, or you will have to rebuild the kernel to support the file system you choose.

Jeremy,

If you have written a user level program such as the demos included with DVSDK, you do not need to recompile the kernel.  With regards to copying your program over, NFS mount via ethernet is probably the best way to go. 

Normally, during development phase, you want to use NFS mount and/or TFTP (if working with kernel); this allow user to quickly make changes and recompile in the more powerful host and quickly test on the target; you could theoretically write your program and recompile on the target side as well, but this will be much slower (not ideal for development phase).

Omap 3530 eval kit designed by Mistral for TI. i need those shematics is any one having

The schematics for the OMAP35x EVM are available by registering at http://www.mistralsolutions.com.

 More questions,

Originally to enable the display I would do this

WrPortE(1,NULL, (char)(data>>8));
WrPortE(1,NULL, (char)data);

Where data would be 0xAABB

and I would write the configuration data to the display to power it up correctly.

If I am understanding correctly I now need to 

 fbfd_ls2 = open("/dev/fb0", O_RDWR);
        if (!fbfd_ls2) {
                printf("Could not open framebuffer.\n");
                return -1;
        }

then at this point I would need to use ioctl to write my configuration data from above.

I have been unable to find documentation on how to use ioctl correctly for this setup.

Please help.

Thanks
Jeremy

 Further investigation shows that using the standard Frame buffer driver will not work in my case. Since I require to write command followed by data, to the smart display.  The standard frame buffer does not allow for this.

Looking at what the standard frame buffer for OMAP uses, I am getting confused. Is there available out there a frame buffer driver that uses the DSS and control signals for a parallel display that can take a command/data structure, or is this something that I will have to make myself.

I only require the following functions that I can tell at the moment open, close, read and write.

Even if the driver does not exist if someone could point me in the direction of how to get started that would be appreciated.

Thanks

Jeremy

Jeremy,

The frame buffer driver is a Linux Standard API.  Normally, there is a 'Documentation' directory at the root kernel tree that has information an most (if not all) standard Linux APIs.

Please note that you can extend the frame buffer API with your own proprietary IOCTLs to meet your needs.  You can even submit your changes to open source community and have them become part of the Linux Standard API (something I am sure the smart display manufacturer will like to see).  Just one word of caution, when you define your own proprietary APIs, make sure you use values that are higher than the last standard API (I believe there is a FBIO_LAST define or similar to help you).

Finally, there is a good Linux driver book resource if you need to ramp up on Linux drivers in general: http://lwn.net/Kernel/LDD3/