From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933468AbcLHAto (ORCPT ); Wed, 7 Dec 2016 19:49:44 -0500 Received: from mail-out.m-online.net ([212.18.0.9]:48791 "EHLO mail-out.m-online.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932987AbcLHAtn (ORCPT ); Wed, 7 Dec 2016 19:49:43 -0500 X-Auth-Info: KnqWiK84AMoBZsS4C/LUEyhHgzW0jb5oFH43AElBN6s= Subject: Re: [PATCH] drm/mxsfb: fix pixel clock polarity To: Stefan Agner References: <20161208002706.10147-1-stefan@agner.ch> Cc: airlied@linux.ie, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org From: Marek Vasut Message-ID: Date: Thu, 8 Dec 2016 01:49:03 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161208002706.10147-1-stefan@agner.ch> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/08/2016 01:27 AM, Stefan Agner wrote: > The DRM subsystem specifies the pixel clock polarity from a > controllers perspective: DRM_BUS_FLAG_PIXDATA_NEGEDGE means > the controller drives the data on pixel clocks falling edge. > That is the controllers DOTCLK_POL=0 (Default is data launched > at negative edge). > > Also change the data enable logic to be high active by default > and only change if explicitly requested via bus_flags. With > that defaults are: > - Data enable: high active > - Pixel clock polarity: controller drives data on negative edge > > Signed-off-by: Stefan Agner > --- > Hi Marek, Hi, that was quick, thanks for checking this. > I discovered this while testing on a i.MX 7 eLCDIF IP. Particularly the > non-standard DE polarity was causing issues. I was using a EDT display > which is part of simple panel driver since a while now and does not > specify any bus_flags currently... Of course I could (and probably should) > add the proper bus_flags there too, but there are several displays > which do not specify any polarity and likely rely on sensible driver > standards (which is afact high active for the DE signal). I actually use a panel which requires correct settings of the flags, see e0932f9d7ba9a16f99a84943b720f109de8e3e06 in mainline , so this patch would break things for me. So I wonder whether you should fix the panel driver or whether the mxsfb should be fixed ? > -- > Stefan > > drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 11 +++++++++-- > 1 file changed, 9 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c > index 0818903..4bcc8a3 100644 > --- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c > +++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c > @@ -168,9 +168,16 @@ static void mxsfb_crtc_mode_set_nofb(struct mxsfb_drm_private *mxsfb) > vdctrl0 |= VDCTRL0_HSYNC_ACT_HIGH; > if (m->flags & DRM_MODE_FLAG_PVSYNC) > vdctrl0 |= VDCTRL0_VSYNC_ACT_HIGH; > - if (bus_flags & DRM_BUS_FLAG_DE_HIGH) > + /* Data Enable should be high active by default */ > + if (!(bus_flags & DRM_BUS_FLAG_DE_LOW)) > vdctrl0 |= VDCTRL0_ENABLE_ACT_HIGH; > - if (bus_flags & DRM_BUS_FLAG_PIXDATA_NEGEDGE) > + /* > + * Note: DRM_BUS_FLAG_PIXDATA defines are controller centric, > + * controllers VDCTRL0_DOTCLK is display centric. > + * Drive on positive edige -> display samples on falling edge > + * DRM_BUS_FLAG_PIXDATA_POSEDGE -> VDCTRL0_DOTCLK_ACT_FALLING > + */ > + if (bus_flags & DRM_BUS_FLAG_PIXDATA_POSEDGE) > vdctrl0 |= VDCTRL0_DOTCLK_ACT_FALLING; > > writel(vdctrl0, mxsfb->base + LCDC_VDCTRL0); > -- Best regards, Marek Vasut