linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Matthias Brugger <matthias.bgg@gmail.com>
To: Stefan Wahren <wahrenst@gmx.net>,
	Matthias Brugger <mbrugger@suse.com>,
	robh+dt@kernel.org, linux-arm-kernel@lists.infradead.org,
	Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Cc: f.fainelli@gmail.com, phil@raspberrypi.org,
	linux-rpi-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 0/4] Raspberry Pi 4 DMA addressing support
Date: Tue, 17 Sep 2019 11:04:57 +0200	[thread overview]
Message-ID: <197ebc29-2e4d-fa2c-7ad4-1a83ce3f3eb4@gmail.com> (raw)
In-Reply-To: <c7e6ab89-aaae-debc-5f63-2e091efcf76f@gmx.net>



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. 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.

> 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?

Regards,
Matthias

> 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-kernel@lists.infradead.org
>>>>>>>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> linux-arm-kernel mailing list
>>>>>>>> linux-arm-kernel@lists.infradead.org
>>>>>>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2019-09-17  9:05 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-09  9:58 [PATCH v5 0/4] Raspberry Pi 4 DMA addressing support Nicolas Saenz Julienne
2019-09-09  9:58 ` [PATCH v5 1/4] arm64: mm: use arm64_dma_phys_limit instead of calling max_zone_dma_phys() Nicolas Saenz Julienne
2019-09-09  9:58 ` [PATCH v5 2/4] arm64: rename variables used to calculate ZONE_DMA32's size Nicolas Saenz Julienne
2019-09-09  9:58 ` [PATCH v5 3/4] arm64: use both ZONE_DMA and ZONE_DMA32 Nicolas Saenz Julienne
2019-09-11 10:54   ` Nicolas Saenz Julienne
2019-09-11 14:35     ` Catalin Marinas
2019-09-11 15:00       ` Nicolas Saenz Julienne
2019-09-09  9:58 ` [PATCH v5 4/4] mm: refresh ZONE_DMA and ZONE_DMA32 comments in 'enum zone_type' Nicolas Saenz Julienne
2019-09-09 19:33 ` [PATCH v5 0/4] Raspberry Pi 4 DMA addressing support Stefan Wahren
2019-09-09 19:50   ` Nicolas Saenz Julienne
2019-09-10  9:27   ` Matthias Brugger
2019-09-12 17:18     ` Matthias Brugger
2019-09-12 17:27       ` Florian Fainelli
2019-09-12 19:32       ` Stefan Wahren
2019-09-13  7:15         ` Matthias Brugger
2019-09-13  8:09         ` Matthias Brugger
2019-09-13  8:50           ` Stefan Wahren
2019-09-13  9:25             ` Matthias Brugger
2019-09-13 10:08               ` Stefan Wahren
2019-09-13 10:39                 ` Matthias Brugger
2019-09-16 19:19                   ` Stefan Wahren
2019-09-17  9:04                     ` Matthias Brugger [this message]
2019-09-17 18:03                       ` Stefan Wahren
2019-09-27 16:44                         ` Stefan Wahren

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=197ebc29-2e4d-fa2c-7ad4-1a83ce3f3eb4@gmail.com \
    --to=matthias.bgg@gmail.com \
    --cc=f.fainelli@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rpi-kernel@lists.infradead.org \
    --cc=mbrugger@suse.com \
    --cc=nsaenzjulienne@suse.de \
    --cc=phil@raspberrypi.org \
    --cc=robh+dt@kernel.org \
    --cc=wahrenst@gmx.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).