Date: Thu, 08 Jan 2015 08:52:21 -0700 From: Ian Lepore <ian@freebsd.org> To: Scott Ellis <scott@jumpnowtek.com> Cc: freebsd-arm@freebsd.org Subject: Re: Proposed patch for omap443x.dtsi Message-ID: <1420732341.14601.124.camel@freebsd.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <interrupts> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1420732341.14601.124.camel>