common location for devicetree files

common location for devicetree files

[Kumar Gala]

As we start having more sharing of device trees between architectures (arm & arm64, arm & powerpc, guessing maybe mips & arm) we need dts to live in location that 

I was wondering what people felt about doing:

	arch/dts/<VENDOR>/

as a common location that could be shared.  I'm up for other suggestions.

- k

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

Re: common location for devicetree files

[Jason Cooper]

On Thu, Nov 07, 2013 at 05:21:58PM -0600, Kumar Gala wrote:
> As we start having more sharing of device trees between architectures
> (arm & arm64, arm & powerpc, guessing maybe mips & arm) we need dts to
> live in location that 
> 
> I was wondering what people felt about doing:
> 
> 	arch/dts/<VENDOR>/
> 
> as a common location that could be shared.  I'm up for other
> suggestions.

What do we really need to do before the move?  Should all arch dts files
be able to #include from any arch?  What's the minimum churn needed to
accomplish that?  Maybe just move the needed bits to arch/dts/include/ ?

I'm not real keen on separating by vendor.  For example, us mvebu folks
would probably miss useful/duplicated effort in another vendor's
subdirectory.  Which was the whole reason for moving driver code out of
machine directories to begin with.

thx,

Jason.

Re: common location for devicetree files

[Kumar Gala]

On Nov 8, 2013, at 10:52 AM, Jason Cooper wrote:

> On Thu, Nov 07, 2013 at 05:21:58PM -0600, Kumar Gala wrote:
>> As we start having more sharing of device trees between architectures
>> (arm & arm64, arm & powerpc, guessing maybe mips & arm) we need dts to
>> live in location that 
>> 
>> I was wondering what people felt about doing:
>> 
>> 	arch/dts/<VENDOR>/
>> 
>> as a common location that could be shared.  I'm up for other
>> suggestions.
> 
> What do we really need to do before the move?  Should all arch dts files
> be able to #include from any arch?  What's the minimum churn needed to
> accomplish that?  Maybe just move the needed bits to arch/dts/include/ ?
> 
> I'm not real keen on separating by vendor.  For example, us mvebu folks
> would probably miss useful/duplicated effort in another vendor's
> subdirectory.  Which was the whole reason for moving driver code out of
> machine directories to begin with.


Can you explain that further, what would you miss from other vendors.  All the patches should still be going via devicetree ML.

- k

-- 
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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: common location for devicetree files

[Jason Cooper]

On Fri, Nov 08, 2013 at 11:59:56AM -0600, Kumar Gala wrote:
> 
> On Nov 8, 2013, at 10:52 AM, Jason Cooper wrote:
> 
> > On Thu, Nov 07, 2013 at 05:21:58PM -0600, Kumar Gala wrote:
> >> As we start having more sharing of device trees between architectures
> >> (arm & arm64, arm & powerpc, guessing maybe mips & arm) we need dts to
> >> live in location that 
> >> 
> >> I was wondering what people felt about doing:
> >> 
> >> 	arch/dts/<VENDOR>/
> >> 
> >> as a common location that could be shared.  I'm up for other
> >> suggestions.
> > 
> > What do we really need to do before the move?  Should all arch dts files
> > be able to #include from any arch?  What's the minimum churn needed to
> > accomplish that?  Maybe just move the needed bits to arch/dts/include/ ?
> > 
> > I'm not real keen on separating by vendor.  For example, us mvebu folks
> > would probably miss useful/duplicated effort in another vendor's
> > subdirectory.  Which was the whole reason for moving driver code out of
> > machine directories to begin with.
> 
> 
> Can you explain that further, what would you miss from other vendors.
> All the patches should still be going via devicetree ML.

I was simply applying the same logic used to justify moving all of the
driver code out of arch/arm/.  Once that happened, a lot of patterns
emerged and we have things like common clock now.  Yet all of this code
(originally under arch/arm) was submitted to the same ML.

iow, there's a difference between being on the same high-traffic
mailinglist where people are filtering out just what they need, and
being in the same subdirectory, right next to three other
implementations of the same code (I exaggerate, but the point remains).
It's a lot easier to spot similar implementations when they are all
congregated under one directory.

