From mboxrd@z Thu Jan 1 00:00:00 1970 From: CK Hu Subject: Re: [RFC resend] arm64: mt8173: Fix Acer Chromebooks mmsys probe problem Date: Mon, 23 Oct 2017 09:42:58 +0800 Message-ID: <1508722978.1108.16.camel@mtksdaap41> References: <20171019112610.13645-1-mbrugger@suse.com> <1508418114.7665.16.camel@pengutronix.de> <1683149.BjzMD0lNNQ@avalon> <1508424856.7665.22.camel@pengutronix.de> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <1508424856.7665.22.camel@pengutronix.de> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Philipp Zabel Cc: mark.rutland@arm.com, devicetree@vger.kernel.org, catalin.marinas@arm.com, will.deacon@arm.com, linux@armlinux.org.uk, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, ulrich.hecht+renesas@gmail.com, robh+dt@kernel.org, linux-mediatek@lists.infradead.org, Laurent Pinchart , Matthias Brugger , linux-arm-kernel@lists.infradead.org List-Id: linux-mediatek@lists.infradead.org SGksCgpPbiBUaHUsIDIwMTctMTAtMTkgYXQgMTY6NTQgKzAyMDAsIFBoaWxpcHAgWmFiZWwgd3Jv dGU6Cj4gSGkgTGF1cmVudCwKPiAKPiBPbiBUaHUsIDIwMTctMTAtMTkgYXQgMTY6MzkgKzAzMDAs IExhdXJlbnQgUGluY2hhcnQgd3JvdGU6Cj4gPiBIaSBQaGlsaXBwLAo+ID4gCj4gPiBPbiBUaHVy c2RheSwgMTkgT2N0b2JlciAyMDE3IDE2OjAxOjU0IEVFU1QgUGhpbGlwcCBaYWJlbCB3cm90ZToK PiA+ID4gT24gVGh1LCAyMDE3LTEwLTE5IGF0IDEzOjI2ICswMjAwLCBNYXR0aGlhcyBCcnVnZ2Vy IHdyb3RlOgo+ID4gPiA+IEluIHRoZW9yeSB0aGUgTU1TWVMgZGV2aWNlIHRyZWUgaWRlbnRpZmll ciBpcyBtYXRjaGVzIHR3aWNlLCBieSB0aGUgY2xrCj4gPiA+ID4gZHJpdmVyIGFuZCB0aGUgRFJN IHN1YnN5c3RlbS4gQnV0IHRoZSBrZXJuZWwgb25seSBtYXRjaGVzIHRoZSBmaXJzdAo+ID4gPiA+ IGRyaXZlciBmb3IgYSBkZXZpY2UgKGNsaykgYW5kIGRpc2NhcmRzIHRoZSBzZWNvbmQgb25lLiBU aGlzIGJyZWFrcwo+ID4gPiA+IGdyYXBoaWNzIG9uIG10ODE3MyBhbmQgbW9zdCBwcm9iYWJseSBv biBtdDI3MDEgYXMgd2VsbC4KPiA+ID4gPiAKPiA+ID4gPiBNTVNZUyBpbiBNZWRpYXRlayBTb0Nz IGhhcyBzb21lIHJlZ2lzdGVycyB0byBjb250cm9sIGNsb2NrIGdhdGVzICh3aGljaCBpcwo+ID4g PiA+IHVzZWQgaW4gdGhlIGNsayBkcml2ZXIpIGFuZCBzb21lIHJlZ2lzdGVycyB0byBlbmFibGUg dGhlIGRpZmZlcm5ldCBibG9ja3MKPiA+ID4gPiBvZiB0aGUgZGlzcGxheSBzdWJzeXN0ZW0uIFRo ZSBrZXJuZWwgdXNlcyB0aGUgYmluZGluZyB0byBsb2FkIHRoZSBjZW50cmFsCj4gPiA+ID4gY29t b3BvbmVudCBvZiB0aGUgZGlzdHBsYXkgc3Vic3lzdGVtLCB3aGljaCBpbiBwbGFjZSBwcm9iZXMg YWxsIHRoZSBvdGhlcgo+ID4gPiA+IGNvbXBvbmVudHMgYW5kIGVuYWJsZXMgdGhlIHByZXNlbnQg b25lcyBpbiB0aGUgTU1TWVMuCj4gPiA+ID4gCj4gPiA+ID4gV2UgZm91bmQgdXMgd2l0aCB0aGUg cHJvYmxlbSwgdGhhdCB3ZSBuZWVkIHRvIGNoYW5nZSBhbmQgdGhlcmVmb3IgYnJlYWsKPiA+ID4g PiBvbmUKPiA+ID4gPiBvZiB0aGUgdHdvIGJpbmRpbmdzLCBvciB0aGUgRFJNIG9uZSBvciB0aGUg Y2xvY2sgZHJpdmVyIG9uZS4KPiA+ID4gPiAKPiA+ID4gPiBBcGFydCBmcm9tIHRoYXQgdGhlIERS TSBzdWJ5c3lzdGVtIGRvZXMgYWNjZXNzIHRoZSBNTVNZUyByZWdpc3RlcnMgdmlhCj4gPiA+ID4g cmVsYXhlZCByZWFkcy93cml0ZXMuIEJ1dCB0aGUgaXQgc2hvdWxkIHRvIHNvIHZpYSByZWdtYXAs IGFzIHRoZQo+ID4gPiA+IHJlZ2lzdGVycyBhcmUgc2hhcmVkLgo+ID4gPiA+IAo+ID4gPiA+IFBv c3NpYmxlIHNvbHV0aW9uczoKPiA+ID4gPiAxKSBXZSBhZGQgYSBuZXcgbWVkaWF0ZWssbXQ4MTcz LW1tc3lzLWNsayBub2RlLCB3aGljaCBsaXZlcyBhcyBhCj4gPiA+ID4gc2ltcGxlLW1mZCB1bmRl ciB0aGUgYWN0dWFsIG1tc3lzIG5vZGUuIFdlIGNoYW5nZSB0aGUgY2xvY2sgZHJpdmVyIHRvCj4g PiA+ID4gcHJvYmUgb24gdGhpcyBiaW5kaW5nLiBUaGlzIHdvdWxkIG1ha2Ugc2Vuc2UgYXMgdGhl IGNsb2NrIGdhdGUgcmVnaXN0ZXIKPiA+ID4gPiBsaXZlIGNvbXBsZXRseSBpbiB0aGUgTU1TWVMg Y29uZmlndXJhdGlvbiByZWdpc3RlcnMuCj4gPiA+IAo+ID4gPiBUaGUgcmVhc29uIHdoeSB0aGUg ZHJtIGRyaXZlciBtYXRjaGVzIGFnYWluc3QgdGhlIG1tc3lzIG5vZGUgaW4gdGhlCj4gPiA+IGZp cnN0IHBsYWNlIGlzIHRoYXQgd2Ugd2FudGVkIHRvIGF2b2lkIDIpLgo+ID4gCj4gPiBXaHkgZGlk IHlvdSB3YW50IHRvIGF2b2lkIDIpID8KPiAKPiBCZWNhdXNlIHRoZSAiZGlzcGxheS1zdWJzeXN0 ZW0iIG5vZGUgZG9lcyBub3QgcmVwcmVzZW50IGEgcmVhbCBkZXZpY2UsCj4gaXQncyBqdXN0IHRo ZXJlIHRvIHByb2JlIHRoZSBkcml2ZXIgdGhhdCBzdGl0Y2hlcyBhbGwgdGhlIERJU1AKPiBjb21w b25lbnRzIHRvZ2V0aGVyLgo+IAo+ID4gPiBBbHNvLCBtbXN5cyBpcyBub3QgYSBwdXJlIGNsb2Nr IGNvbnRyb2xsZXIsIGFzIGl0IGFsc28gY29udGFpbnMgdGhlCj4gPiA+IGRpc3BsYXkgcGF0aCBj b25maWd1cmF0aW9uIGluIGl0cyByZWdpc3RlciBzcGFjZS4KPiA+IAo+ID4gV2hpY2ggbWFrZXMg dGhlIG1tc3lzIHJlbGF0ZWQgdG8gZGlzcGxheSwgYnV0IG1vcmUgaW4gYSBzeXNjb24gKGNvbWJp bmluZyAKPiA+IGNsb2NrcyBhbmQgcm91dGluZywgYW5kIEkgYXNzdW1lIG90aGVyIG1pc2NlbGxh bmVvdXMgZmVhdHVyZXMgdGhhdCB3b3VsZG4ndCAKPiA+IGZpdCBuaWNlbHkgaW4gdGhlIG90aGVy IGRpc3BsYXktcmVsYXRlZCBJUCBjb3Jlcykgd2F5IHRoYW4gYWN0dWFsbHkgYmVpbmcgcGFydCAK PiA+IG9mIHRoZSBkaXNwbGF5IHN1YnN5c3RlbS4gT3IgZG9lcyBtbXN5cyBvbmx5IHByb3ZpZGUg ZGlzcGxheS1yZWxhdGVkIGZlYXR1cmVzIAo+ID4gPwo+IAo+IEFsbCBkZXZpY2VzIGluIHRoZSAw eDE0MDAwMDAwIC0gMHgxNGZmZmZmZiBtZW1vcnkgcmFuZ2UgYXJlIHBhcnQgb2YgdGhlCj4gTU1T WVMgc3lzdGVtLiBUaGF0IGluY2x1ZGVzIHRoZSBNTVNZUyBjb250cm9sIG9yIHN5c3RlbSBjb25m aWd1cmF0aW9uCj4gYmxvY2sgYXQgMHgxNDAwMDAwMCAtIDB4MTQwMDBmZmYgYXMgd2VsbCBhcyBh bGwgdGhlIHJlbGF0ZWQgTURQIChtZWRpYQo+IGRhdGEgcGF0aCkgYW5kIERJU1AgKGRpc3BsYXkg ZGF0YSBwYXRoKSBibG9ja3MgdGhhdCBmb2xsb3cuIFRoZSBESVNQCj4gYmxvY2tzIGFyZSBwdXJl bHkgZGlzcGxheSByZWxhdGVkLCB3aGlsZSB0aGUgTURQIGJsb2NrcyBpbXBsZW1lbnQKPiBpbXBs ZW1lbnQgbWVtMm1lbSBmdW5jdGlvbnMgbGlrZSBzY2FsaW5nIGFuZCBjb252ZXJzaW9uLgo+IAo+ ID4gPiA+IDIpIEFzIHRoZSBub2RlcyBvZiB0aGUgRFJNIHN1YnN5c3RlbSBqdXN0IG5lZWQgc29t ZSBvZiB0aGUgcmVnaXN0ZXJzIG9mCj4gPiA+ID4gTU1TWVMgd2UgYWRkIGEgbmV3IGJpbmRpbmcg bWVkaWF0ZWssbXQ4MTczLWRpc3BzeXMgd2hpY2ggcHJvYmVzIHRoZQo+ID4gPiA+IGNlbnRyYWwg Y29tcG9uZW50IG9mIHRoZSBEUk0gc3lzdGVtLiBJdCBoYXMgb25seSBhIGhhbmRsZSB0byBtdDgx NzMtbW1zeXMKPiA+ID4gPiB0byBhY2Nlc3MgdGhlIHJlZ2lzdGVyc3BhY2UgdmlhIHJlZ21hcCBm dW5jdGlvbnMuCj4gPiA+ID4gCj4gPiA+ID4gSW4gdGhpcyBwYXRjaHNldCBJIGltcGxlbWVudGVk IDIpLiBQbGVhc2UgdGFrZSBpbnRvIGFjY291bnQsIHRoYXQgdGhpcyBpcwo+ID4gPiA+IGEgUkZD LiBJIGhhZCBubyB0aW1lIHRvIGFjdHVhbGx5IHRlc3QgdGhlIHZlcmlzb24gb24gcmVhbCBIVy4g U29tZSBvZiB0aGUKPiA+ID4gPiByZWdpc3RlciBhY2Nlc3NlcyBzaG91bGQgYmUgZG9uZSB1c2lu ZyByZWdtYXBfdXBkYXRlIGluc3RlYWQgb2YKPiA+ID4gPiByZWdtYXBfcmVhZCArIHJlZ21hcF93 cml0ZS4KPiA+ID4gPiAKPiA+ID4gPiBUaGlzIFJGQyBzaGFsbCBvbmx5IHNob3cgaG93IHNvbHV0 aW9uIDIpIHdvdWxkIGxvb2sgbGlrZS4gV2UgY2FuIHVzZSBpdCBhcwo+ID4gPiA+IGRpc2N1c3Np b24gdG8gc2VlIGhvdyB3ZSBjaXJjdW12ZW50IHRoZSBhY3R1YWwgc2l0dWF0aW9uLgo+ID4gPiAK PiA+ID4gT3Igd2UgY291bGQgbGVhdmUgdGhlIGJpbmRpbmdzIHVudG91Y2hlZCBhbmQgY3JlYXRl IG9uZSBwbGF0Zm9ybSBkZXZpY2UKPiA+ID4gZnJvbSB0aGUgb3RoZXIgb3IgZXZlbiBzZXQgdXAg dGhlIGNsb2NrcyBmcm9tIHRoZSBkcm0gZHJpdmVyPwo+ID4gCj4gPiBEb2VzIG1tc3lzIHByb3Zp ZGUgZmVhdHVyZXMgKHN1Y2ggYXMgY2xvY2tzKSB0byBub24tZGlzcGxheSBJUCBjb3JlcyA/Cj4g Cj4gVGhlIE1NU1lTIGNvbnRyb2wgYmxvY2sgcHJvdmlkZXMgY2xvY2tzIGZvciB0aGUgRElTUCAo ZGlzcGxheSBkYXRhIHBhdGgpCj4gYW5kIE1EUCAobXVsdGltZWRpYSBkYXRhIHBhdGgpIGJsb2Nr cywgYXMgd2VsbCBhcyB0aGUgcm91dGluZyBiZXR3ZWVuCj4gdGhlbSwgYnV0IG5vdCB0byBhbnl0 aGluZyBvdXRzaWRlIG9mIHRoZSBNTVNZUyBzeXN0ZW0uCgpBY2NvcmRpbmcgdG8gcmVnaXN0ZXIg dGFibGUgb2YgbWVkaWF0ZWsgeDIwIG1tc3lzIFsxXSBhbmQgUGhpbGlwcCdzCnN0YXRlbWVudCwg SSB0aGluayBtbXN5cyBpcyBuZWl0aGVyIGNsb2NrLWNvbnRyb2xsZXIgbm9yIGRpc3BsYXkKY29u dHJvbGxlci4gSXQncyBhIGNvbWJpbmF0aW9uIG9mIG11bHRpcGxlIGZ1bmN0aW9uLiBUaGUgZm91 ciBtYWpvcgpmdW5jdGlvbiBpcyBkaXNwbGF5J3MgY2xvY2stY29udHJvbCwgbWRwJ3MgY2xvY2st Y29udHJvbCwgZGlzcGxheSdzCnJvdXRpbmcsIGFuZCBtZHAncyByb3V0aW5nLiBTbyB3ZSBoYXZl IHR3byBjaG9pY2U6CgoxKSBDZW50cmFsaXplIHRoZXNlIG11bHRpcGxlIGZ1bmN0aW9uIGNvbnRy b2wgaW5zaWRlIG1tc3lzIGRldmljZTogVGhpcwptZWFucyB0aGVyZSBpcyBvbmx5IGEgbW1zeXMg ZGV2aWNlIHdoaWNoIGNvbnRhaW5zIGZ1bmN0aW9uIG9mCmNsb2NrLWNvbnRyb2wsIGRpc3BsYXks IGFuZCBtZHAuCgoyKSBTZXBhcmF0ZSB0aGVzZSBtdWx0aXBsZSBmdW5jdGlvbiB0byBkaWZmZXJl bnQgZGV2aWNlOiBtbXN5cyBpcyB0aGUKbWFqb3IgZGV2aWNlIHdoaWNoIG93bnMgdGhlIHJlZ2lz dGVyIHJlc291cmNlIGJ1dCBkb2VzIG5vdGhpbmcuIFRoZQpmdW5jdGlvbiBpcyBjb250cm9sbGVk IGJ5IHRocmVlIHZpcnR1YWwgZGV2aWNlOiBtbXN5cy1jbG9jay1jb250cm9sbGVyLApkaXNwbGF5 LWNvbnRyb2xsZXIsIGFuZCBtZHAtY29udHJvbGxlci4KCkkgcHJlZmVyIDIpIGJlY2F1c2UgdGhl c2UgZnVuY3Rpb24gc2VlbXMgaW5kZXBlbmRlbnQuIAoKUmVnYXJkcywKQ0sKClsxXQpodHRwczov L3d3dy45NmJvYXJkcy5vcmcvZG9jdW1lbnRhdGlvbi9Db25zdW1lckVkaXRpb24vTWVkaWFUZWtY MjAvQWRkaXRpb25hbERvY3MvCgo+IAo+IHJlZ2FyZHMKPiBQaGlsaXBwCgoKX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVsIG1haWxpbmcgbGlz dApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlzdHMuZnJlZWRlc2t0 b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== From mboxrd@z Thu Jan 1 00:00:00 1970 From: ck.hu@mediatek.com (CK Hu) Date: Mon, 23 Oct 2017 09:42:58 +0800 Subject: [RFC resend] arm64: mt8173: Fix Acer Chromebooks mmsys probe problem In-Reply-To: <1508424856.7665.22.camel@pengutronix.de> References: <20171019112610.13645-1-mbrugger@suse.com> <1508418114.7665.16.camel@pengutronix.de> <1683149.BjzMD0lNNQ@avalon> <1508424856.7665.22.camel@pengutronix.de> Message-ID: <1508722978.1108.16.camel@mtksdaap41> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi, On Thu, 2017-10-19 at 16:54 +0200, Philipp Zabel wrote: > Hi Laurent, > > On Thu, 2017-10-19 at 16:39 +0300, Laurent Pinchart wrote: > > Hi Philipp, > > > > On Thursday, 19 October 2017 16:01:54 EEST Philipp Zabel wrote: > > > On Thu, 2017-10-19 at 13:26 +0200, Matthias Brugger wrote: > > > > In theory the MMSYS device tree identifier is matches twice, by the clk > > > > driver and the DRM subsystem. But the kernel only matches the first > > > > driver for a device (clk) and discards the second one. This breaks > > > > graphics on mt8173 and most probably on mt2701 as well. > > > > > > > > MMSYS in Mediatek SoCs has some registers to control clock gates (which is > > > > used in the clk driver) and some registers to enable the differnet blocks > > > > of the display subsystem. The kernel uses the binding to load the central > > > > comoponent of the distplay subsystem, which in place probes all the other > > > > components and enables the present ones in the MMSYS. > > > > > > > > We found us with the problem, that we need to change and therefor break > > > > one > > > > of the two bindings, or the DRM one or the clock driver one. > > > > > > > > Apart from that the DRM subysystem does access the MMSYS registers via > > > > relaxed reads/writes. But the it should to so via regmap, as the > > > > registers are shared. > > > > > > > > Possible solutions: > > > > 1) We add a new mediatek,mt8173-mmsys-clk node, which lives as a > > > > simple-mfd under the actual mmsys node. We change the clock driver to > > > > probe on this binding. This would make sense as the clock gate register > > > > live completly in the MMSYS configuration registers. > > > > > > The reason why the drm driver matches against the mmsys node in the > > > first place is that we wanted to avoid 2). > > > > Why did you want to avoid 2) ? > > Because the "display-subsystem" node does not represent a real device, > it's just there to probe the driver that stitches all the DISP > components together. > > > > Also, mmsys is not a pure clock controller, as it also contains the > > > display path configuration in its register space. > > > > Which makes the mmsys related to display, but more in a syscon (combining > > clocks and routing, and I assume other miscellaneous features that wouldn't > > fit nicely in the other display-related IP cores) way than actually being part > > of the display subsystem. Or does mmsys only provide display-related features > > ? > > All devices in the 0x14000000 - 0x14ffffff memory range are part of the > MMSYS system. That includes the MMSYS control or system configuration > block at 0x14000000 - 0x14000fff as well as all the related MDP (media > data path) and DISP (display data path) blocks that follow. The DISP > blocks are purely display related, while the MDP blocks implement > implement mem2mem functions like scaling and conversion. > > > > > 2) As the nodes of the DRM subsystem just need some of the registers of > > > > MMSYS we add a new binding mediatek,mt8173-dispsys which probes the > > > > central component of the DRM system. It has only a handle to mt8173-mmsys > > > > to access the registerspace via regmap functions. > > > > > > > > In this patchset I implemented 2). Please take into account, that this is > > > > a RFC. I had no time to actually test the verison on real HW. Some of the > > > > register accesses should be done using regmap_update instead of > > > > regmap_read + regmap_write. > > > > > > > > This RFC shall only show how solution 2) would look like. We can use it as > > > > discussion to see how we circumvent the actual situation. > > > > > > Or we could leave the bindings untouched and create one platform device > > > from the other or even set up the clocks from the drm driver? > > > > Does mmsys provide features (such as clocks) to non-display IP cores ? > > The MMSYS control block provides clocks for the DISP (display data path) > and MDP (multimedia data path) blocks, as well as the routing between > them, but not to anything outside of the MMSYS system. According to register table of mediatek x20 mmsys [1] and Philipp's statement, I think mmsys is neither clock-controller nor display controller. It's a combination of multiple function. The four major function is display's clock-control, mdp's clock-control, display's routing, and mdp's routing. So we have two choice: 1) Centralize these multiple function control inside mmsys device: This means there is only a mmsys device which contains function of clock-control, display, and mdp. 2) Separate these multiple function to different device: mmsys is the major device which owns the register resource but does nothing. The function is controlled by three virtual device: mmsys-clock-controller, display-controller, and mdp-controller. I prefer 2) because these function seems independent. Regards, CK [1] https://www.96boards.org/documentation/ConsumerEdition/MediaTekX20/AdditionalDocs/ > > regards > Philipp From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932117AbdJWBnI (ORCPT ); Sun, 22 Oct 2017 21:43:08 -0400 Received: from mailgw02.mediatek.com ([210.61.82.184]:55056 "EHLO mailgw02.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1750991AbdJWBnG (ORCPT ); Sun, 22 Oct 2017 21:43:06 -0400 X-UUID: 0c36cd6c95bb44b694630a715a7b055e-20171023 Message-ID: <1508722978.1108.16.camel@mtksdaap41> Subject: Re: [RFC resend] arm64: mt8173: Fix Acer Chromebooks mmsys probe problem From: CK Hu To: Philipp Zabel CC: Laurent Pinchart , Matthias Brugger , , , , , , , , , , , , Date: Mon, 23 Oct 2017 09:42:58 +0800 In-Reply-To: <1508424856.7665.22.camel@pengutronix.de> References: <20171019112610.13645-1-mbrugger@suse.com> <1508418114.7665.16.camel@pengutronix.de> <1683149.BjzMD0lNNQ@avalon> <1508424856.7665.22.camel@pengutronix.de> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-MTK: N Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Thu, 2017-10-19 at 16:54 +0200, Philipp Zabel wrote: > Hi Laurent, > > On Thu, 2017-10-19 at 16:39 +0300, Laurent Pinchart wrote: > > Hi Philipp, > > > > On Thursday, 19 October 2017 16:01:54 EEST Philipp Zabel wrote: > > > On Thu, 2017-10-19 at 13:26 +0200, Matthias Brugger wrote: > > > > In theory the MMSYS device tree identifier is matches twice, by the clk > > > > driver and the DRM subsystem. But the kernel only matches the first > > > > driver for a device (clk) and discards the second one. This breaks > > > > graphics on mt8173 and most probably on mt2701 as well. > > > > > > > > MMSYS in Mediatek SoCs has some registers to control clock gates (which is > > > > used in the clk driver) and some registers to enable the differnet blocks > > > > of the display subsystem. The kernel uses the binding to load the central > > > > comoponent of the distplay subsystem, which in place probes all the other > > > > components and enables the present ones in the MMSYS. > > > > > > > > We found us with the problem, that we need to change and therefor break > > > > one > > > > of the two bindings, or the DRM one or the clock driver one. > > > > > > > > Apart from that the DRM subysystem does access the MMSYS registers via > > > > relaxed reads/writes. But the it should to so via regmap, as the > > > > registers are shared. > > > > > > > > Possible solutions: > > > > 1) We add a new mediatek,mt8173-mmsys-clk node, which lives as a > > > > simple-mfd under the actual mmsys node. We change the clock driver to > > > > probe on this binding. This would make sense as the clock gate register > > > > live completly in the MMSYS configuration registers. > > > > > > The reason why the drm driver matches against the mmsys node in the > > > first place is that we wanted to avoid 2). > > > > Why did you want to avoid 2) ? > > Because the "display-subsystem" node does not represent a real device, > it's just there to probe the driver that stitches all the DISP > components together. > > > > Also, mmsys is not a pure clock controller, as it also contains the > > > display path configuration in its register space. > > > > Which makes the mmsys related to display, but more in a syscon (combining > > clocks and routing, and I assume other miscellaneous features that wouldn't > > fit nicely in the other display-related IP cores) way than actually being part > > of the display subsystem. Or does mmsys only provide display-related features > > ? > > All devices in the 0x14000000 - 0x14ffffff memory range are part of the > MMSYS system. That includes the MMSYS control or system configuration > block at 0x14000000 - 0x14000fff as well as all the related MDP (media > data path) and DISP (display data path) blocks that follow. The DISP > blocks are purely display related, while the MDP blocks implement > implement mem2mem functions like scaling and conversion. > > > > > 2) As the nodes of the DRM subsystem just need some of the registers of > > > > MMSYS we add a new binding mediatek,mt8173-dispsys which probes the > > > > central component of the DRM system. It has only a handle to mt8173-mmsys > > > > to access the registerspace via regmap functions. > > > > > > > > In this patchset I implemented 2). Please take into account, that this is > > > > a RFC. I had no time to actually test the verison on real HW. Some of the > > > > register accesses should be done using regmap_update instead of > > > > regmap_read + regmap_write. > > > > > > > > This RFC shall only show how solution 2) would look like. We can use it as > > > > discussion to see how we circumvent the actual situation. > > > > > > Or we could leave the bindings untouched and create one platform device > > > from the other or even set up the clocks from the drm driver? > > > > Does mmsys provide features (such as clocks) to non-display IP cores ? > > The MMSYS control block provides clocks for the DISP (display data path) > and MDP (multimedia data path) blocks, as well as the routing between > them, but not to anything outside of the MMSYS system. According to register table of mediatek x20 mmsys [1] and Philipp's statement, I think mmsys is neither clock-controller nor display controller. It's a combination of multiple function. The four major function is display's clock-control, mdp's clock-control, display's routing, and mdp's routing. So we have two choice: 1) Centralize these multiple function control inside mmsys device: This means there is only a mmsys device which contains function of clock-control, display, and mdp. 2) Separate these multiple function to different device: mmsys is the major device which owns the register resource but does nothing. The function is controlled by three virtual device: mmsys-clock-controller, display-controller, and mdp-controller. I prefer 2) because these function seems independent. Regards, CK [1] https://www.96boards.org/documentation/ConsumerEdition/MediaTekX20/AdditionalDocs/ > > regards > Philipp