Hi,
We found a possible regression issue (not seen in kernel 4.7-stable), which has to do with the new NXP commit ba7f4f557eb67ee21c979c8539dc1886f5d5341c when we did a DP test (1920x1080@60) with clock source PLL5.
The DP desired pixel clock (148.5MHz that is calculated from the input of PLL output frequency) would be correct again when we reverted this commit.
Could you please help check if the commit has the side effect since it would have impacts on our on-going project when it requires moving from kernel 4.7 to kernel 4.8 or newer version?
Please check the following URL for the details
https://www.dropbox.com/s/7wc5jdp8unlsiob/possible_regression_for_clk_imx_correct_VL_PLL_rate_formula.pdf?dl=0
Thank you
Cheers,
Ken Lin
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-----Original Message-----
From: Ken.Lin
Sent: Thursday, October 6, 2016 4:21 PM
To: '[email protected]'; '[email protected]'; '[email protected]'; '[email protected]'
Cc: '[email protected]'; '[email protected]'; '[email protected]'; Peter.Stretz; Peter.Chiang; Akshay Bhat
Subject: The possible regression in kernel 4.8 - clk: imx: correct AV PLL rate formula
Hi,
We found a possible regression issue (not seen in kernel 4.7-stable), which has to do with the new NXP commit ba7f4f557eb67ee21c979c8539dc1886f5d5341c when we did a DP test (1920x1080@60) with clock source PLL5.
The DP desired pixel clock (148.5MHz that is calculated from the input of PLL output frequency) would be correct again when we reverted this commit.
Could you please help check if the commit has the side effect since it would have impacts on our on-going project when it requires moving from kernel 4.7 to kernel 4.8 or newer version?
Please check the following URL for the details
https://www.dropbox.com/s/7wc5jdp8unlsiob/possible_regression_for_clk_imx_correct_VL_PLL_rate_formula.pdf?dl=0
Thank you
Cheers,
Ken Lin
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Hi Fabio,
> -----Original Message-----
> From: Fabio Estevam [mailto:[email protected]]
> Sent: Thursday, October 6, 2016 4:38 PM
> To: Ken.Lin
> Cc: [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; linux-
> [email protected]; [email protected]; Peter.Stretz; Peter.Chiang;
> Akshay Bhat; Jason Moss; [email protected]
> Subject: Re: The possible regression in kernel 4.8 - clk: imx: correct AV PLL rate
> formula
>
> Hi Ken,
>
> On Thu, Oct 6, 2016 at 8:26 PM, Ken.Lin <[email protected]> wrote:
> > Hi,
> >
> > We found a possible regression issue (not seen in kernel 4.7-stable), which has
> to do with the new NXP commit ba7f4f557eb67ee21c979c8539dc1886f5d5341c
> when we did a DP test (1920x1080@60) with clock source PLL5.
> > The DP desired pixel clock (148.5MHz that is calculated from the input of PLL
> output frequency) would be correct again when we reverted this commit.
> > Could you please help check if the commit has the side effect since it would
> have impacts on our on-going project when it requires moving from kernel 4.7
> to kernel 4.8 or newer version?
> >
> > Please check the following URL for the details
> > https://www.dropbox.com/s/7wc5jdp8unlsiob/possible_regression_for_clk_
> > imx_correct_VL_PLL_rate_formula.pdf?dl=0
>
> Do these patches from Emil fix the issue?
>
> http://www.spinics.net/lists/arm-kernel/msg535204.html
>
> and
>
> http://www.spinics.net/lists/arm-kernel/msg535203.html
>
> Thanks
With the patches applied, the pixel clock (148500000 required for 1920x1080@60) is correct as we checked in kernel 4.7 and the actual measurement result looked good as we expected.
I think the patches should fix the issue.
Ref: /sys/kernel/debug/clk/clk_summary
pll5 1 1 1039500000 0 0
pll5_bypass 1 1 1039500000 0 0
pll5_video 1 1 1039500000 0 0
pll5_post_div 1 1 519750000 0 0
pll5_video_div 2 2 519750000 0 0
ipu2_di1_pre_sel 0 0 519750000 0 0
ipu2_di1_pre 0 0 173250000 0 0
ipu2_di1_sel 0 0 173250000 0 0
ipu2_di1 0 0 173250000 0 0
ipu2_di0_pre_sel 0 0 519750000 0 0
ipu2_di0_pre 0 0 173250000 0 0
ldb_di1_sel 1 1 519750000 0 0
ldb_di1_div_3_5 1 1 148500000 0 0
ldb_di1_podf 1 1 148500000 0 0
ldb_di1 2 2 148500000 0 0
ipu2_di0_sel 1 1 148500000 0 0
ipu2_di0 1 1 148500000 0 0
ldb_di0_sel 1 1 519750000 0 0
ldb_di0_div_3_5 1 1 148500000 0 0
ldb_di0_podf 1 1 148500000 0 0
ldb_di0 1 1 148500000 0 0
Ref: kernel debug messages
[ 113.848959] imx-ipuv3-crtc imx-ipuv3-crtc.6: ipu_crtc_mode_set_nofb: mode->hdisplay: 1920
[ 113.857201] imx-ipuv3-crtc imx-ipuv3-crtc.6: ipu_crtc_mode_set_nofb: mode->vdisplay: 1080
[ 113.865421] imx-ipuv3-crtc imx-ipuv3-crtc.6: ipu_crtc_mode_set_nofb: attached to encoder types 0x8
[ 113.874483] imx-ipuv3 2800000.ipu: disp 0: panel size = 1920 x 1080
[ 113.880803] imx-ipuv3 2800000.ipu: Clocks: IPU 264000000Hz DI 75833334Hz Needed 148500000Hz
[ 113.889252] imx-ipuv3 2800000.ipu: Want 148500000Hz IPU 264000000Hz DI 75833334Hz using DI, 75833334Hz
[ 113.898768] imx-ldb 2000000.aips-bus:ldb@020e0008: imx_ldb_set_clock: now: 227500000 want: 519750000
[ 113.908018] imx-ldb 2000000.aips-bus:ldb@020e0008: imx_ldb_set_clock after: 519750000
[ 113.915886] imx-ldb 2000000.aips-bus:ldb@020e0008: imx_ldb_set_clock: now: 148500000 want: 148500000
[ 113.925050] imx-ldb 2000000.aips-bus:ldb@020e0008: imx_ldb_set_clock after: 148500000
[ 113.932928] imx-ldb 2000000.aips-bus:ldb@020e0008: imx_ldb_set_clock: now: 519750000 want: 519750000
[ 113.942096] imx-ldb 2000000.aips-bus:ldb@020e0008: imx_ldb_set_clock after: 519750000
[ 113.949938] imx-ldb 2000000.aips-bus:ldb@020e0008: imx_ldb_set_clock: now: 148500000 want: 148500000
[ 113.959104] imx-ldb 2000000.aips-bus:ldb@020e0008: imx_ldb_set_clock after: 148500000
>
> --
> This message has been scanned for viruses and dangerous content by
> MailScanner, and is believed to be clean.
Thank you
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Hi Ken,
On Tue, Oct 11, 2016 at 2:49 PM, Ken.Lin <[email protected]> wrote:
> With the patches applied, the pixel clock (148500000 required for 1920x1080@60) is correct as we checked in kernel 4.7 and the actual measurement result looked good as we expected.
> I think the patches should fix the issue.
That's good news. Thanks for testing.
Emil is working on a v3 version of the patch series.
Emil,
Please add Ken Lin on Cc when you submit v3.
On Tue, Oct 11, 2016 at 3:00 PM, Fabio Estevam <[email protected]> wrote:
> Hi Ken,
>
> On Tue, Oct 11, 2016 at 2:49 PM, Ken.Lin <[email protected]> wrote:
>
>> With the patches applied, the pixel clock (148500000 required for 1920x1080@60) is correct as we checked in kernel 4.7 and the actual measurement result looked good as we expected.
>> I think the patches should fix the issue.
>
> That's good news. Thanks for testing.
>
> Emil is working on a v3 version of the patch series.
>
> Emil,
>
> Please add Ken Lin on Cc when you submit v3.
And what will be done regarding 4.8? Is the faulty change to be
reverted or this patches will be backported?
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750