All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rafael@kernel.org>
To: Peter Chen <hzpeterchen@gmail.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Peter Chen <peter.chen@nxp.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	Heiko Stuebner <heiko@sntech.de>,
	Stephen Boyd <stephen.boyd@linaro.org>,
	frank.li@nxp.com,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Gary Bisson <gary.bisson@boundarydevices.com>,
	Fabio Estevam <festevam@gmail.com>,
	Joshua Clayton <stillcompiling@gmail.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>,
	Vaibhav Hiremath <vaibhav.hiremath@linaro.org>,
	Krzysztof Kozlowski <krzk@kernel.org>,
	mka@chromium.org, Alan Stern <stern@rowland.harvard.edu>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	mail@maciej.szmigiero.name, Pawel Moll <pawel.moll@arm.com>,
	Linux PM <linux-pm@vger.kernel.org>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	troy.kisky@boundarydevices.com, Rob Herring <robh+dt@kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	hverkuil@xs4all.nl, oscar@naiandei.net,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:" 
	<linux-usb@vger.kernel.org>, Sebastian Reichel <sre@kernel.org>,
	Mark Brown <broonie@kernel.org>,
	p.zabel@pengutronix.de, Shawn Guo <shawnguo@kernel.org>,
	jun.li@nxp.com
Subject: Re: [PATCH v16 2/7] power: add power sequence library
Date: Tue, 18 Jul 2017 19:06:05 +0200	[thread overview]
Message-ID: <CAJZ5v0hGbJuqqY6Pq5cYPrawSGW-zdhYHj0ovhJ9zXRAkBPCRQ@mail.gmail.com> (raw)
In-Reply-To: <20170718042955.GA12080@b29397-desktop>

On Tue, Jul 18, 2017 at 6:29 AM, Peter Chen <hzpeterchen@gmail.com> wrote:
> On Mon, Jul 17, 2017 at 03:39:07PM +0200, Rafael J. Wysocki wrote:
>> > Sorry, I should describe more.
>> >
>> > Let's take USB bus as an example, when the new USB device is at the
>> > host port, the device structure at device model is not created until
>> > it is discoverable by the USB bus. If this new USB device needs to be
>> > powered on before can be discoverable by the bus, the device structure
>> > will be not created without powering on operation. The code usb_alloc_dev
>> > (drivers/usb/core/usb.c) is only called for discoverable device.
>> >
>> > Unlike the other bus, eg, platform bus, it creates device structure
>> > according to DT node. The USB bus was designed for hot plug model, the
>> > device structure is for discoverable device. In recent years, we begin
>> > to have some hard-wired USB device, Eg, onboard USB-hub, onboard USB 4G
>> > Modem, etc at the market. It needs some board level power operation before
>> > it can be found by the USB bus. This patch set is designed primarily for
>> > fix this kind of problem. You will see at at pwrseq_generic.c, we use DT
>> > version clock API of_clk_get and DT version gpio API of_get_named_gpio_flags
>> > instead of device structure version, like devm_clk_get and
>> > devm_gpiod_get_optional.
>> >
>> > MMC system has similar use case, it creates power sequence platform
>> > device for this issue, but all those power stuffs (clock, gpio, etc)
>> > may not be suitable as a dedicated virtual device at DT, they are belonged
>> > to one physical device, so this patch set is created to see if this issue
>> > can be fixed better.
>>
>> OK, thanks for the explanation.
>>
>> The above needs to be part of your problem statement.
>
> Ok, I will add it to cover letter.
>
>> >
>> > The bus will power up all device nodes in this bus according to DT
>> > information, the device structure has not created at this time.
>>
>> OK
>>
>> I still think that the information on power resources depended on by devices
>> should be used for power management as well as for the initial power-up.
>>
>> The most straightforward way to arrange for that would be to make it possible
>> to find the DT node matching the device after the device has been discovered
>> and struct device created for it, say by USB.  That would require adding some
>> more information on the device to the DT node, probably.
>
> After the device is created, the device node structure is under struct
> device, say dev->of_node. The most difficulty for this issue is the
> device creation is dynamic and is after the physical device is
> discovered by the bus, the initial power-up is needed before the device
> can be discovered by the bus.

So you power up all devices on the bus using the information from
of_nodes upfront.

Then you scan the bus and discover devices.  For each of them, once it
has been discovered, you look up a matching of_node and initialize
power_state from there.

>>
>> Then, the DT device nodes would be used for the initial power-up and next, after
>> discovering a device, you'd do a lookup in the DT, find the node matching it
>> and read the power resuources information from there to populate the device's
>> power state structure.  From that point on you can simply use the interface I
>> suggested.
>>
>
> Just like I said above, without initial power-up, the device can't be
> discovered by the bus.

