[04/12] ARM: dts: dragonboard-600c: add board support with serial

Message ID 1458762442-9492-1-git-send-email-srinivas.kandagatla@linaro.org
State New
Headers show

Commit Message

Srinivas Kandagatla March 23, 2016, 7:47 p.m.
This patch adds support to DragonBoard600 with basic serial ports.
DragonBoard600 is based on APQ8064.

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>

---
 arch/arm/boot/dts/Makefile                         |  1 +
 .../arm/boot/dts/qcom-apq8064-dragonboard-600c.dts | 36 ++++++++++++++++++++++
 2 files changed, 37 insertions(+)
 create mode 100644 arch/arm/boot/dts/qcom-apq8064-dragonboard-600c.dts

-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Stephen Boyd March 23, 2016, 8:07 p.m. | #1
On 03/23/2016 12:47 PM, Srinivas Kandagatla wrote:
> diff --git a/arch/arm/boot/dts/qcom-apq8064-dragonboard-600c.dts b/arch/arm/boot/dts/qcom-apq8064-dragonboard-600c.dts

> new file mode 100644

> index 0000000..e96aab6

> --- /dev/null

> +++ b/arch/arm/boot/dts/qcom-apq8064-dragonboard-600c.dts

> @@ -0,0 +1,36 @@

> +#include "qcom-apq8064-v2.0.dtsi"

> +

