From mboxrd@z Thu Jan 1 00:00:00 1970 From: alexander.stein@systec-electronic.com (Alexander Stein) Date: Tue, 29 Mar 2016 09:26:53 +0200 Subject: [PATCH v2 6/8] drm/fsl-dcu: add TCON driver In-Reply-To: <57c86de8eca0aa16a5cdfc488977ca4e@agner.ch> References: <1459216802-32094-1-git-send-email-stefan@agner.ch> <2234894.ri36D5MRrN@ws-stein> <57c86de8eca0aa16a5cdfc488977ca4e@agner.ch> Message-ID: <3752084.bcROvR6fvG@ws-stein> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Tuesday 29 March 2016 00:11:13, Stefan Agner wrote: > >> --- a/Documentation/devicetree/bindings/display/fsl,dcu.txt > >> +++ b/Documentation/devicetree/bindings/display/fsl,dcu.txt > >> > >> @@ -14,6 +14,7 @@ Required properties: > >> Optional properties: > >> - clocks: Second handle for pixel clock. > >> - clock-names: Second name "pix" for pixel clock. > >> > >> +- fsl,tcon: The phandle to the timing controller node. > > > > Maybe a comment this is (currently) only for Vybrid, but not LS1021A. > > IMHO, such references to SoCs in a peripheral binding is somewhat > misplaced. If we would start doing this, we would end up in lots of SoC > references, and nobody knows whether they are actually accurate and up > to date... And I think we should add tcon to LS1021a, more on that > below... Well, I don't mind after all. > >> --- /dev/null > >> +++ b/drivers/gpu/drm/fsl-dcu/fsl_tcon.c > >> [...] > >> +struct fsl_tcon *fsl_tcon_init(struct device *dev) > >> +{ > >> + struct fsl_tcon *tcon; > >> + struct device_node *np; > >> + int ret; > >> + > >> + tcon = devm_kzalloc(dev, sizeof(*tcon), GFP_KERNEL); > >> + if (!tcon) > >> + return NULL; > >> + > >> + np = of_parse_phandle(dev->of_node, "fsl,tcon", 0); > >> + if (!np) { > >> + dev_warn(dev, "Couldn't find the tcon node\n"); > >> + return NULL; > >> + } > > > > Maybe check for device tree node before allocating struct fsl_tcon? Also > > this should not be a warning, as on LS1021A this is to be expected. > > Agreed, definitely the smarter sequence. > > Afact LS1021a has also a TCON. At least in Jianwei Wangs initial patches > it was part of the driver, see: > https://lkml.org/lkml/2015/7/13/242 > > Not sure how that driver can work without TCON support on LS1021a, maybe > the bootloader sets the TCON to bypass? > > Since I do not have a LS1021a, I hesitated to just add it to the LS1021s > dt's, but it should be fairly straight forward. Interesting, but in Patch 3 (https://lists.freedesktop.org/archives/dri-devel/2015-July/086381.html) no TCON node is added and using is still optional. Yet, I don't find any TCON hardware in the LS1021A reference manual, e.g. in the memory map. I hard guess is that it doesn't require/use one. Without memory address it would be pretty hard to add one. Alexander From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Stein Subject: Re: [PATCH v2 6/8] drm/fsl-dcu: add TCON driver Date: Tue, 29 Mar 2016 09:26:53 +0200 Message-ID: <3752084.bcROvR6fvG@ws-stein> References: <1459216802-32094-1-git-send-email-stefan@agner.ch> <2234894.ri36D5MRrN@ws-stein> <57c86de8eca0aa16a5cdfc488977ca4e@agner.ch> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <57c86de8eca0aa16a5cdfc488977ca4e@agner.ch> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Stefan Agner Cc: meng.yi@nxp.com, pawel.moll@arm.com, alison.wang@freescale.com, daniel.vetter@ffwll.ch, mturquette@baylibre.com, ijc+devicetree@hellion.org.uk, sboyd@codeaurora.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org, robh+dt@kernel.org, kernel@pengutronix.de, galak@codeaurora.org, mark.rutland@arm.com, shawnguo@kernel.org, linux-arm-kernel@lists.infradead.org List-Id: devicetree@vger.kernel.org T24gVHVlc2RheSAyOSBNYXJjaCAyMDE2IDAwOjExOjEzLCBTdGVmYW4gQWduZXIgd3JvdGU6Cj4g Pj4gLS0tIGEvRG9jdW1lbnRhdGlvbi9kZXZpY2V0cmVlL2JpbmRpbmdzL2Rpc3BsYXkvZnNsLGRj dS50eHQKPiA+PiArKysgYi9Eb2N1bWVudGF0aW9uL2RldmljZXRyZWUvYmluZGluZ3MvZGlzcGxh eS9mc2wsZGN1LnR4dAo+ID4+IAo+ID4+IEBAIC0xNCw2ICsxNCw3IEBAIFJlcXVpcmVkIHByb3Bl cnRpZXM6Cj4gPj4gIE9wdGlvbmFsIHByb3BlcnRpZXM6Cj4gPj4gIC0gY2xvY2tzOgkJU2Vjb25k IGhhbmRsZSBmb3IgcGl4ZWwgY2xvY2suCj4gPj4gIC0gY2xvY2stbmFtZXM6CQlTZWNvbmQgbmFt ZSAicGl4IiBmb3IgcGl4ZWwgY2xvY2suCj4gPj4gCj4gPj4gKy0gZnNsLHRjb246CQlUaGUgcGhh bmRsZSB0byB0aGUgdGltaW5nIGNvbnRyb2xsZXIgbm9kZS4KPiA+IAo+ID4gTWF5YmUgYSBjb21t ZW50IHRoaXMgaXMgKGN1cnJlbnRseSkgb25seSBmb3IgVnlicmlkLCBidXQgbm90IExTMTAyMUEu Cj4gCj4gSU1ITywgc3VjaCByZWZlcmVuY2VzIHRvIFNvQ3MgaW4gYSBwZXJpcGhlcmFsIGJpbmRp bmcgaXMgc29tZXdoYXQKPiBtaXNwbGFjZWQuIElmIHdlIHdvdWxkIHN0YXJ0IGRvaW5nIHRoaXMs IHdlIHdvdWxkIGVuZCB1cCBpbiBsb3RzIG9mIFNvQwo+IHJlZmVyZW5jZXMsIGFuZCBub2JvZHkg a25vd3Mgd2hldGhlciB0aGV5IGFyZSBhY3R1YWxseSBhY2N1cmF0ZSBhbmQgdXAKPiB0byBkYXRl Li4uIEFuZCBJIHRoaW5rIHdlIHNob3VsZCBhZGQgdGNvbiB0byBMUzEwMjFhLCBtb3JlIG9uIHRo YXQKPiBiZWxvdy4uLgoKV2VsbCwgSSBkb24ndCBtaW5kIGFmdGVyIGFsbC4KCj4gPj4gLS0tIC9k ZXYvbnVsbAo+ID4+ICsrKyBiL2RyaXZlcnMvZ3B1L2RybS9mc2wtZGN1L2ZzbF90Y29uLmMKPiA+ PiBbLi4uXQo+ID4+ICtzdHJ1Y3QgZnNsX3Rjb24gKmZzbF90Y29uX2luaXQoc3RydWN0IGRldmlj ZSAqZGV2KQo+ID4+ICt7Cj4gPj4gKwlzdHJ1Y3QgZnNsX3Rjb24gKnRjb247Cj4gPj4gKwlzdHJ1 Y3QgZGV2aWNlX25vZGUgKm5wOwo+ID4+ICsJaW50IHJldDsKPiA+PiArCj4gPj4gKwl0Y29uID0g ZGV2bV9remFsbG9jKGRldiwgc2l6ZW9mKCp0Y29uKSwgR0ZQX0tFUk5FTCk7Cj4gPj4gKwlpZiAo IXRjb24pCj4gPj4gKwkJcmV0dXJuIE5VTEw7Cj4gPj4gKwo+ID4+ICsJbnAgPSBvZl9wYXJzZV9w aGFuZGxlKGRldi0+b2Zfbm9kZSwgImZzbCx0Y29uIiwgMCk7Cj4gPj4gKwlpZiAoIW5wKSB7Cj4g Pj4gKwkJZGV2X3dhcm4oZGV2LCAiQ291bGRuJ3QgZmluZCB0aGUgdGNvbiBub2RlXG4iKTsKPiA+ PiArCQlyZXR1cm4gTlVMTDsKPiA+PiArCX0KPiA+IAo+ID4gTWF5YmUgY2hlY2sgZm9yIGRldmlj ZSB0cmVlIG5vZGUgYmVmb3JlIGFsbG9jYXRpbmcgc3RydWN0IGZzbF90Y29uPyBBbHNvCj4gPiB0 aGlzIHNob3VsZCBub3QgYmUgYSB3YXJuaW5nLCBhcyBvbiBMUzEwMjFBIHRoaXMgaXMgdG8gYmUg ZXhwZWN0ZWQuCj4gCj4gQWdyZWVkLCBkZWZpbml0ZWx5IHRoZSBzbWFydGVyIHNlcXVlbmNlLgo+ IAo+IEFmYWN0IExTMTAyMWEgaGFzIGFsc28gYSBUQ09OLiBBdCBsZWFzdCBpbiBKaWFud2VpIFdh bmdzIGluaXRpYWwgcGF0Y2hlcwo+IGl0IHdhcyBwYXJ0IG9mIHRoZSBkcml2ZXIsIHNlZToKPiBo dHRwczovL2xrbWwub3JnL2xrbWwvMjAxNS83LzEzLzI0Mgo+IAo+IE5vdCBzdXJlIGhvdyB0aGF0 IGRyaXZlciBjYW4gd29yayB3aXRob3V0IFRDT04gc3VwcG9ydCBvbiBMUzEwMjFhLCBtYXliZQo+ IHRoZSBib290bG9hZGVyIHNldHMgdGhlIFRDT04gdG8gYnlwYXNzPwo+IAo+IFNpbmNlIEkgZG8g bm90IGhhdmUgYSBMUzEwMjFhLCBJIGhlc2l0YXRlZCB0byBqdXN0IGFkZCBpdCB0byB0aGUgTFMx MDIxcwo+IGR0J3MsIGJ1dCBpdCBzaG91bGQgYmUgZmFpcmx5IHN0cmFpZ2h0IGZvcndhcmQuCgpJ bnRlcmVzdGluZywgYnV0IGluIFBhdGNoIDMgKGh0dHBzOi8vbGlzdHMuZnJlZWRlc2t0b3Aub3Jn L2FyY2hpdmVzL2RyaS1kZXZlbC8yMDE1LUp1bHkvMDg2MzgxLmh0bWwpIG5vIFRDT04gbm9kZSBp cyBhZGRlZCBhbmQgdXNpbmcgaXMgc3RpbGwgCm9wdGlvbmFsLiBZZXQsIEkgZG9uJ3QgZmluZCBh bnkgVENPTiBoYXJkd2FyZSBpbiB0aGUgTFMxMDIxQSByZWZlcmVuY2UgbWFudWFsLCAKZS5nLiBp biB0aGUgbWVtb3J5IG1hcC4gSSBoYXJkIGd1ZXNzIGlzIHRoYXQgaXQgZG9lc24ndCByZXF1aXJl L3VzZSBvbmUuIApXaXRob3V0IG1lbW9yeSBhZGRyZXNzIGl0IHdvdWxkIGJlIHByZXR0eSBoYXJk IHRvIGFkZCBvbmUuCgpBbGV4YW5kZXIKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fCmRyaS1kZXZlbCBtYWlsaW5nIGxpc3QKZHJpLWRldmVsQGxpc3RzLmZy ZWVkZXNrdG9wLm9yZwpodHRwczovL2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2RyaS1kZXZlbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756077AbcC2H1K (ORCPT ); Tue, 29 Mar 2016 03:27:10 -0400 Received: from webbox1416.server-home.net ([77.236.96.61]:41898 "EHLO webbox1416.server-home.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751569AbcC2H1E (ORCPT ); Tue, 29 Mar 2016 03:27:04 -0400 From: Alexander Stein To: Stefan Agner Cc: dri-devel@lists.freedesktop.org, shawnguo@kernel.org, kernel@pengutronix.de, airlied@linux.ie, daniel.vetter@ffwll.ch, jianwei.wang.chn@gmail.com, alison.wang@freescale.com, meng.yi@nxp.com, mturquette@baylibre.com, sboyd@codeaurora.org, mark.rutland@arm.com, robh+dt@kernel.org, pawel.moll@arm.com, ijc+devicetree@hellion.org.uk, galak@codeaurora.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v2 6/8] drm/fsl-dcu: add TCON driver Date: Tue, 29 Mar 2016 09:26:53 +0200 Message-ID: <3752084.bcROvR6fvG@ws-stein> User-Agent: KMail/4.14.10 (Linux/4.1.15-gentoo-r1; KDE/4.14.16; x86_64; ; ) In-Reply-To: <57c86de8eca0aa16a5cdfc488977ca4e@agner.ch> References: <1459216802-32094-1-git-send-email-stefan@agner.ch> <2234894.ri36D5MRrN@ws-stein> <57c86de8eca0aa16a5cdfc488977ca4e@agner.ch> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday 29 March 2016 00:11:13, Stefan Agner wrote: > >> --- a/Documentation/devicetree/bindings/display/fsl,dcu.txt > >> +++ b/Documentation/devicetree/bindings/display/fsl,dcu.txt > >> > >> @@ -14,6 +14,7 @@ Required properties: > >> Optional properties: > >> - clocks: Second handle for pixel clock. > >> - clock-names: Second name "pix" for pixel clock. > >> > >> +- fsl,tcon: The phandle to the timing controller node. > > > > Maybe a comment this is (currently) only for Vybrid, but not LS1021A. > > IMHO, such references to SoCs in a peripheral binding is somewhat > misplaced. If we would start doing this, we would end up in lots of SoC > references, and nobody knows whether they are actually accurate and up > to date... And I think we should add tcon to LS1021a, more on that > below... Well, I don't mind after all. > >> --- /dev/null > >> +++ b/drivers/gpu/drm/fsl-dcu/fsl_tcon.c > >> [...] > >> +struct fsl_tcon *fsl_tcon_init(struct device *dev) > >> +{ > >> + struct fsl_tcon *tcon; > >> + struct device_node *np; > >> + int ret; > >> + > >> + tcon = devm_kzalloc(dev, sizeof(*tcon), GFP_KERNEL); > >> + if (!tcon) > >> + return NULL; > >> + > >> + np = of_parse_phandle(dev->of_node, "fsl,tcon", 0); > >> + if (!np) { > >> + dev_warn(dev, "Couldn't find the tcon node\n"); > >> + return NULL; > >> + } > > > > Maybe check for device tree node before allocating struct fsl_tcon? Also > > this should not be a warning, as on LS1021A this is to be expected. > > Agreed, definitely the smarter sequence. > > Afact LS1021a has also a TCON. At least in Jianwei Wangs initial patches > it was part of the driver, see: > https://lkml.org/lkml/2015/7/13/242 > > Not sure how that driver can work without TCON support on LS1021a, maybe > the bootloader sets the TCON to bypass? > > Since I do not have a LS1021a, I hesitated to just add it to the LS1021s > dt's, but it should be fairly straight forward. Interesting, but in Patch 3 (https://lists.freedesktop.org/archives/dri-devel/2015-July/086381.html) no TCON node is added and using is still optional. Yet, I don't find any TCON hardware in the LS1021A reference manual, e.g. in the memory map. I hard guess is that it doesn't require/use one. Without memory address it would be pretty hard to add one. Alexander