Message ID | 20240205044557.3340848-1-u-kumar1@ti.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-52030-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7301:168b:b0:106:860b:bbdd with SMTP id ma11csp669594dyb; Sun, 4 Feb 2024 20:50:16 -0800 (PST) X-Google-Smtp-Source: AGHT+IEDt5NfdlPNfhoG0tq3c29G7ZpsoBLBazy+Qp2MIfsJY0ecr4jR9+e8qMOUOhgzi0n8o3MF X-Received: by 2002:ac8:5409:0:b0:42a:ac17:a71a with SMTP id b9-20020ac85409000000b0042aac17a71amr7943106qtq.27.1707108616771; Sun, 04 Feb 2024 20:50:16 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1707108616; cv=pass; d=google.com; s=arc-20160816; b=EqFIyxx5UTWTwQaQaQZKzvaVB57qqwOIL+xHqF8lHj6aKA0iv/Dj+M8aBaklimxZag qy4verkJl0CFKxEi+SojVCapTo+Ptw2bDLp8s8LN/NOAfWVtGcec8NorIEgvAVTuVEe4 OQeIe2BAib3KPv0+A9BmVsMXTMMcaZz27j1Jq8OYm1bslciAxdSi99ComR1E/C/dV00C Uj3TKB/elKdcvTHjg5jestgtMEH0kKxt6q+tgHyDruMqwROyy2HuGOuFB40ioIHaGlYE AKHnU/xXZeIXXdO5WRgk+UMrAc4ojP8FSKStEnPLDq/dpJ9XMHwEtsw95OXVxE9RxZ2g Ddqg== ARC-Message-Signature: i=2; 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:message-id:date:subject:cc:to :from:dkim-signature; bh=Xtnfb8xnQNhu/YXCkFubO57gi1E2WQInflCGp92loXQ=; fh=ut8QcyXhJVkH5jD9C2YJFNAB580Di0jwWQNVvsW0zmk=; b=lEZtXA05Mrmomu+5ySS91Hk0LSZ91nAlI1g8AEb8QpoOOjcTe7mrHlQV2WrKUml+IJ 7Q8jLcUB95Ket0cDW/ITw+kZt2Pm4WpUN0sjEin/GNiUVrrZu6ReHYSD5pfbrqy1hx5a N8Czz9on4/Z57D1tD4cH7mr2p/2LHHQCfxP+eyqf2K/nOoB7m+N/YP0LrrRoLncWtbWg z6IQ6ShlByztStFwBXjP5IjLEJNfb6lltG88xldU3+cXoteDNLGAjXXQ6QkKKOF07Cj1 NsV8h+xov6WA8Zsxn83r1QHRBIj1CtAYyrUgGUZfWIu/GovE/tZubx9gEHBrBTH3a1D0 Cf3g==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=cOON0SHv; arc=pass (i=1 spf=pass spfdomain=ti.com dkim=pass dkdomain=ti.com dmarc=pass fromdomain=ti.com); spf=pass (google.com: domain of linux-kernel+bounces-52030-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-52030-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com X-Forwarded-Encrypted: i=1; AJvYcCVP5UC9guCxNGTDVP9E2+hWDK4BeUN2nODvoOoVnv2uTr20BkGGtAeEIllBD3XbNupqZusjHtAoKUYqdA2ZI+2uDWWCeg== Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id n17-20020a05622a11d100b0042c2846e2f6si791999qtk.623.2024.02.04.20.50.16 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 04 Feb 2024 20:50:16 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-52030-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=cOON0SHv; arc=pass (i=1 spf=pass spfdomain=ti.com dkim=pass dkdomain=ti.com dmarc=pass fromdomain=ti.com); spf=pass (google.com: domain of linux-kernel+bounces-52030-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-52030-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.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 ny.mirrors.kernel.org (Postfix) with ESMTPS id BDD641C222D6 for <ouuuleilei@gmail.com>; Mon, 5 Feb 2024 04:50:14 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id A215EB677; Mon, 5 Feb 2024 04:50:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=ti.com header.i=@ti.com header.b="cOON0SHv" Received: from lelv0143.ext.ti.com (lelv0143.ext.ti.com [198.47.23.248]) (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 154D0AD32; Mon, 5 Feb 2024 04:49:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.47.23.248 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707108600; cv=none; b=eITWtNZQGRipG0CHGtmCTyjhlTuU4Mmmk4LAoIo9Bsw5Ed86wJOVe1pBMEpvcPBIWeNkVG/hCsL2hggGW/OPyEhF1IEzmZfEfHPEeOyXDtDXXwTJ78GF1w9zglAebwEuefkSj2j/34VHNLh/5YTh8416YCd7UkbseVSyaHrK+gI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707108600; c=relaxed/simple; bh=NduTLHFnZfhCN2CkJ9oqz73qOh10y1E+6FLyT0zEKO0=; h=From:To:CC:Subject:Date:Message-ID:MIME-Version:Content-Type; b=EdqwiqhH40g+E1KDV4zvWh41ASQy+7XnpODDEJ0BhYLbxbaxC4AcovFFtxvEwM/y88Qea600VzZ4sMxY75gOeabL3YMEeRETn8Gxgdx4Z08LzIOLye9U/ZdoiRrtMRdKynymlMdiOb8dbmrxfJjrxB1yam+3sXBMsa+XZ+FOmb8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=ti.com; spf=pass smtp.mailfrom=ti.com; dkim=pass (1024-bit key) header.d=ti.com header.i=@ti.com header.b=cOON0SHv; arc=none smtp.client-ip=198.47.23.248 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=ti.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ti.com Received: from fllv0035.itg.ti.com ([10.64.41.0]) by lelv0143.ext.ti.com (8.15.2/8.15.2) with ESMTP id 4154nElG022636; Sun, 4 Feb 2024 22:49:14 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1707108554; bh=Xtnfb8xnQNhu/YXCkFubO57gi1E2WQInflCGp92loXQ=; h=From:To:CC:Subject:Date; b=cOON0SHvZCUNGkGhchQdw7q+4bpaFV9mnhg0AQDO9GSCKkxzkOuEaWO4QqUa16+49 8k2/LwQs8SjG+mM/LxQCT4P5MFcvljlwbtCJQur5gjTgjPJ/wlsLXMot1TxnIoq7XD VEOLYb5P1K82DJE/Hbm4pkl6bK9Gv1MupKij/z+Q= Received: from DFLE101.ent.ti.com (dfle101.ent.ti.com [10.64.6.22]) by fllv0035.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 4154nE5h031263 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Sun, 4 Feb 2024 22:49:14 -0600 Received: from DFLE111.ent.ti.com (10.64.6.32) by DFLE101.ent.ti.com (10.64.6.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23; Sun, 4 Feb 2024 22:49:13 -0600 Received: from lelvsmtp5.itg.ti.com (10.180.75.250) by DFLE111.ent.ti.com (10.64.6.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23 via Frontend Transport; Sun, 4 Feb 2024 22:49:13 -0600 Received: from udit-HP-Z2-Tower-G9-Workstation-Desktop-PC.dhcp.ti.com (udit-hp-z2-tower-g9-workstation-desktop-pc.dhcp.ti.com [172.24.227.18]) by lelvsmtp5.itg.ti.com (8.15.2/8.15.2) with ESMTP id 4154nA0K035269; Sun, 4 Feb 2024 22:49:11 -0600 From: Udit Kumar <u-kumar1@ti.com> To: <nm@ti.com>, <kristo@kernel.org>, <ssantosh@kernel.org> CC: <vigneshr@ti.com>, <mturquette@baylibre.com>, <sboyd@kernel.org>, <linux-arm-kernel@lists.infradead.org>, <linux-kernel@vger.kernel.org>, <linux-clk@vger.kernel.org>, Udit Kumar <u-kumar1@ti.com> Subject: [PATCH v1] clk: keystone: sci-clk: Adding support for non contiguous clocks Date: Mon, 5 Feb 2024 10:15:58 +0530 Message-ID: <20240205044557.3340848-1-u-kumar1@ti.com> X-Mailer: git-send-email 2.34.1 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 Content-Type: text/plain X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1790033125134248833 X-GMAIL-MSGID: 1790033125134248833 |
Series |
[v1] clk: keystone: sci-clk: Adding support for non contiguous clocks
|
|
Commit Message
Kumar, Udit
Feb. 5, 2024, 4:45 a.m. UTC
Most of clocks and their parents are defined in contiguous range,
But in few cases, there is gap in clock numbers[0].
Driver assumes clocks to be in contiguous range, and assigns
accordingly.
New firmware started returning error in case of
non-available clock id. Therefore drivers throws error while
re-calculate and other functions.
In this fix, before assigning and adding clock in list,
driver checks if given clock is valid or not.
Fixes: 3c13933c6033 ("clk: keystone: sci-clk: add support for dynamically probing clocks")
[0] https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/j7200/clocks.html
Section Clocks for NAVSS0_CPTS_0 Device,
clock id 12-15 and 18-19 not present
Signed-off-by: Udit Kumar <u-kumar1@ti.com>
---
Original logs
https://gist.github.com/uditkumarti/de4b36b21247fb36725ad909ce4812f6#file-original-logs
Line 2630 for error
Logs with fix
https://gist.github.com/uditkumarti/de4b36b21247fb36725ad909ce4812f6#file-with-fix
Line 2594
drivers/clk/keystone/sci-clk.c | 20 ++++++++++++++++----
1 file changed, 16 insertions(+), 4 deletions(-)
Comments
On 10:15-20240205, Udit Kumar wrote: > Most of clocks and their parents are defined in contiguous range, > But in few cases, there is gap in clock numbers[0]. > > Driver assumes clocks to be in contiguous range, and assigns > accordingly. > > New firmware started returning error in case of > non-available clock id. Therefore drivers throws error while > re-calculate and other functions. What changed here? started returning error for what API? also please fix up 70 char alignment -> there extra spaces in your commit message. > > In this fix, before assigning and adding clock in list, > driver checks if given clock is valid or not. > > Fixes: 3c13933c6033 ("clk: keystone: sci-clk: add support for dynamically probing clocks") > > [0] https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/j7200/clocks.html > Section Clocks for NAVSS0_CPTS_0 Device, > clock id 12-15 and 18-19 not present > > Signed-off-by: Udit Kumar <u-kumar1@ti.com> > --- > Original logs > https://gist.github.com/uditkumarti/de4b36b21247fb36725ad909ce4812f6#file-original-logs > Line 2630 for error > > Logs with fix > https://gist.github.com/uditkumarti/de4b36b21247fb36725ad909ce4812f6#file-with-fix > Line 2594 > > drivers/clk/keystone/sci-clk.c | 20 ++++++++++++++++---- > 1 file changed, 16 insertions(+), 4 deletions(-) > > diff --git a/drivers/clk/keystone/sci-clk.c b/drivers/clk/keystone/sci-clk.c > index 35fe197dd303..d417ec018d82 100644 > --- a/drivers/clk/keystone/sci-clk.c > +++ b/drivers/clk/keystone/sci-clk.c > @@ -517,6 +517,8 @@ static int ti_sci_scan_clocks_from_dt(struct sci_clk_provider *provider) > int num_clks = 0; > int num_parents; > int clk_id; > + int max_clk_id; > + u64 freq; > const char * const clk_names[] = { > "clocks", "assigned-clocks", "assigned-clock-parents", NULL > }; > @@ -584,6 +586,7 @@ static int ti_sci_scan_clocks_from_dt(struct sci_clk_provider *provider) > } > > clk_id = args.args[1] + 1; > + max_clk_id = clk_id + num_parents; > > while (num_parents--) { > sci_clk = devm_kzalloc(dev, > @@ -592,11 +595,20 @@ static int ti_sci_scan_clocks_from_dt(struct sci_clk_provider *provider) > if (!sci_clk) > return -ENOMEM; > sci_clk->dev_id = args.args[0]; > - sci_clk->clk_id = clk_id++; > - sci_clk->provider = provider; > - list_add_tail(&sci_clk->node, &clks); > + /* check if given clock id is valid by calling get_freq */ > + /* loop over max possible ids */ > + do { > + sci_clk->clk_id = clk_id++; > > - num_clks++; > + ret = provider->ops->get_freq(provider->sci, > + sci_clk->dev_id, sci_clk->clk_id, &freq); > + } while (ret != 0 && clk_id < max_clk_id); take clock ids 0 1 2 3 -> Say 2 is reserved. num_parents = 4 while(num_parents) Loop 1 -> clk ID 0 is valid, list_add_tail while(num_parents) Loop 2 -> clk ID 1 is valid, list_add_tail while(num_parents) Loop 3 -> clk ID 2 is invalid.. so we scan forward to clk ID 3 -> list_add_tail while(num_parents) Loop 4 -> clk ID 4 is invalid.. but 5 is out of range, so we break off loop. sci_clk is still devm_kzalloced -> but since clk_id > max_clk_id, we jump off loop, and we dont add it to tail. so one extra allocation? If we have multiple reserved intermediate ones, then we'd have as many allocations that aren't linked? Could we not improve the logic a bit to allocate just what is necessary? > + > + sci_clk->provider = provider; > + if (ret == 0) { > + list_add_tail(&sci_clk->node, &clks); > + num_clks++; > + } > } > } > > -- > 2.34.1 >
On 2/5/2024 7:34 PM, Nishanth Menon wrote: > On 10:15-20240205, Udit Kumar wrote: >> Most of clocks and their parents are defined in contiguous range, >> But in few cases, there is gap in clock numbers[0]. >> >> Driver assumes clocks to be in contiguous range, and assigns >> accordingly. >> >> New firmware started returning error in case of >> non-available clock id. Therefore drivers throws error while >> re-calculate and other functions. > What changed here? started returning error for what API? also please fix > up 70 char alignment -> there extra spaces in your commit message. will address in v2 >> In this fix, before assigning and adding clock in list, >> driver checks if given clock is valid or not. >> >> Fixes: 3c13933c6033 ("clk: keystone: sci-clk: add support for dynamically probing clocks") >> >> [0] https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/j7200/clocks.html >> Section Clocks for NAVSS0_CPTS_0 Device, >> clock id 12-15 and 18-19 not present >> >> Signed-off-by: Udit Kumar <u-kumar1@ti.com> >> --- >> Original logs >> https://gist.github.com/uditkumarti/de4b36b21247fb36725ad909ce4812f6#file-original-logs >> Line 2630 for error >> >> Logs with fix >> https://gist.github.com/uditkumarti/de4b36b21247fb36725ad909ce4812f6#file-with-fix >> Line 2594 >> >> drivers/clk/keystone/sci-clk.c | 20 ++++++++++++++++---- >> 1 file changed, 16 insertions(+), 4 deletions(-) >> >> diff --git a/drivers/clk/keystone/sci-clk.c b/drivers/clk/keystone/sci-clk.c >> index 35fe197dd303..d417ec018d82 100644 >> --- a/drivers/clk/keystone/sci-clk.c >> +++ b/drivers/clk/keystone/sci-clk.c >> @@ -517,6 +517,8 @@ static int ti_sci_scan_clocks_from_dt(struct sci_clk_provider *provider) >> int num_clks = 0; >> int num_parents; >> [..] >> - num_clks++; >> + ret = provider->ops->get_freq(provider->sci, >> + sci_clk->dev_id, sci_clk->clk_id, &freq); >> + } while (ret != 0 && clk_id < max_clk_id); > take clock ids 0 1 2 3 -> Say 2 is reserved. > num_parents = 4 > while(num_parents) Loop 1 -> clk ID 0 is valid, list_add_tail > while(num_parents) Loop 2 -> clk ID 1 is valid, list_add_tail > while(num_parents) Loop 3 -> clk ID 2 is invalid.. so we scan forward > to clk ID 3 -> list_add_tail > while(num_parents) Loop 4 -> clk ID 4 is invalid.. but 5 is out of > range, so we break off loop. sci_clk is still devm_kzalloced -> > but since clk_id > max_clk_id, we jump off loop, and we dont add > it to tail. so one extra allocation? Thanks for catching this. > If we have multiple reserved intermediate ones, then we'd have as many > allocations that aren't linked? Could we not improve the logic a bit to > allocate just what is necessary? Sure, will change in v2. to check clock validity first and then allocate, add >> + >> + sci_clk->provider = provider; >> + if (ret == 0) { >> + list_add_tail(&sci_clk->node, &clks); >> + num_clks++; >> + } >> } >> } >> >> -- >> 2.34.1 >>
diff --git a/drivers/clk/keystone/sci-clk.c b/drivers/clk/keystone/sci-clk.c index 35fe197dd303..d417ec018d82 100644 --- a/drivers/clk/keystone/sci-clk.c +++ b/drivers/clk/keystone/sci-clk.c @@ -517,6 +517,8 @@ static int ti_sci_scan_clocks_from_dt(struct sci_clk_provider *provider) int num_clks = 0; int num_parents; int clk_id; + int max_clk_id; + u64 freq; const char * const clk_names[] = { "clocks", "assigned-clocks", "assigned-clock-parents", NULL }; @@ -584,6 +586,7 @@ static int ti_sci_scan_clocks_from_dt(struct sci_clk_provider *provider) } clk_id = args.args[1] + 1; + max_clk_id = clk_id + num_parents; while (num_parents--) { sci_clk = devm_kzalloc(dev, @@ -592,11 +595,20 @@ static int ti_sci_scan_clocks_from_dt(struct sci_clk_provider *provider) if (!sci_clk) return -ENOMEM; sci_clk->dev_id = args.args[0]; - sci_clk->clk_id = clk_id++; - sci_clk->provider = provider; - list_add_tail(&sci_clk->node, &clks); + /* check if given clock id is valid by calling get_freq */ + /* loop over max possible ids */ + do { + sci_clk->clk_id = clk_id++; - num_clks++; + ret = provider->ops->get_freq(provider->sci, + sci_clk->dev_id, sci_clk->clk_id, &freq); + } while (ret != 0 && clk_id < max_clk_id); + + sci_clk->provider = provider; + if (ret == 0) { + list_add_tail(&sci_clk->node, &clks); + num_clks++; + } } }