From patchwork Fri Nov 18 23:37:33 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Russell King (Oracle)" X-Patchwork-Id: 9437675 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 6D12660469 for ; Fri, 18 Nov 2016 23:40:11 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 50CB229A5D for ; Fri, 18 Nov 2016 23:40:11 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 4532729A5F; Fri, 18 Nov 2016 23:40:11 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.1 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_MED,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 2026E29A5D for ; Fri, 18 Nov 2016 23:40:09 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.85_2 #1 (Red Hat Linux)) id 1c7sjV-0004MB-0a; Fri, 18 Nov 2016 23:38:13 +0000 Received: from pandora.armlinux.org.uk ([2001:4d48:ad52:3201:214:fdff:fe10:1be6]) by bombadil.infradead.org with esmtps (Exim 4.85_2 #1 (Red Hat Linux)) id 1c7sjQ-00045r-Qz for linux-arm-kernel@lists.infradead.org; Fri, 18 Nov 2016 23:38:10 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2014; h=Sender:Content-Type:MIME-Version:Message-ID:Subject:Cc:To:From:Date; bh=Q7eidvsTJslRXygHxcElGAimq2pPqT4zRC9DCDcdmjw=; b=OFwVmvYKPF7ts1GuGna3AD1UCcoRA7Iv/mP5kAuVk7E6uxAVS7sr+bo4k0ZFU+rAwo8d6VDacAxofc/+i5Wuimzl37R/rqKREnoepVly/UrxaR0sMns8utU2FhmfxYN64j8iKSEaC0SGyZ7wEeoanOSqy72QoebDy9skYo9e8g8=; Received: from n2100.armlinux.org.uk ([2002:4e20:1eda:1:214:fdff:fe10:4f86]:40857) by pandora.armlinux.org.uk with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1c7siu-0007vp-UC; Fri, 18 Nov 2016 23:37:37 +0000 Received: from linux by n2100.armlinux.org.uk with local (Exim 4.76) (envelope-from ) id 1c7sir-0006Vy-UZ; Fri, 18 Nov 2016 23:37:33 +0000 Date: Fri, 18 Nov 2016 23:37:33 +0000 From: Russell King - ARM Linux To: Liviu Dudau , Brian Starkey , Mali DP Maintainers Subject: [BUG] hdlcd gets confused about base address Message-ID: <20161118233733.GP1041@n2100.armlinux.org.uk> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20161118_153809_379427_730F879D X-CRM114-Status: GOOD ( 17.30 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: David Airlie , linux-arm-kernel@lists.infradead.org, dri-devel@lists.freedesktop.org Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Virus-Scanned: ClamAV using ClamSMTP Hi, While testing HDMI with Xorg on the Juno board, I find that when Xorg starts up or shuts down, the display is shifted significantly to the right and wrapped in the active region. (No sync bars are visible.) The timings are correct, it behaves as if the start address has been shifted many pixels _into_ the framebuffer. This occurs whenever the display mode size is changed - using xrandr in Xorg shows that changing the resolution triggers the problem almost every time, but changing the refresh rate does not. Using devmem2 to disable and re-enable the HDLCD resolves the issue, and repeated disable/enable cycles do not make the issue re-appear. So, I patched the HDLCD to do this, and testing it with Xorg after several repetitions seems to work. Signed-off-by: Russell King --- What I think is going on is that the FIFO or address generator for reading data from the AXI bus is not properly reset when changing the resolution, and the enable-disable-enable cycle causes the HDLCD hardware to sort itself out. It's (eg) significantly out - for example, to properly align the display, I have to program an address of 0xf4ff0200 into the hardware rather than 0xf5000000 - that's 896 pixels before the real start of the frame buffer. With this patch, a patch to TDA998x to avoid the i2c-designware issue, and xf86-video-armada, I have LXDE running on the Juno. Something I also noticed is this: scanout_start = gem->paddr + plane->state->fb->offsets[0] + plane->state->crtc_y * plane->state->fb->pitches[0] + plane->state->crtc_x * bpp / 8; Surely this should be using src_[xy] (which are the position in the source - iow, memory, and not crtc_[xy] which is the position on the CRTC displayed window. To put it another way, the src_* define the region of the source material that is mapped onto a rectangular area on the display defined by crtc_*. Another note is that since the CRTC can't place the plane in arbitary positions and sizes within the active area, should the atomic_check ensure that crtc_x = crtc_y = 0, and the crtc width/height are the size of the active area? drivers/gpu/drm/arm/hdlcd_crtc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c index 48019ae22ddb..3e97acf6e2a7 100644 --- a/drivers/gpu/drm/arm/hdlcd_crtc.c +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c @@ -150,6 +150,8 @@ static void hdlcd_crtc_enable(struct drm_crtc *crtc) clk_prepare_enable(hdlcd->clk); hdlcd_crtc_mode_set_nofb(crtc); hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 1); + hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 0); + hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 1); } static void hdlcd_crtc_disable(struct drm_crtc *crtc)