User:JordanCrouse/OLPC Sysfs Interface (Proposal)
The following is a possible layout for a platform device that communicates the current revision and features of the OLPC platform to userland. This will be mainly used by X to determine which workarounds (if any) should be used for the OLPC platform. Note that this is only a proposal in wiki format - this has yet to gain any sort of official momentum and will probably be edited mercilessly.
I propose adding a new toplevel directory in /sys called 'mainboard'. This would be a repository for information about the motherboard that wouldn't be part of a device driver. For an example, consider a motherboard which uses a tiny smbus attached EEPROM to store manufacturing information. Such a device wouldn't normally rate a driver of its own, but a kernel entity could read the EEPOM and make the board information available via an file in /sys/mainboard.
For OLPC, I propose two entries within the /sys/mainboard interface:
/sys/mainboard/olpc_revision
A text string indicating the revision of the current OLPC board. This file outputs the a string indicating the current board revision. The following strings are proposed:
| A1 | A-Test |
| B0 | Pre B-Test (developers boards) |
| B1 | B-Test-1 (November 2006 build) |
The A1 and B0 boards do not have a complete manufacturing data area, so we must infer the board revision by checking the version of the embedded controller. B1 and newer will have complete manufacturing data regions, so we can read the revision directly.
The first consumer of this file will be the X driver which will test for the presence of the /sys/mainboard/olpc_revision file to determine if OLPC extensions are needed, and read the value to determine what revision specific workarounds are needed.
/sys/mainboard/olpc_features
We could create a different sysfs file with a boolean 0 or 1 for the DCON, CAFE, and other features on the board, but I figured this would be easier. We will output a hex value with each bit corresponding to a feature available on the board. Some of these will be static, others will be dynamically calculated at boot time. I'm not sure if we should define the individual CAFE devices or not - it is overkill now, but if we decide to de-feature something in the future (or add additional features in a further revision), then having each device defined individually would be nice. If that was the case, then the map could look something like this:
| Bit | Feature |
|---|---|
| 0 | DCON |
| 1 | CAFE NAND |
| 2 | CAFE SD |
| 3 | CAFE Camera |
Bits 1-3 would be statically assigned based on board revision, and bit 0 would be set based on the value of the CMOS bit. So the typical values would be:
| Board | Value |
|---|---|
| testA | 0x00 |
| testA+DCON | 0x01 |
| preB | 0x0E |
| testB | 0x0F |
X would immediately use this to determine if a DCON is attached, and if so, to enable the special panel timings and possible gamma swizzling (see above), thereby removing the horrible configuration hacks we have in place right now.