From mboxrd@z Thu Jan 1 00:00:00 1970 From: khilman@baylibre.com (Kevin Hilman) Date: Mon, 06 Mar 2017 09:27:47 -0800 Subject: [PATCH v2 3/3] ARM64: dts: meson-gx: Add MALI nodes for GXBB and GXL In-Reply-To: <1825920f-586f-7c84-8e0e-958046397b64@baylibre.com> (Neil Armstrong's message of "Mon, 6 Mar 2017 09:58:33 +0100") References: <1488365164-22861-1-git-send-email-narmstrong@baylibre.com> <1488365164-22861-4-git-send-email-narmstrong@baylibre.com> <9f3a17e8-63fa-6c14-4d17-0539ef7cd5a2@suse.de> <1825920f-586f-7c84-8e0e-958046397b64@baylibre.com> Message-ID: To: linus-amlogic@lists.infradead.org List-Id: linus-amlogic.lists.infradead.org Neil Armstrong writes: > On 03/04/2017 01:38 PM, Andreas F?rber wrote: >> Am 03.03.2017 um 20:29 schrieb Kevin Hilman: >>> Neil Armstrong writes: >>>> On 03/02/2017 01:31 PM, Andreas F?rber wrote: >>>>> Am 01.03.2017 um 11:46 schrieb Neil Armstrong: >>>>>> The same MALI-450 MP3 GPU is present in the GXBB and GXL SoCs. >> [...] >>>>>> The node is simply added in the meson-gxbb.dtsi file. >> [...] >>>>>> For GXL, since a lot is shared with the GXM that has a MALI-T820 IP, this >>>>>> patch adds a new meson-gxl-mali.dtsi and is included in the SoC specific >>>>>> dtsi files. >>>>> >>>>> This part is slightly confusing though. >>>>> >>>>> What exactly is the GXL vs. GXM difference that this can't be handled by >>>>> overriding node properties compatible/interrupts/clocks? I am missing a >>>>> GXM patch in this series as rationale for doing it this way. >>>>> >>>>> In particular I am wondering whether the whole GXM-inherits-from-GXL >>>>> concept is flawed and should be adjusted if this leads to secondary >>>>> .dtsi files like this: My proposal would be to instead create a >>>>> meson-gxl-gxm.dtsi, that meson-gxl.dtsi and meson-gxm.dtsi can inherit >>>>> the current common parts from, then the Mali bits can simply go into >>>>> meson-gxl.dtsi without extra #includes needed in S905X and S905D. While >>>>> it's slightly more work to split once again, I think it would be cleaner. >> [...] >>>> The only changes are : >> [...] >>>> - A different Mali core, but with the same interrupts (less but they share the same lower interrupts), clocks and memory space >>>> >>>> This is why it was decided to have a sub-dtsi, having a secondary dtsi will simply copy 99% of the GXL dtsi, >>>> but surely we could also have an intermediate dtsi but for boards I'm ok with it, but less for a SoC dtsi, >>>> since it could lead to some confusion. >>>> >>>> Finally, yes I could have added the mali node to the GXL dtsi, but the midgard Mali dt-bindings are not upstream >>>> and the family is too big and recent enough to consider having stable bindings for now. >>>> >>>> Nevertheless, nothing is final, this gxl-mali.dtsi could be merged into the GXL dtsi in the future when we >>>> have proper dt-bindings and a real support of the T820 Mali on the S912. >>>> >>>> Kevin, what's your thought about this ? >>> >>> I don't have a strong preference. I'm OK with a separate Mali .dtsi due >>> to the signficant overlap between GXL/GXM in terms of clocks, interrupts >>> etc. >>> >>> However, if the plan is to #include this from GXM .dts files, whould a >>> better name be meson-gx-mali.dtsi? >> >> I thought the purpose was specifically to not have GXM include it >> because it uses a Midgard IP. >> >> If you want to share the fragment with GXBB too (gx), we should rather >> use meson-gx-mali-utgard.dtsi, which would differentiate from GXM's >> Midgard while still allowing for variation on the 4xx side (e.g., 470). >> >> Regards, >> Andreas >> > > Exact, there is no plan to include it from GXM. > > I'm not fan of having meson-gx-mali-utgard.dtsi, we should still need some attributes additions for > the clocks to the mali node in the gxbb dtsi and each s905x and s905d dtsi files. > I'm not sure this is even cleaner... OK, I misunderstood the intent of having it separated from out from the GXL .dsti then. Could you please clarify? Kevin From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: From: Kevin Hilman To: Neil Armstrong Subject: Re: [PATCH v2 3/3] ARM64: dts: meson-gx: Add MALI nodes for GXBB and GXL References: <1488365164-22861-1-git-send-email-narmstrong@baylibre.com> <1488365164-22861-4-git-send-email-narmstrong@baylibre.com> <9f3a17e8-63fa-6c14-4d17-0539ef7cd5a2@suse.de> <1825920f-586f-7c84-8e0e-958046397b64@baylibre.com> Date: Mon, 06 Mar 2017 09:27:47 -0800 In-Reply-To: <1825920f-586f-7c84-8e0e-958046397b64@baylibre.com> (Neil Armstrong's message of "Mon, 6 Mar 2017 09:58:33 +0100") Message-ID: MIME-Version: 1.0 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devicetree@vger.kernel.org, sboyd@codeaurora.org, linux-kernel@vger.kernel.org, Andreas =?utf-8?Q?F=C3=A4rber?= , carlo@caione.org, linux-amlogic@lists.infradead.org, linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="utf-8" Sender: "linux-amlogic" Errors-To: linux-amlogic-bounces+mturquette=baylibre.com@lists.infradead.org List-ID: TmVpbCBBcm1zdHJvbmcgPG5hcm1zdHJvbmdAYmF5bGlicmUuY29tPiB3cml0ZXM6Cgo+IE9uIDAz LzA0LzIwMTcgMDE6MzggUE0sIEFuZHJlYXMgRsOkcmJlciB3cm90ZToKPj4gQW0gMDMuMDMuMjAx NyB1bSAyMDoyOSBzY2hyaWViIEtldmluIEhpbG1hbjoKPj4+IE5laWwgQXJtc3Ryb25nIDxuYXJt c3Ryb25nQGJheWxpYnJlLmNvbT4gd3JpdGVzOgo+Pj4+IE9uIDAzLzAyLzIwMTcgMDE6MzEgUE0s IEFuZHJlYXMgRsOkcmJlciB3cm90ZToKPj4+Pj4gQW0gMDEuMDMuMjAxNyB1bSAxMTo0NiBzY2hy aWViIE5laWwgQXJtc3Ryb25nOgo+Pj4+Pj4gVGhlIHNhbWUgTUFMSS00NTAgTVAzIEdQVSBpcyBw cmVzZW50IGluIHRoZSBHWEJCIGFuZCBHWEwgU29Dcy4KPj4gWy4uLl0KPj4+Pj4+IFRoZSBub2Rl IGlzIHNpbXBseSBhZGRlZCBpbiB0aGUgbWVzb24tZ3hiYi5kdHNpIGZpbGUuCj4+IFsuLi5dCj4+ Pj4+PiBGb3IgR1hMLCBzaW5jZSBhIGxvdCBpcyBzaGFyZWQgd2l0aCB0aGUgR1hNIHRoYXQgaGFz IGEgTUFMSS1UODIwIElQLCB0aGlzCj4+Pj4+PiBwYXRjaCBhZGRzIGEgbmV3IG1lc29uLWd4bC1t YWxpLmR0c2kgYW5kIGlzIGluY2x1ZGVkIGluIHRoZSBTb0Mgc3BlY2lmaWMKPj4+Pj4+IGR0c2kg ZmlsZXMuCj4+Pj4+Cj4+Pj4+IFRoaXMgcGFydCBpcyBzbGlnaHRseSBjb25mdXNpbmcgdGhvdWdo Lgo+Pj4+Pgo+Pj4+PiBXaGF0IGV4YWN0bHkgaXMgdGhlIEdYTCB2cy4gR1hNIGRpZmZlcmVuY2Ug dGhhdCB0aGlzIGNhbid0IGJlIGhhbmRsZWQgYnkKPj4+Pj4gb3ZlcnJpZGluZyBub2RlIHByb3Bl cnRpZXMgY29tcGF0aWJsZS9pbnRlcnJ1cHRzL2Nsb2Nrcz8gSSBhbSBtaXNzaW5nIGEKPj4+Pj4g R1hNIHBhdGNoIGluIHRoaXMgc2VyaWVzIGFzIHJhdGlvbmFsZSBmb3IgZG9pbmcgaXQgdGhpcyB3 YXkuCj4+Pj4+Cj4+Pj4+IEluIHBhcnRpY3VsYXIgSSBhbSB3b25kZXJpbmcgd2hldGhlciB0aGUg d2hvbGUgR1hNLWluaGVyaXRzLWZyb20tR1hMCj4+Pj4+IGNvbmNlcHQgaXMgZmxhd2VkIGFuZCBz aG91bGQgYmUgYWRqdXN0ZWQgaWYgdGhpcyBsZWFkcyB0byBzZWNvbmRhcnkKPj4+Pj4gLmR0c2kg ZmlsZXMgbGlrZSB0aGlzOiBNeSBwcm9wb3NhbCB3b3VsZCBiZSB0byBpbnN0ZWFkIGNyZWF0ZSBh Cj4+Pj4+IG1lc29uLWd4bC1neG0uZHRzaSwgdGhhdCBtZXNvbi1neGwuZHRzaSBhbmQgbWVzb24t Z3htLmR0c2kgY2FuIGluaGVyaXQKPj4+Pj4gdGhlIGN1cnJlbnQgY29tbW9uIHBhcnRzIGZyb20s IHRoZW4gdGhlIE1hbGkgYml0cyBjYW4gc2ltcGx5IGdvIGludG8KPj4+Pj4gbWVzb24tZ3hsLmR0 c2kgd2l0aG91dCBleHRyYSAjaW5jbHVkZXMgbmVlZGVkIGluIFM5MDVYIGFuZCBTOTA1RC4gV2hp bGUKPj4+Pj4gaXQncyBzbGlnaHRseSBtb3JlIHdvcmsgdG8gc3BsaXQgb25jZSBhZ2FpbiwgSSB0 aGluayBpdCB3b3VsZCBiZSBjbGVhbmVyLgo+PiBbLi4uXQo+Pj4+IFRoZSBvbmx5IGNoYW5nZXMg YXJlIDoKPj4gWy4uLl0KPj4+PiAgLSBBIGRpZmZlcmVudCBNYWxpIGNvcmUsIGJ1dCB3aXRoIHRo ZSBzYW1lIGludGVycnVwdHMgKGxlc3MgYnV0IHRoZXkgc2hhcmUgdGhlIHNhbWUgbG93ZXIgaW50 ZXJydXB0cyksIGNsb2NrcyBhbmQgbWVtb3J5IHNwYWNlCj4+Pj4KPj4+PiBUaGlzIGlzIHdoeSBp dCB3YXMgZGVjaWRlZCB0byBoYXZlIGEgc3ViLWR0c2ksIGhhdmluZyBhIHNlY29uZGFyeSBkdHNp IHdpbGwgc2ltcGx5IGNvcHkgOTklIG9mIHRoZSBHWEwgZHRzaSwKPj4+PiBidXQgc3VyZWx5IHdl IGNvdWxkIGFsc28gaGF2ZSBhbiBpbnRlcm1lZGlhdGUgZHRzaSBidXQgZm9yIGJvYXJkcyBJJ20g b2sgd2l0aCBpdCwgYnV0IGxlc3MgZm9yIGEgU29DIGR0c2ksCj4+Pj4gc2luY2UgaXQgY291bGQg bGVhZCB0byBzb21lIGNvbmZ1c2lvbi4KPj4+Pgo+Pj4+IEZpbmFsbHksIHllcyBJIGNvdWxkIGhh dmUgYWRkZWQgdGhlIG1hbGkgbm9kZSB0byB0aGUgR1hMIGR0c2ksIGJ1dCB0aGUgbWlkZ2FyZCBN YWxpIGR0LWJpbmRpbmdzIGFyZSBub3QgdXBzdHJlYW0KPj4+PiBhbmQgdGhlIGZhbWlseSBpcyB0 b28gYmlnIGFuZCByZWNlbnQgZW5vdWdoIHRvIGNvbnNpZGVyIGhhdmluZyBzdGFibGUgYmluZGlu Z3MgZm9yIG5vdy4KPj4+Pgo+Pj4+IE5ldmVydGhlbGVzcywgbm90aGluZyBpcyBmaW5hbCwgdGhp cyBneGwtbWFsaS5kdHNpIGNvdWxkIGJlIG1lcmdlZCBpbnRvIHRoZSBHWEwgZHRzaSBpbiB0aGUg ZnV0dXJlIHdoZW4gd2UKPj4+PiBoYXZlIHByb3BlciBkdC1iaW5kaW5ncyBhbmQgYSByZWFsIHN1 cHBvcnQgb2YgdGhlIFQ4MjAgTWFsaSBvbiB0aGUgUzkxMi4KPj4+Pgo+Pj4+IEtldmluLCB3aGF0 J3MgeW91ciB0aG91Z2h0IGFib3V0IHRoaXMgPwo+Pj4KPj4+IEkgZG9uJ3QgaGF2ZSBhIHN0cm9u ZyBwcmVmZXJlbmNlLiAgSSdtIE9LIHdpdGggYSBzZXBhcmF0ZSBNYWxpIC5kdHNpIGR1ZQo+Pj4g dG8gdGhlIHNpZ25maWNhbnQgb3ZlcmxhcCBiZXR3ZWVuIEdYTC9HWE0gaW4gdGVybXMgb2YgY2xv Y2tzLCBpbnRlcnJ1cHRzCj4+PiBldGMuCj4+Pgo+Pj4gSG93ZXZlciwgaWYgdGhlIHBsYW4gaXMg dG8gI2luY2x1ZGUgdGhpcyBmcm9tIEdYTSAuZHRzIGZpbGVzLCB3aG91bGQgYQo+Pj4gYmV0dGVy IG5hbWUgYmUgbWVzb24tZ3gtbWFsaS5kdHNpPwo+PiAKPj4gSSB0aG91Z2h0IHRoZSBwdXJwb3Nl IHdhcyBzcGVjaWZpY2FsbHkgdG8gbm90IGhhdmUgR1hNIGluY2x1ZGUgaXQKPj4gYmVjYXVzZSBp dCB1c2VzIGEgTWlkZ2FyZCBJUC4KPj4gCj4+IElmIHlvdSB3YW50IHRvIHNoYXJlIHRoZSBmcmFn bWVudCB3aXRoIEdYQkIgdG9vIChneCksIHdlIHNob3VsZCByYXRoZXIKPj4gdXNlIG1lc29uLWd4 LW1hbGktdXRnYXJkLmR0c2ksIHdoaWNoIHdvdWxkIGRpZmZlcmVudGlhdGUgZnJvbSBHWE0ncwo+ PiBNaWRnYXJkIHdoaWxlIHN0aWxsIGFsbG93aW5nIGZvciB2YXJpYXRpb24gb24gdGhlIDR4eCBz aWRlIChlLmcuLCA0NzApLgo+PiAKPj4gUmVnYXJkcywKPj4gQW5kcmVhcwo+PiAKPgo+IEV4YWN0 LCB0aGVyZSBpcyBubyBwbGFuIHRvIGluY2x1ZGUgaXQgZnJvbSBHWE0uCj4KPiBJJ20gbm90IGZh biBvZiBoYXZpbmcgbWVzb24tZ3gtbWFsaS11dGdhcmQuZHRzaSwgd2Ugc2hvdWxkIHN0aWxsIG5l ZWQgc29tZSBhdHRyaWJ1dGVzIGFkZGl0aW9ucyBmb3IKPiB0aGUgY2xvY2tzIHRvIHRoZSBtYWxp IG5vZGUgaW4gdGhlIGd4YmIgZHRzaSBhbmQgZWFjaCBzOTA1eCBhbmQgczkwNWQgZHRzaSBmaWxl cy4KPiBJJ20gbm90IHN1cmUgdGhpcyBpcyBldmVuIGNsZWFuZXIuLi4KCk9LLCBJIG1pc3VuZGVy c3Rvb2QgdGhlIGludGVudCBvZiBoYXZpbmcgaXQgc2VwYXJhdGVkIGZyb20gb3V0IGZyb20gdGhl CkdYTCAuZHN0aSB0aGVuLiAgQ291bGQgeW91IHBsZWFzZSBjbGFyaWZ5PwoKS2V2aW4KCgoKCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmxpbnV4LWFtbG9n aWMgbWFpbGluZyBsaXN0CmxpbnV4LWFtbG9naWNAbGlzdHMuaW5mcmFkZWFkLm9yZwpodHRwOi8v bGlzdHMuaW5mcmFkZWFkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LWFtbG9naWMK From mboxrd@z Thu Jan 1 00:00:00 1970 From: khilman@baylibre.com (Kevin Hilman) Date: Mon, 06 Mar 2017 09:27:47 -0800 Subject: [PATCH v2 3/3] ARM64: dts: meson-gx: Add MALI nodes for GXBB and GXL In-Reply-To: <1825920f-586f-7c84-8e0e-958046397b64@baylibre.com> (Neil Armstrong's message of "Mon, 6 Mar 2017 09:58:33 +0100") References: <1488365164-22861-1-git-send-email-narmstrong@baylibre.com> <1488365164-22861-4-git-send-email-narmstrong@baylibre.com> <9f3a17e8-63fa-6c14-4d17-0539ef7cd5a2@suse.de> <1825920f-586f-7c84-8e0e-958046397b64@baylibre.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Neil Armstrong writes: > On 03/04/2017 01:38 PM, Andreas F?rber wrote: >> Am 03.03.2017 um 20:29 schrieb Kevin Hilman: >>> Neil Armstrong writes: >>>> On 03/02/2017 01:31 PM, Andreas F?rber wrote: >>>>> Am 01.03.2017 um 11:46 schrieb Neil Armstrong: >>>>>> The same MALI-450 MP3 GPU is present in the GXBB and GXL SoCs. >> [...] >>>>>> The node is simply added in the meson-gxbb.dtsi file. >> [...] >>>>>> For GXL, since a lot is shared with the GXM that has a MALI-T820 IP, this >>>>>> patch adds a new meson-gxl-mali.dtsi and is included in the SoC specific >>>>>> dtsi files. >>>>> >>>>> This part is slightly confusing though. >>>>> >>>>> What exactly is the GXL vs. GXM difference that this can't be handled by >>>>> overriding node properties compatible/interrupts/clocks? I am missing a >>>>> GXM patch in this series as rationale for doing it this way. >>>>> >>>>> In particular I am wondering whether the whole GXM-inherits-from-GXL >>>>> concept is flawed and should be adjusted if this leads to secondary >>>>> .dtsi files like this: My proposal would be to instead create a >>>>> meson-gxl-gxm.dtsi, that meson-gxl.dtsi and meson-gxm.dtsi can inherit >>>>> the current common parts from, then the Mali bits can simply go into >>>>> meson-gxl.dtsi without extra #includes needed in S905X and S905D. While >>>>> it's slightly more work to split once again, I think it would be cleaner. >> [...] >>>> The only changes are : >> [...] >>>> - A different Mali core, but with the same interrupts (less but they share the same lower interrupts), clocks and memory space >>>> >>>> This is why it was decided to have a sub-dtsi, having a secondary dtsi will simply copy 99% of the GXL dtsi, >>>> but surely we could also have an intermediate dtsi but for boards I'm ok with it, but less for a SoC dtsi, >>>> since it could lead to some confusion. >>>> >>>> Finally, yes I could have added the mali node to the GXL dtsi, but the midgard Mali dt-bindings are not upstream >>>> and the family is too big and recent enough to consider having stable bindings for now. >>>> >>>> Nevertheless, nothing is final, this gxl-mali.dtsi could be merged into the GXL dtsi in the future when we >>>> have proper dt-bindings and a real support of the T820 Mali on the S912. >>>> >>>> Kevin, what's your thought about this ? >>> >>> I don't have a strong preference. I'm OK with a separate Mali .dtsi due >>> to the signficant overlap between GXL/GXM in terms of clocks, interrupts >>> etc. >>> >>> However, if the plan is to #include this from GXM .dts files, whould a >>> better name be meson-gx-mali.dtsi? >> >> I thought the purpose was specifically to not have GXM include it >> because it uses a Midgard IP. >> >> If you want to share the fragment with GXBB too (gx), we should rather >> use meson-gx-mali-utgard.dtsi, which would differentiate from GXM's >> Midgard while still allowing for variation on the 4xx side (e.g., 470). >> >> Regards, >> Andreas >> > > Exact, there is no plan to include it from GXM. > > I'm not fan of having meson-gx-mali-utgard.dtsi, we should still need some attributes additions for > the clocks to the mali node in the gxbb dtsi and each s905x and s905d dtsi files. > I'm not sure this is even cleaner... OK, I misunderstood the intent of having it separated from out from the GXL .dsti then. Could you please clarify? Kevin From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Hilman Subject: Re: [PATCH v2 3/3] ARM64: dts: meson-gx: Add MALI nodes for GXBB and GXL Date: Mon, 06 Mar 2017 09:27:47 -0800 Message-ID: References: <1488365164-22861-1-git-send-email-narmstrong@baylibre.com> <1488365164-22861-4-git-send-email-narmstrong@baylibre.com> <9f3a17e8-63fa-6c14-4d17-0539ef7cd5a2@suse.de> <1825920f-586f-7c84-8e0e-958046397b64@baylibre.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <1825920f-586f-7c84-8e0e-958046397b64@baylibre.com> (Neil Armstrong's message of "Mon, 6 Mar 2017 09:58:33 +0100") List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Neil Armstrong Cc: devicetree@vger.kernel.org, sboyd@codeaurora.org, linux-kernel@vger.kernel.org, Andreas =?utf-8?Q?F=C3=A4rber?= , carlo@caione.org, linux-amlogic@lists.infradead.org, linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org List-Id: devicetree@vger.kernel.org TmVpbCBBcm1zdHJvbmcgPG5hcm1zdHJvbmdAYmF5bGlicmUuY29tPiB3cml0ZXM6Cgo+IE9uIDAz LzA0LzIwMTcgMDE6MzggUE0sIEFuZHJlYXMgRsOkcmJlciB3cm90ZToKPj4gQW0gMDMuMDMuMjAx NyB1bSAyMDoyOSBzY2hyaWViIEtldmluIEhpbG1hbjoKPj4+IE5laWwgQXJtc3Ryb25nIDxuYXJt c3Ryb25nQGJheWxpYnJlLmNvbT4gd3JpdGVzOgo+Pj4+IE9uIDAzLzAyLzIwMTcgMDE6MzEgUE0s IEFuZHJlYXMgRsOkcmJlciB3cm90ZToKPj4+Pj4gQW0gMDEuMDMuMjAxNyB1bSAxMTo0NiBzY2hy aWViIE5laWwgQXJtc3Ryb25nOgo+Pj4+Pj4gVGhlIHNhbWUgTUFMSS00NTAgTVAzIEdQVSBpcyBw cmVzZW50IGluIHRoZSBHWEJCIGFuZCBHWEwgU29Dcy4KPj4gWy4uLl0KPj4+Pj4+IFRoZSBub2Rl IGlzIHNpbXBseSBhZGRlZCBpbiB0aGUgbWVzb24tZ3hiYi5kdHNpIGZpbGUuCj4+IFsuLi5dCj4+ Pj4+PiBGb3IgR1hMLCBzaW5jZSBhIGxvdCBpcyBzaGFyZWQgd2l0aCB0aGUgR1hNIHRoYXQgaGFz IGEgTUFMSS1UODIwIElQLCB0aGlzCj4+Pj4+PiBwYXRjaCBhZGRzIGEgbmV3IG1lc29uLWd4bC1t YWxpLmR0c2kgYW5kIGlzIGluY2x1ZGVkIGluIHRoZSBTb0Mgc3BlY2lmaWMKPj4+Pj4+IGR0c2kg ZmlsZXMuCj4+Pj4+Cj4+Pj4+IFRoaXMgcGFydCBpcyBzbGlnaHRseSBjb25mdXNpbmcgdGhvdWdo Lgo+Pj4+Pgo+Pj4+PiBXaGF0IGV4YWN0bHkgaXMgdGhlIEdYTCB2cy4gR1hNIGRpZmZlcmVuY2Ug dGhhdCB0aGlzIGNhbid0IGJlIGhhbmRsZWQgYnkKPj4+Pj4gb3ZlcnJpZGluZyBub2RlIHByb3Bl cnRpZXMgY29tcGF0aWJsZS9pbnRlcnJ1cHRzL2Nsb2Nrcz8gSSBhbSBtaXNzaW5nIGEKPj4+Pj4g R1hNIHBhdGNoIGluIHRoaXMgc2VyaWVzIGFzIHJhdGlvbmFsZSBmb3IgZG9pbmcgaXQgdGhpcyB3 YXkuCj4+Pj4+Cj4+Pj4+IEluIHBhcnRpY3VsYXIgSSBhbSB3b25kZXJpbmcgd2hldGhlciB0aGUg d2hvbGUgR1hNLWluaGVyaXRzLWZyb20tR1hMCj4+Pj4+IGNvbmNlcHQgaXMgZmxhd2VkIGFuZCBz aG91bGQgYmUgYWRqdXN0ZWQgaWYgdGhpcyBsZWFkcyB0byBzZWNvbmRhcnkKPj4+Pj4gLmR0c2kg ZmlsZXMgbGlrZSB0aGlzOiBNeSBwcm9wb3NhbCB3b3VsZCBiZSB0byBpbnN0ZWFkIGNyZWF0ZSBh Cj4+Pj4+IG1lc29uLWd4bC1neG0uZHRzaSwgdGhhdCBtZXNvbi1neGwuZHRzaSBhbmQgbWVzb24t Z3htLmR0c2kgY2FuIGluaGVyaXQKPj4+Pj4gdGhlIGN1cnJlbnQgY29tbW9uIHBhcnRzIGZyb20s IHRoZW4gdGhlIE1hbGkgYml0cyBjYW4gc2ltcGx5IGdvIGludG8KPj4+Pj4gbWVzb24tZ3hsLmR0 c2kgd2l0aG91dCBleHRyYSAjaW5jbHVkZXMgbmVlZGVkIGluIFM5MDVYIGFuZCBTOTA1RC4gV2hp bGUKPj4+Pj4gaXQncyBzbGlnaHRseSBtb3JlIHdvcmsgdG8gc3BsaXQgb25jZSBhZ2FpbiwgSSB0 aGluayBpdCB3b3VsZCBiZSBjbGVhbmVyLgo+PiBbLi4uXQo+Pj4+IFRoZSBvbmx5IGNoYW5nZXMg YXJlIDoKPj4gWy4uLl0KPj4+PiAgLSBBIGRpZmZlcmVudCBNYWxpIGNvcmUsIGJ1dCB3aXRoIHRo ZSBzYW1lIGludGVycnVwdHMgKGxlc3MgYnV0IHRoZXkgc2hhcmUgdGhlIHNhbWUgbG93ZXIgaW50 ZXJydXB0cyksIGNsb2NrcyBhbmQgbWVtb3J5IHNwYWNlCj4+Pj4KPj4+PiBUaGlzIGlzIHdoeSBp dCB3YXMgZGVjaWRlZCB0byBoYXZlIGEgc3ViLWR0c2ksIGhhdmluZyBhIHNlY29uZGFyeSBkdHNp IHdpbGwgc2ltcGx5IGNvcHkgOTklIG9mIHRoZSBHWEwgZHRzaSwKPj4+PiBidXQgc3VyZWx5IHdl IGNvdWxkIGFsc28gaGF2ZSBhbiBpbnRlcm1lZGlhdGUgZHRzaSBidXQgZm9yIGJvYXJkcyBJJ20g b2sgd2l0aCBpdCwgYnV0IGxlc3MgZm9yIGEgU29DIGR0c2ksCj4+Pj4gc2luY2UgaXQgY291bGQg bGVhZCB0byBzb21lIGNvbmZ1c2lvbi4KPj4+Pgo+Pj4+IEZpbmFsbHksIHllcyBJIGNvdWxkIGhh dmUgYWRkZWQgdGhlIG1hbGkgbm9kZSB0byB0aGUgR1hMIGR0c2ksIGJ1dCB0aGUgbWlkZ2FyZCBN YWxpIGR0LWJpbmRpbmdzIGFyZSBub3QgdXBzdHJlYW0KPj4+PiBhbmQgdGhlIGZhbWlseSBpcyB0 b28gYmlnIGFuZCByZWNlbnQgZW5vdWdoIHRvIGNvbnNpZGVyIGhhdmluZyBzdGFibGUgYmluZGlu Z3MgZm9yIG5vdy4KPj4+Pgo+Pj4+IE5ldmVydGhlbGVzcywgbm90aGluZyBpcyBmaW5hbCwgdGhp cyBneGwtbWFsaS5kdHNpIGNvdWxkIGJlIG1lcmdlZCBpbnRvIHRoZSBHWEwgZHRzaSBpbiB0aGUg ZnV0dXJlIHdoZW4gd2UKPj4+PiBoYXZlIHByb3BlciBkdC1iaW5kaW5ncyBhbmQgYSByZWFsIHN1 cHBvcnQgb2YgdGhlIFQ4MjAgTWFsaSBvbiB0aGUgUzkxMi4KPj4+Pgo+Pj4+IEtldmluLCB3aGF0 J3MgeW91ciB0aG91Z2h0IGFib3V0IHRoaXMgPwo+Pj4KPj4+IEkgZG9uJ3QgaGF2ZSBhIHN0cm9u ZyBwcmVmZXJlbmNlLiAgSSdtIE9LIHdpdGggYSBzZXBhcmF0ZSBNYWxpIC5kdHNpIGR1ZQo+Pj4g dG8gdGhlIHNpZ25maWNhbnQgb3ZlcmxhcCBiZXR3ZWVuIEdYTC9HWE0gaW4gdGVybXMgb2YgY2xv Y2tzLCBpbnRlcnJ1cHRzCj4+PiBldGMuCj4+Pgo+Pj4gSG93ZXZlciwgaWYgdGhlIHBsYW4gaXMg dG8gI2luY2x1ZGUgdGhpcyBmcm9tIEdYTSAuZHRzIGZpbGVzLCB3aG91bGQgYQo+Pj4gYmV0dGVy IG5hbWUgYmUgbWVzb24tZ3gtbWFsaS5kdHNpPwo+PiAKPj4gSSB0aG91Z2h0IHRoZSBwdXJwb3Nl IHdhcyBzcGVjaWZpY2FsbHkgdG8gbm90IGhhdmUgR1hNIGluY2x1ZGUgaXQKPj4gYmVjYXVzZSBp dCB1c2VzIGEgTWlkZ2FyZCBJUC4KPj4gCj4+IElmIHlvdSB3YW50IHRvIHNoYXJlIHRoZSBmcmFn bWVudCB3aXRoIEdYQkIgdG9vIChneCksIHdlIHNob3VsZCByYXRoZXIKPj4gdXNlIG1lc29uLWd4 LW1hbGktdXRnYXJkLmR0c2ksIHdoaWNoIHdvdWxkIGRpZmZlcmVudGlhdGUgZnJvbSBHWE0ncwo+ PiBNaWRnYXJkIHdoaWxlIHN0aWxsIGFsbG93aW5nIGZvciB2YXJpYXRpb24gb24gdGhlIDR4eCBz aWRlIChlLmcuLCA0NzApLgo+PiAKPj4gUmVnYXJkcywKPj4gQW5kcmVhcwo+PiAKPgo+IEV4YWN0 LCB0aGVyZSBpcyBubyBwbGFuIHRvIGluY2x1ZGUgaXQgZnJvbSBHWE0uCj4KPiBJJ20gbm90IGZh biBvZiBoYXZpbmcgbWVzb24tZ3gtbWFsaS11dGdhcmQuZHRzaSwgd2Ugc2hvdWxkIHN0aWxsIG5l ZWQgc29tZSBhdHRyaWJ1dGVzIGFkZGl0aW9ucyBmb3IKPiB0aGUgY2xvY2tzIHRvIHRoZSBtYWxp IG5vZGUgaW4gdGhlIGd4YmIgZHRzaSBhbmQgZWFjaCBzOTA1eCBhbmQgczkwNWQgZHRzaSBmaWxl cy4KPiBJJ20gbm90IHN1cmUgdGhpcyBpcyBldmVuIGNsZWFuZXIuLi4KCk9LLCBJIG1pc3VuZGVy c3Rvb2QgdGhlIGludGVudCBvZiBoYXZpbmcgaXQgc2VwYXJhdGVkIGZyb20gb3V0IGZyb20gdGhl CkdYTCAuZHN0aSB0aGVuLiAgQ291bGQgeW91IHBsZWFzZSBjbGFyaWZ5PwoKS2V2aW4KCgoKCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmxpbnV4LWFybS1r ZXJuZWwgbWFpbGluZyBsaXN0CmxpbnV4LWFybS1rZXJuZWxAbGlzdHMuaW5mcmFkZWFkLm9yZwpo dHRwOi8vbGlzdHMuaW5mcmFkZWFkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LWFybS1rZXJu ZWwK From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932252AbdCFR6j (ORCPT ); Mon, 6 Mar 2017 12:58:39 -0500 Received: from mail-pf0-f169.google.com ([209.85.192.169]:33352 "EHLO mail-pf0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932161AbdCFR6b (ORCPT ); Mon, 6 Mar 2017 12:58:31 -0500 From: Kevin Hilman To: Neil Armstrong Cc: Andreas =?utf-8?Q?F=C3=A4rber?= , devicetree@vger.kernel.org, sboyd@codeaurora.org, linux-kernel@vger.kernel.org, linux-clk@vger.kernel.org, carlo@caione.org, linux-amlogic@lists.infradead.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v2 3/3] ARM64: dts: meson-gx: Add MALI nodes for GXBB and GXL Organization: BayLibre References: <1488365164-22861-1-git-send-email-narmstrong@baylibre.com> <1488365164-22861-4-git-send-email-narmstrong@baylibre.com> <9f3a17e8-63fa-6c14-4d17-0539ef7cd5a2@suse.de> <1825920f-586f-7c84-8e0e-958046397b64@baylibre.com> Date: Mon, 06 Mar 2017 09:27:47 -0800 In-Reply-To: <1825920f-586f-7c84-8e0e-958046397b64@baylibre.com> (Neil Armstrong's message of "Mon, 6 Mar 2017 09:58:33 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (darwin) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id v26HwlZY001368 Neil Armstrong writes: > On 03/04/2017 01:38 PM, Andreas Färber wrote: >> Am 03.03.2017 um 20:29 schrieb Kevin Hilman: >>> Neil Armstrong writes: >>>> On 03/02/2017 01:31 PM, Andreas Färber wrote: >>>>> Am 01.03.2017 um 11:46 schrieb Neil Armstrong: >>>>>> The same MALI-450 MP3 GPU is present in the GXBB and GXL SoCs. >> [...] >>>>>> The node is simply added in the meson-gxbb.dtsi file. >> [...] >>>>>> For GXL, since a lot is shared with the GXM that has a MALI-T820 IP, this >>>>>> patch adds a new meson-gxl-mali.dtsi and is included in the SoC specific >>>>>> dtsi files. >>>>> >>>>> This part is slightly confusing though. >>>>> >>>>> What exactly is the GXL vs. GXM difference that this can't be handled by >>>>> overriding node properties compatible/interrupts/clocks? I am missing a >>>>> GXM patch in this series as rationale for doing it this way. >>>>> >>>>> In particular I am wondering whether the whole GXM-inherits-from-GXL >>>>> concept is flawed and should be adjusted if this leads to secondary >>>>> .dtsi files like this: My proposal would be to instead create a >>>>> meson-gxl-gxm.dtsi, that meson-gxl.dtsi and meson-gxm.dtsi can inherit >>>>> the current common parts from, then the Mali bits can simply go into >>>>> meson-gxl.dtsi without extra #includes needed in S905X and S905D. While >>>>> it's slightly more work to split once again, I think it would be cleaner. >> [...] >>>> The only changes are : >> [...] >>>> - A different Mali core, but with the same interrupts (less but they share the same lower interrupts), clocks and memory space >>>> >>>> This is why it was decided to have a sub-dtsi, having a secondary dtsi will simply copy 99% of the GXL dtsi, >>>> but surely we could also have an intermediate dtsi but for boards I'm ok with it, but less for a SoC dtsi, >>>> since it could lead to some confusion. >>>> >>>> Finally, yes I could have added the mali node to the GXL dtsi, but the midgard Mali dt-bindings are not upstream >>>> and the family is too big and recent enough to consider having stable bindings for now. >>>> >>>> Nevertheless, nothing is final, this gxl-mali.dtsi could be merged into the GXL dtsi in the future when we >>>> have proper dt-bindings and a real support of the T820 Mali on the S912. >>>> >>>> Kevin, what's your thought about this ? >>> >>> I don't have a strong preference. I'm OK with a separate Mali .dtsi due >>> to the signficant overlap between GXL/GXM in terms of clocks, interrupts >>> etc. >>> >>> However, if the plan is to #include this from GXM .dts files, whould a >>> better name be meson-gx-mali.dtsi? >> >> I thought the purpose was specifically to not have GXM include it >> because it uses a Midgard IP. >> >> If you want to share the fragment with GXBB too (gx), we should rather >> use meson-gx-mali-utgard.dtsi, which would differentiate from GXM's >> Midgard while still allowing for variation on the 4xx side (e.g., 470). >> >> Regards, >> Andreas >> > > Exact, there is no plan to include it from GXM. > > I'm not fan of having meson-gx-mali-utgard.dtsi, we should still need some attributes additions for > the clocks to the mali node in the gxbb dtsi and each s905x and s905d dtsi files. > I'm not sure this is even cleaner... OK, I misunderstood the intent of having it separated from out from the GXL .dsti then. Could you please clarify? Kevin