On 13/08/2024 10:59, Aiqun Yu (Maria) wrote: >>>>>> Does "new board" mean that "old board" disappears? No users to care >>>>>> about it? Or just the existing board is being changed (like new revision)? >>>>> >>>>> We will support both boards. Sa8775p-ride board with sa8775p chipset and >>>>> sa8775p-ride board with qcs9100 chipset. Both of them can be used for >>>>> development. >>>> >>>> Patch does something else then - changes compatibles for the existing >>>> (old) board. >>> >>> Can you educate us the right way to add the qcs9100 SoC support in >>> sa8775p-ride board? We don't want to duplicate whole device tree file >>> since all the hardwares are same except the SoC, so we add qcs9100 SoC >>> compatible to sa8775p-ride board and still keep sa8775p SoC compatible. >> >> Split board DTS into shared DTSI (just don't forget about proper >> -M/-C/-B arguments for format-patch) and include it in relevant boards. >> You also need new SoC DTSI. This will be unusual code, but it matches >> what you want to achieve. > > If we create two additional DTSs, a total of four DTBs will be generated. > Should we update the current board DTSs (sa8775p-ride-r3.dts and > sa8775p-ride.dts) to support the pin-to-pin compatible QCS9100 and > SA8775p SoCs? I don't know, I don't have such device. Decision should be based on real life, real events happening, real products, not on feelings. > > Considering the higher usage of QCS9100 boards in IoT compared to > SA8775p in automotive for these DTBs, perhaps we should prioritize the > 'qcom,qcs9100' compatibility before 'qcom,sa8775p'. Prioritize in what way? What does it mean? Best regards, Krzysztof
