All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v3/resend 3/4] drivers: bus: Add Simple Power-Managed Bus DT Bindings
Date: Fri, 23 Jan 2015 13:46:35 +0000	[thread overview]
Message-ID: <2160255.41m7rrCYxI@wuerfel> (raw)
In-Reply-To: <CAMuHMdUMcyXdgv+xdd8Zo67rYnfh6JaSWfr1H3c6NrQs=JsNLg@mail.gmail.com>

On Friday 23 January 2015 09:56:51 Geert Uytterhoeven wrote:
> >> diff --git a/Documentation/devicetree/bindings/bus/simple-pm-bus.txt b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt
> >> new file mode 100644
> >> index 0000000000000000..d03abf7fd8e3997a
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt
> >> @@ -0,0 +1,52 @@
> >> +Simple Power-Managed Bus
> >> +============
> >> +
> >> +A Simple Power-Managed Bus is a transparent bus that doesn't need a real
> >> +driver, as it's typically initialized by the boot loader.
> >> +
> >> +However, its bus controller is part of a PM domain, or under the control of a
> >> +functional clock.  Hence, the bus controller's PM domain and/or clock must be
> >> +enabled for child devices connected to the bus (either on-SoC or externally)
> >> +to function.
> >> +
> >> +
> >> +Generic compatible values and properties
> >> +----------------------------------------
> >> +
> >> +Required properties:
> >> +  - compatible: Must be at least one of the vendor-specific compatible values
> >> +             from a vendor-specific section below, and "simple-bus" as a
> >> +             fallback.
> >
> > What happened to the idea of using something like "simple-pm-bus"?
> 
> I think that's a decision to make by the (successor of the) ePAPR committee.
> At least it would be nice to get some feedback from the DT review team
> about this.
> 
> If we go that road, the vendor-specific compatible value should still be
> documented, else checkpatch will complain when encountering it in a DTS.
> Then, should it become
> 
>     compatible = "renesas,bsc-sh73a0", "renesas,bsc", "simple-pm-bus",
> "simple-bus";
> 
> or should "simple-bus" just be added to of_default_bus_match_table[], so we
> can drop "simple-bus" from the list in the DTS:
> 
>     compatible = "renesas,bsc-sh73a0", "renesas,bsc", "simple-pm-bus";

I was thinking of the reverse: drop "simple-bus" bus from the list here,
but not add "simple-pm-bus" to of_default_bus_match_table. This will
cause child devices to no longer be probed automatically, and you will
have to call of_platform_populate() from simple_pm_bus_probe(), after
pm_runtime_enable(). This seems like a cleaner model to me, for two
reasons:

- In the binding, claiming compatibility with "simple-bus" feels
  wrong to me, because you have a bus that is not as simple as others

- The ordering between pm_runtime_enable() and the probing of the
  child devices is guaranteed, which I think it is not with your
  current code.

Does this make sense, or am I missing an important reason why there
has to be a "simple-bus" compatible string here?

	Arnd

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Kevin Hilman <khilman@kernel.org>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	Rob Herring <robh+dt@kernel.org>, Pawel Moll <pawel.moll@arm.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Ian Campbell <ijc+devicetree@hellion.org.uk>,
	Kumar Gala <galak@codeaurora.org>,
	Grant Likely <grant.likely@linaro.org>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Olof Johansson <olof@lixom.net>,
	Simon Horman <horms+renesas@verge.net.au>,
	Magnus Damm <magnus.damm@gmail.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	Linux-sh list <linux-sh@vger.kernel.org>,
	Linux PM list <linux-pm@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3/resend 3/4] drivers: bus: Add Simple Power-Managed Bus DT Bindings
Date: Fri, 23 Jan 2015 14:46:35 +0100	[thread overview]
Message-ID: <2160255.41m7rrCYxI@wuerfel> (raw)
In-Reply-To: <CAMuHMdUMcyXdgv+xdd8Zo67rYnfh6JaSWfr1H3c6NrQs=JsNLg@mail.gmail.com>

