headers
daeinki | 1 Aug 2011 05:52

Re: [PATCH] [RFC PATCH] DRM: add DRM Driver for Samsung SoC EXYNOS4210.

Hi, Sascha Hauer.
thank you for your comments and below is my answer.

Sascha Hauer wrote:
> Hi,
> 
> On Fri, Jul 29, 2011 at 04:24:35PM +0900, Inki Dae wrote:
>> This patch is a DRM Driver(only including FIMD Driver yet)
>> for Samsung SoC Exynos4210. and as RFC, I am sending only DRM driver part.
>>
>> this patch is based on git repository below:
>> git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git,
>> branch: drm-next
>> commit-id: 5a96a899bbdee86024ab9ea6d02b9e242faacbed
>>
>> We tried to re-use lowlevel codes of the FIMD driver(s3c-fb.c
>> based on Linux framebuffer) but couldn't so because lowlevel codes
>> of s3c-fb.c are included internally and so this driver shares only
>> platform device.
>>
>> Sub drivers such as fimd or hdmi have indenpendent platform device and
>> Platform driver and when driver's probe is called, the driver object
>> including callbacks(for hardware control) would be registered to
>> Samsung drm driver. and then when samsung drm driver is probed,
>> each probe callback of the driver object registered is called so that
>> additional callbacks for drm framework would be set at this time.
>>
>> We used GEM framework for buffer management and this driver supports
>> only physically continuous memory yet(non-iommu). and for buffer allocation,
>> we used DMA APIs(dma_alloc_writecombine) but we will change it to CMA instead
(Continue reading)

Permalink | Reply | 5 comments |
headers
bugzilla-daemon | 1 Aug 2011 14:12

[Bug 39714] New: Slow and choppy 3D performace on evergreen after pm-suspend

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

           Summary: Slow and choppy 3D performace on evergreen after
                    pm-suspend
           Product: Mesa
           Version: git
          Platform: x86-64 (AMD64)
        OS/Version: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Drivers/Gallium/r600
        AssignedTo: dri-devel <at> lists.freedesktop.org
        ReportedBy: bugs.xorg <at> boris64.net

Created an attachment (id=49783)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=49783)
dmesg including pm-suspend event

I get very slow and choppy 3d performance after suspending my computer.
This is valid for glxgears (i-know-it's-not-a-benchmark), kwin and others.
After restarting the 3d application speed seems to be normal/ok again. 

Example:
[glxgears output]
17641 frames in 5.0 seconds = 3528.125 FPS
18396 frames in 5.0 seconds = 3679.087 FPS
22768 frames in 5.0 seconds = 4553.543 FPS
18280 frames in 5.0 seconds = 3655.863 FPS
16051 frames in 5.0 seconds = 3210.111 FPS
(Continue reading)

Permalink | Reply | 14 comments |
headers
bugzilla-daemon | 1 Aug 2011 14:12

[Bug 39714] Slow and choppy 3D performace on evergreen after pm-suspend

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

--- Comment #1 from boris64 <bugs.xorg <at> boris64.net> 2011-08-01 05:12:55 PDT ---
Created an attachment (id=49784)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=49784)
Xorg.0.log

--

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 1 Aug 2011 14:13

[Bug 39714] Slow and choppy 3D performace on evergreen after pm-suspend

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

--- Comment #2 from boris64 <bugs.xorg <at> boris64.net> 2011-08-01 05:13:14 PDT ---
Created an attachment (id=49785)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=49785)
lspci -vvn

--

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
Permalink | Reply | 0 comments |
headers
Prof. Dr. Klaus Kusche | 1 Aug 2011 10:14
Favicon

Re: [Feature request] Multiple X servers on one graphics card?

On 2011-07-31 22:09, Dave Airlie wrote:
>> * Are there any plans or activities to port these patches
>> to recent kernels? To include these patches or something similar
>> in the official linux kernel any time soon?
>
> Nothing in my plans, I did a proof of concept to show how someone
> should do things, I'd sort of hoped some of the people who dedicate
> time to fixing multiseat and cared about it would pick things up and
> run with them, it really does need a proper ioctl or configfs

Is there any mailing list for the technical aspects of multiseat linux?
Who and where are the relevant developers?

Klaus.

--

