diff for duplicates of <1786762.HqNHoLusdi@diego> diff --git a/a/1.txt b/N1/1.txt index 8944833..1d6c6bb 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,40 +1,33 @@ Hi Xing, Am Freitag, 5. August 2016, 10:26:57 schrieb Xing Zheng: -> On 2016=E5=B9=B408=E6=9C=8805=E6=97=A5 03:19, Heiko St=C3=BCbner wrot= -e: +> On 2016年08月05日 03:19, Heiko Stübner wrote: > > Am Dienstag, 2. August 2016, 15:22:59 schrieb Xing Zheng: > >> We need to support various display resolutions for external > >> display devices like HDMI/DP, the frac mode can help us to > >> acquire almost any frequencies, and need higher VCOs to reduce > >> clock jitters. -> >>=20 +> >> > >> Signed-off-by: Xing Zheng<zhengxing@rock-chips.com> -> >=20 -> > why does this need to be a separate rate array and cannot live in t= -he +> > +> > why does this need to be a separate rate array and cannot live in the > > general pll rate array? -> >=20 -> > The plls are general purpose, so we shouldn't limit them arbitarily= -. ->=20 +> > +> > The plls are general purpose, so we shouldn't limit them arbitarily. +> > Yes, I understand your mean. :-) ->=20 -> > I currently only see some frequencies (594MHz, 297MHz, 54MHz) that = -are +> +> > I currently only see some frequencies (594MHz, 297MHz, 54MHz) that are > > present in both arrays but have different settings. As your patch -> > description says that these settings reduce clock jitter, wouldn't = -the -> > general frequencies also profit from merging these new values into = -the +> > description says that these settings reduce clock jitter, wouldn't the +> > general frequencies also profit from merging these new values into the > > general rate array? ->=20 +> > and here are some of our ideas: ->=20 +> > "WIth the frac mode and higher VCO to reduce clock jitters" that > suggestion is from IC designer. -> There are many and various kinds resolution and needed frequencies fo= -r +> There are many and various kinds resolution and needed frequencies for > external disaplay devices. For example, the DP needs: > 3840x2160 533250KHz > 3840x2160 297000KHz @@ -47,42 +40,30 @@ r > 1280x1024 135000KHz > 1280x1024 108000KHz > ... and so on ->=20 +> > There some frequencies must be allocated with frac mode. We separate -> these frequencies that are only used for display (VPLL) from the gene= -ral -> rate table, and put them to be classified into a frac mode table, we = -can +> these frequencies that are only used for display (VPLL) from the general +> rate table, and put them to be classified into a frac mode table, we can > reduce the frequency of the query time, the two rate tables will not -> interfere with each other. Because other PLLs don't need to assgin th= -ese +> interfere with each other. Because other PLLs don't need to assgin these > various frequencies with frac mode. -Hmm, you're adding 14 frequencies to that new table (4 or so of them=20= - -duplicating existing frequencies). So even if the effective number of n= -ew=20 -frequencies goes from now 10 to 20, I don't think walking that table wi= -ll take=20 +Hmm, you're adding 14 frequencies to that new table (4 or so of them +duplicating existing frequencies). So even if the effective number of new +frequencies goes from now 10 to 20, I don't think walking that table will take an excessive time longer than now. -After the patch introducing the automatic rate calculation, the rate ta= -ble we=20 +After the patch introducing the automatic rate calculation, the rate table we need to walk, will even get smaller. -Other components might also profit from the updated standard frequencie= -s with=20 +Other components might also profit from the updated standard frequencies with less jitter you're introducing here. -And of course there is also the possibility somebody might want to buil= -d some=20 -rk3399 device without any graphics output at all [arm-server seem to be= - the=20 -new hype :-) ], so may want to use the vpll for something else complete= -ly. +And of course there is also the possibility somebody might want to build some +rk3399 device without any graphics output at all [arm-server seem to be the +new hype :-) ], so may want to use the vpll for something else completely. -So I still don't see an argument why it needs to be a separate table, a= -s I=20 +So I still don't see an argument why it needs to be a separate table, as I currently don't see a case were it will really hurt the other PLLs. diff --git a/a/content_digest b/N1/content_digest index d2eeda9..9795de4 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -20,40 +20,33 @@ "Hi Xing,\n" "\n" "Am Freitag, 5. August 2016, 10:26:57 schrieb Xing Zheng:\n" - "> On 2016=E5=B9=B408=E6=9C=8805=E6=97=A5 03:19, Heiko St=C3=BCbner wrot=\n" - "e:\n" + "> On 2016\345\271\26408\346\234\21005\346\227\245 03:19, Heiko St\303\274bner wrote:\n" "> > Am Dienstag, 2. August 2016, 15:22:59 schrieb Xing Zheng:\n" "> >> We need to support various display resolutions for external\n" "> >> display devices like HDMI/DP, the frac mode can help us to\n" "> >> acquire almost any frequencies, and need higher VCOs to reduce\n" "> >> clock jitters.\n" - "> >>=20\n" + "> >> \n" "> >> Signed-off-by: Xing Zheng<zhengxing@rock-chips.com>\n" - "> >=20\n" - "> > why does this need to be a separate rate array and cannot live in t=\n" - "he\n" + "> > \n" + "> > why does this need to be a separate rate array and cannot live in the\n" "> > general pll rate array?\n" - "> >=20\n" - "> > The plls are general purpose, so we shouldn't limit them arbitarily=\n" - ".\n" - ">=20\n" + "> > \n" + "> > The plls are general purpose, so we shouldn't limit them arbitarily.\n" + "> \n" "> Yes, I understand your mean. :-)\n" - ">=20\n" - "> > I currently only see some frequencies (594MHz, 297MHz, 54MHz) that =\n" - "are\n" + "> \n" + "> > I currently only see some frequencies (594MHz, 297MHz, 54MHz) that are\n" "> > present in both arrays but have different settings. As your patch\n" - "> > description says that these settings reduce clock jitter, wouldn't =\n" - "the\n" - "> > general frequencies also profit from merging these new values into =\n" - "the\n" + "> > description says that these settings reduce clock jitter, wouldn't the\n" + "> > general frequencies also profit from merging these new values into the\n" "> > general rate array?\n" - ">=20\n" + "> \n" "> and here are some of our ideas:\n" - ">=20\n" + "> \n" "> \"WIth the frac mode and higher VCO to reduce clock jitters\" that\n" "> suggestion is from IC designer.\n" - "> There are many and various kinds resolution and needed frequencies fo=\n" - "r\n" + "> There are many and various kinds resolution and needed frequencies for\n" "> external disaplay devices. For example, the DP needs:\n" "> 3840x2160 533250KHz\n" "> 3840x2160 297000KHz\n" @@ -66,45 +59,33 @@ "> 1280x1024 135000KHz\n" "> 1280x1024 108000KHz\n" "> ... and so on\n" - ">=20\n" + "> \n" "> There some frequencies must be allocated with frac mode. We separate\n" - "> these frequencies that are only used for display (VPLL) from the gene=\n" - "ral\n" - "> rate table, and put them to be classified into a frac mode table, we =\n" - "can\n" + "> these frequencies that are only used for display (VPLL) from the general\n" + "> rate table, and put them to be classified into a frac mode table, we can\n" "> reduce the frequency of the query time, the two rate tables will not\n" - "> interfere with each other. Because other PLLs don't need to assgin th=\n" - "ese\n" + "> interfere with each other. Because other PLLs don't need to assgin these\n" "> various frequencies with frac mode.\n" "\n" - "Hmm, you're adding 14 frequencies to that new table (4 or so of them=20=\n" - "\n" - "duplicating existing frequencies). So even if the effective number of n=\n" - "ew=20\n" - "frequencies goes from now 10 to 20, I don't think walking that table wi=\n" - "ll take=20\n" + "Hmm, you're adding 14 frequencies to that new table (4 or so of them \n" + "duplicating existing frequencies). So even if the effective number of new \n" + "frequencies goes from now 10 to 20, I don't think walking that table will take \n" "an excessive time longer than now.\n" "\n" - "After the patch introducing the automatic rate calculation, the rate ta=\n" - "ble we=20\n" + "After the patch introducing the automatic rate calculation, the rate table we \n" "need to walk, will even get smaller.\n" "\n" - "Other components might also profit from the updated standard frequencie=\n" - "s with=20\n" + "Other components might also profit from the updated standard frequencies with \n" "less jitter you're introducing here.\n" "\n" - "And of course there is also the possibility somebody might want to buil=\n" - "d some=20\n" - "rk3399 device without any graphics output at all [arm-server seem to be=\n" - " the=20\n" - "new hype :-) ], so may want to use the vpll for something else complete=\n" - "ly.\n" + "And of course there is also the possibility somebody might want to build some \n" + "rk3399 device without any graphics output at all [arm-server seem to be the \n" + "new hype :-) ], so may want to use the vpll for something else completely.\n" "\n" - "So I still don't see an argument why it needs to be a separate table, a=\n" - "s I=20\n" + "So I still don't see an argument why it needs to be a separate table, as I \n" "currently don't see a case were it will really hurt the other PLLs.\n" "\n" "\n" Heiko -27c58e639dae638078b7e1bac91496a7cb78938c36a94206d03ac9092535746c +9bb27954dbeef6e5a78e3efdb833a6db805a186f3088cd7699597874f7c9ab0a
diff --git a/a/1.txt b/N2/1.txt index 8944833..a5b5085 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -1,40 +1,33 @@ Hi Xing, Am Freitag, 5. August 2016, 10:26:57 schrieb Xing Zheng: -> On 2016=E5=B9=B408=E6=9C=8805=E6=97=A5 03:19, Heiko St=C3=BCbner wrot= -e: +> On 2016?08?05? 03:19, Heiko St?bner wrote: > > Am Dienstag, 2. August 2016, 15:22:59 schrieb Xing Zheng: > >> We need to support various display resolutions for external > >> display devices like HDMI/DP, the frac mode can help us to > >> acquire almost any frequencies, and need higher VCOs to reduce > >> clock jitters. -> >>=20 +> >> > >> Signed-off-by: Xing Zheng<zhengxing@rock-chips.com> -> >=20 -> > why does this need to be a separate rate array and cannot live in t= -he +> > +> > why does this need to be a separate rate array and cannot live in the > > general pll rate array? -> >=20 -> > The plls are general purpose, so we shouldn't limit them arbitarily= -. ->=20 +> > +> > The plls are general purpose, so we shouldn't limit them arbitarily. +> > Yes, I understand your mean. :-) ->=20 -> > I currently only see some frequencies (594MHz, 297MHz, 54MHz) that = -are +> +> > I currently only see some frequencies (594MHz, 297MHz, 54MHz) that are > > present in both arrays but have different settings. As your patch -> > description says that these settings reduce clock jitter, wouldn't = -the -> > general frequencies also profit from merging these new values into = -the +> > description says that these settings reduce clock jitter, wouldn't the +> > general frequencies also profit from merging these new values into the > > general rate array? ->=20 +> > and here are some of our ideas: ->=20 +> > "WIth the frac mode and higher VCO to reduce clock jitters" that > suggestion is from IC designer. -> There are many and various kinds resolution and needed frequencies fo= -r +> There are many and various kinds resolution and needed frequencies for > external disaplay devices. For example, the DP needs: > 3840x2160 533250KHz > 3840x2160 297000KHz @@ -47,42 +40,30 @@ r > 1280x1024 135000KHz > 1280x1024 108000KHz > ... and so on ->=20 +> > There some frequencies must be allocated with frac mode. We separate -> these frequencies that are only used for display (VPLL) from the gene= -ral -> rate table, and put them to be classified into a frac mode table, we = -can +> these frequencies that are only used for display (VPLL) from the general +> rate table, and put them to be classified into a frac mode table, we can > reduce the frequency of the query time, the two rate tables will not -> interfere with each other. Because other PLLs don't need to assgin th= -ese +> interfere with each other. Because other PLLs don't need to assgin these > various frequencies with frac mode. -Hmm, you're adding 14 frequencies to that new table (4 or so of them=20= - -duplicating existing frequencies). So even if the effective number of n= -ew=20 -frequencies goes from now 10 to 20, I don't think walking that table wi= -ll take=20 +Hmm, you're adding 14 frequencies to that new table (4 or so of them +duplicating existing frequencies). So even if the effective number of new +frequencies goes from now 10 to 20, I don't think walking that table will take an excessive time longer than now. -After the patch introducing the automatic rate calculation, the rate ta= -ble we=20 +After the patch introducing the automatic rate calculation, the rate table we need to walk, will even get smaller. -Other components might also profit from the updated standard frequencie= -s with=20 +Other components might also profit from the updated standard frequencies with less jitter you're introducing here. -And of course there is also the possibility somebody might want to buil= -d some=20 -rk3399 device without any graphics output at all [arm-server seem to be= - the=20 -new hype :-) ], so may want to use the vpll for something else complete= -ly. +And of course there is also the possibility somebody might want to build some +rk3399 device without any graphics output at all [arm-server seem to be the +new hype :-) ], so may want to use the vpll for something else completely. -So I still don't see an argument why it needs to be a separate table, a= -s I=20 +So I still don't see an argument why it needs to be a separate table, as I currently don't see a case were it will really hurt the other PLLs. diff --git a/a/content_digest b/N2/content_digest index d2eeda9..15c9b10 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -1,59 +1,42 @@ "ref\01470122401-31934-1-git-send-email-zhengxing@rock-chips.com\0" "ref\012790025.3tRiQgk9GG@diego\0" "ref\057A3F971.6000009@rock-chips.com\0" - "From\0Heiko St\303\274bner <heiko@sntech.de>\0" - "Subject\0Re: [PATCH v3 7/7] clk: rockchip: rk3399: Add support frac mode frequencies\0" + "From\0heiko@sntech.de (Heiko St\303\274bner)\0" + "Subject\0[PATCH v3 7/7] clk: rockchip: rk3399: Add support frac mode frequencies\0" "Date\0Fri, 05 Aug 2016 10:48:38 +0200\0" - "To\0Xing Zheng <zhengxing@rock-chips.com>\0" - "Cc\0mturquette@baylibre.com" - sboyd@codeaurora.org - linux-clk@vger.kernel.org - linux-arm-kernel@lists.infradead.org - linux-rockchip@lists.infradead.org - linux-kernel@vger.kernel.org - dianders@chromium.org - briannorris@chromium.org - huangtao@rock-chips.com - " zhangqing@rock-chips.com\0" + "To\0linux-arm-kernel@lists.infradead.org\0" "\00:1\0" "b\0" "Hi Xing,\n" "\n" "Am Freitag, 5. August 2016, 10:26:57 schrieb Xing Zheng:\n" - "> On 2016=E5=B9=B408=E6=9C=8805=E6=97=A5 03:19, Heiko St=C3=BCbner wrot=\n" - "e:\n" + "> On 2016?08?05? 03:19, Heiko St?bner wrote:\n" "> > Am Dienstag, 2. August 2016, 15:22:59 schrieb Xing Zheng:\n" "> >> We need to support various display resolutions for external\n" "> >> display devices like HDMI/DP, the frac mode can help us to\n" "> >> acquire almost any frequencies, and need higher VCOs to reduce\n" "> >> clock jitters.\n" - "> >>=20\n" + "> >> \n" "> >> Signed-off-by: Xing Zheng<zhengxing@rock-chips.com>\n" - "> >=20\n" - "> > why does this need to be a separate rate array and cannot live in t=\n" - "he\n" + "> > \n" + "> > why does this need to be a separate rate array and cannot live in the\n" "> > general pll rate array?\n" - "> >=20\n" - "> > The plls are general purpose, so we shouldn't limit them arbitarily=\n" - ".\n" - ">=20\n" + "> > \n" + "> > The plls are general purpose, so we shouldn't limit them arbitarily.\n" + "> \n" "> Yes, I understand your mean. :-)\n" - ">=20\n" - "> > I currently only see some frequencies (594MHz, 297MHz, 54MHz) that =\n" - "are\n" + "> \n" + "> > I currently only see some frequencies (594MHz, 297MHz, 54MHz) that are\n" "> > present in both arrays but have different settings. As your patch\n" - "> > description says that these settings reduce clock jitter, wouldn't =\n" - "the\n" - "> > general frequencies also profit from merging these new values into =\n" - "the\n" + "> > description says that these settings reduce clock jitter, wouldn't the\n" + "> > general frequencies also profit from merging these new values into the\n" "> > general rate array?\n" - ">=20\n" + "> \n" "> and here are some of our ideas:\n" - ">=20\n" + "> \n" "> \"WIth the frac mode and higher VCO to reduce clock jitters\" that\n" "> suggestion is from IC designer.\n" - "> There are many and various kinds resolution and needed frequencies fo=\n" - "r\n" + "> There are many and various kinds resolution and needed frequencies for\n" "> external disaplay devices. For example, the DP needs:\n" "> 3840x2160 533250KHz\n" "> 3840x2160 297000KHz\n" @@ -66,45 +49,33 @@ "> 1280x1024 135000KHz\n" "> 1280x1024 108000KHz\n" "> ... and so on\n" - ">=20\n" + "> \n" "> There some frequencies must be allocated with frac mode. We separate\n" - "> these frequencies that are only used for display (VPLL) from the gene=\n" - "ral\n" - "> rate table, and put them to be classified into a frac mode table, we =\n" - "can\n" + "> these frequencies that are only used for display (VPLL) from the general\n" + "> rate table, and put them to be classified into a frac mode table, we can\n" "> reduce the frequency of the query time, the two rate tables will not\n" - "> interfere with each other. Because other PLLs don't need to assgin th=\n" - "ese\n" + "> interfere with each other. Because other PLLs don't need to assgin these\n" "> various frequencies with frac mode.\n" "\n" - "Hmm, you're adding 14 frequencies to that new table (4 or so of them=20=\n" - "\n" - "duplicating existing frequencies). So even if the effective number of n=\n" - "ew=20\n" - "frequencies goes from now 10 to 20, I don't think walking that table wi=\n" - "ll take=20\n" + "Hmm, you're adding 14 frequencies to that new table (4 or so of them \n" + "duplicating existing frequencies). So even if the effective number of new \n" + "frequencies goes from now 10 to 20, I don't think walking that table will take \n" "an excessive time longer than now.\n" "\n" - "After the patch introducing the automatic rate calculation, the rate ta=\n" - "ble we=20\n" + "After the patch introducing the automatic rate calculation, the rate table we \n" "need to walk, will even get smaller.\n" "\n" - "Other components might also profit from the updated standard frequencie=\n" - "s with=20\n" + "Other components might also profit from the updated standard frequencies with \n" "less jitter you're introducing here.\n" "\n" - "And of course there is also the possibility somebody might want to buil=\n" - "d some=20\n" - "rk3399 device without any graphics output at all [arm-server seem to be=\n" - " the=20\n" - "new hype :-) ], so may want to use the vpll for something else complete=\n" - "ly.\n" + "And of course there is also the possibility somebody might want to build some \n" + "rk3399 device without any graphics output at all [arm-server seem to be the \n" + "new hype :-) ], so may want to use the vpll for something else completely.\n" "\n" - "So I still don't see an argument why it needs to be a separate table, a=\n" - "s I=20\n" + "So I still don't see an argument why it needs to be a separate table, as I \n" "currently don't see a case were it will really hurt the other PLLs.\n" "\n" "\n" Heiko -27c58e639dae638078b7e1bac91496a7cb78938c36a94206d03ac9092535746c +2467a00d9ebe3ec7fea3c3bd2e2dc3b1a6ebd2523c543c362bd47b2a52cad4b8
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.