Re: [PATCH v2 11/11] drm/exynos: remove struct exynos_drm_encoder layer

From: Daniel Vetter <daniel@ffwll.ch>
To: Inki Dae <inki.dae@samsung.com>
Cc: linux-samsung-soc@vger.kernel.org,
	dri-devel@lists.freedesktop.org, tjakobi@math.uni-bielefeld.de,
	Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Subject: Re: [PATCH v2 11/11] drm/exynos: remove struct exynos_drm_encoder layer
Date: Tue, 11 Aug 2015 17:03:08 +0200	[thread overview]
Message-ID: <20150811150308.GZ17734@phenom.ffwll.local> (raw)
In-Reply-To: <55C9E702.8060603@samsung.com>

On Tue, Aug 11, 2015 at 09:13:54PM +0900, Inki Dae wrote:
> On 2015년 08월 11일 09:38, Gustavo Padovan wrote:
> > Hi Inki,
> > 
> > 2015-08-07 Inki Dae <inki.dae@samsung.com>:
> > 
> >> Hi Gustavo,
> >>
> >> On 2015년 08월 06일 22:31, Gustavo Padovan wrote:
> >>> From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
> >>>
> >>> struct exynos_drm_encoder was justing wrapping struct drm_encoder, it had
> >>> only a drm_encoder member and the internal exynos_drm_encoders ops that
> >>> was directly mapped to the drm_encoder helper funcs.
> >>>
> >>> So now exynos DRM uses struct drm_encoder directly, this removes
> >>> completely the struct exynos_drm_encoder.
> >>>
> >>
> >> Trats2 board, which uses Exynos4412 Soc, doesn't work after this patch
> >> is applied. Below is the booting logs,
> >> [    1.171318] console [ttySAC2] enabled
> >> [    1.175522] 13830000.serial: ttySAC3 at MMIO 0x13830000 (irq = 60,
> >> base_baud = 0) is a S3C6400/10
> >> [    1.185545] [drm] Initialized drm 1.1.0 20060810
> >> [    1.194104] exynos-drm exynos-drm: bound 11c00000.fimd (ops
> >> fimd_component_ops)
> >> [    1.200352] exynos-drm exynos-drm: bound 11c80000.dsi (ops
> >> exynos_dsi_component_ops)
> >> [    1.207688] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> >> [    1.214313] [drm] No driver support for vblank timestamp query.
> >> [    1.220218] [drm] Initialized exynos 1.0.0 20110530 on minor 0
> >>
> >> Booting is locked up here. This patch looks good to me so I tried to
> >> find why locked up and I found the booting is locked up as soon as
> >> console_lock function is called. Can you and other guys look into this
> >> issue?
> > 
> > I've realized that I left a fix for patch 01 behind, it could be the
> > cause of this issue. I've just resent this patch with the added v2 fix
> > up.
> 
> With above change, still locked up. So your updated patch doesn't
> resolve this issue.
> 
> Anyway, I tested it with fbdev emulation relevant patch series[1] and
> the booting was ok with disabling fbdev emulation as Daniel commented.
> However, I think the booting should also be ok with fbdev emulation so I
> don't want for your last patch to be merged to mainline until the issue
> is resolved.

Without fbdev you need to start a kms client (X, whatever) to force a
modeset. Otherwise you won't reproduce anything. And sometimes it requires
a bit of trickery to create a sequence of modeset calls which exactly
match what fbcon would do.
-Daniel

> 
> [1] http://www.spinics.net/lists/dri-devel/msg86617.html
>     http://lists.freedesktop.org/archives/dri-devel/2015-March/078975.html
> 
> Thanks,
> Inki Dae
> 
> > 
> > 	Gustavo
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > 
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel