All of lore.kernel.org
 help / color / mirror / Atom feed
From: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
To: u-boot@lists.denx.de
Subject: [PATCH 0/4] Use just one DTS file for all Espressobin variants
Date: Wed, 2 Dec 2020 15:20:10 +0100	[thread overview]
Message-ID: <2963AC40-09CD-43F1-A1F4-7F642FAAACCF@theobroma-systems.com> (raw)
In-Reply-To: <998062ef-4c6c-327c-8b0d-9f6363772811@gmail.com>



> On 02.12.2020, at 13:37, Andre Heider <a.heider@gmail.com> wrote:
> 
> On 02/12/2020 11:35, Stefan Roese wrote:
>> On 02.12.20 10:12, Pali Roh?r wrote:
>>> On Wednesday 02 December 2020 09:09:15 Stefan Roese wrote:
>>>> On 02.12.20 01:33, Pali Roh?r wrote:
>>>>> On Wednesday 25 November 2020 19:20:06 Pali Roh?r wrote:
>>>>>> This patch series change Espressobin code to use in U-Boot just one DTS
>>>>>> file for all Espressobin variants. Therefore DT compatible string
>>>>>> globalscale,espressobin-emmc is not used anymore as it is not needed.
>>>>>> 
>>>>>> It means that setup and compilation of U-Boot for Espressobin is less
>>>>>> complicated and more simple. As there is no need to check for HW details
>>>>>> and just one U-Boot binary would work for all Espressobin variants.
>>>>>> 
>>>>>> First two patches just revert previous eMMC support and next two patches
>>>>>> add support for eMMC in way that just one DTS file is used and fdtfile
>>>>>> env variable is correctly set for any Espressobin variant.
>>>>>> 
>>>>>> We have tested that fdtfile env variable is correctly set on Espressobin
>>>>>> variants with eMMC, without eMMC, with DDR3 RAM and also with DDR4 RAM.
>>>>>> Also that eMMC is working on Espressobin variant with eMMC.
>>>>> 
>>>>> Stefan, could you please review this patch series?
>>>> 
>>>> I like the approach in general to simplify things. One comment though:
>>>> 
>>>> AFAICT, Linux uses multiple dts/dtsi files for espressobin. So your
>>>> approach to move to one single file contradicts the (planned after
>>>> comphy conversion) move to the Linux dts/dtsi files.
>>> 
>>> After comphy conversion we can use e.g. Linux dtsi file and create one
>>> main U-Boot dts file which would contain all nodes enabled and in U-Boot
>>> code disable nodes which are not present/relevant. This patch series
>>> allows to detect all variants v5, v7, with emmc, without emmc; so we can
>>> reconstruct dts file at U-Boot runtime. In Linux we also simplified dts
>>> files as much as possible, so all options are in common dtsi file and
>>> only variant relevant changes (enable/disable nodes) are in dts files.
>> I see. So let's please wait for Andre, if he has some comments on this.
>> Thanks,
>> Stefan
>>>>> Andre, are you fine with these changes? I would like to get your
>>>>> acknowledgment or review comment what needs to be changed or improved as
>>>>> this patch series basically rework your code (which is first reverted
>>>>> and them implemented in different way).
>>>> 
>>>> Yes. Andre please also comment on this.
> 
> This is a nice simplification. Pali had this idea before, and I hesitated because of two questions I don't have the answer to:
> - Can we just try to detect an emmc chip on an unpopulated board without any drawbacks?

All eMMC host controllers I know, will eventually return a timeout on the first command(s) to the eMMC.
So the main drawback should be wasted runtime that will slow down the boot sequence.

> - What about power consumption? Does this unnecessarily waste power on non-emmc boards because something is still powered up?
> 
> But if noone sees an issue with that I don't have any objections.
> 
> I think this set could be simplified though. Instead of the first two reverts, just remove the non-emmc dts and rename the emmc dts. That's less churn and keeps the dtsi for future syncing with linux.
> 
> Thanks,
> Andre
> 
>>>> 
>>>> Thanks,
>>>> Stefan
>>>> 
>>>>>> Pali Roh?r (4):
>>>>>>     Revert "arm64: dts: armada-3720-espressobin: split common parts to
>>>>>>       .dtsi"
>>>>>>     Revert "arm64: dts: a3720: add support for espressobin with populated
>>>>>>       emmc"
>>>>>>     arm: mvebu: Espressobin: Add support for emmc into dts file
>>>>>>     arm: mvebu: Espressobin: Detect presence of emmc at runtime
>>>>>> 
>>>>>>    arch/arm/dts/Makefile                         |   1 -
>>>>>>    arch/arm/dts/armada-3720-espressobin-emmc.dts |  44 -----
>>>>>>    arch/arm/dts/armada-3720-espressobin.dts      | 186 +++++++++++++++++-
>>>>>>    arch/arm/dts/armada-3720-espressobin.dtsi     | 167 ----------------
>>>>>>    board/Marvell/mvebu_armada-37xx/board.c       |   6 +-
>>>>>>    doc/README.marvell                            |   7 +-
>>>>>>    6 files changed, 186 insertions(+), 225 deletions(-)
>>>>>>    delete mode 100644 arch/arm/dts/armada-3720-espressobin-emmc.dts
>>>>>>    delete mode 100644 arch/arm/dts/armada-3720-espressobin.dtsi
>>>>>> 
>>>>>> -- 
>>>>>> 2.20.1
>>>>>> 
>>>> 
>>>> 
>>>> Viele Gr??e,
>>>> Stefan
>>>> 
>>>> -- 
>>>> DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
>>>> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
>>>> Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: sr at denx.de
>> Viele Gr??e,
>> Stefan

  reply	other threads:[~2020-12-02 14:20 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-25 18:20 [PATCH 0/4] Use just one DTS file for all Espressobin variants Pali Rohár
2020-11-25 18:20 ` [PATCH 1/4] Revert "arm64: dts: armada-3720-espressobin: split common parts to .dtsi" Pali Rohár
2020-11-25 18:20 ` [PATCH 2/4] Revert "arm64: dts: a3720: add support for espressobin with populated emmc" Pali Rohár
2020-11-25 18:20 ` [PATCH 3/4] arm: mvebu: Espressobin: Add support for emmc into dts file Pali Rohár
2020-11-25 18:20 ` [PATCH 4/4] arm: mvebu: Espressobin: Detect presence of emmc at runtime Pali Rohár
2020-12-02 14:35   ` Andre Heider
2020-12-03 15:56     ` Pali Rohár
2020-12-03 16:30       ` Stefan Roese
2020-12-05 12:44         ` Pali Rohár
2020-12-07 11:07           ` Stefan Roese
2020-11-25 18:38 ` [PATCH 0/4] Use just one DTS file for all Espressobin variants Peter Robinson
2020-11-25 19:06   ` Pali Rohár
2020-12-02  0:33 ` Pali Rohár
2020-12-02  8:09   ` Stefan Roese
2020-12-02  9:12     ` Pali Rohár
2020-12-02 10:35       ` Stefan Roese
2020-12-02 12:37         ` Andre Heider
2020-12-02 14:20           ` Philipp Tomsich [this message]
2020-12-07 11:09 ` Stefan Roese

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=2963AC40-09CD-43F1-A1F4-7F642FAAACCF@theobroma-systems.com \
    --to=philipp.tomsich@theobroma-systems.com \
    --cc=u-boot@lists.denx.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.