请教82 83 CMD 的真正作用. 看不懂ACPI SPEC的描述!

smile__xu 发表于 2008-10-21 15:32:34

清高人指点一下:
82h EC Burst Enable Enable EC operation in burst mode
83h EC Burst Disable Disable EC operation in burst mode

这两个命令倒是是在什么时候发的, 具体的作用是什么啊!
万分感谢!!

david 发表于 2008-10-21 16:23:13

In burst mode, embedded controller has received the burst enable command from the host, has halted normal processing, and is waiting for a series of commands to be sent from the host. this allows OSPM or system management handler to quickly read and write several bytes of data at a time without the overhead of SCIs between the commands.
一般情况下, OSPM与EC通信均是通过SCIs事件方式(interrupt-driven command processing)来完成, 但当在需要传输比较多数据时, 如SMBus Block 的大量数据传输时, OSPM可以发送 Bust Enable Command 请求EC进入burst Mode, 在此模式下, EC将中止正常的其它处理, 只处理与 OSPM 进行的全速的读/写操作, 此时, 不再是以SCIs事件来触发每一次的读写,而是查询方式(polled command processing)进行, 但这样处理不能超过 1ms:
• First Access – 400 microseconds
• Subsequent Accesses – 50 microseconds each
• Total Burst Time – 1 millisecond
当EC在收到 OSPM 发送的 Bust Disable Command 后, 则结束 Burst mode.

smile__xu 发表于 2008-10-21 16:27:52

尽管还是看不大懂. 不过还是明白了一些.感谢感谢, david 大哥了

david 发表于 2008-10-21 17:40:00

:), 好吧! 取个例子好了:

如果OSPM 想一次写入 EC SPACE 0x20-0x3F共32Byte, 那OSPM将连续发送32次 Writ Command, EC 被触发了 32*3 = 96次中断，才能全部写完，
Write Command (3 Bytes)
Byte #1 (Command byte Header)    Interrupt on IBF=0
Byte #2 (Address byte to write)       Interrupt on IBF=0
Byte #3 (Data to read )                   Interrupt on IBF=0

这种连续的中断，效率反而会非常地低，访问的时间会变得比较长，但如果在这种连续地传输过程中不使用中断，而是查询方式全速向EC写，那速度上肯定会远远快于EC不停地被IBF=0中断触发，burst mode就是在这样的情况下使用的．
当然，这是一个比较极端的情况了，可如果你设计为通过 EC Smubs Controller 的方式来访问其下的设备，如电池，还是会有机会出现一次访问多个的情况，比如读取一个DWORD，读入OEM STRING等等，这些都不能通过一次R/W Cmd就可以访问的．

daway 发表于 2009-1-14 12:59:09

非常感谢！
受益非浅！

蓝色永恒 发表于 2009-1-15 13:57:26

回复 4# 的帖子

你好,我看到ACPI里有提到
While in burst mode, the embedded controller follows these guidelines for OSPM driver:
SCIs are generated as normal, including IBF=0 and OBF=1.
Accesses should be responded to within 50 microseconds.
它也在正常产生SCI 啊，也就是说HOST 发命令或数据或读数据还是会引起SCI 啊，并非查询方式(polled command processing)进行，这是怎么回事？
请指教，谢谢

蓝色永恒 发表于 2009-1-15 15:31:01

回复 2# 的帖子

你好，请问ACPI中：
      This implies that a system management handler uses commands that parallel the functionality of all the commands for ACPI including query, read, write, and any other implemented specific commands.
上边这句话可不可以这样理解：对于shared EC Interface ，SMIhandler 环境下，也可以使用 ACPI所定义的80-84 Command 吗？
   如果可以这样理解的话，是不是说在 SMIhandler环境下也可以读，写 EC space了，用的是不是 80，81，82，83，84command 这些命令?
那么当在读或写时引起IBF=0,OBF=1,产生什么中断? 是 SCI吗？如果是，在这个环境下由谁来处理这个中断？

对于80，81 commad ACPI 里有提到： This command byte allows OSPM to read a byte in the address space of the embedded controller. This command byte is reserved for exclusive use by OSPM, and it indicates to the embedded controller to generate SCIs in response to related transactions (that is, IBF=0 or OBF=1 in the EC Status Register), rather than SMIs.
      这句话是不是说80，81 commad是 OSPM环境专用的吗？在IBF=0,OBF=1的时候产生SCI,而不是SMI,那么在上面的 SMI handler环境下，怎么可以使用80（读）,81（写）命令？
是不是每一个环境（OSPM 或 SMI handler）各有一套读写，查询的 command sets啊？
谢谢~

[ 本帖最后由蓝色永恒于 2009-1-15 15:43 编辑 ]

heden 发表于 2009-3-11 16:15:31

回复 7# 蓝色永恒的帖子

it's decided by EC.
if EC not judge the os is in OSPM or SMI handler, when it received the 80, 81 commands, it executed always.
in SMI handler, EC executed 80, 81 commands as usual and generated a SCI.
but the bios not configure the SCI in SB, SCI lost. no other function.

iabbg 发表于 2009-4-16 15:58:44

回复 8# heden 的帖子

多谢！你的意思让我大致明白了，也就是说EC只管接收来自HOST的COMMAND，然后做对应的动作了，而不去区分是谁发的啦！:D

cgz7802 发表于 2009-9-21 10:14:19

了解,谢谢
:handshake

jhq296296 发表于 2009-9-21 22:10:12

回复 4# david 的帖子

david 大侠好，小弟在理解0X80，0X81也没有搞懂，麻烦一起解析下，谢谢！

页: [1]

计匠网论坛's Archiver