How many boards are using the same PMIC across vendors?  Would it make
sense to have a tps6905.dtsi they could all include?  Flash chips?  I'm
just asking.

My gut is that having separate vendor directories would lead to
balkanization.  That might not be a problem, but it's worth considering.

thx,

Jason.

Re: common location for devicetree files

[Kumar Gala]

On Nov 8, 2013, at 12:13 PM, Jason Cooper wrote:

> On Fri, Nov 08, 2013 at 11:59:56AM -0600, Kumar Gala wrote:
>> 
>> On Nov 8, 2013, at 10:52 AM, Jason Cooper wrote:
>> 
>>> On Thu, Nov 07, 2013 at 05:21:58PM -0600, Kumar Gala wrote:
>>>> As we start having more sharing of device trees between architectures
>>>> (arm & arm64, arm & powerpc, guessing maybe mips & arm) we need dts to
>>>> live in location that 
>>>> 
>>>> I was wondering what people felt about doing:
>>>> 
>>>> 	arch/dts/<VENDOR>/
>>>> 
>>>> as a common location that could be shared.  I'm up for other
>>>> suggestions.
>>> 
>>> What do we really need to do before the move?  Should all arch dts files
>>> be able to #include from any arch?  What's the minimum churn needed to
>>> accomplish that?  Maybe just move the needed bits to arch/dts/include/ ?
>>> 
>>> I'm not real keen on separating by vendor.  For example, us mvebu folks
>>> would probably miss useful/duplicated effort in another vendor's
>>> subdirectory.  Which was the whole reason for moving driver code out of
>>> machine directories to begin with.
>> 
>> 
>> Can you explain that further, what would you miss from other vendors.
>> All the patches should still be going via devicetree ML.
> 
> I was simply applying the same logic used to justify moving all of the
> driver code out of arch/arm/.  Once that happened, a lot of patterns
> emerged and we have things like common clock now.  Yet all of this code
> (originally under arch/arm) was submitted to the same ML.
> 
> iow, there's a difference between being on the same high-traffic
> mailinglist where people are filtering out just what they need, and
> being in the same subdirectory, right next to three other
> implementations of the same code (I exaggerate, but the point remains).
> It's a lot easier to spot similar implementations when they are all
> congregated under one directory.
> 
> How many boards are using the same PMIC across vendors?  Would it make
> sense to have a tps6905.dtsi they could all include?  Flash chips?  I'm
> just asking.
> 
> My gut is that having separate vendor directories would lead to
> balkanization.  That might not be a problem, but it's worth considering.
> 
> thx,
> 
> Jason.

I get the point, just not sure how else to sort the 800+ .dts{i} files that we have in the kernel tree right now.

I think common patterns have to be looked at by various maintainers.

- k

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

Re: common location for devicetree files

[Jason Cooper]

On Fri, Nov 08, 2013 at 12:17:30PM -0600, Kumar Gala wrote:
...
> I get the point, just not sure how else to sort the 800+ .dts{i} files
> that we have in the kernel tree right now.

Well, to start with, all #include'd files could go into a
arch/dts/include directory.  That would clean things up a bit.

We could also consider separating the dts files by ISA.  All armv7 in
one directory, armv8, armv5te, powerpc, mips, etc.  Since multiplatform
kernels would only support one of those directories, it would make build
products easier:

