Minimal support for dm814x

Minimal support for dm814x

[Delio Brignoli]

Hello Tony,

We use dm814x in some of our products with a kernel based on version 2.6.37 modified by TI and are considering moving to a current kernel version. I recently saw this <http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/348444.html> and I?d like to try getting our board to boot as a first step and then take it from there.
We aim at eventually having remoteproc working (at least for the DSP) and to port fixes/features we added to our 2.6.37 based tree [2].

The temporary testing branch [1] mentioned in your original message is not longer available, does that mean I can just use the master branch of <https://git.kernel.org/cgit/linux/kernel/git/tmlind/linux-omap.git> for my tests? Which toolchain did you use to build your test kernel for the hp t410?

I wonder if there is anyone on this list already working on getting dm814x fully working or interested in cooperating towards this goal.

Thank you!
--
Delio

[1] <https://git.kernel.org/cgit/linux/kernel/git/tmlind/linux-omap.git/log/?h=tmp-testing-dm814x-2015-06-03>
[2] <https://github.com/audioscience/linux-omap3/tree/asi1230-upstream-tracking>

Re: Minimal support for dm814x

[Tony Lindgren]

Hi,

* Delio Brignoli <dbrignoli@audioscience.com> [151105 05:10]:
> Hello Tony,
> 
> We use dm814x in some of our products with a kernel based on version 2.6.37 modified by TI and are considering moving to a current kernel version. I recently saw this <http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/348444.html> and I’d like to try getting our board to boot as a first step and then take it from there.
> We aim at eventually having remoteproc working (at least for the DSP) and to port fixes/features we added to our 2.6.37 based tree [2].

OK great. Once you post some patches, I'm sure other people will start helping
with the effort too.

> The temporary testing branch [1] mentioned in your original message is not longer available, does that mean I can just use the master branch of <https://git.kernel.org/cgit/linux/kernel/git/tmlind/linux-omap.git> for my tests? Which toolchain did you use to build your test kernel for the hp t410?

It's now merged to mainline v4.3, so whatever is the current latest tagged
mainline kernel release (v4.3 currently) is the one to use from now on
natually :) 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.

> I wonder if there is anyone on this list already working on getting dm814x fully working or interested in cooperating towards this goal.

Yes for sure. I've also addes linux-omap list to Cc.

Regards,

Tony

> [1] <https://git.kernel.org/cgit/linux/kernel/git/tmlind/linux-omap.git/log/?h=tmp-testing-dm814x-2015-06-03>
> [2] <https://github.com/audioscience/linux-omap3/tree/asi1230-upstream-tracking>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Minimal support for dm814x

[Tony Lindgren]

Hi,

* Delio Brignoli <dbrignoli@audioscience.com> [151105 05:10]:
> Hello Tony,
> 
> We use dm814x in some of our products with a kernel based on version 2.6.37 modified by TI and are considering moving to a current kernel version. I recently saw this <http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/348444.html> and I?d like to try getting our board to boot as a first step and then take it from there.
> We aim at eventually having remoteproc working (at least for the DSP) and to port fixes/features we added to our 2.6.37 based tree [2].

OK great. Once you post some patches, I'm sure other people will start helping
with the effort too.

> The temporary testing branch [1] mentioned in your original message is not longer available, does that mean I can just use the master branch of <https://git.kernel.org/cgit/linux/kernel/git/tmlind/linux-omap.git> for my tests? Which toolchain did you use to build your test kernel for the hp t410?

It's now merged to mainline v4.3, so whatever is the current latest tagged
mainline kernel release (v4.3 currently) is the one to use from now on
natually :) 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.

> I wonder if there is anyone on this list already working on getting dm814x fully working or interested in cooperating towards this goal.

Yes for sure. I've also addes linux-omap list to Cc.

Regards,

Tony

> [1] <https://git.kernel.org/cgit/linux/kernel/git/tmlind/linux-omap.git/log/?h=tmp-testing-dm814x-2015-06-03>
> [2] <https://github.com/audioscience/linux-omap3/tree/asi1230-upstream-tracking>

Re: Minimal support for dm814x

[Matthijs van Duin]

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. :-)

Minimal support for dm814x

[Matthijs van Duin]

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. :-)

Re: Minimal support for dm814x

[Delio Brignoli]

Hi,

On 09 Nov 2015, at 16:06, Tony Lindgren <tony@atomide.com> wrote:
> It's now merged to mainline v4.3, so whatever is the current latest tagged
> mainline kernel release (v4.3 currently) is the one to use from now on
> natually :) 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.

ack, thanks for the status update.

Regards
--
Delio

Minimal support for dm814x

[Delio Brignoli]

Hi,

On 09 Nov 2015, at 16:06, Tony Lindgren <tony@atomide.com> wrote:
> It's now merged to mainline v4.3, so whatever is the current latest tagged
> mainline kernel release (v4.3 currently) is the one to use from now on
> natually :) 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.

ack, thanks for the status update.

Regards
--
Delio

Re: Minimal support for dm814x

[Delio Brignoli]

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

Minimal support for dm814x

[Delio Brignoli]

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

Re: Minimal support for dm814x

[Matthijs van Duin]

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.

Minimal support for dm814x

[Matthijs van Duin]

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.

Re: Minimal support for dm814x

[Tony Lindgren]

* 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

Minimal support for dm814x

[Tony Lindgren]

* 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

Re: Minimal support for dm814x

[Matthijs van Duin]

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

Minimal support for dm814x

[Matthijs van Duin]

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

Re: Minimal support for dm814x

[Tony Lindgren]

* 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

Minimal support for dm814x

[Tony Lindgren]

* 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

Re: Minimal support for dm814x

[Matthijs van Duin]

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

Minimal support for dm814x

[Matthijs van Duin]

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

Re: Minimal support for dm814x

[Matthijs van Duin]

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.

Minimal support for dm814x

[Matthijs van Duin]

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.

Re: Minimal support for dm814x

[Tony Lindgren]

* 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

Minimal support for dm814x

[Tony Lindgren]

* 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

Re: Minimal support for dm814x

[Tony Lindgren]

* 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

Minimal support for dm814x

[Tony Lindgren]

* 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

Re: Minimal support for dm814x

[Matthijs van Duin]

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

Minimal support for dm814x

[Matthijs van Duin]

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

Re: Minimal support for dm814x

[Delio Brignoli]

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

Minimal support for dm814x

[Delio Brignoli]

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

Re: Minimal support for dm814x

[Matthijs van Duin]

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

Minimal support for dm814x

[Matthijs van Duin]

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

Re: Minimal support for dm814x

[Delio Brignoli]

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

Minimal support for dm814x

[Delio Brignoli]

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