* Re: 2.6.38-rc2: Uhhuh. NMI received for unknown reason 2d on CPU 0.
From: Cyrill Gorcunov @ 2011-02-01 20:00 UTC (permalink / raw)
To: Don Zickus
Cc: George Spelvin, linux-kernel, Ingo Molnar, Peter Zijlstra,
Lin Ming, Stephane Eranian
In-Reply-To: <20110201185120.GD21209@redhat.com>
On 02/01/2011 09:51 PM, Don Zickus wrote:
...
>>
>> You mean it didn't help?
>
> Not that I noticed no.
>
> Cheers,
> Don
Thanks a huge for testing, Don! I'll check what else I can do.
--
Cyrill
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 7/7] ahci: work around bug with level interrupts
From: Aurelien Jarno @ 2011-02-01 19:58 UTC (permalink / raw)
To: Alexander Graf
Cc: Kevin Wolf, Joerg Roedel, qemu-devel Developers,
Sebastian Herbszt
In-Reply-To: <1296585301-15510-1-git-send-email-agraf@suse.de>
On Tue, Feb 01, 2011 at 07:35:01PM +0100, Alexander Graf wrote:
> When using level based interrupts, the interrupt is treated the same as an
> edge triggered one: leaving the line up does not retrigger the interrupt.
>
> In fact, when not lowering the line, we won't ever get a new interrupt inside
> the guest. So let's always retrigger an interrupt as soon as the OS ack'ed
> something on the device. This way we're sure the guest doesn't starve on
> interrupts until someone fixes the actual interrupt path.
>
> Signed-off-by: Alexander Graf <agraf@suse.de>
>
> ---
>
> v2 -> v3:
>
> - add comment about the interrupt hack
> ---
> hw/ide/ahci.c | 8 ++++++--
> 1 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c
> index 98bdf70..95e1cf7 100644
> --- a/hw/ide/ahci.c
> +++ b/hw/ide/ahci.c
> @@ -152,11 +152,15 @@ static void ahci_check_irq(AHCIState *s)
> }
> }
>
> + /* XXX We lower the interrupt line here because of a bug with interrupt
> + handling in Qemu. When leaving a line up, the interrupt does
> + not get retriggered automatically currently. Once that bug is fixed,
> + this workaround is not necessary anymore and we only need to lower
> + in the else branch. */
> + ahci_irq_lower(s, NULL);
> if (s->control_regs.irqstatus &&
> (s->control_regs.ghc & HOST_CTL_IRQ_EN)) {
> ahci_irq_raise(s, NULL);
> - } else {
> - ahci_irq_lower(s, NULL);
> }
> }
>
It's a lot better that way, however I think we should still keep the
correct code. Also given this problem only concerns the i386 target (ppc
code is actually a bit strange, but at the end does the correct thing),
it's something we should probably mention.
What about something like that?
diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c
index 671b4df..0b153f0 100644
--- a/hw/ide/ahci.c
+++ b/hw/ide/ahci.c
@@ -489,12 +489,25 @@ static void ahci_check_irq(AHCIState *s)
}
}
+#if 0
if (s->control_regs.irqstatus &&
(s->control_regs.ghc & HOST_CTL_IRQ_EN)) {
ahci_irq_raise(s, NULL);
} else {
ahci_irq_lower(s, NULL);
}
+#else
+ /* XXX We lower the interrupt line here because of a bug with interrupt
+ handling in Qemu on the i386 target. When leaving a line up, the
+ interrupt does not get retriggered automatically currently. Once
+ that bug is fixed, this workaround is not necessary anymore and
+ we only need to lower in the else branch. */
+ ahci_irq_lower(s, NULL);
+ if (s->control_regs.irqstatus &&
+ (s->control_regs.ghc & HOST_CTL_IRQ_EN)) {
+ ahci_irq_raise(s, NULL);
+ }
+#endif
}
static void ahci_trigger_irq(AHCIState *s, AHCIDevice *d,
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurelien@aurel32.net http://www.aurel32.net
^ permalink raw reply related
* [Patch RFC -RT ] Convert clocksource to High Res Timer
From: Will Schmidt @ 2011-02-01 19:59 UTC (permalink / raw)
To: LKML, Thomas Gleixner, john stultz; +Cc: pacman, Will Schmidt
Update the clocksource code to use (higher priority) high-res-timers
instead of a (lower priority) jiffies based timer.
This addresses some of the problems seen in Real-Time environments where
a high priority user-space application consumes CPU time such that the
TSC clocksource is starved and ultimately disabled due to "unstable
clocksource" conditions being met. Converting the clocksource code to
use hrtimers moves the dependence on lower priority softirqs to higher
priority hrtimers, allowing the clocksource better stability.
This patch has been tested against 2.6.33.7-rt* patch series.
Signed-off-by: Will Schmidt <will_schmidt@vnet.ibm.com>
CC: John Stultz <johnstul@us.ibm.com>
CC: Thomas Gleixner <tglx@linutronix.de>
CC: Paul Clarke <pacman@us.ibm.com>
--
diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c
index 0e98497..eb188a6 100644
--- a/kernel/time/clocksource.c
+++ b/kernel/time/clocksource.c
@@ -181,7 +181,7 @@ static void clocksource_watchdog_work(struct work_struct *work);
static LIST_HEAD(watchdog_list);
static struct clocksource *watchdog;
-static struct timer_list watchdog_timer;
+static struct hrtimer hr_watchdog_timer;
static DECLARE_WORK(watchdog_work, clocksource_watchdog_work);
static DEFINE_SPINLOCK(watchdog_lock);
static cycle_t watchdog_last;
@@ -195,6 +195,7 @@ static void __clocksource_change_rating(struct clocksource *cs, int rating);
*/
#define WATCHDOG_INTERVAL (HZ >> 1)
#define WATCHDOG_THRESHOLD (NSEC_PER_SEC >> 4)
+#define HR_WATCHDOG_INTERVAL (NSEC_PER_SEC/2)
static void clocksource_watchdog_work(struct work_struct *work)
{
@@ -242,8 +243,9 @@ void clocksource_mark_unstable(struct clocksource *cs)
spin_unlock_irqrestore(&watchdog_lock, flags);
}
-static void clocksource_watchdog(unsigned long data)
+static enum hrtimer_restart clocksource_watchdog(unsigned long data)
{
+ enum hrtimer_restart ret = HRTIMER_NORESTART;
struct clocksource *cs;
cycle_t csnow, wdnow;
int64_t wd_nsec, cs_nsec;
@@ -305,21 +307,26 @@ static void clocksource_watchdog(unsigned long data)
next_cpu = cpumask_next(raw_smp_processor_id(), cpu_online_mask);
if (next_cpu >= nr_cpu_ids)
next_cpu = cpumask_first(cpu_online_mask);
- watchdog_timer.expires += WATCHDOG_INTERVAL;
- add_timer_on(&watchdog_timer, next_cpu);
+ hrtimer_add_expires(&hr_watchdog_timer, ktime_set(0,HR_WATCHDOG_INTERVAL));
+ ret = HRTIMER_RESTART;
out:
spin_unlock(&watchdog_lock);
+ return ret;
}
static inline void clocksource_start_watchdog(void)
{
+ ktime_t delta;
+
if (watchdog_running || !watchdog || list_empty(&watchdog_list))
return;
- init_timer(&watchdog_timer);
- watchdog_timer.function = clocksource_watchdog;
+ hrtimer_init(&hr_watchdog_timer,
+ CLOCK_MONOTONIC, HRTIMER_MODE_ABS);
+ hr_watchdog_timer.function = clocksource_watchdog;
watchdog_last = watchdog->read(watchdog);
- watchdog_timer.expires = jiffies + WATCHDOG_INTERVAL;
- add_timer_on(&watchdog_timer, cpumask_first(cpu_online_mask));
+ delta = ktime_set(0, HR_WATCHDOG_INTERVAL);
+ hrtimer_start(&hr_watchdog_timer, ktime_add(
+ ktime_get(), delta), HRTIMER_MODE_ABS);
watchdog_running = 1;
}
@@ -327,7 +334,7 @@ static inline void clocksource_stop_watchdog(void)
{
if (!watchdog_running || (watchdog && !list_empty(&watchdog_list)))
return;
- del_timer(&watchdog_timer);
+ hrtimer_cancel(&hr_watchdog_timer);
watchdog_running = 0;
}
^ permalink raw reply related
* Re: [PATCH] sparc32: unaligned memory access (MNA) trap handler bug
From: Sam Ravnborg @ 2011-02-01 19:59 UTC (permalink / raw)
To: sparclinux
In-Reply-To: <1296583423-5469-1-git-send-email-daniel@gaisler.com>
On Tue, Feb 01, 2011 at 07:03:43PM +0100, Daniel Hellstrom wrote:
> Since the merge process of the sparc and sparc64 the sparc32
> MNA trap handler does not emulate stores to unaligned addresses
> correctly. MNA operation from both from kernel and user space
> are affected.
Well spotted!
This bug was actually introduced by:
f0e98c387e61de00646be31fab4c2fa0224e1efb "[SPARC]: Fix link errors with gcc-4.3"
I wanted to check if there were similar bugs introduced, but
this looks like a solo incident.
I grepped for "%1" in the other *.S files, no hits.
[Likewise for "%2", "%3", "%4"]
Patch looks good to me.
Reluctant with an "Acked-by" only because I do not feel confident
with the code in question. The change looks obviously correct.
I noticed you copied Greg on this. I guess you did so because you
consider this -stable material.
A better way to do so is to add:
Cc: <stable@kernel.org>
Then the stable team(s) will all be notified when this patch is applied
by Linus to mainline.
This is also a strong hint for David to apply this to sparc-2.6.git and not
sparc-next-2.6.git
But being explicit is always preferred.
Sam
^ permalink raw reply
* RE: [PATCH 3/4] nettime: Documentation
From: Aki Niemi @ 2011-02-01 19:58 UTC (permalink / raw)
To: ofono
In-Reply-To: <B668883EB5DD7144ADFC248A72176EA802DA147E@fioues07.ebgroup.elektrobit.com>
[-- Attachment #1: Type: text/plain, Size: 529 bytes --]
Hi Jeevaka,
On Tue, 2011-02-01 at 16:54 +0200, ext Jeevaka.Badrappan(a)elektrobit.com
wrote:
> > + int32 DST [optional]
> > + Current daylight saving setting in
> > + hours.
>
> few hours back I delivered a patch for converting the DST from hours to
> seconds in ofono driver code.
> are we going to take that into consideration?
Ah, well. Might as well then change the dst to be hours. Would you mind
resubmitting those patches, plus one that fixes struct
ofono_network_time as well?
Cheers,
Aki
^ permalink raw reply
* Re: [PATCH v2 2/6] KVM-HV: KVM Steal time implementation
From: Glauber Costa @ 2011-02-01 19:58 UTC (permalink / raw)
To: Avi Kivity
Cc: kvm, linux-kernel, aliguori, Rik van Riel, Jeremy Fitzhardinge,
Peter Zijlstra
In-Reply-To: <4D483E43.5060904@redhat.com>
On Tue, 2011-02-01 at 19:09 +0200, Avi Kivity wrote:
> On 02/01/2011 05:48 PM, Glauber Costa wrote:
> > > > @@ -2106,6 +2120,25 @@ void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
> > > > kvm_migrate_timers(vcpu);
> > > > vcpu->cpu = cpu;
> > > > }
> > > > +
> > > > + if (vcpu->arch.this_time_out) {
> > > > + u64 to = (get_kernel_ns() - vcpu->arch.this_time_out);
> > > > + /*
> > > > + * using nanoseconds introduces noise, which accumulates easily
> > > > + * leading to big steal time values. We want, however, to keep the
> > > > + * interface nanosecond-based for future-proofness.
> > > > + */
> > > > + to /= NSEC_PER_USEC;
> > > > + to *= NSEC_PER_USEC;
> > >
> > > Seems there is a real problem and that this is just papering it over.
> > > I'd like to understand the root cause.
> > Okay, my self-explanation seemed reasonable to me, but since both you
> > and Peter dislike it, I think it is important enough to get a more
> > thorough investigation before a second round.
>
> Yes please.
>
> > But in this case,
> > I keep that using nanoseconds may then not be the best approach here. We
> > also have to keep in mind that the host and guest clocks may be running
> > at different resolutions.
>
> We need to choose a resolution for the clock (or negotiate one), an
> nanoseconds seems as good as any from a range and precision
> considerations, and is convenient for the host and Linux guests. So why
> not pick it?
>
> > > > + vcpu->arch.sversion += 2;
> > >
> > > Doesn't survive live migration. You need to use the version from the
> > > guest area.
> > Why not? Who said versions need to always increase? If current version
> > is 102324, and we live migrate and it becomes 0, what is the problem?
>
> Guest reads version (result: 2)
> Guest starts reading data
> Live migration; vcpu->arch.sversion is zeroed
> Steal time update; vcpu->arch.sversion += 2; write to guest
> Guest continues reading data
> Guest reads version (result: 2)
>
> So the guest is unaware that an update has occurred while it was reading
> the data.
Ok, fair.
By the way, kvmclock have the same problem, then
>
^ permalink raw reply
* Re: Locking in the clk API, part 2: clk_prepare/clk_unprepare
From: Russell King - ARM Linux @ 2011-02-01 19:56 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Nicolas Pitre, Lorenzo Pieralisi, Saravana Kannan, linux-sh,
Ben Herrenschmidt, Sascha Hauer, Paul Mundt, linux-kernel,
Dima Zavin, Ben Dooks, Vincent Guittot, Jeremy Kerr,
linux-arm-kernel
In-Reply-To: <20110201193201.GH1147@pengutronix.de>
On Tue, Feb 01, 2011 at 08:32:01PM +0100, Uwe Kleine-König wrote:
> On Tue, Feb 01, 2011 at 05:06:37PM +0000, Russell King - ARM Linux wrote:
> > So? You're not _supposed_ to call it from any atomic context ever.
>
> My motivation for a more complicated clk_prepare was to make clk_prepare
> atomic when that's possible (i.e. when the clk is already prepared) and
> call it before the enable callback in clk_enable. Then everything
> behaves nicely even if clk_enable is called from atomic context provided
> that the clock was prepared before (or doesn't need to).
You really don't get the point of clk_prepare() do you. I'm not
going to bother trying to educate you anymore.
Hopefully someone with more patience can give you the necessary
teaching to make you understand.
^ permalink raw reply
* Locking in the clk API, part 2: clk_prepare/clk_unprepare
From: Russell King - ARM Linux @ 2011-02-01 19:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110201193201.GH1147@pengutronix.de>
On Tue, Feb 01, 2011 at 08:32:01PM +0100, Uwe Kleine-K?nig wrote:
> On Tue, Feb 01, 2011 at 05:06:37PM +0000, Russell King - ARM Linux wrote:
> > So? You're not _supposed_ to call it from any atomic context ever.
>
> My motivation for a more complicated clk_prepare was to make clk_prepare
> atomic when that's possible (i.e. when the clk is already prepared) and
> call it before the enable callback in clk_enable. Then everything
> behaves nicely even if clk_enable is called from atomic context provided
> that the clock was prepared before (or doesn't need to).
You really don't get the point of clk_prepare() do you. I'm not
going to bother trying to educate you anymore.
Hopefully someone with more patience can give you the necessary
teaching to make you understand.
^ permalink raw reply
* Re: Locking in the clk API, part 2: clk_prepare/clk_unprepare
From: Russell King - ARM Linux @ 2011-02-01 19:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110201193201.GH1147@pengutronix.de>
On Tue, Feb 01, 2011 at 08:32:01PM +0100, Uwe Kleine-König wrote:
> On Tue, Feb 01, 2011 at 05:06:37PM +0000, Russell King - ARM Linux wrote:
> > So? You're not _supposed_ to call it from any atomic context ever.
>
> My motivation for a more complicated clk_prepare was to make clk_prepare
> atomic when that's possible (i.e. when the clk is already prepared) and
> call it before the enable callback in clk_enable. Then everything
> behaves nicely even if clk_enable is called from atomic context provided
> that the clock was prepared before (or doesn't need to).
You really don't get the point of clk_prepare() do you. I'm not
going to bother trying to educate you anymore.
Hopefully someone with more patience can give you the necessary
teaching to make you understand.
^ permalink raw reply
* Re: [PATCH v2 5/6] KVM-GST: adjust scheduler cpu power
From: Glauber Costa @ 2011-02-01 19:55 UTC (permalink / raw)
To: Peter Zijlstra
Cc: kvm, linux-kernel, aliguori, Rik van Riel, Jeremy Fitzhardinge,
Avi Kivity
In-Reply-To: <1296586771.26581.298.camel@laptop>
On Tue, 2011-02-01 at 19:59 +0100, Peter Zijlstra wrote:
> On Tue, 2011-02-01 at 14:22 -0200, Glauber Costa wrote:
> >
> >
> > Which tick accounting? In your other e-mail , you pointed that this only
> > runs in touch_steal_time, which is fine, will change.
>
> That tick ;-), all the account_foo muck is per tick.
>
> > But all the rest
> > here, that is behind the hypervisor specific vs generic code has nothing
> > to do with ticks at all.
>
> But I don't get it, there is no generic code needed, all that's needed
> is u64 steal_time_clock(int cpu), and the first part of your
> kvm_account_steal_time() function is exactly that if you add the cpu
> argument.
>
> +static u64 steal_time_clock(int cpu)
> +{
> + u64 steal_time;
> + struct kvm_steal_time *src;
> + int version;
> +
> + preempt_disable();
> + src = &per_cpu_ptr(steal_time, cpu);
> + do {
> + version = src->version;
> + rmb();
> + steal_time = src->steal;
> + rmb();
> + } while ((src->version & 1) || (version != src->version));
> + preempt_enable();
> +
> + return steal_time
> +}
>
> And you're done.. no need to for any of that steal_time_{read,write} business.
update_rq_clock_task still have to keep track of what was the last steal
time value we saw, in the same way it does for irq. One option is to
call update_rq_clock_task from inside kvm-code, but I don't really like
it very much.
But okay, there are many ways to work around it, I'll cook something.
^ permalink raw reply
* Re: nbd / hot plug
From: Paul Clements @ 2011-02-01 19:55 UTC (permalink / raw)
To: Roberto Spadim; +Cc: Linux-RAID
In-Reply-To: <AANLkTi=NEgB_fJPfsK+36wUWZ_Kc_W23v15nT1Qz9iTP@mail.gmail.com>
On Sun, Jan 30, 2011 at 3:27 PM, Roberto Spadim <roberto@spadim.com.br> wrote:
> hi guys, i was thinking about nbd problems with server disconnection /
> client disconnection
> it's not like a SATA disk hot plug?
> for example unplug the disk (SATA) = unplug the network card
> could md raid work with it?
> i tried but i should run
> mdadm fail / remove / add
> to get nbd back in array, it's right?
Yes, nbd with md/raid works fine. If the nbd connection gets broken,
the nbd component of the array will fail, you can then remove it and
re-add it.
--
Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Nvidia 9500GT Xen VGA passthru
From: Pasi Kärkkäinen @ 2011-02-01 19:55 UTC (permalink / raw)
To: Anish Patel; +Cc: xen-devel, Peter van der Maas, xen-users
In-Reply-To: <4D485E69.3040707@gmail.com>
On Tue, Feb 01, 2011 at 02:26:33PM -0500, Anish Patel wrote:
> Hi All,
> I have managed to get the 2nd vga passed though. I had to use
> AMD/ATI card to get this done.
>
Nice!
Please post the details:
- VGA card model
- Xen version
- Dom0 kernel version
- DomU OS/version/kernel
- Any custom/additional patches used
-- Pasi
>
> Thanks
> Anish
>
> On 01/31/11 14:26, Pasi Kärkkäinen wrote:
>> On Mon, Jan 31, 2011 at 11:39:51AM -0500, Anish Patel wrote:
>>> I have this almost working now, I think the only thing that i need to
>>> change is to add a gfx_passthru=2 option to let xen know not to read
>>> from /dev/mem then an option to tell it what VGA rom to use. Are there
>>> any patches for 4.01 for this?
>>>
>> I think gfx_passthru can only use 0 or 1 nowadays.
>>
>> Patches probably need to be forward-ported to current Xen..
>> most of them are for xen-unstable from the Xen 3.5 days..
>>
>> -- Pasi
>>
>>> Thanks
>>> Anish
>>> On 01/31/11 06:50, Pasi Kärkkäinen wrote:
>>>> On Sun, Jan 30, 2011 at 12:42:56AM -0500, Peter van der Maas wrote:
>>>>> I really have not played with too much after the proof of concept. I do recall something eventually breaking the config, perhaps a Xen update. I've since put the hardware to better use, although I am still intrigued by Xen. At the time, I was working with a team that was giving serious consideration to virtualizing their platform, and what better way to learn than dig in and get my hands dirty.
>>>>>
>>>>> I tried to include as much detail at the time, with the plethora of different Xen builds, BIOS's updates, etc.
>>>>>
>>>>> If someone has something specific I can try to help, but doubtful I will be of any use. For example, I did not realize Xen 4.x was even released. Recent projects I've been working on do not lend themselves well to virtualization; however, I might have to give Xen 4.0 shot - just to play, of course. There were some serious changes happening with Xen, the Linux kernel, and KVM when I stopped playing.
>>>>>
>>>> Ok.
>>>>
>>>> I mainly meant if you remember what custom patches did you have to use/create?
>>>> Most probably you had to do some vBar=pBar hacking, right?
>>>>
>>>> I guess I'll have to try this myself one day and document the process
>>>> with current Xen versions..
>>>>
>>>> -- Pasi
>>>>
>>>>
>>>>> Sorry I could not be of more help.
>>>>>
>>>>> Peter van der Maas
>>>>> peter&pjv-c.com
>>>>>
>>>>> -----Original Message-----
>>>>> From: Pasi Kärkkäinen [mailto:pasik@iki.fi]
>>>>> Sent: Saturday, January 29, 2011 2:04 PM
>>>>> To: Peter van der Maas
>>>>> Cc: xen-users@lists.xensource.com; anish.mailing.list@gmail.com; xen-devel@lists.xensource.com
>>>>> Subject: Nvidia 9500GT Xen VGA passthru
>>>>>
>>>>>
>>>>> Hello Peter,
>>>>>
>>>>> Some people have been asking for tips about Nvidia Xen VGA passthru,
>>>>> so maybe you could help?
>>>>>
>>>>> Could you post the exact steps you did?
>>>>>
>>>>> Have you tried with Xen 4.0.x after your initial experiments in 2009?
>>>>>
>>>>> Thanks!
>>>>>
>>>>> -- Pasi
>>>>>
>>>>> On Mon, Jan 26, 2009 at 02:16:32PM -0500, Peter J. van der Maas wrote:
>>>>>> I am happy to announce that I have successfully (and finally!) been able
>>>>>> to pass a PCIe graphics card via VT-d to a Windows XP HVM DomU.
>>>>>>
>>>>>>
>>>>>>
>>>>>> About time!
>>>>>>
>>>>>>
>>>>>>
>>>>>> Config:
>>>>>>
>>>>>> -Intel Q6600 Core 2 Quad-Core, G0 stepping (I think)
>>>>>>
>>>>>> -Intel DQ35JO Motherboard, Q35 Chipset, BIOS v.991 (1/9/09), VT and VT-d
>>>>>> enabled
>>>>>>
>>>>>> -nVidia 9500GT (for VT-d passthrough - DomU)
>>>>>>
>>>>>> -nVidia GeForce2 MX200 (Dom0 console)
>>>>>>
>>>>>> -Xen (build: xen-unstable, recent as of ~ 1/25/09 1:00AM-EST)
>>>>>>
>>>>>> -Dom0: Linux-2.6.18.8-xen (via xen-unstable.hg)
>>>>>>
>>>>>> -DomU: Windows XP (pro, sp3, 32-bit)
>>>>>>
>>>>>>
>>>>>>
>>>>>> Once the VT-d bugs were recently corrected (thank you, xen-devel!),
>>>>>> everything went fairly smoothly. Still very buggy yet (its
>>>>>> xen-unstable!), but overall it works.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Make sure support for the PCI-backend is compiled into the kernel (not
>>>>>> just a module) and that you have your pciback.hide options in grub
>>>>>> (late-binding may work, but I haven't tried).
>>>>>>
>>>>>>
>>>>>>
>>>>>> Good luck!
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> -Peter van der Maas
>>>>>> _______________________________________________
>>>>>> Xen-users mailing list
>>>>>> Xen-users@lists.xensource.com
>>>>>> http://lists.xensource.com/xen-users
>
^ permalink raw reply
* [U-Boot] [PATCH 2/2] at91sam9261ek: make operational again
From: Reinhard Meyer @ 2011-02-01 19:54 UTC (permalink / raw)
To: u-boot
In-Reply-To: <4D47F99D.1080208@free.fr>
Dear all,
>> /home/toolchain/bin/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-ld -pie -r -o libat91.o lowlevel_init.o clock.o cpu.o reset.o timer.o
>> /home/toolchain/bin/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-ld: -r and -shared may not be used together
>>
>> I have tried this patch but this a problem releated to linking option. Do you have this problem?
>>
>> Michael
>
> Read up recent posts on the list: this was detected and is fixed in the
> master branch of the u-boot-arm repository.
I'll rebase u-boot-atmel on u-boot-arm/master then. Please rebase at91 related patches on
u-boot-atmel/rework then (my time permitting, that branch will exist somewhere tomorrow)
Best Regards,
Reinhard
^ permalink raw reply
* [Buildroot] [git commit master 1/1] Enable ccache for u-boot compile
From: Martin Hicks @ 2011-02-01 19:53 UTC (permalink / raw)
To: buildroot
commit: http://git.buildroot.net/buildroot/commit/?id=e3fb2ce122055fd34df7e1712700e5d72bdb40e4
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Just needed to pass in ccache as a prefix to the CROSS_TARGET variable.
Signed-off-by: Martin Hicks <mort@bork.org>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
boot/u-boot/u-boot.mk | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/boot/u-boot/u-boot.mk b/boot/u-boot/u-boot.mk
index d520bb8..2f890fa 100644
--- a/boot/u-boot/u-boot.mk
+++ b/boot/u-boot/u-boot.mk
@@ -130,7 +130,7 @@ $(U_BOOT_DIR)/$(U_BOOT_BIN): $(U_BOOT_DIR)/.header_modified
CFLAGS="$(TARGET_CFLAGS)" \
LDFLAGS="$(TARGET_LDFLAGS)" \
$(U_BOOT_CONFIGURE_OPTS) \
- $(MAKE) CROSS_COMPILE="$(TARGET_CROSS)" ARCH=$(U_BOOT_ARCH) \
+ $(MAKE) CROSS_COMPILE="$(CCACHE) $(TARGET_CROSS)" ARCH=$(U_BOOT_ARCH) \
$(U_BOOT_MAKE_OPT) -C $(U_BOOT_DIR)
# Copy the result to the images/ directory
--
1.7.3.4
^ permalink raw reply related
* [Buildroot] [git commit master 1/1] barebox: use ccache if enabled
From: Peter Korsgaard @ 2011-02-01 19:53 UTC (permalink / raw)
To: buildroot
commit: http://git.buildroot.net/buildroot/commit/?id=a7306b8aa5b51f7c6e9f5327e0bd80c11cfadda6
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
boot/barebox/barebox.mk | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/boot/barebox/barebox.mk b/boot/barebox/barebox.mk
index 3df424c..07266d9 100644
--- a/boot/barebox/barebox.mk
+++ b/boot/barebox/barebox.mk
@@ -19,7 +19,7 @@ else
BAREBOX_ARCH=$(KERNEL_ARCH)
endif
-BAREBOX_MAKE_FLAGS = ARCH=$(BAREBOX_ARCH) CROSS_COMPILE=$(TARGET_CROSS)
+BAREBOX_MAKE_FLAGS = ARCH=$(BAREBOX_ARCH) CROSS_COMPILE="$(CCACHE) $(TARGET_CROSS)"
$(DL_DIR)/$(BAREBOX_SOURCE):
$(call DOWNLOAD,$(BAREBOX_SITE),$(BAREBOX_SOURCE))
--
1.7.3.4
^ permalink raw reply related
* [Buildroot] [git commit master 1/1] Enable ccache for kernel compile
From: Martin Hicks @ 2011-02-01 19:53 UTC (permalink / raw)
To: buildroot
commit: http://git.buildroot.net/buildroot/commit/?id=d10e46fb7623673b590faac2a90dccea475a7e3e
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Just needed to pass in ccache as a prefix to the CROSS_TARGET variable.
Signed-off-by: Martin Hicks <mort@bork.org>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
linux/linux.mk | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/linux/linux.mk b/linux/linux.mk
index d3c06db..2bc2efe 100644
--- a/linux/linux.mk
+++ b/linux/linux.mk
@@ -23,7 +23,7 @@ LINUX26_MAKE_FLAGS = \
HOSTCFLAGS="$(HOSTCFLAGS)" \
ARCH=$(KERNEL_ARCH) \
INSTALL_MOD_PATH=$(TARGET_DIR) \
- CROSS_COMPILE=$(TARGET_CROSS) \
+ CROSS_COMPILE="$(CCACHE) $(TARGET_CROSS)" \
LZMA="$(LZMA)"
# Get the real Linux version, which tells us where kernel modules are
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH] virtio_blk: allow re-reading config space at runtime
From: Michael S. Tsirkin @ 2011-02-01 19:51 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Rusty Russell, linux-kernel
In-Reply-To: <20110201192156.GA20197@lst.de>
On Tue, Feb 01, 2011 at 08:21:56PM +0100, Christoph Hellwig wrote:
> On Tue, Feb 01, 2011 at 08:38:27PM +0200, Michael S. Tsirkin wrote:
> > Should not be hard to solve.
> > If it's running, it is ok to requeue. I don't remember offhand if it's
> > ok to requeue if it's queued but not running, if not we could have a
> > flag that signals that's the case.
>
> Looks like the workqueue infrastructure does indeed handle requing
> an pending work_struct, and we're free to reuse it from the point
> just before the callback is called.
>
> Does the version below look okay?
Yes, looks good to me. A couple of minor comments below
but they don't really matter. FWIW
Acked-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> From: Christoph Hellwig <hch@lst.de>
> Subject: [PATCH v2] virtio_blk: allow re-reading config space at runtime
>
> Wire up the virtio_driver config_changed method to get notified about
> config changes raised by the host. For now we just re-read the device
> size to support online resizing of devices, but once we add more
> attributes that might be changeable they could be added as well.
>
> Note that the config_changed method is called from irq context, so
> we'll have to use the workqueue infrastructure to provide us a proper
> user context for our changes.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
>
> Index: linux-2.6/drivers/block/virtio_blk.c
> ===================================================================
> --- linux-2.6.orig/drivers/block/virtio_blk.c 2010-12-01 09:30:59.647253809 -0700
> +++ linux-2.6/drivers/block/virtio_blk.c 2011-02-01 12:10:02.803164641 -0700
> @@ -6,10 +6,12 @@
> #include <linux/virtio.h>
> #include <linux/virtio_blk.h>
> #include <linux/scatterlist.h>
> +#include <linux/string_helpers.h>
>
> #define PART_BITS 4
>
> static int major, index;
> +struct workqueue_struct *virtblk_wq;
>
> struct virtio_blk
> {
> @@ -26,6 +28,9 @@ struct virtio_blk
>
> mempool_t *pool;
>
> + /* Process context for config space updates */
> + struct work_struct config_work;
> +
> /* What host tells us, plus 2 for header & tailer. */
> unsigned int sg_elems;
>
> @@ -291,6 +296,47 @@ static ssize_t virtblk_serial_show(struc
> }
> DEVICE_ATTR(serial, S_IRUGO, virtblk_serial_show, NULL);
>
> +static void virtblk_config_changed_work(struct work_struct *work)
> +{
> + struct virtio_blk *vblk =
> + container_of(work, struct virtio_blk, config_work);
> + struct virtio_device *vdev = vblk->vdev;
> + struct request_queue *q = vblk->disk->queue;
> + char cap_str_2[10], cap_str_10[10];
> + u64 capacity, size;
> +
> + /* Host must always specify the capacity. */
> + vdev->config->get(vdev, offsetof(struct virtio_blk_config, capacity),
> + &capacity, sizeof(capacity));
> +
> + /* If capacity is too big, truncate with warning. */
> + if ((sector_t)capacity != capacity) {
> + dev_warn(&vdev->dev, "Capacity %llu too large: truncating\n",
> + (unsigned long long)capacity);
> + capacity = (sector_t)-1;
One thing to note here is that we will get this warning
on each config change even if capacity is not updated.
Not sure whether it matters.
> + }
> +
> + size = capacity * queue_logical_block_size(q);
> + string_get_size(size, STRING_UNITS_2, cap_str_2, sizeof(cap_str_2));
> + string_get_size(size, STRING_UNITS_10, cap_str_10, sizeof(cap_str_10));
> +
> + dev_notice(&vdev->dev,
> + "new size: %llu %d-byte logical blocks (%s/%s)\n",
> + (unsigned long long)capacity,
> + queue_logical_block_size(q),
> + cap_str_10, cap_str_2);
> +
> + set_capacity(vblk->disk, capacity);
> +
empty line :)
> +}
> +
> +static void virtblk_config_changed(struct virtio_device *vdev)
> +{
> + struct virtio_blk *vblk = vdev->priv;
> +
> + queue_work(virtblk_wq, &vblk->config_work);
> +}
> +
> static int __devinit virtblk_probe(struct virtio_device *vdev)
> {
> struct virtio_blk *vblk;
> @@ -327,6 +373,7 @@ static int __devinit virtblk_probe(struc
> vblk->vdev = vdev;
> vblk->sg_elems = sg_elems;
> sg_init_table(vblk->sg, vblk->sg_elems);
> + INIT_WORK(&vblk->config_work, virtblk_config_changed_work);
>
> /* We expect one virtqueue, for output. */
> vblk->vq = virtio_find_single_vq(vdev, blk_done, "requests");
> @@ -477,6 +524,8 @@ static void __devexit virtblk_remove(str
> {
> struct virtio_blk *vblk = vdev->priv;
>
> + flush_work(&vblk->config_work);
> +
> /* Nothing should be pending. */
> BUG_ON(!list_empty(&vblk->reqs));
>
> @@ -508,27 +557,47 @@ static unsigned int features[] = {
> * Use __refdata to avoid this warning.
> */
> static struct virtio_driver __refdata virtio_blk = {
> - .feature_table = features,
> - .feature_table_size = ARRAY_SIZE(features),
> - .driver.name = KBUILD_MODNAME,
> - .driver.owner = THIS_MODULE,
> - .id_table = id_table,
> - .probe = virtblk_probe,
> - .remove = __devexit_p(virtblk_remove),
> + .feature_table = features,
> + .feature_table_size = ARRAY_SIZE(features),
> + .driver.name = KBUILD_MODNAME,
> + .driver.owner = THIS_MODULE,
> + .id_table = id_table,
> + .probe = virtblk_probe,
> + .remove = __devexit_p(virtblk_remove),
> + .config_changed = virtblk_config_changed,
> };
>
> static int __init init(void)
> {
> + int error;
> +
> + virtblk_wq = alloc_workqueue("md_misc", 0, 0);
What does md_misc stand for? Would virtblk_wq be a better name?
> + if (!virtblk_wq)
> + return -ENOMEM;
> +
> major = register_blkdev(0, "virtblk");
> - if (major < 0)
> - return major;
> - return register_virtio_driver(&virtio_blk);
> + if (major < 0) {
> + error = major;
> + goto out_destroy_workqueue;
> + }
> +
> + error = register_virtio_driver(&virtio_blk);
> + if (error)
> + goto out_unregister_blkdev;
> + return 0;
> +
> +out_unregister_blkdev:
> + unregister_blkdev(major, "virtblk");
> +out_destroy_workqueue:
> + destroy_workqueue(virtblk_wq);
> + return error;
> }
>
> static void __exit fini(void)
> {
> unregister_blkdev(major, "virtblk");
> unregister_virtio_driver(&virtio_blk);
> + destroy_workqueue(virtblk_wq);
> }
> module_init(init);
> module_exit(fini);
^ permalink raw reply
* [U-Boot] [PATCH] Introduce a new linker flag LDFLAGS_FINAL
From: Scott Wood @ 2011-02-01 19:51 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20110201193229.7C545B187@gemini.denx.de>
On Tue, 1 Feb 2011 20:32:29 +0100
Wolfgang Denk <wd@denx.de> wrote:
> Dear Scott Wood,
>
> In message <20110201102446.23b4a2e9@udp111988uds.am.freescale.net> you wrote:
> >
> > Prior to the introduction of LDFLAGS_u-boot, was LDFLAGS not what was
> > used? So before, anything that board/cpu code adds directly to LDFLAGS
> > (maybe they're supposed to use PLATFORM_LDFLAGS, but not all do) was
> > used in the final link. After 8aba9dc, only things in
> > PLATFORM_LDFLAGS plus -Bstatic and -T are used in the final link.
>
> And this is correct for all boards?
By "this" do you mean the switch to PLATFORM_LDFLAGS in 8aba9dc, or the
switch back to LDFLAGS? It's not obvious to me that the dropping of
board/cpu modifications to LDFLAGS except during partial link was an
intentional change, or a correct one for all boards.
The only case I see where it makes any difference at all is arch/i386,
which does LDFLAGS += --cref. From the description of --cref in the
linker manual, it probably actually belongs in LDFLAGS_FINAL, though
I'm not sure if it's harmless to include it in partial link or not.
Currently, with 8aba9dc, it's included *only* in partial link.
It's also not clear to me what this option has to do with i386... it
looks like an arch-neutral debugging feature that doesn't affect the
actual u-boot image at all (the output goes into the map file).
-Scott
^ permalink raw reply
* RE: [PATCH] leds-pca9532: Add gpio capability v3
From: H Hartley Sweeten @ 2011-02-01 19:48 UTC (permalink / raw)
To: Joachim Eastwood, linux-kernel@vger.kernel.org, rpurdie@rpsys.net,
riku.voipio@iki.fi
Cc: joachim.eastwood@jotron.com, w.sang@pengutronix.de
In-Reply-To: <AANLkTikqeq_fLSEvVc34Wum1nrf6BojyUp=JAe7m8Lby@mail.gmail.com>
On Tuesday, February 01, 2011 12:41 PM, Joachim Eastwood wrote:
> Hello,
>
> The patch below allows unused leds on pca9532 to be used as gpio. The
> board I am working on now has no less than 6 pca9532 chips. One chips
> is used for only leds, one has 14 leds and 2 gpio and the rest of the
> chips are gpio only.
>
> There is also one board in mainline which could use this capabilty;
> arch/arm/mach-iop32x/n2100.c
> 232 { .type = PCA9532_TYPE_NONE }, /* power OFF gpio */
> 233 { .type = PCA9532_TYPE_NONE }, /* reset gpio */
>
> This patch defines a new pin type, PCA9532_TYPE_GPIO, and registers a
> gpiochip if any pin has this type set. The gpio will registers all
> chip pins but will filter on gpio_request.
>
> Changes in v3:
> * Fixed direction_output funtion, thanks to H Hartley Sweeten
> * direction_input now calles set_value as direction_output
> * Instructions in Kconfig
>
> Tested on custom ARM board.
>
> -------------------------------------------------------------------
> [leds-pca9532] Add gpio capability
>
> Pins not used for leds can now be used as gpio by setting pin type as
> PCA9532_TYPE_GPIO and defining a gpio_base in platform data.
>
> Signed-off-by: Joachim Eastwood <joachim.eastwood@jotron.com>
> Reviewed-by: Wolfram Sang <w.sang@pengutronix.de>
Looks good.
Reviewed-by: H Hartley Sweeten <hsweeten@visionengravers.com>
^ permalink raw reply
* [PATCH] leds-pca9532: Add gpio capability v3
From: Joachim Eastwood @ 2011-02-01 19:40 UTC (permalink / raw)
To: linux-kernel, rpurdie, riku.voipio; +Cc: joachim.eastwood, w.sang, hartleys
Hello,
The patch below allows unused leds on pca9532 to be used as gpio. The
board I am working on now has no less than 6 pca9532 chips. One chips
is used for only leds, one has 14 leds and 2 gpio and the rest of the
chips are gpio only.
There is also one board in mainline which could use this capabilty;
arch/arm/mach-iop32x/n2100.c
232 { .type = PCA9532_TYPE_NONE }, /* power OFF gpio */
233 { .type = PCA9532_TYPE_NONE }, /* reset gpio */
This patch defines a new pin type, PCA9532_TYPE_GPIO, and registers a
gpiochip if any pin has this type set. The gpio will registers all
chip pins but will filter on gpio_request.
Changes in v3:
* Fixed direction_output funtion, thanks to H Hartley Sweeten
* direction_input now calles set_value as direction_output
* Instructions in Kconfig
Tested on custom ARM board.
-------------------------------------------------------------------
[leds-pca9532] Add gpio capability
Pins not used for leds can now be used as gpio by setting pin type as
PCA9532_TYPE_GPIO and defining a gpio_base in platform data.
Signed-off-by: Joachim Eastwood <joachim.eastwood@jotron.com>
Reviewed-by: Wolfram Sang <w.sang@pengutronix.de>
---
drivers/leds/Kconfig | 10 ++++
drivers/leds/leds-pca9532.c | 111 ++++++++++++++++++++++++++++++++++++++++-
include/linux/leds-pca9532.h | 3 +-
3 files changed, 120 insertions(+), 4 deletions(-)
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 6f190f4..525c517 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -152,6 +152,16 @@ config LEDS_PCA9532
LED controller. It is generally only useful
as a platform driver
+config LEDS_PCA9532_GPIO
+ bool "Enable GPIO support for PCA9532"
+ depends on LEDS_PCA9532
+ depends on GPIOLIB
+ help
+ Allow unused pins on PCA9532 to be used as gpio.
+
+ To use a pin as gpio pca9532_type in pca9532_platform data needs to
+ set to PCA9532_TYPE_GPIO.
+
config LEDS_GPIO
tristate "LED Support for GPIO connected LEDs"
depends on LEDS_CLASS
diff --git a/drivers/leds/leds-pca9532.c b/drivers/leds/leds-pca9532.c
index afac338..ad008bb 100644
--- a/drivers/leds/leds-pca9532.c
+++ b/drivers/leds/leds-pca9532.c
@@ -19,7 +19,9 @@
#include <linux/mutex.h>
#include <linux/workqueue.h>
#include <linux/leds-pca9532.h>
+#include <linux/gpio.h>
+#define PCA9532_REG_INPUT(i) ((i)/8)
#define PCA9532_REG_PSC(i) (0x2+(i)*2)
#define PCA9532_REG_PWM(i) (0x3+(i)*2)
#define PCA9532_REG_LS0 0x6
@@ -34,6 +36,7 @@ struct pca9532_data {
struct mutex update_lock;
struct input_dev *idev;
struct work_struct work;
+ struct gpio_chip gpio;
u8 pwm[2];
u8 psc[2];
};
@@ -200,16 +203,68 @@ static void pca9532_led_work(struct work_struct *work)
pca9532_setled(led);
}
-static void pca9532_destroy_devices(struct pca9532_data *data, int n_devs)
+#ifdef CONFIG_LEDS_PCA9532_GPIO
+static int pca9532_gpio_request_pin(struct gpio_chip *gc, unsigned offset)
+{
+ struct pca9532_data *data = container_of(gc, struct pca9532_data, gpio);
+ struct pca9532_led *led = &data->leds[offset];
+
+ if (led->type == PCA9532_TYPE_GPIO)
+ return 0;
+
+ return -EBUSY;
+}
+
+static void pca9532_gpio_set_value(struct gpio_chip *gc, unsigned
offset, int val)
+{
+ struct pca9532_data *data = container_of(gc, struct pca9532_data, gpio);
+ struct pca9532_led *led = &data->leds[offset];
+
+ if (val)
+ led->state = PCA9532_ON;
+ else
+ led->state = PCA9532_OFF;
+
+ pca9532_setled(led);
+}
+
+static int pca9532_gpio_get_value(struct gpio_chip *gc, unsigned offset)
+{
+ struct pca9532_data *data = container_of(gc, struct pca9532_data, gpio);
+ unsigned char reg;
+
+ reg = i2c_smbus_read_byte_data(data->client, PCA9532_REG_INPUT(offset));
+
+ return !!(reg & (1 << (offset % 8)));
+}
+
+static int pca9532_gpio_direction_input(struct gpio_chip *gc, unsigned offset)
+{
+ /* To use as input ensure pin is not driven */
+ pca9532_gpio_set_value(gc, offset, 0);
+
+ return 0;
+}
+
+static int pca9532_gpio_direction_output(struct gpio_chip *gc,
unsigned offset, int val)
+{
+ pca9532_gpio_set_value(gc, offset, val);
+
+ return 0;
+}
+#endif /* CONFIG_LEDS_PCA9532_GPIO */
+
+static int pca9532_destroy_devices(struct pca9532_data *data, int n_devs)
{
int i = n_devs;
if (!data)
- return;
+ return -EINVAL;
while (--i >= 0) {
switch (data->leds[i].type) {
case PCA9532_TYPE_NONE:
+ case PCA9532_TYPE_GPIO:
break;
case PCA9532_TYPE_LED:
led_classdev_unregister(&data->leds[i].ldev);
@@ -224,12 +279,26 @@ static void pca9532_destroy_devices(struct
pca9532_data *data, int n_devs)
break;
}
}
+
+#ifdef CONFIG_LEDS_PCA9532_GPIO
+ if (data->gpio.dev) {
+ int err = gpiochip_remove(&data->gpio);
+ if (err) {
+ dev_err(&data->client->dev, "%s failed, %d\n",
+ "gpiochip_remove()", err);
+ return err;
+ }
+ }
+#endif
+
+ return 0;
}
static int pca9532_configure(struct i2c_client *client,
struct pca9532_data *data, struct pca9532_platform_data *pdata)
{
int i, err = 0;
+ int gpios = 0;
for (i = 0; i < 2; i++) {
data->pwm[i] = pdata->pwm[i];
@@ -249,6 +318,9 @@ static int pca9532_configure(struct i2c_client *client,
switch (led->type) {
case PCA9532_TYPE_NONE:
break;
+ case PCA9532_TYPE_GPIO:
+ gpios++;
+ break;
case PCA9532_TYPE_LED:
led->state = pled->state;
led->name = pled->name;
@@ -297,6 +369,34 @@ static int pca9532_configure(struct i2c_client *client,
break;
}
}
+
+#ifdef CONFIG_LEDS_PCA9532_GPIO
+ if (gpios) {
+ data->gpio.label = "gpio-pca9532";
+ data->gpio.direction_input = pca9532_gpio_direction_input;
+ data->gpio.direction_output = pca9532_gpio_direction_output;
+ data->gpio.set = pca9532_gpio_set_value;
+ data->gpio.get = pca9532_gpio_get_value;
+ data->gpio.request = pca9532_gpio_request_pin;
+ data->gpio.can_sleep = 1;
+ data->gpio.base = pdata->gpio_base;
+ data->gpio.ngpio = 16;
+ data->gpio.dev = &client->dev;
+ data->gpio.owner = THIS_MODULE;
+
+ err = gpiochip_add(&data->gpio);
+ if (err) {
+ /* Use data->gpio.dev as a flag for freeing gpiochip */
+ data->gpio.dev = NULL;
+ dev_warn(&client->dev, "could not add gpiochip\n");
+ } else {
+ dev_info(&client->dev, "gpios %i...%i\n",
+ data->gpio.base, data->gpio.base +
+ data->gpio.ngpio - 1);
+ }
+ }
+#endif
+
return 0;
exit:
@@ -337,7 +437,12 @@ static int pca9532_probe(struct i2c_client *client,
static int pca9532_remove(struct i2c_client *client)
{
struct pca9532_data *data = i2c_get_clientdata(client);
- pca9532_destroy_devices(data, 16);
+ int err;
+
+ err = pca9532_destroy_devices(data, 16);
+ if (err)
+ return err;
+
kfree(data);
return 0;
}
diff --git a/include/linux/leds-pca9532.h b/include/linux/leds-pca9532.h
index f158eb1..b8d6fff 100644
--- a/include/linux/leds-pca9532.h
+++ b/include/linux/leds-pca9532.h
@@ -25,7 +25,7 @@ enum pca9532_state {
};
enum pca9532_type { PCA9532_TYPE_NONE, PCA9532_TYPE_LED,
- PCA9532_TYPE_N2100_BEEP };
+ PCA9532_TYPE_N2100_BEEP, PCA9532_TYPE_GPIO };
struct pca9532_led {
u8 id;
@@ -41,6 +41,7 @@ struct pca9532_platform_data {
struct pca9532_led leds[16];
u8 pwm[2];
u8 psc[2];
+ int gpio_base;
};
#endif /* __LINUX_PCA9532_H */
^ permalink raw reply related
* Re: How To Temporarily Suspend Network Traffic
From: Volkan YAZICI @ 2011-02-01 18:12 UTC (permalink / raw)
To: Rick Jones; +Cc: netdev
In-Reply-To: <4D4843B0.1090803@hp.com>
On Tue, 01 Feb 2011 09:32:32 -0800, Rick Jones writes:
> Out of not quite idle curiousity, what are you trying to accomplish?
I'm trying to implement a coarse-grained soft-TDMA (Time Division
Multiple Access) among devices in a Wi-Fi network. (Coarse-grained, that
is, compared to a hardware implementation.) Assuming that device clocks
are in sync via NTP, I will figure out the granularity I can achieve
with soft-TDMA.
> Instead of using tc to set a zero rate, you could perhaps try using tc
> to set a delay? If it doesn't offer microseconds of delay, pehaps
> setting a delay and then eliminating it after your own pause will do
> what you want - depends of course on what it is you really want.
Thanks for the advice. I'll check this out and see what I can do.
> Your saying you wanted microsecond granularity suggests you don't want
> to suspend traffic for very long?
I want to figure out the smallest delay that I can achieve in a periodic
manner. (E.g., freeze the traffic for 200us, continue without
interruption for 800us, and freeze the traffic again for another 200us,
etc.) Pay attention that, an undeterministic delay somewhere in between
1000us is not something I prefer, I must be able to determine the point
in time where delay will appear -- ofcourse, with some error margin.
Regards.
^ permalink raw reply
* RE: [RFC][PATCH] kmsg_dumper for NVRAM
From: Luck, Tony @ 2011-02-01 19:46 UTC (permalink / raw)
To: Américo Wang, Seiji Aguchi
Cc: rdunlap@xenotime.net, Yu, Fenghua, tglx@linutronix.de,
mingo@redhat.com, hpa@zytor.com, x86@kernel.org, tj@kernel.org,
akpm@linux-foundation.org, a.p.zijlstra@chello.nl, arnd@arndb.de,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-ia64@vger.kernel.org, dle-develop@lists.sourceforge.net,
shiyer@redhat.com, pjones@redhat.com, Satoru Moriya
In-Reply-To: <20110201092942.GD21239@cr0.nay.redhat.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1211 bytes --]
> This looks like what Tony wanted, pstore.
Yes - this looks like another means to the same end (making console log
Available after a crash).
I wonder whether you could use my pstore file system interface
for this ... you'd need to write a backend that used EFI variable
space to save the pieces of a console log, in much the same way
that I used ERST to stash the pieces.
This might be a bit messy - but I think that it would be
worth doing in order to provide a single user interface
to the kmsg_dump on different architectures, regardless
of the underlying storage method used. I.e. the OS
vendors would just have to write startup scripts to glean
information from /dev/pstore and clear it by removing the
files there. Rather than having one set of scripts that
looks at EFI variables for machines that use that, a different
set for machines that have the sparc64 method of saving in
some special area of ram, and yet another set for a machine
that has some other motherboard magical non volatile storage
that hasn't been designed yet.
-Tony
ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a¢f£¢·hšïêÿ‘êçz_è®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨èÚ&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥
^ permalink raw reply
* Re: [PATCH 1/2] security/selinux: fix /proc/sys/ labeling
From: Lucian Adrian Grijincu @ 2011-02-01 19:46 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Stephen Smalley, James Morris, Eric Paris, linux-kernel,
linux-security-module
In-Reply-To: <m1r5brr1mn.fsf@fess.ebiederm.org>
On Tue, Feb 1, 2011 at 9:33 PM, Eric W. Biederman <ebiederm@xmission.com> wrote:
> What kernel has a dentry_path_raw? Perhaps you mean __dentry_path?
See the function here:
https://github.com/mirrors/linux-2.6/blob/70d1f365568e0cdbc9f4ab92428e1830fdb09ab0/fs/dcache.c
The last patches were against 2.6.38-rc2 because the dcache layer got
rewritten in 2.6.38 http://lwn.net/Articles/421784/
__dentry_path is now static (in fs/dcache.c) and does not take the
necessary locks.
dentry_path_raw is __dentry_path with locks
ec2447c278ee973d35f38e53ca16ba7f965ae33d
hostfs: simplify locking
Remove dcache_lock locking from hostfs filesystem, and move it into dcache
helpers. All that is required is a coherent path name. Protection from
concurrent modification of the namespace after path name generation is not
provided in current code, because dcache_lock is dropped before the path is
used.
Signed-off-by: Nick Piggin <npiggin@kernel.dk>
--
.
..: Lucian
^ permalink raw reply
* RE: [RFC][PATCH] kmsg_dumper for NVRAM
From: Luck, Tony @ 2011-02-01 19:46 UTC (permalink / raw)
To: Américo Wang, Seiji Aguchi
Cc: rdunlap@xenotime.net, Yu, Fenghua, tglx@linutronix.de,
mingo@redhat.com, hpa@zytor.com, x86@kernel.org, tj@kernel.org,
akpm@linux-foundation.org, a.p.zijlstra@chello.nl, arnd@arndb.de,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-ia64@vger.kernel.org, dle-develop@lists.sourceforge.net,
shiyer@redhat.com, pjones@redhat.com, Satoru Moriya
In-Reply-To: <20110201092942.GD21239@cr0.nay.redhat.com>
> This looks like what Tony wanted, pstore.
Yes - this looks like another means to the same end (making console log
Available after a crash).
I wonder whether you could use my pstore file system interface
for this ... you'd need to write a backend that used EFI variable
space to save the pieces of a console log, in much the same way
that I used ERST to stash the pieces.
This might be a bit messy - but I think that it would be
worth doing in order to provide a single user interface
to the kmsg_dump on different architectures, regardless
of the underlying storage method used. I.e. the OS
vendors would just have to write startup scripts to glean
information from /dev/pstore and clear it by removing the
files there. Rather than having one set of scripts that
looks at EFI variables for machines that use that, a different
set for machines that have the sparc64 method of saving in
some special area of ram, and yet another set for a machine
that has some other motherboard magical non volatile storage
that hasn't been designed yet.
-Tony
ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þ&ºãø§¶\x17›¡Ü¨}©ž²Æ zÚ&j:+v‰¨þø\x1e¯ù\x1e®w¥þŠà2ŠÞ™¨èÚ&¢)ß¡«a¶Úÿÿûàz¿äz¹Þ—ú+ƒùšŽŠÝ¢jÿŠwèþ^[f
^ permalink raw reply
* [U-Boot] [PATCH 6/6] p1021mds: add QE and UEC support
From: Haiying Wang @ 2011-02-01 19:46 UTC (permalink / raw)
To: u-boot
In-Reply-To: <E9864516-6A8E-40DE-ABCA-06AE4690873C@kernel.crashing.org>
On Tue, 2011-02-01 at 13:15 -0600, Kumar Gala wrote:
> On Feb 1, 2011, at 11:01 AM, Haiying Wang wrote:
>
> > On Tue, 2011-02-01 at 10:50 -0600, Scott Wood wrote:
> >>>>
> >>> If it is a one time setting, there should be no problem to put it into
> >>> board code. But these pin settings need to be done before any usage of
> >>> phy read/write (accessing MDIO/MDC), and need to be released after the
> >>> usage of phy, thus the devices connected to eLBC like NAND flash/BCSR
> >>> can be accessed. If we use board code to set/release the pin, we don't
> >>> know when the phy access and nand flash access will happen.
> >>
> >> Is this actually a board issue or an SoC issue?
> >>
> > It is not a board issue. It is a SoC *feature*. Too many pins are muxed
> > on P1021. For this case, LBCTL of eLBC is muxed with QE's CE_PB[20]
> > which is used for MDIO signal.
> >
> > Haiying
> >
>
> But its a board decision on how they want to utilize those pins and for what feature.
Yes, you can say that. If the board doesn't have QE UCC ETH support at
all, we won't have to add such code in QE driver. But if there is QE UCC
ETH on board, we have no choice to decide which pins to use. We
definitely need to use CE_PB[20] for MDIO signal, there is no other GPIO
pins to use for QE's MDIO.
Haiying
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.