Hi,
On 09/08/2014 07:40 PM, Sergei Shtylyov wrote:
> Hello.
>
> On 9/8/2014 6:10 PM, Roger Quadros wrote:
>
>> The SoC supports 2 DCAN nodes. Add them.
>
>> Signed-off-by: Roger Quadros <rog...@ti.com>
>> ---
>> arch/arm/boot/dts/dra7.dtsi | 30 ++++++++++++++++++++++++++++++
>> 1 file changed, 30 insertions(+)
>
>> diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
>> index 370009e..4ce1a4f 100644
>> --- a/arch/arm/boot/dts/dra7.dtsi
>> +++ b/arch/arm/boot/dts/dra7.dtsi
> [...]
>> @@ -1267,6 +1269,34 @@
>> ti,irqs-skip = <10 133 139 140>;
>> ti,irqs-safe-map = <0>;
>> };
>> +
>> + dcan1: d_can@481cc000 {
>
> The ePAPR standard has something to say here:
>
>>>
> The name of a node should be somewhat generic, reflecting the function of the
> device and not its precise programming model. If appropriate, the name should
> be one of the following choices:
>
> • can
Right. I'll fix it up.
>>>
>
>> + compatible = "bosch,d_can";
>> + ti,hwmods = "dcan1";
>> + reg = <0x4ae3c000 0x2000>,
>> + <0x558 0x4>; /* index to RAMINIT reg within syscon */
>> + raminit-syscon = <&dra7_ctrl_core>;
>> + raminit-start-bit = <3>;
>> + raminit-done-bit = <1>;
>> + raminit-pulse;
>
> Hm, aren't the above 4 properties vendor specific? If so, they should
> start with a vendor prefix and comma.
At least for now I don't know about any other platform other than TI using a
RAMINIT register outside the
CAN register space. However the mechanism is generic enough and not limited to
TI platforms.
I don't mind vendor prefix or not, but would like to hear the opinion of the
CAN maintainers as to what they would prefer.
>
>> + interrupts = <GIC_SPI 222 IRQ_TYPE_LEVEL_HIGH>;
>> + clocks = <&dcan1_sys_clk_mux>;
>> + status = "disabled";
>> + };
>
cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