On Friday 23 January 2015 09:56:51 Geert Uytterhoeven wrote:
> >> diff --git a/Documentation/devicetree/bindings/bus/simple-pm-bus.txt b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt
> >> new file mode 100644
> >> index 0000000000000000..d03abf7fd8e3997a
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt
> >> @@ -0,0 +1,52 @@
> >> +Simple Power-Managed Bus
> >> +========================
> >> +
> >> +A Simple Power-Managed Bus is a transparent bus that doesn't need a real
> >> +driver, as it's typically initialized by the boot loader.
> >> +
> >> +However, its bus controller is part of a PM domain, or under the control of a
> >> +functional clock.  Hence, the bus controller's PM domain and/or clock must be
> >> +enabled for child devices connected to the bus (either on-SoC or externally)
> >> +to function.
> >> +
> >> +
> >> +Generic compatible values and properties
> >> +----------------------------------------
> >> +
> >> +Required properties:
> >> +  - compatible: Must be at least one of the vendor-specific compatible values
> >> +             from a vendor-specific section below, and "simple-bus" as a
> >> +             fallback.
> >
> > What happened to the idea of using something like "simple-pm-bus"?
> 
> I think that's a decision to make by the (successor of the) ePAPR committee.
> At least it would be nice to get some feedback from the DT review team
> about this.
> 
> If we go that road, the vendor-specific compatible value should still be
> documented, else checkpatch will complain when encountering it in a DTS.
> Then, should it become
> 
>     compatible = "renesas,bsc-sh73a0", "renesas,bsc", "simple-pm-bus",
> "simple-bus";
> 
> or should "simple-bus" just be added to of_default_bus_match_table[], so we
> can drop "simple-bus" from the list in the DTS:
> 
>     compatible = "renesas,bsc-sh73a0", "renesas,bsc", "simple-pm-bus";

I was thinking of the reverse: drop "simple-bus" bus from the list here,
but not add "simple-pm-bus" to of_default_bus_match_table. This will
cause child devices to no longer be probed automatically, and you will
have to call of_platform_populate() from simple_pm_bus_probe(), after
pm_runtime_enable(). This seems like a cleaner model to me, for two
reasons:

- In the binding, claiming compatibility with "simple-bus" feels
  wrong to me, because you have a bus that is not as simple as others

- The ordering between pm_runtime_enable() and the probing of the
  child devices is guaranteed, which I think it is not with your
  current code.

Does this make sense, or am I missing an important reason why there
has to be a "simple-bus" compatible string here?

	Arnd

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Kevin Hilman <khilman@kernel.org>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	Rob Herring <robh+dt@kernel.org>, Pawel Moll <pawel.moll@arm.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Ian Campbell <ijc+devicetree@hellion.org.uk>,
	Kumar Gala <galak@codeaurora.org>,
	Grant Likely <grant.likely@linaro.org>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Olof Johansson <olof@lixom.net>,
	Simon Horman <horms+renesas@verge.net.au>,
	Magnus Damm <magnus.damm@gmail.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	Linux-sh list <linux-sh@vger.kernel.org>,
	Linux PM list <linux-pm@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3/resend 3/4] drivers: bus: Add Simple Power-Managed Bus DT Bindings
Date: Fri, 23 Jan 2015 14:46:35 +0100	[thread overview]
Message-ID: <2160255.41m7rrCYxI@wuerfel> (raw)
In-Reply-To: <CAMuHMdUMcyXdgv+xdd8Zo67rYnfh6JaSWfr1H3c6NrQs=JsNLg@mail.gmail.com>

