linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: James Hogan <james.hogan@imgtec.com>
To: Luciano Coelho <coelho@ti.com>
Cc: Mike Turquette <mturquette@linaro.org>,
	linux-arm-kernel@lists.infradead.org,
	LKML <linux-kernel@vger.kernel.org>,
	balbi@ti.com
Subject: Re: [RFC] clk: add flags to distinguish xtal clocks
Date: Fri, 5 Jul 2013 14:12:08 +0100	[thread overview]
Message-ID: <CAAG0J98UL5sLTmRx1o8XnbK8qWv_qNi9+zwuyPBbbYExPSbw8g@mail.gmail.com> (raw)
In-Reply-To: <1372971912-10877-1-git-send-email-coelho@ti.com>

On 4 July 2013 22:05, Luciano Coelho <coelho@ti.com> wrote:
> Add a flag that indicate whether the clock is a crystal or not.  Since
> no clocks set this flag right now, include an additional flag that
> indicates whether the type is set or not.  If the CLK_IS_TYPE_DEFINED
> flag is not set, the value of the CLK_IS_TYPE_XTAL flag is undefined.
> This ensures backwards compatibility.
>
> Additionally, parse a new device tree binding in clk-fixed-rate to set
> this flag.
>
> Signed-off-by: Luciano Coelho <coelho@ti.com>
> ---
>
> I'm not  familiar with the common clock framework and I'm not
> entirely sure the flags can be used in such a way, but to me it looks
> reasonable, since some clock consumers may need to know what type of
> clock is being provided.
>
> Specifically, the wl12xx firmware needs to know if the clock is XTAL
> or not to handle the stabilization and boosts properly.
>
> My main idea is that I need to pass this information in the device
> tree definition of the clocks, so that the driver can pass this
> information on to the firmware.
>
> Please let me know if this looks ok or not.  If not, please let me
> know if you have any other ideas on how to solve my problem (of
> knowing whether the clock attached to the WiLink chip is XTAL or not).

The TZ1090 SoC has something that sounds possibly similar, where some
of the XTAL pads have a bypass bit, which according to the hardware
engineer I asked should be enabled when you want to use the
corresponding XTAL pads as a clock input pad rather than an
oscillator. I was considering extending clk-fixed-rate (via a wrapper
driver) to parse a custom DT property and a register address / bit
number and set the bypass bit as appropriate itself.

So I was wondering, is there a particular reason you don't have a DT
property on the node for the device that needs to know what type of
clock it is, rather than the clock node itself? That way you're not
depending directly on the generic common clock framework to be able to
tell you such electrical details.

Cheers
James

  parent reply	other threads:[~2013-07-05 13:12 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-04 21:05 [RFC] clk: add flags to distinguish xtal clocks Luciano Coelho
     [not found] ` <20130704222538.10823.2559@quantum>
2013-07-04 22:37   ` Luciano Coelho
     [not found]     ` <20130704231953.10823.94331@quantum>
2013-07-05  7:54       ` Luciano Coelho
2013-07-29 13:50         ` Luciano Coelho
     [not found]           ` <20131007074424.7445.52119@quantum>
2013-10-08 15:27             ` Felipe Balbi
2013-10-16 10:24               ` Luca Coelho
2013-10-23  9:24                 ` Mike Turquette
2013-10-23 11:35                   ` Luca Coelho
2013-11-08 18:00                     ` [PATCH] " Felipe Balbi
2013-11-08 19:16                       ` Luca Coelho
2013-11-10 11:37                       ` Maxime Ripard
2013-11-11 19:42                         ` Felipe Balbi
2013-11-11 19:50                           ` Luca Coelho
2013-11-11 20:59                             ` Maxime Ripard
2013-11-12  8:05                               ` Luca Coelho
2013-11-13 14:40                                 ` Maxime Ripard
2013-11-11 20:54                           ` Maxime Ripard
2013-11-11 16:27                       ` Stephen Warren
2013-11-11 19:43                         ` Felipe Balbi
2013-07-05 13:12 ` James Hogan [this message]
2013-07-05 13:21   ` [RFC] " Felipe Balbi
2013-07-05 13:22   ` Luciano Coelho

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=CAAG0J98UL5sLTmRx1o8XnbK8qWv_qNi9+zwuyPBbbYExPSbw8g@mail.gmail.com \
    --to=james.hogan@imgtec.com \
    --cc=balbi@ti.com \
    --cc=coelho@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mturquette@linaro.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).