Message-ID: <5213A0A7.9010502@codeaurora.org>
Date: Tue, 20 Aug 2013 10:00:23 -0700
From: Stephen Boyd <sboyd@codeaurora.org>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Kumar Gala <galak@codeaurora.org>
CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org, linux-serial@vger.kernel.org,
        David Brown <davidb@codeaurora.org>, devicetree@vger.kernel.org
Subject: Re: [PATCH 2/4] devicetree: serial: Document msm_serial bindings
References: <1376948397-6882-1-git-send-email-sboyd@codeaurora.org> <1376948397-6882-3-git-send-email-sboyd@codeaurora.org> <543F6671-8317-446A-B14A-147373BCA9B6@codeaurora.org>
In-Reply-To: <543F6671-8317-446A-B14A-147373BCA9B6@codeaurora.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3225
Lines: 96

On 08/20/13 07:41, Kumar Gala wrote:
> On Aug 19, 2013, at 4:39 PM, Stephen Boyd wrote:
>
>> diff --git a/Documentation/devicetree/bindings/serial/msm_serial.txt b/Documentation/devicetree/bindings/serial/msm_serial.txt
>> new file mode 100644
>> index 0000000..a6efac3
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/serial/msm_serial.txt
>> @@ -0,0 +1,82 @@
>> +* MSM Serial UART and UARTDM
>> +
>> +There are two MSM serial hardware designs. UARTDM is designed for use with a
>> +dma engine in high-speed use cases and the non-DM design is for lower speed use
>> +cases. The two designs are mostly compatible from a software perspective except
>> +the non-DM design can only read and write one character at a time and so the
>> +register layout differs slightly.
> I think you split this into two binding spec docs, one for each type of uart.

Should split into two files? I can do that.

>
>> +
>> +UART
>> +----
>> +Required properties:
>> +- compatible: Should contain "qcom,msm-uart"
>> +- reg: Should contain UART register location and length. The first
> first? is there more than one reg region?
>
>> +       register shall specify the main control registers
>> +- interrupts: Should contain UART interrupt.
>> +- clocks: Should contain the core clock.
>> +- clock-names: Should be "core_clk".
>> +
>> +Optional properties:
>> +- dmas: Should contain dma specifiers for transmit and receive
>> +- dma-names: Should contain "tx" for transmit and "rx" for receive
> confused, above you say the non-DM doesn't support DMA so, why the optional props?

Ah sorry, copy pasta.

>
>> +
>> +Example:
>> +
>> +A uart device with dma capabilities.
>> +
>> +serial@a9c00000 {
>> +	compatible = "qcom,msm-uart";
>> +	reg = <0xa9c00000 0x1000>;
>> +	interrupts = <11>;
>> +	clocks = <&uart_cxc>;
>> +	clock-names = "core_clk";
>> +	dmas = <&dma0 0>, <&dma0 1>;
>> +	dma-names = "tx", "rx";
>> +};
>> +
>> +UARTDM
>> +------
>> +Required properties:
>> +- compatible: Should contain at least "qcom,msm-uartdm".
>> +              A more specific property should be specified as follows depending
>> +	      on the version:
>> +		"qcom,msm-uartdm-v1.1"
>> +		"qcom,msm-uartdm-v1.2"
>> +		"qcom,msm-uartdm-v1.3"
>> +		"qcom,msm-uartdm-v1.4"
>> +- reg: Should contain UART register locations and lengths. The first
>> +       register shall specify the main control registers. An optional second
>> +       register location shall specify the GSBI control region.
> Is GSBI region existing tied to particular versions (if so can we say that)

Not really. GSBI will always be related to v1.3 but not all v1.3
hardware is part of a GSBI.

>
> reg-names?

Optional should be fine? The driver is already handling this without
reg-names.

>> +- interrupts: Should contain UART interrupt.
>> +- clocks: Should contain the core clock and the ahb clock.
> nit, ahb in caps?

Done.

-- 
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 linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/