ding SDMA/RLCG under SRIOV VF
drm/amdgpu/vce4: fix a PSP loading VCE issue
Dave Airlie (3):
Merge tag 'drm-misc-next-fixes-2017-05-05' of
git://anongit.freedesktop.org/git/drm-misc into drm-next
Merge branch 'drm-next-4.12' of
git://people.freedesktop.org/~agd5
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?
>
>
e the optimisation is worth much today.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1132826
Tested-by: Huawei engineering.
Signed-off-by: Dave Airlie
---
Linus, this came up a while back I finally got some confirmation
that it fixes those servers.
include/linux/vt_buffer.h | 4
1 file ch
From: Dave Airlie
When we switch from 256->512 byte font rendering mode, it means the
current contents of the screen is being reinterpreted. The bit that holds
the high bit of the 9-bit font, may have been previously set, and thus
the new font misrenders.
The problem case we see is grub2 wri
means fbmem and switcheroo needed to take the lock around the fb notifier
entry points that lead to this.
This should fix the efifb regression seen by Maarten.
Signed-off-by: Dave Airlie
---
drivers/gpu/vga/vga_switcheroo.c | 3 +++
drivers/video/console/fbcon.c| 11 ---
drivers/
>
> (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 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
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 and that was all.
So after much tracing with direct netconsole
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
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 deletions(-)
diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
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 causes the dummy console to rebind.
this means fbcon_deinit gets called, which
From: Dave Airlie
With framebuffer handover and multiple GPUs, we get into a
position where the fbcon unbinds the vesafb framebuffer for GPU 1,
but we still have a radeon framebuffer bound from GPU 0, so
we don't unregister the console driver. Then when we tried to bind
the new r
I've been working on some issues with the fb handoff between vesafb and KMS
on my machine with a dual-gpu card. These 3 patches are the primary result
of this, to fix a number of issues where the VT layer and fbcon layers
got themselves into a place that they couldn't get out off, having the second
From: Dave Airlie
So in a lot of modern systems, a GPU will always be below a parent bridge that
won't share with any other GPUs. This means VGA arbitration on those GPUs can
be controlled by using the bridge routing instead of io/mem decodes.
The problem is locating which GPUs share
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:
>&g
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 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
2010/8/9 Benjamin Herrenschmidt :
> Just a quick status in case others are interested and want to help
> as I have -very- little time.
>
> I'm currently testing on a rv350 based aluminium powerbooks.
> The basic stuff works provided you stay away from AGP. Here's
> things in no special order I noti
V5000 laptop resume
Dave Airlie (1):
drm/radeon/kms: drop taking lock around crtc lookup.
Tony Luck (1):
Fix ttm_page_alloc.c build breakage
drivers/gpu/drm/radeon/evergreen_cs.c |2 --
drivers/gpu/drm/radeon/r100.c |2 --
drivers/gpu/drm/r
On Wed, Jun 30, 2010 at 5:31 PM, Markus Trippelsdorf
wrote:
> On Wed, Jun 30, 2010 at 08:54:40AM +0200, Markus Trippelsdorf wrote:
>> On Wed, Jun 30, 2010 at 02:03:04AM +0100, Dave Airlie wrote:
>> >
>> > one fb layer fix in a flag I introduced,
>> >
>> &
On Wed, Jun 30, 2010 at 5:57 PM, Dave Airlie wrote:
> On Wed, Jun 30, 2010 at 4:54 PM, Markus Trippelsdorf
> wrote:
>> On Wed, Jun 30, 2010 at 02:03:04AM +0100, Dave Airlie wrote:
>>>
>>> Hi Linus,
>>>
>>> one fb layer fix in a flag I introduced,
On Wed, Jun 30, 2010 at 4:54 PM, Markus Trippelsdorf
wrote:
> On Wed, Jun 30, 2010 at 02:03:04AM +0100, Dave Airlie wrote:
>>
>> Hi Linus,
>>
>> one fb layer fix in a flag I introduced,
>>
>> the rest are drm fixes:
>> radeon fixes: the larger ones
Cedric Godin (1):
drm/radeon/kms: fix dpms state on resume
Dave Airlie (7):
drm/radeon: fix dual-head on rv250
radeon/kms: fix powerpc/rn50 untiled behaviour.
agp: drop vmalloc flag.
agp: add no warn since we have a fallback to vmalloc paths
drm/radeon: add
enables this for KMS drivers.
Signed-off-by: Dave Airlie
---
drivers/char/vt.c | 13 +
drivers/gpu/drm/i915/intel_fb.c |4 +---
drivers/gpu/drm/nouveau/nouveau_fbcon.c |1 +
drivers/gpu/drm/radeon/radeon_fb.c |2 +-
drivers/v
From: Dave Airlie
When I added the flags I must have been using a 25 line terminal and missed the
following flags.
The collided with flag has one user in staging despite being in-tree for 5
years.
I'm happy to push this via my drm tree unless someone really wants to do it.
Signed-o
From: root
This needs more work, esp testing on later servers like js22.
on the js21 I tested on I can't find any answer on any DDC lines.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/radeon/radeon_combios.c | 32 +++
drivers/gpu/drm/radeon/radeon_m
From: Dave Airlie
Installing 2.6.34 on a Power5/rn50 combo machine, X showed buggy sw rendering,
enabling tiling in the DDX fixed it. Investigation showed that a further /16
was needed in the untiled case on this chipset. Need further investigations
on what other chips this could affect
From: Dave Airlie
Plugged in FireMV with the rv250 on it, and the second crtc/dac didn't work,
we were reading/writing different registers than we were modifying in the code.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/radeon/radeon_legacy_encoders.c | 22 +-
1
On Mon, 2010-06-07 at 23:37 +0200, Rafael J. Wysocki wrote:
> On Monday 07 June 2010, Alex Deucher wrote:
> > On Mon, Jun 7, 2010 at 6:15 AM, Dave Airlie wrote:
> > > On Mon, Jun 7, 2010 at 7:29 PM, Rafael J. Wysocki wrote:
> > >> Hi A
On Mon, Jun 7, 2010 at 7:29 PM, Rafael J. Wysocki wrote:
> Hi Alex,
>
> Your commit 9349d5cc920c10845693f906ebd67f394f1d0d04
> (drm/radeon/kms/pm: enable SetVoltage on r7xx/evergreen) has caused my
> test-bed
> Acer Ferrari One to behave quite unreliably. The symptoms are:
>
> - the system hangs
From: Dave Airlie
Some of the laptops with the switchable graphics, seem to not post the
secondary GPU at all, and we can't find a copy of the BIOS anywhere except in
the ACPI rom retrieval.
This adds support for ACPI ROM retrieval to nouveau.
Signed-off-by: Dave Airlie
---
drivers/gp
Just one patch from Jean to fix some regressions in the buffer code
rework. Thanks to Jean for tracking this down.
The following changes since commit 8cfe92d683a0041ac8e016a0b0a487c99a78f6c1:
Thomas Hellstrom (1):
drm/ttm: Remove the ttm_bo_block_reservation() function.
are available
From: Dave Airlie
After thinking it over a lot it made more sense for the core to deal with
the output polling especially so it can notify X.
v2: drop plans for fake connector - per Michel's comments - fix X patch sent to
xorg-devel, add intel polled/hpd setting, add initial nouveau polle
From: Dave Airlie
Simple cloning rules compared to server:
(a) single crtc
(b) > 1 connector active
(c) check command line mode
(d) try and find 1024x768 DMT mode if no command line.
(e) fail to clone
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_edid.c | 17 ---
drivers/
From: Dave Airlie
After thinking it over a lot it made more sense for the core to deal with
the output polling especially so it can notify X.
v2: drop plans for fake connector - per Michel's comments - fix X patch sent to
xorg-devel, add intel polled/hpd setting, add initial nouveau polle
From: Dave Airlie
After thinking it over a lot it made more sense for the core to deal with
the output polling especially so it can notify X.
v2: drop plans for fake connector - per Michel's comments - fix X patch sent to
xorg-devel, add intel polled/hpd setting, add initial nouveau polle
2010/5/5 Michel Dänzer :
> On Mit, 2010-05-05 at 11:12 +1000, Dave Airlie wrote:
>>
>> So at startup X drivers genearlly seem to ask for a list of connectors
>> and status for them, and if it can't find any connected, it goes to
>> unknown, and if none of those th
On Wed, May 5, 2010 at 11:37 AM, Jesse Barnes wrote:
> On Wed, 5 May 2010 11:12:13 +1000
> Dave Airlie wrote:
>> So at startup X drivers genearlly seem to ask for a list of
>> connectors and status for them, and if it can't find any connected,
>> it goes to unkno
From: Dave Airlie
After thinking it over a lot it made more sense for the core to deal with
the output polling especially so it can notify X.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/Kconfig|2 +-
drivers/gpu/drm/drm_crtc_helper.c | 90
From: Dave Airlie
The problem with using a real connector with a fake status is we have no way to
tell userspace it got disconnected if something gets plugged into it, i.e. you
use DVI-0 as the connector with an unknown or connected status, and it puts a
1024x768 mode on it. However when a
So one of the problems I want to solve for KMS it the what to do when nothing
is plugged in at startup, I've fixed this for fbcon in the current tree, but
when looking at X + randr clients I realised it needed a bit more work.
I've pulled the polling code back into the core, and it nows can se
From: Dave Airlie
The DAC Load detection table is meant to take a parameter selecting the DAC
to do load detection on. However on certain BIOS revisions it accept no
parameters and load detects both DACs, with the result that load detecting on
the second DAC causes flicker on the first, which
From: Dave Airlie
The DAC Load detection table is meant to take a parameter selecting the DAC
to do load detection on. However on certain BIOS revisions it accept no
parameters and load detects both DACs, with the result that load detecting on
the second DAC causes flicker on the first, which
From: Dave Airlie
On constrained r100 systems compiz would fail to start due to a lack
of memory, we can just fallback place the objects rather than completely
failing it works a lot better.
v2:
fixes issue identified by Michel when pinning could happen in a busy placement
domain.
Signed-off
From: Dave Airlie
With evergreen this is bounded by num_crtc not by 0,1.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/radeon/radeon_kms.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
b/drivers/gpu/drm/radeon/radeon_kms.c
On Mon, 2010-04-19 at 11:30 +0200, Sedat Dilek wrote:
> Hi,
>
> today I pulled drm-linus GIT branch into Linus-tree (2.6.34-rc4-git6).
>
> Again, I was seeing a version-bump of the radeon-kms wrapper/driver,
> but not in the driver-date:
>
> [dmesg]
> ...
> [ 71.347298] [drm] Initialized radeo
On Tue, Apr 13, 2010 at 5:19 AM, Daniel Vetter wrote:
> On Mon, Apr 12, 2010 at 10:51:20AM -0700, Eric Anholt wrote:
>> On Fri, 9 Apr 2010 21:05:03 +0200, Daniel Vetter
>> wrote:
>> > Daniel Vetter (6):
>> > drm: extract drm_gem_object_init
>> > drm: free core gem object from driver callbac
From: Dave Airlie
On X startup we were getting a flicker where there shouldn't have been one.
the X DDX calls the kernel to set the properties to the same values (yes
it could be smarter), however the kernel was doing a pointless modeset then,
making my nice smooth boot ugly.
Signed-o
Nothing major, Mostly nouveau changes, some radeon tv output fixes, and a
couple of quirks.
The following changes since commit d668046c13024d74af7d04a124ba55f406380fe7:
Dave Airlie (1):
drm/radeon/kms: enable ACPI powermanagement mode on radeon gpus.
are available in the git
On Wed, Apr 7, 2010 at 8:21 PM, Jerome Glisse wrote:
> On fault the driver is given the opportunity to perform any operation
> it sees fit in order to place the buffer into a CPU visible area of
> memory. This patch doesn't break TTM users, nouveau, vmwgfx and radeon
> should keep working properly
On Sat, Apr 3, 2010 at 11:09 PM, Matthew W. S. Bell
wrote:
> On Sat, 2010-04-03 at 08:49 +0100, Dave Airlie wrote:
>> No, its "designed" as is. We can't change it now as its ABI. We make sure
>> we only use 32-bit handles anyways.
The thing is "unsigned int&qu
>
> drm_handle_t appears to be assigned values from void*. As such unsigned
> int is certainly not the same size on 64-bit. Convert to uintptr_t in
> all cases as it is defined for this purpose.
No, its "designed" as is. We can't change it now as its ABI. We make sure
we only use 32-bit handles
2010/4/1 Rafał Miłecki :
> W dniu 30 marca 2010 09:07 użytkownik Dave Airlie napisał:
>> 2010/3/30 Dave Airlie :
>>>
>>> [re-pull request]
>>
>> Actually Linus, don't bother, consider this revoked, I'm going to kill
>> the GPU reset code
ructs to radeon_asic.c
drm/radeon: unconfuse return value of radeon_asic->clear_surface_reg
drm/radeon: include radeon_asic.h in the asic specific files
drm/radeon: collect r100 asic related declarations in radeon_asic.h
Dave Airlie (8):
drm/ttm: use drm calloc large and
From: Dave Airlie
These GPUs should be setting these registers up also.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/radeon/rs400.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/rs400.c b/drivers/gpu/drm/radeon/rs400.c
index d7f554f
From: Dave Airlie
If we resume in a bad way, we'll get 0x in wptr, and then
oops with no console. This just adds a sanity check so that we can
avoid the oops and hopefully get more details out of people's systems.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/radeon/r10
From: Dave Airlie
Some GPUs have an APM/ACPI PM mode selection switch and some BIOSes
set this to APM. We really want this in ACPI mode for Linux.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/radeon/r100.c |7 +++
drivers/gpu/drm/radeon/radeon_reg.h |1 +
2 files changed
2010/3/30 Dave Airlie :
>
> [re-pull request]
Actually Linus, don't bother, consider this revoked, I'm going to kill
the GPU reset code
and re-send this tomorrow, its just a mess to get it back out of the
tree at this point,
but I realised I was falling back to the old ways, o
2010/3/30 Michel Dänzer :
> On Tue, 2010-03-30 at 05:34 +0100, Dave Airlie wrote:
>>
>> Original pull req below + reverts the fallback placement change which had
>> a side effect of causing more lockups on some AGP systems (this is a bug in
>> the AGP drivers th
From: Dave Airlie
a) slow work is always used now for any fbcon hotplug, as its not
a fast task and is more suited to being ran under slow work.
b) attempt to not do any fbdev changes when X is running as we'll
just mess it up. This hooks set_par to hopefully do the changes
o
From: Dave Airlie
When we are running in a headless environment we have no idea what
output the user might plug in later, we only have hotplug detect
from the digital outputs. So if we detect no connected outputs at
initialisation, start a slow work operation to poll every 5 seconds
for an
From: Dave Airlie
If we get no outputs setup provide a 1024x768 fbcon, with
this + radeon hotplug stuff I can plug a monitor in after startup
and get to see stuff.
Last thing is to add some sort of timer for non-hpd outputs like
VGA etc.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm
From: Dave Airlie
This move to using the list of crtcs in the fb helper and cleans up the
whole picking code, now we store the crtc/connectors we want directly
into the modeset and we use the modeset directly to set the mode.
Fixes from James Simmons and Ben Skeggs.
Signed-off-by: Dave Airlie
From: Dave Airlie
This breaks the connection between the core drm connector list
and the fbdev connector usage, and allows them to become disjoint
in the future. It also removes the untype void* that was in the
connector struct to support this.
All connectors are added to the fbdev now but this
This series of 6 patches attempts to clean up the KMS fbdev helper layer,
and add support for two features I'd like to see for some use cases.
The first 3 patches are mainly cleanup and moving code around, the main
idea being to better abstract the fbdev helper layer from the main kms
core. This i
drm/radeon: unconfuse return value of radeon_asic->clear_surface_reg
drm/radeon: include radeon_asic.h in the asic specific files
drm/radeon: collect r100 asic related declarations in radeon_asic.h
Dave Airlie (8):
drm/ttm: use drm calloc large and free large
Merge
2010/3/29 Dave Airlie :
> 2010/3/29 Kristian Høgsberg :
>> On Fri, Mar 26, 2010 at 7:07 PM, Jesse Barnes
>> wrote:
>>> Drivers may use vblank calls now (e.g. drm_vblank_off) in their unload
>>> paths, so don't clean up the vblank related structures until af
2010/3/29 Kristian Høgsberg :
> On Fri, Mar 26, 2010 at 7:07 PM, Jesse Barnes
> wrote:
>> Drivers may use vblank calls now (e.g. drm_vblank_off) in their unload
>> paths, so don't clean up the vblank related structures until after
>> driver unload.
>
> I haven't tested this specific patch on a re
2010/3/25 Michel Dänzer :
> On Fri, 2010-03-19 at 10:35 +1000, Dave Airlie wrote:
>> From: Dave Airlie
>>
>> On constrained r100 systems compiz would fail to start due to a lack
>> of memory, we can just fallback place the objects rather than completely
>&
On Thu, Mar 25, 2010 at 4:52 PM, Pekka Enberg wrote:
> Hi Dave,
>
> 2010/3/25 Dave Airlie :
>> Some nouveau updates + misc drm core fixes,
>>
>> radeon kms: mostly fixes, however a cleanup to the ugly asic tables to
>> avoid drift between C prototypes moves s
rn value of radeon_asic->clear_surface_reg
drm/radeon: include radeon_asic.h in the asic specific files
drm/radeon: collect r100 asic related declarations in radeon_asic.h
Dave Airlie (7):
drm/ttm: use drm calloc large and free large
Merge remote branch 'nouveau/for-airlied
On Mon, Mar 22, 2010 at 9:07 AM, Rafael J. Wysocki wrote:
> On Sunday 21 March 2010, Dave Airlie wrote:
>> 2010/3/22 Rafael J. Wysocki :
>> > Hi,
>> >
>> > Some time ago I reported a problem with resuming from suspend to RAM on
>> > HP nx6325 with rade
2010/3/22 Rafael J. Wysocki :
> Hi,
>
> Some time ago I reported a problem with resuming from suspend to RAM on
> HP nx6325 with radeon+KMS.
Can you post the X.org log file? if you are really using 6.12.4 and
not a backport
then the userspace driver has no KMS support and it is trashing the system
On Sat, Mar 20, 2010 at 4:18 AM, Sedat Dilek wrote:
> Hi Marek - "you are nominated for the next DRIgeller (Uri Geller)" :-)
>
> concerning my problems r300g dri/st with mesa master GIT:
>
> THE BAD:
> commit 68e58a96e80865878e6881dc4d34fcc3ec24eb19
> Author: Dave
On Fri, Mar 19, 2010 at 10:14 AM, Mike Lothian wrote:
> 2010/3/6 Rafał Miłecki :
>> This patchset cleans our HDMI code and adds support for DCE32.
>>
>> It was tested on:
>> 1) RV620 with HDMI - no regressions
>> 2) RV635 with 2 DVI - no regressions
>> 3) RV730 with HDMI - made it work
>>
>> Would
From: Dave Airlie
We can get this if the user moves the mouse when we are waiting to move
some stuff around in the validate. Don't fail.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/radeon/radeon_cs.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/gp
From: Dave Airlie
On constrained r100 systems compiz would fail to start due to a lack
of memory, we can just fallback place the objects rather than completely
failing it works a lot better.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/radeon/radeon.h|2 ++
drivers/gpu/drm
On Thu, Mar 11, 2010 at 1:51 PM, James Simmons wrote:
>
> Okay all the discussion about multiple display brings me to why I'm doing
> this. I'm attempting to revive the linux console project. I'm in a
> position to again work on this project. About 4 years ago the eproject
> managed to get multi-s
On Thu, Mar 18, 2010 at 6:50 AM, Pauli Nieminen wrote:
> Setting single memory pages at a time to wc takes a lot time in cache flush.
> To
> reduce number of cache flush set_pages_array_wc and set_memory_array_wc can be
> used to set multiple pages to WC with single cache flush.
I don't think th
>
> I guess technically we could also drop the AGP requirement, but since it
> worked
> on my box with AGP=n it seemed to me like a NOP.
Its not a NOP, otherwise we'd remove it, AGP || AGP=n means if
AGP is enabled DRM must be enabled similiarly, it stops AGP=m + DRM=y
basically.
>>> EXPORT_SYMB
On Fri, Mar 12, 2010 at 7:48 PM, Daniel Vetter wrote:
> On Fri, Mar 12, 2010 at 10:25:56AM +0100, Jerome Glisse wrote:
>> I would merge patch 1 & 2 into a single patch,
> I've split this up to make patch-reading easier. And it's fully
> bisectable.
I quite like where this is going compared to wha
On Tue, Mar 2, 2010 at 2:00 AM, Jordan Crouse wrote:
>
> Allow platform devices without PCI resources to be DRM devices.
>
> Signed-off-by: Jordan Crouse
This patch has a bunch of whitespace damage at least in my inbox and
also in patchwork
Please also be careful with the places you add copyrig
>
> Searching the TTM code I couldn't find the handle code so easily. I see
> that the vmwgfx driver provides a example of using ttm.
So handles are purely a userspace interface, in-kernel we don't use handles
for buffer management, the vmwgfx TTM interface has
vmw_user_surface_lookup_handle
to do
>> >
>> >> >> It would be nice to find a way to reclaim the console memory for X,
>> >> >> but I'm not sure that can be done and still provide a good way to
>> >> >> provide oops support.
>> >> >
>> >> > What do you think the average user will care about more?
>> >> >
>> >> > * Seeing kernel o
2010/3/12 Jerome Glisse :
> On Thu, Mar 11, 2010 at 05:24:22PM +0100, Rafał Miłecki wrote:
>> 2010/3/11 Alex Deucher :
>> > I like keeping all the asic definitions in one file as you tend to
>> > need to update them all at one time and having them spread across all
>> > the asic files increases the
On Thu, Mar 11, 2010 at 1:51 PM, James Simmons wrote:
>
> Okay all the discussion about multiple display brings me to why I'm doing
> this. I'm attempting to revive the linux console project. I'm in a
> position to again work on this project. About 4 years ago the eproject
> managed to get multi-s
From: Dave Airlie
Now that the drm core can do this, lets just use it, split the code out
so TTM doesn't have to drag all of drmP.h in.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/ttm/ttm_tt.c| 23 ++
include/drm/drmP.h | 34 +
in
From: Dave Airlie
This is just an idea that might or might not be a good idea,
it basically adds two ioctls to create a dumb and map a dumb buffer
suitable for scanout. The handle can be passed to the KMS ioctls to create
a framebuffer.
It looks to me like it would be useful in the following
On Fri, Mar 5, 2010 at 5:44 PM, Ingo Molnar wrote:
>
> * Pekka Enberg wrote:
>
>> On Fri, Mar 5, 2010 at 8:49 AM, Ingo Molnar wrote:
>> > The conclusion is crystal clear, breaking an ABI via a "flag day"
>> > cleanup/feature/etc is:
>> >
>> > ?- wrong
>> >
>> > ?- harmful
>> >
>> > ?- limits the
On Fri, Mar 5, 2010 at 3:17 PM, Linus Torvalds
wrote:
>
>
> On Fri, 5 Mar 2010, Dave Airlie wrote:
>>
>> wget
>> http://kojipkgs.fedoraproject.org/packages/xorg-x11-drv-nouveau/0.0.16/2.20100218git2964702.fc13/src/xorg-x11-drv-nouveau-0.0.16-2.20100218git2964702.fc13.s
>>
>> Anyway, since I had looked at the libdrm sources, I had most of this on my
>> machine anyway, so I've compiled it all, and am going to reboot and see if
>> I can make a few symlinks work.
>>
>> IOW, right now I have this:
>>
>> [r...@nehalem ~]# cd /usr/lib64/xorg/modules/drivers/
>> [r
On Fri, Mar 5, 2010 at 9:28 AM, Linus Torvalds
wrote:
>
>
> On Thu, 4 Mar 2010, Linus Torvalds wrote:
>>
>> Is it really just nouveau? I've not looked, but I bet the intel driver and
>> the radeon driver have _exactly_ the same "oh, I'm the wrong version, I
>> will now kill myself" behavior.
>
> O
>>
>> Its nouveau project not X not DRM, stop generalising the situation.
>
> Is it really just nouveau? I've not looked, but I bet the intel driver and
> the radeon driver have _exactly_ the same "oh, I'm the wrong version, I
> will now kill myself" behavior.
>
> I certainly seem to remember some
On Fri, Mar 5, 2010 at 8:54 AM, Linus Torvalds
wrote:
>
>
> On Thu, 4 Mar 2010, Stephane Marchesin wrote:
>>
>> In short, the "don't break user space interfaces" principle is making
>> user space code quality worse for everyone. And it makes our lives as
>> graphics developers pretty miserable act
> Can we try to make it less of a pain in the ass at some other level?
>
> For example, I realize that it's a real pain - both for the kernel _and_
> for the user space library - to dynamically have to support multiple
> versions of some interface.
>
> And doing it _statically_ (with a compile opti
>>
>> If marking the driver as staging doesn't allow them to break ABI when
>> they need to, then it seems like they'll have no choice but to either
>> remove the driver from upstream and only submit it when the ABI is
>> stable, or fork the driver and submit a new one only when the ABI is
>> stabl
>>
>>
>> I've only really got two answer for this:
>>
>> (a) hook up another /dev/dri/card_fb device and use the current KMS
>> ioctls to control the framebuffer, have the drm callback into fbdev/fbcon
>> to mention resizes etc. Or add one or two info gathering ioctls and
>> allow use of the /dev/d
On Mon, Mar 1, 2010 at 7:18 PM, Michal Suchanek wrote:
> On 21 November 2009 05:27, Dave Airlie wrote:
>
>> At the moment the problem with fbset is what to do with it in the
>> dual head case. Currently we create an fb console that is lowest
>> common size of the two he
write domains in pin_and_relocate
Dave Airlie (23):
drm/radeon/kms: switch all KMS driver ioctls to unlocked.
drm/radeon/kms: use udelay for short delays
drm: switch all GEM/KMS ioctls to unlocked ioctl status.
drm/kms: fix fb_changed = true else statement
drm/radeon/kms:
0/3/3 Dave Airlie :
>>
>> Never mind. I've unpulled the whole effin' mess since it doesn't even
>> compile:
>>
>> drivers/gpu/drm/nouveau/nouveau_acpi.c:191: error: redefinition of
>> ‘nouveau_register_dsm_handler’
>>
1 - 100 of 1512 matches
Mail list logo
