From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Syn Subject: Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition Date: Tue, 13 May 2014 13:24:03 -0700 Message-ID: References: <1399686184-1594-1-git-send-email-mranostay@gmail.com> <20140512195050.GB5668@atomide.com> <20140512201517.GC5668@atomide.com> <20140512204213.GD5668@atomide.com> <537215D3.70306@ti.com> <20140513142252.GG32082@beef> <4BCFCB24-9732-4B96-B814-5290CA2D0EE4@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: Sender: linux-omap-owner@vger.kernel.org To: Javier Martinez Canillas , Pantelis Antoniou Cc: Matt Porter , Tom Rini , Robert Nelson , Tony Lindgren , Matt Ranostay , robh+dt@kernel.org, Mark Rutland , Russell King , "linux-omap@vger.kernel.org" , devicetree , linux kernel List-Id: devicetree@vger.kernel.org On 5/13/14, 10:51 AM, "Javier Martinez Canillas" wrote: >Hello Pantelis, > >On Tue, May 13, 2014 at 7:07 PM, Pantelis Antoniou > wrote: >> Hi Javier, >> >> On May 13, 2014, at 7:39 AM, Javier Martinez Canillas wrote: >> >>> On Tue, May 13, 2014 at 4:22 PM, Matt Porter >>>wrote: >>>> On Tue, May 13, 2014 at 04:06:02PM +0200, Javier Martinez Canillas >>>>wrote: >>>>> On Tue, May 13, 2014 at 2:53 PM, Tom Rini wrote: >>>>>> On 05/12/2014 04:57 PM, Robert Nelson wrote: >>>>>>>>> Either case if fine with me. As who knows when the dtc >>>>>>>>>"overlay" will >>>>>>>>> every truly make it mainline, as the capemgr was the only rea= l >>>>>>>>>kernel >>>>>>>>> user of the i2c/at24 eeprom information. >>>>>>>> >>>>>>>> Sounds like we should keep it disabled though so u-boot can be >>>>>>>>used >>>>>>>> to toggle it while waiting for the capemgr. That's because the >>>>>>>>board >>>>>>>> has a header for pins, so it's not exactly limited to just the >>>>>>>>capes. >>>>>>>> >>>>>>>> Anybody working on enabling/disabling cape dtb configurations = in >>>>>>>>u-boot? >>>>>>> >>>>>>> Well, >>>>>>> >>>>>>> Would Tom even approve of that in mainline u-boot? He didn't wa= nt >>>>>>>my >>>>>>> "invert" the gpio to enable the usb hub on the older beagle xm >>>>>>>A/B.. >>>>>>> >>>>>>> http://lists.denx.de/pipermail/u-boot/2014-January/172154.html >>>>>>> >>>>>>> http://lists.denx.de/pipermail/u-boot/2014-January/172274.html >>>>> >>>>> Using fdt set from the bootloader to use the same FDT for similar >>>>> boards (like the example with Beagle xM variants) is kind of tryi= ng >>>>>to >>>>> replicate what we used to do from boards files where it was possi= ble >>>>> to manage a set of boards using the same platform code. >>>>> >>>>> But Device Trees are meant to describe hardware and thus should b= e >>>>> static, if two board are almost identical but slightly different, >>>>>then >>>>> are two different hardware where each need its proper FDT that >>>>> describes it. >>>>> >>>>>> >>>>>> I would think that using the 'fdt' command in U-Boot to add all >>>>>> properties of every cape found on a running system would drive >>>>>>someone >>>>>> to madness quite quickly. Moving all of Pantelis' work for dyna= mic >>>>>> device trees from the kernel to N bootloaders (U-Boot, barebox, >>>>>>UEFI, >>>>>> etc) sounds like a step in the wrong direction. >>>>>> >>>>> >>>>> Agreed. I think that until the device tree overlay and the cape >>>>> manager find their way into mainline we should treat capes as if = they >>>>> were expansion boards attached to a Computer-on-Module. That is, = a >>>>> static based board which its own DTS including the BB{B,W} as an = dtsi >>>>> and not something that can be added on runtime. >>>> >>>> It's far more complicated than a SOM plus carrier board. Consider = that >>>> you can have any 4 of these capes stacked on the BBB/BBW in any >>>> combination (assuming no resource conflicts). Capturing all possib= le >>>> combinations in static dtsis is not practical. >>>> >>> >> >> Since this appears to be all coming back to DT overlays, let me try = to >> address some points. >> > >It seems that you misunderstood my comments. I do think that DT >overlays and the cape manager are a great solution for any hardware >that could be expanded on runtime and I really hope that they can >eventually land into mainline. > >In fact if you look on my previous mail you will see that I said: >"until device tree overlay and the cape manager find their way into >mainline..." > >>> Right, I forgot that the capes were stackable so is indeed not >>> practical to model every single combination as DTS in mainline. Eve= n >>> if stacking was not possible there are just too many capes out ther= e >>> to have a DTS for every single cape. >>> >> >> Each cape does have a DTS as dynamically loaded fragment; it works >>absolutely fine. >> >> Trying to come up with a base DTS for all the capes you've stacked u= p >> is an exponential problem. >> >>> My point was that someone who wants to use a BBB + a set of capes c= an >>> today write a DTS for its own stacked setup. >>> >> >> No, the guy that designs a cape (or learns how to) can not write a D= TS >>for >> the base board and the cape in question. Doing that he essentially c= uts >> himself off from the community. >> >> Let me explain, the point is for people to easily design capes, >>open-source their >> design as well as their software, and share them to the community. >> >> This requires that things are easily shareable. >> >> Requiring a relative newbie in kernel development not only generate = his >>own >> base DT, but also to merge all of the other capes DT into his own is= a >> nightmare. >> >> BTW, on another tangent, it's not just the BB people that care about >>dynamic >> hardware configuration. There are a number of FPGA people that seem >>interested >> as well. >> >> The notion of hardware as something static that never changes is >>obsolete IMHO. >> >>> Unfortunately I don't have a solution but what I'm pretty sure is t= hat >>> mangling the DTS from the bootloader is not the right one :-) >>> >> >> No, it is not. And this is what we're trying to solve here. >> > >What I said that I'm against is modifying a FDT using U-Boot scripts >commands that is something that mentioned in this thread. That is not >a robust way to do it and also is not something that a newbie could do >it neither. > >Also, doing these FDT changes in the bootloader has several >disadvantages, besides having to implement on each bootloaders like >Tom said, you need to upgrade your bootloader which is something that >just can't be done on many boards and also is still a static >configuration since you need to reboot in order to use a different >FDT. So the hardware can't really be expanded on runtime unlike with >DT overlays where the overlays are loaded from regular files. > >But I guess you agree with me on all those points and you just >misunderstood my comments. So DT overlays is definitely the way to go >(or something similar) but my point is that until we have that >solution merged, you can use a static DT in mainline for your stacked >cape or use a vendor kernel that already has DT overlays support. Given that we are not hot plugging capes, why do we need to modify the = DT at runtime? Even FPGA developers are not modifying their I/O at runtime= =2E =46or example, using the BBB as a reference, why not add an am335x-cape= -dtsi to the am335x-boneblack.dts as follows: /dts-v1/; /include/ "am33xx.dtsi" /include/ "am335x-bone-common.dtsi=B2 /include/ =B3am335x-cape.dtsi" &am33xx_pinmux { xxx and =B3am335x-cape.dtsi=B2 would look like this: /include/ =B3BB-BONE-AUDI-00A0.dtsi=B2 /include/ =B3BB-BONE-UART1-00A0.dtsi=B2 xxx So, cape developers create their own DTSI and users only update the am335x-cape.dtsi to include the cape DT required. What am I missing?=20 BTW, DTC should be updated to detect I/O conflicts. Waiting for the ker= nel to boot before detecting DT conflicts isn=B9t OK. Regards, John > >I hope I explained myself better this time ;-) > >Best regards, >Javier >-- >To unsubscribe from this list: send the line "unsubscribe linux-omap" = in >the body of a message to majordomo@vger.kernel.org >More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" i= n the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html