From owner-freebsd-arm@FreeBSD.ORG Thu Jan 8 15:52:30 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D02DB385 for ; Thu, 8 Jan 2015 15:52:30 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9145B120 for ; Thu, 8 Jan 2015 15:52:30 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Y9FNm-000JIG-Fe; Thu, 08 Jan 2015 15:52:22 +0000 Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t08FqLub003655; Thu, 8 Jan 2015 08:52:21 -0700 (MST) (envelope-from ian@freebsd.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+pPAIZHQCJTGD2UB4w9DpX Message-ID: <1420732341.14601.124.camel@freebsd.org> Subject: Re: Proposed patch for omap443x.dtsi From: Ian Lepore To: Scott Ellis Date: Thu, 08 Jan 2015 08:52:21 -0700 In-Reply-To: <1420727724637-5979285.post@n5.nabble.com> References: <1420646915323-5979090.post@n5.nabble.com> <7B282FBD-180A-46C5-9D1A-FA924831BCF2@bsdimp.com> <1420674783.14601.81.camel@freebsd.org> <1420727724637-5979285.post@n5.nabble.com> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.12.8 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 15:52:31 -0000 On Thu, 2015-01-08 at 07:35 -0700, Scott Ellis wrote: > The Linux dts files are all GPL. > > How is this normally handled? > The files are imported into sys/gnu/dts/, beyond that (legal stuff) I dunno. > Besides the clocks and pin muxing Ian mentioned, general properties > like are defined differently as well. > [...] FreeBSD is ready to handle the proper style for interrupt properties when the interrupt controller is an ARM PL390 GIC, including the interrupts-extended format. For SoCs that have a non-GIC controller some code changes might be needed in the controller drivers. > > Not sure why FreeBSD uses a convention of adding +32 to the > IRQ numbers. I suspect that's an actual usage offset (I didn't > check). > The FDT standard for the GIC divides the interrupt numbering space into private (per-core) versus shared peripheral interrupts and restarts the numbering at zero in each space. The original FreeBSD homegrown dts just used a 0-n linear numbering. There is code in the GIC driver that handles both cases. > Linux uses the MA_IRQ_XX values directly from the tables in the > TRM in their dts files. > > > I don't mind working on this if compatibility with the Linux > dts files is the end goal. > The actual goal is to conform to the documented bindings, but as a practical matter that means compatibility with the published dts files. If some vendor-written file doesn't quite follow the documented bindings but works on linux, then we'll need to not-quite-follow in the same way. > I'd rather do it incrementally working within the FreeBSD tree > instead of an extended side project managing merge conflicts > myself. > As I've been doing this so far I've managed to do driver tweaks in such a way that our old homegrown and the published files both work. That makes doing the conversion as an incremental set of changes practical. Often there's not much more to it than accepting old and new compatible strings, and sometimes assuming reasonable defaults for some homegrown property we added that won't be present in the published files. The only soc we have right now that runs 100% on published fdt data without any homegrown properties added is imx6, so you can find some example code in the arm/freescale/imx directory. For TI there's the added wrinkle of sharing some code between OMAP4 and AM335x, so a few drivers have to conform to two sets of published bindings, but I'll bet TI has made that easy to do with some sensible commonality in how they defined things. > What if I renamed my omap443x.dtsi -> omap4.dtsi and started > from that? > > I do have two types of OMAP4430 boards to test with. > > I did have an OMAP4460 board from another project that I gave > back to the customer when it ended. I can see about getting > another. When I did this for imx6 I incrementally changed our homegrown dts/dtsi files to become ever more like the published files (but stripped down to just the devices we actually support) until one day I realized we were able to just cut over to the files in sys/gnu and stop using our homegrown ones. That should work okay for omap/am335x too I think. If we do make new files along the way we should probably ensure our names don't clash with the names that will be in sys/gnu or we'll have trouble with include statements. The bindings documentation and the published dts(i) files can be viewed here... https://github.com/torvalds/linux/tree/master/Documentation/devicetree/bindings https://github.com/torvalds/linux/tree/master/arch/arm/boot/dts -- Ian