Re: [PATCHv3 1/2] ARM: msm: Add support for APQ8074 Dragonboard

On Sep 9, 2013, at 4:21 PM, Stephen Warren wrote:

On 09/09/2013 01:48 PM, Kumar Gala wrote:

quoted

On Sep 9, 2013, at 2:29 PM, Stephen Warren wrote:

quoted

On 09/09/2013 01:17 PM, Kumar Gala wrote:

quoted

On Sep 9, 2013, at 12:48 PM, Rohit Vaswani wrote:

quoted

On 9/6/2013 2:50 PM, Olof Johansson wrote:

quoted

Hi,

Some comments below.

On Fri, Sep 06, 2013 at 12:32:22PM -0700, Rohit Vaswani wrote:

quoted

This patch adds basic board support for APQ8074 Dragonboard
<snip>
dtb-$(CONFIG_ARCH_MSM) += msm8660-surf.dtb \
-	msm8960-cdp.dtb
+	msm8960-cdp.dtb \
+	apq8074-dragonboard.dtb

Please add boards alphabetically.

Will do.

quoted

quoted

dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
	armada-370-mirabox.dtb \
	armada-370-rd.dtb \

diff --git a/arch/arm/boot/dts/apq8074-dragonboard.dts b/arch/arm/boot/dts/apq8074-dragonboard.dts
new file mode 100644
index 0000000..5b7b6a0
--- /dev/null
+++ b/arch/arm/boot/dts/apq8074-dragonboard.dts

arch/arm/boot/dts/ is getting really crowded. It's been working best if the SoC
family or vendor is used as a prefix to keep things a bit more organized. In
that spirit, prefixing these with msm-<foo> makes sense. Can you please do so?

Sure. But the board is called an APQ8074 and we wanted to keep the naming consistent with that.

If we do this we should use qcom, not msm as the prefix.  Match the device tree vendor prefix.

Hmm. It'd be nice for the filenames to be ${soc}-${board} so that e.g.
U-Boot can easily calculate the DTB filename based on its soc/board
environment variables... Luckily in my case for Tegra, all the Tegra
chip names start with "Tegra", so we already sort all our DTB filenames
together in the directory listing:-)

u-boot's not supported on MSM platforms, so not sure what purpose this serves.

Presumably that's just because nobody has ported the code; it could be
supported couldn't it?

In theory.

quoted

we might want to just introduce vendor dirs so its arch/arm/boot/dts/{vendor}/{soc}-{board}

That seems reasonable to me, although people will complain about the
files moving again. Perhaps it's worth doing that as part of the move of
*.dts out of the kernel?

Agreed, probably best since we'll probably be merging different arch dts's as well at that point

quoted

Not sure if we want to argue about {vendor} vs {sub-arch}.

sub-arch being the mach-xxx/plat-xxx directory? If so, I think that's a
Linux-ism that shouldn't affect the DT directory layout.

Yeah, the mach-xxx/plat-xxx dir, and agree that it being a Linux-ism we shouldn't apply to this.

- k

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation