[Bug 75276] Implement VGPR Register Spilling
https://bugs.freedesktop.org/show_bug.cgi?id=75276 Michel Dänzer changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #63 from Michel Dänzer --- Great plan. :) Awesome work, Tom! -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150206/0c4cc53b/attachment.html>
[Bug 73320] [radeonsi] LLVM runs out of registers during register allocation in Painkiller Hell & Damnation
https://bugs.freedesktop.org/show_bug.cgi?id=73320 Bug 73320 depends on bug 75276, which changed state. Bug 75276 Summary: Implement VGPR Register Spilling https://bugs.freedesktop.org/show_bug.cgi?id=75276 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150206/5d779f28/attachment.html>
[Bug 75005] "Upvoid" segfault in radeonsi/llvm
https://bugs.freedesktop.org/show_bug.cgi?id=75005 Bug 75005 depends on bug 75276, which changed state. Bug 75276 Summary: Implement VGPR Register Spilling https://bugs.freedesktop.org/show_bug.cgi?id=75276 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150206/ed562a54/attachment.html>
[Bug 75211] radeonsi/llvm SIGABRT in Antichamber (UDK)
https://bugs.freedesktop.org/show_bug.cgi?id=75211 Bug 75211 depends on bug 75276, which changed state. Bug 75276 Summary: Implement VGPR Register Spilling https://bugs.freedesktop.org/show_bug.cgi?id=75276 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150206/ef924a48/attachment-0001.html>
[Bug 75361] freeze in Mass Effect 3 (wine)
https://bugs.freedesktop.org/show_bug.cgi?id=75361 Bug 75361 depends on bug 75276, which changed state. Bug 75276 Summary: Implement VGPR Register Spilling https://bugs.freedesktop.org/show_bug.cgi?id=75276 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150206/c6e42597/attachment-0001.html>
[Bug 86635] Live for Speed and gallium nine, missing objects
https://bugs.freedesktop.org/show_bug.cgi?id=86635 David Heidelberg (okias) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from David Heidelberg (okias) --- Fix is included in mesa upstream repository :) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150206/bfcbcefd/attachment.html>
[Bug 85696] r600g+nine: Bioshock shader failure after 7b1c0cbc90d456384b0950ad21faa3c61a6b43ff
https://bugs.freedesktop.org/show_bug.cgi?id=85696 David Heidelberg (okias) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from David Heidelberg (okias) --- Fixed in mesa repository by commit 6a8e5e48be0bad4606b2d5d7ba736a3d2a277c55 . Closing. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150206/b3f68c0c/attachment.html>
[PATCH 12/12] ARM: shmobile: koelsch: Add DU HDMI output support
[CC Damian, Magnus] On Mon, Oct 27, 2014 at 02:12:56PM +0200, Laurent Pinchart wrote: > Hi Simon, > > On Monday 27 October 2014 09:38:29 Simon Horman wrote: > > On Wed, Sep 24, 2014 at 11:04:32PM +0300, Laurent Pinchart wrote: > > > Add DT nodes for the ADV7511 HDMI encoder and its HDMI output connector > > > and configure the DISP pin group that drives the HDMI transmitter DE > > > pin. > > > > > > Signed-off-by: Laurent Pinchart > > > > > > > Acked-by: Simon Horman > > > > Please be careful of any conflicts that may arise if this patch > > doesn't go through my renesas tree. > > I think it would be best if the patch went through your tree. There's no > compile time or runtime dependency on the DU HDMI code, so as soon as the > ADV7511 DT bindings get accepted I plan to ask you to merge this patch. Hi Laurent, I'd like to enquire about the status of this change as Damian has asked me about it. It seems that I could pick this up for v3.21 as the bindings seem to be in v3.19-rc1. But perhaps events have overtaken the discussion above which was some months ago now.
[Bug 88658] (bisected) Slow video playback on Kabini
https://bugs.freedesktop.org/show_bug.cgi?id=88658 Michel Dänzer changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from Michel Dänzer --- Module: Mesa Branch: master Commit: a338dc01866ce50bf7555ee8dc08491c7f63b585 URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=a338dc01866ce50bf7555ee8dc08491c7f63b585 Author: Michel Dänzer Date: Thu Feb 5 12:46:04 2015 +0900 st/mesa: Don't use PIPE_USAGE_STREAM for GL_PIXEL_UNPACK_BUFFER_ARB -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150206/8b8f0d58/attachment.html>
[Bug 84648] Lag/Pause When VRAM->GTT or GTT->VRAM transfer occur
https://bugs.freedesktop.org/show_bug.cgi?id=84648 --- Comment #8 from Michel Dänzer --- Does http://cgit.freedesktop.org/mesa/mesa/commit/?id=a338dc01866ce50bf7555ee8dc08491c7f63b585 help? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150206/106fed5d/attachment.html>
[Bug 84662] Long pauses with Unreal demo Elemental on R9270X since : Always flush the HDP cache before submitting a CS to the GPU
https://bugs.freedesktop.org/show_bug.cgi?id=84662 --- Comment #55 from Michel Dänzer --- Does http://cgit.freedesktop.org/mesa/mesa/commit/?id=a338dc01866ce50bf7555ee8dc08491c7f63b585 help for this by any chance? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150206/4661438c/attachment-0001.html>
X using radeon is refusing to start
On 06.02.2015 09:10, Andy Lutomirski wrote: > I just started getting X failures that say: > > [ 739.208] (EE) RADEON(0): [drm] failed to set drm interface version. > > I'm not sure what triggered it. > > dmesg says: > > [ 740.156499] [drm:drm_stub_open] > [ 740.156502] [drm:drm_open_helper] pid = 2170, minor = 0 > [ 740.156541] [drm:drm_ioctl] pid=2170, dev=0xe200, auth=1, > DRM_IOCTL_MODE_GETRESOURCES > [ 740.156557] [drm:drm_ioctl] pid=2170, dev=0xe200, auth=1, > DRM_IOCTL_MODE_GETRESOURCES > [ 740.156575] [drm:drm_release] open_count = 2 > [ 740.156577] [drm:drm_release] pid = 2170, device = 0xe200, open_count = 2 > [ 740.158548] [drm:drm_ioctl] pid=2170, dev=0xe200, auth=1, > DRM_IOCTL_SET_VERSION > [ 740.158549] [drm:drm_ioctl] ret = -13 > [ 740.159612] [drm:drm_framebuffer_reference] 8804457110a0: FB ID: 83 (3) > > -13 means -EACCES. We'd need to see dmesg from the beginning to be sure, but it looks like something (maybe plymouth or whatever boot splash you're using?) is keeping the DRM device open, so Xorg doesn't become DRM master. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
[Bug 88561] [radeonsi][regression, bisected] Depth test/buffer issues in Portal
https://bugs.freedesktop.org/show_bug.cgi?id=88561 Michel Dänzer changed: What|Removed |Added Attachment #113176|text/plain |image/jpeg mime type|| -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150206/8b3c4d67/attachment.html>
[Bug 88642] Trilinear sampling on cubemap wrongly sampled at the border of rasterized triangle on HAWAII
https://bugs.freedesktop.org/show_bug.cgi?id=88642 Michel Dänzer changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Michel Dänzer --- Author: daenzer Date: Thu Feb 5 20:51:20 2015 New Revision: 228372 URL: http://llvm.org/viewvc/llvm-project?rev=228372&view=rev Log: R600/SI: Also enable WQM for image opcodes which calculate LOD v3 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150206/c7c80365/attachment.html>
[PATCH 04/14] drm/exynos: remove struct *_win_data abstraction on planes
Hi, On 02/05/2015 10:06 PM, Daniel Vetter wrote: > On Thu, Feb 05, 2015 at 12:48:07PM +, Daniel Stone wrote: >> Hi, >> >> On 5 February 2015 at 12:26, Rob Clark wrote: >>> On Thu, Feb 5, 2015 at 4:15 AM, Daniel Vetter wrote: Yeah I noticed the zpos fun when hacking around too. Exynos should probably switch defaults so that overlays are visible by default. And we need to standardize the zpos property so that other drivers can use it too. >>> >>> jfyi, I have a bit of logic in mdp5_crtc_atomic_check() (and really >>> mdp4 probably needs the same) to sort attached planes and derive the >>> actual hw zpos (with each layer having a unique zpos).. >>> >>> I suspect most hw will end up needing the same (ie. dislike having two >>> overlays at same zpos), so might not be a horrible idea to make the >>> atomic helpers do this sorting for us.. > > Oh yeah such a helper would be nice. Especially since on intel hw flipping > planes around means fishing the right value out of some enum table ;-) > So some sort of helper to compute the absolute ordering in a stable way > would be nice. > >> Same with Exynos, except it's a bit funnier still. In terms of its >> hardware, each CRTC has a number of planes which have a fixed zpos. >> The reason exynos_drm exposes zpos is because it sets up a fixed >> number of planes for the entire device and declares they can run >> across every single CRTC, and then works out from the combination of >> CRTC assignment and zpos property, which hardware plane to assign it >> to. This includes the primary, so if you accidentally get zpos==0 in >> there, then you smash the primary plane. Or set a duplicate zpos and >> then the last one in wins. >> >> It also means if you're using multiple CRTCs (e.g. FIMD for internal >> panel plus mixer for external HDMI), then you can only use 5 planes in >> total, rather than 5 planes per head. (And let's not forget that each >> backend has disjoint format support, so again the driver just lies to >> you and claims to support them all, with a silent fallback via a >> default case statement when the format isn't actually supported. >> Whoops.) >> >> I think a more ideal setup would be a much more direct 1:1 mapping >> with the hardware, where each actual plane on each actual CRTC gets >> exposed directly to userspace, perhaps with a fixed/read-only zpos >> property to tell the userspace which plane it's actually configuring. >> I suspect this would be a pretty good map to other hardware as well. > > Hm that sounds indeed a bit funny. I agree that exynos should split planes > into per-crtc and separate the code and capability tables out so that > there's less lying. And zpos should probably be converted to a read-only > property to tell userspace about the facts, instead of doing something > funny behind the scenes. I agree, it seems be time to convert each planes have unique zpos. Thanks.
[PATCH 4/4] drm/exynos: fix NULL pointer reference
Hi, On 02/05/2015 10:07 PM, Gustavo Padovan wrote: > Hi, > > > 2015-02-05 Joonyoung Shim : > >> There is a case called disable_plane callback function even if >> plane->crtc is NULL from exynos_drm_encoder_disable and it will cause >> NULL pointer reference error. >> >> Signed-off-by: Joonyoung Shim >> --- >> drivers/gpu/drm/exynos/exynos_drm_encoder.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) > > You need to merge this patch with patch 3 or you will break the bisect. > The NULL pointer is introduced by the previous patch, so fix it in the same > patch. > Yeah, it is revealed by patch 3 but it was original problem from before patch 3. How about apply this patch earlier than patch 3? > Once that is fixed: > > Reviewed-by: Gustavo Padovan > Thanks for review.
[PATCH 1/4] drm/exynos: Remove exynos_plane_dpms() call with no effect
Hi, On 02/05/2015 06:40 PM, Daniel Vetter wrote: > On Thu, Feb 05, 2015 at 04:11:35PM +0900, Joonyoung Shim wrote: >> From: Gustavo Padovan >> >> exynos_plane_dpms(DRM_MODE_DPMS_ON) calls the win_enable()'s callback >> from the underlying layer. However neither one of these layers implement >> win_enable() - FIMD, Mixer and VIDI. Thus the call to exynos_plane_dpms() >> is pointless. >> >> Signed-off-by: Gustavo Padovan > > I guess you want to apply this patch after patch 2&3 for bisecting. But Yeah, but i just applied this than modify original patch. > makes sense otherwise. For the entire series: > > Acked-by: Daniel Vetter Thanks. >> --- >> drivers/gpu/drm/exynos/exynos_drm_crtc.c | 2 -- >> 1 file changed, 2 deletions(-) >> >> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c >> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c >> index a85c451..fff2e55 100644 >> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c >> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c >> @@ -66,8 +66,6 @@ static void exynos_drm_crtc_commit(struct drm_crtc *crtc) >> >> if (exynos_crtc->ops->commit) >> exynos_crtc->ops->commit(exynos_crtc); >> - >> -exynos_plane_dpms(crtc->primary, DRM_MODE_DPMS_ON); >> } >> >> static bool >> -- >> 1.9.1 >> >
[PATCH 1/4] drm/exynos: remove struct *_win_data abstraction on planes
Hi Gustavo,
On 02/06/2015 02:59 AM, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> struct {fimd,mixer,vidi}_win_data was just keeping the same data
> as struct exynos_drm_plane thus get ride of it and use exynos_drm_plane
> directly.
>
> It changes how planes are created and remove .win_mode_set() callback
> that was only filling all *_win_data structs.
>
OK, let's go ahead this with next zpos problem fix.
> Signed-off-by: Gustavo Padovan
> ---
> drivers/gpu/drm/exynos/exynos_drm_crtc.c | 9 +-
> drivers/gpu/drm/exynos/exynos_drm_crtc.h | 1 +
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 14 --
> drivers/gpu/drm/exynos/exynos_drm_drv.h | 5 +-
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 182 ++---
> drivers/gpu/drm/exynos/exynos_drm_plane.c | 20 +--
> drivers/gpu/drm/exynos/exynos_drm_plane.h | 6 +-
> drivers/gpu/drm/exynos/exynos_drm_vidi.c | 123 +
> drivers/gpu/drm/exynos/exynos_mixer.c | 212
> +++---
> 9 files changed, 183 insertions(+), 389 deletions(-)
>
[snip]
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index 736269a..6e7c0cc 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -37,34 +37,13 @@
>
> #include "exynos_drm_drv.h"
> #include "exynos_drm_crtc.h"
> +#include "exynos_drm_plane.h"
> #include "exynos_drm_iommu.h"
> #include "exynos_mixer.h"
>
> #define MIXER_WIN_NR 3
> #define MIXER_DEFAULT_WIN0
>
> -struct hdmi_win_data {
> - dma_addr_t dma_addr;
> - dma_addr_t chroma_dma_addr;
> - uint32_tpixel_format;
> - unsigned intbpp;
> - unsigned intcrtc_x;
> - unsigned intcrtc_y;
> - unsigned intcrtc_width;
> - unsigned intcrtc_height;
> - unsigned intfb_x;
> - unsigned intfb_y;
> - unsigned intfb_width;
> - unsigned intfb_height;
> - unsigned intsrc_width;
> - unsigned intsrc_height;
> - unsigned intmode_width;
> - unsigned intmode_height;
> - unsigned intscan_flags;
> - boolenabled;
> - boolresume;
> -};
> -
> struct mixer_resources {
> int irq;
> void __iomem*mixer_regs;
> @@ -88,6 +67,7 @@ struct mixer_context {
> struct device *dev;
> struct drm_device *drm_dev;
> struct exynos_drm_crtc *crtc;
> + struct exynos_drm_plane planes[MIXER_WIN_NR];
> int pipe;
> boolinterlace;
> boolpowered;
> @@ -97,7 +77,6 @@ struct mixer_context {
>
> struct mutexmixer_mutex;
> struct mixer_resources mixer_res;
> - struct hdmi_win_datawin_data[MIXER_WIN_NR];
> enum mixer_version_id mxr_ver;
> wait_queue_head_t wait_vsync_queue;
> atomic_twait_vsync_event;
> @@ -401,7 +380,7 @@ static void vp_video_buffer(struct mixer_context *ctx,
> int win)
> {
> struct mixer_resources *res = &ctx->mixer_res;
> unsigned long flags;
> - struct hdmi_win_data *win_data;
> + struct exynos_drm_plane *plane;
> unsigned int x_ratio, y_ratio;
> unsigned int buf_num = 1;
> dma_addr_t luma_addr[2], chroma_addr[2];
> @@ -409,9 +388,9 @@ static void vp_video_buffer(struct mixer_context *ctx,
> int win)
> bool crcb_mode = false;
> u32 val;
>
> - win_data = &ctx->win_data[win];
> + plane = &ctx->planes[win];
>
> - switch (win_data->pixel_format) {
> + switch (plane->pixel_format) {
> case DRM_FORMAT_NV12MT:
> tiled_mode = true;
> case DRM_FORMAT_NV12:
> @@ -421,35 +400,35 @@ static void vp_video_buffer(struct mixer_context *ctx,
> int win)
> /* TODO: single buffer format NV12, NV21 */
> default:
> /* ignore pixel format at disable time */
> - if (!win_data->dma_addr)
> + if (!plane->dma_addr[0])
> break;
>
> DRM_ERROR("pixel format for vp is wrong [%d].\n",
> - win_data->pixel_format);
> + plane->pixel_format);
> return;
> }
>
> /* scaling feature: (src << 16) / dst */
> - x_ratio = (win_data->src_width << 16) / win_data->crtc_width;
> - y_ratio = (win_data->src_height << 16) / win_data->crtc_height;
> + x_ratio = (plane->src_width << 16) / plane->crtc_width;
> + y_ratio = (plane->src_height << 16) / plane->crtc_height;
>
> if (buf_num == 2) {
> - luma_addr[0] = win_data->dma_addr;
> - chroma_addr[0] = win_data->chroma_dma_addr;
> + luma_
[PATCH 2/4] drm/exynos: preset zpos value for overlay planes
Hi,
On 02/06/2015 02:59 AM, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Usually userspace don't want to have two overlay planes on the same zpos
> so this change assign a different zpos for each plane. Before this change
> a zpos of value zero was created for all planes so the userspace had to
> set up the zpos of every plane it wanted to use.
>
Plane zpos should be read-only. If not, it can't do 1:1 mapping plane
and hw overlay. Let's make zpos to DRM_MODE_PROP_IMMUTABLE property.
Thanks.
> Signed-off-by: Gustavo Padovan
> ---
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 +-
> drivers/gpu/drm/exynos/exynos_drm_plane.c | 15 ---
> drivers/gpu/drm/exynos/exynos_drm_plane.h | 3 ++-
> drivers/gpu/drm/exynos/exynos_drm_vidi.c | 2 +-
> drivers/gpu/drm/exynos/exynos_mixer.c | 2 +-
> 5 files changed, 13 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 489ce90..b49b038 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -1006,7 +1006,7 @@ static int fimd_bind(struct device *dev, struct device
> *master, void *data)
> type = (zpos == ctx->default_win) ? DRM_PLANE_TYPE_PRIMARY :
> DRM_PLANE_TYPE_OVERLAY;
> exynos_plane_init(drm_dev, &ctx->planes[zpos], 1 << ctx->pipe,
> - type);
> + type, zpos);
> }
>
> ret = fimd_ctx_initialize(ctx, drm_dev);
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c
> b/drivers/gpu/drm/exynos/exynos_drm_plane.c
> index 011a9b1..4c33e04 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
> @@ -211,7 +211,7 @@ static struct drm_plane_funcs exynos_plane_funcs = {
> .set_property = exynos_plane_set_property,
> };
>
> -static void exynos_plane_attach_zpos_property(struct drm_plane *plane)
> +static void exynos_plane_attach_zpos_property(struct drm_plane *plane, int
> zpos)
> {
> struct drm_device *dev = plane->dev;
> struct exynos_drm_private *dev_priv = dev->dev_private;
> @@ -227,12 +227,13 @@ static void exynos_plane_attach_zpos_property(struct
> drm_plane *plane)
> dev_priv->plane_zpos_property = prop;
> }
>
> - drm_object_attach_property(&plane->base, prop, 0);
> + drm_object_attach_property(&plane->base, prop, zpos);
> }
>
> int exynos_plane_init(struct drm_device *dev,
> struct exynos_drm_plane *exynos_plane,
> - unsigned long possible_crtcs, enum drm_plane_type type)
> + unsigned long possible_crtcs, enum drm_plane_type type,
> + int zpos)
> {
> int err;
>
> @@ -244,10 +245,10 @@ int exynos_plane_init(struct drm_device *dev,
> return err;
> }
>
> - if (type == DRM_PLANE_TYPE_PRIMARY)
> - exynos_plane->zpos = DEFAULT_ZPOS;
> - else
> - exynos_plane_attach_zpos_property(&exynos_plane->base);
> + exynos_plane->zpos = zpos;
> +
> + if (type == DRM_PLANE_TYPE_OVERLAY)
> + exynos_plane_attach_zpos_property(&exynos_plane->base, zpos);
>
> return 0;
> }
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.h
> b/drivers/gpu/drm/exynos/exynos_drm_plane.h
> index d8a3494..d8a66b5 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_plane.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_plane.h
> @@ -22,4 +22,5 @@ int exynos_update_plane(struct drm_plane *plane, struct
> drm_crtc *crtc,
> uint32_t src_w, uint32_t src_h);
> int exynos_plane_init(struct drm_device *dev,
> struct exynos_drm_plane *exynos_plane,
> - unsigned long possible_crtcs, enum drm_plane_type type);
> + unsigned long possible_crtcs, enum drm_plane_type type,
> + int zpos);
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> index f33974e..e545a58 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> @@ -478,7 +478,7 @@ static int vidi_bind(struct device *dev, struct device
> *master, void *data)
> type = (zpos == ctx->default_win) ? DRM_PLANE_TYPE_PRIMARY :
> DRM_PLANE_TYPE_OVERLAY;
> exynos_plane_init(drm_dev, &ctx->planes[zpos], 1 << ctx->pipe,
> - type);
> + type, zpos);
> }
>
> vidi_ctx_initialize(ctx, drm_dev);
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index 6e7c0cc..141d461 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -1177,7 +1177,7 @@ static int mi
[PATCH 4/4] drm/exynos: remove checks for zpos == -1 on primary planes
Hi,
On 02/06/2015 02:59 AM, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> The primary plane default zpos is now 0, so remove checks for zpos ==
> -1. We don't need to set win to 0 anymore it is already zero.
>
Could you also remove DEFAULT_ZPOS define? And zpos and win should be
unsigned from now.
Thanks.
> Signed-off-by: Gustavo Padovan
> ---
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 6 --
> drivers/gpu/drm/exynos/exynos_drm_vidi.c | 6 --
> drivers/gpu/drm/exynos/exynos_mixer.c| 6 ++
> 3 files changed, 2 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 00df40d..7637780 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -612,9 +612,6 @@ static void fimd_win_commit(struct exynos_drm_crtc *crtc,
> int win)
> if (ctx->suspended)
> return;
>
> - if (win == DEFAULT_ZPOS)
> - win = ctx->default_win;
> -
> if (win < 0 || win >= WINDOWS_NR)
> return;
>
> @@ -735,9 +732,6 @@ static void fimd_win_disable(struct exynos_drm_crtc
> *crtc, int win)
> struct fimd_context *ctx = crtc->ctx;
> struct exynos_drm_plane *plane;
>
> - if (win == DEFAULT_ZPOS)
> - win = ctx->default_win;
> -
> if (win < 0 || win >= WINDOWS_NR)
> return;
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> index 3c0dcb4..e730ef6 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> @@ -125,9 +125,6 @@ static void vidi_win_commit(struct exynos_drm_crtc *crtc,
> int win)
> if (ctx->suspended)
> return;
>
> - if (win == DEFAULT_ZPOS)
> - win = ctx->default_win;
> -
> if (win < 0 || win >= WINDOWS_NR)
> return;
>
> @@ -146,9 +143,6 @@ static void vidi_win_disable(struct exynos_drm_crtc
> *crtc, int win)
> struct vidi_context *ctx = crtc->ctx;
> struct exynos_drm_plane *plane;
>
> - if (win == DEFAULT_ZPOS)
> - win = ctx->default_win;
> -
> if (win < 0 || win >= WINDOWS_NR)
> return;
>
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index 141d461..b283713 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -892,10 +892,9 @@ static void mixer_disable_vblank(struct exynos_drm_crtc
> *crtc)
> mixer_reg_writemask(res, MXR_INT_EN, 0, MXR_INT_EN_VSYNC);
> }
>
> -static void mixer_win_commit(struct exynos_drm_crtc *crtc, int zpos)
> +static void mixer_win_commit(struct exynos_drm_crtc *crtc, int win)
> {
> struct mixer_context *mixer_ctx = crtc->ctx;
> - int win = zpos == DEFAULT_ZPOS ? MIXER_DEFAULT_WIN : zpos;
>
> DRM_DEBUG_KMS("win: %d\n", win);
>
> @@ -914,11 +913,10 @@ static void mixer_win_commit(struct exynos_drm_crtc
> *crtc, int zpos)
> mixer_ctx->planes[win].enabled = true;
> }
>
> -static void mixer_win_disable(struct exynos_drm_crtc *crtc, int zpos)
> +static void mixer_win_disable(struct exynos_drm_crtc *crtc, int win)
> {
> struct mixer_context *mixer_ctx = crtc->ctx;
> struct mixer_resources *res = &mixer_ctx->mixer_res;
> - int win = zpos == DEFAULT_ZPOS ? MIXER_DEFAULT_WIN : zpos;
> unsigned long flags;
>
> DRM_DEBUG_KMS("win: %d\n", win);
>
[RFC PATCH 0/3] Fix power domains handling on exynos542x
Hi, On 02/05/2015 11:45 PM, Javier Martinez Canillas wrote: > Hello Andrzej, > > Thanks a lot for finally finding what was causing the HDMI issue. > > On 02/05/2015 01:35 PM, Andrzej Hajda wrote: >> Hi, >> >> Exynos chipsets since 542x have asynchronous bridges connecting different >> IPs. >> These bridges should be operational during power domain switching, ie >> associated >> clocks cannot be gated. >> This patchset adds binding to provide such clocks per power domain and adds >> code >> which enables them during domain on/off operation. >> >> This patchset fixes power domain issues with disp1 domain and HDMI (some of >> them) >> on Odroid XU3: >> - disp1 power domain can be turned off, >> - no more "imprecise external abort" faults. >> >> The patchset is based on '[PATCH v5 0/9] Enable HDMI support on Exynos >> platforms' [1]. >> > > It also depends on '[PATCH 0/2] Add HDMI support for Exynos5420 platform' [2]. > >> It was successfully tested on OdroidXU3. >> >> [1]: http://permalink.gmane.org/gmane.linux.kernel.samsung-soc/42743 > > Your patches looks good to me so please feel free to add: > > Reviewed-by: Javier Martinez Canillas > > I also tested on an Exynos5420 Peach Pit Chromebook and both the "Power > domain power-domain disable failed" message and the system crash are gone. > Really gone out "Power domain power-domain disable failed" message? Still i get the message from second try, # modetest -M exynos -s 23 at 21:1920x1080 setting mode 1920x1080 at XR24 on connectors 23, crtc 21 # modetest -M exynos -s 23 at 21:1920x1080 setting mode 1920x1080 at XR24 on connectors 23, crtc 21 [ 39.608881] Power domain power-domain disable failed # modetest -M exynos -s 23 at 21:1920x1080 setting mode 1920x1080 at XR24 on connectors 23, crtc 21 [ 42.827637] Power domain power-domain disable failed ... Thanks. > Tested-by: Javier Martinez Canillas > > Best regards, > Javier > > [2]: https://lkml.org/lkml/2015/1/20/235 > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
[PATCH -next] drm/nouveau/clk: Use plain "/" for 32-bit division
Hi Geert, On 02/05/2015 01:02 AM, Geert Uytterhoeven wrote: > On 32-bit platforms using asm-generic/div64.h: > > drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c: In function > 'gk20a_pllg_calc_rate': > drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c:147:79: warning: comparison > of distinct pointer types lacks a cast >do_div(rate, divider); > > ^ > drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c:147:2: warning: right shift > count >= width of type >do_div(rate, divider); >^ > drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c:147:238: warning: passing > argument 1 of '__div64_32' from incompatible pointer type >do_div(rate, divider); > > > > ^ > In file included from arch/parisc/include/generated/asm/div64.h:1:0, > from include/linux/kernel.h:124, > from include/linux/list.h:8, > from include/linux/preempt.h:10, > from include/linux/spinlock.h:50, > from include/linux/mmzone.h:7, > from include/linux/gfp.h:5, > from include/linux/slab.h:14, > from drivers/gpu/drm/nouveau/include/nvif/os.h:5, > from drivers/gpu/drm/nouveau/include/nvkm/core/os.h:3, > from drivers/gpu/drm/nouveau/include/nvkm/core/object.h:3, > from drivers/gpu/drm/nouveau/include/nvkm/core/subdev.h:3, > from drivers/gpu/drm/nouveau/include/nvkm/subdev/clk.h:3, > from drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c:25: > include/asm-generic/div64.h:35:17: note: expected 'uint64_t *' but argument > is of type 'u32 *' > extern uint32_t __div64_32(uint64_t *dividend, uint32_t divisor); > ^ > > do_div() is meant for 64-bit by 32-bit division, but both the dividend > and divisor are 32-bit here. Hence use plain "/" instead. > > Signed-off-by: Geert Uytterhoeven > --- > Compile-tested only. > > parisc/allmodconfig: > http://kisskb.ellerman.id.au/kisskb/buildresult/12358386/ > --- > drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c > b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c > index 65c532742b08d1c6..022595876ea4dc85 100644 > --- a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c > +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c > @@ -144,9 +144,8 @@ gk20a_pllg_calc_rate(struct gk20a_clk_priv *priv) > > rate = priv->parent_rate * priv->n; > divider = priv->m * pl_to_div[priv->pl]; > - do_div(rate, divider); > > - return rate / 2; > + return rate / divider / 2; I agree there is a problem here, but considering the theoretical values that rate can take, could we rather fix this by making rate a u64? With the current maximum values of priv->parent_rate and priv->n, rate might approach dangerously to the u32 limit and I believe casting it to u64 would be safer.
[Bug 86635] Live for Speed and gallium nine, missing objects
https://bugs.freedesktop.org/show_bug.cgi?id=86635 --- Comment #9 from Balázs Vinarz --- you are awesome! day by day im getting closer to leave my dual-boot system :) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150206/606054b9/attachment.html>
[PULL] topic/drm-misc
Hi Dave, Flushing out my drm-misc queue with a few oddball things all over. Cheers, Daniel The following changes since commit b7703726251191cd9f3ef3a80b2d9667901eec95: drm/probe-helper: clamp unknown connector status in the poll work (2015-01-22 06:11:39 +0100) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/topic/drm-misc-2015-02-06 for you to fetch changes up to 335f1a62c5a6334c4fc92c3c448d7648408d9b83: drm: Use static attribute groups for managing connector sysfs entries (2015-02-04 15:02:00 +0100) Daniel Vetter (1): drm: remove DRM_FORMAT_NV12MT Laurent Pinchart (1): drm/irq: Don't disable vblank interrupts when already disabled Takashi Iwai (1): drm: Use static attribute groups for managing connector sysfs entries Ville Syrjälä (1): drm/modes: Print the mode status in human readable form drivers/gpu/drm/drm_irq.c | 11 ++- drivers/gpu/drm/drm_modes.c | 61 +- drivers/gpu/drm/drm_sysfs.c | 132 +++--- drivers/gpu/drm/exynos/exynos_drm_fimc.c | 14 +--- drivers/gpu/drm/exynos/exynos_drm_gsc.c | 6 -- drivers/gpu/drm/exynos/exynos_drm_plane.c | 1 - drivers/gpu/drm/exynos/exynos_mixer.c | 2 - include/uapi/drm/drm_fourcc.h | 3 - 8 files changed, 137 insertions(+), 93 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH] modetest: add connector names for missing kinds of connectors
Without the matched name for the connector types, modetest prints
invalid for that kinds of connectors like below:
Connectors:
id encoder status typesize (mm) modes encoders
16 15 connected (invalid) 71x125 1 15
So this patch adds connector names for missing kinds of connector types.
Signed-off-by: Hyungwon Hwang
---
tests/modetest/modetest.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 5fcf2a4..f5a973c 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -168,6 +168,8 @@ struct type_name connector_type_names[] = {
{ DRM_MODE_CONNECTOR_HDMIB, "HDMI-B" },
{ DRM_MODE_CONNECTOR_TV, "TV" },
{ DRM_MODE_CONNECTOR_eDP, "eDP" },
+ { DRM_MODE_CONNECTOR_VIRTUAL, "virtual" },
+ { DRM_MODE_CONNECTOR_DSI, "dsi" },
};
static type_name_fn(connector_type)
--
1.9.1
[PATCH -next] drm/nouveau/clk: Use plain "/" for 32-bit division
Hi Alexandre,
On Fri, Feb 6, 2015 at 7:50 AM, Alexandre Courbot
wrote:
> On 02/05/2015 01:02 AM, Geert Uytterhoeven wrote:
>> On 32-bit platforms using asm-generic/div64.h:
>> drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c: In function
>> 'gk20a_pllg_calc_rate':
>> drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c:147:79: warning:
>> comparison of distinct pointer types lacks a cast
>>do_div(rate, divider);
>>
>> ^
>> drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c:147:2: warning: right
>> shift count >= width of type
>>do_div(rate, divider);
>>^
>> drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c:147:238: warning: passing
>> argument 1 of '__div64_32' from incompatible pointer type
>>do_div(rate, divider);
>>
>> ^
>> In file included from arch/parisc/include/generated/asm/div64.h:1:0,
>> from include/linux/kernel.h:124,
>> from include/linux/list.h:8,
>> from include/linux/preempt.h:10,
>> from include/linux/spinlock.h:50,
>> from include/linux/mmzone.h:7,
>> from include/linux/gfp.h:5,
>> from include/linux/slab.h:14,
>> from drivers/gpu/drm/nouveau/include/nvif/os.h:5,
>> from drivers/gpu/drm/nouveau/include/nvkm/core/os.h:3,
>> from
>> drivers/gpu/drm/nouveau/include/nvkm/core/object.h:3,
>> from
>> drivers/gpu/drm/nouveau/include/nvkm/core/subdev.h:3,
>> from
>> drivers/gpu/drm/nouveau/include/nvkm/subdev/clk.h:3,
>> from drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c:25:
>> include/asm-generic/div64.h:35:17: note: expected 'uint64_t *' but
>> argument is of type 'u32 *'
>> extern uint32_t __div64_32(uint64_t *dividend, uint32_t divisor);
>> ^
>>
>> do_div() is meant for 64-bit by 32-bit division, but both the dividend
>> and divisor are 32-bit here. Hence use plain "/" instead.
>>
>> Signed-off-by: Geert Uytterhoeven
>> ---
>> Compile-tested only.
>>
>> parisc/allmodconfig:
>> http://kisskb.ellerman.id.au/kisskb/buildresult/12358386/
>> ---
>> drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c
>> b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c
>> index 65c532742b08d1c6..022595876ea4dc85 100644
>> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c
>> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c
>> @@ -144,9 +144,8 @@ gk20a_pllg_calc_rate(struct gk20a_clk_priv *priv)
>>
>> rate = priv->parent_rate * priv->n;
>> divider = priv->m * pl_to_div[priv->pl];
>> - do_div(rate, divider);
>>
>> - return rate / 2;
>> + return rate / divider / 2;
>
>
> I agree there is a problem here, but considering the theoretical values that
> rate can take, could we rather fix this by making rate a u64? With the
> current maximum values of priv->parent_rate and priv->n, rate might approach
> dangerously to the u32 limit and I believe casting it to u64 would be safer.
Yes, that's better.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at
linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH RFC v8 11/21] Documentation: dt-bindings: Add bindings for Synopsys DW MIPI DSI DRM bridge driver
On Thu, Feb 05, 2015 at 11:10:04AM +0100, Philipp Zabel wrote: > Am Mittwoch, den 31.12.2014, 16:23 +0800 schrieb Liu Ying: > > This patch adds device tree bindings for Synopsys DesignWare MIPI DSI > > host controller DRM bridge driver. > > > > Signed-off-by: Liu Ying > > --- > > v7->v8: > > * None. > > > > v6->v7: > > * None. > > > > v5->v6: > > * Add the #address-cells and #size-cells properties in the example 'ports' > >node. > > * Remove the useless input-port properties from the example port at 0 and > > port at 1 > >nodes. > > > > v4->v5: > > * None. > > > > v3->v4: > > * Newly introduced in v4. This is separated from the relevant driver patch > >in v3 to address Stefan Wahren's comment. > > > > .../devicetree/bindings/drm/bridge/dw_mipi_dsi.txt | 73 > > ++ > > 1 file changed, 73 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/drm/bridge/dw_mipi_dsi.txt > > > > diff --git a/Documentation/devicetree/bindings/drm/bridge/dw_mipi_dsi.txt > > b/Documentation/devicetree/bindings/drm/bridge/dw_mipi_dsi.txt > > new file mode 100644 > > index 000..f88a8d6 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/drm/bridge/dw_mipi_dsi.txt > > @@ -0,0 +1,73 @@ > > +Device-Tree bindings for Synopsys DesignWare MIPI DSI host controller > > + > > +The controller is a digital core that implements all protocol functions > > +defined in the MIPI DSI specification, providing an interface between > > +the system and the MIPI DPHY, and allowing communication with a MIPI DSI > > +compliant display. > > + > > +Required properties: > > + - #address-cells: Should be <1>. > > + - #size-cells: Should be <0>. > > + - compatible: The compatible string should be "fsl,imx6q-mipi-dsi" for > > + i.MX6q/sdl SoCs. For other SoCs, please refer to their specific > > + device tree binding documentations. > > I think the compatible property should additionally contain > "snps,dw-mipi-dsi". Also I think other SoCs using the same IP core > should eventually list their compatibles here, but that's for later. > > How about: > + - compatible: The compatible string contain "fsl,imx6q-mipi-dsi" for > + i.MX6q/sdl SoCs. For other SoCs, please refer to their specific > + device tree binding documentations. A common compatible string > + "snps,dw-mipi-dsi" should be appended for all SoCs. I'm not sure if "snps,dw-mipi-dsi" should be appended. Is it a compatible string that SoC specific drivers should actually use to bind a device? As Andy mentioned in [1], DW MIPI DSI embedded in RK618 is configured via I2C bus, while i.MX6Q/DL is configured via ARM bus... Another concern is that if users only specify "snps,dw-mipi-dsi" in their device tree sources and use a kernel which supports multiple platforms, say ARM multi v7 platforms, could several enabled SoC specific drivers be probed for a single DW MIPI DSI device? [1] http://lists.freedesktop.org/archives/dri-devel/2014-December/074344.html > > > + - reg: Represent the physical address range of the controller. > > + - interrupts: Represent the controller's interrupt to the CPU(s). > > + - clocks, clock-names: Phandles to the controller pll reference and > > + core configuration clocks, as described in [1]. > > From the MIPI CSI-2 datasheets it looks like the D-PHY has a refclk and > a cfg_clk input. So I suspect from the name of the "core_cfg" clock, > that it actually represents two clock inputs, the "cfg_clk" wired to the > D-PHY and a core clock wired to the MIPI DSI host controller. I am not > sure if there are designs that control those clocks separately, but I > think it'd be safer to split this into two clocks in the device tree. What MIPI CSI-2 datasheets do you refer to? I don't find the refclk and cfg_clk in the MIPI CSI chapter of the i.MX6DQ Reference Manual v2[2]. I think we need to know the design philosophy of DW MIPI DSI clock sources to settle down the documentation here. I've asked our internal MIPI DSI SoC owner for ideas. But, someone from Synopsys might be the right person, perhaps. [2] http://cache.freescale.com/files/32bit/doc/ref_manual/IMX6DQRM.pdf?fasp=1&WT_TYPE=Reference%20Manuals&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=pdf&WT_ASSET=Documentation&fileExt=.pdf > > Also I am not sure which input to the MIPI DSI host controller the core > clock represents. The i.MX6DQ Reference Manual v2 calls the remaining > clock inputs gated by mipi_core_cfg_clk_enable "ac_clk_125m" and > "ips_clk" (I think the latter is the ABP clock driving the register > bank, just called "pclk" in the MIPI CSI-2 documentation). The same MIPI CSI-2 documentation you mentioned above? I'm also puzzled about the clocks. Regards, Liu Ying > > regards > Philipp >
[PATCH] drm: atmel-hlcdc: Atomic mode-setting conversion
On Thu, Feb 05, 2015 at 04:37:56PM +0100, Boris Brezillon wrote: > On Thu, 5 Feb 2015 14:08:32 +0100 > Daniel Vetter wrote: > > > On Wed, Feb 04, 2015 at 09:20:51PM +0100, Boris Brezillon wrote: > > > Convert the HLCDC driver to atomic mode-setting. > > > > > > Signed-off-by: Boris Brezillon > > > > Just a quick comment: dpms isn't yet converted over, and from experience > > with tegra/msm that probably will yield some surprises. Since only with > > dpms will it be obvious how strict the added requirements from the atomic > > helpers are ;-) > > Yes, I noticed I was not using the appropriate dpms helper in the > connector funcs just after sending this patch. > > Would this patch [1] address what you're talking about, or am I still > missing something ? > > Thanks, > > Boris > > [1]http://code.bulix.org/l70xf4-87827 You should be able to bin all your dpms implementations too, at least if you switch to the new enable/disable hooks for crtc/encoder. prepare/commit/dpms are all depcrecated (for both crtc and encoder) and shouldn't be needed any more. Same with crtc_funcs->mode_set. But yeah the functional change should be all there is, if it still works you're all set. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
X using radeon is refusing to start
On Fri, Feb 06, 2015 at 11:51:55AM +0900, Michel Dänzer wrote: > On 06.02.2015 09:10, Andy Lutomirski wrote: > > I just started getting X failures that say: > > > > [ 739.208] (EE) RADEON(0): [drm] failed to set drm interface version. > > > > I'm not sure what triggered it. > > > > dmesg says: > > > > [ 740.156499] [drm:drm_stub_open] > > [ 740.156502] [drm:drm_open_helper] pid = 2170, minor = 0 > > [ 740.156541] [drm:drm_ioctl] pid=2170, dev=0xe200, auth=1, > > DRM_IOCTL_MODE_GETRESOURCES > > [ 740.156557] [drm:drm_ioctl] pid=2170, dev=0xe200, auth=1, > > DRM_IOCTL_MODE_GETRESOURCES > > [ 740.156575] [drm:drm_release] open_count = 2 > > [ 740.156577] [drm:drm_release] pid = 2170, device = 0xe200, open_count = 2 > > [ 740.158548] [drm:drm_ioctl] pid=2170, dev=0xe200, auth=1, > > DRM_IOCTL_SET_VERSION > > [ 740.158549] [drm:drm_ioctl] ret = -13 > > [ 740.159612] [drm:drm_framebuffer_reference] 8804457110a0: FB ID: 83 > > (3) > > > > -13 means -EACCES. > > We'd need to see dmesg from the beginning to be sure, but it looks like > something (maybe plymouth or whatever boot splash you're using?) is > keeping the DRM device open, so Xorg doesn't become DRM master. The trick is to inspect /sys/kernel/debug/dri/%d/clients at the time it fails and see who the kernel thinks is DRM_MASTER. -Chris -- Chris Wilson, Intel Open Source Technology Centre
X using radeon is refusing to start
On 06.02.2015 17:29, Chris Wilson wrote: > On Fri, Feb 06, 2015 at 11:51:55AM +0900, Michel Dänzer wrote: >> On 06.02.2015 09:10, Andy Lutomirski wrote: >>> I just started getting X failures that say: >>> >>> [ 739.208] (EE) RADEON(0): [drm] failed to set drm interface version. >>> >>> I'm not sure what triggered it. >>> >>> dmesg says: >>> >>> [ 740.156499] [drm:drm_stub_open] >>> [ 740.156502] [drm:drm_open_helper] pid = 2170, minor = 0 >>> [ 740.156541] [drm:drm_ioctl] pid=2170, dev=0xe200, auth=1, >>> DRM_IOCTL_MODE_GETRESOURCES >>> [ 740.156557] [drm:drm_ioctl] pid=2170, dev=0xe200, auth=1, >>> DRM_IOCTL_MODE_GETRESOURCES >>> [ 740.156575] [drm:drm_release] open_count = 2 >>> [ 740.156577] [drm:drm_release] pid = 2170, device = 0xe200, open_count = 2 >>> [ 740.158548] [drm:drm_ioctl] pid=2170, dev=0xe200, auth=1, >>> DRM_IOCTL_SET_VERSION >>> [ 740.158549] [drm:drm_ioctl] ret = -13 >>> [ 740.159612] [drm:drm_framebuffer_reference] 8804457110a0: FB ID: 83 >>> (3) >>> >>> -13 means -EACCES. >> >> We'd need to see dmesg from the beginning to be sure, but it looks like >> something (maybe plymouth or whatever boot splash you're using?) is >> keeping the DRM device open, so Xorg doesn't become DRM master. > > The trick is to inspect /sys/kernel/debug/dri/%d/clients at the time it > fails and see who the kernel thinks is DRM_MASTER. That's a neat trick, thanks. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
[Bug 73378] [drm:radeon_uvd_send_upll_ctlreq] *ERROR* Timeout setting UVD clocks!
https://bugs.freedesktop.org/show_bug.cgi?id=73378 --- Comment #30 from Christian König --- (In reply to Chernovsky Oleg from comment #29) > No luck. Tried various hacks and commenting return values. > > Will try mmiotracing these registers from fglrx on weekend Be careful that to write no irrational values into the PLL registers, e.g. don't use partly radeon partly fglrx settings. I once over clocked UVD to 4GHz instead of 400MHz by accident and the card is still working, but at least in theory you can damage the hardware with that. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150206/daf1d9e3/attachment.html>
[PATCH v2] drm/nouveau/clk: Change rate from u32 to u64 in gk20a_pllg_calc_rate()
On 32-bit platforms using asm-generic/div64.h:
drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c: In function
'gk20a_pllg_calc_rate':
drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c:147:79: warning: comparison of
distinct pointer types lacks a cast
do_div(rate, divider);
^
drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c:147:2: warning: right shift
count >= width of type
do_div(rate, divider);
^
drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c:147:238: warning: passing
argument 1 of '__div64_32' from incompatible pointer type
do_div(rate, divider);
^
In file included from arch/parisc/include/generated/asm/div64.h:1:0,
from include/linux/kernel.h:124,
from include/linux/list.h:8,
from include/linux/preempt.h:10,
from include/linux/spinlock.h:50,
from include/linux/mmzone.h:7,
from include/linux/gfp.h:5,
from include/linux/slab.h:14,
from drivers/gpu/drm/nouveau/include/nvif/os.h:5,
from drivers/gpu/drm/nouveau/include/nvkm/core/os.h:3,
from drivers/gpu/drm/nouveau/include/nvkm/core/object.h:3,
from drivers/gpu/drm/nouveau/include/nvkm/core/subdev.h:3,
from drivers/gpu/drm/nouveau/include/nvkm/subdev/clk.h:3,
from drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c:25:
include/asm-generic/div64.h:35:17: note: expected 'uint64_t *' but argument is
of type 'u32 *'
extern uint32_t __div64_32(uint64_t *dividend, uint32_t divisor);
^
do_div() is meant for 64-bit by 32-bit division, but both the dividend
and divisor are 32-bit here, causing the warning.
As the product of priv->parent_rate and priv->n may no longer fit in u32
soon, change rate from u32 to u64, which also fixes the warning.
Signed-off-by: Geert Uytterhoeven
---
Compile-tested only.
This is v2 of "drm/nouveau/clk: Use plain "/" for 32-bit division".
v2:
- Change rate from u32 to u64 instead of changing the division.
parisc/allmodconfig:
http://kisskb.ellerman.id.au/kisskb/buildresult/12358386/
---
drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c
index 65c532742b08d1c6..e87a964b8bea4d30 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c
@@ -139,7 +139,7 @@ gk20a_pllg_read_mnp(struct gk20a_clk_priv *priv)
static u32
gk20a_pllg_calc_rate(struct gk20a_clk_priv *priv)
{
- u32 rate;
+ u64 rate;
u32 divider;
rate = priv->parent_rate * priv->n;
--
1.9.1
[PATCH v2] drm/nouveau/clk: Change rate from u32 to u64 in gk20a_pllg_calc_rate()
On 02/06/2015 06:20 PM, Geert Uytterhoeven wrote:
> On 32-bit platforms using asm-generic/div64.h:
>
> drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c: In function
> 'gk20a_pllg_calc_rate':
> drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c:147:79: warning: comparison
> of distinct pointer types lacks a cast
>do_div(rate, divider);
>
> ^
> drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c:147:2: warning: right shift
> count >= width of type
>do_div(rate, divider);
>^
> drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c:147:238: warning: passing
> argument 1 of '__div64_32' from incompatible pointer type
>do_div(rate, divider);
>
>
>
> ^
> In file included from arch/parisc/include/generated/asm/div64.h:1:0,
> from include/linux/kernel.h:124,
> from include/linux/list.h:8,
> from include/linux/preempt.h:10,
> from include/linux/spinlock.h:50,
> from include/linux/mmzone.h:7,
> from include/linux/gfp.h:5,
> from include/linux/slab.h:14,
> from drivers/gpu/drm/nouveau/include/nvif/os.h:5,
> from drivers/gpu/drm/nouveau/include/nvkm/core/os.h:3,
> from drivers/gpu/drm/nouveau/include/nvkm/core/object.h:3,
> from drivers/gpu/drm/nouveau/include/nvkm/core/subdev.h:3,
> from drivers/gpu/drm/nouveau/include/nvkm/subdev/clk.h:3,
> from drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c:25:
> include/asm-generic/div64.h:35:17: note: expected 'uint64_t *' but argument
> is of type 'u32 *'
> extern uint32_t __div64_32(uint64_t *dividend, uint32_t divisor);
> ^
>
> do_div() is meant for 64-bit by 32-bit division, but both the dividend
> and divisor are 32-bit here, causing the warning.
>
> As the product of priv->parent_rate and priv->n may no longer fit in u32
> soon, change rate from u32 to u64, which also fixes the warning.
>
> Signed-off-by: Geert Uytterhoeven
> ---
> Compile-tested only.
>
> This is v2 of "drm/nouveau/clk: Use plain "/" for 32-bit division".
>
> v2:
>- Change rate from u32 to u64 instead of changing the division.
>
> parisc/allmodconfig:
> http://kisskb.ellerman.id.au/kisskb/buildresult/12358386/
> ---
> drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c
> index 65c532742b08d1c6..e87a964b8bea4d30 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c
> @@ -139,7 +139,7 @@ gk20a_pllg_read_mnp(struct gk20a_clk_priv *priv)
> static u32
> gk20a_pllg_calc_rate(struct gk20a_clk_priv *priv)
> {
> - u32 rate;
> + u64 rate;
> u32 divider;
>
> rate = priv->parent_rate * priv->n;
>
Tested-by: Alexandre Courbot
Adding Ben as he might want to take this in his tree?
[Bug 91861] [Radeon RS780] Blank screen (no signal) on HDMI after boot in 3.15 & later
https://bugzilla.kernel.org/show_bug.cgi?id=91861 --- Comment #14 from Christian König --- (In reply to Mike S. from comment #13) > So, from your explanation, using a ref_div of 7 compared to 2, means that > the VCO is running at a higher frequency, and hence, higher voltage. So I > assume that would mean the GPU would be drawing more power & therefore run > hotter, though I am not sure how significant this is to its overall power > use. > > Is that right? No, just the other way around. A higher reference divider results in a lower post divider and a lower feedback divider and that in turn results in a lower voltage and lower power consumption. But the over all power consumption of a PLL compared to the whole system or even the GFX block is completely neglitable. I would guess something between a 1/100 and 1/10 of a Watt compared to a couple of Watt for the whole system. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 91861] [Radeon RS780] Blank screen (no signal) on HDMI after boot in 3.15 & later
https://bugzilla.kernel.org/show_bug.cgi?id=91861 --- Comment #15 from Mike S. --- Thanks again for the info. I have been running the Radeon driver with the patch to limit the reference divider to 7 for a week now, and I can confirm that apart from that original incident, it has been very stable. So thank you for the patch, and I hope it can get into 3.19. -- You are receiving this mail because: You are watching the assignee of the bug.
[Intel-gfx] [PATCH] drm: Global atomic state handling
On Wed, 05 Nov 2014, Daniel Vetter wrote:
[heavily edited to just show the debugs]
> +struct drm_atomic_state *
> +drm_atomic_state_alloc(struct drm_device *dev)
> +{
> + DRM_DEBUG_KMS("Allocate atomic state %p\n", state);
> +}
> +void drm_atomic_state_clear(struct drm_atomic_state *state)
> +{
> + DRM_DEBUG_KMS("Clearing atomic state %p\n", state);
> +}
> +void drm_atomic_state_free(struct drm_atomic_state *state)
> +{
> + DRM_DEBUG_KMS("Freeing atomic state %p\n", state);
> +}
> +struct drm_crtc_state *
> +drm_atomic_get_crtc_state(struct drm_atomic_state *state,
> + struct drm_crtc *crtc)
> +{
> + DRM_DEBUG_KMS("Added [CRTC:%d] %p state to %p\n",
> + crtc->base.id, crtc_state, state);
> +}
> +struct drm_plane_state *
> +drm_atomic_get_plane_state(struct drm_atomic_state *state,
> + struct drm_plane *plane)
> +{
> + DRM_DEBUG_KMS("Added [PLANE:%d] %p state to %p\n",
> + plane->base.id, plane_state, state);
> +}
> +struct drm_connector_state *
> +drm_atomic_get_connector_state(struct drm_atomic_state *state,
> + struct drm_connector *connector)
> +{
> + DRM_DEBUG_KMS("Added [CONNECTOR:%d] %p state to %p\n",
> + connector->base.id, connector_state, state);
> +}
> +int drm_atomic_check_only(struct drm_atomic_state *state)
> +{
> + DRM_DEBUG_KMS("checking %p\n", state);
> +}
> +int drm_atomic_commit(struct drm_atomic_state *state)
> +{
> + DRM_DEBUG_KMS("commiting %p\n", state);
> +}
These seem to be rather verbose [1], is this normal or indicative of
something going awry? If normal, it does seem quite noisy in the logs.
BR,
Jani.
[1] https://bugs.freedesktop.org/attachment.cgi?id=113217
--
Jani Nikula, Intel Open Source Technology Center
[Bug 91861] [Radeon RS780] Blank screen (no signal) on HDMI after boot in 3.15 & later
https://bugzilla.kernel.org/show_bug.cgi?id=91861 --- Comment #16 from Christian König --- (In reply to Mike S. from comment #15) > So thank you for the patch, and I hope it can get into 3.19. Alex has added it to his -fixes branch, so it either ends up in 3.19 or in 3.20. Can you close the bug report then? -- You are receiving this mail because: You are watching the assignee of the bug.
drm: Request for help about drm_mode_getresources( ) returns empty modes message
hi all,
when I run modetest process in libdrm to test our drm module, I find a
strange problem:
The test successfully opened /dev/dri/card0 (major:226 minor:0) device by
using module name.
but the returned message about crtc, encoder and connector are all empty. I
confirm the num of them
is one when our drm device driver register in kernel. So I track the kernel and
find here:
drivers/gpu/drm/drm_crtc.c
1806 if (!drm_is_primary_client(file_priv)) {
1807
1808 mode_group = NULL;
1809 list_for_each(lh, &dev->mode_config.crtc_list)
1810 crtc_count++;
1811
1812 list_for_each(lh, &dev->mode_config.connector_list)
1813 connector_count++;
1814
1815 list_for_each(lh, &dev->mode_config.encoder_list)
1816 encoder_count++;
1817 } else {
1818
1819 mode_group = &file_priv->master->minor->mode_group;
1820 crtc_count = mode_group->num_crtcs;
1821 connector_count = mode_group->num_connectors;
1822 encoder_count = mode_group->num_encoders;
1823 }
The device we opened with type of DRM_MINOR_LEGACY, so here come into else
branch. The description
of drm_mode_group is that struct drm_mode_group - group of mode setting
resources for potential sub-grouping,
and the note in drm_crtc.h also said :
943 * Currently this simply tracks the global mode setting state. But
in the
944 * future it could allow groups of objects to be set aside into
independent
945 * control groups for use by different user level processes (e.g. two
X servers
946 * running simultaneously on different heads, each with their own mode
947 * configuration and freedom of mode setting).
I doubt the empty result has some relations with it, so I continue to
track the kernel in function
drm_open, and I find mode_group lies in drm_minor, whick can be found by inode
in function drm_open.
But when we create a crtc, encoder or connector, we do nothing to mode_group,
just initializing it
when drm_core register. Can you help me and give me some advice?
regards,
Yunlei He
[Bug 91861] [Radeon RS780] Blank screen (no signal) on HDMI after boot in 3.15 & later
https://bugzilla.kernel.org/show_bug.cgi?id=91861 Mike S. changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |CODE_FIX -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH] drm/i915: Remove references to previously removed UMS config option
On Fri, 2015-02-06 at 11:16 +0100, Andreas Ruprecht wrote:
> Commit 03dae59c72d8 ("drm/i915: Ditch UMS config option") removed
> CONFIG_DRM_I915_UMS from the Kconfig file, but i915_drv.c still
> references this option in two #ifndef statements.
>
> As an undefined config option will always be 'false', we can drop
> the #ifndefs alltogether and adapt the printed error message.
>
> This inconsistency was found with the undertaker tool.
>
> Signed-off-by: Andreas Ruprecht
> ---
Previously discussed in
http://lists.freedesktop.org/archives/dri-devel/2014-July/064702.html
(but not on lkml). If I understand Daniels message correctly this
$ git grep -n '!drm_core_check_feature' | grep -w DRIVER_MODESET | wc -l
43
means the cleanup needed to be done before this cleanup will be applied,
hasn't happened yet.
> drivers/gpu/drm/i915/i915_drv.c | 6 +-
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 8039cec..4ecf85f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1630,11 +1630,9 @@ static int __init i915_init(void)
>
> if (!(driver.driver_features & DRIVER_MODESET)) {
> driver.get_vblank_timestamp = NULL;
> -#ifndef CONFIG_DRM_I915_UMS
> /* Silently fail loading to not upset userspace. */
> - DRM_DEBUG_DRIVER("KMS and UMS disabled.\n");
> + DRM_DEBUG_DRIVER("KMS disabled.\n");
> return 0;
> -#endif
> }
>
> /*
> @@ -1650,10 +1648,8 @@ static int __init i915_init(void)
>
> static void __exit i915_exit(void)
> {
> -#ifndef CONFIG_DRM_I915_UMS
> if (!(driver.driver_features & DRIVER_MODESET))
> return; /* Never loaded a driver. */
> -#endif
>
> drm_pci_exit(&driver, &i915_pci_driver);
> }
Thanks,
Paul Bolle
[PATCH] drm/i915: Remove references to previously removed UMS config option
On Fri, 06 Feb 2015, Andreas Ruprecht wrote:
> Commit 03dae59c72d8 ("drm/i915: Ditch UMS config option") removed
> CONFIG_DRM_I915_UMS from the Kconfig file, but i915_drv.c still
> references this option in two #ifndef statements.
>
> As an undefined config option will always be 'false', we can drop
> the #ifndefs alltogether and adapt the printed error message.
>
> This inconsistency was found with the undertaker tool.
>
> Signed-off-by: Andreas Ruprecht
> ---
> drivers/gpu/drm/i915/i915_drv.c | 6 +-
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 8039cec..4ecf85f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1630,11 +1630,9 @@ static int __init i915_init(void)
>
> if (!(driver.driver_features & DRIVER_MODESET)) {
> driver.get_vblank_timestamp = NULL;
> -#ifndef CONFIG_DRM_I915_UMS
> /* Silently fail loading to not upset userspace. */
> - DRM_DEBUG_DRIVER("KMS and UMS disabled.\n");
> + DRM_DEBUG_DRIVER("KMS disabled.\n");
I'm not sure if this logging change is required. UMS will still also be
disabled. Or maybe make it "KMS disabled, UMS not
supported.\n". Background in
commit c9cd7b65db50175a5f1ff64bbad6d5affdad6aba
Author: Jani Nikula
Date: Mon Jun 2 16:58:30 2014 +0300
drm/i915: tell the user if both KMS and UMS are disabled
Other than that,
Reviewed-by: Jani Nikula
> return 0;
> -#endif
> }
>
> /*
> @@ -1650,10 +1648,8 @@ static int __init i915_init(void)
>
> static void __exit i915_exit(void)
> {
> -#ifndef CONFIG_DRM_I915_UMS
> if (!(driver.driver_features & DRIVER_MODESET))
> return; /* Never loaded a driver. */
> -#endif
>
> drm_pci_exit(&driver, &i915_pci_driver);
> }
> --
> 1.9.1
>
--
Jani Nikula, Intel Open Source Technology Center
[RFC PATCH v2 3/3] ARM: dts: exynos5420: add async-bridge clocks to disp1 power domain
FIMD and MIXER IPs in disp1 power domain have async-bridges (to GSCALER),
therefore their clocks should be enabled during power domain switch.
Signed-off-by: Andrzej Hajda
---
Hi,
This is 2nd version of the patch. After decrypting manual and discussion
with Marek I guess this set of clocks is more apropriate - async-bridges
are present in MIXER and FIMD, so their clocks should be enabled.
The 1st version worked for me due to fact I have forgot to remove
clk_ignore_unused kernel boot option during tests ;)
Regards
Andrzej
---
arch/arm/boot/dts/exynos5420.dtsi | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index e1fa800..58579f5 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -293,9 +293,11 @@
<&clock CLK_MOUT_SW_ACLK300>,
<&clock CLK_MOUT_USER_ACLK300_DISP1>,
<&clock CLK_MOUT_SW_ACLK400>,
-<&clock CLK_MOUT_USER_ACLK400_DISP1>;
+<&clock CLK_MOUT_USER_ACLK400_DISP1>,
+<&clock CLK_FIMD1>, <&clock CLK_MIXER>;
clock-names = "oscclk", "pclk0", "clk0",
- "pclk1", "clk1", "pclk2", "clk2";
+ "pclk1", "clk1", "pclk2", "clk2",
+ "asb0", "asb1";
};
pinctrl_0: pinctrl at 1340 {
--
1.9.1
[PATCH v3] drm/tegra: Use 64-bit offset for tegra_gem_mmap
On Fri, Jan 30, 2015 at 01:57:01PM -0500, Sean Paul wrote: > On 64-bit targets, tegra_gem_mmap doesn't return the > offset to userspace. As such, subsequent calls to mmap(2) > fail. Alter the args to use 64-bit offset to fix this. > > Signed-off-by: Sean Paul > --- > include/uapi/drm/tegra_drm.h | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) I've applied this with a slightly tweaked commit message. Thanks, Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150206/6a276c03/attachment.sig>
[PATCH 4/4] drm/exynos: fix NULL pointer reference
Hi, 2015-02-06 Joonyoung Shim : > Hi, > > On 02/05/2015 10:07 PM, Gustavo Padovan wrote: > > Hi, > > > > > > 2015-02-05 Joonyoung Shim : > > > >> There is a case called disable_plane callback function even if > >> plane->crtc is NULL from exynos_drm_encoder_disable and it will cause > >> NULL pointer reference error. > >> > >> Signed-off-by: Joonyoung Shim > >> --- > >> drivers/gpu/drm/exynos/exynos_drm_encoder.c | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > > > > You need to merge this patch with patch 3 or you will break the bisect. > > The NULL pointer is introduced by the previous patch, so fix it in the same > > patch. > > > > Yeah, it is revealed by patch 3 but it was original problem from before > patch 3. How about apply this patch earlier than patch 3? Okay. That sounds good too. Gustavo
[PATCH 1/4] drm/exynos: remove struct *_win_data abstraction on planes
Hi,
2015-02-06 Joonyoung Shim :
> Hi Gustavo,
>
> On 02/06/2015 02:59 AM, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > struct {fimd,mixer,vidi}_win_data was just keeping the same data
> > as struct exynos_drm_plane thus get ride of it and use exynos_drm_plane
> > directly.
> >
> > It changes how planes are created and remove .win_mode_set() callback
> > that was only filling all *_win_data structs.
> >
>
> OK, let's go ahead this with next zpos problem fix.
>
> > Signed-off-by: Gustavo Padovan
> > ---
> > drivers/gpu/drm/exynos/exynos_drm_crtc.c | 9 +-
> > drivers/gpu/drm/exynos/exynos_drm_crtc.h | 1 +
> > drivers/gpu/drm/exynos/exynos_drm_drv.c | 14 --
> > drivers/gpu/drm/exynos/exynos_drm_drv.h | 5 +-
> > drivers/gpu/drm/exynos/exynos_drm_fimd.c | 182 ++---
> > drivers/gpu/drm/exynos/exynos_drm_plane.c | 20 +--
> > drivers/gpu/drm/exynos/exynos_drm_plane.h | 6 +-
> > drivers/gpu/drm/exynos/exynos_drm_vidi.c | 123 +
> > drivers/gpu/drm/exynos/exynos_mixer.c | 212
> > +++---
> > 9 files changed, 183 insertions(+), 389 deletions(-)
> >
>
> [snip]
>
> > diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
> > b/drivers/gpu/drm/exynos/exynos_mixer.c
> > index 736269a..6e7c0cc 100644
> > --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> > +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> > @@ -37,34 +37,13 @@
> >
> > #include "exynos_drm_drv.h"
> > #include "exynos_drm_crtc.h"
> > +#include "exynos_drm_plane.h"
> > #include "exynos_drm_iommu.h"
> > #include "exynos_mixer.h"
> >
> > #define MIXER_WIN_NR 3
> > #define MIXER_DEFAULT_WIN 0
> >
> > -struct hdmi_win_data {
> > - dma_addr_t dma_addr;
> > - dma_addr_t chroma_dma_addr;
> > - uint32_tpixel_format;
> > - unsigned intbpp;
> > - unsigned intcrtc_x;
> > - unsigned intcrtc_y;
> > - unsigned intcrtc_width;
> > - unsigned intcrtc_height;
> > - unsigned intfb_x;
> > - unsigned intfb_y;
> > - unsigned intfb_width;
> > - unsigned intfb_height;
> > - unsigned intsrc_width;
> > - unsigned intsrc_height;
> > - unsigned intmode_width;
> > - unsigned intmode_height;
> > - unsigned intscan_flags;
> > - boolenabled;
> > - boolresume;
> > -};
> > -
> > struct mixer_resources {
> > int irq;
> > void __iomem*mixer_regs;
> > @@ -88,6 +67,7 @@ struct mixer_context {
> > struct device *dev;
> > struct drm_device *drm_dev;
> > struct exynos_drm_crtc *crtc;
> > + struct exynos_drm_plane planes[MIXER_WIN_NR];
> > int pipe;
> > boolinterlace;
> > boolpowered;
> > @@ -97,7 +77,6 @@ struct mixer_context {
> >
> > struct mutexmixer_mutex;
> > struct mixer_resources mixer_res;
> > - struct hdmi_win_datawin_data[MIXER_WIN_NR];
> > enum mixer_version_id mxr_ver;
> > wait_queue_head_t wait_vsync_queue;
> > atomic_twait_vsync_event;
> > @@ -401,7 +380,7 @@ static void vp_video_buffer(struct mixer_context *ctx,
> > int win)
> > {
> > struct mixer_resources *res = &ctx->mixer_res;
> > unsigned long flags;
> > - struct hdmi_win_data *win_data;
> > + struct exynos_drm_plane *plane;
> > unsigned int x_ratio, y_ratio;
> > unsigned int buf_num = 1;
> > dma_addr_t luma_addr[2], chroma_addr[2];
> > @@ -409,9 +388,9 @@ static void vp_video_buffer(struct mixer_context *ctx,
> > int win)
> > bool crcb_mode = false;
> > u32 val;
> >
> > - win_data = &ctx->win_data[win];
> > + plane = &ctx->planes[win];
> >
> > - switch (win_data->pixel_format) {
> > + switch (plane->pixel_format) {
> > case DRM_FORMAT_NV12MT:
> > tiled_mode = true;
> > case DRM_FORMAT_NV12:
> > @@ -421,35 +400,35 @@ static void vp_video_buffer(struct mixer_context
> > *ctx, int win)
> > /* TODO: single buffer format NV12, NV21 */
> > default:
> > /* ignore pixel format at disable time */
> > - if (!win_data->dma_addr)
> > + if (!plane->dma_addr[0])
> > break;
> >
> > DRM_ERROR("pixel format for vp is wrong [%d].\n",
> > - win_data->pixel_format);
> > + plane->pixel_format);
> > return;
> > }
> >
> > /* scaling feature: (src << 16) / dst */
> > - x_ratio = (win_data->src_width << 16) / win_data->crtc_width;
> > - y_ratio = (win_data->src_height << 16) / win_data->crtc_height;
> > + x_ratio = (plane->src_width << 16) / plane->crtc_width;
> > + y_ratio = (plane->src_height << 16) / plane->crtc_he
[PATCH 0/5] DRM: STI: infoframe improvement and new pixel formats
Rework infoframe to add audio informations. Support two additional pixel formats in GDP planes. Arnaud Pouliquen (1): drm: sti: HDMI add audio infoframe Benjamin Gaignard (1): drm: sti: add support of ABGR for gdp plane Fabien Dessenne (1): drm: sti: add support of XBGR for gdp plane Jassi Brar (1): drm: sti: fix check for clk_pix_main Vincent Abriou (1): drm: sti: fix static checker warning in sti_awg_utils drivers/gpu/drm/sti/sti_awg_utils.c | 2 - drivers/gpu/drm/sti/sti_gdp.c | 11 +++ drivers/gpu/drm/sti/sti_hdmi.c | 179 +++- drivers/gpu/drm/sti/sti_hqvdp.c | 2 +- 4 files changed, 149 insertions(+), 45 deletions(-) -- 1.9.1
[PATCH 1/5] drm: sti: fix check for clk_pix_main
From: Jassi Brar
copy-paste wasn't followed by editing, do it.
Signed-off-by: Jassi Brar
---
drivers/gpu/drm/sti/sti_hqvdp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sti/sti_hqvdp.c b/drivers/gpu/drm/sti/sti_hqvdp.c
index f3db05d..b0eb62d 100644
--- a/drivers/gpu/drm/sti/sti_hqvdp.c
+++ b/drivers/gpu/drm/sti/sti_hqvdp.c
@@ -1025,7 +1025,7 @@ static int sti_hqvdp_probe(struct platform_device *pdev)
/* Get clock resources */
hqvdp->clk = devm_clk_get(dev, "hqvdp");
hqvdp->clk_pix_main = devm_clk_get(dev, "pix_main");
- if (IS_ERR(hqvdp->clk) || IS_ERR(hqvdp->clk)) {
+ if (IS_ERR(hqvdp->clk) || IS_ERR(hqvdp->clk_pix_main)) {
DRM_ERROR("Cannot get clocks\n");
return -ENXIO;
}
--
1.9.1
[PATCH 2/5] drm: sti: fix static checker warning in sti_awg_utils
From: Vincent Abriou The shift and the mask done on arg value is useless since arg is null. Signed-off-by: Vincent Abriou --- drivers/gpu/drm/sti/sti_awg_utils.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/sti/sti_awg_utils.c b/drivers/gpu/drm/sti/sti_awg_utils.c index 9fde3ee..6029a2e 100644 --- a/drivers/gpu/drm/sti/sti_awg_utils.c +++ b/drivers/gpu/drm/sti/sti_awg_utils.c @@ -60,8 +60,6 @@ static int awg_generate_instr(enum opcode opcode, * pixel. So we transform SKIP into SET * instruction */ opcode = SET; - arg = (arg << 24) >> 24; - arg &= (0x0ff); break; } -- 1.9.1
[PATCH 3/5] drm: sti: add support of ABGR8888 for gdp plane
Use GDP capabilities to support DRM_FORMAT_ABGR (AB24)
Signed-off-by: Benjamin Gaignard
---
drivers/gpu/drm/sti/sti_gdp.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/sti/sti_gdp.c b/drivers/gpu/drm/sti/sti_gdp.c
index 32448d1..f018bb1 100644
--- a/drivers/gpu/drm/sti/sti_gdp.c
+++ b/drivers/gpu/drm/sti/sti_gdp.c
@@ -14,7 +14,9 @@
#include "sti_layer.h"
#include "sti_vtg.h"
+#define ALPHASWITCH BIT(6)
#define ENA_COLOR_FILL BIT(8)
+#define BIGNOTLITTLEBIT(23)
#define WAIT_NEXT_VSYNC BIT(31)
/* GDP color formats */
@@ -23,6 +25,7 @@
#define GDP_RGB888_32 0x02
#define GDP_ARGB85650x04
#define GDP_ARGB0x05
+#define GDP_ABGR (GDP_ARGB | BIGNOTLITTLE | ALPHASWITCH)
#define GDP_ARGB15550x06
#define GDP_ARGB0x07
#define GDP_CLUT8 0x0B
@@ -104,6 +107,7 @@ struct sti_gdp {
static const uint32_t gdp_supported_formats[] = {
DRM_FORMAT_XRGB,
DRM_FORMAT_ARGB,
+ DRM_FORMAT_ABGR,
DRM_FORMAT_ARGB,
DRM_FORMAT_ARGB1555,
DRM_FORMAT_RGB565,
@@ -131,6 +135,8 @@ static int sti_gdp_fourcc2format(int fourcc)
return GDP_RGB888_32;
case DRM_FORMAT_ARGB:
return GDP_ARGB;
+ case DRM_FORMAT_ABGR:
+ return GDP_ABGR;
case DRM_FORMAT_ARGB:
return GDP_ARGB;
case DRM_FORMAT_ARGB1555:
@@ -157,6 +163,7 @@ static int sti_gdp_get_alpharange(int format)
case GDP_ARGB8565:
case GDP_ARGB:
case GDP_AYCBR:
+ case GDP_ABGR:
return GAM_GDP_ALPHARANGE_255;
}
return 0;
--
1.9.1
[PATCH 4/5] drm: sti: add support of XBGR8888 for gdp plane
From: Fabien Dessenne
Use GDP capabilities to support DRM_FORMAT_XBGR (XB24)
Signed-off-by: Fabien Dessenne
---
drivers/gpu/drm/sti/sti_gdp.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/sti/sti_gdp.c b/drivers/gpu/drm/sti/sti_gdp.c
index f018bb1..087906f 100644
--- a/drivers/gpu/drm/sti/sti_gdp.c
+++ b/drivers/gpu/drm/sti/sti_gdp.c
@@ -23,6 +23,7 @@
#define GDP_RGB565 0x00
#define GDP_RGB888 0x01
#define GDP_RGB888_32 0x02
+#define GDP_XBGR(GDP_RGB888_32 | BIGNOTLITTLE | ALPHASWITCH)
#define GDP_ARGB85650x04
#define GDP_ARGB0x05
#define GDP_ABGR (GDP_ARGB | BIGNOTLITTLE | ALPHASWITCH)
@@ -106,6 +107,7 @@ struct sti_gdp {
static const uint32_t gdp_supported_formats[] = {
DRM_FORMAT_XRGB,
+ DRM_FORMAT_XBGR,
DRM_FORMAT_ARGB,
DRM_FORMAT_ABGR,
DRM_FORMAT_ARGB,
@@ -133,6 +135,8 @@ static int sti_gdp_fourcc2format(int fourcc)
switch (fourcc) {
case DRM_FORMAT_XRGB:
return GDP_RGB888_32;
+ case DRM_FORMAT_XBGR:
+ return GDP_XBGR;
case DRM_FORMAT_ARGB:
return GDP_ARGB;
case DRM_FORMAT_ABGR:
--
1.9.1
[PATCH 5/5] drm: sti: HDMI add audio infoframe
From: Arnaud Pouliquen
Add a default audio infoframe for HDMI compliance
Signed-off-by: Arnaud Pouliquen
---
drivers/gpu/drm/sti/sti_hdmi.c | 179 +++--
1 file changed, 137 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
index e840ca5d..1485ade 100644
--- a/drivers/gpu/drm/sti/sti_hdmi.c
+++ b/drivers/gpu/drm/sti/sti_hdmi.c
@@ -42,8 +42,17 @@
#define HDMI_SW_DI_1_PKT_WORD5 0x0228
#define HDMI_SW_DI_1_PKT_WORD6 0x022C
#define HDMI_SW_DI_CFG 0x0230
+#define HDMI_SW_DI_2_HEAD_WORD 0x0600
+#define HDMI_SW_DI_2_PKT_WORD0 0x0604
+#define HDMI_SW_DI_2_PKT_WORD1 0x0608
+#define HDMI_SW_DI_2_PKT_WORD2 0x060C
+#define HDMI_SW_DI_2_PKT_WORD3 0x0610
+#define HDMI_SW_DI_2_PKT_WORD4 0x0614
+#define HDMI_SW_DI_2_PKT_WORD5 0x0618
+#define HDMI_SW_DI_2_PKT_WORD6 0x061C
#define HDMI_IFRAME_SLOT_AVI1
+#define HDMI_IFRAME_SLOT_AUDIO 2
#define XCAT(prefix, x, suffix)prefix ## x ## suffix
#define HDMI_SW_DI_N_HEAD_WORD(x) XCAT(HDMI_SW_DI_, x, _HEAD_WORD)
@@ -99,6 +108,10 @@
#define HDMI_STA_SW_RST BIT(1)
+#define HDMI_INFOFRAME_HEADER_TYPE(x)(((x) & 0xff) << 0)
+#define HDMI_INFOFRAME_HEADER_VERSION(x) (((x) & 0xff) << 8)
+#define HDMI_INFOFRAME_HEADER_LEN(x) (((x) & 0x0f) << 16)
+
struct sti_hdmi_connector {
struct drm_connector drm_connector;
struct drm_encoder *encoder;
@@ -228,6 +241,90 @@ static void hdmi_config(struct sti_hdmi *hdmi)
}
/**
+ * Helper to concatenate infoframe in 32 bits word
+ *
+ * @ptr: pointer on the hdmi internal structure
+ * @data: infoframe to write
+ * @size: size to write
+ */
+static inline unsigned int hdmi_infoframe_subpack(const u8 *ptr, size_t size)
+{
+ unsigned long value = 0;
+ size_t i;
+
+ for (i = size; i > 0; i--)
+ value = (value << 8) | ptr[i - 1];
+
+ return value;
+}
+
+/**
+ * Helper to write info frame
+ *
+ * @hdmi: pointer on the hdmi internal structure
+ * @data: infoframe to write
+ * @size: size to write
+ */
+static void hdmi_infoframe_write_infopack(struct sti_hdmi *hdmi, const u8
*data)
+{
+ const u8 *ptr = data;
+ u32 val, slot, mode, i;
+ u32 head_offset, pack_offset;
+ size_t size;
+
+ switch (*ptr) {
+ case HDMI_INFOFRAME_TYPE_AVI:
+ slot = HDMI_IFRAME_SLOT_AVI;
+ mode = HDMI_IFRAME_FIELD;
+ head_offset = HDMI_SW_DI_N_HEAD_WORD(HDMI_IFRAME_SLOT_AVI);
+ pack_offset = HDMI_SW_DI_N_PKT_WORD0(HDMI_IFRAME_SLOT_AVI);
+ size = HDMI_AVI_INFOFRAME_SIZE;
+ break;
+
+ case HDMI_INFOFRAME_TYPE_AUDIO:
+ slot = HDMI_IFRAME_SLOT_AUDIO;
+ mode = HDMI_IFRAME_FRAME;
+ head_offset = HDMI_SW_DI_N_HEAD_WORD(HDMI_IFRAME_SLOT_AUDIO);
+ pack_offset = HDMI_SW_DI_N_PKT_WORD0(HDMI_IFRAME_SLOT_AUDIO);
+ size = HDMI_AUDIO_INFOFRAME_SIZE;
+ break;
+
+ default:
+ DRM_ERROR("unsupported infoframe type: %#x\n", *ptr);
+ return;
+ }
+
+ /* Disable transmission slot for updated infoframe */
+ val = hdmi_read(hdmi, HDMI_SW_DI_CFG);
+ val &= ~HDMI_IFRAME_CFG_DI_N(HDMI_IFRAME_MASK, slot);
+ hdmi_write(hdmi, val, HDMI_SW_DI_CFG);
+
+ val = HDMI_INFOFRAME_HEADER_TYPE(*ptr++);
+ val |= HDMI_INFOFRAME_HEADER_VERSION(*ptr++);
+ val |= HDMI_INFOFRAME_HEADER_LEN(*ptr++);
+ writel(val, hdmi->regs + head_offset);
+
+ /*
+* Each subpack contains 4 bytes
+* The First Bytes of the first subpacket must contain the checksum
+* Packet size in increase by one.
+*/
+ for (i = 0; i < size; i += sizeof(u32)) {
+ size_t num;
+
+ num = min_t(size_t, size - i, sizeof(u32));
+ val = hdmi_infoframe_subpack(ptr, num);
+ ptr += sizeof(u32);
+ writel(val, hdmi->regs + pack_offset + i);
+ }
+
+ /* Enable transmission slot for updated infoframe */
+ val = hdmi_read(hdmi, HDMI_SW_DI_CFG);
+ val |= HDMI_IFRAME_CFG_DI_N(HDMI_IFRAME_FIELD, slot);
+ hdmi_write(hdmi, val, HDMI_SW_DI_CFG);
+}
+
+/**
* Prepare and configure the AVI infoframe
*
* AVI infoframe are transmitted at least once per two video field and
@@ -243,8 +340,6 @@ static int hdmi_avi_infoframe_config(struct sti_hdmi *hdmi)
struct drm_display_mode *mode = &hdmi->mode;
struct hdmi_avi_infoframe infoframe;
u8 buffer[HDMI_INFOFRAME_SIZE(AVI)];
- u8 *frame = buffer + HDMI_INFOFRAME_HEADER_SIZE;
- u32 val;
int ret;
DRM_DEBUG_DRIVER("\n");
@@ -266,47 +361,43 @@ static int hdmi_avi_infoframe_config(struct sti_hdmi
*hdmi)
return ret;
[Bug 89009] radeon: Failed to allocate a buffer
https://bugs.freedesktop.org/show_bug.cgi?id=89009 Bug ID: 89009 Summary: radeon: Failed to allocate a buffer Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: tsesmelistheodore at gmail.com QA Contact: dri-devel at lists.freedesktop.org I am trying to play the Limbo indie game in an Archlinux system, the issue that I am facing is that while the game loads without any problem the texture of the boy is missing. It is really strange because I can move the boy, but I cannot see it. Only sometimes a small rectangle flickers in the position where the boy supposed to be. I am with mesa-git and my graphics card is a 5850 ati and if I run the game from command line I am getting the following error continuously: radeon: Failed to allocate a buffer: radeon:size : 44728320 bytes radeon:alignment : 32768 bytes radeon:domains : 4 radeon:flags : 20 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150206/3e7077a7/attachment-0001.html>
[PATCH v2] drm: atmel-hlcdc: Atomic mode-setting conversion
Convert the HLCDC driver to atomic mode-setting.
Signed-off-by: Boris Brezillon
---
Changes since v1:
- use atomic helper for DPMS handlers
- remove unneeded DPMS handling functions
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 278 +---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 4 +
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 59 +--
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.c | 4 +-
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.h | 3 +-
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 41 +-
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 549 +--
7 files changed, 443 insertions(+), 495 deletions(-)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index 0409b90..de6973d 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -44,7 +44,6 @@ struct atmel_hlcdc_crtc {
struct atmel_hlcdc_dc *dc;
struct drm_pending_vblank_event *event;
int id;
- int dpms;
};
static inline struct atmel_hlcdc_crtc *
@@ -53,86 +52,17 @@ drm_crtc_to_atmel_hlcdc_crtc(struct drm_crtc *crtc)
return container_of(crtc, struct atmel_hlcdc_crtc, base);
}
-static void atmel_hlcdc_crtc_dpms(struct drm_crtc *c, int mode)
+static void atmel_hlcdc_crtc_mode_set_nofb(struct drm_crtc *c)
{
- struct drm_device *dev = c->dev;
struct atmel_hlcdc_crtc *crtc = drm_crtc_to_atmel_hlcdc_crtc(c);
struct regmap *regmap = crtc->dc->hlcdc->regmap;
- unsigned int status;
-
- if (mode != DRM_MODE_DPMS_ON)
- mode = DRM_MODE_DPMS_OFF;
-
- if (crtc->dpms == mode)
- return;
-
- pm_runtime_get_sync(dev->dev);
-
- if (mode != DRM_MODE_DPMS_ON) {
- regmap_write(regmap, ATMEL_HLCDC_DIS, ATMEL_HLCDC_DISP);
- while (!regmap_read(regmap, ATMEL_HLCDC_SR, &status) &&
- (status & ATMEL_HLCDC_DISP))
- cpu_relax();
-
- regmap_write(regmap, ATMEL_HLCDC_DIS, ATMEL_HLCDC_SYNC);
- while (!regmap_read(regmap, ATMEL_HLCDC_SR, &status) &&
- (status & ATMEL_HLCDC_SYNC))
- cpu_relax();
-
- regmap_write(regmap, ATMEL_HLCDC_DIS, ATMEL_HLCDC_PIXEL_CLK);
- while (!regmap_read(regmap, ATMEL_HLCDC_SR, &status) &&
- (status & ATMEL_HLCDC_PIXEL_CLK))
- cpu_relax();
-
- clk_disable_unprepare(crtc->dc->hlcdc->sys_clk);
-
- pm_runtime_allow(dev->dev);
- } else {
- pm_runtime_forbid(dev->dev);
-
- clk_prepare_enable(crtc->dc->hlcdc->sys_clk);
-
- regmap_write(regmap, ATMEL_HLCDC_EN, ATMEL_HLCDC_PIXEL_CLK);
- while (!regmap_read(regmap, ATMEL_HLCDC_SR, &status) &&
- !(status & ATMEL_HLCDC_PIXEL_CLK))
- cpu_relax();
-
-
- regmap_write(regmap, ATMEL_HLCDC_EN, ATMEL_HLCDC_SYNC);
- while (!regmap_read(regmap, ATMEL_HLCDC_SR, &status) &&
- !(status & ATMEL_HLCDC_SYNC))
- cpu_relax();
-
- regmap_write(regmap, ATMEL_HLCDC_EN, ATMEL_HLCDC_DISP);
- while (!regmap_read(regmap, ATMEL_HLCDC_SR, &status) &&
- !(status & ATMEL_HLCDC_DISP))
- cpu_relax();
- }
-
- pm_runtime_put_sync(dev->dev);
-
- crtc->dpms = mode;
-}
-
-static int atmel_hlcdc_crtc_mode_set(struct drm_crtc *c,
-struct drm_display_mode *mode,
-struct drm_display_mode *adj,
-int x, int y,
-struct drm_framebuffer *old_fb)
-{
- struct atmel_hlcdc_crtc *crtc = drm_crtc_to_atmel_hlcdc_crtc(c);
- struct regmap *regmap = crtc->dc->hlcdc->regmap;
- struct drm_plane *plane = c->primary;
- struct drm_framebuffer *fb;
+ struct drm_display_mode *adj = &c->state->adjusted_mode;
unsigned long mode_rate;
struct videomode vm;
unsigned long prate;
unsigned int cfg;
int div;
- if (atmel_hlcdc_dc_mode_valid(crtc->dc, adj) != MODE_OK)
- return -EINVAL;
-
vm.vfront_porch = adj->crtc_vsync_start - adj->crtc_vdisplay;
vm.vback_porch = adj->crtc_vtotal - adj->crtc_vsync_end;
vm.vsync_len = adj->crtc_vsync_end - adj->crtc_vsync_start;
@@ -156,7 +86,7 @@ static int atmel_hlcdc_crtc_mode_set(struct drm_crtc *c,
cfg = ATMEL_HLCDC_CLKPOL;
prate = clk_get_rate(crtc->dc->hlcdc->sys_clk);
- mode_rate = mode->crtc_clock * 1000;
+ mode_rate = adj->crtc_clock * 1000;
if ((prate / 2) < mode_rate) {
prate *= 2;
cfg |= ATMEL_HLCDC_CLKSEL;
@@ -174,1
[PATCH] drm: atmel-hlcdc: add discard area support
The HLCDC IP provides a way to discard a specific area on the primary
plane (in case at least one of the overlay is activated and alpha
blending is disabled).
Doing this will reduce the amount of data to transfer from the main
memory to the Display Controller, and thus alleviate the load on the
memory bus (since this link is quite limited on such hardware,
this kind of optimization is really important).
Signed-off-by: Boris Brezillon
---
Hi Daniel,
Can you tell me if that's what you had in mind for the discard area feature
we talked about yersterday.
This patch depends on the Atmel HLCDC Atomic mode-setting conversion
work [1].
Best Regards,
Boris
[1]https://lkml.org/lkml/2015/2/4/658
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 2 +-
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h| 2 +
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 108
3 files changed, 111 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index de6973d..4fd1683 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -201,7 +201,7 @@ static int atmel_hlcdc_crtc_atomic_check(struct drm_crtc *c,
if (atmel_hlcdc_dc_mode_valid(crtc->dc, &s->adjusted_mode) != MODE_OK)
return -EINVAL;
- return 0;
+ return atmel_hlcdc_plane_prepare_disc_area(s);
}
static void atmel_hlcdc_crtc_atomic_begin(struct drm_crtc *c)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
index 015c3f1..1ea9c2c 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
@@ -148,6 +148,8 @@ int atmel_hlcdc_dc_mode_valid(struct atmel_hlcdc_dc *dc,
struct atmel_hlcdc_planes *
atmel_hlcdc_create_planes(struct drm_device *dev);
+int atmel_hlcdc_plane_prepare_disc_area(struct drm_crtc_state *c_state);
+
void atmel_hlcdc_crtc_irq(struct drm_crtc *c);
void atmel_hlcdc_crtc_cancel_page_flip(struct drm_crtc *crtc,
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
index 6c6fcae..dbf97d9 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
@@ -51,6 +51,13 @@ struct atmel_hlcdc_plane_state {
u8 alpha;
+ bool disc_updated;
+
+ int disc_x;
+ int disc_y;
+ int disc_w;
+ int disc_h;
+
/* These fields are private and should not be touched */
int bpp[ATMEL_HLCDC_MAX_PLANES];
unsigned int offsets[ATMEL_HLCDC_MAX_PLANES];
@@ -428,6 +435,104 @@ static void atmel_hlcdc_plane_update_buffers(struct
atmel_hlcdc_plane *plane,
}
}
+int
+atmel_hlcdc_plane_prepare_disc_area(struct drm_crtc_state *c_state)
+{
+ int disc_x = 0, disc_y = 0, disc_w = 0, disc_h = 0;
+ const struct atmel_hlcdc_layer_cfg_layout *layout;
+ struct atmel_hlcdc_plane_state *primary_state;
+ struct drm_plane_state *primary_s;
+ struct atmel_hlcdc_plane *primary;
+ struct drm_plane *ovl;
+
+ primary = drm_plane_to_atmel_hlcdc_plane(c_state->crtc->primary);
+ layout = &primary->layer.desc->layout;
+ if (!layout->disc_pos || !layout->disc_size)
+ return 0;
+
+ primary_s = drm_atomic_get_plane_state(c_state->state,
+ &primary->base);
+ if (IS_ERR(primary_s))
+ return PTR_ERR(primary_s);
+
+ primary_state = drm_plane_state_to_atmel_hlcdc_plane_state(primary_s);
+
+ drm_atomic_crtc_state_for_each_plane(ovl, c_state) {
+ struct atmel_hlcdc_plane_state *ovl_state;
+ struct drm_plane_state *ovl_s;
+
+ if (ovl == c_state->crtc->primary)
+ continue;
+
+ ovl_s = drm_atomic_get_plane_state(c_state->state, ovl);
+ if (IS_ERR(ovl_s))
+ return PTR_ERR(ovl_s);
+
+ ovl_state = drm_plane_state_to_atmel_hlcdc_plane_state(ovl_s);
+
+ if (!ovl_s->fb ||
+ atmel_hlcdc_format_embeds_alpha(ovl_s->fb->pixel_format) ||
+ ovl_state->alpha != 255)
+ continue;
+
+ /* TODO: implement a smarter hidden area detection */
+ if (ovl_state->crtc_h * ovl_state->crtc_w < disc_h * disc_w)
+ continue;
+
+ disc_x = ovl_state->crtc_x;
+ disc_y = ovl_state->crtc_y;
+ disc_h = ovl_state->crtc_h;
+ disc_w = ovl_state->crtc_w;
+ }
+
+ if (disc_x == primary_state->disc_x &&
+ disc_y == primary_state->disc_y &&
+ disc_w == primary_state->disc_w &&
+ disc_h == primary_state->disc_h)
+ return 0;
+
+
+ primary_state->disc_x = disc_x;
+
[PATCH] drm: atmel-hlcdc: reset layer A2Q and UPDATE bits when disabling it
The A2Q (Add To Queue) and UPDATE bits are left in their previous state when resetting the layer. This lead to weird behavior when enabling the plane again: the framebuffer previously queued is dequeued and we end up with access to an old memory region. Reset those bits when resetting the channel. Signed-off-by: Boris Brezillon --- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.c b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.c index 063d2a7..e79bd9b 100644 --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.c +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.c @@ -311,7 +311,8 @@ int atmel_hlcdc_layer_disable(struct atmel_hlcdc_layer *layer) /* Disable the layer */ regmap_write(regmap, desc->regs_offset + ATMEL_HLCDC_LAYER_CHDR, -ATMEL_HLCDC_LAYER_RST); +ATMEL_HLCDC_LAYER_RST | ATMEL_HLCDC_LAYER_A2Q | +ATMEL_HLCDC_LAYER_UPDATE); /* Clear all pending interrupts */ regmap_read(regmap, desc->regs_offset + ATMEL_HLCDC_LAYER_ISR, &isr); -- 1.9.1
[Bug 89012] Incorrect behaviour of half_pixel_center = 0 rasterizer setting on R600 and SI
https://bugs.freedesktop.org/show_bug.cgi?id=89012 Bug ID: 89012 Summary: Incorrect behaviour of half_pixel_center = 0 rasterizer setting on R600 and SI Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: axel.davy at ens.fr QA Contact: dri-devel at lists.freedesktop.org Created attachment 113228 --> https://bugs.freedesktop.org/attachment.cgi?id=113228&action=edit result drawn by the test. The bottom triangle is wrong. Tested on Evergreen and CAPE VERDE. Nine uses the rasterize setting half_pixel_center = 0, which means, as the docs puts it: "the rasterizer should use (0, 0) pixel centers for determining pixel ownership". This is the mode needed for d3d9. The hw has a state for that. For example on SI, PA_SU_VTX_CNTL has PIX_CENTER set to 0 to get this rasterizer mode. The doc says that the hw implements it by adding 0.5. This is the same for R600. But is seems it requires some other things to work, or that it is buggy, or something else we don't know. We have some games having bugs because of off by 1 results for the drawing. This causes red shadows for example for Borderlands 2. Nouveau and llvmpipe don't hit these bugs. The problem is that the translation seems to suffer precision issue or something. We tried play a lot with the states for IEEE-> fixed float prevision on the two cards and with FLOAT_ROUND, but that didn't solve the issue. The problem can be reproduced with the attached demo, using Xnine (you need edit Xnine.c to fix the loading path of the nine module). This attached image show the visual result: on two triangles drawn, one gets off-by one pixels(the one of the bottom). These issues only happen with corner cases vertex positions. The program also outputs some numbers, and the green ones should show 1, but on R600 and radeonsi they will show 0.98. the fact this result is below 1, will make floor result in the wrong number, and causes the off by one pixel issue of the demo. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150206/7d3978ef/attachment.html>
[Bug 89012] Incorrect behaviour of half_pixel_center = 0 rasterizer setting on R600 and SI
https://bugs.freedesktop.org/show_bug.cgi?id=89012 --- Comment #1 from Axel Davy --- Created attachment 113229 --> https://bugs.freedesktop.org/attachment.cgi?id=113229&action=edit Image showing the expected triangle (top, drawn with nouveau), and the triangle got on R600/SI (bottom) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150206/3583c3d8/attachment.html>
[Bug 89012] Incorrect behaviour of half_pixel_center = 0 rasterizer setting on R600 and SI
https://bugs.freedesktop.org/show_bug.cgi?id=89012 Tiziano Bacocco changed: What|Removed |Added CC||tizbac2 at gmail.com --- Comment #2 from Tiziano Bacocco --- Created attachment 113231 --> https://bugs.freedesktop.org/attachment.cgi?id=113231&action=edit Xnine testcase that checks the output of fract on texcoord.x*16-1/256 Beware that the part to d3dadapter9.so is hardcoded so you will need to change it This testcase renders a quad of two triangles that cover the entire screen ( 256x16) , and outputs what happens with frac along the X axis on the 15th line, where the triangle that has problems lies -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150206/3fe9dee7/attachment.html>
[Bug 89014] PIPE_QUERY_GPU_FINISHED is not acting as expected on SI
https://bugs.freedesktop.org/show_bug.cgi?id=89014 Bug ID: 89014 Summary: PIPE_QUERY_GPU_FINISHED is not acting as expected on SI Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: axel.davy at ens.fr QA Contact: dri-devel at lists.freedesktop.org I put it as radeonsi bug, but it is probably r600 bug given the implementation seems shared there. Some d3d9 games do manual throttling as advised at the end of: http://www.nvidia.com/object/General_FAQ.html#G4 "A second solution is to use DirectX 9's Asynchronous Query functionality (analogous to using fences in OpenGL). At the end of your frame, insert a D3DQUERYTYPE_EVENT query into your rendering stream. You can then poll whether the GPU has reached this event yet by using GetData." Games like Heroes V of Might and Magic uses two d3d9 event queries (mapped to PIPE_QUERY_GPU_FINISHED) to do manual throttling: end query A loop until query B is OK (d3d9: loop on GetData /pipe: loop on pipe->get_query_result) render present frame end query B loop until query A is OK render present frame etc Only old apps seems to do this manual throttling, as likely recent drivers do it automatically, like Mesa. Both Gallium Nine and Wine get poor performance with this scheme and get same performance (and is the same performance than by forcing a glfinish) Not advertising the query under Gallium Nine gives a enormous performance boost to the app. Similarly advertising the query, but not using PIPE_QUERY_GPU_FINISHED but rather a custom implementation with pipe fences, gives the correct performance. In both cases, forcing glFinish gives the same bad performance than before. Thus PIPE_QUERY_GPU_FINISHED implementation seems to have a bug that makes it acts as glFinish instead of just waiting what was before the end query is rendered. What seems strange is that Wine uses ARB_sync to implement the query, and it doesn't seem to be implemented in Mesa with PIPE_QUERY_GPU_FINISHED. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150206/7bd3487c/attachment-0001.html>
[Bug 89014] PIPE_QUERY_GPU_FINISHED is not acting as expected on SI
https://bugs.freedesktop.org/show_bug.cgi?id=89014 --- Comment #1 from Axel Davy --- Created attachment 113232 --> https://bugs.freedesktop.org/attachment.cgi?id=113232&action=edit Hack used to use pipe fences instead of PIPE_QUERY_GPU_FINISHED -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150206/00c24fb8/attachment.html>
[Bug 89015] [radeonsi] unvanquished & nexuiz crash after switching AA
https://bugs.freedesktop.org/show_bug.cgi?id=89015 Bug ID: 89015 Summary: [radeonsi] unvanquished & nexuiz crash after switching AA Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: arek.rusi at gmail.com QA Contact: dri-devel at lists.freedesktop.org Created attachment 113233 --> https://bugs.freedesktop.org/attachment.cgi?id=113233&action=edit unvanquished.log Without AA everything looks good. Atfer turn on antialliasing both games crash with log: EE r600_texture.c:326 r600_texture_get_fmask_info - Got error in surface_init while allocating FMASK and "_name_of_process_":dri2.c:547: dri2_allocate_textures: Assertion `drawable->msaa_textures[statt]' failed. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150206/8fcf3ec2/attachment.html>
[Bug 89015] [radeonsi] unvanquished & nexuiz crash after switching AA
https://bugs.freedesktop.org/show_bug.cgi?id=89015 --- Comment #1 from Arek RuÅniak --- Created attachment 113234 --> https://bugs.freedesktop.org/attachment.cgi?id=113234&action=edit nexuiz.log sw: linux:drm-next-3.20 mesa: git-d4a461c llvm: r228386 xorg: 1.17.0 + modesetting instead radeon hw: capeverde -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150206/8baa5d34/attachment.html>
[Bug 89012] Incorrect behaviour of half_pixel_center = 0 rasterizer setting on R600 and SI
https://bugs.freedesktop.org/show_bug.cgi?id=89012 Alex Deucher changed: What|Removed |Added Attachment #113228|text/plain |image/png mime type|| -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150206/9f14809c/attachment.html>
[Bug 89012] Incorrect behaviour of half_pixel_center = 0 rasterizer setting on R600 and SI
https://bugs.freedesktop.org/show_bug.cgi?id=89012 Alex Deucher changed: What|Removed |Added Attachment #113229|text/plain |image/png mime type|| -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150206/53383956/attachment.html>
[Bug 84836] VERDE lockup with Unigine Valley/Heaven if ARB_sample_shading is enabled
https://bugs.freedesktop.org/show_bug.cgi?id=84836 Marek Olšák changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Marek Olšák --- Not sure what fixed this, but there is no GPU hang anymore. I also disabled the drirc workaround, so that Heaven would fail to compile its shaders. Tested on my VERDE. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150206/7c552cd5/attachment.html>
[Bug 84662] Long pauses with Unreal demo Elemental on R9270X since : Always flush the HDP cache before submitting a CS to the GPU
https://bugs.freedesktop.org/show_bug.cgi?id=84662 --- Comment #56 from Andy Furniss --- (In reply to Michel Dänzer from comment #55) > Does > http://cgit.freedesktop.org/mesa/mesa/commit/ > ?id=a338dc01866ce50bf7555ee8dc08491c7f63b585 help for this by any chance? No, it's the same on current Mesa head. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150206/7f12696f/attachment-0001.html>
[PATCH -v2 00/14] drm/exynos: clean up + atomic phase 1 and 2
From: Gustavo Padovan Hi, This is the v2 of this patchset. The only difference here is that I added the zpos refactor to this series after the review of v1 today. No changes were made to atomic patches besides solving conflicts after the new zpos changes. This series clean ups a few more paths from exynos-drm with the most important being the removal of the global page flip queue, the zpos refactor, and the removal in driver internal data (struct *_win_data) that was replicating plane data. Following these patches comes the first step torwards atomic modesetting support on exynos. These patches are applied on top of the dpms clean patches from Joonyoung and rebased on exynos-drm-next. Gustavo Padovan (13): drm/exynos: remove unused exynos_crtc->win_enable() callback drm/exynos: remove struct *_win_data abstraction on planes drm/exynos: preset zpos value for overlay planes drm/exynos: make zpos property immutable drm/exynos: remove exynos_plane_destroy() drm/exynos: remove leftover functions declarations drm/exynos: atomic phase 1: use drm_plane_helper_update() drm/exynos: atomic phase 1: use drm_plane_helper_disable() drm/exynos: atomic phase 1: add atomic_begin()/atomic_flush() drm/exynos: atomic phase 1: add .mode_set_nofb() callback drm/exynos: atomic phase 2: wire up state reset(), duplicate() and destroy() drm/exynos: atomic phase 2: keep track of framebuffer pointer drm/exynos: make exynos_plane_mode_set() static Mandeep Singh Baines (1): drm/exynos: track vblank events on a per crtc basis drivers/gpu/drm/bridge/ptn3460.c | 4 + drivers/gpu/drm/exynos/exynos_dp_core.c | 4 + drivers/gpu/drm/exynos/exynos_drm_connector.c | 4 + drivers/gpu/drm/exynos/exynos_drm_crtc.c | 205 ++--- drivers/gpu/drm/exynos/exynos_drm_crtc.h | 7 +- drivers/gpu/drm/exynos/exynos_drm_dpi.c | 4 + drivers/gpu/drm/exynos/exynos_drm_drv.c | 29 +-- drivers/gpu/drm/exynos/exynos_drm_drv.h | 26 +-- drivers/gpu/drm/exynos/exynos_drm_dsi.c | 4 + drivers/gpu/drm/exynos/exynos_drm_fb.c| 2 +- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 245 +++--- drivers/gpu/drm/exynos/exynos_drm_plane.c | 126 +++-- drivers/gpu/drm/exynos/exynos_drm_plane.h | 14 +- drivers/gpu/drm/exynos/exynos_drm_vidi.c | 138 --- drivers/gpu/drm/exynos/exynos_hdmi.c | 4 + drivers/gpu/drm/exynos/exynos_mixer.c | 217 --- 16 files changed, 418 insertions(+), 615 deletions(-) -- 1.9.3
[PATCH -v2 01/14] drm/exynos: remove unused exynos_crtc->win_enable() callback
From: Gustavo Padovan
None of the exynos crtc drivers implements win_enable() so remove it for
better clarity of the code.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_drv.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 1aceafc..66f4a06 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -174,7 +174,6 @@ struct exynos_drm_display {
* hardware overlay is updated.
* @win_mode_set: copy drm overlay info to hw specific overlay info.
* @win_commit: apply hardware specific overlay data to registers.
- * @win_enable: enable hardware specific overlay.
* @win_disable: disable hardware specific overlay.
* @te_handler: trigger to transfer video image at the tearing effect
* synchronization signal if there is a page flip request.
@@ -192,7 +191,6 @@ struct exynos_drm_crtc_ops {
void (*win_mode_set)(struct exynos_drm_crtc *crtc,
struct exynos_drm_plane *plane);
void (*win_commit)(struct exynos_drm_crtc *crtc, int zpos);
- void (*win_enable)(struct exynos_drm_crtc *crtc, int zpos);
void (*win_disable)(struct exynos_drm_crtc *crtc, int zpos);
void (*te_handler)(struct exynos_drm_crtc *crtc);
};
--
1.9.3
[PATCH -v2 02/14] drm/exynos: remove struct *_win_data abstraction on planes
From: Gustavo Padovan
struct {fimd,mixer,vidi}_win_data was just keeping the same data
as struct exynos_drm_plane thus get ride of it and use exynos_drm_plane
directly.
It changes how planes are created and remove .win_mode_set() callback
that was only filling all *_win_data structs.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 9 +-
drivers/gpu/drm/exynos/exynos_drm_crtc.h | 1 +
drivers/gpu/drm/exynos/exynos_drm_drv.c | 14 --
drivers/gpu/drm/exynos/exynos_drm_drv.h | 5 +-
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 182 ++---
drivers/gpu/drm/exynos/exynos_drm_plane.c | 23 +---
drivers/gpu/drm/exynos/exynos_drm_plane.h | 6 +-
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 123 +
drivers/gpu/drm/exynos/exynos_mixer.c | 212 +++---
9 files changed, 183 insertions(+), 392 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 48ccab7..47dd2b0 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -239,13 +239,13 @@ static struct drm_crtc_funcs exynos_crtc_funcs = {
};
struct exynos_drm_crtc *exynos_drm_crtc_create(struct drm_device *drm_dev,
+ struct drm_plane *plane,
int pipe,
enum exynos_drm_output_type type,
struct exynos_drm_crtc_ops *ops,
void *ctx)
{
struct exynos_drm_crtc *exynos_crtc;
- struct drm_plane *plane;
struct exynos_drm_private *private = drm_dev->dev_private;
struct drm_crtc *crtc;
int ret;
@@ -262,12 +262,6 @@ struct exynos_drm_crtc *exynos_drm_crtc_create(struct
drm_device *drm_dev,
exynos_crtc->type = type;
exynos_crtc->ops = ops;
exynos_crtc->ctx = ctx;
- plane = exynos_plane_init(drm_dev, 1 << pipe,
- DRM_PLANE_TYPE_PRIMARY);
- if (IS_ERR(plane)) {
- ret = PTR_ERR(plane);
- goto err_plane;
- }
crtc = &exynos_crtc->base;
@@ -284,7 +278,6 @@ struct exynos_drm_crtc *exynos_drm_crtc_create(struct
drm_device *drm_dev,
err_crtc:
plane->funcs->destroy(plane);
-err_plane:
kfree(exynos_crtc);
return ERR_PTR(ret);
}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.h
b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
index 6258b80..e1fd2ef 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
@@ -18,6 +18,7 @@
#include "exynos_drm_drv.h"
struct exynos_drm_crtc *exynos_drm_crtc_create(struct drm_device *drm_dev,
+ struct drm_plane *plane,
int pipe,
enum exynos_drm_output_type type,
struct exynos_drm_crtc_ops *ops,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 1bcbe07..c598197 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -55,7 +55,6 @@ static int exynos_drm_load(struct drm_device *dev, unsigned
long flags)
{
struct exynos_drm_private *private;
int ret;
- int nr;
private = kzalloc(sizeof(struct exynos_drm_private), GFP_KERNEL);
if (!private)
@@ -81,19 +80,6 @@ static int exynos_drm_load(struct drm_device *dev, unsigned
long flags)
exynos_drm_mode_config_init(dev);
- for (nr = 0; nr < MAX_PLANE; nr++) {
- struct drm_plane *plane;
- unsigned long possible_crtcs = (1 << MAX_CRTC) - 1;
-
- plane = exynos_plane_init(dev, possible_crtcs,
- DRM_PLANE_TYPE_OVERLAY);
- if (!IS_ERR(plane))
- continue;
-
- ret = PTR_ERR(plane);
- goto err_mode_config_cleanup;
- }
-
/* setup possible_clones. */
exynos_drm_encoder_setup(dev);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 66f4a06..7ea7648 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -78,6 +78,7 @@ enum exynos_drm_output_type {
* @transparency: transparency on or off.
* @activated: activated or not.
* @enabled: enabled or not.
+ * @resume: to resume or not.
*
* this structure is common to exynos SoC and its contents would be copied
* to hardware specific overlay info.
@@ -112,6 +113,7 @@ struct exynos_drm_plane {
bool transparency:1;
bool activated:1;
bool enabled:1;
+ bool resume:1;
};
/*
@@ -172,7 +174,6 @@ str
[PATCH -v2 03/14] drm/exynos: preset zpos value for overlay planes
From: Gustavo Padovan
Usually userspace don't want to have two overlay planes on the same zpos
so this change assign a different zpos for each plane. Before this change
a zpos of value zero was created for all planes so the userspace had to
set up the zpos of every plane it wanted to use.
Also all places that were storing zpos positions are now unsigned int.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_drv.h | 7 +++
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 24 +++-
drivers/gpu/drm/exynos/exynos_drm_plane.c | 16 +---
drivers/gpu/drm/exynos/exynos_drm_plane.h | 3 ++-
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 17 +
drivers/gpu/drm/exynos/exynos_mixer.c | 11 +--
6 files changed, 35 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 7ea7648..a3a2d63 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -21,7 +21,6 @@
#define MAX_CRTC 3
#define MAX_PLANE 5
#define MAX_FB_BUFFER 4
-#define DEFAULT_ZPOS -1
#define to_exynos_crtc(x) container_of(x, struct exynos_drm_crtc, base)
#define to_exynos_plane(x) container_of(x, struct exynos_drm_plane, base)
@@ -104,7 +103,7 @@ struct exynos_drm_plane {
unsigned int pitch;
uint32_t pixel_format;
dma_addr_t dma_addr[MAX_FB_BUFFER];
- int zpos;
+ unsigned int zpos;
unsigned int index_color;
bool default_win:1;
@@ -189,8 +188,8 @@ struct exynos_drm_crtc_ops {
int (*enable_vblank)(struct exynos_drm_crtc *crtc);
void (*disable_vblank)(struct exynos_drm_crtc *crtc);
void (*wait_for_vblank)(struct exynos_drm_crtc *crtc);
- void (*win_commit)(struct exynos_drm_crtc *crtc, int zpos);
- void (*win_disable)(struct exynos_drm_crtc *crtc, int zpos);
+ void (*win_commit)(struct exynos_drm_crtc *crtc, unsigned int zpos);
+ void (*win_disable)(struct exynos_drm_crtc *crtc, unsigned int zpos);
void (*te_handler)(struct exynos_drm_crtc *crtc);
};
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 489ce90..990ead434 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -195,7 +195,12 @@ static inline struct fimd_driver_data
*drm_fimd_get_driver_data(
static void fimd_wait_for_vblank(struct exynos_drm_crtc *crtc)
{
- struct fimd_context *ctx = crtc->ctx;
+ struct fimd_context *ctx;
+
+ if (!crtc)
+ return;
+
+ ctx = crtc->ctx;
if (ctx->suspended)
return;
@@ -601,11 +606,10 @@ static void fimd_shadow_protect_win(struct fimd_context
*ctx,
writel(val, ctx->regs + reg);
}
-static void fimd_win_commit(struct exynos_drm_crtc *crtc, int zpos)
+static void fimd_win_commit(struct exynos_drm_crtc *crtc, unsigned int win)
{
struct fimd_context *ctx = crtc->ctx;
struct exynos_drm_plane *plane;
- int win = zpos;
dma_addr_t dma_addr;
unsigned long val, alpha, size, offset;
unsigned int last_x, last_y, buf_offsize, line_size;
@@ -613,9 +617,6 @@ static void fimd_win_commit(struct exynos_drm_crtc *crtc,
int zpos)
if (ctx->suspended)
return;
- if (win == DEFAULT_ZPOS)
- win = ctx->default_win;
-
if (win < 0 || win >= WINDOWS_NR)
return;
@@ -731,14 +732,10 @@ static void fimd_win_commit(struct exynos_drm_crtc *crtc,
int zpos)
atomic_set(&ctx->win_updated, 1);
}
-static void fimd_win_disable(struct exynos_drm_crtc *crtc, int zpos)
+static void fimd_win_disable(struct exynos_drm_crtc *crtc, unsigned int win)
{
struct fimd_context *ctx = crtc->ctx;
struct exynos_drm_plane *plane;
- int win = zpos;
-
- if (win == DEFAULT_ZPOS)
- win = ctx->default_win;
if (win < 0 || win >= WINDOWS_NR)
return;
@@ -1000,13 +997,14 @@ static int fimd_bind(struct device *dev, struct device
*master, void *data)
struct drm_device *drm_dev = data;
struct exynos_drm_plane *exynos_plane;
enum drm_plane_type type;
- int zpos, ret;
+ unsigned int zpos;
+ int ret;
for (zpos = 0; zpos < WINDOWS_NR; zpos++) {
type = (zpos == ctx->default_win) ? DRM_PLANE_TYPE_PRIMARY :
DRM_PLANE_TYPE_OVERLAY;
exynos_plane_init(drm_dev, &ctx->planes[zpos], 1 << ctx->pipe,
- type);
+ type, zpos);
}
ret = fimd_ctx_initialize(ctx, drm_dev);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index 61c3954..8292819 100644
--- a/drivers/gpu/drm/exynos/exynos_dr
[PATCH -v2 04/14] drm/exynos: make zpos property immutable
From: Gustavo Padovan
We already set each plane zpos at init, after that changes to zpos are
not expected. This patch turns zpos into a read-only property so now it is
impossible to set zpos.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_plane.c | 21 ++---
1 file changed, 2 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index 8292819..3847545 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -185,27 +185,10 @@ static void exynos_plane_destroy(struct drm_plane *plane)
drm_plane_cleanup(plane);
}
-static int exynos_plane_set_property(struct drm_plane *plane,
-struct drm_property *property,
-uint64_t val)
-{
- struct drm_device *dev = plane->dev;
- struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
- struct exynos_drm_private *dev_priv = dev->dev_private;
-
- if (property == dev_priv->plane_zpos_property) {
- exynos_plane->zpos = val;
- return 0;
- }
-
- return -EINVAL;
-}
-
static struct drm_plane_funcs exynos_plane_funcs = {
.update_plane = exynos_update_plane,
.disable_plane = exynos_disable_plane,
.destroy= exynos_plane_destroy,
- .set_property = exynos_plane_set_property,
};
static void exynos_plane_attach_zpos_property(struct drm_plane *plane,
@@ -217,8 +200,8 @@ static void exynos_plane_attach_zpos_property(struct
drm_plane *plane,
prop = dev_priv->plane_zpos_property;
if (!prop) {
- prop = drm_property_create_range(dev, 0, "zpos", 0,
-MAX_PLANE - 1);
+ prop = drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE,
+"zpos", 0, MAX_PLANE - 1);
if (!prop)
return;
--
1.9.3
[PATCH -v2 05/14] drm/exynos: remove exynos_plane_destroy()
From: Gustavo Padovan
The .destroy() callback for exynos can be replaced by drm_plane_cleanup().
The only extra operation on exynos_plane_destroy() was a call to
exynos_plane_disable() but the plane is already disabled by a earlier call
to drm_framebuffer_remove().
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_plane.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index 3847545..4367379 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -179,16 +179,10 @@ static int exynos_disable_plane(struct drm_plane *plane)
return 0;
}
-static void exynos_plane_destroy(struct drm_plane *plane)
-{
- exynos_disable_plane(plane);
- drm_plane_cleanup(plane);
-}
-
static struct drm_plane_funcs exynos_plane_funcs = {
.update_plane = exynos_update_plane,
.disable_plane = exynos_disable_plane,
- .destroy= exynos_plane_destroy,
+ .destroy= drm_plane_cleanup,
};
static void exynos_plane_attach_zpos_property(struct drm_plane *plane,
--
1.9.3
[PATCH -v2 06/14] drm/exynos: remove leftover functions declarations
From: Gustavo Padovan These functions were already removed by previous cleanup work, but these ones were left behind. Signed-off-by: Gustavo Padovan Acked-by: Joonyoung Shim --- drivers/gpu/drm/exynos/exynos_drm_crtc.h | 6 -- 1 file changed, 6 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.h b/drivers/gpu/drm/exynos/exynos_drm_crtc.h index e1fd2ef..0ecd8fc 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.h +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.h @@ -28,12 +28,6 @@ void exynos_drm_crtc_disable_vblank(struct drm_device *dev, int pipe); void exynos_drm_crtc_finish_pageflip(struct drm_device *dev, int pipe); void exynos_drm_crtc_complete_scanout(struct drm_framebuffer *fb); -void exynos_drm_crtc_plane_mode_set(struct drm_crtc *crtc, - struct exynos_drm_plane *plane); -void exynos_drm_crtc_plane_commit(struct drm_crtc *crtc, int zpos); -void exynos_drm_crtc_plane_enable(struct drm_crtc *crtc, int zpos); -void exynos_drm_crtc_plane_disable(struct drm_crtc *crtc, int zpos); - /* This function gets pipe value to crtc device matched with out_type. */ int exynos_drm_crtc_get_pipe_from_type(struct drm_device *drm_dev, unsigned int out_type); -- 1.9.3
[PATCH -v2 07/14] drm/exynos: track vblank events on a per crtc basis
From: Mandeep Singh Baines
The goal of the change is to make sure we send the vblank event on the
current vblank. My hope is to fix any races that might be causing flicker.
After this change I only see a flicker in the transition plymouth and
X11.
Simplified the code by tracking vblank events on a per-crtc basis. This
allowed me to remove all error paths from the callback. It also allowed
me to remove the vblank wait from the callback.
Signed-off-by: Mandeep Singh Baines
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 92 +++-
drivers/gpu/drm/exynos/exynos_drm_drv.c | 13 -
drivers/gpu/drm/exynos/exynos_drm_drv.h | 6 +--
3 files changed, 44 insertions(+), 67 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 47dd2b0..eb49195 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -34,9 +34,8 @@ static void exynos_drm_crtc_dpms(struct drm_crtc *crtc, int
mode)
if (mode > DRM_MODE_DPMS_ON) {
/* wait for the completion of page flip. */
if (!wait_event_timeout(exynos_crtc->pending_flip_queue,
- !atomic_read(&exynos_crtc->pending_flip),
- HZ/20))
- atomic_set(&exynos_crtc->pending_flip, 0);
+ (exynos_crtc->event == NULL), HZ/20))
+ exynos_crtc->event = NULL;
drm_crtc_vblank_off(crtc);
}
@@ -164,11 +163,10 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc
*crtc,
uint32_t page_flip_flags)
{
struct drm_device *dev = crtc->dev;
- struct exynos_drm_private *dev_priv = dev->dev_private;
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
struct drm_framebuffer *old_fb = crtc->primary->fb;
unsigned int crtc_w, crtc_h;
- int ret = -EINVAL;
+ int ret;
/* when the page flip is requested, crtc's dpms should be on */
if (exynos_crtc->dpms > DRM_MODE_DPMS_ON) {
@@ -176,48 +174,49 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc
*crtc,
return -EINVAL;
}
- mutex_lock(&dev->struct_mutex);
+ if (!event)
+ return -EINVAL;
- if (event) {
- /*
-* the pipe from user always is 0 so we can set pipe number
-* of current owner to event.
-*/
- event->pipe = exynos_crtc->pipe;
+ spin_lock_irq(&dev->event_lock);
+ if (exynos_crtc->event) {
+ ret = -EBUSY;
+ goto out;
+ }
- ret = drm_vblank_get(dev, exynos_crtc->pipe);
- if (ret) {
- DRM_DEBUG("failed to acquire vblank counter\n");
+ ret = drm_vblank_get(dev, exynos_crtc->pipe);
+ if (ret) {
+ DRM_DEBUG("failed to acquire vblank counter\n");
+ goto out;
+ }
- goto out;
- }
+ exynos_crtc->event = event;
+ spin_unlock_irq(&dev->event_lock);
+ /*
+* the pipe from user always is 0 so we can set pipe number
+* of current owner to event.
+*/
+ event->pipe = exynos_crtc->pipe;
+
+ crtc->primary->fb = fb;
+ crtc_w = fb->width - crtc->x;
+ crtc_h = fb->height - crtc->y;
+ ret = exynos_update_plane(crtc->primary, crtc, fb, 0, 0,
+ crtc_w, crtc_h, crtc->x, crtc->y,
+ crtc_w, crtc_h);
+ if (ret) {
+ crtc->primary->fb = old_fb;
spin_lock_irq(&dev->event_lock);
- list_add_tail(&event->base.link,
- &dev_priv->pageflip_event_list);
- atomic_set(&exynos_crtc->pending_flip, 1);
+ exynos_crtc->event = NULL;
+ drm_vblank_put(dev, exynos_crtc->pipe);
spin_unlock_irq(&dev->event_lock);
-
- crtc->primary->fb = fb;
- crtc_w = fb->width - crtc->x;
- crtc_h = fb->height - crtc->y;
- ret = exynos_update_plane(crtc->primary, crtc, fb, 0, 0,
- crtc_w, crtc_h, crtc->x, crtc->y,
- crtc_w, crtc_h);
- if (ret) {
- crtc->primary->fb = old_fb;
-
- spin_lock_irq(&dev->event_lock);
- drm_vblank_put(dev, exynos_crtc->pipe);
- list_del(&event->base.link);
- atomic_set(&exynos_crtc->pending_flip, 0);
- spin_unlock_irq(&dev->event_lock);
-
- goto out;
- }
+ return ret;
}
+
+ return 0;
+
out:
- mutex_
[PATCH -v2 08/14] drm/exynos: atomic phase 1: use drm_plane_helper_update()
From: Gustavo Padovan
Rip out the check from exynos_update_plane() and create
exynos_check_plane() for the check phase enabling use to use
the atomic helpers to call our check and update phases when updating
planes.
Update all users of exynos_update_plane() accordingly to call
exynos_check_plane() before.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 29
drivers/gpu/drm/exynos/exynos_drm_plane.c | 37 ++-
drivers/gpu/drm/exynos/exynos_drm_plane.h | 2 +-
3 files changed, 43 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index eb49195..1c0d936 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -116,6 +116,7 @@ static int exynos_drm_crtc_mode_set_base(struct drm_crtc
*crtc, int x, int y,
struct drm_framebuffer *fb = crtc->primary->fb;
unsigned int crtc_w;
unsigned int crtc_h;
+ int ret;
/* when framebuffer changing is requested, crtc's dpms should be on */
if (exynos_crtc->dpms > DRM_MODE_DPMS_ON) {
@@ -123,11 +124,16 @@ static int exynos_drm_crtc_mode_set_base(struct drm_crtc
*crtc, int x, int y,
return -EPERM;
}
+ ret = exynos_check_plane(crtc->primary, fb);
+ if (ret)
+ return ret;
+
crtc_w = fb->width - x;
crtc_h = fb->height - y;
+ exynos_update_plane(crtc->primary, crtc, fb, 0, 0,
+ crtc_w, crtc_h, x, y, crtc_w, crtc_h);
- return exynos_update_plane(crtc->primary, crtc, fb, 0, 0,
- crtc_w, crtc_h, x, y, crtc_w, crtc_h);
+ return 0;
}
static void exynos_drm_crtc_disable(struct drm_crtc *crtc)
@@ -164,7 +170,6 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc,
{
struct drm_device *dev = crtc->dev;
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
- struct drm_framebuffer *old_fb = crtc->primary->fb;
unsigned int crtc_w, crtc_h;
int ret;
@@ -183,6 +188,10 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc,
goto out;
}
+ ret = exynos_check_plane(crtc->primary, fb);
+ if (ret)
+ goto out;
+
ret = drm_vblank_get(dev, exynos_crtc->pipe);
if (ret) {
DRM_DEBUG("failed to acquire vblank counter\n");
@@ -201,17 +210,9 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc,
crtc->primary->fb = fb;
crtc_w = fb->width - crtc->x;
crtc_h = fb->height - crtc->y;
- ret = exynos_update_plane(crtc->primary, crtc, fb, 0, 0,
- crtc_w, crtc_h, crtc->x, crtc->y,
- crtc_w, crtc_h);
- if (ret) {
- crtc->primary->fb = old_fb;
- spin_lock_irq(&dev->event_lock);
- exynos_crtc->event = NULL;
- drm_vblank_put(dev, exynos_crtc->pipe);
- spin_unlock_irq(&dev->event_lock);
- return ret;
- }
+ exynos_update_plane(crtc->primary, crtc, fb, 0, 0,
+ crtc_w, crtc_h, crtc->x, crtc->y,
+ crtc_w, crtc_h);
return 0;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index 4367379..3d7c749 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -141,21 +141,15 @@ void exynos_plane_mode_set(struct drm_plane *plane,
struct drm_crtc *crtc,
plane->crtc = crtc;
}
-int
+void
exynos_update_plane(struct drm_plane *plane, struct drm_crtc *crtc,
struct drm_framebuffer *fb, int crtc_x, int crtc_y,
unsigned int crtc_w, unsigned int crtc_h,
uint32_t src_x, uint32_t src_y,
uint32_t src_w, uint32_t src_h)
{
-
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
- int ret;
-
- ret = exynos_check_plane(plane, fb);
- if (ret < 0)
- return ret;
exynos_plane_mode_set(plane, crtc, fb, crtc_x, crtc_y,
crtc_w, crtc_h, src_x >> 16, src_y >> 16,
@@ -163,8 +157,6 @@ exynos_update_plane(struct drm_plane *plane, struct
drm_crtc *crtc,
if (exynos_crtc->ops->win_commit)
exynos_crtc->ops->win_commit(exynos_crtc, exynos_plane->zpos);
-
- return 0;
}
static int exynos_disable_plane(struct drm_plane *plane)
@@ -180,11 +172,34 @@ static int exynos_disable_plane(struct drm_plane *plane)
}
static struct drm_plane_funcs exynos_plane_funcs = {
- .update_plane = exynos_update_plane,
+ .update_plane = drm_plane_helper_update,
.disable_plane = exyn
[PATCH -v2 09/14] drm/exynos: atomic phase 1: use drm_plane_helper_disable()
From: Gustavo Padovan
The atomic helper to disable planes also uses the optional
.atomic_disable() helper. The unique operation it does is calling
.win_disable()
exynos_drm_fb_get_buf_cnt() needs a fb check too to avoid a null pointer.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_fb.c| 2 +-
drivers/gpu/drm/exynos/exynos_drm_plane.c | 26 +-
2 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index d346d1e..470456d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -136,7 +136,7 @@ unsigned int exynos_drm_fb_get_buf_cnt(struct
drm_framebuffer *fb)
exynos_fb = to_exynos_fb(fb);
- return exynos_fb->buf_cnt;
+ return exynos_fb ? exynos_fb->buf_cnt : 0;
}
struct drm_framebuffer *
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index 3d7c749..5d3243e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -159,21 +159,9 @@ exynos_update_plane(struct drm_plane *plane, struct
drm_crtc *crtc,
exynos_crtc->ops->win_commit(exynos_crtc, exynos_plane->zpos);
}
-static int exynos_disable_plane(struct drm_plane *plane)
-{
- struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
- struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(plane->crtc);
-
- if (exynos_crtc->ops->win_disable)
- exynos_crtc->ops->win_disable(exynos_crtc,
- exynos_plane->zpos);
-
- return 0;
-}
-
static struct drm_plane_funcs exynos_plane_funcs = {
.update_plane = drm_plane_helper_update,
- .disable_plane = exynos_disable_plane,
+ .disable_plane = drm_plane_helper_disable,
.destroy= drm_plane_cleanup,
};
@@ -195,9 +183,21 @@ static void exynos_plane_atomic_update(struct drm_plane
*plane,
state->src_w >> 16, state->src_h >> 16);
}
+static void exynos_plane_atomic_disable(struct drm_plane *plane,
+ struct drm_plane_state *old_state)
+{
+ struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
+ struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(old_state->crtc);
+
+ if (exynos_crtc->ops->win_disable)
+ exynos_crtc->ops->win_disable(exynos_crtc,
+ exynos_plane->zpos);
+}
+
static const struct drm_plane_helper_funcs plane_helper_funcs = {
.atomic_check = exynos_plane_atomic_check,
.atomic_update = exynos_plane_atomic_update,
+ .atomic_disable = exynos_plane_atomic_disable,
};
static void exynos_plane_attach_zpos_property(struct drm_plane *plane,
--
1.9.3
[PATCH -v2 10/14] drm/exynos: atomic phase 1: add atomic_begin()/atomic_flush()
From: Gustavo Padovan
Add CRTC callbacks .atomic_begin() .atomic_flush(). On exynos they
unprotect the windows before the commit and protects it after based on
a plane mask tha store which plane will be updated.
For that we create two new exynos_crtc callbacks: .win_protect() and
.win_unprotect(). The only driver that implement those now is FIMD.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 34 +
drivers/gpu/drm/exynos/exynos_drm_drv.h | 6
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 49 ---
drivers/gpu/drm/exynos/exynos_drm_plane.c | 4 +++
4 files changed, 76 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 1c0d936..5e7c13e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -153,6 +153,38 @@ static void exynos_drm_crtc_disable(struct drm_crtc *crtc)
}
}
+static void exynos_crtc_atomic_begin(struct drm_crtc *crtc)
+{
+ struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
+ struct drm_plane *plane;
+ int index = 0;
+
+ list_for_each_entry(plane, &crtc->dev->mode_config.plane_list, head) {
+ if (exynos_crtc->ops->win_protect &&
+ exynos_crtc->plane_mask & (0x01 << index))
+ exynos_crtc->ops->win_protect(exynos_crtc, index);
+
+ index++;
+ }
+}
+
+static void exynos_crtc_atomic_flush(struct drm_crtc *crtc)
+{
+ struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
+ struct drm_plane *plane;
+ int index = 0;
+
+ list_for_each_entry(plane, &crtc->dev->mode_config.plane_list, head) {
+ if (exynos_crtc->ops->win_unprotect &&
+ exynos_crtc->plane_mask & (0x01 << index))
+ exynos_crtc->ops->win_unprotect(exynos_crtc, index);
+
+ index++;
+ }
+
+ exynos_crtc->plane_mask = 0;
+}
+
static struct drm_crtc_helper_funcs exynos_crtc_helper_funcs = {
.dpms = exynos_drm_crtc_dpms,
.prepare= exynos_drm_crtc_prepare,
@@ -161,6 +193,8 @@ static struct drm_crtc_helper_funcs
exynos_crtc_helper_funcs = {
.mode_set = exynos_drm_crtc_mode_set,
.mode_set_base = exynos_drm_crtc_mode_set_base,
.disable= exynos_drm_crtc_disable,
+ .atomic_begin = exynos_crtc_atomic_begin,
+ .atomic_flush = exynos_crtc_atomic_flush,
};
static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index ab82772..f025a54 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -175,6 +175,8 @@ struct exynos_drm_display {
* hardware overlay is updated.
* @win_commit: apply hardware specific overlay data to registers.
* @win_disable: disable hardware specific overlay.
+ * @win_protect: protect hardware specific window.
+ * @win_unprotect: unprotect hardware specific window.
* @te_handler: trigger to transfer video image at the tearing effect
* synchronization signal if there is a page flip request.
*/
@@ -190,6 +192,8 @@ struct exynos_drm_crtc_ops {
void (*wait_for_vblank)(struct exynos_drm_crtc *crtc);
void (*win_commit)(struct exynos_drm_crtc *crtc, unsigned int zpos);
void (*win_disable)(struct exynos_drm_crtc *crtc, unsigned int zpos);
+ void (*win_protect)(struct exynos_drm_crtc *crtc, unsigned int zpos);
+ void (*win_unprotect)(struct exynos_drm_crtc *crtc, unsigned int zpos);
void (*te_handler)(struct exynos_drm_crtc *crtc);
};
@@ -206,6 +210,7 @@ struct exynos_drm_crtc_ops {
* we can refer to the crtc to current hardware interrupt occurred through
* this pipe value.
* @dpms: store the crtc dpms value
+ * @plane_mask: store planes to be updated on atomic modesetting
* @event: vblank event that is currently queued for flip
* @ops: pointer to callbacks for exynos drm specific functionality
* @ctx: A pointer to the crtc's implementation specific context
@@ -215,6 +220,7 @@ struct exynos_drm_crtc {
enum exynos_drm_output_type type;
unsigned intpipe;
unsigned intdpms;
+ unsigned intplane_mask;
wait_queue_head_t pending_flip_queue;
struct drm_pending_vblank_event *event;
struct exynos_drm_crtc_ops *ops;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 990ead434..bea70f6 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -590,6 +590,16 @@ static void fimd_shadow_protect_win(struct fimd_context
*ctx,
{
u32 reg, bits, val;
+ /*
+
[PATCH -v2 11/14] drm/exynos: atomic phase 1: add .mode_set_nofb() callback
From: Gustavo Padovan
The new atomic infrastructure needs the .mode_set_nofb() callback to
update CRTC timings before setting any plane.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 60 +---
1 file changed, 9 insertions(+), 51 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 5e7c13e..7fbea8e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -81,59 +81,16 @@ exynos_drm_crtc_mode_fixup(struct drm_crtc *crtc,
return true;
}
-static int
-exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode, int x, int y,
- struct drm_framebuffer *old_fb)
-{
- struct drm_framebuffer *fb = crtc->primary->fb;
- unsigned int crtc_w;
- unsigned int crtc_h;
- int ret;
-
- /*
-* copy the mode data adjusted by mode_fixup() into crtc->mode
-* so that hardware can be seet to proper mode.
-*/
- memcpy(&crtc->mode, adjusted_mode, sizeof(*adjusted_mode));
-
- ret = exynos_check_plane(crtc->primary, fb);
- if (ret < 0)
- return ret;
-
- crtc_w = fb->width - x;
- crtc_h = fb->height - y;
- exynos_plane_mode_set(crtc->primary, crtc, fb, 0, 0,
- crtc_w, crtc_h, x, y, crtc_w, crtc_h);
-
- return 0;
-}
-
-static int exynos_drm_crtc_mode_set_base(struct drm_crtc *crtc, int x, int y,
- struct drm_framebuffer *old_fb)
+static void
+exynos_drm_crtc_mode_set_nofb(struct drm_crtc *crtc)
{
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
- struct drm_framebuffer *fb = crtc->primary->fb;
- unsigned int crtc_w;
- unsigned int crtc_h;
- int ret;
- /* when framebuffer changing is requested, crtc's dpms should be on */
- if (exynos_crtc->dpms > DRM_MODE_DPMS_ON) {
- DRM_ERROR("failed framebuffer changing request.\n");
- return -EPERM;
- }
-
- ret = exynos_check_plane(crtc->primary, fb);
- if (ret)
- return ret;
-
- crtc_w = fb->width - x;
- crtc_h = fb->height - y;
- exynos_update_plane(crtc->primary, crtc, fb, 0, 0,
- crtc_w, crtc_h, x, y, crtc_w, crtc_h);
+ if (WARN_ON(!crtc->state))
+ return;
- return 0;
+ if (exynos_crtc->ops->commit)
+ exynos_crtc->ops->commit(exynos_crtc);
}
static void exynos_drm_crtc_disable(struct drm_crtc *crtc)
@@ -190,8 +147,9 @@ static struct drm_crtc_helper_funcs
exynos_crtc_helper_funcs = {
.prepare= exynos_drm_crtc_prepare,
.commit = exynos_drm_crtc_commit,
.mode_fixup = exynos_drm_crtc_mode_fixup,
- .mode_set = exynos_drm_crtc_mode_set,
- .mode_set_base = exynos_drm_crtc_mode_set_base,
+ .mode_set = drm_helper_crtc_mode_set,
+ .mode_set_nofb = exynos_drm_crtc_mode_set_nofb,
+ .mode_set_base = drm_helper_crtc_mode_set_base,
.disable= exynos_drm_crtc_disable,
.atomic_begin = exynos_crtc_atomic_begin,
.atomic_flush = exynos_crtc_atomic_flush,
--
1.9.3
[PATCH -v2 12/14] drm/exynos: atomic phase 2: wire up state reset(), duplicate() and destroy()
From: Gustavo Padovan
Set CRTC, planes and connectors to use the default implementations from
the atomic helper library. The helpers will work to keep track of state
for each DRM object.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/bridge/ptn3460.c | 4
drivers/gpu/drm/exynos/exynos_dp_core.c | 4
drivers/gpu/drm/exynos/exynos_drm_connector.c | 4
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 6 ++
drivers/gpu/drm/exynos/exynos_drm_dpi.c | 4
drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 ++
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 4
drivers/gpu/drm/exynos/exynos_drm_plane.c | 4
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 4
drivers/gpu/drm/exynos/exynos_hdmi.c | 4
10 files changed, 40 insertions(+)
diff --git a/drivers/gpu/drm/bridge/ptn3460.c b/drivers/gpu/drm/bridge/ptn3460.c
index 826833e..30da10c 100644
--- a/drivers/gpu/drm/bridge/ptn3460.c
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -27,6 +27,7 @@
#include "drm_crtc.h"
#include "drm_crtc_helper.h"
+#include "drm_atomic_helper.h"
#include "drm_edid.h"
#include "drmP.h"
@@ -263,6 +264,9 @@ static struct drm_connector_funcs ptn3460_connector_funcs =
{
.fill_modes = drm_helper_probe_single_connector_modes,
.detect = ptn3460_detect,
.destroy = ptn3460_connector_destroy,
+ .reset = drm_atomic_helper_connector_reset,
+ .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+ .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
};
int ptn3460_bridge_attach(struct drm_bridge *bridge)
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index bf17a60..6704d5c 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
@@ -952,6 +953,9 @@ static struct drm_connector_funcs exynos_dp_connector_funcs
= {
.fill_modes = drm_helper_probe_single_connector_modes,
.detect = exynos_dp_detect,
.destroy = exynos_dp_connector_destroy,
+ .reset = drm_atomic_helper_connector_reset,
+ .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+ .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
};
static int exynos_dp_get_modes(struct drm_connector *connector)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c
b/drivers/gpu/drm/exynos/exynos_drm_connector.c
index ba9b3d5..980b085 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_connector.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c
@@ -13,6 +13,7 @@
#include
#include
+#include
#include
#include "exynos_drm_drv.h"
@@ -182,6 +183,9 @@ static struct drm_connector_funcs exynos_connector_funcs = {
.fill_modes = exynos_drm_connector_fill_modes,
.detect = exynos_drm_connector_detect,
.destroy= exynos_drm_connector_destroy,
+ .reset = drm_atomic_helper_connector_reset,
+ .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+ .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
};
struct drm_connector *exynos_drm_connector_create(struct drm_device *dev,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 7fbea8e..adb56656 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -14,6 +14,8 @@
#include
#include
+#include
+#include
#include "exynos_drm_crtc.h"
#include "exynos_drm_drv.h"
@@ -228,8 +230,12 @@ static struct drm_crtc_funcs exynos_crtc_funcs = {
.set_config = drm_crtc_helper_set_config,
.page_flip = exynos_drm_crtc_page_flip,
.destroy= exynos_drm_crtc_destroy,
+ .reset = drm_atomic_helper_crtc_reset,
+ .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
+ .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
};
+
struct exynos_drm_crtc *exynos_drm_crtc_create(struct drm_device *drm_dev,
struct drm_plane *plane,
int pipe,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
index 37678cf..ced5c23 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
@@ -63,6 +64,9 @@ static struct drm_connector_funcs exynos_dpi_connector_funcs
= {
.detect = exynos_dpi_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
.destroy = exynos_dpi_connector_destroy,
+ .reset = drm_atomic_helper_connector_reset,
+ .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+ .atomic_destroy_state
[PATCH -v2 13/14] drm/exynos: atomic phase 2: keep track of framebuffer pointer
From: Gustavo Padovan Use drm_atomic_set_fb_for_plane() in the legacy page_flip path to keep track of the framebuffer pointer and reference. Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c b/drivers/gpu/drm/exynos/exynos_drm_crtc.c index adb56656..1739212 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c @@ -208,6 +208,9 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc, crtc_w, crtc_h, crtc->x, crtc->y, crtc_w, crtc_h); + if (crtc->primary->state) + drm_atomic_set_fb_for_plane(crtc->primary->state, fb); + return 0; out: -- 1.9.3
[PATCH -v2 14/14] drm/exynos: make exynos_plane_mode_set() static
From: Gustavo Padovan
It is not used outside of the plane scope anymore.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_plane.c | 11 ++-
drivers/gpu/drm/exynos/exynos_drm_plane.h | 5 -
2 files changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index 840e618..31c8b13 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -91,11 +91,12 @@ int exynos_check_plane(struct drm_plane *plane, struct
drm_framebuffer *fb)
return 0;
}
-void exynos_plane_mode_set(struct drm_plane *plane, struct drm_crtc *crtc,
- struct drm_framebuffer *fb, int crtc_x, int crtc_y,
- unsigned int crtc_w, unsigned int crtc_h,
- uint32_t src_x, uint32_t src_y,
- uint32_t src_w, uint32_t src_h)
+static void exynos_plane_mode_set(struct drm_plane *plane, struct drm_crtc
*crtc,
+ struct drm_framebuffer *fb,
+ int crtc_x, int crtc_y,
+ unsigned int crtc_w, unsigned int crtc_h,
+ uint32_t src_x, uint32_t src_y,
+ uint32_t src_w, uint32_t src_h)
{
struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
unsigned int actual_w;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.h
b/drivers/gpu/drm/exynos/exynos_drm_plane.h
index 560ca71..a7b1a21 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.h
@@ -10,11 +10,6 @@
*/
int exynos_check_plane(struct drm_plane *plane, struct drm_framebuffer *fb);
-void exynos_plane_mode_set(struct drm_plane *plane, struct drm_crtc *crtc,
- struct drm_framebuffer *fb, int crtc_x, int crtc_y,
- unsigned int crtc_w, unsigned int crtc_h,
- uint32_t src_x, uint32_t src_y,
- uint32_t src_w, uint32_t src_h);
void exynos_update_plane(struct drm_plane *plane, struct drm_crtc *crtc,
struct drm_framebuffer *fb, int crtc_x, int crtc_y,
unsigned int crtc_w, unsigned int crtc_h,
--
1.9.3
[PATCH 1/2] util: add missing include
Required by strcmp, otherwise we'll error out of the build with the following commit. Signed-off-by: Emil Velikov --- tests/util/format.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tests/util/format.c b/tests/util/format.c index c365ceb..52b3f97 100644 --- a/tests/util/format.c +++ b/tests/util/format.c @@ -29,6 +29,7 @@ #include #include +#include #include -- 2.1.3
[PATCH 2/2] util: silence pointer arithmetic warnings
Signed-off-by: Emil Velikov --- tests/util/Makefile.am | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tests/util/Makefile.am b/tests/util/Makefile.am index aaaf932..1d71c40 100644 --- a/tests/util/Makefile.am +++ b/tests/util/Makefile.am @@ -6,7 +6,8 @@ AM_CPPFLAGS = \ AM_CFLAGS = \ $(CAIRO_CFLAGS) \ - $(WARN_CFLAGS) + $(filter-out -Wpointer-arith, $(WARN_CFLAGS)) + noinst_LTLIBRARIES = \ libutil.la -- 2.1.3
[PATCH 1/2] util: add missing include
Grr... git send-email did not keep the fix of the patches :\ This one should be "PATCH 0.1/6" while "util: silence pointer arithmetic warnings" - "PATCH 1.1/6". Cheers, Emil On 06/02/15 19:42, Emil Velikov wrote: > Required by strcmp, otherwise we'll error out of the build with the > following commit. > > Signed-off-by: Emil Velikov > --- > tests/util/format.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/tests/util/format.c b/tests/util/format.c > index c365ceb..52b3f97 100644 > --- a/tests/util/format.c > +++ b/tests/util/format.c > @@ -29,6 +29,7 @@ > > #include > #include > +#include > > #include > >
[Bug 89015] [radeonsi] unvanquished & nexuiz crash after switching AA
https://bugs.freedesktop.org/show_bug.cgi?id=89015 --- Comment #2 from Arek RuÅniak --- i've tried this with xf86-video-ati and it looks like the problem is in modesetting ddx. With radeon AA works fine. Should i fill new bug in xorg/modesetting thread? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150206/b5068fab/attachment.html>
[PATCH] drm: atmel-hlcdc: add discard area support
On Fri, Feb 06, 2015 at 04:31:02PM +0100, Boris Brezillon wrote:
> The HLCDC IP provides a way to discard a specific area on the primary
> plane (in case at least one of the overlay is activated and alpha
> blending is disabled).
> Doing this will reduce the amount of data to transfer from the main
> memory to the Display Controller, and thus alleviate the load on the
> memory bus (since this link is quite limited on such hardware,
> this kind of optimization is really important).
>
> Signed-off-by: Boris Brezillon
> ---
> Hi Daniel,
>
> Can you tell me if that's what you had in mind for the discard area feature
> we talked about yersterday.
>
> This patch depends on the Atmel HLCDC Atomic mode-setting conversion
> work [1].
>
> Best Regards,
>
> Boris
>
> [1]https://lkml.org/lkml/2015/2/4/658
>
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 2 +-
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h| 2 +
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 108
>
> 3 files changed, 111 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> index de6973d..4fd1683 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> @@ -201,7 +201,7 @@ static int atmel_hlcdc_crtc_atomic_check(struct drm_crtc
> *c,
> if (atmel_hlcdc_dc_mode_valid(crtc->dc, &s->adjusted_mode) != MODE_OK)
> return -EINVAL;
>
> - return 0;
> + return atmel_hlcdc_plane_prepare_disc_area(s);
> }
>
> static void atmel_hlcdc_crtc_atomic_begin(struct drm_crtc *c)
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
> index 015c3f1..1ea9c2c 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
> @@ -148,6 +148,8 @@ int atmel_hlcdc_dc_mode_valid(struct atmel_hlcdc_dc *dc,
> struct atmel_hlcdc_planes *
> atmel_hlcdc_create_planes(struct drm_device *dev);
>
> +int atmel_hlcdc_plane_prepare_disc_area(struct drm_crtc_state *c_state);
> +
> void atmel_hlcdc_crtc_irq(struct drm_crtc *c);
>
> void atmel_hlcdc_crtc_cancel_page_flip(struct drm_crtc *crtc,
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> index 6c6fcae..dbf97d9 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> @@ -51,6 +51,13 @@ struct atmel_hlcdc_plane_state {
>
> u8 alpha;
>
> + bool disc_updated;
> +
> + int disc_x;
> + int disc_y;
> + int disc_w;
> + int disc_h;
> +
> /* These fields are private and should not be touched */
> int bpp[ATMEL_HLCDC_MAX_PLANES];
> unsigned int offsets[ATMEL_HLCDC_MAX_PLANES];
> @@ -428,6 +435,104 @@ static void atmel_hlcdc_plane_update_buffers(struct
> atmel_hlcdc_plane *plane,
> }
> }
>
> +int
> +atmel_hlcdc_plane_prepare_disc_area(struct drm_crtc_state *c_state)
> +{
> + int disc_x = 0, disc_y = 0, disc_w = 0, disc_h = 0;
> + const struct atmel_hlcdc_layer_cfg_layout *layout;
> + struct atmel_hlcdc_plane_state *primary_state;
> + struct drm_plane_state *primary_s;
> + struct atmel_hlcdc_plane *primary;
> + struct drm_plane *ovl;
> +
> + primary = drm_plane_to_atmel_hlcdc_plane(c_state->crtc->primary);
> + layout = &primary->layer.desc->layout;
> + if (!layout->disc_pos || !layout->disc_size)
> + return 0;
> +
> + primary_s = drm_atomic_get_plane_state(c_state->state,
> +&primary->base);
> + if (IS_ERR(primary_s))
> + return PTR_ERR(primary_s);
> +
> + primary_state = drm_plane_state_to_atmel_hlcdc_plane_state(primary_s);
> +
> + drm_atomic_crtc_state_for_each_plane(ovl, c_state) {
> + struct atmel_hlcdc_plane_state *ovl_state;
> + struct drm_plane_state *ovl_s;
> +
> + if (ovl == c_state->crtc->primary)
> + continue;
> +
> + ovl_s = drm_atomic_get_plane_state(c_state->state, ovl);
> + if (IS_ERR(ovl_s))
> + return PTR_ERR(ovl_s);
> +
> + ovl_state = drm_plane_state_to_atmel_hlcdc_plane_state(ovl_s);
Note that right now the atomic helpers do not no-op out null plane state
updates. The assumption is that such plane states aren't requested.
Usually it's not harmful to add more planes by default (just a bit of
busy-work really), but if you have more than 1 crtc then suddenly every
pageflip will be converted into an update spanning more than 1 crtc, and
you most definitely don't want that. This is because we always must the
state for the crtc each plane is connected to. This is also the reason why
my speudo-code started from the planes and not the crtc, so that
unecessary plane states can b
[Intel-gfx] [PATCH] drm: Global atomic state handling
On Fri, Feb 06, 2015 at 11:58:58AM +0200, Jani Nikula wrote:
> On Wed, 05 Nov 2014, Daniel Vetter wrote:
>
> [heavily edited to just show the debugs]
>
> > +struct drm_atomic_state *
> > +drm_atomic_state_alloc(struct drm_device *dev)
> > +{
> > + DRM_DEBUG_KMS("Allocate atomic state %p\n", state);
> > +}
>
> > +void drm_atomic_state_clear(struct drm_atomic_state *state)
> > +{
> > + DRM_DEBUG_KMS("Clearing atomic state %p\n", state);
> > +}
>
> > +void drm_atomic_state_free(struct drm_atomic_state *state)
> > +{
> > + DRM_DEBUG_KMS("Freeing atomic state %p\n", state);
> > +}
>
> > +struct drm_crtc_state *
> > +drm_atomic_get_crtc_state(struct drm_atomic_state *state,
> > + struct drm_crtc *crtc)
> > +{
> > + DRM_DEBUG_KMS("Added [CRTC:%d] %p state to %p\n",
> > + crtc->base.id, crtc_state, state);
> > +}
>
> > +struct drm_plane_state *
> > +drm_atomic_get_plane_state(struct drm_atomic_state *state,
> > + struct drm_plane *plane)
> > +{
> > + DRM_DEBUG_KMS("Added [PLANE:%d] %p state to %p\n",
> > + plane->base.id, plane_state, state);
> > +}
>
> > +struct drm_connector_state *
> > +drm_atomic_get_connector_state(struct drm_atomic_state *state,
> > + struct drm_connector *connector)
> > +{
> > + DRM_DEBUG_KMS("Added [CONNECTOR:%d] %p state to %p\n",
> > + connector->base.id, connector_state, state);
> > +}
>
> > +int drm_atomic_check_only(struct drm_atomic_state *state)
> > +{
> > + DRM_DEBUG_KMS("checking %p\n", state);
> > +}
>
> > +int drm_atomic_commit(struct drm_atomic_state *state)
> > +{
> > + DRM_DEBUG_KMS("commiting %p\n", state);
> > +}
>
> These seem to be rather verbose [1], is this normal or indicative of
> something going awry? If normal, it does seem quite noisy in the logs.
For debugging screw-ups in the state-preparetion, checks and commit
they're fairly useful imo. So definitely valuable for developing atomic
drivers.
Should we instead have a new DRM_DEBUG_ATOMIC to be able to filter these
out as needed?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH] drm: atmel-hlcdc: add discard area support
On Fri, Feb 6, 2015 at 4:11 PM, Daniel Vetter wrote:
> On Fri, Feb 06, 2015 at 04:31:02PM +0100, Boris Brezillon wrote:
>> The HLCDC IP provides a way to discard a specific area on the primary
>> plane (in case at least one of the overlay is activated and alpha
>> blending is disabled).
>> Doing this will reduce the amount of data to transfer from the main
>> memory to the Display Controller, and thus alleviate the load on the
>> memory bus (since this link is quite limited on such hardware,
>> this kind of optimization is really important).
>>
>> Signed-off-by: Boris Brezillon
>> ---
>> Hi Daniel,
>>
>> Can you tell me if that's what you had in mind for the discard area feature
>> we talked about yersterday.
>>
>> This patch depends on the Atmel HLCDC Atomic mode-setting conversion
>> work [1].
>>
>> Best Regards,
>>
>> Boris
>>
>> [1]https://lkml.org/lkml/2015/2/4/658
>>
>> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 2 +-
>> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h| 2 +
>> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 108
>>
>> 3 files changed, 111 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
>> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
>> index de6973d..4fd1683 100644
>> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
>> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
>> @@ -201,7 +201,7 @@ static int atmel_hlcdc_crtc_atomic_check(struct drm_crtc
>> *c,
>> if (atmel_hlcdc_dc_mode_valid(crtc->dc, &s->adjusted_mode) != MODE_OK)
>> return -EINVAL;
>>
>> - return 0;
>> + return atmel_hlcdc_plane_prepare_disc_area(s);
>> }
>>
>> static void atmel_hlcdc_crtc_atomic_begin(struct drm_crtc *c)
>> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
>> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
>> index 015c3f1..1ea9c2c 100644
>> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
>> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
>> @@ -148,6 +148,8 @@ int atmel_hlcdc_dc_mode_valid(struct atmel_hlcdc_dc *dc,
>> struct atmel_hlcdc_planes *
>> atmel_hlcdc_create_planes(struct drm_device *dev);
>>
>> +int atmel_hlcdc_plane_prepare_disc_area(struct drm_crtc_state *c_state);
>> +
>> void atmel_hlcdc_crtc_irq(struct drm_crtc *c);
>>
>> void atmel_hlcdc_crtc_cancel_page_flip(struct drm_crtc *crtc,
>> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
>> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
>> index 6c6fcae..dbf97d9 100644
>> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
>> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
>> @@ -51,6 +51,13 @@ struct atmel_hlcdc_plane_state {
>>
>> u8 alpha;
>>
>> + bool disc_updated;
>> +
>> + int disc_x;
>> + int disc_y;
>> + int disc_w;
>> + int disc_h;
>> +
>> /* These fields are private and should not be touched */
>> int bpp[ATMEL_HLCDC_MAX_PLANES];
>> unsigned int offsets[ATMEL_HLCDC_MAX_PLANES];
>> @@ -428,6 +435,104 @@ static void atmel_hlcdc_plane_update_buffers(struct
>> atmel_hlcdc_plane *plane,
>> }
>> }
>>
>> +int
>> +atmel_hlcdc_plane_prepare_disc_area(struct drm_crtc_state *c_state)
>> +{
>> + int disc_x = 0, disc_y = 0, disc_w = 0, disc_h = 0;
>> + const struct atmel_hlcdc_layer_cfg_layout *layout;
>> + struct atmel_hlcdc_plane_state *primary_state;
>> + struct drm_plane_state *primary_s;
>> + struct atmel_hlcdc_plane *primary;
>> + struct drm_plane *ovl;
>> +
>> + primary = drm_plane_to_atmel_hlcdc_plane(c_state->crtc->primary);
>> + layout = &primary->layer.desc->layout;
>> + if (!layout->disc_pos || !layout->disc_size)
>> + return 0;
>> +
>> + primary_s = drm_atomic_get_plane_state(c_state->state,
>> +&primary->base);
>> + if (IS_ERR(primary_s))
>> + return PTR_ERR(primary_s);
>> +
>> + primary_state = drm_plane_state_to_atmel_hlcdc_plane_state(primary_s);
>> +
>> + drm_atomic_crtc_state_for_each_plane(ovl, c_state) {
>> + struct atmel_hlcdc_plane_state *ovl_state;
>> + struct drm_plane_state *ovl_s;
>> +
>> + if (ovl == c_state->crtc->primary)
>> + continue;
>> +
>> + ovl_s = drm_atomic_get_plane_state(c_state->state, ovl);
>> + if (IS_ERR(ovl_s))
>> + return PTR_ERR(ovl_s);
>> +
>> + ovl_state = drm_plane_state_to_atmel_hlcdc_plane_state(ovl_s);
>
> Note that right now the atomic helpers do not no-op out null plane state
> updates. The assumption is that such plane states aren't requested.
> Usually it's not harmful to add more planes by default (just a bit of
> busy-work really), but if you have more than 1 crtc then suddenly every
> pageflip will be converted into an update spanning more than 1 crtc, and
> you most definitely don't want that. This is because we always must the
> sta
[RFC PATCH v2 3/3] ARM: dts: exynos5420: add async-bridge clocks to disp1 power domain
Hello Andrzej, On 02/06/2015 11:55 AM, Andrzej Hajda wrote: > FIMD and MIXER IPs in disp1 power domain have async-bridges (to GSCALER), > therefore their clocks should be enabled during power domain switch. > > Signed-off-by: Andrzej Hajda > --- > Hi, > > This is 2nd version of the patch. After decrypting manual and discussion > with Marek I guess this set of clocks is more apropriate - async-bridges > are present in MIXER and FIMD, so their clocks should be enabled. > I just tested this version on my Exynos5420 Peach Pit and the power domain failed error does not happen anymore even after enabling and disabling the HDMI display several times. Thanks a lot for fixing this since the dependency was not clear to me from reading the manual. > The 1st version worked for me due to fact I have forgot to remove > clk_ignore_unused kernel boot option during tests ;) > Yes, that has bitten me too many times as well :) > Regards > Andrzej > --- Best regards, Javier
[PATCH] drm/i915: Remove references to previously removed UMS config option
Commit 03dae59c72d8 ("drm/i915: Ditch UMS config option") removed
CONFIG_DRM_I915_UMS from the Kconfig file, but i915_drv.c still
references this option in two #ifndef statements.
As an undefined config option will always be 'false', we can drop
the #ifndefs alltogether and adapt the printed error message.
This inconsistency was found with the undertaker tool.
Signed-off-by: Andreas Ruprecht
---
drivers/gpu/drm/i915/i915_drv.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 8039cec..4ecf85f 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1630,11 +1630,9 @@ static int __init i915_init(void)
if (!(driver.driver_features & DRIVER_MODESET)) {
driver.get_vblank_timestamp = NULL;
-#ifndef CONFIG_DRM_I915_UMS
/* Silently fail loading to not upset userspace. */
- DRM_DEBUG_DRIVER("KMS and UMS disabled.\n");
+ DRM_DEBUG_DRIVER("KMS disabled.\n");
return 0;
-#endif
}
/*
@@ -1650,10 +1648,8 @@ static int __init i915_init(void)
static void __exit i915_exit(void)
{
-#ifndef CONFIG_DRM_I915_UMS
if (!(driver.driver_features & DRIVER_MODESET))
return; /* Never loaded a driver. */
-#endif
drm_pci_exit(&driver, &i915_pci_driver);
}
--
1.9.1
[RFC PATCH 0/3] Fix power domains handling on exynos542x
Hello Joonyoung, On 02/06/2015 06:27 AM, Joonyoung Shim wrote: > On 02/05/2015 11:45 PM, Javier Martinez Canillas wrote: >> >> I also tested on an Exynos5420 Peach Pit Chromebook and both the "Power >> domain power-domain disable failed" message and the system crash are gone. >> > > Really gone out "Power domain power-domain disable failed" message? > > Still i get the message from second try, > > # modetest -M exynos -s 23 at 21:1920x1080 > setting mode 1920x1080 at XR24 on connectors 23, crtc 21 > > # modetest -M exynos -s 23 at 21:1920x1080 > setting mode 1920x1080 at XR24 on connectors 23, crtc 21 > > [ 39.608881] Power domain power-domain disable failed > # modetest -M exynos -s 23 at 21:1920x1080 > setting mode 1920x1080 at XR24 on connectors 23, crtc 21 > > [ 42.827637] Power domain power-domain disable failed > ... > You are right, I tested that if I execute: # for val in 1 0; do echo $val > /sys/class/drm/card0/device/graphics/fb0/blank; done many times I see the "Power domain power-domain disable failed" message again and there is no output in the HDMI display when dpms on. But even in that case, the imprecise external abort does not happen when the exynos_mixer driver tries to access the mixer registers and the system does not crash anymore. So I think that Andrzej's patches are at least a step in the right direction. Best regards, Javier
