Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751974AbbFREVy (ORCPT ); Thu, 18 Jun 2015 00:21:54 -0400 Received: from bh-25.webhostbox.net ([208.91.199.152]:42664 "EHLO bh-25.webhostbox.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751391AbbFREVq (ORCPT ); Thu, 18 Jun 2015 00:21:46 -0400 Message-ID: <55824756.7030009@roeck-us.net> Date: Wed, 17 Jun 2015 21:21:42 -0700 From: Guenter Roeck User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Rob Herring , Pantelis Antoniou CC: Grant Likely , Matt Porter , Koen Kooi , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Pantelis Antoniou Subject: Re: [PATCH 1/8] of: overlay: Implement indirect target support References: <1434138905-15886-1-git-send-email-pantelis.antoniou@konsulko.com> <1434138905-15886-2-git-send-email-pantelis.antoniou@konsulko.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated_sender: linux@roeck-us.net X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - bh-25.webhostbox.net X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - roeck-us.net X-Get-Message-Sender-Via: bh-25.webhostbox.net: authenticated_id: linux@roeck-us.net X-Source: X-Source-Args: X-Source-Dir: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3907 Lines: 102 On 06/17/2015 05:10 PM, Rob Herring wrote: > On Fri, Jun 12, 2015 at 2:54 PM, Pantelis Antoniou > wrote: >> Some applications require applying the same overlay to a different >> target according to some external condition (for instance depending >> on the slot a card has been inserted, the overlay target is different). >> >> The indirect target use requires using the new >> of_overlay_create_indirect() API which uses a text selector. >> >> The format requires the use of a target-indirect node as follows: >> >> fragment@0 { >> target-indirect { >> foo { target = <&foo_target>; }; >> bar { target = <&bar_target>; }; >> }; >> }; > > The problem with this is it does not scale. The overlay has to be > changed for every new target. If you had an add-on board (possibly Not really. For our use case, at least, each target is a slot in the chassis, so we end up with something like target-indirect { slot0 { target = <&sib0i2c>; }; slot1 { target = <&sib1i2c>; }; slot2 { target = <&sib2i2c>; }; slot3 { target = <&sib3i2c>; }; slot4 { target = <&sib4i2c>; }; slot5 { target = <&sib5i2c>; }; slot6 { target = <&sib6i2c>; }; slot7 { target = <&sib7i2c>; }; slot8 { target = <&sib8i2c>; }; }; where sib[0-8]i2c is defined in the master dts file. Since the number of slots is well defined, the overlay will always work. Sure, it may have to be updated if it is used in a chassis with 20 slots, but that doesn't happen that often. > providing an overlay from an EEPROM), you would not want to have to > rebuild overlays with every new host board. It also only handles > translations of where to apply the overlay, but doesn't provide > translations of phandles within the overlay. Say a node that is a > clock or regulator consumer for example. Or am I missing something. > > Grant and I discussed this briefly. I think we need a connector > definition in the base dtb which can provide the target for an > overlay. The connector should provide the translation between > connector local signals/buses and host signals/buses. We need to > define what this translation would look like for each binding. > > At least for GPIO, we could have something similar to interrupt-map > properties. For example, to map connector gpio 0 to host gpio 66 and > connector gpio 1 to host gpio 44: > > gpio-map = <0 &host-gpio 66>, <1 &host-gpio 44>; > > We'd need to define how to handle I2C, SPI, regulators, and clocks > minimally. Perhaps rather than trying to apply nodes into the base > dtb, they should be under the connector and the kernel has to learn to > not just look for child nodes for various bindings. Just thinking > aloud... > Anything is fine with me, as long as it is usable (and does not require us to create 9 overlay files for sib[0-8] from the example above). The real tricky part is pci, where it is not just about simple target redirection but irq numbers, memory address ranges, and bus number ranges. It would be quite useful to have a workable solution for that as well, but at least I don't have an idea how it could be done. Talking about connector ... Right now we have something like sib0 { compatible = "jnx,sib-connector", "simple-bus"; ... (various properties) }; Maybe we could use something like the following ? sib0 { compatible = "jnx,sib-connector", "simple-bus"; ... (various attributes) ref0 = <&sib0i2c>; ref1 = <&sib0spi>; }; and then just reference ref0 and ref1 as targets in the overlay itself ? Guenter -- 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/