On Tue, Jun 17, 2003 at 04:12:32PM -0300, Maximo wrote: > At 02:31 PM 17/6/2003, you wrote: > >> Reading the archives I notice that Andreas was working on "wait > >> for idle". Do you know if he finished that? What should be the next step? > > > >Since savage_bci.c doesn't have it, I conclude he didn't. IIRC what > >Andreas said at the time, the problem is that this function depends on > >the actual version of the Savage chipset family, so it's not a simple > >cut'n'paste from the XFree86 2D driver. > > > >After that, the next step would be create a function to write a buffer > >to the BCI and the respective ioctl (to be called by the libGL driver > >or, first, a test program). > > I asked if "wait for idle" was finished because i found this > function on savage_bci.c " > int savage_do_bci_idle( drm_savage_private_t *dev_priv )" and i thought it > was the wait for idle thing. Am I wrong? > > > >> I think you already noticed but i'm not really familiar with all > >> these terms like: MMIO, PIO, SEARS etc. I already read the faq but i > >think > >> i didn't get the whole idea. I would really appreciate if you could > >give me > >> some help with that. > > > >Have you noticed the explanations in the FAQ?: > > > > http://dri.sourceforge.net/doc/faq/glossary.html#MMIO-TERM > > http://dri.sourceforge.net/doc/faq/glossary.html#PIO-TERM > > http://dri.sourceforge.net/doc/faq/architecture.html#SAREA-DEFINITION > > > >They may not be totally clear. (*) Tell me if you'r still not completely > >enlightened about them or what other terms are confusing. > > > > > >José Fonseca > > I already read the glossary but what i wanted to know is how the > interact with each other and what kind of information do they deal with. I > don't really understand them and I may saying stupid things :).
I understand that you're not familiar with low level programming, but to further explain things like MMIO or PIO starts to get quite off-topic here. Unfortunatly I don't know any good web resource which covers topics such as computer architecture or low-level programming. I searched some for you and these are some which I found interesting (by order of appearence ;): http://kernelnewbies.org/links/ http://kernelnewbies.org/glossary/ http://cdsmith.twu.net/professional/osdesign.html You may find chapter 3 of the last link most interesting. This next one is probably too much techical but I found it very interesting so I leave here for future reference: http://www.nondot.org/sabre/os/articles Now some more toughts on your questions. At least these concepts you mention above (MMIO, PIO, SAREA) don't interact much - they are mostly communication purposes. Using an analogy, your telephone radio, and your television don't interact - you either use one, the other, or a combination depending of your objective at the moment and what you have available. The same goes for these. PIO is the most low-level way to communicate with a hardware device. It (would) consist of statments such as outl(port, dword); The _compiler_ will translate that into the assembly "out port, dword". MMIO is just like the above, but trhough memory-maps. unsigned long *mmio_start = ....; mmio_start[port] = dword. The _processor_ will translate in the same thing as above. MMIO gives some advantages over PIO, so it's usually preferred. DMA is an indirect way to programm the card: using PIO or MMIO you tell the hardware to read _more_ commands and/or data from a certain position in memory. SAREA is _not_ a hardware communication interface. Is a way to share information with the three parts that make a complete driver (the DRM module, the XFree 2D driver and libGL driver). It holds stuff such as the windows cliprects (used for window clipping) or acts as a proxy of the hardware state, i.e., holds the last known values of the hardware registers. A driver can put there (mostly?) anything it wants. The quest for maximum efficient (and at least within the DRI project, without damaging security) will dictate how one uses all these paradigms in a driver. José Fonseca ------------------------------------------------------- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
