* [FIX PATCH] acpi/video_detect: Add "Asus UL30VT" to acpi video detect blacklist
From: Lan Tianyu @ 2012-11-29 6:15 UTC (permalink / raw)
To: rjw, lenb; +Cc: Lan Tianyu, linux-pm, linux-acpi
The ACPI video driver can't control backlight correctly on Asus UL30VT.
Vent driver(asus-laptop) can work. This patch is to add "Asus UL30VT"
to acpi video detect blacklist in order to use vent driver for video
control on the "Asus UL30VT" rather than ACPI video driver.
https://bugzilla.kernel.org/show_bug.cgi?id=32592
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
---
drivers/acpi/video_detect.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index b728880..4ac2593 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -156,6 +156,14 @@ static struct dmi_system_id video_detect_dmi_table[] = {
DMI_MATCH(DMI_BOARD_NAME, "X360"),
},
},
+ {
+ .callback = video_detect_force_vendor,
+ .ident = "Asus UL30VT",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK Computer Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "UL30VT"),
+ },
+ },
{ },
};
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH 6/6 v6] cpufreq, highbank: add support for highbank cpufreq
From: Mike Turquette @ 2012-11-29 4:34 UTC (permalink / raw)
To: Shawn Guo
Cc: Mark Langsdorf, linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
cpufreq-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <20121129015133.GD28170-+NayF8gZjK2ctlrPMvKcciBecyulp+rMXqFh9Ls21Oc@public.gmane.org>
Quoting Shawn Guo (2012-11-28 17:51:36)
> > The notifiers in the clk framework might be a better place for this than
> > just simply hacking the logic into the .set_rate callback.
>
> Ah, right. How did I forget about that nice piece?
>
> > I haven't looked at the definition of hb_voltage_change but does the
> > call graph make any clk api calls? Are you talking over i2c to a
> > regulator? If so then you'll probably hit the same reentrancy problem I
> > hit when trying to make a general solution.
>
> So, how is your "reentrancy in the common clk framework" series[1]
> going on? Haven't seen any update since August.
>
I've begun to look at a dvfs api that builds on top of the clock
framework, as opposed to using clk_set_rate as the dvfs api itself.
This eliminates the need for reentrancy, at least for the dvfs case.
I'll post more when I have it. Honestly the reentrancy stuff was just
too ugly. I might try again some day but for now I'm thinking a less
radical approach deserves consideration.
Thanks,
Mike
> Shawn
>
> [1] http://thread.gmane.org/gmane.linux.ports.arm.kernel/182198
^ permalink raw reply
* Re: [PATCH 6/6 v6] cpufreq, highbank: add support for highbank cpufreq
From: Shawn Guo @ 2012-11-29 1:51 UTC (permalink / raw)
To: Mike Turquette
Cc: Mark Langsdorf, linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
cpufreq-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <20121128160115.21126.3841@nucleus>
> The notifiers in the clk framework might be a better place for this than
> just simply hacking the logic into the .set_rate callback.
Ah, right. How did I forget about that nice piece?
> I haven't looked at the definition of hb_voltage_change but does the
> call graph make any clk api calls? Are you talking over i2c to a
> regulator? If so then you'll probably hit the same reentrancy problem I
> hit when trying to make a general solution.
So, how is your "reentrancy in the common clk framework" series[1]
going on? Haven't seen any update since August.
Shawn
[1] http://thread.gmane.org/gmane.linux.ports.arm.kernel/182198
^ permalink raw reply
* Re: [PATCH 6/6 v6] cpufreq, highbank: add support for highbank cpufreq
From: Mark Langsdorf @ 2012-11-29 0:24 UTC (permalink / raw)
To: Mike Turquette
Cc: Shawn Guo, linux-arm-kernel@lists.infradead.org,
devicetree-discuss@lists.ozlabs.org, linux-kernel@vger.kernel.org,
cpufreq@vger.kernel.org, linux-pm@vger.kernel.org
In-Reply-To: <20121128210552.21126.90710@nucleus>
On 11/28/2012 03:05 PM, Mike Turquette wrote:
> Quoting Mark Langsdorf (2012-11-28 08:18:35)
>> On 11/28/2012 10:01 AM, Mike Turquette wrote:
>>> Quoting Shawn Guo (2012-11-28 07:17:44)
>>>> On Wed, Nov 28, 2012 at 10:58:02PM +0800, Shawn Guo wrote:
>>>>> On Wed, Nov 28, 2012 at 07:16:12AM -0600, Mark Langsdorf wrote:
>>>>>> I'd
>>>>>> have to move most of the logic of hb_set_target() into
>>>>>> clk_highbank.c:clk_pll_set_rate() and then add extra logic for when
>>>>>> cpufreq is not enabled/loaded.
>>>>>
>>>>> You only need to move hb_voltage_change() into cpu clock's .set_rate()
>>>>> hook with no need of checking if cpufreq is enabled or not.
>>>>>
>>>> Need to also check whether frequency or voltage should be changed first
>>>> in .set_rate() though.
>>>>
>>>> Shawn
>>>>
>>>
>>> The notifiers in the clk framework might be a better place for this than
>>> just simply hacking the logic into the .set_rate callback.
>>
>> Unless the clk notifiers are different than the cpufreq notifiers, they
>> don't handle returning error conditions very well. And given that the
>> voltage change operation can fail (though it almost always succeeds on a
>> retry) I need to be able to handle and detect that error condition.
>
> The notifier handler can handle the case where the transition fails (and
> needs to be retried).
>
> Also you should check out the clk notifiers. I think they handle
> failure decently. If a notifer returns an error code then everything
> unrolls and the clk_set_rate operation aborts.
Thanks for the pointer. The clk notifier calls seem to be working with
cpufreq-cpu0.
I did enough surgery on the code that I want to run a lot of stress
tests before I resubmit. I'll try to have something for Tuesday.
--Mark Langsdorf
Calxeda, Inc.
^ permalink raw reply
* Re: [PATCH] PCI/PM: Keep runtime PM enabled for unbound PCI devices
From: Rafael J. Wysocki @ 2012-11-28 22:43 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Huang Ying, linux-kernel, linux-pci, linux-pm, Rafael J. Wysocki,
Alan Stern
In-Reply-To: <CAErSpo6CPSMXjq1eSTX41vtwOcd5rQOdC0-9ye5NZhds9U1B8A@mail.gmail.com>
On Wednesday, November 28, 2012 03:25:59 PM Bjorn Helgaas wrote:
> On Tue, Nov 20, 2012 at 1:08 AM, Huang Ying <ying.huang@intel.com> wrote:
> > For unbound PCI devices, what we need is:
> >
> > - Always in D0 state, because some devices does not work again after
> > being put into D3 by the PCI bus.
> >
> > - In SUSPENDED state if allowed, so that the parent devices can still
> > be put into low power state.
> >
> > To satisfy these requirement, the runtime PM for the unbound PCI
> > devices are disabled and set to SUSPENDED state. One issue of this
> > solution is that the PCI devices will be put into SUSPENDED state even
> > if the SUSPENDED state is forbidden via the sysfs interface
> > (.../power/control) of the device. This is not an issue for most
> > devices, because most PCI devices are not used at all if unbounded.
> > But there are exceptions. For example, unbound VGA card can be used
> > for display, but suspend its parents make it stop working.
> >
> > To fix the issue, we keep the runtime PM enabled when the PCI devices
> > are unbound. But the runtime PM callbacks will do nothing if the PCI
> > devices are unbound. This way, we can put the PCI devices into
> > SUSPENDED state without put the PCI devices into D3 state.
>
> Does this fix a reported problem? Is there a bug report URL? What
> problem would a user notice?
There is a BZ: https://bugzilla.kernel.org/show_bug.cgi?id=48201
Unfortunately, the reporter hasn't confirmed that the bug is fixed,
although we're quite confident that it will be.
> This doesn't look critical enough to try to put in v3.7 (correct me if
> I'm wrong). It's getting pretty late for the v3.8 merge window, but
> it looks like it qualifies as a bug fix that we would merge even after
> the merge window, so I'll put it in my -next branch headed for v3.8.
> Then it can be backported to v3.6 and v3.7.
I think that's OK.
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* Re: [PATCH] PCI/PM: Keep runtime PM enabled for unbound PCI devices
From: Bjorn Helgaas @ 2012-11-28 22:25 UTC (permalink / raw)
To: Huang Ying
Cc: linux-kernel, linux-pci, linux-pm, Rafael J. Wysocki,
Rafael J. Wysocki, Alan Stern
In-Reply-To: <1353398902-21253-1-git-send-email-ying.huang@intel.com>
On Tue, Nov 20, 2012 at 1:08 AM, Huang Ying <ying.huang@intel.com> wrote:
> For unbound PCI devices, what we need is:
>
> - Always in D0 state, because some devices does not work again after
> being put into D3 by the PCI bus.
>
> - In SUSPENDED state if allowed, so that the parent devices can still
> be put into low power state.
>
> To satisfy these requirement, the runtime PM for the unbound PCI
> devices are disabled and set to SUSPENDED state. One issue of this
> solution is that the PCI devices will be put into SUSPENDED state even
> if the SUSPENDED state is forbidden via the sysfs interface
> (.../power/control) of the device. This is not an issue for most
> devices, because most PCI devices are not used at all if unbounded.
> But there are exceptions. For example, unbound VGA card can be used
> for display, but suspend its parents make it stop working.
>
> To fix the issue, we keep the runtime PM enabled when the PCI devices
> are unbound. But the runtime PM callbacks will do nothing if the PCI
> devices are unbound. This way, we can put the PCI devices into
> SUSPENDED state without put the PCI devices into D3 state.
Does this fix a reported problem? Is there a bug report URL? What
problem would a user notice?
This doesn't look critical enough to try to put in v3.7 (correct me if
I'm wrong). It's getting pretty late for the v3.8 merge window, but
it looks like it qualifies as a bug fix that we would merge even after
the merge window, so I'll put it in my -next branch headed for v3.8.
Then it can be backported to v3.6 and v3.7.
> Signed-off-by: Huang Ying <ying.huang@intel.com>
> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Cc: Alan Stern <stern@rowland.harvard.edu>
> CC: stable@vger.kernel.org # v3.6+
> ---
> drivers/pci/pci-driver.c | 69 +++++++++++++++++++++++++++--------------------
> drivers/pci/pci.c | 2 +
> 2 files changed, 43 insertions(+), 28 deletions(-)
>
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -1900,6 +1900,8 @@ void pci_pm_init(struct pci_dev *dev)
> u16 pmc;
>
> pm_runtime_forbid(&dev->dev);
> + pm_runtime_set_active(&dev->dev);
> + pm_runtime_enable(&dev->dev);
> device_enable_async_suspend(&dev->dev);
> dev->wakeup_prepared = false;
>
> --- a/drivers/pci/pci-driver.c
> +++ b/drivers/pci/pci-driver.c
> @@ -256,31 +256,26 @@ struct drv_dev_and_id {
> static long local_pci_probe(void *_ddi)
> {
> struct drv_dev_and_id *ddi = _ddi;
> - struct device *dev = &ddi->dev->dev;
> - struct device *parent = dev->parent;
> + struct pci_dev *pci_dev = ddi->dev;
> + struct pci_driver *pci_drv = ddi->drv;
> + struct device *dev = &pci_dev->dev;
> int rc;
>
> - /* The parent bridge must be in active state when probing */
> - if (parent)
> - pm_runtime_get_sync(parent);
> - /* Unbound PCI devices are always set to disabled and suspended.
> - * During probe, the device is set to enabled and active and the
> - * usage count is incremented. If the driver supports runtime PM,
> - * it should call pm_runtime_put_noidle() in its probe routine and
> - * pm_runtime_get_noresume() in its remove routine.
> - */
> - pm_runtime_get_noresume(dev);
> - pm_runtime_set_active(dev);
> - pm_runtime_enable(dev);
> -
> - rc = ddi->drv->probe(ddi->dev, ddi->id);
> + /*
> + * Unbound PCI devices are always put in D0, regardless of
> + * runtime PM status. During probe, the device is set to
> + * active and the usage count is incremented. If the driver
> + * supports runtime PM, it should call pm_runtime_put_noidle()
> + * in its probe routine and pm_runtime_get_noresume() in its
> + * remove routine.
> + */
> + pm_runtime_get_sync(dev);
> + pci_dev->driver = pci_drv;
> + rc = pci_drv->probe(pci_dev, ddi->id);
> if (rc) {
> - pm_runtime_disable(dev);
> - pm_runtime_set_suspended(dev);
> - pm_runtime_put_noidle(dev);
> + pci_dev->driver = NULL;
> + pm_runtime_put_sync(dev);
> }
> - if (parent)
> - pm_runtime_put(parent);
> return rc;
> }
>
> @@ -330,10 +325,8 @@ __pci_device_probe(struct pci_driver *dr
> id = pci_match_device(drv, pci_dev);
> if (id)
> error = pci_call_probe(drv, pci_dev, id);
> - if (error >= 0) {
> - pci_dev->driver = drv;
> + if (error >= 0)
> error = 0;
> - }
> }
> return error;
> }
> @@ -369,9 +362,7 @@ static int pci_device_remove(struct devi
> }
>
> /* Undo the runtime PM settings in local_pci_probe() */
> - pm_runtime_disable(dev);
> - pm_runtime_set_suspended(dev);
> - pm_runtime_put_noidle(dev);
> + pm_runtime_put_sync(dev);
>
> /*
> * If the device is still on, set the power state as "unknown",
> @@ -994,6 +985,13 @@ static int pci_pm_runtime_suspend(struct
> pci_power_t prev = pci_dev->current_state;
> int error;
>
> + /*
> + * If pci_dev->driver is not set (unbound), the device should
> + * always remain in D0 regardless of the runtime PM status
> + */
> + if (!pci_dev->driver)
> + return 0;
> +
> if (!pm || !pm->runtime_suspend)
> return -ENOSYS;
>
> @@ -1029,6 +1027,13 @@ static int pci_pm_runtime_resume(struct
> struct pci_dev *pci_dev = to_pci_dev(dev);
> const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
>
> + /*
> + * If pci_dev->driver is not set (unbound), the device should
> + * always remain in D0 regardless of the runtime PM status
> + */
> + if (!pci_dev->driver)
> + return 0;
> +
> if (!pm || !pm->runtime_resume)
> return -ENOSYS;
>
> @@ -1046,8 +1051,16 @@ static int pci_pm_runtime_resume(struct
>
> static int pci_pm_runtime_idle(struct device *dev)
> {
> + struct pci_dev *pci_dev = to_pci_dev(dev);
> const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
>
> + /*
> + * If pci_dev->driver is not set (unbound), the device should
> + * always remain in D0 regardless of the runtime PM status
> + */
> + if (!pci_dev->driver)
> + goto out;
> +
> if (!pm)
> return -ENOSYS;
>
> @@ -1057,8 +1070,8 @@ static int pci_pm_runtime_idle(struct de
> return ret;
> }
>
> +out:
> pm_runtime_suspend(dev);
> -
> return 0;
> }
>
^ permalink raw reply
* Re: [PATCH 6/6 v6] cpufreq, highbank: add support for highbank cpufreq
From: Mike Turquette @ 2012-11-28 21:05 UTC (permalink / raw)
To: Mark Langsdorf
Cc: Shawn Guo, linux-arm-kernel@lists.infradead.org,
devicetree-discuss@lists.ozlabs.org, linux-kernel@vger.kernel.org,
cpufreq@vger.kernel.org, linux-pm@vger.kernel.org
In-Reply-To: <50B6395B.806@calxeda.com>
Quoting Mark Langsdorf (2012-11-28 08:18:35)
> On 11/28/2012 10:01 AM, Mike Turquette wrote:
> > Quoting Shawn Guo (2012-11-28 07:17:44)
> >> On Wed, Nov 28, 2012 at 10:58:02PM +0800, Shawn Guo wrote:
> >>> On Wed, Nov 28, 2012 at 07:16:12AM -0600, Mark Langsdorf wrote:
> >>>> I'd
> >>>> have to move most of the logic of hb_set_target() into
> >>>> clk_highbank.c:clk_pll_set_rate() and then add extra logic for when
> >>>> cpufreq is not enabled/loaded.
> >>>
> >>> You only need to move hb_voltage_change() into cpu clock's .set_rate()
> >>> hook with no need of checking if cpufreq is enabled or not.
> >>>
> >> Need to also check whether frequency or voltage should be changed first
> >> in .set_rate() though.
> >>
> >> Shawn
> >>
> >
> > The notifiers in the clk framework might be a better place for this than
> > just simply hacking the logic into the .set_rate callback.
>
> Unless the clk notifiers are different than the cpufreq notifiers, they
> don't handle returning error conditions very well. And given that the
> voltage change operation can fail (though it almost always succeeds on a
> retry) I need to be able to handle and detect that error condition.
>
The notifier handler can handle the case where the transition fails (and
needs to be retried).
Also you should check out the clk notifiers. I think they handle
failure decently. If a notifer returns an error code then everything
unrolls and the clk_set_rate operation aborts.
Regards,
Mike
> > I haven't looked at the definition of hb_voltage_change but does the
> > call graph make any clk api calls? Are you talking over i2c to a
> > regulator? If so then you'll probably hit the same reentrancy problem I
> > hit when trying to make a general solution.
>
> I'm talking over a pl320 Interprocessor Communication Mailbox to a
> separate core running it's own RTOS. The RTOS might speak i2c to a
> regulator but it's a black box to me.
>
> hb_voltage_change() doesn't make any clk api calls. It changes the
> voltages, and then hb_set_target() makes clk api calls to change the
> frequency.
>
> --Mark Langsdorf
> Calxeda, Inc.
^ permalink raw reply
* Re: [PATCH 6/6 v6] cpufreq, highbank: add support for highbank cpufreq
From: Mark Langsdorf @ 2012-11-28 16:18 UTC (permalink / raw)
To: Mike Turquette
Cc: Shawn Guo, linux-arm-kernel@lists.infradead.org,
devicetree-discuss@lists.ozlabs.org, linux-kernel@vger.kernel.org,
cpufreq@vger.kernel.org, linux-pm@vger.kernel.org
In-Reply-To: <20121128160115.21126.3841@nucleus>
On 11/28/2012 10:01 AM, Mike Turquette wrote:
> Quoting Shawn Guo (2012-11-28 07:17:44)
>> On Wed, Nov 28, 2012 at 10:58:02PM +0800, Shawn Guo wrote:
>>> On Wed, Nov 28, 2012 at 07:16:12AM -0600, Mark Langsdorf wrote:
>>>> I'd
>>>> have to move most of the logic of hb_set_target() into
>>>> clk_highbank.c:clk_pll_set_rate() and then add extra logic for when
>>>> cpufreq is not enabled/loaded.
>>>
>>> You only need to move hb_voltage_change() into cpu clock's .set_rate()
>>> hook with no need of checking if cpufreq is enabled or not.
>>>
>> Need to also check whether frequency or voltage should be changed first
>> in .set_rate() though.
>>
>> Shawn
>>
>
> The notifiers in the clk framework might be a better place for this than
> just simply hacking the logic into the .set_rate callback.
Unless the clk notifiers are different than the cpufreq notifiers, they
don't handle returning error conditions very well. And given that the
voltage change operation can fail (though it almost always succeeds on a
retry) I need to be able to handle and detect that error condition.
> I haven't looked at the definition of hb_voltage_change but does the
> call graph make any clk api calls? Are you talking over i2c to a
> regulator? If so then you'll probably hit the same reentrancy problem I
> hit when trying to make a general solution.
I'm talking over a pl320 Interprocessor Communication Mailbox to a
separate core running it's own RTOS. The RTOS might speak i2c to a
regulator but it's a black box to me.
hb_voltage_change() doesn't make any clk api calls. It changes the
voltages, and then hb_set_target() makes clk api calls to change the
frequency.
--Mark Langsdorf
Calxeda, Inc.
^ permalink raw reply
* Re: [PATCH 6/6 v6] cpufreq, highbank: add support for highbank cpufreq
From: Mike Turquette @ 2012-11-28 16:01 UTC (permalink / raw)
To: Shawn Guo, Mark Langsdorf
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
cpufreq-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20121128151741.GC28170-+NayF8gZjK2ctlrPMvKcciBecyulp+rMXqFh9Ls21Oc@public.gmane.org>
Quoting Shawn Guo (2012-11-28 07:17:44)
> On Wed, Nov 28, 2012 at 10:58:02PM +0800, Shawn Guo wrote:
> > On Wed, Nov 28, 2012 at 07:16:12AM -0600, Mark Langsdorf wrote:
> > > I'd
> > > have to move most of the logic of hb_set_target() into
> > > clk_highbank.c:clk_pll_set_rate() and then add extra logic for when
> > > cpufreq is not enabled/loaded.
> >
> > You only need to move hb_voltage_change() into cpu clock's .set_rate()
> > hook with no need of checking if cpufreq is enabled or not.
> >
> Need to also check whether frequency or voltage should be changed first
> in .set_rate() though.
>
> Shawn
>
The notifiers in the clk framework might be a better place for this than
just simply hacking the logic into the .set_rate callback.
I haven't looked at the definition of hb_voltage_change but does the
call graph make any clk api calls? Are you talking over i2c to a
regulator? If so then you'll probably hit the same reentrancy problem I
hit when trying to make a general solution.
Regards,
Mike
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 6/6 v6] cpufreq, highbank: add support for highbank cpufreq
From: Mark Langsdorf @ 2012-11-28 15:01 UTC (permalink / raw)
To: Shawn Guo
Cc: linux-kernel@vger.kernel.org, cpufreq@vger.kernel.org,
linux-pm@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
devicetree-discuss@lists.ozlabs.org
In-Reply-To: <20121128151741.GC28170@S2100-06.ap.freescale.net>
On 11/28/2012 09:17 AM, Shawn Guo wrote:
> On Wed, Nov 28, 2012 at 10:58:02PM +0800, Shawn Guo wrote:
>> On Wed, Nov 28, 2012 at 07:16:12AM -0600, Mark Langsdorf wrote:
>>> I'd
>>> have to move most of the logic of hb_set_target() into
>>> clk_highbank.c:clk_pll_set_rate() and then add extra logic for when
>>> cpufreq is not enabled/loaded.
>>
>> You only need to move hb_voltage_change() into cpu clock's .set_rate()
>> hook with no need of checking if cpufreq is enabled or not.
>>
> Need to also check whether frequency or voltage should be changed first
> in .set_rate() though.
Yes, that's entirely what I meant when I said that I would need to move
most of the hb_set_target() logic into .set_rate(). I would also need to
account for retries if the voltage set operation fails, which it
sometimes does.
The ECME handles changing the voltage but doesn't look like a voltage
regulator. Amongst other things, by design it doesn't export meaningful
voltage information to Linux. I tried to get cpufreq-clk0 to work with
the Highbank design and it ended up being much easier and more sane to
create a separate driver.
--Mark Langsdorf
Calxeda, Inc.
^ permalink raw reply
* Re: [PATCH 6/6 v6] cpufreq, highbank: add support for highbank cpufreq
From: Shawn Guo @ 2012-11-28 14:58 UTC (permalink / raw)
To: Mark Langsdorf
Cc: linux-kernel@vger.kernel.org, cpufreq@vger.kernel.org,
linux-pm@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
devicetree-discuss@lists.ozlabs.org
In-Reply-To: <50B60E9C.9000405@calxeda.com>
On Wed, Nov 28, 2012 at 07:16:12AM -0600, Mark Langsdorf wrote:
> Standard practice is to have cpufreq_set_target() handle voltage
> transitions and leave clk_set_rate() handle the frequency changes.
The standard practice is to have cpufreq_set_target() handle both
voltage and frequency transitions, while voltage is handled by regulator
and frequency by clk API.
> I'd
> have to move most of the logic of hb_set_target() into
> clk_highbank.c:clk_pll_set_rate() and then add extra logic for when
> cpufreq is not enabled/loaded.
You only need to move hb_voltage_change() into cpu clock's .set_rate()
hook with no need of checking if cpufreq is enabled or not.
> I don't think the clk maintainers would
> take that patch, either.
This is all handled platform clock specific .set_rate() hook. I doubt
it will concern clk maintainers at all, especially when doing so we
will avoid another cpufreq driver by just using cpufreq-cpu0 driver.
Shawn
^ permalink raw reply
* Re: [PATCH 6/6 v6] cpufreq, highbank: add support for highbank cpufreq
From: Shawn Guo @ 2012-11-28 15:17 UTC (permalink / raw)
To: Mark Langsdorf
Cc: linux-kernel@vger.kernel.org, cpufreq@vger.kernel.org,
linux-pm@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
devicetree-discuss@lists.ozlabs.org
In-Reply-To: <20121128145759.GB28170@S2100-06.ap.freescale.net>
On Wed, Nov 28, 2012 at 10:58:02PM +0800, Shawn Guo wrote:
> On Wed, Nov 28, 2012 at 07:16:12AM -0600, Mark Langsdorf wrote:
> > I'd
> > have to move most of the logic of hb_set_target() into
> > clk_highbank.c:clk_pll_set_rate() and then add extra logic for when
> > cpufreq is not enabled/loaded.
>
> You only need to move hb_voltage_change() into cpu clock's .set_rate()
> hook with no need of checking if cpufreq is enabled or not.
>
Need to also check whether frequency or voltage should be changed first
in .set_rate() though.
Shawn
^ permalink raw reply
* Re: [PATCH v6 2/6] PM / Runtime: introduce pm_runtime_set_memalloc_noio()
From: Ming Lei @ 2012-11-28 13:51 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: linux-pm, linux-kernel, Alan Stern, Oliver Neukum, Minchan Kim,
Greg Kroah-Hartman, Jens Axboe, David S. Miller, Andrew Morton,
netdev, linux-usb, linux-mm
In-Reply-To: <2254856.YsOm9y7BK1@vostro.rjw.lan>
On Wed, Nov 28, 2012 at 6:06 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>
> Well, it may be unfrequent, but does it mean it has to do things that may
> be avoided (ie. walking the children of every node in the path in some cases)?
I agree so without introducing extra cost, :-)
> I don't really think that the counters would cost us that much anyway.
On ARM v7, sizeof(struct device) becomes 376 from 368 after introducing
'unsigned int noio_cnt;' to 'struct dev_pm_info', and total memory
increases about 3752bytes in a small configuration(about 494 device instance).
The actual memory increase should be more than the data because 'struct device'
is generally embedded into other concrete device structure.
>> Also looks the current implementation of pm_runtime_set_memalloc_noio()
>> is simple and clean enough with the flag, IMO.
>
> I know you always know better. :-)
We still need to consider cost and the function calling frequency, :-)
>
>> > I would use the flag only to store the information that
>> > pm_runtime_set_memalloc_noio(dev, true) has been run for this device directly
>> > and I'd use a counter for everything else.
>> >
>> > That is, have power.memalloc_count that would be incremented when (1)
>> > pm_runtime_set_memalloc_noio(dev, true) is called for that device and (2) when
>> > power.memalloc_count for one of its children changes from 0 to 1 (and
>> > analogously for decrementation). Then, check the counter in rpm_callback().
>>
>> Sorry, could you explain in a bit detail why we need the counter? Looks only
>> checking the flag in rpm_callback() is enough, doesn't it?
>
> Why would I want to use power.memalloc_count in addition to the
> power.memalloc_noio flag?
>
> Consider this:
>
> pm_runtime_set_memalloc_noio(dev):
> return if power.memalloc_noio is set
> set power.memalloc_noio
> loop:
> increment power.memalloc_count
> if power.memalloc_count is 1 now switch to parent and go to loop
I am wondering if the above should be changed to below because the child
count of memalloc_noio device need to be recorded.
pm_runtime_set_memalloc_noio(dev):
return if power.memalloc_noio is set
set power.memalloc_noio
loop:
increment power.memalloc_count
switch to parent and go to loop
So pm_runtime_set_memalloc_noio(dev) will become worse than
the improved pm_runtime_set_memalloc_noio(dev, true), which
can return immediately if one dev or parent's flag is true.
> pm_runtime_clear_memalloc_noio(dev):
> return if power.memalloc_noio is unset
> unset power.memalloc_noio
> loop:
> decrement power.memalloc_count
> if power.memalloc_count is 0 now switch to parent and go to loop
The above will perform well than pm_runtime_set_memalloc_noio(dev, false),
because the above avoids to walk children of device.
So one becomes worse and another becomes better, :-)
Also the children count of one device is generally very small, less than
10 for most devices, see the data obtained in one common x86 pc(thinkpad
t410) from below link:
http://kernel.ubuntu.com/~ming/up/t410-dev-child-cnt.log
- about 8 devices whose child count is more than 10, top three are 18, 17 ,12,
and all the three are root devices.
- about 117 devices whose child count is between 1 and 9
- other 501 devices whose child count is zero
>From above data, walking device children should have not much effect on
performance of pm_runtime_set_memalloc_noio(), which is also called in
very infrequent path.
> Looks kind of simpler, doesn't it?
Looks simpler, but more code lines than single
pm_runtime_set_memalloc_noio(), :-)
>
> And why rpm_callback() should check power.memalloc_count instead of the count?
> Because power.memalloc_noio will only be set for devices that
> pm_runtime_set_memalloc_noio(dev) was called for directly (not necessarily for
> the parents).
>
> And that works even if someone calls any of them twice in a row for the same
> device (presumably by mistake) and doesn't have to make any assumptions
> about devices it is called for.
IMO, we can ignore the mistake usage because the function is called only
in network/block core code currently, not by individual driver.
>
>> > Besides, don't you need to check children for the arg device itself?
>>
>> It isn't needed since the children of network/block device can't be
>> involved of the deadlock in runtime PM path.
>>
>> Also, the function is only called by network device or block device
>> subsystem, both the two kind of device are class device and should
>> have no children.
>
> OK, so not walking the arg device's children is an optimization related to
> some assumptions regarding who's supposed to use this routine. That should
> be clearly documented.
I think the patch already documents it in the comment of
pm_runtime_set_memalloc_noio().
Thanks,
--
Ming Lei
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH 6/6 v6] cpufreq, highbank: add support for highbank cpufreq
From: Mark Langsdorf @ 2012-11-28 13:16 UTC (permalink / raw)
To: Shawn Guo
Cc: linux-kernel@vger.kernel.org, cpufreq@vger.kernel.org,
linux-pm@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
devicetree-discuss@lists.ozlabs.org
In-Reply-To: <20121128023240.GA28170@S2100-06.ap.freescale.net>
On 11/27/2012 08:32 PM, Shawn Guo wrote:
> On Tue, Nov 27, 2012 at 02:04:32PM -0600, Mark Langsdorf wrote:
>> Highbank processors depend on the external ECME to perform voltage
>> management based on a requested frequency. Communication between the
>> A9 cores and the ECME happens over the pl320 IPC channel.
>
> ...
>
>> +static int hb_voltage_change(unsigned int freq)
>> +{
>> + int i;
>> + u32 msg[7];
>> +
>> + msg[0] = HB_CPUFREQ_CHANGE_NOTE;
>> + msg[1] = freq / 1000;
>> + for (i = 2; i < 7; i++)
>> + msg[i] = 0;
>> +
>> + return pl320_ipc_transmit(msg);
>
> Is it possible to have this handled inside clk_set_rate() call of cpu
> clock?
Standard practice is to have cpufreq_set_target() handle voltage
transitions and leave clk_set_rate() handle the frequency changes. I'd
have to move most of the logic of hb_set_target() into
clk_highbank.c:clk_pll_set_rate() and then add extra logic for when
cpufreq is not enabled/loaded. I don't think the clk maintainers would
take that patch, either.
So no.
--Mark Langsdorf
Calxeda, Inc.
^ permalink raw reply
* Re: [PATCH 1/5] cpufreq: handle SW coordinated CPUs
From: Rafael J. Wysocki @ 2012-11-28 12:49 UTC (permalink / raw)
To: Fabio Baltieri
Cc: linux-pm, cpufreq, Rickard Andersson, Vincent Guittot,
Linus Walleij, Lee Jones, linux-kernel
In-Reply-To: <20121128105120.GB22300@balto.lan>
On Wednesday, November 28, 2012 11:51:20 AM Fabio Baltieri wrote:
> Hello Rafael,
Hi,
> On Tue, Nov 27, 2012 at 11:05:52PM +0100, Rafael J. Wysocki wrote:
> > > static inline void dbs_timer_init(struct dbs_data *dbs_data,
> > > - struct cpu_dbs_common_info *cdbs, unsigned int sampling_rate)
> > > + struct cpu_dbs_common_info *cdbs,
> > > + unsigned int sampling_rate,
> > > + int cpu)
> > > {
> > > int delay = delay_for_sampling_rate(sampling_rate);
> > > + struct cpu_dbs_common_info *cdbs_local = dbs_data->get_cpu_cdbs(cpu);
> > > + struct od_cpu_dbs_info_s *od_dbs_info;
> > > +
> > > + cancel_delayed_work_sync(&cdbs_local->work);
> > > +
> > > + if (dbs_data->governor == GOV_ONDEMAND) {
> > > + od_dbs_info = dbs_data->get_cpu_dbs_info_s(cpu);
> > > + od_dbs_info->sample_type = OD_NORMAL_SAMPLE;
> > > + }
> >
> > The patch looks good in general except for the special case above.
> >
> > Why exactly is it necessary?
>
> Now that you point it out... it's not! It was part of ondemand init and
> moved in cpufreq_governor_dbs, I forgot to take it out the way.
>
> Also, I think that cancel_delayed_work_sync can be removed too.
>
> Should I send an updated version as soon as I get an ack for the other
> patches in the series or do you want me to wait until 3.8-rc1?
Well, if it's not very urgent, I'd prefer it to wait a bit longer,
get some more testing and so on.
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* Re: [PATCH] PM / devfreq: remove compiler error with module governors (2)
From: Rafael J. Wysocki @ 2012-11-28 12:51 UTC (permalink / raw)
To: myungjoo.ham; +Cc: linux-pm@vger.kernel.org, myungjoo.ham@gmail.com, nm@ti.com
In-Reply-To: <18994982.208311354098418554.JavaMail.weblogic@epml02>
On Wednesday, November 28, 2012 10:26:58 AM MyungJoo Ham wrote:
> > On Wednesday, November 28, 2012 10:57:21 AM MyungJoo Ham wrote:
> > > Governors compiled as modules may use these functions.
> >
> > OK
> >
> > Do you want me to take this directly?
> >
> > Rafael
>
>
> Yes.
>
> You can either take it directly or pull it with
> git://git.kernel.org/pub/scm/linux/kernel/git/mzx/devfreq for-rafael tags/pull_req_20121128
> as well.
OK, I think I'll take it directly. I'll do some extra build testing of the
devfreq branch before I merge it back into the linux-next branch, however.
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* Re: [PATCH 1/5] cpufreq: handle SW coordinated CPUs
From: Fabio Baltieri @ 2012-11-28 10:51 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: linux-pm, cpufreq, Rickard Andersson, Vincent Guittot,
Linus Walleij, Lee Jones, linux-kernel
In-Reply-To: <1723557.AFJjisZlEm@vostro.rjw.lan>
Hello Rafael,
On Tue, Nov 27, 2012 at 11:05:52PM +0100, Rafael J. Wysocki wrote:
> > static inline void dbs_timer_init(struct dbs_data *dbs_data,
> > - struct cpu_dbs_common_info *cdbs, unsigned int sampling_rate)
> > + struct cpu_dbs_common_info *cdbs,
> > + unsigned int sampling_rate,
> > + int cpu)
> > {
> > int delay = delay_for_sampling_rate(sampling_rate);
> > + struct cpu_dbs_common_info *cdbs_local = dbs_data->get_cpu_cdbs(cpu);
> > + struct od_cpu_dbs_info_s *od_dbs_info;
> > +
> > + cancel_delayed_work_sync(&cdbs_local->work);
> > +
> > + if (dbs_data->governor == GOV_ONDEMAND) {
> > + od_dbs_info = dbs_data->get_cpu_dbs_info_s(cpu);
> > + od_dbs_info->sample_type = OD_NORMAL_SAMPLE;
> > + }
>
> The patch looks good in general except for the special case above.
>
> Why exactly is it necessary?
Now that you point it out... it's not! It was part of ondemand init and
moved in cpufreq_governor_dbs, I forgot to take it out the way.
Also, I think that cancel_delayed_work_sync can be removed too.
Should I send an updated version as soon as I get an ack for the other
patches in the series or do you want me to wait until 3.8-rc1?
Thanks,
Fabio
--
Fabio Baltieri
^ permalink raw reply
* [PATCH 4/5] cpufreq: dbx500: Minor code cleanup
From: Ulf Hansson @ 2012-11-28 10:27 UTC (permalink / raw)
To: Rafael J. Wysocki, cpufreq, linux-pm
Cc: linux-arm-kernel, Lee Jones, Linus Walleij, Rickard Andersson,
Jonas Aberg, Vincent Guittot, Philippe Begnic, Ulf Hansson
In-Reply-To: <1354098464-6665-1-git-send-email-ulf.hansson@stericsson.com>
From: Jonas Aaberg <jonas.aberg@stericsson.com>
Some minor code cleanup and some minor changes to printed
error messages.
Signed-off-by: Jonas Aaberg <jonas.aberg@stericsson.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
drivers/cpufreq/dbx500-cpufreq.c | 22 ++++++++++++----------
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/cpufreq/dbx500-cpufreq.c b/drivers/cpufreq/dbx500-cpufreq.c
index d974a8e..d4cb782 100644
--- a/drivers/cpufreq/dbx500-cpufreq.c
+++ b/drivers/cpufreq/dbx500-cpufreq.c
@@ -36,6 +36,7 @@ static int dbx500_cpufreq_target(struct cpufreq_policy *policy,
{
struct cpufreq_freqs freqs;
unsigned int idx;
+ int ret;
/* scale the target frequency to one of the extremes supported */
if (target_freq < policy->cpuinfo.min_freq)
@@ -44,10 +45,9 @@ static int dbx500_cpufreq_target(struct cpufreq_policy *policy,
target_freq = policy->cpuinfo.max_freq;
/* Lookup the next frequency */
- if (cpufreq_frequency_table_target
- (policy, freq_table, target_freq, relation, &idx)) {
+ if (cpufreq_frequency_table_target(policy, freq_table, target_freq,
+ relation, &idx))
return -EINVAL;
- }
freqs.old = policy->cur;
freqs.new = freq_table[idx].frequency;
@@ -60,9 +60,12 @@ static int dbx500_cpufreq_target(struct cpufreq_policy *policy,
cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
/* update armss clk frequency */
- if (clk_set_rate(armss_clk, freq_table[idx].frequency * 1000)) {
- pr_err("dbx500-cpufreq: Failed to update armss clk\n");
- return -EINVAL;
+ ret = clk_set_rate(armss_clk, freqs.new * 1000);
+
+ if (ret) {
+ pr_err("dbx500-cpufreq: Failed to set armss_clk to %d Hz: error %d\n",
+ freqs.new * 1000, ret);
+ return ret;
}
/* post change notification */
@@ -97,7 +100,7 @@ static int __cpuinit dbx500_cpufreq_init(struct cpufreq_policy *policy)
if (!res)
cpufreq_frequency_table_get_attr(freq_table, policy->cpu);
else {
- pr_err("dbx500-cpufreq : Failed to read policy table\n");
+ pr_err("dbx500-cpufreq: Failed to read policy table\n");
return res;
}
@@ -143,11 +146,11 @@ static int dbx500_cpufreq_probe(struct platform_device *pdev)
armss_clk = clk_get(&pdev->dev, "armss");
if (IS_ERR(armss_clk)) {
- pr_err("dbx500-cpufreq : Failed to get armss clk\n");
+ pr_err("dbx500-cpufreq: Failed to get armss clk\n");
return PTR_ERR(armss_clk);
}
- pr_info("dbx500-cpufreq : Available frequencies:\n");
+ pr_info("dbx500-cpufreq: Available frequencies:\n");
while (freq_table[i].frequency != CPUFREQ_TABLE_END) {
pr_info(" %d Mhz\n", freq_table[i].frequency/1000);
i++;
@@ -169,7 +172,6 @@ static int __init dbx500_cpufreq_register(void)
if (!cpu_is_u8500_family())
return -ENODEV;
- pr_info("cpufreq for DBX500 started\n");
return platform_driver_register(&dbx500_cpufreq_plat_driver);
}
device_initcall(dbx500_cpufreq_register);
--
1.7.10
^ permalink raw reply related
* [PATCH 5/5] cpufreq: dbx500: Update file header
From: Ulf Hansson @ 2012-11-28 10:27 UTC (permalink / raw)
To: Rafael J. Wysocki, cpufreq, linux-pm
Cc: linux-arm-kernel, Lee Jones, Linus Walleij, Rickard Andersson,
Jonas Aberg, Vincent Guittot, Philippe Begnic, Ulf Hansson
In-Reply-To: <1354098464-6665-1-git-send-email-ulf.hansson@stericsson.com>
From: Lee Jones <lee.jones@linaro.org>
Real simple patch to extend the ST-Ericsson copyright date and
remove unnecessary extra commented lines.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
drivers/cpufreq/dbx500-cpufreq.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/dbx500-cpufreq.c b/drivers/cpufreq/dbx500-cpufreq.c
index d4cb782..047fc4f 100644
--- a/drivers/cpufreq/dbx500-cpufreq.c
+++ b/drivers/cpufreq/dbx500-cpufreq.c
@@ -1,13 +1,13 @@
/*
* Copyright (C) STMicroelectronics 2009
- * Copyright (C) ST-Ericsson SA 2010
+ * Copyright (C) ST-Ericsson SA 2010-2012
*
* License Terms: GNU General Public License v2
* Author: Sundar Iyer <sundar.iyer@stericsson.com>
* Author: Martin Persson <martin.persson@stericsson.com>
* Author: Jonas Aaberg <jonas.aberg@stericsson.com>
- *
*/
+
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/cpufreq.h>
--
1.7.10
^ permalink raw reply related
* [PATCH 3/5] cpufreq: dbx500: Move clk_get to probe
From: Ulf Hansson @ 2012-11-28 10:27 UTC (permalink / raw)
To: Rafael J. Wysocki, cpufreq, linux-pm
Cc: linux-arm-kernel, Lee Jones, Linus Walleij, Rickard Andersson,
Jonas Aberg, Vincent Guittot, Philippe Begnic, Ulf Hansson
In-Reply-To: <1354098464-6665-1-git-send-email-ulf.hansson@stericsson.com>
From: Ulf Hansson <ulf.hansson@linaro.org>
The armss clock shall only be fetched at probe thus move this here.
Same thing goes for the printing of the available frequencies.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Jonas Aaberg <jonas.aberg@stericsson.com>
---
drivers/cpufreq/dbx500-cpufreq.c | 29 ++++++++++++++---------------
1 file changed, 14 insertions(+), 15 deletions(-)
diff --git a/drivers/cpufreq/dbx500-cpufreq.c b/drivers/cpufreq/dbx500-cpufreq.c
index 0a411b5..d974a8e 100644
--- a/drivers/cpufreq/dbx500-cpufreq.c
+++ b/drivers/cpufreq/dbx500-cpufreq.c
@@ -90,28 +90,14 @@ static unsigned int dbx500_cpufreq_getspeed(unsigned int cpu)
static int __cpuinit dbx500_cpufreq_init(struct cpufreq_policy *policy)
{
- int i = 0;
int res;
- armss_clk = clk_get(NULL, "armss");
- if (IS_ERR(armss_clk)) {
- pr_err("dbx500-cpufreq : Failed to get armss clk\n");
- return PTR_ERR(armss_clk);
- }
-
- pr_info("dbx500-cpufreq : Available frequencies:\n");
- while (freq_table[i].frequency != CPUFREQ_TABLE_END) {
- pr_info(" %d Mhz\n", freq_table[i].frequency/1000);
- i++;
- }
-
/* get policy fields based on the table */
res = cpufreq_frequency_table_cpuinfo(policy, freq_table);
if (!res)
cpufreq_frequency_table_get_attr(freq_table, policy->cpu);
else {
pr_err("dbx500-cpufreq : Failed to read policy table\n");
- clk_put(armss_clk);
return res;
}
@@ -147,13 +133,26 @@ static struct cpufreq_driver dbx500_cpufreq_driver = {
static int dbx500_cpufreq_probe(struct platform_device *pdev)
{
- freq_table = dev_get_platdata(&pdev->dev);
+ int i = 0;
+ freq_table = dev_get_platdata(&pdev->dev);
if (!freq_table) {
pr_err("dbx500-cpufreq: Failed to fetch cpufreq table\n");
return -ENODEV;
}
+ armss_clk = clk_get(&pdev->dev, "armss");
+ if (IS_ERR(armss_clk)) {
+ pr_err("dbx500-cpufreq : Failed to get armss clk\n");
+ return PTR_ERR(armss_clk);
+ }
+
+ pr_info("dbx500-cpufreq : Available frequencies:\n");
+ while (freq_table[i].frequency != CPUFREQ_TABLE_END) {
+ pr_info(" %d Mhz\n", freq_table[i].frequency/1000);
+ i++;
+ }
+
return cpufreq_register_driver(&dbx500_cpufreq_driver);
}
--
1.7.10
^ permalink raw reply related
* [PATCH 2/5] mfd: db8500: Update cpufreq device name
From: Ulf Hansson @ 2012-11-28 10:27 UTC (permalink / raw)
To: Rafael J. Wysocki, cpufreq, linux-pm
Cc: linux-arm-kernel, Lee Jones, Linus Walleij, Rickard Andersson,
Jonas Aberg, Vincent Guittot, Philippe Begnic, Ulf Hansson,
Samuel Ortiz
In-Reply-To: <1354098464-6665-1-git-send-email-ulf.hansson@stericsson.com>
From: Lee Jones <lee.jones@linaro.org>
Since the cpufreq driver for ux500 has been renamed from
cpufreq-db8500 to cpufreq-dbx500, we need to change the
device name here as well.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Samuel Ortiz <sameo@linux.intel.com>
---
drivers/mfd/db8500-prcmu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mfd/db8500-prcmu.c b/drivers/mfd/db8500-prcmu.c
index a1b295f..2900132 100644
--- a/drivers/mfd/db8500-prcmu.c
+++ b/drivers/mfd/db8500-prcmu.c
@@ -3072,8 +3072,8 @@ static struct mfd_cell db8500_prcmu_devs[] = {
.pdata_size = sizeof(db8500_regulators),
},
{
- .name = "cpufreq-u8500",
- .of_compatible = "stericsson,cpufreq-u8500",
+ .name = "cpufreq-ux500",
+ .of_compatible = "stericsson,cpufreq-ux500",
.platform_data = &db8500_cpufreq_table,
.pdata_size = sizeof(db8500_cpufreq_table),
},
--
1.7.10
^ permalink raw reply related
* [PATCH 1/5] cpufreq: Give driver used for dbx500 family a more generic name
From: Ulf Hansson @ 2012-11-28 10:27 UTC (permalink / raw)
To: Rafael J. Wysocki, cpufreq, linux-pm
Cc: linux-arm-kernel, Lee Jones, Linus Walleij, Rickard Andersson,
Jonas Aberg, Vincent Guittot, Philippe Begnic, Ulf Hansson
In-Reply-To: <1354098464-6665-1-git-send-email-ulf.hansson@stericsson.com>
From: Lee Jones <lee.jones@linaro.org>
This driver doesn't only handle cpufreq functionality for the
db8500 anymore. There are new variants which rely on it too.
Let's make the name a bit more generic.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
drivers/cpufreq/Makefile | 2 +-
drivers/cpufreq/db8500-cpufreq.c | 179 --------------------------------------
drivers/cpufreq/dbx500-cpufreq.c | 179 ++++++++++++++++++++++++++++++++++++++
3 files changed, 180 insertions(+), 180 deletions(-)
delete mode 100644 drivers/cpufreq/db8500-cpufreq.c
create mode 100644 drivers/cpufreq/dbx500-cpufreq.c
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 5b1413e..b842ba5 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -41,7 +41,7 @@ obj-$(CONFIG_X86_CPUFREQ_NFORCE2) += cpufreq-nforce2.o
##################################################################################
# ARM SoC drivers
-obj-$(CONFIG_UX500_SOC_DB8500) += db8500-cpufreq.o
+obj-$(CONFIG_UX500_SOC_DB8500) += dbx500-cpufreq.o
obj-$(CONFIG_ARM_S3C2416_CPUFREQ) += s3c2416-cpufreq.o
obj-$(CONFIG_ARM_S3C64XX_CPUFREQ) += s3c64xx-cpufreq.o
obj-$(CONFIG_ARM_S5PV210_CPUFREQ) += s5pv210-cpufreq.o
diff --git a/drivers/cpufreq/db8500-cpufreq.c b/drivers/cpufreq/db8500-cpufreq.c
deleted file mode 100644
index 4f154bc..0000000
--- a/drivers/cpufreq/db8500-cpufreq.c
+++ /dev/null
@@ -1,179 +0,0 @@
-/*
- * Copyright (C) STMicroelectronics 2009
- * Copyright (C) ST-Ericsson SA 2010
- *
- * License Terms: GNU General Public License v2
- * Author: Sundar Iyer <sundar.iyer@stericsson.com>
- * Author: Martin Persson <martin.persson@stericsson.com>
- * Author: Jonas Aaberg <jonas.aberg@stericsson.com>
- *
- */
-#include <linux/module.h>
-#include <linux/kernel.h>
-#include <linux/cpufreq.h>
-#include <linux/delay.h>
-#include <linux/slab.h>
-#include <linux/platform_device.h>
-#include <linux/clk.h>
-#include <mach/id.h>
-
-static struct cpufreq_frequency_table *freq_table;
-static struct clk *armss_clk;
-
-static struct freq_attr *db8500_cpufreq_attr[] = {
- &cpufreq_freq_attr_scaling_available_freqs,
- NULL,
-};
-
-static int db8500_cpufreq_verify_speed(struct cpufreq_policy *policy)
-{
- return cpufreq_frequency_table_verify(policy, freq_table);
-}
-
-static int db8500_cpufreq_target(struct cpufreq_policy *policy,
- unsigned int target_freq,
- unsigned int relation)
-{
- struct cpufreq_freqs freqs;
- unsigned int idx;
-
- /* scale the target frequency to one of the extremes supported */
- if (target_freq < policy->cpuinfo.min_freq)
- target_freq = policy->cpuinfo.min_freq;
- if (target_freq > policy->cpuinfo.max_freq)
- target_freq = policy->cpuinfo.max_freq;
-
- /* Lookup the next frequency */
- if (cpufreq_frequency_table_target
- (policy, freq_table, target_freq, relation, &idx)) {
- return -EINVAL;
- }
-
- freqs.old = policy->cur;
- freqs.new = freq_table[idx].frequency;
-
- if (freqs.old == freqs.new)
- return 0;
-
- /* pre-change notification */
- for_each_cpu(freqs.cpu, policy->cpus)
- cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
-
- /* update armss clk frequency */
- if (clk_set_rate(armss_clk, freq_table[idx].frequency * 1000)) {
- pr_err("db8500-cpufreq: Failed to update armss clk\n");
- return -EINVAL;
- }
-
- /* post change notification */
- for_each_cpu(freqs.cpu, policy->cpus)
- cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
-
- return 0;
-}
-
-static unsigned int db8500_cpufreq_getspeed(unsigned int cpu)
-{
- int i = 0;
- unsigned long freq = clk_get_rate(armss_clk) / 1000;
-
- while (freq_table[i].frequency != CPUFREQ_TABLE_END) {
- if (freq <= freq_table[i].frequency)
- return freq_table[i].frequency;
- i++;
- }
-
- /* We could not find a corresponding frequency. */
- pr_err("db8500-cpufreq: Failed to find cpufreq speed\n");
- return 0;
-}
-
-static int __cpuinit db8500_cpufreq_init(struct cpufreq_policy *policy)
-{
- int i = 0;
- int res;
-
- armss_clk = clk_get(NULL, "armss");
- if (IS_ERR(armss_clk)) {
- pr_err("db8500-cpufreq : Failed to get armss clk\n");
- return PTR_ERR(armss_clk);
- }
-
- pr_info("db8500-cpufreq : Available frequencies:\n");
- while (freq_table[i].frequency != CPUFREQ_TABLE_END) {
- pr_info(" %d Mhz\n", freq_table[i].frequency/1000);
- i++;
- }
-
- /* get policy fields based on the table */
- res = cpufreq_frequency_table_cpuinfo(policy, freq_table);
- if (!res)
- cpufreq_frequency_table_get_attr(freq_table, policy->cpu);
- else {
- pr_err("db8500-cpufreq : Failed to read policy table\n");
- clk_put(armss_clk);
- return res;
- }
-
- policy->min = policy->cpuinfo.min_freq;
- policy->max = policy->cpuinfo.max_freq;
- policy->cur = db8500_cpufreq_getspeed(policy->cpu);
- policy->governor = CPUFREQ_DEFAULT_GOVERNOR;
-
- /*
- * FIXME : Need to take time measurement across the target()
- * function with no/some/all drivers in the notification
- * list.
- */
- policy->cpuinfo.transition_latency = 20 * 1000; /* in ns */
-
- /* policy sharing between dual CPUs */
- cpumask_copy(policy->cpus, cpu_present_mask);
-
- policy->shared_type = CPUFREQ_SHARED_TYPE_ALL;
-
- return 0;
-}
-
-static struct cpufreq_driver db8500_cpufreq_driver = {
- .flags = CPUFREQ_STICKY,
- .verify = db8500_cpufreq_verify_speed,
- .target = db8500_cpufreq_target,
- .get = db8500_cpufreq_getspeed,
- .init = db8500_cpufreq_init,
- .name = "DB8500",
- .attr = db8500_cpufreq_attr,
-};
-
-static int db8500_cpufreq_probe(struct platform_device *pdev)
-{
- freq_table = dev_get_platdata(&pdev->dev);
-
- if (!freq_table) {
- pr_err("db8500-cpufreq: Failed to fetch cpufreq table\n");
- return -ENODEV;
- }
-
- return cpufreq_register_driver(&db8500_cpufreq_driver);
-}
-
-static struct platform_driver db8500_cpufreq_plat_driver = {
- .driver = {
- .name = "cpufreq-u8500",
- .owner = THIS_MODULE,
- },
- .probe = db8500_cpufreq_probe,
-};
-
-static int __init db8500_cpufreq_register(void)
-{
- if (!cpu_is_u8500_family())
- return -ENODEV;
-
- pr_info("cpufreq for DB8500 started\n");
- return platform_driver_register(&db8500_cpufreq_plat_driver);
-}
-device_initcall(db8500_cpufreq_register);
-
-MODULE_LICENSE("GPL v2");
-MODULE_DESCRIPTION("cpufreq driver for DB8500");
diff --git a/drivers/cpufreq/dbx500-cpufreq.c b/drivers/cpufreq/dbx500-cpufreq.c
new file mode 100644
index 0000000..0a411b5
--- /dev/null
+++ b/drivers/cpufreq/dbx500-cpufreq.c
@@ -0,0 +1,179 @@
+/*
+ * Copyright (C) STMicroelectronics 2009
+ * Copyright (C) ST-Ericsson SA 2010
+ *
+ * License Terms: GNU General Public License v2
+ * Author: Sundar Iyer <sundar.iyer@stericsson.com>
+ * Author: Martin Persson <martin.persson@stericsson.com>
+ * Author: Jonas Aaberg <jonas.aberg@stericsson.com>
+ *
+ */
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/cpufreq.h>
+#include <linux/delay.h>
+#include <linux/slab.h>
+#include <linux/platform_device.h>
+#include <linux/clk.h>
+#include <mach/id.h>
+
+static struct cpufreq_frequency_table *freq_table;
+static struct clk *armss_clk;
+
+static struct freq_attr *dbx500_cpufreq_attr[] = {
+ &cpufreq_freq_attr_scaling_available_freqs,
+ NULL,
+};
+
+static int dbx500_cpufreq_verify_speed(struct cpufreq_policy *policy)
+{
+ return cpufreq_frequency_table_verify(policy, freq_table);
+}
+
+static int dbx500_cpufreq_target(struct cpufreq_policy *policy,
+ unsigned int target_freq,
+ unsigned int relation)
+{
+ struct cpufreq_freqs freqs;
+ unsigned int idx;
+
+ /* scale the target frequency to one of the extremes supported */
+ if (target_freq < policy->cpuinfo.min_freq)
+ target_freq = policy->cpuinfo.min_freq;
+ if (target_freq > policy->cpuinfo.max_freq)
+ target_freq = policy->cpuinfo.max_freq;
+
+ /* Lookup the next frequency */
+ if (cpufreq_frequency_table_target
+ (policy, freq_table, target_freq, relation, &idx)) {
+ return -EINVAL;
+ }
+
+ freqs.old = policy->cur;
+ freqs.new = freq_table[idx].frequency;
+
+ if (freqs.old == freqs.new)
+ return 0;
+
+ /* pre-change notification */
+ for_each_cpu(freqs.cpu, policy->cpus)
+ cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
+
+ /* update armss clk frequency */
+ if (clk_set_rate(armss_clk, freq_table[idx].frequency * 1000)) {
+ pr_err("dbx500-cpufreq: Failed to update armss clk\n");
+ return -EINVAL;
+ }
+
+ /* post change notification */
+ for_each_cpu(freqs.cpu, policy->cpus)
+ cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
+
+ return 0;
+}
+
+static unsigned int dbx500_cpufreq_getspeed(unsigned int cpu)
+{
+ int i = 0;
+ unsigned long freq = clk_get_rate(armss_clk) / 1000;
+
+ while (freq_table[i].frequency != CPUFREQ_TABLE_END) {
+ if (freq <= freq_table[i].frequency)
+ return freq_table[i].frequency;
+ i++;
+ }
+
+ /* We could not find a corresponding frequency. */
+ pr_err("dbx500-cpufreq: Failed to find cpufreq speed\n");
+ return 0;
+}
+
+static int __cpuinit dbx500_cpufreq_init(struct cpufreq_policy *policy)
+{
+ int i = 0;
+ int res;
+
+ armss_clk = clk_get(NULL, "armss");
+ if (IS_ERR(armss_clk)) {
+ pr_err("dbx500-cpufreq : Failed to get armss clk\n");
+ return PTR_ERR(armss_clk);
+ }
+
+ pr_info("dbx500-cpufreq : Available frequencies:\n");
+ while (freq_table[i].frequency != CPUFREQ_TABLE_END) {
+ pr_info(" %d Mhz\n", freq_table[i].frequency/1000);
+ i++;
+ }
+
+ /* get policy fields based on the table */
+ res = cpufreq_frequency_table_cpuinfo(policy, freq_table);
+ if (!res)
+ cpufreq_frequency_table_get_attr(freq_table, policy->cpu);
+ else {
+ pr_err("dbx500-cpufreq : Failed to read policy table\n");
+ clk_put(armss_clk);
+ return res;
+ }
+
+ policy->min = policy->cpuinfo.min_freq;
+ policy->max = policy->cpuinfo.max_freq;
+ policy->cur = dbx500_cpufreq_getspeed(policy->cpu);
+ policy->governor = CPUFREQ_DEFAULT_GOVERNOR;
+
+ /*
+ * FIXME : Need to take time measurement across the target()
+ * function with no/some/all drivers in the notification
+ * list.
+ */
+ policy->cpuinfo.transition_latency = 20 * 1000; /* in ns */
+
+ /* policy sharing between dual CPUs */
+ cpumask_copy(policy->cpus, cpu_present_mask);
+
+ policy->shared_type = CPUFREQ_SHARED_TYPE_ALL;
+
+ return 0;
+}
+
+static struct cpufreq_driver dbx500_cpufreq_driver = {
+ .flags = CPUFREQ_STICKY,
+ .verify = dbx500_cpufreq_verify_speed,
+ .target = dbx500_cpufreq_target,
+ .get = dbx500_cpufreq_getspeed,
+ .init = dbx500_cpufreq_init,
+ .name = "DBX500",
+ .attr = dbx500_cpufreq_attr,
+};
+
+static int dbx500_cpufreq_probe(struct platform_device *pdev)
+{
+ freq_table = dev_get_platdata(&pdev->dev);
+
+ if (!freq_table) {
+ pr_err("dbx500-cpufreq: Failed to fetch cpufreq table\n");
+ return -ENODEV;
+ }
+
+ return cpufreq_register_driver(&dbx500_cpufreq_driver);
+}
+
+static struct platform_driver dbx500_cpufreq_plat_driver = {
+ .driver = {
+ .name = "cpufreq-ux500",
+ .owner = THIS_MODULE,
+ },
+ .probe = dbx500_cpufreq_probe,
+};
+
+static int __init dbx500_cpufreq_register(void)
+{
+ if (!cpu_is_u8500_family())
+ return -ENODEV;
+
+ pr_info("cpufreq for DBX500 started\n");
+ return platform_driver_register(&dbx500_cpufreq_plat_driver);
+}
+device_initcall(dbx500_cpufreq_register);
+
+MODULE_LICENSE("GPL v2");
+MODULE_DESCRIPTION("cpufreq driver for DBX500");
--
1.7.10
^ permalink raw reply related
* [PATCH 0/5] cpufreq: db8500: Rename driver and update some parts
From: Ulf Hansson @ 2012-11-28 10:27 UTC (permalink / raw)
To: Rafael J. Wysocki, cpufreq, linux-pm
Cc: linux-arm-kernel, Lee Jones, Linus Walleij, Rickard Andersson,
Jonas Aberg, Vincent Guittot, Philippe Begnic, Ulf Hansson
From: Ulf Hansson <ulf.hansson@linaro.org>
This patchset starts by renaming the db8500 cpufreq driver to a more generic
name. There are new variants which rely on it too, so instead we give it a
family name of dbx500.
On top of that a fixup patch for initialization of the driver and some minor
cleanup patches are included as well.
These patches can be material for 3.8, thus I think it should be fine if the
patches are merged through different trees. Unless some of the maintainers
are of other opinions.
Jonas Aaberg (1):
cpufreq: dbx500: Minor code cleanup
Lee Jones (3):
cpufreq: Give driver used for dbx500 family a more generic name
mfd: db8500: Update cpufreq device name
cpufreq: dbx500: Update file header
Ulf Hansson (1):
cpufreq: dbx500: Move clk_get to probe
drivers/cpufreq/Makefile | 2 +-
drivers/cpufreq/db8500-cpufreq.c | 179 -------------------------------------
drivers/cpufreq/dbx500-cpufreq.c | 180 ++++++++++++++++++++++++++++++++++++++
drivers/mfd/db8500-prcmu.c | 4 +-
4 files changed, 183 insertions(+), 182 deletions(-)
delete mode 100644 drivers/cpufreq/db8500-cpufreq.c
create mode 100644 drivers/cpufreq/dbx500-cpufreq.c
--
1.7.10
^ permalink raw reply
* Re: Re: [PATCH] PM / devfreq: remove compiler error with module governors (2)
From: MyungJoo Ham @ 2012-11-28 10:26 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: linux-pm@vger.kernel.org, myungjoo.ham@gmail.com, nm@ti.com
> On Wednesday, November 28, 2012 10:57:21 AM MyungJoo Ham wrote:
> > Governors compiled as modules may use these functions.
>
> OK
>
> Do you want me to take this directly?
>
> Rafael
Yes.
You can either take it directly or pull it with
git://git.kernel.org/pub/scm/linux/kernel/git/mzx/devfreq for-rafael tags/pull_req_20121128
as well.
Thanks.
Cheers,
MyungJoo
>
>
> > Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
> > ---
> > This patch is also locataed at
> > git.kernel.org/pub/scm/linux/kernel/git/mzx/devfreq for-rafael tags/pull_req_20121128
> >
> > drivers/devfreq/devfreq.c | 5 +++++
> > 1 files changed, 5 insertions(+), 0 deletions(-)
> >
^ permalink raw reply
* Re: [PATCH] PM / devfreq: remove compiler error with module governors (2)
From: Rafael J. Wysocki @ 2012-11-28 10:22 UTC (permalink / raw)
To: MyungJoo Ham; +Cc: linux-pm, myungjoo.ham, nm
In-Reply-To: <1354067841-4936-1-git-send-email-myungjoo.ham@samsung.com>
On Wednesday, November 28, 2012 10:57:21 AM MyungJoo Ham wrote:
> Governors compiled as modules may use these functions.
OK
Do you want me to take this directly?
Rafael
> Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
> ---
> This patch is also locataed at
> git.kernel.org/pub/scm/linux/kernel/git/mzx/devfreq for-rafael tags/pull_req_20121128
>
> drivers/devfreq/devfreq.c | 5 +++++
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> index 34c00c5..a8f0173 100644
> --- a/drivers/devfreq/devfreq.c
> +++ b/drivers/devfreq/devfreq.c
> @@ -235,6 +235,7 @@ void devfreq_monitor_start(struct devfreq *devfreq)
> queue_delayed_work(devfreq_wq, &devfreq->work,
> msecs_to_jiffies(devfreq->profile->polling_ms));
> }
> +EXPORT_SYMBOL(devfreq_monitor_start);
>
> /**
> * devfreq_monitor_stop() - Stop load monitoring of a devfreq instance
> @@ -248,6 +249,7 @@ void devfreq_monitor_stop(struct devfreq *devfreq)
> {
> cancel_delayed_work_sync(&devfreq->work);
> }
> +EXPORT_SYMBOL(devfreq_monitor_stop);
>
> /**
> * devfreq_monitor_suspend() - Suspend load monitoring of a devfreq instance
> @@ -273,6 +275,7 @@ void devfreq_monitor_suspend(struct devfreq *devfreq)
> mutex_unlock(&devfreq->lock);
> cancel_delayed_work_sync(&devfreq->work);
> }
> +EXPORT_SYMBOL(devfreq_monitor_suspend);
>
> /**
> * devfreq_monitor_resume() - Resume load monitoring of a devfreq instance
> @@ -297,6 +300,7 @@ void devfreq_monitor_resume(struct devfreq *devfreq)
> out:
> mutex_unlock(&devfreq->lock);
> }
> +EXPORT_SYMBOL(devfreq_monitor_resume);
>
> /**
> * devfreq_interval_update() - Update device devfreq monitoring interval
> @@ -343,6 +347,7 @@ void devfreq_interval_update(struct devfreq *devfreq, unsigned int *delay)
> out:
> mutex_unlock(&devfreq->lock);
> }
> +EXPORT_SYMBOL(devfreq_interval_update);
>
> /**
> * devfreq_notifier_call() - Notify that the device frequency requirements
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox