From mboxrd@z Thu Jan 1 00:00:00 1970 From: khilman@baylibre.com (Kevin Hilman) Date: Fri, 03 Mar 2017 11:29:12 -0800 Subject: [PATCH v2 3/3] ARM64: dts: meson-gx: Add MALI nodes for GXBB and GXL In-Reply-To: (Neil Armstrong's message of "Thu, 2 Mar 2017 13:47:26 +0100") References: <1488365164-22861-1-git-send-email-narmstrong@baylibre.com> <1488365164-22861-4-git-send-email-narmstrong@baylibre.com> Message-ID: To: linus-amlogic@lists.infradead.org List-Id: linus-amlogic.lists.infradead.org Neil Armstrong writes: > Hi Andreas, > On 03/02/2017 01:31 PM, Andreas F?rber wrote: >> Hi Neil, >> >> Am 01.03.2017 um 11:46 schrieb Neil Armstrong: >>> The same MALI-450 MP3 GPU is present in the GXBB and GXL SoCs. >> >> First of all, any reason you're upper-casing Mali in the commit message? >> ARM doesn't. > > No reason, only a type, indeed it was lower-casing on the v1. > Will fix in v2. > >> >>> >>> The node is simply added in the meson-gxbb.dtsi file. >> >> The GXBB part looks fine on a quick look. >> >>> >>> 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 GXL and GXM differences are very small : > - They share the same clock tree > - They share the same pinctrl and even the same pinout (S905D and S912 are pin-to-pin compatible) > - They share all the peripherals > > The only changes are : > - Enhanced video encoding and decoding support, this will need a family-specific compatible when pushed > - Slightly differences in the Video Processing Unit, this is why I introduced family-specific compatibles > - A secondary Cortex-A53 cluster > - A secondary SCPI cpufreq clock entry > - 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? 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> Date: Fri, 03 Mar 2017 11:29:12 -0800 In-Reply-To: (Neil Armstrong's message of "Thu, 2 Mar 2017 13:47:26 +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, linux-clk@vger.kernel.org, carlo@caione.org, linux-amlogic@lists.infradead.org, Andreas =?utf-8?Q?F=C3=A4rber?= , 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+IEhpIEFu ZHJlYXMsCj4gT24gMDMvMDIvMjAxNyAwMTozMSBQTSwgQW5kcmVhcyBGw6RyYmVyIHdyb3RlOgo+ PiBIaSBOZWlsLAo+PiAKPj4gQW0gMDEuMDMuMjAxNyB1bSAxMTo0NiBzY2hyaWViIE5laWwgQXJt c3Ryb25nOgo+Pj4gVGhlIHNhbWUgTUFMSS00NTAgTVAzIEdQVSBpcyBwcmVzZW50IGluIHRoZSBH WEJCIGFuZCBHWEwgU29Dcy4KPj4gCj4+IEZpcnN0IG9mIGFsbCwgYW55IHJlYXNvbiB5b3UncmUg dXBwZXItY2FzaW5nIE1hbGkgaW4gdGhlIGNvbW1pdCBtZXNzYWdlPwo+PiBBUk0gZG9lc24ndC4K Pgo+IE5vIHJlYXNvbiwgb25seSBhIHR5cGUsIGluZGVlZCBpdCB3YXMgbG93ZXItY2FzaW5nIG9u IHRoZSB2MS4KPiBXaWxsIGZpeCBpbiB2Mi4KPgo+PiAKPj4+Cj4+PiBUaGUgbm9kZSBpcyBzaW1w bHkgYWRkZWQgaW4gdGhlIG1lc29uLWd4YmIuZHRzaSBmaWxlLgo+PiAKPj4gVGhlIEdYQkIgcGFy dCBsb29rcyBmaW5lIG9uIGEgcXVpY2sgbG9vay4KPj4gCj4+Pgo+Pj4gRm9yIEdYTCwgc2luY2Ug YSBsb3QgaXMgc2hhcmVkIHdpdGggdGhlIEdYTSB0aGF0IGhhcyBhIE1BTEktVDgyMCBJUCwgdGhp cwo+Pj4gcGF0Y2ggYWRkcyBhIG5ldyBtZXNvbi1neGwtbWFsaS5kdHNpIGFuZCBpcyBpbmNsdWRl ZCBpbiB0aGUgU29DIHNwZWNpZmljCj4+PiBkdHNpIGZpbGVzLgo+PiAKPj4gVGhpcyBwYXJ0IGlz IHNsaWdodGx5IGNvbmZ1c2luZyB0aG91Z2guCj4+IAo+PiBXaGF0IGV4YWN0bHkgaXMgdGhlIEdY TCB2cy4gR1hNIGRpZmZlcmVuY2UgdGhhdCB0aGlzIGNhbid0IGJlIGhhbmRsZWQgYnkKPj4gb3Zl cnJpZGluZyBub2RlIHByb3BlcnRpZXMgY29tcGF0aWJsZS9pbnRlcnJ1cHRzL2Nsb2Nrcz8gSSBh bSBtaXNzaW5nIGEKPj4gR1hNIHBhdGNoIGluIHRoaXMgc2VyaWVzIGFzIHJhdGlvbmFsZSBmb3Ig ZG9pbmcgaXQgdGhpcyB3YXkuCj4+IAo+PiBJbiBwYXJ0aWN1bGFyIEkgYW0gd29uZGVyaW5nIHdo ZXRoZXIgdGhlIHdob2xlIEdYTS1pbmhlcml0cy1mcm9tLUdYTAo+PiBjb25jZXB0IGlzIGZsYXdl ZCBhbmQgc2hvdWxkIGJlIGFkanVzdGVkIGlmIHRoaXMgbGVhZHMgdG8gc2Vjb25kYXJ5Cj4+IC5k dHNpIGZpbGVzIGxpa2UgdGhpczogTXkgcHJvcG9zYWwgd291bGQgYmUgdG8gaW5zdGVhZCBjcmVh dGUgYQo+PiBtZXNvbi1neGwtZ3htLmR0c2ksIHRoYXQgbWVzb24tZ3hsLmR0c2kgYW5kIG1lc29u LWd4bS5kdHNpIGNhbiBpbmhlcml0Cj4+IHRoZSBjdXJyZW50IGNvbW1vbiBwYXJ0cyBmcm9tLCB0 aGVuIHRoZSBNYWxpIGJpdHMgY2FuIHNpbXBseSBnbyBpbnRvCj4+IG1lc29uLWd4bC5kdHNpIHdp dGhvdXQgZXh0cmEgI2luY2x1ZGVzIG5lZWRlZCBpbiBTOTA1WCBhbmQgUzkwNUQuIFdoaWxlCj4+ IGl0J3Mgc2xpZ2h0bHkgbW9yZSB3b3JrIHRvIHNwbGl0IG9uY2UgYWdhaW4sIEkgdGhpbmsgaXQg d291bGQgYmUgY2xlYW5lci4KPgo+IFRoZSBHWEwgYW5kIEdYTSBkaWZmZXJlbmNlcyBhcmUgdmVy eSBzbWFsbCA6Cj4gIC0gVGhleSBzaGFyZSB0aGUgc2FtZSBjbG9jayB0cmVlCj4gIC0gVGhleSBz aGFyZSB0aGUgc2FtZSBwaW5jdHJsIGFuZCBldmVuIHRoZSBzYW1lIHBpbm91dCAoUzkwNUQgYW5k IFM5MTIgYXJlIHBpbi10by1waW4gY29tcGF0aWJsZSkKPiAgLSBUaGV5IHNoYXJlIGFsbCB0aGUg cGVyaXBoZXJhbHMKPgo+IFRoZSBvbmx5IGNoYW5nZXMgYXJlIDoKPiAgLSBFbmhhbmNlZCB2aWRl byBlbmNvZGluZyBhbmQgZGVjb2Rpbmcgc3VwcG9ydCwgdGhpcyB3aWxsIG5lZWQgYSBmYW1pbHkt c3BlY2lmaWMgY29tcGF0aWJsZSB3aGVuIHB1c2hlZAo+ICAtIFNsaWdodGx5IGRpZmZlcmVuY2Vz IGluIHRoZSBWaWRlbyBQcm9jZXNzaW5nIFVuaXQsIHRoaXMgaXMgd2h5IEkgaW50cm9kdWNlZCBm YW1pbHktc3BlY2lmaWMgY29tcGF0aWJsZXMKPiAgLSBBIHNlY29uZGFyeSBDb3J0ZXgtQTUzIGNs dXN0ZXIKPiAgLSBBIHNlY29uZGFyeSBTQ1BJIGNwdWZyZXEgY2xvY2sgZW50cnkKPiAgLSBBIGRp ZmZlcmVudCBNYWxpIGNvcmUsIGJ1dCB3aXRoIHRoZSBzYW1lIGludGVycnVwdHMgKGxlc3MgYnV0 IHRoZXkgc2hhcmUgdGhlIHNhbWUgbG93ZXIgaW50ZXJydXB0cyksIGNsb2NrcyBhbmQgbWVtb3J5 IHNwYWNlCj4KPiBUaGlzIGlzIHdoeSBpdCB3YXMgZGVjaWRlZCB0byBoYXZlIGEgc3ViLWR0c2ks IGhhdmluZyBhIHNlY29uZGFyeSBkdHNpIHdpbGwgc2ltcGx5IGNvcHkgOTklIG9mIHRoZSBHWEwg ZHRzaSwKPiBidXQgc3VyZWx5IHdlIGNvdWxkIGFsc28gaGF2ZSBhbiBpbnRlcm1lZGlhdGUgZHRz aSBidXQgZm9yIGJvYXJkcyBJJ20gb2sgd2l0aCBpdCwgYnV0IGxlc3MgZm9yIGEgU29DIGR0c2ks Cj4gc2luY2UgaXQgY291bGQgbGVhZCB0byBzb21lIGNvbmZ1c2lvbi4KPgo+IEZpbmFsbHksIHll cyBJIGNvdWxkIGhhdmUgYWRkZWQgdGhlIG1hbGkgbm9kZSB0byB0aGUgR1hMIGR0c2ksIGJ1dCB0 aGUgbWlkZ2FyZCBNYWxpIGR0LWJpbmRpbmdzIGFyZSBub3QgdXBzdHJlYW0KPiBhbmQgdGhlIGZh bWlseSBpcyB0b28gYmlnIGFuZCByZWNlbnQgZW5vdWdoIHRvIGNvbnNpZGVyIGhhdmluZyBzdGFi bGUgYmluZGluZ3MgZm9yIG5vdy4KPgo+IE5ldmVydGhlbGVzcywgbm90aGluZyBpcyBmaW5hbCwg dGhpcyBneGwtbWFsaS5kdHNpIGNvdWxkIGJlIG1lcmdlZCBpbnRvIHRoZSBHWEwgZHRzaSBpbiB0 aGUgZnV0dXJlIHdoZW4gd2UKPiBoYXZlIHByb3BlciBkdC1iaW5kaW5ncyBhbmQgYSByZWFsIHN1 cHBvcnQgb2YgdGhlIFQ4MjAgTWFsaSBvbiB0aGUgUzkxMi4KPgo+IEtldmluLCB3aGF0J3MgeW91 ciB0aG91Z2h0IGFib3V0IHRoaXMgPwoKSSBkb24ndCBoYXZlIGEgc3Ryb25nIHByZWZlcmVuY2Uu ICBJJ20gT0sgd2l0aCBhIHNlcGFyYXRlIE1hbGkgLmR0c2kgZHVlCnRvIHRoZSBzaWduZmljYW50 IG92ZXJsYXAgYmV0d2VlbiBHWEwvR1hNIGluIHRlcm1zIG9mIGNsb2NrcywgaW50ZXJydXB0cwpl dGMuCgpIb3dldmVyLCBpZiB0aGUgcGxhbiBpcyB0byAjaW5jbHVkZSB0aGlzIGZyb20gR1hNIC5k dHMgZmlsZXMsIHdob3VsZCBhCmJldHRlciBuYW1lIGJlIG1lc29uLWd4LW1hbGkuZHRzaT8KCktl dmluCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpsaW51 eC1hbWxvZ2ljIG1haWxpbmcgbGlzdApsaW51eC1hbWxvZ2ljQGxpc3RzLmluZnJhZGVhZC5vcmcK aHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1hbWxvZ2lj Cg== From mboxrd@z Thu Jan 1 00:00:00 1970 From: khilman@baylibre.com (Kevin Hilman) Date: Fri, 03 Mar 2017 11:29:12 -0800 Subject: [PATCH v2 3/3] ARM64: dts: meson-gx: Add MALI nodes for GXBB and GXL In-Reply-To: (Neil Armstrong's message of "Thu, 2 Mar 2017 13:47:26 +0100") References: <1488365164-22861-1-git-send-email-narmstrong@baylibre.com> <1488365164-22861-4-git-send-email-narmstrong@baylibre.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Neil Armstrong writes: > Hi Andreas, > On 03/02/2017 01:31 PM, Andreas F?rber wrote: >> Hi Neil, >> >> Am 01.03.2017 um 11:46 schrieb Neil Armstrong: >>> The same MALI-450 MP3 GPU is present in the GXBB and GXL SoCs. >> >> First of all, any reason you're upper-casing Mali in the commit message? >> ARM doesn't. > > No reason, only a type, indeed it was lower-casing on the v1. > Will fix in v2. > >> >>> >>> The node is simply added in the meson-gxbb.dtsi file. >> >> The GXBB part looks fine on a quick look. >> >>> >>> 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 GXL and GXM differences are very small : > - They share the same clock tree > - They share the same pinctrl and even the same pinout (S905D and S912 are pin-to-pin compatible) > - They share all the peripherals > > The only changes are : > - Enhanced video encoding and decoding support, this will need a family-specific compatible when pushed > - Slightly differences in the Video Processing Unit, this is why I introduced family-specific compatibles > - A secondary Cortex-A53 cluster > - A secondary SCPI cpufreq clock entry > - 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? 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: Fri, 03 Mar 2017 11:29:12 -0800 Message-ID: References: <1488365164-22861-1-git-send-email-narmstrong@baylibre.com> <1488365164-22861-4-git-send-email-narmstrong@baylibre.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: (Neil Armstrong's message of "Thu, 2 Mar 2017 13:47:26 +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, linux-clk@vger.kernel.org, carlo@caione.org, linux-amlogic@lists.infradead.org, Andreas =?utf-8?Q?F=C3=A4rber?= , linux-arm-kernel@lists.infradead.org List-Id: devicetree@vger.kernel.org TmVpbCBBcm1zdHJvbmcgPG5hcm1zdHJvbmdAYmF5bGlicmUuY29tPiB3cml0ZXM6Cgo+IEhpIEFu ZHJlYXMsCj4gT24gMDMvMDIvMjAxNyAwMTozMSBQTSwgQW5kcmVhcyBGw6RyYmVyIHdyb3RlOgo+ PiBIaSBOZWlsLAo+PiAKPj4gQW0gMDEuMDMuMjAxNyB1bSAxMTo0NiBzY2hyaWViIE5laWwgQXJt c3Ryb25nOgo+Pj4gVGhlIHNhbWUgTUFMSS00NTAgTVAzIEdQVSBpcyBwcmVzZW50IGluIHRoZSBH WEJCIGFuZCBHWEwgU29Dcy4KPj4gCj4+IEZpcnN0IG9mIGFsbCwgYW55IHJlYXNvbiB5b3UncmUg dXBwZXItY2FzaW5nIE1hbGkgaW4gdGhlIGNvbW1pdCBtZXNzYWdlPwo+PiBBUk0gZG9lc24ndC4K Pgo+IE5vIHJlYXNvbiwgb25seSBhIHR5cGUsIGluZGVlZCBpdCB3YXMgbG93ZXItY2FzaW5nIG9u IHRoZSB2MS4KPiBXaWxsIGZpeCBpbiB2Mi4KPgo+PiAKPj4+Cj4+PiBUaGUgbm9kZSBpcyBzaW1w bHkgYWRkZWQgaW4gdGhlIG1lc29uLWd4YmIuZHRzaSBmaWxlLgo+PiAKPj4gVGhlIEdYQkIgcGFy dCBsb29rcyBmaW5lIG9uIGEgcXVpY2sgbG9vay4KPj4gCj4+Pgo+Pj4gRm9yIEdYTCwgc2luY2Ug YSBsb3QgaXMgc2hhcmVkIHdpdGggdGhlIEdYTSB0aGF0IGhhcyBhIE1BTEktVDgyMCBJUCwgdGhp cwo+Pj4gcGF0Y2ggYWRkcyBhIG5ldyBtZXNvbi1neGwtbWFsaS5kdHNpIGFuZCBpcyBpbmNsdWRl ZCBpbiB0aGUgU29DIHNwZWNpZmljCj4+PiBkdHNpIGZpbGVzLgo+PiAKPj4gVGhpcyBwYXJ0IGlz IHNsaWdodGx5IGNvbmZ1c2luZyB0aG91Z2guCj4+IAo+PiBXaGF0IGV4YWN0bHkgaXMgdGhlIEdY TCB2cy4gR1hNIGRpZmZlcmVuY2UgdGhhdCB0aGlzIGNhbid0IGJlIGhhbmRsZWQgYnkKPj4gb3Zl cnJpZGluZyBub2RlIHByb3BlcnRpZXMgY29tcGF0aWJsZS9pbnRlcnJ1cHRzL2Nsb2Nrcz8gSSBh bSBtaXNzaW5nIGEKPj4gR1hNIHBhdGNoIGluIHRoaXMgc2VyaWVzIGFzIHJhdGlvbmFsZSBmb3Ig ZG9pbmcgaXQgdGhpcyB3YXkuCj4+IAo+PiBJbiBwYXJ0aWN1bGFyIEkgYW0gd29uZGVyaW5nIHdo ZXRoZXIgdGhlIHdob2xlIEdYTS1pbmhlcml0cy1mcm9tLUdYTAo+PiBjb25jZXB0IGlzIGZsYXdl ZCBhbmQgc2hvdWxkIGJlIGFkanVzdGVkIGlmIHRoaXMgbGVhZHMgdG8gc2Vjb25kYXJ5Cj4+IC5k dHNpIGZpbGVzIGxpa2UgdGhpczogTXkgcHJvcG9zYWwgd291bGQgYmUgdG8gaW5zdGVhZCBjcmVh dGUgYQo+PiBtZXNvbi1neGwtZ3htLmR0c2ksIHRoYXQgbWVzb24tZ3hsLmR0c2kgYW5kIG1lc29u LWd4bS5kdHNpIGNhbiBpbmhlcml0Cj4+IHRoZSBjdXJyZW50IGNvbW1vbiBwYXJ0cyBmcm9tLCB0 aGVuIHRoZSBNYWxpIGJpdHMgY2FuIHNpbXBseSBnbyBpbnRvCj4+IG1lc29uLWd4bC5kdHNpIHdp dGhvdXQgZXh0cmEgI2luY2x1ZGVzIG5lZWRlZCBpbiBTOTA1WCBhbmQgUzkwNUQuIFdoaWxlCj4+ IGl0J3Mgc2xpZ2h0bHkgbW9yZSB3b3JrIHRvIHNwbGl0IG9uY2UgYWdhaW4sIEkgdGhpbmsgaXQg d291bGQgYmUgY2xlYW5lci4KPgo+IFRoZSBHWEwgYW5kIEdYTSBkaWZmZXJlbmNlcyBhcmUgdmVy eSBzbWFsbCA6Cj4gIC0gVGhleSBzaGFyZSB0aGUgc2FtZSBjbG9jayB0cmVlCj4gIC0gVGhleSBz aGFyZSB0aGUgc2FtZSBwaW5jdHJsIGFuZCBldmVuIHRoZSBzYW1lIHBpbm91dCAoUzkwNUQgYW5k IFM5MTIgYXJlIHBpbi10by1waW4gY29tcGF0aWJsZSkKPiAgLSBUaGV5IHNoYXJlIGFsbCB0aGUg cGVyaXBoZXJhbHMKPgo+IFRoZSBvbmx5IGNoYW5nZXMgYXJlIDoKPiAgLSBFbmhhbmNlZCB2aWRl byBlbmNvZGluZyBhbmQgZGVjb2Rpbmcgc3VwcG9ydCwgdGhpcyB3aWxsIG5lZWQgYSBmYW1pbHkt c3BlY2lmaWMgY29tcGF0aWJsZSB3aGVuIHB1c2hlZAo+ICAtIFNsaWdodGx5IGRpZmZlcmVuY2Vz IGluIHRoZSBWaWRlbyBQcm9jZXNzaW5nIFVuaXQsIHRoaXMgaXMgd2h5IEkgaW50cm9kdWNlZCBm YW1pbHktc3BlY2lmaWMgY29tcGF0aWJsZXMKPiAgLSBBIHNlY29uZGFyeSBDb3J0ZXgtQTUzIGNs dXN0ZXIKPiAgLSBBIHNlY29uZGFyeSBTQ1BJIGNwdWZyZXEgY2xvY2sgZW50cnkKPiAgLSBBIGRp ZmZlcmVudCBNYWxpIGNvcmUsIGJ1dCB3aXRoIHRoZSBzYW1lIGludGVycnVwdHMgKGxlc3MgYnV0 IHRoZXkgc2hhcmUgdGhlIHNhbWUgbG93ZXIgaW50ZXJydXB0cyksIGNsb2NrcyBhbmQgbWVtb3J5 IHNwYWNlCj4KPiBUaGlzIGlzIHdoeSBpdCB3YXMgZGVjaWRlZCB0byBoYXZlIGEgc3ViLWR0c2ks IGhhdmluZyBhIHNlY29uZGFyeSBkdHNpIHdpbGwgc2ltcGx5IGNvcHkgOTklIG9mIHRoZSBHWEwg ZHRzaSwKPiBidXQgc3VyZWx5IHdlIGNvdWxkIGFsc28gaGF2ZSBhbiBpbnRlcm1lZGlhdGUgZHRz aSBidXQgZm9yIGJvYXJkcyBJJ20gb2sgd2l0aCBpdCwgYnV0IGxlc3MgZm9yIGEgU29DIGR0c2ks Cj4gc2luY2UgaXQgY291bGQgbGVhZCB0byBzb21lIGNvbmZ1c2lvbi4KPgo+IEZpbmFsbHksIHll cyBJIGNvdWxkIGhhdmUgYWRkZWQgdGhlIG1hbGkgbm9kZSB0byB0aGUgR1hMIGR0c2ksIGJ1dCB0 aGUgbWlkZ2FyZCBNYWxpIGR0LWJpbmRpbmdzIGFyZSBub3QgdXBzdHJlYW0KPiBhbmQgdGhlIGZh bWlseSBpcyB0b28gYmlnIGFuZCByZWNlbnQgZW5vdWdoIHRvIGNvbnNpZGVyIGhhdmluZyBzdGFi bGUgYmluZGluZ3MgZm9yIG5vdy4KPgo+IE5ldmVydGhlbGVzcywgbm90aGluZyBpcyBmaW5hbCwg dGhpcyBneGwtbWFsaS5kdHNpIGNvdWxkIGJlIG1lcmdlZCBpbnRvIHRoZSBHWEwgZHRzaSBpbiB0 aGUgZnV0dXJlIHdoZW4gd2UKPiBoYXZlIHByb3BlciBkdC1iaW5kaW5ncyBhbmQgYSByZWFsIHN1 cHBvcnQgb2YgdGhlIFQ4MjAgTWFsaSBvbiB0aGUgUzkxMi4KPgo+IEtldmluLCB3aGF0J3MgeW91 ciB0aG91Z2h0IGFib3V0IHRoaXMgPwoKSSBkb24ndCBoYXZlIGEgc3Ryb25nIHByZWZlcmVuY2Uu ICBJJ20gT0sgd2l0aCBhIHNlcGFyYXRlIE1hbGkgLmR0c2kgZHVlCnRvIHRoZSBzaWduZmljYW50 IG92ZXJsYXAgYmV0d2VlbiBHWEwvR1hNIGluIHRlcm1zIG9mIGNsb2NrcywgaW50ZXJydXB0cwpl dGMuCgpIb3dldmVyLCBpZiB0aGUgcGxhbiBpcyB0byAjaW5jbHVkZSB0aGlzIGZyb20gR1hNIC5k dHMgZmlsZXMsIHdob3VsZCBhCmJldHRlciBuYW1lIGJlIG1lc29uLWd4LW1hbGkuZHRzaT8KCktl dmluCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpsaW51 eC1hcm0ta2VybmVsIG1haWxpbmcgbGlzdApsaW51eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVh ZC5vcmcKaHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1h cm0ta2VybmVsCg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752208AbdCCVWX (ORCPT ); Fri, 3 Mar 2017 16:22:23 -0500 Received: from mail-pg0-f43.google.com ([74.125.83.43]:35511 "EHLO mail-pg0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751821AbdCCVWW (ORCPT ); Fri, 3 Mar 2017 16:22:22 -0500 From: Kevin Hilman To: Neil Armstrong Cc: Andreas =?utf-8?Q?F=C3=A4rber?= , sboyd@codeaurora.org, carlo@caione.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-amlogic@lists.infradead.org, linux-clk@vger.kernel.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> Date: Fri, 03 Mar 2017 11:29:12 -0800 In-Reply-To: (Neil Armstrong's message of "Thu, 2 Mar 2017 13:47:26 +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 v23LMbGQ023970 Neil Armstrong writes: > Hi Andreas, > On 03/02/2017 01:31 PM, Andreas Färber wrote: >> Hi Neil, >> >> Am 01.03.2017 um 11:46 schrieb Neil Armstrong: >>> The same MALI-450 MP3 GPU is present in the GXBB and GXL SoCs. >> >> First of all, any reason you're upper-casing Mali in the commit message? >> ARM doesn't. > > No reason, only a type, indeed it was lower-casing on the v1. > Will fix in v2. > >> >>> >>> The node is simply added in the meson-gxbb.dtsi file. >> >> The GXBB part looks fine on a quick look. >> >>> >>> 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 GXL and GXM differences are very small : > - They share the same clock tree > - They share the same pinctrl and even the same pinout (S905D and S912 are pin-to-pin compatible) > - They share all the peripherals > > The only changes are : > - Enhanced video encoding and decoding support, this will need a family-specific compatible when pushed > - Slightly differences in the Video Processing Unit, this is why I introduced family-specific compatibles > - A secondary Cortex-A53 cluster > - A secondary SCPI cpufreq clock entry > - 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? Kevin