From: sebastian.hesselbarth@gmail.com (Sebastian Hesselbarth)
To: linux-arm-kernel@lists.infradead.org
Subject: [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@mail.gmail.com>
On 05/29/2014 04:13 PM, Linus Walleij wrote:
> On Thu, May 29, 2014 at 12:10 PM, Sebastian Hesselbarth
> <sebastian.hesselbarth@gmail.com> 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
WARNING: multiple messages have this Message-ID (diff)
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
next prev parent reply other threads:[~2014-05-29 14:47 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-08 22:08 [PATCH v2] ARM: realview: basic device tree implementation Linus Walleij
2014-05-08 22:08 ` Linus Walleij
2014-05-09 10:44 ` Arnd Bergmann
2014-05-09 10:44 ` Arnd Bergmann
2014-05-22 7:41 ` Linus Walleij
2014-05-22 7:41 ` Linus Walleij
2014-05-22 8:31 ` Arnd Bergmann
2014-05-22 8:31 ` Arnd Bergmann
2014-05-22 13:04 ` Linus Walleij
2014-05-22 13:04 ` Linus Walleij
2014-05-22 13:38 ` Arnd Bergmann
2014-05-22 13:38 ` Arnd Bergmann
2014-05-22 14:45 ` Catalin Marinas
2014-05-22 14:45 ` Catalin Marinas
2014-05-22 15:49 ` Arnd Bergmann
2014-05-22 15:49 ` Arnd Bergmann
2014-05-22 16:09 ` Catalin Marinas
2014-05-22 16:09 ` Catalin Marinas
2014-05-22 18:09 ` Nicolas Pitre
2014-05-22 18:09 ` Nicolas Pitre
2014-05-22 18:26 ` Arnd Bergmann
2014-05-22 18:26 ` Arnd Bergmann
2014-05-22 18:39 ` Nicolas Pitre
2014-05-22 18:39 ` Nicolas Pitre
2014-05-22 20:25 ` Arnd Bergmann
2014-05-22 20:25 ` Arnd Bergmann
2014-05-22 18:52 ` Linus Walleij
2014-05-22 18:52 ` Linus Walleij
2014-05-22 20:35 ` Arnd Bergmann
2014-05-22 20:35 ` Arnd Bergmann
2014-05-29 9:38 ` Linus Walleij
2014-05-29 9:38 ` Linus Walleij
2014-05-22 22:34 ` Sebastian Hesselbarth
2014-05-22 22:34 ` Sebastian Hesselbarth
2014-05-29 9:44 ` Linus Walleij
2014-05-29 9:44 ` Linus Walleij
2014-05-29 10:10 ` Sebastian Hesselbarth
2014-05-29 10:10 ` Sebastian Hesselbarth
2014-05-29 14:13 ` Linus Walleij
2014-05-29 14:13 ` Linus Walleij
2014-05-29 14:47 ` Sebastian Hesselbarth [this message]
2014-05-29 14:47 ` Sebastian Hesselbarth
2014-05-22 13:17 ` Rob Herring
2014-05-22 13:17 ` Rob Herring
2014-05-22 13:30 ` Linus Walleij
2014-05-22 13:30 ` Linus Walleij
2014-05-22 13:36 ` Arnd Bergmann
2014-05-22 13:36 ` Arnd Bergmann
2014-05-28 22:47 ` Rob Herring
2014-05-22 13:41 ` Jason Cooper
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@gmail.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.