Right.

So you do the power up upfront, as per the above.

Thanks,
Rafael

WARNING: multiple messages have this Message-ID (diff)
From: "Rafael J. Wysocki" <rafael@kernel.org>
To: Peter Chen <hzpeterchen@gmail.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Peter Chen <peter.chen@nxp.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	Heiko Stuebner <heiko@sntech.de>,
	Stephen Boyd <stephen.boyd@linaro.org>,
	frank.li@nxp.com,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Gary Bisson <gary.bisson@boundarydevices.com>,
	Fabio Estevam <festevam@gmail.com>,
	Joshua Clayton <stillcompiling@gmail.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>,
	Vaibhav Hiremath <vaibhav.hiremath@linaro.org>,
	Krzysztof Kozlowski <krzk@kernel.org>,
	mka@chromium.org, Alan Stern <stern@rowland.harvard.edu>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	mail@maciej.szmigiero.name, Pawel Moll <pawel.moll@arm.com>
Subject: Re: [PATCH v16 2/7] power: add power sequence library
Date: Tue, 18 Jul 2017 19:06:05 +0200	[thread overview]
Message-ID: <CAJZ5v0hGbJuqqY6Pq5cYPrawSGW-zdhYHj0ovhJ9zXRAkBPCRQ@mail.gmail.com> (raw)
In-Reply-To: <20170718042955.GA12080@b29397-desktop>

On Tue, Jul 18, 2017 at 6:29 AM, Peter Chen <hzpeterchen@gmail.com> wrote:
> On Mon, Jul 17, 2017 at 03:39:07PM +0200, Rafael J. Wysocki wrote:
>> > Sorry, I should describe more.
>> >
>> > Let's take USB bus as an example, when the new USB device is at the
>> > host port, the device structure at device model is not created until
>> > it is discoverable by the USB bus. If this new USB device needs to be
>> > powered on before can be discoverable by the bus, the device structure
>> > will be not created without powering on operation. The code usb_alloc_dev
>> > (drivers/usb/core/usb.c) is only called for discoverable device.
>> >
>> > Unlike the other bus, eg, platform bus, it creates device structure
>> > according to DT node. The USB bus was designed for hot plug model, the
>> > device structure is for discoverable device. In recent years, we begin
>> > to have some hard-wired USB device, Eg, onboard USB-hub, onboard USB 4G
>> > Modem, etc at the market. It needs some board level power operation before
>> > it can be found by the USB bus. This patch set is designed primarily for
>> > fix this kind of problem. You will see at at pwrseq_generic.c, we use DT
>> > version clock API of_clk_get and DT version gpio API of_get_named_gpio_flags
>> > instead of device structure version, like devm_clk_get and
>> > devm_gpiod_get_optional.
>> >
>> > MMC system has similar use case, it creates power sequence platform
>> > device for this issue, but all those power stuffs (clock, gpio, etc)
>> > may not be suitable as a dedicated virtual device at DT, they are belonged
>> > to one physical device, so this patch set is created to see if this issue
>> > can be fixed better.
>>
>> OK, thanks for the explanation.
>>
>> The above needs to be part of your problem statement.
>
> Ok, I will add it to cover letter.
>
>> >
>> > The bus will power up all device nodes in this bus according to DT
>> > information, the device structure has not created at this time.
>>
>> OK
>>
>> I still think that the information on power resources depended on by devices
>> should be used for power management as well as for the initial power-up.
>>
>> The most straightforward way to arrange for that would be to make it possible
>> to find the DT node matching the device after the device has been discovered
>> and struct device created for it, say by USB.  That would require adding some
>> more information on the device to the DT node, probably.
>
> After the device is created, the device node structure is under struct
> device, say dev->of_node. The most difficulty for this issue is the
> device creation is dynamic and is after the physical device is
> discovered by the bus, the initial power-up is needed before the device
> can be discovered by the bus.

So you power up all devices on the bus using the information from
of_nodes upfront.

Then you scan the bus and discover devices.  For each of them, once it
has been discovered, you look up a matching of_node and initialize
power_state from there.

>>
>> Then, the DT device nodes would be used for the initial power-up and next, after
>> discovering a device, you'd do a lookup in the DT, find the node matching it
>> and read the power resuources information from there to populate the device's
>> power state structure.  From that point on you can simply use the interface I
>> suggested.
>>
>
> Just like I said above, without initial power-up, the device can't be
> discovered by the bus.

Right.

So you do the power up upfront, as per the above.

Thanks,
Rafael

