5 and 965, I
> think the author found the latter to be problematic since the chipset
> had the table mapped over top of motherboard resources. The extra
> checking here may catch that case if we add that chipset-specific
> support.
>
> Applies to 2.6.21.1.
>
> Signed-off-by: R
On Wednesday, May 23, 2007 5:21:13 Linus Torvalds wrote:
> On Wed, 23 May 2007, Jesse Barnes wrote:
> > After I sent my last message I realized the same thing... though I
> > occasionally hear people talk about removing it (I seriously doubt that
> > will ever happen). I don
On Wednesday, May 23, 2007 5:20:46 Wayne Sherman wrote:
> Ivan Kokshaysky wrote:
> > No, it won't help. The 1M range (ff50-ff5f) is more than enough.
>
> Good catch, I didn't look close enough at the allocations of the devices
> under the bridge.
>
> > The reason why the D-Link resource is
On Wednesday, May 23, 2007 8:08:23 Jesse Barnes wrote:
> On Wednesday, May 23, 2007 5:20:46 Wayne Sherman wrote:
> > Ivan Kokshaysky wrote:
> > > No, it won't help. The 1M range (ff50-ff5f) is more than
> > > enough.
> >
> > Good catch, I didn&#
done the same way (I haven't looked) and so we might run
into the same problems there.
Thanks,
Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
But how often do you have to debug bootloader or compressed boot code? In
fact, most debug output like this isn't very useful after some initial
debugging, so we usually take it out. I'm not sure why this would be any
different...
Jesse
-
To unsubscribe from this list: send the
On Friday, May 25, 2007 4:28:18 H. Peter Anvin wrote:
> Jesse Barnes wrote:
> > But how often do you have to debug bootloader or compressed boot code?
> > In fact, most debug output like this isn't very useful after some initial
> > debugging, so we usually take it o
On Friday, May 25, 2007 4:43:41 H. Peter Anvin wrote:
> Jesse Barnes wrote:
> > Right, but you're special that way. And moreover, you would know how to
> > add such debug statements as needed. But is this output something we
> > really need enabled unconditionally fo
t someplace completely unsuitable like on top of RAM or other
> registers. It seems that with some of those 965 chipsets the latter is
> what the BIOS is actually doing, and so when we think we're writing to
> the table we're really writing to random chipset registers and hosing
&g
On Sunday, April 29, 2007 7:10 pm Robert Hancock wrote:
> Jesse Barnes wrote:
> > Add support for Intel 915 bridge chips to the new PCI MMConfig
> > detection code. Tested and works on my sole 915 based platform (a
> > Toshiba laptop). I added register masking per Oliver&
e the MFCG ACPI
> table without questions.
We need to look at the register, but we may not want to use it if it looks
too confused. If it doesn't agree with what we see in ACPI, we likely
have a problem due to the issues Robert outlined in his other mail.
Jesse
-
To unsubscribe from t
ntion of it from the documentation.
Signed-off-by: Jesse Barnes <[EMAIL PROTECTED]>
Thanks,
Jesse
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 84c3bd0..49b1ea3 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-pa
rformance as long as you make
sure you use the libata based drivers for everything. If you're
running Fedora I think the rawhide kernels are configured this way, but
the fc6 era kernels aren't.
Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" i
out the pata controller interface and both my hd
> and od are on the second
> channel of the pata.
>
> So can I configure out the old ide and just have ata_piix
> automatically control them both in
> 2.6.21?
Yeah, I think that'll work. You could try an FC7 .config file i
ff in mmconfig-shared.c to check against the register
values like Olivier mentioned?
Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
ci_mmcfg_check_hostbridge returns a
failure, there's no way MCFG space can work, so we should disable it
unconditionally in that case (even if ACPI says "trust me, when have I
ever lied to you?").
I'm testing it now on my 965...
Thanks,
Jesse
-
To unsubscribe from this list: send the
On Tuesday, May 01, 2007, Jesse Barnes wrote:
> On Monday, April 30, 2007, Olivier Galibert wrote:
> > On Sun, Apr 29, 2007 at 08:14:37PM -0600, Robert Hancock wrote:
> > > -Validate that the area is reserved even if we read it from the
> > > chipset directly and no
On Tuesday, May 01, 2007, Jesse Barnes wrote:
> > I'm testing it now on my 965...
>
> Bah... nevermind Robert, I see you're doing this already in
> pci_mmcfg_reject_broken. I'm about to reboot & test now.
Ok, I've tested a bit on my 965 (after re-adding m
On Wednesday, May 2, 2007 7:34 am Robert Hancock wrote:
> Jesse Barnes wrote:
> > On Tuesday, May 01, 2007, Jesse Barnes wrote:
> >>> I'm testing it now on my 965...
> >>
> >> Bah... nevermind Robert, I see you're doing this already in
> >>
On Wednesday, May 2, 2007 4:45 pm Robert Hancock wrote:
> Jesse Barnes wrote:
> > On Wednesday, May 2, 2007 7:34 am Robert Hancock wrote:
> >> Jesse Barnes wrote:
> >>> On Tuesday, May 01, 2007, Jesse Barnes wrote:
> >>>>> I'm testing it now
(it's mostly by node first, then by zone iirc, but has a
few other tweaks).
Another option would be to make this behavior automatic if both ZONE_DMA
and ZONE_NORMAL had pages. I initially wrote this stuff with the idea
that machines that really needed it would have all their memory in
ZONE_
cation,
etc. It should be enough to clear the scanout buffer and output the
printk, though if there's a lot of rendering going on, the DRM driver
might have to be pretty smart about it.
Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body o
he right thing to do...
So aside from the comment issues Lee already pointed out, I think
Kamezawa-san's patch from
http://marc.info/?l=linux-mm&m=117758484122663&w=4 seems reasonable.
Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bo
e address
space for mmconfig usage. If the BIOS doesn't completely describe all
the reserved regions via e820 or similar (apparently a common problem)
we may end up making mmconfig overlap with another important area...
It's pretty hard not to trust the BIOS here without completely
re
On Thursday, September 6, 2007 10:50 am Yinghai Lu wrote:
> On 9/6/07, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> > The problem with doing that is it would mean reserving some address
> > space for mmconfig usage. If the BIOS doesn't completely describe
> > all
FYI, we just released a new white paper describing memory ordering for
Intel processors:
http://developer.intel.com/products/processor/manuals/index.htm
Should help answer some questions about some of the ordering primitives
we use on i386 and x86_64.
Jesse
-
To unsubscribe from this list
hanks,
Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Wednesday, September 12, 2007, Randy Dunlap wrote:
> On Wed, 12 Sep 2007 08:33:15 -0700 Jesse Barnes wrote:
> > I just narrowed down a weird problem where I was losing more than
> > 50% of my vblank interrupts to what seems to be the hires timers
> > patch. Stock 2.6.23-rc
Joonwoo Park wrote:
> /* If no Tx and not enough Rx work done, exit the polling mode */
> if ((!tx_cleaned && (work_done == 0)) ||
>!netif_running(poll_dev)) {
> quit_polling:
> if (likely(adapter->itr_setting & 3))
> e1000_set_itr(adapter);
> netif_rx_co
Joonwoo Park wrote:
> 2007/12/12, Brandeburg, Jesse <[EMAIL PROTECTED]>:
>>
>> all drivers using NAPI in 2.6.24+ (NNAPI??) must return zero here,
>> after calling netif_rx_complete. netif_rx_complete plus work_done
>> != 0 causes a bug.
>>
>
> B
iling to allocate space for the device with
the root drive on it, there are probably bigger issues than just
failing to get a few bytes of I/O space for it...
OTOH like Robert said, many devices really only need either MMIO or IO
space enabled, not both, so having separate enable/disable routine
s a good idea or
not...
The advantage of a specific post-mmap call is that it would make setting the
attribute types a little easier, so either ioctl or madvise seems preferable
to mmapping over and over with different flags until you get the mapping.
Jesse
--
To unsubscribe from this list: send the l
you could apply the
original patch, and remove this "break" just by commenting out line
4008. This would guarantee all tx work is cleaned at every e1000_clean
Jesse
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PR
David Miller wrote:
> From: "Brandeburg, Jesse" <[EMAIL PROTECTED]>
> Date: Tue, 15 Jan 2008 13:53:43 -0800
>
>> The tx code has an "early exit" that tries to limit the amount of tx
>> packets handled in a single poll loop and requires napi or inte
Andrew Morton wrote:
> On Thu, 17 Jan 2008 11:22:19 -0800 "Pallipadi, Venkatesh"
> <[EMAIL PROTECTED]> wrote:
>
>>
>> The problem is
modprobe:2584 conflicting cache attribute 5000-50001000
uncached<->default
>>
>> Some address range here is being mapped with conflicting types.
>>
enable it for AMD as well, and it would also be
good to track down the one failure you found... I don't *think* the
re-ordering of MTRR initialization should affect AMDs anymore than it does
Intel, but someone familiar with the boot code would have to do a quick audit
to be sure.
Jesse
--
it looks good.
>
> I think it should be enabled on AMD too though. If the reordering breaks
> it then blacklisting won't help anyways.
>
> -Andi
>
> [1] but I checked the known errata and there was nothing related to MTRR.
Ah, ok, that explains your reticence earlier. Tha
sage
count = 1
Where 2.6.24-rc5 e1000 is okay still. Seems like maybe we are still
missing a netif_rx_complete or a napi_disable somewhere.
I don't think this problem has anything to do with the irq_sem right
now. Something is still badly broken. I am just using the interface
regularly (no heavy
cpu for x86_32, and move mtrr_bp_init early
>
> compiled test only, need someone test it
I like this approach too. So as long as the E820 modification method works
(i.e. we have some testers, maybe Justin can give it a try), you can add
Signed-off-by: Jesse Barnes <[EMAIL PROTECTED]>
or
Acked
0 (2048MB), size=1024MB: write-back, count=1
> > > reg02: base=0xc000 (3072MB), size= 256MB: write-back, count=1
> > > reg03: base=0xcf80 (3320MB), size= 8MB: uncachable, count=1
> > > reg04: base=0xcf70 (3319MB), size= 1MB: uncachable, count=1
> > >
ive me a clue.
This sounds a lot like a problem we had recently. The driver wasn't
preserving its mappings across X startup/shutdown (drm open/close) and so
you'd see crashes like this. It should be fixed already in DRM git.
Jesse
--
To unsubscribe from this list: send the line
Ian Wienand wrote:
> Hi,
>
> When rebooting today I got
>
> Will now restart.
> ACPI: PCI interrupt for device :00:03.0 disabled
> GSI 20 (level, low) -> CPU 1 (0x0100) vector 53 unregistered
> Destroying IRQ53 without calling free_irq
> WARNING: at
> /home/insecure/ianw/programs/git-kernel
n out of range
for a few days...
Thanks,
Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Thursday, September 13, 2007, Chris Snook wrote:
> Jesse Barnes wrote:
> > I just narrowed down a weird problem where I was losing more than
> > 50% of my vblank interrupts to what seems to be the hires timers
> > patch. Stock 2.6.23-rc5 works fine, but the latest (171) ke
On Monday, September 17, 2007, Thomas Gleixner wrote:
> On Mon, 2007-09-17 at 12:13 -0700, Jesse Barnes wrote:
> > On Wednesday, September 12, 2007, Thomas Gleixner wrote:
> > > does it make any difference when you boot the box with:
> > >
> > > nohz=off
&g
On Wednesday, September 12, 2007 11:26 am Dr. David Alan Gilbert wrote:
> * Jesse Barnes ([EMAIL PROTECTED]) wrote:
> > FYI, we just released a new white paper describing memory ordering
> > for Intel processors:
> > http://developer.intel.com/products/processor/manuals/ind
), but we have yet to see any in real
life. Moreover, reversion is trivial, and we could move to a more
complex scheme at that time if needed, but why bother unless we're sure
we need to?
Thanks,
Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the b
helped in this case.
To do this in a nicer way (and be less vulnerable to similar BIOS
funkiness) the kernel really needs full PAT support. That should allow
WC over WB and WC over UC mappings to occur, at least if I'm
remembering the docs right...
Jesse
-
To unsubscribe from this list: s
On Wednesday, September 19, 2007 11:50:23 pm Andi Kleen wrote:
> Jesse Barnes <[EMAIL PROTECTED]> writes:
> > To do this in a nicer way (and be less vulnerable to similar BIOS
> > funkiness) the kernel really needs full PAT support. That should allow
> > WC over WB
On Thursday, September 20, 2007, Jesse Barnes wrote:
> On Wednesday, September 19, 2007 11:50:23 pm Andi Kleen wrote:
> > Jesse Barnes <[EMAIL PROTECTED]> writes:
> > > To do this in a nicer way (and be less vulnerable to similar BIOS
> > > funkiness) the ker
On Thursday, September 20, 2007, Thomas Gleixner wrote:
> On Thu, 2007-09-20 at 12:22 -0700, Jesse Barnes wrote:
> > > Eeek, that sounds scary. Can you add "highres=off" as well ?
> >
> > FWIW I just tried your linux-2.6-hires tree with the attached
> &g
suddenly drops by 99% and only actually important
messages make it to my log...
Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
you can add a
Signed-off-by: Jesse Barnes <[EMAIL PROTECTED]>
to it.
Thanks,
Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please re
support for
the quirk, since I don't have any way of testing it. We can easily add
that later though, if a tester steps forward or we see demand for it
(should just be an extra conditional in the trim code).
Thanks,
Jesse
-
To unsubscribe from this list: send the line "unsubscrib
vice (say the actual data).
If the completion queue write arrives first (which can happen on sn2), the
driver must ensure that the rest of the outstanding DMA is complete prior to
looking at the completion queue status. It can either use a regular PIO read
to do this (i.e. a non-relaxed on
so unless someone can think of
a better way of hiding this architectural detail in lower level code it's
probably a good thing to add (especially given that future revs of PCIe will
probably allow this behavior, and hopefully less ambiguously than the current
spec).
Jesse
-
To unsubscribe fr
that
> allows transaction flushes to be inserted into the stream for devices
> and bridges that have already negotiated relaxed ordering? ... in which
> case we need to take this to the PCI list.
I think it would have to be the latter, since otherwise it would be hard to
setup just comp
On Tuesday, June 26, 2007 8:03:48 am Andi Kleen wrote:
> On Mon, Jun 25, 2007 at 08:30:52PM -0700, Jesse Barnes wrote:
> > Oh, and FYI I've seen new systems with a default mapping type of WB, with
> > a few uncached holes for MMIO. That means PAT will be absolutely
> >
On Tuesday, June 26, 2007 8:07:45 am Jesse Barnes wrote:
> On Tuesday, June 26, 2007 8:03:48 am Andi Kleen wrote:
> > On Mon, Jun 25, 2007 at 08:30:52PM -0700, Jesse Barnes wrote:
> > > Oh, and FYI I've seen new systems with a default mapping type of WB,
> > > wi
On Tuesday, June 26, 2007 8:02:49 am Andi Kleen wrote:
> On Mon, Jun 25, 2007 at 04:36:52PM -0700, Jesse Barnes wrote:
> > On Monday, June 25, 2007 4:34:33 Andi Kleen wrote:
> > > > This patch fixes a bug in the last patch that caused the code to
> > > > run on
t DRM does support much less hardware than the X server?
Yeah, the number of DRM drivers is relatively small compared to X or
fbdev, but for simple DMA they're fairly easy to write.
> Perhaps we just need an ioctl where an X server can switch this.
Switch what? Turn on or off transp
On Wednesday, June 27, 2007 7:22:24 Mauro Giachero wrote:
> On 6/27/07, Pim Zandbergen <[EMAIL PROTECTED]> wrote:
> > Now:
> > Jesse released a new patch and I tried if for fun on 2.6.22-rc6
> > It looks like the patch is releasing memory rather than trimming
> > i
On Wednesday, June 27, 2007 9:00:33 Pim Zandbergen wrote:
> Jesse Barnes wrote:
> > Yeah, you're right I should use an unsigned format string. Pim, if
> > you change it to %lu does the printk in your dmesg look better?
>
> Er, no.
>
> MTRRs do
On Wednesday, June 27, 2007 9:00:33 Pim Zandbergen wrote:
> Jesse Barnes wrote:
> > Yeah, you're right I should use an unsigned format string. Pim, if
> > you change it to %lu does the printk in your dmesg look better?
>
> Er, no.
>
> MTRRs do
On Wednesday, June 27, 2007 10:02:35 Pim Zandbergen wrote:
> Jesse Barnes wrote:
> > It looks like end_pfn might be ~0UL now... can you print that out
> > in your configuration?
>
> Er, do you need the value of end_pfn ?
> Here's what I changed:
>
> if ((hig
t minute on certain AMD machines,
so I'll have to track down that bug before we can push it.
Thanks,
Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Calimero kernel: [drm:i810_wait_ring] *ERROR* lockup
> Jul 24 10:11:31 Calimero kernel: [drm:i810_wait_ring] *ERROR* space:
> 65468 wanted 65528
> Jul 24 10:11:31 Calimero kernel: [drm:i810_wait_ring] *ERROR* lockup
Looks like a DRM driver problem. Can you file a bug for this at
freed
ent. It's really an ordering problem, and
the new API is setting a "barrier" bit in the DMA address that indicates to
the bridge that any outstanding DMA should be written before the barriered
data. So calling it set_flush or set_barrier is fine with me...
Jesse
-
To unsubscribe from
On Wednesday, September 26, 2007 2:18 pm Greg KH wrote:
> Due to the issues surrounding this patch, I'm dropping it from my
> repo.
What issues? Is it causing problems for people?
Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body o
On Wednesday, September 26, 2007 2:56 pm Greg KH wrote:
> On Wed, Sep 26, 2007 at 02:55:55PM -0700, Jesse Barnes wrote:
> > On Wednesday, September 26, 2007 2:18 pm Greg KH wrote:
> > > Due to the issues surrounding this patch, I'm dropping it from my
> > > r
rwise I'll wait until stable..)
Without this patch, my 965GM drops vblank interrupts, so I'd really like to
see it upstream ASAP too.
Acked-by: Jesse Barnes <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a mess
MSI capability that's
> not working.
I don't have a 945 to test with, but Dave might...
Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
I try too
> hard to get it working.
I don't see anything in the docs (either public or private) that would
indicate that MSI is broken on those chips, so I'd expect it to work...
Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bo
lags argument awhile back (~2000), so SGI has been reluctant to push
it again. :)
Glad you're finally coming around, I think a flags argument makes sense,
as long as we're careful about adding new ones.
Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel
On Friday, October 19, 2007, Jesse Barnes wrote:
> Dave can you take a look at the new flag and also see what you think
> about supporting suspend/resume in the event X hasn't started yet?
> There's some #if 0'd code to support that case, but I haven't tested
&g
o pull over uglies from the X code but I guess I forgot
this bit. I should also update the copyright.
> > + unsigned long reg = pipe == PIPE_A ? PALETTE_A : PALETTE_B;
>
> Uff. Mixing = and == and ? in one expression is evil.
I could put parens around it if you think that woul
ession.
Well it's really documenting existing behavior. Unless you're very
careful, running custom applications, the Intel FB and DRM drivers will
conflict. IMO this is a long overdue change, but Dave has some custom
stuff that requires both drivers so he'd rather not see it
I think Greg doesn't like it, even though we don't have an alternative
at this point...
Jesse
On Thursday, October 25, 2007 4:20 pm Robert Hancock wrote:
> Where did this patch go? I didn't get notified that anyone dropped
> it, but I don't see it in current -git..
&
crashes during module unload or X startup.
Thanks,
Jesse
diff --git a/linux-core/Kconfig b/linux-core/Kconfig
diff --git a/linux-core/drmP.h b/linux-core/drmP.h
index d0ab2c9..39fce95 100644
--- a/linux-core/drmP.h
+++ b/linux-core/drmP.h
@@ -619,6 +619,8 @@ struct drm_driver {
void (*post
On Thursday, October 25, 2007 9:59 pm Greg KH wrote:
> On Thu, Oct 25, 2007 at 04:53:18PM -0700, Jesse Barnes wrote:
> > Ok, here's yet another version that uses the device model for the
> > suspend/resume, rather than pci hooks.
> >
> > Greg, DRM desperately needs
On Thursday, October 25, 2007 7:54 pm Greg KH wrote:
> On Thu, Oct 25, 2007 at 04:22:35PM -0700, Jesse Barnes wrote:
> > I think Greg doesn't like it, even though we don't have an
> > alternative at this point...
>
> Yes, I didn't like it, Ivan didn't li
On Thursday, October 25, 2007 10:27 pm Greg KH wrote:
> On Thu, Oct 25, 2007 at 11:03:51PM -0600, Robert Hancock wrote:
> > Greg KH wrote:
> >> On Thu, Oct 25, 2007 at 04:22:35PM -0700, Jesse Barnes wrote:
> >>> I think Greg doesn't like it, even though we don&
IG_SYSFS_DEPRECATED, there will be symlinks instead of
> directories, otherwise the same pathes, like for all other
> (converted) classes too.
Ok, thanks.
Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTE
On Friday, October 26, 2007 10:10 am Kay Sievers wrote:
> On 10/26/07, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> > On Thursday, October 25, 2007 9:59 pm Greg KH wrote:
> > > On Thu, Oct 25, 2007 at 04:53:18PM -0700, Jesse Barnes wrote:
> > > > Ok, here's
relationship in sysfs, so that a
> "device" link is created, or that the device directory lives as a
> child below the parent device. Seems fine so far.
Ok, sounds good.
>
> > Dave, the drm_head stuff is a bit funky; it seems like a partially
> > implemented featur
On Monday, October 29, 2007 1:12 pm Keith Packard wrote:
> On Mon, 2007-10-29 at 12:47 -0700, Jesse Barnes wrote:
> > In this case, we're performing basically a
> > dma_sync*(...DMA_TO_DEVICE) right?
>
> But this is just for the GPU; every other DMA device in the system i
#x27;s not
> > a whole lot we can do about that.
>
> Again I'm trying to workaround broken BIOS.. nothing I can do.
Right, BIOSes are so much fun to deal with. One other thing: it looks
like the flush mmio space has to be allocated above the top of DRAM but
below 4G. I wonde
, I'd
> appreciate any commentary particularly in the setting up of the
> resource stuff.
Looks reasonable, I'm not sure we can do much better. The only concern
I have is that allocating some more PCI space like that may end up
clobbering some *other* hidden BIOS mapping, but there&
> > Greg, please drop Robert's patch and put mine in instead.
>
> Based on looking at your patch it seems OK. The first problem you
> mentioned with what Jesse and I had there is definitely a valid one.
>
> You can add my:
>
> Acked-by: Robert Hancock <[EMAI
Dear All:
Was IC Plus IP1000A Linux Driver in kernel tree or not? Our customer is pushing
us to put it into kernel. Is there anything that we should do?
Thanks.
Best Regards,
Jesse Huang
-Original Message-
From: Francois Romieu [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 12, 2007 6
space access, including
> changing the BAR back to its previous value.
>
> However, don't do this disabling on host bridge devices, as it is
> reported that some of them do silly things like disable CPU to RAM
> access if this is done.
>
> Based on an original patch
ke sure you have i915 loaded before you suspend if you want your text
console to come back.
Jesse
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
>
> > > I have Lenovo ThinkPad T61.
> >
> > If you have CONFIG_CPU_IDLE set, please try to boot with idle=poll and
> > see if that helps.
>
> Just sent this patch to fix a regression in acpi processor_idle.c on
> another thread. Can you try the patch below
ed though ...
We're doing something similar in the DRM these days... We need big chunks of
memory to be pinned so that the GPU can operate on them, but when the
operation completes we can allow them to be swappable again. I think with
the current implementation, allocations are always pin
On Thu, Nov 1, 2012 at 7:33 AM, Christoph Lameter wrote:
> On Thu, 1 Nov 2012, Shan Wei wrote:
>
>> But for different field in same per-cpu variable, how to guarantee n_missed
>> and n_hit are from same cpu?
>> this_cpu_read(dp->stats_percpu->n_missed);
>> [processor changed]
>> this_cpu_read(dp->
to be more defensive about the
resume configuration in case the BIOS did something weird, but overall I
think we should be able to do this one way or another.
Thanks,
Jesse
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kerne
: Jesse Barnes
---
drivers/gpu/drm/i915/i915_dma.c |3 +++
drivers/gpu/drm/i915/i915_drv.c | 28 +---
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm/i915/intel_display.c | 25 +
4 files changed, 54 insertions(+), 3
VT on resume, but rather leave things alone for a nicer looking
suspend and resume sequence.
Signed-off-by: Jesse Barnes
---
include/linux/pm.h |3 +++
kernel/power/console.c |7 +++
2 files changed, 10 insertions(+)
diff --git a/include/linux/pm.h b/include/linux/pm.h
index 00
On Fri, 02 Nov 2012 22:51:07 +0100
"Rafael J. Wysocki" wrote:
> On Friday, November 02, 2012 02:43:39 PM Jesse Barnes wrote:
> > I've lightly tested this with X and it definitely makes my
> > suspend/resume sequence a bit prettier. It should speed things up
>
On 11/2/2012 4:43 PM, Alan Cox wrote:
On Fri, 2 Nov 2012 14:43:40 -0700
Jesse Barnes wrote:
KMS drivers can potentially restore the display configuration without
userspace help. Such drivers can set a new global, pm_vt_switch, to
false if they support this feature. In that case, the PM
101 - 200 of 756 matches
Mail list logo
