Received: by 2002:a05:7412:b995:b0:f9:9502:5bb8 with SMTP id it21csp959797rdb; Fri, 22 Dec 2023 09:52:39 -0800 (PST) X-Google-Smtp-Source: AGHT+IEz+9RanzRsuEiO6iTikOa5NEaXlydSj3/yMVo16wYjePyC/iTLta8cG8d25rGRtUC0g54Z X-Received: by 2002:a17:907:96a4:b0:a26:8c27:a6c6 with SMTP id hd36-20020a17090796a400b00a268c27a6c6mr604938ejc.111.1703267559337; Fri, 22 Dec 2023 09:52:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1703267559; cv=none; d=google.com; s=arc-20160816; b=OKsgP9c2jjUohO0CsZdVEem5yNrW+Bmz2Oi/Gnqdin4jPJDNVQJNU/GZRGZsaMYJQf N7jmnIFR2QjdIlkF/DOn3SQMxu98EFl+LRzCwdHujfFLISKDLzeIplOwCa01tqFmTN55 SBcnfp5UDWO/ZRovA/hNfIXuAl5A6SVYtP+oxG4SUxSdlIDh8RDNmKXM4S8CYVNkN8it kSMnbD/KFo5fauqMPkCVrgBzaZUofiXnysoUHiC9qZ9ng7l4wxJjJWRk54p7eBnxcrBx YZh8uLvfSaJNRfujBhYpIjOvMVNKjFsgUBSLXjzBsRNLKOVJT3xGjNAuSeL6atJe29hH zdiA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:in-reply-to:references:cc:to:from :content-language:subject:user-agent:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:date:message-id:dkim-signature; bh=0dJEbxddZykrxGq+8fDRLJfMAa7JxIMNTLEIMv/B4fQ=; fh=pug+WK5cgVvlw/GSkU4VcKwsW/1wdN8AJU//kbaZW8Y=; b=y2byaWR8LXRsEzkigvhNNcKdmd5P0aIJRG6DO0k/J8X6k+Bp/upyGdsbDbLBh2QFR0 VPjhE0UgYIXRSy2UhCcQiKFNK4G9CuCLzMC1rKP7pKOwZryj/0sEox5ha47eG0qSuflk JEn5BNKgcVegRmdVj7tx8Wi6iFZCxrwwP0HIxHzrOb60UaS2pAmkHSTwfdfcrPgVhjZn DhnnBnBbb7e9USD9R76qs3vw5I1pCVGwcdIj+TFKtUpatmzBMIoNcD5lJwTGhJXH22QI CqzDI3HOjhzUoJCctt33MukE78uOBCfahtcr18K39qefkPp87dwJiOmk7MTUV/D9/B3b e66w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=TlpONAjz; spf=pass (google.com: domain of linux-kernel+bounces-9985-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-9985-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [147.75.80.249]) by mx.google.com with ESMTPS id dv1-20020a170906b80100b00a18e17a95d7si1934133ejb.208.2023.12.22.09.52.39 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Dec 2023 09:52:39 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-9985-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=TlpONAjz; spf=pass (google.com: domain of linux-kernel+bounces-9985-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-9985-linux.lists.archive=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 DFB531F2352D for ; Fri, 22 Dec 2023 17:52:38 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 0C90A2E637; Fri, 22 Dec 2023 17:51:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="TlpONAjz" X-Original-To: linux-kernel@vger.kernel.org Received: from mail-lj1-f178.google.com (mail-lj1-f178.google.com [209.85.208.178]) (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 78F592C199; Fri, 22 Dec 2023 17:51:53 +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-lj1-f178.google.com with SMTP id 38308e7fff4ca-2ccae5719cfso7034571fa.1; Fri, 22 Dec 2023 09:51:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1703267511; x=1703872311; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:references:cc:to:from :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=0dJEbxddZykrxGq+8fDRLJfMAa7JxIMNTLEIMv/B4fQ=; b=TlpONAjzRMj4k6Y0P10KGuLAzs9+NuNcFH1ZbaOOkMCjedBnFCYEi+6ne2FmSQSv87 d6XKLFBLRmClWcf2APoRq5Qq55M3nwHU629vvI5Ss69FuGsRjZZ8/GxfoQg+g495oXRl syRd+lVXA+lsde0P1axcQt6GPIxSkSQLKNdCSSmNVwgzh2HNY6gGEMKIT0gsVn+BTOrj fCwe2Xn+BIGfnvCgv33A8H+sDsJW5N0kEXO2XpSTuOuJz0smBiytpqAlRxlw5lf7s6qK wnsltUUSV1lzXCxOMaqyyXxyv0RTdc7ObM16AoiVw1bKiYwHVJ7/wQpJeBdW+byo8anO LEWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703267511; x=1703872311; h=content-transfer-encoding:in-reply-to:references:cc:to:from :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=0dJEbxddZykrxGq+8fDRLJfMAa7JxIMNTLEIMv/B4fQ=; b=Vka6yPWD9M/bQSKCg/OfytjbBvG40DsAdZVBeAQqjWq13jBHbQ2ykVQg4HEd2YDZz7 LfR4/L44U0HXdG3IL424A7Q+94CHGbW36TUjuj8aH3Hd4d/iQQgcDBcKLqQxESp0jdcV L+x1DjAG80IKoSCSXwAZFv1OUQiUM064aWACITF3RzDbw7XVBluHYuLYqGUorawTkBql e4IVace6KI+G5C5K5uw8RDYcMClYxTpAGzsktjTbmkgHWApMkGlq5Jqjk9rFGc8Wnt0s jrz4Kdun5dkfX/FdIePj74FKrbQa6wG/h9bh6wLY/2r6As94pu75lxcwPqt6tnmyyhLV Mudw== X-Gm-Message-State: AOJu0YxURvyFMHpCVw848Tlvv+jk9fRJAW2G0Wwwh7uWVCwE39YkQ2cx 6PjDk8BoXzpvkqj8rG7/5Q== X-Received: by 2002:a2e:9611:0:b0:2cc:9548:8d31 with SMTP id v17-20020a2e9611000000b002cc95488d31mr453765ljh.184.1703267511314; Fri, 22 Dec 2023 09:51:51 -0800 (PST) Received: from ?IPV6:2a02:810b:f40:4300:f3ae:2788:7e03:f44? ([2a02:810b:f40:4300:f3ae:2788:7e03:f44]) by smtp.gmail.com with ESMTPSA id n13-20020a05640204cd00b00554745eca8csm377398edw.59.2023.12.22.09.51.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 22 Dec 2023 09:51:50 -0800 (PST) Message-ID: Date: Fri, 22 Dec 2023 18:51:49 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 19/27] drm/rockchip: inno_hdmi: Move tmds rate to connector state subclass Content-Language: en-US, de-DE From: Alex Bee To: Maxime Ripard Cc: Sandy Huang , =?UTF-8?Q?Heiko_St=C3=BCbner?= , Andy Yan , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Maarten Lankhorst , Thomas Zimmermann , David Airlie , Daniel Vetter , devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org References: <20231216162639.125215-1-knaerzche@gmail.com> <20231216162639.125215-20-knaerzche@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Maxime, Am 18.12.23 um 13:49 schrieb Alex Bee: > > Am 18.12.23 um 11:06 schrieb Maxime Ripard: >> Hi, >> >> On Sat, Dec 16, 2023 at 05:26:30PM +0100, Alex Bee wrote: >>> Similar to the othter members of inno_hdmi_connector_state the >>> tmds_rate is >>> not a property of the device, but of the connector state. Move it to >>> inno_hdmi_connector_state and make it a long to comply with the clock >>> framework. To get arround the issue of not having the connector >>> state when >>> inno_hdmi_i2c_init is called in the bind path, getting the tmds rate is >>> wrapped in function which returns the fallback rate if the connector >>> doesn't have a state yet. >>> >>> Signed-off-by: Alex Bee >>> --- >>> changes in v2: >>>   - new patch >>> >>>   drivers/gpu/drm/rockchip/inno_hdmi.c | 36 >>> +++++++++++++++++++--------- >>>   1 file changed, 25 insertions(+), 11 deletions(-) >>> >>> diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c >>> b/drivers/gpu/drm/rockchip/inno_hdmi.c >>> index f9bfae1e97a2..6799d24501b8 100644 >>> --- a/drivers/gpu/drm/rockchip/inno_hdmi.c >>> +++ b/drivers/gpu/drm/rockchip/inno_hdmi.c >>> @@ -47,14 +47,13 @@ struct inno_hdmi { >>>         struct inno_hdmi_i2c *i2c; >>>       struct i2c_adapter *ddc; >>> - >>> -    unsigned int tmds_rate; >>>   }; >>>     struct inno_hdmi_connector_state { >>>       struct drm_connector_state    base; >>>       unsigned int            enc_out_format; >>>       unsigned int            colorimetry; >>> +    unsigned long            tmds_rate; >>>   }; >>>     static struct inno_hdmi *encoder_to_inno_hdmi(struct drm_encoder >>> *encoder) >>> @@ -133,11 +132,33 @@ static inline void hdmi_modb(struct inno_hdmi >>> *hdmi, u16 offset, >>>       hdmi_writeb(hdmi, offset, temp); >>>   } >>>   +static unsigned long inno_hdmi_tmds_rate(struct inno_hdmi *hdmi) >>> +{ >>> +    struct drm_connector *connector = &hdmi->connector; >>> +    struct drm_connector_state *conn_state = connector->state; >>> +    struct inno_hdmi_connector_state *inno_conn_state; >>> + >>> +    if (conn_state) { >>> +        inno_conn_state = to_inno_hdmi_conn_state(conn_state); >>> +        return inno_conn_state->tmds_rate; >>> +    } >>> + >>> +    /* >>> +     * When IP controller haven't configured to an accurate video >>> +     * timing, then the TMDS clock source would be switched to >>> +     * PCLK_HDMI, so we need to init the TMDS rate to PCLK rate, >>> +     * and reconfigure the DDC clock. >>> +     */ >>> + >>> +    return clk_get_rate(hdmi->pclk); >>> +} >>> + >>>   static void inno_hdmi_i2c_init(struct inno_hdmi *hdmi) >>>   { >>>       int ddc_bus_freq; >>> +    unsigned long tmds_rate = inno_hdmi_tmds_rate(hdmi); >>>   -    ddc_bus_freq = (hdmi->tmds_rate >> 2) / HDMI_SCL_RATE; >>> +    ddc_bus_freq = (tmds_rate >> 2) / HDMI_SCL_RATE; >>>         hdmi_writeb(hdmi, DDC_BUS_FREQ_L, ddc_bus_freq & 0xFF); >>>       hdmi_writeb(hdmi, DDC_BUS_FREQ_H, (ddc_bus_freq >> 8) & 0xFF); >>> @@ -431,7 +452,7 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi, >>>        * DCLK_LCDC, so we need to init the TMDS rate to mode pixel >>>        * clock rate, and reconfigure the DDC clock. >>>        */ >>> -    hdmi->tmds_rate = mode->clock * 1000; >>> +    inno_conn_state->tmds_rate = mode->clock * 1000; >>>       inno_hdmi_i2c_init(hdmi); >>>         /* Unmute video and audio output */ >>> @@ -823,13 +844,6 @@ static int inno_hdmi_bind(struct device *dev, >>> struct device *master, >>>           goto err_disable_clk; >>>       } >>>   -    /* >>> -     * When IP controller haven't configured to an accurate video >>> -     * timing, then the TMDS clock source would be switched to >>> -     * PCLK_HDMI, so we need to init the TMDS rate to PCLK rate, >>> -     * and reconfigure the DDC clock. >>> -     */ >>> -    hdmi->tmds_rate = clk_get_rate(hdmi->pclk); >>>       inno_hdmi_i2c_init(hdmi); >> I still think my patch is better there. >> I found a way now and added your patch which removes the tmds_rate: I noticed powering up the phy initially isn't necessary at all (and makes no sense). I refactored inno_hdmi_set_pwr_mode in two functions (in a similar way you did for the infoframe), so that the tmds rate (pixelclock) is only needed as parameter when a mode is set. Alex >> There's two places that use the inno_hdmi.tmds_rate field: the two >> callers of inno_hdmi_i2c_init(). One is at bind time and needs to >> initialise it with a sane default since we don't have a mode set yet, >> the other is to update the internal clock rate while we have a mode set. > That’s, unfortunately, not fully true: inno_hdmi_set_pwr_mode not only > called at mode_set-time, but also in inno_hdmi_reset which is called > in the > bind path (where we do not have a mode). That’s the point why I thought > extracting this in function makes sense. Otherwise I would have to > pass the > tmds_rate to inno_hdmi_set_pwr_mode (also for the LOWER_PWR-case where I > don't need it) or do that whole fallback-if-no-mode thing in > inno_hdmi_set_pwr_mode directly. Neither would make the code easier to > follow. Being able to use it in inno_hdmi_i2c_init also is a nice > gimmick. > I agree, having it in the custom connector state is not strictly > required, > but I'd really like to keep the wrapping function. > > Alex > >> Since there's a single "modeset" user, there's no need to store it in >> the state structure at all: it can be a local variable. >> >> And in the bind function, you're not going to use the state structure >> either since there's no state, and it's just a default that has no >> relation to the modeset code at all. >> >> Your function on the other end tries to reconcile and handle the two. >> But there's no reason to, it just makes the code harder to follow. Just >> pass the parent rate you want to init with as an argument and it's easy >> to read and maintain. >> >> Maxime