mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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'


      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®