Добрый день!

подскажите, где глянуть как организовать параллельную шину посредством gpio выводов.
Желательно в виде драйвера для linux.

Какая максимальная производительность у данного решения. процессор ti-dm3730.

зы. извините, новичок в этом деле

чисто на поиграться, скорость будет никакая..
смотрите в даташите на АРМ подходящее количество свободных пинов в одном банке, идущие подряд - обзываете их (для себя) "шиной"..
настраиваете в режим GPIO и работаете, или через свой драйвер в ядре или из юзерспейса.. грубо говоря, организуете две п/п - чтение и запись

если пины идут не подряд, то придется собирать байт/слово из битов, что заметно скажется на производительности..
лучше присмотреть удобоваримый интерфейс (а-ля канал памяти) из давинчи наружу и забуферизировав, пользоваться всякими плюшками типа ДМА
или смотреть в сторону ФПГА, типа десериализатора - давинчи по SPI в фпга, а оттуда параллельной шиной наружу..


на свободный пин прицепите осцилл и прогой на 10 строк сами все увидите..

Делал для LPC1768, работающего на частоте 100 МГц, без особых ухищрений на С получилось записывать 4 Мегаслова в сек (чтение элемента массива из памяти и запись его в gpio, формирование импульса WR, инкремент указателя массива, и так по циклу). Возможно можно как-то оптимизировать, или написать на асме, вероятно можно увеличить скорость в несколько раз, но мне не нужно было, поэтому не заморачивался.

а толку то - проц только и будет занят этим. Надо аппаратно такое.

Причем тут - это? А когда проц будет писать через внешнюю шину - он небудет "только и занят этим" ?
Да, там - DMA можно задействовать, но это - не во всех случаях.

Я про DMA и говорю, мы же все таки ARM обсуждаем, а не 51-ый

Кому надо? Топикстартеру? Он нигде не писал, что пересылка должна идти постоянно. Скорей всего - это кратковременные транзакции.
Ранее делал что-то подобное - кратковременные пересылки пакета в неск. килобайт. Запрещал прерывания и программно гнал через GPIO.
Выигрыша от DMA в таком режиме не будет - если проц во время такой DMA-пересылки будет выполнять код - будут проблемы с арбитражом шины (если у DMA приоритет доступа ниже чем у CPU), как следствие - замедление работы DMA, следствие - возможные ошибки протокола обмена по этой вашей GPIO-шине.
Я шёл путём оптимизации протокола этой GPIO-шины - после всех оптимизаций у меня на передачу одного слова требовалась одна запись в порт GPIO. При таком алгоритме я передавал весь блок за неск. десятков или сотен микросекунд - это не мешало работе ISR-ов.
Не использовал сигналы синхронизации (типа CS или WR) на каждое слово. Синхронизировал начало пакета, потом просто гнал весь пакет. Предварительно необходимо весь код это выполняющий переместиить в кеш CPU или разместить его в ОЗУ.
Работало в двунаправленном режиме.
Хоть стороны обмена тактировались от разных задающих генераторов, но за время передачи блока частоты не успевали рассинхронизироваться.

Делал в том же проекте вариант с DMA (растягивал по времени, добавлял синхросигналы на каждое слово, фоновое выполнение с кодом) - выигрыша в общей производительности системы не получал.

У процессора кэш и далеко не одна шина, так что выигрыш никуда не денется.

Кеш не бесконечен - значит будут кеш-промахи.
Да, вроде шина не одна, но по факту, из опыта SSP+DMA (LPC1778), SCLK=30МГц, при приоритете доступа к шине CPU выше чем DMA, наблюдал разрывы в аппаратно формируемом SSEL (SSP-мастер).
При установке приоритета DMA выше чем CPU, эти разрывы пропадали. Благо у LPC1778 есть регистр приоритетов арбитража шины.
Писал об этом здесь ранее.

Так "dm3730" процессор, а не простенький LPC1778. Человек писал про шину, а у процессоров обработки потокового видео DMA явно не для мигания гирляндой. С 16 кбайт I-cache выигрыш будет, даже на не очень длинных транзакциях.