Message ID | 20240106223951.387067-2-aford173@gmail.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-18733-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:37c1:b0:101:2151:f287 with SMTP id y1csp307604dyq; Sat, 6 Jan 2024 14:40:51 -0800 (PST) X-Google-Smtp-Source: AGHT+IFQ8sSWilz3V3LJzvyQ76oYbRzxLMrv3gjE1m5ULz6eZH5VzqbkLjLSh7LlH9IsxBoXQNyu X-Received: by 2002:a05:600c:5407:b0:40c:2c36:2a23 with SMTP id he7-20020a05600c540700b0040c2c362a23mr791726wmb.180.1704580851087; Sat, 06 Jan 2024 14:40:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704580851; cv=none; d=google.com; s=arc-20160816; b=gDC1ZAWrdtCUe4J5s+eTebkQ1vkec9wFFZvTcc1PapS8NCSUzuBwUrjmoXiFQFPRQ9 l/juaOr3OWAe6Ek2u1rPBSEdsjPjQYq2ySLLrkoNMbp1h9yWWdczv9KfpSXzKcfpUY/6 aqtmcVpgH/g8fya6Fdzx0PtVtoPa4qa9jL2vYcVqPt5H2OouO1vgII/6x09SGnj6FGhq 0Caum7Y1nst4d5Ua//VO71lDiw0crVxwyq4iet9hA6mK6Km7E+INGsOaUZIcJJu+jyyJ Dvr++iFwoL6ihqVieka6iVZlIBjX+0V7qmq/59/JEs7OghrBU3qkmMygJSWJ4BB/p7cq lYYQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=pjMgdeRpctwTJ7F3CFnuysHXKhIpRAp8TwJ6AUfLDG4=; fh=wWDtD32YjFo6T5hANCl4Ux6OekDxLZ6AKidCvR5NXPg=; b=qMxSxUlYPfFK+7lnngHO9XfbGQcatKB3Jf1RcmgUl2oUvvOVxv24d7KzayhkuKm55S unVIoM41A4e9lp5czCgK5gobhXwT0MqXcpnRuf/KHedyhuuP6H2ejkA1DjR/tGfuDuG7 OS2q+a7OHl4ZEynWTESODFZ4PXlocKdB199vLr0XaVMdt799EIVVDoBSu4Nz6j0rkPNi K73pyLyYHqDfgv9htKoBFf6xnjYv5xhBVUIt+vIfPjji7uyKBzLLCHOUaPBmtywe4mkS lEGcoKdGkJUERRGs8L68krKei4ffnBsk4oM/tfM6bFljXNXLpL1fdhaMPai1Pg9OMRgS TfqA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=cgOP3q4p; spf=pass (google.com: domain of linux-kernel+bounces-18733-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-18733-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [2604:1380:4601:e00::3]) by mx.google.com with ESMTPS id e18-20020a1709062c1200b00a2a43358c95si175451ejh.783.2024.01.06.14.40.50 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 06 Jan 2024 14:40:51 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-18733-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=cgOP3q4p; spf=pass (google.com: domain of linux-kernel+bounces-18733-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-18733-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id AE8441F22054 for <ouuuleilei@gmail.com>; Sat, 6 Jan 2024 22:40:50 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id E436210A0E; Sat, 6 Jan 2024 22:40:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="cgOP3q4p" X-Original-To: linux-kernel@vger.kernel.org Received: from mail-io1-f51.google.com (mail-io1-f51.google.com [209.85.166.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0D5B4101E3; Sat, 6 Jan 2024 22:40:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-io1-f51.google.com with SMTP id ca18e2360f4ac-7ba8e33dd0cso40710339f.0; Sat, 06 Jan 2024 14:40:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704580806; x=1705185606; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=pjMgdeRpctwTJ7F3CFnuysHXKhIpRAp8TwJ6AUfLDG4=; b=cgOP3q4p95nx0zj5ZtKQ7kGZqSW23grCuabNMXaiXOFQjzzU97RI4y7zXClkW24kxF j/wCoxYxZZDlCVK8gmrcFWY3iKbzDNP9Gn9WH0BirU/abG/oR8HtClJPWd+Vih7vPbiU Uo331tSs0C+GBZLwznUXtljFebb19eShSXKTCecvy04nffMHpGsO4UQifsVhGP6yyo5z Hj+QL3xf1I6G2szt7gtzudmGutsdVRT2P7dBP/J87Gwe29VweLfhsyI98yO3scYSuyVL +sUSWHPduky0htJjKZQ6kmfsZFDLadcVwNIk7fzJiyDHzdeSRhWEExiFDb06J8fpf9ST dRRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704580806; x=1705185606; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=pjMgdeRpctwTJ7F3CFnuysHXKhIpRAp8TwJ6AUfLDG4=; b=hcdEi6Jnx1OHohYuypPDEGkunnDzyM5SwqtaIZK7dCq9bLT3G32evzxZ2k6qO6ok3C uhB5drSr2ZJkb4pvzWUsELXX4jzL9APf7ygebDMjxwCPqj7K5HvWvUoqMUIC5rHlDyWu fonxW+OmW03duUA8UbKnkxpG9RUzSOklp9Ul3+Q3YIjuiS/pUd1HX7twY1W/DrrVqXOl IXZZlsUVY60Gjh8jaVOXXnMDwYqVUkhP0FslGLpPkkrgJR3Xr9sD9n0k6Ye6Xdj0LtrP ux++jLcDTZvo6+4oWhfxFJBG8vdVOHjk45cAjCwQJpf+x5sxNLK4k1eb4LFfYMa++gGf XinQ== X-Gm-Message-State: AOJu0YzKMeGme657fGtRZLwmhQGD4fLr/HtRbl+u1pU5ATvgX+KDql4/ Dzys4DDv+o9EMAODBPQHnS3Z8J5S+2oyeA== X-Received: by 2002:a05:6e02:2402:b0:360:8928:2170 with SMTP id bs2-20020a056e02240200b0036089282170mr507707ilb.26.1704580805888; Sat, 06 Jan 2024 14:40:05 -0800 (PST) Received: from aford-System-Version.lan ([2601:447:d002:5be:af2f:17f0:33a3:d6fe]) by smtp.gmail.com with ESMTPSA id l13-20020a056e021c0d00b0035ffe828182sm735346ilh.37.2024.01.06.14.40.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 06 Jan 2024 14:40:05 -0800 (PST) From: Adam Ford <aford173@gmail.com> To: linux-pm@vger.kernel.org Cc: Adam Ford <aford173@gmail.com>, Sandor Yu <Sandor.yu@nxp.com>, Jacky Bai <ping.bai@nxp.com>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org>, Shawn Guo <shawnguo@kernel.org>, Sascha Hauer <s.hauer@pengutronix.de>, Pengutronix Kernel Team <kernel@pengutronix.de>, Fabio Estevam <festevam@gmail.com>, NXP Linux Team <linux-imx@nxp.com>, Ulf Hansson <ulf.hansson@linaro.org>, Lucas Stach <l.stach@pengutronix.de>, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: [PATCH 2/3] pmdomain: imx8mp-blk-ctrl: imx8mp_blk: Add fdcc clock to hdmimix domain Date: Sat, 6 Jan 2024 16:39:49 -0600 Message-ID: <20240106223951.387067-2-aford173@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240106223951.387067-1-aford173@gmail.com> References: <20240106223951.387067-1-aford173@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1787382570293655226 X-GMAIL-MSGID: 1787382570293655226 |
Series |
[1/3] dt-bindings: soc: imx: add fdcc clock to i.MX8MP hdmi blk ctrl
|
|
Commit Message
Adam Ford
Jan. 6, 2024, 10:39 p.m. UTC
According to i.MX8MP RM and HDMI ADD, the fdcc clock is part of hdmi rx verification IP that should not enable for HDMI TX. But actually if the clock is disabled before HDMI/LCDIF probe, LCDIF will not get pixel clock from HDMI PHY and print the error logs: [CRTC:39:crtc-2] vblank wait timed out WARNING: CPU: 2 PID: 9 at drivers/gpu/drm/drm_atomic_helper.c:1634 drm_atomic_helper_wait_for_vblanks.part.0+0x23c/0x260 Add fdcc clock to LCDIF and HDMI TX power domains to fix the issue. Signed-off-by: Sandor Yu <Sandor.yu@nxp.com> Reviewed-by: Jacky Bai <ping.bai@nxp.com> Signed-off-by: Adam Ford <aford173@gmail.com> --- The original work was from Sandor on the NXP Down-stream kernel
Comments
On Sat, Jan 6, 2024 at 4:40 PM Adam Ford <aford173@gmail.com> wrote: > > According to i.MX8MP RM and HDMI ADD, the fdcc clock is part of > hdmi rx verification IP that should not enable for HDMI TX. > But actually if the clock is disabled before HDMI/LCDIF probe, > LCDIF will not get pixel clock from HDMI PHY and print the error > logs: > > [CRTC:39:crtc-2] vblank wait timed out > WARNING: CPU: 2 PID: 9 at drivers/gpu/drm/drm_atomic_helper.c:1634 drm_atomic_helper_wait_for_vblanks.part.0+0x23c/0x260 > > Add fdcc clock to LCDIF and HDMI TX power domains to fix the issue. Peng (or anyone from NXP), I borrowed this patch from the NXP down-stream kernel for two reasons: It's in NXP's branch to address an error & move the fdcc clock out of the HDMI-tx driver due to questions/feedback that Lucas got on that driver. The FDCC clock isn't well documented, and it seems like it's necessary for the HDMI-TX, but I'd like to make sure this is the proper solution, and I haven't received any additional feedback. Can someone from NXP confirm that really is the proper solution? thank you, adam > > Signed-off-by: Sandor Yu <Sandor.yu@nxp.com> > Reviewed-by: Jacky Bai <ping.bai@nxp.com> > Signed-off-by: Adam Ford <aford173@gmail.com> > --- > The original work was from Sandor on the NXP Down-stream kernel > > diff --git a/drivers/pmdomain/imx/imx8mp-blk-ctrl.c b/drivers/pmdomain/imx/imx8mp-blk-ctrl.c > index e3203eb6a022..a56f7f92d091 100644 > --- a/drivers/pmdomain/imx/imx8mp-blk-ctrl.c > +++ b/drivers/pmdomain/imx/imx8mp-blk-ctrl.c > @@ -55,7 +55,7 @@ struct imx8mp_blk_ctrl_domain_data { > const char *gpc_name; > }; > > -#define DOMAIN_MAX_CLKS 2 > +#define DOMAIN_MAX_CLKS 3 > #define DOMAIN_MAX_PATHS 3 > > struct imx8mp_blk_ctrl_domain { > @@ -457,8 +457,8 @@ static const struct imx8mp_blk_ctrl_domain_data imx8mp_hdmi_domain_data[] = { > }, > [IMX8MP_HDMIBLK_PD_LCDIF] = { > .name = "hdmiblk-lcdif", > - .clk_names = (const char *[]){ "axi", "apb" }, > - .num_clks = 2, > + .clk_names = (const char *[]){ "axi", "apb", "fdcc" }, > + .num_clks = 3, > .gpc_name = "lcdif", > .path_names = (const char *[]){"lcdif-hdmi"}, > .num_paths = 1, > @@ -483,8 +483,8 @@ static const struct imx8mp_blk_ctrl_domain_data imx8mp_hdmi_domain_data[] = { > }, > [IMX8MP_HDMIBLK_PD_HDMI_TX] = { > .name = "hdmiblk-hdmi-tx", > - .clk_names = (const char *[]){ "apb", "ref_266m" }, > - .num_clks = 2, > + .clk_names = (const char *[]){ "apb", "ref_266m", "fdcc" }, > + .num_clks = 3, > .gpc_name = "hdmi-tx", > }, > [IMX8MP_HDMIBLK_PD_HDMI_TX_PHY] = { > -- > 2.43.0 >
> -----Original Message----- > From: Adam Ford <aford173@gmail.com> > Sent: 2024年1月28日 2:20 > To: linux-pm@vger.kernel.org > Cc: Sandor Yu <sandor.yu@nxp.com>; Jacky Bai <ping.bai@nxp.com>; Rob > Herring <robh+dt@kernel.org>; Krzysztof Kozlowski > <krzysztof.kozlowski+dt@linaro.org>; Conor Dooley <conor+dt@kernel.org>; > Shawn Guo <shawnguo@kernel.org>; Sascha Hauer > <s.hauer@pengutronix.de>; Pengutronix Kernel Team > <kernel@pengutronix.de>; Fabio Estevam <festevam@gmail.com>; > dl-linux-imx <linux-imx@nxp.com>; Ulf Hansson <ulf.hansson@linaro.org>; > Lucas Stach <l.stach@pengutronix.de>; devicetree@vger.kernel.org; > linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org; Marek > Vasut <marex@denx.de>; Peng Fan (OSS) <peng.fan@oss.nxp.com> > Subject: [EXT] Re: [PATCH 2/3] pmdomain: imx8mp-blk-ctrl: imx8mp_blk: Add > fdcc clock to hdmimix domain > > Caution: This is an external email. Please take care when clicking links or > opening attachments. When in doubt, report the message using the 'Report > this email' button > > > On Sat, Jan 6, 2024 at 4:40 PM Adam Ford <aford173@gmail.com> wrote: > > > > According to i.MX8MP RM and HDMI ADD, the fdcc clock is part of hdmi > > rx verification IP that should not enable for HDMI TX. > > But actually if the clock is disabled before HDMI/LCDIF probe, LCDIF > > will not get pixel clock from HDMI PHY and print the error > > logs: > > > > [CRTC:39:crtc-2] vblank wait timed out > > WARNING: CPU: 2 PID: 9 at drivers/gpu/drm/drm_atomic_helper.c:1634 > > drm_atomic_helper_wait_for_vblanks.part.0+0x23c/0x260 > > > > Add fdcc clock to LCDIF and HDMI TX power domains to fix the issue. > > Peng (or anyone from NXP), > > I borrowed this patch from the NXP down-stream kernel for two reasons: > It's in NXP's branch to address an error & move the fdcc clock out of the > HDMI-tx driver due to questions/feedback that Lucas got on that driver. > > The FDCC clock isn't well documented, and it seems like it's necessary for the > HDMI-TX, but I'd like to make sure this is the proper solution, and I haven't > received any additional feedback. > Can someone from NXP confirm that really is the proper solution? > > thank you, > > adam Hi Adam, In NXP internal document, the clock HDMI_FDCC_TST_CLK_ROOT was for internal use only for future NXP development IP. It should not be exposed to customer in document but unfortunately it have to be enabled for HDMITX. I submitted a request ticket to the design team several months ago, Generally, tickets of this didn't get the priority in design team and I haven’t received any valuable feedback. Once design team confirmed, I think the document will update to add the fdcc clock. B.R Sandor > > > > > Signed-off-by: Sandor Yu <Sandor.yu@nxp.com> > > Reviewed-by: Jacky Bai <ping.bai@nxp.com> > > Signed-off-by: Adam Ford <aford173@gmail.com> > > --- > > The original work was from Sandor on the NXP Down-stream kernel > > > > diff --git a/drivers/pmdomain/imx/imx8mp-blk-ctrl.c > > b/drivers/pmdomain/imx/imx8mp-blk-ctrl.c > > index e3203eb6a022..a56f7f92d091 100644 > > --- a/drivers/pmdomain/imx/imx8mp-blk-ctrl.c > > +++ b/drivers/pmdomain/imx/imx8mp-blk-ctrl.c > > @@ -55,7 +55,7 @@ struct imx8mp_blk_ctrl_domain_data { > > const char *gpc_name; > > }; > > > > -#define DOMAIN_MAX_CLKS 2 > > +#define DOMAIN_MAX_CLKS 3 > > #define DOMAIN_MAX_PATHS 3 > > > > struct imx8mp_blk_ctrl_domain { > > @@ -457,8 +457,8 @@ static const struct imx8mp_blk_ctrl_domain_data > imx8mp_hdmi_domain_data[] = { > > }, > > [IMX8MP_HDMIBLK_PD_LCDIF] = { > > .name = "hdmiblk-lcdif", > > - .clk_names = (const char *[]){ "axi", "apb" }, > > - .num_clks = 2, > > + .clk_names = (const char *[]){ "axi", "apb", "fdcc" }, > > + .num_clks = 3, > > .gpc_name = "lcdif", > > .path_names = (const char *[]){"lcdif-hdmi"}, > > .num_paths = 1, > > @@ -483,8 +483,8 @@ static const struct imx8mp_blk_ctrl_domain_data > imx8mp_hdmi_domain_data[] = { > > }, > > [IMX8MP_HDMIBLK_PD_HDMI_TX] = { > > .name = "hdmiblk-hdmi-tx", > > - .clk_names = (const char *[]){ "apb", "ref_266m" }, > > - .num_clks = 2, > > + .clk_names = (const char *[]){ "apb", "ref_266m", > "fdcc" }, > > + .num_clks = 3, > > .gpc_name = "hdmi-tx", > > }, > > [IMX8MP_HDMIBLK_PD_HDMI_TX_PHY] = { > > -- > > 2.43.0 > >
On Sun, Jan 28, 2024 at 7:39 PM Sandor Yu <sandor.yu@nxp.com> wrote: > > > > > -----Original Message----- > > From: Adam Ford <aford173@gmail.com> > > Sent: 2024年1月28日 2:20 > > To: linux-pm@vger.kernel.org > > Cc: Sandor Yu <sandor.yu@nxp.com>; Jacky Bai <ping.bai@nxp.com>; Rob > > Herring <robh+dt@kernel.org>; Krzysztof Kozlowski > > <krzysztof.kozlowski+dt@linaro.org>; Conor Dooley <conor+dt@kernel.org>; > > Shawn Guo <shawnguo@kernel.org>; Sascha Hauer > > <s.hauer@pengutronix.de>; Pengutronix Kernel Team > > <kernel@pengutronix.de>; Fabio Estevam <festevam@gmail.com>; > > dl-linux-imx <linux-imx@nxp.com>; Ulf Hansson <ulf.hansson@linaro.org>; > > Lucas Stach <l.stach@pengutronix.de>; devicetree@vger.kernel.org; > > linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org; Marek > > Vasut <marex@denx.de>; Peng Fan (OSS) <peng.fan@oss.nxp.com> > > Subject: [EXT] Re: [PATCH 2/3] pmdomain: imx8mp-blk-ctrl: imx8mp_blk: Add > > fdcc clock to hdmimix domain > > > > Caution: This is an external email. Please take care when clicking links or > > opening attachments. When in doubt, report the message using the 'Report > > this email' button > > > > > > On Sat, Jan 6, 2024 at 4:40 PM Adam Ford <aford173@gmail.com> wrote: > > > > > > According to i.MX8MP RM and HDMI ADD, the fdcc clock is part of hdmi > > > rx verification IP that should not enable for HDMI TX. > > > But actually if the clock is disabled before HDMI/LCDIF probe, LCDIF > > > will not get pixel clock from HDMI PHY and print the error > > > logs: > > > > > > [CRTC:39:crtc-2] vblank wait timed out > > > WARNING: CPU: 2 PID: 9 at drivers/gpu/drm/drm_atomic_helper.c:1634 > > > drm_atomic_helper_wait_for_vblanks.part.0+0x23c/0x260 > > > > > > Add fdcc clock to LCDIF and HDMI TX power domains to fix the issue. > > > > Peng (or anyone from NXP), > > > > I borrowed this patch from the NXP down-stream kernel for two reasons: > > It's in NXP's branch to address an error & move the fdcc clock out of the > > HDMI-tx driver due to questions/feedback that Lucas got on that driver. > > > > The FDCC clock isn't well documented, and it seems like it's necessary for the > > HDMI-TX, but I'd like to make sure this is the proper solution, and I haven't > > received any additional feedback. > > Can someone from NXP confirm that really is the proper solution? > > > > thank you, > > > > adam > > Hi Adam, > Sandor, > In NXP internal document, the clock HDMI_FDCC_TST_CLK_ROOT was for internal use only for future NXP development IP. > It should not be exposed to customer in document but unfortunately it have to be enabled for HDMITX. > > I submitted a request ticket to the design team several months ago, > Generally, tickets of this didn't get the priority in design team and I haven’t received any valuable feedback. > Once design team confirmed, I think the document will update to add the fdcc clock. Thank you for your response. Do you have any objections to having the FDCC clock added to the power domain driver? I know there are several of us who would really like to see the HDMI-TX driver applied, and I think this patch gets us one step closer. thanks, adam > > B.R > Sandor > > > > > > > > > Signed-off-by: Sandor Yu <Sandor.yu@nxp.com> > > > Reviewed-by: Jacky Bai <ping.bai@nxp.com> > > > Signed-off-by: Adam Ford <aford173@gmail.com> > > > --- > > > The original work was from Sandor on the NXP Down-stream kernel > > > > > > diff --git a/drivers/pmdomain/imx/imx8mp-blk-ctrl.c > > > b/drivers/pmdomain/imx/imx8mp-blk-ctrl.c > > > index e3203eb6a022..a56f7f92d091 100644 > > > --- a/drivers/pmdomain/imx/imx8mp-blk-ctrl.c > > > +++ b/drivers/pmdomain/imx/imx8mp-blk-ctrl.c > > > @@ -55,7 +55,7 @@ struct imx8mp_blk_ctrl_domain_data { > > > const char *gpc_name; > > > }; > > > > > > -#define DOMAIN_MAX_CLKS 2 > > > +#define DOMAIN_MAX_CLKS 3 > > > #define DOMAIN_MAX_PATHS 3 > > > > > > struct imx8mp_blk_ctrl_domain { > > > @@ -457,8 +457,8 @@ static const struct imx8mp_blk_ctrl_domain_data > > imx8mp_hdmi_domain_data[] = { > > > }, > > > [IMX8MP_HDMIBLK_PD_LCDIF] = { > > > .name = "hdmiblk-lcdif", > > > - .clk_names = (const char *[]){ "axi", "apb" }, > > > - .num_clks = 2, > > > + .clk_names = (const char *[]){ "axi", "apb", "fdcc" }, > > > + .num_clks = 3, > > > .gpc_name = "lcdif", > > > .path_names = (const char *[]){"lcdif-hdmi"}, > > > .num_paths = 1, > > > @@ -483,8 +483,8 @@ static const struct imx8mp_blk_ctrl_domain_data > > imx8mp_hdmi_domain_data[] = { > > > }, > > > [IMX8MP_HDMIBLK_PD_HDMI_TX] = { > > > .name = "hdmiblk-hdmi-tx", > > > - .clk_names = (const char *[]){ "apb", "ref_266m" }, > > > - .num_clks = 2, > > > + .clk_names = (const char *[]){ "apb", "ref_266m", > > "fdcc" }, > > > + .num_clks = 3, > > > .gpc_name = "hdmi-tx", > > > }, > > > [IMX8MP_HDMIBLK_PD_HDMI_TX_PHY] = { > > > -- > > > 2.43.0 > > >
> -----Original Message----- > From: Adam Ford <aford173@gmail.com> > Sent: 2024年1月30日 1:56 > To: Sandor Yu <sandor.yu@nxp.com> > Cc: linux-pm@vger.kernel.org; Jacky Bai <ping.bai@nxp.com>; Rob Herring > <robh+dt@kernel.org>; Krzysztof Kozlowski > <krzysztof.kozlowski+dt@linaro.org>; Conor Dooley <conor+dt@kernel.org>; > Shawn Guo <shawnguo@kernel.org>; Sascha Hauer > <s.hauer@pengutronix.de>; Pengutronix Kernel Team > <kernel@pengutronix.de>; Fabio Estevam <festevam@gmail.com>; > dl-linux-imx <linux-imx@nxp.com>; Ulf Hansson <ulf.hansson@linaro.org>; > Lucas Stach <l.stach@pengutronix.de>; devicetree@vger.kernel.org; > linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org; Marek > Vasut <marex@denx.de>; Peng Fan (OSS) <peng.fan@oss.nxp.com> > Subject: Re: [EXT] Re: [PATCH 2/3] pmdomain: imx8mp-blk-ctrl: imx8mp_blk: > Add fdcc clock to hdmimix domain > > Caution: This is an external email. Please take care when clicking links or > opening attachments. When in doubt, report the message using the 'Report > this email' button > > > On Sun, Jan 28, 2024 at 7:39 PM Sandor Yu <sandor.yu@nxp.com> wrote: > > > > > > > > > -----Original Message----- > > > From: Adam Ford <aford173@gmail.com> > > > Sent: 2024年1月28日 2:20 > > > To: linux-pm@vger.kernel.org > > > Cc: Sandor Yu <sandor.yu@nxp.com>; Jacky Bai <ping.bai@nxp.com>; Rob > > > Herring <robh+dt@kernel.org>; Krzysztof Kozlowski > > > <krzysztof.kozlowski+dt@linaro.org>; Conor Dooley > > > <conor+dt@kernel.org>; Shawn Guo <shawnguo@kernel.org>; Sascha > Hauer > > > <s.hauer@pengutronix.de>; Pengutronix Kernel Team > > > <kernel@pengutronix.de>; Fabio Estevam <festevam@gmail.com>; > > > dl-linux-imx <linux-imx@nxp.com>; Ulf Hansson > > > <ulf.hansson@linaro.org>; Lucas Stach <l.stach@pengutronix.de>; > > > devicetree@vger.kernel.org; linux-arm-kernel@lists.infradead.org; > > > linux-kernel@vger.kernel.org; Marek Vasut <marex@denx.de>; Peng Fan > > > (OSS) <peng.fan@oss.nxp.com> > > > Subject: [EXT] Re: [PATCH 2/3] pmdomain: imx8mp-blk-ctrl: > > > imx8mp_blk: Add fdcc clock to hdmimix domain > > > > > > Caution: This is an external email. Please take care when clicking > > > links or opening attachments. When in doubt, report the message > > > using the 'Report this email' button > > > > > > > > > On Sat, Jan 6, 2024 at 4:40 PM Adam Ford <aford173@gmail.com> wrote: > > > > > > > > According to i.MX8MP RM and HDMI ADD, the fdcc clock is part of > > > > hdmi rx verification IP that should not enable for HDMI TX. > > > > But actually if the clock is disabled before HDMI/LCDIF probe, > > > > LCDIF will not get pixel clock from HDMI PHY and print the error > > > > logs: > > > > > > > > [CRTC:39:crtc-2] vblank wait timed out > > > > WARNING: CPU: 2 PID: 9 at drivers/gpu/drm/drm_atomic_helper.c:1634 > > > > drm_atomic_helper_wait_for_vblanks.part.0+0x23c/0x260 > > > > > > > > Add fdcc clock to LCDIF and HDMI TX power domains to fix the issue. > > > > > > Peng (or anyone from NXP), > > > > > > I borrowed this patch from the NXP down-stream kernel for two reasons: > > > It's in NXP's branch to address an error & move the fdcc clock out > > > of the HDMI-tx driver due to questions/feedback that Lucas got on that > driver. > > > > > > The FDCC clock isn't well documented, and it seems like it's > > > necessary for the HDMI-TX, but I'd like to make sure this is the > > > proper solution, and I haven't received any additional feedback. > > > Can someone from NXP confirm that really is the proper solution? > > > > > > thank you, > > > > > > adam > > > > Hi Adam, > > > > Sandor, > > > In NXP internal document, the clock HDMI_FDCC_TST_CLK_ROOT was for > internal use only for future NXP development IP. > > It should not be exposed to customer in document but unfortunately it have > to be enabled for HDMITX. > > > > I submitted a request ticket to the design team several months ago, > > Generally, tickets of this didn't get the priority in design team and I haven’t > received any valuable feedback. > > Once design team confirmed, I think the document will update to add the > fdcc clock. > Hi Adam, > Thank you for your response. Do you have any objections to having > the FDCC clock added to the power domain driver? I know there are several > of us who would really like to see the HDMI-TX driver applied, and I think this > patch gets us one step closer. > As I mentioned above, the FDCC clock is not for HDMITX in desgin, but it is part of HDMI domain that needed by HDMITX. So I think it is reasonable added it to the power domain driver. B.R Sandor > thanks, > > adam > > > > B.R > > Sandor > > > > > > > > > > > > > Signed-off-by: Sandor Yu <Sandor.yu@nxp.com> > > > > Reviewed-by: Jacky Bai <ping.bai@nxp.com> > > > > Signed-off-by: Adam Ford <aford173@gmail.com> > > > > --- > > > > The original work was from Sandor on the NXP Down-stream kernel > > > > > > > > diff --git a/drivers/pmdomain/imx/imx8mp-blk-ctrl.c > > > > b/drivers/pmdomain/imx/imx8mp-blk-ctrl.c > > > > index e3203eb6a022..a56f7f92d091 100644 > > > > --- a/drivers/pmdomain/imx/imx8mp-blk-ctrl.c > > > > +++ b/drivers/pmdomain/imx/imx8mp-blk-ctrl.c > > > > @@ -55,7 +55,7 @@ struct imx8mp_blk_ctrl_domain_data { > > > > const char *gpc_name; > > > > }; > > > > > > > > -#define DOMAIN_MAX_CLKS 2 > > > > +#define DOMAIN_MAX_CLKS 3 > > > > #define DOMAIN_MAX_PATHS 3 > > > > > > > > struct imx8mp_blk_ctrl_domain { > > > > @@ -457,8 +457,8 @@ static const struct > > > > imx8mp_blk_ctrl_domain_data > > > imx8mp_hdmi_domain_data[] = { > > > > }, > > > > [IMX8MP_HDMIBLK_PD_LCDIF] = { > > > > .name = "hdmiblk-lcdif", > > > > - .clk_names = (const char *[]){ "axi", "apb" }, > > > > - .num_clks = 2, > > > > + .clk_names = (const char *[]){ "axi", "apb", "fdcc" }, > > > > + .num_clks = 3, > > > > .gpc_name = "lcdif", > > > > .path_names = (const char *[]){"lcdif-hdmi"}, > > > > .num_paths = 1, > > > > @@ -483,8 +483,8 @@ static const struct > > > > imx8mp_blk_ctrl_domain_data > > > imx8mp_hdmi_domain_data[] = { > > > > }, > > > > [IMX8MP_HDMIBLK_PD_HDMI_TX] = { > > > > .name = "hdmiblk-hdmi-tx", > > > > - .clk_names = (const char *[]){ "apb", "ref_266m" }, > > > > - .num_clks = 2, > > > > + .clk_names = (const char *[]){ "apb", "ref_266m", > > > "fdcc" }, > > > > + .num_clks = 3, > > > > .gpc_name = "hdmi-tx", > > > > }, > > > > [IMX8MP_HDMIBLK_PD_HDMI_TX_PHY] = { > > > > -- > > > > 2.43.0 > > > >
On Sat, 6 Jan 2024 at 23:40, Adam Ford <aford173@gmail.com> wrote: > > According to i.MX8MP RM and HDMI ADD, the fdcc clock is part of > hdmi rx verification IP that should not enable for HDMI TX. > But actually if the clock is disabled before HDMI/LCDIF probe, > LCDIF will not get pixel clock from HDMI PHY and print the error > logs: > > [CRTC:39:crtc-2] vblank wait timed out > WARNING: CPU: 2 PID: 9 at drivers/gpu/drm/drm_atomic_helper.c:1634 drm_atomic_helper_wait_for_vblanks.part.0+0x23c/0x260 > > Add fdcc clock to LCDIF and HDMI TX power domains to fix the issue. > > Signed-off-by: Sandor Yu <Sandor.yu@nxp.com> > Reviewed-by: Jacky Bai <ping.bai@nxp.com> > Signed-off-by: Adam Ford <aford173@gmail.com> Just to let you know, this looks good to me and it seems like the NXP people like this too. What I am waiting for is an ack on the DT patch, then I am ready to queue this up. Kind regards Uffe > --- > The original work was from Sandor on the NXP Down-stream kernel > > diff --git a/drivers/pmdomain/imx/imx8mp-blk-ctrl.c b/drivers/pmdomain/imx/imx8mp-blk-ctrl.c > index e3203eb6a022..a56f7f92d091 100644 > --- a/drivers/pmdomain/imx/imx8mp-blk-ctrl.c > +++ b/drivers/pmdomain/imx/imx8mp-blk-ctrl.c > @@ -55,7 +55,7 @@ struct imx8mp_blk_ctrl_domain_data { > const char *gpc_name; > }; > > -#define DOMAIN_MAX_CLKS 2 > +#define DOMAIN_MAX_CLKS 3 > #define DOMAIN_MAX_PATHS 3 > > struct imx8mp_blk_ctrl_domain { > @@ -457,8 +457,8 @@ static const struct imx8mp_blk_ctrl_domain_data imx8mp_hdmi_domain_data[] = { > }, > [IMX8MP_HDMIBLK_PD_LCDIF] = { > .name = "hdmiblk-lcdif", > - .clk_names = (const char *[]){ "axi", "apb" }, > - .num_clks = 2, > + .clk_names = (const char *[]){ "axi", "apb", "fdcc" }, > + .num_clks = 3, > .gpc_name = "lcdif", > .path_names = (const char *[]){"lcdif-hdmi"}, > .num_paths = 1, > @@ -483,8 +483,8 @@ static const struct imx8mp_blk_ctrl_domain_data imx8mp_hdmi_domain_data[] = { > }, > [IMX8MP_HDMIBLK_PD_HDMI_TX] = { > .name = "hdmiblk-hdmi-tx", > - .clk_names = (const char *[]){ "apb", "ref_266m" }, > - .num_clks = 2, > + .clk_names = (const char *[]){ "apb", "ref_266m", "fdcc" }, > + .num_clks = 3, > .gpc_name = "hdmi-tx", > }, > [IMX8MP_HDMIBLK_PD_HDMI_TX_PHY] = { > -- > 2.43.0 >
On Thu, Feb 1, 2024 at 4:33 PM Ulf Hansson <ulf.hansson@linaro.org> wrote: > > On Sat, 6 Jan 2024 at 23:40, Adam Ford <aford173@gmail.com> wrote: > > > > According to i.MX8MP RM and HDMI ADD, the fdcc clock is part of > > hdmi rx verification IP that should not enable for HDMI TX. > > But actually if the clock is disabled before HDMI/LCDIF probe, > > LCDIF will not get pixel clock from HDMI PHY and print the error > > logs: > > > > [CRTC:39:crtc-2] vblank wait timed out > > WARNING: CPU: 2 PID: 9 at drivers/gpu/drm/drm_atomic_helper.c:1634 drm_atomic_helper_wait_for_vblanks.part.0+0x23c/0x260 > > > > Add fdcc clock to LCDIF and HDMI TX power domains to fix the issue. > > > > Signed-off-by: Sandor Yu <Sandor.yu@nxp.com> > > Reviewed-by: Jacky Bai <ping.bai@nxp.com> > > Signed-off-by: Adam Ford <aford173@gmail.com> > > Just to let you know, this looks good to me and it seems like the NXP > people like this too. What I am waiting for is an ack on the DT patch, > then I am ready to queue this up. What about the bindings? I'm assuming that Shawn would take the DT through his IMX tree, but I am not sure if I need to resubmit the bindings with a different commit message. adam > > Kind regards > Uffe > > > --- > > The original work was from Sandor on the NXP Down-stream kernel > > > > diff --git a/drivers/pmdomain/imx/imx8mp-blk-ctrl.c b/drivers/pmdomain/imx/imx8mp-blk-ctrl.c > > index e3203eb6a022..a56f7f92d091 100644 > > --- a/drivers/pmdomain/imx/imx8mp-blk-ctrl.c > > +++ b/drivers/pmdomain/imx/imx8mp-blk-ctrl.c > > @@ -55,7 +55,7 @@ struct imx8mp_blk_ctrl_domain_data { > > const char *gpc_name; > > }; > > > > -#define DOMAIN_MAX_CLKS 2 > > +#define DOMAIN_MAX_CLKS 3 > > #define DOMAIN_MAX_PATHS 3 > > > > struct imx8mp_blk_ctrl_domain { > > @@ -457,8 +457,8 @@ static const struct imx8mp_blk_ctrl_domain_data imx8mp_hdmi_domain_data[] = { > > }, > > [IMX8MP_HDMIBLK_PD_LCDIF] = { > > .name = "hdmiblk-lcdif", > > - .clk_names = (const char *[]){ "axi", "apb" }, > > - .num_clks = 2, > > + .clk_names = (const char *[]){ "axi", "apb", "fdcc" }, > > + .num_clks = 3, > > .gpc_name = "lcdif", > > .path_names = (const char *[]){"lcdif-hdmi"}, > > .num_paths = 1, > > @@ -483,8 +483,8 @@ static const struct imx8mp_blk_ctrl_domain_data imx8mp_hdmi_domain_data[] = { > > }, > > [IMX8MP_HDMIBLK_PD_HDMI_TX] = { > > .name = "hdmiblk-hdmi-tx", > > - .clk_names = (const char *[]){ "apb", "ref_266m" }, > > - .num_clks = 2, > > + .clk_names = (const char *[]){ "apb", "ref_266m", "fdcc" }, > > + .num_clks = 3, > > .gpc_name = "hdmi-tx", > > }, > > [IMX8MP_HDMIBLK_PD_HDMI_TX_PHY] = { > > -- > > 2.43.0 > >
On Fri, 2 Feb 2024 at 01:17, Adam Ford <aford173@gmail.com> wrote: > > On Thu, Feb 1, 2024 at 4:33 PM Ulf Hansson <ulf.hansson@linaro.org> wrote: > > > > On Sat, 6 Jan 2024 at 23:40, Adam Ford <aford173@gmail.com> wrote: > > > > > > According to i.MX8MP RM and HDMI ADD, the fdcc clock is part of > > > hdmi rx verification IP that should not enable for HDMI TX. > > > But actually if the clock is disabled before HDMI/LCDIF probe, > > > LCDIF will not get pixel clock from HDMI PHY and print the error > > > logs: > > > > > > [CRTC:39:crtc-2] vblank wait timed out > > > WARNING: CPU: 2 PID: 9 at drivers/gpu/drm/drm_atomic_helper.c:1634 drm_atomic_helper_wait_for_vblanks.part.0+0x23c/0x260 > > > > > > Add fdcc clock to LCDIF and HDMI TX power domains to fix the issue. > > > > > > Signed-off-by: Sandor Yu <Sandor.yu@nxp.com> > > > Reviewed-by: Jacky Bai <ping.bai@nxp.com> > > > Signed-off-by: Adam Ford <aford173@gmail.com> > > > > Just to let you know, this looks good to me and it seems like the NXP > > people like this too. What I am waiting for is an ack on the DT patch, > > then I am ready to queue this up. > > What about the bindings? I'm assuming that Shawn would take the DT > through his IMX tree, but I am not sure if I need to resubmit the > bindings with a different commit message. I am usually trying to help with patch1 and patch2 for pmdomain related changes - and I am sharing new/updated DT bindings on an immutable "dt" branch. Then Shawn can pull in that branch and apply patch3 to his tree. So, I need an ack on patch1 from some of the DT maintainers to go ahead. Unless you want to manage this entirely through Shawn's tree, that works too. Just let me know. [...] Kind regards Uffe
diff --git a/drivers/pmdomain/imx/imx8mp-blk-ctrl.c b/drivers/pmdomain/imx/imx8mp-blk-ctrl.c index e3203eb6a022..a56f7f92d091 100644 --- a/drivers/pmdomain/imx/imx8mp-blk-ctrl.c +++ b/drivers/pmdomain/imx/imx8mp-blk-ctrl.c @@ -55,7 +55,7 @@ struct imx8mp_blk_ctrl_domain_data { const char *gpc_name; }; -#define DOMAIN_MAX_CLKS 2 +#define DOMAIN_MAX_CLKS 3 #define DOMAIN_MAX_PATHS 3 struct imx8mp_blk_ctrl_domain { @@ -457,8 +457,8 @@ static const struct imx8mp_blk_ctrl_domain_data imx8mp_hdmi_domain_data[] = { }, [IMX8MP_HDMIBLK_PD_LCDIF] = { .name = "hdmiblk-lcdif", - .clk_names = (const char *[]){ "axi", "apb" }, - .num_clks = 2, + .clk_names = (const char *[]){ "axi", "apb", "fdcc" }, + .num_clks = 3, .gpc_name = "lcdif", .path_names = (const char *[]){"lcdif-hdmi"}, .num_paths = 1, @@ -483,8 +483,8 @@ static const struct imx8mp_blk_ctrl_domain_data imx8mp_hdmi_domain_data[] = { }, [IMX8MP_HDMIBLK_PD_HDMI_TX] = { .name = "hdmiblk-hdmi-tx", - .clk_names = (const char *[]){ "apb", "ref_266m" }, - .num_clks = 2, + .clk_names = (const char *[]){ "apb", "ref_266m", "fdcc" }, + .num_clks = 3, .gpc_name = "hdmi-tx", }, [IMX8MP_HDMIBLK_PD_HDMI_TX_PHY] = {