From: Daniel Vetter <daniel@ffwll.ch>
To: Inki Dae <inki.dae@samsung.com>
Cc: DRI mailing list <dri-devel@lists.freedesktop.org>
Subject: Re: How to support various hardware blocks in drm driver
Date: Tue, 18 Mar 2014 18:37:33 +0100 [thread overview]
Message-ID: <20140318173733.GG30571@phenom.ffwll.local> (raw)
In-Reply-To: <CAAQKjZPn=pP6YSzjGxQ6K4yZMSKL9sFjAJKPqKJk=b-z-TO=vA@mail.gmail.com>
On Tue, Mar 18, 2014 at 09:58:25PM +0900, Inki Dae wrote:
> 2014-03-18 21:47 GMT+09:00 Daniel Vetter <daniel@ffwll.ch>:
> > On Tue, Mar 18, 2014 at 1:42 PM, Inki Dae <inki.dae@samsung.com> wrote:
> >> I think now drm_bridge couldn't do what we want for embedded systems
> >> as long as drm_encoder has drm_bridge.
> >> See the blow hardware pipeline,
> >> Display Controller-----Image Enhancement chip-----MIP DSI-----MIPI TO
> >> LVDS Bridge-----LCD Panel
> >>
> >> In above hardware pipeline, Display controller is controlled by crtc,
> >> and Image Enhancement chip receives output from display controller.
> >> So the use of existing drm_bridge would be suitable to only bridge
> >> devices between MIPI DSI and LCD Panel, but not to Image Enhancement
> >> chip.
> >>
> >> For such hardware, drm_panel infrastructure is more reasonable to me,
> >> and that is why I try to integrate drm_panel and drm_bridge to one
> >> integrated framework which has infrastructure same as existing
> >> drm_panel.
> >> The important thing is to free this integrated framework from
> >> drm_encoder so that crtc device can also use this framework.
> >
> > Hm, what is this image enhancement chip? Is that some IP block on the
> > SoC? Is it optional? Can it be attached to different crtcs?
>
> In case of Exynos, this chip is in SoC, and can be only attached to
> one crtc, display controller. But I'm not sure other SoC have similar
> chip.
>
> >
> > I think we have similar things on intel hardware, but without details
> > on what it does and how it works I can't really say how to best expose
> > it to userspace and how to best handle it internally in the driver.
> > -Daniel
>
> Simply saying, the image enhancement chip can enhance image data from
> display controller, i.e. saturation enhancement, color reproduction,
> dithering, and so on.
> And this chip receives image data through hardware wired lines
> connected internally between display controller and this chip.
To me this sounds like you simply need to expose all these capabilities to
userspace as crtc properties. Which addresses one part of this issue.
The other side is how you are going to track this in the driver, and there
you can do whatever you want - just add a pointer/structure to the exynos
crtc structure for the display enhancement block.
The MIPI DSI block would then be treated as a drm_encoder, and all the
later stages as drm_bridges up to the very last (the actual lvds panel)
which would be a simple drm_panel.
I don't really see what additional complexity you need here. Especially
since this image enhancer is on your SoC (and I guess a samgsung IP block
not shared with any other SoC manufacture) you can easily keep the driver
code for it in the exynos driver. So really no need to have a generic
interface here.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
next prev parent reply other threads:[~2014-03-18 17:37 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-18 8:26 How to support various hardware blocks in drm driver Inki Dae
2014-03-18 10:27 ` Daniel Vetter
2014-03-18 10:48 ` Inki Dae
2014-03-18 12:12 ` Rob Clark
2014-03-18 12:20 ` Daniel Vetter
2014-03-18 12:22 ` Daniel Vetter
2014-03-18 12:42 ` Inki Dae
2014-03-18 12:47 ` Daniel Vetter
2014-03-18 12:58 ` Inki Dae
2014-03-18 13:29 ` Rob Clark
2014-03-18 15:22 ` Inki Dae
2014-03-18 15:54 ` Rob Clark
2014-03-18 17:37 ` Daniel Vetter [this message]
2014-03-18 21:23 ` Dave Airlie
2014-03-19 4:21 ` Inki Dae
2014-03-19 4:07 ` Inki Dae
2014-03-19 4:11 ` Inki Dae
2014-03-19 10:05 ` Andrzej Hajda
2014-03-18 12:52 ` Rob Clark
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=20140318173733.GG30571@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=inki.dae@samsung.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.