* Re: [RFC PATCH v2 ]pci: pci resource iterator
From: Yinghai Lu @ 2012-08-22 17:31 UTC (permalink / raw)
To: Ram Pai; +Cc: linux-pci, Bjorn Helgaas
In-Reply-To: <20120822101533.GA2332@ram-ThinkPad-T61>
On Wed, Aug 22, 2012 at 3:15 AM, Ram Pai <linuxram@us.ibm.com> wrote:
> On Tue, Aug 21, 2012 at 04:22:52PM -0700, Yinghai Lu wrote:
>> On Tue, Aug 21, 2012 at 8:13 AM, Ram Pai <linuxram@us.ibm.com> wrote:
> by exposing idx through the interface, we are exposing the implementation to
> the enduser. I want the end user not know that the resources are
> structured as a array. This will help easily restructure resources
> in the pci_dev structure to whatever implementation we want, linked list
> or hash or whatever...
>
> Why can't the addon resource be hidden behind the interface? something
> like this?
keep the idx would make thing simple for referencing and converting.
pci_dev_resource_n() would be wrapper to from idx to real resource pointer.
we just need to change &dev->resource[i] referencing to
pci_dev_resource_n(dev, i) instead.
We did that before for irq_desc storage converting, and now we have
for_each_irq_desc(irq, desc)
later for the resource allocation, I will change resource member from
struct resource resource[DEVICE_COUNT_RESOURCE];
to
struct resource *std_res;
^ permalink raw reply
* RE: Porting git to HP NonStop
From: Joachim Schmitz @ 2012-08-22 17:30 UTC (permalink / raw)
To: 'Brandon Casey'
Cc: 'Junio C Hamano', 'Shawn Pearce', git, rsbecker
In-Reply-To: <CA+sFfMd5zzfZVrGJSMkr2ga8kTg6Tiun=HBdHkg6rV-stjDT8Q@mail.gmail.com>
> From: Brandon Casey [mailto:drafnel@gmail.com]
> Sent: Wednesday, August 22, 2012 7:23 PM
> To: Joachim Schmitz
> Cc: Junio C Hamano; Shawn Pearce; git@vger.kernel.org;
> rsbecker@nexbridge.com
> Subject: Re: Porting git to HP NonStop
>
> On Wed, Aug 22, 2012 at 10:18 AM, Joachim Schmitz <jojo@schmitz-digital.de>
> wrote:
> >> From: Brandon Casey [mailto:drafnel@gmail.com]
> >> Sent: Wednesday, August 22, 2012 7:01 PM
> >> To: Joachim Schmitz
> >> Cc: Junio C Hamano; Shawn Pearce; git@vger.kernel.org;
> >> rsbecker@nexbridge.com
> >> Subject: Re: Porting git to HP NonStop
> >>
> >> On Wed, Aug 22, 2012 at 9:30 AM, Joachim Schmitz
> >> <jojo@schmitz-digital.de>
> >> wrote:
> >>
> >> > OK, so how about this:
> >> > /usr/local/bin/diff -EBbu ./compat/mkdir.c.orig ./compat/mkdir.c
> >> > --- ./compat/mkdir.c.orig 2012-08-21 05:02:11 -0500
> >> > +++ ./compat/mkdir.c 2012-08-21 05:02:11 -0500
> >> > @@ -0,0 +1,24 @@
> >> > +#include "../git-compat-util.h"
> >> > +#undef mkdir
> >> > +
> >> > +/* for platforms that can't deal with a trailing '/' */ int
> >> > +compat_mkdir_wo_trailing_slash(const char *dir, mode_t mode) {
> >> > + int retval;
> >> > + char *tmp_dir = NULL;
> >> > + size_t len = strlen(dir);
> >> > +
> >> > + if (len && dir[len-1] == '/') {
> >> > + if ((tmp_dir = strdup(dir)) == NULL)
> >> > + return -1;
> >> > + tmp_dir[len-1] = '\0';
> >> > + }
> >> > + else
> >> > + tmp_dir = (char *)dir;
> >> > +
> >> > + retval = mkdir(tmp_dir, mode);
> >> > + if (tmp_dir != dir)
> >> > + free(tmp_dir);
> >> > +
> >> > + return retval;
> >> > +}
> >>
> >> Why not rearrange this so that you assign to dir the value of tmp_dir
> >> and then just pass dir to mkdir. Then you can avoid the recast of
> >> dir to (char*) in the else branch. Later, just call free(tmp_dir).
> >> Also, we have xstrndup. So I think the body of your function can become
> something like:
> >>
> >> if (len && dir[len-1] == '/')
> >> dir = tmp_dir = xstrndup(dir, len-1);
> >
> > xstndup() can't fail?
>
> Correct. It will either succeed or die. It will also try to free up some memory
> used by git if possible.
OK. So let's use that then.
Bye, Jojo
^ permalink raw reply
* [Bug 50121] [Regression] NV34 Fx5200 & NVC3/Quadro 2000M both fail to resume with commit 'convert to exec engine, and improve channel sync'
From: bugzilla-daemon-CC+yJ3UmIYqDUpFQwHEjaQ @ 2012-08-22 17:31 UTC (permalink / raw)
To: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
In-Reply-To: <bug-50121-8800-V0hAGp6uBxMKqLRl/0Ahz6D7qz1kEfGD2LY78lusg7I@public.gmane.org/>
https://bugs.freedesktop.org/show_bug.cgi?id=50121
Ronald <ronald645-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|[Regression] NV34 Fx5200 |[Regression] NV34 Fx5200 &
|fails to resume with commit |NVC3/Quadro 2000M both fail
|'convert to exec engine, |to resume with commit
|and improve channel sync' |'convert to exec engine,
| |and improve channel sync'
--
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
* [Bug 50121] [Regression] NV34 Fx5200 fails to resume with commit 'convert to exec engine, and improve channel sync'
From: bugzilla-daemon-CC+yJ3UmIYqDUpFQwHEjaQ @ 2012-08-22 17:30 UTC (permalink / raw)
To: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
In-Reply-To: <bug-50121-8800-V0hAGp6uBxMKqLRl/0Ahz6D7qz1kEfGD2LY78lusg7I@public.gmane.org/>
https://bugs.freedesktop.org/show_bug.cgi?id=50121
Ronald <ronald645-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|[Regression] NV34 Fx5200 |[Regression] NV34 Fx5200
|fails to resume with commit |fails to resume with commit
|5d720f2450 |'convert to exec engine,
| |and improve channel sync'
--
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: Porting git to HP NonStop
From: Junio C Hamano @ 2012-08-22 17:30 UTC (permalink / raw)
To: Brandon Casey; +Cc: Joachim Schmitz, Shawn Pearce, git, rsbecker
In-Reply-To: <CA+sFfMdnixrUekh40Sde05tkap7Oj19=5D6J6aYVVD1krqPZkw@mail.gmail.com>
Brandon Casey <drafnel@gmail.com> writes:
> On Wed, Aug 22, 2012 at 9:30 AM, Joachim Schmitz
> <jojo@schmitz-digital.de> wrote:
>
>> OK, so how about this:
>> /usr/local/bin/diff -EBbu ./compat/mkdir.c.orig ./compat/mkdir.c
>> --- ./compat/mkdir.c.orig 2012-08-21 05:02:11 -0500
>> +++ ./compat/mkdir.c 2012-08-21 05:02:11 -0500
>> @@ -0,0 +1,24 @@
>> +#include "../git-compat-util.h"
>> +#undef mkdir
>> +
>> +/* for platforms that can't deal with a trailing '/' */
>> +int compat_mkdir_wo_trailing_slash(const char *dir, mode_t mode)
>> +{
>> + int retval;
>> + char *tmp_dir = NULL;
>> + size_t len = strlen(dir);
>> + ...
> Why not rearrange this so that you assign to dir the value of tmp_dir
> and then just pass dir to mkdir. Then you can avoid the recast of dir
> to (char*) in the else branch. Later, just call free(tmp_dir). Also,
> we have xstrndup. So I think the body of your function can become
> something like:
>
> if (len && dir[len-1] == '/')
> dir = tmp_dir = xstrndup(dir, len-1);
>
> retval = mkdir(dir, mode);
> free(tmp_dir);
Nice. And we have xmemdupz() would be even better as you
followed-up.
Thanks.
^ permalink raw reply
* Re: [PATCH 1/1] tcp: Wrong timeout for SYN segments
From: H.K. Jerry Chu @ 2012-08-22 17:29 UTC (permalink / raw)
To: Eric Dumazet
Cc: Alex Bergmann, davem, netdev, linux-kernel, Jerry Chu,
Neal Cardwell, Nandita Dukkipati
In-Reply-To: <1345629806.5158.933.camel@edumazet-glaptop>
On Wed, Aug 22, 2012 at 3:03 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Wed, 2012-08-22 at 12:00 +0200, Eric Dumazet wrote:
>> On Wed, 2012-08-22 at 11:29 +0200, Alex Bergmann wrote:
>>
>> > Actual 6 SYN frames are sent. The initial one and 5 retries.
>> >
>>
>> first one had a t0 + 0 delay. How can it count ???
>>
>> > The kernel is waiting another 32 seconds for a SYN+ACK and then gives
>> > the ETIMEDOUT back to userspace.
>> >
>> > Do you mean that we have to send another SYN packet after the 3 minutes?
>> >
>>
>> First SYN is not a retransmit
>>
>> R2 = time_of_last_SYN - time_of_initial_SYN (t0) = 31
>>
>> If you read RFC it states :
>>
>> "In particular, R2 for a SYN segment MUST
>> be set large enough to provide retransmission of the segment
>> for at least 3 minutes."
>>
>>
>> That means that the last _retransmit_ MUST happen after 180 seconds.
>>
>> And not :
>>
>> Send all the restransmits at t0 + 1, then wait 180 seconds before giving
>> connect() a timeout indication.
>>
>>
>
> Therefore, the minimal connect() timeout should be : 180 + 100 seconds
>
> (allowing 100 seconds for the SYNACKs sent in answer of the very last
> retransmit to come back)
>
> (100 seconds is the R2 for non SYN frames)
>
> RFC quote : The value of R2 SHOULD
> correspond to at least 100 seconds.
I agree if you take RFC1122 literally the last retransmission must
happen no less than 3 minutes from the 1st SYN... Oh actually it'd be
3 minutes plus initRTO because the 3 minutes applies only to
"retransmission" as in
"R2 for a SYN segment MUST be set large enough to provide retransmission
of the segment for at least 3 minutes.:
But IMHO 6 retries providing 1+2+4+8+16+32 = 63 secs retransmission plus
64 secs wait time totaling 127 secs is really plenty enough.
You have a good point on SYN-ACK.
Jerry
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" 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] Don't use curl_easy_strerror prior to curl-7.12.0
From: Joachim Schmitz @ 2012-08-22 17:28 UTC (permalink / raw)
To: 'Junio C Hamano'; +Cc: git
In-Reply-To: <7v8vd6alqe.fsf@alter.siamese.dyndns.org>
> From: Junio C Hamano [mailto:gitster@pobox.com]
> Sent: Wednesday, August 22, 2012 7:19 PM
> To: Joachim Schmitz
> Cc: git@vger.kernel.org
> Subject: Re: [PATCH] Don't use curl_easy_strerror prior to curl-7.12.0
>
> "Joachim Schmitz" <jojo@schmitz-digital.de> writes:
>
> > Signed-off-by: Joachim Schmitz <jojo@schmitz-digital.de>
>
> At the very least, please mention that this reverts be22d92 (http:
> avoid empty error messages for some curl errors, 2011-09-05) on platforms
> with older versions of libcURL.
a) Of course I didn't know that, thanks for telling me.
b) How and where to add that? In the Subject of an email, in the body, right
at the front?
Like this:
----
This reverts be22d92 (http: avoid empty error messages for some curl errors,
2011-09-05) on platforms with older versions of libcURL.
Signed-off-by: Joachim Schmitz <jojo@schmitz-digital.de>
---
http.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/http.c b/http.c
index b61ac85..18bc6bf 100644
--- a/http.c
+++ b/http.c
@@ -806,10 +806,12 @@ static int http_request(const char *url, void *result,
int target, int options)
ret = HTTP_REAUTH;
}
} else {
+#if LIBCURL_VERSION_NUM >= 0x070c00
if (!curl_errorstr[0])
strlcpy(curl_errorstr,
curl_easy_strerror(results.curl_result),
sizeof(curl_errorstr));
+#endif
ret = HTTP_ERROR;
}
} else {
--
1.7.12
Bye, Jojo
^ permalink raw reply related
* Re: [PATCH 2/3] x86_64: Define 128-bit memory-mapped I/O operations
From: Ben Hutchings @ 2012-08-22 17:27 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Linus Torvalds, David Laight, Benjamin LaHaise, David Miller,
tglx, mingo, netdev, linux-net-drivers, x86
In-Reply-To: <50351304.20608@zytor.com>
On Wed, 2012-08-22 at 10:12 -0700, H. Peter Anvin wrote:
> On 08/22/2012 10:09 AM, Ben Hutchings wrote:
> >
> > Well, sure, I'm assuming that the driver is responsible for checking
> > that the device and its bus interface support an MMIO of the requested
> > width.
> >
> > But the architecture code must be responsible for reporting whether the
> > host supports it, right?
> >
>
> No, the architecture code *can't*.
So, let me check that I understand this right:
- To support 32-bit architectures, a driver should include one of two
different definitions of readq/writeq depending on which order the
device needs to receive 32-bit operations.
- On 64-bit architectures (or at least x86_64), the system might split
up readq/writeq into 32-bit operations in unspecified order, and the
driver can't control this.
If this is right, how can it be safe to use readq/writeq at all?
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [RFC][PATCH] Disintegrate sharpsl_param.c
From: dromede at gmail.com @ 2012-08-22 17:27 UTC (permalink / raw)
To: linux-arm-kernel
From: Marko Katic <dromede.gmail.com>
I recently tried running 3.6-rc2 kernel on my Sharp Zaurus C-1000. It
hanged almost immediately after uncompressing the kernel. I tracked the
problem down to a single line in arch/arm/common/sharpsl_param.c:
memcpy(&sharpsl_param, (void *)PARAM_BASE, sizeof(struct sharpsl_param_info));
Commenting out the line makes the kernel boot just fine. This left me
wondering whether sharpsl_param.c is actually needed. Here's a comment
from sharpsl_param.c that describes what sharpsl_param.c actually does:
/*
* Certain hardware parameters determined at the time of device manufacture,
* typically including LCD parameters are loaded by the bootloader at the
* address PARAM_BASE. As the kernel will overwrite them, we need to store
* them early in the boot process, then pass them to the appropriate drivers.
* Not all devices use all parameters but the format is common to all.
*/
So sharpsl_save_param() is supposed to fill the sharpsl_param_info struct
with various parameters or fill some of the struct fields with -1.
I found only four drivers that use some of these
parameters (only two parameters are used by these drivers, comadj and phadadj).
These drivers are:
drivers/video/backlight/corgi_lcd.c
drivers/video/backlight/locomolcd.c
drivers/video/backlight/tosa_bl.c
drivers/video/backlight/tosa_lcd.c
These drivers also have default values when comadj or phadadj == -1.
I checked what values are actually contained in this struct in
earlier kernels. 3.2.24 kernel is the latest one i know of where
sharpsl_save_param() works properly. And it also has these fields initialised
to -1.
So it seems to me that sharpsl_param.c is redundant as it currently only
serves to assign -1 to a few variables. And drivers that use these variables
then handle -1 with assigning default values.
I propose a patch that completely removes the usage of sharpsl_param.c.
I confirm that this patch works fine on a C-1000 and therefore i assume that
it should work fine on all machines that use the corgi_lcd.c driver.
This patch should be tested on collie and tosa machines.
---
arch/arm/common/Kconfig | 3 -
arch/arm/common/Makefile | 1 -
arch/arm/common/sharpsl_param.c | 62 -----------------------------
arch/arm/include/asm/mach/sharpsl_param.h | 37 -----------------
arch/arm/mach-pxa/Kconfig | 1 -
arch/arm/mach-pxa/corgi.c | 2 -
arch/arm/mach-pxa/poodle.c | 2 -
arch/arm/mach-pxa/spitz.c | 2 -
arch/arm/mach-pxa/tosa.c | 2 -
arch/arm/mach-sa1100/Kconfig | 1 -
arch/arm/mach-sa1100/collie.c | 2 -
drivers/power/collie_battery.c | 1 -
drivers/video/backlight/corgi_lcd.c | 9 +---
drivers/video/backlight/locomolcd.c | 8 +--
drivers/video/backlight/tosa_bl.c | 4 +-
drivers/video/backlight/tosa_lcd.c | 2 -
16 files changed, 6 insertions(+), 133 deletions(-)
delete mode 100644 arch/arm/common/sharpsl_param.c
delete mode 100644 arch/arm/include/asm/mach/sharpsl_param.h
diff --git a/arch/arm/common/Kconfig b/arch/arm/common/Kconfig
index 283fa1d..8a2688a 100644
--- a/arch/arm/common/Kconfig
+++ b/arch/arm/common/Kconfig
@@ -35,8 +35,5 @@ config DMABOUNCE
config SHARP_LOCOMO
bool
-config SHARP_PARAM
- bool
-
config SHARP_SCOOP
bool
diff --git a/arch/arm/common/Makefile b/arch/arm/common/Makefile
index e8a4e58..c8634c8 100644
--- a/arch/arm/common/Makefile
+++ b/arch/arm/common/Makefile
@@ -9,7 +9,6 @@ obj-$(CONFIG_SA1111) += sa1111.o
obj-$(CONFIG_PCI_HOST_VIA82C505) += via82c505.o
obj-$(CONFIG_DMABOUNCE) += dmabounce.o
obj-$(CONFIG_SHARP_LOCOMO) += locomo.o
-obj-$(CONFIG_SHARP_PARAM) += sharpsl_param.o
obj-$(CONFIG_SHARP_SCOOP) += scoop.o
obj-$(CONFIG_PCI_HOST_ITE8152) += it8152.o
obj-$(CONFIG_ARM_TIMER_SP804) += timer-sp.o
diff --git a/arch/arm/common/sharpsl_param.c b/arch/arm/common/sharpsl_param.c
deleted file mode 100644
index d56c932..0000000
--- a/arch/arm/common/sharpsl_param.c
+++ /dev/null
@@ -1,62 +0,0 @@
-/*
- * Hardware parameter area specific to Sharp SL series devices
- *
- * Copyright (c) 2005 Richard Purdie
- *
- * Based on Sharp's 2.4 kernel patches
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- */
-
-#include <linux/kernel.h>
-#include <linux/module.h>
-#include <linux/string.h>
-#include <asm/mach/sharpsl_param.h>
-
-/*
- * Certain hardware parameters determined at the time of device manufacture,
- * typically including LCD parameters are loaded by the bootloader at the
- * address PARAM_BASE. As the kernel will overwrite them, we need to store
- * them early in the boot process, then pass them to the appropriate drivers.
- * Not all devices use all parameters but the format is common to all.
- */
-#ifdef CONFIG_ARCH_SA1100
-#define PARAM_BASE 0xe8ffc000
-#else
-#define PARAM_BASE 0xa0000a00
-#endif
-#define MAGIC_CHG(a,b,c,d) ( ( d << 24 ) | ( c << 16 ) | ( b << 8 ) | a )
-
-#define COMADJ_MAGIC MAGIC_CHG('C','M','A','D')
-#define UUID_MAGIC MAGIC_CHG('U','U','I','D')
-#define TOUCH_MAGIC MAGIC_CHG('T','U','C','H')
-#define AD_MAGIC MAGIC_CHG('B','V','A','D')
-#define PHAD_MAGIC MAGIC_CHG('P','H','A','D')
-
-struct sharpsl_param_info sharpsl_param;
-EXPORT_SYMBOL(sharpsl_param);
-
-void sharpsl_save_param(void)
-{
- memcpy(&sharpsl_param, (void *)PARAM_BASE, sizeof(struct sharpsl_param_info));
-
- if (sharpsl_param.comadj_keyword != COMADJ_MAGIC)
- sharpsl_param.comadj=-1;
-
- if (sharpsl_param.phad_keyword != PHAD_MAGIC)
- sharpsl_param.phadadj=-1;
-
- if (sharpsl_param.uuid_keyword != UUID_MAGIC)
- sharpsl_param.uuid[0]=-1;
-
- if (sharpsl_param.touch_keyword != TOUCH_MAGIC)
- sharpsl_param.touch_xp=-1;
-
- if (sharpsl_param.adadj_keyword != AD_MAGIC)
- sharpsl_param.adadj=-1;
-}
-
-
diff --git a/arch/arm/include/asm/mach/sharpsl_param.h b/arch/arm/include/asm/mach/sharpsl_param.h
deleted file mode 100644
index 7a24ecf..0000000
--- a/arch/arm/include/asm/mach/sharpsl_param.h
+++ /dev/null
@@ -1,37 +0,0 @@
-/*
- * Hardware parameter area specific to Sharp SL series devices
- *
- * Copyright (c) 2005 Richard Purdie
- *
- * Based on Sharp's 2.4 kernel patches
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- */
-
-struct sharpsl_param_info {
- unsigned int comadj_keyword;
- unsigned int comadj;
-
- unsigned int uuid_keyword;
- unsigned char uuid[16];
-
- unsigned int touch_keyword;
- unsigned int touch_xp;
- unsigned int touch_yp;
- unsigned int touch_xd;
- unsigned int touch_yd;
-
- unsigned int adadj_keyword;
- unsigned int adadj;
-
- unsigned int phad_keyword;
- unsigned int phadadj;
-} __attribute__((packed));
-
-
-extern struct sharpsl_param_info sharpsl_param;
-extern void sharpsl_save_param(void);
-
diff --git a/arch/arm/mach-pxa/Kconfig b/arch/arm/mach-pxa/Kconfig
index fe2d1f8..71e9429 100644
--- a/arch/arm/mach-pxa/Kconfig
+++ b/arch/arm/mach-pxa/Kconfig
@@ -471,7 +471,6 @@ config MACH_RAUMFELD_SPEAKER
config PXA_SHARPSL
bool "SHARP Zaurus SL-5600, SL-C7xx and SL-Cxx00 Models"
select SHARP_SCOOP
- select SHARP_PARAM
help
Say Y here if you intend to run this kernel on a
Sharp Zaurus SL-5600 (Poodle), SL-C700 (Corgi),
diff --git a/arch/arm/mach-pxa/corgi.c b/arch/arm/mach-pxa/corgi.c
index c1fe32d..1ddf87f 100644
--- a/arch/arm/mach-pxa/corgi.c
+++ b/arch/arm/mach-pxa/corgi.c
@@ -52,7 +52,6 @@
#include <mach/corgi.h>
#include <mach/sharpsl_pm.h>
-#include <asm/mach/sharpsl_param.h>
#include <asm/hardware/scoop.h>
#include "generic.h"
@@ -716,7 +715,6 @@ static void __init corgi_init(void)
static void __init fixup_corgi(struct tag *tags, char **cmdline,
struct meminfo *mi)
{
- sharpsl_save_param();
mi->nr_banks=1;
mi->bank[0].start = 0xa0000000;
if (machine_is_corgi())
diff --git a/arch/arm/mach-pxa/poodle.c b/arch/arm/mach-pxa/poodle.c
index 89d98c8..0c4c083 100644
--- a/arch/arm/mach-pxa/poodle.c
+++ b/arch/arm/mach-pxa/poodle.c
@@ -48,7 +48,6 @@
#include <asm/hardware/scoop.h>
#include <asm/hardware/locomo.h>
-#include <asm/mach/sharpsl_param.h>
#include "generic.h"
#include "devices.h"
@@ -457,7 +456,6 @@ static void __init poodle_init(void)
static void __init fixup_poodle(struct tag *tags, char **cmdline,
struct meminfo *mi)
{
- sharpsl_save_param();
mi->nr_banks=1;
mi->bank[0].start = 0xa0000000;
mi->bank[0].size = (32*1024*1024);
diff --git a/arch/arm/mach-pxa/spitz.c b/arch/arm/mach-pxa/spitz.c
index 363d91b..9a0d583 100644
--- a/arch/arm/mach-pxa/spitz.c
+++ b/arch/arm/mach-pxa/spitz.c
@@ -35,7 +35,6 @@
#include <asm/setup.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
-#include <asm/mach/sharpsl_param.h>
#include <asm/hardware/scoop.h>
#include <mach/pxa27x.h>
@@ -971,7 +970,6 @@ static void __init spitz_init(void)
static void __init spitz_fixup(struct tag *tags, char **cmdline,
struct meminfo *mi)
{
- sharpsl_save_param();
mi->nr_banks = 1;
mi->bank[0].start = 0xa0000000;
mi->bank[0].size = (64*1024*1024);
diff --git a/arch/arm/mach-pxa/tosa.c b/arch/arm/mach-pxa/tosa.c
index 4d4eb60..3f8fe17 100644
--- a/arch/arm/mach-pxa/tosa.c
+++ b/arch/arm/mach-pxa/tosa.c
@@ -53,7 +53,6 @@
#include <mach/tosa.h>
#include <asm/hardware/scoop.h>
-#include <asm/mach/sharpsl_param.h>
#include "generic.h"
#include "clock.h"
@@ -968,7 +967,6 @@ static void __init tosa_init(void)
static void __init fixup_tosa(struct tag *tags, char **cmdline,
struct meminfo *mi)
{
- sharpsl_save_param();
mi->nr_banks=1;
mi->bank[0].start = 0xa0000000;
mi->bank[0].size = (64*1024*1024);
diff --git a/arch/arm/mach-sa1100/Kconfig b/arch/arm/mach-sa1100/Kconfig
index 42625e4..87b8604 100644
--- a/arch/arm/mach-sa1100/Kconfig
+++ b/arch/arm/mach-sa1100/Kconfig
@@ -50,7 +50,6 @@ config SA1100_COLLIE
# FIXME: select CPU_FREQ_SA11x0
select SHARP_LOCOMO
select SHARP_SCOOP
- select SHARP_PARAM
help
Say Y here to support the Sharp Zaurus SL5500 PDAs.
diff --git a/arch/arm/mach-sa1100/collie.c b/arch/arm/mach-sa1100/collie.c
index ea5cff3..98287a4 100644
--- a/arch/arm/mach-sa1100/collie.c
+++ b/arch/arm/mach-sa1100/collie.c
@@ -43,7 +43,6 @@
#include <asm/mach/serial_sa1100.h>
#include <asm/hardware/scoop.h>
-#include <asm/mach/sharpsl_param.h>
#include <asm/hardware/locomo.h>
#include <mach/mcp.h>
#include <mach/irqs.h>
@@ -366,7 +365,6 @@ static void __init collie_init(void)
ARRAY_SIZE(collie_flash_resources));
sa11x0_register_mcp(&collie_mcp_data);
- sharpsl_save_param();
}
static struct map_desc collie_io_desc[] __initdata = {
diff --git a/drivers/power/collie_battery.c b/drivers/power/collie_battery.c
index 74c6b23..e83b963 100644
--- a/drivers/power/collie_battery.c
+++ b/drivers/power/collie_battery.c
@@ -19,7 +19,6 @@
#include <linux/gpio.h>
#include <linux/mfd/ucb1x00.h>
-#include <asm/mach/sharpsl_param.h>
#include <asm/mach-types.h>
#include <mach/collie.h>
diff --git a/drivers/video/backlight/corgi_lcd.c b/drivers/video/backlight/corgi_lcd.c
index c781768..c28838a 100644
--- a/drivers/video/backlight/corgi_lcd.c
+++ b/drivers/video/backlight/corgi_lcd.c
@@ -25,7 +25,6 @@
#include <linux/spi/spi.h>
#include <linux/spi/corgi_lcd.h>
#include <linux/slab.h>
-#include <asm/mach/sharpsl_param.h>
#define POWER_IS_ON(pwr) ((pwr) <= FB_BLANK_NORMAL)
@@ -195,9 +194,7 @@ static void lcdtg_set_phadadj(struct corgi_lcd *lcd, int mode)
switch(mode) {
case CORGI_LCD_MODE_VGA:
/* Setting for VGA */
- adj = sharpsl_param.phadadj;
- adj = (adj < 0) ? PHACTRL_PHASE_MANUAL :
- PHACTRL_PHASE_MANUAL | ((adj & 0xf) << 1);
+ adj = PHACTRL_PHASE_MANUAL;
break;
case CORGI_LCD_MODE_QVGA:
default:
@@ -242,9 +239,7 @@ static void corgi_lcd_power_on(struct corgi_lcd *lcd)
PICTRL_INIT_STATE | PICTRL_COM_SIGNAL_OFF);
/* Set Common Voltage */
- comadj = sharpsl_param.comadj;
- if (comadj < 0)
- comadj = DEFAULT_COMADJ;
+ comadj = DEFAULT_COMADJ;
lcdtg_set_common_voltage(lcd, POWER0_DAC_ON | POWER0_COM_OFF |
POWER0_VCC5_OFF, comadj);
diff --git a/drivers/video/backlight/locomolcd.c b/drivers/video/backlight/locomolcd.c
index 3a6d541..62c4cb9 100644
--- a/drivers/video/backlight/locomolcd.c
+++ b/drivers/video/backlight/locomolcd.c
@@ -21,7 +21,6 @@
#include <asm/hardware/locomo.h>
#include <asm/irq.h>
-#include <asm/mach/sharpsl_param.h>
#include <asm/mach-types.h>
#include "../../../arch/arm/mach-sa1100/generic.h"
@@ -82,7 +81,7 @@ static void locomolcd_off(int comadj)
void locomolcd_power(int on)
{
- int comadj = sharpsl_param.comadj;
+ int comadj;
unsigned long flags;
local_irq_save(flags);
@@ -92,10 +91,9 @@ void locomolcd_power(int on)
return;
}
- /* read comadj */
- if (comadj == -1 && machine_is_collie())
+ if (machine_is_collie())
comadj = 128;
- if (comadj == -1 && machine_is_poodle())
+ if (machine_is_poodle())
comadj = 118;
if (on)
diff --git a/drivers/video/backlight/tosa_bl.c b/drivers/video/backlight/tosa_bl.c
index 49342e1..2918075 100644
--- a/drivers/video/backlight/tosa_bl.c
+++ b/drivers/video/backlight/tosa_bl.c
@@ -20,8 +20,6 @@
#include <linux/backlight.h>
#include <linux/slab.h>
-#include <asm/mach/sharpsl_param.h>
-
#include <mach/tosa.h>
#define COMADJ_DEFAULT 97
@@ -90,7 +88,7 @@ static int __devinit tosa_bl_probe(struct i2c_client *client,
if (!data)
return -ENOMEM;
- data->comadj = sharpsl_param.comadj == -1 ? COMADJ_DEFAULT : sharpsl_param.comadj;
+ data->comadj = COMADJ_DEFAULT;
ret = devm_gpio_request(&client->dev, TOSA_GPIO_BL_C20MA, "backlight");
if (ret) {
diff --git a/drivers/video/backlight/tosa_lcd.c b/drivers/video/backlight/tosa_lcd.c
index 33047a66..6fc575f 100644
--- a/drivers/video/backlight/tosa_lcd.c
+++ b/drivers/video/backlight/tosa_lcd.c
@@ -21,8 +21,6 @@
#include <linux/lcd.h>
#include <linux/fb.h>
-#include <asm/mach/sharpsl_param.h>
-
#include <mach/tosa.h>
#define POWER_IS_ON(pwr) ((pwr) <= FB_BLANK_NORMAL)
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH v2 00/16] Clean up drivers/pci/remove.c
From: Bjorn Helgaas @ 2012-08-22 17:26 UTC (permalink / raw)
To: Yijing Wang; +Cc: linux-pci, linux-pcmcia, Yinghai Lu, Kenji Kaneshige
In-Reply-To: <50330473.6030902@huawei.com>
On Mon, Aug 20, 2012 at 8:45 PM, Yijing Wang <wangyijing@huawei.com> wrote:
> On 2012/8/20 23:40, Bjorn Helgaas wrote:
>> On Sun, Aug 19, 2012 at 10:58 PM, Yijing Wang <wangyijing@huawei.com> wrote:
>>> tested-by Yijing Wang <wangyijing@huawei.com>
>>
>> Great, thanks for trying this out! Can you give me any details on
>> what you tested (what sort of machine, which hotplug driver, PCIe
>> button/LED style hotplug or ExpressCard style, etc?)
>>
>
> Hi Bjorn,
> I tested these patches in IA_64, and use acpiphp driver to do the hot-plug test.
> The hotplug action was triggered via sysfs interface(/sys/bus/pci/slots/xxx/).
> The target pcie devices were fibre channel card and Intel 82576 card.As bellow:
Thanks, that's perfect! It's especially good to test acpiphp because
that was one of the "not completely obvious" changes.
I added your Tested-by: to the acpiphp and the PCI core patches; let
me know if that's not what you intended.
> 0000:40:07.0 root port supports hotplug by acpiphp.
> hot plug 0000:46:00.0 and its child devices and buses.
>
> -+-[0000:40]-+-00.0-[0000:41]--
> | +-01.0-[0000:42]--+-00.0 Intel Corporation 82576 Gigabit Network Connection
> | | \-00.1 Intel Corporation 82576 Gigabit Network Connection
> | +-03.0-[0000:43]----00.0 LSI Logic / Symbios Logic SAS1064ET PCI-Express Fusion-MPT SAS
> | +-04.0-[0000:44]--
> | +-05.0-[0000:45]--
> | +-07.0-[0000:46-49]----00.0-[0000:47-49]--+-02.0-[0000:48]--+-00.0 Intel Corporation 82576 Gigabit Network Connection
> | | | \-00.1 Intel Corporation 82576 Gigabit Network Connection
> | | \-04.0-[0000:49]--+-00.0 Intel Corporation 82576 Gigabit Network Connection
> | | \-00.1 Intel Corporation 82576 Gigabit Network Connection
>
> after hot remove
> -+-[0000:40]-+-00.0-[0000:41]--
> | +-01.0-[0000:42]--+-00.0 Intel Corporation 82576 Gigabit Network Connection
> | | \-00.1 Intel Corporation 82576 Gigabit Network Connection
> | +-03.0-[0000:43]----00.0 LSI Logic / Symbios Logic SAS1064ET PCI-Express Fusion-MPT SAS
> | +-04.0-[0000:44]--
> | +-05.0-[0000:45]--
> | +-07.0-[0000:46-49]--
>
>
>>>> This started as a simple conversion of list_for_each() to
>>>> list_for_each_entry(), so I could remove the pci_dev_b() helper.
>>>>
>>>> In the process, I noticed that drivers/pci/remove.c is getting a little
>>>> crufty, so I reworked it to make it more understandable. This is a long
>>>> series of small patches, so it might be easiest to start by looking at the
>>>> end product, so you have some idea where I'm heading.
>
>
>
> --
> Thanks!
> Yijing
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" 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 2/3] x86_64: Define 128-bit memory-mapped I/O operations
From: Linus Torvalds @ 2012-08-22 17:26 UTC (permalink / raw)
To: Ben Hutchings
Cc: H. Peter Anvin, David Laight, Benjamin LaHaise, David Miller,
tglx, mingo, netdev, linux-net-drivers, x86
In-Reply-To: <1345655343.2709.56.camel@bwh-desktop.uk.solarflarecom.com>
On Wed, Aug 22, 2012 at 10:09 AM, Ben Hutchings
<bhutchings@solarflare.com> wrote:
>
> But the architecture code must be responsible for reporting whether the
> host supports it, right?
How? It's impossible. As far as the CPU is concerned, the writes
happen atomically. Look how you use it: you don't even query
dynamically about whether the stuff outside the CPU can handle atomic
128-bit writes. You just assume it at compile-time with an #ifdef. How
the hell do you expect that to be able to then say "oh, on this
machine the device you are doing the access to is behind an odd
PCI->PCIe bridge that will split the access"?
Not that we even tend to *know* those kinds of things. It's really
esoteric chipset knowledge. I wouldn't even expect it to be
necessarily documented in the chipset docs, it *might* be in some
NDA'd BIOS writer's guide thing.
You don't even seem to realize that things like the Intel FSB was
patented and wasn't fully documented by Intel at all? And that's for a
bus interface that was used for over a decade from the dominant CPU
manufacturer. What do you think happens with odd random chipsets? Who
do you expects to know?
I *suspect* that 128-bit writes would generally make it intact over
PCIe in real life, but I absolutely wouldn't guarantee it on all
machines. Exactly because of issues like "what happens with a nVidia
host bridge and the old FSB model on older Intel chips?" or "What does
the AMD memory pipeline do?".
Many CPU cores have 64-bit buses even *internally*, much less
externally. Yes, they have atomicity guarantees in their architecture
manual, but go look at it: those talk about memory accesses, and they
are based on cache coherency (these days - they *used* to be based on
certain bus guarantees). The MMIO side is a completely different
animal, and is still based on the bus - and nobody documents that,
afaik.
Linus
^ permalink raw reply
* Re: What's cooking in git.git (Aug 2012, #06; Tue, 21)
From: Junio C Hamano @ 2012-08-22 17:25 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <CACsJy8CVe53URvheehhGnxpOdhhidd67UY6OD5KD-X-f9hGBQg@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> On Wed, Aug 22, 2012 at 6:10 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> * nd/i18n-parseopt-help (2012-08-20) 54 commits
>> - i18n: shortlog: mark parseopt strings for translation
>> ...
>> - i18n: mark "style" in OPT_COLUMN() for translation
>>
>> A lot of i18n mark-up for the help text from "git <cmd> -h".
>
> It's a 66 patch series, but only 54 here. 55/66 [1] to 66/66 [2] did
> not make it to your inbox?
>
> [1] http://article.gmane.org/gmane.comp.version-control.git/203827
> [2] http://article.gmane.org/gmane.comp.version-control.git/203838
I do recall discarding one (the one about _(" tracked")), but
otherwise no I didn't throw anything else away on purpose.
Let me recheck. Thanks for letting me know.
^ permalink raw reply
* [PATCH] virt.netperf: Use ssh_key lib rather than off limits server lib
From: Lucas Meneghel Rodrigues @ 2012-08-22 17:24 UTC (permalink / raw)
To: autotest-kernel; +Cc: kvm, Lucas Meneghel Rodrigues, Amos Kong
When running the kvm autotest tests on a given host through
the autotest server, it's important to remember that only
the autotest client is copied to machines, making anything
that is not on the autotest.client namespace *off-limits*.
So, replace usage of SSHHost server class (here used only
to get ssh key setup) to use the ssh_key module, recently
split out due to a similar mistake made by test authors.
CC: Amos Kong <akong@redhat.com>
Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>
---
client/virt/tests/netperf.py | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/client/virt/tests/netperf.py b/client/virt/tests/netperf.py
index c054c10..e137d45 100644
--- a/client/virt/tests/netperf.py
+++ b/client/virt/tests/netperf.py
@@ -1,6 +1,6 @@
import logging, os, commands, threading, re, glob
-from autotest.server.hosts.ssh_host import SSHHost
from autotest.client import utils
+from autotest.client.shared import ssh_key
from autotest.client.virt import utils_test, utils_misc, remote
@@ -60,7 +60,8 @@ def run_netperf(test, params, env):
def env_setup(ip):
logging.debug("Setup env for %s" % ip)
- SSHHost(ip, user=username, port=shell_port, password=password)
+ ssh_key.setup_ssh_key(hostname=ip, user=username, port=shell_port,
+ password=password)
ssh_cmd(ip, "service iptables stop")
ssh_cmd(ip, "echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore")
--
1.7.11.4
^ permalink raw reply related
* Re: [Qemu-devel] Windows slow boot: contractor wanted
From: Troy Benjegerdes @ 2012-08-22 17:22 UTC (permalink / raw)
To: Avi Kivity; +Cc: Richard Davies, kvm, qemu-devel
In-Reply-To: <5034F24D.1090105@redhat.com>
> > I've now triggered a very slow boot at 3x 36GB 8-core VMs on a 128GB host
> > (i.e. 108GB on a 128GB host).
> >
> > It has the same profile with _raw_spin_lock_irqsave and
> > isolate_freepages_block at the top.
>
> Then it's still memory starved.
>
> Please provide /proc/zoneinfo while this is happening.
Is there a way to capture/reproduce this 'slow boot' behavior with
a simple regression test? I'd like to know if it happens on a
single-physical CPU socket machine, or just on dual-sockets.
I'm also observing an interesting phenomenon here.. Kernel development
can move so fast as to make regression testing pointless. ;)
^ permalink raw reply
* Re: Porting git to HP NonStop
From: Brandon Casey @ 2012-08-22 17:23 UTC (permalink / raw)
To: Joachim Schmitz; +Cc: Junio C Hamano, Shawn Pearce, git, rsbecker
In-Reply-To: <002f01cd808a$2e027e90$8a077bb0$@schmitz-digital.de>
On Wed, Aug 22, 2012 at 10:18 AM, Joachim Schmitz
<jojo@schmitz-digital.de> wrote:
>> From: Brandon Casey [mailto:drafnel@gmail.com]
>> Sent: Wednesday, August 22, 2012 7:01 PM
>> To: Joachim Schmitz
>> Cc: Junio C Hamano; Shawn Pearce; git@vger.kernel.org;
>> rsbecker@nexbridge.com
>> Subject: Re: Porting git to HP NonStop
>>
>> On Wed, Aug 22, 2012 at 9:30 AM, Joachim Schmitz <jojo@schmitz-digital.de>
>> wrote:
>>
>> > OK, so how about this:
>> > /usr/local/bin/diff -EBbu ./compat/mkdir.c.orig ./compat/mkdir.c
>> > --- ./compat/mkdir.c.orig 2012-08-21 05:02:11 -0500
>> > +++ ./compat/mkdir.c 2012-08-21 05:02:11 -0500
>> > @@ -0,0 +1,24 @@
>> > +#include "../git-compat-util.h"
>> > +#undef mkdir
>> > +
>> > +/* for platforms that can't deal with a trailing '/' */ int
>> > +compat_mkdir_wo_trailing_slash(const char *dir, mode_t mode) {
>> > + int retval;
>> > + char *tmp_dir = NULL;
>> > + size_t len = strlen(dir);
>> > +
>> > + if (len && dir[len-1] == '/') {
>> > + if ((tmp_dir = strdup(dir)) == NULL)
>> > + return -1;
>> > + tmp_dir[len-1] = '\0';
>> > + }
>> > + else
>> > + tmp_dir = (char *)dir;
>> > +
>> > + retval = mkdir(tmp_dir, mode);
>> > + if (tmp_dir != dir)
>> > + free(tmp_dir);
>> > +
>> > + return retval;
>> > +}
>>
>> Why not rearrange this so that you assign to dir the value of tmp_dir and then
>> just pass dir to mkdir. Then you can avoid the recast of dir to (char*) in the
>> else branch. Later, just call free(tmp_dir). Also, we have xstrndup. So I think
>> the body of your function can become something like:
>>
>> if (len && dir[len-1] == '/')
>> dir = tmp_dir = xstrndup(dir, len-1);
>
> xstndup() can't fail?
Correct. It will either succeed or die. It will also try to free up
some memory used by git if possible.
-Brandon
^ permalink raw reply
* Re: [PATCH] Prefer sysconf(_SC_OPEN_MAX) over getrlimit(RLIMIT_NOFILE,...)
From: Junio C Hamano @ 2012-08-22 17:23 UTC (permalink / raw)
To: Joachim Schmitz; +Cc: git
In-Reply-To: <002301cd807f$4e19ad80$ea4d0880$@schmitz-digital.de>
"Joachim Schmitz" <jojo@schmitz-digital.de> writes:
> Signed-off-by: Joachim Schmitz <jojo@schmitz-digital.de>
> ---
> sha1_file.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/sha1_file.c b/sha1_file.c
> index af5cfbd..76714ad 100644
> --- a/sha1_file.c
> +++ b/sha1_file.c
> @@ -747,6 +747,9 @@ static int open_packed_git_1(struct packed_git *p)
> return error("packfile %s index unavailable", p->pack_name);
>
> if (!pack_max_fds) {
> +#ifdef _SC_OPEN_MAX
> + unsigned int max_fds = sysconf(_SC_OPEN_MAX);
> +#else
> struct rlimit lim;
> unsigned int max_fds;
>
> @@ -754,6 +757,7 @@ static int open_packed_git_1(struct packed_git *p)
> die_errno("cannot get RLIMIT_NOFILE");
>
> max_fds = lim.rlim_cur;
> +#endif
>
> /* Save 3 for stdin/stdout/stderr, 22 for work */
> if (25 < max_fds)
> --
> 1.7.12
Looks sane but it would be more readable to make this a small helper
function, so that we do not need to have #ifdef/#endif in the
primary flow of the code.
By the way, I noticed that you seem to be sending patches out of
git, instead of "diff -ru", which is a good sign ;-). But all of
your patches are whitespace damaged and cannot be applied X-<.
^ permalink raw reply
* Re: [Qemu-devel] Windows slow boot: contractor wanted
From: Troy Benjegerdes @ 2012-08-22 17:22 UTC (permalink / raw)
To: Avi Kivity; +Cc: Richard Davies, qemu-devel, kvm
In-Reply-To: <5034F24D.1090105@redhat.com>
> > I've now triggered a very slow boot at 3x 36GB 8-core VMs on a 128GB host
> > (i.e. 108GB on a 128GB host).
> >
> > It has the same profile with _raw_spin_lock_irqsave and
> > isolate_freepages_block at the top.
>
> Then it's still memory starved.
>
> Please provide /proc/zoneinfo while this is happening.
Is there a way to capture/reproduce this 'slow boot' behavior with
a simple regression test? I'd like to know if it happens on a
single-physical CPU socket machine, or just on dual-sockets.
I'm also observing an interesting phenomenon here.. Kernel development
can move so fast as to make regression testing pointless. ;)
^ permalink raw reply
* Re: [PATCH 2/6] ARM: omap: allow building omap44xx without SMP
From: Arnd Bergmann @ 2012-08-22 17:22 UTC (permalink / raw)
To: Shilimkar, Santosh
Cc: linux-arm-kernel, Russell King, linux-kernel, Kevin Hilman,
Tony Lindgren
In-Reply-To: <CAMQu2gw0x6saWrK-M3teu49tJDGvS8RhGrVSh6JTs5DEy+22pA@mail.gmail.com>
On Wednesday 22 August 2012, Shilimkar, Santosh wrote:
> Was just thinking whether we should just take care of it at
> core cpuidle level itself. Will below be enough to kill the build
> error what you mentioned in the change log ?
>
> diff --git a/drivers/cpuidle/coupled.c b/drivers/cpuidle/coupled.c
> index 2c9bf26..df34534 100644
> --- a/drivers/cpuidle/coupled.c
> +++ b/drivers/cpuidle/coupled.c
> @@ -314,7 +314,9 @@ static void cpuidle_coupled_poke(int cpu)
> struct call_single_data *csd = &per_cpu(cpuidle_coupled_poke_cb, cpu);
>
> if (!cpumask_test_and_set_cpu(cpu, &cpuidle_coupled_poked_mask))
> +#ifdef CONFIG_SMP
> __smp_call_function_single(cpu, csd, 0);
> +#endif
> }
>
That would work, but isn't the entire concept of the cpuidle-coupled driver
dependent on SMP? If this driver makes no sense on UP, I think we should
not attempt to build it.
Arnd
^ permalink raw reply
* [PATCH 2/6] ARM: omap: allow building omap44xx without SMP
From: Arnd Bergmann @ 2012-08-22 17:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMQu2gw0x6saWrK-M3teu49tJDGvS8RhGrVSh6JTs5DEy+22pA@mail.gmail.com>
On Wednesday 22 August 2012, Shilimkar, Santosh wrote:
> Was just thinking whether we should just take care of it at
> core cpuidle level itself. Will below be enough to kill the build
> error what you mentioned in the change log ?
>
> diff --git a/drivers/cpuidle/coupled.c b/drivers/cpuidle/coupled.c
> index 2c9bf26..df34534 100644
> --- a/drivers/cpuidle/coupled.c
> +++ b/drivers/cpuidle/coupled.c
> @@ -314,7 +314,9 @@ static void cpuidle_coupled_poke(int cpu)
> struct call_single_data *csd = &per_cpu(cpuidle_coupled_poke_cb, cpu);
>
> if (!cpumask_test_and_set_cpu(cpu, &cpuidle_coupled_poked_mask))
> +#ifdef CONFIG_SMP
> __smp_call_function_single(cpu, csd, 0);
> +#endif
> }
>
That would work, but isn't the entire concept of the cpuidle-coupled driver
dependent on SMP? If this driver makes no sense on UP, I think we should
not attempt to build it.
Arnd
^ permalink raw reply
* [PATCH] ui/knotty: give out start time of task
From: Enrico Scholz @ 2012-08-22 17:09 UTC (permalink / raw)
To: bitbake-devel; +Cc: Enrico Scholz
For long running tasks like compiling qt it might be interesting to know
when the task has been started. Patch prints this information by using
the %X modifier (locale dependent presentation of time without date).
Signed-off-by: Enrico Scholz <enrico.scholz@sigma-chemnitz.de>
---
lib/bb/ui/knotty.py | 3 ++-
lib/bb/ui/uihelper.py | 4 +++-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/lib/bb/ui/knotty.py b/lib/bb/ui/knotty.py
index 858cacf..60d5886 100644
--- a/lib/bb/ui/knotty.py
+++ b/lib/bb/ui/knotty.py
@@ -190,7 +190,8 @@ class TerminalFilter(object):
return
tasks = []
for t in runningpids:
- tasks.append("%s (pid %s)" % (activetasks[t]["title"], t))
+ tasks.append("%s - %s (pid %s)" %
+ (activetasks[t]["started_str"], activetasks[t]["title"], t))
if self.main.shutdown:
content = "Waiting for %s running tasks to finish:" % len(activetasks)
diff --git a/lib/bb/ui/uihelper.py b/lib/bb/ui/uihelper.py
index e408b04..ae97c78 100644
--- a/lib/bb/ui/uihelper.py
+++ b/lib/bb/ui/uihelper.py
@@ -18,6 +18,7 @@
# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
import bb.build
+import time
class BBUIHelper:
def __init__(self):
@@ -31,7 +32,8 @@ class BBUIHelper:
def eventHandler(self, event):
if isinstance(event, bb.build.TaskStarted):
- self.running_tasks[event.pid] = { 'title' : "%s %s" % (event._package, event._task) }
+ self.running_tasks[event.pid] = { 'title' : "%s %s" % (event._package, event._task),
+ 'started_str' : time.strftime("%X") }
self.running_pids.append(event.pid)
self.needUpdate = True
if isinstance(event, bb.build.TaskSucceeded):
--
1.7.11.4
^ permalink raw reply related
* Re: [PATCH] recipes: Replace proto= with protocol= in SRC_URI
From: Denys Dmytriyenko @ 2012-08-22 17:20 UTC (permalink / raw)
To: Khem Raj; +Cc: meta-ti
In-Reply-To: <CAMKF1spkEvJNcs4fr75jbM9ByCFU__QfiJfZxQOjOUJ6hDdC0A@mail.gmail.com>
On Wed, Aug 22, 2012 at 10:07:30AM -0700, Khem Raj wrote:
> On Wed, Aug 22, 2012 at 8:24 AM, Denys Dmytriyenko <denys@ti.com> wrote:
> > On Wed, Aug 22, 2012 at 07:48:31AM -0700, Khem Raj wrote:
> >> protocol is supported proto is not.
> >>
> >> Signed-off-by: Khem Raj <raj.khem@gmail.com>
> >
> > So, how many times this needs fixing?
> >
>
> as many times as stale mirrors
>
> here is my problem
>
>
> [remote "origin"]
> fetch = +refs/heads/*:refs/remotes/origin/*
> url = git://github.com/Angstrom-distribution/meta-ti.git
>
> and master on that mirror is still at
>
> commit d3ff5630a74640f46ca2ceaef1aa1baa86b9b795
> Author: Andreas M??ller <schnitzeltony@googlemail.com>
> Date: Mon Jul 9 14:35:36 2012 +0200
>
> netbase: follow oe-core to v5.0
>
> Signed-off-by: Andreas M??ller <schnitzeltony@googlemail.com>
> Signed-off-by: Denys Dmytriyenko <denys@ti.com>
>
>
> Koen should angstrom still use meta-ti from github or from git.yp.org
> for angstrom-next ?
Sorry, still not convinced:
https://github.com/Angstrom-distribution/setup-scripts/blob/master/sources/layers.txt
https://github.com/Angstrom-distribution/setup-scripts/blob/next/sources/layers.txt
https://github.com/Angstrom-distribution/setup-scripts/blob/angstrom-v2012.05-yocto1.2/sources/layers.txt
All the branches point to the correct location of meta-ti on git.yp.org
Moreover, it was pointing there since March:
https://github.com/Angstrom-distribution/setup-scripts/commit/edc1ec58f60de2624dd376182e0d1d6c463675a0
I couldn't find in the history when it was ever pointing to that mirror - are
you sure you didn't make the change yourself?
--
Denys
> >> ---
> >> recipes-bsp/ti/am-sysinfo_svn.bb | 2 +-
> >> recipes-ti/dmai/ti-dmai.inc | 2 +-
> >> recipes-ti/gstreamer-ti/gstreamer-ti_svn.bb | 2 +-
> >> 3 files changed, 3 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/recipes-bsp/ti/am-sysinfo_svn.bb b/recipes-bsp/ti/am-sysinfo_svn.bb
> >> index d4f8740..b73a884 100644
> >> --- a/recipes-bsp/ti/am-sysinfo_svn.bb
> >> +++ b/recipes-bsp/ti/am-sysinfo_svn.bb
> >> @@ -9,7 +9,7 @@ SRCREV = "5"
> >> PV = "1.0"
> >> PR = "r1+svnr${SRCPV}"
> >>
> >> -SRC_URI = "svn://gforge.ti.com/svn/am_sysinfo/;module=trunk;proto=https;user=anonymous;pswd=''"
> >> +SRC_URI = "svn://gforge.ti.com/svn/am_sysinfo/;module=trunk;protocol=https;user=anonymous;pswd=''"
> >>
> >> S = "${WORKDIR}/trunk"
> >>
> >> diff --git a/recipes-ti/dmai/ti-dmai.inc b/recipes-ti/dmai/ti-dmai.inc
> >> index 23481b7..58955b5 100644
> >> --- a/recipes-ti/dmai/ti-dmai.inc
> >> +++ b/recipes-ti/dmai/ti-dmai.inc
> >> @@ -17,7 +17,7 @@ DMAIBRANCH ?= "UNDEFINED_DMAIBRANCH"
> >>
> >> S = "${WORKDIR}/${DMAIBRANCH}/davinci_multimedia_application_interface/dmai_${PV}/dmai"
> >>
> >> -SRC_URI = "svn://gforge.ti.com/svn/dmai/;module=${DMAIBRANCH};proto=https;user=anonymous;pswd='' \
> >> +SRC_URI = "svn://gforge.ti.com/svn/dmai/;module=${DMAIBRANCH};protocol=https;user=anonymous;pswd='' \
> >> file://loadmodules-ti-dmai-dm6446_al.sh \
> >> file://loadmodules-ti-dmai-dm6467_al.sh \
> >> file://loadmodules-ti-dmai-o3530_al.sh \
> >> diff --git a/recipes-ti/gstreamer-ti/gstreamer-ti_svn.bb b/recipes-ti/gstreamer-ti/gstreamer-ti_svn.bb
> >> index 3d260ed..f314a35 100644
> >> --- a/recipes-ti/gstreamer-ti/gstreamer-ti_svn.bb
> >> +++ b/recipes-ti/gstreamer-ti/gstreamer-ti_svn.bb
> >> @@ -11,7 +11,7 @@ SRCREV = "962"
> >> # apply patches from tracker 1208 to get zero copy support.
> >> # https://gstreamer.ti.com/gf/project/gstreamer_ti/tracker/?action=TrackerItemEdit&tracker_item_id=1208&start=175
> >>
> >> -SRC_URI = "svn://gforge.ti.com/svn/gstreamer_ti/trunk;module=gstreamer_ti;proto=https;user=anonymous;pswd='' \
> >> +SRC_URI = "svn://gforge.ti.com/svn/gstreamer_ti/trunk;module=gstreamer_ti;protocol=https;user=anonymous;pswd='' \
> >> file://gstreamer-ti-rc.sh \
> >> file://r962-remove-include-videodev.diff \
> >> file://gstti-init.service \
> >> --
> >> 1.7.9.5
> >>
> >> _______________________________________________
> >> meta-ti mailing list
> >> meta-ti@yoctoproject.org
> >> https://lists.yoctoproject.org/listinfo/meta-ti
^ permalink raw reply
* Re: Computer crash, btrfs partition errors
From: Not Zippy @ 2012-08-22 17:19 UTC (permalink / raw)
To: dave, linux-btrfs
In-Reply-To: <CANDob0J40BuLhJ2g0Et+-Gq0Nu6V=QkgLfTPGRT5rQUQpBRQaA@mail.gmail.com>
Hi
The full output of the btrfs-debug-tree is 190MB compressed, did you
want it still ?
As far as the conditions, I was running a repo sync which I had
CTRL-Z, I then got distracted and mistakenly started the sync again
(not sure if you are familiar with repo command, it spawns git
processes to checkout project). The crash did not occur immediately
but it was probably within 2 minutes of me starting this second repo
sync. The lock up was bad enough that BUSIER did not reboot the PC, I
had to power down.
After the patch to btrfsck, I got this error:
# ./work/builds/btrfs-progs/btrfsck --repair /dev/sda2
enabling repair mode
checking extents
leaf parent key incorrect 46329503744
bad block 46329503744
owner ref check failed [46329503744 4096]
repair deleting extent record: key 46329503744 168 4096
adding new tree backref on start 46329503744 len 4096 parent 256 root 256
repaired damaged extent references
*** glibc detected *** ./work/builds/btrfs-progs/btrfsck: corrupted
double-linked list: 0x000000001202b220 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x77896)[0x7f0008c59896]
/lib64/libc.so.6(+0x77cfb)[0x7f0008c59cfb]
/lib64/libc.so.6(+0x784a8)[0x7f0008c5a4a8]
/lib64/libc.so.6(cfree+0x6c)[0x7f0008c5d84c]
./work/builds/btrfs-progs/btrfsck[0x415db8]
./work/builds/btrfs-progs/btrfsck[0x415e15]
./work/builds/btrfs-progs/btrfsck[0x40aa9e]
./work/builds/btrfs-progs/btrfsck[0x4046c7]
/lib64/libc.so.6(__libc_start_main+0xed)[0x7f0008c0636d]
./work/builds/btrfs-progs/btrfsck[0x4017f9]
======= Memory map: ========
00400000-00427000 r-xp 00000000 00:22 1375631
/mnt/DevSystem/Work/builds/btrfs-progs/btrfsck
00626000-00627000 r--p 00026000 00:22 1375631
/mnt/DevSystem/Work/builds/btrfs-progs/btrfsck
00627000-00628000 rw-p 00027000 00:22 1375631
/mnt/DevSystem/Work/builds/btrfs-progs/btrfsck
01f27000-2576c000 rw-p 00000000 00:00 0 [heap]
7f0004000000-7f0004021000 rw-p 00000000 00:00 0
7f0004021000-7f0008000000 ---p 00000000 00:00 0
7f00089cb000-7f00089e0000 r-xp 00000000 08:22 298053
/lib64/libgcc_s.so.1
7f00089e0000-7f0008be0000 ---p 00015000 08:22 298053
/lib64/libgcc_s.so.1
7f0008be0000-7f0008be1000 r--p 00015000 08:22 298053
/lib64/libgcc_s.so.1
7f0008be1000-7f0008be2000 rw-p 00016000 08:22 298053
/lib64/libgcc_s.so.1
7f0008be2000-7f0008d64000 r-xp 00000000 08:22 2883622
/lib64/libc-2.14.1.so
7f0008d64000-7f0008f64000 ---p 00182000 08:22 2883622
/lib64/libc-2.14.1.so
7f0008f64000-7f0008f68000 r--p 00182000 08:22 2883622
/lib64/libc-2.14.1.so
7f0008f68000-7f0008f69000 rw-p 00186000 08:22 2883622
/lib64/libc-2.14.1.so
7f0008f69000-7f0008f6e000 rw-p 00000000 00:00 0
7f0008f6e000-7f0008fef000 r-xp 00000000 08:22 2883678
/lib64/libm-2.14.1.so
7f0008fef000-7f00091ee000 ---p 00081000 08:22 2883678
/lib64/libm-2.14.1.so
7f00091ee000-7f00091ef000 r--p 00080000 08:22 2883678
/lib64/libm-2.14.1.so
7f00091ef000-7f00091f0000 rw-p 00081000 08:22 2883678
/lib64/libm-2.14.1.so
7f00091f0000-7f00091f4000 r-xp 00000000 08:22 394806
/lib64/libuuid.so.1.3.0
7f00091f4000-7f00093f3000 ---p 00004000 08:22 394806
/lib64/libuuid.so.1.3.0
7f00093f3000-7f00093f4000 r--p 00003000 08:22 394806
/lib64/libuuid.so.1.3.0
7f00093f4000-7f00093f5000 rw-p 00004000 08:22 394806
/lib64/libuuid.so.1.3.0
7f00093f5000-7f0009415000 r-xp 00000000 08:22 2883603
/lib64/ld-2.14.1.so
7f00095d1000-7f00095d4000 rw-p 00000000 00:00 0
7f0009612000-7f0009615000 rw-p 00000000 00:00 0
7f0009615000-7f0009616000 r--p 00020000 08:22 2883603
/lib64/ld-2.14.1.so
7f0009616000-7f0009617000 rw-p 00021000 08:22 2883603
/lib64/ld-2.14.1.so
7f0009617000-7f0009618000 rw-p 00000000 00:00 0
7fff70f01000-7fff70f23000 rw-p 00000000 00:00 0 [stack]
7fff70fff000-7fff71000000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0
[vsyscall]
Aborted
^ permalink raw reply
* Re: [PATCH 01/10] alpha: Add missing RCU idle APIs on idle loop
From: Paul E. McKenney @ 2012-08-22 17:19 UTC (permalink / raw)
To: Frederic Weisbecker
Cc: LKML, Richard Henderson, Ivan Kokshaysky, Matt Turner, alpha,
3.2.x..
In-Reply-To: <1345652628-15060-2-git-send-email-fweisbec@gmail.com>
On Wed, Aug 22, 2012 at 06:23:39PM +0200, Frederic Weisbecker wrote:
> In the old times, the whole idle task was considered
> as an RCU quiescent state. But as RCU became more and
> more successful overtime, some RCU read side critical
> section have been added even in the code of some
> architectures idle tasks, for tracing for example.
>
> So nowadays, rcu_idle_enter() and rcu_idle_exit() must
> be called by the architecture to tell RCU about the part
> in the idle loop that doesn't make use of rcu read side
> critical sections, typically the part that puts the CPU
> in low power mode.
>
> This is necessary for RCU to find the quiescent states in
> idle in order to complete grace periods.
>
> Add this missing pair of calls in the Alpha's idle loop.
>
> Reported-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
> Cc: Richard Henderson <rth@twiddle.net>
> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
> Cc: Matt Turner <mattst88@gmail.com>
> Cc: alpha <linux-alpha@vger.kernel.org>
> Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> Cc: 3.2.x.. <stable@kernel.org>
> ---
> arch/alpha/kernel/process.c | 6 +++++-
> 1 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git a/arch/alpha/kernel/process.c b/arch/alpha/kernel/process.c
> index 153d3fc..2ebf7b5 100644
> --- a/arch/alpha/kernel/process.c
> +++ b/arch/alpha/kernel/process.c
> @@ -28,6 +28,7 @@
> #include <linux/tty.h>
> #include <linux/console.h>
> #include <linux/slab.h>
> +#include <linux/rcupdate.h>
>
> #include <asm/reg.h>
> #include <asm/uaccess.h>
> @@ -50,13 +51,16 @@ cpu_idle(void)
> {
> set_thread_flag(TIF_POLLING_NRFLAG);
>
> + preempt_disable();
I don't understand the above preempt_disable() not having a matching
preempt_enable() at exit, but the rest of the patches in this series
look good to me.
Thanx, Paul
> while (1) {
> /* FIXME -- EV6 and LCA45 know how to power down
> the CPU. */
>
> + rcu_idle_enter();
> while (!need_resched())
> cpu_relax();
> - schedule();
> + rcu_idle_exit();
> + schedule_preempt_disabled();
> }
> }
>
> --
> 1.7.5.4
>
^ permalink raw reply
* [PATCH 2/2] routerstationpro: switch to Xorg instead of kdrive
From: Ross Burton @ 2012-08-22 17:11 UTC (permalink / raw)
To: yocto
In-Reply-To: <1345655483-10933-1-git-send-email-ross.burton@intel.com>
All of the other BSPs are using Xorg and kdrive is only maintained for Xephyr.
Signed-off-by: Ross Burton <ross.burton@intel.com>
---
meta-yocto/conf/machine/routerstationpro.conf | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/meta-yocto/conf/machine/routerstationpro.conf b/meta-yocto/conf/machine/routerstationpro.conf
index 3c2f56f..645a94a 100644
--- a/meta-yocto/conf/machine/routerstationpro.conf
+++ b/meta-yocto/conf/machine/routerstationpro.conf
@@ -11,9 +11,14 @@ KERNEL_ALT_IMAGETYPE = "vmlinux.bin"
PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
PREFERRED_VERSION_linux-yocto ?= "3.0%"
-PREFERRED_PROVIDER_virtual/xserver = "xserver-kdrive"
-XSERVER = "xserver-kdrive-fbdev"
+PREFERRED_PROVIDER_virtual/xserver ?= "xserver-xorg"
+XSERVER ?= "xserver-xorg \
+ xserver-xorg-extension-extmod \
+ xf86-input-mouse \
+ xf86-input-keyboard \
+ xf86-input-evdev \
+ xf86-video-fbdev"
SERIAL_CONSOLE = "115200 ttyS0"
--
1.7.10
^ permalink raw reply related
* Re: [PATCH] Don't use curl_easy_strerror prior to curl-7.12.0
From: Junio C Hamano @ 2012-08-22 17:18 UTC (permalink / raw)
To: Joachim Schmitz; +Cc: git
In-Reply-To: <002201cd807d$0e83d300$2b8b7900$@schmitz-digital.de>
"Joachim Schmitz" <jojo@schmitz-digital.de> writes:
> Signed-off-by: Joachim Schmitz <jojo@schmitz-digital.de>
At the very least, please mention that this reverts be22d92 (http:
avoid empty error messages for some curl errors, 2011-09-05) on
platforms with older versions of libcURL.
> ---
> http.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/http.c b/http.c
> index b61ac85..18bc6bf 100644
> --- a/http.c
> +++ b/http.c
> @@ -806,10 +806,12 @@ static int http_request(const char *url, void *result,
> int target, int options)
> ret = HTTP_REAUTH;
> }
> } else {
> +#if LIBCURL_VERSION_NUM >= 0x070c00
> if (!curl_errorstr[0])
> strlcpy(curl_errorstr,
>
> curl_easy_strerror(results.curl_result),
> sizeof(curl_errorstr));
> +#endif
> ret = HTTP_ERROR;
> }
> } else {
> --
> 1.7.12
>
> Bye, Jojo
^ 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.