WARNING: multiple messages have this Message-ID (diff)
From: rafael@kernel.org (Rafael J. Wysocki)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v16 2/7] power: add power sequence library
Date: Tue, 18 Jul 2017 19:06:05 +0200	[thread overview]
Message-ID: <CAJZ5v0hGbJuqqY6Pq5cYPrawSGW-zdhYHj0ovhJ9zXRAkBPCRQ@mail.gmail.com> (raw)
In-Reply-To: <20170718042955.GA12080@b29397-desktop>

On Tue, Jul 18, 2017 at 6:29 AM, Peter Chen <hzpeterchen@gmail.com> wrote:
> On Mon, Jul 17, 2017 at 03:39:07PM +0200, Rafael J. Wysocki wrote:
>> > Sorry, I should describe more.
>> >
>> > Let's take USB bus as an example, when the new USB device is at the
>> > host port, the device structure at device model is not created until
>> > it is discoverable by the USB bus. If this new USB device needs to be
>> > powered on before can be discoverable by the bus, the device structure
>> > will be not created without powering on operation. The code usb_alloc_dev
>> > (drivers/usb/core/usb.c) is only called for discoverable device.
>> >
>> > Unlike the other bus, eg, platform bus, it creates device structure
>> > according to DT node. The USB bus was designed for hot plug model, the
>> > device structure is for discoverable device. In recent years, we begin
>> > to have some hard-wired USB device, Eg, onboard USB-hub, onboard USB 4G
>> > Modem, etc at the market. It needs some board level power operation before
>> > it can be found by the USB bus. This patch set is designed primarily for
>> > fix this kind of problem. You will see at at pwrseq_generic.c, we use DT
>> > version clock API of_clk_get and DT version gpio API of_get_named_gpio_flags
>> > instead of device structure version, like devm_clk_get and
>> > devm_gpiod_get_optional.
>> >
>> > MMC system has similar use case, it creates power sequence platform
>> > device for this issue, but all those power stuffs (clock, gpio, etc)
>> > may not be suitable as a dedicated virtual device at DT, they are belonged
>> > to one physical device, so this patch set is created to see if this issue
>> > can be fixed better.
>>
>> OK, thanks for the explanation.
>>
>> The above needs to be part of your problem statement.
>
> Ok, I will add it to cover letter.
>
>> >
>> > The bus will power up all device nodes in this bus according to DT
>> > information, the device structure has not created at this time.
>>
>> OK
>>
>> I still think that the information on power resources depended on by devices
>> should be used for power management as well as for the initial power-up.
>>
>> The most straightforward way to arrange for that would be to make it possible
>> to find the DT node matching the device after the device has been discovered
>> and struct device created for it, say by USB.  That would require adding some
>> more information on the device to the DT node, probably.
>
> After the device is created, the device node structure is under struct
> device, say dev->of_node. The most difficulty for this issue is the
> device creation is dynamic and is after the physical device is
> discovered by the bus, the initial power-up is needed before the device
> can be discovered by the bus.

So you power up all devices on the bus using the information from
of_nodes upfront.

Then you scan the bus and discover devices.  For each of them, once it
has been discovered, you look up a matching of_node and initialize
power_state from there.

>>
>> Then, the DT device nodes would be used for the initial power-up and next, after
>> discovering a device, you'd do a lookup in the DT, find the node matching it
>> and read the power resuources information from there to populate the device's
>> power state structure.  From that point on you can simply use the interface I
>> suggested.
>>
>
> Just like I said above, without initial power-up, the device can't be
> discovered by the bus.

Right.

So you do the power up upfront, as per the above.

