From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Keeping Subject: Re: [PATCH v2 19/26] drm/rockchip: dw-mipi-dsi: improve PLL configuration Date: Mon, 23 Jan 2017 12:49:25 +0000 Message-ID: <20170123124925.4fa10fc2.john@metanate.com> References: <20170121163128.22240-1-john@metanate.com> <20170121163128.22240-20-john@metanate.com> <58855EAE.2010704@rock-chips.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <58855EAE.2010704@rock-chips.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Chris Zhong Cc: linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, dri-devel@lists.freedesktop.org List-Id: linux-rockchip.vger.kernel.org SGkgQ2hyaXMsCgpPbiBNb24sIDIzIEphbiAyMDE3IDA5OjM4OjU0ICswODAwLCBDaHJpcyBaaG9u ZyB3cm90ZToKPiBPbiAwMS8yMi8yMDE3IDEyOjMxIEFNLCBKb2huIEtlZXBpbmcgd3JvdGU6Cj4g PiBUaGUgbXVsdGlwbGljYXRpb24gcmF0aW8gZm9yIHRoZSBQTEwgaXMgcmVxdWlyZWQgdG8gYmUg ZXZlbiBkdWUgdG8gdGhlCj4gPiB1c2Ugb2YgYSAiYnkgMiBwcmUtc2NhbGVyIi4gIEN1cnJlbnRs eSB3ZSBhcmUgbGlrZWx5IHRvIGVuZCB1cCB3aXRoIGFuCj4gPiBvZGQgbXVsdGlwbGllciBldmVu IHRob3VnaCB0aGVyZSBpcyBhbiBlcXVpdmFsZW50IHNldCBvZiBwYXJhbWV0ZXJzIHdpdGgKPiA+ IGFuIGV2ZW4gbXVsdGlwbGllci4KPiA+Cj4gPiBGb3IgZXhhbXBsZSwgdXNpbmcgdGhlIDMyNE1I eiBiaXQgcmF0ZSB3aXRoIGEgcmVmZXJlbmNlIGNsb2NrIG9mIDI0TUh6Cj4gPiB3ZSBlbmQgdXAg d2l0aCBNID0gMjcsIE4gPSAyIHdoZXJlYXMgdGhlIGV4YW1wbGUgaW4gdGhlIFBIWSBkYXRhYm9v awo+ID4gZ2l2ZXMgTSA9IDU0LCBOID0gNCBmb3IgdGhpcyBiaXQgcmF0ZSBhbmQgcmVmZXJlbmNl IGNsb2NrLgo+ID4KPiA+IEJ5IHdhbGtpbmcgZG93biB0aHJvdWdoIHRoZSBhdmFpbGFibGUgbXVs dGlwbGllciBpbnN0ZWFkIG9mIHVwIHdlIGFyZQo+ID4gbW9yZSBsaWtlbHkgdG8gaGl0IGFuIGV2 ZW4gbXVsdGlwbGllci4gIFdpdGggdGhlIGFib3ZlIGV4YW1wbGUgd2UgZG8gbm93Cj4gPiBnZXQg TSA9IDU0LCBOID0gNCBhcyBnaXZlbiBieSB0aGUgZGF0YWJvb2suCj4gPgo+ID4gV2hpbGUgZG9p bmcgdGhpcywgY2hhbmdlIHRoZSBsb29wIGxpbWl0cyB0byBlbmNvZGUgdGhlIGFjdHVhbCBsaW1p dHMgb24KPiA+IHRoZSBkaXZpc29yLCB3aGljaCBhcmU6Cj4gPgo+ID4gCTQwTUh6ID49IChwbGxy ZWYgLyBOKSA+PSA1TUh6ICAKPiAKPiBUaGlzIGZvcm11bGEgaXMgbGltaXQgZm9yIE4sIGJ1dCB3 ZSBzdGlsbCBjYW4gbm90IGd1YXJhbnRlZSB0byBnZXQgYW4gCj4gZXZlbiBNLgo+IERvIHlvdSB0 aGluayB3ZSBzaG91bGQgZG8gYSBjaGVjayBmb3IgTS4KPiBzdWNoIGFzOgo+IGlmIChtICUgMikK PiAgICAgIGNvbnRpbnVlOwo+IC4uLgo+ICAgICAgZm9yIChpID0gcGxscmVmIC8gNTsgaSA+IChw bGxyZWYgLyA0MCk7IGktLSkgewo+ICAgICAgICAgIHByZSA9IHBsbHJlZiAvIGk7Cj4gICAgICAg ICAgaWYgKCh0bXAgPiAodGFyZ2V0X21icHMgJSBwcmUpKSAmJiAodGFyZ2V0X21icHMgLyBwcmUg PCA1MTIpKSB7Cj4gICAgICAgICAgICAgIHRtcCA9IHRhcmdldF9tYnBzICUgcHJlOwo+ICAgICAg ICAgICAgICBuID0gaTsKPiAgICAgICAgICAgICAgbSA9IHRhcmdldF9tYnBzIC8gcHJlOwo+ICAg ICAgICAgICAgICBpZiAobSAlIDIpCj4gICAgICAgICAgICAgICAgICBjb250aW51ZTsKPiAgICAg ICAgICB9Cj4gICAgICAgICAgaWYgKHRtcCA9PSAwKQo+ICAgICAgICAgICAgICBicmVhazsKPiAg ICAgIH0KPiAKPiBpZiAobSAlIDIpCj4gICAgICBtKys7Cj4gCj4gICAgICBkc2ktPmxhbmVfbWJw cyA9IHBsbHJlZiAvIG4gKiBtOwo+ICAgICAgZHNpLT5pbnB1dF9kaXYgPSBuOwo+ICAgICAgZHNp LT5mZWVkYmFja19kaXYgPSBtOwoKWWVzLCBJIGFncmVlIHRoYXQgdGhlcmUgc2hvdWxkIGJlIGEg Y2hlY2sgZm9yIE0sIGJ1dCBJJ20gbm90IHN1cmUgaWYKdGhlIHZlcnNpb24gYWJvdmUgaXMgc3Vm ZmljaWVudC4gIFRoZSAibSAlIDIiIGNoZWNrIGluc2lkZSB0aGUgbG9vcAptZWFucyB0aGF0IHdl IGRvbid0IGJyZWFrIGltbWVkaWF0ZWx5IHdoZW4gdG1wPTAgYnV0IHRoZW4gd2UgYXJlCmd1YXJh bnRlZWQgdG8gYnJlYWsgbmV4dCB0aW1lIHdpdGhvdXQgaGF2aW5nIG1vZGlmaWVkIG4sIG0gYmVj YXVzZSBub3cKdG1wPTAgc28gInRtcCA+ICh0YXJnZXRfbWJwcyAlIHByZSkiIGlzIGFsd2F5cyBm YWxzZSBhbmQgd2UganVzdCBoaXQgdGhlCiJpZiAodG1wID09IDApIGJyZWFrIiBjYXNlIG5leHQg dGltZS4KCkdpdmVuIHRoYXQgdGhlIGRlc2NlbmRpbmcgbG9vcCBhbHJlYWR5IG1lYW5zIHRoYXQg aWYgd2UgY2FuIGhpdCAidG1wIgpleGFjdGx5IHdlIGFyZSBtb3JlIGxpa2VseSB0byBkbyBzbyB3 aXRoIGEgYmlnZ2VyIE4gYW5kIGV2ZW4gTSwgSSB0aGluawppdCBtaWdodCBiZSBiZXR0ZXIgdG8g anVzdCBmaXggTSBhZnRlciB0aGUgbG9vcCBsaWtlOgoKCWlmIChtICUgMikgewoJCWlmIChtIDwg MjU2ICYmIChuICogMikgPD0gKHBsbHJlZiAvIDUpKSB7CgkJCW4gKj0gMjsKCQkJbSAqPSAyOwoJ CX0gZWxzZSB7CgkJCW0rKzsKCQl9Cgl9CgpidXQgSSBoYXZlbid0IHRob3VnaHQgYWJvdXQgdGhp cyB0b28gY2FyZWZ1bGx5LgoKRm9yIHRoaXMgc2VyaWVzLCBJJ2QgcmF0aGVyIGVpdGhlciBrZWVw IHRoaXMgcGF0Y2ggYXMgaXQgaXMgb3IgZHJvcCBpdAppbiBmYXZvdXIgb2YgYSBtb3JlIGNvbXBy ZWhlbnNpdmUgc29sdXRpb24uICBJIGRvbid0IHdhbnQgdG8gYmxvY2sgdGhlCm90aGVyIGZpeGVz IHdhaXRpbmcgZm9yIGEgcGVyZmVjdCBmaXggaGVyZSBhbmQgd2UgY2FuIGFsd2F5cyBpbXByb3Zl CnRoaXMgZnVydGhlciB3aXRoIGEgZm9sbG93LXVwIHBhdGNoLgoKPiA+IFNpZ25lZC1vZmYtYnk6 IEpvaG4gS2VlcGluZyA8am9obkBtZXRhbmF0ZS5jb20+Cj4gPiAtLS0KPiA+IFVuY2hhbmdlZCBp biB2Mgo+ID4gLS0tCj4gPiAgIGRyaXZlcnMvZ3B1L2RybS9yb2NrY2hpcC9kdy1taXBpLWRzaS5j IHwgMiArLQo+ID4gICAxIGZpbGUgY2hhbmdlZCwgMSBpbnNlcnRpb24oKyksIDEgZGVsZXRpb24o LSkKPiA+Cj4gPiBkaWZmIC0tZ2l0IGEvZHJpdmVycy9ncHUvZHJtL3JvY2tjaGlwL2R3LW1pcGkt ZHNpLmMgYi9kcml2ZXJzL2dwdS9kcm0vcm9ja2NoaXAvZHctbWlwaS1kc2kuYwo+ID4gaW5kZXgg MTI0MzJlNDE5NzFiLi5mMjMyMGNmMTM2NmMgMTAwNjQ0Cj4gPiAtLS0gYS9kcml2ZXJzL2dwdS9k cm0vcm9ja2NoaXAvZHctbWlwaS1kc2kuYwo+ID4gKysrIGIvZHJpdmVycy9ncHUvZHJtL3JvY2tj aGlwL2R3LW1pcGktZHNpLmMKPiA+IEBAIC01MTksNyArNTE5LDcgQEAgc3RhdGljIGludCBkd19t aXBpX2RzaV9nZXRfbGFuZV9icHMoc3RydWN0IGR3X21pcGlfZHNpICpkc2ksCj4gPiAgIAlwbGxy ZWYgPSBESVZfUk9VTkRfVVAoY2xrX2dldF9yYXRlKGRzaS0+cGxscmVmX2NsayksIFVTRUNfUEVS X1NFQyk7Cj4gPiAgIAl0bXAgPSBwbGxyZWY7Cj4gPiAgIAo+ID4gLQlmb3IgKGkgPSAxOyBpIDwg NjsgaSsrKSB7Cj4gPiArCWZvciAoaSA9IHBsbHJlZiAvIDU7IGkgPiAocGxscmVmIC8gNDApOyBp LS0pIHsKPiA+ICAgCQlwcmUgPSBwbGxyZWYgLyBpOwo+ID4gICAJCWlmICgodG1wID4gKHRhcmdl dF9tYnBzICUgcHJlKSkgJiYgKHRhcmdldF9tYnBzIC8gcHJlIDwgNTEyKSkgewo+ID4gICAJCQl0 bXAgPSB0YXJnZXRfbWJwcyAlIHByZTsgIAo+IAo+IApfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXwpkcmktZGV2ZWwgbWFpbGluZyBsaXN0CmRyaS1kZXZlbEBs aXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cHM6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1h bi9saXN0aW5mby9kcmktZGV2ZWwK From mboxrd@z Thu Jan 1 00:00:00 1970 From: john@metanate.com (John Keeping) Date: Mon, 23 Jan 2017 12:49:25 +0000 Subject: [PATCH v2 19/26] drm/rockchip: dw-mipi-dsi: improve PLL configuration In-Reply-To: <58855EAE.2010704@rock-chips.com> References: <20170121163128.22240-1-john@metanate.com> <20170121163128.22240-20-john@metanate.com> <58855EAE.2010704@rock-chips.com> Message-ID: <20170123124925.4fa10fc2.john@metanate.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Chris, On Mon, 23 Jan 2017 09:38:54 +0800, Chris Zhong wrote: > On 01/22/2017 12:31 AM, John Keeping wrote: > > The multiplication ratio for the PLL is required to be even due to the > > use of a "by 2 pre-scaler". Currently we are likely to end up with an > > odd multiplier even though there is an equivalent set of parameters with > > an even multiplier. > > > > For example, using the 324MHz bit rate with a reference clock of 24MHz > > we end up with M = 27, N = 2 whereas the example in the PHY databook > > gives M = 54, N = 4 for this bit rate and reference clock. > > > > By walking down through the available multiplier instead of up we are > > more likely to hit an even multiplier. With the above example we do now > > get M = 54, N = 4 as given by the databook. > > > > While doing this, change the loop limits to encode the actual limits on > > the divisor, which are: > > > > 40MHz >= (pllref / N) >= 5MHz > > This formula is limit for N, but we still can not guarantee to get an > even M. > Do you think we should do a check for M. > such as: > if (m % 2) > continue; > ... > for (i = pllref / 5; i > (pllref / 40); i--) { > pre = pllref / i; > if ((tmp > (target_mbps % pre)) && (target_mbps / pre < 512)) { > tmp = target_mbps % pre; > n = i; > m = target_mbps / pre; > if (m % 2) > continue; > } > if (tmp == 0) > break; > } > > if (m % 2) > m++; > > dsi->lane_mbps = pllref / n * m; > dsi->input_div = n; > dsi->feedback_div = m; Yes, I agree that there should be a check for M, but I'm not sure if the version above is sufficient. The "m % 2" check inside the loop means that we don't break immediately when tmp=0 but then we are guaranteed to break next time without having modified n, m because now tmp=0 so "tmp > (target_mbps % pre)" is always false and we just hit the "if (tmp == 0) break" case next time. Given that the descending loop already means that if we can hit "tmp" exactly we are more likely to do so with a bigger N and even M, I think it might be better to just fix M after the loop like: if (m % 2) { if (m < 256 && (n * 2) <= (pllref / 5)) { n *= 2; m *= 2; } else { m++; } } but I haven't thought about this too carefully. For this series, I'd rather either keep this patch as it is or drop it in favour of a more comprehensive solution. I don't want to block the other fixes waiting for a perfect fix here and we can always improve this further with a follow-up patch. > > Signed-off-by: John Keeping > > --- > > Unchanged in v2 > > --- > > drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c > > index 12432e41971b..f2320cf1366c 100644 > > --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c > > +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c > > @@ -519,7 +519,7 @@ static int dw_mipi_dsi_get_lane_bps(struct dw_mipi_dsi *dsi, > > pllref = DIV_ROUND_UP(clk_get_rate(dsi->pllref_clk), USEC_PER_SEC); > > tmp = pllref; > > > > - for (i = 1; i < 6; i++) { > > + for (i = pllref / 5; i > (pllref / 40); i--) { > > pre = pllref / i; > > if ((tmp > (target_mbps % pre)) && (target_mbps / pre < 512)) { > > tmp = target_mbps % pre; > > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751165AbdAWNHf (ORCPT ); Mon, 23 Jan 2017 08:07:35 -0500 Received: from dougal.metanate.com ([90.155.101.14]:38433 "EHLO metanate.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750723AbdAWNHe (ORCPT ); Mon, 23 Jan 2017 08:07:34 -0500 Date: Mon, 23 Jan 2017 12:49:25 +0000 From: John Keeping To: Chris Zhong Cc: Mark Yao , dri-devel@lists.freedesktop.org, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 19/26] drm/rockchip: dw-mipi-dsi: improve PLL configuration Message-ID: <20170123124925.4fa10fc2.john@metanate.com> In-Reply-To: <58855EAE.2010704@rock-chips.com> References: <20170121163128.22240-1-john@metanate.com> <20170121163128.22240-20-john@metanate.com> <58855EAE.2010704@rock-chips.com> Organization: Metanate Ltd X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-unknown-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Chris, On Mon, 23 Jan 2017 09:38:54 +0800, Chris Zhong wrote: > On 01/22/2017 12:31 AM, John Keeping wrote: > > The multiplication ratio for the PLL is required to be even due to the > > use of a "by 2 pre-scaler". Currently we are likely to end up with an > > odd multiplier even though there is an equivalent set of parameters with > > an even multiplier. > > > > For example, using the 324MHz bit rate with a reference clock of 24MHz > > we end up with M = 27, N = 2 whereas the example in the PHY databook > > gives M = 54, N = 4 for this bit rate and reference clock. > > > > By walking down through the available multiplier instead of up we are > > more likely to hit an even multiplier. With the above example we do now > > get M = 54, N = 4 as given by the databook. > > > > While doing this, change the loop limits to encode the actual limits on > > the divisor, which are: > > > > 40MHz >= (pllref / N) >= 5MHz > > This formula is limit for N, but we still can not guarantee to get an > even M. > Do you think we should do a check for M. > such as: > if (m % 2) > continue; > ... > for (i = pllref / 5; i > (pllref / 40); i--) { > pre = pllref / i; > if ((tmp > (target_mbps % pre)) && (target_mbps / pre < 512)) { > tmp = target_mbps % pre; > n = i; > m = target_mbps / pre; > if (m % 2) > continue; > } > if (tmp == 0) > break; > } > > if (m % 2) > m++; > > dsi->lane_mbps = pllref / n * m; > dsi->input_div = n; > dsi->feedback_div = m; Yes, I agree that there should be a check for M, but I'm not sure if the version above is sufficient. The "m % 2" check inside the loop means that we don't break immediately when tmp=0 but then we are guaranteed to break next time without having modified n, m because now tmp=0 so "tmp > (target_mbps % pre)" is always false and we just hit the "if (tmp == 0) break" case next time. Given that the descending loop already means that if we can hit "tmp" exactly we are more likely to do so with a bigger N and even M, I think it might be better to just fix M after the loop like: if (m % 2) { if (m < 256 && (n * 2) <= (pllref / 5)) { n *= 2; m *= 2; } else { m++; } } but I haven't thought about this too carefully. For this series, I'd rather either keep this patch as it is or drop it in favour of a more comprehensive solution. I don't want to block the other fixes waiting for a perfect fix here and we can always improve this further with a follow-up patch. > > Signed-off-by: John Keeping > > --- > > Unchanged in v2 > > --- > > drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c > > index 12432e41971b..f2320cf1366c 100644 > > --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c > > +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c > > @@ -519,7 +519,7 @@ static int dw_mipi_dsi_get_lane_bps(struct dw_mipi_dsi *dsi, > > pllref = DIV_ROUND_UP(clk_get_rate(dsi->pllref_clk), USEC_PER_SEC); > > tmp = pllref; > > > > - for (i = 1; i < 6; i++) { > > + for (i = pllref / 5; i > (pllref / 40); i--) { > > pre = pllref / i; > > if ((tmp > (target_mbps % pre)) && (target_mbps / pre < 512)) { > > tmp = target_mbps % pre; > >