Thanks very much for your help, Marc. Adding the xf86SetOperatingState() calls did indeed fix the problem.
--Matt -----Original Message----- From: Marc Aurele La France [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 12, 2005 11:56 AM To: [EMAIL PROTECTED] Cc: devel@XFree86.Org Subject: Re: Memory mapped IO in video drivers On Tue, 12 Jul 2005 [EMAIL PROTECTED] wrote: > I have an xFree86 video driver for a custom gfx board, and am running > into a problem with the memory mapped IO. The display portion of the > driver works just fine, however we are also trying to support I2C/DDC. > The quick explanation of the problem is that the IO address range to > the video registers we need for I2C is getting mapped in and out > multiple times during the X session. Sometimes the registers are > there, other times they aren't (i.e., we read 0xFF for all registers instead of valid data). > The problem occurs with all of the mapped registers, not just the I2C > ones, but the IO space always seems to be mapped in properly during > accelerated drawing functions, it's just when we try to access I2C > through our back door that it is rather unpredictable. > The pointer to the address range itself is not changing, just the > validity of the data. Also, it doesn't appear that the BAR for the IO > registers is being moved. > The registers are being mapped in during ScreenInit with a call to > xf86MapPciMem() with the VIDMEM_MMIO_32BIT flag. Our code to unmap > the registers with xf86UnMapVidMem() doesn't get called until the X > session is closed. > So, is there some part of the XFree86 server that would be mapping and > unmapping the address space behind my back? How can I indicate to the > X server that this memory is non-relocatable and has to be permenant > for the duration of the X session? > Also, I have noticed that the memory mapped IO gets unmapped whenever > I temporarily switch out of the X server to a virtual terminal in VGA > mode, and then the IO gets mapped in again when I switch back to the X > server. I know our driver code for EnterVT() and LeaveVT() isn't > doing this, so where does this happen in the server code? Perhaps it could be a related issue? > This is a multiple board configuration (four monitors, two per board), > so perhaps its not something that has really been tested heavily before? > BTW, if it matters, the video driver is being loaded as a module, not > compiled into the kernel. > Any help or tips here would be appreciated. I have already been > perusing the only XF86 video driver resource I could find at > http://xfree86.activeventure.org/design/DESIGN.html > <http://xfree86.activeventure.org/design/DESIGN.html> . It sounds like your driver isn't sharing VGA properly. For examples, look for calls to xf86SetOperatingState() in other drivers. This function is documented in xc/programs/Xserver/hw/xfree86/RAC.Notes in the source. Marc. +----------------------------------+-----------------------------------+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and | fax: 1-780-492-1729 | | Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +-----------------------------------+ | University of Alberta | | | Edmonton, Alberta | Standard disclaimers apply | | T6G 2H1 | | | CANADA | | +----------------------------------+-----------------------------------+ XFree86 developer and VP. ATI driver and X server internals. - - - - - - - - DISCLAIMER - - - - - - - - Unless indicated otherwise, the information contained in this message is privileged and confidential, and is intended only for the use of the addressee(s) named above and others who have been specifically authorized to receive it. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this message and/or attachments is strictly prohibited. The company accepts no liability for any damage caused by any virus transmitted by this email. Furthermore, the company does not warrant a proper and complete transmission of this information, nor does it accept liability for any delays. If you have received this message in error, please contact the sender and delete the message. Thank you. _______________________________________________ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
