devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sebastian Hesselbarth <sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>,
	Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
	"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>,
	Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Marc Zyngier <marc.zyngier-5wv7dgnIgG8@public.gmane.org>,
	Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>,
	Feng Kan <fkan-qTEPVZfXA3Y@public.gmane.org>,
	Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>,
	"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: [PATCH v2] ARM: realview: basic device tree implementation
Date: Thu, 29 May 2014 16:47:21 +0200	[thread overview]
Message-ID: <53874879.2080807@gmail.com> (raw)
In-Reply-To: <CACRpkdYVe+++Qb-CWrWwM1zDHxNqmpE0CFzp959Q40Zqb5sUEg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On 05/29/2014 04:13 PM, Linus Walleij wrote:
> On Thu, May 29, 2014 at 12:10 PM, Sebastian Hesselbarth
> <sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> On 05/29/2014 11:44 AM, Linus Walleij wrote:
>>> Hmmmm well I want to see that code before I believe it ... but
>>> I get what you mean.
>>
>> Well, the register set on Berlin I was thinking about tackles pinctrl,
>> padmux, clock, reset and some other freaky stuff I cannot recall. The
>> mess in it is that there is no order you can apply to split it up into
>> separate nodes. Moreover, the next SoC has some registers just shoved
>> into it, moving some other registers.
> 
> Berlin hardware engineers seem to be hellbent on complicating
> your life.

Tell me about it! ;)

Although, I don't think it is exclusive to Berlin but other vendors,
too.

>> The way we will go for it on Berlin is now:
>>
>> (a) have a single node for the whole chip-ctrl register set
>> (b) register clk driver on it (early, as it provides timer clk)
>> (c) register one chip-ctrl driver on it that will
>>     (d) reserve the iomap,
>>     (e) register a regmap-mmio,
>>     (f) register platform_devices for {pinctrl,reset,...} that will
>>         use regmap-mmio and read their properties from the single
>>         node
> 
> OK makes perfect sense actually.
> 
>> The individual drivers should stay in their respective drivers/ folder,
>> but (c) needs a good home. It would have been mach-foo in the past, and
>> could be drivers/soc now. In (f), I tend to just lookup regmap by name,
>> no DT involved at all.
> 
> OK
> 
>> BTW, syscon is of no use here at all, once it registers itself as a
>> driver for the node, there will be no other drivers registered. That
>> would at least require (again subsystem driven) dummy-nodes for
>> pinctrl, clk, reset.
> 
> Yeah that sucks, we need something more flexible no question
> about that.
> 
> Will the chipctrl driver be as generic as syscon or a
> Berlin-specific thing?

There is nothing berlin-specific about it except what regmap(s) and
platform_devices are registered. I can think of some generic helpers
to ease looping over regmap structs to be registered, IIRC driver core
already provides the same for platform_devices.

Actually, syscon is already a good starting point, it just lacks to
register platform_devices using the DT-registered regmap.

>> Also, using some of_xlate as we already have for clk, gpio, pinctrl ...
>> would put an end to syscon's syscon_get_regmap_from_{foo,bar,baz,...}
>> that gets a new helper every cycle.
> 
> This part I don't understand but I guess I will understand it
> when I see the code.

