Minimal support for dm814x

Tony Lindgren tony at atomide.com
Thu Nov 12 09:41:55 PST 2015


* Matthijs van Duin <matthijsvanduin at gmail.com> [151112 01:21]:
> On 11 November 2015 at 18:40, Tony Lindgren <tony at 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



More information about the linux-arm-kernel mailing list