Conectar câmeras em placas e dispositivos com chips Rockchip está prestes a ficar muito mais fácil. Um esforço de desenvolvimento significativo está trazendo um novo e unificado driver de captura de vídeo para o kernel Linux mainline. A série de patches — agora na 11ª revisão — introduz o rkcif, projetado para suportar a Camera Interface (CIF) encontrada em SoCs populares como o PX30 e o RK3568. Em outras palavras: em vez de coleções de hacks específicos de placa, teremos um caminho padrão, limpo e escalável para ligar sensores e começar a capturar vídeo no mainline.
Uma arquitetura moderna com Media Controller
Em vez de uma abordagem monolítica, o novo driver é construído sobre a framework Media Controller — a API do ecossistema V4L2 que descreve pipelines de mídia como grafos. O rkcif modela o pipeline de captura de forma flexível: há subdevices lógicos para o receptor MIPI CSI-2 e para a interface DVP (parallel), que se conectam aos drivers dos sensores de câmera. Assim, o grafo no userspace reflete exatamente a fiação da placa, permitindo configurar rotas (por exemplo, DVP → memória, CSI-2 → memória) e ajustar formatos e crops por estágio. Essa divisão também facilita manutenção e testes, porque cada bloco (INTERFACE/CROP, receptor CSI-2, etc.) evolui de forma independente sem “quebrar” o todo.
Um só driver, várias famílias de SoC
A beleza do rkcif está na sua modularidade. O código abstrai blocos comuns de hardware — como o mecanismo de DMA em “ping-pong” (duplo buffering) — em componentes reutilizáveis, expondo nós e pads que batem com a topologia dos controladores Rockchip. Na prática, isso já cobre o PX30 (VIP) e o RK3568 (VICAP), incluindo o receptor MIPI CSI-2 e a DVP, e deixa o caminho aberto para variantes mais complexas. A documentação e as mensagens da série indicam que o design foi pensado para escalar até o RK3588, onde o VICAP integra um DVP e seis receptores MIPI CSI-2, além de multiplexadores e unidades de scale/crop — um cenário típico de SBCs com múltiplas câmeras.
No RK3568, por exemplo, o receptor MIPI CSI-2 expõe quatro engines de DMA, cada um podendo capturar um Virtual Channel diferente, enquanto a DVP tem seu caminho dedicado — ambos operando de forma independente e usando o esquema ping-pong. O rkcif espelha isso apresentando subdevices e nós de vídeo separados (rkcif-dvp0, rkcif-mipi0, etc.), o que simplifica a vida do userspace (GStreamer, libcamera) ao mapear streams e formatos.
Abrindo as portas para o suporte a câmeras
Por que isso importa? Porque muita gente compra placas com Rockchip (PX30, RK3568, RK3588) imaginando montar um NVR, um kiosque com câmera ou um gateway de visão computacional — e esbarra num labirinto de patches out-of-tree e DTs específicos de vendor. Com o rkcif no mainline, a promessa é exatamente o oposto: device trees padronizados, documentação na árvore do kernel, e uma API V4L2/Media Controller coerente para todas as variações de CIF. Em termos práticos: menos atrito para “dar imagem” no Linux, mais estabilidade a longo prazo e base sólida para camadas como libcamera.
E não é só o driver: o trabalho de upstream é abrangente. A série reúne dt-bindings (para descrever o VICAP/CSI-2 no Device Tree), a documentação do rkcif no admin-guide (incluindo diagramas do grafo), o código do driver principal e dos subdevices (MIPI CSI-2 host/receiver, INTERFACE/CROP), além das atualizações em Device Tree e defconfig para habilitar o suporte nas plataformas afetadas. É o pacote completo que você espera quando o objetivo é tornar a experiência “ligou, reconheceu, capturou” universal nas placas Linux com Rockchip.
Gente séria revisando — e isso faz diferença
Qualidade é um ponto central aqui. A série é assinada por Michael Riesch (Collabora) e teve contribuições de Mehdi Djait, além de um rastro de discussões e Reviewed-by de nomes conhecidos do subsistema de mídia, como Laurent Pinchart, Sakari Ailus, Philipp Zabel e Bryan O’Donoghue — justamente as pessoas que, no dia a dia, mantêm a sanidade do Media Controller e do V4L2. O alto número de revisões (v2, v6, v7, v10, v11…) sinaliza aquele ciclo de lapidação que a comunidade valoriza: responder feedback, ajustar DTs, separar subdrivers, limpar interfaces e documentar. Isso tudo aumenta a confiança de que, quando o código entrar, ele entra para ficar.
E na prática, o que você ganha?
Se você trabalha com uma SBC baseada em RK3568 ou está de olho em designs com RK3588, o rkcif é uma ponte entre o seu sensor (IMX415, OV5647, etc.) e um pipeline Linux robusto. Para quem faz produto, isso significa menos dependência de BSPs proprietários e menos risco de regressões ao atualizar o kernel. Para quem é maker ou pesquisador, significa poder combinar sensores MIPI CSI-2 e DVP com menos fricção, explorar múltiplos Virtual Channels e encaixar tudo no seu stack favorito (GStreamer, libcamera) — com upstream do seu lado.
O que vem a seguir
A proposta está madura e mirando uma futura janela de merge. Algumas peças (como partes específicas de MUX/SCALE/TOISP em variantes do RK3588) devem chegar em patches subsequentes — já há sinais de “primeiros sucessos” para o RK3588, mas com envio separado para manter a revisão organizada. Essa cadência incremental é saudável: habilita logo o que é estável (CIF + DVP + MIPI CSI-2 no RK3568/PX30) e mantém espaço para aprofundar recursos avançados sem travar quem precisa começar a capturar vídeo hoje.
No fim do dia, “Linux Rockchip camera” deixa de ser um bingo de patches e passa a ser um caminho claro dentro do mainline: driver único, Media Controller bem modelado, V4L2 do jeito certo e documentação pronta para levar você do Device Tree ao streaming de frames com previsibilidade — em placas reais, com sensores reais, sem depender de árvores privadas.
