All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Brandt <Chris.Brandt@renesas.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Ulf Hansson <ulf.hansson@linaro.org>,
	Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Simon Horman <horms@verge.net.au>,
	Wolfram Sang <wsa+renesas@sang-engineering.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	Linux MMC List <linux-mmc@vger.kernel.org>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>
Subject: RE: [PATCH v5 1/3] mmc: sh_mobile_sdhi: add support for 2 clocks
Date: Mon, 23 Jan 2017 14:48:45 +0000	[thread overview]
Message-ID: <SG2PR06MB11656145E7F0EEA7117F09A08A720@SG2PR06MB1165.apcprd06.prod.outlook.com> (raw)
In-Reply-To: <CAMuHMdWwqa7CbNCRr8q60hDVsj243-ZjHCPp+o9R2a6Dg7YNWQ@mail.gmail.com>

Hi Geert,

On Monday, January 23, 2017, Geert Uytterhoeven:
> > @@ -190,6 +191,12 @@ static int sh_mobile_sdhi_clk_enable(struct
> tmio_mmc_host *host)
> >         if (ret < 0)
> >                 return ret;
> >
> > +       ret = clk_prepare_enable(priv->clk_cd);
> > +       if (ret < 0) {
> > +               clk_disable_unprepare(priv->clk);
> > +               return ret;
> > +       }
> > +
> 
> As enabling the "core" clock but not the "cd" clock is not a valid setting,
> shouldn't the cd clock be enabled first?

I'm pretty sure the chip designers just didn't want you to 'use' the
peripheral with that clock configuration, and we are not using it in
between those 2 lines so I personally think it's fine.

If I need to change it to get it approved, let me know and I'll change
the code around.

(In reality, I checked and the SDHI does work with the cd clock off,
but I don't know if the restriction in the spec was because they never
fully tested the use of it that way because it wasn't a design goal for
them.)



> >         /*
> >          * The clock driver may not know what maximum frequency
> >          * actually works, so it should be set with the max-frequency
> > @@ -255,6 +262,8 @@ static void sh_mobile_sdhi_clk_disable(struct
> tmio_mmc_host *host)
> >         struct sh_mobile_sdhi *priv = host_to_priv(host);
> >
> >         clk_disable_unprepare(priv->clk);
> > +       if (priv->clk_cd)
> 
> No need to check for a NULL pointer first.

OK, I see that IS_ERR_OR_NULL(clk) is done for clk_disable_unprepare so
I'll take the check out.
Thank you.


> > +               clk_disable_unprepare(priv->clk_cd);
> 
> Disabling is already done in the correct order ;-)

I guess you could get into some theoretical technical discussion around
if it is OK to enable/disable the clocks in any order (as long as you
don't use the SDHI in between), then you would want to enable the cd
circuit last, and disable it first so you would ensure that no cd
interrupts are being registered when the core clock is off?
In that case, the current enable order should remain but the disable
order should change.

Opinions???


Thank you,
Chris

  reply	other threads:[~2017-01-23 14:48 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-21  3:06 [PATCH v5 0/3] mmc: sh_mobile_sdhi: fix missing r7s72100 clocks Chris Brandt
2017-01-21  3:06 ` Chris Brandt
2017-01-21  3:06 ` [PATCH v5 1/3] mmc: sh_mobile_sdhi: add support for 2 clocks Chris Brandt
2017-01-21  9:37   ` Wolfram Sang
2017-01-23  9:22   ` Geert Uytterhoeven
2017-01-23 14:48     ` Chris Brandt [this message]
     [not found] ` <20170121030604.7672-1-chris.brandt-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
2017-01-21  3:06   ` [PATCH v5 2/3] mmc: sh_mobile_sdhi: explain clock bindings Chris Brandt
2017-01-21  3:06     ` Chris Brandt
     [not found]     ` <20170121030604.7672-3-chris.brandt-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
2017-01-21  9:36       ` Wolfram Sang
2017-01-21  9:36         ` Wolfram Sang
2017-01-23  9:18     ` Geert Uytterhoeven
2017-01-23 16:55     ` Rob Herring
2017-01-23 17:56       ` Chris Brandt
2017-01-26 14:39         ` Rob Herring
2017-01-26 15:20           ` Chris Brandt
2017-01-27  8:36           ` Ulf Hansson
2017-01-21  3:06 ` [PATCH v5 3/3] ARM: dts: r7s72100: update sdhi " Chris Brandt

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=SG2PR06MB11656145E7F0EEA7117F09A08A720@SG2PR06MB1165.apcprd06.prod.outlook.com \
    --to=chris.brandt@renesas.com \
    --cc=devicetree@vger.kernel.org \
    --cc=geert@linux-m68k.org \
    --cc=horms@verge.net.au \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=ulf.hansson@linaro.org \
    --cc=wsa+renesas@sang-engineering.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.