User:JordanCrouse/OLPC Sysfs Interface (Proposal): Difference between revisions
JordanCrouse (talk | contribs) No edit summary |
JordanCrouse (talk | contribs) No edit summary |
||
| Line 2: | Line 2: | ||
mercilessly. |
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 |
|||
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. |
|||
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 |
|||
: ''Andres proposed something like /sys/devices/system/mainboard/ - I like it and I have added them to the headers below for comparison.'' |
|||
could read the EEPOM and make the board information available via an file in /sys/mainboard. |
|||
:: ''Other possibilities: /sys/olpc (too presumptuous?) or /sys/mainboard'' |
|||
For OLPC, I propose two entries within the /sys/mainboard interface: |
|||
== /sys |
== /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: |
|||
<strike>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.</strike> I've thought about it, and I think I'm going to go with strings after all. "ATest", "BTest-1", etc are so much more usable then just plain numbers. |
|||
{| border="1" |
|||
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 |
|||
| A1 || A-Test |
|||
is a FPGA or an ASIC. |
|||
|- |
|||
| 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 |
|||
== /sys/devices/platform/olpc/features ''(/sys/devices/system/mainboard/olpc_features)''== |
|||
complete manufacturing data regions, so we can read the revision directly. |
|||
| ⚫ | |||
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 |
|||
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 |
||
| ⚫ | |||
be nice. If that was the case, then the map could look something like this: |
be nice. If that was the case, then the map could look something like this: |
||
Latest revision as of 22:30, 15 November 2006
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.