* Re: [PATCH] fast-import: Allow filemodify to set the root
From: David Barr @ 2010-10-07 23:45 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Jonathan Nieder, Git Mailing List, Ramkumar Ramachandra
In-Reply-To: <AANLkTi=K0NsKB0uBpHs+mB=PubieX7jO7vFiqrs+dnqB@mail.gmail.com>
Hi,
> | For a command (like filter-branch --subdirectory-filter) that wants
> | to commit a lot of trees that already exist in the object db, writing
> | undeltified objects as loose files only to repack them later can
> | involve a significant amount[*] of overhead.
> [*] how significant? Numbers are always nice. :)
Using git hash-object:
real 2m51.748s
user 0m25.460s
sys 0m23.890s
Using git fast-import:
real 2m13.337s
user 0m28.010s
sys 0m18.100s
>
> > Ok, so maybe I do understand, is it basically 'git read-tree
> > 4b825dc642cb6eb9a060e54bf8d69288fbee4904' for fast-import?
> Perhaps mention that in the commit message as well then. Of course,
> the fast-import doc needs updating, and it needs test.
| is a synonym for the deleteall command and the fast-import equivalent of
|
| git read-tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904
--
David Barr
^ permalink raw reply
* Re: kgdb errors with serial console
From: Jason Wessel @ 2010-10-07 23:44 UTC (permalink / raw)
To: Elvis Dowson; +Cc: Linux Kernel Mailing List, Linux OMAP Mailing List
In-Reply-To: <7BA01CAF-DD25-4AB6-9498-8AB89E2EDDE1@mac.com>
On 10/07/2010 06:07 PM, Elvis Dowson wrote:
> On Oct 8, 2010, at 2:37 AM, Jason Wessel wrote:
>
>
>> It would probably also be good to test if the debugger is working at all
>> on your serial port.
>>
>> Configure the debugger with:
>> # echo ttyS2 > /sys/module/kgdboc/parameters/kgdboc
>> kgdb: Registered I/O driver kgdboc.
>> # echo g > /proc/sysrq-trigger
>> SysRq : DEBUG
>>
>> And now to exit debugger you must blindly and perfectly type
>> $D#44+
>>
>> Nothing will be echoed because at this stage the kernel serial polling
>> driver would just be collecting characters.
>>
>> After typing that the kernel should return back to the running state and
>> print something like:
>> +$OK#9a#
>>
>
> Cool, I tried all the commands that you suggested and it worked perfectly. I got the same outputs.
>
> So, if I understand correctly, I boot into the kernel without the kgbdwait option, and then manually launch the kgdb and then connect from Eclipse using gdb.
>
> The system waits at the root login prompt.
>
Probably just set a break point at sys_sync.
Of course if you are willing to try something a bit more complex you can
probably make use of being able to interactively break in with the
eclipse gdb plugin, assuming your serial port is connected to a linux
host, and it appeared that way based on your description.
On your host you could set up the following:
git clone git://git.kernel.org/pub/scm/utils/kernel/kgdb/agent-proxy.git
cd agent-proxy
make
./agent-proxy 4440^4441 0 /dev/ttyUSB0,115200 &
telnet localhost 4440
Now in your gdbinit file you replace the target remote with
target remote localhost:4441
The agent proxy should take care of sending the sysrq g for you, and the
telnet window will provide you a look at the target console.
Jason.
^ permalink raw reply
* Re: phandle patch review?
From: Andres Salomon @ 2010-10-07 23:44 UTC (permalink / raw)
To: sparclinux
In-Reply-To: <AANLkTikaAkPqgKu-+JTbPOjiqKZdOcz+czEGUvvbc00y@mail.gmail.com>
On Thu, 7 Oct 2010 17:01:28 -0600
Grant Likely <grant.likely@secretlab.ca> wrote:
> On Tue, Oct 5, 2010 at 1:29 PM, Andres Salomon <dilinger@queued.net>
> wrote:
> > On Tue, 28 Sep 2010 14:59:53 -0700
> > Andres Salomon <dilinger@queued.net> wrote:
> >
> >> On Wed, 29 Sep 2010 05:39:59 +0900
> >> Grant Likely <grant.likely@secretlab.ca> wrote:
> >>
> >> > On Wed, Sep 29, 2010 at 4:48 AM, Andres Salomon
> >> > <dilinger@queued.net> wrote:
> >> > > Hi Grant,
> >> > >
> >> > > I'm assuming the sparc patches can go through your tree as
> >> > > well. Please let me know if anything else needs to happen, now
> >> > > that we have an ACK from davem.
> >> >
> >> > Did the phandle -> types.h issues get sorted out? Â I can't
> >> > remember.
> >>
> >> The relevant thread was here:
> >> https://patchwork.kernel.org/patch/140991/
> >>
> >> I found Sam's initial comment unclear, so I asked for clarification
> >> (specifying that we didn't need phandle to be exported to
> >> userspace); his response was:
> >>
> >> "So the above looks good considerign that userspace
> >> so far does not require ihanlde/phandle."
> >>
> >> I left it open-ended regarding whether or not userspace might want
> >> phandle/ihandle to be exported (that's more a question for you
> >> flat devicetree folks :) , but for my purposes not having it
> >> exposed to userspace is just fine.
> >
> >
> >
> > So yeah, please let me know if there's anything outstanding that I
> > missed that would keep the patches from getting merged.
>
> Okay, I'm confused. As you say, asm/openprom.h is exported. None of
> openprom.h is protect with __KERNEL__, so all of it gets exposed to
> userspace. You're patch adds phandle to the __KERNEL__ protected
> section of types.h, which means that it is unavailable to userspace.
> In which case anything from userspace including asm/openprom.h will
> fail to compile, or am I missing something?
>
Ah, you're right, so phandle will need to be exported to userspace as
well. I will send an updated patch.
^ permalink raw reply
* [PATCH 6/6] rtc: rtc-s3c: Add rtc_valid_tm in s3c_rtc_gettime()
From: Kukjin Kim @ 2010-10-07 23:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1286494879-2932-1-git-send-email-kgene.kim@samsung.com>
This patch adds "rtc_valid_tm" in s3c_rtc_gettime()
as per Wan ZongShun's suggestion.
Suggested-by: Wan ZongShun <mcuos.com@gmail.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Cc: Ben Dooks <ben-linux@fluff.org>
---
drivers/rtc/rtc-s3c.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
index 51e7b25..7c7db81 100644
--- a/drivers/rtc/rtc-s3c.c
+++ b/drivers/rtc/rtc-s3c.c
@@ -185,7 +185,7 @@ static int s3c_rtc_gettime(struct device *dev, struct rtc_time *rtc_tm)
rtc_tm->tm_year += 100;
rtc_tm->tm_mon -= 1;
- return 0;
+ return rtc_valid_tm(rtc_tm);
}
static int s3c_rtc_settime(struct device *dev, struct rtc_time *tm)
--
1.6.2.5
^ permalink raw reply related
* [PATCH 5/6] rtc: rtc-s3c: Fix on RTC initialization method
From: Kukjin Kim @ 2010-10-07 23:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1286494879-2932-1-git-send-email-kgene.kim@samsung.com>
From: Changhwan Youn <chaos.youn@samsung.com>
This patch changes RTC initialization method on probe(). The
'rtc_valid_tm(tm)' can check whether RTC BCD is valid or not.
And should be changed the method of check because previous
method cannot validate RTC BCD registers properly.
Signed-off-by: Changhwan Youn <chaos.youn@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Cc: Ben Dooks <ben-linux@fluff.org>
---
drivers/rtc/rtc-s3c.c | 18 +++++++++++++-----
1 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
index 276b7c1..51e7b25 100644
--- a/drivers/rtc/rtc-s3c.c
+++ b/drivers/rtc/rtc-s3c.c
@@ -453,8 +453,8 @@ static int __devexit s3c_rtc_remove(struct platform_device *dev)
static int __devinit s3c_rtc_probe(struct platform_device *pdev)
{
struct rtc_device *rtc;
+ struct rtc_time rtc_tm;
struct resource *res;
- unsigned int tmp, i;
int ret;
pr_debug("%s: probe=%p\n", __func__, pdev);
@@ -535,11 +535,19 @@ static int __devinit s3c_rtc_probe(struct platform_device *pdev)
/* Check RTC Time */
- for (i = S3C2410_RTCSEC; i <= S3C2410_RTCYEAR; i += 0x4) {
- tmp = readb(s3c_rtc_base + i);
+ s3c_rtc_gettime(NULL, &rtc_tm);
- if ((tmp & 0xf) > 0x9 || ((tmp >> 4) & 0xf) > 0x9)
- writeb(0, s3c_rtc_base + i);
+ if (rtc_valid_tm(&rtc_tm)) {
+ rtc_tm.tm_year = 100;
+ rtc_tm.tm_mon = 0;
+ rtc_tm.tm_mday = 1;
+ rtc_tm.tm_hour = 0;
+ rtc_tm.tm_min = 0;
+ rtc_tm.tm_sec = 0;
+
+ s3c_rtc_settime(NULL, &rtc_tm);
+
+ dev_warn(&pdev->dev, "warning: invalid RTC value so initializing it\n");
}
if (s3c_rtc_cpu_type == TYPE_S3C64XX)
--
1.6.2.5
^ permalink raw reply related
* [PATCH 4/6] rtc: rtc-s3c: Fix debug message format on RTC
From: Kukjin Kim @ 2010-10-07 23:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1286494879-2932-1-git-send-email-kgene.kim@samsung.com>
This patch fixes debug message format on rtc-s3c.
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Acked-by: Ben Dooks <ben-linux@fluff.org>
---
drivers/rtc/rtc-s3c.c | 18 +++++++++---------
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
index 39fa5b0..276b7c1 100644
--- a/drivers/rtc/rtc-s3c.c
+++ b/drivers/rtc/rtc-s3c.c
@@ -171,8 +171,8 @@ static int s3c_rtc_gettime(struct device *dev, struct rtc_time *rtc_tm)
goto retry_get_time;
}
- pr_debug("read time %02x.%02x.%02x %02x/%02x/%02x\n",
- rtc_tm->tm_year, rtc_tm->tm_mon, rtc_tm->tm_mday,
+ pr_debug("read time %04d.%02d.%02d %02d:%02d:%02d\n",
+ 1900 + rtc_tm->tm_year, rtc_tm->tm_mon, rtc_tm->tm_mday,
rtc_tm->tm_hour, rtc_tm->tm_min, rtc_tm->tm_sec);
rtc_tm->tm_sec = bcd2bin(rtc_tm->tm_sec);
@@ -193,8 +193,8 @@ static int s3c_rtc_settime(struct device *dev, struct rtc_time *tm)
void __iomem *base = s3c_rtc_base;
int year = tm->tm_year - 100;
- pr_debug("set time %02d.%02d.%02d %02d/%02d/%02d\n",
- tm->tm_year, tm->tm_mon, tm->tm_mday,
+ pr_debug("set time %04d.%02d.%02d %02d:%02d:%02d\n",
+ 1900 + tm->tm_year, tm->tm_mon, tm->tm_mday,
tm->tm_hour, tm->tm_min, tm->tm_sec);
/* we get around y2k by simply not supporting it */
@@ -231,9 +231,9 @@ static int s3c_rtc_getalarm(struct device *dev, struct rtc_wkalrm *alrm)
alrm->enabled = (alm_en & S3C2410_RTCALM_ALMEN) ? 1 : 0;
- pr_debug("read alarm %02x %02x.%02x.%02x %02x/%02x/%02x\n",
+ pr_debug("read alarm %d, %04d.%02d.%02d %02d:%02d:%02d\n",
alm_en,
- alm_tm->tm_year, alm_tm->tm_mon, alm_tm->tm_mday,
+ 1900 + alm_tm->tm_year, alm_tm->tm_mon, alm_tm->tm_mday,
alm_tm->tm_hour, alm_tm->tm_min, alm_tm->tm_sec);
@@ -280,10 +280,10 @@ static int s3c_rtc_setalarm(struct device *dev, struct rtc_wkalrm *alrm)
void __iomem *base = s3c_rtc_base;
unsigned int alrm_en;
- pr_debug("s3c_rtc_setalarm: %d, %02x/%02x/%02x %02x.%02x.%02x\n",
+ pr_debug("s3c_rtc_setalarm: %d, %04d.%02d.%02d %02d:%02d:%02d\n",
alrm->enabled,
- tm->tm_mday & 0xff, tm->tm_mon & 0xff, tm->tm_year & 0xff,
- tm->tm_hour & 0xff, tm->tm_min & 0xff, tm->tm_sec);
+ 1900 + tm->tm_year, tm->tm_mon, tm->tm_mday,
+ tm->tm_hour, tm->tm_min, tm->tm_sec);
alrm_en = readb(base + S3C2410_RTCALM) & S3C2410_RTCALM_ALMEN;
--
1.6.2.5
^ permalink raw reply related
* [PATCH 3/6] rtc: rtc-s3c: Fix on support RTC Alarm
From: Kukjin Kim @ 2010-10-07 23:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1286494879-2932-1-git-send-email-kgene.kim@samsung.com>
From: Changhwan Youn <chaos.youn@samsung.com>
The alarm_irq_enable function should be implemented to support RTC alarm.
And fixes tab instead of white space abound proc field.
Signed-off-by: Changhwan Youn <chaos.youn@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Acked-by: Ben Dooks <ben-linux@fluff.org>
---
drivers/rtc/rtc-s3c.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
index fd08876..39fa5b0 100644
--- a/drivers/rtc/rtc-s3c.c
+++ b/drivers/rtc/rtc-s3c.c
@@ -379,7 +379,8 @@ static const struct rtc_class_ops s3c_rtcops = {
.set_alarm = s3c_rtc_setalarm,
.irq_set_freq = s3c_rtc_setfreq,
.irq_set_state = s3c_rtc_setpie,
- .proc = s3c_rtc_proc,
+ .proc = s3c_rtc_proc,
+ .alarm_irq_enable = s3c_rtc_setaie,
};
static void s3c_rtc_enable(struct platform_device *pdev, int en)
--
1.6.2.5
^ permalink raw reply related
* [PATCH 2/6] rtc: rtc-s3c: Fix setting missing field of getalarm
From: Kukjin Kim @ 2010-10-07 23:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1286494879-2932-1-git-send-email-kgene.kim@samsung.com>
From: Changhwan Youn <chaos.youn@samsung.com>
Current s3c_rtc_getalarm() sets missing field of alarm time with 0xff.
But this value should be -1 according to drivers/rtc/interface.c.
Signed-off-by: Changhwan Youn <chaos.youn@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Acked-by: Ben Dooks <ben-linux@fluff.org>
---
drivers/rtc/rtc-s3c.c | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
index 4a0b875..fd08876 100644
--- a/drivers/rtc/rtc-s3c.c
+++ b/drivers/rtc/rtc-s3c.c
@@ -242,34 +242,34 @@ static int s3c_rtc_getalarm(struct device *dev, struct rtc_wkalrm *alrm)
if (alm_en & S3C2410_RTCALM_SECEN)
alm_tm->tm_sec = bcd2bin(alm_tm->tm_sec);
else
- alm_tm->tm_sec = 0xff;
+ alm_tm->tm_sec = -1;
if (alm_en & S3C2410_RTCALM_MINEN)
alm_tm->tm_min = bcd2bin(alm_tm->tm_min);
else
- alm_tm->tm_min = 0xff;
+ alm_tm->tm_min = -1;
if (alm_en & S3C2410_RTCALM_HOUREN)
alm_tm->tm_hour = bcd2bin(alm_tm->tm_hour);
else
- alm_tm->tm_hour = 0xff;
+ alm_tm->tm_hour = -1;
if (alm_en & S3C2410_RTCALM_DAYEN)
alm_tm->tm_mday = bcd2bin(alm_tm->tm_mday);
else
- alm_tm->tm_mday = 0xff;
+ alm_tm->tm_mday = -1;
if (alm_en & S3C2410_RTCALM_MONEN) {
alm_tm->tm_mon = bcd2bin(alm_tm->tm_mon);
alm_tm->tm_mon -= 1;
} else {
- alm_tm->tm_mon = 0xff;
+ alm_tm->tm_mon = -1;
}
if (alm_en & S3C2410_RTCALM_YEAREN)
alm_tm->tm_year = bcd2bin(alm_tm->tm_year);
else
- alm_tm->tm_year = 0xffff;
+ alm_tm->tm_year = -1;
return 0;
}
--
1.6.2.5
^ permalink raw reply related
* [PATCH 1/6] rtc: rtc-s3c: Fix access unit from byte to word on RTCCON
From: Kukjin Kim @ 2010-10-07 23:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1286494879-2932-1-git-send-email-kgene.kim@samsung.com>
From: Changhwan Youn <chaos.youn@samsung.com>
S3C2410_RTCCON of TYPE_S3C64XX RTC should be read/written by
readw and writew, because TYPE_S3C64XX RTC uses bit 8 and 9.
And TYPE_S3C2410 RTC also can access it by readw and writew.
Signed-off-by: Changhwan Youn <chaos.youn@samsung.com>
[atul.dahiya at samsung.com: tested on smdk2416]
Tested-by: Atul Dahiya <atul.dahiya@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Cc: Ben Dooks <ben-linux@fluff.org>
---
drivers/rtc/rtc-s3c.c | 36 ++++++++++++++++++------------------
1 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
index f57a87f..4a0b875 100644
--- a/drivers/rtc/rtc-s3c.c
+++ b/drivers/rtc/rtc-s3c.c
@@ -100,7 +100,7 @@ static int s3c_rtc_setpie(struct device *dev, int enabled)
spin_lock_irq(&s3c_rtc_pie_lock);
if (s3c_rtc_cpu_type == TYPE_S3C64XX) {
- tmp = readb(s3c_rtc_base + S3C2410_RTCCON);
+ tmp = readw(s3c_rtc_base + S3C2410_RTCCON);
tmp &= ~S3C64XX_RTCCON_TICEN;
if (enabled)
@@ -318,7 +318,7 @@ static int s3c_rtc_proc(struct device *dev, struct seq_file *seq)
unsigned int ticnt;
if (s3c_rtc_cpu_type == TYPE_S3C64XX) {
- ticnt = readb(s3c_rtc_base + S3C2410_RTCCON);
+ ticnt = readw(s3c_rtc_base + S3C2410_RTCCON);
ticnt &= S3C64XX_RTCCON_TICEN;
} else {
ticnt = readb(s3c_rtc_base + S3C2410_TICNT);
@@ -391,11 +391,11 @@ static void s3c_rtc_enable(struct platform_device *pdev, int en)
return;
if (!en) {
- tmp = readb(base + S3C2410_RTCCON);
+ tmp = readw(base + S3C2410_RTCCON);
if (s3c_rtc_cpu_type == TYPE_S3C64XX)
tmp &= ~S3C64XX_RTCCON_TICEN;
tmp &= ~S3C2410_RTCCON_RTCEN;
- writeb(tmp, base + S3C2410_RTCCON);
+ writew(tmp, base + S3C2410_RTCCON);
if (s3c_rtc_cpu_type == TYPE_S3C2410) {
tmp = readb(base + S3C2410_TICNT);
@@ -405,25 +405,25 @@ static void s3c_rtc_enable(struct platform_device *pdev, int en)
} else {
/* re-enable the device, and check it is ok */
- if ((readb(base+S3C2410_RTCCON) & S3C2410_RTCCON_RTCEN) == 0){
+ if ((readw(base+S3C2410_RTCCON) & S3C2410_RTCCON_RTCEN) == 0){
dev_info(&pdev->dev, "rtc disabled, re-enabling\n");
- tmp = readb(base + S3C2410_RTCCON);
- writeb(tmp|S3C2410_RTCCON_RTCEN, base+S3C2410_RTCCON);
+ tmp = readw(base + S3C2410_RTCCON);
+ writew(tmp|S3C2410_RTCCON_RTCEN, base+S3C2410_RTCCON);
}
- if ((readb(base + S3C2410_RTCCON) & S3C2410_RTCCON_CNTSEL)){
+ if ((readw(base + S3C2410_RTCCON) & S3C2410_RTCCON_CNTSEL)){
dev_info(&pdev->dev, "removing RTCCON_CNTSEL\n");
- tmp = readb(base + S3C2410_RTCCON);
- writeb(tmp& ~S3C2410_RTCCON_CNTSEL, base+S3C2410_RTCCON);
+ tmp = readw(base + S3C2410_RTCCON);
+ writew(tmp& ~S3C2410_RTCCON_CNTSEL, base+S3C2410_RTCCON);
}
- if ((readb(base + S3C2410_RTCCON) & S3C2410_RTCCON_CLKRST)){
+ if ((readw(base + S3C2410_RTCCON) & S3C2410_RTCCON_CLKRST)){
dev_info(&pdev->dev, "removing RTCCON_CLKRST\n");
- tmp = readb(base + S3C2410_RTCCON);
- writeb(tmp & ~S3C2410_RTCCON_CLKRST, base+S3C2410_RTCCON);
+ tmp = readw(base + S3C2410_RTCCON);
+ writew(tmp & ~S3C2410_RTCCON_CLKRST, base+S3C2410_RTCCON);
}
}
}
@@ -514,8 +514,8 @@ static int __devinit s3c_rtc_probe(struct platform_device *pdev)
s3c_rtc_enable(pdev, 1);
- pr_debug("s3c2410_rtc: RTCCON=%02x\n",
- readb(s3c_rtc_base + S3C2410_RTCCON));
+ pr_debug("s3c2410_rtc: RTCCON=%02x\n",
+ readw(s3c_rtc_base + S3C2410_RTCCON));
device_init_wakeup(&pdev->dev, 1);
@@ -578,7 +578,7 @@ static int s3c_rtc_suspend(struct platform_device *pdev, pm_message_t state)
/* save TICNT for anyone using periodic interrupts */
ticnt_save = readb(s3c_rtc_base + S3C2410_TICNT);
if (s3c_rtc_cpu_type == TYPE_S3C64XX) {
- ticnt_en_save = readb(s3c_rtc_base + S3C2410_RTCCON);
+ ticnt_en_save = readw(s3c_rtc_base + S3C2410_RTCCON);
ticnt_en_save &= S3C64XX_RTCCON_TICEN;
}
s3c_rtc_enable(pdev, 0);
@@ -596,8 +596,8 @@ static int s3c_rtc_resume(struct platform_device *pdev)
s3c_rtc_enable(pdev, 1);
writeb(ticnt_save, s3c_rtc_base + S3C2410_TICNT);
if (s3c_rtc_cpu_type == TYPE_S3C64XX && ticnt_en_save) {
- tmp = readb(s3c_rtc_base + S3C2410_RTCCON);
- writeb(tmp | ticnt_en_save, s3c_rtc_base + S3C2410_RTCCON);
+ tmp = readw(s3c_rtc_base + S3C2410_RTCCON);
+ writew(tmp | ticnt_en_save, s3c_rtc_base + S3C2410_RTCCON);
}
if (device_may_wakeup(&pdev->dev))
--
1.6.2.5
^ permalink raw reply related
* [PATCH RE-SEND 0/6] rtc: rtc-s3c: Fix rtc-s3c
From: Kukjin Kim @ 2010-10-07 23:41 UTC (permalink / raw)
To: linux-arm-kernel
This patches already have been submitted regarding mailing list.
Now...I'm re-sending this for handling by Andrew Morton.
Thanks.
[PATCH 1/6] rtc: rtc-s3c: Fix access unit from byte to word on RTCCON
[PATCH 2/6] rtc: rtc-s3c: Fix setting missing field of getalarm
[PATCH 3/6] rtc: rtc-s3c: Fix on support RTC Alarm
[PATCH 4/6] rtc: rtc-s3c: Fix debug message format on RTC
[PATCH 5/6] rtc: rtc-s3c: Fix on RTC initialization method
[PATCH 6/6] rtc: rtc-s3c: Add rtc_valid_tm in s3c_rtc_gettime()
^ permalink raw reply
* Re: What happened to ~shefty/libibcm.git?
From: Jason Gunthorpe @ 2010-10-07 23:40 UTC (permalink / raw)
To: Hefty, Sean; +Cc: Jeff Becker, Linux RDMA list
In-Reply-To: <CF9C39F99A89134C9CF9C4CCB68B8DDF25B788C995-osO9UTpF0USkrb+BlOpmy7fspsVTdybXVpNB7YpNyf8@public.gmane.org>
On Thu, Oct 07, 2010 at 08:11:07AM -0700, Hefty, Sean wrote:
> > All the tags are also missing from:
> >
> > git://git.openfabrics.org/~shefty/librdmacm.git
> >
> > git push --tags ??
>
> thanks - done
Could you also
git tag v1.0.8 78e67b72a15380e93273951b63ea85f1129d5946
on librdmacm?
Thanks,
--
Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> (780)4406067x832
Chief Technology Officer, Obsidian Research Corp Edmonton, Canada
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2] wireless: Set some stats used by /proc/net/wireless (wext)
From: greearb @ 2010-10-07 23:39 UTC (permalink / raw)
To: linux-wireless; +Cc: Ben Greear
From: Ben Greear <greearb@candelatech.com>
Some stats for /proc/net/wireless (and wext in general) are not
being set. This patch addresses a few of those with values easily
obtained from mac80211 core.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
v1 -> v2: Add and use filled flags.
:100644 100644 183739c... 338248d... M include/net/cfg80211.h
:100644 100644 ecf9b71... 25fb351... M net/mac80211/cfg.c
:100644 100644 6002265... 12222ee... M net/wireless/wext-compat.c
include/net/cfg80211.h | 4 ++++
net/mac80211/cfg.c | 4 +++-
net/wireless/wext-compat.c | 4 ++++
3 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 183739c..338248d 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -403,6 +403,7 @@ struct station_parameters {
* @STATION_INFO_TX_PACKETS: @tx_packets filled
* @STATION_INFO_TX_RETRIES: @tx_retries filled
* @STATION_INFO_TX_FAILED: @tx_failed filled
+ * @STATION_INFO_RX_DROP_MISC: @rx_dropped_misc filled
*/
enum station_info_flags {
STATION_INFO_INACTIVE_TIME = 1<<0,
@@ -417,6 +418,7 @@ enum station_info_flags {
STATION_INFO_TX_PACKETS = 1<<9,
STATION_INFO_TX_RETRIES = 1<<10,
STATION_INFO_TX_FAILED = 1<<11,
+ STATION_INFO_RX_DROP_MISC = 1<<12,
};
/**
@@ -468,6 +470,7 @@ struct rate_info {
* @tx_packets: packets transmitted to this station
* @tx_retries: cumulative retry counts
* @tx_failed: number of failed transmissions (retries exceeded, no ACK)
+ * @rx_dropped_misc: Dropped for un-specified reason.
* @generation: generation number for nl80211 dumps.
* This number should increase every time the list of stations
* changes, i.e. when a station is added or removed, so that
@@ -487,6 +490,7 @@ struct station_info {
u32 tx_packets;
u32 tx_retries;
u32 tx_failed;
+ u32 rx_dropped_misc;
int generation;
};
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index ecf9b71..25fb351 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -329,7 +329,8 @@ static void sta_set_sinfo(struct sta_info *sta, struct station_info *sinfo)
STATION_INFO_TX_PACKETS |
STATION_INFO_TX_RETRIES |
STATION_INFO_TX_FAILED |
- STATION_INFO_TX_BITRATE;
+ STATION_INFO_TX_BITRATE |
+ STATION_INFO_RX_DROP_MISC;
sinfo->inactive_time = jiffies_to_msecs(jiffies - sta->last_rx);
sinfo->rx_bytes = sta->rx_bytes;
@@ -338,6 +339,7 @@ static void sta_set_sinfo(struct sta_info *sta, struct station_info *sinfo)
sinfo->tx_packets = sta->tx_packets;
sinfo->tx_retries = sta->tx_retry_count;
sinfo->tx_failed = sta->tx_retry_failed;
+ sinfo->rx_dropped_misc = sta->rx_dropped;
if ((sta->local->hw.flags & IEEE80211_HW_SIGNAL_DBM) ||
(sta->local->hw.flags & IEEE80211_HW_SIGNAL_UNSPEC)) {
diff --git a/net/wireless/wext-compat.c b/net/wireless/wext-compat.c
index 6002265..12222ee 100644
--- a/net/wireless/wext-compat.c
+++ b/net/wireless/wext-compat.c
@@ -1366,6 +1366,10 @@ struct iw_statistics *cfg80211_wireless_stats(struct net_device *dev)
}
wstats.qual.updated |= IW_QUAL_NOISE_INVALID;
+ if (sinfo.filled & STATION_INFO_RX_DROP_MISC)
+ wstats.discard.misc = sinfo.rx_dropped_misc;
+ if (sinfo.filled & STATION_INFO_TX_FAILED)
+ wstats.discard.retries = sinfo.tx_failed;
return &wstats;
}
--
1.7.2.2
^ permalink raw reply related
* [PATCH 17/20] drm/i915/dp: use VBT provided eDP params if available
From: Jesse Barnes @ 2010-10-07 23:01 UTC (permalink / raw)
To: intel-gfx
In-Reply-To: <1286492485-18145-1-git-send-email-jbarnes@virtuousgeek.org>
We can skip most of the link training step if we use the VBT provided
values.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
---
drivers/gpu/drm/i915/intel_dp.c | 146 ++++++++++++++++++++++++---------------
1 files changed, 89 insertions(+), 57 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 5ea1d8d..fa24d94 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -581,6 +581,17 @@ intel_dp_mode_fixup(struct drm_encoder *encoder, struct drm_display_mode *mode,
mode->clock = dev_priv->panel_fixed_mode->clock;
}
+ /* Just use VBT values for eDP */
+ if (is_edp(intel_dp)) {
+ intel_dp->lane_count = dev_priv->edp.lanes;
+ intel_dp->link_bw = dev_priv->edp.rate;
+ adjusted_mode->clock = intel_dp_link_clock(intel_dp->link_bw);
+ DRM_DEBUG_KMS("eDP link bw %02x lane count %d clock %d\n",
+ intel_dp->link_bw, intel_dp->lane_count,
+ adjusted_mode->clock);
+ return true;
+ }
+
for (lane_count = 1; lane_count <= max_lane_count; lane_count <<= 1) {
for (clock = 0; clock <= max_clock; clock++) {
int link_avail = intel_dp_max_data_rate(intel_dp_link_clock(bws[clock]), lane_count);
@@ -599,19 +610,6 @@ intel_dp_mode_fixup(struct drm_encoder *encoder, struct drm_display_mode *mode,
}
}
- if (is_edp(intel_dp)) {
- /* okay we failed just pick the highest */
- intel_dp->lane_count = max_lane_count;
- intel_dp->link_bw = bws[max_clock];
- adjusted_mode->clock = intel_dp_link_clock(intel_dp->link_bw);
- DRM_DEBUG_KMS("Force picking display port link bw %02x lane "
- "count %d clock %d\n",
- intel_dp->link_bw, intel_dp->lane_count,
- adjusted_mode->clock);
-
- return true;
- }
-
return false;
}
@@ -1089,11 +1087,21 @@ intel_get_adjust_train(struct intel_dp *intel_dp)
}
static uint32_t
-intel_dp_signal_levels(uint8_t train_set, int lane_count)
+intel_dp_signal_levels(struct intel_dp *intel_dp)
{
- uint32_t signal_levels = 0;
+ struct drm_device *dev = intel_dp->base.base.dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ uint32_t signal_levels = 0;
+ u8 train_set = intel_dp->train_set[0];
+ u32 vswing = train_set & DP_TRAIN_VOLTAGE_SWING_MASK;
+ u32 preemphasis = train_set & DP_TRAIN_PRE_EMPHASIS_MASK;
- switch (train_set & DP_TRAIN_VOLTAGE_SWING_MASK) {
+ if (is_edp(intel_dp)) {
+ vswing = dev_priv->edp.vswing;
+ preemphasis = dev_priv->edp.preemphasis;
+ }
+
+ switch (vswing) {
case DP_TRAIN_VOLTAGE_SWING_400:
default:
signal_levels |= DP_VOLTAGE_0_4;
@@ -1108,7 +1116,7 @@ intel_dp_signal_levels(uint8_t train_set, int lane_count)
signal_levels |= DP_VOLTAGE_1_2;
break;
}
- switch (train_set & DP_TRAIN_PRE_EMPHASIS_MASK) {
+ switch (preemphasis) {
case DP_TRAIN_PRE_EMPHASIS_0:
default:
signal_levels |= DP_PRE_EMPHASIS_0;
@@ -1195,6 +1203,18 @@ intel_channel_eq_ok(struct intel_dp *intel_dp)
}
static bool
+intel_dp_aux_handshake_required(struct intel_dp *intel_dp)
+{
+ struct drm_device *dev = intel_dp->base.base.dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+
+ if (is_edp(intel_dp) && dev_priv->no_aux_handshake)
+ return false;
+
+ return true;
+}
+
+static bool
intel_dp_set_link_train(struct intel_dp *intel_dp,
uint32_t dp_reg_value,
uint8_t dp_train_pat)
@@ -1206,6 +1226,9 @@ intel_dp_set_link_train(struct intel_dp *intel_dp,
I915_WRITE(intel_dp->output_reg, dp_reg_value);
POSTING_READ(intel_dp->output_reg);
+ if (!intel_dp_aux_handshake_required(intel_dp))
+ return true;
+
intel_dp_aux_native_write_1(intel_dp,
DP_TRAINING_PATTERN_SET,
dp_train_pat);
@@ -1238,10 +1261,11 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
POSTING_READ(intel_dp->output_reg);
intel_wait_for_vblank(dev, intel_crtc->pipe);
- /* Write the link configuration data */
- intel_dp_aux_native_write(intel_dp, DP_LINK_BW_SET,
- intel_dp->link_configuration,
- DP_LINK_CONFIGURATION_SIZE);
+ if (intel_dp_aux_handshake_required(intel_dp))
+ /* Write the link configuration data */
+ intel_dp_aux_native_write(intel_dp, DP_LINK_BW_SET,
+ intel_dp->link_configuration,
+ DP_LINK_CONFIGURATION_SIZE);
DP |= DP_PORT_EN;
if (HAS_PCH_CPT(dev) && !is_edp(intel_dp))
@@ -1259,7 +1283,7 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
signal_levels = intel_gen6_edp_signal_levels(intel_dp->train_set[0]);
DP = (DP & ~EDP_LINK_TRAIN_VOL_EMP_MASK_SNB) | signal_levels;
} else {
- signal_levels = intel_dp_signal_levels(intel_dp->train_set[0], intel_dp->lane_count);
+ signal_levels = intel_dp_signal_levels(intel_dp);
DP = (DP & ~(DP_VOLTAGE_MASK|DP_PRE_EMPHASIS_MASK)) | signal_levels;
}
@@ -1273,33 +1297,37 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
break;
/* Set training pattern 1 */
- udelay(100);
- if (!intel_dp_get_link_status(intel_dp))
+ udelay(500);
+ if (intel_dp_aux_handshake_required(intel_dp)) {
break;
+ } else {
+ if (!intel_dp_get_link_status(intel_dp))
+ break;
- if (intel_clock_recovery_ok(intel_dp->link_status, intel_dp->lane_count)) {
- clock_recovery = true;
- break;
- }
-
- /* Check to see if we've tried the max voltage */
- for (i = 0; i < intel_dp->lane_count; i++)
- if ((intel_dp->train_set[i] & DP_TRAIN_MAX_SWING_REACHED) == 0)
+ if (intel_clock_recovery_ok(intel_dp->link_status, intel_dp->lane_count)) {
+ clock_recovery = true;
break;
- if (i == intel_dp->lane_count)
- break;
+ }
- /* Check to see if we've tried the same voltage 5 times */
- if ((intel_dp->train_set[0] & DP_TRAIN_VOLTAGE_SWING_MASK) == voltage) {
- ++tries;
- if (tries == 5)
+ /* Check to see if we've tried the max voltage */
+ for (i = 0; i < intel_dp->lane_count; i++)
+ if ((intel_dp->train_set[i] & DP_TRAIN_MAX_SWING_REACHED) == 0)
+ break;
+ if (i == intel_dp->lane_count)
break;
- } else
- tries = 0;
- voltage = intel_dp->train_set[0] & DP_TRAIN_VOLTAGE_SWING_MASK;
- /* Compute new intel_dp->train_set as requested by target */
- intel_get_adjust_train(intel_dp);
+ /* Check to see if we've tried the same voltage 5 times */
+ if ((intel_dp->train_set[0] & DP_TRAIN_VOLTAGE_SWING_MASK) == voltage) {
+ ++tries;
+ if (tries == 5)
+ break;
+ } else
+ tries = 0;
+ voltage = intel_dp->train_set[0] & DP_TRAIN_VOLTAGE_SWING_MASK;
+
+ /* Compute new intel_dp->train_set as requested by target */
+ intel_get_adjust_train(intel_dp);
+ }
}
intel_dp->DP = DP;
@@ -1326,7 +1354,7 @@ intel_dp_complete_link_train(struct intel_dp *intel_dp)
signal_levels = intel_gen6_edp_signal_levels(intel_dp->train_set[0]);
DP = (DP & ~EDP_LINK_TRAIN_VOL_EMP_MASK_SNB) | signal_levels;
} else {
- signal_levels = intel_dp_signal_levels(intel_dp->train_set[0], intel_dp->lane_count);
+ signal_levels = intel_dp_signal_levels(intel_dp);
DP = (DP & ~(DP_VOLTAGE_MASK|DP_PRE_EMPHASIS_MASK)) | signal_levels;
}
@@ -1340,24 +1368,28 @@ intel_dp_complete_link_train(struct intel_dp *intel_dp)
DP_TRAINING_PATTERN_2))
break;
- udelay(400);
- if (!intel_dp_get_link_status(intel_dp))
- break;
+ udelay(500);
- if (intel_channel_eq_ok(intel_dp)) {
- channel_eq = true;
+ if (!intel_dp_aux_handshake_required(intel_dp)) {
break;
- }
+ } else {
+ if (!intel_dp_get_link_status(intel_dp))
+ break;
- /* Try 5 times */
- if (tries > 5)
- break;
+ if (intel_channel_eq_ok(intel_dp)) {
+ channel_eq = true;
+ break;
+ }
- /* Compute new intel_dp->train_set as requested by target */
- intel_get_adjust_train(intel_dp);
- ++tries;
- }
+ /* Try 5 times */
+ if (tries > 5)
+ break;
+ /* Compute new intel_dp->train_set as requested by target */
+ intel_get_adjust_train(intel_dp);
+ ++tries;
+ }
+ }
if (HAS_PCH_CPT(dev) && !is_edp(intel_dp))
reg = DP | DP_LINK_TRAIN_OFF_CPT;
else
--
1.7.0.4
^ permalink raw reply related
* [PATCH 16/20] drm/i915/dp: cache eDP DPCD data
From: Jesse Barnes @ 2010-10-07 23:01 UTC (permalink / raw)
To: intel-gfx
In-Reply-To: <1286492485-18145-1-git-send-email-jbarnes@virtuousgeek.org>
Cache the first 4 bytes of DPCD data in the eDP case. It's unlikely to
change and can save us some trouble at link training time.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_dp.c | 20 ++++++++++++++++++++
2 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6d49a9f..84e33ae 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -350,6 +350,7 @@ typedef struct drm_i915_private {
int bpp;
struct edp_power_seq pps;
} edp;
+ bool no_aux_handshake;
struct notifier_block lid_notifier;
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index e5f183f..5ea1d8d 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1725,6 +1725,26 @@ intel_dp_init(struct drm_device *dev, int output_reg)
intel_dp_i2c_init(intel_dp, intel_connector, name);
+ /* Cache some DPCD data in the eDP case */
+ if (is_edp(intel_dp)) {
+ int ret;
+ bool was_on;
+
+ was_on = ironlake_edp_panel_on(intel_dp);
+ ret = intel_dp_aux_native_read(intel_dp, DP_DPCD_REV,
+ intel_dp->dpcd,
+ sizeof (intel_dp->dpcd));
+ if (ret == sizeof (intel_dp->dpcd)) {
+ if (intel_dp->dpcd[0] >= 0x11)
+ dev_priv->no_aux_handshake = intel_dp->dpcd[3] &
+ DP_NO_AUX_HANDSHAKE_LINK_TRAINING;
+ } else {
+ DRM_ERROR("failed to retrieve link info\n");
+ }
+ if (!was_on)
+ ironlake_edp_panel_off(dev);
+ }
+
intel_encoder->hot_plug = intel_dp_hot_plug;
if (is_edp(intel_dp)) {
--
1.7.0.4
^ permalink raw reply related
* [PATCH 19/20] drm/i915/dp: make eDP PLL functions work as advertised
From: Jesse Barnes @ 2010-10-07 23:01 UTC (permalink / raw)
To: intel-gfx
In-Reply-To: <1286492485-18145-1-git-send-email-jbarnes@virtuousgeek.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
---
drivers/gpu/drm/i915/intel_dp.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 19e0d65..8e019c8 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -891,8 +891,10 @@ static void ironlake_edp_pll_on(struct drm_encoder *encoder)
DRM_DEBUG_KMS("\n");
dpa_ctl = I915_READ(DP_A);
- dpa_ctl &= ~DP_PLL_ENABLE;
+ dpa_ctl |= DP_PLL_ENABLE;
I915_WRITE(DP_A, dpa_ctl);
+ POSTING_READ(DP_A);
+ udelay(200);
}
static void ironlake_edp_pll_off(struct drm_encoder *encoder)
@@ -902,7 +904,7 @@ static void ironlake_edp_pll_off(struct drm_encoder *encoder)
u32 dpa_ctl;
dpa_ctl = I915_READ(DP_A);
- dpa_ctl |= DP_PLL_ENABLE;
+ dpa_ctl &= ~DP_PLL_ENABLE;
I915_WRITE(DP_A, dpa_ctl);
POSTING_READ(DP_A);
udelay(200);
--
1.7.0.4
^ permalink raw reply related
* [PATCH 18/20] drm/i915/dp: don't bother with DP PLL for PCH attached eDP
From: Jesse Barnes @ 2010-10-07 23:01 UTC (permalink / raw)
To: intel-gfx
In-Reply-To: <1286492485-18145-1-git-send-email-jbarnes@virtuousgeek.org>
We don't use the CPU DP PLL with PCH attached eDP panels, so don't
bother to enable it.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
---
drivers/gpu/drm/i915/intel_dp.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index fa24d94..19e0d65 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -775,7 +775,7 @@ intel_dp_mode_set(struct drm_encoder *encoder, struct drm_display_mode *mode,
if (intel_crtc->pipe == 1 && !HAS_PCH_CPT(dev))
intel_dp->DP |= DP_PIPEB_SELECT;
- if (is_edp(intel_dp)) {
+ if (is_edp(intel_dp) && !is_pch_edp(intel_dp)) {
/* don't miss out required setting for eDP */
intel_dp->DP |= DP_PLL_ENABLE;
if (adjusted_mode->clock < 200000)
--
1.7.0.4
^ permalink raw reply related
* [PATCH 20/20] drm/i915: diasable clock gating for the panel power sequencer
From: Jesse Barnes @ 2010-10-07 23:01 UTC (permalink / raw)
To: intel-gfx; +Cc: stable
In-Reply-To: <1286492485-18145-1-git-send-email-jbarnes@virtuousgeek.org>
Needed on Ibex Peak and Cougar Point or the panel won't always come on.
Cc: stable@kernel.org
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
---
drivers/gpu/drm/i915/i915_reg.h | 3 +++
drivers/gpu/drm/i915/intel_display.c | 7 +++++++
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 5a22887..8829289 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2784,6 +2784,9 @@
#define FDI_RX_PHASE_SYNC_POINTER_ENABLE (1)
#define FDI_RX_CHICKEN(pipe) _PIPE(pipe, FDI_RXA_CHICKEN, FDI_RXB_CHICKEN)
+#define SOUTH_DSPCLK_GATE_D 0xc2020
+#define PCH_DPLSUNIT_CLOCK_GATE_DISABLE (1<<29)
+
/* CPU: FDI_TX */
#define FDI_TXA_CTL 0x60100
#define FDI_TXB_CTL 0x61100
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 09bc613..159dd01 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5744,6 +5744,13 @@ void intel_init_clock_gating(struct drm_device *dev)
I915_WRITE(PCH_DSPCLK_GATE_D, dspclk_gate);
/*
+ * On Ibex Peak and Cougar Point, we need to disable clock
+ * gating for the panel power sequencer or it will fail to
+ * start up when no ports are active.
+ */
+ I915_WRITE(SOUTH_DSPCLK_GATE_D, PCH_DPLSUNIT_CLOCK_GATE_DISABLE);
+
+ /*
* According to the spec the following bits should be set in
* order to enable memory self-refresh
* The bit 22/21 of 0x42004
--
1.7.0.4
^ permalink raw reply related
* Re: opkg install gdbserver
From: Tom Rini @ 2010-10-07 23:38 UTC (permalink / raw)
To: openembedded-devel
In-Reply-To: <4E064324-2FF0-4F2B-BCB7-04AFD285689B@mac.com>
Elvis Dowson wrote:
> Hi,
> I have a target board that is not connected to the internet.
>
> What should I do to get gdbserver onto the target?
>
> I have built gdb-cross. Is there another recipe I can add to omap3-console-image, to make sure that gdbserver gets pulled in?
There is a gdbserver recipe for the target.
--
Tom Rini
Mentor Graphics Corporation
^ permalink raw reply
* Re: [PATCH] PM: add synchronous runtime interface for interrupt handlers
From: Rafael J. Wysocki @ 2010-10-07 23:37 UTC (permalink / raw)
To: Kevin Hilman; +Cc: Alan Stern, Linux-pm mailing list, Partha Basak, linux-omap
In-Reply-To: <8762xd4msy.fsf@deeprootsystems.com>
On Friday, October 08, 2010, Kevin Hilman wrote:
> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
>
> > On Thursday, October 07, 2010, Alan Stern wrote:
> >> On Thu, 7 Oct 2010, Kevin Hilman wrote:
> >>
> >> > My confusion is not about the use of spinlocks, it's a question of what
> >> > is being busy-waited for, and the thread that is being waited for is
> >> > going to complete when interrupts are disabled.
> >> >
> >> > Sorry to be dense, but can you (re)summarize what you're proposing as I
> >> > think I'm getting mixed up with all the various options we've been
> >> > tossing around.
> >> >
> >> > If it can work, I'm certainly in favor of a busy-wait approach as it
> >> > really ensures that sync requests are handled quickly.
> >>
> >> Okay, here's the story in a nutshell. Allowing a subsystem's or
> >> driver's runtime-PM callbacks to run with interrupts disabled faces two
> >> obstacles:
> >>
> >> (1): We don't want two different CPUs to run callbacks for the
> >> same device at the same time. So if a callback is already
> >> running on one CPU (i.e., if the device's runtime status is
> >> either SUSPENDING or RESUMING) then another CPU can't be
> >> allowed to invoke a callback.
> >>
> >> Thus, you can't do a synchronous pm_runtime_resume_irq()
> >> if the device is in the middle of a suspend or resume
> >> operation. We're left with two choices: Fail the synchronous
> >> call and force the driver to defer matters to a workqueue
> >> (possibly masking an IRQ line in the meantime), or busy-wait
> >> until the concurrent operation finishes.
> >>
> >> If the PM core simply avoids releasing dev->power.lock before
> >> invoking the runtime_suspend or runtime_resume callback, the
> >> end result is almost the same as with busy-waiting.
> >
> > This is slightly more complicated, because suspend is a bit different from
> > resume. I think it's generally acceptable to refuse to do a "fast path" suspend
> > if the device state is not RPM_ACTIVE at the moment, but refusing to do
> > a "fast path" resume may be more problematic (more on that later).
> >
> >> (2): In general we can't resume a device if its parent is suspended.
> >> If the parent's runtime_resume routine needs to run with
> >> interrupts enabled then there's no way to resume the device
> >> while keeping interrupts disabled.
> >>
> >> Possible solutions involve, again, deferring matters to a
> >> workqueue, or else simply not allowing the situation to arise
> >> in the first place (forbid a device to have interrupt-disabled
> >> callbacks unless its parent does too or the parent doesn't use
> >> runtime PM at all).
> >>
> >> In general I'm against the solutions that require a workqueue.
> >
> > OK
> >
> >> Raphael appears to favor workqueues for (1) and be against them for (2).
> >
> > The particular case we need to handle (I think) is that some devices need to be
> > resumed "atomically" as a part of bringing a CPU package out of a C-like-state
> > (Kevin, is that correct?).
>
> Correct, but there is more than one problematic case.
>
> Another problem is in devices that are not atomic with C-states, but
> receive wakeup IRQs while they're suspended and thus need to
> pm_runtime_get() from their ISRs, without having an essentially
> unbounded interrupt latency before the ISR can be handled.
>
> Consider the following sequence for a given device
>
> - device: ->runtime_suspend() /* registers not accessible */
> - pm_idle
> - IRQs disabled
> - idle
> - wakeup event
> - idle loop finishes
> - IRQs enabled
> - device: ->runtime_resume()
>
> Now, consider the 'wakeup event' is an IRQ for that device. That means
> as soon as IRQs are (re)enabled (and before some other activity has
> triggered a ->runtime_resume), the device's ISR is called. Since it is
> RPM_SUSPENDED, it's registers are not accessible so it needs to do a
> pm_runtime_get().
>
> The case that raised this initially was a GPIO IRQ demux, where the
> initial ISR is just a chained handler whichfigures out which GPIO
> fired and then call genirq for that IRQ.
>
> All that being said, while I've currently described these as two
> different problems, the second one could be solved by converting it to
> the first one. IOW, make GPIO be one of those devices that are
> suspended/resumed atomically with the CPU so that it is guaranteed to be
> awake when IRQs are re-enabled.
>
> While that would work, I've been trying to move in the opposite
> direction by trying to dis-connect them from CPU idle.
>
> > In that case not only we can't defer the resume (by
> > using a workqueue), but also we have to finish the resume within strict time
> > constraints (the time to leave the given C-like-state is one of the parameters
> > used by cpuidle governors to decide which state to choose).
> >
> > On the other hand, busy waiting (by looping) in the case the state is
> > RPM_RESUMING is as though the callbacks were executed under a spinlock and we
> > happened to wait on it. I'd prefer to avoid that. Moreover, if the state is
> > RPM_SUSPENDING at the time a "fast path" resume is started, we are almost
> > guaranteed to violate the time constraints (by busy waiting for the suspend to
> > complete and carrying out the resume).
> >
> > So, here's an idea:
> >
> > First, let's introduce two flags in struct dev_pm_info, irq_safe and
> > fast_resume. The former has to be set so that the things above work.
> >
> > Second, let's add a new flag to pass to __pm_runtime_{suspend|resume}(),
> > RPM_FAST_RESUME such that if it is passed to __pm_runtime_suspend(), it
> > causes fast_resume to be set for the given device (if the status is already
> > RPM_SUSPENDED, it just sets the flag, otherwise it suspends the device
> > normally and then sets the flag). Now, if fast_resume is set,
> > __pm_runtime_resume() has to be passed RPM_FAST_RESUME, or it will
> > fail (it also will fail if passed RPM_FAST_RESUME and fast_resume isn't
> > set). In that case the status has to be RPM_SUSPENDED or RPM_RESUMING
> > (otherwise fast_resume won't be set) and if it is RPM_RESUMING, this means
> > that the other resume has been called with RPM_FAST_RESUME too (it would
> > fail otherwise), so it's fine to busy loop until the status is RPM_SUSPENDED
> > (it's the caller's problem to avoid that). RPM_FAST_RESUME causes
> > __pm_runtime_resume() to avod turning interrupts on.
> >
> > If necessary, there may be a flag for __pm_runtime_suspend() that will
> > carry out "atomic" suspend, but I'm not sure if that's necessary. Kevin?
>
> I think we'll need both "atomic" suspend & resume.
>
> One of the devices I'm currently managing in this atomic fashion (inside
> pm_idle) is the UARTs (of course, I'm not currently using runtime PM for
> this, I'm calling platform-specific hooks directly since IRQs are
> disabled.) For the UARTs I'm using both atomic suspend and resume,
> primarily for debug so I am sure UARTs are awake to see any panics
> during the last parts of the suspend/idle process and the early parts of
> the resume path. This UART case is a bit of a hack until the driver is
> converted to runtime PM, but illustrates some debug related reasons we
> might also need atomic suspend and resume.
>
> We also have some workarounds for hardware errata that require
> putting certain devices in a specific state just before (and after)
> idle. The drivers for these devices will need both suspend and resume.
OK, thanks for the info.
Do you need "normal" resume to work after "atomic" suspend, or is it
sufficient that "atomic" suspend will require "atomic" resume?
Rafael
^ permalink raw reply
* Re: [PATCH] PM: add synchronous runtime interface for interrupt handlers
From: Rafael J. Wysocki @ 2010-10-07 23:37 UTC (permalink / raw)
To: Kevin Hilman; +Cc: Partha Basak, Linux-pm mailing list, linux-omap
In-Reply-To: <8762xd4msy.fsf@deeprootsystems.com>
On Friday, October 08, 2010, Kevin Hilman wrote:
> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
>
> > On Thursday, October 07, 2010, Alan Stern wrote:
> >> On Thu, 7 Oct 2010, Kevin Hilman wrote:
> >>
> >> > My confusion is not about the use of spinlocks, it's a question of what
> >> > is being busy-waited for, and the thread that is being waited for is
> >> > going to complete when interrupts are disabled.
> >> >
> >> > Sorry to be dense, but can you (re)summarize what you're proposing as I
> >> > think I'm getting mixed up with all the various options we've been
> >> > tossing around.
> >> >
> >> > If it can work, I'm certainly in favor of a busy-wait approach as it
> >> > really ensures that sync requests are handled quickly.
> >>
> >> Okay, here's the story in a nutshell. Allowing a subsystem's or
> >> driver's runtime-PM callbacks to run with interrupts disabled faces two
> >> obstacles:
> >>
> >> (1): We don't want two different CPUs to run callbacks for the
> >> same device at the same time. So if a callback is already
> >> running on one CPU (i.e., if the device's runtime status is
> >> either SUSPENDING or RESUMING) then another CPU can't be
> >> allowed to invoke a callback.
> >>
> >> Thus, you can't do a synchronous pm_runtime_resume_irq()
> >> if the device is in the middle of a suspend or resume
> >> operation. We're left with two choices: Fail the synchronous
> >> call and force the driver to defer matters to a workqueue
> >> (possibly masking an IRQ line in the meantime), or busy-wait
> >> until the concurrent operation finishes.
> >>
> >> If the PM core simply avoids releasing dev->power.lock before
> >> invoking the runtime_suspend or runtime_resume callback, the
> >> end result is almost the same as with busy-waiting.
> >
> > This is slightly more complicated, because suspend is a bit different from
> > resume. I think it's generally acceptable to refuse to do a "fast path" suspend
> > if the device state is not RPM_ACTIVE at the moment, but refusing to do
> > a "fast path" resume may be more problematic (more on that later).
> >
> >> (2): In general we can't resume a device if its parent is suspended.
> >> If the parent's runtime_resume routine needs to run with
> >> interrupts enabled then there's no way to resume the device
> >> while keeping interrupts disabled.
> >>
> >> Possible solutions involve, again, deferring matters to a
> >> workqueue, or else simply not allowing the situation to arise
> >> in the first place (forbid a device to have interrupt-disabled
> >> callbacks unless its parent does too or the parent doesn't use
> >> runtime PM at all).
> >>
> >> In general I'm against the solutions that require a workqueue.
> >
> > OK
> >
> >> Raphael appears to favor workqueues for (1) and be against them for (2).
> >
> > The particular case we need to handle (I think) is that some devices need to be
> > resumed "atomically" as a part of bringing a CPU package out of a C-like-state
> > (Kevin, is that correct?).
>
> Correct, but there is more than one problematic case.
>
> Another problem is in devices that are not atomic with C-states, but
> receive wakeup IRQs while they're suspended and thus need to
> pm_runtime_get() from their ISRs, without having an essentially
> unbounded interrupt latency before the ISR can be handled.
>
> Consider the following sequence for a given device
>
> - device: ->runtime_suspend() /* registers not accessible */
> - pm_idle
> - IRQs disabled
> - idle
> - wakeup event
> - idle loop finishes
> - IRQs enabled
> - device: ->runtime_resume()
>
> Now, consider the 'wakeup event' is an IRQ for that device. That means
> as soon as IRQs are (re)enabled (and before some other activity has
> triggered a ->runtime_resume), the device's ISR is called. Since it is
> RPM_SUSPENDED, it's registers are not accessible so it needs to do a
> pm_runtime_get().
>
> The case that raised this initially was a GPIO IRQ demux, where the
> initial ISR is just a chained handler whichfigures out which GPIO
> fired and then call genirq for that IRQ.
>
> All that being said, while I've currently described these as two
> different problems, the second one could be solved by converting it to
> the first one. IOW, make GPIO be one of those devices that are
> suspended/resumed atomically with the CPU so that it is guaranteed to be
> awake when IRQs are re-enabled.
>
> While that would work, I've been trying to move in the opposite
> direction by trying to dis-connect them from CPU idle.
>
> > In that case not only we can't defer the resume (by
> > using a workqueue), but also we have to finish the resume within strict time
> > constraints (the time to leave the given C-like-state is one of the parameters
> > used by cpuidle governors to decide which state to choose).
> >
> > On the other hand, busy waiting (by looping) in the case the state is
> > RPM_RESUMING is as though the callbacks were executed under a spinlock and we
> > happened to wait on it. I'd prefer to avoid that. Moreover, if the state is
> > RPM_SUSPENDING at the time a "fast path" resume is started, we are almost
> > guaranteed to violate the time constraints (by busy waiting for the suspend to
> > complete and carrying out the resume).
> >
> > So, here's an idea:
> >
> > First, let's introduce two flags in struct dev_pm_info, irq_safe and
> > fast_resume. The former has to be set so that the things above work.
> >
> > Second, let's add a new flag to pass to __pm_runtime_{suspend|resume}(),
> > RPM_FAST_RESUME such that if it is passed to __pm_runtime_suspend(), it
> > causes fast_resume to be set for the given device (if the status is already
> > RPM_SUSPENDED, it just sets the flag, otherwise it suspends the device
> > normally and then sets the flag). Now, if fast_resume is set,
> > __pm_runtime_resume() has to be passed RPM_FAST_RESUME, or it will
> > fail (it also will fail if passed RPM_FAST_RESUME and fast_resume isn't
> > set). In that case the status has to be RPM_SUSPENDED or RPM_RESUMING
> > (otherwise fast_resume won't be set) and if it is RPM_RESUMING, this means
> > that the other resume has been called with RPM_FAST_RESUME too (it would
> > fail otherwise), so it's fine to busy loop until the status is RPM_SUSPENDED
> > (it's the caller's problem to avoid that). RPM_FAST_RESUME causes
> > __pm_runtime_resume() to avod turning interrupts on.
> >
> > If necessary, there may be a flag for __pm_runtime_suspend() that will
> > carry out "atomic" suspend, but I'm not sure if that's necessary. Kevin?
>
> I think we'll need both "atomic" suspend & resume.
>
> One of the devices I'm currently managing in this atomic fashion (inside
> pm_idle) is the UARTs (of course, I'm not currently using runtime PM for
> this, I'm calling platform-specific hooks directly since IRQs are
> disabled.) For the UARTs I'm using both atomic suspend and resume,
> primarily for debug so I am sure UARTs are awake to see any panics
> during the last parts of the suspend/idle process and the early parts of
> the resume path. This UART case is a bit of a hack until the driver is
> converted to runtime PM, but illustrates some debug related reasons we
> might also need atomic suspend and resume.
>
> We also have some workarounds for hardware errata that require
> putting certain devices in a specific state just before (and after)
> idle. The drivers for these devices will need both suspend and resume.
OK, thanks for the info.
Do you need "normal" resume to work after "atomic" suspend, or is it
sufficient that "atomic" suspend will require "atomic" resume?
Rafael
^ permalink raw reply
* Re: [PATCH] memcg: lock-free clear page writeback (Was Re: [PATCH 04/10] memcg: disable local interrupts in lock_page_cgroup()
From: Minchan Kim @ 2010-10-07 23:35 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki
Cc: Daisuke Nishimura, Greg Thelen, Andrew Morton, linux-kernel,
linux-mm, containers, Andrea Righi, Balbir Singh
In-Reply-To: <20101007152422.c5919517.kamezawa.hiroyu@jp.fujitsu.com>
Hi Kame,
On Thu, Oct 7, 2010 at 3:24 PM, KAMEZAWA Hiroyuki
<kamezawa.hiroyu@jp.fujitsu.com> wrote:
> Greg, I think clear_page_writeback() will not require _any_ locks with this patch.
> But set_page_writeback() requires it...
> (Maybe adding a special function for clear_page_writeback() is better rather than
> adding some complex to switch() in update_page_stat())
>
> ==
> From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
>
> Now, at page information accounting, we do lock_page_cgroup() if pc->mem_cgroup
> points to a cgroup where someone is moving charges from.
>
> At supporing dirty-page accounting, one of troubles is writeback bit.
> In general, writeback can be cleared via IRQ context. To update writeback bit
> with lock_page_cgroup() in safe way, we'll have to disable IRQ.
> ....or do something.
>
> This patch waits for completion of writeback under lock_page() and do
> lock_page_cgroup() in safe way. (We never got end_io via IRQ context.)
>
> By this, writeback-accounting will never see race with account_move() and
> it can trust pc->mem_cgroup always _without_ any lock.
>
> Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
> ---
> mm/memcontrol.c | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> Index: mmotm-0928/mm/memcontrol.c
> ===================================================================
> --- mmotm-0928.orig/mm/memcontrol.c
> +++ mmotm-0928/mm/memcontrol.c
> @@ -2183,17 +2183,35 @@ static void __mem_cgroup_move_account(st
> /*
> * check whether the @pc is valid for moving account and call
> * __mem_cgroup_move_account()
> + * Don't call this under pte_lock etc...we'll do lock_page() and wait for
> + * the end of I/O.
> */
> static int mem_cgroup_move_account(struct page_cgroup *pc,
> struct mem_cgroup *from, struct mem_cgroup *to, bool uncharge)
> {
> int ret = -EINVAL;
> +
> + /*
> + * We move severl flags and accounting information here. So we need to
> + * avoid the races with update_stat routines. For most of routines,
> + * lock_page_cgroup() is enough for avoiding race. But we need to take
> + * care of IRQ context. If flag updates comes from IRQ context, This
> + * "move account" will be racy (and cause deadlock in lock_page_cgroup())
> + *
> + * Now, the only race we have is Writeback flag. We wait for it cleared
> + * before starting our jobs.
> + */
> +
> + lock_page(pc->page);
> + wait_on_page_writeback(pc->page);
> +
> lock_page_cgroup(pc);
> if (PageCgroupUsed(pc) && pc->mem_cgroup == from) {
> __mem_cgroup_move_account(pc, from, to, uncharge);
> ret = 0;
> }
> unlock_page_cgroup(pc);
> + unlock_page(pc->page);
> /*
> * check events
> */
>
>
Looks good to me.
But let me ask a question.
Why do only move_account need this logic?
Is deadlock candidate is only this place?
How about mem_cgroup_prepare_migration?
unmap_and_move
lock_page
mem_cgroup_prepare_migration
lock_page_cgroup
...
softirq happen
lock_page_cgroup
If race happens only where move_account and writeback, please describe
it as comment.
It would help to review the code in future.
--
Kind regards,
Minchan Kim
^ permalink raw reply
* Re: [PATCH] memcg: lock-free clear page writeback (Was Re: [PATCH 04/10] memcg: disable local interrupts in lock_page_cgroup()
From: Minchan Kim @ 2010-10-07 23:35 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki
Cc: Daisuke Nishimura, Greg Thelen, Andrew Morton, linux-kernel,
linux-mm, containers, Andrea Righi, Balbir Singh
In-Reply-To: <20101007152422.c5919517.kamezawa.hiroyu@jp.fujitsu.com>
Hi Kame,
On Thu, Oct 7, 2010 at 3:24 PM, KAMEZAWA Hiroyuki
<kamezawa.hiroyu@jp.fujitsu.com> wrote:
> Greg, I think clear_page_writeback() will not require _any_ locks with this patch.
> But set_page_writeback() requires it...
> (Maybe adding a special function for clear_page_writeback() is better rather than
> adding some complex to switch() in update_page_stat())
>
> ==
> From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
>
> Now, at page information accounting, we do lock_page_cgroup() if pc->mem_cgroup
> points to a cgroup where someone is moving charges from.
>
> At supporing dirty-page accounting, one of troubles is writeback bit.
> In general, writeback can be cleared via IRQ context. To update writeback bit
> with lock_page_cgroup() in safe way, we'll have to disable IRQ.
> ....or do something.
>
> This patch waits for completion of writeback under lock_page() and do
> lock_page_cgroup() in safe way. (We never got end_io via IRQ context.)
>
> By this, writeback-accounting will never see race with account_move() and
> it can trust pc->mem_cgroup always _without_ any lock.
>
> Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
> ---
> mm/memcontrol.c | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> Index: mmotm-0928/mm/memcontrol.c
> ===================================================================
> --- mmotm-0928.orig/mm/memcontrol.c
> +++ mmotm-0928/mm/memcontrol.c
> @@ -2183,17 +2183,35 @@ static void __mem_cgroup_move_account(st
> /*
> * check whether the @pc is valid for moving account and call
> * __mem_cgroup_move_account()
> + * Don't call this under pte_lock etc...we'll do lock_page() and wait for
> + * the end of I/O.
> */
> static int mem_cgroup_move_account(struct page_cgroup *pc,
> struct mem_cgroup *from, struct mem_cgroup *to, bool uncharge)
> {
> int ret = -EINVAL;
> +
> + /*
> + * We move severl flags and accounting information here. So we need to
> + * avoid the races with update_stat routines. For most of routines,
> + * lock_page_cgroup() is enough for avoiding race. But we need to take
> + * care of IRQ context. If flag updates comes from IRQ context, This
> + * "move account" will be racy (and cause deadlock in lock_page_cgroup())
> + *
> + * Now, the only race we have is Writeback flag. We wait for it cleared
> + * before starting our jobs.
> + */
> +
> + lock_page(pc->page);
> + wait_on_page_writeback(pc->page);
> +
> lock_page_cgroup(pc);
> if (PageCgroupUsed(pc) && pc->mem_cgroup == from) {
> __mem_cgroup_move_account(pc, from, to, uncharge);
> ret = 0;
> }
> unlock_page_cgroup(pc);
> + unlock_page(pc->page);
> /*
> * check events
> */
>
>
Looks good to me.
But let me ask a question.
Why do only move_account need this logic?
Is deadlock candidate is only this place?
How about mem_cgroup_prepare_migration?
unmap_and_move
lock_page
mem_cgroup_prepare_migration
lock_page_cgroup
...
softirq happen
lock_page_cgroup
If race happens only where move_account and writeback, please describe
it as comment.
It would help to review the code in future.
--
Kind regards,
Minchan Kim
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [RFC] CONFIG_NET_DMA can hang the system if DMA engine driver uses tasklets
From: Ilya Yanok @ 2010-10-07 23:14 UTC (permalink / raw)
To: linux-kernel, dan.j.williams, 'Vladimir K'; +Cc: Wolfgang Denk
Hi Dan, everybody.
I use mpc512x_dma driver which utilizes tasklet to free completed
descriptors. With CONFIG_NET_DMA enabled the whole system hangs during
network throughput testing. I've done some investigation and found that
at some point we run out of descriptors and for some reason my tasklet
is not executed. After doing some more investigation I've found this
reason. Here is a stack dump at the moment of hang:
[ 1220.884981] BUG: soft lockup - CPU#0 stuck for 61s! [syslogd:1177]
[ 1220.891143] Modules linked in:
[ 1220.894192] NIP: c02739c0 LR: c027222c CTR: c0273950
[ 1220.899144] REGS: c7ffbbf0 TRAP: 0901 Not tainted
(2.6.36-rc5-00159-gf3beefd-dirty)
[ 1220.907029] MSR: 00009032 <EE,ME,IR,DR> CR: 88284482 XER: 20000000
[ 1220.913408] TASK = c78723e0[1177] 'syslogd' THREAD: c7ada000
[ 1220.918870] GPR00: c78a40ac c7ffbca0 c78723e0 00000000 000005a8
07b22892 00000000 c78a4084
[ 1220.927245] GPR08: 00009032 c78a40ac 10056948 c059f960 00000000
[ 1220.933460] NIP [c02739c0] mpc_dma_prep_memcpy+0x70/0x22c
[ 1220.938849] LR [c027222c] dma_async_memcpy_buf_to_pg+0xd4/0x1c0
[ 1220.944745] Call Trace:
[ 1220.947186] [c7ffbca0] [00009032] 0x9032 (unreliable)
[ 1220.952234] [c7ffbcb0] [20000000] 0x20000000
[ 1220.956502] [c7ffbcd0] [c0273398] dma_memcpy_to_iovec+0xe8/0x180
[ 1220.962511] [c7ffbd10] [c029f040] dma_skb_copy_datagram_iovec+0x200/0x218
[ 1220.969292] [c7ffbd50] [c02c2b9c] tcp_rcv_established+0x6c4/0x7c4
[ 1220.975380] [c7ffbd80] [c02c8ffc] tcp_v4_do_rcv+0xc0/0x1d0
[ 1220.980861] [c7ffbdb0] [c02caffc] tcp_v4_rcv+0x530/0x7b4
[ 1220.986175] [c7ffbde0] [c02ab494] ip_local_deliver+0x9c/0x1fc
[ 1220.991914] [c7ffbe00] [c02ab928] ip_rcv+0x334/0x5a8
[ 1220.996877] [c7ffbe30] [c028adf0] __netif_receive_skb+0x2bc/0x318
[ 1221.002966] [c7ffbe60] [c020aff4] gfar_clean_rx_ring+0x2b0/0x4cc
[ 1221.008965] [c7ffbec0] [c020de94] gfar_poll+0x378/0x5e0
[ 1221.014187] [c7ffbf80] [c028e444] net_rx_action+0x9c/0x1ac
[ 1221.019669] [c7ffbfb0] [c0025e84] __do_softirq+0xa8/0x120
[ 1221.025068] [c7ffbff0] [c000ee04] call_do_softirq+0x14/0x24
[ 1221.030641] [c7adbd10] [c00061a0] do_softirq+0x78/0x84
[ 1221.035773] [c7adbd30] [c0025bd0] irq_exit+0x98/0x9c
[ 1221.040734] [c7adbd40] [c000627c] do_IRQ+0xd0/0x140
[ 1221.045612] [c7adbd70] [c000fad4] ret_from_except+0x0/0x14
[ 1221.051120] --- Exception: 501 at __srcu_read_lock+0x18/0x24
[ 1221.051132] LR = fsnotify+0x25c/0x26c
[ 1221.060752] [c7adbe30] [3c4a7839] 0x3c4a7839 (unreliable)
[ 1221.066150] [c7adbe90] [c00896d4] do_readv_writev+0x144/0x1e4
[ 1221.071889] [c7adbf10] [c008a13c] sys_writev+0x4c/0x90
[ 1221.077024] [c7adbf40] [c000f43c] ret_from_syscall+0x0/0x38
[ 1221.082588] --- Exception: c01 at 0x20316098
[ 1221.082598] LR = 0x203c98a8
[ 1221.089962] Instruction dump:
[ 1221.092920] 814c0034 3d200020 60000100 816c0030 61290200 916a0000
914b0004 900c0030
[ 1221.100684] 912c0034 7d000124 2f8c0000 38600000 <419e00cc> 7ca0fb78
814c0024 7c0b2378
We can see that the network stack calls dma_memcpy_to_iovec() function
from the softirq context and it never returns in case of DMA driver runs
out of descriptors and thus blocks the tasklet from being executed. We
have a deadlock.
Dan, I'd like to ask your opinion, do you think this is a problem of
CONFIG_NET_DMA feature implementation or should the DMA engine drivers
be aware of it? How should we fix it?
I can imagine the following possible solutions:
1. Add a possibility to return a failure to the dma_memcpy_to_iovec()
function (and reschedule it from the upper level) to give tasklets a
chance to be executed.
2. Place a restriction on the DMA drivers that descriptors should be
freed from the hard-irq context, not soft-irq and fix the existing drivers.
3. Try to free the descriptors not only from tasklet but also from the
place they get requested.
Maybe somebody has a better solution.
Some additional details on my configuration (pretty PowerPC-specific
though I think this issue is generic one).
I use MPC8308RDB development board based on MPC8308, mpc512x_dma driver
with my fixes and added support for MPC8308.
Kernel version: v2.6.36-rc5-151-g32163f4 + some my patches that is not
accepted into mainline yet.
This issue can be easily reproduced with the integrated eTSEC Ethernet
controller (gianfar driver) but I can't reproduce it with Intel PCIE
card (e1000e driver).
Regards, Ilya.
^ permalink raw reply
* Re: [RFC] CONFIG_NET_DMA can hang the system if DMA engine driver uses tasklets
From: Dan Williams @ 2010-10-07 23:33 UTC (permalink / raw)
To: Ilya Yanok
Cc: linux-kernel@vger.kernel.org, 'Vladimir K', Wolfgang Denk
In-Reply-To: <4CAE5445.4020106@emcraft.com>
On 10/7/2010 4:14 PM, Ilya Yanok wrote:
[..]
> We can see that the network stack calls dma_memcpy_to_iovec() function
> from the softirq context and it never returns in case of DMA driver runs
> out of descriptors and thus blocks the tasklet from being executed. We
> have a deadlock.
>
> Dan, I'd like to ask your opinion, do you think this is a problem of
> CONFIG_NET_DMA feature implementation or should the DMA engine drivers
> be aware of it? How should we fix it?
>
> I can imagine the following possible solutions:
> 1. Add a possibility to return a failure to the dma_memcpy_to_iovec()
> function (and reschedule it from the upper level) to give tasklets a
> chance to be executed.
> 2. Place a restriction on the DMA drivers that descriptors should be
> freed from the hard-irq context, not soft-irq and fix the existing drivers.
> 3. Try to free the descriptors not only from tasklet but also from the
> place they get requested.
This is what ioatdma and iop-adma do i.e. process descriptor reclaim
from the allocation failure path. For example in ioat2_check_space_lock():
/* progress reclaim in the allocation failure case we may be
* called under bh_disabled so we need to trigger the timer
* event directly
*/
if (jiffies > chan->timer.expires && timer_pending(&chan->timer)) {
struct ioatdma_device *device = chan->device;
mod_timer(&chan->timer, jiffies + COMPLETION_TIMEOUT);
device->timer_fn((unsigned long) &chan->common);
}
The assumption is that a free descriptor is always a short time delay.
> Maybe somebody has a better solution.
Not really, but extending dmatest with a test for this expectation would
help make this more clear but it would need a config option that injects
descriptor allocation failures.
--
Dan
^ permalink raw reply
* Re: [PATCH] sdhci: highspeed: check for mmc as well as sd cards
From: Philip Rakity @ 2010-10-07 23:27 UTC (permalink / raw)
To: linux-mmc@vger.kernel.org
In-Reply-To: <41A82D88-6200-469C-986D-EF46B0C6A773@marvell.com>
validated code when testing eMMC dual data rate.
On Oct 6, 2010, at 11:57 AM, Philip Rakity wrote:
>
> when examining the code in the mmc directory the SD and MMC code
> set highspeed using a different constant. Change the sd driver
> to recognize this and switch to high speed.
>
> Signed-off-by: Philip Rakity <prakity@marvell.com>
> ---
> drivers/mmc/host/sdhci.c | 5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index d3f924b..1d3f4d8 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -1194,8 +1194,9 @@ static void sdhci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
> else
> ctrl &= ~SDHCI_CTRL_4BITBUS;
>
> - if (ios->timing == MMC_TIMING_SD_HS &&
> - !(host->quirks & SDHCI_QUIRK_NO_HISPD_BIT))
> + if ((ios->timing == MMC_TIMING_SD_HS
> + || ios->timing == MMC_TIMING_MMC_HS)
> + && !(host->quirks & SDHCI_QUIRK_NO_HISPD_BIT))
> ctrl |= SDHCI_CTRL_HISPD;
> else
> ctrl &= ~SDHCI_CTRL_HISPD;
> --
> 1.6.0.4
>
^ 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.