Hi Matthias, Am 17.09.19 um 11:04 schrieb Matthias Brugger: > > On 16/09/2019 21:19, Stefan Wahren wrote: >> 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 > On the other hand it get's confusing that the SoC for RPi4 is called bcm2711 > while all the others are named bcm283x. one could argue this is a complete new SoC. But i got your point. > Anyway if the majority prefers bcm2711 > so shall it be and let's get forward instead :) > >> Btw currently u-boot only uses bcm2711, so it would be nice to keep that. >> > Yes that's true. We already identified the compatible we'll need to add to > U-Boot to also boot with the upstream DTS. I'll send a patch to the U-Boot > mailinglist. Since the upstream DTS isn't completely stable yet, maybe you better wait until it has been accepted. > >> So my suggestion is to add bcm2711 compatibles in the downstream tree. >> > Ok, can you take care of it, or shall I send a pull request/open a bug?
I'll send a send a pull request and hope the RPi guys are happy with it. Btw the clk changes has been applied. Stefan
