Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752159AbdCDMjI (ORCPT ); Sat, 4 Mar 2017 07:39:08 -0500 Received: from mx2.suse.de ([195.135.220.15]:56818 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751472AbdCDMi5 (ORCPT ); Sat, 4 Mar 2017 07:38:57 -0500 Subject: Re: [PATCH v2 3/3] ARM64: dts: meson-gx: Add MALI nodes for GXBB and GXL To: Kevin Hilman , Neil Armstrong References: <1488365164-22861-1-git-send-email-narmstrong@baylibre.com> <1488365164-22861-4-git-send-email-narmstrong@baylibre.com> 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, linux-arm-kernel@lists.infradead.org From: =?UTF-8?Q?Andreas_F=c3=a4rber?= Organization: SUSE Linux GmbH Message-ID: <9f3a17e8-63fa-6c14-4d17-0539ef7cd5a2@suse.de> Date: Sat, 4 Mar 2017 13:38:04 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2920 Lines: 63 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 -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg)