[PATCH 2/2 v3] drm/exynos: added userptr feature.

[KOSAKI Motohiro]

(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 once
> malloc() call so if user tries to access the region then page fault
> handler would be triggered


 Understood.

> and then in turn next process like swap in to fill physical frame
> number
 into entry of the page faulted.


 Sorry, I can't understand your point due to my poor English.
 Could you rewrite it easiliy? :)

>>>
>>> Simply saying, handle_mm_fault would be called to update pte after
>>> finding
>>> vma and checking access right. and as you know, there are many cases to
>>> process page fault such as COW or demand paging.
>>
>> Hmm. If I understand correctly, you guys misunderstand mlock. it doesn't
>> page pinning
>> nor prevent pfn change. It only guarantee to don't make swap out. e.g.
>
>
> Symantic point of view, you're right but the implementation makes sure page 
> pinning.
>
>> memory campaction
>> feature may automatically change page physical address.
>
>
> I tried it last year but decided drop by realtime issue.
> https://lkml.org/lkml/2011/8/29/295
>
> so I think mlock is a kind of page pinning. If elsewhere I don't realized is 
> doing, that place should be fixed.
> Or my above patch should go ahead.

Thanks pointing out. I didn't realized your patch didn't merged. I think it 
should go ahead. think autonuma case,
if mlock disable autonuma migration, that's bug.  I don't think we can promise 
mlock don't change physical page.
I wonder if any realtime guys page migration is free lunch. they should disable 
both auto migration and compaction.

And, think if application explictly use migrate_pages(2) or admins uses 
cpusets. driver code can't assume such scenario
doesn't occur, yes?

[Bug 49747] dpms on only works on DP0 on a hd5700

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=49747

--- Comment #18 from Alex Deucher  2012-05-10 15:45:57 PDT 
---
Can you 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://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 49654] Heavy flickering on LVDS panel when not using the native resolution

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=49654

--- Comment #1 from Alex Deucher  2012-05-10 15:43:30 PDT 
---
please attach your xorg log and dmesg output.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 49110] debug build: AMDILCFGStructurizer.cpp:1751:3: error: 'isCurrentDebugType' was not declared in this scope

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=49110

--- Comment #7 from Mike Mestnik  2012-05-10 14:43:40 PDT ---
Hello,
  I've concluded that there just isn't enough time until Diablo III is released
and so I hope that I can get myself to halt all work on this issue.

The llvm r600g compiler isn't close enough to the horizon for me to see it
being useful by May 15th.

Thank you.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH 2/2] vga_switcheroo: Add the support for audio clients

[Takashi Iwai]

At Thu, 10 May 2012 20:05:25 +0100,
Dave Airlie wrote:
> 
> On Thu, May 10, 2012 at 7:42 PM, Takashi Iwai  wrote:
> > At Thu, 10 May 2012 13:42:09 +0200,
> > Takashi Iwai wrote:
> >>
> >> At Thu, 10 May 2012 12:20:05 +0100,
> >> Alan Cox wrote:
> >> >
> >> > On Thu, 10 May 2012 09:10:16 +0200
> >> > Takashi Iwai  wrote:
> >> >
> >> > > 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 explicity at registration time unlike
> >> > > the video controller.
> >> >
> >> > It would I think be a lot cleaner and more future proof to pass a
> >> >
> >> > struct hdmi_audio_switch_ops
> >> >
> >> > or some similar named object with an array of function pointers ?
> >>
> >> That would be a good option, indeed.
> >>
> >> In my patch series, I just didn't want to break the existing API,
> >> so I kept the current style.
> >
> > Dave, do you prefer the way with an ops struct as Alan suggested?
> >
> > For example, I can make like
> >
> > struct vga_switcheroo_client_ops {
> > ? ? ? void (*set_gpu_state)(struct pci_dev *dev, enum vga_switcheroo_state),
> > ? ? ? void (*reprobe)(struct pci_dev *dev),
> > ? ? ? bool (*can_switch)(struct pci_dev *dev));
> > };
> 
> Yeah I suppose we should go and just do that now, it kinda grew a bit
> much previously.
> 
> If you want to do patches for it I'd be happy to take them.

OK, I'll work on it tomorrow.


Takashi

[Bug 49747] dpms on only works on DP0 on a hd5700

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=49747

Daniel Vetter  changed:

   What|Removed |Added

  Attachment #61403|application/octet-stream|text/plain
  mime type||

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 49747] dpms on only works on DP0 on a hd5700

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=49747

--- Comment #17 from Daniel Vetter  2012-05-10 13:58:04 PDT 
---
Created attachment 61405
  --> https://bugs.freedesktop.org/attachment.cgi?id=61405
radeonregs dump after boot, DP1 broken

Somehow dpms off/on doesn't break things right now (I've only managed to once
create a strangely torn-in-half screen, never black and otherwise it just
worked). So I've fallen back to the always reliable switch-screen-off-and-on
and then forced a mode set with xrandr --off/--auto (which did not help).

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 49747] dpms on only works on DP0 on a hd5700

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=49747

--- Comment #16 from Daniel Vetter  2012-05-10 13:56:12 PDT 
---
Created attachment 61403
  --> https://bugs.freedesktop.org/attachment.cgi?id=61403
radeonregs dump after boot, both screens working

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 49747] dpms on only works on DP0 on a hd5700

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=49747

Daniel Vetter  changed:

   What|Removed |Added

  Attachment #61402|0   |1
is obsolete||

--- Comment #15 from Daniel Vetter  2012-05-10 13:55:55 PDT 
---
Comment on attachment 61402
  --> https://bugs.freedesktop.org/attachment.cgi?id=61402
radeonregs dump after boot

Actually wrong file, sorry.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 49747] dpms on only works on DP0 on a hd5700

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=49747

--- Comment #14 from Daniel Vetter  2012-05-10 13:54:35 PDT 
---
Created attachment 61402
  --> https://bugs.freedesktop.org/attachment.cgi?id=61402
radeonregs dump after boot

dce4 regdump after boot, both screens working

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 49747] dpms on only works on DP0 on a hd5700

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=49747

--- Comment #13 from Daniel Vetter  2012-05-10 13:44:07 PDT 
---
Another curious thing I've just noticed: I've accidentally left the hdmi
plugged in and hat 3 DP ports enabled in xrandr. Disabling the 3rd output did
not kill the picture on DP1, despite that both DP0 and DP1 shortly blanked (I
didn't dare switching to the hdmi output to see what's going on there).

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH 2/2] vga_switcheroo: Add the support for audio clients

[Takashi Iwai]

At Thu, 10 May 2012 13:42:09 +0200,
Takashi Iwai wrote:
> 
> At Thu, 10 May 2012 12:20:05 +0100,
> Alan Cox wrote:
> > 
> > On Thu, 10 May 2012 09:10:16 +0200
> > Takashi Iwai  wrote:
> > 
> > > 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 explicity at registration time unlike
> > > the video controller.
> > 
> > It would I think be a lot cleaner and more future proof to pass a 
> > 
> > struct hdmi_audio_switch_ops
> > 
> > or some similar named object with an array of function pointers ?
> 
> That would be a good option, indeed.
> 
> In my patch series, I just didn't want to break the existing API,
> so I kept the current style.

Dave, do you prefer the way with an ops struct as Alan suggested?

For example, I can make like

struct vga_switcheroo_client_ops {
   void (*set_gpu_state)(struct pci_dev *dev, enum vga_switcheroo_state),
   void (*reprobe)(struct pci_dev *dev),
   bool (*can_switch)(struct pci_dev *dev));
};

and pass the pointer to vga_switcher_register_client() and
vga_switcher_register_audio_client().

If it's preferred, I'll work on it and resend you a pull request later.

BTW, I modified topic/vga-switcheroo branch of sound git tree again.
Now it contains only two commits I posted here.  The rest commits for
HD-audio are found in topic/hda-switcheroo branch.


thanks,

Takashi

[Bug 49747] dpms on only works on DP0 on a hd5700

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=49747

--- Comment #12 from Daniel Vetter  2012-05-10 13:39:27 PDT 
---
Ok, more throughrough testing on all ports. The screens are both the same
model, but different manufacturing dates (and firmware revision according to
osd).

DP0 seems to work in all cases, although when I switch off the screeen or
unplug the cable, I need to do a vt switch to get a picture on the screen.

DP1-4 seem to work with the hdmi cable for a dpms off/on cycle, but not with
the dp cable.

DP1-4 doesn't work at all (either hdmi or dp) when the monitor got switched off
or the cable freshly plugged in while linux is running. Even xrandr
--off/--auto doesn't help, only rebooting.

The entire thing seems pretty flaky, even switching the input selection on the
screen between hdmi and dp is enough to loose the dp signal. With this round of
playing I've also seen new noise in dmesg:

[ 1275.106268] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
remainder is 44
[ 1275.106271] Raw EDID:
[ 1275.106272]  00 ff ff ff ff ff ff 00 22 f0 f9 26 01 01 01 01
[ 1275.106274]  0b 13 01 04 a5 36 23 78 ee ce 50 a3 54 4c 99 26
[ 1275.106275]  77 0f 50 54 a5 6b 80 81 40 a9 00 a9 40 b3 00 d1
[ 1275.106276]  00 01 01 01 01 01 01 28 3c 80 a0 70 b0 23 40 30
[ 1275.106277]  20 36 00 22 60 21 00 00 1a 77 00 00 fc 00 48 50
[ 1275.106278]  20 4c 50 32 34 37 35 77 0a 20 20 00 00 00 fd 00
[ 1275.106279]  30 55 1e 5e 15 04 11 50 d2 f8 58 f0 00 00 00 00
[ 1275.106280]  ff 00 43 5a 43 39 31 31 30 30 39 34 0a 20 20 00

and similar corrupted EDIDs. xrandr always displayed the correct modelist
though, afact. I'll do the radeontool dump now.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 49747] dpms on only works on DP0 on a hd5700

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=49747

--- Comment #11 from Alex Deucher  2012-05-10 13:18:19 PDT 
---
Also do you get the same behavior on all DP ports?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 49747] dpms on only works on DP0 on a hd5700

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=49747

--- Comment #10 from Daniel Vetter  2012-05-10 13:17:54 PDT 
---
Actually it's more confusing, dpms seems to work with hdmi ... I'll switch
cables again.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 49747] dpms on only works on DP0 on a hd5700

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=49747

--- Comment #9 from Daniel Vetter  2012-05-10 13:14:35 PDT 
---
I've forgot to add, after some extensive playing around I see:

[  116.394377] [drm:radeon_dp_get_link_status] *ERROR* displayport link status
failed
[  143.302728] [drm:radeon_dp_get_link_status] *ERROR* displayport link status
failed

in dmesg. I'll try the other stuff right away.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 49747] dpms on only works on DP0 on a hd5700

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=49747

--- Comment #8 from Daniel Vetter  2012-05-10 13:13:38 PDT 
---
I've played some more around with it, and the same problem happens when I
switch off the screen and on again. I've noticed that vt-switching sometimes
helps, but not always.

I've also tried to connect the screen with a dp->hdmi cable (well, mini-dp->dvi
with a dvi->hdmi) and the same problem happens there.

One thing I've noticed though is that over hdmi the screen is much brighter,
kind what I'd expect if the wrong color space is being used by the screen.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 49747] dpms on only works on DP0 on a hd5700

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=49747

--- Comment #7 from Alex Deucher  2012-05-10 13:12:51 PDT 
---
(In reply to comment #6)
> The driver correctly lights up the display on DP1 after boot, it only
> fails after the first dpms off. The dmesg/xrandr is after I've done a
> dpms cycle, i.e. black DP1 output. So nothing in there.

Does an full off/on modeset cycle bring it back?

> 
> Should I regrab dmesg after a dpms cycle with more verbose logging?

I figured maybe link training was failing.  Can you dump the registers before
and after the dpms cycle with radeonreg
(http://cgit.freedesktop.org/~airlied/radeontool/)?

radeonreg regs dce4

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH 2/2] vga_switcheroo: Add the support for audio clients

[Dave Airlie]

On Thu, May 10, 2012 at 7:42 PM, Takashi Iwai  wrote:
> At Thu, 10 May 2012 13:42:09 +0200,
> Takashi Iwai wrote:
>>
>> At Thu, 10 May 2012 12:20:05 +0100,
>> Alan Cox wrote:
>> >
>> > On Thu, 10 May 2012 09:10:16 +0200
>> > Takashi Iwai  wrote:
>> >
>> > > 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 explicity at registration time unlike
>> > > the video controller.
>> >
>> > It would I think be a lot cleaner and more future proof to pass a
>> >
>> > struct hdmi_audio_switch_ops
>> >
>> > or some similar named object with an array of function pointers ?
>>
>> That would be a good option, indeed.
>>
>> In my patch series, I just didn't want to break the existing API,
>> so I kept the current style.
>
> Dave, do you prefer the way with an ops struct as Alan suggested?
>
> For example, I can make like
>
> struct vga_switcheroo_client_ops {
> ? ? ? void (*set_gpu_state)(struct pci_dev *dev, enum vga_switcheroo_state),
> ? ? ? void (*reprobe)(struct pci_dev *dev),
> ? ? ? bool (*can_switch)(struct pci_dev *dev));
> };

Yeah I suppose we should go and just do that now, it kinda grew a bit
much previously.

If you want to do patches for it I'd be happy to take them.

Dave.

[PATCH] drm/radeon: add PRIME support

[alexdeuc...@gmail.com]

From: Alex Deucher 

This adds prime->fd and fd->prime support to radeon.
It passes the sg object to ttm and then populates
the gart entries using it.

Compile tested only.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/Makefile |3 +-
 drivers/gpu/drm/radeon/evergreen_blit_kms.c |2 +-
 drivers/gpu/drm/radeon/r600.c   |4 +-
 drivers/gpu/drm/radeon/r600_blit_kms.c  |2 +-
 drivers/gpu/drm/radeon/radeon_benchmark.c   |4 +-
 drivers/gpu/drm/radeon/radeon_device.c  |2 +-
 drivers/gpu/drm/radeon/radeon_drv.c |   14 +++-
 drivers/gpu/drm/radeon/radeon_gart.c|2 +-
 drivers/gpu/drm/radeon/radeon_gem.c |4 +-
 drivers/gpu/drm/radeon/radeon_object.c  |6 +-
 drivers/gpu/drm/radeon/radeon_object.h  |7 +-
 drivers/gpu/drm/radeon/radeon_prime.c   |  146 +++
 drivers/gpu/drm/radeon/radeon_ring.c|4 +-
 drivers/gpu/drm/radeon/radeon_sa.c  |2 +-
 drivers/gpu/drm/radeon/radeon_test.c|4 +-
 drivers/gpu/drm/radeon/radeon_ttm.c |   20 -
 drivers/gpu/drm/radeon/si.c |6 +-
 17 files changed, 207 insertions(+), 25 deletions(-)
 create mode 100644 drivers/gpu/drm/radeon/radeon_prime.c

diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile
index 9d83729..78ce7f9 100644
--- a/drivers/gpu/drm/radeon/Makefile
+++ b/drivers/gpu/drm/radeon/Makefile
@@ -71,7 +71,8 @@ radeon-y += radeon_device.o radeon_asic.o radeon_kms.o \
r600_blit_kms.o radeon_pm.o atombios_dp.o r600_audio.o r600_hdmi.o \
evergreen.o evergreen_cs.o evergreen_blit_shaders.o 
evergreen_blit_kms.o \
radeon_trace_points.o ni.o cayman_blit_shaders.o atombios_encoders.o \
-   radeon_semaphore.o radeon_sa.o atombios_i2c.o si.o si_blit_shaders.o
+   radeon_semaphore.o radeon_sa.o atombios_i2c.o si.o si_blit_shaders.o \
+   radeon_prime.o

 radeon-$(CONFIG_COMPAT) += radeon_ioc32.o
 radeon-$(CONFIG_VGA_SWITCHEROO) += radeon_atpx_handler.o
diff --git a/drivers/gpu/drm/radeon/evergreen_blit_kms.c 
b/drivers/gpu/drm/radeon/evergreen_blit_kms.c
index 30f0480..1e96bd4 100644
--- a/drivers/gpu/drm/radeon/evergreen_blit_kms.c
+++ b/drivers/gpu/drm/radeon/evergreen_blit_kms.c
@@ -668,7 +668,7 @@ int evergreen_blit_init(struct radeon_device *rdev)
obj_size = ALIGN(obj_size, 256);

r = radeon_bo_create(rdev, obj_size, PAGE_SIZE, true, 
RADEON_GEM_DOMAIN_VRAM,
-   >r600_blit.shader_obj);
+NULL, >r600_blit.shader_obj);
if (r) {
DRM_ERROR("evergreen failed to allocate shader\n");
return r;
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 971d244..e408460 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -1223,7 +1223,7 @@ int r600_vram_scratch_init(struct radeon_device *rdev)
if (rdev->vram_scratch.robj == NULL) {
r = radeon_bo_create(rdev, RADEON_GPU_PAGE_SIZE,
 PAGE_SIZE, true, RADEON_GEM_DOMAIN_VRAM,
->vram_scratch.robj);
+NULL, >vram_scratch.robj);
if (r) {
return r;
}
@@ -2761,7 +2761,7 @@ int r600_ih_ring_alloc(struct radeon_device *rdev)
r = radeon_bo_create(rdev, rdev->ih.ring_size,
 PAGE_SIZE, true,
 RADEON_GEM_DOMAIN_GTT,
->ih.ring_obj);
+NULL, >ih.ring_obj);
if (r) {
DRM_ERROR("radeon: failed to create ih ring buffer 
(%d).\n", r);
return r;
diff --git a/drivers/gpu/drm/radeon/r600_blit_kms.c 
b/drivers/gpu/drm/radeon/r600_blit_kms.c
index ef20822..03b6e0d 100644
--- a/drivers/gpu/drm/radeon/r600_blit_kms.c
+++ b/drivers/gpu/drm/radeon/r600_blit_kms.c
@@ -552,7 +552,7 @@ int r600_blit_init(struct radeon_device *rdev)
obj_size = ALIGN(obj_size, 256);

r = radeon_bo_create(rdev, obj_size, PAGE_SIZE, true, 
RADEON_GEM_DOMAIN_VRAM,
-   >r600_blit.shader_obj);
+NULL, >r600_blit.shader_obj);
if (r) {
DRM_ERROR("r600 failed to allocate shader\n");
return r;
diff --git a/drivers/gpu/drm/radeon/radeon_benchmark.c 
b/drivers/gpu/drm/radeon/radeon_benchmark.c
index fef7b72..364f5b1 100644
--- a/drivers/gpu/drm/radeon/radeon_benchmark.c
+++ b/drivers/gpu/drm/radeon/radeon_benchmark.c
@@ -103,7 +103,7 @@ static void radeon_benchmark_move(struct radeon_device 
*rdev, unsigned size,
int time;

n = RADEON_BENCHMARK_ITERATIONS;
-   r = radeon_bo_create(rdev, size, PAGE_SIZE, true, sdomain, );
+   

[Bug 49747] dpms on only works on DP0 on a hd5700

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=49747

--- Comment #6 from Daniel Vetter  2012-05-10 11:29:57 PDT 
---
On Thu, May 10, 2012 at 8:18 PM,   wrote:
> --- Comment #5 from Alex Deucher  2012-05-10 11:18:49 PDT 
> ---
> Is the failure only after a dpms cycle or does the second DP monitor not light
> up at all? ?If the former, are there any driver messages in dmesg when after a
> failed dpms cycle?

The driver correctly lights up the display on DP1 after boot, it only
fails after the first dpms off. The dmesg/xrandr is after I've done a
dpms cycle, i.e. black DP1 output. So nothing in there.

Should I regrab dmesg after a dpms cycle with more verbose logging?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 49747] dpms on only works on DP0 on a hd5700

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=49747

--- Comment #5 from Alex Deucher  2012-05-10 11:18:49 PDT 
---
Is the failure only after a dpms cycle or does the second DP monitor not light
up at all?  If the former, are there any driver messages in dmesg when after a
failed dpms cycle?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 49747] dpms on only works on DP0 on a hd5700

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=49747

--- Comment #4 from Daniel Vetter  2012-05-10 11:01:16 PDT 
---
Created attachment 61381
  --> https://bugs.freedesktop.org/attachment.cgi?id=61381
Xorg.log

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 49747] dpms on only works on DP0 on a hd5700

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=49747

Daniel Vetter  changed:

   What|Removed |Added

  Attachment #61379|text/x-log  |text/plain
  mime type||

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 49747] dpms on only works on DP0 on a hd5700

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=49747

Daniel Vetter  changed:

   What|Removed |Added

  Attachment #61380|text/x-log  |text/plain
  mime type||

--- Comment #3 from Daniel Vetter  2012-05-10 10:59:21 PDT 
---
Comment on attachment 61380
  --> https://bugs.freedesktop.org/attachment.cgi?id=61380
xrandr --verbose

>Screen 0: minimum 320 x 200, current 3840 x 1200, maximum 8192 x 8192
>DisplayPort-0 connected 1920x1200+0+0 (0x5a) normal (normal left inverted 
>right x axis y axis) 546mm x 352mm
>   Identifier: 0x55
>   Timestamp:  33295
>   Subpixel:   horizontal rgb
>   Gamma:  1.0:1.0:1.0
>   Brightness: 1.0
>   Clones:
>   CRTC:   0
>   CRTCs:  0 1 2 3 4 5
>   Transform:  1.00 0.00 0.00
>   0.00 1.00 0.00
>   0.00 0.00 1.00
>  filter: 
>   EDID:
>   000022f0f92601010101
>   0b130104a5362378eece50a3544c9926
>   0f5054a56b808140a900a940b300d100
>   010101010101283c80a070b023403020
>   36002260211a00fc00485020
>   4c5032343735770a202000fd0030
>   551e5e15041150d2f858f0ff
>   00435a43393131303039340a202000c2
>   underscan vborder: 0 (0x)   range:  (0,128)
>   underscan hborder: 0 (0x)   range:  (0,128)
>   underscan:  off
>   supported: off  on   auto
>   coherent: 1 (0x0001)range:  (0,1)
>  1920x1200 (0x5a)  154.0MHz +HSync -VSync *current +preferred
>h: width  1920 start 1968 end 2000 total 2080 skew0 clock   74.0KHz
>v: height 1200 start 1203 end 1209 total 1235   clock   60.0Hz
>  1600x1200 (0x5b)  202.5MHz +HSync +VSync
>h: width  1600 start 1664 end 1856 total 2160 skew0 clock   93.8KHz
>v: height 1200 start 1201 end 1204 total 1250   clock   75.0Hz
>  1600x1200 (0x5c)  189.0MHz +HSync +VSync
>h: width  1600 start 1664 end 1856 total 2160 skew0 clock   87.5KHz
>v: height 1200 start 1201 end 1204 total 1250   clock   70.0Hz
>  1600x1200 (0x5d)  175.5MHz +HSync +VSync
>h: width  1600 start 1664 end 1856 total 2160 skew0 clock   81.2KHz
>v: height 1200 start 1201 end 1204 total 1250   clock   65.0Hz
>  1600x1200 (0x5e)  162.0MHz +HSync +VSync
>h: width  1600 start 1664 end 1856 total 2160 skew0 clock   75.0KHz
>v: height 1200 start 1201 end 1204 total 1250   clock   60.0Hz
>  1680x1050 (0x5f)  187.0MHz -HSync +VSync
>h: width  1680 start 1800 end 1976 total 2272 skew0 clock   82.3KHz
>v: height 1050 start 1053 end 1059 total 1099   clock   74.9Hz
>  1680x1050 (0x60)  146.2MHz -HSync +VSync
>h: width  1680 start 1784 end 1960 total 2240 skew0 clock   65.3KHz
>v: height 1050 start 1053 end 1059 total 1089   clock   60.0Hz
>  1680x1050 (0x61)  119.0MHz +HSync -VSync
>h: width  1680 start 1728 end 1760 total 1840 skew0 clock   64.7KHz
>v: height 1050 start 1053 end 1059 total 1080   clock   59.9Hz
>  1600x1000 (0x62)  133.2MHz -HSync +VSync
>h: width  1600 start 1704 end 1872 total 2144 skew0 clock   62.1KHz
>v: height 1000 start 1001 end 1004 total 1035   clock   60.0Hz
>  1680x945 (0x63)  107.2MHz +HSync -VSync
>h: width  1680 start 1728 end 1760 total 1840 skew0 clock   58.3KHz
>v: height  945 start  948 end  953 total  972   clock   60.0Hz
>  1400x1050 (0x64)  179.5MHz -HSync +VSync
>h: width  1400 start 1504 end 1656 total 1912 skew0 clock   93.9KHz
>v: height 1050 start 1053 end 1057 total 1105   clock   85.0Hz
>  1400x1050 (0x65)  156.0MHz -HSync +VSync
>h: width  1400 start 1504 end 1648 total 1896 skew0 clock   82.3KHz
>v: height 1050 start 1053 end 1057 total 1099   clock   74.9Hz
>  1400x1050 (0x66)  121.8MHz -HSync +VSync
>h: width  1400 start 1488 end 1632 total 1864 skew0 clock   65.3KHz
>v: height 1050 start 1053 end 1057 total 1089   clock   60.0Hz
>  1400x1050 (0x67)  101.0MHz +HSync -VSync
>h: width  1400 start 1448 end 1480 total 1560 skew0 clock   64.7KHz
>v: height 1050 start 1053 end 1057 total 1080   clock   59.9Hz
>  1600x900 (0x68)   97.5MHz +HSync -VSync
>h: width  1600 start 1648 end 1680 total 1760 skew0 clock   55.4KHz
>v: height  900 start  903 end  908 total  926   clock   59.8Hz
>  1280x1024 (0x69)  157.5MHz +HSync +VSync
>h: width  1280 start 1344 end 1504 total 1728 skew0 clock   91.1KHz
>v: height 1024 start 1025 end 

[Bug 49747] dpms on only works on DP0 on a hd5700

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=49747

--- Comment #2 from Daniel Vetter  2012-05-10 10:58:57 PDT 
---
Created attachment 61380
  --> https://bugs.freedesktop.org/attachment.cgi?id=61380
xrandr --verbose

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH libdrm] radeon: Add new R600 PCI ids for surface manager

[Anisse Astier]

This is the same list of PCI ids added by Alex Deucher in xf86-video-ati commit
aacbd629b02cbee3f9e6a0ee452b4e3f21376bd3.

This is needed since the addition of the surface allocator helper in
commit c51f7f0e460dcadb9f1a56ecf1615810877c33c8 ; it needs to differentiate
pre and post-R600 GPUs.
Therefore we should maintain another PCI id list.

Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=48138
Signed-off-by: Anisse Astier 
---
 radeon/r600_pci_ids.h |   10 ++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/radeon/r600_pci_ids.h b/radeon/r600_pci_ids.h
index 8fbd749..360c73d 100644
--- a/radeon/r600_pci_ids.h
+++ b/radeon/r600_pci_ids.h
@@ -152,6 +152,7 @@ CHIPSET(0x68F1, CEDAR_68F1, CEDAR)
 CHIPSET(0x68F2, CEDAR_68F2, CEDAR)
 CHIPSET(0x68F8, CEDAR_68F8, CEDAR)
 CHIPSET(0x68F9, CEDAR_68F9, CEDAR)
+CHIPSET(0x68FA, CEDAR_68FA, CEDAR)
 CHIPSET(0x68FE, CEDAR_68FE, CEDAR)

 CHIPSET(0x68C0, REDWOOD_68C0, REDWOOD)
@@ -192,6 +193,8 @@ CHIPSET(0x9804, PALM_9804, PALM)
 CHIPSET(0x9805, PALM_9805, PALM)
 CHIPSET(0x9806, PALM_9806, PALM)
 CHIPSET(0x9807, PALM_9807, PALM)
+CHIPSET(0x9808, PALM_9808, PALM)
+CHIPSET(0x9809, PALM_9809, PALM)

 CHIPSET(0x9640, SUMO_9640,  SUMO)
 CHIPSET(0x9641, SUMO_9641,  SUMO)
@@ -202,6 +205,8 @@ CHIPSET(0x9645, SUMO2_9645, SUMO2)
 CHIPSET(0x9647, SUMO_9647,  SUMO)
 CHIPSET(0x9648, SUMO_9648,  SUMO)
 CHIPSET(0x964a, SUMO_964A,  SUMO)
+CHIPSET(0x964b, SUMO_964B,  SUMO)
+CHIPSET(0x964c, SUMO_964C,  SUMO)
 CHIPSET(0x964e, SUMO_964E,  SUMO)
 CHIPSET(0x964f, SUMO_964F,  SUMO)

@@ -245,8 +250,11 @@ CHIPSET(0x6747, TURKS_6747, TURKS)
 CHIPSET(0x6748, TURKS_6748, TURKS)
 CHIPSET(0x6749, TURKS_6749, TURKS)
 CHIPSET(0x6750, TURKS_6750, TURKS)
+CHIPSET(0x6751, TURKS_6751, TURKS)
 CHIPSET(0x6758, TURKS_6758, TURKS)
 CHIPSET(0x6759, TURKS_6759, TURKS)
+CHIPSET(0x675B, TURKS_675B, TURKS)
+CHIPSET(0x675D, TURKS_675D, TURKS)
 CHIPSET(0x675F, TURKS_675F, TURKS)
 CHIPSET(0x6840, TURKS_6840, TURKS)
 CHIPSET(0x6841, TURKS_6841, TURKS)
