Hi Matthias, [drop uninvolved receiver]
Am 13.09.19 um 12:39 schrieb Matthias Brugger: > >>>>> If you talk about the >>>>> downstream kernel, I suppose you mean we should change this in the FW DT >>>>> blob >>>>> and in the downstream kernel. That would work for me. >>>>> >>>>> Did I understand you correctly? >>>> Yes >>>> >>>> So i suggest to add the upstream compatibles into the repo mentioned above. >>>> >>>> Sorry, but in case you decided as a U-Boot developer to be compatible >>>> with a unreviewed DT, we also need to make U-Boot compatible with >>>> upstream and downstream DT blobs. >>>> >>> Well RPi3 is working with the DT blob provided by the FW, as I mentioned >>> earlier >>> if we can use this DTB we can work towards one binary that can boot both >>> RPi3 >>> and RPi4. On the other hand we can rely on the FW to detect the amount of >>> memory >>> our RPi4 has. >>> >>> That said, I agree that we should make sure that U-Boot can boot with both >>> DTBs, >>> the upstream one and the downstream. Now the question is how to get to >>> this. I'm >>> a bit puzzled that by talking about "unreviewed DT" you insinuate that >>> bcm2711 >>> compatible is already reviewed and can't be changed. From what I can see >>> none of >>> these compatibles got merged for now, so we are still at time to change >>> them. >> Stephen Boyd was okay with clk changes except of a small nit. So i fixed >> this is as he suggested in a separate series. Unfortunately this hasn't >> be applied yet [1]. >> >> The i2c, pinctrl and the sdhci changes has been applied yet. >> >> In my opinion it isn't the job of the mainline kernel to adapt to a >> vendor device tree. It's the vendor device tree which needs to be fixed. >> > I agree with that. But if we can make this easier by choosing a compatible > which > fits downstream without violating upstream and it makes sense with the naming > scheme of the RPi, I think that's a good argument. i spend a lot of my spare time to prepare these patch series in order to get a clean solution. Either mixing bcm2711/bcm2838 or changing everything to bcm2838 in the upstream tree has the following drawbacks: - additional review time and delay of the Raspberry Pi 4 support - harder to understand for developer/reviewer without RPi knowledge Btw currently u-boot only uses bcm2711, so it would be nice to keep that. So my suggestion is to add bcm2711 compatibles in the downstream tree. Best regards Stefan > >> Sorry, but this is my holiday. I will back after the weekend. >> > Sure, enjoy. I'll be on travel for the next two weeks but will try to keep up > with emails. > > Regards, > Matthias > >> Best regards >> Stefan >> >> [1] - https://www.spinics.net/lists/linux-clk/msg40534.html >> >>> Apart from the point Florian made, to stay consistent with the RPi SoC >>> naming, >>> it will save us work, both in the kernel and in U-Boot, as we would need to >>> add >>> both compatibles to the code-base. >>> >>> Regards, >>> Matthias >>> >>>>>>> Regards, >>>>>>> Matthias >>>>>>> >>>>>>>> Regards, >>>>>>>> Matthias >>>>>>>> >>>>>>>>> Are there any config.txt tweaks necessary? >>>>>>>>> >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> linux-arm-kernel mailing list >>>>>>>> linux-arm-ker...@lists.infradead.org >>>>>>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> linux-arm-kernel mailing list >>>>>>> linux-arm-ker...@lists.infradead.org >>>>>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
