let's assume that one application want to allocate user space memory
region using malloc() and then write something on the region. as you
may know, user space buffer doen't have real physical pages once
malloc() call so if user tries to access the region then page fault
handler would be triggered
Hi KOSAKI,
On 05/11/2012 02:53 AM, KOSAKI Motohiro wrote:
let's assume that one application want to allocate user space memory
region using malloc() and then write something on the region. as you
may know, user space buffer doen't have real physical pages once
malloc() call so
On 05/11/2012 10:47 AM, Inki Dae wrote:
>
>> -Original Message-
>> From: Jerome Glisse [mailto:j.gli...@gmail.com]
>> Sent: Friday, May 11, 2012 12:53 AM
>> To: Jerome Glisse; Inki Dae; linux...@kvack.org;
> kyungmin.p...@samsung.com;
>> sw0312@samsung.com; dri-devel@lists.freedesktop
(5/10/12 8:50 PM), Minchan Kim wrote:
Hi KOSAKI,
On 05/11/2012 02:53 AM, KOSAKI Motohiro wrote:
let's assume that one application want to allocate user space memory
region using malloc() and then write something on the region. as you
may know, user space buffer doen't have real physical pages
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/gma500/opregion.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/gma500/opregion.c
b/drivers/gpu/drm/gma500/opregion.c
index 05661bf..e2fbf4d 100644
--- a/drivers/gpu/drm/gma500/opregion.c
+++ b/drivers/g
https://bugs.freedesktop.org/show_bug.cgi?id=49654
--- Comment #2 from Niels Ole Salscheider
2012-05-11 00:05:13 UTC ---
Created attachment 61417
--> https://bugs.freedesktop.org/attachment.cgi?id=61417
Xorg.0.log
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
---
https://bugs.freedesktop.org/show_bug.cgi?id=49654
--- Comment #3 from Niels Ole Salscheider
2012-05-11 00:09:55 PDT ---
Created attachment 61419
--> https://bugs.freedesktop.org/attachment.cgi?id=61419
dmesg
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
---
On Don, 2012-05-10 at 13:00 -0400, alexdeuc...@gmail.com wrote:
> From: Alex Deucher
>
> All radeon_gem_init() does is initialize the gem objects
> list. radeon_device.c does this explicitly. r600+ calls
> radeon_gem_init() so the list gets initialized twice. Older
> asics don't call it at al
https://bugs.freedesktop.org/show_bug.cgi?id=49654
--- Comment #4 from Niels Ole Salscheider
2012-05-11 00:16:58 UTC ---
Created attachment 61420
--> https://bugs.freedesktop.org/attachment.cgi?id=61420
Xorg.0.log after switching between modes
The non-native mode 1440x900 seems to work, too.
https://bugs.freedesktop.org/show_bug.cgi?id=49782
Bug #: 49782
Summary: libdrm 2.4.34 fails to build
Classification: Unclassified
Product: DRI
Version: XOrg CVS
Platform: Other
OS/Version: All
Status: NEW
Se
Hi,
here is the updated patches including the conversion to struct
vga_switcheroo_client_ops.
The patches can be pulled from
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
topic/vga-switcheroo
[background info if anyone hasn't read v1 patch series:
this is for allowing to hand
This changes the API as a clean-up. Instead of passing multiple
function pointers at each time, introduce a new struct holding the
whole callback functions and pass it to the registration.
The same struct will be used for the upcoming audio client
registration, too.
Signed-off-by: Takashi Iwai
Add the support for audio clients to VGA-switcheroo for handling the
HDMI audio controller together with VGA switching. The id of the
audio controller should be given explicitly at registration time
unlike the video controller.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43155
Signed-o
Refactor the code base a bit for the further work to adapt more clients.
Signed-off-by: Takashi Iwai
---
drivers/gpu/vga/vga_switcheroo.c | 209 --
1 file changed, 110 insertions(+), 99 deletions(-)
diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu
On Fri, 11 May 2012 06:39:02 +0200
Sasha Levin wrote:
> Signed-off-by: Sasha Levin
NAK - see the patch I posted for Randy to test. That avoids all the
ifdeffery and simply doesn't touch the opregion at all in a non ACPI
build.
Not btw that I imagine you could run a non ACPI kernel on a box new
On Fri, 11 May 2012 11:49:48 +0200
Sasha Levin wrote:
> On Fri, May 11, 2012 at 11:43 AM, Alan Cox wrote:
> > Not btw that I imagine you could run a non ACPI kernel on a box new
> > enough to have a GMA500 8)
>
> Probably not, but I saw more #ifdef CONFIG_ACPI below and assumed
> there's a good
Hi everybody,
well the following patches remove the cs and vram mutex from the radeon driver
and so are something very experimental. The first three just move what I know
to be still critical into the protection of the ring mutex, and the other two
actually remove the mutexs.
Interestingly it sti
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h | 23 ++-
drivers/gpu/drm/radeon/radeon_fence.c | 73 +
2 files changed, 85 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/ra
It is completely unnecessary to create fences
before they are emitted, so remove it and a bunch
of checks if fences are emitted or not.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/evergreen.c|2 +-
drivers/gpu/drm/radeon/ni.c |2 +-
drivers/gpu/drm/rad
There are probably some missed corner cases, but at least try to remove or
replace it with a vm mutex where it is still needed.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h| 44 +---
drivers/gpu/drm/radeon/radeon_cs.c |7 ++---
Move inter ring syncing with semaphores into the
existing ring allocations, with that we need to
lock the ring mutex only once.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/evergreen_blit_kms.c |3 +-
drivers/gpu/drm/radeon/r600.c |5 +-
drivers/gpu/drm/radeon/
Even more heretic than the last one. The mutex is
probably good for something, I just can't see what
that is at the moment.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h|1 -
drivers/gpu/drm/radeon/radeon_device.c |1 -
drivers/gpu/drm/radeon/radeon_object.c
On Fri, May 11, 2012 at 11:10 AM, Christian König
wrote:
> Hi everybody,
>
> well the following patches remove the cs and vram mutex from the radeon driver
> and so are something very experimental. The first three just move what I know
> to be still critical into the protection of the ring mutex,
From: Alan Cox
Reported-by: Randy Dunlap
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/Makefile |3 ++-
drivers/gpu/drm/gma500/opregion.c |6 --
drivers/gpu/drm/gma500/opregion.h | 22 +-
drivers/gpu/drm/gma500/psb_drv.h |6 --
4 files changed
From: Alan Cox
This starts the move away from lots of confused unions of per driver stuff
inherited when we merged the drivers together.
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/cdv_intel_display.c | 33 ++---
drivers/gpu/drm/gma500/mdfld_device.c | 177 -
From: Alan Cox
We have lots of local assignments that can now be eliminated
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/mdfld_device.c | 129 -
1 files changed, 46 insertions(+), 83 deletions(-)
diff --git a/drivers/gpu/drm/gma500/mdfld_device.c
b/dri
From: Alan Cox
All the conditional ugly register selection really wants to be
cleaned up. Use a struct describing each pipe and its registers.
This will also let us hide some of the oddments between platforms
for any future merging of bits together. In particular the way the
DPLL and FP register
From: Alan Cox
We have a lot of debug type stuff we don't actually need any more.
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/cdv_device.c |2 +-
drivers/gpu/drm/gma500/framebuffer.c |2 +-
drivers/gpu/drm/gma500/gtt.c | 12 +++-
drivers/gpu/drm/gma500/psb_dr
From: Alan Cox
Cover all D2xxx/N2xxx chips.
Signed-off-by: Zhenyu Wang
[Hand applied to upstream driver]
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/psb_drv.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers
From: Alan Cox
We don't need to check these - they are always going to be the
same for any PVR based device.
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/cdv_device.c |3 +++
drivers/gpu/drm/gma500/mdfld_device.c|2 ++
drivers/gpu/drm/gma500/oaktrail_device.c |3 +++
From: Alan Cox
Keep this as a patch of its own in case of bug reports.
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/psb_drv.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/gpu/drm/gma500/psb_drv.c
index 2bfbeb6..74
https://bugs.freedesktop.org/show_bug.cgi?id=49789
Bug #: 49789
Summary: External monitor flickers on xrandr or cat
/sys/class/drm/card0-VGA-1/status
Classification: Unclassified
Product: DRI
Version: XOrg CVS
Platform
https://bugs.freedesktop.org/show_bug.cgi?id=49789
--- Comment #1 from Harald Judt 2012-05-11 04:38:17 PDT ---
Created attachment 61442
--> https://bugs.freedesktop.org/attachment.cgi?id=61442
xdpyinfo
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are
On 11.05.2012 12:12, Dave Airlie wrote:
On Fri, May 11, 2012 at 11:10 AM, Christian König
wrote:
Hi everybody,
well the following patches remove the cs and vram mutex from the radeon driver
and so are something very experimental. The first three just move what I know
to be still critical into
https://bugs.freedesktop.org/show_bug.cgi?id=49794
Michel Dänzer changed:
What|Removed |Added
AssignedTo|xorg-driver-...@lists.x.org |dri-devel@lists.freedesktop
On Fri, May 11, 2012 at 6:10 AM, Christian König
wrote:
> Even more heretic than the last one. The mutex is
> probably good for something, I just can't see what
> that is at the moment.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/radeon/radeon.h | 1 -
> drivers/gpu/drm/
On Fri, May 11, 2012 at 10:41 AM, Jerome Glisse wrote:
> On Fri, May 11, 2012 at 6:10 AM, Christian König
> wrote:
>> Even more heretic than the last one. The mutex is
>> probably good for something, I just can't see what
>> that is at the moment.
>>
>> Signed-off-by: Christian König
>> ---
>>
https://bugs.freedesktop.org/show_bug.cgi?id=49789
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugzilla.kernel.org/show_bug.cgi?id=43207
Alex Deucher changed:
What|Removed |Added
CC||alexdeuc...@gmail.com
--- Comment #2 f
https://bugzilla.kernel.org/show_bug.cgi?id=43207
--- Comment #3 from Alex Deucher 2012-05-11 14:56:18
---
This is a duplicate of:
https://bugs.freedesktop.org/show_bug.cgi?id=49792
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this ma
https://bugs.freedesktop.org/show_bug.cgi?id=49794
--- Comment #1 from Alex Deucher 2012-05-11 07:59:13 PDT ---
Please attach a copy of your vbios.
(as root)
(use lspci to get the bus id)
cd /sys/bus/pci/devices/
echo 1 > rom
cat rom > /tmp/vbios.rom
echo 0 > rom
--
Configure bugmail: https://
https://bugs.freedesktop.org/show_bug.cgi?id=49789
--- Comment #3 from Harald Judt 2012-05-11 08:10:30 PDT ---
Can I somehow find out (log files, whatever), whether the monitor has an EDID
or not, after it has been connected? Because then I could turn off the polling
for the time being, or at lea
On 11.05.2012 16:44, Jerome Glisse wrote:
On Fri, May 11, 2012 at 10:41 AM, Jerome Glisse wrote:
On Fri, May 11, 2012 at 6:10 AM, Christian König
wrote:
Even more heretic than the last one. The mutex is
probably good for something, I just can't see what
that is at the moment.
Signed-off-by:
On Fri, May 11, 2012 at 11:43 AM, Alan Cox wrote:
> Not btw that I imagine you could run a non ACPI kernel on a box new
> enough to have a GMA500 8)
Probably not, but I saw more #ifdef CONFIG_ACPI below and assumed
there's a good reason for that.
Out of curiously, is a scenario where a GMA500 is
https://bugs.freedesktop.org/show_bug.cgi?id=49794
--- Comment #2 from ddfs 2012-05-11 08:24:45 PDT ---
Created attachment 61456
--> https://bugs.freedesktop.org/attachment.cgi?id=61456
hd5850 bios
vbios attached
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
On Tue, Apr 24, 2012 at 4:08 AM, Daniel Vetter wrote:
> Compared to Rob Clark's RFC I've ditched the prepare/finish hooks
> and corresponding ioctls on the dma_buf file. The major reason for
> that is that many people seem to be under the impression that this is
> also for synchronization with out
https://bugs.freedesktop.org/show_bug.cgi?id=49794
--- Comment #3 from ddfs 2012-05-11 08:33:08 PDT ---
Created attachment 61457
--> https://bugs.freedesktop.org/attachment.cgi?id=61457
boot clocks
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are rece
https://bugs.freedesktop.org/show_bug.cgi?id=49794
--- Comment #4 from ddfs 2012-05-11 08:33:36 PDT ---
Created attachment 61458
--> https://bugs.freedesktop.org/attachment.cgi?id=61458
UVD clocks
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are recei
https://bugs.freedesktop.org/show_bug.cgi?id=49794
--- Comment #5 from ddfs 2012-05-11 08:34:42 PDT ---
I also attched RBE screenshots with opened vbios.rom
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are th
https://bugs.freedesktop.org/show_bug.cgi?id=49789
--- Comment #4 from Alex Deucher 2012-05-11 10:23:56 PDT ---
(In reply to comment #3)
> Can I somehow find out (log files, whatever), whether the monitor has an EDID
> or not, after it has been connected? Because then I could turn off the polling
https://bugs.freedesktop.org/show_bug.cgi?id=27184
--- Comment #27 from tomi.or...@ncircle.nullnet.fi 2012-05-11 13:14:35 PDT ---
> You can use xset to test dpms, e.g.,
> xset dpms force off
>
> Also, for what it's worth, the driver only implements two states: on and off.
> All of the intermedi
https://bugzilla.kernel.org/show_bug.cgi?id=43207
--- Comment #4 from Vladislav Tcendrovskii 2012-05-11 20:21:01
---
Created an attachment (id=73252)
--> (https://bugzilla.kernel.org/attachment.cgi?id=73252)
dmesg
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
https://bugzilla.kernel.org/show_bug.cgi?id=43207
--- Comment #5 from Vladislav Tcendrovskii 2012-05-11 20:21:21
---
Created an attachment (id=73253)
--> (https://bugzilla.kernel.org/attachment.cgi?id=73253)
Xorg log
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=ema
https://bugzilla.kernel.org/show_bug.cgi?id=43207
--- Comment #6 from Vladislav Tcendrovskii 2012-05-11 20:34:02
---
Created an attachment (id=73254)
--> (https://bugzilla.kernel.org/attachment.cgi?id=73254)
screenshot
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=e
https://bugs.freedesktop.org/show_bug.cgi?id=49603
--- Comment #6 from Sven Arvidsson 2012-05-11 13:46:30 PDT ---
I have tried both stopsleep and the shell loop now, but sadly neither one gets
rid of the problem.
I get the feeling that there's less stalls with them, but video playback isn't
as s
https://bugs.freedesktop.org/show_bug.cgi?id=49817
Bug #: 49817
Summary: radeon: The kernel rejected CS when running shader
example from SFML library
Classification: Unclassified
Product: Mesa
Version: git
Platform: x8
On Fri, May 11, 2012 at 5:20 PM, KOSAKI Motohiro
wrote:
> (5/10/12 11:01 PM), Jerome Glisse wrote:
>>
>> On Thu, May 10, 2012 at 10:51 PM, KOSAKI Motohiro
>> wrote:
>>>
>>> (5/10/12 8:50 PM), Minchan Kim wrote:
Hi KOSAKI,
On 05/11/2012 02:53 AM, KOSAKI Motohiro wrote:
>>
https://bugs.freedesktop.org/show_bug.cgi?id=43167
Daniel Vetter changed:
What|Removed |Added
AssignedTo|dan...@ffwll.ch |dri-devel@lists.freedesktop
https://bugs.freedesktop.org/show_bug.cgi?id=43167
--- Comment #35 from Daniel Vetter 2012-05-11 16:16:21 PDT ---
Bisect result points at core drm, moving bug from driver component to general.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving t
https://bugs.freedesktop.org/show_bug.cgi?id=43167
--- Comment #36 from Alan 2012-05-11 16:22:12 PDT ---
Looks like a vt bug to me as well. As if something is changing the end of line
behaviour flag and not restoring it. As and when Alex files it against the vt
layer in the kernel bugzilla I'll t
On Fri, May 11, 2012 at 6:59 PM, KOSAKI Motohiro
wrote:
>> My point is this ioctl will be restricted to one user (Xserver if i
>> understand) and only this user, there is no fork in it so no need to
>> worry about fork, just setting the vma as locked will be enough.
>>
>> But i don't want people r
https://bugzilla.kernel.org/show_bug.cgi?id=43125
Alan changed:
What|Removed |Added
CC||a...@lxorguk.ukuu.org.uk
Component|x86-6
https://bugzilla.kernel.org/show_bug.cgi?id=43209
Alan changed:
What|Removed |Added
CC||a...@lxorguk.ukuu.org.uk
Component|Other
https://bugzilla.kernel.org/show_bug.cgi?id=43112
Alan changed:
What|Removed |Added
Component|Video(Other)|Video(DRI - non Intel)
AssignedTo|drivers
https://bugzilla.kernel.org/show_bug.cgi?id=42984
Alan changed:
What|Removed |Added
CC||a...@lxorguk.ukuu.org.uk
Component|Video
https://bugs.freedesktop.org/show_bug.cgi?id=43167
--- Comment #37 from al...@verizon.net 2012-05-11 19:07:07 PDT ---
Thanks, Alan.
As mentioned, I'm a simple user, never filed a kernel bug
so I need a little help, please.
Is there an easy way (workaround?) to file a kernel bugzilla
whereby I'd j
https://bugzilla.kernel.org/show_bug.cgi?id=42609
Alan changed:
What|Removed |Added
CC||a...@lxorguk.ukuu.org.uk
Component|Video
https://bugzilla.kernel.org/show_bug.cgi?id=42570
Alan changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://bugzilla.kernel.org/show_bug.cgi?id=43112
Alex Deucher changed:
What|Removed |Added
CC||alexdeuc...@gmail.com
--- Comment #2 f
https://bugzilla.kernel.org/show_bug.cgi?id=42609
Alex Deucher changed:
What|Removed |Added
CC||alexdeuc...@gmail.com
--- Comment #1 f
https://bugzilla.kernel.org/show_bug.cgi?id=42609
Alexandre Demers changed:
What|Removed |Added
CC||alexandre.f.dem...@gmail.co
https://bugs.freedesktop.org/show_bug.cgi?id=49322
--- Comment #1 from Brian Schott 2012-05-11 21:27:21
PDT ---
I got tired of only being able to use ⅔ of my monitors, so I tried using the
integrated graphics (Intel hd4000 / ivy bridge) to power them. (Motherboard has
VGA, DVI, HDMI and full-siz
2012/5/12 KOSAKI Motohiro :
> On Fri, May 11, 2012 at 7:29 PM, Jerome Glisse wrote:
>> On Fri, May 11, 2012 at 6:59 PM, KOSAKI Motohiro
>> wrote:
My point is this ioctl will be restricted to one user (Xserver if i
understand) and only this user, there is no fork in it so no need to
Hi,
we had posted this patch and we hope this patch is applied to libdrm
so that we can go ahead next work. as you may know, exynos drm driver
have already been merged to mainline.
please, let me know if there is any problem.
Thanks,
Inki Dae
2012/5/4 Inki Dae :
> this patch adds libdrm_exynos
> -Original Message-
> From: Jerome Glisse [mailto:j.glisse at gmail.com]
> Sent: Friday, May 11, 2012 12:53 AM
> To: Jerome Glisse; Inki Dae; linux-mm at kvack.org;
kyungmin.park at samsung.com;
> sw0312.kim at samsung.com; dri-devel at lists.freedesktop.org
> Subject: Re: [PATCH 2/2 v3]
https://bugs.freedesktop.org/show_bug.cgi?id=49747
--- Comment #19 from Daniel Vetter 2012-05-10 23:09:22 PDT
---
Created attachment 61414
--> https://bugs.freedesktop.org/attachment.cgi?id=61414
vbios rom
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You
Hi KOSAKI,
On 05/11/2012 02:53 AM, KOSAKI Motohiro wrote:
let's assume that one application want to allocate user space memory
region using malloc() and then write something on the region. as you
may know, user space buffer doen't have real physical pages once
malloc() call so
On 05/11/2012 10:47 AM, Inki Dae wrote:
>
>> -Original Message-
>> From: Jerome Glisse [mailto:j.glisse at gmail.com]
>> Sent: Friday, May 11, 2012 12:53 AM
>> To: Jerome Glisse; Inki Dae; linux-mm at kvack.org;
> kyungmin.park at samsung.com;
>> sw0312.kim at samsung.com; dri-devel at li
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/gma500/opregion.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/gma500/opregion.c
b/drivers/gpu/drm/gma500/opregion.c
index 05661bf..e2fbf4d 100644
--- a/drivers/gpu/drm/gma500/opregion.c
+++ b/drivers/g
https://bugs.freedesktop.org/show_bug.cgi?id=49654
--- Comment #2 from Niels Ole Salscheider
2012-05-11 00:05:13 UTC ---
Created attachment 61417
--> https://bugs.freedesktop.org/attachment.cgi?id=61417
Xorg.0.log
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
---
https://bugs.freedesktop.org/show_bug.cgi?id=49654
--- Comment #3 from Niels Ole Salscheider
2012-05-11 00:09:55 PDT ---
Created attachment 61419
--> https://bugs.freedesktop.org/attachment.cgi?id=61419
dmesg
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
---
On Don, 2012-05-10 at 13:00 -0400, alexdeucher at gmail.com wrote:
> From: Alex Deucher
>
> All radeon_gem_init() does is initialize the gem objects
> list. radeon_device.c does this explicitly. r600+ calls
> radeon_gem_init() so the list gets initialized twice. Older
> asics don't call it at
https://bugs.freedesktop.org/show_bug.cgi?id=49654
--- Comment #4 from Niels Ole Salscheider
2012-05-11 00:16:58 UTC ---
Created attachment 61420
--> https://bugs.freedesktop.org/attachment.cgi?id=61420
Xorg.0.log after switching between modes
The non-native mode 1440x900 seems to work, too.
https://bugs.freedesktop.org/show_bug.cgi?id=49782
Bug #: 49782
Summary: libdrm 2.4.34 fails to build
Classification: Unclassified
Product: DRI
Version: XOrg CVS
Platform: Other
OS/Version: All
Status: NEW
Se
Hi,
here is the updated patches including the conversion to struct
vga_switcheroo_client_ops.
The patches can be pulled from
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
topic/vga-switcheroo
[background info if anyone hasn't read v1 patch series:
this is for allowing to hand
This changes the API as a clean-up. Instead of passing multiple
function pointers at each time, introduce a new struct holding the
whole callback functions and pass it to the registration.
The same struct will be used for the upcoming audio client
registration, too.
Signed-off-by: Takashi Iwai
Add the support for audio clients to VGA-switcheroo for handling the
HDMI audio controller together with VGA switching. The id of the
audio controller should be given explicitly at registration time
unlike the video controller.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43155
Signed-o
Refactor the code base a bit for the further work to adapt more clients.
Signed-off-by: Takashi Iwai
---
drivers/gpu/vga/vga_switcheroo.c | 209 --
1 file changed, 110 insertions(+), 99 deletions(-)
diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu
On Fri, 11 May 2012 06:39:02 +0200
Sasha Levin wrote:
> Signed-off-by: Sasha Levin
NAK - see the patch I posted for Randy to test. That avoids all the
ifdeffery and simply doesn't touch the opregion at all in a non ACPI
build.
Not btw that I imagine you could run a non ACPI kernel on a box new
On Fri, 11 May 2012 11:49:48 +0200
Sasha Levin wrote:
> On Fri, May 11, 2012 at 11:43 AM, Alan Cox
> wrote:
> > Not btw that I imagine you could run a non ACPI kernel on a box new
> > enough to have a GMA500 8)
>
> Probably not, but I saw more #ifdef CONFIG_ACPI below and assumed
> there's a g
Hi everybody,
well the following patches remove the cs and vram mutex from the radeon driver
and so are something very experimental. The first three just move what I know
to be still critical into the protection of the ring mutex, and the other two
actually remove the mutexs.
Interestingly it sti
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h | 23 ++-
drivers/gpu/drm/radeon/radeon_fence.c | 73 +
2 files changed, 85 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/ra
It is completely unnecessary to create fences
before they are emitted, so remove it and a bunch
of checks if fences are emitted or not.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/evergreen.c|2 +-
drivers/gpu/drm/radeon/ni.c |2 +-
drivers/gpu/drm/rad
There are probably some missed corner cases, but at least try to remove or
replace it with a vm mutex where it is still needed.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h| 44 +---
drivers/gpu/drm/radeon/radeon_cs.c |7 ++---
Move inter ring syncing with semaphores into the
existing ring allocations, with that we need to
lock the ring mutex only once.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/evergreen_blit_kms.c |3 +-
drivers/gpu/drm/radeon/r600.c |5 +-
drivers/gpu/drm/radeon/
Even more heretic than the last one. The mutex is
probably good for something, I just can't see what
that is at the moment.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h|1 -
drivers/gpu/drm/radeon/radeon_device.c |1 -
drivers/gpu/drm/radeon/radeon_object.c
On Fri, May 11, 2012 at 11:10 AM, Christian K?nig
wrote:
> Hi everybody,
>
> well the following patches remove the cs and vram mutex from the radeon driver
> and so are something very experimental. The first three just move what I know
> to be still critical into the protection of the ring mutex,
From: Alan Cox
Reported-by: Randy Dunlap
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/Makefile |3 ++-
drivers/gpu/drm/gma500/opregion.c |6 --
drivers/gpu/drm/gma500/opregion.h | 22 +-
drivers/gpu/drm/gma500/psb_drv.h |6 --
4 files changed
From: Alan Cox
This starts the move away from lots of confused unions of per driver stuff
inherited when we merged the drivers together.
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/cdv_intel_display.c | 33 ++---
drivers/gpu/drm/gma500/mdfld_device.c | 177 -
From: Alan Cox
We have lots of local assignments that can now be eliminated
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/mdfld_device.c | 129 -
1 files changed, 46 insertions(+), 83 deletions(-)
diff --git a/drivers/gpu/drm/gma500/mdfld_device.c
b/dri
1 - 100 of 141 matches
Mail list logo
