Re: [PATCH v5 0/4] Raspberry Pi 4 DMA addressing support

[Stefan Wahren]

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