@@ -267,8 +275,10 @@ CHIPSET(0x6766, CAICOS_6766, CAICOS)
 CHIPSET(0x6767, CAICOS_6767, CAICOS)
 CHIPSET(0x6768, CAICOS_6768, CAICOS)
 CHIPSET(0x6770, CAICOS_6770, CAICOS)
+CHIPSET(0x6772, CAICOS_6772, CAICOS)
 CHIPSET(0x6778, CAICOS_6778, CAICOS)
 CHIPSET(0x6779, CAICOS_6779, CAICOS)
+CHIPSET(0x677B, CAICOS_677B, CAICOS)

 CHIPSET(0x9900, ARUBA_9900, ARUBA)
 CHIPSET(0x9901, ARUBA_9901, ARUBA)
-- 
1.7.9

[PATCH 2/2 v3] drm/exynos: added userptr feature.

[Inki Dae]

> -Original Message-
> From: Minchan Kim [mailto:minchan at kernel.org]
> Sent: Thursday, May 10, 2012 5:11 PM
> To: InKi Dae
> Cc: Inki Dae; Jerome Glisse; airlied at linux.ie; dri-
> devel at lists.freedesktop.org; kyungmin.park at samsung.com;
> sw0312.kim at samsung.com; linux-mm at kvack.org
> Subject: Re: [PATCH 2/2 v3] drm/exynos: added userptr feature.
> 
> On 05/10/2012 04:59 PM, InKi Dae wrote:
> 
> > 2012/5/10, Minchan Kim :
> >> On 05/10/2012 03:57 PM, Inki Dae wrote:
> >>
> >>>
> >>>
>  -Original Message-
>  From: Minchan Kim [mailto:minchan at kernel.org]
>  Sent: Thursday, May 10, 2012 1:58 PM
>  To: Inki Dae
>  Cc: 'Jerome Glisse'; airlied at linux.ie; dri-
> devel at lists.freedesktop.org;
>  kyungmin.park at samsung.com; sw0312.kim at samsung.com; linux-mm at 
>  kvack.org
>  Subject: Re: [PATCH 2/2 v3] drm/exynos: added userptr feature.
> 
>  On 05/10/2012 10:39 AM, Inki Dae wrote:
> 
> > Hi Jerome,
> >
> >> -Original Message-
> >> From: Jerome Glisse [mailto:j.glisse at gmail.com]
> >> Sent: Wednesday, May 09, 2012 11:46 PM
> >> To: Inki Dae
> >> Cc: airlied at linux.ie; dri-devel at lists.freedesktop.org;
> >> kyungmin.park at samsung.com; sw0312.kim at samsung.com; linux-
> mm at kvack.org
> >> Subject: Re: [PATCH 2/2 v3] drm/exynos: added userptr feature.
> >>
> >> On Wed, May 9, 2012 at 2:17 AM, Inki Dae 
> wrote:
> >>> this feature is used to import user space region allocated by
> >>> malloc()
> >> or
> >>> mmaped into a gem. and to guarantee the pages to user space not to
> be
> >>> swapped out, the VMAs within the user space would be locked and
> then
> >> unlocked
> >>> when the pages are released.
> >>>
> >>> but this lock might result in significant degradation of system
> >> performance
> >>> because the pages couldn't be swapped out so we limit user-desired
> >> userptr
> >>> size to pre-defined.
> >>>
> >>> Signed-off-by: Inki Dae 
> >>> Signed-off-by: Kyungmin Park 
> >>
> >>
> >> Again i would like feedback from mm people (adding cc). I am not
> sure
> >
> > Thank you, I missed adding mm as cc.
> >
> >> locking the vma is the right anwser as i said in my previous mail,
> >> userspace can munlock it in your back, maybe VM_RESERVED is better.
> >
> > I know that with VM_RESERVED flag, also we can avoid the pages from
>  being
> > swapped out. but these pages should be unlocked anytime we want
> because
>  we
> > could allocate all pages on system and lock them, which in turn, it
> may
> > result in significant deterioration of system performance.(maybe
> other
> > processes requesting free memory would be blocked) so I used
> VM_LOCKED
>  flags
> > instead. but I'm not sure this way is best also.
> >
> >> Anyway even not considering that you don't check at all that
> process
> >> don't go over the limit of locked page see mm/mlock.c
> RLIMIT_MEMLOCK
> >
> > Thank you for your advices.
> >
> >> for how it's done. Also you mlock complete vma but the userptr you
> get
> >> might be inside say 16M vma and you only care about 1M of userptr,
> if
> >> you mark the whole vma as locked than anytime a new page is fault
> in
> >> the vma else where than in the buffer you are interested then it
> got
> >> allocated for ever until the gem buffer is destroy, i am not sure
> of
> >> what happen to the vma on next malloc if it grows or not (i would
> >> think it won't grow at it would have different flags than new
> >> anonymous memory).
> 
> 
>  I don't know history in detail because you didn't have sent full
> patches
>  to linux-mm and
>  I didn't read the below code, either.
>  Just read your description and reply of Jerome. Apparently, there is
>  something I missed.
> 
>  Your goal is to avoid swap out some user pages which is used in
> kernel
>  at
>  the same time. Right?
>  Let's use get_user_pages. Is there any issue you can't use it?
>  It increases page count so reclaimer can't swap out page.
>  Isn't it enough?
>  Marking whole VMA into MLCOKED is overkill.
> 
> >>>
> >>> As I mentioned, we are already using get_user_pages. as you said, this
> >>> function increases page count but just only things to the user address
> >>> space
> >>> cpu already accessed. other would be allocated by page fault hander
> once
> >>> get_user_pages call. if so... ok, after that refcount(page->_count) of
> >>> the
> >>
> >>
> >> Not true. Look __get_user_pages.
> >> It handles case you mentioned by handle_mm_fault.
> >> Do I miss something?
> >>
> >
> > 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 

[PATCH 2/2 v3] drm/exynos: added userptr feature.

[Daniel Vetter]

On Thu, May 10, 2012 at 11:05:07AM -0400, Jerome Glisse wrote:
> On Wed, May 9, 2012 at 10:44 PM, Inki Dae  wrote:
> > Hi Jerome,
> >
> > Thank you again.
> >
> >> -Original Message-
> >> From: Jerome Glisse [mailto:j.glisse at gmail.com]
> >> Sent: Thursday, May 10, 2012 3:33 AM
> >> To: Inki Dae
> >> Cc: airlied at linux.ie; dri-devel at lists.freedesktop.org;
> >> kyungmin.park at samsung.com; sw0312.kim at samsung.com; linux-mm at 
> >> kvack.org
> >> Subject: Re: [PATCH 2/2 v3] drm/exynos: added userptr feature.
> >>
> >> On Wed, May 9, 2012 at 10:45 AM, Jerome Glisse  
> >> wrote:
> >> > On Wed, May 9, 2012 at 2:17 AM, Inki Dae  wrote:
> >> >> this feature is used to import user space region allocated by malloc()
> >> or
> >> >> mmaped into a gem. and to guarantee the pages to user space not to be
> >> >> swapped out, the VMAs within the user space would be locked and then
> >> unlocked
> >> >> when the pages are released.
> >> >>
> >> >> but this lock might result in significant degradation of system
> >> performance
> >> >> because the pages couldn't be swapped out so we limit user-desired
> >> userptr
> >> >> size to pre-defined.
> >> >>
> >> >> Signed-off-by: Inki Dae 
> >> >> Signed-off-by: Kyungmin Park 
> >> >
> >> >
> >> > Again i would like feedback from mm people (adding cc). I am not sure
> >> > locking the vma is the right anwser as i said in my previous mail,
> >> > userspace can munlock it in your back, maybe VM_RESERVED is better.
> >> > Anyway even not considering that you don't check at all that process
> >> > don't go over the limit of locked page see mm/mlock.c RLIMIT_MEMLOCK
> >> > for how it's done. Also you mlock complete vma but the userptr you get
> >> > might be inside say 16M vma and you only care about 1M of userptr, if
> >> > you mark the whole vma as locked than anytime a new page is fault in
> >> > the vma else where than in the buffer you are interested then it got
> >> > allocated for ever until the gem buffer is destroy, i am not sure of
> >> > what happen to the vma on next malloc if it grows or not (i would
> >> > think it won't grow at it would have different flags than new
> >> > anonymous memory).
> >> >
> >> > The whole business of directly using malloced memory for gpu is fishy
> >> > and i would really like to get it right rather than relying on never
> >> > hitting strange things like page migration, vma merging, or worse
> >> > things like over locking pages and stealing memory.
> >> >
> >> > Cheers,
> >> > Jerome
> >>
> >> I had a lengthy discussion with mm people (thx a lot for that). I
> >> think we should split 2 different use case. The zero-copy upload case
> >> ie :
> >> app:
> >> ? ? ptr = malloc()
> >> ? ? ...
> >> ? ? glTex/VBO/UBO/...(ptr)
> >> ? ? free(ptr) or reuse it for other things
> >> For which i guess you want to avoid having to do a memcpy inside the
> >> gl library (could be anything else than gl that have same useage
> >> pattern).
> >>
> >
> > Right, in this case, we are using the userptr feature as pixman and evas
> > backend to use 2d accelerator.
> >
> >> ie after the upload happen you don't care about those page they can
> >> removed from the vma or marked as cow so that anything messing with
> >> those page after the upload won't change what you uploaded. Of course
> >
> > I'm not sure that I understood your mentions but could the pages be removed
> > from vma with VM_LOCKED or VM_RESERVED? once glTex/VBO/UBO/..., the VMAs to
> > user space would be locked. if cpu accessed significant part of all the
> > pages in user mode then pages to the part would be allocated by page fault
> > handler, after that, through userptr, the VMAs to user address space would
> > be locked(at this time, the remaining pages would be allocated also by
> > get_user_pages by calling page fault handler) I'd be glad to give me any
> > comments and advices if there is my missing point.
> >
> >> this is assuming that the tlb cost of doing such thing is smaller than
> >> the cost of memcpy the data.
> >>
> >
> > yes, in our test case, the tlb cost(incurred by tlb miss) was smaller than
> > the cost of memcpy also cpu usage. of course, this would be depended on gpu
> > performance.
> >
> >> Two way to do that, either you assume app can't not read back data
> >> after gl can and you do an unmap_mapping_range (make sure you only
> >> unmap fully covered page and that you copy non fully covered page) or
> >> you want to allow userspace to still read data or possibly overwrite
> >> them
> >>
> >> Second use case is something more like for the opencl case of
> >> CL_MEM_USE_HOST_PTR, in which you want to use the same page in the gpu
> >> and keep the userspace vma pointing to those page. I think the
> >> agreement on this case is that there is no way right now to do it
> >> sanely inside linux kernel. mlocking will need proper accounting
> >> against rtlimit but this limit might be low. Also the fork case might
> >> be problematic.
> >>
> >> For the fork 

[Bug 41265] KMS does not work on Radeon HD6700M

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=41265

--- Comment #14 from Alex Deucher  2012-05-10 10:14:03 PDT 
---
(In reply to comment #13)
> The driver gets really confused with the PCI busid.
> 
> lspci reports the ID as 16, but the driver thinks it's on 22.

they are the same.  0x16 (hex) = 22 (decimal)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 41265] KMS does not work on Radeon HD6700M

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=41265

--- Comment #13 from Shiv Sikand  2012-05-10 10:11:47 PDT 
---
I have a very similar issue to gyhor.

The driver gets really confused with the PCI busid.

lspci reports the ID as 16, but the driver thinks it's on 22.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH 2/2 v3] drm/exynos: added userptr feature.

[Minchan Kim]

On 05/10/2012 04:59 PM, InKi Dae wrote:

> 2012/5/10, Minchan Kim :
>> On 05/10/2012 03:57 PM, Inki Dae wrote:
>>
>>>
>>>
 -Original Message-
 From: Minchan Kim [mailto:minchan at kernel.org]
 Sent: Thursday, May 10, 2012 1:58 PM
 To: Inki Dae
 Cc: 'Jerome Glisse'; airlied at linux.ie; dri-devel at 
 lists.freedesktop.org;
 kyungmin.park at samsung.com; sw0312.kim at samsung.com; linux-mm at 
 kvack.org
 Subject: Re: [PATCH 2/2 v3] drm/exynos: added userptr feature.

 On 05/10/2012 10:39 AM, Inki Dae wrote:

> Hi Jerome,
>
>> -Original Message-
>> From: Jerome Glisse [mailto:j.glisse at gmail.com]
>> Sent: Wednesday, May 09, 2012 11:46 PM
>> To: Inki Dae
>> Cc: airlied at linux.ie; dri-devel at lists.freedesktop.org;
>> kyungmin.park at samsung.com; sw0312.kim at samsung.com; linux-mm at 
>> kvack.org
>> Subject: Re: [PATCH 2/2 v3] drm/exynos: added userptr feature.
>>
>> On Wed, May 9, 2012 at 2:17 AM, Inki Dae  wrote:
>>> this feature is used to import user space region allocated by
>>> malloc()
>> or
>>> mmaped into a gem. and to guarantee the pages to user space not to be
>>> swapped out, the VMAs within the user space would be locked and then
>> unlocked
>>> when the pages are released.
>>>
>>> but this lock might result in significant degradation of system
>> performance
>>> because the pages couldn't be swapped out so we limit user-desired
>> userptr
>>> size to pre-defined.
>>>
>>> Signed-off-by: Inki Dae 
>>> Signed-off-by: Kyungmin Park 
>>
>>
>> Again i would like feedback from mm people (adding cc). I am not sure
>
> Thank you, I missed adding mm as cc.
>
>> locking the vma is the right anwser as i said in my previous mail,
>> userspace can munlock it in your back, maybe VM_RESERVED is better.
>
> I know that with VM_RESERVED flag, also we can avoid the pages from
 being
> swapped out. but these pages should be unlocked anytime we want because
 we
> could allocate all pages on system and lock them, which in turn, it may
> result in significant deterioration of system performance.(maybe other
> processes requesting free memory would be blocked) so I used VM_LOCKED
 flags
> instead. but I'm not sure this way is best also.
>
>> Anyway even not considering that you don't check at all that process
>> don't go over the limit of locked page see mm/mlock.c RLIMIT_MEMLOCK
>
> Thank you for your advices.
>
>> for how it's done. Also you mlock complete vma but the userptr you get
>> might be inside say 16M vma and you only care about 1M of userptr, if
>> you mark the whole vma as locked than anytime a new page is fault in
>> the vma else where than in the buffer you are interested then it got
>> allocated for ever until the gem buffer is destroy, i am not sure of
>> what happen to the vma on next malloc if it grows or not (i would
>> think it won't grow at it would have different flags than new
>> anonymous memory).


 I don't know history in detail because you didn't have sent full patches
 to linux-mm and
 I didn't read the below code, either.
 Just read your description and reply of Jerome. Apparently, there is
 something I missed.

 Your goal is to avoid swap out some user pages which is used in kernel
 at
 the same time. Right?
 Let's use get_user_pages. Is there any issue you can't use it?
 It increases page count so reclaimer can't swap out page.
 Isn't it enough?
 Marking whole VMA into MLCOKED is overkill.

>>>
>>> As I mentioned, we are already using get_user_pages. as you said, this
>>> function increases page count but just only things to the user address
>>> space
>>> cpu already accessed. other would be allocated by page fault hander once
>>> get_user_pages call. if so... ok, after that refcount(page->_count) of
>>> the
>>
>>
>> Not true. Look __get_user_pages.
>> It handles case you mentioned by handle_mm_fault.
>> Do I miss something?
>>
> 
> 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


Understood.

> and then in turn next process like swap in to fill physical frame number into 
> entry of the page faulted.


Sorry, I can't understand your point due to my poor English.
Could you rewrite it easiliy? :)

Thanks.

> of course,if user never access the buffer and requested userptr then

> handle_mm_fault would be called by __get_user_pages. please give me
> any comments if there is my missing point.
> 
> Thanks,
> Inki Dae
> 
> 
>>> pages user already accessed would have 2 

[PATCH 2/2 v3] drm/exynos: added userptr feature.

[InKi Dae]

2012/5/10, Minchan Kim :
> On 05/10/2012 03:57 PM, Inki Dae wrote:
>
>>
>>
>>> -Original Message-
>>> From: Minchan Kim [mailto:minchan at kernel.org]
>>> Sent: Thursday, May 10, 2012 1:58 PM
>>> To: Inki Dae
>>> Cc: 'Jerome Glisse'; airlied at linux.ie; dri-devel at 
>>> lists.freedesktop.org;
>>> kyungmin.park at samsung.com; sw0312.kim at samsung.com; linux-mm at 
>>> kvack.org
>>> Subject: Re: [PATCH 2/2 v3] drm/exynos: added userptr feature.
>>>
>>> On 05/10/2012 10:39 AM, Inki Dae wrote:
>>>
 Hi Jerome,

> -Original Message-
> From: Jerome Glisse [mailto:j.glisse at gmail.com]
> Sent: Wednesday, May 09, 2012 11:46 PM
> To: Inki Dae
> Cc: airlied at linux.ie; dri-devel at lists.freedesktop.org;
> kyungmin.park at samsung.com; sw0312.kim at samsung.com; linux-mm at 
> kvack.org
> Subject: Re: [PATCH 2/2 v3] drm/exynos: added userptr feature.
>
> On Wed, May 9, 2012 at 2:17 AM, Inki Dae  wrote:
>> this feature is used to import user space region allocated by
>> malloc()
> or
>> mmaped into a gem. and to guarantee the pages to user space not to be
>> swapped out, the VMAs within the user space would be locked and then
> unlocked
>> when the pages are released.
>>
>> but this lock might result in significant degradation of system
> performance
>> because the pages couldn't be swapped out so we limit user-desired
> userptr
>> size to pre-defined.
>>
>> Signed-off-by: Inki Dae 
>> Signed-off-by: Kyungmin Park 
>
>
> Again i would like feedback from mm people (adding cc). I am not sure

 Thank you, I missed adding mm as cc.

> locking the vma is the right anwser as i said in my previous mail,
> userspace can munlock it in your back, maybe VM_RESERVED is better.

 I know that with VM_RESERVED flag, also we can avoid the pages from
>>> being
 swapped out. but these pages should be unlocked anytime we want because
>>> we
 could allocate all pages on system and lock them, which in turn, it may
 result in significant deterioration of system performance.(maybe other
 processes requesting free memory would be blocked) so I used VM_LOCKED
>>> flags
 instead. but I'm not sure this way is best also.

> Anyway even not considering that you don't check at all that process
> don't go over the limit of locked page see mm/mlock.c RLIMIT_MEMLOCK

 Thank you for your advices.

> for how it's done. Also you mlock complete vma but the userptr you get
> might be inside say 16M vma and you only care about 1M of userptr, if
> you mark the whole vma as locked than anytime a new page is fault in
> the vma else where than in the buffer you are interested then it got
> allocated for ever until the gem buffer is destroy, i am not sure of
> what happen to the vma on next malloc if it grows or not (i would
> think it won't grow at it would have different flags than new
> anonymous memory).
>>>
>>>
>>> I don't know history in detail because you didn't have sent full patches
>>> to linux-mm and
>>> I didn't read the below code, either.
>>> Just read your description and reply of Jerome. Apparently, there is
>>> something I missed.
>>>
>>> Your goal is to avoid swap out some user pages which is used in kernel
>>> at
>>> the same time. Right?
>>> Let's use get_user_pages. Is there any issue you can't use it?
>>> It increases page count so reclaimer can't swap out page.
>>> Isn't it enough?
>>> Marking whole VMA into MLCOKED is overkill.
>>>
>>
>> As I mentioned, we are already using get_user_pages. as you said, this
>> function increases page count but just only things to the user address
>> space
>> cpu already accessed. other would be allocated by page fault hander once
>> get_user_pages call. if so... ok, after that refcount(page->_count) of
>> the
>
>
> Not true. Look __get_user_pages.
> It handles case you mentioned by handle_mm_fault.
> Do I miss something?
>

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 and then in turn next process like swap in
to fill physical frame number into entry of the page faulted. of
course, if user never access the buffer and requested userptr then
handle_mm_fault would be called by __get_user_pages. please give me
any comments if there is my missing point.

Thanks,
Inki Dae


>> pages user already accessed would have 2 and just 1 for other all pages.
>> so
>> we may have to consider only pages never accessed by cpu to be locked to
>> avoid from swapped out.
>>
>> Thanks,
>> Inki Dae
>>
>>> --
>>> Kind regards,
>>> Minchan Kim
>>
>> --
>> To unsubscribe, send a message with 'unsubscribe linux-mm' in
>> the body to 

[PATCH 2/2 v3] drm/exynos: added userptr feature.

[Minchan Kim]

On 05/10/2012 04:56 PM, Minchan Kim wrote:

> On 05/10/2012 04:31 PM, Kyungmin Park wrote:
> 
>> On 5/10/12, Minchan Kim  wrote:
>>> On 05/10/2012 03:53 PM, KOSAKI Motohiro wrote:
>>>
 (5/10/12 12:58 AM), Minchan Kim wrote:
> On 05/10/2012 10:39 AM, Inki Dae wrote:
>
>> Hi Jerome,
>>
>>> -Original Message-
>>> From: Jerome Glisse [mailto:j.glisse at gmail.com]
>>> Sent: Wednesday, May 09, 2012 11:46 PM
>>> To: Inki Dae
>>> Cc: airlied at linux.ie; dri-devel at lists.freedesktop.org;
>>> kyungmin.park at samsung.com; sw0312.kim at samsung.com; linux-mm at 
>>> kvack.org
>>> Subject: Re: [PATCH 2/2 v3] drm/exynos: added userptr feature.
>>>
>>> On Wed, May 9, 2012 at 2:17 AM, Inki Dae  
>>> wrote:
 this feature is used to import user space region allocated by
 malloc()
>>> or
 mmaped into a gem. and to guarantee the pages to user space not to be
 swapped out, the VMAs within the user space would be locked and then
>>> unlocked
 when the pages are released.

 but this lock might result in significant degradation of system
>>> performance
 because the pages couldn't be swapped out so we limit user-desired
>>> userptr
 size to pre-defined.

 Signed-off-by: Inki Dae
 Signed-off-by: Kyungmin Park
>>>
>>>
>>> Again i would like feedback from mm people (adding cc). I am not sure
>>
>> Thank you, I missed adding mm as cc.
>>
>>> locking the vma is the right anwser as i said in my previous mail,
>>> userspace can munlock it in your back, maybe VM_RESERVED is better.
>>
>> I know that with VM_RESERVED flag, also we can avoid the pages from
>> being
>> swapped out. but these pages should be unlocked anytime we want
>> because we
>> could allocate all pages on system and lock them, which in turn, it may
>> result in significant deterioration of system performance.(maybe other
>> processes requesting free memory would be blocked) so I used
>> VM_LOCKED flags
>> instead. but I'm not sure this way is best also.
>>
>>> Anyway even not considering that you don't check at all that process
>>> don't go over the limit of locked page see mm/mlock.c RLIMIT_MEMLOCK
>>
>> Thank you for your advices.
>>
>>> for how it's done. Also you mlock complete vma but the userptr you get
>>> might be inside say 16M vma and you only care about 1M of userptr, if
>>> you mark the whole vma as locked than anytime a new page is fault in
>>> the vma else where than in the buffer you are interested then it got
>>> allocated for ever until the gem buffer is destroy, i am not sure of
>>> what happen to the vma on next malloc if it grows or not (i would
>>> think it won't grow at it would have different flags than new
>>> anonymous memory).
>
>
> I don't know history in detail because you didn't have sent full
> patches to linux-mm and
> I didn't read the below code, either.
> Just read your description and reply of Jerome. Apparently, there is
> something I missed.
>
> Your goal is to avoid swap out some user pages which is used in kernel
> at the same time. Right?
> Let's use get_user_pages. Is there any issue you can't use it?

 Maybe because get_user_pages() is fork unsafe? dunno.
>>>
>>>
>>> If there is such problem, I think user program should handle it by
>>> MADV_DONTFORK
>>> and make to allow write by only parent process.
>> Please read the original patches and discuss the root cause. Does it
>> harm to pass user space memory to kernel space and how to make is
>> possible at DRM?
> 
> 
> Where can I read original discussion history?
> I am not expert of DRAM so I can answer only mm stuff and it's why Jerome 
> ccing mm-list.

 ^^^ silly typo
 DRM

-- 
Kind regards,
Minchan Kim

[PATCH 2/2 v3] drm/exynos: added userptr feature.

[Minchan Kim]

On 05/10/2012 04:31 PM, Kyungmin Park wrote:

> On 5/10/12, Minchan Kim  wrote:
>> On 05/10/2012 03:53 PM, KOSAKI Motohiro wrote:
>>
>>> (5/10/12 12:58 AM), Minchan Kim wrote:
 On 05/10/2012 10:39 AM, Inki Dae wrote:

> Hi Jerome,
>
>> -Original Message-
>> From: Jerome Glisse [mailto:j.glisse at gmail.com]
>> Sent: Wednesday, May 09, 2012 11:46 PM
>> To: Inki Dae
>> Cc: airlied at linux.ie; dri-devel at lists.freedesktop.org;
>> kyungmin.park at samsung.com; sw0312.kim at samsung.com; linux-mm at 
>> kvack.org
>> Subject: Re: [PATCH 2/2 v3] drm/exynos: added userptr feature.
>>
>> On Wed, May 9, 2012 at 2:17 AM, Inki Dae  wrote:
>>> this feature is used to import user space region allocated by
>>> malloc()
>> or
>>> mmaped into a gem. and to guarantee the pages to user space not to be
>>> swapped out, the VMAs within the user space would be locked and then
>> unlocked
>>> when the pages are released.
>>>
>>> but this lock might result in significant degradation of system
>> performance
>>> because the pages couldn't be swapped out so we limit user-desired
>> userptr
>>> size to pre-defined.
>>>
>>> Signed-off-by: Inki Dae
>>> Signed-off-by: Kyungmin Park
>>
>>
>> Again i would like feedback from mm people (adding cc). I am not sure
>
> Thank you, I missed adding mm as cc.
>
>> locking the vma is the right anwser as i said in my previous mail,
>> userspace can munlock it in your back, maybe VM_RESERVED is better.
>
> I know that with VM_RESERVED flag, also we can avoid the pages from
> being
> swapped out. but these pages should be unlocked anytime we want
> because we
> could allocate all pages on system and lock them, which in turn, it may
> result in significant deterioration of system performance.(maybe other
> processes requesting free memory would be blocked) so I used
> VM_LOCKED flags
> instead. but I'm not sure this way is best also.
>
>> Anyway even not considering that you don't check at all that process
>> don't go over the limit of locked page see mm/mlock.c RLIMIT_MEMLOCK
>
> Thank you for your advices.
>
>> for how it's done. Also you mlock complete vma but the userptr you get
>> might be inside say 16M vma and you only care about 1M of userptr, if
>> you mark the whole vma as locked than anytime a new page is fault in
>> the vma else where than in the buffer you are interested then it got
>> allocated for ever until the gem buffer is destroy, i am not sure of
>> what happen to the vma on next malloc if it grows or not (i would
>> think it won't grow at it would have different flags than new
>> anonymous memory).


 I don't know history in detail because you didn't have sent full
 patches to linux-mm and
 I didn't read the below code, either.
 Just read your description and reply of Jerome. Apparently, there is
 something I missed.

 Your goal is to avoid swap out some user pages which is used in kernel
 at the same time. Right?
 Let's use get_user_pages. Is there any issue you can't use it?
>>>
>>> Maybe because get_user_pages() is fork unsafe? dunno.
>>
>>
>> If there is such problem, I think user program should handle it by
>> MADV_DONTFORK
>> and make to allow write by only parent process.
> Please read the original patches and discuss the root cause. Does it
> harm to pass user space memory to kernel space and how to make is
> possible at DRM?


Where can I read original discussion history?
I am not expert of DRAM so I can answer only mm stuff and it's why Jerome ccing 
mm-list.
About mm stuff, I think it's no harm for kernel to use user space memory if it 
uses carefully.
If you are saying about permission, at least, DRM code can check it by 
can_do_mlock and checking lock_limit.
If you are saying another security, I'm not right person to discuss it.
please Ccing security at kernel.org.

Thanks.

> 
> Thank you,
> Kyungmin Park
>>
>> --
>> Kind regards,
>> Minchan Kim
>>
>> --
>> To unsubscribe, send a message with 'unsubscribe linux-mm' in
>> the body to majordomo at kvack.org.  For more info on Linux MM,
>> see: http://www.linux-mm.org/ .
>> Fight unfair telecom internet charges in Canada: sign
>> http://stopthemeter.ca/
>> Don't email: mailto:"dont at kvack.org"> email at kvack.org 
>>
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo at kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
> Don't email: mailto:"dont at kvack.org"> email at kvack.org 
> 



-- 
Kind regards,
Minchan Kim

[PATCH] drm/exynos: Include missing linux/types.h in header

[Emil Goode]

Include the linux/types.h file where used types are declared.

Sparse gives the following warning:
/usr/include/drm/exynos_drm.h:92:
found __[us]{8,16,32,64} type without
#include 

Signed-off-by: Emil Goode 
---
 include/drm/exynos_drm.h |2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/drm/exynos_drm.h b/include/drm/exynos_drm.h
index e478de4..7eb7ae7 100644
--- a/include/drm/exynos_drm.h
+++ b/include/drm/exynos_drm.h
@@ -29,6 +29,8 @@
 #ifndef _EXYNOS_DRM_H_
 #define _EXYNOS_DRM_H_

