Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 8 Jan 2015 07:35:24 -0700 (MST)
From:      Scott Ellis <scott@jumpnowtek.com>
To:        freebsd-arm@freebsd.org
Subject:   Re: Proposed patch for omap443x.dtsi
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>

next in thread | previous in thread | raw e-mail | index | archive | help
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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1420727724637-5979285.post>