From owner-freebsd-arm@FreeBSD.ORG  Thu Jan  8 14:35:26 2015
Return-Path: <owner-freebsd-arm@FreeBSD.ORG>
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 688D33D5
 for <freebsd-arm@freebsd.org>; Thu,  8 Jan 2015 14:35:26 +0000 (UTC)
Received: from mwork.nabble.com (mwork.nabble.com [162.253.133.43])
 by mx1.freebsd.org (Postfix) with ESMTP id 51A628DE
 for <freebsd-arm@freebsd.org>; Thu,  8 Jan 2015 14:35:25 +0000 (UTC)
Received: from msam.nabble.com (unknown [162.253.133.85])
 by mwork.nabble.com (Postfix) with ESMTP id 08947FE45FB
 for <freebsd-arm@freebsd.org>; Thu,  8 Jan 2015 06:35:26 -0800 (PST)
Date: Thu, 8 Jan 2015 07:35:24 -0700 (MST)
From: Scott Ellis <scott@jumpnowtek.com>
To: freebsd-arm@freebsd.org
Message-ID: <1420727724637-5979285.post@n5.nabble.com>
In-Reply-To: <1420674783.14601.81.camel@freebsd.org>
References: <1420646915323-5979090.post@n5.nabble.com>
 <7B282FBD-180A-46C5-9D1A-FA924831BCF2@bsdimp.com>
 <1420674783.14601.81.camel@freebsd.org>
Subject: Re: Proposed patch for omap443x.dtsi
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-BeenThere: freebsd-arm@freebsd.org
X-Mailman-Version: 2.1.18-1
Precedence: list
List-Id: "Porting FreeBSD to ARM processors." <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
 <mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm/>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
 <mailto:freebsd-arm-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Jan 2015 14:35:26 -0000

The Linux dts files are all GPL. 

How is this normally handled?

Besides the clocks and pin muxing Ian mentioned, general properties
like <interrupts> are defined differently as well.

FreeBSD

uart2: serial@4806c000 {
    compatible = "ti,ns16550";
    reg = <0x4806c000 0x400>;
    reg-shift = <2>;
    interrupts = < 105 >;
    interrupt-parent = <&GIC>;
    clock-frequency = <48000000>;
    uart-device-id = <1>;
};

Linux (3.18 omap4.dtsi)

uart2: serial@4806c000 {
    compatible = "ti,omap4-uart";
    reg = <0x4806c000 0x100>;
    interrupts-extended = <&gic GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
    ti,hwmods = "uart2";
    clock-frequency = <48000000>;
};

FreeBSD

i2c1: i2c@48070000 {
    compatible = "ti,i2c";
    reg = < 0x48070000 0x100 >;
    interrupts = <88>;
    interrupt-parent = <&GIC>;
    i2c-device-id = <1>;
    clock-frequency = <100000>;
};

Linux (3.18 omap4.dtsi)

i2c1: i2c@48070000 {
    compatible = "ti,omap4-i2c";
    reg = <0x48070000 0x100>;
    interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>;
    #address-cells = <1>;
    #size-cells = <0>;
    ti,hwmods = "i2c1";
};


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). 

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.

I'd rather do it incrementally working within the FreeBSD tree
instead of an extended side project managing merge conflicts
myself.

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.




--
View this message in context: http://freebsd.1045724.n5.nabble.com/Proposed-patch-for-omap443x-dtsi-tp5979090p5979285.html
Sent from the freebsd-arm mailing list archive at Nabble.com.