Message ID | 20240213082640.457316-1-u-kumar1@ti.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-63115-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:bc8a:b0:106:860b:bbdd with SMTP id dn10csp398456dyb; Tue, 13 Feb 2024 00:31:35 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCXBRMTLME3yzMTM9n2eqTBGnN7zRD2lHYMA5sHQxKEiRdO7idYv5Pz5w83unTe1cpx4ORoczF4WMVSFvxGp5M4oygY8zw== X-Google-Smtp-Source: AGHT+IGH8EiM2PGsrm8sibVC1mWVeqHuPNKg1v4Jhcmn7FTP5NLOViIUj7p1xJFkDr7fATT3gkln X-Received: by 2002:a17:902:e892:b0:1d9:d:5730 with SMTP id w18-20020a170902e89200b001d9000d5730mr9248301plg.3.1707813095264; Tue, 13 Feb 2024 00:31:35 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1707813095; cv=pass; d=google.com; s=arc-20160816; b=PzCTZImi/HS2fqXVaItshkqTH7JyZYLqNg+YNTCVMl3YpDaZ2DNCIGIRRbez6igCVI S7ETrN+50z92mRNFmJ4oufXQ0DOGdBBIsddN6PzjrAP47dspzNH9L1nK54gou4wxlyf+ LyQdiO0T4VWIIbVzhtAi6tkZzjKoRbsZT+5qq/Ecr0s4z3kJRg1EhBb5ks5Ym9I9L01S MVRW5YdV0N+HMnGyHTk34nA2XLE1bvcwpVkdMTEa7d21ceoXK6OQFVFSBJ3B6s82E5T6 abW31lmU+0nkpZxDqnHnNoprXSW9yumvHXmAO+Uuw7Hkwzbjxeis8BDZAQPwrAaAlE73 rZTg== 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=efVT6VYP6+c1CNm4+amsfIbNPIkqQ++4RigN9/iTUGI=; fh=zrzVNKV6xWhIUdph/kQuNOj24PHlMdx42bU1EAL1+8M=; b=KdNxjQAHzeGerQ3kusRIKw8kt2os/I0C56jUNvoznCqXtdFnPj6eVSmA3GtKqVJkaf dnRLld/ERf8EPtpcHcmdzCJnsyqPUmKpqWvxhlO6NDE+OX+wAmyHeQhaYM/BWmLuNsy5 7lXGSi9Oi8h2HG5CEjQpFMEVFs2zow4xavuWkDJ5Xu/biAbbiC4tq0sWMppb3zajyJaz VRBp7Wfz5GXgEXiNJ19DrlpyvHVivp6GyxO7pxHBfU+vNEh3qLsN/7Th9n1I5CWi2eoj /kTnFx0G5KNpgB9Fyu+Vj9YhhbLjYivJsbRx4pS2a/qAsXFexSGOgOVRXjqRIg+ifW28 6rxA==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=JEOBt5OX; 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-63115-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-63115-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com X-Forwarded-Encrypted: i=2; AJvYcCUJp8ys8ljWk4GPR0FWYsjS/Oe9NY/pVgzxocKCCSU16TXhAXG0bfGDFHZFZLmjdWEgFzSXDaBcZPBraJqmLzO8sLdr1w== Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [2604:1380:40f1:3f00::1]) by mx.google.com with ESMTPS id ix9-20020a170902f80900b001d952ae03f9si1559393plb.603.2024.02.13.00.31.34 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 13 Feb 2024 00:31:35 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-63115-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=JEOBt5OX; 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-63115-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-63115-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 sy.mirrors.kernel.org (Postfix) with ESMTPS id F2BEBB2418F for <ouuuleilei@gmail.com>; Tue, 13 Feb 2024 08:27:54 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id C935C1A701; Tue, 13 Feb 2024 08:27:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=ti.com header.i=@ti.com header.b="JEOBt5OX" Received: from fllv0016.ext.ti.com (fllv0016.ext.ti.com [198.47.19.142]) (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 5F57822319; Tue, 13 Feb 2024 08:27:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.47.19.142 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707812828; cv=none; b=LEJ9G+6tDODOrBhGjuDRB2yorw/ipmdiLkmyRjiFWdmMPjESOZyfm/wt07efpV0giFA7quEAiQ5vcuZOBCv2GlKqBMqeTdEpIVfcibWO1Eohl8y36YepBYWlWsNq5MVhojOFA9KyYQjw3VwWzSxNIFrBL6/uS0UTnbbogS6Xa6o= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707812828; c=relaxed/simple; bh=uQ3pvkYlbb9sP+1HniO8vjtexme1WQGKUWPzjjcS9jU=; h=From:To:CC:Subject:Date:Message-ID:MIME-Version:Content-Type; b=qJlklJ8uSpP9RmqECUYC9ITcoIkZiYEtIWT1YQWouA5MLbV3D3HizcxABRSbH3NT4LSF4iRZtUnivWJ+lS0YBBDFNkUDfhHXLaEoKw2xsn+P7RyoraWzeKd3cOEbIMDKiVS4w2NPiTm/4W3sBle2f3o6SSfRV/vYNC/HMEmfPx0= 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=JEOBt5OX; arc=none smtp.client-ip=198.47.19.142 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 fllv0016.ext.ti.com (8.15.2/8.15.2) with ESMTP id 41D8Qr3E049651; Tue, 13 Feb 2024 02:26:53 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1707812813; bh=efVT6VYP6+c1CNm4+amsfIbNPIkqQ++4RigN9/iTUGI=; h=From:To:CC:Subject:Date; b=JEOBt5OXFXIq0UCpmKVle7JORkfKWb+EKI8MpCpJO2mmXPaROubeP6qSnjOtL4Ynp KymtsCniLld8mUfa2k00racz+VCxvElKUh2YyKjNlLojP/0sQm6V1gB7TOGv6bWcM7 eXhVXr3O8u7+2U5zsJY1SfMEFcT3McYePOhJ07HU= Received: from DFLE102.ent.ti.com (dfle102.ent.ti.com [10.64.6.23]) by fllv0035.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 41D8QrB1010740 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 13 Feb 2024 02:26:53 -0600 Received: from DFLE115.ent.ti.com (10.64.6.36) by DFLE102.ent.ti.com (10.64.6.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23; Tue, 13 Feb 2024 02:26:52 -0600 Received: from lelvsmtp6.itg.ti.com (10.180.75.249) by DFLE115.ent.ti.com (10.64.6.36) 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; Tue, 13 Feb 2024 02:26:52 -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 lelvsmtp6.itg.ti.com (8.15.2/8.15.2) with ESMTP id 41D8Qm5k102902; Tue, 13 Feb 2024 02:26:49 -0600 From: Udit Kumar <u-kumar1@ti.com> To: <nm@ti.com>, <kristo@kernel.org>, <ssantosh@kernel.org>, <chandru@ti.com>, <rishabh@ti.com>, <kamlesh@ti.com>, <francesco@dolcini.it> 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 v4] clk: keystone: sci-clk: Adding support for non contiguous clocks Date: Tue, 13 Feb 2024 13:56:40 +0530 Message-ID: <20240213082640.457316-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: 1790771824295586389 X-GMAIL-MSGID: 1790771824295586389 |
Series |
[v4] clk: keystone: sci-clk: Adding support for non contiguous clocks
|
|
Commit Message
Kumar, Udit
Feb. 13, 2024, 8:26 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 add their clock
ids incrementally.
New firmware started returning error while calling get_freq and is_on
API for non-available clock ids.
In this fix, driver checks and adds only valid clock ids.
[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 not present.
Fixes: 3c13933c6033 ("clk: keystone: sci-clk: add support for dynamically probing clocks")
Signed-off-by: Udit Kumar <u-kumar1@ti.com>
---
Changelog
Changes in v4
- Added only incremental chanegs as per v3 discussion
- Updated commit message
- v3 was Reviewed-by, Dropping Reviewed-by as logic is changed
Link to v3
https://lore.kernel.org/all/20240207091100.4001428-1-u-kumar1@ti.com/
Changes in v3
- instead of get_freq, is_auto API is used to check validilty of clock
- Address comments of v2, to have preindex increment
Link to v2 https://lore.kernel.org/all/20240206104357.3803517-1-u-kumar1@ti.com/
Changes in v2
- Updated commit message
- Simplified logic for valid clock id
link to v1 https://lore.kernel.org/all/20240205044557.3340848-1-u-kumar1@ti.com/
P.S
Firmawre returns total num_parents count including non available ids.
For above device id NAVSS0_CPTS_0, number of parents clocks are 16
i.e from id 2 to 17. But out of these ids few are not valid.
So driver adds only valid clock ids out ot total.
Original logs
https://gist.github.com/uditkumarti/de4b36b21247fb36725ad909ce4812f6#file-original-logs
Line 2630 for error
Logs with fix v4
https://gist.github.com/uditkumarti/f25482a5e18e918010b790cffb39f572
Line 2640
drivers/clk/keystone/sci-clk.c | 10 ++++++++++
1 file changed, 10 insertions(+)
Comments
On 13:56-20240213, 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 add their clock > ids incrementally. > > New firmware started returning error while calling get_freq and is_on > API for non-available clock ids. > > In this fix, driver checks and adds only valid clock ids. > > [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 not present. > > Fixes: 3c13933c6033 ("clk: keystone: sci-clk: add support for dynamically probing clocks") > Signed-off-by: Udit Kumar <u-kumar1@ti.com> > --- > Changelog > Changes in v4 > - Added only incremental chanegs as per v3 discussion > - Updated commit message > - v3 was Reviewed-by, Dropping Reviewed-by as logic is changed > Link to v3 > https://lore.kernel.org/all/20240207091100.4001428-1-u-kumar1@ti.com/ > > Changes in v3 > - instead of get_freq, is_auto API is used to check validilty of clock > - Address comments of v2, to have preindex increment > Link to v2 https://lore.kernel.org/all/20240206104357.3803517-1-u-kumar1@ti.com/ > > Changes in v2 > - Updated commit message > - Simplified logic for valid clock id > link to v1 https://lore.kernel.org/all/20240205044557.3340848-1-u-kumar1@ti.com/ > > > P.S > Firmawre returns total num_parents count including non available ids. > For above device id NAVSS0_CPTS_0, number of parents clocks are 16 > i.e from id 2 to 17. But out of these ids few are not valid. > So driver adds only valid clock ids out ot total. > > Original logs > https://gist.github.com/uditkumarti/de4b36b21247fb36725ad909ce4812f6#file-original-logs > Line 2630 for error > > Logs with fix v4 > https://gist.github.com/uditkumarti/f25482a5e18e918010b790cffb39f572 > Line 2640 > > > drivers/clk/keystone/sci-clk.c | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/drivers/clk/keystone/sci-clk.c b/drivers/clk/keystone/sci-clk.c > index 35fe197dd303..eb2ef44869b2 100644 > --- a/drivers/clk/keystone/sci-clk.c > +++ b/drivers/clk/keystone/sci-clk.c > @@ -516,6 +516,7 @@ static int ti_sci_scan_clocks_from_dt(struct sci_clk_provider *provider) > struct sci_clk *sci_clk, *prev; > int num_clks = 0; > int num_parents; > + bool state; > int clk_id; > const char * const clk_names[] = { > "clocks", "assigned-clocks", "assigned-clock-parents", NULL > @@ -586,6 +587,15 @@ static int ti_sci_scan_clocks_from_dt(struct sci_clk_provider *provider) > clk_id = args.args[1] + 1; > > while (num_parents--) { > + /* Check if this clock id is valid */ > + ret = provider->ops->is_auto(provider->sci, > + sci_clk->dev_id, clk_id, &state); > + > + if (ret) { > + clk_id++; > + continue; > + } > + Thanks. This makes more sense. Reviewed-by: Nishanth Menon <nm@ti.com> > sci_clk = devm_kzalloc(dev, > sizeof(*sci_clk), > GFP_KERNEL); > -- > 2.34.1 >
Quoting Udit Kumar (2024-02-13 00:26:40) > 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 add their clock > ids incrementally. > > New firmware started returning error while calling get_freq and is_on > API for non-available clock ids. > > In this fix, driver checks and adds only valid clock ids. > > [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 not present. > > Fixes: 3c13933c6033 ("clk: keystone: sci-clk: add support for dynamically probing clocks") > Signed-off-by: Udit Kumar <u-kumar1@ti.com> > --- Applied to clk-next
On Tue, Feb 13, 2024 at 01:56:40PM +0530, 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 add their clock > ids incrementally. > > New firmware started returning error while calling get_freq and is_on > API for non-available clock ids. Is this the kind of errors I should expect in such situation? ti-sci-clk 44043000.system-controller:clock-controller: recalc-rate failed for dev=13, clk=7, ret=-19 If this is the case, I feel like this patch should be back-ported to stable kernels. Any malfunction because of these errors or just some noise in the logs? Francesco
On 2/26/2024 4:24 PM, Francesco Dolcini wrote: > On Tue, Feb 13, 2024 at 01:56:40PM +0530, 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 add their clock >> ids incrementally. >> >> New firmware started returning error while calling get_freq and is_on >> API for non-available clock ids. > Is this the kind of errors I should expect in such situation? > > ti-sci-clk 44043000.system-controller:clock-controller: recalc-rate failed for dev=13, clk=7, ret=-19 > > If this is the case, I feel like this patch should be back-ported to > stable kernels. Sure will send to stable@vger.kernel.org > Any malfunction because of these errors or just some noise in the logs? Error is noise in logs, no impact on function as these reserved clocks are not used by drivers. > > Francesco >
diff --git a/drivers/clk/keystone/sci-clk.c b/drivers/clk/keystone/sci-clk.c index 35fe197dd303..eb2ef44869b2 100644 --- a/drivers/clk/keystone/sci-clk.c +++ b/drivers/clk/keystone/sci-clk.c @@ -516,6 +516,7 @@ static int ti_sci_scan_clocks_from_dt(struct sci_clk_provider *provider) struct sci_clk *sci_clk, *prev; int num_clks = 0; int num_parents; + bool state; int clk_id; const char * const clk_names[] = { "clocks", "assigned-clocks", "assigned-clock-parents", NULL @@ -586,6 +587,15 @@ static int ti_sci_scan_clocks_from_dt(struct sci_clk_provider *provider) clk_id = args.args[1] + 1; while (num_parents--) { + /* Check if this clock id is valid */ + ret = provider->ops->is_auto(provider->sci, + sci_clk->dev_id, clk_id, &state); + + if (ret) { + clk_id++; + continue; + } + sci_clk = devm_kzalloc(dev, sizeof(*sci_clk), GFP_KERNEL);