-- 
Prof. Dr. Klaus Kusche
Private address: Rainstraße 9/1, 88316 Isny, Germany
+49 7562 6211377 Klaus.Kusche <at> computerix.info http://www.computerix.info
Office address: NTA Isny gGmbH, Seidenstraße 12-35, 88316 Isny, Germany
+49 7562 9707 36 kusche <at> nta-isny.de http://www.nta-isny.de
Permalink | Reply | 0 comments |
headers
Wu Fengguang | 1 Aug 2011 15:51
Picon
Favicon

[PATCH v3] pass ELD to HDMI/DP audio driver

Hi Jesse,

> On Wed, 29 Jun 2011 21:10:13 +0800
> Wu Fengguang <fengguang.wu <at> intel.com> wrote:
> 
> > Update: according to the spec, limit max a/v latencies to 500ms and
> > avoid overflowing the ELD field Aud_Synch_Delay[7:0].
> > 
> > Thanks to Pierre for pointing this out!
> > 
> > btw, the drm_edid_to_eld() function reuses some code from Ben Skeggs.
> > Ben, please add your Signed-off-by if the patch looks OK to you :)
> 
> Looks like this needs to be refreshed against Keith's drm-intel-next
> tree (some trivial conflicts).

Yeah. Below is the updated patch that also fixes an ELD size bug.
There are still known bugs: when hot plug an HDMI monitor, I get these
dmesg, which show that

1) intel_write_eld() is not called at all
   It seems we need to call intel_write_eld() in other places besides
   inside ->mode_set(). Is ->detect() the right place to do so? In
   other words, are there established connector<=>encoder mapping
   that can be queried inside intel_hdmi_detect()/intel_dp_detect()?

2) intel_dp_detect() is called even though it's an HDMI monitor
   connected to an HDMI jack.. It may be a bug specific to the
   hardware I'm testing (attached its full dmesg).
(Continue reading)

Permalink | Reply | 6 comments |
headers
bugzilla-daemon | 1 Aug 2011 16:08

[Bug 38163] Gnome Shell Display Bug

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

--- Comment #5 from Harri Nieminen <moikkis <at> gmail.com> 2011-08-01 07:08:38 PDT ---
It happens with my radeon 5450 in Fedora 15 x64.

glxinfo | grep OpenGL
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD CEDAR
OpenGL version string: 2.1 Mesa 7.11-rc4
OpenGL shading language version string: 1.20
OpenGL extensions:

--

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 1 Aug 2011 17:41

[Bug 39648] compositor goes crazy after a game has run

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

Alex Deucher <agd5f <at> yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #5 from Alex Deucher <agd5f <at> yahoo.com> 2011-08-01 08:41:54 PDT ---
I've gone ahead and pushed the patches:
9493563c1ef4b51af0ee8a44cb4e7c5bb280347e
d29bab632e9ecccba518d4107d52620bf75eb1cf
104b2d7c071f29266b1bc4184a74e9714d14febc

--

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
Permalink | Reply | 0 comments |
headers
Dave Airlie | 1 Aug 2011 21:47
Picon
Gravatar

Re: [Feature request] Multiple X servers on one graphics card?

>
> Hmmm, what's about the opposite approach?
> To me, it sounds simpler and more logical when the kernel always creates
> one device node per output (or maybe dynamically per connected output),
> without any need for configuration or device assignment.

It just doesn't fit in with how the drm device nodes work, like it might seem
simpler in the kernel but I think it would just complicate userspace.

> If a single X server wants to control several outputs,
> libdrm should open the corresponding number of devices in parallel.
> We already have both static X configuration and xrandr for configuring
> that, and if the devices allow only a single open,
> this would also arbitrate outputs between servers
> (a server can't open an output which is already taken).

I haven't decided it couldn't work but I'd need a working
implementation to even consider merging it, where I've already done a
demo of how I think it should work, which means I don't have to
revalidate things if someone were to complete it.

Dave.
Permalink | Reply | 8 comments |
headers
bugzilla-daemon | 1 Aug 2011 21:52

[Bug 39972] [regression] Radeon multi-screen

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

Andrew Morton <akpm <at> linux-foundation.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |akpm <at> linux-foundation.org
          Component|Video(Other)                |Video(DRI - non Intel)
         AssignedTo|drivers_video-other <at> kernel- |drivers_video-dri <at> kernel-bu
                   |bugs.osdl.org               |gs.osdl.org

--

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
Permalink | Reply | 0 comments |

Gmane