Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI
This information is Copyright 2009 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
IC2/SMBus supplement to DDC/CI
1.2. Name of Document Author/Supplier:
Author: John Martin
1.3 Date of This Document:
19 October, 2009
4. Technical Description
PSARC/2007/695, Display Data Channel Command Interface (DDC/CI) ioctls,
provides an interface for devices which support DDC/CI on an I2C bus.
As noted in the case materials, DDC/CI is useful in combination with
EDID to uniquely identify the device and its capabilities. This case
supplements PSARC/2007/695 with a more generic I2C interface that allows
access to both DDC/CI and EDID, plus optionally other devices as well.
Issues addressed by this supplement:
------------------------------------
1. Access to EDID and other functions. The original case makes reference
to using EDID to obtain information such as the monitor model and
serial number, but only specified DDC/CI access methods which reside
at I2C bus address 0x37. EDID pages reside at I2C bus address 0x50.
This case allows specifying the I2C bus address, which provides an
single interface for DDC/CI, EDID and other I2C bus operations.
2. Guaranteed command sequences. Some operations may require a
sequence of commands, for example a command write to select a page
followed by a read. If multiple clients access the driver at the
same time, there no guarantee the ioctls from mutiple clients don't
interleave. This case allows submission of command sequences.
The implementation guarantees the command sequences are delivered
to the device without effect from other clients.
3. Better control over timing. I2C devices have a minimum idle
time requirement between commands. In addition some devices have
a maximum time between the receipt of command and the subsequent
request for a data transfer. The original case makes the clients
responsible for handling the timing. This case moves the timing
requirements to the implementation.
4. SMBus operations. Some operations on third party devices
support some of the protocols listed in section 7.5 of the SMBus 1.1
specification. This case allows the implementation to define which
protocols, if any, are implemented by the master. For reference,
the 1.1 spec is available at http://smbus.org/specs/smbus110.pdf.
Delivery:
---------
This case adds the following ioctls and assocated structures
to visual_io.h. There is no intent to obsolete or remove the
interfaces added in the original case.
#define VIS_I2C_CAPS (('V' << 8) | 23)
#define VIS_I2C_CMDS (('V' << 8) | 24)
struct vis_i2c_caps {
uint32_t bus_count;
uint32_t flags;
uint32_t max_cmds;
uint32_t max_cmd_buffer_size;
};
#define VIS_I2C_TENBIT_ADDR 0x00000001
#define VIS_I2C_READ 0x00000002
#define VIS_I2C_WRITE 0x00000004
#define VIS_I2C_SMBUS_TENBIT_ADDR 0x00000010
#define VIS_I2C_SMBUS_QUICK_READ 0x00000020
#define VIS_I2C_SMBUS_QUICK_WRITE 0x00000040
#define VIS_I2C_SMBUS_BYTE_READ 0x00000080
#define VIS_I2C_SMBUS_BYTE_WRITE 0x00000100
#define VIS_I2C_SMBUS_BYTE_BLOCK_READ 0x00000200
#define VIS_I2C_SMBUS_BYTE_BLOCK_WRITE 0x00000400
#define VIS_I2C_SMBUS_SHORT_BLOCK_READ 0x00000800
#define VIS_I2C_SMBUS_SHORT_BLOCK_WRITE 0x00001000
VIS_I2C_CAPS fills the structure vis_i2c_caps. The element
bus_count contains the number of I2C buses on the card,
enumerated 0..(bus_count-1). The element flags is a mask
of the above capabilities for the I2C/SMBUS masters on the
graphics card and/or the capabilites supported by the implementation.
It does not define the capabilities of all the slave devices on each bus.
The element max_cmds defines the maximum number of commands which
the implementation can handle for a single VIS_I2C_CMDS request.
The element max_cmd_buffer_size is the maximum buffer (vis_i2c_cmd.buffer)
size for a single command supported by the implementation.
struct vis_i2c_cmd {
uint32_t bus; /* I2C bus number */
uint32_t addr; /* I2C bus address */
uint32_t command; /* SMBus command */
uint32_t flags; /* vis_i2c_caps.flags */
int32_t length;
int32_t pad; /* mbz */
caddr_t buffer;
};
struct vis_i2c_cmd_list {
uint32_t count;
struct vis_i2c_cmd *cmd_list;
};
VIS_I2C_CMDS submits a non-zero length list of commands to
be executed on one or more I2C buses. vis_i2c_cmd_list.count
is the number of vis_i2c_cmd structures pointed to by
vis_i2c_cmd_list.cmd_list. Each vis_i2c_cmd request is
handled sequentially without interference from any other client
request.
Each vis_i2c_cmd structure defines an operation to be performed
on an I2C bus. The element bus defines the I2C bus number on
the card, enumerated 0..(vis_i2c_caps.bus_count-). The element
addr defines the I2C address on the bus, for example, 0x50 for
EDID and 0x37 for DDC/CI. The element command is the command
data for certain SMBUS operations. The element flags defines
the requested operation. For example, (VIS_I2C_READ |
VIS_I2C_TENBIT_ADDR) would request a read from the I2C bus with
a 10 bit address. The element length defines the size in bytes
of the data pointed to by the element buffer, if needed.
In case of failure, this case does not define a completion/error
status for each vis_i2c_cmd. For debugging, the failing vis_i2c_cmd
can be determined by submitting the commands one at a time.
6. Resources and Schedule
6.4. Steering Committee requested information
6.4.1. Consolidation C-team Name:
X
6.5. ARC review type: FastTrack
6.6. ARC Exposure: open
