From egs@sunray3.SFBay.Sun.COM Mon Apr 6 16:20:39 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n36NKclL019861 for ; Mon, 6 Apr 2009 16:20:39 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n36NKWxq012260; Tue, 7 Apr 2009 07:20:36 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KHP00M07CUAO900@brm-avmta-1.central.sun.com>; Mon, 06 Apr 2009 17:20:34 -0600 (MDT) Received: from sunray3.SFBay.Sun.COM ([10.6.102.113]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KHP00I3SCU91J20@brm-avmta-1.central.sun.com>; Mon, 06 Apr 2009 17:20:34 -0600 (MDT) Received: from sunray3.SFBay.Sun.COM (localhost [127.0.0.1]) by sunray3.SFBay.Sun.COM (8.13.8+Sun/8.13.8) with ESMTP id n36NKXDn023342; Mon, 06 Apr 2009 16:20:33 -0700 (PDT) Received: (from egs@localhost) by sunray3.SFBay.Sun.COM (8.13.8+Sun/8.13.8/Submit) id n36NKXHD023338; Mon, 06 Apr 2009 16:20:33 -0700 (PDT) Date: Mon, 06 Apr 2009 16:20:33 -0700 (PDT) From: Eric Sultan Subject: visual_io.h ioctl definitions [PSARC/2009/224 FastTrack timeout 04/13/2009] To: PSARC-ext@sun.com Cc: charmaine.lee@sun.com Message-id: <200904062320.n36NKXHD023338@sunray3.SFBay.Sun.COM> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 4348 Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: visual_io.h ioctl definitions 1.2. Name of Document Author/Supplier: Author: Charmaine Lee 1.3 Date of This Document: 06 April, 2009 4. Technical Description I'm sponsoring this case on behalf of Charmaine Lee. This case proposes standard ioctls for graphics devices to replace per-device ioctls to fetch device identification information, to fetch EDID data, to fetch PCI config space data, and to store and retrieve the current video mode name. It also proposes an ioctl to perform I/O space access. These ioctl definitions will be included in /usr/include/sys/visual_io.h. Patch binding is requested. The proposed additions to visual_io.h are: /* * VIS_GETGFXIDENTIFIER: * Return the model name and part number of the device */ #define VIS_GETGFXIDENTIFIER (VIOC | 11) #define VIS_IDENT_VERSION 1 #define VIS_IDENT_MODELNAME 0x01 #define VIS_IDENT_PARTNUM 0x02 #define VIS_MAX_MODELNAME_LEN 36 #define VIS_MAX_PARTNUM_LEN 36 typedef struct vis_gfx_identifier { uint32_t version; uint32_t flags; char model_name[VIS_MAX_MODELNAME_LEN]; char part_number[VIS_MAX_PARTNUM_LEN]; char pad[100]; } vis_gfx_identifier_t; /* * VIS_STOREVIDEOMODENAME: * VIS_GETVIDEOMODENAME: * Notify the driver of the current video mode name. * Returns the current video mode name. */ #define VIS_GETVIDEOMODE (VIOC | 12) #define VIS_SETVIDEOMODE (VIOC | 13) #define VIS_MAX_VMODE_LEN 48 typedef struct vis_video_mode { char mode_name[VIS_MAX_VMODE_LEN]; uint32_t vRefresh; char pad[96]; } vis_video_mode_t; /* * VIS_GETPCICONFIG: * Return the PCI configuration space information */ #define VIS_GETPCICONFIG (VIOC | 14) typedef struct vis_pci_cfg { uint16_t VendorID; uint16_t DeviceID; uint16_t Command; uint16_t Status; uint8_t RevisionID; uint8_t ProgIF; uint8_t SubClass; uint8_t BaseClass; uint8_t CacheLineSize; uint8_t LatencyTimer; uint8_t HeaderType; uint8_t BIST; uint32_t bar[6]; uint32_t CIS; uint16_t SubVendorID; uint16_t SubSystemID; uint32_t ROMBaseAddress; uint8_t CapabilitiesPtr; uint8_t Reserved_1[3]; uint32_t Reserved_2; uint8_t InterruptLine; uint8_t InterruptPin; uint8_t MinimumGrant; uint8_t MaximumLatency; uint8_t pad[100]; } vis_pci_cfg_t; /* * VIS_GETEDIDLENGTH: * Return the size of to-be-returned EDID data * * VIS_GETEDID: * Returns the raw EDID data from the specified display device. The data field * specifies a pointer to a buffer for the data. */ #define VIS_GETEDIDLENGTH (VIOC | 15) #define VIS_GETEDID (VIOC | 16) #define VIS_EDID_VERSION 1 #define VIS_EDID_BLOCK_SIZE 128 #define VIS_EDID_HEAD_ONE 1 #define VIS_EDID_HEAD_TWO 2 #define VIS_EDID_HEAD_THREE 3 #define VIS_EDID_HEAD_FOUR 4 typedef struct vis_edid { uint32_t version; uint32_t head; #ifndef _LP64 uint32_t pad; #endif caddr_t data; /* buffer pointer for EDID data */ uint32_t length; /* length of the buffer. */ } vis_edid_t; /* * VIS_SETIOREG * Writes to an I/O space register * * VIS_GETIOREG: * Reads from an I/O space register */ #define VIS_SETIOREG (VIOC | 17) #define VIS_GETIOREG (VIOC | 18) typedef struct vis_io_reg { uchar_t offset; uchar_t value; } vis_io_reg_t; 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From carlsonj@phorcys.east.sun.com Tue Apr 7 04:35:54 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n37BZrec011749 for ; Tue, 7 Apr 2009 04:35:54 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n37BZklp009840; Tue, 7 Apr 2009 12:35:52 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KHQ00803AVP6H00@brm-avmta-1.central.sun.com>; Tue, 07 Apr 2009 05:35:49 -0600 (MDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KHQ00ETMAVPLJC0@brm-avmta-1.central.sun.com>; Tue, 07 Apr 2009 05:35:49 -0600 (MDT) Received: from phorcys.east.sun.com (phorcys.local [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n37BZPHI002533; Tue, 07 Apr 2009 07:35:25 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n37BZP0I002530; Tue, 07 Apr 2009 07:35:25 -0400 (EDT) Date: Tue, 07 Apr 2009 07:35:25 -0400 From: James Carlson Subject: Re: visual_io.h ioctl definitions [PSARC/2009/224 FastTrack timeout 04/13/2009] In-reply-to: <200904062320.n36NKXHD023338@sunray3.SFBay.Sun.COM> To: Eric Sultan Cc: PSARC-ext@sun.com, Charmaine.Lee@sun.com Message-id: <18907.14973.897275.769521@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200904062320.n36NKXHD023338@sunray3.SFBay.Sun.COM> Status: RO Content-Length: 1135 Eric Sultan writes: > This case proposes standard ioctls for graphics devices to replace > per-device ioctls to fetch device identification information, to fetch > EDID data, to fetch PCI config space data, and to store and retrieve > the current video mode name. It also proposes an ioctl to perform I/O > space access. I'm missing some context here. What per-device ioctls are being replaced? Does this project remove them or are they removed by another project? Does this project also update the Xorg server to use the new ioctls or is there a separate project that depends on these new ioctls? If the latter, then please specify. If neither, then please explain. What privileges are required to invoke the ioctls? Do the I/O register interfaces duplicate what's available through the pcitool (PSARC 2005/232) ioctl interfaces? What's different about these interfaces? What do other platforms do? -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Eric.Sultan@sun.com Tue Apr 7 16:35:43 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n37NZhhf006870 for ; Tue, 7 Apr 2009 16:35:43 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n37NZhxs014258 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 7 Apr 2009 16:35:43 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KHR00C0387JBS00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 07 Apr 2009 16:35:43 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KHR000L287IINE0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 07 Apr 2009 16:35:43 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n37NZgfs015364 for ; Tue, 07 Apr 2009 23:35:42 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KHR00H0084MP200@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 07 Apr 2009 17:35:42 -0600 (MDT) Received: from sunray3.SFBay.Sun.COM ([unknown] [10.6.102.113]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KHR00B7O870RB00@mail-amer.sun.com>; Tue, 07 Apr 2009 17:35:34 -0600 (MDT) Date: Tue, 07 Apr 2009 16:35:24 -0700 From: Eric Sultan Subject: Re: visual_io.h ioctl definitions [PSARC/2009/224 FastTrack timeout 04/13/2009] In-reply-to: <18907.14973.897275.769521@gargle.gargle.HOWL> Sender: Eric.Sultan@sun.com To: James Carlson Cc: Eric Sultan , PSARC-ext@sun.com, Charmaine.Lee@sun.com Reply-to: Eric.Sultan@sun.com Message-id: <49DBE33C.1030506@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200904062320.n36NKXHD023338@sunray3.SFBay.Sun.COM> <18907.14973.897275.769521@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.9 (X11/20080119) Status: RO Content-Length: 3490 On 04/07/09 04:35, James Carlson wrote: > Eric Sultan writes: >> This case proposes standard ioctls for graphics devices to replace >> per-device ioctls to fetch device identification information, to fetch >> EDID data, to fetch PCI config space data, and to store and retrieve >> the current video mode name. It also proposes an ioctl to perform I/O >> space access. > > I'm missing some context here. > > What per-device ioctls are being replaced? Does this project remove > them or are they removed by another project? SPARC graphics projects have traditionally defined Project Private interfaces for some commonly-performed operations such as fetching unparsed EDID data, fetching PCI config space data, and recording video mode names. This proposal does not remove those ioctls, but rather provides standard definitions that could be used across project boundaries for new devices. The previous ioctls wouldn't be removed, though they would become deprecated. Because there is little interest in modifying legacy code, the old ioctls would probably stay in use in the legacy devices. The ioctls to access device I/O space are provided for SPARC processors, which do not implement the inb and outb operations. Those platforms do provide memory-mapped access to I/O space, but that space is not always page-aligned and may not always be mmapable. The I/O access ioctls are limited in scope to the I/O space of the device. > > Does this project also update the Xorg server to use the new ioctls or > is there a separate project that depends on these new ioctls? If the > latter, then please specify. If neither, then please explain. The ioctls are not necessarily bound to X. One of the consumers would be the fbconfig utility, which isn't an X client. Fbconfig would use the new ioctl definitions if the target device supports them, and would fallback to prior device-specific ioctls otherwise. But yes, the relevant ddx code in Xorg would be updated to use these interfaces. For example, the AST ddx module would use these. > > What privileges are required to invoke the ioctls? Read/Write access to the target device is required. The implementation of the ioctls is in the individual device drivers, and so the scope of the potential accesses are the spaces of those devices. This is consistent with the model for all other operations that can read/write device space for SPARC graphics drivers. > > Do the I/O register interfaces duplicate what's available through the > pcitool (PSARC 2005/232) ioctl interfaces? What's different about > these interfaces? The ioctls of this proposal to fetch PCI config space and to access device I/O space are specific to the target devices. The interfaces defined by PSARC 2005/232 don't seem to provide a direct way to access a specified device without navigating through the device tree. The interfaces of this proposal are routed directly to the target device needing only the device name. There does seem to be some overlap. The Consolidation Private interfaces of PSARC 2005/232 seem very generalized but require data (bus number, device number, function number, for example) not readily available to the caller. > > What do other platforms do? > The Xorg code has ioctl support for fetching EDID data, but those ioctls are defined in the context of Xorg and not really intended for non-X clients. The EDID ioctls proposed for visual_io.h are not bound to the context of the X server. -- Eric