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 creating a new platform device called 'olpc' (The full path would be /sys/devices/platform/olpc/). Granted, this is not really properly a device, and I considered something like /sys/mainboard/olpc/, but I'm not sure how many others would find that useful. No point in creating a main level directory if we're the only ones who are going to use it. Within the device, I propose two entries:
/sys/devices/platform/olpc/revision
Off the bat, I would consider returning a 1 for testA, and a 2 for testB, but that sort of falls down because we know that testB-2 won't require the DCON swizzling we are doing for testB-1, and that is definitely something that X will need to be aware of. So I'm thinking a hex format where bits 4-7 is the board, and bits 0-3 is the revision (i.e. 0x10 = revA, 0x21 = revB-1, 0x22 = revB-2). I suppose we could also go with strings - that has the advantage of being more understandable to the user, but from what I gather, there is a whole movement of folks who frown upon strings in sysfs files.
As mentioned before, X will immediately use this value to determine if it needs to apply the gamma RAM swizzling. This may also be used by applications that need to determine if the CAFE chip is a FPGA or an ASIC.
/sys/devices/platform/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. Output a hex value with each bit corresponding to a feature that is either present or not 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 - its over kill 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.