+#include 
+
 /**
  * User-desired buffer creation information structure.
  *
-- 
1.7.10

[PATCH 2/2 v3] drm/exynos: added userptr feature.

[Kyungmin Park]

On 5/10/12, Minchan Kim  wrote:
> On 05/10/2012 03:53 PM, KOSAKI Motohiro wrote:
>
>> (5/10/12 12:58 AM), Minchan Kim wrote:
>>> On 05/10/2012 10:39 AM, Inki Dae wrote:
>>>
 Hi Jerome,

> -Original Message-
> From: Jerome Glisse [mailto:j.glisse at gmail.com]
> Sent: Wednesday, May 09, 2012 11:46 PM
> To: Inki Dae
> Cc: airlied at linux.ie; dri-devel at lists.freedesktop.org;
> kyungmin.park at samsung.com; sw0312.kim at samsung.com; linux-mm at 
> kvack.org
> Subject: Re: [PATCH 2/2 v3] drm/exynos: added userptr feature.
>
> On Wed, May 9, 2012 at 2:17 AM, Inki Dae  wrote:
>> this feature is used to import user space region allocated by
>> malloc()
> or
>> mmaped into a gem. and to guarantee the pages to user space not to be
>> swapped out, the VMAs within the user space would be locked and then
> unlocked
>> when the pages are released.
>>
>> but this lock might result in significant degradation of system
> performance
>> because the pages couldn't be swapped out so we limit user-desired
> userptr
>> size to pre-defined.
>>
>> Signed-off-by: Inki Dae
>> Signed-off-by: Kyungmin Park
>
>
> Again i would like feedback from mm people (adding cc). I am not sure

 Thank you, I missed adding mm as cc.

> locking the vma is the right anwser as i said in my previous mail,
> userspace can munlock it in your back, maybe VM_RESERVED is better.

 I know that with VM_RESERVED flag, also we can avoid the pages from
 being
 swapped out. but these pages should be unlocked anytime we want
 because we
 could allocate all pages on system and lock them, which in turn, it may
 result in significant deterioration of system performance.(maybe other
 processes requesting free memory would be blocked) so I used
 VM_LOCKED flags
 instead. but I'm not sure this way is best also.

> Anyway even not considering that you don't check at all that process
> don't go over the limit of locked page see mm/mlock.c RLIMIT_MEMLOCK

 Thank you for your advices.

> for how it's done. Also you mlock complete vma but the userptr you get
> might be inside say 16M vma and you only care about 1M of userptr, if
> you mark the whole vma as locked than anytime a new page is fault in
> the vma else where than in the buffer you are interested then it got
> allocated for ever until the gem buffer is destroy, i am not sure of
> what happen to the vma on next malloc if it grows or not (i would
> think it won't grow at it would have different flags than new
> anonymous memory).
>>>
>>>
>>> I don't know history in detail because you didn't have sent full
>>> patches to linux-mm and
>>> I didn't read the below code, either.
>>> Just read your description and reply of Jerome. Apparently, there is
>>> something I missed.
>>>
>>> Your goal is to avoid swap out some user pages which is used in kernel
>>> at the same time. Right?
>>> Let's use get_user_pages. Is there any issue you can't use it?
>>
>> Maybe because get_user_pages() is fork unsafe? dunno.
>
>
> If there is such problem, I think user program should handle it by
> MADV_DONTFORK
> and make to allow write by only parent process.
Please read the original patches and discuss the root cause. Does it
harm to pass user space memory to kernel space and how to make is
possible at DRM?

Thank you,
Kyungmin Park
>
> --
> Kind regards,
> Minchan Kim
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo at kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Fight unfair telecom internet charges in Canada: sign
> http://stopthemeter.ca/
> Don't email: mailto:"dont at kvack.org"> email at kvack.org 
>

[patch] gma500: silence an unused variable warning

[Alan Cox]

On Thu, 10 May 2012 10:33:02 +0300
Dan Carpenter  wrote:

> If CONFIG_BACKLIGHT_CLASS_DEVICE is disabled then GCC warns that:
>   drivers/gpu/drm/gma500/opregion.c:154:6: warning:
>   unused variable ?max? [-Wunused-variable]
> 
> Which give me a chance to use the new config_enabled() macro.  :)
> 
> Signed-off-by: Dan Carpenter 

Acked-by: Alan Cox 

[PATCH 2/2 v3] drm/exynos: added userptr feature.

[Minchan Kim]

On 05/10/2012 03:53 PM, KOSAKI Motohiro wrote:

> (5/10/12 12:58 AM), Minchan Kim wrote:
>> On 05/10/2012 10:39 AM, Inki Dae wrote:
>>
>>> Hi Jerome,
>>>
 -Original Message-
 From: Jerome Glisse [mailto:j.glisse at gmail.com]
 Sent: Wednesday, May 09, 2012 11:46 PM
 To: Inki Dae
 Cc: airlied at linux.ie; dri-devel at lists.freedesktop.org;
 kyungmin.park at samsung.com; sw0312.kim at samsung.com; linux-mm at 
 kvack.org
 Subject: Re: [PATCH 2/2 v3] drm/exynos: added userptr feature.

 On Wed, May 9, 2012 at 2:17 AM, Inki Dae  wrote:
> this feature is used to import user space region allocated by malloc()
 or
> mmaped into a gem. and to guarantee the pages to user space not to be
> swapped out, the VMAs within the user space would be locked and then
 unlocked
> when the pages are released.
>
> but this lock might result in significant degradation of system
 performance
> because the pages couldn't be swapped out so we limit user-desired
 userptr
> size to pre-defined.
>
> Signed-off-by: Inki Dae
> Signed-off-by: Kyungmin Park


 Again i would like feedback from mm people (adding cc). I am not sure
>>>
>>> Thank you, I missed adding mm as cc.
>>>
 locking the vma is the right anwser as i said in my previous mail,
 userspace can munlock it in your back, maybe VM_RESERVED is better.
>>>
>>> I know that with VM_RESERVED flag, also we can avoid the pages from
>>> being
>>> swapped out. but these pages should be unlocked anytime we want
>>> because we
>>> could allocate all pages on system and lock them, which in turn, it may
>>> result in significant deterioration of system performance.(maybe other
>>> processes requesting free memory would be blocked) so I used
>>> VM_LOCKED flags
>>> instead. but I'm not sure this way is best also.
>>>
 Anyway even not considering that you don't check at all that process
 don't go over the limit of locked page see mm/mlock.c RLIMIT_MEMLOCK
>>>
>>> Thank you for your advices.
>>>
 for how it's done. Also you mlock complete vma but the userptr you get
 might be inside say 16M vma and you only care about 1M of userptr, if
 you mark the whole vma as locked than anytime a new page is fault in
 the vma else where than in the buffer you are interested then it got
 allocated for ever until the gem buffer is destroy, i am not sure of
 what happen to the vma on next malloc if it grows or not (i would
 think it won't grow at it would have different flags than new
 anonymous memory).
>>
>>
>> I don't know history in detail because you didn't have sent full
>> patches to linux-mm and
>> I didn't read the below code, either.
>> Just read your description and reply of Jerome. Apparently, there is
>> something I missed.
>>
>> Your goal is to avoid swap out some user pages which is used in kernel
>> at the same time. Right?
>> Let's use get_user_pages. Is there any issue you can't use it?
> 
> Maybe because get_user_pages() is fork unsafe? dunno.


If there is such problem, I think user program should handle it by 
MADV_DONTFORK 
and make to allow write by only parent process.

-- 
Kind regards,
Minchan Kim

[PATCH 2/2 v3] drm/exynos: added userptr feature.

[Minchan Kim]

On 05/10/2012 03:57 PM, Inki Dae wrote:

> 
> 
>> -Original Message-
>> From: Minchan Kim [mailto:minchan at kernel.org]
>> Sent: Thursday, May 10, 2012 1:58 PM
>> To: Inki Dae
>> Cc: 'Jerome Glisse'; airlied at linux.ie; dri-devel at lists.freedesktop.org;
>> kyungmin.park at samsung.com; sw0312.kim at samsung.com; linux-mm at 
>> kvack.org
>> Subject: Re: [PATCH 2/2 v3] drm/exynos: added userptr feature.
>>
>> On 05/10/2012 10:39 AM, Inki Dae wrote:
>>
>>> Hi Jerome,
>>>
 -Original Message-
 From: Jerome Glisse [mailto:j.glisse at gmail.com]
 Sent: Wednesday, May 09, 2012 11:46 PM
 To: Inki Dae
 Cc: airlied at linux.ie; dri-devel at lists.freedesktop.org;
 kyungmin.park at samsung.com; sw0312.kim at samsung.com; linux-mm at 
 kvack.org
 Subject: Re: [PATCH 2/2 v3] drm/exynos: added userptr feature.

 On Wed, May 9, 2012 at 2:17 AM, Inki Dae  wrote:
> this feature is used to import user space region allocated by malloc()
 or
> mmaped into a gem. and to guarantee the pages to user space not to be
> swapped out, the VMAs within the user space would be locked and then
 unlocked
> when the pages are released.
>
> but this lock might result in significant degradation of system
 performance
> because the pages couldn't be swapped out so we limit user-desired
 userptr
> size to pre-defined.
>
> Signed-off-by: Inki Dae 
> Signed-off-by: Kyungmin Park 


 Again i would like feedback from mm people (adding cc). I am not sure
>>>
>>> Thank you, I missed adding mm as cc.
>>>
 locking the vma is the right anwser as i said in my previous mail,
 userspace can munlock it in your back, maybe VM_RESERVED is better.
>>>
>>> I know that with VM_RESERVED flag, also we can avoid the pages from
>> being
>>> swapped out. but these pages should be unlocked anytime we want because
>> we
>>> could allocate all pages on system and lock them, which in turn, it may
>>> result in significant deterioration of system performance.(maybe other
>>> processes requesting free memory would be blocked) so I used VM_LOCKED
>> flags
>>> instead. but I'm not sure this way is best also.
>>>
 Anyway even not considering that you don't check at all that process
 don't go over the limit of locked page see mm/mlock.c RLIMIT_MEMLOCK
>>>
>>> Thank you for your advices.
>>>
 for how it's done. Also you mlock complete vma but the userptr you get
 might be inside say 16M vma and you only care about 1M of userptr, if
 you mark the whole vma as locked than anytime a new page is fault in
 the vma else where than in the buffer you are interested then it got
 allocated for ever until the gem buffer is destroy, i am not sure of
 what happen to the vma on next malloc if it grows or not (i would
 think it won't grow at it would have different flags than new
 anonymous memory).
>>
>>
>> I don't know history in detail because you didn't have sent full patches
>> to linux-mm and
>> I didn't read the below code, either.
>> Just read your description and reply of Jerome. Apparently, there is
>> something I missed.
>>
>> Your goal is to avoid swap out some user pages which is used in kernel at
>> the same time. Right?
>> Let's use get_user_pages. Is there any issue you can't use it?
>> It increases page count so reclaimer can't swap out page.
>> Isn't it enough?
>> Marking whole VMA into MLCOKED is overkill.
>>
> 
> As I mentioned, we are already using get_user_pages. as you said, this
> function increases page count but just only things to the user address space
> cpu already accessed. other would be allocated by page fault hander once
> get_user_pages call. if so... ok, after that refcount(page->_count) of the


Not true. Look __get_user_pages.
It handles case you mentioned by handle_mm_fault.
Do I miss something?

> pages user already accessed would have 2 and just 1 for other all pages. so
> we may have to consider only pages never accessed by cpu to be locked to
> avoid from swapped out.
> 
> Thanks,
> Inki Dae
> 
>> --
>> Kind regards,
>> Minchan Kim
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo at kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
> Don't email: mailto:"dont at kvack.org"> email at kvack.org 
> 



-- 
Kind regards,
Minchan Kim

[PATCH 2/2 v3] drm/exynos: added userptr feature.

[Inki Dae]

> -Original Message-
> From: Minchan Kim [mailto:minchan at kernel.org]
> Sent: Thursday, May 10, 2012 1:58 PM
> To: Inki Dae
> Cc: 'Jerome Glisse'; airlied at linux.ie; dri-devel at lists.freedesktop.org;
> kyungmin.park at samsung.com; sw0312.kim at samsung.com; linux-mm at kvack.org
> Subject: Re: [PATCH 2/2 v3] drm/exynos: added userptr feature.
> 
> On 05/10/2012 10:39 AM, Inki Dae wrote:
> 
> > Hi Jerome,
> >
> >> -Original Message-
> >> From: Jerome Glisse [mailto:j.glisse at gmail.com]
> >> Sent: Wednesday, May 09, 2012 11:46 PM
> >> To: Inki Dae
> >> Cc: airlied at linux.ie; dri-devel at lists.freedesktop.org;
> >> kyungmin.park at samsung.com; sw0312.kim at samsung.com; linux-mm at 
> >> kvack.org
> >> Subject: Re: [PATCH 2/2 v3] drm/exynos: added userptr feature.
> >>
> >> On Wed, May 9, 2012 at 2:17 AM, Inki Dae  wrote:
> >>> this feature is used to import user space region allocated by malloc()
> >> or
> >>> mmaped into a gem. and to guarantee the pages to user space not to be
> >>> swapped out, the VMAs within the user space would be locked and then
> >> unlocked
> >>> when the pages are released.
> >>>
> >>> but this lock might result in significant degradation of system
> >> performance
> >>> because the pages couldn't be swapped out so we limit user-desired
> >> userptr
> >>> size to pre-defined.
> >>>
> >>> Signed-off-by: Inki Dae 
> >>> Signed-off-by: Kyungmin Park 
> >>
> >>
> >> Again i would like feedback from mm people (adding cc). I am not sure
> >
> > Thank you, I missed adding mm as cc.
> >
> >> locking the vma is the right anwser as i said in my previous mail,
> >> userspace can munlock it in your back, maybe VM_RESERVED is better.
> >
> > I know that with VM_RESERVED flag, also we can avoid the pages from
> being
> > swapped out. but these pages should be unlocked anytime we want because
> we
> > could allocate all pages on system and lock them, which in turn, it may
> > result in significant deterioration of system performance.(maybe other
> > processes requesting free memory would be blocked) so I used VM_LOCKED
> flags
> > instead. but I'm not sure this way is best also.
> >
> >> Anyway even not considering that you don't check at all that process
> >> don't go over the limit of locked page see mm/mlock.c RLIMIT_MEMLOCK
> >
> > Thank you for your advices.
> >
> >> for how it's done. Also you mlock complete vma but the userptr you get
> >> might be inside say 16M vma and you only care about 1M of userptr, if
> >> you mark the whole vma as locked than anytime a new page is fault in
> >> the vma else where than in the buffer you are interested then it got
> >> allocated for ever until the gem buffer is destroy, i am not sure of
> >> what happen to the vma on next malloc if it grows or not (i would
> >> think it won't grow at it would have different flags than new
> >> anonymous memory).
> 
> 
> I don't know history in detail because you didn't have sent full patches
> to linux-mm and
> I didn't read the below code, either.
> Just read your description and reply of Jerome. Apparently, there is
> something I missed.
> 
> Your goal is to avoid swap out some user pages which is used in kernel at
> the same time. Right?
> Let's use get_user_pages. Is there any issue you can't use it?
> It increases page count so reclaimer can't swap out page.
> Isn't it enough?
> Marking whole VMA into MLCOKED is overkill.
> 

As I mentioned, we are already using get_user_pages. as you said, this
function increases page count but just only things to the user address space
cpu already accessed. other would be allocated by page fault hander once
get_user_pages call. if so... ok, after that refcount(page->_count) of the
pages user already accessed would have 2 and just 1 for other all pages. so
we may have to consider only pages never accessed by cpu to be locked to
avoid from swapped out.

Thanks,
Inki Dae

> --
> Kind regards,
> Minchan Kim

[PULL] drm-intel-next

[Daniel Vetter]

Hi Dave,

New drm-intel-next pull request.
Highlights:
- sparse fixes from Ben.
- tons of little cleanups from Chris all over: tiling_changed
  clarification, deferred_free list removal, ...
- fix up irq handler on gen2 & gen3 + related cleanups from Chris
- prep work for wait_rendering_timeout from Ben with some nice
  refactorings
- first set of infoframe fixes from Paulo for doubleclocked CEA modes
- improve pch pll handling from Jesse and Chris
- gpu hangman, this also contains the reset fix for gen4
- rps sanity check from Chris - this papers over issues when the gpu fails
  to clock up on snb/ivb, and it is shockingly easy to hit. The code
  prints a big WARN backtrace and restores the hw to a sane state. The
  real fix is still in the works.

Atm I'm aware of 2 regressions in -next:
- One of the gmbus patches (not gmbus itself) regressed lvds detection on
  a MacbookPro. I've analyzed the bug already and I think I know what's
  going on, patch is awaiting test feedback.
- Just today QA reported that DP on ilk regressed. That bug is fresh of
  the press and still awaiting detailed logfiles and the bisect result.
  The only thing that's clear atm is that -fixes works and -next doesn't.

Otherwise 3.5 merge is winding down, I am queueing up a few things though
that I'd like to still sneak in:
- More infoframe fixes from Paulo (most already queued into my tree).
- Final pieces of the first cut at hsw support from Eugeni - all the
  invasive pieces and code rework has landed already so not much harm
  there.
- I'm working on some backlight fixes I'd like to land in 3.5, but not yet
  all ready.

As discussed on irc this pull request is for the merged branch which
already resolves the conflicts with drm-next (due to the -rc6 backmerge).

Yours, Daniel

The following changes since commit 4f256e8aa3eda15c11c3cec3ec5336e1fc579cbd:

  Merge branch 'for-airlied' of git://people.freedesktop.org/~danvet/drm-intel 
into drm-core-next (2012-05-07 16:09:35 +0100)

are available in the git repository at:


  git://people.freedesktop.org/~danvet/drm-intel 
tags/drm-intel-next-2012-05-06-merged

for you to fetch changes up to 5e13a0c5ec05d382b488a691dfb8af015b1dea1e:

  Merge remote-tracking branch 'airlied/drm-core-next' into 
drm-intel-next-queued (2012-05-08 13:39:59 +0200)



Ben Widawsky (11):
  drm/i915: [sparse] __iomem fixes for opregion
  drm/i915: [sparse] __iomem fixes for overlay
  drm/i915: [sparse] __iomem fixes for gem
  drm/i915: remove do_retire from i915_wait_request
  drm/i915: move vbetool invoked ier stuff
  drm/i915: kill waiting_seqno
  drm/i915: drop polled waits from i915_wait_request
  drm/i915: extract __wait_seqno from i915_wait_request
  drm/i915: remove polled wait from throttle
  drm/i915: use __wait_seqno for ring throttle
  drm/i915: extract some common olr+wedge code

Chris Wilson (32):
  drm/i915/sprite: Avoid incurring extra vblank stall when updating plane 
on IVB
  drm/i915: Remove i915_gem_ringbuffer_(data|info) from debugfs
  drm/i915: Clarify the semantics of tiling_changed
  drm/i915: Only the zap the VMA after updating the tiling parameters
  drm/i915: i8xx interrupt handler
  drm/i915: Use a global lock for modifying global irq flags
  drm/i915: Remove too early plane enable on pre-PCH hardware
  drm/i915: Bump the inactive LRU on set-to-GTT-domain
  drm/i915: Remove i915_gem_evict_inactive()
  drm/i915: Remove the list of pinned inactive objects
  drm/i915: Remove the deferred-free list
  drm/i915: Split the stolen handling for GEM out of i915_dma.c
  drm/i915: Move GEM initialisation from i915_dma.c to i915_gem.c
  drm/i915: CR clock gating is recommend to be set on PineView
  drm/i915: Unconditionally initialise the interrupt workers
  drm/i915: Remove redundant initialisation of per-ring IRQ waitqueues
  drm/i915: pending_flip_is_done is gen3, name it so
  drm/i915: Duplicate and split the gen3/4 irq handler
  drm/i915: Clear FlipDone semantics change for pageflipping on gen3
  drm/i915: Remove gen3 irq code from gen4 irq routine
  drm/i915: Remove gen4 irq code from gen3 irq routine
  drm/i915: HWSTAM is only 16-bit on gen3
  drm/i915: Cleanup gen3 irq uninstall
  drm/i915: Handle PendingFlip on gen3 robustly
  drm/i915: Inline I915_INTERRUPT_ENABLE_FIX
  drm/i915: Remove unused and unloved vblank macros
  drm/i915: Remove unused ring->irq_seqno
  drm/i915: Only enable IPS polling for gen5
  drm/i915: Remove unused dev_priv->vblank_pipe
  drm/i915: Wait for the clocks to stabilise before updating PLLs
  drm/i915: Periodically sanity check power management
  drm/i915: Support pageflipping interrupts for all 3-pipes on IVB

Daniel Vetter (43):
  drm/i915: print computed bpp in dp link configuration
  drm/i915: [sparse] __iomem 

[PATCH] i915: add dmabuf/prime buffer sharing support.

[Daniel Vetter]

This adds handle->fd and fd->handle support to i915, this is to allow
for offloading of rendering in one direction and outputs in the other.

v2 from Daniel Vetter:
- fixup conflicts with the prepare/finish gtt prep work.
- implement ppgtt binding support.

Note that we have squat i-g-t testcoverage for any of the lifetime and
access rules dma_buf/prime support brings along. And there are quite a
few intricate situations here.

Also note that the integration with the existing code is a bit
hackish, especially around get_gtt_pages and put_gtt_pages. It imo
would be easier with the prep code from Chris Wilson's unbound series,
but that is for 3.6.

Also note that I didn't bother to put the new prepare/finish gtt hooks
to good use by moving the dma_buf_map/unmap_attachment calls in there
(like we've originally planned for).

Last but not least this patch is only compile-tested, but I've changed
very little compared to Dave Airlie's version. So there's a decent
chance v2 on drm-next works as well as v1 on 3.4-rc.

v3: Right when I've hit sent I've noticed that I've screwed up one
obj->sg_list (for dmar support) and obj->sg_table (for prime support)
disdinction. We should be able to merge these 2 paths, but that's
material for another patch.

Signed-off-by: Dave Airlie 
Signed-Off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/Makefile  |3 +-
 drivers/gpu/drm/i915/i915_drv.c|8 +-
 drivers/gpu/drm/i915/i915_drv.h|   11 +++
 drivers/gpu/drm/i915/i915_gem.c|   13 ++-
 drivers/gpu/drm/i915/i915_gem_dmabuf.c |  149 
 drivers/gpu/drm/i915/i915_gem_gtt.c|   15 +++-
 6 files changed, 193 insertions(+), 6 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_gem_dmabuf.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 8b8bbc7..7b7ecb8 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -37,7 +37,8 @@ i915-y := i915_drv.o i915_dma.o i915_irq.o \
  dvo_ch7017.o \
  dvo_ivch.o \
  dvo_tfp410.o \
- dvo_sil164.o
+ dvo_sil164.o \
+ i915_gem_dmabuf.o

 i915-$(CONFIG_COMPAT)   += i915_ioc32.o

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 1ccfc23..ac13c2c 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1034,7 +1034,7 @@ static struct drm_driver driver = {
 */
