All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: Matthijs van Duin <matthijsvanduin@gmail.com>
Cc: "linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Delio Brignoli <dbrignoli@audioscience.com>
Subject: Re: Minimal support for dm814x
Date: Thu, 12 Nov 2015 09:41:55 -0800	[thread overview]
Message-ID: <20151112174155.GM3218@atomide.com> (raw)
In-Reply-To: <CAALWOA_dEtajQBLrXesQ2bRCDf-1Dzg_tJw_=yAmaO=T3=KMZQ@mail.gmail.com>

* Matthijs van Duin <matthijsvanduin@gmail.com> [151112 01:21]:
> On 11 November 2015 at 18:40, Tony Lindgren <tony@atomide.com> wrote:
> > Well we do first try to set the rate using the divider only at least for
> > drivers/clk/ti/fapll.c used on dm816x. I'm thinking about doing a similar
> > driver for the dm814x adpll where we have a PLL and separate output clocks
> > in a single driver as the PLL and output control registers are all mixed in.
> 
> Well the output control *is* part of the PLL block. More importantly,
> due to the constraints of DPLL-LJ you may need to consider the
> postdivider and PLL config together to produce the desired output
> frequency.

Yup.

> Note BTW that afaik exactly the same two DPLL types are used in nearly
> all TI SoCs (with exception of DM816x, and some enhancements have been
> made in the latest SoCs), but since the PLLs themselves only have
> wires sticking out, the register interface can vary significantly
> between devices. Most of them also wrap a layer of abstraction around
> them, while it seems the DM814x just directly wired all available
> signals into registers, no added sugar.
> 
> Another difference is that normally nearly all DPLLs are DPLL-S (aka
> "type A") and often only one is -LJ (aka "type B"), while the
> situation is reversed on the DM814x which has only one instance of
> DPLL-S and 12 instances of DPLL-LJ. Also unusual is that none have
> more than one output divider (no HSDIVIDER blocks present) and only
> two (HDMI and USB) make direct use of the undivided dco clock. This
> means that, with those two exceptions, you do have complete freedom in
> configuring the PLL for the needs of its single output clock.

OK

> It does however also mean you can't really escape dealing with the
> fussiness of DPLL-LJ like you can on other devices (e.g. the am335x
> has only one, which is configured correctly by ROM and can't be
> reconfigured without breaking USB.)

Does the old TI kernel tree driver correctly handle that?

Regards,

Tony

WARNING: multiple messages have this Message-ID (diff)
From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: Minimal support for dm814x
Date: Thu, 12 Nov 2015 09:41:55 -0800	[thread overview]
Message-ID: <20151112174155.GM3218@atomide.com> (raw)
In-Reply-To: <CAALWOA_dEtajQBLrXesQ2bRCDf-1Dzg_tJw_=yAmaO=T3=KMZQ@mail.gmail.com>

* Matthijs van Duin <matthijsvanduin@gmail.com> [151112 01:21]:
> On 11 November 2015 at 18:40, Tony Lindgren <tony@atomide.com> wrote:
> > Well we do first try to set the rate using the divider only at least for
> > drivers/clk/ti/fapll.c used on dm816x. I'm thinking about doing a similar
> > driver for the dm814x adpll where we have a PLL and separate output clocks
> > in a single driver as the PLL and output control registers are all mixed in.
> 
> Well the output control *is* part of the PLL block. More importantly,
> due to the constraints of DPLL-LJ you may need to consider the
> postdivider and PLL config together to produce the desired output
> frequency.

Yup.

> Note BTW that afaik exactly the same two DPLL types are used in nearly
> all TI SoCs (with exception of DM816x, and some enhancements have been
> made in the latest SoCs), but since the PLLs themselves only have
> wires sticking out, the register interface can vary significantly
> between devices. Most of them also wrap a layer of abstraction around
> them, while it seems the DM814x just directly wired all available
> signals into registers, no added sugar.
> 
> Another difference is that normally nearly all DPLLs are DPLL-S (aka
> "type A") and often only one is -LJ (aka "type B"), while the
> situation is reversed on the DM814x which has only one instance of
> DPLL-S and 12 instances of DPLL-LJ. Also unusual is that none have
> more than one output divider (no HSDIVIDER blocks present) and only
> two (HDMI and USB) make direct use of the undivided dco clock. This
> means that, with those two exceptions, you do have complete freedom in
> configuring the PLL for the needs of its single output clock.

OK

> It does however also mean you can't really escape dealing with the
> fussiness of DPLL-LJ like you can on other devices (e.g. the am335x
> has only one, which is configured correctly by ROM and can't be
> reconfigured without breaking USB.)

Does the old TI kernel tree driver correctly handle that?

Regards,

Tony

  reply	other threads:[~2015-11-12 17:41 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-05 13:08 Minimal support for dm814x Delio Brignoli
2015-11-09 15:06 ` Tony Lindgren
2015-11-09 15:06   ` Tony Lindgren
2015-11-10  8:50   ` Matthijs van Duin
2015-11-10  8:50     ` Matthijs van Duin
2015-11-10 10:23     ` Delio Brignoli
2015-11-10 10:23       ` Delio Brignoli
2015-11-10 10:44       ` Matthijs van Duin
2015-11-10 10:44         ` Matthijs van Duin
2015-11-11 17:40       ` Tony Lindgren
2015-11-11 17:40         ` Tony Lindgren
2015-11-12  9:20         ` Matthijs van Duin
2015-11-12  9:20           ` Matthijs van Duin
2015-11-12 17:41           ` Tony Lindgren [this message]
2015-11-12 17:41             ` Tony Lindgren
2015-11-13  7:14             ` Matthijs van Duin
2015-11-13  7:14               ` Matthijs van Duin
2015-11-13 10:59               ` Matthijs van Duin
2015-11-13 10:59                 ` Matthijs van Duin
2015-11-13 14:52                 ` Tony Lindgren
2015-11-13 14:52                   ` Tony Lindgren
2015-11-13 14:57                   ` Tony Lindgren
2015-11-13 14:57                     ` Tony Lindgren
2015-11-18  5:22                   ` Matthijs van Duin
2015-11-18  5:22                     ` Matthijs van Duin
2015-11-18  8:26                     ` Delio Brignoli
2015-11-18  8:26                       ` Delio Brignoli
2015-11-18 10:01                       ` Matthijs van Duin
2015-11-18 10:01                         ` Matthijs van Duin
2015-11-18 11:09                         ` Delio Brignoli
2015-11-18 11:09                           ` Delio Brignoli
2015-11-10 10:05   ` Delio Brignoli
2015-11-10 10:05     ` Delio Brignoli

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=20151112174155.GM3218@atomide.com \
    --to=tony@atomide.com \
    --cc=dbrignoli@audioscience.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=matthijsvanduin@gmail.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.