From: "André Draszik" <andre.draszik@linaro.org>
To: "Rob Herring (Arm)" <robh@kernel.org>
Cc: Tudor Ambarus <tudor.ambarus@linaro.org>,
Will McVicker <willmcvicker@google.com>,
kernel-team@android.com, linux-arm-kernel@lists.infradead.org,
linux-samsung-soc@vger.kernel.org, linux-kernel@vger.kernel.org,
Peter Griffin <peter.griffin@linaro.org>,
Conor Dooley <conor+dt@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
devicetree@vger.kernel.org,
Alim Akhtar <alim.akhtar@samsung.com>
Subject: Re: [PATCH v3 0/4] Google Pixel 6 (simple) framebuffer support
Date: Thu, 16 Jan 2025 14:53:46 +0000 [thread overview]
Message-ID: <3be2a6e263f127bbc3331b6aeb533fc0ba636772.camel@linaro.org> (raw)
In-Reply-To: <173703609099.1976411.4033971019635742956.robh@kernel.org>
On Thu, 2025-01-16 at 08:02 -0600, Rob Herring (Arm) wrote:
>
> On Wed, 15 Jan 2025 16:11:08 +0000, André Draszik wrote:
> > Hi,
> >
> > This series enables simple framebuffer support on Google Pixel 6 and
> > Pixel 6 Pro.
> >
> > Even if simple-framebuffer is deprecated and DRM should be used
> > instead, having it available in DT is beneficial for several reasons at
> > this point in time (the phone uses an OLED display):
> > * energy consumption goes down significantly, as it changes from white
> > (as left by bootloader) to black (linux console), and we generally
> > don't run out of battery anymore when plugged into a USB port
> > * less of a burn-in effect I assume
> > * phone stays cooler due to reduced energy consumption by display
> >
> > Since Pixel 6 and Pixel 6 Pro use a different resolution display, this
> > is the time to separate them into their respective DTs, and provide one
> > for each of them. There are other differences between the two, like
> > battery design capacity, but they don't matter at this stage due to
> > incomplete upstream support.
> >
> > * dependency note *
> >
> > None (anymore) - earlier versions of this series had dependencies, but
> > those are all part of linux-next already, so none remain.
> >
> > * dependency note end *
> >
> > For those who want to try this out:
> > The stock bootloader disables the decon hardware trigger before jumping
> > to Linux, preventing framebuffer updates from reaching the display. We
> > have added a work-around in our Yocto BSP layer for the time being
> > (until a proper display exists upstream). An alternative might be to
> > port and use uniLoader from https://github.com/ivoszbg/uniLoader, as
> > seems to be done for some other Exynos platforms.
> >
> > Signed-off-by: André Draszik <andre.draszik@linaro.org>
> > ---
> > Changes in v3:
> > - back to using separate DTBs for Pixel 6 and Pixel 6 Pro (Krzysztof)
> > - update name of common dtsi file (Krzysztof)
> > - use 'memory-region' property from the start in patch 2, don't
> > introduce it as change in patch 3 (Krzysztof)
> > - Link to v2: https://lore.kernel.org/r/20241220-gs101-simplefb-v2-0-c10a8f9e490b@linaro.org
> > and https://lore.kernel.org/r/20241220-gs101-simplefb-oriole-v2-1-df60e566932a@linaro.org
> >
> > Changes in v2:
> > - We now have a generic gs101-based Pixel board DT, which can work on
> > any Pixel 6 / 6 Pro / 6a
> > - Pixel 6 (Pro) are overlays onto that one.
> > This has the advantage that all boards can be supported without
> > having to have a full copy of the DT for each of them. We still
> > instruct kbuild to create merged DTBs (in addition to the DTBOs) so
> > that existing scripts can keep working while giving the option to
> > just apply the overlay before boot (e.g. by the bootloader).
> > - The binding has been updated according to the above points
> > - I've changed the simple-framebuffer node to specify the memory via
> > memory-region instead of reg, as that avoids unnecessary duplication
> > (of the size), and it avoids having to specify #address-cells
> > and #size-cells in the chosen node (and duplicating this in the
> > DTSO), which is otherwise necessary to keep dt_binding_check happy
> > and DT validation working in general.
> > - sort overriding/extending nodes ordered by label name (Krzysztof)
> > - format patches with diff.renames=copies (Krzysztof)
> > - dependencies have been updated, see below
> > - Link to v1: https://lore.kernel.org/r/20241216-gs101-simplefb-v1-0-8ccad1830281@linaro.org
> >
> > ---
> > André Draszik (4):
> > dt-bindings: arm: google: add gs101-raven
> > arm64: dts: exynos: gs101-oriole: configure simple-framebuffer
> > arm64: dts: exynos: gs101-oriole: move common Pixel6 & 6Pro parts into a .dtsi
> > arm64: dts: exynos: gs101-raven: add new board file
> >
> > Documentation/devicetree/bindings/arm/google.yaml | 3 +-
> > arch/arm64/boot/dts/exynos/google/Makefile | 1 +
> > arch/arm64/boot/dts/exynos/google/gs101-oriole.dts | 267 +--------------------
> > .../{gs101-oriole.dts => gs101-pixel-common.dtsi} | 22 +-
> > arch/arm64/boot/dts/exynos/google/gs101-raven.dts | 29 +++
> > 5 files changed, 58 insertions(+), 264 deletions(-)
> > ---
> > base-commit: 4e16367cfe0ce395f29d0482b78970cce8e1db73
> > change-id: 20241216-gs101-simplefb-8aae80278ed7
> >
> > Best regards,
> > --
> > André Draszik <andre.draszik@linaro.org>
> >
> >
>
>
> My bot found new DTB warnings on the .dts files added or changed in this
> series.
>
> Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings
> are fixed by another series. Ultimately, it is up to the platform
> maintainer whether these warnings are acceptable or not. No need to reply
> unless the platform maintainer has comments.
>
> If you already ran DT checks and didn't see these error(s), then
> make sure dt-schema is up to date:
>
> pip3 install dtschema --upgrade
>
>
> New warnings running 'make CHECK_DTBS=y for arch/arm64/boot/dts/exynos/' for 20250115-gs101-simplefb-v3-0-52eca3a582b7@linaro.org:
>
> arch/arm64/boot/dts/exynos/google/gs101-raven.dtb: phy@11100000: 'orientation-switch' does not match any of the regexes: 'pinctrl-[0-9]+'
> from schema $id: http://devicetree.org/schemas/phy/samsung,usb3-drd-phy.yaml#
These are emitted because
https://lore.kernel.org/all/20241206-gs101-phy-lanes-orientation-phy-v4-0-f5961268b149@linaro.org/
hasn't been merged yet.
Cheers,
Andre'
prev parent reply other threads:[~2025-01-16 14:53 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-15 16:11 André Draszik
2025-01-15 16:11 ` [PATCH v3 1/4] dt-bindings: arm: google: add gs101-raven André Draszik
2025-01-15 16:11 ` [PATCH v3 2/4] arm64: dts: exynos: gs101-oriole: configure simple-framebuffer André Draszik
2025-01-15 16:11 ` [PATCH v3 3/4] arm64: dts: exynos: gs101-oriole: move common Pixel6 & 6Pro parts into a .dtsi André Draszik
2025-01-15 16:11 ` [PATCH v3 4/4] arm64: dts: exynos: gs101-raven: add new board file André Draszik
2025-01-16 14:02 ` [PATCH v3 0/4] Google Pixel 6 (simple) framebuffer support Rob Herring (Arm)
2025-01-16 14:53 ` André Draszik [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=3be2a6e263f127bbc3331b6aeb533fc0ba636772.camel@linaro.org \
--to=andre.draszik@linaro.org \
--cc=alim.akhtar@samsung.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=kernel-team@android.com \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=peter.griffin@linaro.org \
--cc=robh@kernel.org \
--cc=tudor.ambarus@linaro.org \
--cc=willmcvicker@google.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
all inboxes | Powered by JetHome®