dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Linus Walleij <linus.walleij@linaro.org>
To: Peter Collingbourne <pcc@google.com>,
	John Stultz <john.stultz@linaro.org>
Cc: Kevin Brodsky <Kevin.Brodsky@arm.com>,
	Russell King <linux@armlinux.org.uk>,
	ML dri-devel <dri-devel@lists.freedesktop.org>,
	Sean Paul <sean@poorly.run>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 2/4] video: fbdev: amba-clcd: Retire elder CLCD driver
Date: Mon, 21 Sep 2020 23:32:37 +0200	[thread overview]
Message-ID: <CACRpkdYnXXvPAbCMdG8OOPYqWqDHFh_=z9mR5vKZ+ri8sDyAgA@mail.gmail.com> (raw)
In-Reply-To: <CAMn1gO52PQ-dFbCU49FCnJZz=gyLEE3F2vZ5rtbF_C-H+ur7qw@mail.gmail.com>

On Tue, Sep 15, 2020 at 3:10 AM Peter Collingbourne <pcc@google.com> wrote:
> On Tue, Jun 9, 2020 at 1:08 PM Linus Walleij <linus.walleij@linaro.org> wrote:
> >
> > All the functionality in this driver has been reimplemented
> > in the new DRM driver in drivers/gpu/drm/pl111/* and all
> > the boards using it have been migrated to use the DRM driver
> > with all configuration coming from the device tree.
>
> Android's FVP configuration still uses FBDEV.

But all DRM drivers support frame buffer emulation so I don't
see how this can be a problem? The new DRM driver provides
a framebuffer.

I'm also confused about how this can be in use.
fvp-base-revc.dts includes rtsm_ve-motherboard.dtsi
where the PL111 is defined.

commit f1fe12c8bf33241e04c57a0fc5b25b16ba77ba2d
"ARM: dts: Modernize the Vexpress PL111 integration"
changes the DTS for the FVP such that only the new DRM
driver really works with it: it removes the panel-dpi encoded
panel and defines the panel
"arm,rtsm-display" for FVP and that is *only* supported
by drivers/gpu/drm/panel/panel-simple.c from DRM.

The upstream FVP has been using the new DRM driver
by default since
commit 37ad688497785c9ad1471236e28efda1e2f39741
"arm64: defconfig: Switch to PL11x DRM driver"
in january 2019.

Are you using old or outoftree devicetrees with a newer
kernel?

> While it would be great
> to see it migrated to DRM, this first requires resolving a design
> incompatibility between Android's composer and DRM devices that only
> support software rendering. I proposed a patch that would help resolve
> this [1], but there was disagreement about the approach and I haven't
> had time to get back to this.
>
> Can this please be reverted until FVP on Android can be migrated to DRM?

We need a clear technical reason, I understand that using DRM
directly might be a problem, but DRM supports full framebuffer
emulation and from a userspace point of view, what the new
driver provides should be equivalent.

I can think of problems like Android seeing the new fancy
DRM userspace ABI but surely it can be instructed to
ignore that and just use the framebuffer emulation instead?

If there is anything else making DRMs framebuffer emulation
substandard I am sure the DRM developers would like to know,
especially if it makes Android unhappy.

Yours,
Linus Walleij
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2020-09-21 21:32 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-09 20:04 [PATCH 1/4] drm: pl111: Credit where credit is due Linus Walleij
2020-06-09 20:04 ` [PATCH 2/4] video: fbdev: amba-clcd: Retire elder CLCD driver Linus Walleij
2020-09-15  1:10   ` Peter Collingbourne
2020-09-21 21:32     ` Linus Walleij [this message]
2020-09-22  4:10       ` Peter Collingbourne
2020-09-22 19:43         ` Peter Collingbourne
2020-06-09 20:04 ` [PATCH 3/4] drm: pl111: Absorb the external register header Linus Walleij
2020-06-09 20:04 ` [PATCH 4/4] drm: pl111: Update documentation Linus Walleij
2020-06-09 20:10   ` Eric Anholt
2020-06-09 20:17     ` Linus Walleij
2020-06-09 20:53       ` Eric Anholt
2020-06-10  7:37   ` kernel test robot
2020-06-12 11:04     ` Linus Walleij
2020-06-12 11:14       ` Sam Ravnborg
2020-06-12 12:40       ` [kbuild-all] " Philip Li
2020-06-22  9:28         ` Rong Chen
2020-06-16 16:12     ` Emil Velikov
2020-06-17  0:33       ` Philip Li

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='CACRpkdYnXXvPAbCMdG8OOPYqWqDHFh_=z9mR5vKZ+ri8sDyAgA@mail.gmail.com' \
    --to=linus.walleij@linaro.org \
    --cc=Kevin.Brodsky@arm.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=john.stultz@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux@armlinux.org.uk \
    --cc=pcc@google.com \
    --cc=sean@poorly.run \
    /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).