];
It has been introduced by commit
ba8bbcf6ff4650712f64c0ef61139c73898e2165, which seems to be you Jesse.
Just a silly off by one, don't know why I didn't catch it earlier. I'll push
the fix to the drm tree. Linus, you may want to take it in parallel.
Jesse
Make sure we have enough room for all
for
you (this one in particular is the one I'm worried may break 855).
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/
y").
For legacy memory, we actually have /sys/bus/pci//legacy_mem
(though ia64 may be the only supported platform). It's actually
required on some arches due to the way this space is allocated across
the system.
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/
t commit itself needed a couple of follow on bug fixes, but the point
is that you could download 7.3.20 from sourceforge (which would compile
on your kernel) and compare the performance with it if you were
interested in a further experiment.
Jesse
--
To unsubscribe from this list: send the line &qu
a couple of follow on bug fixes, but the point
is that you could download 7.3.20 from sourceforge (which would compile
on your kernel) and compare the performance with it if you were
interested in a further experiment.
Jesse
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
more often stolen system memory).
For legacy memory, we actually have /sys/bus/pci/busno/legacy_mem
(though ia64 may be the only supported platform). It's actually
required on some arches due to the way this space is allocated across
the system.
Jesse
--
To unsubscribe from this list: send
ook to disable SMM/NMI/etc.
around PCI probing)
What else was there? What reason do we have to think that things are so
disastrous?
So I really prefer willy's approach to Arjan's alternative...
Jesse
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
nly.
> If that's the case then the original changelog entry "Move PCI-Express
> device IDs over to e1000e" is misleading as it's not only PCI-Express
> devices...
Unfortunate bit of confusion over terminology.
> Hmmm. Or does which driver is loaded decide on which
is misleading as it's not only PCI-Express
devices...
Unfortunate bit of confusion over terminology.
Hmmm. Or does which driver is loaded decide on which bus the device
ends up?
Hope this helped,
Jesse
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
.
around PCI probing)
What else was there? What reason do we have to think that things are so
disastrous?
So I really prefer willy's approach to Arjan's alternative...
Jesse
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED
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
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-by: Jesse Barnes [EMAIL PROTECTED
.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 load) and I can't unload the m
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 load) and I can't unload the module.
Jesse
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
> 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. Thanks for testing agai
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
--
To unsubscribe
, 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
--
To unsubscribe from this list: send
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. Thanks for testing again, I
guess the patch is good to go.
Jesse
--
To unsubscribe from this list: send the line
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.
>>
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.
Somewhere the range was
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
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 interrupt
rescheduling based on the return value from
ould 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 PROT
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 PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
inning to be tested widely with the deployment of
Vista, so we'll doubtless see more problems on older chipsets if we
enable it by default.
Jesse
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majo
you confirm that your box boots fine with that patch
> > > applied?
> >
> > Yes it does.
>
> thanks for testing it. (and thanks for finding & reporting the
> problem) I've added that patch to x86.git, right before:
>
> Subject: x86: validate against ACPI motherb
) I've added that patch to x86.git, right before:
Subject: x86: validate against ACPI motherboard resources
this should be the only dependency AFAICS.
Yeah, that should work afaik, thanks for sorting this out.
Jesse
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
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 "uns
already in DRM git.
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/
ether it was 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 line &
ing 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 routines for
, many devices really only need either MMIO or IO
space enabled, not both, so having separate enable/disable routines for
them makes a lot of sense.
Jesse
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info
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 line unsubscribe linux-kernel
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
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);
>
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);
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.
Brandeburg,
Don't we need to return non-zero work_done after
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
>
forwarding whole message for netdev to review
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
, 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
> > > reg05: b
: base=0xcf70 (3319MB), size= 1MB: uncachable, count=1
reg05: base=0x1 (4096MB), size= 512MB: write-back,
count=1 reg06: base=0x12000 (4608MB), size= 128MB:
write-back, count=1
Jesse Barnes (cc:d) wrote a patch to address this, I think (x86:
trim memory not covered by WB
sure the
values read from the base regs actually matched what the firmware was
telling us in the ACPI tables (at least iirc, it's been awhile since I
looked at the patch).
So don't be too nervous. :)
Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
th
rs figured no one actually uses MMCONFIG yet
(Windows == whole world of users), so why worry about that particular
bug?
The "not E820-reserved" message is actually bogus. I'll bet MMCONFIG
works fine on your machine with Robert's patch and the disable decode
stuff applied.
On Tuesday, October 30, 2007 3:22 pm Linus Torvalds wrote:
> On Tue, 30 Oct 2007, Jesse Barnes wrote:
> > The per-device flag is fine with me, but I should make something
> > clear:
> >
> > MMCONFIG IS NOT BROKEN!
>
> Trust me, it is.
>
> The particular pr
can either use I/O ports for sizing and only switch to MMCONFIG
later, or we can just use it on an as-needed basis, or we can make our
PCI probing safe if MMCONFIG is in use.
Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a me
to MMCONFIG
later, or we can just use it on an as-needed basis, or we can make our
PCI probing safe if MMCONFIG is in use.
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
On Tuesday, October 30, 2007 3:22 pm Linus Torvalds wrote:
On Tue, 30 Oct 2007, Jesse Barnes wrote:
The per-device flag is fine with me, but I should make something
clear:
MMCONFIG IS NOT BROKEN!
Trust me, it is.
The particular problem _you_ had with it is only a small small part
that particular
bug?
The not E820-reserved message is actually bogus. I'll bet MMCONFIG
works fine on your machine with Robert's patch and the disable decode
stuff applied.
Jesse
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
the firmware was
telling us in the ACPI tables (at least iirc, it's been awhile since I
looked at the patch).
So don't be too nervous. :)
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
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 is
>
ot 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 wonder if there's an easy way to gu
preciate 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's not a whole
lot we can do a
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 is
cache-coherent.
Right
.
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 wonder if there's an easy way to guarantee this with the
pci_bus* routines...
Jesse
-
To unsubscribe from this list: send the line
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's not a whole
lot we can do about that.
Jesse
-
To unsubscribe from this list: send
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 feature? I wonder if we should rip that out too, just
> >
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 yet
e 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 PROTECTED]
More majordomo info at
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 like it, and I got rep
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 d
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 revie
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 review of its device model usage, can
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 like it, and I got reports that it
wasn't even
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't have an
alternative at this point
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 PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please
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 yet another version that uses the device model
a partially
implemented feature? I wonder if we should rip that out too, just
to keep things simple...
Hehe, that's always a solution. :)
Yeah, removing code is nearly always a win. :)
Thanks,
Jesse
diff --git a/linux-core/drmP.h b/linux-core/drmP.h
index d0ab2c9..82a3a23 100644
--- a/linux
ring 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 (*postclose) (st
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..
>
> [EMAIL PROT
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..
[EMAIL PROTECTED] wrote
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 (*postclose) (struct
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 go in, so
r 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 would help, or
could put parens around it if you think that would help, or just move it to
a new line...
I think I seen some #if 0 code just remove that.
Oh I left some in there? Yeah I'll remove it.
Thanks,
Jesse
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
this is a long overdue change, but Dave has some custom
stuff that requires both drivers so he'd rather not see it go in, so
I'm fine with dropping this part.
Jesse
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo
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
> it.
Ok Dave, thi
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
it.
Ok Dave, this one's been updated
On Thursday, October 18, 2007 2:01 pm Jesse Barnes wrote:
> We seem to see a lot of bug reports along the lines of, "my machine
> resumes but I can't see X" or, "I can see X but only with a bright
> flashlight", etc. These sorts of problems are due to the fact that
On Thursday, October 18, 2007 2:01 pm Jesse Barnes wrote:
We seem to see a lot of bug reports along the lines of, my machine
resumes but I can't see X or, I can see X but only with a bright
flashlight, etc. These sorts of problems are due to the fact that
the X server isn't designed to do
ituations with other drivers? Thoughts?
Thanks,
Jesse
diff --git a/linux-core/Kconfig b/linux-core/Kconfig
index 2d02c76..5e73fc7 100644
--- a/linux-core/Kconfig
+++ b/linux-core/Kconfig
@@ -50,7 +50,7 @@ config DRM_I810
choice
prompt "Intel 830M, 845G, 852GM, 855GM, 865G"
drivers? Thoughts?
Thanks,
Jesse
diff --git a/linux-core/Kconfig b/linux-core/Kconfig
index 2d02c76..5e73fc7 100644
--- a/linux-core/Kconfig
+++ b/linux-core/Kconfig
@@ -50,7 +50,7 @@ config DRM_I810
choice
prompt Intel 830M, 845G, 852GM, 855GM, 865G
- depends on DRM AGP AGP_INTEL
On Tuesday, October 16, 2007 11:25 pm Henrique de Moraes Holschuh wrote:
> On Tue, 16 Oct 2007, Jesse Barnes wrote:
> > > Last time the issue was brought up (and I do believe it was
> > > because of thinkpad-acpi :-) ), he made it clear that any events
> > > you are
On Tuesday, October 16, 2007 11:25 pm Henrique de Moraes Holschuh wrote:
On Tue, 16 Oct 2007, Jesse Barnes wrote:
Last time the issue was brought up (and I do believe it was
because of thinkpad-acpi :-) ), he made it clear that any events
you are to act upon are fine in input, but events
On Tuesday, October 16, 2007 2:18 am Henrique de Moraes Holschuh wrote:
> On Tue, 16 Oct 2007, Jesse Barnes wrote:
> > On Tuesday, October 16, 2007 1:36 am Henrique de Moraes Holschuh
wrote:
> > > You want ACPI video to just pass the messages to userspace when
> > > X.o
he display they control and only *one* backlight
driver should be registered for a given display. Unfortunately we
don't have enough info in the kernel to identify displays, so those
changes may have to wait until the DRM grows such knowledge.
Jesse
-
To unsubscribe from this list: send the line
. Unfortunately we
don't have enough info in the kernel to identify displays, so those
changes may have to wait until the DRM grows such knowledge.
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
On Tuesday, October 16, 2007 2:18 am Henrique de Moraes Holschuh wrote:
On Tue, 16 Oct 2007, Jesse Barnes wrote:
On Tuesday, October 16, 2007 1:36 am Henrique de Moraes Holschuh
wrote:
You want ACPI video to just pass the messages to userspace when
X.org is driving the backlight? Fine
others will
probably follow eventually.
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/
. Otherwise if another driver touches it the driver and
firmware will be out of sync, causing unexpected and undesirable
behavior. We intend to fix this for the Intel driver at least
(requiring both ACPI video driver and gfx driver updates), others will
probably follow eventually.
Jesse
le 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" in
the body of a messag
,
as long as we're careful about adding new ones.
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/
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 body of a message to [EMAIL PROT
'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/
...
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/
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 body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
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 message to
..)
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 message to [EMAIL PROTECTED]
More majordomo info at http
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
> > >
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 of a m
ring 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 this list: send the line &quo
501 - 600 of 1411 matches
Mail list logo
