Linux kernel mirror (for testing) git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel os linux
at v2.6.15-rc3 570 lines 17 kB view raw
1#ifndef _SMU_H 2#define _SMU_H 3 4/* 5 * Definitions for talking to the SMU chip in newer G5 PowerMacs 6 */ 7 8#include <linux/config.h> 9#include <linux/list.h> 10 11/* 12 * Known SMU commands 13 * 14 * Most of what is below comes from looking at the Open Firmware driver, 15 * though this is still incomplete and could use better documentation here 16 * or there... 17 */ 18 19 20/* 21 * Partition info commands 22 * 23 * These commands are used to retreive the sdb-partition-XX datas from 24 * the SMU. The lenght is always 2. First byte is the subcommand code 25 * and second byte is the partition ID. 26 * 27 * The reply is 6 bytes: 28 * 29 * - 0..1 : partition address 30 * - 2 : a byte containing the partition ID 31 * - 3 : length (maybe other bits are rest of header ?) 32 * 33 * The data must then be obtained with calls to another command: 34 * SMU_CMD_MISC_ee_GET_DATABLOCK_REC (described below). 35 */ 36#define SMU_CMD_PARTITION_COMMAND 0x3e 37#define SMU_CMD_PARTITION_LATEST 0x01 38#define SMU_CMD_PARTITION_BASE 0x02 39#define SMU_CMD_PARTITION_UPDATE 0x03 40 41 42/* 43 * Fan control 44 * 45 * This is a "mux" for fan control commands. The command seem to 46 * act differently based on the number of arguments. With 1 byte 47 * of argument, this seem to be queries for fans status, setpoint, 48 * etc..., while with 0xe arguments, we will set the fans speeds. 49 * 50 * Queries (1 byte arg): 51 * --------------------- 52 * 53 * arg=0x01: read RPM fans status 54 * arg=0x02: read RPM fans setpoint 55 * arg=0x11: read PWM fans status 56 * arg=0x12: read PWM fans setpoint 57 * 58 * the "status" queries return the current speed while the "setpoint" ones 59 * return the programmed/target speed. It _seems_ that the result is a bit 60 * mask in the first byte of active/available fans, followed by 6 words (16 61 * bits) containing the requested speed. 62 * 63 * Setpoint (14 bytes arg): 64 * ------------------------ 65 * 66 * first arg byte is 0 for RPM fans and 0x10 for PWM. Second arg byte is the 67 * mask of fans affected by the command. Followed by 6 words containing the 68 * setpoint value for selected fans in the mask (or 0 if mask value is 0) 69 */ 70#define SMU_CMD_FAN_COMMAND 0x4a 71 72 73/* 74 * Battery access 75 * 76 * Same command number as the PMU, could it be same syntax ? 77 */ 78#define SMU_CMD_BATTERY_COMMAND 0x6f 79#define SMU_CMD_GET_BATTERY_INFO 0x00 80 81/* 82 * Real time clock control 83 * 84 * This is a "mux", first data byte contains the "sub" command. 85 * The "RTC" part of the SMU controls the date, time, powerup 86 * timer, but also a PRAM 87 * 88 * Dates are in BCD format on 7 bytes: 89 * [sec] [min] [hour] [weekday] [month day] [month] [year] 90 * with month being 1 based and year minus 100 91 */ 92#define SMU_CMD_RTC_COMMAND 0x8e 93#define SMU_CMD_RTC_SET_PWRUP_TIMER 0x00 /* i: 7 bytes date */ 94#define SMU_CMD_RTC_GET_PWRUP_TIMER 0x01 /* o: 7 bytes date */ 95#define SMU_CMD_RTC_STOP_PWRUP_TIMER 0x02 96#define SMU_CMD_RTC_SET_PRAM_BYTE_ACC 0x20 /* i: 1 byte (address?) */ 97#define SMU_CMD_RTC_SET_PRAM_AUTOINC 0x21 /* i: 1 byte (data?) */ 98#define SMU_CMD_RTC_SET_PRAM_LO_BYTES 0x22 /* i: 10 bytes */ 99#define SMU_CMD_RTC_SET_PRAM_HI_BYTES 0x23 /* i: 10 bytes */ 100#define SMU_CMD_RTC_GET_PRAM_BYTE 0x28 /* i: 1 bytes (address?) */ 101#define SMU_CMD_RTC_GET_PRAM_LO_BYTES 0x29 /* o: 10 bytes */ 102#define SMU_CMD_RTC_GET_PRAM_HI_BYTES 0x2a /* o: 10 bytes */ 103#define SMU_CMD_RTC_SET_DATETIME 0x80 /* i: 7 bytes date */ 104#define SMU_CMD_RTC_GET_DATETIME 0x81 /* o: 7 bytes date */ 105 106 /* 107 * i2c commands 108 * 109 * To issue an i2c command, first is to send a parameter block to the 110 * the SMU. This is a command of type 0x9a with 9 bytes of header 111 * eventually followed by data for a write: 112 * 113 * 0: bus number (from device-tree usually, SMU has lots of busses !) 114 * 1: transfer type/format (see below) 115 * 2: device address. For combined and combined4 type transfers, this 116 * is the "write" version of the address (bit 0x01 cleared) 117 * 3: subaddress length (0..3) 118 * 4: subaddress byte 0 (or only byte for subaddress length 1) 119 * 5: subaddress byte 1 120 * 6: subaddress byte 2 121 * 7: combined address (device address for combined mode data phase) 122 * 8: data length 123 * 124 * The transfer types are the same good old Apple ones it seems, 125 * that is: 126 * - 0x00: Simple transfer 127 * - 0x01: Subaddress transfer (addr write + data tx, no restart) 128 * - 0x02: Combined transfer (addr write + restart + data tx) 129 * 130 * This is then followed by actual data for a write. 131 * 132 * At this point, the OF driver seems to have a limitation on transfer 133 * sizes of 0xd bytes on reads and 0x5 bytes on writes. I do not know 134 * wether this is just an OF limit due to some temporary buffer size 135 * or if this is an SMU imposed limit. This driver has the same limitation 136 * for now as I use a 0x10 bytes temporary buffer as well 137 * 138 * Once that is completed, a response is expected from the SMU. This is 139 * obtained via a command of type 0x9a with a length of 1 byte containing 140 * 0 as the data byte. OF also fills the rest of the data buffer with 0xff's 141 * though I can't tell yet if this is actually necessary. Once this command 142 * is complete, at this point, all I can tell is what OF does. OF tests 143 * byte 0 of the reply: 144 * - on read, 0xfe or 0xfc : bus is busy, wait (see below) or nak ? 145 * - on read, 0x00 or 0x01 : reply is in buffer (after the byte 0) 146 * - on write, < 0 -> failure (immediate exit) 147 * - else, OF just exists (without error, weird) 148 * 149 * So on read, there is this wait-for-busy thing when getting a 0xfc or 150 * 0xfe result. OF does a loop of up to 64 retries, waiting 20ms and 151 * doing the above again until either the retries expire or the result 152 * is no longer 0xfe or 0xfc 153 * 154 * The Darwin I2C driver is less subtle though. On any non-success status 155 * from the response command, it waits 5ms and tries again up to 20 times, 156 * it doesn't differenciate between fatal errors or "busy" status. 157 * 158 * This driver provides an asynchronous paramblock based i2c command 159 * interface to be used either directly by low level code or by a higher 160 * level driver interfacing to the linux i2c layer. The current 161 * implementation of this relies on working timers & timer interrupts 162 * though, so be careful of calling context for now. This may be "fixed" 163 * in the future by adding a polling facility. 164 */ 165#define SMU_CMD_I2C_COMMAND 0x9a 166 /* transfer types */ 167#define SMU_I2C_TRANSFER_SIMPLE 0x00 168#define SMU_I2C_TRANSFER_STDSUB 0x01 169#define SMU_I2C_TRANSFER_COMBINED 0x02 170 171/* 172 * Power supply control 173 * 174 * The "sub" command is an ASCII string in the data, the 175 * data lenght is that of the string. 176 * 177 * The VSLEW command can be used to get or set the voltage slewing. 178 * - lenght 5 (only "VSLEW") : it returns "DONE" and 3 bytes of 179 * reply at data offset 6, 7 and 8. 180 * - lenght 8 ("VSLEWxyz") has 3 additional bytes appended, and is 181 * used to set the voltage slewing point. The SMU replies with "DONE" 182 * I yet have to figure out their exact meaning of those 3 bytes in 183 * both cases. They seem to be: 184 * x = processor mask 185 * y = op. point index 186 * z = processor freq. step index 187 * I haven't yet decyphered result codes 188 * 189 */ 190#define SMU_CMD_POWER_COMMAND 0xaa 191#define SMU_CMD_POWER_RESTART "RESTART" 192#define SMU_CMD_POWER_SHUTDOWN "SHUTDOWN" 193#define SMU_CMD_POWER_VOLTAGE_SLEW "VSLEW" 194 195/* 196 * Read ADC sensors 197 * 198 * This command takes one byte of parameter: the sensor ID (or "reg" 199 * value in the device-tree) and returns a 16 bits value 200 */ 201#define SMU_CMD_READ_ADC 0xd8 202 203/* Misc commands 204 * 205 * This command seem to be a grab bag of various things 206 */ 207#define SMU_CMD_MISC_df_COMMAND 0xdf 208#define SMU_CMD_MISC_df_SET_DISPLAY_LIT 0x02 /* i: 1 byte */ 209#define SMU_CMD_MISC_df_NMI_OPTION 0x04 210 211/* 212 * Version info commands 213 * 214 * I haven't quite tried to figure out how these work 215 */ 216#define SMU_CMD_VERSION_COMMAND 0xea 217 218 219/* 220 * Misc commands 221 * 222 * This command seem to be a grab bag of various things 223 * 224 * SMU_CMD_MISC_ee_GET_DATABLOCK_REC is used, among others, to 225 * transfer blocks of data from the SMU. So far, I've decrypted it's 226 * usage to retreive partition data. In order to do that, you have to 227 * break your transfer in "chunks" since that command cannot transfer 228 * more than a chunk at a time. The chunk size used by OF is 0xe bytes, 229 * but it seems that the darwin driver will let you do 0x1e bytes if 230 * your "PMU" version is >= 0x30. You can get the "PMU" version apparently 231 * either in the last 16 bits of property "smu-version-pmu" or as the 16 232 * bytes at offset 1 of "smu-version-info" 233 * 234 * For each chunk, the command takes 7 bytes of arguments: 235 * byte 0: subcommand code (0x02) 236 * byte 1: 0x04 (always, I don't know what it means, maybe the address 237 * space to use or some other nicety. It's hard coded in OF) 238 * byte 2..5: SMU address of the chunk (big endian 32 bits) 239 * byte 6: size to transfer (up to max chunk size) 240 * 241 * The data is returned directly 242 */ 243#define SMU_CMD_MISC_ee_COMMAND 0xee 244#define SMU_CMD_MISC_ee_GET_DATABLOCK_REC 0x02 245#define SMU_CMD_MISC_ee_LEDS_CTRL 0x04 /* i: 00 (00,01) [00] */ 246#define SMU_CMD_MISC_ee_GET_DATA 0x05 /* i: 00 , o: ?? */ 247 248 249 250/* 251 * - Kernel side interface - 252 */ 253 254#ifdef __KERNEL__ 255 256/* 257 * Asynchronous SMU commands 258 * 259 * Fill up this structure and submit it via smu_queue_command(), 260 * and get notified by the optional done() callback, or because 261 * status becomes != 1 262 */ 263 264struct smu_cmd; 265 266struct smu_cmd 267{ 268 /* public */ 269 u8 cmd; /* command */ 270 int data_len; /* data len */ 271 int reply_len; /* reply len */ 272 void *data_buf; /* data buffer */ 273 void *reply_buf; /* reply buffer */ 274 int status; /* command status */ 275 void (*done)(struct smu_cmd *cmd, void *misc); 276 void *misc; 277 278 /* private */ 279 struct list_head link; 280}; 281 282/* 283 * Queues an SMU command, all fields have to be initialized 284 */ 285extern int smu_queue_cmd(struct smu_cmd *cmd); 286 287/* 288 * Simple command wrapper. This structure embeds a small buffer 289 * to ease sending simple SMU commands from the stack 290 */ 291struct smu_simple_cmd 292{ 293 struct smu_cmd cmd; 294 u8 buffer[16]; 295}; 296 297/* 298 * Queues a simple command. All fields will be initialized by that 299 * function 300 */ 301extern int smu_queue_simple(struct smu_simple_cmd *scmd, u8 command, 302 unsigned int data_len, 303 void (*done)(struct smu_cmd *cmd, void *misc), 304 void *misc, 305 ...); 306 307/* 308 * Completion helper. Pass it to smu_queue_simple or as 'done' 309 * member to smu_queue_cmd, it will call complete() on the struct 310 * completion passed in the "misc" argument 311 */ 312extern void smu_done_complete(struct smu_cmd *cmd, void *misc); 313 314/* 315 * Synchronous helpers. Will spin-wait for completion of a command 316 */ 317extern void smu_spinwait_cmd(struct smu_cmd *cmd); 318 319static inline void smu_spinwait_simple(struct smu_simple_cmd *scmd) 320{ 321 smu_spinwait_cmd(&scmd->cmd); 322} 323 324/* 325 * Poll routine to call if blocked with irqs off 326 */ 327extern void smu_poll(void); 328 329 330/* 331 * Init routine, presence check.... 332 */ 333extern int smu_init(void); 334extern int smu_present(void); 335struct of_device; 336extern struct of_device *smu_get_ofdev(void); 337 338 339/* 340 * Common command wrappers 341 */ 342extern void smu_shutdown(void); 343extern void smu_restart(void); 344struct rtc_time; 345extern int smu_get_rtc_time(struct rtc_time *time, int spinwait); 346extern int smu_set_rtc_time(struct rtc_time *time, int spinwait); 347 348/* 349 * SMU command buffer absolute address, exported by pmac_setup, 350 * this is allocated very early during boot. 351 */ 352extern unsigned long smu_cmdbuf_abs; 353 354 355/* 356 * Kenrel asynchronous i2c interface 357 */ 358 359/* SMU i2c header, exactly matches i2c header on wire */ 360struct smu_i2c_param 361{ 362 u8 bus; /* SMU bus ID (from device tree) */ 363 u8 type; /* i2c transfer type */ 364 u8 devaddr; /* device address (includes direction) */ 365 u8 sublen; /* subaddress length */ 366 u8 subaddr[3]; /* subaddress */ 367 u8 caddr; /* combined address, filled by SMU driver */ 368 u8 datalen; /* length of transfer */ 369 u8 data[7]; /* data */ 370}; 371 372#define SMU_I2C_READ_MAX 0x0d 373#define SMU_I2C_WRITE_MAX 0x05 374 375struct smu_i2c_cmd 376{ 377 /* public */ 378 struct smu_i2c_param info; 379 void (*done)(struct smu_i2c_cmd *cmd, void *misc); 380 void *misc; 381 int status; /* 1 = pending, 0 = ok, <0 = fail */ 382 383 /* private */ 384 struct smu_cmd scmd; 385 int read; 386 int stage; 387 int retries; 388 u8 pdata[0x10]; 389 struct list_head link; 390}; 391 392/* 393 * Call this to queue an i2c command to the SMU. You must fill info, 394 * including info.data for a write, done and misc. 395 * For now, no polling interface is provided so you have to use completion 396 * callback. 397 */ 398extern int smu_queue_i2c(struct smu_i2c_cmd *cmd); 399 400 401#endif /* __KERNEL__ */ 402 403 404/* 405 * - SMU "sdb" partitions informations - 406 */ 407 408 409/* 410 * Partition header format 411 */ 412struct smu_sdbp_header { 413 __u8 id; 414 __u8 len; 415 __u8 version; 416 __u8 flags; 417}; 418 419 420 /* 421 * demangle 16 and 32 bits integer in some SMU partitions 422 * (currently, afaik, this concerns only the FVT partition 423 * (0x12) 424 */ 425#define SMU_U16_MIX(x) le16_to_cpu(x); 426#define SMU_U32_MIX(x) ((((x) & 0xff00ff00u) >> 8)|(((x) & 0x00ff00ffu) << 8)) 427 428 429/* This is the definition of the SMU sdb-partition-0x12 table (called 430 * CPU F/V/T operating points in Darwin). The definition for all those 431 * SMU tables should be moved to some separate file 432 */ 433#define SMU_SDB_FVT_ID 0x12 434 435struct smu_sdbp_fvt { 436 __u32 sysclk; /* Base SysClk frequency in Hz for 437 * this operating point. Value need to 438 * be unmixed with SMU_U32_MIX() 439 */ 440 __u8 pad; 441 __u8 maxtemp; /* Max temp. supported by this 442 * operating point 443 */ 444 445 __u16 volts[3]; /* CPU core voltage for the 3 446 * PowerTune modes, a mode with 447 * 0V = not supported. Value need 448 * to be unmixed with SMU_U16_MIX() 449 */ 450}; 451 452/* This partition contains voltage & current sensor calibration 453 * informations 454 */ 455#define SMU_SDB_CPUVCP_ID 0x21 456 457struct smu_sdbp_cpuvcp { 458 __u16 volt_scale; /* u4.12 fixed point */ 459 __s16 volt_offset; /* s4.12 fixed point */ 460 __u16 curr_scale; /* u4.12 fixed point */ 461 __s16 curr_offset; /* s4.12 fixed point */ 462 __s32 power_quads[3]; /* s4.28 fixed point */ 463}; 464 465/* This partition contains CPU thermal diode calibration 466 */ 467#define SMU_SDB_CPUDIODE_ID 0x18 468 469struct smu_sdbp_cpudiode { 470 __u16 m_value; /* u1.15 fixed point */ 471 __s16 b_value; /* s10.6 fixed point */ 472 473}; 474 475/* This partition contains Slots power calibration 476 */ 477#define SMU_SDB_SLOTSPOW_ID 0x78 478 479struct smu_sdbp_slotspow { 480 __u16 pow_scale; /* u4.12 fixed point */ 481 __s16 pow_offset; /* s4.12 fixed point */ 482}; 483 484/* This partition contains machine specific version information about 485 * the sensor/control layout 486 */ 487#define SMU_SDB_SENSORTREE_ID 0x25 488 489struct smu_sdbp_sensortree { 490 u8 model_id; 491 u8 unknown[3]; 492}; 493 494/* This partition contains CPU thermal control PID informations. So far 495 * only single CPU machines have been seen with an SMU, so we assume this 496 * carries only informations for those 497 */ 498#define SMU_SDB_CPUPIDDATA_ID 0x17 499 500struct smu_sdbp_cpupiddata { 501 u8 unknown1; 502 u8 target_temp_delta; 503 u8 unknown2; 504 u8 history_len; 505 s16 power_adj; 506 u16 max_power; 507 s32 gp,gr,gd; 508}; 509 510 511/* Other partitions without known structures */ 512#define SMU_SDB_DEBUG_SWITCHES_ID 0x05 513 514#ifdef __KERNEL__ 515/* 516 * This returns the pointer to an SMU "sdb" partition data or NULL 517 * if not found. The data format is described below 518 */ 519extern struct smu_sdbp_header *smu_get_sdb_partition(int id, 520 unsigned int *size); 521 522#endif /* __KERNEL__ */ 523 524 525/* 526 * - Userland interface - 527 */ 528 529/* 530 * A given instance of the device can be configured for 2 different 531 * things at the moment: 532 * 533 * - sending SMU commands (default at open() time) 534 * - receiving SMU events (not yet implemented) 535 * 536 * Commands are written with write() of a command block. They can be 537 * "driver" commands (for example to switch to event reception mode) 538 * or real SMU commands. They are made of a header followed by command 539 * data if any. 540 * 541 * For SMU commands (not for driver commands), you can then read() back 542 * a reply. The reader will be blocked or not depending on how the device 543 * file is opened. poll() isn't implemented yet. The reply will consist 544 * of a header as well, followed by the reply data if any. You should 545 * always provide a buffer large enough for the maximum reply data, I 546 * recommand one page. 547 * 548 * It is illegal to send SMU commands through a file descriptor configured 549 * for events reception 550 * 551 */ 552struct smu_user_cmd_hdr 553{ 554 __u32 cmdtype; 555#define SMU_CMDTYPE_SMU 0 /* SMU command */ 556#define SMU_CMDTYPE_WANTS_EVENTS 1 /* switch fd to events mode */ 557#define SMU_CMDTYPE_GET_PARTITION 2 /* retreive an sdb partition */ 558 559 __u8 cmd; /* SMU command byte */ 560 __u8 pad[3]; /* padding */ 561 __u32 data_len; /* Lenght of data following */ 562}; 563 564struct smu_user_reply_hdr 565{ 566 __u32 status; /* Command status */ 567 __u32 reply_len; /* Lenght of data follwing */ 568}; 569 570#endif /* _SMU_H */