* Minimal support for dm814x
@ 2015-11-10 10:23 ` Delio Brignoli
0 siblings, 0 replies; 33+ messages in thread
From: Delio Brignoli @ 2015-11-10 10:23 UTC (permalink / raw)
To: linux-arm-kernel
On 10 Nov 2015, at 09:50, Matthijs van Duin <matthijsvanduin@gmail.com> wrote:
> On 9 November 2015 at 16:06, Tony Lindgren <tony@atomide.com> wrote:
>> The PLL support is still missing, so it relies on the bootloader
>> configured PLL values for now. I'm hoping to post PLL support patches over
>> next few weeks and then we can have that and more devices working for v4.5.
>
> Ah, yes, configuring a DPLL-LJ is fun.. figuring out how to write the
> desired ratio as M/(M2*(1+N)) while simultaneously satisfying all
> constraints on M, N, M2, refclk, and dco. :-)
Yes, indeed. We have the additional requirement of being able to adjust the frequency (by a relatively small amount) without loss of lock. Recalculating the DCO mode and M,N,M2 from scratch each time based on the target frequency, like was done in the 2.6.37 based tree from TI was not acceptable, so we try to change m2 first to see if we can reach the target frequency and fall back to recalculate parameters from scratch if that fails.
BTW, are you aware of section 2.1.2 of ?TMS320DM814x DaVinci Digital Media Processors Silicon Revisions 3.0, 2.1?? <http://www.ti.com/lit/er/sprz343c/sprz343c.pdf>
Regards
?
Delio
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Minimal support for dm814x
2015-11-10 10:23 ` Delio Brignoli
@ 2015-11-10 10:44 ` Matthijs van Duin
-1 siblings, 0 replies; 33+ messages in thread
From: Matthijs van Duin @ 2015-11-10 10:44 UTC (permalink / raw)
To: Delio Brignoli; +Cc: Tony Lindgren, linux-omap, linux-arm-kernel
On 10 November 2015 at 11:23, Delio Brignoli <dbrignoli@audioscience.com> wrote:
> are you aware of section 2.1.2 of ...
I am. It seems that the digital PLLs tend to produce an asymmetrical
clock in general hence you need an even postdivider to get a 50% duty
cycle. DPLL-S however already has an implicit /2 divider integrated,
and a few peripherals seem to be fine with an asymmetrical clock (e.g.
apparently the USB subsystem which is clocked by PLL_USB / 5).
In the most recent SoCs they included a "DC corrector" in some PLLs to
be able to symmetrize the clock without the need for postdivision.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Minimal support for dm814x
@ 2015-11-10 10:44 ` Matthijs van Duin
0 siblings, 0 replies; 33+ messages in thread
From: Matthijs van Duin @ 2015-11-10 10:44 UTC (permalink / raw)
To: linux-arm-kernel
On 10 November 2015 at 11:23, Delio Brignoli <dbrignoli@audioscience.com> wrote:
> are you aware of section 2.1.2 of ...
I am. It seems that the digital PLLs tend to produce an asymmetrical
clock in general hence you need an even postdivider to get a 50% duty
cycle. DPLL-S however already has an implicit /2 divider integrated,
and a few peripherals seem to be fine with an asymmetrical clock (e.g.
apparently the USB subsystem which is clocked by PLL_USB / 5).
In the most recent SoCs they included a "DC corrector" in some PLLs to
be able to symmetrize the clock without the need for postdivision.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Minimal support for dm814x
2015-11-10 10:23 ` Delio Brignoli
@ 2015-11-11 17:40 ` Tony Lindgren
-1 siblings, 0 replies; 33+ messages in thread
From: Tony Lindgren @ 2015-11-11 17:40 UTC (permalink / raw)
To: Delio Brignoli; +Cc: linux-omap, linux-arm-kernel, Matthijs van Duin
* Delio Brignoli <dbrignoli@audioscience.com> [151110 02:24]:
> On 10 Nov 2015, at 09:50, Matthijs van Duin <matthijsvanduin@gmail.com> wrote:
> > On 9 November 2015 at 16:06, Tony Lindgren <tony@atomide.com> wrote:
> >> The PLL support is still missing, so it relies on the bootloader
> >> configured PLL values for now. I'm hoping to post PLL support patches over
> >> next few weeks and then we can have that and more devices working for v4.5.
> >
> > Ah, yes, configuring a DPLL-LJ is fun.. figuring out how to write the
> > desired ratio as M/(M2*(1+N)) while simultaneously satisfying all
> > constraints on M, N, M2, refclk, and dco. :-)
>
> Yes, indeed. We have the additional requirement of being able to adjust the frequency (by a relatively small amount) without loss of lock. Recalculating the DCO mode and M,N,M2 from scratch each time based on the target frequency, like was done in the 2.6.37 based tree from TI was not acceptable, so we try to change m2 first to see if we can reach the target frequency and fall back to recalculate parameters from scratch if that fails.
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.
> BTW, are you aware of section 2.1.2 of “TMS320DM814x DaVinci Digital Media Processors Silicon Revisions 3.0, 2.1”? <http://www.ti.com/lit/er/sprz343c/sprz343c.pdf>
OK good to know :)
Tony
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 33+ messages in thread
* Minimal support for dm814x
@ 2015-11-11 17:40 ` Tony Lindgren
0 siblings, 0 replies; 33+ messages in thread
From: Tony Lindgren @ 2015-11-11 17:40 UTC (permalink / raw)
To: linux-arm-kernel
* Delio Brignoli <dbrignoli@audioscience.com> [151110 02:24]:
> On 10 Nov 2015, at 09:50, Matthijs van Duin <matthijsvanduin@gmail.com> wrote:
> > On 9 November 2015 at 16:06, Tony Lindgren <tony@atomide.com> wrote:
> >> The PLL support is still missing, so it relies on the bootloader
> >> configured PLL values for now. I'm hoping to post PLL support patches over
> >> next few weeks and then we can have that and more devices working for v4.5.
> >
> > Ah, yes, configuring a DPLL-LJ is fun.. figuring out how to write the
> > desired ratio as M/(M2*(1+N)) while simultaneously satisfying all
> > constraints on M, N, M2, refclk, and dco. :-)
>
> Yes, indeed. We have the additional requirement of being able to adjust the frequency (by a relatively small amount) without loss of lock. Recalculating the DCO mode and M,N,M2 from scratch each time based on the target frequency, like was done in the 2.6.37 based tree from TI was not acceptable, so we try to change m2 first to see if we can reach the target frequency and fall back to recalculate parameters from scratch if that fails.
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.
> BTW, are you aware of section 2.1.2 of ?TMS320DM814x DaVinci Digital Media Processors Silicon Revisions 3.0, 2.1?? <http://www.ti.com/lit/er/sprz343c/sprz343c.pdf>
OK good to know :)
Tony
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Minimal support for dm814x
2015-11-11 17:40 ` Tony Lindgren
@ 2015-11-12 9:20 ` Matthijs van Duin
-1 siblings, 0 replies; 33+ messages in thread
From: Matthijs van Duin @ 2015-11-12 9:20 UTC (permalink / raw)
To: Tony Lindgren; +Cc: linux-omap, linux-arm-kernel, Delio Brignoli
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.
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.
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.)
Matthijs
^ permalink raw reply [flat|nested] 33+ messages in thread
* Minimal support for dm814x
@ 2015-11-12 9:20 ` Matthijs van Duin
0 siblings, 0 replies; 33+ messages in thread
From: Matthijs van Duin @ 2015-11-12 9:20 UTC (permalink / raw)
To: linux-arm-kernel
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.
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.
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.)
Matthijs
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Minimal support for dm814x
2015-11-12 9:20 ` Matthijs van Duin
@ 2015-11-12 17:41 ` Tony Lindgren
-1 siblings, 0 replies; 33+ messages in thread
From: Tony Lindgren @ 2015-11-12 17:41 UTC (permalink / raw)
To: Matthijs van Duin; +Cc: linux-omap, linux-arm-kernel, Delio Brignoli
* 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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Minimal support for dm814x
@ 2015-11-12 17:41 ` Tony Lindgren
0 siblings, 0 replies; 33+ messages in thread
From: Tony Lindgren @ 2015-11-12 17:41 UTC (permalink / raw)
To: linux-arm-kernel
* 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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Minimal support for dm814x
2015-11-12 17:41 ` Tony Lindgren
@ 2015-11-13 7:14 ` Matthijs van Duin
-1 siblings, 0 replies; 33+ messages in thread
From: Matthijs van Duin @ 2015-11-13 7:14 UTC (permalink / raw)
To: Tony Lindgren; +Cc: linux-omap, linux-arm-kernel, Delio Brignoli
On 12 November 2015 at 18:41, Tony Lindgren <tony@atomide.com> wrote:
> Does the old TI kernel tree driver correctly handle that?
It seems this is how the old TI kernel handles them: http://goo.gl/3I3OEL
^ permalink raw reply [flat|nested] 33+ messages in thread
* Minimal support for dm814x
@ 2015-11-13 7:14 ` Matthijs van Duin
0 siblings, 0 replies; 33+ messages in thread
From: Matthijs van Duin @ 2015-11-13 7:14 UTC (permalink / raw)
To: linux-arm-kernel
On 12 November 2015 at 18:41, Tony Lindgren <tony@atomide.com> wrote:
> Does the old TI kernel tree driver correctly handle that?
It seems this is how the old TI kernel handles them: http://goo.gl/3I3OEL
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Minimal support for dm814x
2015-11-13 7:14 ` Matthijs van Duin
@ 2015-11-13 10:59 ` Matthijs van Duin
-1 siblings, 0 replies; 33+ messages in thread
From: Matthijs van Duin @ 2015-11-13 10:59 UTC (permalink / raw)
To: Tony Lindgren; +Cc: linux-omap, linux-arm-kernel, Delio Brignoli
On 13 November 2015 at 08:14, Matthijs van Duin
<matthijsvanduin@gmail.com> wrote:
> It seems this is how the old TI kernel handles them: http://goo.gl/3I3OEL
Never mind, wasn't paying attention and managed to overlook that
google had found me the u-boot tree instead of the kernel tree I
intended to search for. -.-
Sorry about that, when I find a moment I'll locate the correct files
and check those.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Minimal support for dm814x
@ 2015-11-13 10:59 ` Matthijs van Duin
0 siblings, 0 replies; 33+ messages in thread
From: Matthijs van Duin @ 2015-11-13 10:59 UTC (permalink / raw)
To: linux-arm-kernel
On 13 November 2015 at 08:14, Matthijs van Duin
<matthijsvanduin@gmail.com> wrote:
> It seems this is how the old TI kernel handles them: http://goo.gl/3I3OEL
Never mind, wasn't paying attention and managed to overlook that
google had found me the u-boot tree instead of the kernel tree I
intended to search for. -.-
Sorry about that, when I find a moment I'll locate the correct files
and check those.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Minimal support for dm814x
2015-11-13 10:59 ` Matthijs van Duin
@ 2015-11-13 14:52 ` Tony Lindgren
-1 siblings, 0 replies; 33+ messages in thread
From: Tony Lindgren @ 2015-11-13 14:52 UTC (permalink / raw)
To: Matthijs van Duin; +Cc: linux-omap, linux-arm-kernel, Delio Brignoli
* Matthijs van Duin <matthijsvanduin@gmail.com> [151113 03:00]:
> On 13 November 2015 at 08:14, Matthijs van Duin
> <matthijsvanduin@gmail.com> wrote:
> > It seems this is how the old TI kernel handles them: http://goo.gl/3I3OEL
>
> Never mind, wasn't paying attention and managed to overlook that
> google had found me the u-boot tree instead of the kernel tree I
> intended to search for. -.-
>
> Sorry about that, when I find a moment I'll locate the correct files
> and check those.
I think this is the most recent TI git repo for dm81xx changes:
http://arago-project.org/git/projects/?p=linux-omap3.git;a=summary
git://arago-project.org/git/projects/linux-omap3.git
Regards,
Tony
^ permalink raw reply [flat|nested] 33+ messages in thread
* Minimal support for dm814x
@ 2015-11-13 14:52 ` Tony Lindgren
0 siblings, 0 replies; 33+ messages in thread
From: Tony Lindgren @ 2015-11-13 14:52 UTC (permalink / raw)
To: linux-arm-kernel
* Matthijs van Duin <matthijsvanduin@gmail.com> [151113 03:00]:
> On 13 November 2015 at 08:14, Matthijs van Duin
> <matthijsvanduin@gmail.com> wrote:
> > It seems this is how the old TI kernel handles them: http://goo.gl/3I3OEL
>
> Never mind, wasn't paying attention and managed to overlook that
> google had found me the u-boot tree instead of the kernel tree I
> intended to search for. -.-
>
> Sorry about that, when I find a moment I'll locate the correct files
> and check those.
I think this is the most recent TI git repo for dm81xx changes:
http://arago-project.org/git/projects/?p=linux-omap3.git;a=summary
git://arago-project.org/git/projects/linux-omap3.git
Regards,
Tony
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Minimal support for dm814x
2015-11-13 14:52 ` Tony Lindgren
@ 2015-11-13 14:57 ` Tony Lindgren
-1 siblings, 0 replies; 33+ messages in thread
From: Tony Lindgren @ 2015-11-13 14:57 UTC (permalink / raw)
To: Matthijs van Duin; +Cc: linux-omap, linux-arm-kernel, Delio Brignoli
* Tony Lindgren <tony@atomide.com> [151113 06:53]:
> * Matthijs van Duin <matthijsvanduin@gmail.com> [151113 03:00]:
> > On 13 November 2015 at 08:14, Matthijs van Duin
> > <matthijsvanduin@gmail.com> wrote:
> > > It seems this is how the old TI kernel handles them: http://goo.gl/3I3OEL
> >
> > Never mind, wasn't paying attention and managed to overlook that
> > google had found me the u-boot tree instead of the kernel tree I
> > intended to search for. -.-
> >
> > Sorry about that, when I find a moment I'll locate the correct files
> > and check those.
>
> I think this is the most recent TI git repo for dm81xx changes:
>
> http://arago-project.org/git/projects/?p=linux-omap3.git;a=summary
> git://arago-project.org/git/projects/linux-omap3.git
Oh and the adpll code is under arch/arm/mach-omap2 in that kernel:
http://arago-project.org/git/projects/?p=linux-omap3.git;a=blob;f=arch/arm/mach-omap2/adpll_ti814x.c;h=27877268f3598f7a253b578674208ab406c44524;hb=HEAD
Regards,
Tony
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Minimal support for dm814x
2015-11-13 14:52 ` Tony Lindgren
@ 2015-11-18 5:22 ` Matthijs van Duin
-1 siblings, 0 replies; 33+ messages in thread
From: Matthijs van Duin @ 2015-11-18 5:22 UTC (permalink / raw)
To: Tony Lindgren; +Cc: linux-omap, linux-arm-kernel, Delio Brignoli
On 13 November 2015 at 15:52, Tony Lindgren <tony@atomide.com> wrote:
> I think this is the most recent TI git repo for dm81xx changes:
>
> http://arago-project.org/git/projects/?p=linux-omap3.git;a=summary
Yeah, although I usually prefer to look at the
linux-ipnc-rdk-dm81xx.git and linux-dvr-rdk-dm81xx.git that descend
from it since they include some fixes that the last TI kernel doesn't.
(However they may also include patches specific to the ipnc/dvr
hardware, so some caution is needed.)
Since arago can be sluggish I just mirrored all three branches on github:
https://github.com/dutchanddutch/ti81xx-linux
I've also fixed an obnoxious commit in the ipnc-rdk which changed all
files to mode 755, since this made comparisons rather unpleasant.
The PLL code looks pretty mediocre to me. In particular, they make no
effort whatsoever to configure an exact ratio. It seems their
algorithm uses whatever predivider was already programmed, selects the
minimum postdivider that puts the DCO clock within valid range, and
then approximates the dco/refclk ratio using the fractional
multiplier.
This works in principle, but both minimizing the DCO and (often
needlessly) using the fractional multiplier seem like recipes to
maximize the clock jitter. Mind you, I don't know how much jitter
we're talking about here, I don't recall having seen specs about this.
I also have some concerns about the correctness of the implementation.
I haven't analyzed it in any detail, but repeated occurrences of
expressions of the form (unsigned long long)( foo * bar ) make me
doubt whether the author realizes this is utterly pointless and will,
for 32-bit arguments, still perform a 32-bit multiplication.
Matthijs
^ permalink raw reply [flat|nested] 33+ messages in thread
* Minimal support for dm814x
@ 2015-11-18 5:22 ` Matthijs van Duin
0 siblings, 0 replies; 33+ messages in thread
From: Matthijs van Duin @ 2015-11-18 5:22 UTC (permalink / raw)
To: linux-arm-kernel
On 13 November 2015 at 15:52, Tony Lindgren <tony@atomide.com> wrote:
> I think this is the most recent TI git repo for dm81xx changes:
>
> http://arago-project.org/git/projects/?p=linux-omap3.git;a=summary
Yeah, although I usually prefer to look at the
linux-ipnc-rdk-dm81xx.git and linux-dvr-rdk-dm81xx.git that descend
from it since they include some fixes that the last TI kernel doesn't.
(However they may also include patches specific to the ipnc/dvr
hardware, so some caution is needed.)
Since arago can be sluggish I just mirrored all three branches on github:
https://github.com/dutchanddutch/ti81xx-linux
I've also fixed an obnoxious commit in the ipnc-rdk which changed all
files to mode 755, since this made comparisons rather unpleasant.
The PLL code looks pretty mediocre to me. In particular, they make no
effort whatsoever to configure an exact ratio. It seems their
algorithm uses whatever predivider was already programmed, selects the
minimum postdivider that puts the DCO clock within valid range, and
then approximates the dco/refclk ratio using the fractional
multiplier.
This works in principle, but both minimizing the DCO and (often
needlessly) using the fractional multiplier seem like recipes to
maximize the clock jitter. Mind you, I don't know how much jitter
we're talking about here, I don't recall having seen specs about this.
I also have some concerns about the correctness of the implementation.
I haven't analyzed it in any detail, but repeated occurrences of
expressions of the form (unsigned long long)( foo * bar ) make me
doubt whether the author realizes this is utterly pointless and will,
for 32-bit arguments, still perform a 32-bit multiplication.
Matthijs
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Minimal support for dm814x
2015-11-18 5:22 ` Matthijs van Duin
@ 2015-11-18 8:26 ` Delio Brignoli
-1 siblings, 0 replies; 33+ messages in thread
From: Delio Brignoli @ 2015-11-18 8:26 UTC (permalink / raw)
To: Matthijs van Duin; +Cc: Tony Lindgren, linux-omap, linux-arm-kernel
On 18 Nov 2015, at 06:22, Matthijs van Duin <matthijsvanduin@gmail.com> wrote:
> The PLL code looks pretty mediocre to me. In particular, they make no
> effort whatsoever to configure an exact ratio. It seems their
> algorithm uses whatever pre divider was already programmed,
I believe the implementors assumed the bootloader was setting up the PLL, its adjustment may have been an afterthought added in order to support PTP.
> This works in principle, but both minimizing the DCO and (often
> needlessly) using the fractional multiplier seem like recipes to
> maximize the clock jitter. Mind you, I don't know how much jitter
> we’re talking about here, I don't recall having seen specs about this.
We haven’t seen any specs either but testing shows that changing DCO mode causes the PLL to lose lock at least temporarily.
—
Delio
^ permalink raw reply [flat|nested] 33+ messages in thread
* Minimal support for dm814x
@ 2015-11-18 8:26 ` Delio Brignoli
0 siblings, 0 replies; 33+ messages in thread
From: Delio Brignoli @ 2015-11-18 8:26 UTC (permalink / raw)
To: linux-arm-kernel
On 18 Nov 2015, at 06:22, Matthijs van Duin <matthijsvanduin@gmail.com> wrote:
> The PLL code looks pretty mediocre to me. In particular, they make no
> effort whatsoever to configure an exact ratio. It seems their
> algorithm uses whatever pre divider was already programmed,
I believe the implementors assumed the bootloader was setting up the PLL, its adjustment may have been an afterthought added in order to support PTP.
> This works in principle, but both minimizing the DCO and (often
> needlessly) using the fractional multiplier seem like recipes to
> maximize the clock jitter. Mind you, I don't know how much jitter
> we?re talking about here, I don't recall having seen specs about this.
We haven?t seen any specs either but testing shows that changing DCO mode causes the PLL to lose lock at least temporarily.
?
Delio
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Minimal support for dm814x
2015-11-18 8:26 ` Delio Brignoli
@ 2015-11-18 10:01 ` Matthijs van Duin
-1 siblings, 0 replies; 33+ messages in thread
From: Matthijs van Duin @ 2015-11-18 10:01 UTC (permalink / raw)
To: Delio Brignoli; +Cc: Tony Lindgren, linux-omap, linux-arm-kernel
On 18 November 2015 at 09:26, Delio Brignoli <dbrignoli@audioscience.com> wrote:
>> This works in principle, but both minimizing the DCO and (often
>> needlessly) using the fractional multiplier seem like recipes to
>> maximize the clock jitter. Mind you, I don't know how much jitter
>> we’re talking about here, I don't recall having seen specs about this.
>
> We haven’t seen any specs either but testing shows that changing DCO mode causes
> the PLL to lose lock at least temporarily.
Losing lock on reconfiguration is entirely a separate matter from
clock jitter. The fractional multiplier works by essentially by
alternating between the nearest integer multiplier values. This will
be smoothed out by the loop filter, but it's not going to vanish.
To put this in perspective, some docs (I can't immediately find which
one) warned that when using the fractional multiplier of DPLLS, its
value needed to be at least 100 to ensure max 2.5% jitter. To put this
in perspective, if I grab the datasheet of an audio DAC I find:
Although the architecture of the PCM4104 is tolerant to
phase jitter on the system clock, it is recommended that
the user provide a low jitter clock (100 picoseconds or less)
for optimal performance.
For a typical 24.576 MHz audio system clock that means max 0.25%
jitter. Whoops :P
Now DPLLLJ will presumably do better, but without actual specs the
safe option is to avoid the fractional multiplier altogether.
Matthijs
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 33+ messages in thread
* Minimal support for dm814x
@ 2015-11-18 10:01 ` Matthijs van Duin
0 siblings, 0 replies; 33+ messages in thread
From: Matthijs van Duin @ 2015-11-18 10:01 UTC (permalink / raw)
To: linux-arm-kernel
On 18 November 2015 at 09:26, Delio Brignoli <dbrignoli@audioscience.com> wrote:
>> This works in principle, but both minimizing the DCO and (often
>> needlessly) using the fractional multiplier seem like recipes to
>> maximize the clock jitter. Mind you, I don't know how much jitter
>> we?re talking about here, I don't recall having seen specs about this.
>
> We haven?t seen any specs either but testing shows that changing DCO mode causes
> the PLL to lose lock at least temporarily.
Losing lock on reconfiguration is entirely a separate matter from
clock jitter. The fractional multiplier works by essentially by
alternating between the nearest integer multiplier values. This will
be smoothed out by the loop filter, but it's not going to vanish.
To put this in perspective, some docs (I can't immediately find which
one) warned that when using the fractional multiplier of DPLLS, its
value needed to be at least 100 to ensure max 2.5% jitter. To put this
in perspective, if I grab the datasheet of an audio DAC I find:
Although the architecture of the PCM4104 is tolerant to
phase jitter on the system clock, it is recommended that
the user provide a low jitter clock (100 picoseconds or less)
for optimal performance.
For a typical 24.576 MHz audio system clock that means max 0.25%
jitter. Whoops :P
Now DPLLLJ will presumably do better, but without actual specs the
safe option is to avoid the fractional multiplier altogether.
Matthijs
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Minimal support for dm814x
2015-11-18 10:01 ` Matthijs van Duin
@ 2015-11-18 11:09 ` Delio Brignoli
-1 siblings, 0 replies; 33+ messages in thread
From: Delio Brignoli @ 2015-11-18 11:09 UTC (permalink / raw)
To: Matthijs van Duin; +Cc: Tony Lindgren, linux-omap, linux-arm-kernel
On 18 Nov 2015, at 11:01, Matthijs van Duin <matthijsvanduin@gmail.com> wrote:
> On 18 November 2015 at 09:26, Delio Brignoli <dbrignoli@audioscience.com> wrote:
>>> This works in principle, but both minimizing the DCO and (often
>>> needlessly) using the fractional multiplier seem like recipes to
>>> maximize the clock jitter. Mind you, I don't know how much jitter
>>> we’re talking about here, I don't recall having seen specs about this.
>>
>> We haven’t seen any specs either but testing shows that changing DCO mode causes
>> the PLL to lose lock at least temporarily.
>
> Losing lock on reconfiguration is entirely a separate matter from
> clock jitter.
Sure, I just wanted to report a case in which the implementation you mention does something which may be undesirable.
> The fractional multiplier works by essentially by
> alternating between the nearest integer multiplier values. This will
> be smoothed out by the loop filter, but it’s not going to vanish.
[…]
> Now DPLLLJ will presumably do better, but without actual specs the
> safe option is to avoid the fractional multiplier altogether.
Still FYI, using adpll_ti814x.c from the linux-omap3 tree from the Arago project (i.e. the one you are talking about) hacked to prefer searching for neighbouring m2 values to DCO switching works OK for us (i.e. resulting jitter is low enough for our audio applications).
—
Delio
^ permalink raw reply [flat|nested] 33+ messages in thread
* Minimal support for dm814x
@ 2015-11-18 11:09 ` Delio Brignoli
0 siblings, 0 replies; 33+ messages in thread
From: Delio Brignoli @ 2015-11-18 11:09 UTC (permalink / raw)
To: linux-arm-kernel
On 18 Nov 2015, at 11:01, Matthijs van Duin <matthijsvanduin@gmail.com> wrote:
> On 18 November 2015 at 09:26, Delio Brignoli <dbrignoli@audioscience.com> wrote:
>>> This works in principle, but both minimizing the DCO and (often
>>> needlessly) using the fractional multiplier seem like recipes to
>>> maximize the clock jitter. Mind you, I don't know how much jitter
>>> we?re talking about here, I don't recall having seen specs about this.
>>
>> We haven?t seen any specs either but testing shows that changing DCO mode causes
>> the PLL to lose lock at least temporarily.
>
> Losing lock on reconfiguration is entirely a separate matter from
> clock jitter.
Sure, I just wanted to report a case in which the implementation you mention does something which may be undesirable.
> The fractional multiplier works by essentially by
> alternating between the nearest integer multiplier values. This will
> be smoothed out by the loop filter, but it?s not going to vanish.
[?]
> Now DPLLLJ will presumably do better, but without actual specs the
> safe option is to avoid the fractional multiplier altogether.
Still FYI, using adpll_ti814x.c from the linux-omap3 tree from the Arago project (i.e. the one you are talking about) hacked to prefer searching for neighbouring m2 values to DCO switching works OK for us (i.e. resulting jitter is low enough for our audio applications).
?
Delio
^ permalink raw reply [flat|nested] 33+ messages in thread