PixelSmart Driver Log 12 June 2004 1300h ? Attempt to understand how the code actually runs. Am using the newer hrt.c? All the parameters of the card is defined in hrt.h. However, the registers that are used for I2C bus is located in hrt.c Here?s the breakdown: The whole module start with: init_module(). The init_module() calls the following functions: * pci_module_init() /* this function is included in pci.h */ * hrt_try_address() /* custom */ * hrt_dev_init() /* custom */ The order listed is the order in which they are called within init_module(). Since pci_module_init() is a function defined in pci.h, I?ll go ahead and list the subroutines that the latter two addresses will call: hrt_try_address() call only one routine (I am excluding the I2C routine, since I am trying to just get it to work without V4L or I2C). This function checks to see if there really is a device at the specified address that you pass through the parameters. Here is where request_mem_region is called and checked. The routine it calls is: hrt_probe(). hrt_probe(): another function that checks whether the device is there, and verifies the presence by writing and reading from the address with the register values and the addresses. It does not call any custom functions. hrt_dev_init(): After all the checks are over, the init_module() then calls this function to initialize every video cards found (since the driver is suppose to be able to support several cards). END OF INIT_MODULE() 13 June 2004 Began to realize that I need to probe for the pci. 14 June 2004 (930h-1100h, 1700h-1845h) -15 June 2004 (005h-420h) So after looking through Dr. Baker?s I2C code, I?ve decided to stop whatever I was doing in terms of trying to write from scratch and just work with hrt-older. Kartik was right?it is more comprehensible, and it actually compiles. What I?ve done so far is that I?ve patched kraxel (v4l2) into the 2.4.26 kernel. I?m going to see if this will work out before I start modifying hrt-older. I think however, writing part of it from scratch was a necessary part in understanding how there is a three fold initialization step for the video card. So, in order to get hrt-older and hrtdemo to compile, I took the following steps: 1.) I took the patch-kraxel for the 2.4.26 kernel (the one I?m using for now) and patched up the kernel. Recompile the kernel and put it in boot menu. 2.) Use yum to download and install gtk2 and gtk2-devel (along with its dependencies like pango, glib, etc). This is for Alex?s demo program, which wouldn?t compile otherwise. 3.) I noticed that videodev.o must be inserted in order for hrt.o to be inserted. Otherwise I get these unresolved symbols error from v4l2 stuff?didn?t realize that before? If I can get at least an image, then I can start adding the interrupts, since the I2C code is already written for us, and I have a fairly good understanding as to how the code is working. No streaming so far, but at least this is a step. Problems: every thing now compiles?except here?s the strange part. I initially was able to insert the hrt-older module into the kernel. I rmmod and insmod a couple of times to make sure that there?s no problem with freeing memory. Then I got to working on getting Alex?s hrtdemo stuff working. That took a bit, since I didn?t realize it needed quite a few dependencies that luckily, the Fedora repository has all of them. Then the strange thing is, I insmod again after I finally got hrtdemo to compile, and the kernel came up with memory is already in use error. I lsmod and the driver is not there. I tried this a few times and no avail. So what I ended up doing is the following: I recompiled the kernel to make sure that plug and play and v4l are both in modules form (for more control). Then reboot. Then I manually inserted the videodev.o and i2c-core.o, and attempted to load hrt.o. Now I get undefined references for two functions: unresolved symbol v4l2_video_std_construct unresolved symbol v4l2_ioctl_names It is possible that the newer v4l2 has a different implementation for these?but upon checking I?m pretty sure everything in my 2.4.26 kernel was patched correctly. But then again I am kind of behind so perhaps I can go and ask someone in class. 15 June 2004 Was able to get the demo program to run but keep facing the seg fault - SDL Parachute Deployed. Am wondering what is up with that. To get rid of the unresolved symbols from last night (or this morning?whatever) I went ahead and commented out wherever there is an instance of v4l2_video_std_construct and v4l2_ioctl_names. At a glance, the ifdefs for HAVE_V4L2 seems almost arbitrary placed throughout the code? Would like to cleanup some part of the code because there is a mishmash of v4l1 and v4l2? So I have two implementations in mind: 1.) Create a separate fops (that I saw in short.c) for the interruptible card, and simply call the regular fops when necessary. 2.) Just alter the original fops functions to check for whether we?re dealing with interrupt devices and if so, perform accordingly. Still pending? 16 June 2004 (0015h-329h) Asked Mark L. about the SDL seg fault, and what a stupid error?I didn?t specify the node from which the video node should work from. SO, WE HAVE AN IMAGE!!! Rather blurry and fuzzy around the edges, but all well? So, plan for the night: There are two ways I can think of in deploying the interrupt config within the code. One of the more appealing way is to do a separate fops specially for handling interrupts, so I wouldn?t have to touch the original code and leave it as it is. If I can get this working by Friday, sweet deal. I wouldn?t mind getting the streaming to work either in this case if I am allowed to work on this next week. But first things first: get it interrupt. ? ok, so the separate fops for interrupt devices is a bit unnecessary, now that I?ve looked over the redundancy and decided that step from the previous log is better. But right now, I don?t want to just forge ahead and implement the handler with all its reading glory. Also, if I can eventually get the v4l2 stuff completely out of the code that?ll be awesome too? Make sure the interrupts are generating fine. What I did was I made a dummy interrupt handler, that all it does it count the amount of times it is called and check against the set time interval (in this case, I attempted to disable the interrupt when it reaches 1 second). If the way I wrote the code is correct, the handler was called approx. 265116 times for 1 second. That looks abnormally large but I have to double check the manual or with other ppl. Also, I am not actually sure as to whether the card sends an interrupt when BOTH fields (even and odd) are in the buffer, or only when one of fields are ready. (Probably already talked about in class?didn?t catch it). I?m just glad that I have some sort of feed, and that the handler *seems* like its working. I set a static int flag for the interrupt setting, and that if the card is not an interrupt device, then we?ll resort to the good old fuzzy kernel timer? One of my concern is that I did not add irq number as a field in the struct of hrt. I remember from led that it seems to be bad to store irq number globally or internally. But another thing is that would mean changing the hrtdev parameters in several other functions, which I?m not ready to do yet. What I?ve done so far is I?ve been calling pci_read_config_byte for functions that don?t have type hrt* lying around as parameters and when I need an irqnum. I have to ask whether that?s ok?I?m pretty sure that in PCI bus, an IRQ number is assigned to it at boot time (the bios assigns it I think). But I?ll double check. Normally I?d stay til 5?but Automated Reasoning final is coming?have to get some sleep for cram time? TODOs: get the handler working? that?ll be nice?