linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: sebastian.hesselbarth@googlemail.com (Sebastian Hesselbarh)
To: linux-arm-kernel@lists.infradead.org
Subject: Dove clock support
Date: Mon, 18 Jun 2012 22:38:41 +0200	[thread overview]
Message-ID: <4FDF91D1.1040301@googlemail.com> (raw)
In-Reply-To: <20120618101100.GN4799@lunn.ch>

On 06/18/2012 12:11 PM, Andrew Lunn wrote:
 >> But I'd prefer the driver to take care of clks _and_ PHYs.
 >
 > That would be nice, but we have to remember that the driver is used
 > for a number of different Marvell SoC and discreet devices. Only a few
 > have the ability to turn on/off there clocks and PHYs. So you need to
 > abstract this in such a way it does not break older chipsets.

Well, I'd suggest to find a good name for clk and PHY, e.g.
"pcie.0","clk" and "pcie.0","phy", and let the driver decide if it
enables/disables clk/PHY when it gets a valid struct clk back.

Although struct clk is meant for clocks there is no difference
between clocks and PHYs. Moreover, dove handles PHY control in
it's clock control register sometimes. (Well, it is maybe external
clock to PHY so it's ok)

But first I suggest to have a drivers/clk/clk-orion (which I have
somehow) and I already sent you a proposal some weeks ago.

I wasn't sure how to hook up drivers/clk/clk-orion with the platform
itself but now that there are some other clock drivers available I'll
have another look.

I have the datasheets for dove and kirkwood but with other orion-based
platforms I cannot tell the differences. Maybe someone can comment on
the different other platforms.

 >> One more: I suggest to clean the clk names of orion platforms,
 >> they are a mess
 >
 > Do you have a proposal?

Hmm, well if you look at mach-kirkwood/common.c there is:
- orion_spi.0/NULL (underscore)
- orion-ehci.0/NULL (dash)
- pcie/0
- kirkwood-i2s/NULL

First, I suggest to choose either underscore or dash. Second, pcie/0
should be kirkwood-pcie.0/NULL (or orion-pcie.0) and if we consider
having PHY "clocks" it should be kirkwood-pcie.0/clk.

With kirkwood-i2s/NULL there is mach-dove that has two i2s controllers
so it should be kirkwood-i2s.0. Moreover, the i2s controller can have
an external clk instead of internal clock divider, so the clock names
should be kirkwood-i2s.0/clk and kirkwood-i2s.0/extclk.

With external i2s clock it _could_ be possible to have high bitrate
audio on spdif by overclocking the i2s controller.

Sebastian

  reply	other threads:[~2012-06-18 20:38 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-18  0:07 RFC: [PATCH] ARM: Kirkwood: clk_register_gate_fn: add fn assignment Marc Kleine-Budde
2012-06-18  7:42 ` Andrew Lunn
2012-06-18  7:54   ` Marc Kleine-Budde
2012-06-18  8:04     ` Andrew Lunn
2012-06-18  8:28       ` Dove clock support (was: Re: RFC: [PATCH] ARM: Kirkwood: clk_register_gate_fn: add fn assignment) Marc Kleine-Budde
2012-06-18  8:43         ` Andrew Lunn
2012-06-18  9:42           ` Dove clock support Sebastian Hesselbarh
2012-06-18  9:54             ` Marc Kleine-Budde
2012-06-18 10:01               ` Sebastian Hesselbarh
2012-06-18 10:11                 ` Andrew Lunn
2012-06-18 20:38                   ` Sebastian Hesselbarh [this message]
2012-06-19 19:25                     ` Andrew Lunn
2012-06-19 19:31                       ` Sebastian Hesselbarh
2012-06-19 19:35                         ` Andrew Lunn
2012-06-18 11:50                 ` Marc Kleine-Budde
2012-06-18 21:41           ` Dove clock support (was: Re: RFC: [PATCH] ARM: Kirkwood: clk_register_gate_fn: add fn assignment) Simon Baatz
2012-06-18 22:10             ` Dove clock support Sebastian Hesselbarh
2012-06-19 19:32               ` Andrew Lunn
2012-06-19 20:42                 ` Simon Baatz
2012-06-19 20:43                   ` Marc Kleine-Budde
2012-06-19 20:55                   ` Sebastian Hesselbarh
2012-06-19 23:06                     ` Simon Baatz
2012-06-20  5:43                       ` Andrew Lunn
2012-06-20  5:51                   ` Andrew Lunn
2012-06-24 15:17                     ` Simon Baatz

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=4FDF91D1.1040301@googlemail.com \
    --to=sebastian.hesselbarth@googlemail.com \
    --cc=linux-arm-kernel@lists.infradead.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).