MB77.07 и ядро

Сейчас последнее наше экспериментальное - 4.2.х, стабильное - 3.10.90. Все на есть гитхабе (В 4.2.х есть сеть, нанд, easynmc с поддержкой ION и собственно все).

В апстриме никак не могут решить насчет стабильных биндингов devicetree к ION memory manager, а на него хочется завязать всю нашу мультимедия и DSP, ибо без ION никак. Как сделают - будет массивный форвардпорт всего на 4.2.

Что касается поддержки базовой системы в мейнлайне, ближе к НГ будет еще один респин - сейчас много работы по другим проектам.

ION memory manager, а на него хочется завязать всю нашу мультимедия и DSP, ибо без ION никак

какой смысл на андроедный аллокатор завязываться, чем нативный DMABUF с CMA не устраивает ?

У нас потребность аллоцировать DMA буфер на стороне userspace для передачи последующей в декодер, видеоконтроллер и DSP

Что хуже, у нас несколько хипов: две банки SRAM памяти по 256к + мультимедийная банка DDR2, и опять на стороне юзерспейса в приложении нужно иметь контроль над тем, откуда мы выделяем.

Когда последний раз мы это дело смотрели, лучше всего на это дело ложился ION - на него решили и завязаться.

У нас потребность аллоцировать DMA буфер на стороне userspace для передачи последующей в декодер, видеоконтроллер и DSP

не верю что в этом есть реальная потребность

у нас несколько хипов: две банки SRAM памяти по 256к

http://lxr.free-electrons.com/source/drivers/misc/sram.c

мультимедийная банка DDR2

https://www.kernel.org/doc/Documentation/devicetree/bindings/reserved-memory/...

не верю что в этом есть реальная потребность

ВНЕЗАПНО. Отсюда и все эти приключения.

http://lxr.free-electrons.com/source/drivers/misc/sram.c
https://www.kernel.org/doc/Documentation/devicetree/bindings/reserved-memory/...

Да видел я это все по сто раз уже, ION пока оказался сыроватым, но единственным решением.

ВНЕЗАПНО. Отсюда и все эти приключения

да нет тут ничего внезапного - опыта у вас мало вот и изобретаете велосипед, манипуляции физическими адресами в юзерспейсе - это однозначно кривизна дизайна.

ION пока оказался сыроватым, но единственным решением

хз зачем эта срань в нативном Linux - гугель ее для проприетарщиков делал.

да нет тут ничего внезапного - опыта у вас мало вот и изобретаете велосипед, манипуляции физическими адресами в юзерспейсе - это однозначно кривизна дизайна.

Ну тогда посоветуй невелосипедное решение, о эксперт.

HINT: Если не видел ION API, то userspace про физ. адреса ничего не знает, он получает только fd который может ммапнуть или экспортнуть драйверу, который уже этот буфер импортирует.

Ну тогда посоветуй невелосипедное решение

DMABUF - в третий раз повторять не буду

HINT: Если не видел ION API, то userspace про физ. адреса ничего не знает, он получает только fd который может ммапнуть или экспортнуть драйверу

да - я посмотрел сейчас и тем более не понял для чего он вам понадобился. Посмотри как написаны mem2mem драйверы в v4l2 - зачем в юзерспейсе манипулировать памятью DMA ?

http://lxr.free-electrons.com/source/drivers/media/v4l2-core/v4l2-mem2mem.c

DMABUF - в третий раз повторять не буду

Да видел все это, прежде чем ION юзать даже его тыкали, так как ION до сих пор только собирается из стейджинга вылазить.

да - я посмотрел сейчас и тем более не понял для чего он вам понадобился. Посмотри как написаны mem2mem драйверы в v4l2 - зачем в юзерспейсе манипулировать памятью DMA ?

Попробую пояснить вкратце. Там под капотом специфики на десяток страниц, которую мне крайне лениво сейчас расписывать. Вся проблема в том, что тут решается очень узкая задача.

1. Есть необходимость делать приложения (узкоспециализированные! крайне!), которые будут использовать DSP, одно или несколько ядер. Из одного приложения!

2. В системе несколько неравноценных банок памяти, в которых должны быть выделены DMA буферы под эту задачу. От накристального SRAM, до дополнительной банки DDR, которая висит на отдельном контроллере и откуда ARM ядро не может исполнять код. На К1879ХБ1Я всего три таких хипа. От того, откуда будут выделены какие буферы производительность может меняться на порядок.

3. Люди которые их делают далеки от kernel development.

DMABUF не имеет userspace api, потому в него запрятать всю аппаратную специфику, придется на каждое такое приложение делать свой kernel драйвер. Так как люди хотят свежего ядра его надо периодически форвард-портировать и поддерживать. С ION вся специфика будет жить в одном приложении и не отсвечивать, облегчая форвард-порты на новые ядра. Суммируя вышесказанное - ION здесь наименьшее зло.

http://lxr.free-electrons.com/source/drivers/media/v4l2-core/v4l2-mem2mem.c

Видели, мимо.

Насчет DSP не знаю, но, казалось бы, видеодекодер уже запрограммирован заранее, и в каком виде ему надо скармливать данные известно, и работу с ним можно вести как с любым другим устройством, хотящим dma, в отличие от dsp, где все определяется пользовательской прошивкой. Или нет?

Там под капотом специфики на десяток страниц

из того что ты описал не вижу ни одной причины использовать ION. Док я не нашел на процессор (может плохо искал) - как понимаю у вас там отдельный контроллер DDR для DSP, отдельный для CPU ARM и двухпортовая SRAM доступная обоим. Какая разница - есть интерфейс для юзерспейса или нет - я так понимаю вы просто не стали заморачиваться со стандартными интерфейсами а сделали колхозные библиотеки под свои узкоспециальные задачи - в этом вся проблема.

