Olá,
há algum git repo “-next” com trabalho para suportar o Kernel Mainline?
Gostaria de contribuir para o driver de pinctrl, mas talvez eu venha a fazer “retrabalho” caso já tenha avanços.
Abraços,
Matheus Castello
Olá @matheus , por hora não há um esforço para suportar Mainline, mas é algo a ser feito no futuro.
Bem quanto ao driver de pinctrl, na versão 32 bits, realmente é algo a ser feito, não tivemos avanço neste driver já faz algum tempo, pode trabalhar nele, não há outras pessoas trabalhando com ele.
Obrigado pela iniciativa!
Att,
Igor Ruschi
1 Curtida
Update: tenho uma versão do Kernel 5.5-rc7 rodando.
clocks (actions,s500-cmu)
pinctrl (actions,s500-pinctrl “baseado no actions,s700-pinctrl”)
uart (actions,s500-uart)
Estou configurando a uart3 já com o pinctrl e o clock do mainline, e ela responde com os logs de printk:
Preciso agora acertar os nós de mcc para ter algo mais útil, ir para user space em rootfs. Adicionar alguns detalhes de clock reset, para verificar se o owl-mmc (actions,owl-mmc) vai ser compatível. (Me parece favorável em uma primeira analise)
Vou começar a colocar aqui também os patches enviados para upstream:
pinctrl: actions: Fix functions groups names
drivers/pinctrl/actions/pinctrl-s700.c
https://patchwork.kernel.org/patch/11350329/
1 Curtida
clocksource: owl: Improve owl_timer_init fail messages
drivers/clocksource/timer-owl.c
Resolvendo alguns problemas, no meu defconfig, que estavam causando “RCU stalls”, agora eu tenho um initramfs com Busybox para me ajudar nos testes com mainline:
1 Curtida
Muito bom!!
Acredito que em breve(próximo mês), vou liberar uma versão do Kernel 5.3, ao menos para a labrador arm32, aproveito para avaliar e adicionar a sua contribuição do pinctrl, é nesse repositório que você mantém ele?
Att,
Igor Ruschi
Olá @ruschigo,
estou mantendo meus testes aqui na verdade: https://github.com/microhobby/linus-tree/
Você pode notar que os commits estão com “WIP”, eu não acho que eles estão bons ainda para irem para produção, ou para enviar para mainline por exemplo.
Eu esperaria até que fosse incluído no mainline para usar. Por exemplo: https://patchwork.kernel.org/patch/11350329/ já foi aceito pelos mantenedores, deve entrar até a próxima release candidate do 5.6
Abraços
Obrigado Matheus,
Bem ainda vou demorar um pouco para prosseguir com isso, mas quero em futuro próximo fazer um driver de clock novo para labrador 32bits, quando for fazer isso olho como está o status do seu pincrtl, daí qualquer coisa posto aqui novamente.
Att,
Igor Ruschi
1 Curtida
Add Caninos Loucos Labrador SoM and Base Board Device Tree
dt-bindings: arm: actions: Document Caninos Loucos Labrador
Documentation/devicetree/bindings/arm/actions.yaml
Documentation/devicetree/bindings/vendor-prefixes.yaml
https://patchwork.kernel.org/patch/11409607/
ARM: dts: Add Caninos Loucos Labrador
arch/arm/boot/dts/Makefile
arch/arm/boot/dts/owl-s500-labrador-bb.dts
arch/arm/boot/dts/owl-s500-labrador-v2.dtsi
https://patchwork.kernel.org/patch/11409609/
v2
https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=252745
estou adicionando a Caninos Loucos como fabricante de dispositivos no mainline e preciso da ajuda de vocês para um input sobre a pergunta do mantenedor do Actions Semi. Deem uma olhada aqui se possível: https://patchwork.kernel.org/patch/11424883/
Gostaria de colocar alguém do time da Caninos como CC nos patches também, como o mantenedor achou melhor, para continuarmos com as decisões.
Em suma a dúvida é sobre o vendor prefix. Utilizar caninos,labrador por exemplo, a Caninos é independente o bastante para ter sua própria vendor-prefix, ou deveríamos ter o vendor-prefix da LSI-TEC lsi-tec,caninosloucos-labrador?
Desde já agradeço,
Abraços!
@matheus, Boa Tarde!
O que temos utilizado internamente é o prefixo ‘caninos,kx-driver-name’, devido a termos duas arquiteturas arm32 e arm64, chamamos a 32 bits de k5 e a 64 bits de k7, então por exemplo, para um driver de uart para a 32 bits, seria ‘caninos,k5-uart’. Assim podemos ter maior flexibilidade no futuro para outros desenvolvimentos para caninos.
Inicialmente quando havia apenas a 32 bits as core V2.x, era usado o prefixo ‘caninos,labrador-drivername’, mas com o desenvolvimento da 64 bits, terminamos criando uma nova terminologia ‘kx’.
Então genericamente, podemos utilizar assim;
caninos,device-driver-name
o ‘device’, atualmente temos os k5 e k7.
Coloque o @edgar.righi em cópia, edgar.righi@lsitec.org.br, se quiser pode me adicionar também igor.lima@lsitec.org.br
Att,
Igor Ruschi
1 Curtida
Add Caninos Loucos Labrador SoM and Base Board Device Tree
Nova versão da serie: https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=259135
@ruschigo e @edgar.righi gostaria que vocês, se possivel, enviassem um “Acked-by:” para o seguinte commit https://patchwork.kernel.org/patch/11448393/ para mostrar acordo com o que foi conversado de usar o prefixo “caninos,*” ao invés de “lsi-tec,*”
Se não tiverem de acordo deixe-me saber.
Abraços!