twitter: linux.kernel - 26 new messages in 19 topics

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

Today's topics:

* sonypi: Kill off the BKL in the ioctl - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/b73af831288843fc?hl=en
* libsrp: fix compile failure - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/9c651cd4589caaa5?hl=en
* Staging tree status for the .33 kernel merge - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/818bdf5c79b5bf8d?hl=en
* Module handling: Use this_cpu_xx to dynamically allocate counters - 3
messages, 2 authors
http://groups.google.com/group/linux.kernel/t/2bf6b597f491a7bc?hl=en
* drm: add KGDB/KDB support Add support for KDB entry/exit. - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/b1dbf9af709811a1?hl=en
* All kernels after 2.6.32-git10 show only 1 CPU ** NOT Fixed in 2.6.33-rc2
either ** - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/de8e3e045599a528?hl=en
* slab: initialize unused alien cache entry as NULL at alloc_alien_cache(). -
2 messages, 1 author
http://groups.google.com/group/linux.kernel/t/225b6b9dddc5ed96?hl=en
* mm: move sys_mmap_pgoff from util.c - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/cbe94a724d88cacd?hl=en
* amso1100/c2_provider.c: use %pM to shown MAC address - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/59ef38c32b3ad284?hl=en
* regulator: Specify REGULATOR_CHANGE_STATUS for WM835x LED constraints - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/b2c7eb1c4f8f292e?hl=en
* proc: Get/set timer slack through /proc - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/af10fc774c5aa078?hl=en
* Add DMI quirk for Intel DP55KG mainboard - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/4627647321ad6508?hl=en
* VLYNQ: add missing linux/irq.h include - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/638674bc9954568a?hl=en
* x86: use early_res instead of bootmem before slab - 2 messages, 1 author
http://groups.google.com/group/linux.kernel/t/1369931d05a2d13f?hl=en
* USB: serial: kfifo_len locking - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/24490aa50dc1af30?hl=en
* BUG(): CONFIG_BUG=n version of BUG() should be unreachable() - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/6f4f3db61541afd3?hl=en
* mfd: Correct WM835x ISINK ramp time defines - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/d13e1c2e9c19c9af?hl=en
* Regulator updates for 2.6.34 - 2 messages, 1 author
http://groups.google.com/group/linux.kernel/t/ed8accccf5e5a195?hl=en
* perf symbols: Generalise the kallsyms parsing routine - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/dd41f1530346f897?hl=en

==============================================================================
TOPIC: sonypi: Kill off the BKL in the ioctl
http://groups.google.com/group/linux.kernel/t/b73af831288843fc?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 4 2010 9:20 am
From: John Kacur