$ make multi_v7_defconfig && make dtbs
$ fancy_script.sh zImage arch/dts/armv7/*.dtb

Just a thought, I'm still not sold that the churn is worth it.

thx,

Jason.

Re: common location for devicetree files

[Stephen Warren]

On 11/08/2013 11:32 AM, Jason Cooper wrote:
> On Fri, Nov 08, 2013 at 12:17:30PM -0600, Kumar Gala wrote:
> ...
>> I get the point, just not sure how else to sort the 800+ .dts{i} files
>> that we have in the kernel tree right now.
> 
> Well, to start with, all #include'd files could go into a
> arch/dts/include directory.  That would clean things up a bit.
> 
> We could also consider separating the dts files by ISA.  All armv7 in
> one directory, armv8, armv5te, powerpc, mips, etc.

It's quite likely people will want to share some significant *.dtsi
across multiple architectures.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: common location for devicetree files

[Jason Cooper]

On Mon, Nov 11, 2013 at 09:24:13AM -0700, Stephen Warren wrote:
> On 11/08/2013 11:32 AM, Jason Cooper wrote:
> > On Fri, Nov 08, 2013 at 12:17:30PM -0600, Kumar Gala wrote:
> > ...
> >> I get the point, just not sure how else to sort the 800+ .dts{i} files
> >> that we have in the kernel tree right now.
> > 
> > Well, to start with, all #include'd files could go into a
> > arch/dts/include directory.  That would clean things up a bit.
> > 
> > We could also consider separating the dts files by ISA.  All armv7 in
> > one directory, armv8, armv5te, powerpc, mips, etc.
> 
> It's quite likely people will want to share some significant *.dtsi
> across multiple architectures.

Yes, I should've been more clear:

arch/
\-dts/
  |-armv5te/
  |-armv7/
  |-armv8/
  |-include/
  |-mips/
  |-powerpc/

etc.

so arch-independent includes could go in arch/dts/include/...

thx,

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

Re: common location for devicetree files

[Mark Rutland]

On Mon, Nov 11, 2013 at 04:24:13PM +0000, Stephen Warren wrote:
> On 11/08/2013 11:32 AM, Jason Cooper wrote:
> > On Fri, Nov 08, 2013 at 12:17:30PM -0600, Kumar Gala wrote:
> > ...
> >> I get the point, just not sure how else to sort the 800+ .dts{i} files
> >> that we have in the kernel tree right now.
> > 
> > Well, to start with, all #include'd files could go into a
> > arch/dts/include directory.  That would clean things up a bit.
> > 
> > We could also consider separating the dts files by ISA.  All armv7 in
> > one directory, armv8, armv5te, powerpc, mips, etc.
> 
> It's quite likely people will want to share some significant *.dtsi
> across multiple architectures.

At the moment we have some duplication of Versatile Express dtsi files
across the arm{,64}/boot/dts/ folders that could be shared. We already
share similar dtsi files between dts for ARMv7 and ARMv8 boards in
Pawel's external arm-dts repo [1].

Sharing across ISAs is important to me at least.

Mark.

[1] http://linux-arm.org/git?p=arm-dts.git;a=tree;f=versatile_express;h=7559c30fa94c471ff2a08c7936c5c01139d16f33;hb=18db2060268ae5b2b8616ba87376d73e338d4ca2

> --
> 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
> 

Re: common location for devicetree files

[Olof Johansson]

On Thu, Nov 7, 2013 at 3:21 PM, Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> wrote:
> As we start having more sharing of device trees between architectures (arm & arm64, arm & powerpc, guessing maybe mips & arm) we need dts to live in location that
>
> I was wondering what people felt about doing:
>
>         arch/dts/<VENDOR>/
>
> as a common location that could be shared.  I'm up for other suggestions.

dts isn't an architecture, so having it directly under arch/ doesn't
make sense. I know it's the first common parent of a lot of platforms
though.

I'd be ok with adding a toplevel dts/ directory for this, for lack of
better options. It doesn't really fit under firmware, lib, kernel,
scripts, tools...


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

Re: common location for devicetree files

[Jason Cooper]

On Fri, Nov 08, 2013 at 11:33:00AM -0800, Olof Johansson wrote:
> On Thu, Nov 7, 2013 at 3:21 PM, Kumar Gala <galak@codeaurora.org> wrote:
> > As we start having more sharing of device trees between architectures (arm & arm64, arm & powerpc, guessing maybe mips & arm) we need dts to live in location that
> >
> > I was wondering what people felt about doing:
> >
> >         arch/dts/<VENDOR>/
> >
> > as a common location that could be shared.  I'm up for other suggestions.
> 
> dts isn't an architecture, so having it directly under arch/ doesn't
> make sense. I know it's the first common parent of a lot of platforms
> though.
> 
> I'd be ok with adding a toplevel dts/ directory for this, for lack of
> better options. It doesn't really fit under firmware, lib, kernel,
> scripts, tools...

I'll admit I shied away from that thought (dts/) for fear of the wrath
of the greybeards.  :)

thx,

Jason.