First cut of a TCP/IP triggered NI battery simulator power measurement
Video here: https://plus.google.com/u/0/104422661029399872488/posts/gKZxeTmEkMe This is cool because it lets us easily integrate the system into LAVA. -- Zach Pfeffer Android Platform Team Lead, Linaro Platform Teams Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] linaro/configs: ubuntu: Disable support for generic OHCI platform driver
On Fri, Sep 14, 2012 at 12:41 AM, Tushar Behera wrote: > OHCI-HCD driver does not support multiple SoC drivers during the compile > time. Hence the generic driver should be disabled in ubuntu.conf and related > OHCI Soc drivers should be enabled in respective board config files. > > Signed-off-by: Tushar Behera > --- > linaro/configs/ubuntu.conf |1 - > 1 files changed, 0 insertions(+), 1 deletions(-) > > diff --git a/linaro/configs/ubuntu.conf b/linaro/configs/ubuntu.conf > index 5d0a372..88e58df 100644 > --- a/linaro/configs/ubuntu.conf > +++ b/linaro/configs/ubuntu.conf > @@ -1556,7 +1556,6 @@ CONFIG_USB_OXU210HP_HCD=m > CONFIG_USB_ISP116X_HCD=m > CONFIG_USB_ISP1760_HCD=m > CONFIG_USB_OHCI_HCD=y > -CONFIG_USB_OHCI_HCD_PLATFORM=y > CONFIG_USB_OHCI_LITTLE_ENDIAN=y > CONFIG_USB_U132_HCD=m > CONFIG_USB_SL811_HCD=m > -- > 1.7.4.1 Pushed to config-core-tracking. Thanks! -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 1/2] UBUNTU: dm-raid4-5: rename split_io to max_io_len
Commit 542f90381422 ("dm: support non power of two target max_io_len")
renames struct dm_target:split_io variable to max_io_len.
Signed-off-by: Tushar Behera
---
ubuntu/dm-raid4-5/dm-raid4-5.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/ubuntu/dm-raid4-5/dm-raid4-5.c b/ubuntu/dm-raid4-5/dm-raid4-5.c
index e05b0e1..e69ab44 100644
--- a/ubuntu/dm-raid4-5/dm-raid4-5.c
+++ b/ubuntu/dm-raid4-5/dm-raid4-5.c
@@ -4073,7 +4073,7 @@ static int raid_ctr(struct dm_target *ti, unsigned argc,
char **argv)
* Make sure that dm core only hands maximum io size
* length down and pays attention to io boundaries.
*/
- ti->split_io = rs->set.io_size;
+ ti->max_io_len = rs->set.io_size;
ti->private = rs;
/* Initialize work queue to handle this RAID set's io. */
--
1.7.4.1
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 2/2] UBUNTU: dm-raid4-5: Fix compilation warning
Fixes following compilation warning.
ubuntu/dm-raid4-5/dm-raid4-5.c:4505:2: warning: initialization from
incompatible pointer type [enabled by default]
ubuntu/dm-raid4-5/dm-raid4-5.c:4505:2: warning: (near initialization for
‘raid_target.status’) [enabled by default]
Signed-off-by: Tushar Behera
---
ubuntu/dm-raid4-5/dm-raid4-5.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/ubuntu/dm-raid4-5/dm-raid4-5.c b/ubuntu/dm-raid4-5/dm-raid4-5.c
index e69ab44..9f55f58 100644
--- a/ubuntu/dm-raid4-5/dm-raid4-5.c
+++ b/ubuntu/dm-raid4-5/dm-raid4-5.c
@@ -4246,7 +4246,7 @@ static void raid_devel_stats(struct dm_target *ti, char
*result,
}
static int raid_status(struct dm_target *ti, status_type_t type,
- char *result, unsigned maxlen)
+ unsigned status_flags, char *result, unsigned maxlen)
{
unsigned p, sz = 0;
char buf[BDEVNAME_SIZE];
--
1.7.4.1
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH] linaro/configs: ubuntu: Disable support for generic OHCI platform driver
OHCI-HCD driver does not support multiple SoC drivers during the compile time. Hence the generic driver should be disabled in ubuntu.conf and related OHCI Soc drivers should be enabled in respective board config files. Signed-off-by: Tushar Behera --- linaro/configs/ubuntu.conf |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/linaro/configs/ubuntu.conf b/linaro/configs/ubuntu.conf index 5d0a372..88e58df 100644 --- a/linaro/configs/ubuntu.conf +++ b/linaro/configs/ubuntu.conf @@ -1556,7 +1556,6 @@ CONFIG_USB_OXU210HP_HCD=m CONFIG_USB_ISP116X_HCD=m CONFIG_USB_ISP1760_HCD=m CONFIG_USB_OHCI_HCD=y -CONFIG_USB_OHCI_HCD_PLATFORM=y CONFIG_USB_OHCI_LITTLE_ENDIAN=y CONFIG_USB_U132_HCD=m CONFIG_USB_SL811_HCD=m -- 1.7.4.1 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Implement devicetree support for AB8500 Btemp
(Thanks for Cc'ing me.)
On Thu, Sep 13, 2012 at 02:37:38PM +, Arnd Bergmann wrote:
[...]
> > > If this is true, I don't understand what makes the 'supplied-to'
> > > properties you list in the device tree binding board specific. Are
> > > they not always done the same way? If so, you could just leave them
> > > out.
> > Precisely 'supplied-to' is not board specific, it was maintained as
> > platform_data which i migrated to dt-node. It is meant to establish
> > dependency across bm drivers based on power_supply property and
> > runtime battery attributes.
> > Basically, 'supplied-to' provides a way of exporting change in
> > power_supply_property and runtime batter characteristics so that other
> > bm devs shall make use or refer the updated values.
> > Ref: external_power_changed(...) call back api.
> > Note: all the bm drivers handles subset of power_supply property and
> > battery attributes,
> > ref: include/linux/power_supply.h and get_property(...) call back
> > api across bm drivers.
>
> Ok, so you want to just remove the property from the device tree,
> or do you want to establish a different method to specify these
> connections?
Power supply subsystem's supplied_to describes not just how driver
should notify other devices, supplied_to is more generic stuff, in terms
that it describes power supply hierarchy. It's like a directed graph,
e.g.:
supplied_to and
supplied_to and
supplied_to
supplied_to
supplied_to
supplied_to
How things interact in linux are just implementations details.
So, device tree is surely a perfect place to describe these things.
Although, in current bindings I see this:
+ ab8500-fg {
+ /* Other enery management module */
+ supplied_to = "ab8500_chargalg", "ab8500_usb";
+ num_supplicants = <2>;
+ };
Instead of addressing supplicants by name, it's better to address
via phandles. And, of course, num_supplicants is not needed, it can
be derived.
[...]
> > > possible batteries and require a property such as
> > >
> > > st-ericsson,battery-type: A string identifier for the type of battery,
> > > which impacts how an operating system interpret
> > > the sensor readings. Possible values include:
> > > * "none"-- no battery connected
> > > * "li-ion-9100" -- Type 9100 Li-ION battery
> > > *
> > Can do this, not precisely as "st-ericsson,battery-type", it will be as
> > battery-type = [unknown|NiMH|LION|...|]], reason being
> > allowable battery type is based on technology, as you can see the
> > possible types as:
> > POWER_SUPPLY_TECHNOLOGY_UNKNOWN = 0,
> > POWER_SUPPLY_TECHNOLOGY_NiMH,
> > POWER_SUPPLY_TECHNOLOGY_LION,
> > POWER_SUPPLY_TECHNOLOGY_LIPO,
> > POWER_SUPPLY_TECHNOLOGY_LiFe,
> > POWER_SUPPLY_TECHNOLOGY_NiCd,
> > POWER_SUPPLY_TECHNOLOGY_LiMn
> > Ref: include/linux/power_supply.h
> > Note: doing this will impact my of_probe(...), may slightly bloat the
> > code.
>
> Ok.
>
> If you want to make the battery type a generic property, it's probably
> best to start a separate binding document for this in
> Documentation/devicetree/bindings/power-supply/common.txt
> and document a string for each of these.
Fully agree. We need to document generic DT bindings for power supplies.
Thanks,
Anton.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC] sched: nohz_idle_balance
On 9/13/12, Peter Zijlstra wrote: > On Thu, 2012-09-13 at 08:49 +0200, Mike Galbraith wrote: >> On Thu, 2012-09-13 at 06:11 +0200, Vincent Guittot wrote: > > Well, updating the load statistics on the cpu you're going to balance > seems like a good end to me.. ;-) No point updating the local statistics > N times and leaving the ones you're going to balance stale for god knows > how long. Don't you think this patch has a very poor subject line? Thanks, Rakib ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC] power: opp: rcu reclaim
+Nishanth Menon
Quoting Vincent Guittot (2012-09-12 21:13:33)
> synchronize_rcu blocks the caller of opp_enable/disbale
> for a complete grace period. This blocking duration prevents
> any intensive use of the functions. Replace synchronize_rcu
> by call_rcu which will call our function for freeing the old
> opp element.
>
> The duration of opp_enable and opp_disable will be no more
> dependant of the grace period.
>
> Signed-off-by: Vincent Guittot
> ---
> drivers/base/power/opp.c | 19 ++-
> 1 file changed, 14 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
> index ac993ea..49e4626 100644
> --- a/drivers/base/power/opp.c
> +++ b/drivers/base/power/opp.c
> @@ -64,6 +64,7 @@ struct opp {
> unsigned long u_volt;
>
> struct device_opp *dev_opp;
> + struct rcu_head head;
> };
>
> /**
> @@ -441,6 +442,17 @@ int opp_add(struct device *dev, unsigned long freq,
> unsigned long u_volt)
> }
>
> /**
> + * opp_free_rcu() - helper to clear the struct opp when grace period has
> + * elapsed without blocking the the caller of opp_set_availability
> + */
> +static void opp_free_rcu(struct rcu_head *head)
> +{
> + struct opp *opp = container_of(head, struct opp, head);
> +
> + kfree(opp);
> +}
> +
> +/**
> * opp_set_availability() - helper to set the availability of an opp
> * @dev: device for which we do this operation
> * @freq: OPP frequency to modify availability
> @@ -511,7 +523,7 @@ static int opp_set_availability(struct device *dev,
> unsigned long freq,
>
> list_replace_rcu(&opp->node, &new_opp->node);
> mutex_unlock(&dev_opp_list_lock);
> - synchronize_rcu();
> + call_rcu(&opp->head, opp_free_rcu);
>
> /* Notify the change of the OPP availability */
> if (availability_req)
> @@ -521,13 +533,10 @@ static int opp_set_availability(struct device *dev,
> unsigned long freq,
> srcu_notifier_call_chain(&dev_opp->head, OPP_EVENT_DISABLE,
> new_opp);
>
> - /* clean up old opp */
> - new_opp = opp;
> - goto out;
> + return 0;
>
> unlock:
> mutex_unlock(&dev_opp_list_lock);
> -out:
> kfree(new_opp);
> return r;
> }
> --
> 1.7.9.5
>
>
> ___
> linaro-dev mailing list
> linaro-dev@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-dev
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: llct "stable" trees
On 09/09/2012 11:40 AM, Ricardo Salveti wrote: On Wed, Sep 5, 2012 at 7:55 AM, Andy Green wrote: On 09/05/12 17:19, the mail apparently from Andy Green included: On 09/04/12 12:13, the mail apparently from Ricardo Salveti included: Hi - 1) Can we have linux stable point release content in tilt-3.4? Rather than my doing it, isn't it better to add it to llc-3.4 and merge it on the lt history tree periodically? That way every lt can get them from one place. I don't see why merging the stable release contents would be an issue. We could keep updating the tree based on stable-only releases, as long as we still have at least one Landing Team interested on consuming it. This would be another job that would probably be automated by Andrey's scripts. Right it should usually be simple, although don't forget there is quite a lot of avant garde content in llct, such as Androidization. Just today I saw Xavier at TI find that merging of stable had a patch conflicting with llct Androidization content. So, it turns out that is a good example. I researched the conflict and found a thread from RMK rejecting the patch 96714b5dfe283cd8ab13aac1f9ccb565064af152 that seems to have come in by Androidization series via llct. http://lists.infradead.org/pipermail/linux-arm-kernel/2010-May/014116.html We decided to take the kernel.org stable version of the patch 6019ae78aa65afe273da8c0dfeed8e89fb5edf8f which removes some locking evil in the Androidization version, which RMK noted opened up a horrible race. Xavier then found a ghastly bug that had previously been impossible to track down disappeared. So we now know that 96714b5dfe283cd8ab13aac1f9ccb565064af152 we had been happily pushing out on everyone in llct-3.4 is a terrible idea, not just for TILT but any kernel that has it in will suffer from very hard to reproduce mm instability under stress, and needs reverting in favour of the version that went in kernel.org stable. But now we know about that flaw in llct-3.4 should we not do something about it? Yeah, at least for stable related changes I believe it'd make a lot of sense to push those to llct-3.4. Andrey, let's also coordinate the stable updates for llct-3.4 during this cycle, and then review the issues, if we get any, after the first merge/update. Cheers, I've created the linux-linaro-core-3.4 branch: http://git.linaro.org/gitweb?p=kernel/linux-linaro-tracking.git;a=shortlog;h=refs/heads/linux-linaro-core-3.4 (and the manifest: http://git.linaro.org/gitweb?p=kernel/linux-linaro-manifest.git;a=shortlog;h=refs/heads/linux-linaro-core-3.4) At the moment this is just something to start from: the old known llct_3.4 with the updated Gator. The rest should follow soon. Thanks, Andrey ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v3 00/23] Introduce Xen support on ARM
Russell, sorry for not CC'ing you on the entire patch series in the past, I'll do it in the next iteration of the series (that TBH is nearly identical to this one apart from being 3.6-rc5 based). Are you happy with it? Given that the changes are entirely contained within arch/arm/xen and arch/arm/include/asm/xen (apart from patch #21 that is a generic ARM fix), should this patch series go through you or Arnd? Thanks, Stefano On Thu, 16 Aug 2012, Stefano Stabellini wrote: > Hi all, > this patch series implements Xen support for ARMv7 with virtualization > extensions. It allows a Linux guest to boot as dom0 and > as domU on Xen on ARM. PV console, disk and network frontends and > backends are all working correctly. > > It has been tested on a Versatile Express Cortex A15 emulator, using the > latest Xen ARM developement branch > (git://xenbits.xen.org/people/ianc/xen-unstable.git arm-for-4.3) plus > the "ARM hypercall ABI: 64 bit ready" patch series > (http://marc.info/?l=xen-devel&m=134426267205408), and a simple ad-hoc > tool to build guest domains (marc.info/?l=xen-devel&m=134089788016546). > > The patch marked with [HACK] shouldn't be applied and is part of the > series only because it is needed to create domUs. > > I am also attaching to this email the dts'es that I am currently using > for dom0 and domU: vexpress-v2p-ca15-tc1.dts (that includes > vexpress-v2m-rs1-rtsm.dtsi) is the dts used for dom0 and it is passed to > Linux by Xen, while vexpress-virt.dts is the dts used for other domUs > and it is appended in binary form to the guest kernel image. I am not > sure where they are supposed to live yet, so I am just attaching them > here so that people can actually try out this series if they want to. > > Comments are very welcome! > > > Changes in v3: > - move patches that have been picked up by Konrad at the end of the > series; > - improve comments; > - add a doc to describe the Xen Device Tree format; > - do not use xen_ulong_t for multicalls and apic_physbase; > - add a patch at the end of the series to use the new __HVC macro; > - add missing pvclock-abi.h include to ia64 header files; > - do not use an anonymous union in struct xen_add_to_physmap. > > > Changes in v2: > - fix up many comments and commit messages; > - remove the early_printk patches: rely on the emulated serial for now; > - remove the xen_guest_init patch: without any PV early_printk, we don't > need any early call to xen_guest_init, we can rely on core_initcall > alone; > - define an HYPERCALL macro for 5 arguments hypercall wrappers, even if > at the moment is unused; > - use ldm instead of pop in the hypercall wrappers; > - return -ENOSYS rather than -1 from the unimplemented grant_table > functions; > - remove the pvclock ifdef in the Xen headers; > - remove include linux/types.h from xen/interface/xen.h; > - replace pr_info with pr_debug in xen_guest_init; > - add a new patch to introduce xen_ulong_t and use it top replace all > the occurences of unsigned long in the public Xen interface; > - explicitely size all the pointers to 64 bit on ARM, so that the > hypercall ABI is "64 bit ready"; > - clean up xenbus_init; > - make pci.o depend on CONFIG_PCI and acpi.o depend on CONFIG_ACPI; > - mark Xen guest support on ARM as EXPERIMENTAL; > - introduce GRANT_TABLE_PHYSADDR; > - remove unneeded initialization of boot_max_nr_grant_frames; > - add a new patch to clear IRQ_NOAUTOEN and IRQ_NOREQUEST in events.c; > - return -EINVAL from xen_remap_domain_mfn_range if > auto_translated_physmap; > - retain binary compatibility in xen_add_to_physmap: use a union to > introduce foreign_domid. > > > Ian Campbell (1): > [HACK] xen/arm: implement xen_remap_domain_mfn_range > > Stefano Stabellini (24): > arm: initial Xen support > xen/arm: hypercalls > xen/arm: page.h definitions > xen/arm: sync_bitops > xen/arm: empty implementation of grant_table arch specific functions > docs: Xen ARM DT bindings > xen/arm: Xen detection and shared_info page mapping > xen/arm: Introduce xen_pfn_t for pfn and mfn types > xen/arm: Introduce xen_ulong_t for unsigned long > xen/arm: compile and run xenbus > xen: do not compile manage, balloon, pci, acpi and cpu_hotplug on ARM > xen/arm: introduce CONFIG_XEN on ARM > xen/arm: get privilege status > xen/arm: initialize grant_table on ARM > xen/arm: receive Xen events on ARM > xen: clear IRQ_NOAUTOEN and IRQ_NOREQUEST > xen/arm: implement alloc/free_xenballooned_pages with alloc_pages/kfree > xen: allow privcmd for HVM guests > xen/arm: compile blkfront and blkback > xen/arm: compile netback > arm/v2m: initialize arch_timers even if v2m_timer is not present > xen/arm: use the __HVC macro > xen: missing includes > xen: update xen_add_to_physmap interface > > Documentation/devicetree/bindings/arm/xen.txt | 22 +++ > arch/arm/Kcon
Re: Implement devicetree support for AB8500 Btemp
On Thursday 13 September 2012, Rajanikanth HV wrote: > On Wednesday 12 September 2012 09:06 PM, Arnd Bergmann wrote:> > > > If this is true, I don't understand what makes the 'supplied-to' > > properties you list in the device tree binding board specific. Are > > they not always done the same way? If so, you could just leave them > > out. > Precisely 'supplied-to' is not board specific, it was maintained as > platform_data which i migrated to dt-node. It is meant to establish > dependency across bm drivers based on power_supply property and > runtime battery attributes. > Basically, 'supplied-to' provides a way of exporting change in > power_supply_property and runtime batter characteristics so that other > bm devs shall make use or refer the updated values. > Ref: external_power_changed(...) call back api. > Note: all the bm drivers handles subset of power_supply property and > battery attributes, > ref: include/linux/power_supply.h and get_property(...) call back > api across bm drivers. Ok, so you want to just remove the property from the device tree, or do you want to establish a different method to specify these connections? > > What does indeed seem to be needed is a place to identify the battery > > type, but it's not clear if the btemp device is the best place for > > that (maybe it is). > I am not clear whether you are trying to correlate battery-type with > supplied-to. however, battery type is identified based on the > resistance value measured at batctrl pin which is expected to be in the > allowable limit of ab8500 device. This resistance limit varies across > battery types. This happens in btemp driver. I wasn't correlating them. I just mentioned that unlike the supplied-to property, the battery type property does seem to belong into the device tree. > For this, I would suggest you give a list of > > possible batteries and require a property such as > > > > st-ericsson,battery-type: A string identifier for the type of battery, > >which impacts how an operating system interpret > >the sensor readings. Possible values include: > > * "none"-- no battery connected > > * "li-ion-9100" -- Type 9100 Li-ION battery > > * > Can do this, not precisely as "st-ericsson,battery-type", it will be as > battery-type = [unknown|NiMH|LION|...|]], reason being > allowable battery type is based on technology, as you can see the > possible types as: > POWER_SUPPLY_TECHNOLOGY_UNKNOWN = 0, > POWER_SUPPLY_TECHNOLOGY_NiMH, > POWER_SUPPLY_TECHNOLOGY_LION, > POWER_SUPPLY_TECHNOLOGY_LIPO, > POWER_SUPPLY_TECHNOLOGY_LiFe, > POWER_SUPPLY_TECHNOLOGY_NiCd, > POWER_SUPPLY_TECHNOLOGY_LiMn > Ref: include/linux/power_supply.h > Note: doing this will impact my of_probe(...), may slightly bloat the > code. Ok. If you want to make the battery type a generic property, it's probably best to start a separate binding document for this in Documentation/devicetree/bindings/power-supply/common.txt and document a string for each of these. If we expect the property to be needed only for ab8500, please use a vendor prefix like 'stericsson,'. Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH v2 3/3] devfreq: Add current freq callback in device profile
From: Rajagopal Venkat
Devfreq returns governor predicted frequency as current frequency
via sysfs interface. But device may not support all frequencies
that governor predicts. So add a callback in device profile to get
current freq from driver. Also add a new sysfs node to expose
governor predicted next target frequency.
Signed-off-by: Rajagopal Venkat
---
Documentation/ABI/testing/sysfs-class-devfreq | 11 ++-
drivers/devfreq/devfreq.c | 14 ++
include/linux/devfreq.h | 3 +++
3 files changed, 27 insertions(+), 1 deletion(-)
diff --git a/Documentation/ABI/testing/sysfs-class-devfreq
b/Documentation/ABI/testing/sysfs-class-devfreq
index 89283b1..e6cf08e 100644
--- a/Documentation/ABI/testing/sysfs-class-devfreq
+++ b/Documentation/ABI/testing/sysfs-class-devfreq
@@ -19,7 +19,16 @@ Date:September 2011
Contact: MyungJoo Ham
Description:
The /sys/class/devfreq/.../cur_freq shows the current
- frequency of the corresponding devfreq object.
+ frequency of the corresponding devfreq object. Same as
+ target_freq when get_cur_freq() is not implemented by
+ devfreq driver.
+
+What: /sys/class/devfreq/.../target_freq
+Date: September 2012
+Contact: Rajagopal Venkat
+Description:
+ The /sys/class/devfreq/.../target_freq shows the next governor
+ predicted target frequency of the corresponding devfreq object.
What: /sys/class/devfreq/.../polling_interval
Date: September 2011
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index 309c46e..049e273 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -401,6 +401,19 @@ static ssize_t show_governor(struct device *dev,
static ssize_t show_freq(struct device *dev,
struct device_attribute *attr, char *buf)
{
+ unsigned long freq;
+ struct devfreq *devfreq = to_devfreq(dev);
+
+ if (devfreq->profile->get_cur_freq &&
+ !devfreq->profile->get_cur_freq(devfreq->dev.parent, &freq))
+ return sprintf(buf, "%lu\n", freq);
+
+ return sprintf(buf, "%lu\n", devfreq->previous_freq);
+}
+
+static ssize_t show_target_freq(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
return sprintf(buf, "%lu\n", to_devfreq(dev)->previous_freq);
}
@@ -504,6 +517,7 @@ static ssize_t show_max_freq(struct device *dev, struct
device_attribute *attr,
static struct device_attribute devfreq_attrs[] = {
__ATTR(governor, S_IRUGO, show_governor, NULL),
__ATTR(cur_freq, S_IRUGO, show_freq, NULL),
+ __ATTR(target_freq, S_IRUGO, show_target_freq, NULL),
__ATTR(polling_interval, S_IRUGO | S_IWUSR, show_polling_interval,
store_polling_interval),
__ATTR(min_freq, S_IRUGO | S_IWUSR, show_min_freq, store_min_freq),
diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
index 7c7e179..d12ed41 100644
--- a/include/linux/devfreq.h
+++ b/include/linux/devfreq.h
@@ -66,6 +66,8 @@ struct devfreq_dev_status {
* explained above with "DEVFREQ_FLAG_*" macros.
* @get_dev_status The device should provide the current performance
* status to devfreq, which is used by governors.
+ * @get_cur_freq The device should provide the current frequency
+ * at which it is operating.
* @exit An optional callback that is called when devfreq
* is removing the devfreq object due to error or
* from devfreq_remove_device() call. If the user
@@ -79,6 +81,7 @@ struct devfreq_dev_profile {
int (*target)(struct device *dev, unsigned long *freq, u32 flags);
int (*get_dev_status)(struct device *dev,
struct devfreq_dev_status *stat);
+ int (*get_cur_freq)(struct device *dev, unsigned long *freq);
void (*exit)(struct device *dev);
};
--
1.7.11.3
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH v2 1/3] devfreq: Core updates to support devices which can idle
From: Rajagopal Venkat
Prepare devfreq core framework to support devices which
can idle. When device idleness is detected perhaps through
runtime-pm, need some mechanism to suspend devfreq load
monitoring and resume back when device is online. Present
code continues monitoring unless device is removed from
devfreq core.
This patch introduces following design changes,
- use per device work instead of global work to monitor device
load. This enables suspend/resume of device devfreq and
reduces monitoring code complexity.
- decouple delayed work based load monitoring logic from core
by introducing helpers functions to be used by governors. This
provides flexibility for governors either to use delayed work
based monitoring functions or to implement their own mechanism.
- devfreq core interacts with governors via events to perform
specific actions. These events include start/stop devfreq.
This sets ground for adding suspend/resume events.
The devfreq apis are not modified and are kept intact.
Signed-off-by: Rajagopal Venkat
---
Documentation/ABI/testing/sysfs-class-devfreq | 8 -
drivers/devfreq/devfreq.c | 377 +-
drivers/devfreq/governor.h| 9 +
drivers/devfreq/governor_performance.c| 16 +-
drivers/devfreq/governor_powersave.c | 16 +-
drivers/devfreq/governor_simpleondemand.c | 31 +++
drivers/devfreq/governor_userspace.c | 23 +-
include/linux/devfreq.h | 31 +--
8 files changed, 219 insertions(+), 292 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-class-devfreq
b/Documentation/ABI/testing/sysfs-class-devfreq
index 23d78b5..89283b1 100644
--- a/Documentation/ABI/testing/sysfs-class-devfreq
+++ b/Documentation/ABI/testing/sysfs-class-devfreq
@@ -21,14 +21,6 @@ Description:
The /sys/class/devfreq/.../cur_freq shows the current
frequency of the corresponding devfreq object.
-What: /sys/class/devfreq/.../central_polling
-Date: September 2011
-Contact: MyungJoo Ham
-Description:
- The /sys/class/devfreq/.../central_polling shows whether
- the devfreq ojbect is using devfreq-provided central
- polling mechanism or not.
-
What: /sys/class/devfreq/.../polling_interval
Date: September 2011
Contact: MyungJoo Ham
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index b146d76..9bf2b6a 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -30,17 +30,11 @@
struct class *devfreq_class;
/*
- * devfreq_work periodically monitors every registered device.
- * The minimum polling interval is one jiffy. The polling interval is
- * determined by the minimum polling period among all polling devfreq
- * devices. The resolution of polling interval is one jiffy.
+ * devfreq core provides delayed work based load monitoring helper
+ * functions. Governors can use these or can implement their own
+ * monitoring mechanism.
*/
-static bool polling;
static struct workqueue_struct *devfreq_wq;
-static struct delayed_work devfreq_work;
-
-/* wait removing if this is to be removed */
-static struct devfreq *wait_remove_device;
/* The list of all device-devfreq */
static LIST_HEAD(devfreq_list);
@@ -72,6 +66,8 @@ static struct devfreq *find_device_devfreq(struct device *dev)
return ERR_PTR(-ENODEV);
}
+/* Load monitoring helper functions for governors use */
+
/**
* update_devfreq() - Reevaluate the device and configure frequency.
* @devfreq: the devfreq instance.
@@ -121,6 +117,91 @@ int update_devfreq(struct devfreq *devfreq)
}
/**
+ * devfreq_monitor() - Periodically poll devfreq objects.
+ * @work: the work struct used to run devfreq_monitor periodically.
+ *
+ */
+static void devfreq_monitor(struct work_struct *work)
+{
+ int err;
+ struct devfreq *devfreq = container_of(work,
+ struct devfreq, work.work);
+
+ mutex_lock(&devfreq->lock);
+ err = update_devfreq(devfreq);
+ if (err)
+ dev_err(&devfreq->dev, "dvfs failed with (%d) error\n", err);
+
+ queue_delayed_work(devfreq_wq, &devfreq->work,
+ msecs_to_jiffies(devfreq->profile->polling_ms));
+ mutex_unlock(&devfreq->lock);
+}
+
+/**
+ * devfreq_monitor_start() - Start load monitoring of devfreq instance
+ * @devfreq: the devfreq instance.
+ *
+ * Helper function for starting devfreq device load monitoing. By
+ * default delayed work based monitoring is supported. Function
+ * to be called from governor in response to DEVFREQ_GOV_START
+ * event when device is added to devfreq framework.
+ */
+void devfreq_monitor_start(struct devfreq *devfreq)
+{
+ INIT_DEFERRABLE_WORK(&devfreq->work, devfreq_monitor);
+ queue_delayed_work(devfreq_wq, &devfreq->work,
+ msecs_to_jiffies(devfreq->prof
[PATCH v2 2/3] devfreq: Add suspend and resume apis
From: Rajagopal Venkat
Add devfreq suspend/resume apis for devfreq users. This patch
supports suspend and resume of devfreq load monitoring, required
for devices which can idle.
Signed-off-by: Rajagopal Venkat
---
drivers/devfreq/devfreq.c | 26 ++
drivers/devfreq/governor.h| 2 ++
drivers/devfreq/governor_simpleondemand.c | 9 +
include/linux/devfreq.h | 12
4 files changed, 49 insertions(+)
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index 9bf2b6a..309c46e 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -366,6 +366,32 @@ int devfreq_remove_device(struct devfreq *devfreq)
}
EXPORT_SYMBOL(devfreq_remove_device);
+/**
+ * devfreq_suspend_device() - Suspend devfreq of a device.
+ * @devfreqthe devfreq instance to be suspended
+ */
+int devfreq_suspend_device(struct devfreq *devfreq)
+{
+ if (!devfreq)
+ return -EINVAL;
+
+ return devfreq->governor->event_handler(devfreq, DEVFREQ_GOV_SUSPEND);
+}
+EXPORT_SYMBOL(devfreq_suspend_device);
+
+/**
+ * devfreq_resume_device() - Resume devfreq of a device.
+ * @devfreqthe devfreq instance to be resumed
+ */
+int devfreq_resume_device(struct devfreq *devfreq)
+{
+ if (!devfreq)
+ return -EINVAL;
+
+ return devfreq->governor->event_handler(devfreq, DEVFREQ_GOV_RESUME);
+}
+EXPORT_SYMBOL(devfreq_resume_device);
+
static ssize_t show_governor(struct device *dev,
struct device_attribute *attr, char *buf)
{
diff --git a/drivers/devfreq/governor.h b/drivers/devfreq/governor.h
index fb621f8..4624607 100644
--- a/drivers/devfreq/governor.h
+++ b/drivers/devfreq/governor.h
@@ -22,6 +22,8 @@
#define DEVFREQ_GOV_START 0x1
#define DEVFREQ_GOV_STOP 0x2
#define DEVFREQ_GOV_INTERVAL 0x3
+#define DEVFREQ_GOV_SUSPEND0x4
+#define DEVFREQ_GOV_RESUME 0x5
/* Caution: devfreq->lock must be locked before calling update_devfreq */
extern int update_devfreq(struct devfreq *devfreq);
diff --git a/drivers/devfreq/governor_simpleondemand.c
b/drivers/devfreq/governor_simpleondemand.c
index 7aed0ef..68ad7d7 100644
--- a/drivers/devfreq/governor_simpleondemand.c
+++ b/drivers/devfreq/governor_simpleondemand.c
@@ -111,6 +111,15 @@ int devfreq_simple_ondemand_handler(struct devfreq
*devfreq,
else
devfreq_monitor_resume(devfreq);
break;
+
+ case DEVFREQ_GOV_SUSPEND:
+ devfreq_monitor_suspend(devfreq);
+ break;
+
+ case DEVFREQ_GOV_RESUME:
+ devfreq_monitor_resume(devfreq);
+ break;
+
default:
break;
}
diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
index 7a11c3e..7c7e179 100644
--- a/include/linux/devfreq.h
+++ b/include/linux/devfreq.h
@@ -155,6 +155,8 @@ extern struct devfreq *devfreq_add_device(struct device
*dev,
const struct devfreq_governor *governor,
void *data);
extern int devfreq_remove_device(struct devfreq *devfreq);
+extern int devfreq_suspend_device(struct devfreq *devfreq);
+extern int devfreq_resume_device(struct devfreq *devfreq);
/* Helper functions for devfreq user device driver with OPP. */
extern struct opp *devfreq_recommended_opp(struct device *dev,
@@ -208,6 +210,16 @@ static int devfreq_remove_device(struct devfreq *devfreq)
return 0;
}
+static int devfreq_suspend_device(struct devfreq *devfreq)
+{
+ return 0;
+}
+
+static int devfreq_resume_device(struct devfreq *devfreq)
+{
+ return 0;
+}
+
static struct opp *devfreq_recommended_opp(struct device *dev,
unsigned long *freq, u32 flags)
{
--
1.7.11.3
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH v2 0/3] devfreq: Add support for devices which can idle
From: Rajagopal Venkat This patchset updates devfreq core to add support for devices which can idle. When device idleness is detected perhaps through runtime-pm, need some mechanism to suspend devfreq load monitoring and resume when device is back online. patch 1 introduce core design changes - per device work, decouple delayed work from core and event based interaction. patch 2 add devfreq suspend and resume apis. patch 3 add new sysfs attribute for governor predicted next target frequency and callback for current device frequency. The existing devfreq apis are kept intact. Two new apis devfreq_suspend_device() and devfreq_resume_device() are added to support suspend/resume of device devfreq. Changes since v1: - revised locking mechanism - added kerneldoc comments for load monitoring helper functions - Fixed minor review comments -- Rajagopal Venkat (3): devfreq: Core updates to support devices which can idle devfreq: Add suspend and resume apis devfreq: Add current freq callback in device profile Documentation/ABI/testing/sysfs-class-devfreq | 15 +- drivers/devfreq/devfreq.c | 413 +++--- drivers/devfreq/governor.h| 11 + drivers/devfreq/governor_performance.c| 16 +- drivers/devfreq/governor_powersave.c | 16 +- drivers/devfreq/governor_simpleondemand.c | 40 +++ drivers/devfreq/governor_userspace.c | 23 +- include/linux/devfreq.h | 46 ++- 8 files changed, 291 insertions(+), 289 deletions(-) -- 1.7.11.3 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 1/3] devfreq: core updates to support devices which can idle
On 10 September 2012 14:43, 함명주 wrote:
>> Prepare devfreq core framework to support devices which
>> can idle. When device idleness is detected perhaps through
>> runtime-pm, need some mechanism to suspend devfreq load
>> monitoring and resume back when device is online. Present
>> code continues monitoring unless device is removed from
>> devfreq core.
>>
>> This patch introduces following design changes,
>>
>> - use per device work instead of global work to monitor device
>> load. This enables suspend/resume of device devfreq and
>> reduces monitoring code complexity.
>> - decouple delayed work based load monitoring logic from core
>> by introducing helpers functions to be used by governors. This
>> provides flexibility for governors either to use delayed work
>> based monitoring functions or to implement their own mechanism.
>> - devfreq core interacts with governors via events to perform
>> specific actions. These events include start/stop devfreq.
>> This sets ground for adding suspend/resume events.
>>
>> The devfreq apis are not modified and are kept intact.
>
> Hello,
>
> Please revise locking mechanism along with event handler.
>
> It appears that we need to do mutex_lock(&devfreq->lock) before calling
> devfreq->governor->event_handler();
I don't think is the case. The governor can make use of devfreq->lock if needed.
Anyways, I have revised locking mechanism in v2 set.
> Or at least, userspace_init and userspace_exit functions require mutex_lock.
The userspace_init function is executed only when device is added to devfreq
framework. This function itself is creating sysfs attributes. So this should not
be a concern for us.
The userspace_exit is executed when device is removed from devfreq
framework. sysfs_remove_group() should take care of serving any pending
reference to sysfs attributes before removing them. No concern here as well.
Am I missing something which demand locking for these functions?
> Event_handler callback won't want the properties in devfreq to be changed
> externally during its execution.
Agree.
>
> Plus, please edit Documentation/ABI entry (central_polling is being removed)
Done.
>
> Other than that, it looks fine.
>
> Cheers!
> MyungJoo
>
>>
>> Signed-off-by: Rajagopal Venkat
>> ---
>> drivers/devfreq/devfreq.c | 376
>> ++
>> drivers/devfreq/governor.h| 9 +
>> drivers/devfreq/governor_performance.c| 16 +-
>> drivers/devfreq/governor_powersave.c | 16 +-
>> drivers/devfreq/governor_simpleondemand.c | 33 +++
>> drivers/devfreq/governor_userspace.c | 23 +-
>> include/linux/devfreq.h | 31 +--
>> 7 files changed, 220 insertions(+), 284 deletions(-)
>>
>> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
>> index b146d76..be524c7 100644
>> --- a/drivers/devfreq/devfreq.c
>> +++ b/drivers/devfreq/devfreq.c
>> @@ -30,17 +30,11 @@
>> struct class *devfreq_class;
>>
>> /*
>> - * devfreq_work periodically monitors every registered device.
>> - * The minimum polling interval is one jiffy. The polling interval is
>> - * determined by the minimum polling period among all polling devfreq
>> - * devices. The resolution of polling interval is one jiffy.
>> + * devfreq core provides delayed work based load monitoring helper
>> + * functions. Governors can use these or can implement their own
>> + * monitoring mechanism.
>> */
>> -static bool polling;
>> static struct workqueue_struct *devfreq_wq;
>> -static struct delayed_work devfreq_work;
>> -
>> -/* wait removing if this is to be removed */
>> -static struct devfreq *wait_remove_device;
>>
>> /* The list of all device-devfreq */
>> static LIST_HEAD(devfreq_list);
>> @@ -72,6 +66,8 @@ static struct devfreq *find_device_devfreq(struct device
>> *dev)
>> return ERR_PTR(-ENODEV);
>> }
>>
>> +/* Load monitoring helper functions for governors use */
>> +
>> /**
>> * update_devfreq() - Reevaluate the device and configure frequency.
>> * @devfreq: the devfreq instance.
>> @@ -121,6 +117,90 @@ int update_devfreq(struct devfreq *devfreq)
>> }
>>
>> /**
>> + * devfreq_monitor() - Periodically poll devfreq objects.
>> + * @work: the work struct used to run devfreq_monitor periodically.
>> + *
>> + */
>> +static void devfreq_monitor(struct work_struct *work)
>> +{
>> + int err;
>> + struct devfreq *devfreq = container_of(work,
>> + struct devfreq, work.work);
>> +
>> + mutex_lock(&devfreq->lock);
>> + err = update_devfreq(devfreq);
>> + mutex_unlock(&devfreq->lock);
>> + if (err)
>> + dev_err(&devfreq->dev, "dvfs failed with (%d) error\n", err);
>> +
>> + queue_delayed_work(devfreq_wq, &devfreq->work,
>> +
>> msecs_to_jiffies(devfreq->profile->polling_ms));
>> +}
>> +
>> +/**
>> + * devfreq_monitor_start() - Start load monitoring of devfreq instance
>> + * using default d
Re: Implement devicetree support for AB8500 Btemp
On Wednesday 12 September 2012 09:06 PM, Arnd Bergmann wrote:
> On Wednesday 12 September 2012, Rajanikanth HV wrote:
>> On Tuesday 11 September 2012 04:52 PM, Arnd Bergmann wrote:
>>> On Tuesday 11 September 2012, Rajanikanth HV wrote:
>
>> Consider: USB charging:
>> __
>>| |
>> --(Vbus)-->| USB Charger with |
>>| Charger FSM (h/w) |
>>|__|
>> ||
>> ||(Vbat and other signals)
>> | __|_
>> to | ||(GaugeSense
>> Charger FSM| | LION | Signal) _
>> | |Battery |--->|FuelGauge blk|
>> | |||{Coulomb Ctr}|
>> | |-
>> |
>> | |
>> | | (BatCtrl Signal)
>> |___|-->[Btemp blk]
>> | |
>> [ADC] |__Btemp_Low
>> |__Btemp_Med
>> |__Btemp_High
>>
>> Note: Charging algorithm is a logical entity.
> Ok, thanks for the explanation, this is starting to make a lot more
> sense. So the three blocks (fb, btemp, charger) are all separate
> mfd cells, each with their own register set in ab8500 and a separate
> driver in drivers/power, right?
Correct, You can have a look at ab8500 spec:
www.stericsson.com/developers/CD00291561_UM1031_AB8500_user_manual-rev5_CTDS_public.pdf
>
> Then there is the ab8500-charalg driver which I guess is implementing
> the Charger FSM you mention above,
ab8500-charalg does not implements charger FSM, Charger FSM is a
hardware block for which any functional info is not available in the
spec. However, ab8500-charalg implements state m/c depicted in the
figure (9) of spec, implementation can be found in the code:
abx500_chargalg.c: centered around abx500_chargalg_algorithm(..)
Let me brief out what 'charger(Wall/USB)' and 'chargalg' driver does:
(a) Charger driver implements:
- events specific to Wall(a/c) and USB Charger
- power supply attributes handling and notification
to power_supply core. Ref: enum power_supply_property
linux/power_supply.h
Note: subset of power_supply_property are handled
- turn on/off charging led, AC and USB charging
- Regulating Voltage and Current values for charging
- voltage threshold check
- Charging regulation based on btemp
all this functionality has register dependency
(b) Charging algorithm:
- Starts by collecting power_supply properties across power
class devices which are 'bm' devices
- Maintains the different charging states across ac and usb
charging process pertaining to 'Vbus, main or Vbat', thermal,
btemp etc.,
- Implements subset of power_suppply_class properties
Note: Do not have direct register interface
but it doesn't have any registers
yes, but make use of power supply properties updated by other bm devs
while managing charging states.
> in the ab8500 but rather ties the other drivers together.
>
> If this is true, I don't understand what makes the 'supplied-to'
> properties you list in the device tree binding board specific. Are
> they not always done the same way? If so, you could just leave them
> out.
Precisely 'supplied-to' is not board specific, it was maintained as
platform_data which i migrated to dt-node. It is meant to establish
dependency across bm drivers based on power_supply property and
runtime battery attributes.
Basically, 'supplied-to' provides a way of exporting change in
power_supply_property and runtime batter characteristics so that other
bm devs shall make use or refer the updated values.
Ref: external_power_changed(...) call back api.
Note: all the bm drivers handles subset of power_supply property and
battery attributes,
ref: include/linux/power_supply.h and get_property(...) call back
api across bm drivers.
>
> What does indeed seem to be needed is a place to identify the battery
> type, but it's not clear if the btemp device is the best place for
> that (maybe it is).
I am not clear whether you are trying to correlate battery-type with
supplied-to. however, battery type is identified based on the
resistance value measured at batctrl pin which is expected to be in the
allowable limit of ab8500 device. This resistance limit varies across
battery types. This happens in btemp driver.
For this, I would suggest you give a list of
> possible batteries and require a property such as
>
> st-ericsson,battery-type: A string identifier for the type of battery,
> which impacts how an operating system interpret
> the sensor readings. Possible values include:
>
Re: [PATCH v4 3/5] ARM: topology: Update cpu_power according to DT information
On Mon, Jul 09, 2012 at 11:27:04AM +0200, Vincent Guittot wrote:
> Use cpu compatibility field and clock-frequency field of DT to
> estimate the capacity of each core of the system and to update
> the cpu_power field accordingly.
> This patch enables to put more running tasks on big cores than
> on LITTLE ones. But this patch doesn't ensure that long running
> tasks will run on big cores and short ones on LITTLE cores.
>
> Signed-off-by: Vincent Guittot
> Reviewed-by: Namhyung Kim
> ---
> arch/arm/kernel/topology.c | 153
>
> 1 file changed, 153 insertions(+)
>
> diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
> index eb5fc81..198b084 100644
> --- a/arch/arm/kernel/topology.c
> +++ b/arch/arm/kernel/topology.c
> @@ -17,7 +17,9 @@
> #include
> #include
> #include
> +#include
> #include
> +#include
>
> #include
> #include
> @@ -49,6 +51,152 @@ static void set_power_scale(unsigned int cpu, unsigned
> long power)
> per_cpu(cpu_scale, cpu) = power;
> }
>
> +#ifdef CONFIG_OF
> +struct cpu_efficiency {
> + const char *compatible;
> + unsigned long efficiency;
> +};
> +
> +/*
> + * Table of relative efficiency of each processors
> + * The efficiency value must fit in 20bit and the final
> + * cpu_scale value must be in the range
> + * 0 < cpu_scale < 3*SCHED_POWER_SCALE/2
> + * in order to return at most 1 when DIV_ROUND_CLOSEST
> + * is used to compute the capacity of a CPU.
> + * Processors that are not defined in the table,
> + * use the default SCHED_POWER_SCALE value for cpu_scale.
> + */
> +struct cpu_efficiency table_efficiency[] = {
> + {"arm,cortex-a15", 3891},
> + {"arm,cortex-a7", 2048},
> + {NULL, },
How accurate would we expect this to be, in general?
How the SoC is integrated will affect things, and throughput is not a
linear function of the clock frequency due to bus and DRAM timing
effects, and so on.
Part of the issue here is that two CPUs can be "compatible" in the DT
sense even when in performance terms there may be significant differences
(different integration options, difference cache sizes, etc.)
If the CPU power estimate doesn't need to be very precise (I suspect it
doesn't?) then then may not be a problem.
Otherwise, could it make sense to put values into the DT itself, or at
least to have the possibility of doing so?
Of course, this can probably be delayed until it proves to be necessary.
Maybe we'll never need it.
Cheers
---Dave
> +};
> +
> +struct cpu_capacity {
> + unsigned long hwid;
> + unsigned long capacity;
> +};
> +
> +struct cpu_capacity *cpu_capacity;
> +
> +unsigned long middle_capacity = 1;
> +
> +/*
> + * Iterate all CPUs' descriptor in DT and compute the efficiency
> + * (as per table_efficiency). Also calculate a middle efficiency
> + * as close as possible to (max{eff_i} - min{eff_i}) / 2
> + * This is later used to scale the cpu_power field such that an
> + * 'average' CPU is of middle power. Also see the comments near
> + * table_efficiency[] and update_cpu_power().
> + */
> +static void __init parse_dt_topology(void)
> +{
> + struct cpu_efficiency *cpu_eff;
> + struct device_node *cn = NULL;
> + unsigned long min_capacity = (unsigned long)(-1);
> + unsigned long max_capacity = 0;
> + unsigned long capacity = 0;
> + int alloc_size, cpu = 0;
> +
> + alloc_size = nr_cpu_ids * sizeof(struct cpu_capacity);
> + cpu_capacity = (struct cpu_capacity *)kzalloc(alloc_size, GFP_NOWAIT);
> +
> + while ((cn = of_find_node_by_type(cn, "cpu"))) {
> + const u32 *rate, *reg;
> + int len;
> +
> + if (cpu >= num_possible_cpus())
> + break;
> +
> + for (cpu_eff = table_efficiency; cpu_eff->compatible; cpu_eff++)
> + if (of_device_is_compatible(cn, cpu_eff->compatible))
> + break;
> +
> + if (cpu_eff->compatible == NULL)
> + continue;
> +
> + rate = of_get_property(cn, "clock-frequency", &len);
> + if (!rate || len != 4) {
> + pr_err("%s missing clock-frequency property\n",
> + cn->full_name);
> + continue;
> + }
> +
> + reg = of_get_property(cn, "reg", &len);
> + if (!reg || len != 4) {
> + pr_err("%s missing reg property\n", cn->full_name);
> + continue;
> + }
> +
> + capacity = ((be32_to_cpup(rate)) >> 20) * cpu_eff->efficiency;
> +
> + /* Save min capacity of the system */
> + if (capacity < min_capacity)
> + min_capacity = capacity;
> +
> + /* Save max capacity of the system */
> + if (capacity > max_capacity)
> + max_capacity = capacity;
> +
> + cpu_capacity[cpu].capacity = capaci
Re: [PATCH v4 0/5] ARM: topology: set the capacity of each cores for big.LITTLE
On 13 September 2012 14:07, Peter Zijlstra wrote: > On Thu, 2012-09-13 at 11:17 +0200, Vincent Guittot wrote: >> On 10 July 2012 15:42, Peter Zijlstra wrote: >> > On Tue, 2012-07-10 at 14:35 +0200, Vincent Guittot wrote: >> >> >> >> May be the last one which enable ARCH_POWER should also go into tip ? >> >> >> > OK, I can take it. >> >> Hi Peter, >> >> I can't find the patch that enable ARCH_POWER in the tip tree. Have >> you take it in your tree ? > > > Uhmmm how about I say I have now? Sorry about that. ok, thanks ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC] sched: nohz_idle_balance
On Thu, 2012-09-13 at 10:19 +0200, Peter Zijlstra wrote: > On Thu, 2012-09-13 at 08:49 +0200, Mike Galbraith wrote: > > On Thu, 2012-09-13 at 06:11 +0200, Vincent Guittot wrote: > > > On tickless system, one CPU runs load balance for all idle CPUs. > > > The cpu_load of this CPU is updated before starting the load balance > > > of each other idle CPUs. We should instead update the cpu_load of the > > > balance_cpu. > > > > > > Signed-off-by: Vincent Guittot > > > --- > > > kernel/sched/fair.c | 11 ++- > > > 1 file changed, 6 insertions(+), 5 deletions(-) > > > > > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > > > index 1ca4fe4..9ae3a5b 100644 > > > --- a/kernel/sched/fair.c > > > +++ b/kernel/sched/fair.c > > > @@ -4794,14 +4794,15 @@ static void nohz_idle_balance(int this_cpu, enum > > > cpu_idle_type idle) > > > if (need_resched()) > > > break; > > > > > > - raw_spin_lock_irq(&this_rq->lock); > > > - update_rq_clock(this_rq); > > > - update_idle_cpu_load(this_rq); > > > - raw_spin_unlock_irq(&this_rq->lock); > > > + rq = cpu_rq(balance_cpu); > > > + > > > + raw_spin_lock_irq(&rq->lock); > > > + update_rq_clock(rq); > > > + update_idle_cpu_load(rq); > > > + raw_spin_unlock_irq(&rq->lock); > > > > > > rebalance_domains(balance_cpu, CPU_IDLE); > > > > > > - rq = cpu_rq(balance_cpu); > > > if (time_after(this_rq->next_balance, rq->next_balance)) > > > this_rq->next_balance = rq->next_balance; > > > } > > > > Ew, banging locks and updating clocks to what good end? > > Well, updating the load statistics on the cpu you're going to balance > seems like a good end to me.. ;-) No point updating the local statistics > N times and leaving the ones you're going to balance stale for god knows > how long. Sure, the goal is fine, but I wonder about the price vs payoff. I was thinking perhaps the redundant updates should go away instead, unless stats are shown to be causing real world pain. -Mike ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v4 0/5] ARM: topology: set the capacity of each cores for big.LITTLE
On Thu, 2012-09-13 at 11:17 +0200, Vincent Guittot wrote: > On 10 July 2012 15:42, Peter Zijlstra wrote: > > On Tue, 2012-07-10 at 14:35 +0200, Vincent Guittot wrote: > >> > >> May be the last one which enable ARCH_POWER should also go into tip ? > >> > > OK, I can take it. > > Hi Peter, > > I can't find the patch that enable ARCH_POWER in the tip tree. Have > you take it in your tree ? Uhmmm how about I say I have now? Sorry about that. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v3 06/25] docs: Xen ARM DT bindings
On Thu, 13 Sep 2012, Rob Herring wrote: > On 09/12/2012 01:14 PM, Stefano Stabellini wrote: > > On Wed, 12 Sep 2012, Stefano Stabellini wrote: > >> On Tue, 28 Aug 2012, Rob Herring wrote: > >>> You should look at ePAPR 1.1 which defines hypervisor related bindings. > >>> While it is a PPC doc, we should reuse or extend what makes sense. > >>> > >>> See section 7.5: > >>> > >>> https://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.1.pdf > >> > >> Thanks for the link, I wasn't aware of ePAPR. > >> > >> The hypervisor node defined by ePAPR is not very different from what I > >> am proposing. Should I try to be compatible with the hypervisor > >> specification above (as in compatible = "epapr,hypervisor-1.1")? > >> Or should I just use it as a reference for my own specification? > >> > >> Personally I would rather avoid full compatibility with ePAPR. > > > > In particular reading section 7.5, these are the required properties of > > the ePAPR hypervisor node: > > > > - compatible = "epapr,hypervisor-1.1" > > compared to what I am proposing, it is laking information about what > > hypervisor we are talking about (xen, kvm, vmware, etc) and the version > > of the ABI (xen-4.2). > > compatible properties are often changed. If we do deviate on the rest of > the binding, then it needs to be different. > > Turns out that powerpc KVM guests use "linux,kvm" and "epapr,hypervisor" > doesn't even appear in the kernel. > > We also perhaps have to consider the possibility of Xen on PowerPC. Then > alignment is more important. OK. In that case I think that we can just use "xen,xen-4.2". > > - hcall-instructions > > potentially interesting, but given that for Xen we are quite happy with > > HVC, we are not going to add any secondary hypercall mechanisms, > > therefore at the moment it would just result in a BUG if the specified > > hcall instruction is != HVC. Besides if somebody else wanted to > > implemented the Xen hypercall interface in a different way they could > > just reimplement the hypercall wrappers, that would be easier than > > trying to do it with this property. > > It's really about the parameters passed with the HVC. The ePAPR may be a > good model for defining this. Just grepping "hypervisor" under > arch/powerpc, it's pretty clear hypervisor support happened first and > the ePAPR came second. Hopefully we can avoid that for ARM. Right. As I wrote in the other email, we could have a new property to select the calling convention (and therefore the hypercall wrappers) to be used with the hypervisor. > > - guest-id > > we usually make a point in trying not to tell the guest its own domid > > because if the VM gets migrated to a different host it acquires a new > > domid, therefore it should not rely on it. > > > > - guest-name > > we could pass the guest name here, but I don't see how it could be > > of any use. > > > > I have no issue with these being optional. OK, good. > > On the other hand, thinking more about what Xen needs in the device > > tree, I think we could improve the current spec by clarifying the > > meaning of the memory region and interrupt properties we currently > > require. I thought about moving them to two separate children node with > > an explicit name: > > > > --- > > > > * Xen hypervisor device tree bindings > > > > I really think we need to define ARM hypervisor device tree bindings > first, then Xen specific bindings as an addition to that. I worry that > the KVM folks aren't paying attention and then want something different > later on. The problem is that there isn't much in common between Xen and KVM at least from the DT point of view. I am not sure what would go into this common hypervisor node. The three key pieces of information that we are currently passing in the DT (xen-4.2, a memory region, a PPI) are Xen specific. If one day KVM (or another hypervisor vendor) decides to support the Xen interface, can't they just have the Xen specific binding with a slightly different compatible node? For example: compatible = "linux,kvm", "xen,xen-4.2" wouldn't that mean "I am KVM but I can support the Xen interface"? > > Xen ARM virtual platforms shall have the following properties and > > children nodes: > > > > - compatible property: > > compatible = "xen,xen", "xen,xen-"; > > "xen,xen" should be last as it is less specific. Ah OK, thanks. > > where is the version of the Xen ABI of the platform. > > > > - grant_table child with the following properties: > > - name: > > name = "grant_table"; > > What's a grant table? A Xen specific mechanism to share pages between guests. > > - reg: specifies the base physical address and size of a region in > > memory where the grant table should be mapped to, using an > > HYPERVISOR_memory_op hypercall. > > > > - events child with the following properties: > > - name: > > name = "events"; > > - interrupts: the interrupt used by Xen to inject even
Re: [PATCH v3 06/25] docs: Xen ARM DT bindings
On Thu, 13 Sep 2012, Dave Martin wrote: > Do you think it's feasible to standardise on some interoperable ABI for > kvm and Xen? This sounds pretty optimistic, but I'm not aware of all > the technicalities, or what possible third-party hypervisors are out > there. > > If we could do it, it would be good. But I have my doubts about the > feasibility and the benefits. If different hypervisors are significantly > imcompatible, then having a common low-level ABI doesn't help all that > much. It is not really possible because each hypervisor offers a different set of hypercalls and has a different calling convention, so there is very little we can do to unify them. For example many of the current Xen hypercalls are to deal with the grant table and event channels, that are Xen specific concepts completely missing in KVM. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v3 06/25] docs: Xen ARM DT bindings
On Thu, 13 Sep 2012, Dave Martin wrote: > On Wed, Sep 12, 2012 at 07:14:58PM +0100, Stefano Stabellini wrote: > > On Wed, 12 Sep 2012, Stefano Stabellini wrote: > > - hcall-instructions > > potentially interesting, but given that for Xen we are quite happy with > > HVC, we are not going to add any secondary hypercall mechanisms, > > therefore at the moment it would just result in a BUG if the specified > > hcall instruction is != HVC. Besides if somebody else wanted to > > implemented the Xen hypercall interface in a different way they could > > just reimplement the hypercall wrappers, that would be easier than > > trying to do it with this property. > > Some thoughts on this: > > We decided that embedding machine instructions into the DT is a fairly > awful idea when discussing how to describe low-level debug UARTs in the > DT. I don't think it's a lot better in this case (never mind issues > like ARM versus Thumb, endianness etc.) > > If we are going to attempt to describe the call interface, we should > do it symbolically, allowing the hypervisor interface code in the kernel > to choose (or, if necessary, generate) the right call wrappers. > > We will have this issue for descrbing power firmware interfaces for > example: we already know that this functionality might require an SMC > or HVC instruction to call it, depending on the platform. > > A hypervisor with only one call ABI could leave this to be implicit, > providing there is a version number property of similar to allow future > changes to be accommodated. I completely agree with Dave. I have no problems adding a symbolic property to say "we are using hvc with parameters on registers". I just want to avoid having actual machine instructions (and potentially dealing with executing them) into the DT. Maybe we could have a "calling-convention" property that can be "xen" or something else. When a new hypervisor vendor comes along it can change the value of "calling-convention" to "foo". ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[RFC PATCH v8] media: add v4l2 subdev driver for S5K4ECGX sensor
This patch adds driver for S5K4ECGX sensor with embedded ISP SoC, S5K4ECGX, which is a 5M CMOS Image sensor from Samsung The driver implements preview mode of the S5K4ECGX sensor. capture (snapshot) operation, face detection are missing now. Following controls are supported: contrast/saturation/brightness/sharpness Signed-off-by: Sangwook Lee Reviewed-by: Sylwester Nawrocki Cc: Francesco Lavra Cc: Scott Bambrough Cc: Homin Lee --- Changes since v7: - added gpio free function - fixed return value of power function Changes since v6: - fixed alignment issue from Francesco, Sylwester Changes since v5: - deleted dummy lines - fixed pointer errors in handling firmware - updated comments - added le32_to_cpu,le16_to_cpu Changes since v4: - replaced register tables with the function from Sylwester - updated firmware parsing function with CRC32 check firmware generator from user space: git://git.linaro.org/people/sangwook/fimc-v4l2-app.git Changes since v3: - used request_firmware to configure initial settings - added parsing functions to read initial settings - updated regulator API - reduced preview setting tables by experiment Changes since v2: - added GPIO (reset/stby) and regulators - updated I2C read/write, based on s5k6aa datasheet - fixed set_fmt errors - reduced register tables a bit - removed vmalloc Changes since v1: - fixed s_stream(0) when it called twice - changed mutex_X position to be used when strictly necessary - add additional s_power(0) in case that error happens - update more accurate debugging statements - remove dummy else drivers/media/i2c/Kconfig|7 + drivers/media/i2c/Makefile |1 + drivers/media/i2c/s5k4ecgx.c | 1017 ++ include/media/s5k4ecgx.h | 37 ++ 4 files changed, 1062 insertions(+) create mode 100644 drivers/media/i2c/s5k4ecgx.c create mode 100644 include/media/s5k4ecgx.h diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig index 9a5a059..55b3bbb 100644 --- a/drivers/media/i2c/Kconfig +++ b/drivers/media/i2c/Kconfig @@ -484,6 +484,13 @@ config VIDEO_S5K6AA This is a V4L2 sensor-level driver for Samsung S5K6AA(FX) 1.3M camera sensor with an embedded SoC image signal processor. +config VIDEO_S5K4ECGX +tristate "Samsung S5K4ECGX sensor support" +depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API +---help--- + This is a V4L2 sensor-level driver for Samsung S5K4ECGX 5M + camera sensor with an embedded SoC image signal processor. + source "drivers/media/i2c/smiapp/Kconfig" comment "Flash devices" diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile index 088a460..a720812 100644 --- a/drivers/media/i2c/Makefile +++ b/drivers/media/i2c/Makefile @@ -55,6 +55,7 @@ obj-$(CONFIG_VIDEO_MT9V032) += mt9v032.o obj-$(CONFIG_VIDEO_SR030PC30) += sr030pc30.o obj-$(CONFIG_VIDEO_NOON010PC30)+= noon010pc30.o obj-$(CONFIG_VIDEO_S5K6AA) += s5k6aa.o +obj-$(CONFIG_VIDEO_S5K4ECGX) += s5k4ecgx.o obj-$(CONFIG_VIDEO_ADP1653)+= adp1653.o obj-$(CONFIG_VIDEO_AS3645A)+= as3645a.o obj-$(CONFIG_VIDEO_SMIAPP_PLL) += smiapp-pll.o diff --git a/drivers/media/i2c/s5k4ecgx.c b/drivers/media/i2c/s5k4ecgx.c new file mode 100644 index 000..7b455e1 --- /dev/null +++ b/drivers/media/i2c/s5k4ecgx.c @@ -0,0 +1,1017 @@ +/* + * Driver for s5k4ecgx (5MP Camera) from Samsung + * a quarter-inch optical format 1.4 micron 5 megapixel (Mp) + * CMOS image sensor. + * + * Copyright (C) 2012, Linaro, Sangwook Lee + * Copyright (C) 2012, Insignal Co,. Ltd, Homin Lee + * + * Based on s5k6aa, noon010pc30 driver + * Copyright (C) 2011, Samsung Electronics Co., Ltd. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include + +static int debug; +module_param(debug, int, 0644); + +#define S5K4ECGX_DRIVER_NAME "s5k4ecgx" +#define S5K4ECGX_FIRMWARE "s5k4ecgx.bin" + +/* Firmware revision information */ +#define REG_FW_REVISION0x71a6 +#define REG_FW_VERSION 0x71a4 +#define S5K4ECGX_REVISION_1_1 0x11 +#define S5K4ECGX_FW_VERSION0x4ec0 + +/* General purpose parameters */ +#define REG_USER_BRIGHTNESS0x722c +#define REG_USER_CONTRAST 0x722e +#define REG_USER_SATURATION0x7230 + +#define REG_G_NEW_CFG_SYNC 0x724a +#define REG_G_PREV_IN_WIDTH0x7250 +#define REG_G_PREV_IN_HEIGHT 0x7252 +#define REG_G_PREV_IN_XOFFS0x7254 +#define REG_G_PREV_IN_YOFFS
Re: [PATCH v3 06/25] docs: Xen ARM DT bindings
On Wed, Sep 12, 2012 at 09:34:28PM -0500, Rob Herring wrote: > On 09/12/2012 01:14 PM, Stefano Stabellini wrote: > > On Wed, 12 Sep 2012, Stefano Stabellini wrote: > >> On Tue, 28 Aug 2012, Rob Herring wrote: > >>> You should look at ePAPR 1.1 which defines hypervisor related bindings. > >>> While it is a PPC doc, we should reuse or extend what makes sense. > >>> > >>> See section 7.5: > >>> > >>> https://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.1.pdf > >> > >> Thanks for the link, I wasn't aware of ePAPR. > >> > >> The hypervisor node defined by ePAPR is not very different from what I > >> am proposing. Should I try to be compatible with the hypervisor > >> specification above (as in compatible = "epapr,hypervisor-1.1")? > >> Or should I just use it as a reference for my own specification? > >> > >> Personally I would rather avoid full compatibility with ePAPR. > > > > In particular reading section 7.5, these are the required properties of > > the ePAPR hypervisor node: > > > > - compatible = "epapr,hypervisor-1.1" > > compared to what I am proposing, it is laking information about what > > hypervisor we are talking about (xen, kvm, vmware, etc) and the version > > of the ABI (xen-4.2). > > compatible properties are often changed. If we do deviate on the rest of > the binding, then it needs to be different. > > Turns out that powerpc KVM guests use "linux,kvm" and "epapr,hypervisor" > doesn't even appear in the kernel. > > We also perhaps have to consider the possibility of Xen on PowerPC. Then > alignment is more important. > > > - hcall-instructions > > potentially interesting, but given that for Xen we are quite happy with > > HVC, we are not going to add any secondary hypercall mechanisms, > > therefore at the moment it would just result in a BUG if the specified > > hcall instruction is != HVC. Besides if somebody else wanted to > > implemented the Xen hypercall interface in a different way they could > > just reimplement the hypercall wrappers, that would be easier than > > trying to do it with this property. > > It's really about the parameters passed with the HVC. The ePAPR may be a > good model for defining this. Just grepping "hypervisor" under > arch/powerpc, it's pretty clear hypervisor support happened first and > the ePAPR came second. Hopefully we can avoid that for ARM. Do you think it's feasible to standardise on some interoperable ABI for kvm and Xen? This sounds pretty optimistic, but I'm not aware of all the technicalities, or what possible third-party hypervisors are out there. If we could do it, it would be good. But I have my doubts about the feasibility and the benefits. If different hypervisors are significantly imcompatible, then having a common low-level ABI doesn't help all that much. Cheers ---Dave ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v3 06/25] docs: Xen ARM DT bindings
On Wed, Sep 12, 2012 at 07:14:58PM +0100, Stefano Stabellini wrote: > On Wed, 12 Sep 2012, Stefano Stabellini wrote: > > On Tue, 28 Aug 2012, Rob Herring wrote: > > > You should look at ePAPR 1.1 which defines hypervisor related bindings. > > > While it is a PPC doc, we should reuse or extend what makes sense. > > > > > > See section 7.5: > > > > > > https://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.1.pdf > > > > Thanks for the link, I wasn't aware of ePAPR. > > > > The hypervisor node defined by ePAPR is not very different from what I > > am proposing. Should I try to be compatible with the hypervisor > > specification above (as in compatible = "epapr,hypervisor-1.1")? > > Or should I just use it as a reference for my own specification? > > > > Personally I would rather avoid full compatibility with ePAPR. > > In particular reading section 7.5, these are the required properties of > the ePAPR hypervisor node: > > - compatible = "epapr,hypervisor-1.1" > compared to what I am proposing, it is laking information about what > hypervisor we are talking about (xen, kvm, vmware, etc) and the version > of the ABI (xen-4.2). > > - hcall-instructions > potentially interesting, but given that for Xen we are quite happy with > HVC, we are not going to add any secondary hypercall mechanisms, > therefore at the moment it would just result in a BUG if the specified > hcall instruction is != HVC. Besides if somebody else wanted to > implemented the Xen hypercall interface in a different way they could > just reimplement the hypercall wrappers, that would be easier than > trying to do it with this property. Some thoughts on this: We decided that embedding machine instructions into the DT is a fairly awful idea when discussing how to describe low-level debug UARTs in the DT. I don't think it's a lot better in this case (never mind issues like ARM versus Thumb, endianness etc.) If we are going to attempt to describe the call interface, we should do it symbolically, allowing the hypervisor interface code in the kernel to choose (or, if necessary, generate) the right call wrappers. We will have this issue for descrbing power firmware interfaces for example: we already know that this functionality might require an SMC or HVC instruction to call it, depending on the platform. A hypervisor with only one call ABI could leave this to be implicit, providing there is a version number property of similar to allow future changes to be accommodated. Cheers ---Dave ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC PATCH v7] media: add v4l2 subdev driver for S5K4ECGX sensor
Hi Francesco
On 12 September 2012 19:07, Francesco Lavra wrote:
> Hi Sangwook,
> two remarks from my review on September 9th haven't been addressed.
Thanks for the review.
I missed those, please let me correct them and send patch again.
Regards
Sangwook
> I believe those remarks are correct, but please let me know if I'm
> missing something.
> See below.
>
> On 09/12/2012 01:26 PM, Sangwook Lee wrote:
>> +static int s5k4ecgx_s_power(struct v4l2_subdev *sd, int on)
>> +{
>> + struct s5k4ecgx *priv = to_s5k4ecgx(sd);
>> + int ret;
>> +
>> + v4l2_dbg(1, debug, sd, "Switching %s\n", on ? "on" : "off");
>> +
>> + if (on) {
>> + ret = __s5k4ecgx_power_on(priv);
>> + if (ret < 0)
>> + return ret;
>> + /* Time to stabilize sensor */
>> + msleep(100);
>> + ret = s5k4ecgx_init_sensor(sd);
>> + if (ret < 0)
>> + __s5k4ecgx_power_off(priv);
>> + else
>> + priv->set_params = 1;
>> + } else {
>> + ret = __s5k4ecgx_power_off(priv);
>> + }
>> +
>> + return 0;
>
> return ret;
>
>> +static int s5k4ecgx_probe(struct i2c_client *client,
>> + const struct i2c_device_id *id)
>> +{
>> + int ret, i;
>> + struct v4l2_subdev *sd;
>> + struct s5k4ecgx *priv;
>> + struct s5k4ecgx_platform_data *pdata = client->dev.platform_data;
>> +
>> + if (pdata == NULL) {
>> + dev_err(&client->dev, "platform data is missing!\n");
>> + return -EINVAL;
>> + }
>> + priv = devm_kzalloc(&client->dev, sizeof(struct s5k4ecgx), GFP_KERNEL);
>> + if (!priv)
>> + return -ENOMEM;
>> +
>> + mutex_init(&priv->lock);
>> + priv->streaming = 0;
>> +
>> + sd = &priv->sd;
>> + /* Registering subdev */
>> + v4l2_i2c_subdev_init(sd, client, &s5k4ecgx_ops);
>> + strlcpy(sd->name, S5K4ECGX_DRIVER_NAME, sizeof(sd->name));
>> +
>> + sd->internal_ops = &s5k4ecgx_subdev_internal_ops;
>> + /* Support v4l2 sub-device user space API */
>> + sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
>> +
>> + priv->pad.flags = MEDIA_PAD_FL_SOURCE;
>> + sd->entity.type = MEDIA_ENT_T_V4L2_SUBDEV_SENSOR;
>> + ret = media_entity_init(&sd->entity, 1, &priv->pad, 0);
>> + if (ret)
>> + return ret;
>> +
>> + ret = s5k4ecgx_config_gpios(priv, pdata);
>> + if (ret) {
>> + dev_err(&client->dev, "Failed to set gpios\n");
>> + goto out_err1;
>> + }
>> + for (i = 0; i < S5K4ECGX_NUM_SUPPLIES; i++)
>> + priv->supplies[i].supply = s5k4ecgx_supply_names[i];
>> +
>> + ret = devm_regulator_bulk_get(&client->dev, S5K4ECGX_NUM_SUPPLIES,
>> + priv->supplies);
>> + if (ret) {
>> + dev_err(&client->dev, "Failed to get regulators\n");
>> + goto out_err2;
>> + }
>> + ret = s5k4ecgx_init_v4l2_ctrls(priv);
>> + if (ret)
>> + goto out_err2;
>> +
>> + priv->curr_pixfmt = &s5k4ecgx_formats[0];
>> + priv->curr_frmsize = &s5k4ecgx_prev_sizes[0];
>> +
>> + return 0;
>> +
>> +out_err2:
>> + s5k4ecgx_free_gpios(priv);
>> +out_err1:
>> + media_entity_cleanup(&priv->sd.entity);
>> +
>> + return ret;
>> +}
>> +
>> +static int s5k4ecgx_remove(struct i2c_client *client)
>> +{
>> + struct v4l2_subdev *sd = i2c_get_clientdata(client);
>> + struct s5k4ecgx *priv = to_s5k4ecgx(sd);
>> +
>> + mutex_destroy(&priv->lock);
>> + v4l2_device_unregister_subdev(sd);
>> + v4l2_ctrl_handler_free(&priv->handler);
>> + media_entity_cleanup(&sd->entity);
>> +
>> + return 0;
>
> s5k4ecgx_free_gpios() should be called to release the GPIOs
>
> Thanks,
> Francesco
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v4 0/5] ARM: topology: set the capacity of each cores for big.LITTLE
On 10 July 2012 15:42, Peter Zijlstra wrote: > On Tue, 2012-07-10 at 14:35 +0200, Vincent Guittot wrote: >> >> May be the last one which enable ARCH_POWER should also go into tip ? >> > OK, I can take it. Hi Peter, I can't find the patch that enable ARCH_POWER in the tip tree. Have you take it in your tree ? Regards, Vincent ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC] sched: nohz_idle_balance
On Thu, 2012-09-13 at 10:45 +0200, Peter Zijlstra wrote:
> On Thu, 2012-09-13 at 10:37 +0200, Vincent Guittot wrote:
> > > I think you need to present numbers showing benefit. Crawling all over
> > > a mostly idle (4096p?) box is decidedly bad thing to do.
>
> Yeah, but we're already doing that anyway.. we know nohz idle balance
> doesn't scale. Venki and Suresh were working on that, but with Venki
> switching jobs this work got dropped.
>
> I did talk to Suresh about it a week or so ago.. I think he was going to
> look at it again.
As a reminder to Suresh.. please also consider calc_load_{idle,idx} in
this work, its another nohz 'feature' that doesn't scale for pretty much
the same reason.
That is, I'm fine with the initial patches not actually fixing that, but
the structure put in place for the ILB should allow for it.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC] sched: nohz_idle_balance
On Thu, 2012-09-13 at 10:37 +0200, Vincent Guittot wrote: > > I think you need to present numbers showing benefit. Crawling all over > > a mostly idle (4096p?) box is decidedly bad thing to do. Yeah, but we're already doing that anyway.. we know nohz idle balance doesn't scale. Venki and Suresh were working on that, but with Venki switching jobs this work got dropped. I did talk to Suresh about it a week or so ago.. I think he was going to look at it again. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC] sched: nohz_idle_balance
Wrong button make me removed others guys from the thread. Sorry for this mistake. On 13 September 2012 09:56, Mike Galbraith wrote: > On Thu, 2012-09-13 at 09:44 +0200, Vincent Guittot wrote: >> On 13 September 2012 09:29, Mike Galbraith wrote: >> > On Thu, 2012-09-13 at 08:59 +0200, Vincent Guittot wrote: >> >> On 13 September 2012 08:49, Mike Galbraith wrote: >> >> > On Thu, 2012-09-13 at 06:11 +0200, Vincent Guittot wrote: >> >> >> On tickless system, one CPU runs load balance for all idle CPUs. >> >> >> The cpu_load of this CPU is updated before starting the load balance >> >> >> of each other idle CPUs. We should instead update the cpu_load of the >> >> >> balance_cpu. >> >> >> >> >> >> Signed-off-by: Vincent Guittot >> >> >> --- >> >> >> kernel/sched/fair.c | 11 ++- >> >> >> 1 file changed, 6 insertions(+), 5 deletions(-) >> >> >> >> >> >> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c >> >> >> index 1ca4fe4..9ae3a5b 100644 >> >> >> --- a/kernel/sched/fair.c >> >> >> +++ b/kernel/sched/fair.c >> >> >> @@ -4794,14 +4794,15 @@ static void nohz_idle_balance(int this_cpu, >> >> >> enum cpu_idle_type idle) >> >> >> if (need_resched()) >> >> >> break; >> >> >> >> >> >> - raw_spin_lock_irq(&this_rq->lock); >> >> >> - update_rq_clock(this_rq); >> >> >> - update_idle_cpu_load(this_rq); >> >> >> - raw_spin_unlock_irq(&this_rq->lock); >> >> >> + rq = cpu_rq(balance_cpu); >> >> >> + >> >> >> + raw_spin_lock_irq(&rq->lock); >> >> >> + update_rq_clock(rq); >> >> >> + update_idle_cpu_load(rq); >> >> >> + raw_spin_unlock_irq(&rq->lock); >> >> >> >> >> >> rebalance_domains(balance_cpu, CPU_IDLE); >> >> >> >> >> >> - rq = cpu_rq(balance_cpu); >> >> >> if (time_after(this_rq->next_balance, rq->next_balance)) >> >> >> this_rq->next_balance = rq->next_balance; >> >> >> } >> >> > >> >> > Ew, banging locks and updating clocks to what good end? >> >> >> >> The goal is to update the cpu_load table of the CPU before starting >> >> the load balance. Other wise we will use outdated value in the load >> >> balance sequence >> > >> > If there's load to distribute, seems it should all work out fine without >> > doing that. What harm is being done that makes this worth while? >> >> this_load and avg_load can be wrong and make an idle CPU set as >> balanced compared to the busy one > > I think you need to present numbers showing benefit. Crawling all over > a mostly idle (4096p?) box is decidedly bad thing to do. Yep, let me prepare some figures You should also notice that you are already crawling all over the idle processor in rebalance_domains Vincent > > -Mike > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC] sched: nohz_idle_balance
On Thu, 2012-09-13 at 06:11 +0200, Vincent Guittot wrote: > On tickless system, one CPU runs load balance for all idle CPUs. > The cpu_load of this CPU is updated before starting the load balance > of each other idle CPUs. We should instead update the cpu_load of the > balance_cpu. > > Signed-off-by: Vincent Guittot > --- > kernel/sched/fair.c | 11 ++- > 1 file changed, 6 insertions(+), 5 deletions(-) > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > index 1ca4fe4..9ae3a5b 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -4794,14 +4794,15 @@ static void nohz_idle_balance(int this_cpu, enum > cpu_idle_type idle) > if (need_resched()) > break; > > - raw_spin_lock_irq(&this_rq->lock); > - update_rq_clock(this_rq); > - update_idle_cpu_load(this_rq); > - raw_spin_unlock_irq(&this_rq->lock); > + rq = cpu_rq(balance_cpu); > + > + raw_spin_lock_irq(&rq->lock); > + update_rq_clock(rq); > + update_idle_cpu_load(rq); > + raw_spin_unlock_irq(&rq->lock); D'0h good spotting.. > rebalance_domains(balance_cpu, CPU_IDLE); > > - rq = cpu_rq(balance_cpu); > if (time_after(this_rq->next_balance, rq->next_balance)) > this_rq->next_balance = rq->next_balance; > } ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC] sched: nohz_idle_balance
On Thu, 2012-09-13 at 08:49 +0200, Mike Galbraith wrote: > On Thu, 2012-09-13 at 06:11 +0200, Vincent Guittot wrote: > > On tickless system, one CPU runs load balance for all idle CPUs. > > The cpu_load of this CPU is updated before starting the load balance > > of each other idle CPUs. We should instead update the cpu_load of the > > balance_cpu. > > > > Signed-off-by: Vincent Guittot > > --- > > kernel/sched/fair.c | 11 ++- > > 1 file changed, 6 insertions(+), 5 deletions(-) > > > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > > index 1ca4fe4..9ae3a5b 100644 > > --- a/kernel/sched/fair.c > > +++ b/kernel/sched/fair.c > > @@ -4794,14 +4794,15 @@ static void nohz_idle_balance(int this_cpu, enum > > cpu_idle_type idle) > > if (need_resched()) > > break; > > > > - raw_spin_lock_irq(&this_rq->lock); > > - update_rq_clock(this_rq); > > - update_idle_cpu_load(this_rq); > > - raw_spin_unlock_irq(&this_rq->lock); > > + rq = cpu_rq(balance_cpu); > > + > > + raw_spin_lock_irq(&rq->lock); > > + update_rq_clock(rq); > > + update_idle_cpu_load(rq); > > + raw_spin_unlock_irq(&rq->lock); > > > > rebalance_domains(balance_cpu, CPU_IDLE); > > > > - rq = cpu_rq(balance_cpu); > > if (time_after(this_rq->next_balance, rq->next_balance)) > > this_rq->next_balance = rq->next_balance; > > } > > Ew, banging locks and updating clocks to what good end? Well, updating the load statistics on the cpu you're going to balance seems like a good end to me.. ;-) No point updating the local statistics N times and leaving the ones you're going to balance stale for god knows how long. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC] sched: nohz_idle_balance
On Thu, 2012-09-13 at 06:11 +0200, Vincent Guittot wrote: > On tickless system, one CPU runs load balance for all idle CPUs. > The cpu_load of this CPU is updated before starting the load balance > of each other idle CPUs. We should instead update the cpu_load of the > balance_cpu. > > Signed-off-by: Vincent Guittot > --- > kernel/sched/fair.c | 11 ++- > 1 file changed, 6 insertions(+), 5 deletions(-) > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > index 1ca4fe4..9ae3a5b 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -4794,14 +4794,15 @@ static void nohz_idle_balance(int this_cpu, enum > cpu_idle_type idle) > if (need_resched()) > break; > > - raw_spin_lock_irq(&this_rq->lock); > - update_rq_clock(this_rq); > - update_idle_cpu_load(this_rq); > - raw_spin_unlock_irq(&this_rq->lock); > + rq = cpu_rq(balance_cpu); > + > + raw_spin_lock_irq(&rq->lock); > + update_rq_clock(rq); > + update_idle_cpu_load(rq); > + raw_spin_unlock_irq(&rq->lock); > > rebalance_domains(balance_cpu, CPU_IDLE); > > - rq = cpu_rq(balance_cpu); > if (time_after(this_rq->next_balance, rq->next_balance)) > this_rq->next_balance = rq->next_balance; > } Ew, banging locks and updating clocks to what good end? -Mike ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
