From: Kevin Hilman <khilman@deeprootsystems.com>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Eric Miao <eric.miao@canonical.com>,
Nicolas Pitre <nico@fluxnic.net>
Subject: Re: [PATCH v2 1/3] OMAP: PM: initial runtime PM core support
Date: Mon, 28 Jun 2010 16:27:23 -0700 [thread overview]
Message-ID: <87fx06viuc.fsf@deeprootsystems.com> (raw)
In-Reply-To: AANLkTimMnJvOJrRHDiE6PH1BXpRz2-6pY1M9nKHw7vpn@mail.gmail.com
Grant Likely <grant.likely@secretlab.ca> writes:
[...]
>
>> This affects many aspects of all drivers, from register and probe (for
>> early devices/drivers too!) to all the plaform_get_resource() usage, all
>> of which assumes a platform_driver and platform_device. I didn't look
>> closely, but I didn't see if (or how) OF was handling early devices.
>
> You don't have to reimplement the entire platform bus. You could
> simply create a new bus type, but reuse all the existing platform bus
> code. All that changes is the bus type that the device and the driver
> gets registered on. Then you could easily replace only the functions
> that matter. (do a git grep platform_bus_type to see how few
> references there actually are. It looks like there are only 5
> references to it in drivers/base/platform.c that you'd need to work
> around; in platform_device_add(), platform_driver_register(), 2 in
> platform_driver_probe(), and the register in platform_bus_init(). You
> may not even need to reimplement platform_driver_probe().
>
> It might even be as simple as doing this:
> - pdev->dev.bus = &platform_bus_type;
> + if (!pdev->dev.bus)
> + pdev->dev.bus = &platform_bus_type;
>
> So that a different bus type can be selected at device registration
> time
just FYI...
as a quick proof of concept, I've done a quick hack just to prove to
myself that I could use platform_devices on a custom bus, and it indeed
works. The small patch below[1] shows the changes required to the
platform code.
Next step was to hack up minimal custom bus code. The quickest (and
dirtiest) way was to simply memcpy platform_bus_type into my new
omap_bus_type and then override the few dev_pm_ops functions I needed[2].
So, with these in place, and using the dev_pm_ops functions from
$SUBJECT patch, I was able register a platform_device and
platform_driver onto my custom bus and see my custom dev_pm_ops
functions being used as expected.
While admittedly a bit hacky, at least this paves the way in my head
that this is indeed do-able, and I can take my vacation in peace without
this particular problem haunting me (too much.)
Kevin
[1]
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 4d99c8b..2cf55e2 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -241,7 +241,8 @@ int platform_device_add(struct platform_device *pdev)
if (!pdev->dev.parent)
pdev->dev.parent = &platform_bus;
- pdev->dev.bus = &platform_bus_type;
+ if (!pdev->dev.bus)
+ pdev->dev.bus = &platform_bus_type;
if (pdev->id != -1)
dev_set_name(&pdev->dev, "%s.%d", pdev->name, pdev->id);
@@ -482,7 +483,8 @@ static void platform_drv_shutdown(struct device *_dev)
*/
int platform_driver_register(struct platform_driver *drv)
{
- drv->driver.bus = &platform_bus_type;
+ if (!drv->driver.bus)
+ drv->driver.bus = &platform_bus_type;
if (drv->probe)
drv->driver.probe = platform_drv_probe;
if (drv->remove)
@@ -539,12 +541,12 @@ int __init_or_module platform_driver_probe(struct platform_driver *drv,
* if the probe was successful, and make sure any forced probes of
* new devices fail.
*/
- spin_lock(&platform_bus_type.p->klist_drivers.k_lock);
+ spin_lock(&drv->driver.bus->p->klist_drivers.k_lock);
drv->probe = NULL;
if (code == 0 && list_empty(&drv->driver.p->klist_devices.k_list))
retval = -ENODEV;
drv->driver.probe = platform_drv_probe_fail;
- spin_unlock(&platform_bus_type.p->klist_drivers.k_lock);
+ spin_unlock(&drv->driver.bus->p->klist_drivers.k_lock);
if (code != retval)
platform_driver_unregister(drv);
[2]
struct bus_type omap_bus_type;
EXPORT_SYMBOL_GPL(omap_bus_type);
static int __init omap_bus_init(void)
{
int error;
struct bus_type *bus = &omap_bus_type;
pr_debug("%s\n", __func__);
/*
* We're just a copy of platform_bus_type with special dev_pm_ops.
*/
memcpy(bus, &platform_bus_type, sizeof(struct bus_type));
bus->name = "omap";
bus->pm->suspend_noirq = omap_pm_suspend_noirq,
bus->pm->resume_noirq = omap_pm_resume_noirq,
bus->pm->runtime_suspend = omap_pm_runtime_suspend,
bus->pm->runtime_resume = omap_pm_runtime_resume,
bus->pm->runtime_idle = omap_pm_runtime_idle,
error = device_register(&omap_bus);
if (error)
return error;
error = bus_register(&omap_bus_type);
if (error)
device_unregister(&omap_bus);
return error;
}
arch_initcall(omap_bus_init);
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: khilman@deeprootsystems.com (Kevin Hilman)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 1/3] OMAP: PM: initial runtime PM core support
Date: Mon, 28 Jun 2010 16:27:23 -0700 [thread overview]
Message-ID: <87fx06viuc.fsf@deeprootsystems.com> (raw)
In-Reply-To: AANLkTimMnJvOJrRHDiE6PH1BXpRz2-6pY1M9nKHw7vpn@mail.gmail.com
Grant Likely <grant.likely@secretlab.ca> writes:
[...]
>
>> This affects many aspects of all drivers, from register and probe (for
>> early devices/drivers too!) to all the plaform_get_resource() usage, all
>> of which assumes a platform_driver and platform_device. ?I didn't look
>> closely, but I didn't see if (or how) OF was handling early devices.
>
> You don't have to reimplement the entire platform bus. You could
> simply create a new bus type, but reuse all the existing platform bus
> code. All that changes is the bus type that the device and the driver
> gets registered on. Then you could easily replace only the functions
> that matter. (do a git grep platform_bus_type to see how few
> references there actually are. It looks like there are only 5
> references to it in drivers/base/platform.c that you'd need to work
> around; in platform_device_add(), platform_driver_register(), 2 in
> platform_driver_probe(), and the register in platform_bus_init(). You
> may not even need to reimplement platform_driver_probe().
>
> It might even be as simple as doing this:
> - pdev->dev.bus = &platform_bus_type;
> + if (!pdev->dev.bus)
> + pdev->dev.bus = &platform_bus_type;
>
> So that a different bus type can be selected at device registration
> time
just FYI...
as a quick proof of concept, I've done a quick hack just to prove to
myself that I could use platform_devices on a custom bus, and it indeed
works. The small patch below[1] shows the changes required to the
platform code.
Next step was to hack up minimal custom bus code. The quickest (and
dirtiest) way was to simply memcpy platform_bus_type into my new
omap_bus_type and then override the few dev_pm_ops functions I needed[2].
So, with these in place, and using the dev_pm_ops functions from
$SUBJECT patch, I was able register a platform_device and
platform_driver onto my custom bus and see my custom dev_pm_ops
functions being used as expected.
While admittedly a bit hacky, at least this paves the way in my head
that this is indeed do-able, and I can take my vacation in peace without
this particular problem haunting me (too much.)
Kevin
[1]
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 4d99c8b..2cf55e2 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -241,7 +241,8 @@ int platform_device_add(struct platform_device *pdev)
if (!pdev->dev.parent)
pdev->dev.parent = &platform_bus;
- pdev->dev.bus = &platform_bus_type;
+ if (!pdev->dev.bus)
+ pdev->dev.bus = &platform_bus_type;
if (pdev->id != -1)
dev_set_name(&pdev->dev, "%s.%d", pdev->name, pdev->id);
@@ -482,7 +483,8 @@ static void platform_drv_shutdown(struct device *_dev)
*/
int platform_driver_register(struct platform_driver *drv)
{
- drv->driver.bus = &platform_bus_type;
+ if (!drv->driver.bus)
+ drv->driver.bus = &platform_bus_type;
if (drv->probe)
drv->driver.probe = platform_drv_probe;
if (drv->remove)
@@ -539,12 +541,12 @@ int __init_or_module platform_driver_probe(struct platform_driver *drv,
* if the probe was successful, and make sure any forced probes of
* new devices fail.
*/
- spin_lock(&platform_bus_type.p->klist_drivers.k_lock);
+ spin_lock(&drv->driver.bus->p->klist_drivers.k_lock);
drv->probe = NULL;
if (code == 0 && list_empty(&drv->driver.p->klist_devices.k_list))
retval = -ENODEV;
drv->driver.probe = platform_drv_probe_fail;
- spin_unlock(&platform_bus_type.p->klist_drivers.k_lock);
+ spin_unlock(&drv->driver.bus->p->klist_drivers.k_lock);
if (code != retval)
platform_driver_unregister(drv);
[2]
struct bus_type omap_bus_type;
EXPORT_SYMBOL_GPL(omap_bus_type);
static int __init omap_bus_init(void)
{
int error;
struct bus_type *bus = &omap_bus_type;
pr_debug("%s\n", __func__);
/*
* We're just a copy of platform_bus_type with special dev_pm_ops.
*/
memcpy(bus, &platform_bus_type, sizeof(struct bus_type));
bus->name = "omap";
bus->pm->suspend_noirq = omap_pm_suspend_noirq,
bus->pm->resume_noirq = omap_pm_resume_noirq,
bus->pm->runtime_suspend = omap_pm_runtime_suspend,
bus->pm->runtime_resume = omap_pm_runtime_resume,
bus->pm->runtime_idle = omap_pm_runtime_idle,
error = device_register(&omap_bus);
if (error)
return error;
error = bus_register(&omap_bus_type);
if (error)
device_unregister(&omap_bus);
return error;
}
arch_initcall(omap_bus_init);
next prev parent reply other threads:[~2010-06-28 23:27 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-24 23:43 [PATCH v2 0/3] OMAP: add runtime PM support at bus-level Kevin Hilman
2010-06-24 23:43 ` Kevin Hilman
2010-06-24 23:43 ` [PATCH v2 1/3] OMAP: PM: initial runtime PM core support Kevin Hilman
2010-06-24 23:43 ` Kevin Hilman
2010-06-25 15:26 ` Grant Likely
2010-06-25 15:26 ` Grant Likely
2010-06-25 18:04 ` Kevin Hilman
2010-06-25 18:04 ` Kevin Hilman
2010-06-25 20:08 ` Grant Likely
2010-06-25 20:08 ` Grant Likely
2010-06-25 21:58 ` Kevin Hilman
2010-06-25 21:58 ` Kevin Hilman
2010-06-25 22:30 ` Grant Likely
2010-06-25 22:30 ` Grant Likely
2010-06-25 22:46 ` Kevin Hilman
2010-06-25 22:46 ` Kevin Hilman
2010-06-25 23:04 ` Grant Likely
2010-06-25 23:04 ` Grant Likely
2010-06-28 21:49 ` Kevin Hilman
2010-06-28 21:49 ` Kevin Hilman
2010-06-28 22:14 ` Grant Likely
2010-06-28 22:14 ` Grant Likely
2010-06-28 23:27 ` Kevin Hilman [this message]
2010-06-28 23:27 ` Kevin Hilman
2010-06-28 23:47 ` Grant Likely
2010-06-28 23:47 ` Grant Likely
2010-06-25 20:06 ` Russell King - ARM Linux
2010-06-25 20:06 ` Russell King - ARM Linux
2010-06-25 20:13 ` Grant Likely
2010-06-25 20:13 ` Grant Likely
2010-06-25 20:20 ` Russell King - ARM Linux
2010-06-25 20:20 ` Russell King - ARM Linux
2010-06-25 23:46 ` Nicolas Pitre
2010-06-25 23:46 ` Nicolas Pitre
2010-06-26 10:51 ` Uwe Kleine-König
2010-06-26 10:51 ` Uwe Kleine-König
2010-06-26 11:07 ` Russell King - ARM Linux
2010-06-26 11:07 ` Russell King - ARM Linux
2010-08-04 22:55 ` Grant Likely
2010-08-04 22:55 ` Grant Likely
2010-06-24 23:43 ` [PATCH v2 2/3] OMAP: bus-level PM: enable use of runtime PM API for suspend/resume Kevin Hilman
2010-06-24 23:43 ` Kevin Hilman
2010-06-24 23:43 ` [PATCH v2 3/3] OMAP1: PM: add simple runtime PM layer to manage clocks Kevin Hilman
2010-06-24 23:43 ` Kevin Hilman
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=87fx06viuc.fsf@deeprootsystems.com \
--to=khilman@deeprootsystems.com \
--cc=eric.miao@canonical.com \
--cc=grant.likely@secretlab.ca \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=nico@fluxnic.net \
/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.