Подтвердить что ты не робот

Регистры конфигурации для шины LPC в системном контроллере системы Poulsbo (US15W)

У нас есть система, основанная на плате US15W Q7 от Atom Z510/Intel SCH (под управлением Debian Linux). Нам нужно передать блоки данных с устройства на шине подсчета Low Pin Count. Насколько я знаю, этот чипсет не предоставляет возможности DMA, то есть процессор должен считывать данные из байта за раз в программном цикле. (Драйвер устройства на самом деле реализует это с помощью инструкций x86 "rep insb", поэтому цикл действительно реализуется CPU, если я правильно понимаю.)

Это далеко не оптимально, но должно быть возможно достичь скорости передачи 14 Мбит/с. Вместо этого мы с трудом можем управлять 4 Мбит/с с транзакциями на шине не ближе, чем на 2 раза друг от друга, хотя каждое чтение на подчиненное устройство выполняется в 560 нс. Я не считаю, что другой трафик на автобусе виноват, но я все еще расследую.

Мой вопрос:

Кто-нибудь знает, есть ли какие-либо регистры конфигурации в SCH, которые могут повлиять на синхронизацию шины LPC?

Я не могу найти какую-либо полезную информацию на устройстве на веб-сайте Intel, и я не заметил ничего в коде ядра Linux, который, кажется, возится с любыми такими реестрами (но я - noob, когда он попадает в материал Linux Kernel.)

Я не эксперт x86, поэтому любые другие факторы, которые могли бы вступить в игру, или любые другие "военные истории", относящиеся к этому устройству, было бы полезно узнать и о них.

Изменить: Я нашел datasheet. Я ничего не видел в этом, что объясняет это поведение, но я изучаю возможность сопоставления нашего устройства в качестве прошивки, поскольку циклы микропрограммного обеспечения, похоже, не те же задержки.

4b9b3361

Ответ 1

Для записи решение заключалось в том, чтобы модифицировать прошивку FPGA таким образом, чтобы регистр ввода/вывода данных чипа был сопоставлен с четырьмя соседними адресами, а драйвер модифицирован для выполнения 32-битных инструкций inb/outb. Хотя SCH не реализует 32-разрядные операции чтения/записи LPC, результатом является 4 8-битных операций "назад-назад", за которыми следует одно и то же мертвое время, которое я получал ранее с помощью одного байта, что означает, что он составляет около 1us на байт. Не идеальный, но все же удвоение пропускной способности.

Понятно, что циклы прошивки были быстрее, потому что SCH передает 64 байта за время от прошивки - после 64 байт существует тот же самый разрыв 1.4us, указывая, что это задержка транзакции для каждой транзакции. Использование этого может быть немного быстрее, чем вышеприведенное решение, однако компромисс заключается в том, что он ограничен 64-байтовыми кусками, и каждый байт занимает больше времени (680 нс IIRC) из-за дополнительных циклов, необходимых для чтения прошивки.