Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp624828imm; Fri, 13 Jul 2018 03:37:27 -0700 (PDT) X-Google-Smtp-Source: AAOMgpc8Pm7LVME0zsFe5InehVjnPFRDvGLPR1seIrOCaFgEWOrkoXCdjBRgfmnpkUvR3cEP+SJE X-Received: by 2002:a62:2b4c:: with SMTP id r73-v6mr6483218pfr.134.1531478247183; Fri, 13 Jul 2018 03:37:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531478247; cv=none; d=google.com; s=arc-20160816; b=ZrdrrjrD9FviTb2A1VJVGpQoaryjUB8upd85M61Uogz3pDIy9ai14VGt/xbCSbwkwf EcHb6x96qxujFWFPOZPM10qEjFVi73FsD//c/PprVtUijubiDQxLjDMmOvNdDAmC+CrF 2UMRYc/VlTcqkufXj5r3QqQDgUWzxfS4AtCPsRwkld6yXDik1L85HVTBwg6GtcW+FFF6 gc/HPmcC/ub12hoMmyjZAFwX2AdPRmJqmrV1cUkSYjqiYnlAqIGQVqPV+1ggxfaq0ClC fxX2Y+JdnVoTa9T8XZyj3jZyMpu8AMzPHl6sJfTKPTfmbWj2pDHy9+L8UAa/mrErOBCL vB7g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=5xsC2Iq1vFvOU1OWTSncA+vWfnxLq3GuS2+1pbOIdCs=; b=TbPGlsl8wtyZkl1MxriIPuT5LPebPmCcYXohHi7B9ZPAHkg9fCC5X3w9w8CJaK9Vju mYGhz9OHvO8mbNyHC8IDTbXG8tnVPcQ/Qk5wcHWvYYZEC2P5N6jpNJWTtM0tsPOhvBc0 YIjFQnHnGBOmGQXdMmFfLAWRxMl9HQKgdriPaWXqD1CASRWmxKFE4dMd2H4DCGB9v9le 6458sqAy4QhXQBW7yOar90Zv5bwqpicGdrsHxI9um7NoT/0Hj9OBaDWbCdFTBiB81W6y eMPAt9xqsXPB3myE50mMOfBFCiAHjaUkNVEwwJJawe/WUncbmfjJ0g5ZZRoAopQI/NV/ 2udg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g6-v6si23185943plq.242.2018.07.13.03.37.11; Fri, 13 Jul 2018 03:37:27 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727582AbeGMKue (ORCPT + 99 others); Fri, 13 Jul 2018 06:50:34 -0400 Received: from mail-out.m-online.net ([212.18.0.10]:34236 "EHLO mail-out.m-online.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727161AbeGMKue (ORCPT ); Fri, 13 Jul 2018 06:50:34 -0400 Received: from frontend01.mail.m-online.net (unknown [192.168.8.182]) by mail-out.m-online.net (Postfix) with ESMTP id 41Rq3c0y9yz1qvnN; Fri, 13 Jul 2018 12:36:28 +0200 (CEST) Received: from localhost (dynscan1.mnet-online.de [192.168.6.70]) by mail.m-online.net (Postfix) with ESMTP id 41Rq3c0NRkz1x42D; Fri, 13 Jul 2018 12:36:28 +0200 (CEST) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.182]) by localhost (dynscan1.mail.m-online.net [192.168.6.70]) (amavisd-new, port 10024) with ESMTP id 2K7TJY9CiAxD; Fri, 13 Jul 2018 12:36:26 +0200 (CEST) X-Auth-Info: QoAHGb/CoII+JHh/sRwPwb7jrtCJpAnPbQyapMSPj28= Received: from [IPv6:::1] (unknown [195.140.253.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTPSA; Fri, 13 Jul 2018 12:36:26 +0200 (CEST) Subject: Re: [PATCH] drm: mxsfb: fix runtime PM handling To: Stefan Agner Cc: Anson Huang , airlied@linux.ie, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, dl-linux-imx References: <1531472085-25174-1-git-send-email-Anson.Huang@nxp.com> <90d16681-2a7a-4826-0411-478353d2afe3@denx.de> <00b5faf737efd1054eb4f0f0e6fc8369@agner.ch> From: Marek Vasut Message-ID: <52c0153c-1810-2919-70b7-d57280c83c90@denx.de> Date: Fri, 13 Jul 2018 12:36:17 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <00b5faf737efd1054eb4f0f0e6fc8369@agner.ch> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07/13/2018 12:33 PM, Stefan Agner wrote: > On 13.07.2018 11:12, Marek Vasut wrote: >> On 07/13/2018 11:06 AM, Anson Huang wrote: >> [...] >>>> >>>> On 07/13/2018 10:54 AM, Anson Huang wrote: >>>>> As display power domain is combined with lcdif node on some i.MX >>>>> platforms like i.MX6SL, when lcdif driver is enabled, the mxsfb_load >>>>> is called to enable runtime pm, and a pair of pm_runtime_get_sync and >>>>> pm_runtime_put_sync are also called, that will cause generic power >>>>> domain driver to disable lcdif power domain and lcdif is no longer >>>>> working, the lcdif power should ONLY be turned off when display is >>>>> disabled, so move the pm_runtime_put_sync to mxsfb_unload and remove >>>>> the pm_runtime_get_sync in mxsfb_unload as well, in this way, when >>>>> display is enabled, the lcdif power will be always ON until the >>>>> display is disabled. >>>>> >>>>> Signed-off-by: Anson Huang >>>> >>>> Doesn't this also mean the block will always be on, thus wasting power ? >>> >>> I think drm driver should have somewhere to implement the display >>> disable case, like when fb0 is blank (echo 1 > /sys/class/graphics/fb0/blank), >> >> Isn't this just the fbdev emulation on top of drm/kms ? >> I think this stuff can be compiled out completely. >> >>> then lcdif can be powered gated, and >>> when display is back on (unblank), lcdif needs to be re-initialization and display will >>> be on, current implementation is incorrect, with kernel booting up, lcdif >>> is NOT working at all. >> >> It works fine on MX6SX , so I think this is isolated to MX6SL ? >> I'm CCing Stefan, he might have some valuable feedback here. >> > > Yeah not sure, but putting it in mxsfb_load seems wrong. > > MXSFB uses struct drm_simple_display_pipe_funcs which does have > enable/disable callbacks, probably closer to what we want... Seems to me like this is not something that should be hacked around in the mxsfb driver in the first place, but somewhere else. -- Best regards, Marek Vasut