git grep 'struct regmap \*syscon' drivers/mfd/syscon.c
drivers/mfd/syscon.c:struct regmap *syscon_node_to_regmap(struct
device_node *np)
drivers/mfd/syscon.c:struct regmap
*syscon_regmap_lookup_by_compatible(const char *s)
drivers/mfd/syscon.c:struct regmap
*syscon_regmap_lookup_by_pdevname(const char *s)
drivers/mfd/syscon.c:struct regmap
*syscon_regmap_lookup_by_phandle(struct device_node *np,

and IIRC I have seen pending patches adding more syscon_regmap_by_foo
helpers.

My point is that we should have some regmap-provider to allow
us to use phandle+specifier, just like of_clk_get and friends work.

With some more time after v3.16-rc1 drops, I plan to provide a
chip-ctrl driver for Berlin. Most likely not too generic or based
on extending syscon but definitely something to talk about.

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

  parent reply	other threads:[~2014-05-29 14:47 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-08 22:08 [PATCH v2] ARM: realview: basic device tree implementation Linus Walleij
     [not found] ` <1399586896-16906-1-git-send-email-linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2014-05-09 10:44   ` Arnd Bergmann
     [not found]     ` <201405091244.02066.arnd-r2nGTMty4D4@public.gmane.org>
2014-05-22  7:41       ` Linus Walleij
     [not found]         ` <CACRpkdb8c=k3Ky=TisNdzycc3owJsNSQmSTu03RR5E0QvE0KZA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-05-22  8:31           ` Arnd Bergmann
2014-05-22 13:04             ` Linus Walleij
     [not found]               ` <CACRpkdYE0Fb+HezqgDbVcqQmWwn7QL2+RWSRyAigv2qcMp2qFQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-05-22 13:38                 ` Arnd Bergmann
2014-05-22 14:45             ` Catalin Marinas
     [not found]               ` <20140522144503.GA27931-5wv7dgnIgG8@public.gmane.org>
2014-05-22 15:49                 ` Arnd Bergmann
2014-05-22 16:09                   ` Catalin Marinas
2014-05-22 18:09                   ` Nicolas Pitre
     [not found]                     ` <alpine.LFD.2.11.1405221406100.17310-fMhRO7WWcppj+hNMo8g0rg@public.gmane.org>
2014-05-22 18:26                       ` Arnd Bergmann
2014-05-22 18:39                         ` Nicolas Pitre
     [not found]                           ` <alpine.LFD.2.11.1405221431370.17310-fMhRO7WWcppj+hNMo8g0rg@public.gmane.org>
2014-05-22 20:25                             ` Arnd Bergmann
2014-05-22 18:52                   ` Linus Walleij
     [not found]                     ` <CACRpkdZX=UFhMfUn68hA+s2FLGRYy_dmjRng_fHtAQEhah0oRA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-05-22 20:35                       ` Arnd Bergmann
2014-05-29  9:38                         ` Linus Walleij
2014-05-22 22:34           ` Sebastian Hesselbarth
     [not found]             ` <537E7B83.4020900-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-05-29  9:44               ` Linus Walleij
     [not found]                 ` <CACRpkdap1U19EiULnq11udhY91UnnNu_-5MnLby3idbdjzBj4Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-05-29 10:10                   ` Sebastian Hesselbarth
     [not found]                     ` <53870787.3030202-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-05-29 14:13                       ` Linus Walleij
     [not found]                         ` <CACRpkdYVe+++Qb-CWrWwM1zDHxNqmpE0CFzp959Q40Zqb5sUEg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-05-29 14:47                           ` Sebastian Hesselbarth [this message]
2014-05-22 13:17   ` Rob Herring
     [not found]     ` <CAL_JsqLN_f1uvrY6w7J7ZcR9pfM0_XKYMQ5YU8F4yAcMW+oDGw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-05-22 13:30       ` Linus Walleij
     [not found]         ` <CACRpkdaqsVUDA+6NC=EQmxcnDAnJEfPNYoptrEv=nq=eZEbA_g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-05-22 13:36           ` Arnd Bergmann
2014-05-28 22:47             ` Rob Herring
2014-05-22 13:41   ` Jason Cooper

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=53874879.2080807@gmail.com \
    --to=sebastian.hesselbarth-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
    --cc=arnd-r2nGTMty4D4@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=fkan-qTEPVZfXA3Y@public.gmane.org \
    --cc=linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=marc.zyngier-5wv7dgnIgG8@public.gmane.org \
    --cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \
    --cc=pawel.moll-5wv7dgnIgG8@public.gmane.org \
    --cc=robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org \
    --cc=will.deacon-5wv7dgnIgG8@public.gmane.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).