On Oct 31, 2013, at 9:55 AM, Laurent Pinchart wrote:
> Hi Kumar,
>
> Thank you for the review.
>
> On Thursday 31 October 2013 09:42:48 Kumar Gala wrote:
>> On Oct 29, 2013, at 5:29 AM, Laurent Pinchart wrote:
>>> Document the device tree bindings for the sci serial port devices.
>>>
>>> Cc: devicetree@xxxxxxxxxxxxxxx
>>> Signed-off-by: Laurent Pinchart
>>> <laurent.pinchart+renesas@xxxxxxxxxxxxxxxx>
>>> ---
>>> .../bindings/serial/renesas,sci-serial.txt | 51 ++++++++++++++++++
>>> 1 file changed, 51 insertions(+)
>>> create mode 100644
>>> Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
>>>
>>> diff --git
>>> a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
>>> b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt new
>>> file mode 100644
>>> index 0000000..5658b4f
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
>>> @@ -0,0 +1,51 @@
>>> +* Renesas SH-Mobile Serial Communication Interface
>>> +
>>> +Required properties:
>>> +
>>> + - compatible: should be one of the following.
>>
>> Being pedantic, but how about saying 'one of the following types (scif,
>> scifa, scifb, or hscif)
>
> Sounds good to me.
>
>>> +
>>> + - "renesas,scif-r8a7790" for R8A7790 (R-Car H2) SCIF compatible UART.
>>> + - "renesas,scifa-r8a7790" for R8A7790 (R-Car H2) SCIFA compatible
>>> UART.
>>> + - "renesas,scifb-r8a7790" for R8A7790 (R-Car H2) SCIFB compatible
>>> UART.
>>> + - "renesas,hscif-r8a7790" for R8A7790 (R-Car H2) HSCIF compatible
>>> UART.
>>> + - "renesas,scif-generic" for generic SCIF compatible UART.
>>> + - "renesas,scifa-generic" for generic SCIFA compatible UART.
>>> + - "renesas,scifb-generic" for generic SCIFB compatible UART.
>>> + - "renesas,hscif-generic" for generic HSCIF compatible UART.
>>> +
>>> + When compatible with the generic version, nodes must also list the
>>> + SoC-specific version corresponding to the platform.
>>> +
>>> + - reg: Base address and length of the memory resource used by the UART.
>>> +
>>> + - interrupt-parent: Reference to the parent interrupt controller.
>>> + - interrupts: Interrupt number(s). Depending on the SoC SCIx UARTs are
>>> tied
>>> + to one or multiple interrupt lines. When using multiple interrupt
>>> lines,
>>> + specify the interrupt names as described below.
>>> +
>>> + - clocks: Reference to the SCIx UART interface clock.
>>> + - clock-names: Should be "sci_ick".
>>> +
>>> +Optional properties:
>>> +
>>> + - interrupt-names: When using multiple interrupts, report the interrupt
>>> + names as "eri" (receive error), "rxi" (receive), "txi" (transmit) and
>>> + "bri" (break). When using a single interrupt this property should not
>>> be + present.
>>
>> Hmm, is there a reason not to just have the 4 interrupts always present and
>> in the case they are all wired to the same interrupt, just have the
>> interrupts all be the same?
>>
>> example:
>>
>> interrupts = <0 144 4>, <0 144 4>, <0 144 4>, <0 144 4>;
>
> The multiple interrupts case is the exception, I thought it would be easier to
> specify a single interrupt in the general case and have a more complex binding
> for the exceptions.
>
>>> +
>>> +Note: Each enabled SCIx UART should have an alias correctly numbered in
>>> the +"aliases" node.
>>> +
>>> +Example:
>>> + aliases {
>>> + serial0 = &scifa0;
>>> + };
>>> +
>>> + scifa0: serial@e6c40000 {
>>> + compatible = "renesas,scifa-r8a7790", "renesas,scifa-generic";
>>> + reg = <0 0xe6c40000 0 64>;
>>> + interrupt-parent = <&gic>;
>>> + interrupts = <0 144 4>;
>>> + clocks = <&mstp2_clks 4>;
>>> + clock-names = "sci_ick";
>>> + };
>>
>> might be nice to have an example with the 4 interrupts.
>
> The example would be pretty theoretical, as the r8a7790 uses a single
> interrupt in all cases. What about adding such an example when adding an SoC
> that uses multiple interrupts to the DT bindings documentation ?
I'm fine with that if we strip the multiple interrupt bits out of the binding until a device/compatible exists that needs it.
- k
>
> --
> Regards,
>
> Laurent Pinchart
>
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
