Message ID | 20230122174548.13758-2-ansuelsmth@gmail.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp1244622wrn; Sun, 22 Jan 2023 09:48:53 -0800 (PST) X-Google-Smtp-Source: AMrXdXtIztD/1j51YBdK2bIQ7Um38pSEVDTY7iGZEuINk3kfxaaszBLMqJ8ldzErlg7QUVW0W6/S X-Received: by 2002:a17:902:c3cd:b0:192:cf35:3fff with SMTP id j13-20020a170902c3cd00b00192cf353fffmr25217996plj.9.1674409733245; Sun, 22 Jan 2023 09:48:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1674409733; cv=none; d=google.com; s=arc-20160816; b=mNOAwhcNDubGuYjHHj4k9Ih4xMbgE60NE4laDgFjPNi/9m2Yt0wPSc0CjDI5tMpuk6 mqMa8WSbJQi+PdqR3bimOiCMy9cGYN/UcIeSTKsbuZgYqLpTEOlthJwGfTv8yKq2Vk7g bKuVjvTY9kfH1rcbw+wnn0a9PPlpHB8ApzJYOw3vrMuuOb9U1IgBxfY/GKMnekxm7u9f hRxftwlqdTsKmXKp/VUrGPYROqSn/IPvOSC3+Jh6c8h/NfgUsaBOxlfZAJOyFMI5RmDX TtuP2ymtXmywgZLAdEtgSbFRzFbD4FLE9YAYhNJOZQiyDnMYM2RnD5+D97HiQU/17JE2 oPEg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=LrGjhQpE634D6lomaeukDiYcPVKw6kiO4+o7Lkr2XV8=; b=KoAuZua8/4Es2e/YqJJBu24CCdFZ4nEmoLSjB1NjSIOxsCuw606dom35H6UG41h9Mm F8QDt9xdUwJQTVYsBK/yuDakU8zZDGDszk2LMWFvrN52nODzGXWMiGewZQuE4xFfWNf6 5SDn4xK9hvHe88fWdGrS8zpRYNAW2JnhINNJzrksZnvyt9yh5CvO4EmR0XsuV+iNcRLz yJv56GmIxFRj//8Y2s2J8sEM/1/x29VBtJZ0R5UVxg2rnEGQKfRkiZwZ1KxHZvBQ5EMg m9wmklcAbwGvosc6r+OvMrHm9UA6dXiXCoHCL3YpJA4SpNRLmadwo7FJqrzGxX0WqORJ eVAg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=Oiw9wjdm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id x14-20020a170902ec8e00b001925dbac333si40303862plg.312.2023.01.22.09.48.41; Sun, 22 Jan 2023 09:48:53 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=Oiw9wjdm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230360AbjAVRqA (ORCPT <rfc822;forouhar.linux@gmail.com> + 99 others); Sun, 22 Jan 2023 12:46:00 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44382 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229934AbjAVRp6 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sun, 22 Jan 2023 12:45:58 -0500 Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A6556F741; Sun, 22 Jan 2023 09:45:55 -0800 (PST) Received: by mail-wm1-x334.google.com with SMTP id j17so7478156wms.0; Sun, 22 Jan 2023 09:45:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; 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=LrGjhQpE634D6lomaeukDiYcPVKw6kiO4+o7Lkr2XV8=; b=Oiw9wjdmxkg+Z4X1DjeV2SoLl1sFCwYQDUjijKclKyrSxMeXiJqZgNr0BPZf6JIpgs gkH6Z8LGhwgAVPKDxR+v3AH/97TCjhu1hfdEB3V8hL26bcwc+kyzyEvOrRBONp3peds2 cceLM70khghwzSDhlLDzU6D66PqvIEIwA/SpkXJj9V5RRcZsPJXNRuqu8Yf64JpXzbnO dwmquxz03jwcBmB9Pd3LHY6UEFCBiTjNJ1JksQWlvhRSgAULq96D776hZg4KlOEjXkks Hvh/gddGpnTnXp/2rX3GZvmc34PhXT3rW28szanLjP/5J3f8b6wGCVJ8BIWybwwA6Nby VsgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=LrGjhQpE634D6lomaeukDiYcPVKw6kiO4+o7Lkr2XV8=; b=t8ehyuvzU/p18lgz4gR4E7KHFVwESx2TJvsjuM2QU2m+yKu0JilRD3X4r+1NrkauYS KCM1YLKoN19pavSQfMQ/8+y6yjTocPh16gq9k6cj2oqE1P+wqw0Y3wGC8vPDy7zEUfDt OB9hvY7ddaXyj7nD0ISUUXylX9qCnQl5j2GQ6IRS4Rdhm17PXkGR7EdjwQseuB1+Pas0 YapuZN8hQkpR1MGS3VZihiXSuUJSVA8OV327Olnbo12ix8Xgl1mJBwkfvQYOiAXD0jmN rZih0AtohZtmnGAjjXJX496Q2qSvz2gXEogYrM4OeiiPvmD6gTxTMor1ym/n5PFj3tx3 aLsA== X-Gm-Message-State: AFqh2koeerSOSn5yfKdqzjMvVpr/7icAJJ718ZNp96potO3Lqt0lSIdB RSIkybY/SIJ0uVqg1DaqLCU= X-Received: by 2002:a05:600c:1d85:b0:3db:1bc5:bbe7 with SMTP id p5-20020a05600c1d8500b003db1bc5bbe7mr14800225wms.0.1674409554113; Sun, 22 Jan 2023 09:45:54 -0800 (PST) Received: from localhost.localdomain (93-34-89-61.ip49.fastwebnet.it. [93.34.89.61]) by smtp.googlemail.com with ESMTPSA id m2-20020a05600c4f4200b003db0ad636d1sm9202257wmq.28.2023.01.22.09.45.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 22 Jan 2023 09:45:53 -0800 (PST) From: Christian Marangi <ansuelsmth@gmail.com> To: Ilia Lin <ilia.lin@kernel.org>, Andy Gross <agross@kernel.org>, Bjorn Andersson <andersson@kernel.org>, Konrad Dybcio <konrad.dybcio@linaro.org>, "Rafael J. Wysocki" <rafael@kernel.org>, Viresh Kumar <viresh.kumar@linaro.org>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Nishanth Menon <nm@ti.com>, Stephen Boyd <sboyd@kernel.org>, Yassine Oudjana <y.oudjana@protonmail.com>, linux-pm@vger.kernel.org, linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Christian Marangi <ansuelsmth@gmail.com> Subject: [PATCH v2 2/2] dt-bindings: opp: opp-v2-kryo-cpu: enlarge opp-supported-hw maximum Date: Sun, 22 Jan 2023 18:45:48 +0100 Message-Id: <20230122174548.13758-2-ansuelsmth@gmail.com> X-Mailer: git-send-email 2.38.1 In-Reply-To: <20230122174548.13758-1-ansuelsmth@gmail.com> References: <20230122174548.13758-1-ansuelsmth@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1755745860345338138?= X-GMAIL-MSGID: =?utf-8?q?1755745860345338138?= |
Series |
[v2,1/2] dt-bindings: cpufreq: qcom-cpufreq-nvmem: make cpr bindings optional
|
|
Commit Message
Christian Marangi
Jan. 22, 2023, 5:45 p.m. UTC
Enlarge opp-supported-hw maximum value. In recent SoC we started
matching more bit and we currently match mask of 112. The old maximum of
7 was good for old SoC that didn't had complex id, but now this is
limiting and we need to enlarge it to support more variants.
Document all the various mask that can be used and limit them to only
reasonable values instead of using a generic maximum limit.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
---
.../bindings/opp/opp-v2-kryo-cpu.yaml | 20 +++++++++++++++++--
1 file changed, 18 insertions(+), 2 deletions(-)
Comments
On Sun, 22 Jan 2023 at 19:46, Christian Marangi <ansuelsmth@gmail.com> wrote: > > Enlarge opp-supported-hw maximum value. In recent SoC we started > matching more bit and we currently match mask of 112. The old maximum of > 7 was good for old SoC that didn't had complex id, but now this is > limiting and we need to enlarge it to support more variants. > > Document all the various mask that can be used and limit them to only > reasonable values instead of using a generic maximum limit. > > Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> > --- > .../bindings/opp/opp-v2-kryo-cpu.yaml | 20 +++++++++++++++++-- > 1 file changed, 18 insertions(+), 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml b/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml > index b4947b326773..908cb0d7695a 100644 > --- a/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml > +++ b/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml > @@ -50,12 +50,28 @@ patternProperties: > opp-supported-hw: > description: | > A single 32 bit bitmap value, representing compatible HW. > - Bitmap: > + Bitmap for MSM8996 format: > 0: MSM8996, speedbin 0 > 1: MSM8996, speedbin 1 > 2: MSM8996, speedbin 2 > 3-31: unused > - maximum: 0x7 > + > + Bitmap for MSM8996 later revision format: > + 0: MSM8996, speedbin 0 > + 1: MSM8996, speedbin 1 > + 2: MSM8996, speedbin 2 > + 3: always set This is used for speedbin 3 > + 4-31: unused > + > + Bitmap for MSM8996SG format (speedbin shifted of 4 left): > + 0-3: unused > + 4: MSM8996SG, speedbin 0 > + 5: MSM8996SG, speedbin 1 > + 6: MSM8996SG, speedbin 2 > + 7-31: unused > + enum: [0x1, 0x2, 0x3, 0x4, 0x7, > + 0x9, 0xd, 0xe, 0xf, > + 0x10, 0x20, 0x30, 0x70] > > clock-latency-ns: true > > -- > 2.38.1 >
On Sun, Jan 22, 2023 at 07:59:42PM +0200, Dmitry Baryshkov wrote: > On Sun, 22 Jan 2023 at 19:46, Christian Marangi <ansuelsmth@gmail.com> wrote: > > > > Enlarge opp-supported-hw maximum value. In recent SoC we started > > matching more bit and we currently match mask of 112. The old maximum of > > 7 was good for old SoC that didn't had complex id, but now this is > > limiting and we need to enlarge it to support more variants. > > > > Document all the various mask that can be used and limit them to only > > reasonable values instead of using a generic maximum limit. > > > > Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> > > --- > > .../bindings/opp/opp-v2-kryo-cpu.yaml | 20 +++++++++++++++++-- > > 1 file changed, 18 insertions(+), 2 deletions(-) > > > > diff --git a/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml b/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml > > index b4947b326773..908cb0d7695a 100644 > > --- a/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml > > +++ b/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml > > @@ -50,12 +50,28 @@ patternProperties: > > opp-supported-hw: > > description: | > > A single 32 bit bitmap value, representing compatible HW. > > - Bitmap: > > + Bitmap for MSM8996 format: > > 0: MSM8996, speedbin 0 > > 1: MSM8996, speedbin 1 > > 2: MSM8996, speedbin 2 > > 3-31: unused > > - maximum: 0x7 > > + > > + Bitmap for MSM8996 later revision format: > > + 0: MSM8996, speedbin 0 > > + 1: MSM8996, speedbin 1 > > + 2: MSM8996, speedbin 2 > > + 3: always set > > This is used for speedbin 3 > Is it right that 4 bit speedbin is only introduced later? Cause looking at the current opp-supported-hw for MSM8996SG and MSM8996 originally (and based on what this Documentation say) there were only 3 bit and then they started using a 4th bit. Just asking if it's ok to keep the bitmap split or i should just merge it. > > + 4-31: unused > > + > > + Bitmap for MSM8996SG format (speedbin shifted of 4 left): > > + 0-3: unused > > + 4: MSM8996SG, speedbin 0 > > + 5: MSM8996SG, speedbin 1 > > + 6: MSM8996SG, speedbin 2 > > + 7-31: unused > > + enum: [0x1, 0x2, 0x3, 0x4, 0x7, > > + 0x9, 0xd, 0xe, 0xf, > > + 0x10, 0x20, 0x30, 0x70] > > > > clock-latency-ns: true > > > > -- > > 2.38.1 > >
On Sun, 22 Jan 2023 at 20:13, Christian Marangi <ansuelsmth@gmail.com> wrote: > > On Sun, Jan 22, 2023 at 07:59:42PM +0200, Dmitry Baryshkov wrote: > > On Sun, 22 Jan 2023 at 19:46, Christian Marangi <ansuelsmth@gmail.com> wrote: > > > > > > Enlarge opp-supported-hw maximum value. In recent SoC we started > > > matching more bit and we currently match mask of 112. The old maximum of > > > 7 was good for old SoC that didn't had complex id, but now this is > > > limiting and we need to enlarge it to support more variants. > > > > > > Document all the various mask that can be used and limit them to only > > > reasonable values instead of using a generic maximum limit. > > > > > > Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> > > > --- > > > .../bindings/opp/opp-v2-kryo-cpu.yaml | 20 +++++++++++++++++-- > > > 1 file changed, 18 insertions(+), 2 deletions(-) > > > > > > diff --git a/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml b/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml > > > index b4947b326773..908cb0d7695a 100644 > > > --- a/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml > > > +++ b/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml > > > @@ -50,12 +50,28 @@ patternProperties: > > > opp-supported-hw: > > > description: | > > > A single 32 bit bitmap value, representing compatible HW. > > > - Bitmap: > > > + Bitmap for MSM8996 format: > > > 0: MSM8996, speedbin 0 > > > 1: MSM8996, speedbin 1 > > > 2: MSM8996, speedbin 2 > > > 3-31: unused > > > - maximum: 0x7 > > > + > > > + Bitmap for MSM8996 later revision format: > > > + 0: MSM8996, speedbin 0 > > > + 1: MSM8996, speedbin 1 > > > + 2: MSM8996, speedbin 2 > > > + 3: always set > > > > This is used for speedbin 3 > > > > Is it right that 4 bit speedbin is only introduced later? Cause looking > at the current opp-supported-hw for MSM8996SG and MSM8996 originally > (and based on what this Documentation say) there were only 3 bit and > then they started using a 4th bit. Just asking if it's ok to keep the > bitmap split or i should just merge it. I don't think I got the question, please excuse me. Historically msm8996.dtsi used 0xff as 'all possible platforms' value for the GPU tables. Lately I fixed the CPU tables, added support for speed-bin 3. However I left these 0xff in GPU opp table intact. I don't remember if there was any reason behind that. Anyway this bit isn't always set, it is set only for the entries which should be selected for MSM8996 speed bin 3. > > > > + 4-31: unused > > > + > > > + Bitmap for MSM8996SG format (speedbin shifted of 4 left): > > > + 0-3: unused > > > + 4: MSM8996SG, speedbin 0 > > > + 5: MSM8996SG, speedbin 1 > > > + 6: MSM8996SG, speedbin 2 > > > + 7-31: unused > > > + enum: [0x1, 0x2, 0x3, 0x4, 0x7, > > > + 0x9, 0xd, 0xe, 0xf, > > > + 0x10, 0x20, 0x30, 0x70] > > > > > > clock-latency-ns: true > > > > > > -- > > > 2.38.1 > > > > > -- > Ansuel
On Sun, Jan 22, 2023 at 09:15:53PM +0200, Dmitry Baryshkov wrote: > On Sun, 22 Jan 2023 at 20:13, Christian Marangi <ansuelsmth@gmail.com> wrote: > > > > On Sun, Jan 22, 2023 at 07:59:42PM +0200, Dmitry Baryshkov wrote: > > > On Sun, 22 Jan 2023 at 19:46, Christian Marangi <ansuelsmth@gmail.com> wrote: > > > > > > > > Enlarge opp-supported-hw maximum value. In recent SoC we started > > > > matching more bit and we currently match mask of 112. The old maximum of > > > > 7 was good for old SoC that didn't had complex id, but now this is > > > > limiting and we need to enlarge it to support more variants. > > > > > > > > Document all the various mask that can be used and limit them to only > > > > reasonable values instead of using a generic maximum limit. > > > > > > > > Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> > > > > --- > > > > .../bindings/opp/opp-v2-kryo-cpu.yaml | 20 +++++++++++++++++-- > > > > 1 file changed, 18 insertions(+), 2 deletions(-) > > > > > > > > diff --git a/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml b/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml > > > > index b4947b326773..908cb0d7695a 100644 > > > > --- a/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml > > > > +++ b/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml > > > > @@ -50,12 +50,28 @@ patternProperties: > > > > opp-supported-hw: > > > > description: | > > > > A single 32 bit bitmap value, representing compatible HW. > > > > - Bitmap: > > > > + Bitmap for MSM8996 format: > > > > 0: MSM8996, speedbin 0 > > > > 1: MSM8996, speedbin 1 > > > > 2: MSM8996, speedbin 2 > > > > 3-31: unused > > > > - maximum: 0x7 > > > > + > > > > + Bitmap for MSM8996 later revision format: > > > > + 0: MSM8996, speedbin 0 > > > > + 1: MSM8996, speedbin 1 > > > > + 2: MSM8996, speedbin 2 > > > > + 3: always set > > > > > > This is used for speedbin 3 > > > > > > > Is it right that 4 bit speedbin is only introduced later? Cause looking > > at the current opp-supported-hw for MSM8996SG and MSM8996 originally > > (and based on what this Documentation say) there were only 3 bit and > > then they started using a 4th bit. Just asking if it's ok to keep the > > bitmap split or i should just merge it. > > I don't think I got the question, please excuse me. Historically > msm8996.dtsi used 0xff as 'all possible platforms' value for the GPU > tables. Lately I fixed the CPU tables, added support for speed-bin 3. > However I left these 0xff in GPU opp table intact. I don't remember if > there was any reason behind that. Anyway this bit isn't always set, it > is set only for the entries which should be selected for MSM8996 speed > bin 3. > Question is: Should I merge the 2 format to something like? A single 32 bit bitmap value, representing compatible HW. Bitmap for MSM8996 format: 0: MSM8996, speedbin 0 1: MSM8996, speedbin 1 2: MSM8996, speedbin 2 3: MSM8996, speedbin 3 4-31: unused Bitmap for MSM8996SG format (speedbin shifted of 4 left): 0-3: unused 4: MSM8996SG, speedbin 0 5: MSM8996SG, speedbin 1 6: MSM8996SG, speedbin 2 7-31: unused Or just replace the 'Always set' to speedbin 3? (by the looks of it seems they started blowing speedbin 3 only in later revision and initialy there were only 3 speedbin bit) > > > > > > + 4-31: unused > > > > + > > > > + Bitmap for MSM8996SG format (speedbin shifted of 4 left): > > > > + 0-3: unused > > > > + 4: MSM8996SG, speedbin 0 > > > > + 5: MSM8996SG, speedbin 1 > > > > + 6: MSM8996SG, speedbin 2 > > > > + 7-31: unused > > > > + enum: [0x1, 0x2, 0x3, 0x4, 0x7, > > > > + 0x9, 0xd, 0xe, 0xf, > > > > + 0x10, 0x20, 0x30, 0x70] > > > > > > > > clock-latency-ns: true > > > > > > > > -- > > > > 2.38.1 > > > > > > > > -- > > Ansuel > > > > -- > With best wishes > Dmitry
On Sun, 22 Jan 2023 18:45:48 +0100, Christian Marangi wrote: > Enlarge opp-supported-hw maximum value. In recent SoC we started > matching more bit and we currently match mask of 112. The old maximum of > 7 was good for old SoC that didn't had complex id, but now this is > limiting and we need to enlarge it to support more variants. > > Document all the various mask that can be used and limit them to only > reasonable values instead of using a generic maximum limit. > > Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> > --- > .../bindings/opp/opp-v2-kryo-cpu.yaml | 20 +++++++++++++++++-- > 1 file changed, 18 insertions(+), 2 deletions(-) > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.example.dtb: /: opp-table-0:opp-1401600000:opp-supported-hw:0:0: 5 is not one of [1, 2, 3, 4, 7, 9, 13, 14, 15, 16, 32, 48, 112] From schema: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/cpufreq/qcom-cpufreq-nvmem.yaml /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.example.dtb: /: opp-table-0: Unevaluated properties are not allowed ('compatible', 'nvmem-cells', 'opp-1401600000', 'opp-1593600000', 'opp-307200000', 'opp-shared' were unexpected) From schema: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/cpufreq/qcom-cpufreq-nvmem.yaml /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.example.dtb: /: opp-table-1:opp-1804800000:opp-supported-hw:0:0: 6 is not one of [1, 2, 3, 4, 7, 9, 13, 14, 15, 16, 32, 48, 112] From schema: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/cpufreq/qcom-cpufreq-nvmem.yaml /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.example.dtb: /: opp-table-1: Unevaluated properties are not allowed ('compatible', 'nvmem-cells', 'opp-1804800000', 'opp-1900800000', 'opp-2150400000', 'opp-307200000', 'opp-shared' were unexpected) From schema: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/cpufreq/qcom-cpufreq-nvmem.yaml /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.example.dtb: opp-table-0: opp-1401600000:opp-supported-hw:0:0: 5 is not one of [1, 2, 3, 4, 7, 9, 13, 14, 15, 16, 32, 48, 112] From schema: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.example.dtb: opp-table-1: opp-1804800000:opp-supported-hw:0:0: 6 is not one of [1, 2, 3, 4, 7, 9, 13, 14, 15, 16, 32, 48, 112] From schema: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20230122174548.13758-2-ansuelsmth@gmail.com The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
diff --git a/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml b/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml index b4947b326773..908cb0d7695a 100644 --- a/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml +++ b/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml @@ -50,12 +50,28 @@ patternProperties: opp-supported-hw: description: | A single 32 bit bitmap value, representing compatible HW. - Bitmap: + Bitmap for MSM8996 format: 0: MSM8996, speedbin 0 1: MSM8996, speedbin 1 2: MSM8996, speedbin 2 3-31: unused - maximum: 0x7 + + Bitmap for MSM8996 later revision format: + 0: MSM8996, speedbin 0 + 1: MSM8996, speedbin 1 + 2: MSM8996, speedbin 2 + 3: always set + 4-31: unused + + Bitmap for MSM8996SG format (speedbin shifted of 4 left): + 0-3: unused + 4: MSM8996SG, speedbin 0 + 5: MSM8996SG, speedbin 1 + 6: MSM8996SG, speedbin 2 + 7-31: unused + enum: [0x1, 0x2, 0x3, 0x4, 0x7, + 0x9, 0xd, 0xe, 0xf, + 0x10, 0x20, 0x30, 0x70] clock-latency-ns: true