Я, правда, с LPC2468 не работал, но очень сильно сомневаюсь, что он не позволяет оттяпать всю полосу.
Ищите, где у вас тормоза случаются.

а какова методика поиска?
я пользую кейловский пример для mass storage, выкинул оттуда scsi, оставил только bulk.
В прерывании обрабатываются только control и мои две точки, там выставляются флаги. В основной проге жду флага и начинаю выгребать буфер точки или наоборот наполнять

Сделайте сначала какой-нибудь bulkloop или вообще простейшую "посылалку", посмотрите скорость. Если скорость неудовлетворительная, посмотрите, нет ли тормозов по вине хоста.

А каким образом, или почему хост может тормозить?

Смотреть, есть ли NAK'и. Хост может тормозить по причине кривизны ПО, на нем запущенного.

делал... то же самое
попробую хост посмотреть

какими пакетами (какого размера) лучше обмениваться хосту с девайсом? я пересылаю по 32К (сначала команда, потом блок данных, потом ответ от девайса)

и еще, так никто не ответил... в таком режиме, когда проц, фактически, тупо ждет флага от прерывания и выгребает точку, есть ли смысл пользовать DMA?

А есть ли у этого LPC механизм двойной буферизации?
С тем, чтобы интерфейс по заполнению конечной точки не простаивал, ожидая, пока обработчик прерывания разгребёт точку, а мгновенно переключался на второй буфер?

буфер есть, т.к. в user manual работа с ним описана. А вот есть ли он в реализации кейла... сейчас посмотрю...

там все в порядке. Как и предлагается на стр.386-388 LPC2468 User Manual (rev.04 26.08.2009), при завершении чтения из буфера используется команда CMD_CLR_BUF, при завершении записи - CMD_VALID_BUF
обе команды переключают используемый буфер
если оба буфера не вычищены, аппаратно генерится NAK