devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Liviu Dudau <liviu.dudau@arm.com>
To: Andrzej Hajda <a.hajda@samsung.com>
Cc: "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
	<devicetree@vger.kernel.org>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	"open list:DRM PANEL DRIVERS" <dri-devel@lists.freedesktop.org>,
	Ryan Harkin <ryan.harkin@linaro.org>,
	Rob Herring <robh+dt@kernel.org>,
	Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
	Sudeep Holla <sudeep.holla@arm.com>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 1/2] drm/bridge: Add virtual display DT bindings
Date: Wed, 29 Aug 2018 12:00:45 +0100	[thread overview]
Message-ID: <20180829110045.GN907@e110455-lin.cambridge.arm.com> (raw)
In-Reply-To: <20180829102320eucas1p28f05f1c765eb85195a06199bb68b87ce~PU9ukgvXA1734817348eucas1p2L@eucas1p2.samsung.com>

On Wed, Aug 29, 2018 at 12:23:18PM +0200, Andrzej Hajda wrote:
> On 29.08.2018 12:01, Liviu Dudau wrote:
> > On Wed, Aug 29, 2018 at 11:58:20AM +0200, Andrzej Hajda wrote:
> >> On 28.08.2018 15:45, Linus Walleij wrote:
> >>> On Mon, Aug 27, 2018 at 1:53 PM Andrzej Hajda <a.hajda@samsung.com> wrote:
> >>>
> >>>> On 24.08.2018 14:23, Linus Walleij wrote:
> >>>>> This adds bindings for a virtual display to be used with displays
> >>>>> inside entirely virtual environments which do not emulate things
> >>>>> like monitors but just need timing information to be supplied to
> >>>>> its display controller.
> >>>>>
> >>>>> This is inspired by earlier work by Liviu Dudau.
> >>>> If this is pure virtual then it should be connected to other pure
> >>>> virtual components.
> >>> OK it's a bit of half-half but outside of my grasp, I am just trying
> >>> to support legacy systems.
> >>>
> >>> The device tree is there:
> >>> arch/arm64/boot/dts/arm/rtsm_ve-aemv8a.dts
> >>> arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi
> >>>
> >>> The latter contains the CLCD which is the display driver.
> >>>
> >>> In RTSM, which is an ARM product I do not develop and
> >>> cannot make changes to, there is an emulated CLCD. So
> >>> that part appear as if it was real hardware. Like in QEMU.
> >>>
> >>> But the display does not have any emulation. The raw
> >>> output from the CLCD is latched out to the screen.
> >>>
> >>> I do not know exactly know how the RTSM emulator
> >>> actually works, but I suspect that the little graphic window
> >>> on the screeen adapts to what gets written into the
> >>> CLCD control registers, so anything goes, more or less.
> >>>
> >>> To satisfy the CLCD with some timings and resolution,
> >>> this bridge gives it that, from the device tree, in a way
> >>> that clearly conveys that "this is not a real thing".
> >>>
> >>> The old code uses DPI. This is not DPI, not even close
> >>> to it. It worked simply because all the DPI really does is
> >>> what this patch does: provide timings.
> >>>
> >>> By contrast on QEMU I have patches the emulator to
> >>> properly represent the I2C DDC link and provide EDID
> >>> so that is all fine.
> >>>
> >>> I cannot patch RTSM to emulate I2C and DDC. It's not
> >>> open source. But the device tree in the kernel supports
> >>> this "machine" and so, I have to maintain it when modernizng
> >>> the fbdev driver to a DRM driver.
> >>>
> >>> I'm sorry RTSM is half/half. Not my fault. I can't fix...
> >> I do not know the platform, so I  I have dug little bit, but I wan't
> >> call it  thorough research. Just please be kind if I wrote sth stupid.
> >> What I have found:
> >> 1. DTS shows CLCD is pl111.
> >> 2. pl111 documentation says it's output interface supports STN and TFT
> >> up to 24-bit bus. I do not know STN, but TFT seems to be compatible with
> >> DPI.
> >>
> >> If it is correct, dpi panel seems to be OK. And I think it is less
> >> important how the emulator works, more important is that it should
> >> emulate pl111, including it's output interfaces.
> > Yeah, unfortunately that ship has sailed a long time ago. The emulator
> > people thought emulating the register interface is good enough and took
> > liberties on how the behaviour was "emulated". End result: output
> > interfaces are not the same.
> 
> So what is wrong/missing with dpi panel?

Linus explained in the links he quoted below. I'll let him add more if
he has additional information.

Best regards,
Liviu

> 
> Regards
> Andrzej
> 
> >
> > Best regards,
> > Liviu
> >
> >> Regards
> >> Andrzej
> >>>> And one more thing, you are defining virtual panel but you are using
> >>>> drm_bridge framework, why not drm_panel?
> >>> This was discussed before in the previous patch set:
> >>> https://lists.freedesktop.org/archives/dri-devel/2018-July/183516.html
> >>>
> >>> Essentially, it's because the display driver is just connected
> >>> to "something" not a panel and a bridge is likely the best I
> >>> can come up with - a bridge over to a virtual display.
> >>>
> >>> A patch to add "VGA", "SGA" and "XGA" to the simple panels
> >>> was NACKed (sort of, politely):
> >>> https://lists.freedesktop.org/archives/dri-devel/2018-July/183698.html
> >>>
> >>> Also it was noted that it would be nice to have something that
> >>> would make it easy to change resolutions on these virtual
> >>> display things. Voila.
> >>
> >>
> >>> Yours,
> >>> Linus Walleij
> >>>
> >>>
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2018-08-29 11:00 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20180824122324epcas3p2922f3e5415dacf4c89cfb136fa5c77b2@epcas3p2.samsung.com>
2018-08-24 12:23 ` [PATCH 1/2] drm/bridge: Add virtual display DT bindings Linus Walleij
2018-08-27 11:53   ` Andrzej Hajda
2018-08-28 13:45     ` Linus Walleij
2018-08-29  9:58       ` Andrzej Hajda
2018-08-29 10:01         ` Liviu Dudau
2018-08-29 10:23           ` Andrzej Hajda
2018-08-29 11:00             ` Liviu Dudau [this message]
2018-08-29 12:16               ` Andrzej Hajda
2018-10-16  9:40                 ` Linus Walleij
2018-10-16  9:33             ` Linus Walleij
2018-08-28 14:35     ` Liviu Dudau
2018-08-29  8:16       ` Andrzej Hajda
2018-08-29  8:51         ` Liviu Dudau

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=20180829110045.GN907@e110455-lin.cambridge.arm.com \
    --to=liviu.dudau@arm.com \
    --cc=Laurent.pinchart@ideasonboard.com \
    --cc=a.hajda@samsung.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=ryan.harkin@linaro.org \
    --cc=sudeep.holla@arm.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).