From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 8530FC433EF for ; Thu, 24 Feb 2022 16:52:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=ckVA776ipGOemQMHfQvm+qhkLWOZc8NAItptA/4KTVI=; b=VS6UFjVWasG7Kl wdEb2YaavHq3kcWJz7mi72rjUzQ8geNNLMeUacOjKPkbB2Y2CB1PcmeFc45m6yrTucGaDDkSkY1fX iiGSyngQkPm80fariPaAckgTdtT8KDNOl1l23PoNUhE6V7xEav2g5iJPgj39vwaxH1WLIbfEC5x42 MqmBZTTjUWRSLxnChVp8ex/Fdd0ik2CnFc3JmWi5ryGV+07A0NzUaASI2Y5e7plw1V9OB8y2glh0X hprs4CY6zYDC5guzx/hZQYBLqj+B9qaRadoJCpbAGjTQ9djrS3m1hWK/ZOmkjyCWuI5SZKjYMIYya 3IezlHP+NGiHCkgTe4/Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nNHKp-001d4r-57; Thu, 24 Feb 2022 16:51:19 +0000 Received: from mail-oi1-x233.google.com ([2607:f8b0:4864:20::233]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nNHKj-001d1q-O2 for linux-arm-kernel@lists.infradead.org; Thu, 24 Feb 2022 16:51:15 +0000 Received: by mail-oi1-x233.google.com with SMTP id x193so3466455oix.0 for ; Thu, 24 Feb 2022 08:51:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=N8RCTotc4cmUTmsRA5J7naJcJh1Q7sGDDwovYyQT86k=; b=fg9hkYcI5u3dbEw84om3H3LjBjjbFYuyGuZzo+47DtuUpbVS1U4m45qC/FWjkCJ0Fq Eve4HcWP9XH/q1aMs4G4ocbr+xm+z0OIssB4urMuHCRuI/h6X87iF+ZPNhLWVkMUAt0+ MTrapkTrtRJFqglGwZ0sh0i1pHqLXoEFoC9Fcl+8BV0ksyQ4oiITyBSys7yZZhX4vEnF C27Xn8uPVBu11qhWxaVSvdAR46bqzbW+nttpUdMm5PDNRVqQKBQFEYPhyBtPGYCFsVZo XmjrNqjO8pHZW7S7UelvdUQw+nGMK8Y3c7Q5UP6CqicM2vNVAoClaawvVilgXSWCOjPg 4YOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=N8RCTotc4cmUTmsRA5J7naJcJh1Q7sGDDwovYyQT86k=; b=s5fM3J89ZZFWCjP7Jb/rsR5OzDI/mX+AJA8x7Aeg/U2ZPWOwIY2eQbjWPM9VAGhSl8 WibWSyZBWmzVX0dNVthSaflight7GiYm9lPFVF5EX1V7Q5xDQnFWkhsUhpofstvqNZAJ 8NldfTjDolmdtayTz77R9t++D1UyqQewrP7qkY2IC4Wd06PeGYU3KOEad7dy7g7YEuMa NhMUz348zrHWBwh/NtLf0y+cL2j2lrPBumEmGbQUxBCeHjIK60Nb5+2+ItEAGQM45FDl yr8urvdnhuTdOrq2AxPDQ3MKUrxL9FtLQBmx5rhylRKI0aMmuapSMRy9K/OS0OKxGoRn Wqeg== X-Gm-Message-State: AOAM533wQvaj6BcYo8RQ35ny6/vEFmjvFq5Q/yy9F60Uk+zygQTxDpKO lp47dO/mnnbYlFqlHjpo7ilqMA== X-Google-Smtp-Source: ABdhPJyH21pu5ycMxU9OVqYiNC++pfYrdMu5u7iIlq5TKIHOHUPz7vUGqYR/Y3LCAml5DLdoA8oD4g== X-Received: by 2002:a05:6808:1801:b0:2d7:206e:36fd with SMTP id bh1-20020a056808180100b002d7206e36fdmr3705715oib.3.1645721469908; Thu, 24 Feb 2022 08:51:09 -0800 (PST) Received: from builder.lan ([2600:1700:a0:3dc8:3697:f6ff:fe85:aac9]) by smtp.gmail.com with ESMTPSA id lc4-20020a056871418400b000c8a240183csm33827oab.25.2022.02.24.08.51.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Feb 2022 08:51:09 -0800 (PST) Date: Thu, 24 Feb 2022 10:51:07 -0600 From: Bjorn Andersson To: Krzysztof Kozlowski Cc: Alim Akhtar , Avri Altman , Rob Herring , Andy Gross , Wei Xu , Nishanth Menon , Vignesh Raghavendra , Tero Kristo , "James E.J. Bottomley" , "Martin K. Petersen" , Jan Kotas , Li Wei , Stanley Chu , Yaniv Gardi , linux-scsi@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org, linux-mediatek@lists.infradead.org Subject: Re: [PATCH v2 09/15] scsi: ufs: deprecate 'freq-table-hz' property Message-ID: References: <20220222145854.358646-1-krzysztof.kozlowski@canonical.com> <20220222145854.358646-10-krzysztof.kozlowski@canonical.com> <455a8a87-63e7-7864-f765-142be18d1fa8@canonical.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <455a8a87-63e7-7864-f765-142be18d1fa8@canonical.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220224_085113_816436_81B77E03 X-CRM114-Status: GOOD ( 32.07 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed 23 Feb 03:15 CST 2022, Krzysztof Kozlowski wrote: > On 22/02/2022 19:16, Bjorn Andersson wrote: > > On Tue 22 Feb 06:58 PST 2022, Krzysztof Kozlowski wrote: > > > >> The 'freq-table-hz' is not correct in DT schema, because '-hz' suffix > >> defines uint32 type, not an array. Therefore deprecate 'freq-table-hz' > >> and use 'freq-table' instead. > >> > > > > Patch looks good in itself, but why don't we use opp-table to describe > > the performance states? > > > > In particular looking at the two columns of frequencies for various > > Qualcomm boards they require different performance-states. > > > > A concrete example is sm8350.dtsi, which specifies 75MHz and 300MHz as > > the first frequency pair. The lower level requires the VDD_CX power rail > > to be at least &rpmhpd_opp_low_svs, the higher frequency has a > > required-opps of &rpmhpd_opp_nom. > > > > > > As this isn't possible to express in the current binding we've just been > > forced to always run at a higher voltage level and kept this in the todo > > list. > > > > But rather than migrating freq-table-hz to freq-table and then having to > > introduce an opp table to express the power constraints, could we > > perhaps skip the intermediate step? > > > > Or would you have any other suggestion about how we can represent the > > required-opps level together with the freq-table (if that's what we want > > to stick with). > > Usage of OPP tables is interesting solution. It would solve your problem > of power rail levels. This would need several opp-tables - one for each > clock, which is not a big problem. > Ahh, so we can only have a single clock, but multiple regulators and interconnect paths tied to the opp table. We have a couple of cases where it would have been nice to be able to key the opp-table off some index (e.g. the UFS gear or PCI Gen) and control multiple clocks. So I think we need to look into this further... > The problem is that I do not have any UFS hardware (none of my Samsung > Exynos boards have UFS... I don't have even arm64 Exynos chips :( ), so > implementing it theoretically will be painful. > OTOH, I believe that having a working dtschema is very useful. Having > dtschema without errors/warnings is even worth some churn/intermediary work. > > The intermediary work is also not that big. Once proper OPP is > implemented, we will have "just" two deprecated properties in the bindings. > Fair enough, was just hoping to avoid the middle step. But that's fine, we'll continue to carry this on our todo list then. Thanks, Bjorn _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel