From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net [23.128.96.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 98D6C2F859 for ; Tue, 7 Nov 2023 21:57:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="H69agnHW" Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D0DA710DD for ; Tue, 7 Nov 2023 13:57:28 -0800 (PST) Received: by mail-lj1-x233.google.com with SMTP id 38308e7fff4ca-2c54c8934abso87988371fa.0 for ; Tue, 07 Nov 2023 13:57:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1699394247; x=1699999047; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=FK647JTOvb77Maf2VTj+zONIf/6LvdRZnkupw91tgPE=; b=H69agnHWvFVT++YuBUxyhVyyDEO0NqyIjlSctOPhX093UG8r+DewbemJW2fcOgqKae Ub3gHCKh+3xXsBl53xq7je+C7Rp/MnCU8prJESjSVx68xkySYt1NXEqbI/jlU/86D1p3 e6J1FQvDq982F3OxydQBsDO8reb9nJVWmPU+uyh4wJaScF/1veMsXVle8/fHf26XpTjb jaM52uw8IyMLm3Ft2qolCWY8UjN/Tk39H5Hl81ehrzIvEec9e5VjAqFjazaJYdMsBLTP 9klhp8EKKp4eb0qgEBiksF0IkOaPltoZcGNH8o70yIZ7oPLn95mZVDgKHWnrUMzfbL7M vgKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699394247; x=1699999047; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=FK647JTOvb77Maf2VTj+zONIf/6LvdRZnkupw91tgPE=; b=ta0TJQA+uulegEZLheBiOkx28I0GeLyduPqlkWWXSVu6p/Jw6lPvkwNhlqfDhn3UM3 CTm3OE/09cbEbW0q2z1rDcgmaXM7APJB8+gzhjzh/guDbes9TBJBLG3w2CQosCaz78CA Q/4nj87+qM/zufQmWJveNwZneNrbD2sFScuuFxnlkr/km7sKT6RpjubtyrXZuI9wbXfG VYqL26CHXDYmIg7CF+Mo5Tplz0rF7KMXIrkdGgr6stc6ordeF4gJa/6L1sOB4ND9wZzp pR8Vh22U8YQ1yeUm/erRhbswtM+9xk0z7TEYfhYUDrMhW5ynS2B38iyGVm8tVCy5MvHN FNaQ== X-Gm-Message-State: AOJu0Yzj9oqL80fSNmcGc5MByBBwU5GGYVOtbHFsoqntSeDKw1tPelDG 1E5nhTGzlUkzmLAHb3z12o3xMA== X-Google-Smtp-Source: AGHT+IGYyAg9ZJkuOrbMHatl2BVJxk8o6k2iosy2VGIvJ4FeYqR6CRHdhVaeJZCe9djWbe++GOivMA== X-Received: by 2002:a05:651c:324:b0:2bc:bf29:18d3 with SMTP id b4-20020a05651c032400b002bcbf2918d3mr192132ljp.31.1699394247074; Tue, 07 Nov 2023 13:57:27 -0800 (PST) Received: from [172.30.205.109] (UNUSED.212-182-62-129.lubman.net.pl. [212.182.62.129]) by smtp.gmail.com with ESMTPSA id a18-20020a2e8612000000b002b9bf5b071bsm1611555lji.20.2023.11.07.13.57.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 07 Nov 2023 13:57:26 -0800 (PST) Message-ID: <8a12ccba-908d-405a-8fcb-411d50a66ebe@linaro.org> Date: Tue, 7 Nov 2023 22:57:23 +0100 Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 0/3] phy: qcom-qmp-pcie: Add support to keep refclk always on Content-Language: en-US To: Krishna chaitanya chundru , Andy Gross , Bjorn Andersson , Vinod Koul , Kishon Vijay Abraham I , Rob Herring , Krzysztof Kozlowski , Conor Dooley Cc: linux-arm-msm@vger.kernel.org, linux-phy@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, quic_vbadigan@quicinc.com, quic_ramkri@quicinc.com, quic_nitegupt@quicinc.com, quic_skananth@quicinc.com, quic_vpernami@quicinc.com, quic_parass@quicinc.com References: <20231107-refclk_always_on-v2-0-de23962fc4b3@quicinc.com> From: Konrad Dybcio In-Reply-To: <20231107-refclk_always_on-v2-0-de23962fc4b3@quicinc.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 11/7/23 13:26, Krishna chaitanya chundru wrote: > This series adds support to provide refclk to endpoint even in low > power states. > > Due to some platform specific issues with CLKREQ signal, it is not being > propagated to the host and as host doesn't know the clkreq signal host is > not sending refclk. Due to this endpoint is seeing linkdown and going > to bad state. > To avoid those ref clk should be provided always to the endpoint. The > issue is coming only when ep intiates the L1.1 or L1.2 exit and clkreq > is not being propagated properly to the host. I'm gonna sound like a broken record, but: How much power does this consume? Would it matter if we kept this clock always-on for all platforms with this version of the phy? Konrad