From: Ulf Hansson <ulf.hansson@linaro.org>
To: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Vinod Koul <vinod.koul@intel.com>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
linux-samsung-soc <linux-samsung-soc@vger.kernel.org>,
dmaengine@vger.kernel.org,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Krzysztof Kozlowski <krzk@kernel.org>,
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
Lars-Peter Clausen <lars@metafoo.de>,
Arnd Bergmann <arnd@arndb.de>, Inki Dae <inki.dae@samsung.com>
Subject: Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM
Date: Mon, 13 Feb 2017 16:09:56 +0100 [thread overview]
Message-ID: <CAPDyKFr6qB7j23E2pVqkBn8OWRZkwE_Diex8ttPiyPWZrruFYw@mail.gmail.com> (raw)
In-Reply-To: <cbccef67-54da-27ce-d0c0-ac57ef251b9b@samsung.com>
[...]
>> The only related PM thing, that shall be the decision of the driver,
>> is whether it wants to enable runtime PM or not, during ->probe().
>
>
> So do you want to create the links during the DMAengine driver probe? How do
> you
> plan to find all the client devices? Please note that you really want to
> create
> links to devices which will really use the DMA engine calls. Some client
> drivers might decide in runtime weather to use DMA engine or not, depending
> on
> other data.
I don't have great plan, just wanted to share my thoughts around the
problems we want to solve.
[...]
>>
>> If we could set up the device link already at device initialization,
>> it should also be possible to avoid getting -EPROBE_DEFER for dma
>> client drivers when requesting their dma channels.
>
>
> At the first glance this sounds like an ultimate solution for all problems,
> but I don't think that device links can be used this way. If I get it right,
> you would like to create links on client device initialization, preferably
> somewhere in the kernel driver core. This will be handled somehow by a
> completely generic code, which will create a link each pair of devices,
> which are connected by a phandle. Is this what you meant? Please note that
> that time no driver for both client and provider are probed. IMHO that
> doesn't look like a right generic approach
>
> How that code will know get following information:
> 1. is it really needed to create a link for given device pair?
> 2. what link flags should it use?
> 3. what about circular dependencies?
> 4. what about runtime optional dependencies?
> 5. what about non-dt platforms? acpi?
>
To give a good answer of these questions, I need to spend more time
investigating.
However, from a top-level point of view, I think the device links
seems like the perfect match for solving the runtime/system PM
problems.
No matter whether we can set up the links at device initialization
time, driver probe or whatever time.
> This looks like another newer ending story of "how can we avoid deferred
> probe
> in a generic way". IMHO we should first solve the problem of irq-safe
> runtime
> PM in DMA engine drivers first. I proposed how it can be done with device
> links.
> With no changes in the client API. Later if one decide to extend the client
> API
> in a way it will allow other runtime PM implementation - I see no problem to
> convert pl330 driver to the new approach, but for the time being - this
> would
> be the easiest way to get it really functional.
Agree, let's drop the deferred probe topic from the discussions - it's
just going to be overwhelming. :-)
[...]
>> So besides solving the irq-safe issue for dma driver, using the
>> device-links has additionally two advantages. I already mentioned the
>> -EPROBE_DEFER issue above.
>
>
> Not really. IMHO device links can be properly established once both drivers
> are probed...
Okay.
>
>>
>> The second thing, is the runtime/system PM relations we get for free
>> by using the links. In other words, the dma driver/core don't need to
>> care about dealing with pm_runtime_get|put() as that would be managed
>> by the dma client driver.
>
>
> IMHO there might be drivers which don't want to use device links based
> runtime
> PM in favor of irq-safe PM or something else. This should be really left to
> drivers.
Okay.
Kind regards
Uffe
WARNING: multiple messages have this Message-ID (diff)
From: Ulf Hansson <ulf.hansson@linaro.org>
To: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: linux-samsung-soc <linux-samsung-soc@vger.kernel.org>,
Arnd Bergmann <arnd@arndb.de>,
"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
Vinod Koul <vinod.koul@intel.com>,
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Krzysztof Kozlowski <krzk@kernel.org>,
Inki Dae <inki.dae@samsung.com>,
Lars-Peter Clausen <lars@metafoo.de>,
dmaengine@vger.kernel.org,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM
Date: Mon, 13 Feb 2017 16:09:56 +0100 [thread overview]
Message-ID: <CAPDyKFr6qB7j23E2pVqkBn8OWRZkwE_Diex8ttPiyPWZrruFYw@mail.gmail.com> (raw)
In-Reply-To: <cbccef67-54da-27ce-d0c0-ac57ef251b9b@samsung.com>
[...]
>> The only related PM thing, that shall be the decision of the driver,
>> is whether it wants to enable runtime PM or not, during ->probe().
>
>
> So do you want to create the links during the DMAengine driver probe? How do
> you
> plan to find all the client devices? Please note that you really want to
> create
> links to devices which will really use the DMA engine calls. Some client
> drivers might decide in runtime weather to use DMA engine or not, depending
> on
> other data.
I don't have great plan, just wanted to share my thoughts around the
problems we want to solve.
[...]
>>
>> If we could set up the device link already at device initialization,
>> it should also be possible to avoid getting -EPROBE_DEFER for dma
>> client drivers when requesting their dma channels.
>
>
> At the first glance this sounds like an ultimate solution for all problems,
> but I don't think that device links can be used this way. If I get it right,
> you would like to create links on client device initialization, preferably
> somewhere in the kernel driver core. This will be handled somehow by a
> completely generic code, which will create a link each pair of devices,
> which are connected by a phandle. Is this what you meant? Please note that
> that time no driver for both client and provider are probed. IMHO that
> doesn't look like a right generic approach
>
> How that code will know get following information:
> 1. is it really needed to create a link for given device pair?
> 2. what link flags should it use?
> 3. what about circular dependencies?
> 4. what about runtime optional dependencies?
> 5. what about non-dt platforms? acpi?
>
To give a good answer of these questions, I need to spend more time
investigating.
However, from a top-level point of view, I think the device links
seems like the perfect match for solving the runtime/system PM
problems.
No matter whether we can set up the links at device initialization
time, driver probe or whatever time.
> This looks like another newer ending story of "how can we avoid deferred
> probe
> in a generic way". IMHO we should first solve the problem of irq-safe
> runtime
> PM in DMA engine drivers first. I proposed how it can be done with device
> links.
> With no changes in the client API. Later if one decide to extend the client
> API
> in a way it will allow other runtime PM implementation - I see no problem to
> convert pl330 driver to the new approach, but for the time being - this
> would
> be the easiest way to get it really functional.
Agree, let's drop the deferred probe topic from the discussions - it's
just going to be overwhelming. :-)
[...]
>> So besides solving the irq-safe issue for dma driver, using the
>> device-links has additionally two advantages. I already mentioned the
>> -EPROBE_DEFER issue above.
>
>
> Not really. IMHO device links can be properly established once both drivers
> are probed...
Okay.
>
>>
>> The second thing, is the runtime/system PM relations we get for free
>> by using the links. In other words, the dma driver/core don't need to
>> care about dealing with pm_runtime_get|put() as that would be managed
>> by the dma client driver.
>
>
> IMHO there might be drivers which don't want to use device links based
> runtime
> PM in favor of irq-safe PM or something else. This should be really left to
> drivers.
Okay.
Kind regards
Uffe
WARNING: multiple messages have this Message-ID (diff)
From: ulf.hansson@linaro.org (Ulf Hansson)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM
Date: Mon, 13 Feb 2017 16:09:56 +0100 [thread overview]
Message-ID: <CAPDyKFr6qB7j23E2pVqkBn8OWRZkwE_Diex8ttPiyPWZrruFYw@mail.gmail.com> (raw)
In-Reply-To: <cbccef67-54da-27ce-d0c0-ac57ef251b9b@samsung.com>
[...]
>> The only related PM thing, that shall be the decision of the driver,
>> is whether it wants to enable runtime PM or not, during ->probe().
>
>
> So do you want to create the links during the DMAengine driver probe? How do
> you
> plan to find all the client devices? Please note that you really want to
> create
> links to devices which will really use the DMA engine calls. Some client
> drivers might decide in runtime weather to use DMA engine or not, depending
> on
> other data.
I don't have great plan, just wanted to share my thoughts around the
problems we want to solve.
[...]
>>
>> If we could set up the device link already at device initialization,
>> it should also be possible to avoid getting -EPROBE_DEFER for dma
>> client drivers when requesting their dma channels.
>
>
> At the first glance this sounds like an ultimate solution for all problems,
> but I don't think that device links can be used this way. If I get it right,
> you would like to create links on client device initialization, preferably
> somewhere in the kernel driver core. This will be handled somehow by a
> completely generic code, which will create a link each pair of devices,
> which are connected by a phandle. Is this what you meant? Please note that
> that time no driver for both client and provider are probed. IMHO that
> doesn't look like a right generic approach
>
> How that code will know get following information:
> 1. is it really needed to create a link for given device pair?
> 2. what link flags should it use?
> 3. what about circular dependencies?
> 4. what about runtime optional dependencies?
> 5. what about non-dt platforms? acpi?
>
To give a good answer of these questions, I need to spend more time
investigating.
However, from a top-level point of view, I think the device links
seems like the perfect match for solving the runtime/system PM
problems.
No matter whether we can set up the links at device initialization
time, driver probe or whatever time.
> This looks like another newer ending story of "how can we avoid deferred
> probe
> in a generic way". IMHO we should first solve the problem of irq-safe
> runtime
> PM in DMA engine drivers first. I proposed how it can be done with device
> links.
> With no changes in the client API. Later if one decide to extend the client
> API
> in a way it will allow other runtime PM implementation - I see no problem to
> convert pl330 driver to the new approach, but for the time being - this
> would
> be the easiest way to get it really functional.
Agree, let's drop the deferred probe topic from the discussions - it's
just going to be overwhelming. :-)
[...]
>> So besides solving the irq-safe issue for dma driver, using the
>> device-links has additionally two advantages. I already mentioned the
>> -EPROBE_DEFER issue above.
>
>
> Not really. IMHO device links can be properly established once both drivers
> are probed...
Okay.
>
>>
>> The second thing, is the runtime/system PM relations we get for free
>> by using the links. In other words, the dma driver/core don't need to
>> care about dealing with pm_runtime_get|put() as that would be managed
>> by the dma client driver.
>
>
> IMHO there might be drivers which don't want to use device links based
> runtime
> PM in favor of irq-safe PM or something else. This should be really left to
> drivers.
Okay.
Kind regards
Uffe
next prev parent reply other threads:[~2017-02-13 15:10 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20170209142307eucas1p2592bbad82dbbffc56bbd993f5a890981@eucas1p2.samsung.com>
2017-02-09 14:22 ` [PATCH v8 0/3] DMA Engine: switch PL330 driver to non-irq-safe runtime PM Marek Szyprowski
2017-02-09 14:22 ` Marek Szyprowski
2017-02-09 14:22 ` Marek Szyprowski
[not found] ` <CGME20170209142307eucas1p180323d005f524760913b8d04ac966423@eucas1p1.samsung.com>
2017-02-09 14:22 ` [PATCH v8 1/3] dmaengine: Add new device_{set,release}_slave callbacks Marek Szyprowski
2017-02-09 14:22 ` [PATCH v8 1/3] dmaengine: Add new device_{set, release}_slave callbacks Marek Szyprowski
2017-02-09 14:22 ` Marek Szyprowski
2017-02-10 4:34 ` [PATCH v8 1/3] dmaengine: Add new device_{set,release}_slave callbacks Vinod Koul
2017-02-10 4:34 ` Vinod Koul
2017-02-10 12:07 ` Marek Szyprowski
2017-02-10 12:07 ` Marek Szyprowski
2017-02-13 1:42 ` Vinod Koul
2017-02-13 1:42 ` Vinod Koul
2017-02-13 11:48 ` Marek Szyprowski
2017-02-13 11:48 ` Marek Szyprowski
[not found] ` <CGME20170209142308eucas1p24d52db3d52e19228e8f423c3dc8b085b@eucas1p2.samsung.com>
2017-02-09 14:22 ` [PATCH v8 2/3] dmaengine: pl330: remove pdata based initialization Marek Szyprowski
2017-02-09 14:22 ` Marek Szyprowski
2017-03-22 8:22 ` Marek Szyprowski
2017-03-22 8:22 ` Marek Szyprowski
2017-03-22 8:22 ` Marek Szyprowski
2017-03-27 4:34 ` Vinod Koul
2017-03-27 4:34 ` Vinod Koul
2017-03-27 4:34 ` Vinod Koul
[not found] ` <CGME20170209142309eucas1p2b1277d96139eafc0d1dcc14145600476@eucas1p2.samsung.com>
2017-02-09 14:22 ` [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM Marek Szyprowski
2017-02-09 14:22 ` Marek Szyprowski
2017-02-09 14:22 ` Marek Szyprowski
2017-02-10 4:50 ` Vinod Koul
2017-02-10 4:50 ` Vinod Koul
2017-02-10 11:51 ` Marek Szyprowski
2017-02-10 11:51 ` Marek Szyprowski
2017-02-10 13:57 ` Ulf Hansson
2017-02-10 13:57 ` Ulf Hansson
2017-02-10 13:57 ` Ulf Hansson
2017-02-13 2:03 ` Vinod Koul
2017-02-13 2:03 ` Vinod Koul
2017-02-13 2:03 ` Vinod Koul
2017-02-13 11:11 ` Ulf Hansson
2017-02-13 11:11 ` Ulf Hansson
2017-02-13 11:11 ` Ulf Hansson
2017-02-13 12:15 ` Marek Szyprowski
2017-02-13 12:15 ` Marek Szyprowski
2017-02-13 12:15 ` Marek Szyprowski
2017-02-13 12:32 ` Vinod Koul
2017-02-13 12:32 ` Vinod Koul
2017-02-13 12:32 ` Vinod Koul
2017-02-13 12:27 ` Vinod Koul
2017-02-13 12:27 ` Vinod Koul
2017-02-13 12:27 ` Vinod Koul
2017-02-13 15:32 ` Ulf Hansson
2017-02-13 15:32 ` Ulf Hansson
2017-02-13 15:32 ` Ulf Hansson
2017-02-13 15:47 ` Vinod Koul
2017-02-13 15:47 ` Vinod Koul
2017-02-13 15:47 ` Vinod Koul
2017-02-14 7:50 ` Marek Szyprowski
2017-02-14 7:50 ` Marek Szyprowski
2017-02-14 7:50 ` Marek Szyprowski
2017-02-14 8:24 ` Ulf Hansson
2017-02-14 8:24 ` Ulf Hansson
2017-02-14 8:24 ` Ulf Hansson
2017-02-13 12:01 ` Marek Szyprowski
2017-02-13 12:01 ` Marek Szyprowski
2017-02-13 12:01 ` Marek Szyprowski
2017-02-13 11:45 ` Marek Szyprowski
2017-02-13 11:45 ` Marek Szyprowski
2017-02-13 11:45 ` Marek Szyprowski
2017-02-13 15:09 ` Ulf Hansson [this message]
2017-02-13 15:09 ` Ulf Hansson
2017-02-13 15:09 ` Ulf Hansson
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=CAPDyKFr6qB7j23E2pVqkBn8OWRZkwE_Diex8ttPiyPWZrruFYw@mail.gmail.com \
--to=ulf.hansson@linaro.org \
--cc=arnd@arndb.de \
--cc=b.zolnierkie@samsung.com \
--cc=dmaengine@vger.kernel.org \
--cc=inki.dae@samsung.com \
--cc=krzk@kernel.org \
--cc=lars@metafoo.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=rjw@rjwysocki.net \
--cc=vinod.koul@intel.com \
/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.