linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Neil Armstrong <narmstrong@baylibre.com>
To: Kevin Hilman <khilman@baylibre.com>,
	Christian Hewitt <christianshewitt@gmail.com>,
	Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-amlogic@lists.infradead.org, linux-kernel@vger.kernel.org
Cc: Benoit Masson <yahoo@perenite.com>
Subject: Re: [RFC PATCH 0/9] arm64: dts: meson: add support for aac2xx devices
Date: Wed, 8 Dec 2021 09:20:38 +0100	[thread overview]
Message-ID: <e3b404f8-758e-ba97-37c6-0178231119dd@baylibre.com> (raw)
In-Reply-To: <7hilw14nhx.fsf@baylibre.com>

On 06/12/2021 19:06, Kevin Hilman wrote:
> Christian Hewitt <christianshewitt@gmail.com> writes:
> 
>> This series adds support for several popular Amlogic S905X3 (SM1) Android
>> Set-Top Box devices. Like most Android box devices, they ship in variants
>> with multiple RAM, eMMC, WiFi and BT configurations. RAM and eMMC are not
>> something we need to consider to get a working boot, but we do need to get
>> the correct connectivity spec.
> 
> The reason we don't need to care about RAM differences is because u-boot
> takes care of that, and updates the DT nodes accordingly.
> 
> In general, I'm not a fan of leaving these decisions up to u-boot,
> but...  as an option...

For now we always set "safe" values for RAM in DT so it could work
even if not the entire memory is configured.

Since there is no way to detect this from Linux on ARM64, we have no choice
but hoping U-boot sets the right value...

> 
> I'm pondering if we should do the same for the connectivity settings?  A
> properly configured u-boot already knows if it's an internal/external
> PHY, Mbit vs Gbit etc. so in a similar way could enable/disable the
> right nodes.
> 
> We could have a single DTS for each of these board families which
> has some reasonable defaults, then u-boot would enable/disable nodes
> accordingly.

Yes it's technically possible, but it puts a larger dependency on the bootloader.

Having a lower RAM value is not idea but the system will work, having the wrong
PHY setup simply doesn't work.

Neil

> 
> Kevin
> 
> 


      reply	other threads:[~2021-12-08  8:20 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-30  6:05 [RFC PATCH 0/9] arm64: dts: meson: add support for aac2xx devices Christian Hewitt
2021-11-30  6:05 ` [RFC PATCH 1/9] arm64: dts: meson: add common SM1 ac2xx dtsi Christian Hewitt
2021-12-06 21:34   ` Martin Blumenstingl
2021-11-30  6:05 ` [RFC PATCH 2/9] dt-bindings: arm: amlogic: add X96-AIR bindings Christian Hewitt
2021-12-07 21:21   ` Rob Herring
2021-12-08  4:44     ` Christian Hewitt
2021-12-08  8:17       ` Neil Armstrong
2021-11-30  6:05 ` [RFC PATCH 3/9] arm64: dts: meson: add initial device-trees for X96-AIR Christian Hewitt
2021-12-06 21:34   ` Martin Blumenstingl
2021-12-07  8:13   ` Piotr Oniszczuk
2021-11-30  6:05 ` [RFC PATCH 4/9] dt-bindings: vendor-prefixes: add cyx prefix Christian Hewitt
2021-12-07 21:22   ` Rob Herring
2021-11-30  6:05 ` [RFC PATCH 5/9] dt-bindings: arm: amlogic: add A95XF3-AIR bindings Christian Hewitt
2021-11-30  6:05 ` [RFC PATCH 6/9] arm64: dts: meson: add initial device-trees for A95XF3-AIR Christian Hewitt
2022-01-03 15:21   ` Neil Armstrong
2022-01-03 15:26     ` Christian Hewitt
2021-11-30  6:05 ` [RFC PATCH 7/9] dt-bindings: vendor-prefixes: add haochuangyi prefix Christian Hewitt
2021-12-07 21:23   ` Rob Herring
2021-11-30  6:05 ` [RFC PATCH 8/9] dt-bindings: arm: amlogic: add H96-Max bindings Christian Hewitt
2021-12-07 21:23   ` Rob Herring
2021-11-30  6:05 ` [RFC PATCH 9/9] arm64: dts: meson: add initial device-tree for H96-Max Christian Hewitt
2021-11-30 10:40 ` [RFC PATCH 0/9] arm64: dts: meson: add support for aac2xx devices Neil Armstrong
2021-12-06 18:06 ` Kevin Hilman
2021-12-08  8:20   ` Neil Armstrong [this message]

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=e3b404f8-758e-ba97-37c6-0178231119dd@baylibre.com \
    --to=narmstrong@baylibre.com \
    --cc=christianshewitt@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=khilman@baylibre.com \
    --cc=linux-amlogic@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=yahoo@perenite.com \
    /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).