> +/ {

> +	model = "Qualcomm Technologies, Inc. APQ8064 DragonBoard600c";

> +	compatible = "qcom,apq8064-dragonboard600c", "qcom,apq8064";


Does the bootloader look at this string at all or is it using appended
DTB design? I'm mostly worried about having that
qcom,apq8064-dragonboard600c part. It should probably be
qcom,apq8064-sbc or something like that instead.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Bjorn Andersson March 24, 2016, 1:04 a.m. | #2
On Wed, Mar 23, 2016 at 1:30 PM, Srinivas Kandagatla
<srinivas.kandagatla@linaro.org> wrote:
>

>

> On 23/03/16 20:07, Stephen Boyd wrote:

>>

>> On 03/23/2016 12:47 PM, Srinivas Kandagatla wrote:

>>>

>>> diff --git a/arch/arm/boot/dts/qcom-apq8064-dragonboard-600c.dts

>>> b/arch/arm/boot/dts/qcom-apq8064-dragonboard-600c.dts

>>> new file mode 100644

>>> index 0000000..e96aab6

>>> --- /dev/null

>>> +++ b/arch/arm/boot/dts/qcom-apq8064-dragonboard-600c.dts

>>> @@ -0,0 +1,36 @@

>>> +#include "qcom-apq8064-v2.0.dtsi"

>>> +

>>> +/ {

>>> +       model = "Qualcomm Technologies, Inc. APQ8064 DragonBoard600c";

>>> +       compatible = "qcom,apq8064-dragonboard600c", "qcom,apq8064";

>>

>>

>> Does the bootloader look at this string at all or is it using appended

>> DTB design? I'm mostly worried about having that

>

> Not at least on APQ8064 bootloaders, as they are still missing DT support.

> Currently we append dtb to the kernel.

>>

>> qcom,apq8064-dragonboard600c part. It should probably be

>> qcom,apq8064-sbc or something like that instead.

>

> Will do that in next version.

>


This "sbc" isn't that just the abbreviation for "single board
computer"? I find it hard to believe this is _the_ 8064 sbc or the
only 8064 sbc.

Also, if I make a product based of this board, with some minor
changes, is that still the sbc?

I think the compatible should be "qcom,apq8064-db600c",
"qcom,apq8064-sbc", "qcom,apq8064"

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Stephen Boyd March 24, 2016, 1:48 a.m. | #3
On 03/23/2016 06:04 PM, Bjorn Andersson wrote:
> On Wed, Mar 23, 2016 at 1:30 PM, Srinivas Kandagatla

> <srinivas.kandagatla@linaro.org> wrote:

>>

>> On 23/03/16 20:07, Stephen Boyd wrote:

>>> On 03/23/2016 12:47 PM, Srinivas Kandagatla wrote:

>>>> diff --git a/arch/arm/boot/dts/qcom-apq8064-dragonboard-600c.dts

>>>> b/arch/arm/boot/dts/qcom-apq8064-dragonboard-600c.dts

>>>> new file mode 100644

>>>> index 0000000..e96aab6

>>>> --- /dev/null

>>>> +++ b/arch/arm/boot/dts/qcom-apq8064-dragonboard-600c.dts

>>>> @@ -0,0 +1,36 @@

>>>> +#include "qcom-apq8064-v2.0.dtsi"

>>>> +

>>>> +/ {

>>>> +       model = "Qualcomm Technologies, Inc. APQ8064 DragonBoard600c";

>>>> +       compatible = "qcom,apq8064-dragonboard600c", "qcom,apq8064";

>>>

>>> Does the bootloader look at this string at all or is it using appended

>>> DTB design? I'm mostly worried about having that

>> Not at least on APQ8064 bootloaders, as they are still missing DT support.

>> Currently we append dtb to the kernel.

>>> qcom,apq8064-dragonboard600c part. It should probably be

>>> qcom,apq8064-sbc or something like that instead.

>> Will do that in next version.

>>

> This "sbc" isn't that just the abbreviation for "single board

> computer"? I find it hard to believe this is _the_ 8064 sbc or the

> only 8064 sbc.


I don't make up the names, but for other qcom sbc products the
bootloader is looking for sbc there to make sure it picks the right dtb
blob. So I guess this is _the_ qcom 8064 sbc? Definitely not _the_ 8064
sbc though.

If this device won't get those bootloaders that look for this then it
doesn't really matter and I don't care what this is named. Please take a
look at Documentation/devicetree/bindings/arm/qcom.txt for what I'm
talking about though.

>

> Also, if I make a product based of this board, with some minor

> changes, is that still the sbc?

>

> I think the compatible should be "qcom,apq8064-db600c",

> "qcom,apq8064-sbc", "qcom,apq8064"

>

>


I really hope that people don't keep using the qcom bootloader dtb
picking design if they make a new product based off qcom boards with a
slight variation. They should replace the vendor part of the compatible
anyway with their own vendor prefix, and then the bootloader would need
to be updated to look for that string or something else. I really don't
want to get in the business of updating dtbTool for all the non-qcom
designs that pop up because they keep using the qcom dtb identification
scheme. It almost doesn't scale right now and that's just qcom designs.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Arnd Bergmann March 24, 2016, 12:49 p.m. | #4
On Wednesday 23 March 2016 18:48:46 Stephen Boyd wrote:
> >>

> > This "sbc" isn't that just the abbreviation for "single board

> > computer"? I find it hard to believe this is _the_ 8064 sbc or the

> > only 8064 sbc.

> 

> I don't make up the names, but for other qcom sbc products the

> bootloader is looking for sbc there to make sure it picks the right dtb

> blob. So I guess this is _the_ qcom 8064 sbc? Definitely not _the_ 8064

> sbc though.

> 


Is it even made by Qualcomm? IIRC the 410c is made by Arrow, not Qualcomm.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Nicolas Dechesne March 24, 2016, 8:50 p.m. | #5
On Thu, Mar 24, 2016 at 2:48 AM, Stephen Boyd <sboyd@codeaurora.org> wrote:
> I don't make up the names, but for other qcom sbc products the

> bootloader is looking for sbc there to make sure it picks the right dtb

> blob. So I guess this is _the_ qcom 8064 sbc? Definitely not _the_ 8064

> sbc though.

>

> If this device won't get those bootloaders that look for this then it

> doesn't really matter and I don't care what this is named. Please take a

> look at Documentation/devicetree/bindings/arm/qcom.txt for what I'm

> talking about though.



I would really want to get rid of the 'i need to append the DTB' on
this board. the DT support in the bootloader have been backported , I
am really hoping we can use this DT aware LK, and thus rely on the
compatible string, like we do on db410c. So this is important to get
the name/property right, since we will get there. In fact, I am even
hoping that once we publish this DT aware LK along with this board,
the other myriad of 8064 based 'SBC' from various vendors will upgrade
their bootloader, so that we can have a single 'boot' image (generated
with the help of dtbTool) that works across all devices.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Bjorn Andersson March 29, 2016, 2:21 p.m. | #6
On Wed 23 Mar 18:48 PDT 2016, Stephen Boyd wrote:

> On 03/23/2016 06:04 PM, Bjorn Andersson wrote:

> > On Wed, Mar 23, 2016 at 1:30 PM, Srinivas Kandagatla

> > <srinivas.kandagatla@linaro.org> wrote:

> >>

> >> On 23/03/16 20:07, Stephen Boyd wrote:

[..]
> >

> > Also, if I make a product based of this board, with some minor

> > changes, is that still the sbc?

> >

> > I think the compatible should be "qcom,apq8064-db600c",

> > "qcom,apq8064-sbc", "qcom,apq8064"

> >

> >

> 

> I really hope that people don't keep using the qcom bootloader dtb

> picking design if they make a new product based off qcom boards with a

> slight variation. They should replace the vendor part of the compatible

> anyway with their own vendor prefix, and then the bootloader would need

> to be updated to look for that string or something else. I really don't

> want to get in the business of updating dtbTool for all the non-qcom

> designs that pop up because they keep using the qcom dtb identification

> scheme. It almost doesn't scale right now and that's just qcom designs.


At that other company the various dtb's that was to be picked for a
given product was always to support the various SoC versions; so those
devices always shipped with the mtp board-id and msm-id.

As far as I've seen this is how Qualcomm's Android customers does it.


But as things progress further I do see a need for being able to also
pick the right product and at that point you're right that the vendor
must change their boot loader.

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Stephen Boyd March 29, 2016, 7 p.m. | #7
On 03/24, Nicolas Dechesne wrote:
> On Thu, Mar 24, 2016 at 2:48 AM, Stephen Boyd <sboyd@codeaurora.org> wrote:

> > I don't make up the names, but for other qcom sbc products the

> > bootloader is looking for sbc there to make sure it picks the right dtb

> > blob. So I guess this is _the_ qcom 8064 sbc? Definitely not _the_ 8064

> > sbc though.

> >

> > If this device won't get those bootloaders that look for this then it

> > doesn't really matter and I don't care what this is named. Please take a

> > look at Documentation/devicetree/bindings/arm/qcom.txt for what I'm

> > talking about though.

> 

> 

> I would really want to get rid of the 'i need to append the DTB' on

> this board. the DT support in the bootloader have been backported , I

> am really hoping we can use this DT aware LK, and thus rely on the

> compatible string, like we do on db410c. So this is important to get

> the name/property right, since we will get there. In fact, I am even

> hoping that once we publish this DT aware LK along with this board,

> the other myriad of 8064 based 'SBC' from various vendors will upgrade

> their bootloader, so that we can have a single 'boot' image (generated

> with the help of dtbTool) that works across all devices.


Ok, I'm not sure how that's going to work though. If all these
'SBC' devices are using the same bootloader and that bootloader
is looking into SMEM for the different device identifying
attributes (called socinfo in the downstream kernel) we're going
to need to make sure that the devices identify uniquely.

There is the 'subtype' attribute, which is just a number to
identify different variations of a similar board. I hope that all
the 'SBC' boards are using different subtypes or things are going
to start getting messy.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 52b34a0..265941a4 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -532,6 +532,7 @@  dtb-$(CONFIG_ARCH_PRIMA2) += \
 	prima2-evb.dtb
 dtb-$(CONFIG_ARCH_QCOM) += \
 	qcom-apq8064-cm-qs600.dtb \
+	qcom-apq8064-dragonboard-600c.dtb \
 	qcom-apq8064-ifc6410.dtb \
 	qcom-apq8064-sony-xperia-yuga.dtb \
 	qcom-apq8064-asus-nexus7-flo.dtb \
diff --git a/arch/arm/boot/dts/qcom-apq8064-dragonboard-600c.dts b/arch/arm/boot/dts/qcom-apq8064-dragonboard-600c.dts
new file mode 100644
index 0000000..e96aab6
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-apq8064-dragonboard-600c.dts
@@ -0,0 +1,36 @@ 
+#include "qcom-apq8064-v2.0.dtsi"
+
+/ {
+	model = "Qualcomm Technologies, Inc. APQ8064 DragonBoard600c";
+	compatible = "qcom,apq8064-dragonboard600c", "qcom,apq8064";
+
+	aliases {
+		serial0 = &gsbi7_serial;
+		serial1 = &gsbi1_serial;
+	};
+
+	soc {
+		gsbi@12440000 {
+			status = "okay";
+			qcom,mode = <GSBI_PROT_UART_W_FC>;
+			serial@12450000 {
+				label = "LS-UART1";
+				status = "okay";
+				pinctrl-names = "default";
+				pinctrl-0 = <&gsbi1_uart_4pins>;
+			};
+		};
+
+		/* DEBUG UART  */
+		gsbi@16600000 {
+			status = "okay";
+			qcom,mode = <GSBI_PROT_I2C_UART>;
+			serial@16640000 {
+				label = "LS-UART0";
+				status = "okay";
+				pinctrl-names = "default";
+				pinctrl-0 = <&gsbi7_uart_2pins>;
+			};
+		};
+	};
+};