All of lore.kernel.org
 help / color / mirror / Atom feed
From: mfuzzey@parkeon.com (Martin Fuzzey)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH] CLK: Allow parent clock and rate to be configured in DT.
Date: Mon, 08 Apr 2013 11:35:29 +0200	[thread overview]
Message-ID: <51628F61.9000300@parkeon.com> (raw)
In-Reply-To: <20130407132623.GP1906@pengutronix.de>

On 07/04/13 15:26, Sascha Hauer wrote:
>
> Honestly I'm annoyed by this aswell. The devicetree contains a nice and
> complete hardware description and it seems convenient to put hardware
> related configuration data there aswell.
Yes
> The problem is that hardware description and configuration data are two
> completely different sets of data. The hardware description is static
> for a given board and should (ideally) never change. The configuration
> data instead is often usecase specific and changes over the lifetime of
> a board. The configuration data can only handle a single (or maybe a
> table of) static setup(s). It's a good way to specify a sane default or
> a very special setup, but doesn't handle the case when some OS (or
> version thereof) wants to have a static setup and another wants to
> figure out the same data dynamically.
Agreed
> For these reasons I am against throwing the two data sets into a single
> pot. Still I also want to have the devicetree way to configure some
> static setup items.
Sure but why does using the DT for both mean "throwing them into a 
single pot?"

I think we need to seperate the ideas of "DT as a container format" and 
"semantics of DT nodes".

The format is the same everywhere but the semantics could change in 
different parts of the tree.

Since the DT is a tree structure surely all we need to do is agree on a 
designated configuration root node
"linux-config" for example under which we put all configuration related 
stuff specific to linux whilst
retaining the "hardware description only" rule for the rest of the DT.

Martin

WARNING: multiple messages have this Message-ID (diff)
From: Martin Fuzzey <mfuzzey-mB3Nsq4MPf1BDgjK7y7TUQ@public.gmane.org>
To: Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Cc: "devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org"
	<devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>,
	Tomasz Figa <tomasz.figa-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Fabio Estevam <festevam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	Mike Turquette <mturquette-l0cyMroinI0@public.gmane.org>
Subject: Re: [RFC PATCH] CLK: Allow parent clock and rate to be configured in DT.
Date: Mon, 08 Apr 2013 11:35:29 +0200	[thread overview]
Message-ID: <51628F61.9000300@parkeon.com> (raw)
In-Reply-To: <20130407132623.GP1906-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>

On 07/04/13 15:26, Sascha Hauer wrote:
>
> Honestly I'm annoyed by this aswell. The devicetree contains a nice and
> complete hardware description and it seems convenient to put hardware
> related configuration data there aswell.
Yes
> The problem is that hardware description and configuration data are two
> completely different sets of data. The hardware description is static
> for a given board and should (ideally) never change. The configuration
> data instead is often usecase specific and changes over the lifetime of
> a board. The configuration data can only handle a single (or maybe a
> table of) static setup(s). It's a good way to specify a sane default or
> a very special setup, but doesn't handle the case when some OS (or
> version thereof) wants to have a static setup and another wants to
> figure out the same data dynamically.
Agreed
> For these reasons I am against throwing the two data sets into a single
> pot. Still I also want to have the devicetree way to configure some
> static setup items.
Sure but why does using the DT for both mean "throwing them into a 
single pot?"

I think we need to seperate the ideas of "DT as a container format" and 
"semantics of DT nodes".

The format is the same everywhere but the semantics could change in 
different parts of the tree.

Since the DT is a tree structure surely all we need to do is agree on a 
designated configuration root node
"linux-config" for example under which we put all configuration related 
stuff specific to linux whilst
retaining the "hardware description only" rule for the rest of the DT.

Martin

  parent reply	other threads:[~2013-04-08  9:35 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-19 17:09 [RFC PATCH] CLK: Allow parent clock and rate to be configured in DT Martin Fuzzey
2013-03-19 17:09 ` Martin Fuzzey
2013-03-25 10:17 ` Sascha Hauer
2013-03-25 10:17   ` Sascha Hauer
2013-03-25 11:07   ` Martin Fuzzey
2013-03-25 11:07     ` Martin Fuzzey
2013-03-25 13:29     ` Sascha Hauer
2013-03-25 13:29       ` Sascha Hauer
2013-03-26 11:12       ` Martin Fuzzey
2013-03-26 11:12         ` Martin Fuzzey
2013-03-27  8:59         ` Sascha Hauer
2013-03-27  8:59           ` Sascha Hauer
2013-04-04 23:08   ` Fabio Estevam
2013-04-04 23:08     ` Fabio Estevam
2013-04-06  1:07     ` Matt Sealey
2013-04-06  1:07       ` Matt Sealey
2013-04-06  1:33       ` Matt Sealey
2013-04-06  1:33         ` Matt Sealey
2013-04-06 13:21       ` Tomasz Figa
2013-04-06 13:21         ` Tomasz Figa
2013-04-06 13:31         ` Tomasz Figa
2013-04-06 13:31           ` Tomasz Figa
2013-04-06 17:51         ` Martin Fuzzey
2013-04-06 17:51           ` Martin Fuzzey
2013-04-06 19:24           ` Matt Sealey
2013-04-06 19:24             ` Matt Sealey
2013-04-06 19:40             ` Fabio Estevam
2013-04-06 19:40               ` Fabio Estevam
2013-04-07 13:26         ` Sascha Hauer
2013-04-07 13:26           ` Sascha Hauer
2013-04-07 15:50           ` Matt Sealey
2013-04-07 15:50             ` Matt Sealey
2013-04-07 16:00             ` Fabio Estevam
2013-04-07 16:00               ` Fabio Estevam
2013-04-07 16:23               ` Matt Sealey
2013-04-07 16:23                 ` Matt Sealey
2013-04-07 16:34                 ` Matt Sealey
2013-04-07 16:34                   ` Matt Sealey
2013-04-07 21:14                   ` Tomasz Figa
2013-04-07 21:14                     ` Tomasz Figa
2013-04-08  9:35           ` Martin Fuzzey [this message]
2013-04-08  9:35             ` Martin Fuzzey
2013-04-08 20:00             ` Sascha Hauer
2013-04-08 20:00               ` Sascha Hauer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51628F61.9000300@parkeon.com \
    --to=mfuzzey@parkeon.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.