linux-clk.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Cristian Ciocaltea <cristian.ciocaltea@gmail.com>
To: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Cc: "Stephen Boyd" <sboyd@kernel.org>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Andreas Färber" <afaerber@suse.de>,
	"Michael Turquette" <mturquette@baylibre.com>,
	"Edgar Bernardi Righi" <edgar.righi@lsitec.org.br>,
	linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-actions@lists.infradead.org, linux-kernel@vger.kernel.org,
	devicetree@vger.kernel.org
Subject: Re: [PATCH 2/6] clk: actions: Fix SD clocks factor table on Owl S500 SoC
Date: Tue, 16 Mar 2021 20:14:37 +0200	[thread overview]
Message-ID: <20210316181437.GB1111731@BV030612LT> (raw)
In-Reply-To: <20210316035845.GB1798@thinkpad>

Hi Mani,

Thanks for reviewing this patch series!

On Tue, Mar 16, 2021 at 09:28:45AM +0530, Manivannan Sadhasivam wrote:
> On Mon, Mar 08, 2021 at 07:18:27PM +0200, Cristian Ciocaltea wrote:
> > Drop the unsupported entries in the factor table used for the SD[0-2]
> > clocks definitions on the Actions Semi Owl S500 SoC.
> > 
> > Fixes: ed6b4795ece4 ("clk: actions: Add clock driver for S500 SoC")
> > Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@gmail.com>
> > ---
> >  drivers/clk/actions/owl-s500.c | 4 ----
> >  1 file changed, 4 deletions(-)
> > 
> > diff --git a/drivers/clk/actions/owl-s500.c b/drivers/clk/actions/owl-s500.c
> > index 75b7186185b0..69cd959205f5 100644
> > --- a/drivers/clk/actions/owl-s500.c
> > +++ b/drivers/clk/actions/owl-s500.c
> > @@ -127,8 +127,6 @@ static struct clk_factor_table sd_factor_table[] = {
> >  	{ 12, 1, 13 }, { 13, 1, 14 }, { 14, 1, 15 }, { 15, 1, 16 },
> >  	{ 16, 1, 17 }, { 17, 1, 18 }, { 18, 1, 19 }, { 19, 1, 20 },
> >  	{ 20, 1, 21 }, { 21, 1, 22 }, { 22, 1, 23 }, { 23, 1, 24 },
> > -	{ 24, 1, 25 }, { 25, 1, 26 }, { 26, 1, 27 }, { 27, 1, 28 },
> > -	{ 28, 1, 29 }, { 29, 1, 30 }, { 30, 1, 31 }, { 31, 1, 32 },
> 
> How did you determine that these values are not supported?
> 
> I've seen cases where the datasheet has the incomplete information about the
> supported ranges but the downstream driver has everything.

My primary source of information is the xapp-le kernel source code:
https://github.com/xapp-le/kernel

I always try to double check the implementation with the information
in the datasheet, but sometimes, as you already pointed out, it is
incomplete.

For the SD clocks, it is even worse: there is absolutely no information
related to the CMU_SD[0-2]CLK registers. Therefore I had to rely
exclusively on the downstream driver code.

Hence, for the SD1 clock, I identified the following code snippets:

static struct owl_clkreq divbit_PRESD0_CLK          = BITMAP(CMU_SD0CLK,                0x0000001f, 0);
static struct owl_clkreq divbit_SD0_CLK_2X          = BITMAP(CMU_SD0CLK,                0x00000100, 8);
static struct owl_refertab T_sdx2   = {{1, 128, -1}, 0};

static struct owl_div divider_PRESD0_CLK = {
    .type = DIV_T_NATURE,
    .range_from = 0,
    .range_to = 24,
    .reg = &divbit_PRESD0_CLK,
};

static struct owl_div divider_SD0_CLK_2X = {
    .type = DIV_T_TABLE,
    .range_from = 0,
    .range_to = 1,
    .ext = {.tab = &T_sdx2,},
    .reg = &divbit_SD0_CLK_2X,
};

This is basically what gets translated to sd_factor_table and I removed
the extra entries 25..31. Actually I also dropped the 24th one, since
that would give us an odd number of items, although I'm not quite sure
this is a bug in the xapp-le code or the HW is really supposed to work
like that.

Kind regards,
Cristi

> Thanks,
> Mani
> 
> >  
> >  	/* bit8: /128 */
> >  	{ 256, 1, 1 * 128 }, { 257, 1, 2 * 128 }, { 258, 1, 3 * 128 }, { 259, 1, 4 * 128 },
> > @@ -137,8 +135,6 @@ static struct clk_factor_table sd_factor_table[] = {
> >  	{ 268, 1, 13 * 128 }, { 269, 1, 14 * 128 }, { 270, 1, 15 * 128 }, { 271, 1, 16 * 128 },
> >  	{ 272, 1, 17 * 128 }, { 273, 1, 18 * 128 }, { 274, 1, 19 * 128 }, { 275, 1, 20 * 128 },
> >  	{ 276, 1, 21 * 128 }, { 277, 1, 22 * 128 }, { 278, 1, 23 * 128 }, { 279, 1, 24 * 128 },
> > -	{ 280, 1, 25 * 128 }, { 281, 1, 26 * 128 }, { 282, 1, 27 * 128 }, { 283, 1, 28 * 128 },
> > -	{ 284, 1, 29 * 128 }, { 285, 1, 30 * 128 }, { 286, 1, 31 * 128 }, { 287, 1, 32 * 128 },
> >  	{ 0, 0, 0 },
> >  };
> >  
> > -- 
> > 2.30.1
> > 

  reply	other threads:[~2021-03-16 18:15 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-08 17:18 [PATCH 0/6] Improve clock support for Actions S500 SoC Cristian Ciocaltea
2021-03-08 17:18 ` [PATCH 1/6] clk: actions: Fix UART clock dividers on Owl " Cristian Ciocaltea
2021-03-16  3:50   ` Manivannan Sadhasivam
2021-03-08 17:18 ` [PATCH 2/6] clk: actions: Fix SD clocks factor table " Cristian Ciocaltea
2021-03-16  3:58   ` Manivannan Sadhasivam
2021-03-16 18:14     ` Cristian Ciocaltea [this message]
2021-05-26 10:07       ` Manivannan Sadhasivam
2021-05-27 13:27         ` Cristian Ciocaltea
2021-03-08 17:18 ` [PATCH 3/6] clk: actions: Fix bisp_factor_table based clocks " Cristian Ciocaltea
2021-03-16  4:17   ` Manivannan Sadhasivam
2021-03-16 18:37     ` Cristian Ciocaltea
2021-05-26 10:18       ` Manivannan Sadhasivam
2021-05-27 13:34         ` Cristian Ciocaltea
2021-03-08 17:18 ` [PATCH 4/6] clk: actions: Fix AHPPREDIV-H-AHB clock chain " Cristian Ciocaltea
2021-03-16  5:45   ` Manivannan Sadhasivam
2021-03-16 18:50     ` Cristian Ciocaltea
2021-05-26 10:12       ` Manivannan Sadhasivam
2021-05-27 13:45         ` Cristian Ciocaltea
2021-03-08 17:18 ` [PATCH 5/6] dt-bindings: clock: Add NIC and ETHERNET bindings for Actions " Cristian Ciocaltea
2021-03-16 22:00   ` Rob Herring
2021-03-08 17:18 ` [PATCH 6/6] clk: actions: Add NIC and ETHERNET clock support " Cristian Ciocaltea
2021-03-16  5:52   ` Manivannan Sadhasivam
2021-03-16 19:02     ` Cristian Ciocaltea

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210316181437.GB1111731@BV030612LT \
    --to=cristian.ciocaltea@gmail.com \
    --cc=afaerber@suse.de \
    --cc=devicetree@vger.kernel.org \
    --cc=edgar.righi@lsitec.org.br \
    --cc=linux-actions@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manivannan.sadhasivam@linaro.org \
    --cc=mturquette@baylibre.com \
    --cc=robh+dt@kernel.org \
    --cc=sboyd@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).