* [Buildroot] [Bug 2677] introducing util-linux-ng as replacement for util-linux
From: bugzilla at busybox.net @ 2010-10-08 6:28 UTC (permalink / raw)
To: buildroot
In-Reply-To: <bug-2677-163@https.bugs.busybox.net/>
https://bugs.busybox.net/show_bug.cgi?id=2677
Ossy <marcus.osdoba@googlemail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|unassigned at buildroot.uclibc |marcus.osdoba at googlemail.co
|.org |m
--
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
^ permalink raw reply
* [Buildroot] [Bug 2677] introducing util-linux-ng as replacement for util-linux
From: bugzilla at busybox.net @ 2010-10-08 6:28 UTC (permalink / raw)
To: buildroot
In-Reply-To: <bug-2677-163@https.bugs.busybox.net/>
https://bugs.busybox.net/show_bug.cgi?id=2677
Ossy <marcus.osdoba@googlemail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P5 |P4
Target Milestone|--- |2010.11
Severity|normal |enhancement
--
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
^ permalink raw reply
* [Buildroot] [Bug 2683] cups does not install correctly to target
From: bugzilla at busybox.net @ 2010-10-08 6:27 UTC (permalink / raw)
To: buildroot
In-Reply-To: <bug-2683-163@https.bugs.busybox.net/>
https://bugs.busybox.net/show_bug.cgi?id=2683
Ossy <marcus.osdoba@googlemail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|unassigned at buildroot.uclibc |marcus.osdoba at googlemail.co
|.org |m
Target Milestone|--- |2010.11
--
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
^ permalink raw reply
* Re: 2.6.36-rc7: kernel panic with SECURITY_TOMOYO=y
From: Tetsuo Handa @ 2010-10-08 6:26 UTC (permalink / raw)
To: kosaki.motohiro
Cc: linux-kernel, takedakn, lists, kawime, jkosina,
linux-security-module
In-Reply-To: <20101008134644.8049.A69D9226@jp.fujitsu.com>
Jiri Kosina wrote: ( http://lkml.org/lkml/2010/8/11/80 )
> > The panic message was:
> > > Profile %u (used by '%s') not defined.
> >
> > Profile 0 (used by '0') not defined.
>
> Looking at the code ...
>
> void tomoyo_check_profile(void)
> {
> struct tomoyo_domain_info *domain;
> const int idx = tomoyo_read_lock();
> tomoyo_policy_loaded = true;
> /* Check all profiles currently assigned to domains are defined. */
> list_for_each_entry_rcu(domain, &tomoyo_domain_list, list) {
> const u8 profile = domain->profile;
> if (tomoyo_profile_ptr[profile])
> continue;
> panic("Profile %u (used by '%s') not defined.\n",
> profile, domain->domainname->name);
> }
> tomoyo_read_unlock(idx);
> if (tomoyo_profile_version != 20090903)
> panic("Profile version %u is not supported.\n",
> tomoyo_profile_version);
> printk(KERN_INFO "TOMOYO: 2.3.0\n");
> printk(KERN_INFO "Mandatory Access Control activated.\n");
> }
>
> makes one wonder whether not having up-to-date userspace really does
> qualify for unconditional kernel panic.
KOSAKI Motohiro wrote:
> Handa-san, please see this panic message again.
>
> > Kernel panic - not syncing: Profile uersion 0 is not supported
>
> Profile?
> This message doesn't have any information which should we look!
> And, 'profile' is wrong word. TOMOYO have to recommend to upgrade
> userland tools here at minimum.
I see. What about this?
>From cc7601c18982909987bbb48971acb86a69a3317a Mon Sep 17 00:00:00 2001
From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date: Fri, 8 Oct 2010 14:43:22 +0900
Subject: [PATCH] TOMOYO: Print URL information before panic().
Configuration files for TOMOYO 2.3 are not compatible with TOMOYO 2.2.
But current panic() message is too unfriendly and is confusing users.
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
---
security/tomoyo/common.c | 11 ++++++++++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/security/tomoyo/common.c b/security/tomoyo/common.c
index c668b44..1f0d45a 100644
--- a/security/tomoyo/common.c
+++ b/security/tomoyo/common.c
@@ -2051,13 +2051,22 @@ void tomoyo_check_profile(void)
const u8 profile = domain->profile;
if (tomoyo_profile_ptr[profile])
continue;
+ printk(KERN_ERR "You need to define profile %u before using it.\n",
+ profile);
+ printk(KERN_ERR "Please see http://tomoyo.sourceforge.jp/2.3/ "
+ "for more information.\n");
panic("Profile %u (used by '%s') not defined.\n",
profile, domain->domainname->name);
}
tomoyo_read_unlock(idx);
- if (tomoyo_profile_version != 20090903)
+ if (tomoyo_profile_version != 20090903) {
+ printk(KERN_ERR "You need to install userland programs for "
+ "TOMOYO 2.3 and initialize policy configuration.\n");
+ printk(KERN_ERR "Please see http://tomoyo.sourceforge.jp/2.3/ "
+ "for more information.\n");
panic("Profile version %u is not supported.\n",
tomoyo_profile_version);
+ }
printk(KERN_INFO "TOMOYO: 2.3.0\n");
printk(KERN_INFO "Mandatory Access Control activated.\n");
}
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] gtk+_2.20.1: add `pango-native` to `DEPENDS`
From: Frans Meulenbroeks @ 2010-10-08 6:24 UTC (permalink / raw)
To: openembedded-devel
In-Reply-To: <1286500978.3659.60.camel@mattotaupa>
2010/10/8 Paul Menzel <paulepanter@users.sourceforge.net>:
> Dear OE folks,
>
>
> I am still testing this patch. But since the new testing cycle will start soon I am sending this out already.
>
>
> Thanks,
>
> Paul
>
> 8<-------------------------------------------------------------------->8
> Date: Thu, 7 Oct 2010 13:43:58 +0200
>
> Since two or three days I am not able to build `gtk+_2.20.1.bb` anymore. I tried to revert to `gtk+.inc` 9730a2 [1] with
>
> git checkout 9730a28e669931fee601756e949bb210999b4b81 recipes/gtk+/gtk+.inc
>
> but it did not help. I do still get the same error.
>
> | /oe/build-minimal-eglibc/minimal-dev/sysroots/i686-linux/usr/bin/g-ir-scanner --add-include-path=../gdk-pixbuf --namespace=Gdk --nsversion=2.0 --libtool="/bin/sh ../i686-linux-libtool" --include=Gio-2.0 --include=GdkPixbuf-2.0 --include=Pango-1.0 --library=libgdk-x11-2.0.la --strip-prefix=Gdk --add-include-path=../gdk-pixbuf -DG_LOG_DOMAIN=\"Gdk\" -DGDK_COMPILATION -I.. -I../gdk -I../gdk-pixbuf -DG_DISABLE_CAST_CHECKS -pthread -I/oe/build-minimal-eglibc/minimal-dev/sysroots/i686-linux/usr/include/glib-2.0 -I/oe/build-minimal-eglibc/minimal-dev/sysroots/i686-linux/usr/lib/glib-2.0/include -I/oe/build-minimal-eglibc/minimal-dev/sysroots/i686-linux/usr/include/pango-1.0 -I/oe/build-minimal-eglibc/minimal-dev/sysroots/i686-linux/usr/include/cairo -I/oe/build-minimal-eglibc/minimal-dev/sysroots/i686-linux/usr/include/pixman-1 -I/oe/build-minimal-eglibc/minimal-dev/sysroots/i686-linux/usr/include/freetype2 -I/oe/build-minimal-eglibc/minimal-dev/sysroots/i686-linux/usr/include -I/oe/build-minimal-eglibc/minimal-dev/sysroots/i686-linux/usr/include/libpng12 -I/oe/build-minimal-eglibc/minimal-dev/sysroots/i686-linux/usr/include/gio-unix-2.0/ gdk.h gdkapplaunchcontext.h gdkcairo.h gdkcolor.h gdkcursor.h gdkdisplay.h gdkdisplaymanager.h gdkdnd.h gdkdrawable.h gdkevents.h gdkfont.h gdkgc.h gdki18n.h gdkimage.h gdkinput.h gdkkeys.h gdkkeysyms.h gdkpango.h gdkpixbuf.h gdkpixmap.h gdkprivate.h gdkproperty.h gdkregion.h gdkrgb.h gdkscreen.h gdkselection.h gdkspawn.h gdktestutils.h gdktypes.h gdkvisual.h gdkwindow.h gdk.c gdkapplaunchcontext.c gdkcairo.c gdkcolor.c gdkcursor.c gdkdisplay.c gdkdisplaymanager.c gdkdnd.c gdkdraw.c gdkevents.c gdkfont.c gdkgc.c gdkglobals.c gdkimage.c gdkkeys.c gdkkeyuni.c gdkoffscreenwindow.c gdkpango.c gdkpixbuf-drawable.c gdkpixbuf-render.c gdkpixmap.c gdkpolyreg-generic.c gdkrectangle.c gdkregion-generic.c gdkrgb.c gdkscreen.c gdkselection.c gdkvisual.c gdkwindow.c gdkwindowimpl.c gdkenumtypes.c gdkenumtypes.h x11/checksettings.c x11/gdkapplaunchcontext-x11.c x11/gdkasync.c x11/gdkcolor-x11.c x11/gdkcursor-x11.c x11/gdkdisplay-x11.c x11/gdkdnd-x11.c x11/gdkdrawable-x11.c x11/gdkevents-x11.c x11/gdkfont-x11.c x11/gdkgc-x11.c x11/gdkgeometry-x11.c x11/gdkglobals-x11.c x11/gdkim-x11.c x11/gdkimage-x11.c x11/gdkinput-none.c x11/gdkinput-x11.c x11/gdkinput-xfree.c x11/gdkinput.c x11/gdkkeys-x11.c x11/gdkmain-x11.c x11/gdkpixmap-x11.c x11/gdkproperty-x11.c x11/gdkscreen-x11.c x11/gdkselection-x11.c x11/gdksettings.c x11/gdkspawn-x11.c x11/gdktestutils-x11.c x11/gdkvisual-x11.c x11/gdkwindow-x11.c x11/gdkxftdefaults.c x11/gdkxid.c x11/xsettings-client.c x11/xsettings-common.c libgdk-x11-2.0.la Makefile --output Gdk-2.0.gir
> | Couldn't find include 'Pango-1.0.gir' (search path: ['../gdk-pixbuf', '../gdk-pixbuf', '/oe/build-minimal-eglibc/minimal-dev/sysroots/i686-linux/usr/share/gir-1.0', '/oe/build-minimal-eglibc/minimal-dev/sysroots/i686-linux/usr/share/gir-1.0', '/usr/share/gir-1.0', '/oe/build-minimal-eglibc/minimal-dev/sysroots/i686-linux/usr/share/gir-1.0'])
>
> `Pango-1.0.gir` is not available in sysroot. But nothing seems to have changed regarding Pango during the last days either.
>
> I am using `minimal` for `MACHINE = "beagleboard"`.
>
> [1] http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=9730a28e669931fee601756e949bb210999b4b81
>
> Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
> ---
> recipes/gtk+/gtk+_2.20.1.bb | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/recipes/gtk+/gtk+_2.20.1.bb b/recipes/gtk+/gtk+_2.20.1.bb
> index 6ef5e5b..915ccf5 100644
> --- a/recipes/gtk+/gtk+_2.20.1.bb
> +++ b/recipes/gtk+/gtk+_2.20.1.bb
> @@ -19,6 +19,8 @@ ARM_INSTRUCTION_SET = "arm"
> DEPENDS_virtclass-native = "libpng-native atk-native pango-native cairo-native libxrender-native libxext-native libgcrypt-native"
> PROVIDES_virtclass-native = "gdk-pixbuf-csource-native"
>
> +DEPENDS += "pango-native"
> +
> # Enable xkb selectively
> XKBTOGGLE = " --disable-xkb"
> XKBTOGGLE_angstrom = ""
> --
>
I doubt that this is sound.
Your error indicates you are missing includes, so you might need a
DEPENDS on pango, not on pango-native (and maybe pango needs to be
fixed to put its stuff in the right dir or gtk+ to look at the right
place)
Then again I do not see any beagle specific include dirs in your path,
which also greatly surprises me.
And please also don't type things before the --- like "Dear OE folks.
Please do explanations below that line, so if your patch is accepted
people can just do a git am without the need to modify the commit
message.
One other thing:
*if* we need a depend on pango-native, I guess it should go from the
DEPENDS_virtclass-native. Then again I am not that good wrt the
machinery that I can say whether it will not add an additional -native
or so. I recall another issue with that from earlier this week. Then
again I feel the build machinery should not add an addtional -native
suffix to depends etc that already have -native at the end).
frans
^ permalink raw reply
* Re: Need expert's advice - Fast Track Ultra (8R) dropping samples
From: Clemens Ladisch @ 2010-10-08 6:26 UTC (permalink / raw)
To: Felix Homann; +Cc: tiwai, alsa-devel
In-Reply-To: <4CADB077.3060907@showlabor.de>
Felix Homann wrote:
> @Daniel:
> You asked for the output of lsusb. Are you thinking of modifying the
> UA-101 driver yourself? Or something more generic?
I guess he wanted to look for UAC2 descriptors (which this device does
not have).
When (if) the driver has UAC2 implicit feedback support, it's easy to
add a simple quirk that makes the FTU work. (In that case, the UA-101
driver can be merged back, too.)
> Did anyone notice the patch adding mixer support for the FTU devices I
> send on Sept, 25?
Yes, I noticed it.
Regards,
Clemens
^ permalink raw reply
* [Buildroot] [Bug 2683] New: cups does not install correctly to target
From: bugzilla at busybox.net @ 2010-10-08 6:25 UTC (permalink / raw)
To: buildroot
https://bugs.busybox.net/show_bug.cgi?id=2683
Summary: cups does not install correctly to target
Product: buildroot
Version: 2010.05
Platform: All
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P5
Component: Other
AssignedTo: unassigned at buildroot.uclibc.org
ReportedBy: marcus.osdoba at googlemail.com
CC: buildroot at uclibc.org
Estimated Hours: 0.0
Created attachment 2587
--> https://bugs.busybox.net/attachment.cgi?id=2587
cups 1.4.4 and autotargets
cups installs its libraries into user/lib64, the attached patch converts to
autotargets and updates to newer version 1.4.4, libraries are installed
correctly, runs well on arm926
--
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
^ permalink raw reply
* [PATCH] drm/i915: make sure hotpulg is enabled
From: Yuanhan Liu @ 2010-10-08 6:19 UTC (permalink / raw)
To: intel-gfx; +Cc: stable
Make sure hotplug is enabled, or the hotplug interrupt will not be
invoked. And, for sandybridge, the bit definition for hotplug on
SDE is changed. So, update the code to new definition.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30378
Cc: stable@kernel.org
Signed-off-by: Yuanhan Liu <yuanhan.liu@intel.com>
---
drivers/gpu/drm/i915/i915_irq.c | 19 ++++++++++++++++---
drivers/gpu/drm/i915/i915_reg.h | 4 ++++
drivers/gpu/drm/i915/intel_crt.c | 3 ++-
3 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 744225e..39a5456 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -310,6 +310,7 @@ irqreturn_t ironlake_irq_handler(struct drm_device *dev)
drm_i915_private_t *dev_priv = (drm_i915_private_t *) dev->dev_private;
int ret = IRQ_NONE;
u32 de_iir, gt_iir, de_ier, pch_iir;
+ u32 hotplug_mask;
struct drm_i915_master_private *master_priv;
struct intel_ring_buffer *render_ring = &dev_priv->render_ring;
@@ -325,6 +326,11 @@ irqreturn_t ironlake_irq_handler(struct drm_device *dev)
if (de_iir == 0 && gt_iir == 0 && pch_iir == 0)
goto done;
+ if (HAS_PCH_CPT(dev))
+ hotplug_mask = SDE_HOTPLUG_MASK_CPT;
+ else
+ hotplug_mask = SDE_HOTPLUG_MASK;
+
ret = IRQ_HANDLED;
if (dev->primary->master) {
@@ -367,7 +373,7 @@ irqreturn_t ironlake_irq_handler(struct drm_device *dev)
/* check event from PCH */
if ((de_iir & DE_PCH_EVENT) &&
- (pch_iir & SDE_HOTPLUG_MASK)) {
+ (pch_iir & hotplug_mask)) {
queue_work(dev_priv->wq, &dev_priv->hotplug_work);
}
@@ -1424,8 +1430,7 @@ static int ironlake_irq_postinstall(struct drm_device *dev)
u32 display_mask = DE_MASTER_IRQ_CONTROL | DE_GSE | DE_PCH_EVENT |
DE_PLANEA_FLIP_DONE | DE_PLANEB_FLIP_DONE;
u32 render_mask = GT_PIPE_NOTIFY | GT_BSD_USER_INTERRUPT;
- u32 hotplug_mask = SDE_CRT_HOTPLUG | SDE_PORTB_HOTPLUG |
- SDE_PORTC_HOTPLUG | SDE_PORTD_HOTPLUG;
+ u32 hotplug_mask;
dev_priv->irq_mask_reg = ~display_mask;
dev_priv->de_irq_enable_reg = display_mask | DE_PIPEA_VBLANK | DE_PIPEB_VBLANK;
@@ -1450,6 +1455,14 @@ static int ironlake_irq_postinstall(struct drm_device *dev)
I915_WRITE(GTIER, dev_priv->gt_irq_enable_reg);
(void) I915_READ(GTIER);
+ if (HAS_PCH_CPT(dev)) {
+ hotplug_mask = SDE_CRT_HOTPLUG_CPT | SDE_PORTB_HOTPLUG_CPT |
+ SDE_PORTC_HOTPLUG_CPT | SDE_PORTD_HOTPLUG_CPT ;
+ } else {
+ hotplug_mask = SDE_CRT_HOTPLUG | SDE_PORTB_HOTPLUG |
+ SDE_PORTC_HOTPLUG | SDE_PORTD_HOTPLUG;
+ }
+
dev_priv->pch_irq_mask_reg = ~hotplug_mask;
dev_priv->pch_irq_enable_reg = hotplug_mask;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 4f5e155..412b38a 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2551,6 +2551,10 @@
#define SDE_PORTD_HOTPLUG_CPT (1 << 23)
#define SDE_PORTC_HOTPLUG_CPT (1 << 22)
#define SDE_PORTB_HOTPLUG_CPT (1 << 21)
+#define SDE_HOTPLUG_MASK_CPT (SDE_CRT_HOTPLUG_CPT | \
+ SDE_PORTD_HOTPLUG_CPT | \
+ SDE_PORTC_HOTPLUG_CPT | \
+ SDE_PORTB_HOTPLUG_CPT)
#define SDEISR 0xc4000
#define SDEIMR 0xc4004
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 197d4f3..0f950e7 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -191,7 +191,8 @@ static bool intel_ironlake_crt_detect_hotplug(struct drm_connector *connector)
DRM_DEBUG_KMS("timed out waiting for FORCE_TRIGGER");
if (turn_off_dac) {
- I915_WRITE(PCH_ADPA, temp);
+ /* Make sure hotplug is enabled */
+ I915_WRITE(PCH_ADPA, temp | ADPA_CRT_HOTPLUG_ENABLE);
(void)I915_READ(PCH_ADPA);
}
--
1.7.2.2
^ permalink raw reply related
* [Buildroot] [Bug 2677] New: introducing util-linux-ng as replacement for util-linux
From: bugzilla at busybox.net @ 2010-10-08 6:22 UTC (permalink / raw)
To: buildroot
https://bugs.busybox.net/show_bug.cgi?id=2677
Summary: introducing util-linux-ng as replacement for
util-linux
Product: buildroot
Version: unspecified
Platform: All
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P5
Component: Other
AssignedTo: unassigned at buildroot.uclibc.org
ReportedBy: marcus.osdoba at googlemail.com
CC: buildroot at uclibc.org
Estimated Hours: 0.0
Created attachment 2581
--> https://bugs.busybox.net/attachment.cgi?id=2581
introducing util-linux-NG
former version of util-linux is rather outdated, this version introduces the
stable version 2.17.2 used widely in distributions
--
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
^ permalink raw reply
* Re: [tip:x86/setup] x86, setup: Use string copy operation to optimze copy in kernel compression
From: H. Peter Anvin @ 2010-10-08 6:21 UTC (permalink / raw)
To: Yinghai Lu, mingo, linux-kernel, yakui.zhao, tglx; +Cc: linux-tip-commits
In-Reply-To: <4CAEB1BA.2030604@kernel.org>
Almost certainly still faster than bytewise copy!
"Yinghai Lu" <yinghai@kernel.org> wrote:
>On 10/07/2010 10:40 PM, tip-bot for Zhao Yakui wrote:
>> Commit-ID: 68f4d5a00adaab33b136fce2c72d5c377b39b0b0
>> Gitweb: http://git.kernel.org/tip/68f4d5a00adaab33b136fce2c72d5c377b39b0b0
>> Author: Zhao Yakui <yakui.zhao@intel.com>
>> AuthorDate: Fri, 8 Oct 2010 09:47:33 +0800
>> Committer: H. Peter Anvin <hpa@zytor.com>
>> CommitDate: Thu, 7 Oct 2010 21:23:09 -0700
>>
>> x86, setup: Use string copy operation to optimze copy in kernel compression
>>
>> The kernel decompression code parses the ELF header and then copies
>> the segment to the corresponding destination. Currently it uses slow
>> byte-copy code. This patch makes it use the string copy operations
>> instead.
>>
>> In the test the copy performance can be improved very significantly after using
>> the string copy operation mechanism.
>> 1. The copy time can be reduced from 150ms to 20ms on one Atom machine
>> 2. The copy time can be reduced about 80% on another machine
>> The time is reduced from 7ms to 1.5ms when using 32-bit kernel.
>> The time is reduced from 10ms to 2ms when using 64-bit kernel.
>>
>> Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
>> LKML-Reference: <1286502453-7043-1-git-send-email-yakui.zhao@intel.com>
>> Signed-off-by: H. Peter Anvin <hpa@zytor.com>
>> ---
>> arch/x86/boot/compressed/misc.c | 29 +++++++++++++++++++++++------
>> 1 files changed, 23 insertions(+), 6 deletions(-)
>>
>> diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
>> index 8f7bef8..23f315c 100644
>> --- a/arch/x86/boot/compressed/misc.c
>> +++ b/arch/x86/boot/compressed/misc.c
>> @@ -229,18 +229,35 @@ void *memset(void *s, int c, size_t n)
>> ss[i] = c;
>> return s;
>> }
>> -
>> +#ifdef CONFIG_X86_32
>> void *memcpy(void *dest, const void *src, size_t n)
>> {
>> - int i;
>> - const char *s = src;
>> - char *d = dest;
>> + int d0, d1, d2;
>> + asm volatile(
>> + "rep ; movsl\n\t"
>> + "movl %4,%%ecx\n\t"
>> + "rep ; movsb\n\t"
>> + : "=&c" (d0), "=&D" (d1), "=&S" (d2)
>> + : "0" (n >> 2), "g" (n & 3), "1" (dest), "2" (src)
>> + : "memory");
>>
>> - for (i = 0; i < n; i++)
>> - d[i] = s[i];
>> return dest;
>> }
>> +#else
>> +void *memcpy(void *dest, const void *src, size_t n)
>> +{
>> + long d0, d1, d2;
>> + asm volatile(
>> + "rep ; movsq\n\t"
>> + "movq %4,%%rcx\n\t"
>> + "rep ; movsb\n\t"
>> + : "=&c" (d0), "=&D" (d1), "=&S" (d2)
>> + : "0" (n >> 3), "g" (n & 7), "1" (dest), "2" (src)
>> + : "memory");
>>
>> + return dest;
>> +}
>> +#endif
>>
>> static void error(char *x)
>> {
>
>wonder if it would have problem with some old AMD K8 systems.
>
>in amd.c
>
> /* On C+ stepping K8 rep microcode works well for copy/memset */
> if (c->x86 == 0xf) {
> u32 level;
>
> level = cpuid_eax(1);
> if ((level >= 0x0f48 && level < 0x0f50) || level >= 0x0f58)
> set_cpu_cap(c, X86_FEATURE_REP_GOOD);
>...
>
> }
> if (c->x86 >= 0x10)
> set_cpu_cap(c, X86_FEATURE_REP_GOOD);
>
>Yinghai
--
Sent from my mobile phone. Please pardon any lack of formatting.
^ permalink raw reply
* missing definition of 's3c_gpio_getpull' function in 'plat-samsung'
From: Kukjin Kim @ 2010-10-08 6:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <000301cb66af$276b8960$76429c20$@com>
Daein Moon wrote:
>
> Hi Ben Dooks and Kukjin,
>
Hi,
> I found an issue about s3c_gpio_getpull API.
>
> The 'plat-samsung' provides 's3c_gpio_setpull' and 's3c_gpio_getpull'
> to set and get pull-{none|up|down} of GPIO. But there is no
> 's3c_gpio_getpull' definition in 'arch/arm/plat-samsung/gpio-config.c',
> and there is only declaration in the corresponding header file.
>
> 's3c_gpio_getpull' isn't supported/used. So if providing this api, its
> definition should be inserted.
>
> Otherwise, code that is used to provide s3c_gpio_getpull including
> following code should be removed.
>
> arch/arm/plat-samsung/include/plat/gpio-cfg.h:
> extern s3c_gpio_pull_t s3c_gpio_getpull(unsigned int pin);
>
> arch/arm/mach-{s3c*|s5p*}/gpiolib.c:
> .get_pull = s3c_gpio_getpull_updown,
>
>
> What do you think about that?:
>
Hmm...
I found s3c_gpio_getpull_updown() in plat-samsung/gpio-config.c like below.
220 s3c_gpio_pull_t s3c_gpio_getpull_updown(struct s3c_gpio_chip *chip,
221 unsigned int off)
222 {
223 void __iomem *reg = chip->base + 0x08;
224 int shift = off * 2;
225 u32 pup = __raw_readl(reg);
226
227 pup >>= shift;
228 pup &= 0x3;
229 return (__force s3c_gpio_pull_t)pup;
230 }
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* RE: [PATCH 1/7] [RFC] OMAP: MCBSP: hwmod database for 2xxx devices
From: Varadarajan, Charulatha @ 2010-10-08 6:20 UTC (permalink / raw)
To: Peter Ujfalusi
Cc: linux-omap@vger.kernel.org, alsa-devel@alsa-project.org,
Kamat, Nishant, Datta, Shubhrajyoti, Basak, Partha,
Girdwood, Liam, jhnikula@gmail.com,
broonie@opensource.wolfsonmicro.com, ABRAHAM, KISHON VIJAY
In-Reply-To: <201010061017.13908.peter.ujfalusi@nokia.com>
> -----Original Message-----
> From: Peter Ujfalusi [mailto:peter.ujfalusi@nokia.com]
> Sent: Wednesday, October 06, 2010 12:47 PM
> To: Varadarajan, Charulatha
> Cc: linux-omap@vger.kernel.org; alsa-devel@alsa-project.org; Kamat,
> Nishant; Datta, Shubhrajyoti; Basak, Partha; Girdwood, Liam;
> jhnikula@gmail.com; broonie@opensource.wolfsonmicro.com; ABRAHAM, KISHON
> VIJAY
> Subject: Re: [PATCH 1/7] [RFC] OMAP: MCBSP: hwmod database for 2xxx
> devices
>
> Hello,
Thanks for the quick response.
>
> On Wednesday 06 October 2010 10:01:28 ext Varadarajan, Charulatha wrote:
> > This patch series is targeted to implement mcbsp driver in
> > hwmod way and to make use of pm_runtime APIs.
> >
> > This patch series is tested on OMAP3 & 4 and yet to be tested
> > on OMAP2.
> >
> > There are few clarifications required so that the next patch series
> > can be implemented after aligning.
> >
> > 1. Audio layer is making use of mcbsp and it's dma base addresses and
> > is closely coupled with omap-mcbsp.
> > This can be handled either by
> > a. providing an API with which Audio layer can get these addresses.
> > (or)
> > b. move the plat-omap/mcbsp.c and mach-omap2/mcbsp.c to sound/soc/omap/
> > [1]
> >
> > Option (a) would only be a workaround to handle the situation. As
> > audio is the only user for mcbsp, option (b) is better. If option(b)
> > is agreed upon, the same can be addressed on top of the mcbsp hwmod
> > series.
>
> it is true that at the moment only audio is using the McBSP ports, but
> McBSP is
> really flexible, it can run for example in SPI mode, and it can be
> configured to
> use other serial protocols.
Yes.
> I would go with option c.
> Since ASoC is moving to multi-component (the conversion is already in
> linux-
> next), this means that the sound/soc/omap/omap-mcbsp, omap-pcm drivers are
> platform drivers.
> So if the plat-omap/mcbsp would register the platform device for McBSP
> clients
> (we have only ASoC client at the moment), and use platform data to pass
> the
> needed information to the McBSP client driver, than we do not need new API.
Sorry I am confused.
With hwmod implementation, there is a device register code for mcbsp
devices in mach-omap2/mcbsp.c and a probe in plat-omap/mcbsp.c. The base
address, dma info are not part of pdata and are available to the driver
only after probe. I do not understand how the multi-component design in
ASOC can avoid the new API.
Also with this multi-component approach in ASOC, two device
registrations happens for a single mcbsp device with two different
rames ("omap-mcbsp-dai.id" & "omap-mcbsp.id"). Please explain if this
what is expected?
> We still need to modify the ASoC drivers to make use of this platform data,
> but
> at least we are going to keep the door open for others to use the McBSP
> ports
> for other than audio.
Agreed. But the current omap-mcbsp driver cannot work standalone for
OMAP3/4 due to the issues stated below:
1. omap_mcbsp_pollwrite and omap_mcbsp_pollread functions access McBSP
registers as 16-bit. But in OMAP3/4, McBSP registers (DRR_REG and DXR_REG)
are limited to 32-bit data accesses and hence poll mode would not work [x].
2. DMA transfers would also not work as it requires a patch similar to [y].
Patches [x] & [y] were rejected as there are no users other than asoc.
If it is not agreed to move omap-mcbsp driver to asoc layer, we need to
get the omap-mcbsp driver working as a standalone driver. Otherwise it
is of no use keeping the mcbsp driver in plat-omap.
Once [x] & [y] patches are upstreamed, audio layer needs to be modified
to make use of omap-mcbsp APIs rather than Audio layer calling dma
APIs directly to transfer data.
Coming back to the original question. Either we need to fix the broken
legacy mcbsp driver or move the omap-mcbsp driver completely to asoc
layer. What do you say?
[x] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg19531.html
[y] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg04085.html
>
> > 2. Sidetone feature is available only in OMAP3 (McBSP2&3) which has
> > different base address and sys configs compared to it's mcbsp port.
> > Hence the mcbsp is considered as a single device with two hwmods
> > for McBSP2&3 devices in OMAP3.
>
> Sounds fair enough.
Thanks.
>
> > 3. Autoidle needs to be disabled for sidetone before enabling the
> sidetone
> > feature. There was a design proposed by Kishon [2] to add an API in
> hwmod
> > to modify the autoidle bit but was not agreed upon. How do we handle
> this
> > situation where the device has to disable or enable the autoidle bit at
> > runtime?
>
> Yeah, this is really annoying problem. The McBSP ST should block autoidle
> from
> McBSP side, but it does not.
> If you can not get through the proposed API, we should consider to switch
> the
> corresponding McBSP port to NoIdle, when the ST is in use (and restore the
> idle
> mode, when the ST has been disabled).
> When McBSP is in NoIdle the interface clock is not going to be gated, so
> ST
> block will be running without a problem (ST needs the iface clock for
> operation)
>
> What do you think?
I think it might not be possible to handle this, as the clocks are the same for ST and mcbsp port. pm_runtime APIs are not called during ST enable/disable as clocks are already enabled while enabling mcbsp port. Hence the idle bit change cannot happen even if the oh->flags are modified runtime during ST enable/disable.
> >
> > [1] https://patchwork.kernel.org/patch/225582/
> > [2] https://patchwork.kernel.org/patch/134371/
> >
> > We would resend the same patch series by including alsa mailing list
> > (alsa-devel@alsa-project.org)
> >
> > <<snip>>
>
> --
> Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" 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: [PATCH] JFFS2: Dynamically choose inocache hash size
From: Artem Bityutskiy @ 2010-10-08 6:17 UTC (permalink / raw)
To: David Woodhouse; +Cc: linux-mtd, Daniel Drake
In-Reply-To: <1286517078.2095.15.camel@localhost>
On Fri, 2010-10-08 at 08:51 +0300, Artem Bityutskiy wrote:
> On Thu, 2010-10-07 at 20:35 +0100, David Woodhouse wrote:
> > On Thu, 2010-10-07 at 22:32 +0300, Artem Bityutskiy wrote:
> > > Why is this complication needed? Unless there is a very good reason, I'd
> > > just stick with older patch you sent, which I BTW also have in my
> > > l2-mtd-2.6.git tree:
> >
> > I asked for it. With smaller file systems, a huge increase buys nothing
> > and is just bloat.
>
> OK, I looked closer to the code and I see that I misunderstood this
> constant. I though it is only about increasing the size of an array of
> integers, but this is about increasing the size of an array of
> struct jffs2_inode_cache.
Oh my, it is indeed about increasing size of array of pointers. I would
not bother with additional calculations - it is just (1024 - 256) * 4 =
3072 bytes which is nothing comparing to overall JFFS2 memory
consumption, not worth bothering.
Anyway, not so important.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
^ permalink raw reply
* Re: git push <branch-name>
From: Michael J Gruber @ 2010-10-08 6:17 UTC (permalink / raw)
To: Eric Raible; +Cc: Sverre Rabbelier, Git Mailing List
In-Reply-To: <AANLkTikwmF74453He4q49CmdxYSREUQanx6JSoW8xxSL@mail.gmail.com>
Eric Raible venit, vidit, dixit 07.10.2010 19:41:
> On Thu, Oct 7, 2010 at 3:50 AM, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
>>
>> Now, if I have a remote foo and a branch foo, what is
>>
>> git push foo
>>
>> supposed to do?
>
> http://thread.gmane.org/gmane.comp.version-control.git/158235/focus=158254
Yep, I saw it later only - Daniel had broken the thread.
Michael
^ permalink raw reply
* [Buildroot] [Bug 2389] Generate a Makefile wrapper in $(O)
From: bugzilla at busybox.net @ 2010-10-08 6:15 UTC (permalink / raw)
To: buildroot
In-Reply-To: <bug-2389-163@https.bugs.busybox.net/>
https://bugs.busybox.net/show_bug.cgi?id=2389
--- Comment #3 from Ossy <marcus.osdoba@googlemail.com> ---
Closed with commit aefad5317f2fd1645ace5a62b6b9643143093173
?
--
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
^ permalink raw reply
* Re: [PATCH v3 6/7] mtd: m25p80: add a read function to read page by page
From: Kumar Gala @ 2010-10-08 6:11 UTC (permalink / raw)
To: Hu Mingkai-B21284
Cc: David Brownell, linuxppc-dev, linux-mtd, spi-devel-general,
Gala Kumar-B11780
In-Reply-To: <73839B4A0818E747864426270AC332C3057F6138@zmy16exm20.fsl.freescale.net>
On Oct 7, 2010, at 9:15 PM, Hu Mingkai-B21284 wrote:
>>>> Yes, I agree with David on this. If large transfers don't work,
>>>> then it is the SPI master driver that is buggy.
>>>=20
>>> By the way, does this fix your problem?
>>>=20
>>> https://patchwork.kernel.org/patch/184752/
>>=20
>> It shouldn't. AFAIK, eSPI is PIO-only controller, and the overrun fix =
is for the
>> DMA mode.
>>=20
>> Thanks,
>>=20
>> p.s. Btw, in patch 3/7, is_dma_mapped argument of fsl_espi_bufs() is =
unneeded.
>>=20
>=20
> Yes, the is_dma_mapped isn't needed, I'll remove it.
>=20
> Thanks,
> Mingkai
I'd be really nice if we could close on this patchset in time for .37 =
acceptance. I'm guessing that cutoff is quickly approaching.
- k=
^ permalink raw reply
* Re: [PATCH v3 6/7] mtd: m25p80: add a read function to read page by page
From: Kumar Gala @ 2010-10-08 6:11 UTC (permalink / raw)
To: Hu Mingkai-B21284
Cc: David Brownell, Grant Likely, linuxppc-dev, linux-mtd,
Anton Vorontsov, spi-devel-general, Gala Kumar-B11780
In-Reply-To: <73839B4A0818E747864426270AC332C3057F6138@zmy16exm20.fsl.freescale.net>
On Oct 7, 2010, at 9:15 PM, Hu Mingkai-B21284 wrote:
>>>> Yes, I agree with David on this. If large transfers don't work,
>>>> then it is the SPI master driver that is buggy.
>>>
>>> By the way, does this fix your problem?
>>>
>>> https://patchwork.kernel.org/patch/184752/
>>
>> It shouldn't. AFAIK, eSPI is PIO-only controller, and the overrun fix is for the
>> DMA mode.
>>
>> Thanks,
>>
>> p.s. Btw, in patch 3/7, is_dma_mapped argument of fsl_espi_bufs() is unneeded.
>>
>
> Yes, the is_dma_mapped isn't needed, I'll remove it.
>
> Thanks,
> Mingkai
I'd be really nice if we could close on this patchset in time for .37 acceptance. I'm guessing that cutoff is quickly approaching.
- k
^ permalink raw reply
* Efficiently detecting paths that differ from each other only in case
From: Dun Peal @ 2010-10-08 6:13 UTC (permalink / raw)
To: git
Hi,
I'm writing a Git hook, for a bare central repo, to reject pushes of
paths that differ from existing tracked paths only by letter case.
So, for example, if the following path is tracked in the repo:
foo/bar.py
Commits adding any of the following paths would be rejected:
Foo/bar.py
foo/Bar.py
fOO/BAR.py
Etc. I know how to do it by listing paths with ls-files, but my repo
contains many thousands of files, so I was wondering if there was a
more efficient way than for every commit:
1. Get a list of all paths in the repo from ls-files.
2. Lowercase all paths.
3. Check for repeats.
Thanks, D
^ permalink raw reply
* Re: [PATCH v3 6/7] mtd: m25p80: add a read function to read page by page
From: Kumar Gala @ 2010-10-08 6:11 UTC (permalink / raw)
To: Hu Mingkai-B21284
Cc: David Brownell, linuxppc-dev, linux-mtd, spi-devel-general,
Gala Kumar-B11780
In-Reply-To: <73839B4A0818E747864426270AC332C3057F6138@zmy16exm20.fsl.freescale.net>
On Oct 7, 2010, at 9:15 PM, Hu Mingkai-B21284 wrote:
>>>> Yes, I agree with David on this. If large transfers don't work,
>>>> then it is the SPI master driver that is buggy.
>>>
>>> By the way, does this fix your problem?
>>>
>>> https://patchwork.kernel.org/patch/184752/
>>
>> It shouldn't. AFAIK, eSPI is PIO-only controller, and the overrun fix is for the
>> DMA mode.
>>
>> Thanks,
>>
>> p.s. Btw, in patch 3/7, is_dma_mapped argument of fsl_espi_bufs() is unneeded.
>>
>
> Yes, the is_dma_mapped isn't needed, I'll remove it.
>
> Thanks,
> Mingkai
I'd be really nice if we could close on this patchset in time for .37 acceptance. I'm guessing that cutoff is quickly approaching.
- k
^ permalink raw reply
* Re: linux-next: manual merge of the hwpoison tree with Linus' tree
From: Andi Kleen @ 2010-10-08 6:11 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Andi Kleen, linux-next, linux-kernel
In-Reply-To: <20101008144037.f487b6d7.sfr@canb.auug.org.au>
On Fri, Oct 08, 2010 at 02:40:37PM +1100, Stephen Rothwell wrote:
> Hi Andi,
>
> Today's linux-next merge of the hwpoison tree got a conflict in
> mm/memory-failure.c between commit
> 0d9ee6a2d4a6e92c49e6fa9469e5731d21ee203e ("HWPOISON: Report correct
> address granuality for AO huge page errors") from Linus' tree and commit
> 3c5ca5455796841ac3cd706a91ba8dada908c375 ("HWPOISON: Report correct
> address granuality for AO huge page errors") from the hwpoison tree.
>
> Slightly different versions of the same patch. I used the version from
Yes I did a rebase here.
> Linus' tree (since it was committed later). The conflict looked like this:
I will rebase the tree. Thanks for catching.
-Andi
^ permalink raw reply
* [Buildroot] [Bug 2557] [PATCH] mkfs.xfs complains about missing libxfs.so.0
From: bugzilla at busybox.net @ 2010-10-08 6:10 UTC (permalink / raw)
To: buildroot
In-Reply-To: <bug-2557-163@https.bugs.busybox.net/>
https://bugs.busybox.net/show_bug.cgi?id=2557
Ossy <marcus.osdoba@googlemail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #2455|0 |1
is obsolete| |
--- Comment #3 from Ossy <marcus.osdoba@googlemail.com> ---
Comment on attachment 2455
--> https://bugs.busybox.net/attachment.cgi?id=2455
Fixes missing libs with xfsprogs
newer patch uses higher version and converts to autotargets
--
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
^ permalink raw reply
* [Buildroot] [Bug 2557] [PATCH] mkfs.xfs complains about missing libxfs.so.0
From: bugzilla at busybox.net @ 2010-10-08 6:09 UTC (permalink / raw)
To: buildroot
In-Reply-To: <bug-2557-163@https.bugs.busybox.net/>
https://bugs.busybox.net/show_bug.cgi?id=2557
--- Comment #2 from Ossy <marcus.osdoba@googlemail.com> ---
Created attachment 2575
--> https://bugs.busybox.net/attachment.cgi?id=2575
xfsprogs 3.1.3 may use util-linux-ng
converts to autotargets and uses libuuid
--
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
^ permalink raw reply
* [Buildroot] [Bug 2557] [PATCH] mkfs.xfs complains about missing libxfs.so.0
From: bugzilla at busybox.net @ 2010-10-08 6:07 UTC (permalink / raw)
To: buildroot
In-Reply-To: <bug-2557-163@https.bugs.busybox.net/>
https://bugs.busybox.net/show_bug.cgi?id=2557
Ossy <marcus.osdoba@googlemail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P5 |P4
Platform|PC |All
AssignedTo|unassigned at buildroot.uclibc |marcus.osdoba at googlemail.co
|.org |m
Severity|minor |normal
--- Comment #1 from Ossy <marcus.osdoba@googlemail.com> ---
Xfsprogs currently uses the old infrastructure. I updated it to the newer
version 3.1.3 and autotargets. This version on xfsprogs may use the libuuid of
util-linux-ng (introduced in another patch) or the libuuid of e2fsxprogs (no
need of util-linux-ng).
--
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
^ permalink raw reply
* missing definition of 's3c_gpio_getpull' function in 'plat-samsung'
From: Daein Moon @ 2010-10-08 6:07 UTC (permalink / raw)
To: linux-arm-kernel
Hi Ben Dooks and Kukjin,
I found an issue about s3c_gpio_getpull API.
The 'plat-samsung' provides 's3c_gpio_setpull' and 's3c_gpio_getpull'
to set and get pull-{none|up|down} of GPIO. But there is no
's3c_gpio_getpull' definition in 'arch/arm/plat-samsung/gpio-config.c',
and there is only declaration in the corresponding header file.
's3c_gpio_getpull' isn't supported/used. So if providing this api, its
definition should be inserted.
Otherwise, code that is used to provide s3c_gpio_getpull including
following code should be removed.
arch/arm/plat-samsung/include/plat/gpio-cfg.h:
extern s3c_gpio_pull_t s3c_gpio_getpull(unsigned int pin);
arch/arm/mach-{s3c*|s5p*}/gpiolib.c:
.get_pull = s3c_gpio_getpull_updown,
What do you think about that?
Best Regards,
Daein Moon
^ permalink raw reply
* Re: [PATCH] serial: DCC(JTAG) serial and console emulation support
From: Mike Frysinger @ 2010-10-08 6:05 UTC (permalink / raw)
To: Daniel Walker
Cc: Greg KH, Alan Cox, linux-kernel, Hyok S. Choi, Tony Lindgren,
Jeff Ohlstein, Ben Dooks, Alan Cox, Kukjin Kim, Feng Tang,
Tobias Klauser, Jason Wessel, Philippe Langlais
In-Reply-To: <6lwrd5r5bkngwsfbw998jv3h.1286513980329@email.android.com>
On Fri, Oct 8, 2010 at 00:59, Daniel Walker wrote:
> I'm not disputing the serial core part. I ok with converting it to tty.
sorry, i missed the distinction you were making with the "disputation" qualifier
please dont top post
-mike
^ 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.