diff for duplicates of <4367690.gXaPoSdE52@diego> diff --git a/a/1.txt b/N1/1.txt index b69e6a2..368a657 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,46 +1,37 @@ Am Freitag, 5. August 2016, 21:23:14 schrieb Xing Zheng: > Hi Heiko, ->=20 -> On 2016=E5=B9=B408=E6=9C=8805=E6=97=A5 16:48, Heiko St=C3=BCbner wrot= -e: +> +> On 2016年08月05日 16:48, Heiko Stübner wrote: > > Hi Xing, -> >=20 +> > > > 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 w= -rote: +> >> 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= - the +> >>> +> >>> 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 arbitari= -ly. -> >>=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) tha= -t 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 int= -o the +> >> +> >>> 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 > >>> 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= - for +> >> There are many and various kinds resolution and needed frequencies for > >> external disaplay devices. For example, the DP needs: > >> 3840x2160 533250KHz > >> 3840x2160 297000KHz @@ -53,56 +44,40 @@ o the > >> 1280x1024 135000KHz > >> 1280x1024 108000KHz > >> ... and so on -> >>=20 -> >> There some frequencies must be allocated with frac mode. We separa= -te -> >> these frequencies that are only used for display (VPLL) from the g= -eneral -> >> 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 n= -ot -> >> interfere with each other. Because other PLLs don't need to assgin= - these +> >> +> >> There some frequencies must be allocated with frac mode. We separate +> >> 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 these > >> various frequencies with frac mode. -> >=20 -> > Hmm, you're adding 14 frequencies to that new table (4 or so of the= -m -> > duplicating existing frequencies). So even if the effective number = -of new -> > frequencies goes from now 10 to 20, I don't think walking that tabl= -e will +> > +> > 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. -> >=20 -> > After the patch introducing the automatic rate calculation, the rat= -e table +> > +> > After the patch introducing the automatic rate calculation, the rate table > > we need to walk, will even get smaller. -> >=20 -> > Other components might also profit from the updated standard freque= -ncies +> > +> > Other components might also profit from the updated standard frequencies > > with less jitter you're introducing here. -> >=20 -> > And of course there is also the possibility somebody might want to = -build -> > some rk3399 device without any graphics output at all [arm-server s= -eem to -> > be the new hype :-) ], so may want to use the vpll for something el= -se +> > +> > 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. -> >=20 -> > So I still don't see an argument why it needs to be a separate tabl= -e, as I -> > currently don't see a case were it will really hurt the other PLLs.= - -> >=20 -> >=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. +> > +> > > > Heiko ->=20 +> > Yes, sorry to this idea is not comprehensive. I will try to find a > better way. ->=20 +> > Thanks for your comments. :-) -as I said, to me just merging the new clock rates into the existing pll= - rate=20 +as I said, to me just merging the new clock rates into the existing pll rate array looks like it should work just fine :-) diff --git a/a/content_digest b/N1/content_digest index 6f9ba89..b62a3d2 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -19,47 +19,38 @@ "b\0" "Am Freitag, 5. August 2016, 21:23:14 schrieb Xing Zheng:\n" "> Hi Heiko,\n" - ">=20\n" - "> On 2016=E5=B9=B408=E6=9C=8805=E6=97=A5 16:48, Heiko St=C3=BCbner wrot=\n" - "e:\n" + "> \n" + "> On 2016\345\271\26408\346\234\21005\346\227\245 16:48, Heiko St\303\274bner wrote:\n" "> > Hi Xing,\n" - "> >=20\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 w=\n" - "rote:\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=\n" - " the\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 arbitari=\n" - "ly.\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) tha=\n" - "t are\n" - "> >>> present in both arrays but have different settings. As your patch=\n" - "\n" - "> >>> description says that these settings reduce clock jitter, wouldn'=\n" - "t the\n" - "> >>> general frequencies also profit from merging these new values int=\n" - "o the\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 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=\n" - " for\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" @@ -72,58 +63,42 @@ "> >> 1280x1024 135000KHz\n" "> >> 1280x1024 108000KHz\n" "> >> ... and so on\n" - "> >>=20\n" - "> >> There some frequencies must be allocated with frac mode. We separa=\n" - "te\n" - "> >> these frequencies that are only used for display (VPLL) from the g=\n" - "eneral\n" - "> >> rate table, and put them to be classified into a frac mode table, =\n" - "we can\n" - "> >> reduce the frequency of the query time, the two rate tables will n=\n" - "ot\n" - "> >> interfere with each other. Because other PLLs don't need to assgin=\n" - " these\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 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 these\n" "> >> various frequencies with frac mode.\n" - "> >=20\n" - "> > Hmm, you're adding 14 frequencies to that new table (4 or so of the=\n" - "m\n" - "> > duplicating existing frequencies). So even if the effective number =\n" - "of new\n" - "> > frequencies goes from now 10 to 20, I don't think walking that tabl=\n" - "e will\n" + "> > \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\n" "> > take an excessive time longer than now.\n" - "> >=20\n" - "> > After the patch introducing the automatic rate calculation, the rat=\n" - "e table\n" + "> > \n" + "> > After the patch introducing the automatic rate calculation, the rate table\n" "> > we need to walk, will even get smaller.\n" - "> >=20\n" - "> > Other components might also profit from the updated standard freque=\n" - "ncies\n" + "> > \n" + "> > Other components might also profit from the updated standard frequencies\n" "> > with less jitter you're introducing here.\n" - "> >=20\n" - "> > And of course there is also the possibility somebody might want to =\n" - "build\n" - "> > some rk3399 device without any graphics output at all [arm-server s=\n" - "eem to\n" - "> > be the new hype :-) ], so may want to use the vpll for something el=\n" - "se\n" + "> > \n" + "> > And of course there is also the possibility somebody might want to build\n" + "> > some rk3399 device without any graphics output at all [arm-server seem to\n" + "> > be the new hype :-) ], so may want to use the vpll for something else\n" "> > completely.\n" - "> >=20\n" - "> > So I still don't see an argument why it needs to be a separate tabl=\n" - "e, as I\n" - "> > currently don't see a case were it will really hurt the other PLLs.=\n" - "\n" - "> >=20\n" - "> >=20\n" + "> > \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\n" - ">=20\n" + "> \n" "> Yes, sorry to this idea is not comprehensive. I will try to find a\n" "> better way.\n" - ">=20\n" + "> \n" "> Thanks for your comments. :-)\n" "\n" - "as I said, to me just merging the new clock rates into the existing pll=\n" - " rate=20\n" + "as I said, to me just merging the new clock rates into the existing pll rate \n" array looks like it should work just fine :-) -a9e7b2adbbc385fa012acbdaf12e6fbbeb4dc6986f590194fc7eb35e3bac3fe9 +c017a1bc3d7f9307f476a67c0a15aa0d9f756764e614cef19c2f0aa1719cd6d8
diff --git a/a/1.txt b/N2/1.txt index b69e6a2..73c3b06 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -1,46 +1,37 @@ Am Freitag, 5. August 2016, 21:23:14 schrieb Xing Zheng: > Hi Heiko, ->=20 -> On 2016=E5=B9=B408=E6=9C=8805=E6=97=A5 16:48, Heiko St=C3=BCbner wrot= -e: +> +> On 2016?08?05? 16:48, Heiko St?bner wrote: > > Hi Xing, -> >=20 +> > > > 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 w= -rote: +> >> 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= - the +> >>> +> >>> 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 arbitari= -ly. -> >>=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) tha= -t 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 int= -o the +> >> +> >>> 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 > >>> 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= - for +> >> There are many and various kinds resolution and needed frequencies for > >> external disaplay devices. For example, the DP needs: > >> 3840x2160 533250KHz > >> 3840x2160 297000KHz @@ -53,56 +44,40 @@ o the > >> 1280x1024 135000KHz > >> 1280x1024 108000KHz > >> ... and so on -> >>=20 -> >> There some frequencies must be allocated with frac mode. We separa= -te -> >> these frequencies that are only used for display (VPLL) from the g= -eneral -> >> 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 n= -ot -> >> interfere with each other. Because other PLLs don't need to assgin= - these +> >> +> >> There some frequencies must be allocated with frac mode. We separate +> >> 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 these > >> various frequencies with frac mode. -> >=20 -> > Hmm, you're adding 14 frequencies to that new table (4 or so of the= -m -> > duplicating existing frequencies). So even if the effective number = -of new -> > frequencies goes from now 10 to 20, I don't think walking that tabl= -e will +> > +> > 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. -> >=20 -> > After the patch introducing the automatic rate calculation, the rat= -e table +> > +> > After the patch introducing the automatic rate calculation, the rate table > > we need to walk, will even get smaller. -> >=20 -> > Other components might also profit from the updated standard freque= -ncies +> > +> > Other components might also profit from the updated standard frequencies > > with less jitter you're introducing here. -> >=20 -> > And of course there is also the possibility somebody might want to = -build -> > some rk3399 device without any graphics output at all [arm-server s= -eem to -> > be the new hype :-) ], so may want to use the vpll for something el= -se +> > +> > 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. -> >=20 -> > So I still don't see an argument why it needs to be a separate tabl= -e, as I -> > currently don't see a case were it will really hurt the other PLLs.= - -> >=20 -> >=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. +> > +> > > > Heiko ->=20 +> > Yes, sorry to this idea is not comprehensive. I will try to find a > better way. ->=20 +> > Thanks for your comments. :-) -as I said, to me just merging the new clock rates into the existing pll= - rate=20 +as I said, to me just merging the new clock rates into the existing pll rate array looks like it should work just fine :-) diff --git a/a/content_digest b/N2/content_digest index 6f9ba89..6ac421d 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -1,65 +1,46 @@ "ref\01470122401-31934-1-git-send-email-zhengxing@rock-chips.com\0" "ref\01786762.HqNHoLusdi@diego\0" "ref\057A49342.3020309@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 15:26:54 +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" "Am Freitag, 5. August 2016, 21:23:14 schrieb Xing Zheng:\n" "> Hi Heiko,\n" - ">=20\n" - "> On 2016=E5=B9=B408=E6=9C=8805=E6=97=A5 16:48, Heiko St=C3=BCbner wrot=\n" - "e:\n" + "> \n" + "> On 2016?08?05? 16:48, Heiko St?bner wrote:\n" "> > Hi Xing,\n" - "> >=20\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 w=\n" - "rote:\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=\n" - " the\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 arbitari=\n" - "ly.\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) tha=\n" - "t are\n" - "> >>> present in both arrays but have different settings. As your patch=\n" - "\n" - "> >>> description says that these settings reduce clock jitter, wouldn'=\n" - "t the\n" - "> >>> general frequencies also profit from merging these new values int=\n" - "o the\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 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=\n" - " for\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" @@ -72,58 +53,42 @@ "> >> 1280x1024 135000KHz\n" "> >> 1280x1024 108000KHz\n" "> >> ... and so on\n" - "> >>=20\n" - "> >> There some frequencies must be allocated with frac mode. We separa=\n" - "te\n" - "> >> these frequencies that are only used for display (VPLL) from the g=\n" - "eneral\n" - "> >> rate table, and put them to be classified into a frac mode table, =\n" - "we can\n" - "> >> reduce the frequency of the query time, the two rate tables will n=\n" - "ot\n" - "> >> interfere with each other. Because other PLLs don't need to assgin=\n" - " these\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 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 these\n" "> >> various frequencies with frac mode.\n" - "> >=20\n" - "> > Hmm, you're adding 14 frequencies to that new table (4 or so of the=\n" - "m\n" - "> > duplicating existing frequencies). So even if the effective number =\n" - "of new\n" - "> > frequencies goes from now 10 to 20, I don't think walking that tabl=\n" - "e will\n" + "> > \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\n" "> > take an excessive time longer than now.\n" - "> >=20\n" - "> > After the patch introducing the automatic rate calculation, the rat=\n" - "e table\n" + "> > \n" + "> > After the patch introducing the automatic rate calculation, the rate table\n" "> > we need to walk, will even get smaller.\n" - "> >=20\n" - "> > Other components might also profit from the updated standard freque=\n" - "ncies\n" + "> > \n" + "> > Other components might also profit from the updated standard frequencies\n" "> > with less jitter you're introducing here.\n" - "> >=20\n" - "> > And of course there is also the possibility somebody might want to =\n" - "build\n" - "> > some rk3399 device without any graphics output at all [arm-server s=\n" - "eem to\n" - "> > be the new hype :-) ], so may want to use the vpll for something el=\n" - "se\n" + "> > \n" + "> > And of course there is also the possibility somebody might want to build\n" + "> > some rk3399 device without any graphics output at all [arm-server seem to\n" + "> > be the new hype :-) ], so may want to use the vpll for something else\n" "> > completely.\n" - "> >=20\n" - "> > So I still don't see an argument why it needs to be a separate tabl=\n" - "e, as I\n" - "> > currently don't see a case were it will really hurt the other PLLs.=\n" - "\n" - "> >=20\n" - "> >=20\n" + "> > \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\n" - ">=20\n" + "> \n" "> Yes, sorry to this idea is not comprehensive. I will try to find a\n" "> better way.\n" - ">=20\n" + "> \n" "> Thanks for your comments. :-)\n" "\n" - "as I said, to me just merging the new clock rates into the existing pll=\n" - " rate=20\n" + "as I said, to me just merging the new clock rates into the existing pll rate \n" array looks like it should work just fine :-) -a9e7b2adbbc385fa012acbdaf12e6fbbeb4dc6986f590194fc7eb35e3bac3fe9 +4607ef1a93e12c4e9dbca62089b97c5c0db0efc238e4433bf44539c02e02643d
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.