Use the Qualcomm vendor prefix (qcom) as the directory name for
Qualcomm MSM devicetrees going forward.
Signed-off-by: Kumar Gala <[email protected]>
---
arch/arm/boot/dts/Makefile | 4 ++--
arch/arm/boot/dts/{ => qcom}/msm8660-surf.dts | 2 +-
arch/arm/boot/dts/{ => qcom}/msm8960-cdp.dts | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
rename arch/arm/boot/dts/{ => qcom}/msm8660-surf.dts (97%)
rename arch/arm/boot/dts/{ => qcom}/msm8960-cdp.dts (97%)
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index cc0f1fb..d784ba0 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -101,8 +101,8 @@ dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-cloudbox.dtb \
kirkwood-ts219-6282.dtb \
kirkwood-openblocks_a6.dtb
dtb-$(CONFIG_ARCH_MARCO) += marco-evb.dtb
-dtb-$(CONFIG_ARCH_MSM) += msm8660-surf.dtb \
- msm8960-cdp.dtb
+dtb-$(CONFIG_ARCH_MSM) += qcom/msm8660-surf.dtb \
+ qcom/msm8960-cdp.dtb
dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
armada-370-mirabox.dtb \
armada-370-netgear-rn102.dtb \
diff --git a/arch/arm/boot/dts/msm8660-surf.dts b/arch/arm/boot/dts/qcom/msm8660-surf.dts
similarity index 97%
rename from arch/arm/boot/dts/msm8660-surf.dts
rename to arch/arm/boot/dts/qcom/msm8660-surf.dts
index 386d428..8c5ea9a 100644
--- a/arch/arm/boot/dts/msm8660-surf.dts
+++ b/arch/arm/boot/dts/qcom/msm8660-surf.dts
@@ -1,6 +1,6 @@
/dts-v1/;
-/include/ "skeleton.dtsi"
+/include/ "../skeleton.dtsi"
/ {
model = "Qualcomm MSM8660 SURF";
diff --git a/arch/arm/boot/dts/msm8960-cdp.dts b/arch/arm/boot/dts/qcom/msm8960-cdp.dts
similarity index 97%
rename from arch/arm/boot/dts/msm8960-cdp.dts
rename to arch/arm/boot/dts/qcom/msm8960-cdp.dts
index 93e9f7e..fe2659a 100644
--- a/arch/arm/boot/dts/msm8960-cdp.dts
+++ b/arch/arm/boot/dts/qcom/msm8960-cdp.dts
@@ -1,6 +1,6 @@
/dts-v1/;
-/include/ "skeleton.dtsi"
+/include/ "../skeleton.dtsi"
/ {
model = "Qualcomm MSM8960 CDP";
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
On Thu, Sep 12, 2013 at 9:37 AM, Kumar Gala <[email protected]> wrote:
> Use the Qualcomm vendor prefix (qcom) as the directory name for
> Qualcomm MSM devicetrees going forward.
>
> Signed-off-by: Kumar Gala <[email protected]>
Let's not move just one platform like this. If we are to do this, we
should move everything, and that will be really painful and needs to
be done in a controlled manner, probably scripted and right before a
-rc1 or such.
-Olof
On Sep 12, 2013, at 11:46 AM, Olof Johansson wrote:
> On Thu, Sep 12, 2013 at 9:37 AM, Kumar Gala <[email protected]> wrote:
>> Use the Qualcomm vendor prefix (qcom) as the directory name for
>> Qualcomm MSM devicetrees going forward.
>>
>> Signed-off-by: Kumar Gala <[email protected]>
>
> Let's not move just one platform like this. If we are to do this, we
> should move everything, and that will be really painful and needs to
> be done in a controlled manner, probably scripted and right before a
> -rc1 or such.
Than I suggest we deal with it when we pull the device trees out of the kernel tree.
As such, I'd tell Rohit to go forward with the file being named apq8074-dragonboard.dtb for the time being.
- k
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
On Thu, Sep 12, 2013 at 9:53 AM, Kumar Gala <[email protected]> wrote:
>
> On Sep 12, 2013, at 11:46 AM, Olof Johansson wrote:
>
>> On Thu, Sep 12, 2013 at 9:37 AM, Kumar Gala <[email protected]> wrote:
>>> Use the Qualcomm vendor prefix (qcom) as the directory name for
>>> Qualcomm MSM devicetrees going forward.
>>>
>>> Signed-off-by: Kumar Gala <[email protected]>
>>
>> Let's not move just one platform like this. If we are to do this, we
>> should move everything, and that will be really painful and needs to
>> be done in a controlled manner, probably scripted and right before a
>> -rc1 or such.
>
>
> Than I suggest we deal with it when we pull the device trees out of the kernel tree.
>
> As such, I'd tell Rohit to go forward with the file being named apq8074-dragonboard.dtb for the time being.
My original request to please use a common prefix for your product
families stands. Please prefix with msm-*, or if you have to, qcom-*
instead, since you guys can't seem to make your mind up on standard
prefixes (msm, apq, etc).
-Olof
On Sep 12, 2013, at 12:06 PM, Olof Johansson wrote:
> On Thu, Sep 12, 2013 at 9:53 AM, Kumar Gala <[email protected]> wrote:
>>
>> On Sep 12, 2013, at 11:46 AM, Olof Johansson wrote:
>>
>>> On Thu, Sep 12, 2013 at 9:37 AM, Kumar Gala <[email protected]> wrote:
>>>> Use the Qualcomm vendor prefix (qcom) as the directory name for
>>>> Qualcomm MSM devicetrees going forward.
>>>>
>>>> Signed-off-by: Kumar Gala <[email protected]>
>>>
>>> Let's not move just one platform like this. If we are to do this, we
>>> should move everything, and that will be really painful and needs to
>>> be done in a controlled manner, probably scripted and right before a
>>> -rc1 or such.
>>
>>
>> Than I suggest we deal with it when we pull the device trees out of the kernel tree.
>>
>> As such, I'd tell Rohit to go forward with the file being named apq8074-dragonboard.dtb for the time being.
>
> My original request to please use a common prefix for your product
> families stands. Please prefix with msm-*, or if you have to, qcom-*
> instead, since you guys can't seem to make your mind up on standard
> prefixes (msm, apq, etc).
This is silly, I dont see the reason to go with qcom-apq<SOC>-<BOARD>.dts and than in the future drop qcom- when we mostly likely shift to a dir structure. As engineers we are all too aware of the lack of sanity in marketing names, but its what we have so we have to live with it.
- k
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
On Thu, Sep 12, 2013 at 10:55 AM, Kumar Gala <[email protected]> wrote:
>
> On Sep 12, 2013, at 12:06 PM, Olof Johansson wrote:
>
>> On Thu, Sep 12, 2013 at 9:53 AM, Kumar Gala <[email protected]> wrote:
>>>
>>> On Sep 12, 2013, at 11:46 AM, Olof Johansson wrote:
>>>
>>>> On Thu, Sep 12, 2013 at 9:37 AM, Kumar Gala <[email protected]> wrote:
>>>>> Use the Qualcomm vendor prefix (qcom) as the directory name for
>>>>> Qualcomm MSM devicetrees going forward.
>>>>>
>>>>> Signed-off-by: Kumar Gala <[email protected]>
>>>>
>>>> Let's not move just one platform like this. If we are to do this, we
>>>> should move everything, and that will be really painful and needs to
>>>> be done in a controlled manner, probably scripted and right before a
>>>> -rc1 or such.
>>>
>>>
>>> Than I suggest we deal with it when we pull the device trees out of the kernel tree.
>>>
>>> As such, I'd tell Rohit to go forward with the file being named apq8074-dragonboard.dtb for the time being.
>>
>> My original request to please use a common prefix for your product
>> families stands. Please prefix with msm-*, or if you have to, qcom-*
>> instead, since you guys can't seem to make your mind up on standard
>> prefixes (msm, apq, etc).
>
> This is silly, I dont see the reason to go with qcom-apq<SOC>-<BOARD>.dts and than in the future drop qcom- when we mostly likely shift to a dir structure.
>
> As engineers we are all too aware of the lack of sanity in marketing names, but its what we have so we have to live with it.
And we all have a choice whether we let the marketing people's
insanity spread into our engineering projects, or if we keep it as
sane as possible in spite of them.
I wouldn't have an objection here if there was some sort of rationale
between what "apq" and "msm" means. But it seems like qualcomm rolls a
dice and decides if a platform will have one name or the other.
Dragonboard dmesg says msm<foo>. DTS file for the same board says apq.
DTSI file says one thing, overridden by the dts to something else.
Total chaos.
I would be fine with adding two instead of one (after all, platforms
like TI has this for AM* vs OMAP*, etc), but there _has_ to be some
sort of consistency or you might just as well assign a random string
as name.
So, if you can't come up with a reasonable, rational and consistent
naming scheme (which, apparantly, you can't since your marketing guys
are in control of this and they don't get it right), then at least
prefix with a common string for the platform. That's all I'm asking.
-Olof
On Sep 12, 2013, at 1:04 PM, Olof Johansson wrote:
> On Thu, Sep 12, 2013 at 10:55 AM, Kumar Gala <[email protected]> wrote:
>>
>> On Sep 12, 2013, at 12:06 PM, Olof Johansson wrote:
>>
>>> On Thu, Sep 12, 2013 at 9:53 AM, Kumar Gala <[email protected]> wrote:
>>>>
>>>> On Sep 12, 2013, at 11:46 AM, Olof Johansson wrote:
>>>>
>>>>> On Thu, Sep 12, 2013 at 9:37 AM, Kumar Gala <[email protected]> wrote:
>>>>>> Use the Qualcomm vendor prefix (qcom) as the directory name for
>>>>>> Qualcomm MSM devicetrees going forward.
>>>>>>
>>>>>> Signed-off-by: Kumar Gala <[email protected]>
>>>>>
>>>>> Let's not move just one platform like this. If we are to do this, we
>>>>> should move everything, and that will be really painful and needs to
>>>>> be done in a controlled manner, probably scripted and right before a
>>>>> -rc1 or such.
>>>>
>>>>
>>>> Than I suggest we deal with it when we pull the device trees out of the kernel tree.
>>>>
>>>> As such, I'd tell Rohit to go forward with the file being named apq8074-dragonboard.dtb for the time being.
>>>
>>> My original request to please use a common prefix for your product
>>> families stands. Please prefix with msm-*, or if you have to, qcom-*
>>> instead, since you guys can't seem to make your mind up on standard
>>> prefixes (msm, apq, etc).
>>
>> This is silly, I dont see the reason to go with qcom-apq<SOC>-<BOARD>.dts and than in the future drop qcom- when we mostly likely shift to a dir structure.
>>
>> As engineers we are all too aware of the lack of sanity in marketing names, but its what we have so we have to live with it.
>
> And we all have a choice whether we let the marketing people's
> insanity spread into our engineering projects, or if we keep it as
> sane as possible in spite of them.
>
> I wouldn't have an objection here if there was some sort of rationale
> between what "apq" and "msm" means. But it seems like qualcomm rolls a
> dice and decides if a platform will have one name or the other.
> Dragonboard dmesg says msm<foo>. DTS file for the same board says apq.
> DTSI file says one thing, overridden by the dts to something else.
> Total chaos.
>
> I would be fine with adding two instead of one (after all, platforms
> like TI has this for AM* vs OMAP*, etc), but there _has_ to be some
> sort of consistency or you might just as well assign a random string
> as name.
>
> So, if you can't come up with a reasonable, rational and consistent
> naming scheme (which, apparantly, you can't since your marketing guys
> are in control of this and they don't get it right), then at least
> prefix with a common string for the platform. That's all I'm asking.
>
>
> -Olof
I'm not sure get why the insanity of naming impacts anything, those people that care about the platforms know what names mean what. Plus we have this same set of having to be in the know for other SoC already. Freescale does this all the time in PPC land, they just do it with numbers and not prefixes.
I suggested doing a qcom/ dir, as it addresses your concern, of putting all of our mess in one place. Just because every other SoC/mach/plat hasn't done that should stop us from at least doing it for qcom.
- k
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
On 09/12/2013 01:15 PM, Kumar Gala wrote:
>
> On Sep 12, 2013, at 1:04 PM, Olof Johansson wrote:
>
>> On Thu, Sep 12, 2013 at 10:55 AM, Kumar Gala <[email protected]>
>> wrote:
>>>
>>> On Sep 12, 2013, at 12:06 PM, Olof Johansson wrote:
>>>
>>>> On Thu, Sep 12, 2013 at 9:53 AM, Kumar Gala
>>>> <[email protected]> wrote:
>>>>>
>>>>> On Sep 12, 2013, at 11:46 AM, Olof Johansson wrote:
>>>>>
>>>>>> On Thu, Sep 12, 2013 at 9:37 AM, Kumar Gala
>>>>>> <[email protected]> wrote:
>>>>>>> Use the Qualcomm vendor prefix (qcom) as the directory
>>>>>>> name for Qualcomm MSM devicetrees going forward.
>>>>>>>
>>>>>>> Signed-off-by: Kumar Gala <[email protected]>
>>>>>>
>>>>>> Let's not move just one platform like this. If we are to do
>>>>>> this, we should move everything, and that will be really
>>>>>> painful and needs to be done in a controlled manner,
>>>>>> probably scripted and right before a -rc1 or such.
>>>>>
>>>>>
>>>>> Than I suggest we deal with it when we pull the device trees
>>>>> out of the kernel tree.
>>>>>
>>>>> As such, I'd tell Rohit to go forward with the file being
>>>>> named apq8074-dragonboard.dtb for the time being.
>>>>
>>>> My original request to please use a common prefix for your
>>>> product families stands. Please prefix with msm-*, or if you
>>>> have to, qcom-* instead, since you guys can't seem to make your
>>>> mind up on standard prefixes (msm, apq, etc).
>>>
>>> This is silly, I dont see the reason to go with
>>> qcom-apq<SOC>-<BOARD>.dts and than in the future drop qcom- when
>>> we mostly likely shift to a dir structure.
>>>
>>> As engineers we are all too aware of the lack of sanity in
>>> marketing names, but its what we have so we have to live with
>>> it.
>>
>> And we all have a choice whether we let the marketing people's
>> insanity spread into our engineering projects, or if we keep it as
>> sane as possible in spite of them.
>>
>> I wouldn't have an objection here if there was some sort of
>> rationale between what "apq" and "msm" means. But it seems like
>> qualcomm rolls a dice and decides if a platform will have one name
>> or the other. Dragonboard dmesg says msm<foo>. DTS file for the
>> same board says apq. DTSI file says one thing, overridden by the
>> dts to something else. Total chaos.
>>
>> I would be fine with adding two instead of one (after all,
>> platforms like TI has this for AM* vs OMAP*, etc), but there _has_
>> to be some sort of consistency or you might just as well assign a
>> random string as name.
>>
>> So, if you can't come up with a reasonable, rational and
>> consistent naming scheme (which, apparantly, you can't since your
>> marketing guys are in control of this and they don't get it right),
>> then at least prefix with a common string for the platform. That's
>> all I'm asking.
>>
>>
>> -Olof
>
> I'm not sure get why the insanity of naming impacts anything, those
> people that care about the platforms know what names mean what. Plus
> we have this same set of having to be in the know for other SoC
> already. Freescale does this all the time in PPC land, they just do
> it with numbers and not prefixes.
>
> I suggested doing a qcom/ dir, as it addresses your concern, of
> putting all of our mess in one place. Just because every other
> SoC/mach/plat hasn't done that should stop us from at least doing it
> for qcom.
>
As Stephen W has pointed out previously, the dtb filename itself is or
may be an ABI and the bootloader may be hardcoded to a name. So we
should avoid future renames.
Rob
On Thu, Sep 12, 2013 at 11:20 AM, Rob Herring <[email protected]> wrote:
> As Stephen W has pointed out previously, the dtb filename itself is or
> may be an ABI and the bootloader may be hardcoded to a name. So we
> should avoid future renames.
We still have the choice of producing the dtb files under
arch/arm/boot/dts even if we move dts/dtsi files one level deeper, as
long as we keep the filenames consistent. So we can do a move, just
not a rename.
-Olof
On Sep 12, 2013, at 1:46 PM, Olof Johansson wrote:
> On Thu, Sep 12, 2013 at 11:20 AM, Rob Herring <[email protected]> wrote:
>
>> As Stephen W has pointed out previously, the dtb filename itself is or
>> may be an ABI and the bootloader may be hardcoded to a name. So we
>> should avoid future renames.
>
> We still have the choice of producing the dtb files under
> arch/arm/boot/dts even if we move dts/dtsi files one level deeper, as
> long as we keep the filenames consistent. So we can do a move, just
> not a rename.
Looking at arch/arm/boot/dts/ we are all over the place, so what's the naming convention we are going forward with?
- k
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
On Thu, Sep 12, 2013 at 12:55:36PM -0500, Kumar Gala wrote:
>
>On Sep 12, 2013, at 12:06 PM, Olof Johansson wrote:
>> My original request to please use a common prefix for your product
>> families stands. Please prefix with msm-*, or if you have to, qcom-*
>> instead, since you guys can't seem to make your mind up on standard
>> prefixes (msm, apq, etc).
>
>This is silly, I dont see the reason to go with
>qcom-apq<SOC>-<BOARD>.dts and than in the future drop qcom- when we
>mostly likely shift to a dir structure. As engineers we are all too
>aware of the lack of sanity in marketing names, but its what we have
>so we have to live with it.
At least what we'd decided a year or two ago was to call _everything_
with an msm* prefix. If marketing comes up with cute prefixes for
things, we would basically ignore them. So, under that, it should be
an msm8074-dragonboard. Admittedly, it might be a little confusing
with the name of the product having the apq in it, but as others have
pointed out, I think there is less confusing than not having a common
prefix on our MSM products.
At least so far, there are no chips where apq vs msm actually
distinguishes anything. In fact, a simple "decoder ring" would point
out that the 'apq' usually corresponds with the second digit being a
zero. It doesn't help that we've added an 'mpq' prefix as well.
I don't really see how to satisfy all of this other than qcom-apq*, or
just continue to use msm*.
David
--
sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
On Sep 12, 2013, at 5:47 PM, David Brown wrote:
> On Thu, Sep 12, 2013 at 12:55:36PM -0500, Kumar Gala wrote:
>>
>> On Sep 12, 2013, at 12:06 PM, Olof Johansson wrote:
>
>>> My original request to please use a common prefix for your product
>>> families stands. Please prefix with msm-*, or if you have to, qcom-*
>>> instead, since you guys can't seem to make your mind up on standard
>>> prefixes (msm, apq, etc).
>>
>> This is silly, I dont see the reason to go with
>> qcom-apq<SOC>-<BOARD>.dts and than in the future drop qcom- when we
>> mostly likely shift to a dir structure. As engineers we are all too
>> aware of the lack of sanity in marketing names, but its what we have
>> so we have to live with it.
>
> At least what we'd decided a year or two ago was to call _everything_
> with an msm* prefix. If marketing comes up with cute prefixes for
> things, we would basically ignore them. So, under that, it should be
> an msm8074-dragonboard. Admittedly, it might be a little confusing
> with the name of the product having the apq in it, but as others have
> pointed out, I think there is less confusing than not having a common
> prefix on our MSM products.
>
> At least so far, there are no chips where apq vs msm actually
> distinguishes anything. In fact, a simple "decoder ring" would point
> out that the 'apq' usually corresponds with the second digit being a
> zero. It doesn't help that we've added an 'mpq' prefix as well.
>
> I don't really see how to satisfy all of this other than qcom-apq*, or
> just continue to use msm*.
I think msm has run out of steam, especially as more SoCs come out of Qualcomm that aren't just targeting phones & tablets.
- k
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
On 9/12/2013 7:05 PM, Kumar Gala wrote:
> On Sep 12, 2013, at 5:47 PM, David Brown wrote:
>
>> On Thu, Sep 12, 2013 at 12:55:36PM -0500, Kumar Gala wrote:
>>> On Sep 12, 2013, at 12:06 PM, Olof Johansson wrote:
>>>> My original request to please use a common prefix for your product
>>>> families stands. Please prefix with msm-*, or if you have to, qcom-*
>>>> instead, since you guys can't seem to make your mind up on standard
>>>> prefixes (msm, apq, etc).
>>> This is silly, I dont see the reason to go with
>>> qcom-apq<SOC>-<BOARD>.dts and than in the future drop qcom- when we
>>> mostly likely shift to a dir structure. As engineers we are all too
>>> aware of the lack of sanity in marketing names, but its what we have
>>> so we have to live with it.
>> At least what we'd decided a year or two ago was to call _everything_
>> with an msm* prefix. If marketing comes up with cute prefixes for
>> things, we would basically ignore them. So, under that, it should be
>> an msm8074-dragonboard. Admittedly, it might be a little confusing
>> with the name of the product having the apq in it, but as others have
>> pointed out, I think there is less confusing than not having a common
>> prefix on our MSM products.
>>
>> At least so far, there are no chips where apq vs msm actually
>> distinguishes anything. In fact, a simple "decoder ring" would point
>> out that the 'apq' usually corresponds with the second digit being a
>> zero. It doesn't help that we've added an 'mpq' prefix as well.
>>
>> I don't really see how to satisfy all of this other than qcom-apq*, or
>> just continue to use msm*.
I think going ahead with what David mentioned for msm* works if we can
be consistent or if we want to explicitly mention apq in the file name,
then
we can rename them to be qcom-msm* or qcom-apq* if people care about the
differences between them.
>
> I think msm has run out of steam, especially as more SoCs come out of Qualcomm that aren't just targeting phones & tablets.
>
> - k
>
Thanks,
Rohit Vaswani
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation
On Sep 16, 2013, at 1:28 PM, Rohit Vaswani wrote:
> On 9/12/2013 7:05 PM, Kumar Gala wrote:
>> On Sep 12, 2013, at 5:47 PM, David Brown wrote:
>>
>>> On Thu, Sep 12, 2013 at 12:55:36PM -0500, Kumar Gala wrote:
>>>> On Sep 12, 2013, at 12:06 PM, Olof Johansson wrote:
>>>>> My original request to please use a common prefix for your product
>>>>> families stands. Please prefix with msm-*, or if you have to, qcom-*
>>>>> instead, since you guys can't seem to make your mind up on standard
>>>>> prefixes (msm, apq, etc).
>>>> This is silly, I dont see the reason to go with
>>>> qcom-apq<SOC>-<BOARD>.dts and than in the future drop qcom- when we
>>>> mostly likely shift to a dir structure. As engineers we are all too
>>>> aware of the lack of sanity in marketing names, but its what we have
>>>> so we have to live with it.
>>> At least what we'd decided a year or two ago was to call _everything_
>>> with an msm* prefix. If marketing comes up with cute prefixes for
>>> things, we would basically ignore them. So, under that, it should be
>>> an msm8074-dragonboard. Admittedly, it might be a little confusing
>>> with the name of the product having the apq in it, but as others have
>>> pointed out, I think there is less confusing than not having a common
>>> prefix on our MSM products.
>>>
>>> At least so far, there are no chips where apq vs msm actually
>>> distinguishes anything. In fact, a simple "decoder ring" would point
>>> out that the 'apq' usually corresponds with the second digit being a
>>> zero. It doesn't help that we've added an 'mpq' prefix as well.
>>>
>>> I don't really see how to satisfy all of this other than qcom-apq*, or
>>> just continue to use msm*.
>
> I think going ahead with what David mentioned for msm* works if we can be consistent or if we want to explicitly mention apq in the file name, then
> we can rename them to be qcom-msm* or qcom-apq* if people care about the differences between them.
>
>>
>> I think msm has run out of steam, especially as more SoCs come out of Qualcomm that aren't just targeting phones & tablets.
>>
>> - k
I think the two options are either:
qcom-msm*, qcom-apq*, etc
or
qcom/msm-*, qcom/apq*, etc
I'm guessing we'll end up without the dir and in the future have:
qcom/qcom-msm-*, qcom/qcom-apq-*
Olof???
- k
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
On Mon, Sep 16, 2013 at 11:46 AM, Kumar Gala <[email protected]> wrote:
> I think the two options are either:
>
> qcom-msm*, qcom-apq*, etc
>
> or
>
> qcom/msm-*, qcom/apq*, etc
>
> I'm guessing we'll end up without the dir and in the future have:
>
> qcom/qcom-msm-*, qcom/qcom-apq-*
>
> Olof???
When you create the dir, you can go from qcom-msm-* to qcom/msm-*, but
still produce qcom-msm-*.dtb as the build output. We care about
keeping the DTB name stable, not DTS. As long as they just conform to
those two patterns it's easy to handle through makefile targets.
-Olof
On Sep 16, 2013, at 1:50 PM, Olof Johansson wrote:
> On Mon, Sep 16, 2013 at 11:46 AM, Kumar Gala <[email protected]> wrote:
>
>> I think the two options are either:
>>
>> qcom-msm*, qcom-apq*, etc
>>
>> or
>>
>> qcom/msm-*, qcom/apq*, etc
>>
>> I'm guessing we'll end up without the dir and in the future have:
>>
>> qcom/qcom-msm-*, qcom/qcom-apq-*
>>
>> Olof???
>
>
> When you create the dir, you can go from qcom-msm-* to qcom/msm-*, but
> still produce qcom-msm-*.dtb as the build output. We care about
> keeping the DTB name stable, not DTS. As long as they just conform to
> those two patterns it's easy to handle through makefile targets.
Sounds good, Rohit let's go ahead with qcom-msm-*, qcom-apq-*.
- k