On Mon, Jan 4, 2010 at 5:21 PM, Alan Cox <alan@linux.intel.com> wrote:
> And another thats been ignored for several months
>
> --
>
> All the internal logic is protected properly by the existing mutex locking
>
> Signed-off-by: Alan Cox <alan@linux.intel.com>
> ---
>
> drivers/char/sonypi.c | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
>
> diff --git a/drivers/char/sonypi.c b/drivers/char/sonypi.c
> index 0798754..6a574bf 100644
> --- a/drivers/char/sonypi.c
> +++ b/drivers/char/sonypi.c
> @@ -955,8 +955,8 @@ static unsigned int sonypi_misc_poll(struct file *file, poll_table *wait)
> return 0;
> }
>
> -static int sonypi_misc_ioctl(struct inode *ip, struct file *fp,
> - unsigned int cmd, unsigned long arg)
> +static long sonypi_misc_ioctl(struct file *fp,
> + unsigned int cmd, unsigned long arg)
> {
> int ret = 0;
> void __user *argp = (void __user *)arg;
> @@ -1074,7 +1074,7 @@ static const struct file_operations sonypi_misc_fops = {
> .open = sonypi_misc_open,
> .release = sonypi_misc_release,
> .fasync = sonypi_misc_fasync,
> - .ioctl = sonypi_misc_ioctl,
> + .unlocked_ioctl = sonypi_misc_ioctl,
> };
>
> static struct miscdevice sonypi_misc_device = {
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>

I submitted this in October that would also remove the bkl from the
sonypi_misc_open function too.
http://lkml.indiana.edu/hypermail/linux/kernel/0910.2/01405.html

Thanks
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: libsrp: fix compile failure
http://groups.google.com/group/linux.kernel/t/9c651cd4589caaa5?hl=en
==============================================================================

== 1 of 2 ==
Date: Mon, Jan 4 2010 9:30 am
From: James Bottomley

On Mon, 2010-01-04 at 16:21 +0100, Jiri Kosina wrote:
> On Wed, 30 Dec 2009, Linus Torvalds wrote:
>
> > > The fix is simple, just add the include, but how did this happen? This
> > > change, introduced at -rc2, hardly looks like a bug fix, and it clearly
> > > didn't go through linux-next, which would have picked up this compile
> > > failure (it only occurs on ppc because of the ibm virtual scsi target).
> >
> > It came through Andrew - and apparently parts of Andrews chain weren't in
> > next. Don't know why.
>
> Uhm ... are they supposed to be? -mm is being built on top of -next, not
> vice versa, right?

Well, the fact that the compile failure wasn't detected before it went
upstream should answer that ...

But to be more specific: linux-next is our integration tree (and also
the obscure architecture compile tree). To ensure the best possible
integration, every tree should be built and tested in linux-next at
least once before it goes to Linus. There were originally technical
reasons why -mm wasn't in ... I just thought they'd been fixed by now.

James

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 2 of 2 ==
Date: Mon, Jan 4 2010 9:40 am
From: Alan Cox

> least once before it goes to Linus. There were originally technical
> reasons why -mm wasn't in ... I just thought they'd been fixed by now.

No - mm also caused problems with the kfifo merge of a core API change
that didn't go via -next.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: Staging tree status for the .33 kernel merge
http://groups.google.com/group/linux.kernel/t/818bdf5c79b5bf8d?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 4 2010 9:30 am
From: "Serge E. Hallyn"

Quoting Ashwin Ganti (ashwin.ganti@gmail.com):
> On Sun, Jan 3, 2010 at 10:57 PM, Serge E. Hallyn <serge@hallyn.com> wrote:
> > Quoting Greg KH (greg@kroah.com):
> > ...
> >> This means, unless someone steps up and starts doing real work (not
> >> trivial spelling fixes) on the following drivers, they will be removed
> >> in the future kernel releases.
> >>
> >> ?- arlan, netwave, strip, wavelan - wireless drivers mentioned above
> >> ? ?that are on the way out. ?Slated for removal in 2.6.35
> >> ?- hv - Microsoft Hyper V drivers. ?The developers again seem to have
> >> ? ?disappeared, this is getting old. Slated for removal in 2.6.35
> >> ?- p9auth - this will be removed in .34 unless someone steps up.
> >
> > I think I've decided to try to push it. ?I'm working with some patches
> > at git://git.kernel.org/pub/scm/linux/kernel/git/sergeh/linux-cr.git
> > (branch p9auth.jan3.4 is latest). ?I'll send patches as I feel they
> > are ready - so far they pass testcases, but are too new for me to
> > feel I should push them today.
>
> Thanks Serge!
>
> It is useful to continue to have this driver in the tree as there a
> few other people as well who have shown interest in using this. I have
> been recently contacted by guys at Glendix (http://www.glendix.org/)
> who have started looking at using this driver.
>
> >
> > Ashwin, I'm curious whether you'd think the last patch
> > (http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/sergeh/linux-cr.git;a=commitdiff;h=1662ba777140a39c21a9b647459d2deab8ffe1ca)
> > would be a problem with any userspace - but I assume there is no
> > legacy userspace to really worry about?
>
> There is no legacy user space support yet for Linux. This should be
> fine in that sense.
> I still need to look at the patches in detail though but what is the
> motivation for this change?

Well, to have a login daemon be unprivileged, it needs some way to
set groups without CAP_SETGID. I was playing with some toy frontend
and backend (i.e. login and factotum) code and this seemed a nice
simple way to do it.

> Please also cc rsc@swtch.com and ericvh@gmail.com as well when you
> send out these patches for review.

Will do, thanks.

> > Apart from plenty more cleanups, another more fundamental issue to
> > address is how to stop unused caphash entries from piling up in
> > memory. ?Put a timeout on them? ?Let privileged userspace list and
> > occasionally delete them? ?Associate a target task with each entry,
> > where either the task or its decendent can use the capability, but
> > if the task dies we free the caphash entry?
>
> So, there are a couple of options here (I favor the second approach):
> 1. We can add a timer to expire the capabilities.
> 2. Add a creation time stamp to every capability. Whenever a
> capability is used (i.e. written to /dev/caphash) we can go through
> the list in the kernel and reap the ones whose time stamp has expired.
> We can optimize the data structure later to make this faster.

Ok, I'll do that when I get a chance, do some more testing, and send
out in the next two weeks.

thanks,
-serge
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: Module handling: Use this_cpu_xx to dynamically allocate counters
http://groups.google.com/group/linux.kernel/t/2bf6b597f491a7bc?hl=en
==============================================================================

== 1 of 3 ==
Date: Mon, Jan 4 2010 9:30 am
From: Christoph Lameter

On Wed, 23 Dec 2009, Tejun Heo wrote:

> On 12/23/2009 12:57 AM, Christoph Lameter wrote:
> > On Mon, 21 Dec 2009, Tejun Heo wrote:
> >
> >>
> >>> Index: linux-2.6/kernel/trace/ring_buffer.c
> >>> ===================================================================
> >>> --- linux-2.6.orig/kernel/trace/ring_buffer.c 2009-12-18 13:13:24.000000000 -0600
> >>> +++ linux-2.6/kernel/trace/ring_buffer.c 2009-12-18 14:15:57.000000000 -0600
> >>> @@ -12,6 +12,7 @@
> >>> #include <linux/hardirq.h>
> >>> #include <linux/kmemcheck.h>
> >>> #include <linux/module.h>
> >>> +#include <asm/local.h>
> >>
> >> This doesn't belong to this patch, right? I stripped this part out,
> >> added Cc: to Rusty and applied 1, 2, 7 and 8 to percpu branch. I'll
> >> post the updated patch here. Thanks.
> >
> > If you strip this part out then ringbuffer.c will no longer compile
> > since it relies on the "#include <local.h>" that is removed by this patch
> > from the module.h file.
>
> Oh... alright. I'll add that comment and drop the offending chunk and
> recommit.

So we need a separate patch to deal with remval of the #include
<asm/local.h> from modules.h?

== 2 of 3 ==
Date: Mon, Jan 4 2010 9:30 am
From: Christoph Lameter

On Tue, 22 Dec 2009, Mathieu Desnoyers wrote:

> > > I am a bit concerned about the "generic" version of this_cpu_cmpxchg.
> > > Given that what LTTng needs is basically an atomic, nmi-safe version of
> > > the primitive (on all architectures that have something close to a NMI),
> > > this means that it could not switch over to your primitives until we add
> > > the equivalent support we currently have with local_t to all
> > > architectures. The transition would be faster if we create an
> > > atomic_cpu_*() variant which would map to local_t operations in the
> > > initial version.
> > >
> > > Or maybe have I missed something in your patchset that address this ?
> >
> > NMI safeness is not covered by this_cpu operations.
> >
> > We could add nmi_safe_.... ops?
> >
> > The atomic_cpu reference make me think that you want full (LOCK)
> > semantics? Then use the regular atomic ops?
>
> nmi_safe would probably make sense here.

I am not sure how to implement fallback for nmi_safe operations though
since there is no way of disabling NMIs.

> But given that we have to disable preemption to add precision in terms
> of trace clock timestamp, I wonder if we would really gain something
> considerable performance-wise.

Not sure what exactly you attempt to do there.

> I also thought about the design change this requires for the per-cpu
> buffer commit count pointer which would have to become a per-cpu pointer
> independent of the buffer structure, and I foresee a problem with
> Steven's irq off tracing which need to perform buffer exchanges while
> tracing is active. Basically, having only one top-level pointer for the
> buffer makes it possible to exchange it atomically, but if we have to
> have two separate pointers (one for per-cpu buffer, one for per-cpu
> commit count array), then we are stucked.

You just need to keep percpu pointers that are offsets into the percpu
area. They can be relocated as needed to the processor specific addresses
using the cpu ops.

> So given that per-cpu ops limits us in terms of data structure layout, I
> am less and less sure it's the best fit for ring buffers, especially if
> we don't gain much performance-wise.

I dont understand how exactly the ring buffer logic works and what you are
trying to do here.

The ringbuffers are per cpu structures right and you do not change cpus
while performing operations on them? If not then the per cpu ops are not
useful to you.

If you dont: How can you safely use the local_t operations for the
ringbuffer logic?

== 3 of 3 ==
Date: Mon, Jan 4 2010 10:00 am
From: Mathieu Desnoyers

* Christoph Lameter (cl@linux-foundation.org) wrote:
> On Wed, 23 Dec 2009, Tejun Heo wrote:
>
> > On 12/23/2009 12:57 AM, Christoph Lameter wrote:
> > > On Mon, 21 Dec 2009, Tejun Heo wrote:
> > >
> > >>
> > >>> Index: linux-2.6/kernel/trace/ring_buffer.c
> > >>> ===================================================================
> > >>> --- linux-2.6.orig/kernel/trace/ring_buffer.c 2009-12-18 13:13:24.000000000 -0600
> > >>> +++ linux-2.6/kernel/trace/ring_buffer.c 2009-12-18 14:15:57.000000000 -0600
> > >>> @@ -12,6 +12,7 @@
> > >>> #include <linux/hardirq.h>
> > >>> #include <linux/kmemcheck.h>
> > >>> #include <linux/module.h>
> > >>> +#include <asm/local.h>
> > >>
> > >> This doesn't belong to this patch, right? I stripped this part out,
> > >> added Cc: to Rusty and applied 1, 2, 7 and 8 to percpu branch. I'll
> > >> post the updated patch here. Thanks.
> > >
> > > If you strip this part out then ringbuffer.c will no longer compile
> > > since it relies on the "#include <local.h>" that is removed by this patch
> > > from the module.h file.
> >
> > Oh... alright. I'll add that comment and drop the offending chunk and
> > recommit.
>
> So we need a separate patch to deal with remval of the #include
> <asm/local.h> from modules.h?
>

I think this would make sense, yes. This would be a patch specific to
the ring-buffer code that would go through (or be acked by) Steven.

Mathieu

--
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: drm: add KGDB/KDB support Add support for KDB entry/exit.
http://groups.google.com/group/linux.kernel/t/b1dbf9af709811a1?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 4 2010 9:30 am
From: Jesse Barnes

Can you send this one over to Dave Airlie <airlied@linux.ie>? At KS he
indicated he'd be happy to just apply it, since other drivers will need
it too (along with the driver specific code of course).

Jesse

On Wed, 23 Dec 2009 15:43:00 -0600
Jason Wessel <jason.wessel@windriver.com> wrote:

> From: Jesse Barnes <jbarnes@virtuousgeek.org>
>
> ---
> drivers/gpu/drm/drm_fb_helper.c | 83
> ++++++++++++++++++++++++++++++ drivers/gpu/drm/i915/intel_display.c
> | 93 ++++++++++++++++++++++++++++++++++
> include/drm/drm_crtc_helper.h | 2 +
> include/drm/drm_fb_helper.h | 4 ++ 4 files changed, 182
> insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c
> b/drivers/gpu/drm/drm_fb_helper.c index 1b49fa0..80aab3c 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -29,6 +29,7 @@
> */
> #include <linux/sysrq.h>
> #include <linux/fb.h>
> +#include <linux/kgdb.h>
> #include "drmP.h"
> #include "drm_crtc.h"
> #include "drm_fb_helper.h"
> @@ -233,6 +234,84 @@ int drm_fb_helper_parse_command_line(struct
> drm_device *dev) return 0;
> }
>
> +#define to_fb_helper(ops) (container_of((ops), struct drm_fb_helper,
> kdb_ops)) +
> +static int drm_fb_kdb_enter(struct dbg_kms_console_ops *ops)
> +{
> + struct drm_fb_helper *helper = to_fb_helper(ops);
> + struct drm_crtc_helper_funcs *funcs;
> + int i;
> +
> + if (atomic_read(&kgdb_active))
> + goto out; /* already in KDB, don't reset mode */
> +
> + if (list_empty(&kernel_fb_helper_list))
> + return false;
> +
> + list_for_each_entry(helper, &kernel_fb_helper_list,
> kernel_fb_list) {
> + for (i = 0; i < helper->crtc_count; i++) {
> + struct drm_mode_set *mode_set =
> + &helper->crtc_info[i].mode_set;
> +
> + if (!mode_set->crtc->enabled)
> + continue;
> +
> + funcs =
> mode_set->crtc->helper_private;
> + funcs->mode_set_base_atomic(mode_set->crtc,
> + mode_set->fb,
> + mode_set->x,
> + mode_set->y);
> +
> + }
> + }
> +
> +out:
> + return 0;
> +}
> +
> +/* Find the real fb for a given fb helper CRTC */
> +static struct drm_framebuffer *drm_mode_config_fb(struct drm_crtc
> *crtc) +{
> + struct drm_device *dev = crtc->dev;
> + struct drm_crtc *c;
> +
> + list_for_each_entry(c, &dev->mode_config.crtc_list, head) {
> + if (crtc->base.id == c->base.id)
> + return c->fb;
> + }
> +
> + return NULL;
> +}
> +
> +static int drm_fb_kdb_exit(struct dbg_kms_console_ops *ops)
> +{
> + struct drm_fb_helper *helper = to_fb_helper(ops);
> + struct drm_crtc *crtc;
> + struct drm_crtc_helper_funcs *funcs;
> + struct drm_framebuffer *fb;
> + int i;
> +
> + for (i = 0; i < helper->crtc_count; i++) {
> + struct drm_mode_set *mode_set =
> &helper->crtc_info[i].mode_set;
> + crtc = mode_set->crtc;
> + funcs = crtc->helper_private;
> + fb = drm_mode_config_fb(crtc);
> +
> + if (!crtc->enabled)
> + continue;
> +
> + if (!fb) {
> + DRM_ERROR("no fb to restore??\n");
> + continue;
> + }
> +
> + funcs->mode_set_base_atomic(mode_set->crtc, fb,
> crtc->x,
> + crtc->y);
> + }
> +
> + return 0;
> +}
> +
> bool drm_fb_helper_force_kernel_mode(void)
> {
> int i = 0;
> @@ -924,6 +1003,9 @@ int drm_fb_helper_single_fb_probe(struct
> drm_device *dev, /* Switch back to kernel console on panic */
> /* multi card linked list maybe */
> if (list_empty(&kernel_fb_helper_list)) {
> + fb_helper->kdb_ops.activate_console =
> drm_fb_kdb_enter;
> + fb_helper->kdb_ops.restore_console = drm_fb_kdb_exit;
> + dbg_kms_console_ops_register(&fb_helper->kdb_ops);
> printk(KERN_INFO "registered panic notifier\n");
> atomic_notifier_chain_register(&panic_notifier_list,
> &paniced);
> @@ -938,6 +1020,7 @@ void drm_fb_helper_free(struct drm_fb_helper
> *helper) {
> list_del(&helper->kernel_fb_list);
> if (list_empty(&kernel_fb_helper_list)) {
> + dbg_kms_console_ops_unregister(&helper->kdb_ops);
> printk(KERN_INFO "unregistered panic notifier\n");
> atomic_notifier_chain_unregister(&panic_notifier_list,
> &paniced);
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c index 52cd9b0..e134a81 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -1234,6 +1234,98 @@ intel_pin_and_fence_fb_obj(struct drm_device
> *dev, struct drm_gem_object *obj) return 0;
> }
>
> +/* Assume fb object is pinned & idle & fenced and just update base
> pointers */ +static int
> +intel_pipe_set_base_atomic(struct drm_crtc *crtc, struct
> drm_framebuffer *fb,
> + int x, int y)
> +{
> + struct drm_device *dev = crtc->dev;
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> + struct intel_framebuffer *intel_fb;
> + struct drm_i915_gem_object *obj_priv;
> + struct drm_gem_object *obj;
> + int plane = intel_crtc->plane;
> + unsigned long Start, Offset;
> + int dspbase = (plane == 0 ? DSPAADDR : DSPBADDR);
> + int dspsurf = (plane == 0 ? DSPASURF : DSPBSURF);
> + int dspstride = (plane == 0) ? DSPASTRIDE : DSPBSTRIDE;
> + int dsptileoff = (plane == 0 ? DSPATILEOFF : DSPBTILEOFF);
> + int dspcntr_reg = (plane == 0) ? DSPACNTR : DSPBCNTR;
> + u32 dspcntr;
> +
> + switch (plane) {
> + case 0:
> + case 1:
> + break;
> + default:
> + DRM_ERROR("Can't update plane %d in SAREA\n", plane);
> + return -EINVAL;
> + }
> +
> + intel_fb = to_intel_framebuffer(fb);
> + obj = intel_fb->obj;
> + obj_priv = obj->driver_private;
> +
> + dspcntr = I915_READ(dspcntr_reg);
> + /* Mask out pixel format bits in case we change it */
> + dspcntr &= ~DISPPLANE_PIXFORMAT_MASK;
> + switch (fb->bits_per_pixel) {
> + case 8:
> + dspcntr |= DISPPLANE_8BPP;
> + break;
> + case 16:
> + if (fb->depth == 15)
> + dspcntr |= DISPPLANE_15_16BPP;
> + else
> + dspcntr |= DISPPLANE_16BPP;
> + break;
> + case 24:
> + case 32:
> + dspcntr |= DISPPLANE_32BPP_NO_ALPHA;
> + break;
> + default:
> + DRM_ERROR("Unknown color depth\n");
> + return -EINVAL;
> + }
> + if (IS_I965G(dev)) {
> + if (obj_priv->tiling_mode != I915_TILING_NONE)
> + dspcntr |= DISPPLANE_TILED;
> + else
> + dspcntr &= ~DISPPLANE_TILED;
> + }
> +
> + if (IS_IRONLAKE(dev))
> + /* must disable */
> + dspcntr |= DISPPLANE_TRICKLE_FEED_DISABLE;
> +
> + I915_WRITE(dspcntr_reg, dspcntr);
> +
> + Start = obj_priv->gtt_offset;
> + Offset = y * fb->pitch + x * (fb->bits_per_pixel / 8);
> +
> + DRM_DEBUG("Writing base %08lX %08lX %d %d\n", Start, Offset,
> x, y);
> + I915_WRITE(dspstride, fb->pitch);
> + if (IS_I965G(dev)) {
> + I915_WRITE(dspbase, Offset);
> + I915_READ(dspbase);
> + I915_WRITE(dspsurf, Start);
> + I915_READ(dspsurf);
> + I915_WRITE(dsptileoff, (y << 16) | x);
> + } else {
> + I915_WRITE(dspbase, Start + Offset);
> + I915_READ(dspbase);
> + }
> +
> + if ((IS_I965G(dev) || plane == 0))
> + intel_update_fbc(crtc, &crtc->mode);
> +
> + intel_wait_for_vblank(dev);
> + intel_increase_pllclock(crtc, true);
> +
> + return 0;
> +}
> +
> static int
> intel_pipe_set_base(struct drm_crtc *crtc, int x, int y,
> struct drm_framebuffer *old_fb)
> @@ -4243,6 +4335,7 @@ static const struct drm_crtc_helper_funcs
> intel_helper_funcs = { .mode_fixup = intel_crtc_mode_fixup,
> .mode_set = intel_crtc_mode_set,
> .mode_set_base = intel_pipe_set_base,
> + .mode_set_base_atomic = intel_pipe_set_base_atomic,
> .prepare = intel_crtc_prepare,
> .commit = intel_crtc_commit,
> .load_lut = intel_crtc_load_lut,
> diff --git a/include/drm/drm_crtc_helper.h
> b/include/drm/drm_crtc_helper.h index b29e201..4c12319 100644
> --- a/include/drm/drm_crtc_helper.h
> +++ b/include/drm/drm_crtc_helper.h
> @@ -61,6 +61,8 @@ struct drm_crtc_helper_funcs {
> /* Move the crtc on the current fb to the given position
> *optional* */ int (*mode_set_base)(struct drm_crtc *crtc, int x, int
> y, struct drm_framebuffer *old_fb);
> + int (*mode_set_base_atomic)(struct drm_crtc *crtc,
> + struct drm_framebuffer *fb, int
> x, int y);
> /* reload the current crtc LUT */
> void (*load_lut)(struct drm_crtc *crtc);
> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> index 58c892a..c4f87a5 100644
> --- a/include/drm/drm_fb_helper.h
> +++ b/include/drm/drm_fb_helper.h
> @@ -30,6 +30,8 @@
> #ifndef DRM_FB_HELPER_H
> #define DRM_FB_HELPER_H
>
> +#include <linux/kgdb.h>
> +
> struct drm_fb_helper_crtc {
> uint32_t crtc_id;
> struct drm_mode_set mode_set;
> @@ -63,8 +65,10 @@ struct drm_fb_helper_connector {
>
> struct drm_fb_helper {
> struct drm_framebuffer *fb;
> + struct drm_framebuffer *saved_fb;
> struct drm_device *dev;
> struct drm_display_mode *mode;
> + struct dbg_kms_console_ops kdb_ops;
> int crtc_count;
> struct drm_fb_helper_crtc *crtc_info;
> struct drm_fb_helper_funcs *funcs;

--
Jesse Barnes, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: All kernels after 2.6.32-git10 show only 1 CPU ** NOT Fixed in 2.6.33-
rc2 either **
http://groups.google.com/group/linux.kernel/t/de8e3e045599a528?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 4 2010 9:30 am
From: Sid Boyce

On 29/12/09 20:19, Len Brown wrote:
> On Mon, 28 Dec 2009, Sid Boyce wrote:
>
>> This dmesg is from a freshly built 2.6.32. The following do not appear
>> in later 2.6.32-git or 2.6.33-rc kernels.
>> # grep LAPIC /DMESG_2.6.32_tindog
>> ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
>> ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
>> ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] disabled)
>> ACPI: LAPIC (acpi_id[0x03] lapic_id[0x03] disabled)
>> ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
>> ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
>> ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
>> ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1]
>
> Right, your local apic is not found, ie this is missing
> in the 2.6.33 dmesg:
>
> ACPI: Local APIC address 0xfee00000
>
> Strange, as CONFIG_X86_LOCAL_APIC=y
>
> -Len
> Len Brown, Intel Open Source Technology Center
>
>

2.6.33-rc2-git5 booted and showed both CPU's on first boot, on
subsequent boots it hung at HDA irq 22 as it did on earlier kernels.
Regards
Sid.
--
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support
Specialist, Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks

==============================================================================
TOPIC: slab: initialize unused alien cache entry as NULL at alloc_alien_cache()
.
http://groups.google.com/group/linux.kernel/t/225b6b9dddc5ed96?hl=en
==============================================================================

== 1 of 2 ==
Date: Mon, Jan 4 2010 9:30 am
From: Christoph Lameter

On Wed, 23 Dec 2009, Haicheng Li wrote:

> > It should have been set up by the SRAT parser (modulo regressions)
> >
> > Haicheng, did you verify with printk it's really incorrect at this point?
>
> Yup. See below debug patch & Oops info.
>
> If we can make sure that SRAT parser must be able to detect out all possible
> node (even the node, cpu+mem, is not populated on the motherboard), it would
> be ACPI Parser issue or BIOS issue rather than a slab issue. In such case, I
> think this patch might become a workaround for buggy system board; and we
> might need to look into ACPI SRAT parser code as well:).

Right. Lets fix the SRAT / ACPI issue. Code elsewhere also dimensions
arrays to nr_node_ids.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 2 of 2 ==
Date: Mon, Jan 4 2010 9:30 am
From: Christoph Lameter

On Wed, 23 Dec 2009, Haicheng Li wrote:

> @@ -966,18 +966,16 @@ static void *alternate_node_alloc(struct kmem_cache *,
> gfp_t);
> static struct array_cache **alloc_alien_cache(int node, int limit, gfp_t gfp)
> {
> struct array_cache **ac_ptr;
> - int memsize = sizeof(void *) * nr_node_ids;
> + int memsize = sizeof(void *) * MAX_NUMNODES;
> int i;

Remove this change and I will ack the patch.

==============================================================================
TOPIC: mm: move sys_mmap_pgoff from util.c
http://groups.google.com/group/linux.kernel/t/cbe94a724d88cacd?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 4 2010 9:30 am
From: Hugh Dickins

On Mon, 4 Jan 2010, Eric B Munson wrote:
> On Wed, 30 Dec 2009, Hugh Dickins wrote:
>
> > Move sys_mmap_pgoff() from mm/util.c to mm/mmap.c and mm/nommu.c,
> > where we'd expect to find such code: especially now that it contains
> > the MAP_HUGETLB handling. Revert mm/util.c to how it was in 2.6.32.
> >
> > This patch just ignores MAP_HUGETLB in the nommu case, as in 2.6.32,
> > whereas 2.6.33-rc2 reported -ENOSYS. Perhaps validate_mmap_request()
> > should reject it with -EINVAL? Add that later if necessary.
> >
> > Signed-off-by: Hugh Dickins <hugh.dickins@tiscali.co.uk>
>
> I think that -ENOSYS is the correcet response in the nommu case, but
> I that can be added in a later patch.
>
> Acked-by: Eric B Munson <ebmunson@us.ibm.com>

Thanks. I had believed -ENOSYS was solely for unsupported system calls,
so thought it inappropriate here; but we seem to have quite a few places
which are using it indeed for "Function not implemented", and -EINVAL is
always so very overloaded that an alternative can be a lot more helpful.
Okay, I'll send a patch to give -ENOSYS for MAP_HUGETLB on nommu, which
will be consistent with mmu.

Hugh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: amso1100/c2_provider.c: use %pM to shown MAC address
http://groups.google.com/group/linux.kernel/t/59ef38c32b3ad284?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 4 2010 9:40 am
From: "H Hartley Sweeten"

Use the %pM kernel extension to display the MAC address.

Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Tom Tucker <tom@opengridcomputing.com>

---

David,

Can you please try the following patch to see if the 'fuzz' issue
is still present. I think my email client was stripping the last
empty line from the patch. Thanks.

diff --git a/drivers/infiniband/hw/amso1100/c2_provider.c b/drivers/infiniband/hw/amso1100/c2_provider.c
index ad723bd..712314a 100644
--- a/drivers/infiniband/hw/amso1100/c2_provider.c
+++ b/drivers/infiniband/hw/amso1100/c2_provider.c
@@ -760,10 +760,7 @@ static struct net_device *c2_pseudo_netdev_init(struct c2_dev *c2dev)
memcpy_fromio(netdev->dev_addr, c2dev->kva + C2_REGS_RDMA_ENADDR, 6);

/* Print out the MAC address */
- pr_debug("%s: MAC %02X:%02X:%02X:%02X:%02X:%02X\n",
- netdev->name,
- netdev->dev_addr[0], netdev->dev_addr[1], netdev->dev_addr[2],
- netdev->dev_addr[3], netdev->dev_addr[4], netdev->dev_addr[5]);
+ pr_debug("%s: MAC %pM\n", netdev->name, netdev->dev_addr);

#if 0
/* Disable network packets */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: regulator: Specify REGULATOR_CHANGE_STATUS for WM835x LED constraints
http://groups.google.com/group/linux.kernel/t/b2c7eb1c4f8f292e?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 4 2010 9:40 am
From: Liam Girdwood

On Mon, 2010-01-04 at 15:30 +0000, Mark Brown wrote:
> The WM8350 LED driver needs to be able to enable and disable the
> regulators it is using. Previously the core wasn't properly enforcing
> status change constraints so the driver was able to function but this
> has always been intended to be required.
>
> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
> Cc: stable@kernel.org
> ---
> drivers/regulator/wm8350-regulator.c | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/regulator/wm8350-regulator.c b/drivers/regulator/wm8350-regulator.c
> index 1bbff09..e7b89e7 100644
> --- a/drivers/regulator/wm8350-regulator.c
> +++ b/drivers/regulator/wm8350-regulator.c
> @@ -1504,7 +1504,8 @@ int wm8350_register_led(struct wm8350 *wm8350, int lednum, int dcdc, int isink,
> led->isink_init.consumer_supplies = &led->isink_consumer;
> led->isink_init.constraints.min_uA = 0;
> led->isink_init.constraints.max_uA = pdata->max_uA;
> - led->isink_init.constraints.valid_ops_mask = REGULATOR_CHANGE_CURRENT;
> + led->isink_init.constraints.valid_ops_mask
> + = REGULATOR_CHANGE_CURRENT | REGULATOR_CHANGE_STATUS;
> led->isink_init.constraints.valid_modes_mask = REGULATOR_MODE_NORMAL;
> ret = wm8350_register_regulator(wm8350, isink, &led->isink_init);
> if (ret != 0) {
> @@ -1517,6 +1518,7 @@ int wm8350_register_led(struct wm8350 *wm8350, int lednum, int dcdc, int isink,
> led->dcdc_init.num_consumer_supplies = 1;
> led->dcdc_init.consumer_supplies = &led->dcdc_consumer;
> led->dcdc_init.constraints.valid_modes_mask = REGULATOR_MODE_NORMAL;
> + led->dcdc_init.constraints.valid_ops_mask = REGULATOR_CHANGE_STATUS;
> ret = wm8350_register_regulator(wm8350, dcdc, &led->dcdc_init);
> if (ret != 0) {
> platform_device_put(pdev);

Applied.

Thanks

Liam

==============================================================================
TOPIC: proc: Get/set timer slack through /proc
http://groups.google.com/group/linux.kernel/t/af10fc774c5aa078?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 4 2010 9:40 am
From: "Smith, GeoffX"

On Friday, January 01, 2010, Arjan@infradead.org wrote:

>On Thu, 31 Dec 2009 13:01:49 -0800
>"Smith, GeoffX" <geoffx.smith@intel.com> wrote:
>
>> Subject: Get/set timer_slack_ns through /proc
>>
>> This patch makes the timer_slack_ns parameter accessible through
>> the /proc system.
>>
>> On 9/1/2008, arjan@linux.intel.com submitted a patch to allow a
>> process to set the timer slack value as part of the range timers
>> feature. Further, he noted that "Applications and admins can
>> override this [the timer slack value] via the prctl()."
>>
>> We have found this feature useful in attempting to reduce system
>> wakeups caused by timer interrupts. But we have also found that
>> while applications can set their own timer slack value, there is no
>> provision for setting the timer slack for another process -- prctl()
>> only operates on the current process.
>
>this statement is incorrect btw;
>timerslack is explicitly inherited over exec, so you can have (and we
>do have) a utility similar to the nice program, that launches an
>application with a specific timer slack.

Hmmm, that seems a lot less flexible, but I see how that would work.

Nonetheless, using "nice" as a model is that you would have to modify anything that launches applications, right? This would mean modifying /etc/init.d and application scripts, which seems beyond the scope of "admin". Or am I missing something?

==============================================================================
TOPIC: Add DMI quirk for Intel DP55KG mainboard
http://groups.google.com/group/linux.kernel/t/4627647321ad6508?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 4 2010 9:40 am
From: "H. Peter Anvin"

On 01/04/2010 09:15 AM, Len Brown wrote:
>
> I believe that Venki is sending a patch to make all recent
> motherboards use acpi reset by default; and I'd rather
> see that kind of patch than this one.
>
> I've had the patch below patch in acpi-test, and thus linus-next,
> and -mm since Nov 2008 to change the default for
> all systems w/ no issues.
>

Maybe I'm misremembering, but didn't we have to pull this patch after it
hit mainstream the last time?

-hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.

==============================================================================
TOPIC: VLYNQ: add missing linux/irq.h include
http://groups.google.com/group/linux.kernel/t/638674bc9954568a?hl=en
==============================================================================

== 1 of 2 ==
Date: Mon, Jan 4 2010 9:50 am
From: Florian Fainelli

This patch adds the missing linux/irq.h header
which will trigger compilation errors on non-AR7
platforms (i.e: TI Davinci).

Reported-by: Rohan Tabish <rohan_javed@yahoo.co.uk>
Signed-off-by: Regards, Florian Fainelli <florian@openwrt.org>
---
diff --git a/drivers/vlynq/vlynq.c b/drivers/vlynq/vlynq.c
index 9554ad5..14b1af9 100644
--- a/drivers/vlynq/vlynq.c
+++ b/drivers/vlynq/vlynq.c
@@ -30,6 +30,7 @@
#include <linux/interrupt.h>
#include <linux/delay.h>
#include <linux/io.h>
+#include <linux/irq.h>

#include <linux/vlynq.h>

--
1.6.3.3

== 2 of 2 ==
Date: Mon, Jan 4 2010 10:20 am
From: Christoph Hellwig

On Mon, Jan 04, 2010 at 06:38:51PM +0100, Florian Fainelli wrote:
> This patch adds the missing linux/irq.h header
> which will trigger compilation errors on non-AR7
> platforms (i.e: TI Davinci).

linux/irq.h should not be included by drivers. It's an internal handler
for the generic hardirq code. All functions for use by drivers are in
linux/interrupt.h

==============================================================================
TOPIC: x86: use early_res instead of bootmem before slab
http://groups.google.com/group/linux.kernel/t/1369931d05a2d13f?hl=en
==============================================================================

== 1 of 2 ==
Date: Mon, Jan 4 2010 9:50 am
From: Christoph Lameter

On Tue, 22 Dec 2009, Yinghai Lu wrote:

> From: "Yinghai Lu <yingai@kernrel.org>"
>
> please check the patches regarding with early_res and bootmem
>
> and at last it will make use early_res instead of bootmem with x86 64bits
>
> the first two are needed for some amd_bus.c/intel_bus.c cleaning up patches too.
> so put other x86/pci related into this series
> hope that is ok to Jesse.
>
> -v2: allocate vmemmap on one node together, and also seperate early_res

The point of this patchset is what?

Avoid use of bootmem altogether by x86 bootstrap? If so why?

== 2 of 2 ==
Date: Mon, Jan 4 2010 10:00 am
From: Christoph Lameter

So you want to allocate lots of memory from higher memory adresses?

==============================================================================
TOPIC: USB: serial: kfifo_len locking
http://groups.google.com/group/linux.kernel/t/24490aa50dc1af30?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 4 2010 9:50 am
From: Johan Hovold

Hi Stefani,

I noticed that the locking that used to protect kfifo_len in
usb_serial_generic_chars_in_buffer was removed when the kifo api changed
to not use internal locking (c1e13f25674ed564948ecb7dfe5f83e578892896 --
kfifo: move out spinlock).

Was this intentional?

I found a related discussion here

http://lkml.org/lkml/2009/12/18/433

where you seem to say that no such locking is required as long as
kfifo_reset is never called (and that one could use kfifo_reset_out
instead)?

However, kfifo_reset was still being called when the locking was removed
and not until later was it changed to kfifo_reset_out
(119eecc831a42bd090543568932e440c6831f1bb -- Fix usb_serial_probe()
problem introduced by the recent kfifo changes).

Does this last change imply that no locking in
usb_serial_generic_chars_in_buffer is required? If this is the case,
perhaps such locking guidelines could be added to kfifo.h?

Thanks,
Johan

==============================================================================
TOPIC: BUG(): CONFIG_BUG=n version of BUG() should be unreachable()
http://groups.google.com/group/linux.kernel/t/6f4f3db61541afd3?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 4 2010 10:10 am
From: David Daney

Arnd Bergmann wrote:
> On Wednesday 23 December 2009, David Daney wrote:
>> David Daney wrote:
>>
>> Well that may be too strong an objection, but I would really recommend
>> deeper consideration.
>>
>> If you use: #define BUG() __builtin_unreachable()
>>
>> which is what your patch does for GCC >= 4.5, it is truly undefined what
>> happens if it is ever reached. One typical thing that might happen is
>> that you start to try to execute data. It is unclear to me if it is
>> preferable in the kernel to do that, rather than loop endlessly. You
>> would likely achieve smaller code, but at what cost?
>
> That is exactly what I was about to reply at first as well, but the
> definition is BUG() is really "this should never happen". Normally,
> i.e. CONFIG_BUG=y, we will print a stack dump and kill the running
> task here. The case that Alexander is patching is for !CONFIG_BUG,
> where we intentionally remove the handling for the unexpected bug
> in order to reduce code size. This option is really just for people
> that want to squeeze out every possibly byte from the kernel object
> code, while everyone else just enables CONFIG_BUG.
>
> Currently, this is "do { } while (0)", which on old compilers is
> the best approximation of doing the right thing there, but may
> cause build warnings.
>
> __builtin_unreachable() is even better on gcc-4.5, because gcc may
> save a few more instructions and not print warnings any more. Getting
> into an undefined state here is not an issue, because if we get to
> a BUG() statement, the system state is already known to be broken
> and !CONFIG_BUG means we don't even try to to improve it any more.
>
> The alternative "do { } while (1)" is not ideal, because an
> endless loop still requires more code (typically one instruction)
> than doing nothing at all.
>

Well "do { } while (1)" is exactly the expansion of unreachable() for
GCC < 4.5. Since GCC-4.5 has not been released yet, most people will
get these extra looping instructions if you change BUG in this way.

You might also consider the discussions here:

http://marc.info/?l=linux-kernel&m=125296549116694&w=2

When I suggested a similar patch.

> If there are only than a handful of places that actually cause a warning,
> using "do { } while (0)" (or __builtin_unreachable where available) and
> fixing up the code using it might be better.
>
> Arnd
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: mfd: Correct WM835x ISINK ramp time defines
http://groups.google.com/group/linux.kernel/t/d13e1c2e9c19c9af?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 4 2010 10:10 am
From: Mark Brown

The constants used to specify ISINK ramp times for WM835x had the
wrong shifts so that the on times applied to the off ramp and vice
versa. The masks for the bitfields are correct.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: stable@kernel.org
---
include/linux/mfd/wm8350/pmic.h | 28 ++++++++++++++--------------
1 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/include/linux/mfd/wm8350/pmic.h b/include/linux/mfd/wm8350/pmic.h
index be3264e..e786fe9 100644
--- a/include/linux/mfd/wm8350/pmic.h
+++ b/include/linux/mfd/wm8350/pmic.h
@@ -666,20 +666,20 @@
#define WM8350_ISINK_FLASH_DUR_64MS (1 << 8)
#define WM8350_ISINK_FLASH_DUR_96MS (2 << 8)
#define WM8350_ISINK_FLASH_DUR_1024MS (3 << 8)
-#define WM8350_ISINK_FLASH_ON_INSTANT (0 << 4)
-#define WM8350_ISINK_FLASH_ON_0_25S (1 << 4)
-#define WM8350_ISINK_FLASH_ON_0_50S (2 << 4)
-#define WM8350_ISINK_FLASH_ON_1_00S (3 << 4)
-#define WM8350_ISINK_FLASH_ON_1_95S (1 << 4)
-#define WM8350_ISINK_FLASH_ON_3_91S (2 << 4)
-#define WM8350_ISINK_FLASH_ON_7_80S (3 << 4)
-#define WM8350_ISINK_FLASH_OFF_INSTANT (0 << 0)
-#define WM8350_ISINK_FLASH_OFF_0_25S (1 << 0)
-#define WM8350_ISINK_FLASH_OFF_0_50S (2 << 0)
-#define WM8350_ISINK_FLASH_OFF_1_00S (3 << 0)
-#define WM8350_ISINK_FLASH_OFF_1_95S (1 << 0)
-#define WM8350_ISINK_FLASH_OFF_3_91S (2 << 0)
-#define WM8350_ISINK_FLASH_OFF_7_80S (3 << 0)
+#define WM8350_ISINK_FLASH_ON_INSTANT (0 << 0)
+#define WM8350_ISINK_FLASH_ON_0_25S (1 << 0)
+#define WM8350_ISINK_FLASH_ON_0_50S (2 << 0)
+#define WM8350_ISINK_FLASH_ON_1_00S (3 << 0)
+#define WM8350_ISINK_FLASH_ON_1_95S (1 << 0)
+#define WM8350_ISINK_FLASH_ON_3_91S (2 << 0)
+#define WM8350_ISINK_FLASH_ON_7_80S (3 << 0)
+#define WM8350_ISINK_FLASH_OFF_INSTANT (0 << 4)
+#define WM8350_ISINK_FLASH_OFF_0_25S (1 << 4)
+#define WM8350_ISINK_FLASH_OFF_0_50S (2 << 4)
+#define WM8350_ISINK_FLASH_OFF_1_00S (3 << 4)
+#define WM8350_ISINK_FLASH_OFF_1_95S (1 << 4)
+#define WM8350_ISINK_FLASH_OFF_3_91S (2 << 4)
+#define WM8350_ISINK_FLASH_OFF_7_80S (3 << 4)

/*
* Regulator Interrupts.
--
1.6.5.7

==============================================================================
TOPIC: Regulator updates for 2.6.34
http://groups.google.com/group/linux.kernel/t/ed8accccf5e5a195?hl=en
==============================================================================

== 1 of 2 ==
Date: Mon, Jan 4 2010 10:20 am
From: Mark Brown

The following changes since commit 204f78ec75e6888bbf1a7b5a3ed0cbfff9bade27:
Tobias Klauser (1):
regulator/lp3971: Storage class should be before const qualifier

are available in the git repository at:

git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator-2.6.git for-lrg

A couple of new APIs, plus a use of one of them.

Mark Brown (3):
regulator: Add notifier event on regulator disable
regulator: Allow regulators to specify the time taken to ramp on enable
regulator: Implement enable_time() for WM835x ISINKs

drivers/regulator/core.c | 48 ++++++++++++++++++++++++++++-----
drivers/regulator/wm8350-regulator.c | 46 ++++++++++++++++++++++++++++++++
include/linux/regulator/consumer.h | 4 ++-
include/linux/regulator/driver.h | 6 ++++
4 files changed, 95 insertions(+), 9 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 2 of 2 ==
Date: Mon, Jan 4 2010 10:20 am
From: Mark Brown

The intended use case is for drivers which disable regulators to save
power but need to do some work to restore the hardware state when
restarting. If the supplies are not actually disabled due to board
limits or sharing with other active devices this notifier allows the
driver to avoid unneeded reinitialisation, particularly when used with
runtime PM.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
---
drivers/regulator/core.c | 7 +++++--
include/linux/regulator/consumer.h | 4 +++-
2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 686ef27..cce76a8 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1341,6 +1341,9 @@ static int _regulator_disable(struct regulator_dev *rdev)
__func__, rdev_get_name(rdev));
return ret;
}
+
+ _notifier_call_chain(rdev, REGULATOR_EVENT_DISABLE,
+ NULL);
}

/* decrease our supplies ref count and disable if required */
@@ -1399,8 +1402,8 @@ static int _regulator_force_disable(struct regulator_dev *rdev)
return ret;
}
/* notify other consumers that power has been forced off */
- _notifier_call_chain(rdev, REGULATOR_EVENT_FORCE_DISABLE,
- NULL);
+ _notifier_call_chain(rdev, REGULATOR_EVENT_FORCE_DISABLE |
+ REGULATOR_EVENT_DISABLE, NULL);
}

/* decrease our supplies ref count and disable if required */
diff --git a/include/linux/regulator/consumer.h b/include/linux/regulator/consumer.h
index 030d922..28c9fd0 100644
--- a/include/linux/regulator/consumer.h
+++ b/include/linux/regulator/consumer.h
@@ -89,8 +89,9 @@
* REGULATION_OUT Regulator output is out of regulation.
* FAIL Regulator output has failed.
* OVER_TEMP Regulator over temp.
- * FORCE_DISABLE Regulator shut down by software.
+ * FORCE_DISABLE Regulator forcibly shut down by software.
* VOLTAGE_CHANGE Regulator voltage changed.
+ * DISABLE Regulator was disabled.
*
* NOTE: These events can be OR'ed together when passed into handler.
*/
@@ -102,6 +103,7 @@
#define REGULATOR_EVENT_OVER_TEMP 0x10
#define REGULATOR_EVENT_FORCE_DISABLE 0x20
#define REGULATOR_EVENT_VOLTAGE_CHANGE 0x40
+#define REGULATOR_EVENT_DISABLE 0x80

struct regulator;

--
1.6.5.7

==============================================================================
TOPIC: perf symbols: Generalise the kallsyms parsing routine
http://groups.google.com/group/linux.kernel/t/dd41f1530346f897?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 4 2010 10:20 am
From: Arnaldo Carvalho de Melo

From: Arnaldo Carvalho de Melo <acme@redhat.com>

Will be used to find an specific symbol by name on 'perf record' to support
relocation reference symbols to support relocatable kernels.

Still have to conver the perf trace tools to use it instead of their current
reimplementation.

Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
tools/perf/util/symbol.c | 76 +++++++++++++++++++++++++++++----------------
tools/perf/util/symbol.h | 2 +
2 files changed, 51 insertions(+), 27 deletions(-)

diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index 79ca6a0..b9e0da5 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -383,16 +383,12 @@ size_t dso__fprintf(struct dso *self, enum map_type type, FILE *fp)
return ret;
}

-/*
- * Loads the function entries in /proc/kallsyms into kernel_map->dso,
- * so that we can in the next step set the symbol ->end address and then
- * call kernel_maps__split_kallsyms.
- */
-static int dso__load_all_kallsyms(struct dso *self, struct map *map)
+int kallsyms__parse(void *arg, int (*process_symbol)(void *arg, const char *name,
+ char type, u64 start))
{
char *line = NULL;
size_t n;
- struct rb_root *root = &self->symbols[map->type];
+ int err = 0;
FILE *file = fopen("/proc/kallsyms", "r");

if (file == NULL)
@@ -400,7 +396,6 @@ static int dso__load_all_kallsyms(struct dso *self, struct map *map)

while (!feof(file)) {
u64 start;
- struct symbol *sym;
int line_len, len;
char symbol_type;
char *symbol_name;
@@ -421,35 +416,62 @@ static int dso__load_all_kallsyms(struct dso *self, struct map *map)
continue;

symbol_type = toupper(line[len]);
- if (!symbol_type__is_a(symbol_type, map->type))
- continue;
-
symbol_name = line + len + 2;
- /*
- * Will fix up the end later, when we have all symbols sorted.
- */
- sym = symbol__new(start, 0, symbol_name);

- if (sym == NULL)
- goto out_delete_line;
- /*
- * We will pass the symbols to the filter later, in
- * map__split_kallsyms, when we have split the maps per module
- */
- symbols__insert(root, sym);
+ err = process_symbol(arg, symbol_name, symbol_type, start);
+ if (err)
+ break;
}

free(line);
fclose(file);
+ return err;

- return 0;
-
-out_delete_line:
- free(line);
out_failure:
return -1;
}

+struct process_kallsyms_args {
+ struct map *map;
+ struct dso *dso;
+};
+
+static int map__process_kallsym_symbol(void *arg, const char *name,
+ char type, u64 start)
+{
+ struct symbol *sym;
+ struct process_kallsyms_args *a = arg;
+ struct rb_root *root = &a->dso->symbols[a->map->type];
+
+ if (!symbol_type__is_a(type, a->map->type))
+ return 0;
+
+ /*
+ * Will fix up the end later, when we have all symbols sorted.
+ */
+ sym = symbol__new(start, 0, name);
+
+ if (sym == NULL)
+ return -ENOMEM;
+ /*
+ * We will pass the symbols to the filter later, in
+ * map__split_kallsyms, when we have split the maps per module
+ */
+ symbols__insert(root, sym);
+ return 0;
+}
+
+/*
+ * Loads the function entries in /proc/kallsyms into kernel_map->dso,
+ * so that we can in the next step set the symbol ->end address and then
+ * call kernel_maps__split_kallsyms.
+ */
+static int dso__load_all_kallsyms(struct dso *self, struct map *map)
+{
+ struct process_kallsyms_args args = { .map = map, .dso = self, };
+ return kallsyms__parse(&args, map__process_kallsym_symbol);
+}
+
/*
* Split the symbols into maps, making sure there are no overlaps, i.e. the
* kernel range is broken in several maps, named [kernel].N, as we don't have
diff --git a/tools/perf/util/symbol.h b/tools/perf/util/symbol.h
index f27e158..21313e8 100644
--- a/tools/perf/util/symbol.h
+++ b/tools/perf/util/symbol.h
@@ -135,6 +135,8 @@ int filename__read_build_id(const char *filename, void *bf, size_t size);
int sysfs__read_build_id(const char *filename, void *bf, size_t size);
bool dsos__read_build_ids(void);
int build_id__sprintf(u8 *self, int len, char *bf);
+int kallsyms__parse(void *arg, int (*process_symbol)(void *arg, const char *name,
+ char type, u64 start));

int symbol__init(void);
int perf_session__create_kernel_maps(struct perf_session *self);
--
1.6.2.5

==============================================================================

You received this message because you are subscribed to the Google Groups "linux.kernel"
group.

To post to this group, visit http://groups.google.com/group/linux.kernel?hl=en

To unsubscribe from this group, send email to linux.kernel+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/linux.kernel/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en

twitter

Monday, January 4, 2010

linux.kernel - 26 new messages in 19 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts