Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754585AbaFXPUe (ORCPT ); Tue, 24 Jun 2014 11:20:34 -0400 Received: from mail-ve0-f173.google.com ([209.85.128.173]:64505 "EHLO mail-ve0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754554AbaFXPUc (ORCPT ); Tue, 24 Jun 2014 11:20:32 -0400 MIME-Version: 1.0 In-Reply-To: <53A94DA1.50703@collabora.co.uk> References: <1403486483-4063-1-git-send-email-afaerber@suse.de> <1403486483-4063-5-git-send-email-afaerber@suse.de> <53A8AE4C.6080702@suse.de> <53A94DA1.50703@collabora.co.uk> Date: Tue, 24 Jun 2014 08:20:30 -0700 X-Google-Sender-Auth: QvjQAXgHiMHQ2OviNBM07wtm6IE Message-ID: Subject: Re: [RFC 4/4] ARM: dts: exynos5250: Add Spring device tree From: Doug Anderson To: Javier Martinez Canillas Cc: =?UTF-8?Q?Andreas_F=C3=A4rber?= , linux-samsung-soc , Stephan van Schaik , Vincent Palatin , Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , Russell King , Ben Dooks , Kukjin Kim , "OPEN FIRMWARE AND..." , ARM PORT , LKML , Olof Johansson , Todd Broch , Tomasz Figa , jwerner@chromium.org Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Javier, On Tue, Jun 24, 2014 at 3:06 AM, Javier Martinez Canillas wrote: > Hello Doug, > > On 06/24/2014 06:05 AM, Doug Anderson wrote: > Another option is to identify DTS fragments that are common across boards and > create .dtsi files for these specific chunks instead of trying to group all set > of common things on a single .dtsi file. > > For example, a quite common design for OMAP2+ based boards is to use a SMSC LAN > chip connected to OMAP's General-Purpose Memory Controller (GPMC). So the > following files were created to reduce DTS duplication: > > arch/arm/boot/dts/omap-gpmc-smsc911x.dtsi > arch/arm/boot/dts/omap-gpmc-smsc9221.dtsi > > Now that I think about it, is the same that what you did for > arm/boot/dts/cros-ec-keyboard.dtsi. > > Maybe splitting exynos5250-cros-common.dtsi in a set of .dtsi files will make it > more flexible/reusable? Yes, I think the config fragments can be cleaner but I think we have to be judicious about using them. There are definitely tradeoffs involved. The keyboard was such an excessively large thing and totally duplicated, so moving it out made sense. Other bits are less obvious (to me) because there are so many interactions / combinations and you end up with a bit of spaghetti in terms of which labels are used by and provided by each fragment. I guess possibly you could codify that better... A few thoughts looking at exynos5420-peach-pit: * backlight: seems (?) too board specific * samsung,exynos5420-oscclk: could totally be a fragment, but very small. * power key: could be a fragment for all boards that happen to use gpx1-2 for this * sound: could be a fragment for all devices using "google,snow-audio-max98090", possibly. > Personally I think that "status = [enabled | disabled]" only makes sense for IP > blocks that are part of the SoC but may or may not be used by a board (e.g: i2c > and spi buses, sdhci and usb host controllers, etc). > > DTS should be a description of the hardware so I agree that having a disabled > node for a device that is not present in the board is not right. Right. We'll take a look again in v2 when cros-common isn't used. I think this could go in steps: 1. Don't use cros-common for spring 2. Don't use cros-common for snow (fold stuff in) 3. Introduce some fragments. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/