On Thu, May 11, 2017 at 11:00 PM, Dave Airlie wrote:
>
> It also has an amdgpu fixes pull, with lots of ongoing work on Vega10
> which is new in this kernel and is preliminary support so may have a
> fair bit of movement.
Note: I will *not* be taking these kinds of pull requests after rc1.
If Ve
Hi Tobias,
Am Sonntag, den 16.08.2015, 14:48 +0200 schrieb Tobias Jakobi:
> Hello,
>
> some time ago I checked whether I could use the userptr functionality to
> do zero-copy from userspace allocated buffers via the G2D. This didn't
> work out so well, so kinda put this to the bottom of my TODO l
Thanks Lucas for the explanation!
Lucas Stach wrote:
> Hi Tobias,
>
> Am Sonntag, den 16.08.2015, 14:48 +0200 schrieb Tobias Jakobi:
>> Hello,
>>
>> some time ago I checked whether I could use the userptr functionality to
>> do zero-copy from userspace allocated buffers via the G2D. This didn't
On Thu 2015-01-29 14:11:25, Dave Airlie wrote:
> These two copy to/from VGA memory, however on the Silicon
> Motion SMI750 VGA card on a 64-bit system cause console corruption.
>
> This is due to the hw being buggy and not handling a 64-bit transaction
> correctly.
>
> We could try and create a 3
On Mon, 9 Feb 2015 11:00:55 +
Daniel Stone wrote:
> On 9 February 2015 at 10:49, Geert Uytterhoeven wrote:
> > On Mon, Feb 9, 2015 at 11:35 AM, Daniel Stone wrote:
> >> On 5 February 2015 at 11:35, One Thousand Gnomes
> >> wrote:
> >>> #if defined (CONFIG_SUPPORT_SHITE_VGA_ADAPTERS)
> >>>
On 5 February 2015 at 11:35, One Thousand Gnomes
wrote:
>> If I'm not mistaken, that would be as simple as adding
>>
>> #define VT_BUF_HAVE_RW.
>> #define scr_writew(val, addr) (*(addr) = (val))
>> #define scr_readw(addr) (*(addr))
>>
>> to arch/x86/include/asm/vga.h.
>
> and stick an
On Mon, Feb 9, 2015 at 11:35 AM, Daniel Stone wrote:
> On 5 February 2015 at 11:35, One Thousand Gnomes
> wrote:
>>> If I'm not mistaken, that would be as simple as adding
>>>
>>> #define VT_BUF_HAVE_RW.
>>> #define scr_writew(val, addr) (*(addr) = (val))
>>> #define scr_readw(addr) (
On 9 February 2015 at 10:49, Geert Uytterhoeven wrote:
> On Mon, Feb 9, 2015 at 11:35 AM, Daniel Stone wrote:
>> On 5 February 2015 at 11:35, One Thousand Gnomes
>> wrote:
>>> #if defined (CONFIG_SUPPORT_SHITE_VGA_ADAPTERS)
>>>
>>> #endif
>>>
>>> around that and its sorted as an option everyone
On Tue, Feb 3, 2015 at 4:54 PM, One Thousand Gnomes
wrote:
> On Thu, 29 Jan 2015 15:40:33 -0800
> Linus Torvalds wrote:
>
>> On Wed, Jan 28, 2015 at 8:11 PM, Dave Airlie wrote:
>> >
>> > Linus, this came up a while back I finally got some confirmation
>> > that it fixes those servers.
>>
>> I'm
> If I'm not mistaken, that would be as simple as adding
>
> #define VT_BUF_HAVE_RW.
> #define scr_writew(val, addr) (*(addr) = (val))
> #define scr_readw(addr) (*(addr))
>
> to arch/x86/include/asm/vga.h.
and stick an
#if defined (CONFIG_SUPPORT_SHITE_VGA_ADAPTERS)
#endif
around
On Thu, 29 Jan 2015 15:40:33 -0800
Linus Torvalds wrote:
> On Wed, Jan 28, 2015 at 8:11 PM, Dave Airlie wrote:
> >
> > Linus, this came up a while back I finally got some confirmation
> > that it fixes those servers.
>
> I'm certainly ok with this. which way should it go in? The users are:
>
>
On 1 February 2015 at 01:03, CodeSwim OS Development
wrote:
> I'm trying to build libdrm and have an issue when I gmake after
> configuring. Steps to reproduce:
>
> # uname -a
> SunOS omnios 5.11 omnios-10b9c79 i86pc i386 i86pc
>
Where can one get a copy of OmniOS ? Free of charge of course :-P
B
On Thu, Jan 29, 2015 at 03:40:33PM -0800, Linus Torvalds wrote:
> On Wed, Jan 28, 2015 at 8:11 PM, Dave Airlie wrote:
> >
> > Linus, this came up a while back I finally got some confirmation
> > that it fixes those servers.
>
> I'm certainly ok with this. which way should it go in? The users are:
On 01/28/2015 11:11 PM, Dave Airlie wrote:
> These two copy to/from VGA memory, however on the Silicon
> Motion SMI750 VGA card on a 64-bit system cause console corruption.
>
> This is due to the hw being buggy and not handling a 64-bit transaction
> correctly.
>
> We could try and create a 32-bi
On 30 January 2015 at 10:03, Linus Torvalds
wrote:
> On Thu, Jan 29, 2015 at 3:57 PM, Greg Kroah-Hartman
> wrote:
>>
>> I can take this through the tty tree, but can I put it in linux-next and
>> wait for the 3.20 merge window to give people who might notice a
>> slow-down a chance to object?
>
>
On Thu, Jan 29, 2015 at 3:57 PM, Greg Kroah-Hartman
wrote:
>
> I can take this through the tty tree, but can I put it in linux-next and
> wait for the 3.20 merge window to give people who might notice a
> slow-down a chance to object?
Yes. The problem only affects one (or a couple of) truly outra
On Wed, Jan 28, 2015 at 8:11 PM, Dave Airlie wrote:
>
> Linus, this came up a while back I finally got some confirmation
> that it fixes those servers.
I'm certainly ok with this. which way should it go in? The users are:
- drivers/tty/vt/vt.c (Greg KH, "tty layer")
- drivers/video/console/*
On Mon, Nov 04, 2013 at 05:57:39AM -0800, Thomas Hellstrom wrote:
> The code handles three different cases:
> 1) physical page addresses. The ttm page array is used.
> 2) DMA subsystem addresses. A scatter-gather list is used.
> 3) Coherent pages. The ttm dma pool is used, together with the dma_ttm
On Thu, Oct 31, 2013 at 04:13:12PM -0700, Keith Packard wrote:
> Make an easy place to splice in a DRI3 version of this function
>
> Signed-off-by: Keith Packard
> ---
> src/mesa/drivers/dri/i915/intel_context.c | 90
> +--
> src/mesa/drivers/dri/i965/brw_context.c
On Mon, Nov 04, 2013 at 05:57:37AM -0800, Thomas Hellstrom wrote:
> These patches makes the vmwgfx driver use the DMA API to obtain valid
> device addresses rather than blindly using physical addresses.
>
> The main motivation is to be able to use a virtual IOMMU in the future.
Ooooh. Neat! Are t
On Thu, Oct 31, 2013 at 04:13:11PM -0700, Keith Packard wrote:
> This just renames them so that they can be used with the DRI3 extension
> without causing too much confusion.
>
> Signed-off-by: Keith Packard
> ---
> src/mesa/drivers/dri/common/dri_util.c | 50
> +
On Mon, Nov 04, 2013 at 05:57:38AM -0800, Thomas Hellstrom wrote:
> Used by the vmwgfx driver
That looks OK to me. And baremetal should not be
affected as the Intel VT-d driver turns of the SWIOTLB
driver - so it will still use the classic ttm pool code.
Reviewed-by: Konrad Rzeszutek Wilk
>
>
On 10/31/2013 04:13 PM, Keith Packard wrote:
> Instead of assuming that the size will be height * pitch, have the caller pass
> in the size explicitly.
>
> Signed-off-by: Keith Packard
One nit below. With that changed,
Reviewed-by: Ian Romanick
> ---
> src/mesa/drivers/dri/i915/intel_region
On 11/04/2013 05:40 PM, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 04, 2013 at 05:57:39AM -0800, Thomas Hellstrom wrote:
>> The code handles three different cases:
>> 1) physical page addresses. The ttm page array is used.
>> 2) DMA subsystem addresses. A scatter-gather list is used.
>> 3) Coherent
On 11/04/2013 05:34 PM, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 04, 2013 at 05:57:38AM -0800, Thomas Hellstrom wrote:
>> Used by the vmwgfx driver
> That looks OK to me. And baremetal should not be
> affected as the Intel VT-d driver turns of the SWIOTLB
> driver - so it will still use the class
On 11/04/2013 05:30 PM, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 04, 2013 at 05:57:37AM -0800, Thomas Hellstrom wrote:
>> These patches makes the vmwgfx driver use the DMA API to obtain valid
>> device addresses rather than blindly using physical addresses.
>>
>> The main motivation is to be able
On 11/04/2013 05:27 PM, Daniel Vetter wrote:
> On Mon, Nov 04, 2013 at 05:57:39AM -0800, Thomas Hellstrom wrote:
>> The code handles three different cases:
>> 1) physical page addresses. The ttm page array is used.
>> 2) DMA subsystem addresses. A scatter-gather list is used.
>> 3) Coherent pages.
On Mon, Nov 04, 2013 at 05:57:39AM -0800, Thomas Hellstrom wrote:
> The code handles three different cases:
> 1) physical page addresses. The ttm page array is used.
> 2) DMA subsystem addresses. A scatter-gather list is used.
> 3) Coherent pages. The ttm dma pool is used, together with the dma_ttm
2013/8/1 Sérgio Basto :
> Hi, DRI devel mailing list have been move to
> dri-de...@lists.freedesktop.org you may want post your question there .
Thanks, I already did:
http://lists.freedesktop.org/archives/dri-devel/2013-July/042583.html
--
Rafał
On Qua, 2013-07-31 at 08:25 +0200, Rafał Miłecki wrote:
> HI guys,
>
> I'm looking for the cheapest DCE8 GPU. I know there are 3
> (engineering) families using DCE8: KAVERI, BONAIRE and KABINI.
>
> The only GPU I know should be DCE8 is HD7790 (not even sure which
> engineering family is that). U
On Fri, Jan 25, 2013 at 2:43 AM, Dave Airlie wrote:
> Okay so Alan's patch handled the case where there was no registered fbcon,
> however the other path entered in set_con2fb_map pit.
>
> In there we called fbcon_takeover, but we also took the console lock in a
> couple
> of places. So push the
On Thu, Jan 24, 2013 at 8:43 PM, Dave Airlie wrote:
> Okay so Alan's patch handled the case where there was no registered fbcon,
> however the other path entered in set_con2fb_map pit.
>
> In there we called fbcon_takeover, but we also took the console lock in a
> couple
> of places. So push the
>
> (please Cc)
>
> I am running 3.7-rc2 and got recently hit a few times (under rc1, too)
> by hanging drm i915 while doing large io operations.
Does booting with i915.i915_enable_rc6=0 help?
(Daniel, looks like an ironlake).
Dave.
--
On Mon, Sep 10, 2012 at 1:27 AM, Michel Dänzer wrote:
> On Son, 2012-09-09 at 15:33 -0700, Jordan Justen wrote:
>> New branch 'debian-experimental' available with the following commits:
>
> I think you pushed this to the wrong repository?
My apologies. I had the hook script mis-configured under m
On Son, 2012-09-09 at 15:33 -0700, Jordan Justen wrote:
> New branch 'debian-experimental' available with the following commits:
I think you pushed this to the wrong repository?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast |
On Tue, Aug 21, 2012 at 7:15 PM, Alan Cox wrote:
>> So after much tracing with direct netconsole writes (printks
>> under console_lock not so useful), I think I found the race.
>
> Direct netconsole write would be a useful patch to have mainline I think
> 8)
Well I used a one line wrapper around
On Tue, Aug 21, 2012 at 2:40 AM, Dave Airlie wrote:
> So we've had a fair few reports of fbcon handover breakage between
> efi/vesafb and i915 surface recently, so I dedicated a couple of
> days to finding the problem.
>
> Essentially the last thing we saw was the conflicting framebuffer
> message
On Tue, 2012-08-21 at 10:15 +0100, Alan Cox wrote:
> > So after much tracing with direct netconsole writes (printks
> > under console_lock not so useful), I think I found the race.
>
> Direct netconsole write would be a useful patch to have mainline I think
> 8)
could we make that use the earlyp
On Tue, 2012-08-21 at 16:40 +1000, Dave Airlie wrote:
> So after much tracing with direct netconsole writes (printks
> under console_lock not so useful)
I always use earlyprintk on serial..
--
Live Security Virtual Conf
> So after much tracing with direct netconsole writes (printks
> under console_lock not so useful), I think I found the race.
Direct netconsole write would be a useful patch to have mainline I think
8)
> Hopefully this fixes the problem for anyone seeing vesafb->kms
> driver handoff.
Not really
On Thu, Apr 5, 2012 at 4:21 PM, Ville Syrjälä wrote:
> On Tue, Apr 03, 2012 at 02:50:01PM -0700, Rob Clark wrote:
>> + /* just testing a limited # of formats to test single
>> + * and multi-planar path.. would be nice to add more..
>> + */
>> + if
On Tue, Apr 03, 2012 at 02:50:01PM -0700, Rob Clark wrote:
> + /* just testing a limited # of formats to test single
> + * and multi-planar path.. would be nice to add more..
> + */
> + if (!strcmp(p->format_str, "YUYV")) {
> + p
On Tue, Feb 28, 2012 at 01:03:27PM +0900, Norbert Preining wrote:
> Dear all,
>
> (please Cc)
>
> since upgrade to 3.3-rc5 I see the following behaviour repeatedly:
>
> Feb 28 11:42:47 mithrandir kernel: [15627.756071]
> [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung
>
On Tue, Feb 28, 2012 at 4:03 AM, Norbert Preining wrote:
> Dear all,
>
> (please Cc)
And you haven't changed userspace in any way?
Dave.
--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive onl
Dear Norbert,
Am Dienstag, den 28.02.2012, 13:03 +0900 schrieb Norbert Preining:
> Dear all,
>
> (please Cc)
>
> since upgrade to 3.3-rc5 I see the following behaviour repeatedly:
>
> Feb 28 11:42:47 mithrandir kernel: [15627.756071]
> [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elap
On Mon, 05 Dec 2011 14:23:55 -0800, Eric Anholt wrote:
> On Mon, 5 Dec 2011 02:31:58 -0800 (PST), ic...@kemper.freedesktop.org (Chris
> Wilson) wrote:
> > configure.ac |2 +-
> > intel/intel_bufmgr_gem.c | 27 +--
> > 2 files changed, 22 insertions(+),
On Mon, 5 Dec 2011 02:31:58 -0800 (PST), ic...@kemper.freedesktop.org (Chris
Wilson) wrote:
> configure.ac |2 +-
> intel/intel_bufmgr_gem.c | 27 +--
> 2 files changed, 22 insertions(+), 7 deletions(-)
>
> New commits:
> commit e73161a02b604742e3da3bca
On 11/28/2011 08:20 PM, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 2028:
>
> The drm tree lost its build failure but gained another for which I
> applied a patch.
ERROR: "drm_helper_get_fb_bpp_depth" [drivers/gpu/drm/vmwgfx/vmwgfx.ko]
undefined!
Full x86_64 randconfig file is att
Hi,
today I upgraded from Radeon X700 to HD6570.
It works very well on my Fedora 15/x86_64.
Thank you very much to everyone working on
the new Radeon driver generations.
Best regards,
Zoltán Böszörményi
2010-02-06 19:55 keltezéssel, Corbin Simpson írta:
>
> Not yet. Work is in progress.
>
> Post
On Mon, 20 Jun 2011, Mandeep Singh Baines wrote:
> Hi Dave,
>
> I think this change is causing a regression I'm seeing in panic.
> Before this change, I'd get a
> reboot on panic (we've configured as such).
>
> With this change, my machine gets wedged if the machine is running in
> X when the pa
On Mon, Jun 20, 2011 at 4:03 PM, David Rientjes wrote:
> On Mon, 20 Jun 2011, Mandeep Singh Baines wrote:
>
>> Hi Dave,
>>
>> I think this change is causing a regression I'm seeing in panic.
>> Before this change, I'd get a
>> reboot on panic (we've configured as such).
>>
>> With this change, my
On Mit, 2011-06-15 at 16:58 +0200, Michel Dänzer wrote:
> On Die, 2011-06-07 at 21:42 +0800, Donnie Fang wrote:
> > 3D render image on WC AGP aperture BO and then CPU fetch the image
> > from this bo, in order to achieve performance, after 3D finished
> > rendering, validate this bo into cached sy
On Die, 2011-06-07 at 21:42 +0800, Donnie Fang wrote:
> 3D render image on WC AGP aperture BO and then CPU fetch the image
> from this bo, in order to achieve performance, after 3D finished
> rendering, validate this bo into cached system memory and then read it
> from system memory. But I always g
On 04/14/2011 12:42 PM, Jesse Barnes wrote:
> We've already seen that apps want to monitor the display config, and
> some (like upowerd) poll for changes since we don't provide a
> notification for general mode config changes, just hotplug events. So
> add a new drm event, with CHANGE=1 set in the
On 4/14/11 1:42 PM, Jesse Barnes wrote:
> We've already seen that apps want to monitor the display config, and
> some (like upowerd) poll for changes since we don't provide a
> notification for general mode config changes, just hotplug events. So
> add a new drm event, with CHANGE=1 set in the eve
On Fri, 15 Apr 2011 09:23:38 -0500
Chris Bandy wrote:
> On 04/14/2011 12:42 PM, Jesse Barnes wrote:
> > /**
> > + * drm_sysfs_change_event - generate a DRM uevent indicating a display
> > config change
> > + * @dev: DRM device
> > + *
> > + * Send a uevent for the DRM device specified by @dev.
On Fri, 1 Apr 2011 14:15:11 +0900
Norbert Preining wrote:
> Hi all,
>
> adding dri-devel as I found it is actually not completely dead,
> but hanging in some i915 problem.
>
> Copyied from screen:
> Process ips-adjust (
> Stack:
>
>
> ...
> Call Trace:
>
> ... ? tick_
https://bugzilla.kernel.org/show_bug.cgi?id=28332
Rafael J. Wysocki changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--
Configure bugmail: htt
https://bugzilla.kernel.org/show_bug.cgi?id=28332
Rafael J. Wysocki changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugzilla.kernel.org/show_bug.cgi?id=28332
--- Comment #13 from Rafał Miłecki 2011-03-07 18:45:12 ---
I've tried 2.6.37.2, it's free of this bug as well.
I had to be some quickly fixed regression I met in wireless-testing.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs
https://bugzilla.kernel.org/show_bug.cgi?id=28332
--- Comment #12 from Rafał Miłecki 2011-02-16 23:07:40 ---
This does not happen in 2.6.38-rc4. I am not sure about final version of 2.6.37
yet.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiv
https://bugzilla.kernel.org/show_bug.cgi?id=28332
Rafael J. Wysocki changed:
What|Removed |Added
CC||flor...@mickler.org,
https://bugzilla.kernel.org/show_bug.cgi?id=28332
Andrew Morton changed:
What|Removed |Added
CC||a...@linux-foundation.org
Compo
> I finally did the bisect and got this as a result after a lot of rebooting:
>
> "
> 139315796778a6d5f67c644e2ff470ddc69efb7b is the first bad commit
> commit 139315796778a6d5f67c644e2ff470ddc69efb7b
> Author: Adam Jackson
> Date: Tue Aug 3 14:38:19 2010 -0400
<...>
> Maybe this should be ch
On Thu, Jan 27, 2011 at 10:28:45AM +0100, Thomas Hellstrom wrote:
> Konrad, Dave
>
> Given our previous discussion on the list, I believe these patches
> shouldn't introduce any regressions in the non-Xen case, however we
> should probably be prepared to back them out quickly if that turns
> out t
Konrad, Dave
Given our previous discussion on the list, I believe these patches
shouldn't introduce any regressions in the non-Xen case, however we
should probably be prepared to back them out quickly if that turns out
to be the case...
Thanks,
Thomas
On 01/07/2011 06:11 PM, Konrad Rzeszute
On Sun, 2011-01-16 at 15:48 -0800, Linus Torvalds wrote:
> On Sun, Jan 16, 2011 at 3:44 PM, Ben Skeggs wrote:
> >
> > I've tested a bit here, current git with the revert does appear to work
> > fine for me.
>
> So Anca has a 8800GT - is that what you're testing?
I don't have an 8800 in the office
On Sun, Jan 16, 2011 at 3:44 PM, Ben Skeggs wrote:
>
> I've tested a bit here, current git with the revert does appear to work
> fine for me.
So Anca has a 8800GT - is that what you're testing?
Also, there may be things like FB config issues and/or kernel command
line arguments. For example, on
On Sun, 2011-01-16 at 12:10 -0800, Linus Torvalds wrote:
> On Sun, Jan 16, 2011 at 12:00 PM, Anca Emanuel wrote:
> >
> > In 2.6.37-git5 with the revert, the boot screen is changing the resolution.
> > With this version, it don't.
>
> So, can you make a nice report of that - along with 'dmesg' for
On Sun, Jan 16, 2011 at 12:00 PM, Anca Emanuel wrote:
>
> In 2.6.37-git5 with the revert, the boot screen is changing the resolution.
> With this version, it don't.
So, can you make a nice report of that - along with 'dmesg' for _both_
cases - to the right people?
In this case, that would be at
On Thu, 06 Jan 2011 12:11:38 +0100, "David Müller (ELSOFT AG)"
wrote:
> The patch below adds an additional check to make sure that there is
> really an analog device attached (similar to the "Mac mini hack" in
> intel_sdvo.c)
Nice patch, thanks. I've applied this to my -fixes queue.
-Chris
--
On Tue, Dec 21, 2010 at 08:29:03AM +0100, Michel D?nzer wrote:
> On Die, 2010-12-21 at 11:41 +1000, Dave Airlie wrote:
> > From: Dave Airlie
> >
> > On my system with a radeon x2, the first GPU was not overlapping vesa
> > but the test decided it was.
> >
> > Signed-off-by: Dave Airlie
> > ---
On Tue, Dec 21, 2010 at 11:41:17AM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> Situation as follow:
> 2 GPUs + vesafb + kms.
>
> GPU 1 is primary, vesafb binds to it as fb0
> radeon loads
> GPU 0 loads as fb1
> GPU 1 loads, vesafb gets kicked off which causes fb0 to unbind
> console, which
On Die, 2010-12-21 at 11:41 +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> On my system with a radeon x2, the first GPU was not overlapping vesa
> but the test decided it was.
>
> Signed-off-by: Dave Airlie
> ---
> drivers/video/fbmem.c |2 +-
> 1 files changed, 1 insertions(+), 1 dele
Hi Alex,
Thanks for the fast reply.
I checked again the patches... I have chosen the ones from people.d.o.
Kind Regards,
- Sedat -
On Tue, Oct 26, 2010 at 6:16 PM, Alex Deucher wrote:
> On Tue, Oct 26, 2010 at 9:32 AM, Sedat Dilek
> wrote:
>> Hi,
>>
>> today, I started with testing "DRM Vblan
On Sun, Oct 24, 2010 at 3:28 PM, Mario Kleiner
wrote:
> Hi all,
>
> after obsessing over these for another month after xds 2010,
> this is the first version of my vblank timestamping patches that
> i'm not totally ashamed off.
>
Mario, these look great. Nice work!
Reviewed-by: Alex Deucher
>
On Tue, Oct 26, 2010 at 9:32 AM, Sedat Dilek wrote:
> Hi,
>
> today, I started with testing "DRM Vblank timestamping patches. 1st
> Try." from Mario in combination with "radeon pageflipping patches"
> from Alex together in a non-BKL config Kernel-setup.
>
> First some words to my system and hardwa
Oh btw., the patches are against the current drm-radeon-testing tree,
applied after commit...
21c74a8ea8b47eb6c3c621e36578f6e27f65c5c7
"drm, kdb, kms: Change mode_set_base_atomic() enter argument to be an enum"
... and should apply cleanly.
thanks,
-mario
--
les people
to put review comments in-line.
- Fix the comment and license at the top of the file.
- Re-wrap lines to 80 columns.
- Fix broken whitespace usage
}else{
should be
} else {
and
if(foo){
should be
if (foo) {
etc.
- piglit_report_result already calls exit, so the c
FWIW, the ddx has the pci id correctly associated with rv410, so it
looks like it was just improperly ported to the drm.
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify applic
Hi Andy,
On Fr, 10 Sep 2010, Andy Isaacson wrote:
> > I never said that it has anything to do with suspend to ram.
>
> Ah, sorry for misunderstanding. My GM45 system is configured to
> automatically S2R on lid close so I tend to conflate the two...
Mine, too, but not when running on AC.
> Do t
On Fr, 10 Sep 2010, Andy Isaacson wrote:
> FWIW, 2.6.36-rc3-00396-gbe6200a suspend-to-ram works for me on GM45
I never said that it has anything to do with suspend to ram.
In fact, suspend to ram works perfectly without any problems. I only
reboot after I installed a new kernel ...
I will try so
On 09/10/2010 05:34 PM, Andy Isaacson wrote:
> On Sat, Sep 11, 2010 at 08:44:48AM +0900, Norbert Preining wrote:
>> On Fr, 10 Sep 2010, Andy Isaacson wrote:
>>> FWIW, 2.6.36-rc3-00396-gbe6200a suspend-to-ram works for me on GM45
>>
>> I never said that it has anything to do with suspend to ram.
>
>
On Sat, Sep 11, 2010 at 08:44:48AM +0900, Norbert Preining wrote:
> On Fr, 10 Sep 2010, Andy Isaacson wrote:
> > FWIW, 2.6.36-rc3-00396-gbe6200a suspend-to-ram works for me on GM45
>
> I never said that it has anything to do with suspend to ram.
Ah, sorry for misunderstanding. My GM45 system is
On Fri, Sep 10, 2010 at 07:41:17AM +0900, Norbert Preining wrote:
> running: 2.6.36-rc3+ (from git) on Integrated Graphics Chipset: Intel(R) GM45
> (Sony Vaio Z11)
> Debian/unstable, so xserver 1.7.7, intel driver: 2.12.0
>
> since some recent kernel I have the following problem: When closing the
Dne 1.9.2010 02:53, Eric Anholt napsal(a):
> On Tue, 31 Aug 2010 12:17:43 +0200, Zdenek Kabelac
> wrote:
>> Dne 28.8.2010 05:55, Eric Anholt napsal(a):
>>> On Fri, 27 Aug 2010 13:16:04 +0200, Zdenek Kabelac
>>> wrote:
On 27.8.2010 12:02, Julien Cristau wrote:
> On Fri, Aug 27, 2010 at
On 09/09/2010 03:41 PM, Norbert Preining wrote:
> Hi all,
>
> running: 2.6.36-rc3+ (from git) on Integrated Graphics Chipset: Intel(R) GM45
> (Sony Vaio Z11)
> Debian/unstable, so xserver 1.7.7, intel driver: 2.12.0
>
> since some recent kernel I have the following problem: When closing the
> lid o
On Tue, 31 Aug 2010 12:17:43 +0200, Zdenek Kabelac wrote:
> Dne 28.8.2010 05:55, Eric Anholt napsal(a):
> > On Fri, 27 Aug 2010 13:16:04 +0200, Zdenek Kabelac
> > wrote:
> >> On 27.8.2010 12:02, Julien Cristau wrote:
> >>> On Fri, Aug 27, 2010 at 11:26:59 +0200, Zdenek Kabelac wrote:
> >>>
> >>>
Dne 28.8.2010 05:55, Eric Anholt napsal(a):
> On Fri, 27 Aug 2010 13:16:04 +0200, Zdenek Kabelac
> wrote:
>> On 27.8.2010 12:02, Julien Cristau wrote:
>>> On Fri, Aug 27, 2010 at 11:26:59 +0200, Zdenek Kabelac wrote:
>>>
Why keeping different name for C++ and C ?
>>> Because changing th
On Fri, 27 Aug 2010 13:16:04 +0200, Zdenek Kabelac wrote:
> On 27.8.2010 12:02, Julien Cristau wrote:
> > On Fri, Aug 27, 2010 at 11:26:59 +0200, Zdenek Kabelac wrote:
> >
> >> Why keeping different name for C++ and C ?
> >>
> > Because changing the name for C means breaking API for existing users
On 27.8.2010 12:02, Julien Cristau wrote:
> On Fri, Aug 27, 2010 at 11:26:59 +0200, Zdenek Kabelac wrote:
>
>> Why keeping different name for C++ and C ?
>>
> Because changing the name for C means breaking API for existing users,
> which is not a nice thing to do.
>
Well if DRM would have very st
On Fri, Aug 27, 2010 at 11:26:59 +0200, Zdenek Kabelac wrote:
> Why keeping different name for C++ and C ?
>
Because changing the name for C means breaking API for existing users,
which is not a nice thing to do.
Cheers,
Julien
---
Dne 27.8.2010 00:50, Eric Anholt napsal(a):
> include/drm/drm.h|4
> intel/intel_bufmgr.h |6 +-
> 2 files changed, 9 insertions(+), 1 deletion(-)
>
> New commits:
> commit 23287f05cf2443ddf9e028e29beb5bd30979c6cf
> Author: Eric Anholt
> Date: Thu Aug 26 15:39:28 2010 -070
On Fri, Aug 6, 2010 at 05:55, Benjamin Herrenschmidt
wrote:
> (For some reason I thought that went in ages ago ...)
>
> This fixes support for PCI domains in what should hopefully be a backward
> compatible way along with a change to libdrm.
>
> When the interface version is set to 1.4, we assume
> > Hm, so pci_domain_nr should just return 0 on platforms where
> > CONFIG_PCI_DOMAINS isn't set. I'd expect that to be the case when
> > CONFIG_PCI=n... Maybe we just need to shuffle the definition
> > around?
>
> I suspect something like the attached would suffice.
>
> Or maybe moving the CO
On Fri, Aug 13, 2010 at 9:45 AM, Jesse Barnes wrote:
> On Fri, 13 Aug 2010 09:33:35 +1000
> Dave Airlie wrote:
>
>> On Fri, Aug 13, 2010 at 7:30 AM, Geert Uytterhoeven
>> wrote:
>> > On Fri, Aug 6, 2010 at 05:55, Benjamin Herrenschmidt
>> > wrote:
>> >> (For some reason I thought that went in a
On Fri, 13 Aug 2010 09:33:35 +1000
Dave Airlie wrote:
> On Fri, Aug 13, 2010 at 7:30 AM, Geert Uytterhoeven
> wrote:
> > On Fri, Aug 6, 2010 at 05:55, Benjamin Herrenschmidt
> > wrote:
> >> (For some reason I thought that went in ages ago ...)
> >>
> >> This fixes support for PCI domains in wha
On Fri, Aug 13, 2010 at 7:30 AM, Geert Uytterhoeven
wrote:
> On Fri, Aug 6, 2010 at 05:55, Benjamin Herrenschmidt
> wrote:
>> (For some reason I thought that went in ages ago ...)
>>
>> This fixes support for PCI domains in what should hopefully be a backward
>> compatible way along with a change
On Wednesday 11 August 2010, Dave Airlie wrote:
> On Wed, Aug 11, 2010 at 6:48 PM, Luca Tettamanti wrote:
> >
> >
> > moved the call to (inside drm_release) drm_lastclose inside dev->count_lock
> > spinlock.
> > drm_lastclose however takes dev->struct_mutex (now inside an atomic
> > context):
Yes
On Wed, Aug 11, 2010 at 6:48 PM, Luca Tettamanti wrote:
> Hi Arnd,
> this commit:
>
> commit 58374713c9dfb4d231f8c56cac089f6fbdedc2ec
> Author: Arnd Bergmann
> Date: Sat Jul 10 23:51:39 2010 +0200
>
> drm: kill BKL from common code
>
>
> moved the call to (inside drm_release) drm_lastclose i
1 - 100 of 26540 matches
Mail list logo