On Friday 23 January 2015 09:56:51 Geert Uytterhoeven wrote:
> >> diff --git a/Documentation/devicetree/bindings/bus/simple-pm-bus.txt b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt
> >> new file mode 100644
> >> index 0000000000000000..d03abf7fd8e3997a
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt
> >> @@ -0,0 +1,52 @@
> >> +Simple Power-Managed Bus
> >> +========================
> >> +
> >> +A Simple Power-Managed Bus is a transparent bus that doesn't need a real
> >> +driver, as it's typically initialized by the boot loader.
> >> +
> >> +However, its bus controller is part of a PM domain, or under the control of a
> >> +functional clock.  Hence, the bus controller's PM domain and/or clock must be
> >> +enabled for child devices connected to the bus (either on-SoC or externally)
> >> +to function.
> >> +
> >> +
> >> +Generic compatible values and properties
> >> +----------------------------------------
> >> +
> >> +Required properties:
> >> +  - compatible: Must be at least one of the vendor-specific compatible values
> >> +             from a vendor-specific section below, and "simple-bus" as a
> >> +             fallback.
> >
> > What happened to the idea of using something like "simple-pm-bus"?
> 
> I think that's a decision to make by the (successor of the) ePAPR committee.
> At least it would be nice to get some feedback from the DT review team
> about this.
> 
> If we go that road, the vendor-specific compatible value should still be
> documented, else checkpatch will complain when encountering it in a DTS.
> Then, should it become
> 
>     compatible = "renesas,bsc-sh73a0", "renesas,bsc", "simple-pm-bus",
> "simple-bus";
> 
> or should "simple-bus" just be added to of_default_bus_match_table[], so we
> can drop "simple-bus" from the list in the DTS:
> 
>     compatible = "renesas,bsc-sh73a0", "renesas,bsc", "simple-pm-bus";

I was thinking of the reverse: drop "simple-bus" bus from the list here,
but not add "simple-pm-bus" to of_default_bus_match_table. This will
cause child devices to no longer be probed automatically, and you will
have to call of_platform_populate() from simple_pm_bus_probe(), after
pm_runtime_enable(). This seems like a cleaner model to me, for two
reasons:

- In the binding, claiming compatibility with "simple-bus" feels
  wrong to me, because you have a bus that is not as simple as others

- The ordering between pm_runtime_enable() and the probing of the
  child devices is guaranteed, which I think it is not with your
  current code.

Does this make sense, or am I missing an important reason why there
has to be a "simple-bus" compatible string here?

	Arnd

WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3/resend 3/4] drivers: bus: Add Simple Power-Managed Bus DT Bindings
Date: Fri, 23 Jan 2015 14:46:35 +0100	[thread overview]
Message-ID: <2160255.41m7rrCYxI@wuerfel> (raw)
In-Reply-To: <CAMuHMdUMcyXdgv+xdd8Zo67rYnfh6JaSWfr1H3c6NrQs=JsNLg@mail.gmail.com>

On Friday 23 January 2015 09:56:51 Geert Uytterhoeven wrote:
> >> diff --git a/Documentation/devicetree/bindings/bus/simple-pm-bus.txt b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt
> >> new file mode 100644
> >> index 0000000000000000..d03abf7fd8e3997a
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt
> >> @@ -0,0 +1,52 @@
> >> +Simple Power-Managed Bus
> >> +========================
> >> +
> >> +A Simple Power-Managed Bus is a transparent bus that doesn't need a real
> >> +driver, as it's typically initialized by the boot loader.
> >> +
> >> +However, its bus controller is part of a PM domain, or under the control of a
> >> +functional clock.  Hence, the bus controller's PM domain and/or clock must be
> >> +enabled for child devices connected to the bus (either on-SoC or externally)
> >> +to function.
> >> +
> >> +
> >> +Generic compatible values and properties
> >> +----------------------------------------
> >> +
> >> +Required properties:
> >> +  - compatible: Must be at least one of the vendor-specific compatible values
> >> +             from a vendor-specific section below, and "simple-bus" as a
> >> +             fallback.
> >
> > What happened to the idea of using something like "simple-pm-bus"?
> 
> I think that's a decision to make by the (successor of the) ePAPR committee.
> At least it would be nice to get some feedback from the DT review team
> about this.
> 
> If we go that road, the vendor-specific compatible value should still be
> documented, else checkpatch will complain when encountering it in a DTS.
> Then, should it become
> 
>     compatible = "renesas,bsc-sh73a0", "renesas,bsc", "simple-pm-bus",
> "simple-bus";
> 
> or should "simple-bus" just be added to of_default_bus_match_table[], so we
> can drop "simple-bus" from the list in the DTS:
> 
>     compatible = "renesas,bsc-sh73a0", "renesas,bsc", "simple-pm-bus";