Какая разница - есть интерфейс для юзерспейса или нет - я так понимаю вы просто не стали заморачиваться со стандартными интерфейсами а сделали колхозные библиотеки под свои узкоспециальные задачи

Ты вообще попробовал осознать хотя бы примерно, что я написал выше, или даже не пытался? Мне кажется, что нет.

в этом вся проблема.

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

Ты вообще попробовал осознать хотя бы примерно

конечно, а тебя видимо задело про колхоз ? Ну дык не секрет что любой интерфейс не может быть оптимален для всех задач - ваша контора не первая и не последняя кто городит колхоз, правда колхозники по-крупнее (Intel, TI, Samsung, AD и пр) со временем обдумывают все и предлагают новые подсистемы в ядре. Меня больше всего улыбнул бред про мултимедию

к ION memory manager, а на него хочется завязать всю нашу мультимедия и DSP, ибо без ION никак

конечно, а тебя видимо задело про колхоз?

Не похоже, иначе бы вопрос не стоял.

Меня больше всего улыбнул бред про мултимедию

То, что тебе это показалось бредом как раз и говорит, то ты анончик даже не попытался вникнуть, или не смог, так как с такой аппаратной спецификой скорее всего никогда не сталкивался в жизни. Либо просто пришел потроллить. Еще раз повторюсь: чтобы приспособить DMABUF, чтобы он покрывал наши юз кейзы его нужно было крайне долго допиливать месяцами протаскивая это дело в апстрим, либо плодить кучу лишнего кода, которому в ядре не место и который будет отваливаться при малейшем изменении в апстриме (stable api nonsense же!). У нас на это ресурсов нет. ION был сделан именно для таких задач и был меньшим злом. Более того, как только он выйдет из стейджинга он станет вполне себе стандартным.

колхозники по-крупнее (Intel, TI, Samsung, AD и пр)

Не спорю, у того же самсунга есть овердохнера кернель-девелоперов и ресурсы протолкнуть целую новую подсистему просто проставившись Торвальдсу пивом. У нас таких ресурсов нет, потому приходится действовать так, чтобы не плодить тонны тяжело-поддерживаемого кода в kernel-space. И если костыли неизбежны для решения задачи в сроки - хотя бы не тащить их в ядро, а держат в юзерспейсе.

Впрочем, если считаешь - что сможешь сделать лучше - все исходники есть на github. Форкай, присылай пулл-реквест, и мы даже сделаем на него код ревью ;)

с такой аппаратной спецификой скорее всего никогда не сталкивался в жизни

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

У меня мысль возникла. Что если сделать файл вроде /proc/mem (ну или отдельную vfs, чтобы не засорять proc) но для отображения памяти dsp, пользовательское приложение ммапит его и пишет что ему надо в dsp. А код, отвечающий за этот файл, находится в kernel space.

поздравляю, ты изобрел uio!

бгг, тебе корона не жмет ?

А тебе?

Аналог /dev/mem и uio. Самое близкое что есть в ядре по архитектуре к нашему DSP - spufs. Но если не считать того что spufs весьма странен сам по себе, чтобы его заюзать для нашего DSP придется много попотеть.

А тебе?

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

Аналог /dev/mem и uio.

почитал про uio, и вправду похоже. Как я понял, все, что требуется от ядра в данной ситуации, это дать приложению возможность быстро писать и читать из памяти dsp, используя dma, и если бы не желание использовать dma, то можно было бы просто заммапить нужный участок /dev/mem. Так? Если же мы хотим использовать dma, то разве задача не сводится к тому, что я написал выше, или uio? Приняли от пользовательской программы блок данных, и скопировали его в память dsp, используя dma. Т.е. тот же драйвер /dev/mem, но с dma.

если spufs странен, ну значит не надо его.

Или я что-то недопонял?

Самое близкое что есть в ядре по архитектуре к нашему DSP - spufs

посмотри тут

http://www.slideshare.net/linaroorg/hkg15106-replacing-cmem-meeting-tis-soc-s...

Спасибо за ссылку, оччень полезная презенташка. По dma-buf - слайд 9, cons #1 и #2 для нас шоустопперы, к сожалению.

По dma-buf - слайд 9, cons #1 и #2 для нас шоустопперы

1) надо посмотреть рассылки линары - работы над cenalloc не завершены, то что там влоб через ID явно не указать откуда выделить буфер еще не значит что управлять нельзя совсем

2) пипец - весь v4l2 работает и не жужжит с такой моделью и да - я конечно видел каким говноделием занимается TI, так что вдойне сомнительный юзкейс

1. К сожалению, надо уже вчера, потому и ION. Будет вменяемая альтернатива готовая к применению - с радостью переедем.

2. И традиционно всегда находится случай, который на красивую модель не ложится. Смирись, this is life.

К сожалению, надо уже вчера, потому и ION ... всегда находится случай, который на красивую модель не ложится

я просто уверен что второе это следствие первого - «чего тут думать - трясти надо!», а оптимальное решение как всегда по середине :)

On 17/11/15 15:15, Arnd Bergmann wrote:

I'm still a bit unsure about the concept of hardwiring ion in the DT
bindings. It's not just Linux-specific, it's specific to the implementation
of one or two GPU drivers, and if we fix the bindings for Ion, we might
never be able to migrate them away from this framework.

migrate them away from this framework

подумайте на досуге...