kernel, sound/alsa использовать для данных - потыкайте мне

Зачем?

Зачем?

Для McBSP (синхронный последовательный порт) на DaVinci и OMAP-Lх есть только «звуковые» драйверы (http://lxr.free-electrons.com/source/Documentation/sound/alsa/soc/DAI.txt).

Вариант использования sound-api избавляет от необходимости корячить свои не-звуковые драйвера из звуковых, плюс получается «совместимость» с большинством актуальных SoC.

Вариант использования sound-api избавляет от необходимости корячить свои не-звуковые драйвера из звуковых, плюс получается «совместимость» с большинством актуальных SoC.

Наркоман со стажем, в большинстве SoC есть EMAC.

Наркоман со стажем, в большинстве SoC есть EMAC.

;)

Да, но MII дальше не в тему... Короче, нужен серийный синхронный порт, точнее даже два.

Короче, нужен серийный синхронный порт, точнее даже два

McBSP - универсальный порт, его можно использовать как обычный SPI, это все описано в техасовских доках. Ты видимо не представляешь как работает звук с SoC - по I2C или SPI процессор с внешним кодеком договариаются о типе протокола, о том кто из них мастер а кто слэйв для битклока и фреймов. Как ты это представляешь для двух устройств реализовывать в рамках высокоуровневого API ALSA ?

McBSP - универсальный порт, его можно использовать как обычный SPI, это все описано в техасовских доках. Ты видимо не представляешь как работает звук с SoC - по I2C или SPI процессор с внешним кодеком договариаются о типе протокола, о том кто из них мастер а кто слэйв для битклока и фреймов. Как ты это представляешь для двух устройств реализовывать в рамках высокоуровневого API ALSA ?

С McBSP/McASP относительная беда, потому что есть примерно три «немного» разные вещи, которые так называются в области DaVinci/OMAP. Дабы не быть голословным - вот мнение чела написавшего один из драйверов https://github.com/leo-yuriev/linux-kernel-davinci/blob/next/sound/soc/davinc...

Да, и еще из SDK от TI пример работы c McBSP выпилили (он «вааще» никакой был) в конце 2012, поддержку распустили (только freelance и community), меинтейнинг своих патчей и бранчей забросили...

О протоколе там никто не договаривается, точнее говоря нужный режим включает софт, т.е. драйвер платформы (например) предварительно детектируя/опрашивая тип кодеков, не редко и по I2C.

Но I2C тут не в тему, но не путать с I2S. Вот, кстати, большинство «McBSP» поддерживают I2S, а некоторые нет... С SPI тут принципиальная разница в отсутствии чипселектов и постоянном дуплексном обмене (а не по-требованию), что сильно меняет софтверную часть.

С клоками относительно просто - все внешние по отношению к McBSP. И по-видимому хватит простого TDМ, т.е. будет достаточно фреймового импульса для привязки к граница байт/таймслотов. На крайняк можно будет поправить режим работы (настройку клоков, таймслотов и прочее) через patch-возможность и regmap API на уровне драйвера платформы.

Поэтому тема сводится к примеру или skeleton кода, в котором при минимальном объеме будет реализованы все бантики для ping-pong подобного обмена, включая реверансы «открытия» stream, настройки/запуска и остановки. Что-то подобное делается в usb-gadget при «склейке» с ALSA.

Часть нужных «хвостов» я уже накопал, но в ALSA очень много вспомогательных рюшечек и код размазан по паре десятков файлов, порядка 1000 структур и функций, индекса или доки по этой части нет (не нашел пока) - короче, просто «много букав», а хочется сделать быстрее.

--

Вариант не использовать имеющихся «звуковых» драйверов выглядит лютым писцом. Ибо (1) в mainstream эти патчи вкрячить будет _очень_ сложно (как я понял народ наслаждается относительным перемирием и отсутствием революций в sound/soc). Ибо (2) режимов работы и вариантов использования McBSP (все что так называет) охеренно много, т.е. чтобы не говнокодить и сохранить некую гибкость нужно делать ALSA-4-DATA. Ну прикольно, да, но пока не до этого...

О протоколе там никто не договаривается, точнее говоря нужный режим включает софт, т.е. драйвер платформы (например) предварительно детектируя/опрашивая тип кодеков, не редко и по I2C

кхм, ты описал то что написал я только своими словами, но возразил, да :) делается это под конкретный кодек - ни о каком детектировании тут речи быть не может, т.е. тебе заранее нужно знать и писать драйвер, дополнительно к приведенному тобой по ссылке драйверу платформы I2S и конкретному кодеку

https://github.com/leo-yuriev/linux-kernel-davinci/tree/next/sound/soc/codecs

кодек программируется чаще всего по I2C, хотя и SPI почти все они поддерживают. Тебе надо дописывать надстройку для готового драйвера платформы I2S + что-то типа драйвера dummy codec. Как это сопрягать с другим устройством которое должно повидимому тоже ALSA API использовать - вообще слабо представляю.

Ибо (1) в mainstream эти патчи вкрячить будет _очень_ сложно

а с твоей идеей тебя сразу у виска там покрутят

кхм, ты описал то что написал я только своими словами, но возразил, да :) делается это под конкретный кодек - ни о каком детектировании тут речи быть не может, т.е. тебе заранее нужно знать и писать драйвер, дополнительно к приведенному тобой по ссылке драйверу платформы I2S и конкретному кодеку

Кодека не предвидеться, но в любом случае тут все понятно, так как есть дока на взаимодействие связки platform-driver, machine-driver, ... и всех остальных.

Трудности в неочевидности (и отсутствия доки) взаимодействия внутри ALSA, верхнего уровня реализующего uapi с нижним звуковым io. Понятно что нужно «разрезать» где-то посередине и дергать за ниточки нижнюю часть, но совсем не очевидно как именно и как лучше/легче, в этом и магопа...