I was thinking of the reverse: drop "simple-bus" bus from the list here,
but not add "simple-pm-bus" to of_default_bus_match_table. This will
cause child devices to no longer be probed automatically, and you will
have to call of_platform_populate() from simple_pm_bus_probe(), after
pm_runtime_enable(). This seems like a cleaner model to me, for two
reasons:

- In the binding, claiming compatibility with "simple-bus" feels
  wrong to me, because you have a bus that is not as simple as others

- The ordering between pm_runtime_enable() and the probing of the
  child devices is guaranteed, which I think it is not with your
  current code.

Does this make sense, or am I missing an important reason why there
has to be a "simple-bus" compatible string here?

	Arnd

  reply	other threads:[~2015-01-23 13:46 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-22  9:34 [PATCH v3/resend 0/4] drivers: bus: Add Simple Power-Managed Bus Geert Uytterhoeven
2015-01-22  9:34 ` Geert Uytterhoeven
2015-01-22  9:34 ` Geert Uytterhoeven
2015-01-22  9:34 ` [PATCH v3/resend 1/4] drivers: bus: Sort Kconfig entries alphabetically Geert Uytterhoeven
2015-01-22  9:34   ` Geert Uytterhoeven
2015-01-22  9:34   ` Geert Uytterhoeven
2015-01-22  9:34 ` [PATCH v3/resend 2/4] drivers: bus: Sort Makefile " Geert Uytterhoeven
2015-01-22  9:34   ` Geert Uytterhoeven
2015-01-22  9:34   ` Geert Uytterhoeven
2015-01-22  9:34 ` [PATCH v3/resend 3/4] drivers: bus: Add Simple Power-Managed Bus DT Bindings Geert Uytterhoeven
2015-01-22  9:34   ` Geert Uytterhoeven
2015-01-22  9:34   ` Geert Uytterhoeven
2015-01-22 22:42   ` Kevin Hilman
2015-01-22 22:42     ` Kevin Hilman
2015-01-22 22:42     ` Kevin Hilman
2015-01-23  8:56     ` Geert Uytterhoeven
2015-01-23  8:56       ` Geert Uytterhoeven
2015-01-23  8:56       ` Geert Uytterhoeven
2015-01-23  8:56       ` Geert Uytterhoeven
2015-01-23 13:46       ` Arnd Bergmann [this message]
2015-01-23 13:46         ` Arnd Bergmann
2015-01-23 13:46         ` Arnd Bergmann
2015-01-23 13:46         ` Arnd Bergmann
2015-01-23 14:18         ` Geert Uytterhoeven
2015-01-23 14:18           ` Geert Uytterhoeven
2015-01-23 14:18           ` Geert Uytterhoeven
2015-01-23 14:18           ` Geert Uytterhoeven
2015-01-23 14:34         ` Mark Rutland
2015-01-23 14:34           ` Mark Rutland
2015-01-23 14:34           ` Mark Rutland
2015-01-23 14:34           ` Mark Rutland
2015-01-22  9:34 ` [PATCH v3/resend 4/4] drivers: bus: Add Simple Power-Managed Bus Driver Geert Uytterhoeven
2015-01-22  9:34   ` Geert Uytterhoeven
2015-01-22  9:34   ` Geert Uytterhoeven

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=2160255.41m7rrCYxI@wuerfel \
    --to=arnd@arndb.de \
    --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.