Message-ID: <3be2a6e263f127bbc3331b6aeb533fc0ba636772.camel@linaro.org>
Date: Thu, 16 Jan 2025 14:53:46 +0000
From: André Draszik <andre.draszik@...aro.org>
To: "Rob Herring (Arm)" <robh@...nel.org>
Cc: Tudor Ambarus <tudor.ambarus@...aro.org>, Will McVicker	
 <willmcvicker@...gle.com>, kernel-team@...roid.com, 
	linux-arm-kernel@...ts.infradead.org, linux-samsung-soc@...r.kernel.org, 
	linux-kernel@...r.kernel.org, Peter Griffin <peter.griffin@...aro.org>,
 Conor Dooley <conor+dt@...nel.org>, Krzysztof Kozlowski
 <krzk+dt@...nel.org>, 	devicetree@...r.kernel.org, Alim Akhtar
 <alim.akhtar@...sung.com>
Subject: Re: [PATCH v3 0/4] Google Pixel 6 (simple) framebuffer support

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@...aro.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@...aro.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@...aro.org:
> 
> arch/arm64/boot/dts/exynos/google/gs101-raven.dtb: phy@...00000: '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'

Powered by blists - more mailing lists