linux-mmc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: dinguyen@altera.com
Cc: dinh.linux@gmail.com, mturquette@linaro.org,
	rob.herring@calxeda.com, pawel.moll@arm.com,
	mark.rutland@arm.com, ian.campbell@citrix.com, cjb@laptop.org,
	jh80.chung@samsung.com, tgih.jun@samsung.com,
	devicetree@vger.kernel.org, linux-mmc@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCHv4 2/4] clk: socfpga: Add a hook for SD/MMC driver to control CIU clock settings
Date: Thu, 5 Dec 2013 21:57:37 +0100	[thread overview]
Message-ID: <201312052157.37538.arnd@arndb.de> (raw)
In-Reply-To: <1386263677-7733-3-git-send-email-dinguyen@altera.com>

On Thursday 05 December 2013, dinguyen@altera.com wrote:
> From: Dinh Nguyen <dinguyen@altera.com>
> 
> Populate the .prepare function in the clk-ops for the "sdmmc_clk" that represents
> the "ciu" clock for the SD/MMC driver. The prepare function will handle setting
> the correct clock-phase for the CIU clock of the SD/MMC IP.
> 
> Re-use the "rockchip,rk2928-dw-mshc" binding as it is already defined and
> appropriate for the SOCFPGA platform as well.
> 
> Signed-off-by: Dinh Nguyen <dinguyen@altera.com>

I think with this series we're getting closer to where things should be, but
there are still a number of the same problems. Maybe I have misunderstood
a few things here in how the clocks fit together, but here is what still
looks wrong about this patch:

> diff --git a/drivers/clk/socfpga/clk.c b/drivers/clk/socfpga/clk.c
> index 60cb2f5..01baf20 100644
> --- a/drivers/clk/socfpga/clk.c
> +++ b/drivers/clk/socfpga/clk.c
> @@ -55,7 +55,13 @@
>  #define div_mask(width)	((1 << (width)) - 1)
>  #define streq(a, b) (strcmp((a), (b)) == 0)
>  
> +#define SYSMGR_SDMMCGRP_CTRL_OFFSET	0x108
> +/* SDMMC Group for System Manager defines */
> +#define SYSMGR_SDMMC_CTRL_SET(smplsel, drvsel)          \
> +	((((smplsel) & 0x7) << 3) | (((drvsel) & 0x7) << 0))
> +
>  extern void __iomem *clk_mgr_base_addr;
> +extern void __iomem *sys_manager_base_addr;

As mentioned in yesterday's comments, you should not have the 'extern'
declaration for sys_manager_base_addr here. In fact, the existing
clk_mgr_base_addr declaration is just as wrong.

> +static int sdmmc_ciuclk_prepare(struct clk_hw *hwclk)
> +{
> +	struct device_node *np;
> +	u32 timing[2];
> +	u32 hs_timing;
> +
> +	np = of_find_compatible_node(NULL, NULL, "rockchip,rk2928-dw-mshc");
> +	if (of_property_read_u32_array(np, "samsung,dw-mshc-sdr-timing", timing, 2)) {
> +		pr_err("SDMMC: cannot find samsung,dw-mshc-sdr-timing!\n");
> +		return -ENODATA;
> +	}
> +	hs_timing = SYSMGR_SDMMC_CTRL_SET(timing[1], timing[0]);
> +	writel(hs_timing, sys_manager_base_addr + SYSMGR_SDMMCGRP_CTRL_OFFSET);
> +	return 0;
> +}
> +

And in now way should the clock provider code look into the DT properties of the
clock consumer. From what I can tell, the dw-mshc code already interprets the
"samsung,dw-mshc-sdr-timing" property and uses the data to pass the correct
clock rate using 'clk_set_rate()'. The clock code should only use the data passed
in the argument to that function to set up the registers and not need to know
at all who is setting it.

I am a little confused though what the SYSMGR_SDMMCGRP_CTRL_OFFSET register actually
does. It looks like this is just a clock divider, which should be represented as
a separate clock node (as you had in v3) and compute the correct factor from the
requested clock rate and the parent clock rate.

	Arnd

  reply	other threads:[~2013-12-05 20:57 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-05 17:14 [PATCHv4 0/4] socfpga: Enable SD/MMC support dinguyen
2013-12-05 17:14 ` [PATCHv4 1/4] arm: dts: Add support for SD/MMC on SOCFPGA dinguyen
2013-12-05 21:08   ` Arnd Bergmann
2013-12-05 22:10     ` Dinh Nguyen
2013-12-06  0:47       ` Arnd Bergmann
2013-12-05 17:14 ` [PATCHv4 2/4] clk: socfpga: Add a hook for SD/MMC driver to control CIU clock settings dinguyen
2013-12-05 20:57   ` Arnd Bergmann [this message]
2013-12-10 14:08     ` Dinh Nguyen
2013-12-10 18:15       ` Arnd Bergmann
2013-12-12 21:45         ` Dinh Nguyen
2013-12-05 17:14 ` [PATCHv4 3/4] mmc: dw_mmc-socfpga: Remove the SOCFPGA specific platform for dw_mmc dinguyen
2013-12-05 17:14 ` [PATCHv4 4/4] ARM: socfpga_defconfig: enable SD/MMC support dinguyen

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=201312052157.37538.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=cjb@laptop.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dinguyen@altera.com \
    --cc=dinh.linux@gmail.com \
    --cc=ian.campbell@citrix.com \
    --cc=jh80.chung@samsung.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mturquette@linaro.org \
    --cc=pawel.moll@arm.com \
    --cc=rob.herring@calxeda.com \
    --cc=tgih.jun@samsung.com \
    /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).