Thanks,
Rafael

  reply	other threads:[~2017-07-18 17:06 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-21  6:42 [PATCH v16 0/7] power: add power sequence library Peter Chen
2017-06-21  6:42 ` Peter Chen
2017-06-21  6:42 ` Peter Chen
2017-06-21  6:42 ` [PATCH v16 1/7] binding-doc: power: pwrseq-generic: add binding doc for generic " Peter Chen
2017-06-21  6:42   ` Peter Chen
2017-06-21  6:42   ` Peter Chen
2017-06-21  6:42 ` [PATCH v16 2/7] power: add " Peter Chen
2017-06-21  6:42   ` Peter Chen
2017-06-21  6:42   ` Peter Chen
2017-07-05  0:44   ` Rafael J. Wysocki
2017-07-05  0:44     ` Rafael J. Wysocki
2017-07-05 11:54     ` Peter Chen
2017-07-05 11:54       ` Peter Chen
2017-07-05 11:54       ` Peter Chen
2017-07-07  1:13       ` Rafael J. Wysocki
2017-07-07  1:13         ` Rafael J. Wysocki
2017-07-07  8:01         ` Peter Chen
2017-07-07  8:01           ` Peter Chen
2017-07-07  8:01           ` Peter Chen
2017-07-07 13:03           ` Rafael J. Wysocki
2017-07-07 13:03             ` Rafael J. Wysocki
2017-07-08  5:51             ` Peter Chen
2017-07-08  5:51               ` Peter Chen
2017-07-08  5:51               ` Peter Chen
2017-07-08 12:14               ` Rafael J. Wysocki
2017-07-08 12:14                 ` Rafael J. Wysocki
2017-07-08 12:14                 ` Rafael J. Wysocki
2017-07-10  2:28                 ` Peter Chen
2017-07-10  2:28                   ` Peter Chen
2017-07-10  2:28                   ` Peter Chen
2017-07-17 13:39                   ` Rafael J. Wysocki
2017-07-17 13:39                     ` Rafael J. Wysocki
2017-07-18  4:29                     ` Peter Chen
2017-07-18  4:29                       ` Peter Chen
2017-07-18  4:29                       ` Peter Chen
2017-07-18 17:06                       ` Rafael J. Wysocki [this message]
2017-07-18 17:06                         ` Rafael J. Wysocki
2017-07-18 17:06                         ` Rafael J. Wysocki
2017-07-19  2:56                         ` Peter Chen
2017-07-19  2:56                           ` Peter Chen
2017-07-19  2:56                           ` Peter Chen
2017-07-19 11:34                           ` Rafael J. Wysocki
2017-07-19 11:34                             ` Rafael J. Wysocki
2017-07-19 11:34                             ` Rafael J. Wysocki
2017-07-20  9:35                             ` Peter Chen
2017-07-20  9:35                               ` Peter Chen
2017-07-20  9:35                               ` Peter Chen
2017-06-21  6:42 ` [PATCH v16 3/7] binding-doc: usb: usb-device: add optional properties for power sequence Peter Chen
2017-06-21  6:42   ` Peter Chen
2017-06-21  6:42   ` Peter Chen
2017-06-21  6:42 ` [PATCH v16 4/7] usb: core: add power sequence handling for USB devices Peter Chen
2017-06-21  6:42   ` Peter Chen
2017-06-21  6:42   ` Peter Chen
2017-06-21  6:42 ` [PATCH v16 5/7] ARM: dts: imx6qdl: Enable usb node children with <reg> Peter Chen
2017-06-21  6:42   ` Peter Chen
2017-06-21  6:42   ` Peter Chen
2017-06-21  6:42 ` [PATCH v16 6/7] ARM: dts: imx6qdl-udoo.dtsi: fix onboard USB HUB property Peter Chen
2017-06-21  6:42   ` Peter Chen
2017-06-21  6:42   ` Peter Chen
2017-06-21  6:42 ` [PATCH v16 7/7] ARM: dts: imx6q-evi: Fix onboard hub reset line Peter Chen
2017-06-21  6:42   ` Peter Chen
2017-06-21  6:42   ` Peter Chen

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=CAJZ5v0hGbJuqqY6Pq5cYPrawSGW-zdhYHj0ovhJ9zXRAkBPCRQ@mail.gmail.com \
    --to=rafael@kernel.org \
    --cc=arnd@arndb.de \
    --cc=broonie@kernel.org \
    --cc=dbaryshkov@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=festevam@gmail.com \
    --cc=frank.li@nxp.com \
    --cc=gary.bisson@boundarydevices.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=heiko@sntech.de \
    --cc=hverkuil@xs4all.nl \
    --cc=hzpeterchen@gmail.com \
    --cc=jun.li@nxp.com \
    --cc=krzk@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mail@maciej.szmigiero.name \
    --cc=mark.rutland@arm.com \
    --cc=mka@chromium.org \
    --cc=oscar@naiandei.net \
    --cc=p.zabel@pengutronix.de \
    --cc=pawel.moll@arm.com \
    --cc=peter.chen@nxp.com \
    --cc=rjw@rjwysocki.net \
    --cc=robh+dt@kernel.org \
    --cc=s.hauer@pengutronix.de \
    --cc=shawnguo@kernel.org \
    --cc=sre@kernel.org \
    --cc=stephen.boyd@linaro.org \
    --cc=stern@rowland.harvard.edu \
    --cc=stillcompiling@gmail.com \
    --cc=troy.kisky@boundarydevices.com \
    --cc=ulf.hansson@linaro.org \
    --cc=vaibhav.hiremath@linaro.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.