* [Bug 29833] radeon crashes kicad when using modeset
From: bugzilla-daemon @ 2010-10-08 8:25 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-29833-502@http.bugs.freedesktop.org/>
https://bugs.freedesktop.org/show_bug.cgi?id=29833
--- Comment #14 from Fabio Varesano <fabio.varesano@gmail.com> 2010-10-08 01:25:05 PDT ---
(In reply to comment #13)
> To see which mesa driver you are using try:
> glxinfo | grep OpenGL
[fabio@gamma ~]$ glxinfo | grep OpenGL
OpenGL vendor string: X.Org R300 Project
OpenGL renderer string: Gallium 0.4 on RV530
OpenGL version string: 2.1 Mesa 7.9
OpenGL shading language version string: 1.20
OpenGL extensions:
[fabio@gamma ~]$
Looks correct to me.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply
* Re: RFC: btusb firmware load help
From: Marcel Holtmann @ 2010-10-08 8:24 UTC (permalink / raw)
To: Bala Shanmugam
Cc: Shanmugamkamatchi Balashanmugam, Luis Rodriguez, Johannes Berg,
linux-bluetooth, linux-kernel@vger.kernel.org,
linux-wireless@vger.kernel.org, Deepak Dhamdhere, Sree Durbha
In-Reply-To: <4CADFE1E.1070708@atheros.com>
Hi Bala,
> >>>> Thanks Johannes. This would be better option to change PID in firmware
> >>>> as blacklisting 3002 might create problems for 3011 chipsets.
> >>>> Will try and let you people know.
> >>> The misbehaving 3002 needs to be blacklisted in btusb.c anyway. However
> >>> after loading the firmware to 3002 device, it should change its PID to
> >>> something else.
> >>>
> >>> I am still trying to figure out if this is one stage firmware loading or
> >>> a two stage firmware loading. This is all pretty unclear and nobody has
> >>> answered this clearly so far.
> >> eeprom based 3011 chips comes up with PID 3000 giving control to DFU
> >> driver [ath3k]. ath3k downloads the
> >> firmware changing PID to 3002. Now btusb gets control.
> >>
> >> In sflash based devices to reduce windows suspend/resume time we had a
> >> small firmware in flash which
> >> enables the device to get detected as Generic Bluetooth USB device with
> >> PID 3002. So control reaches btusb when device is plugged in, leaving
> >> no option for us to load the actual firmware.
> >>
> >> Solution would be to blacklist 3002 in btusb, enable ath3k to get
> >> control for both the devices, download the firmware and change PID to
> >> 3003 so that control with come to btusb.
> > so here is the thing that needs to be done.
> >
> > a) Get a firmware for PID 3000 devices that change the firmware to some
> > other PID. Since 3003 is already in use as well, using 3004 or later is
> > better approach.
> >
> > b) Blacklist PID 3002 in btusb.c.
> >
> > c) Handle special firmware loading case for PID 3002 sflash devices. If
> > firmware is loaded changed to 3005 or other.
> >
> > And as a general note, I prefer that the PID after loading firmware is
> > different if you don't happen to actually load the same firmware.
> >
> > So please sort out your USB PID assignment for Bluetooth in general.
> > This seems to be a mess that is not thought through properly.
> >
> >
> Thanks for your suggestion Marcel.
> Can't we have same PID[3004 or later] for both the devices after loading
> the firmware by ath3k?
> We need two different firmware if we plan to have two different PIDs for
> these two bluetooth devices.
if it loads the same firmware into the device, then it is just fine to
share a PID. If it loads different firmware, then I would propose
different PIDs.
So yes, you can use the PID since you wanna keep the firmware the same.
That is perfectly fine and reasonable.
Regards
Marcel
^ permalink raw reply
* [PATCH 2/2] kvm, MCE, Send SRAR SIGBUS directly
From: Huang Ying @ 2010-10-08 8:24 UTC (permalink / raw)
To: Avi Kivity, Marcelo Tosatti
Cc: kvm@vger.kernel.org, Andi Kleen, linux-kernel@vger.kernel.org,
Dean Nelson
Originally, SRAR SIGBUS is sent to QEMU-KVM via touching the poisoned
page. But commit 96054569190bdec375fe824e48ca1f4e3b53dd36 prevents the
signal from being sent. So now the signal is sent via
force_sig_info_fault directly.
Reported-by: Dean Nelson <dnelson@redhat.com>
Signed-off-by: Huang Ying <ying.huang@intel.com>
---
arch/x86/include/asm/signal.h | 3 +++
arch/x86/kvm/mmu.c | 15 +++------------
arch/x86/mm/fault.c | 6 +++---
3 files changed, 9 insertions(+), 15 deletions(-)
--- a/arch/x86/include/asm/signal.h
+++ b/arch/x86/include/asm/signal.h
@@ -258,6 +258,9 @@ struct pt_regs;
#define ptrace_signal_deliver(regs, cookie) do { } while (0)
+void force_sig_info_fault(int si_signo, int si_code, unsigned long address,
+ struct task_struct *tsk);
+
#endif /* __KERNEL__ */
#endif /* __ASSEMBLY__ */
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -158,9 +158,8 @@ is_prefetch(struct pt_regs *regs, unsign
return prefetch;
}
-static void
-force_sig_info_fault(int si_signo, int si_code, unsigned long address,
- struct task_struct *tsk)
+void force_sig_info_fault(int si_signo, int si_code, unsigned long address,
+ struct task_struct *tsk)
{
siginfo_t info;
@@ -172,6 +171,7 @@ force_sig_info_fault(int si_signo, int s
force_sig_info(si_signo, &info, tsk);
}
+EXPORT_SYMBOL_GPL(force_sig_info_fault);
DEFINE_SPINLOCK(pgd_lock);
LIST_HEAD(pgd_list);
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -39,6 +39,7 @@
#include <asm/cmpxchg.h>
#include <asm/io.h>
#include <asm/vmx.h>
+#include <asm/signal.h>
/*
* When setting this variable to true it enables Two-Dimensional-Paging
@@ -2104,22 +2105,12 @@ static int __direct_map(struct kvm_vcpu
return pt_write;
}
-static void kvm_send_hwpoison_signal(struct kvm *kvm, gfn_t gfn)
-{
- char buf[1];
- void __user *hva;
- int r;
-
- /* Touch the page, so send SIGBUS */
- hva = (void __user *)gfn_to_hva(kvm, gfn);
- r = copy_from_user(buf, hva, 1);
-}
-
static int kvm_handle_bad_page(struct kvm *kvm, gfn_t gfn, pfn_t pfn)
{
kvm_release_pfn_clean(pfn);
if (is_hwpoison_pfn(pfn)) {
- kvm_send_hwpoison_signal(kvm, gfn);
+ force_sig_info_fault(SIGBUS, BUS_MCEERR_AR,
+ gfn_to_hva(kvm, gfn), current);
return 0;
} else if (is_fault_pfn(pfn))
return -EFAULT;
^ permalink raw reply
* [PATCH 1/2] kvm, MCE, Add MCG_SER_P into KVM_MCE_CAP_SUPPORTED
From: Huang Ying @ 2010-10-08 8:24 UTC (permalink / raw)
To: Avi Kivity, Marcelo Tosatti
Cc: kvm@vger.kernel.org, Andi Kleen, Dean Nelson,
linux-kernel@vger.kernel.org
Now we have MCG_SER_P (and corresponding SRAO/SRAR MCE) support in
kernel and QEMU-KVM, the MCG_SER_P should be added into
KVM_MCE_CAP_SUPPORTED to make all these code really works.
Reported-by: Dean Nelson <dnelson@redhat.com>
Signed-off-by: Huang Ying <ying.huang@intel.com>
---
arch/x86/kvm/x86.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -71,7 +71,7 @@
#define CR8_RESERVED_BITS (~(unsigned long)X86_CR8_TPR)
#define KVM_MAX_MCE_BANKS 32
-#define KVM_MCE_CAP_SUPPORTED MCG_CTL_P
+#define KVM_MCE_CAP_SUPPORTED (MCG_CTL_P | MCG_SER_P)
/* EFER defaults:
* - enable syscall per default because its emulated by KVM
^ permalink raw reply
* Re: 2.6.35.6 fails to suspend (pxa2xx-mci.0)
From: Sven Neumann @ 2010-10-08 8:23 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Daniel Mack, Colin Cross, Greg Kroah-Hartman, linux-mmc,
linux-kernel, linux-arm-kernel
In-Reply-To: <201010072323.05218.rjw@sisk.pl>
On Thu, 2010-10-07 at 23:23 +0200, Rafael J. Wysocki wrote:
> > > I wonder what happens if you echo 0 to /sys/power/pm_async ?
> >
> > Nothing happens. The problem persists (tested with 2.6.36-rc7). What
> > would you expect to happen?
>
> Exactly that. :-)
>
> Commit 152e1d5920 should not affect the non-async case (I'd be surprised if
> it did really) and things should work with /sys/power/pm_async = 0 anyway.
>
> Please try check if you can reproduce with commt 152e1d5920 reverted and
> /sys/power/pm_async = 0. If you can, that's a driver bug.
Ok, for the record, here's what I tried. I have rebooted between tests
to make sure there's no state pulled in from the previous test:
2.6.36-rc7, no changes, pm_async 1 : suspend fails
2.6.36-rc7, no changes, pm_async 0 : suspend fails
2.6.36-rc7, 152e1d reverted, pm_async 1 : suspend works
2.6.36-rc7, 152e1d reverted, pm_async 0 : suspend fails
2.6.34.7, no changes, pm_async 1 : suspend works
2.6.34.7, no changes, pm_async 0 : suspend works
I am not sure how this should be interpreted.
Sven
^ permalink raw reply
* 2.6.35.6 fails to suspend (pxa2xx-mci.0)
From: Sven Neumann @ 2010-10-08 8:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201010072323.05218.rjw@sisk.pl>
On Thu, 2010-10-07 at 23:23 +0200, Rafael J. Wysocki wrote:
> > > I wonder what happens if you echo 0 to /sys/power/pm_async ?
> >
> > Nothing happens. The problem persists (tested with 2.6.36-rc7). What
> > would you expect to happen?
>
> Exactly that. :-)
>
> Commit 152e1d5920 should not affect the non-async case (I'd be surprised if
> it did really) and things should work with /sys/power/pm_async = 0 anyway.
>
> Please try check if you can reproduce with commt 152e1d5920 reverted and
> /sys/power/pm_async = 0. If you can, that's a driver bug.
Ok, for the record, here's what I tried. I have rebooted between tests
to make sure there's no state pulled in from the previous test:
2.6.36-rc7, no changes, pm_async 1 : suspend fails
2.6.36-rc7, no changes, pm_async 0 : suspend fails
2.6.36-rc7, 152e1d reverted, pm_async 1 : suspend works
2.6.36-rc7, 152e1d reverted, pm_async 0 : suspend fails
2.6.34.7, no changes, pm_async 1 : suspend works
2.6.34.7, no changes, pm_async 0 : suspend works
I am not sure how this should be interpreted.
Sven
^ permalink raw reply
* Re: Configuration of nestedhvm
From: Keir Fraser @ 2010-10-08 8:22 UTC (permalink / raw)
To: Dong, Eddie; +Cc: Xen-devel
In-Reply-To: <1A42CE6F5F474C41B63392A5F80372B22DBEA5AA@shsmsx501.ccr.corp.intel.com>
On 08/10/2010 08:56, "Dong, Eddie" <eddie.dong@intel.com> wrote:
>> What's the point when a per-domain config option is going to be
>> implemented? You can then simply not configure nestedhvm for a domain
>> you want to test without that capability? I suppose it makes your
>> second patch make a bit more sense than it would in total isolation.
>
> I want double-lock (AND) like other components such as IOMMU.
> If the global switch is off, even per domain configuration is turned on, the
> final effect is "OFF".
>
> The point here is to avoid manual mistake when the nested code is built in as
> formal release but targeting for pilot. Relying on HVM guest configuration
> only may cause the host crash or performance impact if the code has a bug and
> a guest enables nested virtualization feature.
>
> This switch is mainly for developer only at least for now.
Well, at least it should only be disallowing toolstack to set the per-domain
config option. Then it won't need to be accessed on every use of
is_nestedhvm(). So again it depends on that, mainly tool-side, patch.
-- Keir
^ permalink raw reply
* Re: [PATCH 15/18] fs: introduce a per-cpu last_ino allocator
From: Andi Kleen @ 2010-10-08 8:22 UTC (permalink / raw)
To: Dave Chinner; +Cc: linux-fsdevel, linux-kernel
In-Reply-To: <1286515292-15882-16-git-send-email-david@fromorbit.com>
Dave Chinner <david@fromorbit.com> writes:
> From: Eric Dumazet <eric.dumazet@gmail.com>
>
> new_inode() dirties a contended cache line to get increasing
> inode numbers. This limits performance on workloads that cause
> significant parallel inode allocation.
>
> Solve this problem by using a per_cpu variable fed by the shared
> last_ino in batches of 1024 allocations. This reduces contention on
> the shared last_ino, and give same spreading ino numbers than before
> (i.e. same wraparound after 2^32 allocations).
This doesn't help for Unix disk file systems, so not fully sure why you
need it for XFS.
But looks reasonable, although it would be better to simply fix
sockets/pipes/etc. to not allocate an inode numbers.
Acked-by: Andi Kleen <ak@linux.intel.com>
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply
* Re: introduce dm-snap-mv
From: Christoph Hellwig @ 2010-10-08 8:22 UTC (permalink / raw)
To: Daniel Phillips
Cc: Cong Meng, linux-fsdevel, linux-kernel, dm-devel, Andrew Morton,
Alexander Viro, Christoph Hellwig, Nick Piggin
In-Reply-To: <201010071431.14937.phillips@phunq.net>
On Thu, Oct 07, 2010 at 02:31:14PM -0700, Daniel Phillips wrote:
> Hi Meng,
>
> The patch looks sensible, however the question is: why do you want to
> do this? Would it not be better to generalize your metadata format to
> accomodate the device's native blocksize?
Even if it uses fixed 4k sectors it should just read them in smaller
chunks OR even better stop using buffer heads and just read them
manually using submit_bio. BHs really shouldn't be used outside of
filesystems, and even there they slowly are on their way out.
^ permalink raw reply
* Re: [lm-sensors] [PATCH] coretemp: fix reading of microcode revision
From: Jean Delvare @ 2010-10-08 8:22 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <4CADB0A1020000780001B335@vpn.id2.novell.com>
Hi Jan,
On Fri, 08 Oct 2010 08:05:21 +0100, Jan Beulich wrote:
> >>> On 07.10.10 at 20:46, Fenghua Yu <fenghua.yu@intel.com> wrote:
> > On Thu, Oct 07, 2010 at 02:36:01AM -0700, Jan Beulich wrote:
> >> @@ -327,8 +336,13 @@ static int __devinit coretemp_probe(stru
> >>
> >> if ((c->x86_model = 0xe) && (c->x86_mask < 0xc)) {
> >> /* check for microcode update */
> >> - rdmsr_on_cpu(data->id, MSR_IA32_UCODE_REV, &eax, &edx);
> >> - if (edx < 0x39) {
> >> + err = smp_call_function_single(data->id, get_ucode_rev_on_cpu,
> >> + &edx, 1);
> >> + if (err)
> >> + dev_warn(&pdev->dev,
> >> + "Cannot determine microcode revision "
> >> + "of the CPU!\n");
> >
> > When err, need to call dev_err and go to exit_free. This error handling
> > should
> > be same as edx < 0x39 case.
>
> Hmm, not sure - I'd prefer to consider the machine usable in this
> (theoretical only anyway) case.
I tend to prefer Fenghua's approach, sorry. If a bad microcode revision
is so wrong that we fail the probe when we see it, then a failure to
determine the microcode revision should lead to the same result. As
always, missing monitoring information is preferable to unreliable
monitoring information.
--
Jean Delvare
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply
* Re: [RFC] tidspbridge: use a parameter to allocate shared memory
From: Felipe Contreras @ 2010-10-08 8:20 UTC (permalink / raw)
To: Omar Ramirez Luna
Cc: Laurent Pinchart, linux-arm-kernel@lists.infradead.org,
Tony Lindgren, Ohad Ben-Cohen, Greg Kroah-Hartman, Russell King,
Gomez Castellanos, Ivan, Ramos Falcon, Ernesto,
linux-omap@vger.kernel.org, Ameya Palande
In-Reply-To: <4CAE1CA1.4050006@ti.com>
On Thu, Oct 7, 2010 at 10:16 PM, Omar Ramirez Luna <omar.ramirez@ti.com> wrote:
> On 10/7/2010 1:22 PM, Felipe Contreras wrote:
>> Anyway, we will not know for sure until we try... Right?
>
> yes we can try, at least we now for sure arm side can be done.
The only thing that changes is the cacheability of the ARM side
memory, so of course only the ARM side matters. The DSP side will
continue to do what it's doing and would not notice any difference if
the memory is flushed, or is non-cacheable.
--
Felipe Contreras
^ permalink raw reply
* [RFC] tidspbridge: use a parameter to allocate shared memory
From: Felipe Contreras @ 2010-10-08 8:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4CAE1CA1.4050006@ti.com>
On Thu, Oct 7, 2010 at 10:16 PM, Omar Ramirez Luna <omar.ramirez@ti.com> wrote:
> On 10/7/2010 1:22 PM, Felipe Contreras wrote:
>> Anyway, we will not know for sure until we try... Right?
>
> yes we can try, at least we now for sure arm side can be done.
The only thing that changes is the cacheability of the ARM side
memory, so of course only the ARM side matters. The DSP side will
continue to do what it's doing and would not notice any difference if
the memory is flushed, or is non-cacheable.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH 16/18] fs: Make iunique independent of inode_lock
From: Christoph Hellwig @ 2010-10-08 8:19 UTC (permalink / raw)
To: Dave Chinner; +Cc: Christoph Hellwig, linux-fsdevel, linux-kernel
In-Reply-To: <20101008080655.GY4681@dastard>
On Fri, Oct 08, 2010 at 07:06:55PM +1100, Dave Chinner wrote:
> On Fri, Oct 08, 2010 at 03:55:24AM -0400, Christoph Hellwig wrote:
> > > + hlist_bl_for_each_entry(inode, node, &b->head, i_hash) {
> > > + if (inode->i_ino == ino && inode->i_sb == sb) {
> >
> > wouldn't it be more natural to test the sb first here?
>
> Maybe, but I think an inode number match is less likely, so the
> order it currently does the check results in less code being
> executed on misses.
Ok, sounds fine.
^ permalink raw reply
* Re: [PATCH 01/18] kernel: add bl_list
From: Andi Kleen @ 2010-10-08 8:18 UTC (permalink / raw)
To: Dave Chinner; +Cc: linux-fsdevel, linux-kernel
In-Reply-To: <1286515292-15882-2-git-send-email-david@fromorbit.com>
Dave Chinner <david@fromorbit.com> writes:
> +static inline void __hlist_bl_del(struct hlist_bl_node *n)
> +{
> + struct hlist_bl_node *next = n->next;
> + struct hlist_bl_node **pprev = n->pprev;
> +
> + LIST_BL_BUG_ON((unsigned long)n & LIST_BL_LOCKMASK);
> +
> + /* pprev may be `first`, so be careful not to lose the lock bit */
> + *pprev = (struct hlist_bl_node *)
> + ((unsigned long)next |
> + ((unsigned long)*pprev & LIST_BL_LOCKMASK));
> + if (next)
> + next->pprev = pprev;
> +}
Should this set n->pprev to NULL so that unhashed returns true
afterwards?
> +
> +static inline void hlist_bl_del(struct hlist_bl_node *n)
> +{
> + __hlist_bl_del(n);
> + n->next = BL_LIST_POISON1;
> + n->pprev = BL_LIST_POISON2;
> +}
Ok so unhashed only works once. Seems unsymmetric.
Other than that looks good to me.
Reviewed-by: Andi Kleen <ak@linux.intel.com>
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply
* Re: [PATCH 14/18] fs: Protect inode->i_state with th einode->i_lock
From: Christoph Hellwig @ 2010-10-08 8:18 UTC (permalink / raw)
To: Dave Chinner; +Cc: Christoph Hellwig, linux-fsdevel, linux-kernel
In-Reply-To: <20101008080428.GW4681@dastard>
>
> Ah, done thinking now! I was so the i_state field had been set
> before the inode was added to various lists and potentially
> accessable to other threads. I should probably add a comment to that
> effect, right?
Yes, please.
^ permalink raw reply
* [PATCH v2] i.MX35: use the correct IIM register to get CPU revision
From: Eric Bénard @ 2010-10-08 8:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1286524957-30218-1-git-send-email-eric@eukrea.com>
instead of using ROM_SI_REV use IIM's Silicon Revision register
as described in :
- Reference Manual 29.3.3.10
- RM Errata 29.3.3.9.13
Signed-off-by: Eric B?nard <eric@eukrea.com>
---
v2 : fix wrong part of previous patch in plat-mxc/include/mach/mx35.h
arch/arm/mach-mx3/clock-imx35.c | 1 +
arch/arm/mach-mx3/cpu.c | 23 +++++++++--------------
arch/arm/plat-mxc/include/mach/mx35.h | 2 ++
3 files changed, 12 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-mx3/clock-imx35.c b/arch/arm/mach-mx3/clock-imx35.c
index 85884c7..f7cec59 100644
--- a/arch/arm/mach-mx3/clock-imx35.c
+++ b/arch/arm/mach-mx3/clock-imx35.c
@@ -535,6 +535,7 @@ int __init mx35_clocks_init()
__raw_writel(cgr2, CCM_BASE + CCM_CGR2);
__raw_writel(cgr3, CCM_BASE + CCM_CGR3);
+ clk_enable(&iim_clk);
mx35_read_cpu_rev();
mxc_timer_init(&gpt_clk,
diff --git a/arch/arm/mach-mx3/cpu.c b/arch/arm/mach-mx3/cpu.c
index db7af50..d00a754 100644
--- a/arch/arm/mach-mx3/cpu.c
+++ b/arch/arm/mach-mx3/cpu.c
@@ -59,31 +59,26 @@ void __init mx31_read_cpu_rev(void)
unsigned int mx35_cpu_rev;
EXPORT_SYMBOL(mx35_cpu_rev);
-#define MX35_ROM_SI_REV 0x40
-
void __init mx35_read_cpu_rev(void)
{
- void __iomem *rom = ioremap(MX35_IROM_BASE_ADDR, MX35_IROM_SIZE);
u32 rev;
char *srev = "unknown";
- if (!rom)
- return;
-
- rev = readl(rom + MX35_ROM_SI_REV);
+ rev = __raw_readl(MX35_IO_ADDRESS(MX35_IIM_BASE_ADDR + MXC_IIMSREV));
switch (rev) {
- case 0x1:
- mx35_cpu_rev = MX35_CHIP_REV_1_0;
+ case 0x00:
+ mx35_cpu_rev = MX3x_CHIP_REV_1_0;
srev = "1.0";
break;
- case 0x2:
- mx35_cpu_rev = MX35_CHIP_REV_2_0;
+ case 0x10:
+ mx35_cpu_rev = MX3x_CHIP_REV_2_0;
srev = "2.0";
break;
+ case 0x11:
+ mx35_cpu_rev = MX3x_CHIP_REV_2_1;
+ srev = "2.1";
+ break;
}
printk(KERN_INFO "CPU identified as i.MX35, silicon rev %s\n", srev);
-
- iounmap(rom);
}
-
diff --git a/arch/arm/plat-mxc/include/mach/mx35.h b/arch/arm/plat-mxc/include/mach/mx35.h
index 4a864c3..92794be 100644
--- a/arch/arm/plat-mxc/include/mach/mx35.h
+++ b/arch/arm/plat-mxc/include/mach/mx35.h
@@ -70,6 +70,8 @@
#define MX35_CAN1_BASE_ADDR (MX35_AIPS2_BASE_ADDR + 0xe4000)
#define MX35_CAN2_BASE_ADDR (MX35_AIPS2_BASE_ADDR + 0xe8000)
#define MX35_RTIC_BASE_ADDR (MX35_AIPS2_BASE_ADDR + 0xec000)
+#define MX35_IIM_BASE_ADDR (MX35_AIPS2_BASE_ADDR + 0xf0000)
+
#define MX35_OTG_BASE_ADDR 0x53ff4000
#define MX35_ROMP_BASE_ADDR 0x60000000
--
1.7.0.4
^ permalink raw reply related
* Re: [RFC] tidspbridge: use a parameter to allocate shared memory
From: Felipe Contreras @ 2010-10-08 8:18 UTC (permalink / raw)
To: Omar Ramirez Luna
Cc: Laurent Pinchart, linux-arm-kernel@lists.infradead.org,
Tony Lindgren, Ohad Ben-Cohen, Greg Kroah-Hartman, Russell King,
Gomez Castellanos, Ivan, Ramos Falcon, Ernesto,
linux-omap@vger.kernel.org, Ameya Palande
In-Reply-To: <4CAE1CA1.4050006@ti.com>
On Thu, Oct 7, 2010 at 10:16 PM, Omar Ramirez Luna <omar.ramirez@ti.com> wrote:
> On 10/7/2010 1:22 PM, Felipe Contreras wrote:
> ...
>>
>> Note that the "shared memory" described in the document you share has
>> nothing to do with the SHM pool. AFAIK that memory is used for other
>> things, like MMU PTEs, and storing the base image and socket-nodes,
>> thus it needs to be contiguous.
>
> hmmm, no. it is the same memory. i.e.: we propagate the current opp through
> the shared memory so the dsp can read it if it went to sleep, with the
> proper offset you can read that variable starting from the mempool base
> address.
The document mentions "shared memory" for buffer passing, normal
memory is used for that, scattered, even user-space memory, not the
SHM contiguous area.
>> I don't see any problem flushing the SHM area when needed, which
>> probably has performance implications when mmaping/unmapping buffers,
>> at which point you need to flush bigger memory areas anyway, so that's
>> not an issue.
>
> well, you would have to flush when loading the base image, or allocating a
> socket node, but also minor flushes for opp propagation, SHM messages to
> DSP, chnl params, those are the ones I can quickly think of.
All those happen when you send buffers to the DSP, and when you do
that you need to flush the buffer memory area, which is a much heavier
operation. Except maybe the opp propagation, but that would require at
most one page to be flushed, not a big deal I think, besides, it would
be better if that specific area is handled differently than the rest
of the SHM, so that we can allocate it with dma_alloc_coherent().
Cheers.
--
Felipe Contreras
^ permalink raw reply
* [RFC] tidspbridge: use a parameter to allocate shared memory
From: Felipe Contreras @ 2010-10-08 8:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4CAE1CA1.4050006@ti.com>
On Thu, Oct 7, 2010 at 10:16 PM, Omar Ramirez Luna <omar.ramirez@ti.com> wrote:
> On 10/7/2010 1:22 PM, Felipe Contreras wrote:
> ...
>>
>> Note that the "shared memory" described in the document you share has
>> nothing to do with the SHM pool. AFAIK that memory is used for other
>> things, like MMU PTEs, and storing the base image and socket-nodes,
>> thus it needs to be contiguous.
>
> hmmm, no. it is the same memory. i.e.: we propagate the current opp through
> the shared memory so the dsp can read it if it went to sleep, with the
> proper offset you can read that variable starting from the mempool base
> address.
The document mentions "shared memory" for buffer passing, normal
memory is used for that, scattered, even user-space memory, not the
SHM contiguous area.
>> I don't see any problem flushing the SHM area when needed, which
>> probably has performance implications when mmaping/unmapping buffers,
>> at which point you need to flush bigger memory areas anyway, so that's
>> not an issue.
>
> well, you would have to flush when loading the base image, or allocating a
> socket node, but also minor flushes for opp propagation, SHM messages to
> DSP, chnl params, those are the ones I can quickly think of.
All those happen when you send buffers to the DSP, and when you do
that you need to flush the buffer memory area, which is a much heavier
operation. Except maybe the opp propagation, but that would require at
most one page to be flushed, not a big deal I think, besides, it would
be better if that specific area is handled differently than the rest
of the SHM, so that we can allocate it with dma_alloc_coherent().
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH 13/18] fs: split locking of inode writeback and LRU lists
From: Christoph Hellwig @ 2010-10-08 8:18 UTC (permalink / raw)
To: Dave Chinner; +Cc: Christoph Hellwig, linux-fsdevel, linux-kernel
In-Reply-To: <20101008080018.GV4681@dastard>
On Fri, Oct 08, 2010 at 07:00:18PM +1100, Dave Chinner wrote:
> > >
> > > - if (inode->i_state & (I_NEW | I_WILL_FREE)) {
> > > + if (inode->i_state & (I_NEW | I_WILL_FREE | I_FREEING)) {
> > > requeue_io(inode);
> > > continue;
> > > }
> >
> > What does this have to do with the rest of the patch?
>
> That's because there's now a window between setting I_FREEING and taking
> the inode off the writeback list which means that we can see inodes
> in that state here. Generally it means that the code setting
> I_FREEING is spinning waiting for the wb->b_lock that this thread
> currently holds so it can be removed from the list.. Hence the requeue
> to move the inode out of the way and keep processing inodes for
> writeback.
That needs some documentation both in the changelog and in the code
I think.
^ permalink raw reply
* [U-Boot] [PATCH] smc91111: add write_hwaddr
From: Wolfgang Denk @ 2010-10-08 8:17 UTC (permalink / raw)
To: u-boot
In-Reply-To: <4CAEC4CD.6050705@wytron.com.tw>
Dear Thomas Chou,
In message <4CAEC4CD.6050705@wytron.com.tw> you wrote:
>
> The retransmission wait time on my first mail server is quite long and I
> forgot that there is postgrey on denx mail server, so I sent the patch
> again using another mail server. I wondered if my first mail server
> changed IP. Sorry for the noise.
No problem. It was informative for me, too, as I learned that we're
running postgrey. I didn't know that before.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The game of life is a game of boomerangs. Our thoughts, deeds and
words return to us sooner or later with astounding accuracy.
^ permalink raw reply
* [Buildroot] buildroot not support c++ compliing
From: olyvine.chen at logiways.com.cn @ 2010-10-08 8:17 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20101008091844.1afdb502@surf>
On Fri, 2010-10-08 at 09:18 +0200, Thomas Petazzoni wrote:
> Hello,
>
> On Fri, 08 Oct 2010 12:23:47 +0800
> "olyvine.chen at logiways.com.cn" <olyvine.chen@logiways.com.cn> wrote:
>
> > I now try to add package libmusicbrainz to buildroot, but many
> > errors happen, such as the following:
> >
> > *************************************************************************
> >
> > buildroot/output/build/libmusicbrainz-3.0.2/src/artist.cpp:23:18:
> > error: string: No such file or directory
> >
> > *************************************************************************
> > it seems indicate that no c++ library available, then how to enable
> > c ++ compiling for buildroot?
> >
> > I enabled glibc via:
> > Toolchain => Toolchain type (External toolchain) => External
> > toolchain C library (glibc)
>
> Which external toolchain are you using ?
>
> Thomas
STLinux's sh4-linux-
--
Kindest regards !
====================================
Olyvine Chen, Logiways Shenzhen
http://www.logiways.com
====================================
^ permalink raw reply
* Re: [Xenomai-help] kernel oopses when killing realtime task
From: Philippe Gerum @ 2010-10-08 8:17 UTC (permalink / raw)
To: Pavel Machek; +Cc: Jan Kiszka, xenomai
In-Reply-To: <20101008070148.GB2255@domain.hid>
On Fri, 2010-10-08 at 09:01 +0200, Pavel Machek wrote:
> Hi!
>
> > > I have... quite an interesting setup here.
> > >
> > > SMP machine, with special PCI card; that card has GPIOs and serial
> > > ports. Unfortunately, there's only one interrupt, shared between
> > > serials and GPIO pins, and serials are way too complex to be handled
> > > by realtime layer.
> > >
> > > So I ended up with
> > >
> > > // we also have an interrupt handler:
> > > ret = rtdm_irq_request(&my_context->irq_handle,
> > > gpio_rt_config.irq, demo_interrupt,
> > > RTDM_IRQTYPE_SHARED,
> > > context->device->proc_name, my_context);
> > >
> > > and
> > >
> > > static int demo_interrupt(rtdm_irq_t *irq_context)
> > > {
> > > struct demodrv_context *ctx;
> > > int dev_id;
> > > int ret = RTDM_IRQ_HANDLED; // usual return value
> > > unsigned pending, output;
> > >
> > > ctx = rtdm_irq_get_arg(irq_context, struct demodrv_context);
> > > dev_id = ctx->dev_id;
> > >
> > > if (!ctx->ready) {
> > > printk(KERN_CRIT "Unexpected interrupt\n");
> > > return XN_ISR_PROPAGATE;
> >
> > Who sets ready and when? Looks racy.
>
> Debugging aid; yes, this one is racy.
>
> > > rtdm_lock_put(&ctx->lock);
> > >
> > > /* We need to propagate the interrupt, so that PMC-6L serials
> > > work. Result is that interrupt latencies can't be
> > > guaranteed when serials are in use. */
> > >
> > > return RTDM_IRQ_HANDLED;
> > > }
> > >
> > > Unregistration is:
> > > my_context->ready = 0;
> > > rtdm_irq_disable(&my_context->irq_handle);
> >
> > Where is rtdm_irq_free? Again, this ready flag looks racy.
>
> Aha, sorry, I quoted wrong snippet. rtdm_irq_free() follows
> immediately, like this:
>
> int demo_close_rt(struct rtdm_dev_context *context,
> rtdm_user_info_t *user_info)
> {
> struct demodrv_context *my_context;
> rtdm_lockctx_t lock_ctx;
> // get the context
> my_context = (struct demodrv_context *)context->dev_private;
>
> // if we need to do some stuff with preemption disabled:
> rtdm_lock_get_irqsave(&my_context->lock, lock_ctx);
>
> my_context->ready = 0;
> rtdm_irq_disable(&my_context->irq_handle);
>
>
> // free irq in RTDM
> rtdm_irq_free(&my_context->irq_handle);
>
> // destroy our interrupt signal/event
> rtdm_event_destroy(&my_context->irq_event);
>
> // other stuff here
> rtdm_lock_put_irqrestore(&my_context->lock, lock_ctx);
>
> return 0;
> }
>
> Now... I'm aware that lock_get/put around irq_free should be
> unneccessary, as should be irq_disable and my ->ready flag. Those were
> my attempts to work around the problem. I'll attach the full source at
> the end.
>
> > > Unfortunately, when the userspace app is ran and killed repeatedly (so
> > > that interrupt is registered/unregistered all the time), I get
> > > oopses in __ipipe_dispatch_wired() -- it seems to call into the NULL
> > > pointer.
> > >
> > > I decided that "wired" interrupt when the source is shared between
> > > Linux and Xenomai, is wrong thing, so I disable "wired" interrupts
> > > altogether, but that only moved oops to __virq_end.
> >
> > This is wrong. The only way to get a determistically shared IRQs across
> > domains is via the wired path, either using the pattern Gilles cited or,
> > in a slight variation, signaling down via a separate rtdm_nrtsig.
>
> For now, I'm trying to get it not to oops; deterministic latencies are
> the next topic :-(.
The main issue is that we don't lock our IRQ descriptors (the pipeline
ones) when running the handlers, so another CPU clearing them via
ipipe_virtualize_irq() may well sink the boat...
The unwritten rule has always been to assume that drivers would stop
_and_ drain interrupts on all CPUs before unregistering handlers, then
exiting the code. Granted, that's a bit much.
--
Philippe.
^ permalink raw reply
* Re: [PATCH 09/18] fs: rework icount to be a locked variable
From: Christoph Hellwig @ 2010-10-08 8:17 UTC (permalink / raw)
To: Dave Chinner
Cc: Christoph Hellwig, linux-fsdevel, linux-kernel, chris.mason,
linux-btrfs
In-Reply-To: <20101008075001.GT4681@dastard>
On Fri, Oct 08, 2010 at 06:50:01PM +1100, Dave Chinner wrote:
> > There's no need to lock a normal 32-bit variable for readers.
>
> Ok, but will need a memory barrier instead?
Isn't spin_unlock supposed to be one? I'll need some of the locking
experts to shime in.
^ permalink raw reply
* Re: [PATCH 0/9] [GIT PULL] tracing: updates for 2.6.37
From: Ingo Molnar @ 2010-10-08 8:16 UTC (permalink / raw)
To: Steven Rostedt; +Cc: linux-kernel, Andrew Morton, Frederic Weisbecker
In-Reply-To: <20101006033445.465428951@goodmis.org>
* Steven Rostedt <rostedt@goodmis.org> wrote:
> Ingo,
>
> Please pull the latest tip/perf/core tree, which can be found at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-trace.git
> tip/perf/core
>
>
> Jason Baron (1):
> jump label/x86: Move arch_init_ideal_nop5 later
>
> Jiri Olsa (3):
> tracing: Add proper check for irq_depth routines
> tracing: Make graph related irqs/preemptsoff functions global
> tracing: Graph support for wakeup tracer
>
> Steven Rostedt (4):
> tracing/x86: No need to disable interrupts when calling arch_init_ideal_nop5
> tracing: Use one prologue for the wakeup tracer function tracers
> tracing: Use one prologue for the preempt irqs off tracer function tracers
> tracing: Remove parent recording in latency tracer graph options
>
> matt mooney (1):
> tracing/trivial: Remove cast from void*
>
> ----
> arch/x86/kernel/alternative.c | 5 +
> arch/x86/kernel/setup.c | 6 -
> kernel/trace/ftrace.c | 8 +-
> kernel/trace/trace.c | 2 +-
> kernel/trace/trace.h | 4 +
> kernel/trace/trace_functions_graph.c | 86 +++++++++++-
> kernel/trace/trace_irqsoff.c | 152 +++++++-------------
> kernel/trace/trace_sched_wakeup.c | 257 ++++++++++++++++++++++++++++++---
> 8 files changed, 380 insertions(+), 140 deletions(-)
Pulled, thanks a lot Steve!
Ingo
^ permalink raw reply
* Re: [PATCH] fast-import: Allow filemodify to set the root
From: Ramkumar Ramachandra @ 2010-10-08 8:15 UTC (permalink / raw)
To: David Barr
Cc: Git Mailing List, Jonathan Nieder, Sverre Rabbelier,
Johannes Sixt
In-Reply-To: <1286448906-1424-1-git-send-email-david.barr@cordelta.com>
Hi David,
I'm sorry I didn't get the time to look at this earlier- just looked
at it now.
David Barr writes:
> Most git commands do their writing to the object db via the index and
> loose objects. When you just have a pile of trees you want to convert
> into commits, this is wasteful; for performance-critical operations
> like filter-branch --subdirectory-filter, one might want a sort of
> hash-object --batch-to-pack to write a pack directly.
>
> Fortunately we have fast-import (which is one of the only git commands
> that will write to a pack directly) but there is not an advertised way
> to tell fast-import to use a given tree for its commits. So in
> current git, one has the unpleasant choice of writing loose objects
> without parsing the trees or writing straight to pack but having to
> parse trees to do it.
>
> This patch changes that, by allowing
>
> M 040000 <tree id> ""
It can be a <dataref> in general: either a SHA1 or a tree mark.
> as a filemodify line in a commit to reset to a particular tree without
> any need to unpack it. For example,
>
> M 040000 4b825dc642cb6eb9a060e54bf8d69288fbee4904 ""
>
> is a synonym for the deleteall command.
>
> Commit-message-by: Jonathan Nieder <jrnieder@gmail.com>
> Signed-off-by: David Barr <david.barr@cordelta.com>
> ---
> fast-import.c | 9 +++++++++
> 1 files changed, 9 insertions(+), 0 deletions(-)
I applied and tried it out- it works as expected. Here's a patch for
the documentation and a test. You might want to put the test in a
separate patch (in preparation for Jonathan's t9300 cleanup series).
@Jonathan: What happened to your series cleaning up t9300?
Tested-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
-- 8< --
diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt
index 966ba4f..90a4666 100644
--- a/Documentation/git-fast-import.txt
+++ b/Documentation/git-fast-import.txt
@@ -524,6 +524,9 @@ start with double quote (`"`).
If an `LF` or double quote must be encoded into `<path>` shell-style
quoting should be used, e.g. `"path/with\n and \" in it"`.
+Additionally, in `040000` mode, `<path>` may also be an empty string
+(`""`) to specify the root of the tree.
+
The value of `<path>` must be in canonical form. That is it must not:
* contain an empty directory component (e.g. `foo//bar` is invalid),
diff --git a/t/t9300-fast-import.sh b/t/t9300-fast-import.sh
index 7c05920..3c0cf05 100755
--- a/t/t9300-fast-import.sh
+++ b/t/t9300-fast-import.sh
@@ -875,6 +875,27 @@ test_expect_success \
compare_diff_raw expect actual'
test_expect_success \
+ 'N: copy root directory by tree hash' \
+ 'cat >expect <<-\EOF &&
+ :100755 000000 f1fb5da718392694d0076d677d6d0e364c79b0bc 0000000000000000000000000000000000000000 D file3/newf
+ :100644 000000 7123f7f44e39be127c5eb701e5968176ee9d78b1 0000000000000000000000000000000000000000 D file3/oldf
+ EOF
+ root=$(git rev-parse refs/heads/branch^0^{tree}) &&
+ cat >input <<-INPUT_END &&
+ commit refs/heads/N6
+ committer $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> $GIT_COMMITTER_DATE
+ data <<COMMIT
+ copy root directory by tree hash
+ COMMIT
+
+ from refs/heads/branch^0
+ M 040000 $root ""
+ INPUT_END
+ git fast-import <input &&
+ git diff-tree -C --find-copies-harder -r N4 N6 >actual &&
+ compare_diff_raw expect actual'
+
+test_expect_success \
'N: modify copied tree' \
'cat >expect <<-\EOF &&
:100644 100644 fcf778cda181eaa1cbc9e9ce3a2e15ee9f9fe791 fcf778cda181eaa1cbc9e9ce3a2e15ee9f9fe791 C100 newdir/interesting file3/file5
> diff --git a/fast-import.c b/fast-import.c
> index 2317b0f..8f68a89 100644
> --- a/fast-import.c
> +++ b/fast-import.c
> @@ -1454,6 +1454,15 @@ static int tree_content_set(
> n = slash1 - p;
> else
> n = strlen(p);
> + if (!slash1 && !n) {
> + if (!S_ISDIR(mode))
> + die("Root cannot be a non-directory");
> + hashcpy(root->versions[1].sha1, sha1);
> + if (root->tree)
> + release_tree_content_recursive(root->tree);
> + root->tree = subtree;
Should there be a hashclr(root->versions[1].sha1) here? I saw it in
the other branches.
Looks good otherwise. I'm surprised fast-import didn't already have
this functionality.
-- Ram
^ permalink raw reply related
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.