.driver_features =
DRIVER_USE_AGP | DRIVER_REQUIRE_AGP | /* DRIVER_USE_MTRR |*/
-   DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | DRIVER_GEM,
+   DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | DRIVER_GEM | DRIVER_PRIME,
.load = i915_driver_load,
.unload = i915_driver_unload,
.open = i915_driver_open,
@@ -1057,6 +1057,12 @@ static struct drm_driver driver = {
.gem_init_object = i915_gem_init_object,
.gem_free_object = i915_gem_free_object,
.gem_vm_ops = _gem_vm_ops,
+
+   .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
+   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
+   .gem_prime_export = i915_gem_prime_export,
+   .gem_prime_import = i915_gem_prime_import,
+
.dumb_create = i915_gem_dumb_create,
.dumb_map_offset = i915_gem_mmap_gtt,
.dumb_destroy = i915_gem_dumb_destroy,
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e03a4f8..751f25c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -935,6 +935,8 @@ struct drm_i915_gem_object {
struct scatterlist *sg_list;
int num_sg;

+   /* prime dma-buf support */
+   struct sg_table *sg_table;
/**
 * Used for performing relocations during execbuffer insertion.
 */
@@ -1240,6 +1242,8 @@ int __must_check i915_gem_object_unbind(struct 
drm_i915_gem_object *obj);
 void i915_gem_release_mmap(struct drm_i915_gem_object *obj);
 void i915_gem_lastclose(struct drm_device *dev);

+int i915_gem_object_get_pages_gtt(struct drm_i915_gem_object *obj,
+ gfp_t gfpmask);
 int __must_check i915_mutex_lock_interruptible(struct drm_device *dev);
 int __must_check i915_gem_object_wait_rendering(struct drm_i915_gem_object 
*obj);
 int i915_gem_object_sync(struct drm_i915_gem_object *obj,
@@ -1337,6 +1341,13 @@ i915_gem_get_unfenced_gtt_alignment(struct drm_device 
*dev,
 int i915_gem_object_set_cache_level(struct drm_i915_gem_object *obj,
enum i915_cache_level cache_level);

+struct drm_gem_object *i915_gem_prime_import(struct drm_device *dev,
+   struct dma_buf *dma_buf);
+
+struct dma_buf *i915_gem_prime_export(struct drm_device *dev,
+   struct drm_gem_object *gem_obj, int flags);
+
+
 /* i915_gem_gtt.c */
 int __must_check i915_gem_init_aliasing_ppgtt(struct drm_device *dev);
 void i915_gem_cleanup_aliasing_ppgtt(struct 

[Intel-gfx] [PATCH] i915: add dmabuf/prime buffer sharing support.

[Chris Wilson]

On Thu, 10 May 2012 15:11:15 +0200, Daniel Vetter  
wrote:
> From: Dave Airlie 
> 
> This adds handle->fd and fd->handle support to i915, this is to allow
> for offloading of rendering in one direction and outputs in the other.
> 
> v2 from Daniel Vetter:
> - fixup conflicts with the prepare/finish gtt prep work.
> - implement ppgtt binding support.
> 
> Note that we have squat i-g-t testcoverage for any of the lifetime and
> access rules dma_buf/prime support brings along. And there are quite a
> few intricate situations here.
> 
> Also note that the integration with the existing code is a bit
> hackish, especially around get_gtt_pages and put_gtt_pages. It imo
> would be easier with the prep code from Chris Wilson's unbound series,
> but that is for 3.6.
> 
> Also note that I didn't bother to put the new prepare/finish gtt hooks
> to good use by moving the dma_buf_map/unmap_attachment calls in there
> (like we've originally planned for).
> 
> Last but not least this patch is only compile-tested, but I've changed
> very little compared to Dave Airlie's version. So there's a decent
> chance v2 on drm-next works as well as v1 on 3.4-rc.
> 
> Signed-off-by: Dave Airlie 
> Signed-Off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/i915/Makefile  |3 +-
>  drivers/gpu/drm/i915/i915_drv.c|8 +-
>  drivers/gpu/drm/i915/i915_drv.h|   11 +++
>  drivers/gpu/drm/i915/i915_gem.c|   12 ++-
>  drivers/gpu/drm/i915/i915_gem_dmabuf.c |  149 
> 
>  drivers/gpu/drm/i915/i915_gem_gtt.c|   17 +++-
>  6 files changed, 193 insertions(+), 7 deletions(-)
>  create mode 100644 drivers/gpu/drm/i915/i915_gem_dmabuf.c
> 
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 8b8bbc7..7b7ecb8 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -37,7 +37,8 @@ i915-y := i915_drv.o i915_dma.o i915_irq.o \
> dvo_ch7017.o \
> dvo_ivch.o \
> dvo_tfp410.o \
> -   dvo_sil164.o
> +   dvo_sil164.o \
> +   i915_gem_dmabuf.o
>  
>  i915-$(CONFIG_COMPAT)   += i915_ioc32.o
>  
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 1ccfc23..ac13c2c 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1034,7 +1034,7 @@ static struct drm_driver driver = {
>*/
>   .driver_features =
>   DRIVER_USE_AGP | DRIVER_REQUIRE_AGP | /* DRIVER_USE_MTRR |*/
> - DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | DRIVER_GEM,
> + DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | DRIVER_GEM | DRIVER_PRIME,
>   .load = i915_driver_load,
>   .unload = i915_driver_unload,
>   .open = i915_driver_open,
> @@ -1057,6 +1057,12 @@ static struct drm_driver driver = {
>   .gem_init_object = i915_gem_init_object,
>   .gem_free_object = i915_gem_free_object,
>   .gem_vm_ops = _gem_vm_ops,
> +
> + .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> + .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> + .gem_prime_export = i915_gem_prime_export,
> + .gem_prime_import = i915_gem_prime_import,

Maybe a .gem_prime_ops = _gem_prime_ops.

> +
>   .dumb_create = i915_gem_dumb_create,
>   .dumb_map_offset = i915_gem_mmap_gtt,
>   .dumb_destroy = i915_gem_dumb_destroy,
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index e03a4f8..751f25c 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -935,6 +935,8 @@ struct drm_i915_gem_object {
>   struct scatterlist *sg_list;
>   int num_sg;
>  
> + /* prime dma-buf support */
> + struct sg_table *sg_table;

This looks like a kludge which with a little more work could integrate
neatly into the existing sg code without having to add aditional special
cases.

> +struct sg_table *i915_gem_map_dma_buf(struct dma_buf_attachment *attachment,
> +   enum dma_data_direction dir)
> +{
> + struct drm_i915_gem_object *obj = attachment->dmabuf->priv;
> + struct drm_device *dev = obj->base.dev;
> + int npages = obj->base.size / PAGE_SIZE;
> + struct sg_table *sg = NULL;
> + int ret;
> + int nents;
> +
> + ret = i915_mutex_lock_interruptible(dev);
> + if (ret)
> + return NULL;

Not impressed by the lack of error reporting through this interface.

> +struct drm_gem_object *i915_gem_prime_import(struct drm_device *dev,
> + struct dma_buf *dma_buf)
> +{
> + struct dma_buf_attachment *attach;
> + struct sg_table *sg;
> + struct drm_i915_gem_object *obj;
> + int npages;
> + int size;
> + int ret;
> +
> + /* is this one of own objects? */
> + if (dma_buf->ops == _dmabuf_ops) {
> + obj = dma_buf->priv;
> + /* is it from our device? */
> + if (obj->base.dev == dev) {
> + 

[PATCH 2/2 v3] drm/exynos: added userptr feature.

[Minchan Kim]

On 05/10/2012 10:39 AM, Inki Dae wrote:

> Hi Jerome,
> 
>> -Original Message-
>> From: Jerome Glisse [mailto:j.glisse at gmail.com]
>> Sent: Wednesday, May 09, 2012 11:46 PM
>> To: Inki Dae
>> Cc: airlied at linux.ie; dri-devel at lists.freedesktop.org;
>> kyungmin.park at samsung.com; sw0312.kim at samsung.com; linux-mm at 
>> kvack.org
>> Subject: Re: [PATCH 2/2 v3] drm/exynos: added userptr feature.
>>
>> On Wed, May 9, 2012 at 2:17 AM, Inki Dae  wrote:
>>> this feature is used to import user space region allocated by malloc()
>> or
>>> mmaped into a gem. and to guarantee the pages to user space not to be
>>> swapped out, the VMAs within the user space would be locked and then
>> unlocked
>>> when the pages are released.
>>>
>>> but this lock might result in significant degradation of system
>> performance
>>> because the pages couldn't be swapped out so we limit user-desired
>> userptr
>>> size to pre-defined.
>>>
>>> Signed-off-by: Inki Dae 
>>> Signed-off-by: Kyungmin Park 
>>
>>
>> Again i would like feedback from mm people (adding cc). I am not sure
> 
> Thank you, I missed adding mm as cc.
> 
>> locking the vma is the right anwser as i said in my previous mail,
>> userspace can munlock it in your back, maybe VM_RESERVED is better.
> 
> I know that with VM_RESERVED flag, also we can avoid the pages from being
> swapped out. but these pages should be unlocked anytime we want because we
> could allocate all pages on system and lock them, which in turn, it may
> result in significant deterioration of system performance.(maybe other
> processes requesting free memory would be blocked) so I used VM_LOCKED flags
> instead. but I'm not sure this way is best also.
> 
>> Anyway even not considering that you don't check at all that process
>> don't go over the limit of locked page see mm/mlock.c RLIMIT_MEMLOCK
> 
> Thank you for your advices.
> 
>> for how it's done. Also you mlock complete vma but the userptr you get
>> might be inside say 16M vma and you only care about 1M of userptr, if
>> you mark the whole vma as locked than anytime a new page is fault in
>> the vma else where than in the buffer you are interested then it got
>> allocated for ever until the gem buffer is destroy, i am not sure of
>> what happen to the vma on next malloc if it grows or not (i would
>> think it won't grow at it would have different flags than new
>> anonymous memory).


I don't know history in detail because you didn't have sent full patches to 
linux-mm and
I didn't read the below code, either.
Just read your description and reply of Jerome. Apparently, there is something 
I missed.

Your goal is to avoid swap out some user pages which is used in kernel at the 
same time. Right?
Let's use get_user_pages. Is there any issue you can't use it?
It increases page count so reclaimer can't swap out page.
Isn't it enough?
Marking whole VMA into MLCOKED is overkill.

-- 
Kind regards,
Minchan Kim

[PATCH 2/2 v3] drm/exynos: added userptr feature.

[KOSAKI Motohiro]

>>> 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
>>
>>
>> Understood.
>>
>>> and then in turn next process like swap in to fill physical frame number
>> into entry of the page faulted.
>>
>>
>> Sorry, I can't understand your point due to my poor English.
>> Could you rewrite it easiliy? :)
>>
>
> Simply saying, handle_mm_fault would be called to update pte after finding
> vma and checking access right. and as you know, there are many cases to
> process page fault such as COW or demand paging.

Hmm. If I understand correctly, you guys misunderstand mlock. it doesn't page 
pinning
nor prevent pfn change. It only guarantee to don't make swap out. e.g. memory 
campaction
feature may automatically change page physical address.

[PATCH 2/2] vga_switcheroo: Add the support for audio clients

[Takashi Iwai]

At Thu, 10 May 2012 11:40:50 +0100,
Dave Airlie wrote:
> 
> On Thu, May 10, 2012 at 8:10 AM, Takashi Iwai  wrote:
> > 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 explicity at registration time unlike
> > the video controller.
> 
> The only question I really have is how you assign the audio ids.
> 
> Currently we mostly don't see > 1 HDMI audio on a GPU, but that
> should be changing with the latest ones.

There is one HDMI audio "controller" entry usually per graphics.
There are more than one codecs can be connected to the controller,
e.g. Nvidia has up to 8 codecs, but this is an issue inside HD-audio
driver, and irrelevant from VGA-switcheroo.


thanks,

Takashi

[PATCH 2/2] vga_switcheroo: Add the support for audio clients

[Takashi Iwai]

At Thu, 10 May 2012 12:20:05 +0100,
Alan Cox wrote:
> 
> On Thu, 10 May 2012 09:10:16 +0200
> Takashi Iwai  wrote:
> 
> > 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 explicity at registration time unlike
> > the video controller.
> 
> It would I think be a lot cleaner and more future proof to pass a 
> 
> struct hdmi_audio_switch_ops
> 
> or some similar named object with an array of function pointers ?

That would be a good option, indeed.

In my patch series, I just didn't want to break the existing API,
so I kept the current style.


Takashi

[ANNOUNCE] libdrm 2.4.34

[Eric Anholt]

Anisse Astier (1):
  radeon: Add new R600 PCI ids for surface manager

Ben Skeggs (3):
  lists: add nicer+unsafe foreach, and list join macros
  nouveau: pull in major libdrm rewrite
  nouveau: init nvc0 channel alloc req structure fully

Christoph Bumiller (1):
  nouveau: expose notifier handle on nvc0 as well

Daniel Vetter (1):
  intel/decode: decode MI_WAIT_FOR_EVENT

Eugeni Dodonov (1):
  intel: add Ivy Bridge GT2 server variant

Marcin Slusarz (2):
  nouveau: remove unnecessary EAGAIN loops
  nouveau: fix channel closing

Paul Berry (2):
  intel: Add the ability to supply annotations for .aub files.
  configure: Bump version for 2.4.34.

Paulo Zanoni (4):
  modetest: fix some compiler warnings
  modetest: fix drmModeGetConnector memory leak
  modetest: call drmModeFreePlaneResources
  modetest: print more about our properties

Rob Clark (7):
  omap: fix license header
  modetest: add drm_plane support
  modetest: add YUV and multi-planar support
  modetest: add AR15/XR15 (RGB-1555) formats
  modetest: fix typo
  libdrm: update drm headers from kernel for prime/dmabuf
  omap: add dmabuf support

V?ctor Manuel J?quez Leal (1):
  omap: fix compiler warning

git tag: 2.4.34

http://dri.freedesktop.org/libdrm/libdrm-2.4.34.tar.bz2
MD5:  293cb2b31392d52caa02ab0861dfc2c9  libdrm-2.4.34.tar.bz2
SHA1: 861757baff4b37e564e13f5350c1b5d01c66a181  libdrm-2.4.34.tar.bz2
SHA256: a468570e7c85107b7c2f8eaceeebaa8f8a0da86482618f445bb74fa0b0d0f8d0  
libdrm-2.4.34.tar.bz2

http://dri.freedesktop.org/libdrm/libdrm-2.4.34.tar.gz
MD5:  6d83ba8234a93b1078f58005bff3c22c  libdrm-2.4.34.tar.gz
SHA1: 87d1b93ce13a0d940f2c11fa4fa6d9bd0d7e35a8  libdrm-2.4.34.tar.gz
SHA256: 8aeabbc7bd719ab3eb30be6018dd7b28b2c8edc594a8e3af0a9979c8b504d5ab  
libdrm-2.4.34.tar.gz

-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120510/715733ee/attachment.pgp>

[PATCH libdrm] radeon: Add new R600 PCI ids for surface manager

[Alex Deucher]

On Thu, May 10, 2012 at 11:56 AM, Anisse Astier  wrote:
> This is the same list of PCI ids added by Alex Deucher in xf86-video-ati 
> commit
> aacbd629b02cbee3f9e6a0ee452b4e3f21376bd3.
>
> This is needed since the addition of the surface allocator helper in
> commit c51f7f0e460dcadb9f1a56ecf1615810877c33c8 ; it needs to differentiate
> pre and post-R600 GPUs.
> Therefore we should maintain another PCI id list.
>
> Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=48138
> Signed-off-by: Anisse Astier 

Pushed.  thanks!

Alex

> ---
> ?radeon/r600_pci_ids.h | ? 10 ++
> ?1 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git a/radeon/r600_pci_ids.h b/radeon/r600_pci_ids.h
> index 8fbd749..360c73d 100644
> --- a/radeon/r600_pci_ids.h
> +++ b/radeon/r600_pci_ids.h
> @@ -152,6 +152,7 @@ CHIPSET(0x68F1, CEDAR_68F1, CEDAR)
> ?CHIPSET(0x68F2, CEDAR_68F2, CEDAR)
> ?CHIPSET(0x68F8, CEDAR_68F8, CEDAR)
> ?CHIPSET(0x68F9, CEDAR_68F9, CEDAR)
> +CHIPSET(0x68FA, CEDAR_68FA, CEDAR)
> ?CHIPSET(0x68FE, CEDAR_68FE, CEDAR)
>
> ?CHIPSET(0x68C0, REDWOOD_68C0, REDWOOD)
> @@ -192,6 +193,8 @@ CHIPSET(0x9804, PALM_9804, PALM)
> ?CHIPSET(0x9805, PALM_9805, PALM)
> ?CHIPSET(0x9806, PALM_9806, PALM)
> ?CHIPSET(0x9807, PALM_9807, PALM)
> +CHIPSET(0x9808, PALM_9808, PALM)
> +CHIPSET(0x9809, PALM_9809, PALM)
>
> ?CHIPSET(0x9640, SUMO_9640, ?SUMO)
> ?CHIPSET(0x9641, SUMO_9641, ?SUMO)
> @@ -202,6 +205,8 @@ CHIPSET(0x9645, SUMO2_9645, SUMO2)
> ?CHIPSET(0x9647, SUMO_9647, ?SUMO)
> ?CHIPSET(0x9648, SUMO_9648, ?SUMO)
> ?CHIPSET(0x964a, SUMO_964A, ?SUMO)
> +CHIPSET(0x964b, SUMO_964B, ?SUMO)
> +CHIPSET(0x964c, SUMO_964C, ?SUMO)
> ?CHIPSET(0x964e, SUMO_964E, ?SUMO)
> ?CHIPSET(0x964f, SUMO_964F, ?SUMO)
>
> @@ -245,8 +250,11 @@ CHIPSET(0x6747, TURKS_6747, TURKS)
> ?CHIPSET(0x6748, TURKS_6748, TURKS)
> ?CHIPSET(0x6749, TURKS_6749, TURKS)
> ?CHIPSET(0x6750, TURKS_6750, TURKS)
> +CHIPSET(0x6751, TURKS_6751, TURKS)
> ?CHIPSET(0x6758, TURKS_6758, TURKS)
> ?CHIPSET(0x6759, TURKS_6759, TURKS)
> +CHIPSET(0x675B, TURKS_675B, TURKS)
> +CHIPSET(0x675D, TURKS_675D, TURKS)
> ?CHIPSET(0x675F, TURKS_675F, TURKS)
> ?CHIPSET(0x6840, TURKS_6840, TURKS)
> ?CHIPSET(0x6841, TURKS_6841, TURKS)
> @@ -267,8 +275,10 @@ CHIPSET(0x6766, CAICOS_6766, CAICOS)
> ?CHIPSET(0x6767, CAICOS_6767, CAICOS)
> ?CHIPSET(0x6768, CAICOS_6768, CAICOS)
> ?CHIPSET(0x6770, CAICOS_6770, CAICOS)
> +CHIPSET(0x6772, CAICOS_6772, CAICOS)
> ?CHIPSET(0x6778, CAICOS_6778, CAICOS)
> ?CHIPSET(0x6779, CAICOS_6779, CAICOS)
> +CHIPSET(0x677B, CAICOS_677B, CAICOS)
>
> ?CHIPSET(0x9900, ARUBA_9900, ARUBA)
> ?CHIPSET(0x9901, ARUBA_9901, ARUBA)
> --
> 1.7.9
>

[PATCH] drm/radeon: make use of radeon_gem_init() consistent

[alexdeuc...@gmail.com]

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 all and rely on the the init in
radeon_device.c.  Just call radeon_gem_init() in radeon_device.c
and remove the explicit calls from all the newer asics.

All asics call radeon_gem_fini() in their fini pathes.  That
could possibly be cleaned up too.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/evergreen.c |4 
 drivers/gpu/drm/radeon/ni.c|4 
 drivers/gpu/drm/radeon/r600.c  |4 
 drivers/gpu/drm/radeon/radeon_device.c |4 +++-
 drivers/gpu/drm/radeon/rv770.c |4 
 drivers/gpu/drm/radeon/si.c|4 
 6 files changed, 3 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index 7e7ac3d..58991af 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -3435,10 +3435,6 @@ int evergreen_init(struct radeon_device *rdev)
 {
int r;

-   /* This don't do much */
-   r = radeon_gem_init(rdev);
-   if (r)
-   return r;
/* Read BIOS */
if (!radeon_get_bios(rdev)) {
if (ASIC_IS_AVIVO(rdev))
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 107b217..b01c2dd 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1629,10 +1629,6 @@ int cayman_init(struct radeon_device *rdev)
struct radeon_ring *ring = >ring[RADEON_RING_TYPE_GFX_INDEX];
int r;

-   /* This don't do much */
-   r = radeon_gem_init(rdev);
-   if (r)
-   return r;
/* Read BIOS */
if (!radeon_get_bios(rdev)) {
if (ASIC_IS_AVIVO(rdev))
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 4c0d8c9..971d244 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -2552,10 +2552,6 @@ int r600_init(struct radeon_device *rdev)
if (r600_debugfs_mc_info_init(rdev)) {
DRM_ERROR("Failed to register debugfs file for mc !\n");
}
-   /* This don't do much */
-   r = radeon_gem_init(rdev);
-   if (r)
-   return r;
/* Read BIOS */
if (!radeon_get_bios(rdev)) {
if (ASIC_IS_AVIVO(rdev))
diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index e1bc7e9..96d8ed3 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -731,9 +731,11 @@ int radeon_device_init(struct radeon_device *rdev,
mutex_init(>gem.mutex);
mutex_init(>pm.mutex);
mutex_init(>vram_mutex);
-   INIT_LIST_HEAD(>gem.objects);
init_waitqueue_head(>irq.vblank_queue);
init_waitqueue_head(>irq.idle_queue);
+   r = radeon_gem_init(rdev);
+   if (r)
+   return r;
/* initialize vm here */
rdev->vm_manager.use_bitmap = 1;
rdev->vm_manager.max_pfn = 1 << 20;
diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
index 40f82e2..c2f473b 100644
--- a/drivers/gpu/drm/radeon/rv770.c
+++ b/drivers/gpu/drm/radeon/rv770.c
@@ -1175,10 +1175,6 @@ int rv770_init(struct radeon_device *rdev)
 {
int r;

-   /* This don't do much */
-   r = radeon_gem_init(rdev);
-   if (r)
-   return r;
/* Read BIOS */
if (!radeon_get_bios(rdev)) {
if (ASIC_IS_AVIVO(rdev))
diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index be3b9fd..6e5a28a 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -3986,10 +3986,6 @@ int si_init(struct radeon_device *rdev)
struct radeon_ring *ring = >ring[RADEON_RING_TYPE_GFX_INDEX];
int r;

-   /* This don't do much */
-   r = radeon_gem_init(rdev);
-   if (r)
-   return r;
/* Read BIOS */
if (!radeon_get_bios(rdev)) {
if (ASIC_IS_AVIVO(rdev))
-- 
1.7.7.5

[PATCH 2/2] vga_switcheroo: Add the support for audio clients

[Alan Cox]

On Thu, 10 May 2012 09:10:16 +0200
Takashi Iwai  wrote:

> 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 explicity at registration time unlike
> the video controller.

It would I think be a lot cleaner and more future proof to pass a 

struct hdmi_audio_switch_ops

or some similar named object with an array of function pointers ?

Alan

[PATCH 2/2 v3] drm/exynos: added userptr feature.

[Jerome Glisse]

On Thu, May 10, 2012 at 11:31 AM, Daniel Vetter  wrote:
> On Thu, May 10, 2012 at 11:05:07AM -0400, Jerome Glisse wrote:
>> On Wed, May 9, 2012 at 10:44 PM, Inki Dae  wrote:
>> > Hi Jerome,
>> >
>> > Thank you again.
>> >
>> >> -Original Message-
>> >> From: Jerome Glisse [mailto:j.glisse at gmail.com]
>> >> Sent: Thursday, May 10, 2012 3:33 AM
>> >> To: Inki Dae
>> >> Cc: airlied at linux.ie; dri-devel at lists.freedesktop.org;
>> >> kyungmin.park at samsung.com; sw0312.kim at samsung.com; linux-mm at 
>> >> kvack.org
>> >> Subject: Re: [PATCH 2/2 v3] drm/exynos: added userptr feature.
>> >>
>> >> On Wed, May 9, 2012 at 10:45 AM, Jerome Glisse  
>> >> wrote:
>> >> > On Wed, May 9, 2012 at 2:17 AM, Inki Dae  
>> >> > wrote:
>> >> >> this feature is used to import user space region allocated by malloc()
>> >> or
>> >> >> mmaped into a gem. and to guarantee the pages to user space not to be
>> >> >> swapped out, the VMAs within the user space would be locked and then
>> >> unlocked
>> >> >> when the pages are released.
>> >> >>
>> >> >> but this lock might result in significant degradation of system
>> >> performance
>> >> >> because the pages couldn't be swapped out so we limit user-desired
>> >> userptr
>> >> >> size to pre-defined.
>> >> >>
>> >> >> Signed-off-by: Inki Dae 
>> >> >> Signed-off-by: Kyungmin Park 
>> >> >
>> >> >
>> >> > Again i would like feedback from mm people (adding cc). I am not sure
>> >> > locking the vma is the right anwser as i said in my previous mail,
>> >> > userspace can munlock it in your back, maybe VM_RESERVED is better.
>> >> > Anyway even not considering that you don't check at all that process
>> >> > don't go over the limit of locked page see mm/mlock.c RLIMIT_MEMLOCK
>> >> > for how it's done. Also you mlock complete vma but the userptr you get
>> >> > might be inside say 16M vma and you only care about 1M of userptr, if
>> >> > you mark the whole vma as locked than anytime a new page is fault in
>> >> > the vma else where than in the buffer you are interested then it got
>> >> > allocated for ever until the gem buffer is destroy, i am not sure of
>> >> > what happen to the vma on next malloc if it grows or not (i would
>> >> > think it won't grow at it would have different flags than new
>> >> > anonymous memory).
>> >> >
>> >> > The whole business of directly using malloced memory for gpu is fishy
>> >> > and i would really like to get it right rather than relying on never
>> >> > hitting strange things like page migration, vma merging, or worse
>> >> > things like over locking pages and stealing memory.
>> >> >
>> >> > Cheers,
>> >> > Jerome
>> >>
>> >> I had a lengthy discussion with mm people (thx a lot for that). I
>> >> think we should split 2 different use case. The zero-copy upload case
>> >> ie :
>> >> app:
>> >> ? ? ptr = malloc()
>> >> ? ? ...
>> >> ? ? glTex/VBO/UBO/...(ptr)
>> >> ? ? free(ptr) or reuse it for other things
>> >> For which i guess you want to avoid having to do a memcpy inside the
>> >> gl library (could be anything else than gl that have same useage
>> >> pattern).
>> >>
>> >
>> > Right, in this case, we are using the userptr feature as pixman and evas
>> > backend to use 2d accelerator.
>> >
>> >> ie after the upload happen you don't care about those page they can
>> >> removed from the vma or marked as cow so that anything messing with
>> >> those page after the upload won't change what you uploaded. Of course
>> >
>> > I'm not sure that I understood your mentions but could the pages be removed
>> > from vma with VM_LOCKED or VM_RESERVED? once glTex/VBO/UBO/..., the VMAs to
>> > user space would be locked. if cpu accessed significant part of all the
>> > pages in user mode then pages to the part would be allocated by page fault
>> > handler, after that, through userptr, the VMAs to user address space would
>> > be locked(at this time, the remaining pages would be allocated also by
>> > get_user_pages by calling page fault handler) I'd be glad to give me any
>> > comments and advices if there is my missing point.
>> >
>> >> this is assuming that the tlb cost of doing such thing is smaller than
>> >> the cost of memcpy the data.
>> >>
>> >
>> > yes, in our test case, the tlb cost(incurred by tlb miss) was smaller than
>> > the cost of memcpy also cpu usage. of course, this would be depended on gpu
>> > performance.
>> >
>> >> Two way to do that, either you assume app can't not read back data
>> >> after gl can and you do an unmap_mapping_range (make sure you only
>> >> unmap fully covered page and that you copy non fully covered page) or
>> >> you want to allow userspace to still read data or possibly overwrite
>> >> them
>> >>
>> >> Second use case is something more like for the opencl case of
>> >> CL_MEM_USE_HOST_PTR, in which you want to use the same page in the gpu
>> >> and keep the userspace vma pointing to those page. I think the
>> >> agreement on this case is that there is no way right now to do it
>> >> sanely inside 

[PATCH 2/2 v3] drm/exynos: added userptr feature.

[Inki Dae]

Hi Jerome,

Thank you again.

> -Original Message-
> From: Jerome Glisse [mailto:j.glisse at gmail.com]
> Sent: Thursday, May 10, 2012 3:33 AM
> To: Inki Dae
> Cc: airlied at linux.ie; dri-devel at lists.freedesktop.org;
> kyungmin.park at samsung.com; sw0312.kim at samsung.com; linux-mm at kvack.org
> Subject: Re: [PATCH 2/2 v3] drm/exynos: added userptr feature.
> 
> On Wed, May 9, 2012 at 10:45 AM, Jerome Glisse  wrote:
> > On Wed, May 9, 2012 at 2:17 AM, Inki Dae  wrote:
> >> this feature is used to import user space region allocated by malloc()
> or
> >> mmaped into a gem. and to guarantee the pages to user space not to be
> >> swapped out, the VMAs within the user space would be locked and then
> unlocked
> >> when the pages are released.
> >>
> >> but this lock might result in significant degradation of system
> performance
> >> because the pages couldn't be swapped out so we limit user-desired
> userptr
> >> size to pre-defined.
> >>
> >> Signed-off-by: Inki Dae 
> >> Signed-off-by: Kyungmin Park 
> >
> >
> > Again i would like feedback from mm people (adding cc). I am not sure
> > locking the vma is the right anwser as i said in my previous mail,
> > userspace can munlock it in your back, maybe VM_RESERVED is better.
> > Anyway even not considering that you don't check at all that process
> > don't go over the limit of locked page see mm/mlock.c RLIMIT_MEMLOCK
> > for how it's done. Also you mlock complete vma but the userptr you get
> > might be inside say 16M vma and you only care about 1M of userptr, if
> > you mark the whole vma as locked than anytime a new page is fault in
> > the vma else where than in the buffer you are interested then it got
> > allocated for ever until the gem buffer is destroy, i am not sure of
> > what happen to the vma on next malloc if it grows or not (i would
> > think it won't grow at it would have different flags than new
> > anonymous memory).
> >
> > The whole business of directly using malloced memory for gpu is fishy
> > and i would really like to get it right rather than relying on never
> > hitting strange things like page migration, vma merging, or worse
> > things like over locking pages and stealing memory.
> >
> > Cheers,
> > Jerome
> 
> I had a lengthy discussion with mm people (thx a lot for that). I
> think we should split 2 different use case. The zero-copy upload case
> ie :
> app:
> ptr = malloc()
> ...
> glTex/VBO/UBO/...(ptr)
> free(ptr) or reuse it for other things
> For which i guess you want to avoid having to do a memcpy inside the
> gl library (could be anything else than gl that have same useage
> pattern).
> 

Right, in this case, we are using the userptr feature as pixman and evas
backend to use 2d accelerator.

> ie after the upload happen you don't care about those page they can
> removed from the vma or marked as cow so that anything messing with
> those page after the upload won't change what you uploaded. Of course

I'm not sure that I understood your mentions but could the pages be removed
from vma with VM_LOCKED or VM_RESERVED? once glTex/VBO/UBO/..., the VMAs to
user space would be locked. if cpu accessed significant part of all the
pages in user mode then pages to the part would be allocated by page fault
handler, after that, through userptr, the VMAs to user address space would
be locked(at this time, the remaining pages would be allocated also by
get_user_pages by calling page fault handler) I'd be glad to give me any
comments and advices if there is my missing point.

> this is assuming that the tlb cost of doing such thing is smaller than
> the cost of memcpy the data.
> 

yes, in our test case, the tlb cost(incurred by tlb miss) was smaller than
the cost of memcpy also cpu usage. of course, this would be depended on gpu
performance.

> Two way to do that, either you assume app can't not read back data
> after gl can and you do an unmap_mapping_range (make sure you only
> unmap fully covered page and that you copy non fully covered page) or
> you want to allow userspace to still read data or possibly overwrite
> them
> 
> Second use case is something more like for the opencl case of
> CL_MEM_USE_HOST_PTR, in which you want to use the same page in the gpu
> and keep the userspace vma pointing to those page. I think the
> agreement on this case is that there is no way right now to do it
> sanely inside linux kernel. mlocking will need proper accounting
> against rtlimit but this limit might be low. Also the fork case might
> be problematic.
> 
> For the fork case the memory is anonymous so it should be COWed in the
> fork child but relative to cl context that means the child could not
> use the cl context with that memory or at least if the child write to
> this memory the cl will not see those change. I guess the answer to
> that one is that you really need to use the cl api to read the object
> or get proper ptr to read it.
> 
> Anyway in all case, implementing this userptr thing need a lot more
> 

[PATCH 2/2] vga_switcheroo: Add the support for audio clients

[Dave Airlie]

On Thu, May 10, 2012 at 8:10 AM, Takashi Iwai  wrote:
> 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 explicity at registration time unlike
> the video controller.

The only question I really have is how you assign the audio ids.

Currently we mostly don't see > 1 HDMI audio on a GPU, but that
should be changing with the latest ones.

Otherwise I'm happy to pull that branch from you.

Dave.

[PATCH 2/2 v3] drm/exynos: added userptr feature.

[Jerome Glisse]

On Wed, May 9, 2012 at 10:44 PM, Inki Dae  wrote:
> Hi Jerome,
>
> Thank you again.
>
>> -Original Message-
>> From: Jerome Glisse [mailto:j.glisse at gmail.com]
>> Sent: Thursday, May 10, 2012 3:33 AM
>> To: Inki Dae
>> Cc: airlied at linux.ie; dri-devel at lists.freedesktop.org;
>> kyungmin.park at samsung.com; sw0312.kim at samsung.com; linux-mm at 
>> kvack.org
>> Subject: Re: [PATCH 2/2 v3] drm/exynos: added userptr feature.
>>
>> On Wed, May 9, 2012 at 10:45 AM, Jerome Glisse  wrote:
>> > On Wed, May 9, 2012 at 2:17 AM, Inki Dae  wrote:
>> >> this feature is used to import user space region allocated by malloc()
>> or
>> >> mmaped into a gem. and to guarantee the pages to user space not to be
>> >> swapped out, the VMAs within the user space would be locked and then
>> unlocked
>> >> when the pages are released.
>> >>
>> >> but this lock might result in significant degradation of system
>> performance
>> >> because the pages couldn't be swapped out so we limit user-desired
>> userptr
>> >> size to pre-defined.
>> >>
>> >> Signed-off-by: Inki Dae 
>> >> Signed-off-by: Kyungmin Park 
>> >
>> >
>> > Again i would like feedback from mm people (adding cc). I am not sure
>> > locking the vma is the right anwser as i said in my previous mail,
>> > userspace can munlock it in your back, maybe VM_RESERVED is better.
>> > Anyway even not considering that you don't check at all that process
>> > don't go over the limit of locked page see mm/mlock.c RLIMIT_MEMLOCK
>> > for how it's done. Also you mlock complete vma but the userptr you get
>> > might be inside say 16M vma and you only care about 1M of userptr, if
>> > you mark the whole vma as locked than anytime a new page is fault in
>> > the vma else where than in the buffer you are interested then it got
>> > allocated for ever until the gem buffer is destroy, i am not sure of
>> > what happen to the vma on next malloc if it grows or not (i would
>> > think it won't grow at it would have different flags than new
>> > anonymous memory).
>> >
>> > The whole business of directly using malloced memory for gpu is fishy
>> > and i would really like to get it right rather than relying on never
>> > hitting strange things like page migration, vma merging, or worse
>> > things like over locking pages and stealing memory.
>> >
>> > Cheers,
>> > Jerome
>>
>> I had a lengthy discussion with mm people (thx a lot for that). I
>> think we should split 2 different use case. The zero-copy upload case
>> ie :
>> app:
>> ? ? ptr = malloc()
>> ? ? ...
>> ? ? glTex/VBO/UBO/...(ptr)
>> ? ? free(ptr) or reuse it for other things
>> For which i guess you want to avoid having to do a memcpy inside the
>> gl library (could be anything else than gl that have same useage
>> pattern).
>>
>
> Right, in this case, we are using the userptr feature as pixman and evas
> backend to use 2d accelerator.
>
>> ie after the upload happen you don't care about those page they can
>> removed from the vma or marked as cow so that anything messing with
>> those page after the upload won't change what you uploaded. Of course
>
> I'm not sure that I understood your mentions but could the pages be removed
> from vma with VM_LOCKED or VM_RESERVED? once glTex/VBO/UBO/..., the VMAs to
> user space would be locked. if cpu accessed significant part of all the
> pages in user mode then pages to the part would be allocated by page fault
> handler, after that, through userptr, the VMAs to user address space would
> be locked(at this time, the remaining pages would be allocated also by
> get_user_pages by calling page fault handler) I'd be glad to give me any
> comments and advices if there is my missing point.
>
>> this is assuming that the tlb cost of doing such thing is smaller than
>> the cost of memcpy the data.
>>
>
> yes, in our test case, the tlb cost(incurred by tlb miss) was smaller than
> the cost of memcpy also cpu usage. of course, this would be depended on gpu
> performance.
>
>> Two way to do that, either you assume app can't not read back data
>> after gl can and you do an unmap_mapping_range (make sure you only
>> unmap fully covered page and that you copy non fully covered page) or
>> you want to allow userspace to still read data or possibly overwrite
>> them
>>
>> Second use case is something more like for the opencl case of
>> CL_MEM_USE_HOST_PTR, in which you want to use the same page in the gpu
>> and keep the userspace vma pointing to those page. I think the
>> agreement on this case is that there is no way right now to do it
>> sanely inside linux kernel. mlocking will need proper accounting
>> against rtlimit but this limit might be low. Also the fork case might
>> be problematic.
>>
>> For the fork case the memory is anonymous so it should be COWed in the
>> fork child but relative to cl context that means the child could not
>> use the cl context with that memory or at least if the child write to
>> this memory the cl will not see those change. I guess the answer to
>> that one 

[patch] gma500: silence an unused variable warning

[Kirill A. Shutemov]

On Thu, May 10, 2012 at 10:33:02AM +0300, Dan Carpenter wrote:
> If CONFIG_BACKLIGHT_CLASS_DEVICE is disabled then GCC warns that:
>   drivers/gpu/drm/gma500/opregion.c:154:6: warning:
>   unused variable ?max? [-Wunused-variable]
> 
> Which give me a chance to use the new config_enabled() macro.  :)

The first [direct] user of config_enabled()! :)

Acked-by: Kirill A. Shutemov 

> 
> Signed-off-by: Dan Carpenter 
> 
> diff --git a/drivers/gpu/drm/gma500/opregion.c 
> b/drivers/gpu/drm/gma500/opregion.c
> index 05661bf..d2125ba 100644
> --- a/drivers/gpu/drm/gma500/opregion.c
> +++ b/drivers/gpu/drm/gma500/opregion.c
> @@ -151,7 +151,6 @@ static u32 asle_set_backlight(struct drm_device *dev, u32 
> bclp)
>   struct drm_psb_private *dev_priv = dev->dev_private;
>   struct opregion_asle *asle = dev_priv->opregion.asle;
>   struct backlight_device *bd = dev_priv->backlight_device;
> - u32 max;
>  
>   DRM_DEBUG_DRIVER("asle set backlight %x\n", bclp);
>  
> @@ -165,11 +164,12 @@ static u32 asle_set_backlight(struct drm_device *dev, 
> u32 bclp)
>   if (bclp > 255)
>   return ASLE_BACKLIGHT_FAILED;
>  
> -#ifdef CONFIG_BACKLIGHT_CLASS_DEVICE
> - max = bd->props.max_brightness;
> - bd->props.brightness = bclp * max / 255;
> - backlight_update_status(bd);
> -#endif
> + if (config_enabled(CONFIG_BACKLIGHT_CLASS_DEVICE)) {
> + int max = bd->props.max_brightness;
> + bd->props.brightness = bclp * max / 255;
> + backlight_update_status(bd);
> + }
> +
>   asle->cblv = (bclp * 0x64) / 0xff | ASLE_CBLV_VALID;
>  
>   return 0;

-- 
 Kirill A. Shutemov
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120510/b55928d9/attachment.pgp>

[Bug 49418] [RV730] Screen is Scrambled When Booting in EFI Mode

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=49418

--- Comment #4 from Bastien Dejean  2012-05-10 03:59:24 
PDT ---
I can provide further debug information if needed.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH 2/2 v3] drm/exynos: added userptr feature.

[Inki Dae]

Hi Jerome,

> -Original Message-
> From: Jerome Glisse [mailto:j.glisse at gmail.com]
> Sent: Wednesday, May 09, 2012 11:46 PM
> To: Inki Dae
> Cc: airlied at linux.ie; dri-devel at lists.freedesktop.org;
> kyungmin.park at samsung.com; sw0312.kim at samsung.com; linux-mm at kvack.org
> Subject: Re: [PATCH 2/2 v3] drm/exynos: added userptr feature.
> 
> On Wed, May 9, 2012 at 2:17 AM, Inki Dae  wrote:
> > this feature is used to import user space region allocated by malloc()
> or
> > mmaped into a gem. and to guarantee the pages to user space not to be
> > swapped out, the VMAs within the user space would be locked and then
> unlocked
> > when the pages are released.
> >
> > but this lock might result in significant degradation of system
> performance
> > because the pages couldn't be swapped out so we limit user-desired
> userptr
> > size to pre-defined.
> >
> > Signed-off-by: Inki Dae 
> > Signed-off-by: Kyungmin Park 
> 
> 
> Again i would like feedback from mm people (adding cc). I am not sure

Thank you, I missed adding mm as cc.

> locking the vma is the right anwser as i said in my previous mail,
> userspace can munlock it in your back, maybe VM_RESERVED is better.

I know that with VM_RESERVED flag, also we can avoid the pages from being
swapped out. but these pages should be unlocked anytime we want because we
could allocate all pages on system and lock them, which in turn, it may
result in significant deterioration of system performance.(maybe other
processes requesting free memory would be blocked) so I used VM_LOCKED flags
instead. but I'm not sure this way is best also.

> Anyway even not considering that you don't check at all that process
> don't go over the limit of locked page see mm/mlock.c RLIMIT_MEMLOCK

Thank you for your advices.

> for how it's done. Also you mlock complete vma but the userptr you get
> might be inside say 16M vma and you only care about 1M of userptr, if
> you mark the whole vma as locked than anytime a new page is fault in
> the vma else where than in the buffer you are interested then it got
> allocated for ever until the gem buffer is destroy, i am not sure of
> what happen to the vma on next malloc if it grows or not (i would
> think it won't grow at it would have different flags than new
> anonymous memory).
> 
> The whole business of directly using malloced memory for gpu is fishy
> and i would really like to get it right rather than relying on never
> hitting strange things like page migration, vma merging, or worse
> things like over locking pages and stealing memory.
> 

Your comments are very helpful to me and I will consider some cases I missed
and you pointed out for next patch.

Thanks,
Inki Dae

> Cheers,
> Jerome
> 
> 
> > ---
> > ?drivers/gpu/drm/exynos/exynos_drm_drv.c | ? ?2 +
> > ?drivers/gpu/drm/exynos/exynos_drm_gem.c | ?334
> +++
> > ?drivers/gpu/drm/exynos/exynos_drm_gem.h | ? 17 ++-
> > ?include/drm/exynos_drm.h ? ? ? ? ? ? ? ?| ? 26 +++-
> > ?4 files changed, 376 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> > index 1e68ec2..e8ae3f1 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> > @@ -220,6 +220,8 @@ static struct drm_ioctl_desc exynos_ioctls[] = {
> > ? ? ? ?DRM_IOCTL_DEF_DRV(EXYNOS_GEM_MAP_OFFSET,
> > ? ? ? ? ? ? ? ? ? ? ? ?exynos_drm_gem_map_offset_ioctl, DRM_UNLOCKED |
> > ? ? ? ? ? ? ? ? ? ? ? ?DRM_AUTH),
> > + ? ? ? DRM_IOCTL_DEF_DRV(EXYNOS_GEM_USERPTR,
> > + ? ? ? ? ? ? ? ? ? ? ? exynos_drm_gem_userptr_ioctl, DRM_UNLOCKED),
> > ? ? ? ?DRM_IOCTL_DEF_DRV(EXYNOS_GEM_MMAP,
> > ? ? ? ? ? ? ? ? ? ? ? ?exynos_drm_gem_mmap_ioctl, DRM_UNLOCKED |
DRM_AUTH),
> > ? ? ? ?DRM_IOCTL_DEF_DRV(EXYNOS_GEM_GET,
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> > index e6abb66..ccc6e3d 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> > @@ -68,6 +68,83 @@ static int check_gem_flags(unsigned int flags)
> > ? ? ? ?return 0;
> > ?}
> >
> > +static struct vm_area_struct *get_vma(struct vm_area_struct *vma)
> > +{
> > + ? ? ? struct vm_area_struct *vma_copy;
> > +
> > + ? ? ? vma_copy = kmalloc(sizeof(*vma_copy), GFP_KERNEL);
> > + ? ? ? if (!vma_copy)
> > + ? ? ? ? ? ? ? return NULL;
> > +
> > + ? ? ? if (vma->vm_ops && vma->vm_ops->open)
> > + ? ? ? ? ? ? ? vma->vm_ops->open(vma);
> > +
> > + ? ? ? if (vma->vm_file)
> > + ? ? ? ? ? ? ? get_file(vma->vm_file);
> > +
> > + ? ? ? memcpy(vma_copy, vma, sizeof(*vma));
> > +
> > + ? ? ? vma_copy->vm_mm = NULL;
> > + ? ? ? vma_copy->vm_next = NULL;
> > + ? ? ? vma_copy->vm_prev = NULL;
> > +
> > + ? ? ? return vma_copy;
> > +}
> > +
> > +
> > +static void put_vma(struct vm_area_struct *vma)
> > +{
> > + ? ? ? if (!vma)
> > + ? ? ? ? ? ? ? return;
> > +
> > + ? ? ? if (vma->vm_ops && vma->vm_ops->close)
> > + ? ? ? ? ? 

[patch] gma500: silence an unused variable warning

[Dan Carpenter]

If CONFIG_BACKLIGHT_CLASS_DEVICE is disabled then GCC warns that:
drivers/gpu/drm/gma500/opregion.c:154:6: warning:
unused variable ?max? [-Wunused-variable]

Which give me a chance to use the new config_enabled() macro.  :)

Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/gma500/opregion.c 
b/drivers/gpu/drm/gma500/opregion.c
index 05661bf..d2125ba 100644
--- a/drivers/gpu/drm/gma500/opregion.c
+++ b/drivers/gpu/drm/gma500/opregion.c
@@ -151,7 +151,6 @@ static u32 asle_set_backlight(struct drm_device *dev, u32 
bclp)
struct drm_psb_private *dev_priv = dev->dev_private;
struct opregion_asle *asle = dev_priv->opregion.asle;
struct backlight_device *bd = dev_priv->backlight_device;
-   u32 max;

DRM_DEBUG_DRIVER("asle set backlight %x\n", bclp);

@@ -165,11 +164,12 @@ static u32 asle_set_backlight(struct drm_device *dev, u32 
bclp)
if (bclp > 255)
return ASLE_BACKLIGHT_FAILED;

-#ifdef CONFIG_BACKLIGHT_CLASS_DEVICE
-   max = bd->props.max_brightness;
-   bd->props.brightness = bclp * max / 255;
-   backlight_update_status(bd);
-#endif
+   if (config_enabled(CONFIG_BACKLIGHT_CLASS_DEVICE)) {
+   int max = bd->props.max_brightness;
+   bd->props.brightness = bclp * max / 255;
+   backlight_update_status(bd);
+   }
+
asle->cblv = (bclp * 0x64) / 0xff | ASLE_CBLV_VALID;

return 0;

[patch] gma500: silence an unused variable warning

[Paul Menzel]

Am Donnerstag, den 10.05.2012, 10:33 +0300 schrieb Dan Carpenter:
> If CONFIG_BACKLIGHT_CLASS_DEVICE is disabled then GCC warns that:
>   drivers/gpu/drm/gma500/opregion.c:154:6: warning:
>   unused variable ?max? [-Wunused-variable]
> 
> Which give me a chance to use the new config_enabled() macro.  :)

Also the variable type is changed from `u32` to `int`.

> Signed-off-by: Dan Carpenter 

Acked-by: Paul Menzel 

> diff --git a/drivers/gpu/drm/gma500/opregion.c 
> b/drivers/gpu/drm/gma500/opregion.c
> index 05661bf..d2125ba 100644
> --- a/drivers/gpu/drm/gma500/opregion.c
> +++ b/drivers/gpu/drm/gma500/opregion.c
> @@ -151,7 +151,6 @@ static u32 asle_set_backlight(struct drm_device *dev, u32 
> bclp)
>   struct drm_psb_private *dev_priv = dev->dev_private;
>   struct opregion_asle *asle = dev_priv->opregion.asle;
>   struct backlight_device *bd = dev_priv->backlight_device;
> - u32 max;
>  
>   DRM_DEBUG_DRIVER("asle set backlight %x\n", bclp);
>  
> @@ -165,11 +164,12 @@ static u32 asle_set_backlight(struct drm_device *dev, 
> u32 bclp)
>   if (bclp > 255)
>   return ASLE_BACKLIGHT_FAILED;
>  
> -#ifdef CONFIG_BACKLIGHT_CLASS_DEVICE
> - max = bd->props.max_brightness;
> - bd->props.brightness = bclp * max / 255;
> - backlight_update_status(bd);
> -#endif
> + if (config_enabled(CONFIG_BACKLIGHT_CLASS_DEVICE)) {
> + int max = bd->props.max_brightness;
> + bd->props.brightness = bclp * max / 255;
> + backlight_update_status(bd);
> + }
> +
>   asle->cblv = (bclp * 0x64) / 0xff | ASLE_CBLV_VALID;
>  
>   return 0;
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120510/da4a1a52/attachment.pgp>

[PATCH 2/2] vga_switcheroo: Add the support for audio clients

[Paul Menzel]

Dear Takashi,


thank you for your patches.

Am Donnerstag, den 10.05.2012, 09:10 +0200 schrieb 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 explicity at registration time unlike

explicit*l*y

> the video controller.
> 
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43155

Is there a way (command sequence) to test this patch?

> Signed-off-by: Takashi Iwai 
> ---
>  drivers/gpu/vga/vga_switcheroo.c |   84 
> ++
>  include/linux/vga_switcheroo.h   |   10 +
>  2 files changed, 78 insertions(+), 16 deletions(-)

[?]


Thanks,

Paul
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120510/1017e969/attachment.pgp>

[PATCH 0/2] Audio client support for VGA-switcheroo

[Takashi Iwai]

At Thu, 10 May 2012 09:08:38 +0200,
Takashi Iwai wrote:
> 
> Dave,
> 
> this is a small patch series to add the support for audio clients
> to VGA switcheroo.  The background problem is that the HD-audio HDMI
> controller of the discrete GPU is also disabled when the graphics core
> is disabled by vga-switcheroo.  This leads to a long stall of the
> audio driver, or at worst, it Oopses.
>   https://bugzilla.kernel.org/show_bug.cgi?id=43155
> 
> I tried to work around it only in the audio driver side, but it
> doesn't seem to help.  When the graphics is disabled, the whole PCI
> entry can't be accessed any longer.  Even reading a config triggers an
> Oops.  So, the only option is to implement the VGA switcheroo client
> for the audio.
> 
> The first patch refactors the vga-switcheroo code to be ready to
> accept for more than two clients.  It's mostly a clean up using linked
> lists.  The next patch implements the audio client registration.
> 
> BTW, if these patches are OK, the question remains how to merge.
> Obviously I'd need more patches for HD-audio driver based on the new
> vga_switcheroo_register_audio_client().  One option is to apply these
> patches to a persistent branch (i.e. no rebase planned) of your tree
> and pull it to my tree with more patches for HD-audio.
> Does it sound good for you?

Or, if you prefer, just pull from topic/vga-switcheroo branch of my tree:
  git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git 
topic/vga-switcheroo


Takashi

[PATCH 2/2] vga_switcheroo: Add the support for audio clients

[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 explicity at registration time unlike
the video controller.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43155

Signed-off-by: Takashi Iwai 
---
 drivers/gpu/vga/vga_switcheroo.c |   84 ++
 include/linux/vga_switcheroo.h   |   10 +
 2 files changed, 78 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
index c91573f..df25ea6 100644
--- a/drivers/gpu/vga/vga_switcheroo.c
+++ b/drivers/gpu/vga/vga_switcheroo.c
@@ -57,6 +57,11 @@ struct vgasr_priv {
struct vga_switcheroo_handler *handler;
 };

+#define ID_BIT_AUDIO   0x100
+#define client_is_audio(c) ((c)->id & ID_BIT_AUDIO)
+#define client_is_vga(c)   ((c)->id == -1 || !client_is_audio(c))
+#define client_id(c)   ((c)->id & ~ID_BIT_AUDIO)
+
 static int vga_switcheroo_debugfs_init(struct vgasr_priv *priv);
 static void vga_switcheroo_debugfs_fini(struct vgasr_priv *priv);

@@ -96,6 +101,8 @@ static void vga_switcheroo_enable(void)
vgasr_priv.handler->init();

list_for_each_entry(client, _priv.clients, list) {
+   if (client->id != -1)
+   continue;
ret = vgasr_priv.handler->get_client_id(client->pdev);
if (ret < 0)
return;
@@ -106,10 +113,11 @@ static void vga_switcheroo_enable(void)
vgasr_priv.active = true;
 }

-int vga_switcheroo_register_client(struct pci_dev *pdev,
-  void (*set_gpu_state)(struct pci_dev *pdev, 
enum vga_switcheroo_state),
-  void (*reprobe)(struct pci_dev *pdev),
-  bool (*can_switch)(struct pci_dev *pdev))
+static int register_client(struct pci_dev *pdev,
+   void (*set_gpu_state)(struct pci_dev *pdev, enum vga_switcheroo_state),
+   void (*reprobe)(struct pci_dev *pdev),
+   bool (*can_switch)(struct pci_dev *pdev),
+   int id, bool active)
 {
struct vga_switcheroo_client *client;

@@ -122,24 +130,48 @@ int vga_switcheroo_register_client(struct pci_dev *pdev,
client->set_gpu_state = set_gpu_state;
client->reprobe = reprobe;
client->can_switch = can_switch;
-   client->id = -1;
-   if (pdev->resource[PCI_ROM_RESOURCE].flags & IORESOURCE_ROM_SHADOW)
-   client->active = true;
+   client->id = id;
+   client->active = active;

mutex_lock(_mutex);
list_add_tail(>list, _priv.clients);
-   vgasr_priv.registered_clients++;
+   if (client_is_vga(client))
+   vgasr_priv.registered_clients++;

/* if we get two clients + handler */
-   if (vgasr_priv.registered_clients == 2 && vgasr_priv.handler) {
+   if (!vgasr_priv.active &&
+   vgasr_priv.registered_clients == 2 && vgasr_priv.handler) {
printk(KERN_INFO "vga_switcheroo: enabled\n");
vga_switcheroo_enable();
}
mutex_unlock(_mutex);
return 0;
 }
+
+int vga_switcheroo_register_client(struct pci_dev *pdev,
+  void (*set_gpu_state)(struct pci_dev *pdev, 
enum vga_switcheroo_state),
+  void (*reprobe)(struct pci_dev *pdev),
+  bool (*can_switch)(struct pci_dev *pdev))
+{
+   bool active = false;
+   if (pdev->resource[PCI_ROM_RESOURCE].flags & IORESOURCE_ROM_SHADOW)
+   active = true;
+   return register_client(pdev, set_gpu_state, reprobe, can_switch,
+  -1, active);
+}
 EXPORT_SYMBOL(vga_switcheroo_register_client);

+int vga_switcheroo_register_audio_client(struct pci_dev *pdev,
+   void (*set_gpu_state)(struct pci_dev *pdev, enum vga_switcheroo_state),
+   void (*reprobe)(struct pci_dev *pdev),
+   bool (*can_switch)(struct pci_dev *pdev),
+   int id, bool active)
+{
+   return register_client(pdev, set_gpu_state, reprobe, can_switch,
+  id | ID_BIT_AUDIO, active);
+}
+EXPORT_SYMBOL(vga_switcheroo_register_audio_client);
+
 static struct vga_switcheroo_client *
 find_client_from_pci(struct list_head *head, struct pci_dev *pdev)
 {
@@ -165,7 +197,7 @@ find_active_client(struct list_head *head)
 {
struct vga_switcheroo_client *client;
list_for_each_entry(client, head, list)
-   if (client->active == true)
+   if (client->active && client_is_vga(client))
return client;
return NULL;
 }
@@ -177,13 +209,16 @@ void vga_switcheroo_unregister_client(struct pci_dev 
*pdev)
mutex_lock(_mutex);
client = find_client_from_pci(_priv.clients, pdev);
if (client) {
+   if (client_is_vga(client))
+  

[PATCH 1/2] vga_switcheroo: Refactor using linked list

[Takashi Iwai]

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/vga/vga_switcheroo.c
index 58434e8..c91573f 100644
--- a/drivers/gpu/vga/vga_switcheroo.c
+++ b/drivers/gpu/vga/vga_switcheroo.c
@@ -37,6 +37,7 @@ struct vga_switcheroo_client {
bool (*can_switch)(struct pci_dev *pdev);
int id;
bool active;
+   struct list_head list;
 };

 static DEFINE_MUTEX(vgasr_mutex);
@@ -51,7 +52,7 @@ struct vgasr_priv {
struct dentry *switch_file;

int registered_clients;
-   struct vga_switcheroo_client clients[VGA_SWITCHEROO_MAX_CLIENTS];
+   struct list_head clients;

struct vga_switcheroo_handler *handler;
 };
@@ -60,7 +61,9 @@ static int vga_switcheroo_debugfs_init(struct vgasr_priv 
*priv);
 static void vga_switcheroo_debugfs_fini(struct vgasr_priv *priv);

 /* only one switcheroo per system */
-static struct vgasr_priv vgasr_priv;
+static struct vgasr_priv vgasr_priv = {
+   .clients = LIST_HEAD_INIT(vgasr_priv.clients),
+};

 int vga_switcheroo_register_handler(struct vga_switcheroo_handler *handler)
 {
@@ -86,17 +89,18 @@ EXPORT_SYMBOL(vga_switcheroo_unregister_handler);

 static void vga_switcheroo_enable(void)
 {
-   int i;
int ret;
+   struct vga_switcheroo_client *client;
+
/* call the handler to init */
vgasr_priv.handler->init();

-   for (i = 0; i < VGA_SWITCHEROO_MAX_CLIENTS; i++) {
-   ret = 
vgasr_priv.handler->get_client_id(vgasr_priv.clients[i].pdev);
+   list_for_each_entry(client, _priv.clients, list) {
+   ret = vgasr_priv.handler->get_client_id(client->pdev);
if (ret < 0)
return;

-   vgasr_priv.clients[i].id = ret;
+   client->id = ret;
}
vga_switcheroo_debugfs_init(_priv);
vgasr_priv.active = true;
@@ -107,28 +111,27 @@ int vga_switcheroo_register_client(struct pci_dev *pdev,
   void (*reprobe)(struct pci_dev *pdev),
   bool (*can_switch)(struct pci_dev *pdev))
 {
-   int index;
+   struct vga_switcheroo_client *client;

-   mutex_lock(_mutex);
-   /* don't do IGD vs DIS here */
-   if (vgasr_priv.registered_clients & 1)
-   index = 1;
-   else
-   index = 0;
-
-   vgasr_priv.clients[index].pwr_state = VGA_SWITCHEROO_ON;
-   vgasr_priv.clients[index].pdev = pdev;
-   vgasr_priv.clients[index].set_gpu_state = set_gpu_state;
-   vgasr_priv.clients[index].reprobe = reprobe;
-   vgasr_priv.clients[index].can_switch = can_switch;
-   vgasr_priv.clients[index].id = -1;
+   client = kzalloc(sizeof(*client), GFP_KERNEL);
+   if (!client)
+   return -ENOMEM;
+
+   client->pwr_state = VGA_SWITCHEROO_ON;
+   client->pdev = pdev;
+   client->set_gpu_state = set_gpu_state;
+   client->reprobe = reprobe;
+   client->can_switch = can_switch;
+   client->id = -1;
if (pdev->resource[PCI_ROM_RESOURCE].flags & IORESOURCE_ROM_SHADOW)
-   vgasr_priv.clients[index].active = true;
+   client->active = true;

-   vgasr_priv.registered_clients |= (1 << index);
+   mutex_lock(_mutex);
+   list_add_tail(>list, _priv.clients);
+   vgasr_priv.registered_clients++;

/* if we get two clients + handler */
-   if (vgasr_priv.registered_clients == 0x3 && vgasr_priv.handler) {
+   if (vgasr_priv.registered_clients == 2 && vgasr_priv.handler) {
printk(KERN_INFO "vga_switcheroo: enabled\n");
vga_switcheroo_enable();
}
@@ -137,18 +140,47 @@ int vga_switcheroo_register_client(struct pci_dev *pdev,
 }
 EXPORT_SYMBOL(vga_switcheroo_register_client);

+static struct vga_switcheroo_client *
+find_client_from_pci(struct list_head *head, struct pci_dev *pdev)
+{
+   struct vga_switcheroo_client *client;
+   list_for_each_entry(client, head, list)
+   if (client->pdev == pdev)
+   return client;
+   return NULL;
+}
+
+static struct vga_switcheroo_client *
+find_client_from_id(struct list_head *head, int client_id)
+{
+   struct vga_switcheroo_client *client;
+   list_for_each_entry(client, head, list)
+   if (client->id == client_id)
+   return client;
+   return NULL;
+}
+
+static struct vga_switcheroo_client *
+find_active_client(struct list_head *head)
+{
+   struct vga_switcheroo_client *client;
+   list_for_each_entry(client, head, list)
+   if (client->active == true)
+   return client;
+   return NULL;
+}
+
 void vga_switcheroo_unregister_client(struct pci_dev *pdev)
 {
-   

[PATCH 0/2] Audio client support for VGA-switcheroo

[Takashi Iwai]

Dave,

this is a small patch series to add the support for audio clients
to VGA switcheroo.  The background problem is that the HD-audio HDMI
controller of the discrete GPU is also disabled when the graphics core
is disabled by vga-switcheroo.  This leads to a long stall of the
audio driver, or at worst, it Oopses.
  https://bugzilla.kernel.org/show_bug.cgi?id=43155

I tried to work around it only in the audio driver side, but it
doesn't seem to help.  When the graphics is disabled, the whole PCI
entry can't be accessed any longer.  Even reading a config triggers an
Oops.  So, the only option is to implement the VGA switcheroo client
for the audio.

The first patch refactors the vga-switcheroo code to be ready to
accept for more than two clients.  It's mostly a clean up using linked
lists.  The next patch implements the audio client registration.

BTW, if these patches are OK, the question remains how to merge.
Obviously I'd need more patches for HD-audio driver based on the new
vga_switcheroo_register_audio_client().  One option is to apply these
patches to a persistent branch (i.e. no rebase planned) of your tree
and pull it to my tree with more patches for HD-audio.
Does it sound good for you?


thanks,

Takashi

r600: In Diablo III when the ground is covered in water, it's all messed-up.

[Paul Menzel]

Dear Mike,


I have to remarks that unfortunately will not give a solution.

Am Mittwoch, den 09.05.2012, 20:17 -0500 schrieb Mike Mestnik:
> I found a rendering error in Diablo III, in a well there ground is
> covered in water and it's all red and flickers.
> 
> http://c566453.r53.cf2.rackcdn.com/DiabloIII-well-wine-preloader.trace.xz 
> 3.5G,
> 234665296 Bytes compressed ~234M.
> 
> EE r600_shader.c:1605 r600_shader_from_tgsi - GPR limit exceeded -
> shader requires 181 registers
> EE r600_shader.c:140 r600_pipe_shader_create - translation from TGSI
> failed !
> Rendered 621 frames in 80.724 secs, average of 7.69288 fps

1. Please turn off line wrapping for paragraphs were you paste code.

2. I guess the developers need more information what your system set up
is. That means your distribution and the program versions you are
running.


Thanks and good luck,

Paul
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120510/27ee9ebd/attachment.pgp>

[PATCH 2/2 v3] drm/exynos: added userptr feature.

[KOSAKI Motohiro]

(5/10/12 12:58 AM), Minchan Kim wrote:
> On 05/10/2012 10:39 AM, Inki Dae wrote:
>
>> Hi Jerome,
>>
>>> -Original Message-
>>> From: Jerome Glisse [mailto:j.glisse at gmail.com]
>>> Sent: Wednesday, May 09, 2012 11:46 PM
>>> To: Inki Dae
>>> Cc: airlied at linux.ie; dri-devel at lists.freedesktop.org;
>>> kyungmin.park at samsung.com; sw0312.kim at samsung.com; linux-mm at 
>>> kvack.org
>>> Subject: Re: [PATCH 2/2 v3] drm/exynos: added userptr feature.
>>>
>>> On Wed, May 9, 2012 at 2:17 AM, Inki Dae  wrote:
 this feature is used to import user space region allocated by malloc()
>>> or
 mmaped into a gem. and to guarantee the pages to user space not to be
 swapped out, the VMAs within the user space would be locked and then
>>> unlocked
 when the pages are released.

 but this lock might result in significant degradation of system
>>> performance
 because the pages couldn't be swapped out so we limit user-desired
>>> userptr
 size to pre-defined.

 Signed-off-by: Inki Dae
 Signed-off-by: Kyungmin Park
>>>
>>>
>>> Again i would like feedback from mm people (adding cc). I am not sure
>>
>> Thank you, I missed adding mm as cc.
>>
>>> locking the vma is the right anwser as i said in my previous mail,
>>> userspace can munlock it in your back, maybe VM_RESERVED is better.
>>
>> I know that with VM_RESERVED flag, also we can avoid the pages from being
>> swapped out. but these pages should be unlocked anytime we want because we
>> could allocate all pages on system and lock them, which in turn, it may
>> result in significant deterioration of system performance.(maybe other
>> processes requesting free memory would be blocked) so I used VM_LOCKED flags
>> instead. but I'm not sure this way is best also.
>>
>>> Anyway even not considering that you don't check at all that process
>>> don't go over the limit of locked page see mm/mlock.c RLIMIT_MEMLOCK
>>
>> Thank you for your advices.
>>
>>> for how it's done. Also you mlock complete vma but the userptr you get
>>> might be inside say 16M vma and you only care about 1M of userptr, if
>>> you mark the whole vma as locked than anytime a new page is fault in
>>> the vma else where than in the buffer you are interested then it got
>>> allocated for ever until the gem buffer is destroy, i am not sure of
>>> what happen to the vma on next malloc if it grows or not (i would
>>> think it won't grow at it would have different flags than new
>>> anonymous memory).
>
>
> I don't know history in detail because you didn't have sent full patches to 
> linux-mm and
> I didn't read the below code, either.
> Just read your description and reply of Jerome. Apparently, there is 
> something I missed.
>
> Your goal is to avoid swap out some user pages which is used in kernel at the 
> same time. Right?
> Let's use get_user_pages. Is there any issue you can't use it?

Maybe because get_user_pages() is fork unsafe? dunno.



> It increases page count so reclaimer can't swap out page.
> Isn't it enough?
> Marking whole VMA into MLCOKED is overkill.
>

RE: [PATCH 2/2 v3] drm/exynos: added userptr feature.

[Inki Dae]

 -Original Message-
 From: Minchan Kim [mailto:minc...@kernel.org]
 Sent: Thursday, May 10, 2012 1:58 PM
 To: Inki Dae
 Cc: 'Jerome Glisse'; airl...@linux.ie; dri-devel@lists.freedesktop.org;
 kyungmin.p...@samsung.com; sw0312@samsung.com; linux...@kvack.org
 Subject: Re: [PATCH 2/2 v3] drm/exynos: added userptr feature.
 
 On 05/10/2012 10:39 AM, Inki Dae wrote:
 
  Hi Jerome,
 
  -Original Message-
  From: Jerome Glisse [mailto:j.gli...@gmail.com]
  Sent: Wednesday, May 09, 2012 11:46 PM
  To: Inki Dae
  Cc: airl...@linux.ie; dri-devel@lists.freedesktop.org;
  kyungmin.p...@samsung.com; sw0312@samsung.com; linux...@kvack.org
  Subject: Re: [PATCH 2/2 v3] drm/exynos: added userptr feature.
 
  On Wed, May 9, 2012 at 2:17 AM, Inki Dae inki@samsung.com wrote:
  this feature is used to import user space region allocated by malloc()
  or
  mmaped into a gem. and to guarantee the pages to user space not to be
  swapped out, the VMAs within the user space would be locked and then
  unlocked
  when the pages are released.
 
  but this lock might result in significant degradation of system
  performance
  because the pages couldn't be swapped out so we limit user-desired
  userptr
  size to pre-defined.
 
  Signed-off-by: Inki Dae inki@samsung.com
  Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 
 
  Again i would like feedback from mm people (adding cc). I am not sure
 
  Thank you, I missed adding mm as cc.
 
  locking the vma is the right anwser as i said in my previous mail,
  userspace can munlock it in your back, maybe VM_RESERVED is better.
 
  I know that with VM_RESERVED flag, also we can avoid the pages from
 being
  swapped out. but these pages should be unlocked anytime we want because
 we
  could allocate all pages on system and lock them, which in turn, it may
  result in significant deterioration of system performance.(maybe other
  processes requesting free memory would be blocked) so I used VM_LOCKED
 flags
  instead. but I'm not sure this way is best also.
 
  Anyway even not considering that you don't check at all that process
  don't go over the limit of locked page see mm/mlock.c RLIMIT_MEMLOCK
 
  Thank you for your advices.
 
  for how it's done. Also you mlock complete vma but the userptr you get
  might be inside say 16M vma and you only care about 1M of userptr, if
  you mark the whole vma as locked than anytime a new page is fault in
  the vma else where than in the buffer you are interested then it got
  allocated for ever until the gem buffer is destroy, i am not sure of
  what happen to the vma on next malloc if it grows or not (i would
  think it won't grow at it would have different flags than new
  anonymous memory).
 
 
 I don't know history in detail because you didn't have sent full patches
 to linux-mm and
 I didn't read the below code, either.
 Just read your description and reply of Jerome. Apparently, there is
 something I missed.
 
 Your goal is to avoid swap out some user pages which is used in kernel at
 the same time. Right?
 Let's use get_user_pages. Is there any issue you can't use it?
 It increases page count so reclaimer can't swap out page.
 Isn't it enough?
 Marking whole VMA into MLCOKED is overkill.
 

As I mentioned, we are already using get_user_pages. as you said, this
function increases page count but just only things to the user address space
cpu already accessed. other would be allocated by page fault hander once
get_user_pages call. if so... ok, after that refcount(page-_count) of the
pages user already accessed would have 2 and just 1 for other all pages. so
we may have to consider only pages never accessed by cpu to be locked to
avoid from swapped out.

Thanks,
Inki Dae

 --
 Kind regards,
 Minchan Kim

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/2] Audio client support for VGA-switcheroo

[Takashi Iwai]

Dave,

this is a small patch series to add the support for audio clients
to VGA switcheroo.  The background problem is that the HD-audio HDMI
controller of the discrete GPU is also disabled when the graphics core
is disabled by vga-switcheroo.  This leads to a long stall of the
audio driver, or at worst, it Oopses.
  https://bugzilla.kernel.org/show_bug.cgi?id=43155

I tried to work around it only in the audio driver side, but it
doesn't seem to help.  When the graphics is disabled, the whole PCI
entry can't be accessed any longer.  Even reading a config triggers an
Oops.  So, the only option is to implement the VGA switcheroo client
for the audio.

The first patch refactors the vga-switcheroo code to be ready to
accept for more than two clients.  It's mostly a clean up using linked
lists.  The next patch implements the audio client registration.

BTW, if these patches are OK, the question remains how to merge.
Obviously I'd need more patches for HD-audio driver based on the new
vga_switcheroo_register_audio_client().  One option is to apply these
patches to a persistent branch (i.e. no rebase planned) of your tree
and pull it to my tree with more patches for HD-audio.
Does it sound good for you?


thanks,

Takashi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] vga_switcheroo: Refactor using linked list

[Takashi Iwai]

Refactor the code base a bit for the further work to adapt more clients.

Signed-off-by: Takashi Iwai ti...@suse.de
---
 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/vga/vga_switcheroo.c
index 58434e8..c91573f 100644
--- a/drivers/gpu/vga/vga_switcheroo.c
+++ b/drivers/gpu/vga/vga_switcheroo.c
@@ -37,6 +37,7 @@ struct vga_switcheroo_client {
bool (*can_switch)(struct pci_dev *pdev);
int id;
bool active;
+   struct list_head list;
 };
 
 static DEFINE_MUTEX(vgasr_mutex);
@@ -51,7 +52,7 @@ struct vgasr_priv {
struct dentry *switch_file;
 
int registered_clients;
-   struct vga_switcheroo_client clients[VGA_SWITCHEROO_MAX_CLIENTS];
+   struct list_head clients;
 
struct vga_switcheroo_handler *handler;
 };
@@ -60,7 +61,9 @@ static int vga_switcheroo_debugfs_init(struct vgasr_priv 
*priv);
 static void vga_switcheroo_debugfs_fini(struct vgasr_priv *priv);
 
 /* only one switcheroo per system */
-static struct vgasr_priv vgasr_priv;
+static struct vgasr_priv vgasr_priv = {
+   .clients = LIST_HEAD_INIT(vgasr_priv.clients),
+};
 
 int vga_switcheroo_register_handler(struct vga_switcheroo_handler *handler)
 {
@@ -86,17 +89,18 @@ EXPORT_SYMBOL(vga_switcheroo_unregister_handler);
 
 static void vga_switcheroo_enable(void)
 {
-   int i;
int ret;
+   struct vga_switcheroo_client *client;
+
/* call the handler to init */
vgasr_priv.handler-init();
 
-   for (i = 0; i  VGA_SWITCHEROO_MAX_CLIENTS; i++) {
-   ret = 
vgasr_priv.handler-get_client_id(vgasr_priv.clients[i].pdev);
+   list_for_each_entry(client, vgasr_priv.clients, list) {
+   ret = vgasr_priv.handler-get_client_id(client-pdev);
if (ret  0)
return;
 
-   vgasr_priv.clients[i].id = ret;
+   client-id = ret;
}
vga_switcheroo_debugfs_init(vgasr_priv);
vgasr_priv.active = true;
@@ -107,28 +111,27 @@ int vga_switcheroo_register_client(struct pci_dev *pdev,
   void (*reprobe)(struct pci_dev *pdev),
   bool (*can_switch)(struct pci_dev *pdev))
 {
-   int index;
+   struct vga_switcheroo_client *client;
 
-   mutex_lock(vgasr_mutex);
-   /* don't do IGD vs DIS here */
-   if (vgasr_priv.registered_clients  1)
-   index = 1;
-   else
-   index = 0;
-
-   vgasr_priv.clients[index].pwr_state = VGA_SWITCHEROO_ON;
-   vgasr_priv.clients[index].pdev = pdev;
-   vgasr_priv.clients[index].set_gpu_state = set_gpu_state;
-   vgasr_priv.clients[index].reprobe = reprobe;
-   vgasr_priv.clients[index].can_switch = can_switch;
-   vgasr_priv.clients[index].id = -1;
+   client = kzalloc(sizeof(*client), GFP_KERNEL);
+   if (!client)
+   return -ENOMEM;
+
+   client-pwr_state = VGA_SWITCHEROO_ON;
+   client-pdev = pdev;
+   client-set_gpu_state = set_gpu_state;
+   client-reprobe = reprobe;
+   client-can_switch = can_switch;
+   client-id = -1;
if (pdev-resource[PCI_ROM_RESOURCE].flags  IORESOURCE_ROM_SHADOW)
-   vgasr_priv.clients[index].active = true;
+   client-active = true;
 
-   vgasr_priv.registered_clients |= (1  index);
+   mutex_lock(vgasr_mutex);
+   list_add_tail(client-list, vgasr_priv.clients);
+   vgasr_priv.registered_clients++;
 
/* if we get two clients + handler */
-   if (vgasr_priv.registered_clients == 0x3  vgasr_priv.handler) {
+   if (vgasr_priv.registered_clients == 2  vgasr_priv.handler) {
printk(KERN_INFO vga_switcheroo: enabled\n);
vga_switcheroo_enable();
}
@@ -137,18 +140,47 @@ int vga_switcheroo_register_client(struct pci_dev *pdev,
 }
 EXPORT_SYMBOL(vga_switcheroo_register_client);
 
+static struct vga_switcheroo_client *
+find_client_from_pci(struct list_head *head, struct pci_dev *pdev)
+{
+   struct vga_switcheroo_client *client;
+   list_for_each_entry(client, head, list)
+   if (client-pdev == pdev)
+   return client;
+   return NULL;
+}
+
+static struct vga_switcheroo_client *
+find_client_from_id(struct list_head *head, int client_id)
+{
+   struct vga_switcheroo_client *client;
+   list_for_each_entry(client, head, list)
+   if (client-id == client_id)
+   return client;
+   return NULL;
+}
+
+static struct vga_switcheroo_client *
+find_active_client(struct list_head *head)
+{
+   struct vga_switcheroo_client *client;
+   list_for_each_entry(client, head, list)
+   if (client-active == true)
+   return client;
+   return NULL;
+}
+
 void vga_switcheroo_unregister_client(struct 

[PATCH 2/2] vga_switcheroo: Add the support for audio clients

[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 explicity at registration time unlike
the video controller.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43155

Signed-off-by: Takashi Iwai ti...@suse.de
---
 drivers/gpu/vga/vga_switcheroo.c |   84 ++
 include/linux/vga_switcheroo.h   |   10 +
 2 files changed, 78 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
index c91573f..df25ea6 100644
--- a/drivers/gpu/vga/vga_switcheroo.c
+++ b/drivers/gpu/vga/vga_switcheroo.c
@@ -57,6 +57,11 @@ struct vgasr_priv {
struct vga_switcheroo_handler *handler;
 };
 
+#define ID_BIT_AUDIO   0x100
+#define client_is_audio(c) ((c)-id  ID_BIT_AUDIO)
+#define client_is_vga(c)   ((c)-id == -1 || !client_is_audio(c))
+#define client_id(c)   ((c)-id  ~ID_BIT_AUDIO)
+
 static int vga_switcheroo_debugfs_init(struct vgasr_priv *priv);
 static void vga_switcheroo_debugfs_fini(struct vgasr_priv *priv);
 
@@ -96,6 +101,8 @@ static void vga_switcheroo_enable(void)
vgasr_priv.handler-init();
 
list_for_each_entry(client, vgasr_priv.clients, list) {
+   if (client-id != -1)
+   continue;
ret = vgasr_priv.handler-get_client_id(client-pdev);
if (ret  0)
return;
@@ -106,10 +113,11 @@ static void vga_switcheroo_enable(void)
vgasr_priv.active = true;
 }
 
-int vga_switcheroo_register_client(struct pci_dev *pdev,
-  void (*set_gpu_state)(struct pci_dev *pdev, 
enum vga_switcheroo_state),
-  void (*reprobe)(struct pci_dev *pdev),
-  bool (*can_switch)(struct pci_dev *pdev))
+static int register_client(struct pci_dev *pdev,
+   void (*set_gpu_state)(struct pci_dev *pdev, enum vga_switcheroo_state),
+   void (*reprobe)(struct pci_dev *pdev),
+   bool (*can_switch)(struct pci_dev *pdev),
+   int id, bool active)
 {
struct vga_switcheroo_client *client;
 
@@ -122,24 +130,48 @@ int vga_switcheroo_register_client(struct pci_dev *pdev,
client-set_gpu_state = set_gpu_state;
client-reprobe = reprobe;
client-can_switch = can_switch;
-   client-id = -1;
-   if (pdev-resource[PCI_ROM_RESOURCE].flags  IORESOURCE_ROM_SHADOW)
-   client-active = true;
+   client-id = id;
+   client-active = active;
 
mutex_lock(vgasr_mutex);
list_add_tail(client-list, vgasr_priv.clients);
-   vgasr_priv.registered_clients++;
+   if (client_is_vga(client))
+   vgasr_priv.registered_clients++;
 
/* if we get two clients + handler */
-   if (vgasr_priv.registered_clients == 2  vgasr_priv.handler) {
+   if (!vgasr_priv.active 
+   vgasr_priv.registered_clients == 2  vgasr_priv.handler) {
printk(KERN_INFO vga_switcheroo: enabled\n);
vga_switcheroo_enable();
}
mutex_unlock(vgasr_mutex);
return 0;
 }
+
+int vga_switcheroo_register_client(struct pci_dev *pdev,
+  void (*set_gpu_state)(struct pci_dev *pdev, 
enum vga_switcheroo_state),
+  void (*reprobe)(struct pci_dev *pdev),
+  bool (*can_switch)(struct pci_dev *pdev))
+{
+   bool active = false;
+   if (pdev-resource[PCI_ROM_RESOURCE].flags  IORESOURCE_ROM_SHADOW)
+   active = true;
+   return register_client(pdev, set_gpu_state, reprobe, can_switch,
+  -1, active);
+}
 EXPORT_SYMBOL(vga_switcheroo_register_client);
 
+int vga_switcheroo_register_audio_client(struct pci_dev *pdev,
+   void (*set_gpu_state)(struct pci_dev *pdev, enum vga_switcheroo_state),
+   void (*reprobe)(struct pci_dev *pdev),
+   bool (*can_switch)(struct pci_dev *pdev),
+   int id, bool active)
+{
+   return register_client(pdev, set_gpu_state, reprobe, can_switch,
+  id | ID_BIT_AUDIO, active);
+}
+EXPORT_SYMBOL(vga_switcheroo_register_audio_client);
+
 static struct vga_switcheroo_client *
 find_client_from_pci(struct list_head *head, struct pci_dev *pdev)
 {
@@ -165,7 +197,7 @@ find_active_client(struct list_head *head)
 {
struct vga_switcheroo_client *client;
list_for_each_entry(client, head, list)
-   if (client-active == true)
+   if (client-active  client_is_vga(client))
return client;
return NULL;
 }
@@ -177,13 +209,16 @@ void vga_switcheroo_unregister_client(struct pci_dev 
*pdev)
mutex_lock(vgasr_mutex);
client = find_client_from_pci(vgasr_priv.clients, pdev);
if (client) {
+   if 

Re: [PATCH 0/2] Audio client support for VGA-switcheroo

[Takashi Iwai]

At Thu, 10 May 2012 09:08:38 +0200,
Takashi Iwai wrote:
 
 Dave,
 
 this is a small patch series to add the support for audio clients
 to VGA switcheroo.  The background problem is that the HD-audio HDMI
 controller of the discrete GPU is also disabled when the graphics core
 is disabled by vga-switcheroo.  This leads to a long stall of the
 audio driver, or at worst, it Oopses.
   https://bugzilla.kernel.org/show_bug.cgi?id=43155
 
 I tried to work around it only in the audio driver side, but it
 doesn't seem to help.  When the graphics is disabled, the whole PCI
 entry can't be accessed any longer.  Even reading a config triggers an
 Oops.  So, the only option is to implement the VGA switcheroo client
 for the audio.
 
 The first patch refactors the vga-switcheroo code to be ready to
 accept for more than two clients.  It's mostly a clean up using linked
 lists.  The next patch implements the audio client registration.
 
 BTW, if these patches are OK, the question remains how to merge.
 Obviously I'd need more patches for HD-audio driver based on the new
 vga_switcheroo_register_audio_client().  One option is to apply these
 patches to a persistent branch (i.e. no rebase planned) of your tree
 and pull it to my tree with more patches for HD-audio.
 Does it sound good for you?

Or, if you prefer, just pull from topic/vga-switcheroo branch of my tree:
  git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git 
topic/vga-switcheroo


Takashi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: r600: In Diablo III when the ground is covered in water, it's all messed-up.

[Paul Menzel]

Dear Mike,


I have to remarks that unfortunately will not give a solution.

Am Mittwoch, den 09.05.2012, 20:17 -0500 schrieb Mike Mestnik:
 I found a rendering error in Diablo III, in a well there ground is
 covered in water and it's all red and flickers.
 
 http://c566453.r53.cf2.rackcdn.com/DiabloIII-well-wine-preloader.trace.xz 
 3.5G,
 234665296 Bytes compressed ~234M.
 
 EE r600_shader.c:1605 r600_shader_from_tgsi - GPR limit exceeded -
 shader requires 181 registers
 EE r600_shader.c:140 r600_pipe_shader_create - translation from TGSI
 failed !
 Rendered 621 frames in 80.724 secs, average of 7.69288 fps

1. Please turn off line wrapping for paragraphs were you paste code.

2. I guess the developers need more information what your system set up
is. That means your distribution and the program versions you are
running.


Thanks and good luck,

Paul


signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2 v3] drm/exynos: added userptr feature.

[InKi Dae]

2012/5/10, Minchan Kim minc...@kernel.org:
 On 05/10/2012 03:57 PM, Inki Dae wrote:



 -Original Message-
 From: Minchan Kim [mailto:minc...@kernel.org]
 Sent: Thursday, May 10, 2012 1:58 PM
 To: Inki Dae
 Cc: 'Jerome Glisse'; airl...@linux.ie; dri-devel@lists.freedesktop.org;
 kyungmin.p...@samsung.com; sw0312@samsung.com; linux...@kvack.org
 Subject: Re: [PATCH 2/2 v3] drm/exynos: added userptr feature.

 On 05/10/2012 10:39 AM, Inki Dae wrote:

 Hi Jerome,

 -Original Message-
 From: Jerome Glisse [mailto:j.gli...@gmail.com]
 Sent: Wednesday, May 09, 2012 11:46 PM
 To: Inki Dae
 Cc: airl...@linux.ie; dri-devel@lists.freedesktop.org;
 kyungmin.p...@samsung.com; sw0312@samsung.com; linux...@kvack.org
 Subject: Re: [PATCH 2/2 v3] drm/exynos: added userptr feature.

 On Wed, May 9, 2012 at 2:17 AM, Inki Dae inki@samsung.com wrote:
 this feature is used to import user space region allocated by
 malloc()
 or
 mmaped into a gem. and to guarantee the pages to user space not to be
 swapped out, the VMAs within the user space would be locked and then
 unlocked
 when the pages are released.

 but this lock might result in significant degradation of system
 performance
 because the pages couldn't be swapped out so we limit user-desired
 userptr
 size to pre-defined.

 Signed-off-by: Inki Dae inki@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com


 Again i would like feedback from mm people (adding cc). I am not sure

 Thank you, I missed adding mm as cc.

 locking the vma is the right anwser as i said in my previous mail,
 userspace can munlock it in your back, maybe VM_RESERVED is better.

 I know that with VM_RESERVED flag, also we can avoid the pages from
 being
 swapped out. but these pages should be unlocked anytime we want because
 we
 could allocate all pages on system and lock them, which in turn, it may
 result in significant deterioration of system performance.(maybe other
 processes requesting free memory would be blocked) so I used VM_LOCKED
 flags
 instead. but I'm not sure this way is best also.

 Anyway even not considering that you don't check at all that process
 don't go over the limit of locked page see mm/mlock.c RLIMIT_MEMLOCK

 Thank you for your advices.

 for how it's done. Also you mlock complete vma but the userptr you get
 might be inside say 16M vma and you only care about 1M of userptr, if
 you mark the whole vma as locked than anytime a new page is fault in
 the vma else where than in the buffer you are interested then it got
 allocated for ever until the gem buffer is destroy, i am not sure of
 what happen to the vma on next malloc if it grows or not (i would
 think it won't grow at it would have different flags than new
 anonymous memory).


 I don't know history in detail because you didn't have sent full patches
 to linux-mm and
 I didn't read the below code, either.
 Just read your description and reply of Jerome. Apparently, there is
 something I missed.

 Your goal is to avoid swap out some user pages which is used in kernel
 at
 the same time. Right?
 Let's use get_user_pages. Is there any issue you can't use it?
 It increases page count so reclaimer can't swap out page.
 Isn't it enough?
 Marking whole VMA into MLCOKED is overkill.


 As I mentioned, we are already using get_user_pages. as you said, this
 function increases page count but just only things to the user address
 space
 cpu already accessed. other would be allocated by page fault hander once
 get_user_pages call. if so... ok, after that refcount(page-_count) of
 the


 Not true. Look __get_user_pages.
 It handles case you mentioned by handle_mm_fault.
 Do I miss something?


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 and then in turn next process like swap in
to fill physical frame number into entry of the page faulted. of
course, if user never access the buffer and requested userptr then
handle_mm_fault would be called by __get_user_pages. please give me
any comments if there is my missing point.

Thanks,
Inki Dae


 pages user already accessed would have 2 and just 1 for other all pages.
 so
 we may have to consider only pages never accessed by cpu to be locked to
 avoid from swapped out.

 Thanks,
 Inki Dae

 --
 Kind regards,
 Minchan Kim

 --
 To unsubscribe, send a message with 'unsubscribe linux-mm' in
 the body to majord...@kvack.org.  For more info on Linux MM,
 see: http://www.linux-mm.org/ .
 Fight unfair telecom internet charges in Canada: sign
 http://stopthemeter.ca/
 Don't email: a href=mailto:d...@kvack.org; em...@kvack.org /a




 --
 Kind regards,
 Minchan Kim

 --
 To unsubscribe, send a message with 'unsubscribe linux-mm' in
 the body to majord...@kvack.org.  For more info on Linux MM,
 see: 

Re: [PATCH 2/2 v3] drm/exynos: added userptr feature.

[Minchan Kim]

On 05/10/2012 04:56 PM, Minchan Kim wrote:

 On 05/10/2012 04:31 PM, Kyungmin Park wrote:
 
 On 5/10/12, Minchan Kim minc...@kernel.org wrote:
 On 05/10/2012 03:53 PM, KOSAKI Motohiro wrote:

 (5/10/12 12:58 AM), Minchan Kim wrote:
 On 05/10/2012 10:39 AM, Inki Dae wrote:

 Hi Jerome,

 -Original Message-
 From: Jerome Glisse [mailto:j.gli...@gmail.com]
 Sent: Wednesday, May 09, 2012 11:46 PM
 To: Inki Dae
 Cc: airl...@linux.ie; dri-devel@lists.freedesktop.org;
 kyungmin.p...@samsung.com; sw0312@samsung.com; linux...@kvack.org
 Subject: Re: [PATCH 2/2 v3] drm/exynos: added userptr feature.

 On Wed, May 9, 2012 at 2:17 AM, Inki Daeinki@samsung.com  wrote:
 this feature is used to import user space region allocated by
 malloc()
 or
 mmaped into a gem. and to guarantee the pages to user space not to be
 swapped out, the VMAs within the user space would be locked and then
 unlocked
 when the pages are released.

 but this lock might result in significant degradation of system
 performance
 because the pages couldn't be swapped out so we limit user-desired
 userptr
 size to pre-defined.

 Signed-off-by: Inki Daeinki@samsung.com
 Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com


 Again i would like feedback from mm people (adding cc). I am not sure

 Thank you, I missed adding mm as cc.

 locking the vma is the right anwser as i said in my previous mail,
 userspace can munlock it in your back, maybe VM_RESERVED is better.

 I know that with VM_RESERVED flag, also we can avoid the pages from
 being
 swapped out. but these pages should be unlocked anytime we want
 because we
 could allocate all pages on system and lock them, which in turn, it may
 result in significant deterioration of system performance.(maybe other
 processes requesting free memory would be blocked) so I used
 VM_LOCKED flags
 instead. but I'm not sure this way is best also.

 Anyway even not considering that you don't check at all that process
 don't go over the limit of locked page see mm/mlock.c RLIMIT_MEMLOCK

 Thank you for your advices.

 for how it's done. Also you mlock complete vma but the userptr you get
 might be inside say 16M vma and you only care about 1M of userptr, if
 you mark the whole vma as locked than anytime a new page is fault in
 the vma else where than in the buffer you are interested then it got
 allocated for ever until the gem buffer is destroy, i am not sure of
 what happen to the vma on next malloc if it grows or not (i would
 think it won't grow at it would have different flags than new
 anonymous memory).


 I don't know history in detail because you didn't have sent full
 patches to linux-mm and
 I didn't read the below code, either.
 Just read your description and reply of Jerome. Apparently, there is
 something I missed.

 Your goal is to avoid swap out some user pages which is used in kernel
 at the same time. Right?
 Let's use get_user_pages. Is there any issue you can't use it?

 Maybe because get_user_pages() is fork unsafe? dunno.


 If there is such problem, I think user program should handle it by
 MADV_DONTFORK
 and make to allow write by only parent process.
 Please read the original patches and discuss the root cause. Does it
 harm to pass user space memory to kernel space and how to make is
 possible at DRM?
 
 
 Where can I read original discussion history?
 I am not expert of DRAM so I can answer only mm stuff and it's why Jerome 
 ccing mm-list.

 ^^^ silly typo
 DRM

-- 
Kind regards,
Minchan Kim

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2 v3] drm/exynos: added userptr feature.

[KOSAKI Motohiro]

(5/10/12 12:58 AM), Minchan Kim wrote:

On 05/10/2012 10:39 AM, Inki Dae wrote:


Hi Jerome,


-Original Message-
From: Jerome Glisse [mailto:j.gli...@gmail.com]
Sent: Wednesday, May 09, 2012 11:46 PM
To: Inki Dae
Cc: airl...@linux.ie; dri-devel@lists.freedesktop.org;
kyungmin.p...@samsung.com; sw0312@samsung.com; linux...@kvack.org
Subject: Re: [PATCH 2/2 v3] drm/exynos: added userptr feature.

On Wed, May 9, 2012 at 2:17 AM, Inki Daeinki@samsung.com  wrote:

this feature is used to import user space region allocated by malloc()

or

mmaped into a gem. and to guarantee the pages to user space not to be
swapped out, the VMAs within the user space would be locked and then

unlocked

when the pages are released.

but this lock might result in significant degradation of system

performance

because the pages couldn't be swapped out so we limit user-desired

userptr

size to pre-defined.

Signed-off-by: Inki Daeinki@samsung.com
Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com



Again i would like feedback from mm people (adding cc). I am not sure


Thank you, I missed adding mm as cc.


locking the vma is the right anwser as i said in my previous mail,
userspace can munlock it in your back, maybe VM_RESERVED is better.


I know that with VM_RESERVED flag, also we can avoid the pages from being
swapped out. but these pages should be unlocked anytime we want because we
could allocate all pages on system and lock them, which in turn, it may
result in significant deterioration of system performance.(maybe other
processes requesting free memory would be blocked) so I used VM_LOCKED flags
instead. but I'm not sure this way is best also.


Anyway even not considering that you don't check at all that process
don't go over the limit of locked page see mm/mlock.c RLIMIT_MEMLOCK


Thank you for your advices.


for how it's done. Also you mlock complete vma but the userptr you get
might be inside say 16M vma and you only care about 1M of userptr, if
you mark the whole vma as locked than anytime a new page is fault in
the vma else where than in the buffer you are interested then it got
allocated for ever until the gem buffer is destroy, i am not sure of
what happen to the vma on next malloc if it grows or not (i would
think it won't grow at it would have different flags than new
anonymous memory).



I don't know history in detail because you didn't have sent full patches to 
linux-mm and
I didn't read the below code, either.
Just read your description and reply of Jerome. Apparently, there is something 
I missed.

Your goal is to avoid swap out some user pages which is used in kernel at the 
same time. Right?
Let's use get_user_pages. Is there any issue you can't use it?


Maybe because get_user_pages() is fork unsafe? dunno.




It increases page count so reclaimer can't swap out page.
Isn't it enough?
Marking whole VMA into MLCOKED is overkill.



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2 v3] drm/exynos: added userptr feature.

[Minchan Kim]

On 05/10/2012 03:57 PM, Inki Dae wrote:

 
 
 -Original Message-
 From: Minchan Kim [mailto:minc...@kernel.org]
 Sent: Thursday, May 10, 2012 1:58 PM
 To: Inki Dae
 Cc: 'Jerome Glisse'; airl...@linux.ie; dri-devel@lists.freedesktop.org;
 kyungmin.p...@samsung.com; sw0312@samsung.com; linux...@kvack.org
 Subject: Re: [PATCH 2/2 v3] drm/exynos: added userptr feature.

 On 05/10/2012 10:39 AM, Inki Dae wrote:

 Hi Jerome,

 -Original Message-
 From: Jerome Glisse [mailto:j.gli...@gmail.com]
 Sent: Wednesday, May 09, 2012 11:46 PM
 To: Inki Dae
 Cc: airl...@linux.ie; dri-devel@lists.freedesktop.org;
 kyungmin.p...@samsung.com; sw0312@samsung.com; linux...@kvack.org
 Subject: Re: [PATCH 2/2 v3] drm/exynos: added userptr feature.

 On Wed, May 9, 2012 at 2:17 AM, Inki Dae inki@samsung.com wrote:
 this feature is used to import user space region allocated by malloc()
 or
 mmaped into a gem. and to guarantee the pages to user space not to be
 swapped out, the VMAs within the user space would be locked and then
 unlocked
 when the pages are released.

 but this lock might result in significant degradation of system
 performance
 because the pages couldn't be swapped out so we limit user-desired
 userptr
 size to pre-defined.

 Signed-off-by: Inki Dae inki@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com


 Again i would like feedback from mm people (adding cc). I am not sure

 Thank you, I missed adding mm as cc.

 locking the vma is the right anwser as i said in my previous mail,
 userspace can munlock it in your back, maybe VM_RESERVED is better.

 I know that with VM_RESERVED flag, also we can avoid the pages from
 being
 swapped out. but these pages should be unlocked anytime we want because
 we
 could allocate all pages on system and lock them, which in turn, it may
 result in significant deterioration of system performance.(maybe other
 processes requesting free memory would be blocked) so I used VM_LOCKED
 flags
 instead. but I'm not sure this way is best also.

 Anyway even not considering that you don't check at all that process
 don't go over the limit of locked page see mm/mlock.c RLIMIT_MEMLOCK

 Thank you for your advices.

 for how it's done. Also you mlock complete vma but the userptr you get
 might be inside say 16M vma and you only care about 1M of userptr, if
 you mark the whole vma as locked than anytime a new page is fault in
 the vma else where than in the buffer you are interested then it got
 allocated for ever until the gem buffer is destroy, i am not sure of
 what happen to the vma on next malloc if it grows or not (i would
 think it won't grow at it would have different flags than new
 anonymous memory).


 I don't know history in detail because you didn't have sent full patches
 to linux-mm and
 I didn't read the below code, either.
 Just read your description and reply of Jerome. Apparently, there is
 something I missed.

 Your goal is to avoid swap out some user pages which is used in kernel at
 the same time. Right?
 Let's use get_user_pages. Is there any issue you can't use it?
 It increases page count so reclaimer can't swap out page.
 Isn't it enough?
 Marking whole VMA into MLCOKED is overkill.

 
 As I mentioned, we are already using get_user_pages. as you said, this
 function increases page count but just only things to the user address space
 cpu already accessed. other would be allocated by page fault hander once
 get_user_pages call. if so... ok, after that refcount(page-_count) of the


Not true. Look __get_user_pages.
It handles case you mentioned by handle_mm_fault.
Do I miss something?

 pages user already accessed would have 2 and just 1 for other all pages. so
 we may have to consider only pages never accessed by cpu to be locked to
 avoid from swapped out.
 
 Thanks,
 Inki Dae
 
 --
 Kind regards,
 Minchan Kim
 
 --
 To unsubscribe, send a message with 'unsubscribe linux-mm' in
 the body to majord...@kvack.org.  For more info on Linux MM,
 see: http://www.linux-mm.org/ .
 Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
 Don't email: a href=mailto:d...@kvack.org; em...@kvack.org /a
 



-- 
Kind regards,
Minchan Kim
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2 v3] drm/exynos: added userptr feature.

[Minchan Kim]

On 05/10/2012 03:53 PM, KOSAKI Motohiro wrote:

 (5/10/12 12:58 AM), Minchan Kim wrote:
 On 05/10/2012 10:39 AM, Inki Dae wrote:

 Hi Jerome,

 -Original Message-
 From: Jerome Glisse [mailto:j.gli...@gmail.com]
 Sent: Wednesday, May 09, 2012 11:46 PM
 To: Inki Dae
 Cc: airl...@linux.ie; dri-devel@lists.freedesktop.org;
 kyungmin.p...@samsung.com; sw0312@samsung.com; linux...@kvack.org
 Subject: Re: [PATCH 2/2 v3] drm/exynos: added userptr feature.

 On Wed, May 9, 2012 at 2:17 AM, Inki Daeinki@samsung.com  wrote:
 this feature is used to import user space region allocated by malloc()
 or
 mmaped into a gem. and to guarantee the pages to user space not to be
 swapped out, the VMAs within the user space would be locked and then
 unlocked
 when the pages are released.

 but this lock might result in significant degradation of system
 performance
 because the pages couldn't be swapped out so we limit user-desired
 userptr
 size to pre-defined.

 Signed-off-by: Inki Daeinki@samsung.com
 Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com


 Again i would like feedback from mm people (adding cc). I am not sure

 Thank you, I missed adding mm as cc.

 locking the vma is the right anwser as i said in my previous mail,
 userspace can munlock it in your back, maybe VM_RESERVED is better.

 I know that with VM_RESERVED flag, also we can avoid the pages from
 being
 swapped out. but these pages should be unlocked anytime we want
 because we
 could allocate all pages on system and lock them, which in turn, it may
 result in significant deterioration of system performance.(maybe other
 processes requesting free memory would be blocked) so I used
 VM_LOCKED flags
 instead. but I'm not sure this way is best also.

 Anyway even not considering that you don't check at all that process
 don't go over the limit of locked page see mm/mlock.c RLIMIT_MEMLOCK

 Thank you for your advices.

 for how it's done. Also you mlock complete vma but the userptr you get
 might be inside say 16M vma and you only care about 1M of userptr, if
 you mark the whole vma as locked than anytime a new page is fault in
 the vma else where than in the buffer you are interested then it got
 allocated for ever until the gem buffer is destroy, i am not sure of
 what happen to the vma on next malloc if it grows or not (i would
 think it won't grow at it would have different flags than new
 anonymous memory).


 I don't know history in detail because you didn't have sent full
 patches to linux-mm and
 I didn't read the below code, either.
 Just read your description and reply of Jerome. Apparently, there is
 something I missed.

 Your goal is to avoid swap out some user pages which is used in kernel
 at the same time. Right?
 Let's use get_user_pages. Is there any issue you can't use it?
 
 Maybe because get_user_pages() is fork unsafe? dunno.


If there is such problem, I think user program should handle it by 
MADV_DONTFORK 
and make to allow write by only parent process.

-- 
Kind regards,
Minchan Kim
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2 v3] drm/exynos: added userptr feature.

[Minchan Kim]

On 05/10/2012 04:31 PM, Kyungmin Park wrote:

 On 5/10/12, Minchan Kim minc...@kernel.org wrote:
 On 05/10/2012 03:53 PM, KOSAKI Motohiro wrote:

 (5/10/12 12:58 AM), Minchan Kim wrote:
 On 05/10/2012 10:39 AM, Inki Dae wrote:

 Hi Jerome,

 -Original Message-
 From: Jerome Glisse [mailto:j.gli...@gmail.com]
 Sent: Wednesday, May 09, 2012 11:46 PM
 To: Inki Dae
 Cc: airl...@linux.ie; dri-devel@lists.freedesktop.org;
 kyungmin.p...@samsung.com; sw0312@samsung.com; linux...@kvack.org
 Subject: Re: [PATCH 2/2 v3] drm/exynos: added userptr feature.

 On Wed, May 9, 2012 at 2:17 AM, Inki Daeinki@samsung.com  wrote:
 this feature is used to import user space region allocated by
 malloc()
 or
 mmaped into a gem. and to guarantee the pages to user space not to be
 swapped out, the VMAs within the user space would be locked and then
 unlocked
 when the pages are released.

 but this lock might result in significant degradation of system
 performance
 because the pages couldn't be swapped out so we limit user-desired
 userptr
 size to pre-defined.

 Signed-off-by: Inki Daeinki@samsung.com
 Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com


 Again i would like feedback from mm people (adding cc). I am not sure

 Thank you, I missed adding mm as cc.

 locking the vma is the right anwser as i said in my previous mail,
 userspace can munlock it in your back, maybe VM_RESERVED is better.

 I know that with VM_RESERVED flag, also we can avoid the pages from
 being
 swapped out. but these pages should be unlocked anytime we want
 because we
 could allocate all pages on system and lock them, which in turn, it may
 result in significant deterioration of system performance.(maybe other
 processes requesting free memory would be blocked) so I used
 VM_LOCKED flags
 instead. but I'm not sure this way is best also.

 Anyway even not considering that you don't check at all that process
 don't go over the limit of locked page see mm/mlock.c RLIMIT_MEMLOCK

 Thank you for your advices.

 for how it's done. Also you mlock complete vma but the userptr you get
 might be inside say 16M vma and you only care about 1M of userptr, if
 you mark the whole vma as locked than anytime a new page is fault in
 the vma else where than in the buffer you are interested then it got
 allocated for ever until the gem buffer is destroy, i am not sure of
 what happen to the vma on next malloc if it grows or not (i would
 think it won't grow at it would have different flags than new
 anonymous memory).


 I don't know history in detail because you didn't have sent full
 patches to linux-mm and
 I didn't read the below code, either.
 Just read your description and reply of Jerome. Apparently, there is
 something I missed.

 Your goal is to avoid swap out some user pages which is used in kernel
 at the same time. Right?
 Let's use get_user_pages. Is there any issue you can't use it?

 Maybe because get_user_pages() is fork unsafe? dunno.


 If there is such problem, I think user program should handle it by
 MADV_DONTFORK
 and make to allow write by only parent process.
 Please read the original patches and discuss the root cause. Does it
 harm to pass user space memory to kernel space and how to make is
 possible at DRM?


Where can I read original discussion history?
I am not expert of DRAM so I can answer only mm stuff and it's why Jerome ccing 
mm-list.
About mm stuff, I think it's no harm for kernel to use user space memory if it 
uses carefully.
If you are saying about permission, at least, DRM code can check it by 
can_do_mlock and checking lock_limit.
If you are saying another security, I'm not right person to discuss it.
please Ccing secur...@kernel.org.

Thanks.

 
 Thank you,
 Kyungmin Park

 --
 Kind regards,
 Minchan Kim

 --
 To unsubscribe, send a message with 'unsubscribe linux-mm' in
 the body to majord...@kvack.org.  For more info on Linux MM,
 see: http://www.linux-mm.org/ .
 Fight unfair telecom internet charges in Canada: sign
 http://stopthemeter.ca/
 Don't email: a href=mailto:d...@kvack.org; em...@kvack.org /a

 
 --
 To unsubscribe, send a message with 'unsubscribe linux-mm' in
 the body to majord...@kvack.org.  For more info on Linux MM,
 see: http://www.linux-mm.org/ .
 Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
 Don't email: a href=mailto:d...@kvack.org; em...@kvack.org /a
 



-- 
Kind regards,
Minchan Kim
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [patch] gma500: silence an unused variable warning

[Kirill A. Shutemov]

On Thu, May 10, 2012 at 10:33:02AM +0300, Dan Carpenter wrote:
 If CONFIG_BACKLIGHT_CLASS_DEVICE is disabled then GCC warns that:
   drivers/gpu/drm/gma500/opregion.c:154:6: warning:
   unused variable ‘max’ [-Wunused-variable]
 
 Which give me a chance to use the new config_enabled() macro.  :)

The first [direct] user of config_enabled()! :)

Acked-by: Kirill A. Shutemov kirill.shute...@linux.intel.com

 
 Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
 
 diff --git a/drivers/gpu/drm/gma500/opregion.c 
 b/drivers/gpu/drm/gma500/opregion.c
 index 05661bf..d2125ba 100644
 --- a/drivers/gpu/drm/gma500/opregion.c
 +++ b/drivers/gpu/drm/gma500/opregion.c
 @@ -151,7 +151,6 @@ static u32 asle_set_backlight(struct drm_device *dev, u32 
 bclp)
   struct drm_psb_private *dev_priv = dev-dev_private;
   struct opregion_asle *asle = dev_priv-opregion.asle;
   struct backlight_device *bd = dev_priv-backlight_device;
 - u32 max;
  
   DRM_DEBUG_DRIVER(asle set backlight %x\n, bclp);
  
 @@ -165,11 +164,12 @@ static u32 asle_set_backlight(struct drm_device *dev, 
 u32 bclp)
   if (bclp  255)
   return ASLE_BACKLIGHT_FAILED;
  
 -#ifdef CONFIG_BACKLIGHT_CLASS_DEVICE
 - max = bd-props.max_brightness;
 - bd-props.brightness = bclp * max / 255;
 - backlight_update_status(bd);
 -#endif
 + if (config_enabled(CONFIG_BACKLIGHT_CLASS_DEVICE)) {
 + int max = bd-props.max_brightness;
 + bd-props.brightness = bclp * max / 255;
 + backlight_update_status(bd);
 + }
 +
   asle-cblv = (bclp * 0x64) / 0xff | ASLE_CBLV_VALID;
  
   return 0;

-- 
 Kirill A. Shutemov


signature.asc
Description: Digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] vga_switcheroo: Add the support for audio clients

[Paul Menzel]

Dear Takashi,


thank you for your patches.

Am Donnerstag, den 10.05.2012, 09:10 +0200 schrieb 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 explicity at registration time unlike

explicit*l*y

 the video controller.
 
 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43155

Is there a way (command sequence) to test this patch?

 Signed-off-by: Takashi Iwai ti...@suse.de
 ---
  drivers/gpu/vga/vga_switcheroo.c |   84 
 ++
  include/linux/vga_switcheroo.h   |   10 +
  2 files changed, 78 insertions(+), 16 deletions(-)

[…]


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [patch] gma500: silence an unused variable warning

[Paul Menzel]

Am Donnerstag, den 10.05.2012, 10:33 +0300 schrieb Dan Carpenter:
 If CONFIG_BACKLIGHT_CLASS_DEVICE is disabled then GCC warns that:
   drivers/gpu/drm/gma500/opregion.c:154:6: warning:
   unused variable ‘max’ [-Wunused-variable]
 
 Which give me a chance to use the new config_enabled() macro.  :)

Also the variable type is changed from `u32` to `int`.

 Signed-off-by: Dan Carpenter dan.carpen...@oracle.com

Acked-by: Paul Menzel paulepan...@users.sourceforge.net

 diff --git a/drivers/gpu/drm/gma500/opregion.c 
 b/drivers/gpu/drm/gma500/opregion.c
 index 05661bf..d2125ba 100644
 --- a/drivers/gpu/drm/gma500/opregion.c
 +++ b/drivers/gpu/drm/gma500/opregion.c
 @@ -151,7 +151,6 @@ static u32 asle_set_backlight(struct drm_device *dev, u32 
 bclp)
   struct drm_psb_private *dev_priv = dev-dev_private;
   struct opregion_asle *asle = dev_priv-opregion.asle;
   struct backlight_device *bd = dev_priv-backlight_device;
 - u32 max;
  
   DRM_DEBUG_DRIVER(asle set backlight %x\n, bclp);
  
 @@ -165,11 +164,12 @@ static u32 asle_set_backlight(struct drm_device *dev, 
 u32 bclp)
   if (bclp  255)
   return ASLE_BACKLIGHT_FAILED;
  
 -#ifdef CONFIG_BACKLIGHT_CLASS_DEVICE
 - max = bd-props.max_brightness;
 - bd-props.brightness = bclp * max / 255;
 - backlight_update_status(bd);
 -#endif
 + if (config_enabled(CONFIG_BACKLIGHT_CLASS_DEVICE)) {
 + int max = bd-props.max_brightness;
 + bd-props.brightness = bclp * max / 255;
 + backlight_update_status(bd);
 + }
 +
   asle-cblv = (bclp * 0x64) / 0xff | ASLE_CBLV_VALID;
  
   return 0;


signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH 2/2 v3] drm/exynos: added userptr feature.

[Inki Dae]

 -Original Message-
 From: Minchan Kim [mailto:minc...@kernel.org]
 Sent: Thursday, May 10, 2012 5:11 PM
 To: InKi Dae
 Cc: Inki Dae; Jerome Glisse; airl...@linux.ie; dri-
 de...@lists.freedesktop.org; kyungmin.p...@samsung.com;
 sw0312@samsung.com; linux...@kvack.org
 Subject: Re: [PATCH 2/2 v3] drm/exynos: added userptr feature.
 
 On 05/10/2012 04:59 PM, InKi Dae wrote:
 
  2012/5/10, Minchan Kim minc...@kernel.org:
  On 05/10/2012 03:57 PM, Inki Dae wrote:
 
 
 
  -Original Message-
  From: Minchan Kim [mailto:minc...@kernel.org]
  Sent: Thursday, May 10, 2012 1:58 PM
  To: Inki Dae
  Cc: 'Jerome Glisse'; airl...@linux.ie; dri-
 de...@lists.freedesktop.org;
  kyungmin.p...@samsung.com; sw0312@samsung.com; linux...@kvack.org
  Subject: Re: [PATCH 2/2 v3] drm/exynos: added userptr feature.
 
  On 05/10/2012 10:39 AM, Inki Dae wrote:
 
  Hi Jerome,
 
  -Original Message-
  From: Jerome Glisse [mailto:j.gli...@gmail.com]
  Sent: Wednesday, May 09, 2012 11:46 PM
  To: Inki Dae
  Cc: airl...@linux.ie; dri-devel@lists.freedesktop.org;
  kyungmin.p...@samsung.com; sw0312@samsung.com; linux-
 m...@kvack.org
  Subject: Re: [PATCH 2/2 v3] drm/exynos: added userptr feature.
 
  On Wed, May 9, 2012 at 2:17 AM, Inki Dae inki@samsung.com
 wrote:
  this feature is used to import user space region allocated by
  malloc()
  or
  mmaped into a gem. and to guarantee the pages to user space not to
 be
  swapped out, the VMAs within the user space would be locked and
 then
  unlocked
  when the pages are released.
 
  but this lock might result in significant degradation of system
  performance
  because the pages couldn't be swapped out so we limit user-desired
  userptr
  size to pre-defined.
 
  Signed-off-by: Inki Dae inki@samsung.com
  Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 
 
  Again i would like feedback from mm people (adding cc). I am not
 sure
 
  Thank you, I missed adding mm as cc.
 
  locking the vma is the right anwser as i said in my previous mail,
  userspace can munlock it in your back, maybe VM_RESERVED is better.
 
  I know that with VM_RESERVED flag, also we can avoid the pages from
  being
  swapped out. but these pages should be unlocked anytime we want
 because
  we
  could allocate all pages on system and lock them, which in turn, it
 may
  result in significant deterioration of system performance.(maybe
 other
  processes requesting free memory would be blocked) so I used
 VM_LOCKED
  flags
  instead. but I'm not sure this way is best also.
 
  Anyway even not considering that you don't check at all that
 process
  don't go over the limit of locked page see mm/mlock.c
 RLIMIT_MEMLOCK
 
  Thank you for your advices.
 
  for how it's done. Also you mlock complete vma but the userptr you
 get
  might be inside say 16M vma and you only care about 1M of userptr,
 if
  you mark the whole vma as locked than anytime a new page is fault
 in
  the vma else where than in the buffer you are interested then it
 got
  allocated for ever until the gem buffer is destroy, i am not sure
 of
  what happen to the vma on next malloc if it grows or not (i would
  think it won't grow at it would have different flags than new
  anonymous memory).
 
 
  I don't know history in detail because you didn't have sent full
 patches
  to linux-mm and
  I didn't read the below code, either.
  Just read your description and reply of Jerome. Apparently, there is
  something I missed.
 
  Your goal is to avoid swap out some user pages which is used in
 kernel
  at
  the same time. Right?
  Let's use get_user_pages. Is there any issue you can't use it?
  It increases page count so reclaimer can't swap out page.
  Isn't it enough?
  Marking whole VMA into MLCOKED is overkill.
 
 
  As I mentioned, we are already using get_user_pages. as you said, this
  function increases page count but just only things to the user address
  space
  cpu already accessed. other would be allocated by page fault hander
 once
  get_user_pages call. if so... ok, after that refcount(page-_count) of
  the
 
 
  Not true. Look __get_user_pages.
  It handles case you mentioned by handle_mm_fault.
  Do I miss something?
 
 
  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
 
 
 Understood.
 
  and then in turn next process like swap in to fill physical frame number
 into entry of the page faulted.
 
 
 Sorry, I can't understand your point due to my poor English.
 Could you rewrite it easiliy? :)
 

Simply saying, handle_mm_fault would be called to update pte after finding
vma and checking access right. and as you know, there are many cases to
process page fault such as COW or demand paging.

Thanks,
Inki Dae

 Thanks.
 
  of course,if user never 

Re: [PATCH 2/2] vga_switcheroo: Add the support for audio clients

[Dave Airlie]

On Thu, May 10, 2012 at 8:10 AM, Takashi Iwai ti...@suse.de wrote:
 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 explicity at registration time unlike
 the video controller.

The only question I really have is how you assign the audio ids.

Currently we mostly don't see  1 HDMI audio on a GPU, but that
should be changing with the latest ones.

Otherwise I'm happy to pull that branch from you.

Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 49418] [RV730] Screen is Scrambled When Booting in EFI Mode

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=49418

--- Comment #4 from Bastien Dejean nihilh...@gmail.com 2012-05-10 03:59:24 
PDT ---
I can provide further debug information if needed.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] vga_switcheroo: Add the support for audio clients

[Alan Cox]

On Thu, 10 May 2012 09:10:16 +0200
Takashi Iwai ti...@suse.de wrote:

 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 explicity at registration time unlike
 the video controller.

It would I think be a lot cleaner and more future proof to pass a 

struct hdmi_audio_switch_ops

or some similar named object with an array of function pointers ?

Alan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] vga_switcheroo: Add the support for audio clients

[Takashi Iwai]

At Thu, 10 May 2012 11:40:50 +0100,
Dave Airlie wrote:
 
 On Thu, May 10, 2012 at 8:10 AM, Takashi Iwai ti...@suse.de wrote:
  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 explicity at registration time unlike
  the video controller.
 
 The only question I really have is how you assign the audio ids.
 
 Currently we mostly don't see  1 HDMI audio on a GPU, but that
 should be changing with the latest ones.

There is one HDMI audio controller entry usually per graphics.
There are more than one codecs can be connected to the controller,
e.g. Nvidia has up to 8 codecs, but this is an issue inside HD-audio
driver, and irrelevant from VGA-switcheroo.


thanks,

Takashi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] i915: add dmabuf/prime buffer sharing support.

[Daniel Vetter]

From: Dave Airlie airl...@redhat.com

This adds handle-fd and fd-handle support to i915, this is to allow
for offloading of rendering in one direction and outputs in the other.

v2 from Daniel Vetter:
- fixup conflicts with the prepare/finish gtt prep work.
- implement ppgtt binding support.

Note that we have squat i-g-t testcoverage for any of the lifetime and
access rules dma_buf/prime support brings along. And there are quite a
few intricate situations here.

Also note that the integration with the existing code is a bit
hackish, especially around get_gtt_pages and put_gtt_pages. It imo
would be easier with the prep code from Chris Wilson's unbound series,
but that is for 3.6.

Also note that I didn't bother to put the new prepare/finish gtt hooks
to good use by moving the dma_buf_map/unmap_attachment calls in there
(like we've originally planned for).

Last but not least this patch is only compile-tested, but I've changed
very little compared to Dave Airlie's version. So there's a decent
chance v2 on drm-next works as well as v1 on 3.4-rc.

Signed-off-by: Dave Airlie airl...@redhat.com
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/Makefile  |3 +-
 drivers/gpu/drm/i915/i915_drv.c|8 +-
 drivers/gpu/drm/i915/i915_drv.h|   11 +++
 drivers/gpu/drm/i915/i915_gem.c|   12 ++-
 drivers/gpu/drm/i915/i915_gem_dmabuf.c |  149 
 drivers/gpu/drm/i915/i915_gem_gtt.c|   17 +++-
 6 files changed, 193 insertions(+), 7 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_gem_dmabuf.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 8b8bbc7..7b7ecb8 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -37,7 +37,8 @@ i915-y := i915_drv.o i915_dma.o i915_irq.o \
  dvo_ch7017.o \
  dvo_ivch.o \
  dvo_tfp410.o \
- dvo_sil164.o
+ dvo_sil164.o \
+ i915_gem_dmabuf.o
 
 i915-$(CONFIG_COMPAT)   += i915_ioc32.o
 
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 1ccfc23..ac13c2c 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1034,7 +1034,7 @@ static struct drm_driver driver = {
 */
.driver_features =
DRIVER_USE_AGP | DRIVER_REQUIRE_AGP | /* DRIVER_USE_MTRR |*/
-   DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | DRIVER_GEM,
+   DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | DRIVER_GEM | DRIVER_PRIME,
.load = i915_driver_load,
.unload = i915_driver_unload,
.open = i915_driver_open,
@@ -1057,6 +1057,12 @@ static struct drm_driver driver = {
.gem_init_object = i915_gem_init_object,
.gem_free_object = i915_gem_free_object,
.gem_vm_ops = i915_gem_vm_ops,
+
+   .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
+   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
+   .gem_prime_export = i915_gem_prime_export,
+   .gem_prime_import = i915_gem_prime_import,
+
.dumb_create = i915_gem_dumb_create,
.dumb_map_offset = i915_gem_mmap_gtt,
.dumb_destroy = i915_gem_dumb_destroy,
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e03a4f8..751f25c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -935,6 +935,8 @@ struct drm_i915_gem_object {
struct scatterlist *sg_list;
int num_sg;
 
+   /* prime dma-buf support */
+   struct sg_table *sg_table;
/**
 * Used for performing relocations during execbuffer insertion.
 */
@@ -1240,6 +1242,8 @@ int __must_check i915_gem_object_unbind(struct 
drm_i915_gem_object *obj);
 void i915_gem_release_mmap(struct drm_i915_gem_object *obj);
 void i915_gem_lastclose(struct drm_device *dev);
 
+int i915_gem_object_get_pages_gtt(struct drm_i915_gem_object *obj,
+ gfp_t gfpmask);
 int __must_check i915_mutex_lock_interruptible(struct drm_device *dev);
 int __must_check i915_gem_object_wait_rendering(struct drm_i915_gem_object 
*obj);
 int i915_gem_object_sync(struct drm_i915_gem_object *obj,
@@ -1337,6 +1341,13 @@ i915_gem_get_unfenced_gtt_alignment(struct drm_device 
*dev,
 int i915_gem_object_set_cache_level(struct drm_i915_gem_object *obj,
enum i915_cache_level cache_level);
 
+struct drm_gem_object *i915_gem_prime_import(struct drm_device *dev,
+   struct dma_buf *dma_buf);
+
+struct dma_buf *i915_gem_prime_export(struct drm_device *dev,
+   struct drm_gem_object *gem_obj, int flags);
+
+
 /* i915_gem_gtt.c */
 int __must_check i915_gem_init_aliasing_ppgtt(struct drm_device *dev);
 void i915_gem_cleanup_aliasing_ppgtt(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 44a5f24..d3bcfd4 100644
--- 

[PATCH] i915: add dmabuf/prime buffer sharing support.

[Daniel Vetter]

This adds handle-fd and fd-handle support to i915, this is to allow
for offloading of rendering in one direction and outputs in the other.

v2 from Daniel Vetter:
- fixup conflicts with the prepare/finish gtt prep work.
- implement ppgtt binding support.

Note that we have squat i-g-t testcoverage for any of the lifetime and
access rules dma_buf/prime support brings along. And there are quite a
few intricate situations here.

Also note that the integration with the existing code is a bit
hackish, especially around get_gtt_pages and put_gtt_pages. It imo
would be easier with the prep code from Chris Wilson's unbound series,
but that is for 3.6.

Also note that I didn't bother to put the new prepare/finish gtt hooks
to good use by moving the dma_buf_map/unmap_attachment calls in there
(like we've originally planned for).

Last but not least this patch is only compile-tested, but I've changed
very little compared to Dave Airlie's version. So there's a decent
chance v2 on drm-next works as well as v1 on 3.4-rc.

v3: Right when I've hit sent I've noticed that I've screwed up one
obj-sg_list (for dmar support) and obj-sg_table (for prime support)
disdinction. We should be able to merge these 2 paths, but that's
material for another patch.

Signed-off-by: Dave Airlie airl...@redhat.com
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/Makefile  |3 +-
 drivers/gpu/drm/i915/i915_drv.c|8 +-
 drivers/gpu/drm/i915/i915_drv.h|   11 +++
 drivers/gpu/drm/i915/i915_gem.c|   13 ++-
 drivers/gpu/drm/i915/i915_gem_dmabuf.c |  149 
 drivers/gpu/drm/i915/i915_gem_gtt.c|   15 +++-
 6 files changed, 193 insertions(+), 6 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_gem_dmabuf.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 8b8bbc7..7b7ecb8 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -37,7 +37,8 @@ i915-y := i915_drv.o i915_dma.o i915_irq.o \
  dvo_ch7017.o \
  dvo_ivch.o \
  dvo_tfp410.o \
- dvo_sil164.o
+ dvo_sil164.o \
+ i915_gem_dmabuf.o
 
 i915-$(CONFIG_COMPAT)   += i915_ioc32.o
 
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 1ccfc23..ac13c2c 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1034,7 +1034,7 @@ static struct drm_driver driver = {
 */
.driver_features =
DRIVER_USE_AGP | DRIVER_REQUIRE_AGP | /* DRIVER_USE_MTRR |*/
-   DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | DRIVER_GEM,
+   DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | DRIVER_GEM | DRIVER_PRIME,
.load = i915_driver_load,
.unload = i915_driver_unload,
.open = i915_driver_open,
@@ -1057,6 +1057,12 @@ static struct drm_driver driver = {
.gem_init_object = i915_gem_init_object,
.gem_free_object = i915_gem_free_object,
.gem_vm_ops = i915_gem_vm_ops,
+
+   .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
+   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
+   .gem_prime_export = i915_gem_prime_export,
+   .gem_prime_import = i915_gem_prime_import,
+
.dumb_create = i915_gem_dumb_create,
.dumb_map_offset = i915_gem_mmap_gtt,
.dumb_destroy = i915_gem_dumb_destroy,
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e03a4f8..751f25c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -935,6 +935,8 @@ struct drm_i915_gem_object {
struct scatterlist *sg_list;
int num_sg;
 
+   /* prime dma-buf support */
+   struct sg_table *sg_table;
/**
 * Used for performing relocations during execbuffer insertion.
 */
@@ -1240,6 +1242,8 @@ int __must_check i915_gem_object_unbind(struct 
drm_i915_gem_object *obj);
 void i915_gem_release_mmap(struct drm_i915_gem_object *obj);
 void i915_gem_lastclose(struct drm_device *dev);
 
+int i915_gem_object_get_pages_gtt(struct drm_i915_gem_object *obj,
+ gfp_t gfpmask);
 int __must_check i915_mutex_lock_interruptible(struct drm_device *dev);
 int __must_check i915_gem_object_wait_rendering(struct drm_i915_gem_object 
*obj);
 int i915_gem_object_sync(struct drm_i915_gem_object *obj,
@@ -1337,6 +1341,13 @@ i915_gem_get_unfenced_gtt_alignment(struct drm_device 
*dev,
 int i915_gem_object_set_cache_level(struct drm_i915_gem_object *obj,
enum i915_cache_level cache_level);
 
+struct drm_gem_object *i915_gem_prime_import(struct drm_device *dev,
+   struct dma_buf *dma_buf);
+
+struct dma_buf *i915_gem_prime_export(struct drm_device *dev,
+   struct drm_gem_object *gem_obj, int flags);
+
+
 /* i915_gem_gtt.c */
 int __must_check i915_gem_init_aliasing_ppgtt(struct drm_device *dev);
 void 

Re: [Intel-gfx] [PATCH] i915: add dmabuf/prime buffer sharing support.

[Chris Wilson]

On Thu, 10 May 2012 15:11:15 +0200, Daniel Vetter daniel.vet...@ffwll.ch 
wrote:
 From: Dave Airlie airl...@redhat.com
 
 This adds handle-fd and fd-handle support to i915, this is to allow
 for offloading of rendering in one direction and outputs in the other.
 
 v2 from Daniel Vetter:
 - fixup conflicts with the prepare/finish gtt prep work.
 - implement ppgtt binding support.
 
 Note that we have squat i-g-t testcoverage for any of the lifetime and
 access rules dma_buf/prime support brings along. And there are quite a
 few intricate situations here.
 
 Also note that the integration with the existing code is a bit
 hackish, especially around get_gtt_pages and put_gtt_pages. It imo
 would be easier with the prep code from Chris Wilson's unbound series,
 but that is for 3.6.
 
 Also note that I didn't bother to put the new prepare/finish gtt hooks
 to good use by moving the dma_buf_map/unmap_attachment calls in there
 (like we've originally planned for).
 
 Last but not least this patch is only compile-tested, but I've changed
 very little compared to Dave Airlie's version. So there's a decent
 chance v2 on drm-next works as well as v1 on 3.4-rc.
 
 Signed-off-by: Dave Airlie airl...@redhat.com
 Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
 ---
  drivers/gpu/drm/i915/Makefile  |3 +-
  drivers/gpu/drm/i915/i915_drv.c|8 +-
  drivers/gpu/drm/i915/i915_drv.h|   11 +++
  drivers/gpu/drm/i915/i915_gem.c|   12 ++-
  drivers/gpu/drm/i915/i915_gem_dmabuf.c |  149 
 
  drivers/gpu/drm/i915/i915_gem_gtt.c|   17 +++-
  6 files changed, 193 insertions(+), 7 deletions(-)
  create mode 100644 drivers/gpu/drm/i915/i915_gem_dmabuf.c
 
 diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
 index 8b8bbc7..7b7ecb8 100644
 --- a/drivers/gpu/drm/i915/Makefile
 +++ b/drivers/gpu/drm/i915/Makefile
 @@ -37,7 +37,8 @@ i915-y := i915_drv.o i915_dma.o i915_irq.o \
 dvo_ch7017.o \
 dvo_ivch.o \
 dvo_tfp410.o \
 -   dvo_sil164.o
 +   dvo_sil164.o \
 +   i915_gem_dmabuf.o
  
  i915-$(CONFIG_COMPAT)   += i915_ioc32.o
  
 diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
 index 1ccfc23..ac13c2c 100644
 --- a/drivers/gpu/drm/i915/i915_drv.c
 +++ b/drivers/gpu/drm/i915/i915_drv.c
 @@ -1034,7 +1034,7 @@ static struct drm_driver driver = {
*/
   .driver_features =
   DRIVER_USE_AGP | DRIVER_REQUIRE_AGP | /* DRIVER_USE_MTRR |*/
 - DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | DRIVER_GEM,
 + DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | DRIVER_GEM | DRIVER_PRIME,
   .load = i915_driver_load,
   .unload = i915_driver_unload,
   .open = i915_driver_open,
 @@ -1057,6 +1057,12 @@ static struct drm_driver driver = {
   .gem_init_object = i915_gem_init_object,
   .gem_free_object = i915_gem_free_object,
   .gem_vm_ops = i915_gem_vm_ops,
 +
 + .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
 + .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
 + .gem_prime_export = i915_gem_prime_export,
 + .gem_prime_import = i915_gem_prime_import,

Maybe a .gem_prime_ops = i915_gem_prime_ops.

 +
   .dumb_create = i915_gem_dumb_create,
   .dumb_map_offset = i915_gem_mmap_gtt,
   .dumb_destroy = i915_gem_dumb_destroy,
 diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
 index e03a4f8..751f25c 100644
 --- a/drivers/gpu/drm/i915/i915_drv.h
 +++ b/drivers/gpu/drm/i915/i915_drv.h
 @@ -935,6 +935,8 @@ struct drm_i915_gem_object {
   struct scatterlist *sg_list;
   int num_sg;
  
 + /* prime dma-buf support */
 + struct sg_table *sg_table;

This looks like a kludge which with a little more work could integrate
neatly into the existing sg code without having to add aditional special
cases.

 +struct sg_table *i915_gem_map_dma_buf(struct dma_buf_attachment *attachment,
 +   enum dma_data_direction dir)
 +{
 + struct drm_i915_gem_object *obj = attachment-dmabuf-priv;
 + struct drm_device *dev = obj-base.dev;
 + int npages = obj-base.size / PAGE_SIZE;
 + struct sg_table *sg = NULL;
 + int ret;
 + int nents;
 +
 + ret = i915_mutex_lock_interruptible(dev);
 + if (ret)
 + return NULL;

Not impressed by the lack of error reporting through this interface.

 +struct drm_gem_object *i915_gem_prime_import(struct drm_device *dev,
 + struct dma_buf *dma_buf)
 +{
 + struct dma_buf_attachment *attach;
 + struct sg_table *sg;
 + struct drm_i915_gem_object *obj;
 + int npages;
 + int size;
 + int ret;
 +
 + /* is this one of own objects? */
 + if (dma_buf-ops == i915_dmabuf_ops) {
 + obj = dma_buf-priv;
 + /* is it from our device? */
 + if (obj-base.dev == dev) {
 + drm_gem_object_reference(obj-base);
 + 

[PULL] drm-intel-next

[Daniel Vetter]

Hi Dave,

New drm-intel-next pull request.
Highlights:
- sparse fixes from Ben.
- tons of little cleanups from Chris all over: tiling_changed
  clarification, deferred_free list removal, ...
- fix up irq handler on gen2  gen3 + related cleanups from Chris
- prep work for wait_rendering_timeout from Ben with some nice
  refactorings
- first set of infoframe fixes from Paulo for doubleclocked CEA modes
- improve pch pll handling from Jesse and Chris
- gpu hangman, this also contains the reset fix for gen4
- rps sanity check from Chris - this papers over issues when the gpu fails
  to clock up on snb/ivb, and it is shockingly easy to hit. The code
  prints a big WARN backtrace and restores the hw to a sane state. The
  real fix is still in the works.

Atm I'm aware of 2 regressions in -next:
- One of the gmbus patches (not gmbus itself) regressed lvds detection on
  a MacbookPro. I've analyzed the bug already and I think I know what's
  going on, patch is awaiting test feedback.
- Just today QA reported that DP on ilk regressed. That bug is fresh of
  the press and still awaiting detailed logfiles and the bisect result.
  The only thing that's clear atm is that -fixes works and -next doesn't.

Otherwise 3.5 merge is winding down, I am queueing up a few things though
that I'd like to still sneak in:
- More infoframe fixes from Paulo (most already queued into my tree).
- Final pieces of the first cut at hsw support from Eugeni - all the
  invasive pieces and code rework has landed already so not much harm
  there.
- I'm working on some backlight fixes I'd like to land in 3.5, but not yet
  all ready.

As discussed on irc this pull request is for the merged branch which
already resolves the conflicts with drm-next (due to the -rc6 backmerge).

Yours, Daniel

The following changes since commit 4f256e8aa3eda15c11c3cec3ec5336e1fc579cbd:

  Merge branch 'for-airlied' of git://people.freedesktop.org/~danvet/drm-intel 
into drm-core-next (2012-05-07 16:09:35 +0100)

are available in the git repository at:


  git://people.freedesktop.org/~danvet/drm-intel 
tags/drm-intel-next-2012-05-06-merged

for you to fetch changes up to 5e13a0c5ec05d382b488a691dfb8af015b1dea1e:

  Merge remote-tracking branch 'airlied/drm-core-next' into 
drm-intel-next-queued (2012-05-08 13:39:59 +0200)



Ben Widawsky (11):
  drm/i915: [sparse] __iomem fixes for opregion
  drm/i915: [sparse] __iomem fixes for overlay
  drm/i915: [sparse] __iomem fixes for gem
  drm/i915: remove do_retire from i915_wait_request
  drm/i915: move vbetool invoked ier stuff
  drm/i915: kill waiting_seqno
  drm/i915: drop polled waits from i915_wait_request
  drm/i915: extract __wait_seqno from i915_wait_request
  drm/i915: remove polled wait from throttle
  drm/i915: use __wait_seqno for ring throttle
  drm/i915: extract some common olr+wedge code

Chris Wilson (32):
  drm/i915/sprite: Avoid incurring extra vblank stall when updating plane 
on IVB
  drm/i915: Remove i915_gem_ringbuffer_(data|info) from debugfs
  drm/i915: Clarify the semantics of tiling_changed
  drm/i915: Only the zap the VMA after updating the tiling parameters
  drm/i915: i8xx interrupt handler
  drm/i915: Use a global lock for modifying global irq flags
  drm/i915: Remove too early plane enable on pre-PCH hardware
  drm/i915: Bump the inactive LRU on set-to-GTT-domain
  drm/i915: Remove i915_gem_evict_inactive()
  drm/i915: Remove the list of pinned inactive objects
  drm/i915: Remove the deferred-free list
  drm/i915: Split the stolen handling for GEM out of i915_dma.c
  drm/i915: Move GEM initialisation from i915_dma.c to i915_gem.c
  drm/i915: CR clock gating is recommend to be set on PineView
  drm/i915: Unconditionally initialise the interrupt workers
  drm/i915: Remove redundant initialisation of per-ring IRQ waitqueues
  drm/i915: pending_flip_is_done is gen3, name it so
  drm/i915: Duplicate and split the gen3/4 irq handler
  drm/i915: Clear FlipDone semantics change for pageflipping on gen3
  drm/i915: Remove gen3 irq code from gen4 irq routine
  drm/i915: Remove gen4 irq code from gen3 irq routine
  drm/i915: HWSTAM is only 16-bit on gen3
  drm/i915: Cleanup gen3 irq uninstall
  drm/i915: Handle PendingFlip on gen3 robustly
  drm/i915: Inline I915_INTERRUPT_ENABLE_FIX
  drm/i915: Remove unused and unloved vblank macros
  drm/i915: Remove unused ring-irq_seqno
  drm/i915: Only enable IPS polling for gen5
  drm/i915: Remove unused dev_priv-vblank_pipe
  drm/i915: Wait for the clocks to stabilise before updating PLLs
  drm/i915: Periodically sanity check power management
  drm/i915: Support pageflipping interrupts for all 3-pipes on IVB

Daniel Vetter (43):
  drm/i915: print computed bpp in dp link configuration
  drm/i915: [sparse] __iomem fixes 

Re: [PATCH 2/2 v3] drm/exynos: added userptr feature.

[Minchan Kim]

On 05/10/2012 04:59 PM, InKi Dae wrote:

 2012/5/10, Minchan Kim minc...@kernel.org:
 On 05/10/2012 03:57 PM, Inki Dae wrote:



 -Original Message-
 From: Minchan Kim [mailto:minc...@kernel.org]
 Sent: Thursday, May 10, 2012 1:58 PM
 To: Inki Dae
 Cc: 'Jerome Glisse'; airl...@linux.ie; dri-devel@lists.freedesktop.org;
 kyungmin.p...@samsung.com; sw0312@samsung.com; linux...@kvack.org
 Subject: Re: [PATCH 2/2 v3] drm/exynos: added userptr feature.

 On 05/10/2012 10:39 AM, Inki Dae wrote:

 Hi Jerome,

 -Original Message-
 From: Jerome Glisse [mailto:j.gli...@gmail.com]
 Sent: Wednesday, May 09, 2012 11:46 PM
 To: Inki Dae
 Cc: airl...@linux.ie; dri-devel@lists.freedesktop.org;
 kyungmin.p...@samsung.com; sw0312@samsung.com; linux...@kvack.org
 Subject: Re: [PATCH 2/2 v3] drm/exynos: added userptr feature.

 On Wed, May 9, 2012 at 2:17 AM, Inki Dae inki@samsung.com wrote:
 this feature is used to import user space region allocated by
 malloc()
 or
 mmaped into a gem. and to guarantee the pages to user space not to be
 swapped out, the VMAs within the user space would be locked and then
 unlocked
 when the pages are released.

 but this lock might result in significant degradation of system
 performance
 because the pages couldn't be swapped out so we limit user-desired
 userptr
 size to pre-defined.

 Signed-off-by: Inki Dae inki@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com


 Again i would like feedback from mm people (adding cc). I am not sure

 Thank you, I missed adding mm as cc.

 locking the vma is the right anwser as i said in my previous mail,
 userspace can munlock it in your back, maybe VM_RESERVED is better.

 I know that with VM_RESERVED flag, also we can avoid the pages from
 being
 swapped out. but these pages should be unlocked anytime we want because
 we
 could allocate all pages on system and lock them, which in turn, it may
 result in significant deterioration of system performance.(maybe other
 processes requesting free memory would be blocked) so I used VM_LOCKED
 flags
 instead. but I'm not sure this way is best also.

 Anyway even not considering that you don't check at all that process
 don't go over the limit of locked page see mm/mlock.c RLIMIT_MEMLOCK

 Thank you for your advices.

 for how it's done. Also you mlock complete vma but the userptr you get
 might be inside say 16M vma and you only care about 1M of userptr, if
 you mark the whole vma as locked than anytime a new page is fault in
 the vma else where than in the buffer you are interested then it got
 allocated for ever until the gem buffer is destroy, i am not sure of
 what happen to the vma on next malloc if it grows or not (i would
 think it won't grow at it would have different flags than new
 anonymous memory).


 I don't know history in detail because you didn't have sent full patches
 to linux-mm and
 I didn't read the below code, either.
 Just read your description and reply of Jerome. Apparently, there is
 something I missed.

 Your goal is to avoid swap out some user pages which is used in kernel
 at
 the same time. Right?
 Let's use get_user_pages. Is there any issue you can't use it?
 It increases page count so reclaimer can't swap out page.
 Isn't it enough?
 Marking whole VMA into MLCOKED is overkill.


 As I mentioned, we are already using get_user_pages. as you said, this
 function increases page count but just only things to the user address
 space
 cpu already accessed. other would be allocated by page fault hander once
 get_user_pages call. if so... ok, after that refcount(page-_count) of
 the


 Not true. Look __get_user_pages.
 It handles case you mentioned by handle_mm_fault.
 Do I miss something?

 
 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


Understood.

 and then in turn next process like swap in to fill physical frame number into 
 entry of the page faulted.


Sorry, I can't understand your point due to my poor English.
Could you rewrite it easiliy? :)

Thanks.

 of course,if user never access the buffer and requested userptr then

 handle_mm_fault would be called by __get_user_pages. please give me
 any comments if there is my missing point.
 
 Thanks,
 Inki Dae
 
 
 pages user already accessed would have 2 and just 1 for other all pages.
 so
 we may have to consider only pages never accessed by cpu to be locked to
 avoid from swapped out.

 Thanks,
 Inki Dae

 --
 Kind regards,
 Minchan Kim

 --
 To unsubscribe, send a message with 'unsubscribe linux-mm' in
 the body to majord...@kvack.org.  For more info on Linux MM,
 see: http://www.linux-mm.org/ .
 Fight unfair telecom internet charges in Canada: sign
 http://stopthemeter.ca/
 Don't email: a href=mailto:d...@kvack.org; 

[PATCH] drm/exynos: Include missing linux/types.h in header

[Emil Goode]

Include the linux/types.h file where used types are declared.

Sparse gives the following warning:
/usr/include/drm/exynos_drm.h:92:
found __[us]{8,16,32,64} type without
#include linux/types.h

Signed-off-by: Emil Goode emilgo...@gmail.com
---
 include/drm/exynos_drm.h |2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/drm/exynos_drm.h b/include/drm/exynos_drm.h
index e478de4..7eb7ae7 100644
--- a/include/drm/exynos_drm.h
+++ b/include/drm/exynos_drm.h
@@ -29,6 +29,8 @@
 #ifndef _EXYNOS_DRM_H_
 #define _EXYNOS_DRM_H_
 
+#include linux/types.h
+
 /**
  * User-desired buffer creation information structure.
  *
-- 
1.7.10

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH libdrm] radeon: Add new R600 PCI ids for surface manager

[Anisse Astier]

This is the same list of PCI ids added by Alex Deucher in xf86-video-ati commit
aacbd629b02cbee3f9e6a0ee452b4e3f21376bd3.

This is needed since the addition of the surface allocator helper in
commit c51f7f0e460dcadb9f1a56ecf1615810877c33c8 ; it needs to differentiate
pre and post-R600 GPUs.
Therefore we should maintain another PCI id list.

Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=48138
Signed-off-by: Anisse Astier ani...@astier.eu
---
 radeon/r600_pci_ids.h |   10 ++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/radeon/r600_pci_ids.h b/radeon/r600_pci_ids.h
index 8fbd749..360c73d 100644
--- a/radeon/r600_pci_ids.h
+++ b/radeon/r600_pci_ids.h
@@ -152,6 +152,7 @@ CHIPSET(0x68F1, CEDAR_68F1, CEDAR)
 CHIPSET(0x68F2, CEDAR_68F2, CEDAR)
 CHIPSET(0x68F8, CEDAR_68F8, CEDAR)
 CHIPSET(0x68F9, CEDAR_68F9, CEDAR)
+CHIPSET(0x68FA, CEDAR_68FA, CEDAR)
 CHIPSET(0x68FE, CEDAR_68FE, CEDAR)
 
 CHIPSET(0x68C0, REDWOOD_68C0, REDWOOD)
@@ -192,6 +193,8 @@ CHIPSET(0x9804, PALM_9804, PALM)
 CHIPSET(0x9805, PALM_9805, PALM)
 CHIPSET(0x9806, PALM_9806, PALM)
 CHIPSET(0x9807, PALM_9807, PALM)
+CHIPSET(0x9808, PALM_9808, PALM)
+CHIPSET(0x9809, PALM_9809, PALM)
 
 CHIPSET(0x9640, SUMO_9640,  SUMO)
 CHIPSET(0x9641, SUMO_9641,  SUMO)
@@ -202,6 +205,8 @@ CHIPSET(0x9645, SUMO2_9645, SUMO2)
 CHIPSET(0x9647, SUMO_9647,  SUMO)
 CHIPSET(0x9648, SUMO_9648,  SUMO)
 CHIPSET(0x964a, SUMO_964A,  SUMO)
+CHIPSET(0x964b, SUMO_964B,  SUMO)
+CHIPSET(0x964c, SUMO_964C,  SUMO)
 CHIPSET(0x964e, SUMO_964E,  SUMO)
 CHIPSET(0x964f, SUMO_964F,  SUMO)
 
@@ -245,8 +250,11 @@ CHIPSET(0x6747, TURKS_6747, TURKS)
 CHIPSET(0x6748, TURKS_6748, TURKS)
 CHIPSET(0x6749, TURKS_6749, TURKS)
 CHIPSET(0x6750, TURKS_6750, TURKS)
+CHIPSET(0x6751, TURKS_6751, TURKS)
 CHIPSET(0x6758, TURKS_6758, TURKS)
 CHIPSET(0x6759, TURKS_6759, TURKS)
+CHIPSET(0x675B, TURKS_675B, TURKS)
+CHIPSET(0x675D, TURKS_675D, TURKS)
 CHIPSET(0x675F, TURKS_675F, TURKS)
 CHIPSET(0x6840, TURKS_6840, TURKS)
 CHIPSET(0x6841, TURKS_6841, TURKS)
@@ -267,8 +275,10 @@ CHIPSET(0x6766, CAICOS_6766, CAICOS)
 CHIPSET(0x6767, CAICOS_6767, CAICOS)
 CHIPSET(0x6768, CAICOS_6768, CAICOS)
 CHIPSET(0x6770, CAICOS_6770, CAICOS)
+CHIPSET(0x6772, CAICOS_6772, CAICOS)
 CHIPSET(0x6778, CAICOS_6778, CAICOS)
 CHIPSET(0x6779, CAICOS_6779, CAICOS)
+CHIPSET(0x677B, CAICOS_677B, CAICOS)
 
 CHIPSET(0x9900, ARUBA_9900, ARUBA)
 CHIPSET(0x9901, ARUBA_9901, ARUBA)
-- 
1.7.9

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon: make use of radeon_gem_init() consistent

[alexdeucher]

From: Alex Deucher alexander.deuc...@amd.com

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 all and rely on the the init in
radeon_device.c.  Just call radeon_gem_init() in radeon_device.c
and remove the explicit calls from all the newer asics.

All asics call radeon_gem_fini() in their fini pathes.  That
could possibly be cleaned up too.

Signed-off-by: Alex Deucher alexander.deuc...@amd.com
---
 drivers/gpu/drm/radeon/evergreen.c |4 
 drivers/gpu/drm/radeon/ni.c|4 
 drivers/gpu/drm/radeon/r600.c  |4 
 drivers/gpu/drm/radeon/radeon_device.c |4 +++-
 drivers/gpu/drm/radeon/rv770.c |4 
 drivers/gpu/drm/radeon/si.c|4 
 6 files changed, 3 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index 7e7ac3d..58991af 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -3435,10 +3435,6 @@ int evergreen_init(struct radeon_device *rdev)
 {
int r;
 
-   /* This don't do much */
-   r = radeon_gem_init(rdev);
-   if (r)
-   return r;
/* Read BIOS */
if (!radeon_get_bios(rdev)) {
if (ASIC_IS_AVIVO(rdev))
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 107b217..b01c2dd 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1629,10 +1629,6 @@ int cayman_init(struct radeon_device *rdev)
struct radeon_ring *ring = rdev-ring[RADEON_RING_TYPE_GFX_INDEX];
int r;
 
-   /* This don't do much */
-   r = radeon_gem_init(rdev);
-   if (r)
-   return r;
/* Read BIOS */
if (!radeon_get_bios(rdev)) {
if (ASIC_IS_AVIVO(rdev))
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 4c0d8c9..971d244 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -2552,10 +2552,6 @@ int r600_init(struct radeon_device *rdev)
if (r600_debugfs_mc_info_init(rdev)) {
DRM_ERROR(Failed to register debugfs file for mc !\n);
}
-   /* This don't do much */
-   r = radeon_gem_init(rdev);
-   if (r)
-   return r;
/* Read BIOS */
if (!radeon_get_bios(rdev)) {
if (ASIC_IS_AVIVO(rdev))
diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index e1bc7e9..96d8ed3 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -731,9 +731,11 @@ int radeon_device_init(struct radeon_device *rdev,
mutex_init(rdev-gem.mutex);
mutex_init(rdev-pm.mutex);
mutex_init(rdev-vram_mutex);
-   INIT_LIST_HEAD(rdev-gem.objects);
init_waitqueue_head(rdev-irq.vblank_queue);
init_waitqueue_head(rdev-irq.idle_queue);
+   r = radeon_gem_init(rdev);
+   if (r)
+   return r;
/* initialize vm here */
rdev-vm_manager.use_bitmap = 1;
rdev-vm_manager.max_pfn = 1  20;
diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
index 40f82e2..c2f473b 100644
--- a/drivers/gpu/drm/radeon/rv770.c
+++ b/drivers/gpu/drm/radeon/rv770.c
@@ -1175,10 +1175,6 @@ int rv770_init(struct radeon_device *rdev)
 {
int r;
 
-   /* This don't do much */
-   r = radeon_gem_init(rdev);
-   if (r)
-   return r;
/* Read BIOS */
if (!radeon_get_bios(rdev)) {
if (ASIC_IS_AVIVO(rdev))
diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index be3b9fd..6e5a28a 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -3986,10 +3986,6 @@ int si_init(struct radeon_device *rdev)
struct radeon_ring *ring = rdev-ring[RADEON_RING_TYPE_GFX_INDEX];
int r;
 
-   /* This don't do much */
-   r = radeon_gem_init(rdev);
-   if (r)
-   return r;
/* Read BIOS */
if (!radeon_get_bios(rdev)) {
if (ASIC_IS_AVIVO(rdev))
-- 
1.7.7.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 41265] KMS does not work on Radeon HD6700M

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=41265

--- Comment #13 from Shiv Sikand s...@sikand.org 2012-05-10 10:11:47 PDT ---
I have a very similar issue to gyhor.

The driver gets really confused with the PCI busid.

lspci reports the ID as 16, but the driver thinks it's on 22.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 41265] KMS does not work on Radeon HD6700M

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=41265

--- Comment #14 from Alex Deucher ag...@yahoo.com 2012-05-10 10:14:03 PDT ---
(In reply to comment #13)
 The driver gets really confused with the PCI busid.
 
 lspci reports the ID as 16, but the driver thinks it's on 22.

they are the same.  0x16 (hex) = 22 (decimal)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 49747] dpms on only works on DP0 on a hd5700

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=49747

--- Comment #1 from Daniel Vetter dan...@ffwll.ch 2012-05-10 10:58:24 PDT ---
Created attachment 61379
  -- https://bugs.freedesktop.org/attachment.cgi?id=61379
dmesg

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 49747] dpms on only works on DP0 on a hd5700

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=49747

--- Comment #2 from Daniel Vetter dan...@ffwll.ch 2012-05-10 10:58:57 PDT ---
Created attachment 61380
  -- https://bugs.freedesktop.org/attachment.cgi?id=61380
xrandr --verbose

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel