On Wed, Apr 18, 2012 at 10:36 AM, Daniel Vetter wrote:
> On Wed, Apr 18, 2012 at 05:26:07PM +0300, Ville Syrjälä wrote:
>> On Wed, Apr 18, 2012 at 04:04:56PM +0200, Marcus Lorentzon wrote:
>> > On 04/18/2012 02:25 PM, Rob Clark wrote:
>> > > On Wed, Apr 18, 2012 at 5:11 AM, Joonyoung Shim
>> > >
https://bugs.freedesktop.org/show_bug.cgi?id=48894
--- Comment #10 from Bryce Harrington 2012-04-18
15:34:25 PDT ---
ok looks like a core drm kernel bug
we don't lock properly around initialization
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are rec
https://bugs.freedesktop.org/show_bug.cgi?id=48894
Bryce Harrington changed:
What|Removed |Added
AssignedTo|chris at chris-wilson.co.uk|dri-devel at
lists.freedesktop
> That frequency seems about the same as the one I'm experiences. All though
> some times it's more often, but I can't say I've done anything special at
> the same time.
>
> 3.3.2-1-ARCH
> Intel(R) Atom(TM) CPU Z520 @ 1.33GHz
>
> Attachment: dmesg ouput
>
What X display server are you using (fb
https://bugs.freedesktop.org/show_bug.cgi?id=48422
Jonathan Nieder changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On Wed, Apr 18, 2012 at 10:36 AM, Daniel Vetter wrote:
> On Wed, Apr 18, 2012 at 05:26:07PM +0300, Ville Syrj?l? wrote:
>> On Wed, Apr 18, 2012 at 04:04:56PM +0200, Marcus Lorentzon wrote:
>> > On 04/18/2012 02:25 PM, Rob Clark wrote:
>> > > On Wed, Apr 18, 2012 at 5:11 AM, Joonyoung Shim> > > sam
https://bugs.freedesktop.org/show_bug.cgi?id=48772
--- Comment #9 from Roland Scheidegger 2012-04-18
14:21:14 PDT ---
(In reply to comment #8)
> That's the max theoretical mode supported by the chip. Whether or not you can
> drive a monitor that big probably depends on the type and speed of dra
On Wed, Apr 18, 2012 at 07:06:10PM +0300, Ville Syrj?l? wrote:
> On Wed, Apr 18, 2012 at 05:27:57PM +0200, Daniel Vetter wrote:
> > Also, I'm toying around with ideas to split up the big modeset lock such
> > that operations that only touch the crtc (like pageflip, plane changes and
> > cursor chan
On Wed, Apr 18, 2012 at 05:55:15PM +0200, Marcus Lorentzon wrote:
> On 04/18/2012 05:27 PM, Daniel Vetter wrote:
> >On Wed, Apr 18, 2012 at 05:10:47PM +0200, Marcus Lorentzon wrote:
> >>On 04/18/2012 04:36 PM, Daniel Vetter wrote:
> >>>Last time around I've discussed with people we've ended up with
> How do you ensure that no device can do DMA on the buffer while it's mapped
> into user space in a noncoherent manner?
Why do we want to enforce that ? We provide the appropriate base service
but you need to know what you are doing. In reality a lot of use cases
are going to need far more than a
https://bugs.freedesktop.org/show_bug.cgi?id=48880
--- Comment #10 from Alex Deucher 2012-04-18 12:22:55 PDT
---
Is it only problematic on VGA or TMDS? I.e., does one only one or the other,
but not both? It seems to be something specific to your monitor. I can't
reproduce this on my ontario h
On 04/18/2012 05:46 PM, Daniel Vetter wrote:
> On Wed, Apr 18, 2012 at 01:31:59PM +0900, Joonyoung Shim wrote:
>> DRM_MODE_PLANE_EVENT is similar to DRM_MODE_PAGE_FLIP_EVENT but it is
>> for a plane. The setplane ioctl (DRM_IOCTL_MODE_SETPLANE) needs to
>> provide the event such as DRM_MODE_PAGE_FL
On Wed, Apr 18, 2012 at 05:27:57PM +0200, Daniel Vetter wrote:
> On Wed, Apr 18, 2012 at 05:10:47PM +0200, Marcus Lorentzon wrote:
> > On 04/18/2012 04:36 PM, Daniel Vetter wrote:
> > >Last time around I've discussed with people we've ended up with 2 new
> > >ioctls:
> > >
> > >- atomic modeset, to
https://bugs.freedesktop.org/show_bug.cgi?id=48880
--- Comment #9 from Alex Deucher 2012-04-18 12:04:05 PDT
---
How is this monitor connected? Analog VGA or digital TMDS?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: --
On Wed, Apr 18, 2012 at 01:31:59PM +0900, Joonyoung Shim wrote:
> DRM_MODE_PLANE_EVENT is similar to DRM_MODE_PAGE_FLIP_EVENT but it is
> for a plane. The setplane ioctl (DRM_IOCTL_MODE_SETPLANE) needs to
> provide the event such as DRM_MODE_PAGE_FLIP_EVENT. The setplane ioctl
> can change the fram
On 04/18/2012 06:06 PM, Ville Syrj?l? wrote:
>> > If you smash everything into one ioctl, I imagine you have plenty of fun
>> > implementing all this. Which is why I prefer to split this up.
> I don't think there's that much differnce. You build up the full device
> state, check it, and when you'
On 04/18/2012 05:43 PM, Luc Verhaegen wrote:
> This means that there should be (at least) three separate actions:
> * page flipping: buffers -> planes at next vblank, for a list of
> buffer(s) and plane tuples.
> * setplanes: colour format, position, scaling, ordering, rotation, color
> key, crtc
On 04/18/2012 05:27 PM, Daniel Vetter wrote:
> On Wed, Apr 18, 2012 at 05:10:47PM +0200, Marcus Lorentzon wrote:
>> On 04/18/2012 04:36 PM, Daniel Vetter wrote:
>>> Last time around I've discussed with people we've ended up with 2 new
>>> ioctls:
>>>
>>> - atomic modeset, to configure the output st
On Wed, Apr 18, 2012 at 05:10:47PM +0200, Marcus Lorentzon wrote:
> On 04/18/2012 04:36 PM, Daniel Vetter wrote:
>> Last time around I've discussed with people we've ended up with 2 new
>> ioctls:
>>
>> - atomic modeset, to configure the output state on more than one crtc at
>>the same time. Th
On Wed, Apr 18, 2012 at 05:10:47PM +0200, Marcus Lorentzon wrote:
> On 04/18/2012 04:36 PM, Daniel Vetter wrote:
> >Last time around I've discussed with people we've ended up with 2 new
> >ioctls:
> >
> >- atomic modeset, to configure the output state on more than one crtc at
> > the same time. T
On Wed, Apr 18, 2012 at 04:04:56PM +0200, Marcus Lorentzon wrote:
> On 04/18/2012 02:25 PM, Rob Clark wrote:
> > On Wed, Apr 18, 2012 at 5:11 AM, Joonyoung Shim
> > wrote:
> >> On 04/18/2012 05:46 PM, Daniel Vetter wrote:
> >>> On Wed, Apr 18, 2012 at 01:31:59PM +0900, Joonyoung Shim wrote:
> >>>
On 04/18/2012 04:36 PM, Daniel Vetter wrote:
> Last time around I've discussed with people we've ended up with 2 new
> ioctls:
>
> - atomic modeset, to configure the output state on more than one crtc at
>the same time. This is useful to get pll assignement, memory bandwidth
>constrains and
On 04/18/2012 04:26 PM, Ville Syrj?l? wrote:
> On Wed, Apr 18, 2012 at 04:04:56PM +0200, Marcus Lorentzon wrote:
>> On 04/18/2012 02:25 PM, Rob Clark wrote:
>>> On Wed, Apr 18, 2012 at 5:11 AM, Joonyoung Shim
>>> wrote:
On 04/18/2012 05:46 PM, Daniel Vetter wrote:
> On Wed, Apr 18, 2012
On Wed, Apr 18, 2012 at 05:26:07PM +0300, Ville Syrj?l? wrote:
> On Wed, Apr 18, 2012 at 04:04:56PM +0200, Marcus Lorentzon wrote:
> > On 04/18/2012 02:25 PM, Rob Clark wrote:
> > > On Wed, Apr 18, 2012 at 5:11 AM, Joonyoung Shim > > samsung.com> wrote:
> > >> On 04/18/2012 05:46 PM, Daniel Vetter
On Wed, Apr 18, 2012 at 02:06:13PM +, Arnd Bergmann wrote:
> On Wednesday 18 April 2012, Daniel Vetter wrote:
> > + Because existing importing subsystems might presume coherent mappings
> > for
> > + userspace, the exporter needs to set up a coherent mapping. If that's
> > not
> > + pos
On 04/18/2012 02:25 PM, Rob Clark wrote:
> On Wed, Apr 18, 2012 at 5:11 AM, Joonyoung Shim
> wrote:
>> On 04/18/2012 05:46 PM, Daniel Vetter wrote:
>>> On Wed, Apr 18, 2012 at 01:31:59PM +0900, Joonyoung Shim wrote:
DRM_MODE_PLANE_EVENT is similar to DRM_MODE_PAGE_FLIP_EVENT but it is
f
Compared to Rob Clark's RFC I've ditched the prepare/finish hooks
and corresponding ioctls on the dma_buf file. The major reason for
that is that many people seem to be under the impression that this is
also for synchronization with outstanding asynchronous processsing.
I'm pretty massively opposed
https://bugs.freedesktop.org/show_bug.cgi?id=48880
--- Comment #8 from Tvrtko Ursulin 2012-04-18
08:44:56 PDT ---
(In reply to comment #7)
> Try switching to another mode first then switch the new one you added.
I did exactly that :)
--
Configure bugmail: https://bugs.freedesktop.org/userpref
https://bugs.freedesktop.org/show_bug.cgi?id=48880
--- Comment #7 from Alex Deucher 2012-04-18 08:38:08 PDT
---
Try switching to another mode first then switch the new one you added.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail
https://bugs.freedesktop.org/show_bug.cgi?id=48894
--- Comment #10 from Bryce Harrington 2012-04-18 15:34:25
PDT ---
ok looks like a core drm kernel bug
we don't lock properly around initialization
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are rec
https://bugs.freedesktop.org/show_bug.cgi?id=48880
--- Comment #6 from Tvrtko Ursulin 2012-04-18
08:34:44 PDT ---
(In reply to comment #5)
> If you manually add the 1920x1080 modeline with xrandr, does it work ok?
>
> E.g.,
>
> xrandr --newmode "my1920x1080" 148.50 1920 2008 2052 2200 1080
https://bugs.freedesktop.org/show_bug.cgi?id=48894
Bryce Harrington changed:
What|Removed |Added
AssignedTo|ch...@chris-wilson.co.uk|dri-devel@lists.freedesktop
https://bugs.freedesktop.org/show_bug.cgi?id=48880
--- Comment #5 from Alex Deucher 2012-04-18 08:25:53 PDT
---
If you manually add the 1920x1080 modeline with xrandr, does it work ok?
E.g.,
xrandr --newmode "my1920x1080" 148.50 1920 2008 2052 2200 1080 1084 1089
1125 +hsync +vsync
xrandr -
https://bugs.freedesktop.org/show_bug.cgi?id=48880
--- Comment #4 from Tvrtko Ursulin 2012-04-18
08:25:15 PDT ---
So it all looks right (pixel clock wise) in radeon_compute_pll_avivo. I guess
atombios_crtc_set_pll calls atombios_crtc_program_ss to program the hardware.
Could things be going wron
The check of the encoder type in the commit [e00e8b5e: drm/radeon/kms:
fix analog load detection on DVI-I connectors] is obviously wrong, and
it's the culprit of the regression on my workstation with DVI-analog
connection resulting in the blank output.
Fixed the typo now.
Cc:
Signed-off-by: Taka
At Wed, 18 Apr 2012 14:39:54 +0200,
Takashi Iwai wrote:
>
> Hi,
>
> I noticed that one machine here gives only the blank output with
> 3.4-rc's. The bisection lead me to affecting commit:
>
> commit e00e8b5e760cbbe9067daeae5454d67c44c8d035
> Author: Alex Deucher
> Date: Fri Mar 1
https://bugs.freedesktop.org/show_bug.cgi?id=48880
--- Comment #3 from Tvrtko Ursulin 2012-04-18
08:18:54 PDT ---
Some debug showing the modeset itself:
[ 2405.577713] [drm:drm_crtc_helper_set_config], modes are different, full mode
set
[ 2405.577721] [drm:drm_mode_debug_printmodeline], Modeli
https://bugs.freedesktop.org/show_bug.cgi?id=48422
Jonathan Nieder changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=48880
--- Comment #2 from Tvrtko Ursulin 2012-04-18
08:08:39 PDT ---
I've tried setting a handful of other resolutions via the xrandr tool and in
all cases monitors reported clock matches the above list. Only 1920x1080 seems
broken.
--
Configure bug
https://bugs.freedesktop.org/show_bug.cgi?id=48880
--- Comment #1 from Tvrtko Ursulin 2012-04-18
08:07:47 PDT ---
Kernel view of the modelines:
[ 1749.396456] [drm:drm_mode_debug_printmodeline], Modeline 18:"1920x1080" 60
148500 1920 2008 2052 2200 1080 1084 1089 1125 0x48 0x5
[ 1749.396472] [d
https://bugs.freedesktop.org/show_bug.cgi?id=48880
Bug #: 48880
Summary: Set mode has different timings than requested on VGA
Classification: Unclassified
Product: DRI
Version: unspecified
Platform: Other
OS/Version: All
Hi,
I noticed that one machine here gives only the blank output with
3.4-rc's. The bisection lead me to affecting commit:
commit e00e8b5e760cbbe9067daeae5454d67c44c8d035
Author: Alex Deucher
Date: Fri Mar 16 12:22:09 2012 -0400
drm/radeon/kms: fix analog load detection on DVI
https://bugs.freedesktop.org/show_bug.cgi?id=48772
--- Comment #9 from Roland Scheidegger 2012-04-18 14:21:14
PDT ---
(In reply to comment #8)
> That's the max theoretical mode supported by the chip. Whether or not you can
> drive a monitor that big probably depends on the type and speed of dra
> That frequency seems about the same as the one I'm experiences. All though
> some times it's more often, but I can't say I've done anything special at
> the same time.
>
> 3.3.2-1-ARCH
> Intel(R) Atom(TM) CPU Z520 @ 1.33GHz
>
> Attachment: dmesg ouput
>
What X display server are you using (fb
https://bugs.freedesktop.org/show_bug.cgi?id=46711
Alex Deucher changed:
What|Removed |Added
Attachment #60177|0 |1
is obsolete|
On Wednesday 18 April 2012, Daniel Vetter wrote:
> + Because existing importing subsystems might presume coherent mappings for
> + userspace, the exporter needs to set up a coherent mapping. If that's not
> + possible, it needs to fake coherency by manually shooting down ptes when
> + leavi
Free event and restore event_space only when page_flip->flags has
DRM_MODE_PAGE_FLIP_EVENT if page_flip() is failed.
Signed-off-by: Joonyoung Shim
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/drm_crtc.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/driver
DRM_MODE_PLANE_EVENT is similar to DRM_MODE_PAGE_FLIP_EVENT but it is
for a plane. The setplane ioctl (DRM_IOCTL_MODE_SETPLANE) needs to
provide the event such as DRM_MODE_PAGE_FLIP_EVENT. The setplane ioctl
can change the framebuffer of plane but user can't know completion of
changing the framebuf
https://bugs.freedesktop.org/show_bug.cgi?id=48880
--- Comment #10 from Alex Deucher 2012-04-18 12:22:55 PDT ---
Is it only problematic on VGA or TMDS? I.e., does one only one or the other,
but not both? It seems to be something specific to your monitor. I can't
reproduce this on my ontario ha
> How do you ensure that no device can do DMA on the buffer while it's mapped
> into user space in a noncoherent manner?
Why do we want to enforce that ? We provide the appropriate base service
but you need to know what you are doing. In reality a lot of use cases
are going to need far more than a
On Wed, Apr 18, 2012 at 05:55:15PM +0200, Marcus Lorentzon wrote:
> On 04/18/2012 05:27 PM, Daniel Vetter wrote:
> >On Wed, Apr 18, 2012 at 05:10:47PM +0200, Marcus Lorentzon wrote:
> >>On 04/18/2012 04:36 PM, Daniel Vetter wrote:
> >>>Last time around I've discussed with people we've ended up with
https://bugs.freedesktop.org/show_bug.cgi?id=48880
--- Comment #9 from Alex Deucher 2012-04-18 12:04:05 PDT ---
How is this monitor connected? Analog VGA or digital TMDS?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
This patch adds a new constructor for an sg table. The table is constructed
from an array of struct pages. All contiguous chunks of the pages are merged
into a single sg nodes. A user may provide an offset and a size of a buffer if
the buffer is not page-aligned.
The function is dedicated for DMAB
On Wed, Apr 18, 2012 at 07:06:10PM +0300, Ville Syrjälä wrote:
> On Wed, Apr 18, 2012 at 05:27:57PM +0200, Daniel Vetter wrote:
> > Also, I'm toying around with ideas to split up the big modeset lock such
> > that operations that only touch the crtc (like pageflip, plane changes and
> > cursor chan
https://bugs.freedesktop.org/show_bug.cgi?id=48599
--- Comment #1 from Michel D?nzer 2012-04-18 04:17:28
PDT ---
(In reply to comment #1)
> It was written by Jan Engelhardt
Would it be possible to get a Signed-off-by: from him?
BTW, it might have been easier to just submit the patch to the dr
On Wed, Apr 18, 2012 at 01:31:59PM +0900, Joonyoung Shim wrote:
> DRM_MODE_PLANE_EVENT is similar to DRM_MODE_PAGE_FLIP_EVENT but it is
> for a plane. The setplane ioctl (DRM_IOCTL_MODE_SETPLANE) needs to
> provide the event such as DRM_MODE_PAGE_FLIP_EVENT. The setplane ioctl
> can change the fram
On Wed, Apr 18, 2012 at 01:31:59PM +0900, Joonyoung Shim wrote:
> DRM_MODE_PLANE_EVENT is similar to DRM_MODE_PAGE_FLIP_EVENT but it is
> for a plane. The setplane ioctl (DRM_IOCTL_MODE_SETPLANE) needs to
> provide the event such as DRM_MODE_PAGE_FLIP_EVENT. The setplane ioctl
> can change the fram
On Wed, Apr 18, 2012 at 9:21 AM, Takashi Iwai wrote:
> The check of the encoder type in the commit [e00e8b5e: drm/radeon/kms:
> fix analog load detection on DVI-I connectors] is obviously wrong, and
> it's the culprit of the regression on my workstation with DVI-analog
> connection resulting in th
From: Alex Deucher
Reported-by: Takashi Iwai
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_connectors.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
b/drivers/gpu/drm/radeon/r
On 04/18/2012 06:06 PM, Ville Syrjälä wrote:
> If you smash everything into one ioctl, I imagine you have plenty of fun
> implementing all this. Which is why I prefer to split this up.
I don't think there's that much differnce. You build up the full device
state, check it, and when you're read
On Wed, Apr 18, 2012 at 8:39 AM, Takashi Iwai wrote:
> Hi,
>
> I noticed that one machine here gives only the blank output with
> 3.4-rc's. ?The bisection lead me to affecting commit:
>
> ? ?commit e00e8b5e760cbbe9067daeae5454d67c44c8d035
> ? ?Author: Alex Deucher
> ? ?Date: ? Fri Mar 16 12:22:09
On Wed, Apr 18, 2012 at 9:06 AM, Arnd Bergmann wrote:
> On Wednesday 18 April 2012, Daniel Vetter wrote:
>> + ? Because existing importing subsystems might presume coherent mappings for
>> + ? userspace, the exporter needs to set up a coherent mapping. If that's not
>> + ? possible, it needs to fa
On Wed, Apr 18, 2012 at 05:27:57PM +0200, Daniel Vetter wrote:
> On Wed, Apr 18, 2012 at 05:10:47PM +0200, Marcus Lorentzon wrote:
> > On 04/18/2012 04:36 PM, Daniel Vetter wrote:
> > >Last time around I've discussed with people we've ended up with 2 new
> > >ioctls:
> > >
> > >- atomic modeset, to
On Wed, 18 Apr 2012 17:55:15 +0200
Marcus Lorentzon wrote:
> The async vs sync makes sense as reason for splitting them. My problem
> lies somewhere in between sync modeset and async flip - async
> crtc/plane/fbs modeset.
> In Wayland and Android HW composer I need to asynchronously flip and do
On Wed, 18 Apr 2012 17:55:15 +0200
Marcus Lorentzon wrote:
> The async vs sync makes sense as reason for splitting them. My problem
> lies somewhere in between sync modeset and async flip - async
> crtc/plane/fbs modeset.
> In Wayland and Android HW composer I need to asynchronously flip and do
On 04/18/2012 05:43 PM, Luc Verhaegen wrote:
This means that there should be (at least) three separate actions:
* page flipping: buffers -> planes at next vblank, for a list of
buffer(s) and plane tuples.
* setplanes: colour format, position, scaling, ordering, rotation, color
key, crtc adheranc
On Wed, 18 Apr 2012 16:58:36 +0200
Marcus Lorentzon wrote:
> On 04/18/2012 04:26 PM, Ville Syrjälä wrote:
> Yes, from previous emails I have seen that we are quite aligned on the
> single-atomic-modeset-with-properties version.
>
> Do you have any actual proposal for this? Like the API at leas
On Wed, 18 Apr 2012 16:58:36 +0200
Marcus Lorentzon wrote:
> On 04/18/2012 04:26 PM, Ville Syrj?l? wrote:
> Yes, from previous emails I have seen that we are quite aligned on the
> single-atomic-modeset-with-properties version.
>
> Do you have any actual proposal for this? Like the API at leas
On 04/18/2012 05:27 PM, Daniel Vetter wrote:
On Wed, Apr 18, 2012 at 05:10:47PM +0200, Marcus Lorentzon wrote:
On 04/18/2012 04:36 PM, Daniel Vetter wrote:
Last time around I've discussed with people we've ended up with 2 new
ioctls:
- atomic modeset, to configure the output state on more than
From: Rob Clark
There are still a few places to cleanup, and possibly things can be
made a bit easier for individual drm drivers by some helpers in drm
core. But this is enough for a proof of concept.
With this, I can allocate cached buffers, fill them w/ software from
userspace, and on kernel
On Wed, Apr 18, 2012 at 05:10:47PM +0200, Marcus Lorentzon wrote:
> On 04/18/2012 04:36 PM, Daniel Vetter wrote:
>> Last time around I've discussed with people we've ended up with 2 new
>> ioctls:
>>
>> - atomic modeset, to configure the output state on more than one crtc at
>>the same time. Th
https://bugs.freedesktop.org/show_bug.cgi?id=48880
--- Comment #8 from Tvrtko Ursulin 2012-04-18
08:44:56 PDT ---
(In reply to comment #7)
> Try switching to another mode first then switch the new one you added.
I did exactly that :)
--
Configure bugmail: https://bugs.freedesktop.org/userpref
https://bugs.freedesktop.org/show_bug.cgi?id=48880
--- Comment #7 from Alex Deucher 2012-04-18 08:38:08 PDT ---
Try switching to another mode first then switch the new one you added.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail b
https://bugs.freedesktop.org/show_bug.cgi?id=48880
--- Comment #6 from Tvrtko Ursulin 2012-04-18
08:34:44 PDT ---
(In reply to comment #5)
> If you manually add the 1920x1080 modeline with xrandr, does it work ok?
>
> E.g.,
>
> xrandr --newmode "my1920x1080" 148.50 1920 2008 2052 2200 1080
On Wed, Apr 18, 2012 at 05:10:47PM +0200, Marcus Lorentzon wrote:
> On 04/18/2012 04:36 PM, Daniel Vetter wrote:
> >Last time around I've discussed with people we've ended up with 2 new
> >ioctls:
> >
> >- atomic modeset, to configure the output state on more than one crtc at
> > the same time. T
https://bugs.freedesktop.org/show_bug.cgi?id=48880
--- Comment #5 from Alex Deucher 2012-04-18 08:25:53 PDT ---
If you manually add the 1920x1080 modeline with xrandr, does it work ok?
E.g.,
xrandr --newmode "my1920x1080" 148.50 1920 2008 2052 2200 1080 1084 1089
1125 +hsync +vsync
xrandr --
https://bugs.freedesktop.org/show_bug.cgi?id=48880
--- Comment #4 from Tvrtko Ursulin 2012-04-18
08:25:15 PDT ---
So it all looks right (pixel clock wise) in radeon_compute_pll_avivo. I guess
atombios_crtc_set_pll calls atombios_crtc_program_ss to program the hardware.
Could things be going wron
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 16/04/12 18:29, Yinghai Lu wrote:
> On Sun, Apr 15, 2012 at 11:54 PM, Yinghai Lu
> wrote:
>> On Sun, Apr 15, 2012 at 1:06 PM, Yinghai Lu
>> wrote:
3. use pci_bus_allocate_resource in drm/radeon driver ...
===> but that could fail. so cou
https://bugs.freedesktop.org/show_bug.cgi?id=48880
--- Comment #3 from Tvrtko Ursulin 2012-04-18
08:18:54 PDT ---
Some debug showing the modeset itself:
[ 2405.577713] [drm:drm_crtc_helper_set_config], modes are different, full mode
set
[ 2405.577721] [drm:drm_mode_debug_printmodeline], Modeli
https://bugs.freedesktop.org/show_bug.cgi?id=46711
--- Comment #15 from Tvrtko Ursulin 2012-04-18
01:16:19 PDT ---
In fact, with the patch monitor is no longer in power save mode after cable
re-plug (whereas without the patch it would be), but in some strange state
where the screen is black and
On 04/18/2012 04:36 PM, Daniel Vetter wrote:
Last time around I've discussed with people we've ended up with 2 new
ioctls:
- atomic modeset, to configure the output state on more than one crtc at
the same time. This is useful to get pll assignement, memory bandwidth
constrains and similar
https://bugs.freedesktop.org/show_bug.cgi?id=48880
--- Comment #2 from Tvrtko Ursulin 2012-04-18
08:08:39 PDT ---
I've tried setting a handful of other resolutions via the xrandr tool and in
all cases monitors reported clock matches the above list. Only 1920x1080 seems
broken.
--
Configure bug
https://bugs.freedesktop.org/show_bug.cgi?id=48880
--- Comment #1 from Tvrtko Ursulin 2012-04-18
08:07:47 PDT ---
Kernel view of the modelines:
[ 1749.396456] [drm:drm_mode_debug_printmodeline], Modeline 18:"1920x1080" 60
148500 1920 2008 2052 2200 1080 1084 1089 1125 0x48 0x5
[ 1749.396472] [d
https://bugs.freedesktop.org/show_bug.cgi?id=46711
--- Comment #14 from Tvrtko Ursulin 2012-04-18
00:59:41 PDT ---
(In reply to comment #13)
> Run through ssh "udevadm monitor" when pluging/unpluging screen you should see
> event there. If you don't it's kernel issue, if you do it might be your
On 04/18/2012 04:26 PM, Ville Syrjälä wrote:
On Wed, Apr 18, 2012 at 04:04:56PM +0200, Marcus Lorentzon wrote:
On 04/18/2012 02:25 PM, Rob Clark wrote:
On Wed, Apr 18, 2012 at 5:11 AM, Joonyoung Shim
wrote:
On 04/18/2012 05:46 PM, Daniel Vetter wrote:
On Wed, Apr 18, 2012 at 01:31:59PM +09
https://bugs.freedesktop.org/show_bug.cgi?id=48880
Bug #: 48880
Summary: Set mode has different timings than requested on VGA
Classification: Unclassified
Product: DRI
Version: unspecified
Platform: Other
OS/Version: All
On Mit, 2012-04-18 at 13:47 +0900, Joonyoung Shim wrote:
> Free event and restore event_space only when page_flip->flags has
> DRM_MODE_PAGE_FLIP_EVENT if page_flip() is failed.
>
> Signed-off-by: Joonyoung Shim
> Signed-off-by: Kyungmin Park
> ---
> drivers/gpu/drm/drm_crtc.c | 10 ++---
On Wed, Apr 18, 2012 at 05:26:07PM +0300, Ville Syrjälä wrote:
> On Wed, Apr 18, 2012 at 04:04:56PM +0200, Marcus Lorentzon wrote:
> > On 04/18/2012 02:25 PM, Rob Clark wrote:
> > > On Wed, Apr 18, 2012 at 5:11 AM, Joonyoung Shim
> > > wrote:
> > >> On 04/18/2012 05:46 PM, Daniel Vetter wrote:
>
On Wed, Apr 18, 2012 at 04:04:56PM +0200, Marcus Lorentzon wrote:
> On 04/18/2012 02:25 PM, Rob Clark wrote:
> > On Wed, Apr 18, 2012 at 5:11 AM, Joonyoung Shim
> > wrote:
> >> On 04/18/2012 05:46 PM, Daniel Vetter wrote:
> >>> On Wed, Apr 18, 2012 at 01:31:59PM +0900, Joonyoung Shim wrote:
> >>>
On Wed, Apr 18, 2012 at 02:06:13PM +, Arnd Bergmann wrote:
> On Wednesday 18 April 2012, Daniel Vetter wrote:
> > + Because existing importing subsystems might presume coherent mappings
> > for
> > + userspace, the exporter needs to set up a coherent mapping. If that's
> > not
> > + pos
On Wed, Apr 18, 2012 at 5:11 AM, Joonyoung Shim
wrote:
>
> On 04/18/2012 05:46 PM, Daniel Vetter wrote:
>>
>> On Wed, Apr 18, 2012 at 01:31:59PM +0900, Joonyoung Shim wrote:
>>>
>>> DRM_MODE_PLANE_EVENT is similar to DRM_MODE_PAGE_FLIP_EVENT but it is
>>> for a plane. The setplane ioctl (DRM_IOCT
On Wed, Apr 18, 2012 at 9:06 AM, Arnd Bergmann wrote:
> On Wednesday 18 April 2012, Daniel Vetter wrote:
>> + Because existing importing subsystems might presume coherent mappings for
>> + userspace, the exporter needs to set up a coherent mapping. If that's not
>> + possible, it needs to fa
https://bugs.freedesktop.org/show_bug.cgi?id=17902
--- Comment #68 from Daniel Vetter 2012-04-18 00:22:02 PDT
---
Yeah, the second i2cdetect dump looks much more reasonable, and it looks like
you've indeed found the right bus for your i2c device. So the next step is to
use that one with dev_priv
https://bugs.freedesktop.org/show_bug.cgi?id=46711
Alex Deucher changed:
What|Removed |Added
Attachment #60177|0 |1
is obsolete|
On Wednesday 18 April 2012, Daniel Vetter wrote:
> + Because existing importing subsystems might presume coherent mappings for
> + userspace, the exporter needs to set up a coherent mapping. If that's not
> + possible, it needs to fake coherency by manually shooting down ptes when
> + leavi
On 04/18/2012 02:25 PM, Rob Clark wrote:
On Wed, Apr 18, 2012 at 5:11 AM, Joonyoung Shim wrote:
On 04/18/2012 05:46 PM, Daniel Vetter wrote:
On Wed, Apr 18, 2012 at 01:31:59PM +0900, Joonyoung Shim wrote:
DRM_MODE_PLANE_EVENT is similar to DRM_MODE_PAGE_FLIP_EVENT but it is
for a plane. The s
From: Rob Clark
There are still a few places to cleanup, and possibly things can be
made a bit easier for individual drm drivers by some helpers in drm
core. But this is enough for a proof of concept.
With this, I can allocate cached buffers, fill them w/ software from
userspace, and on kernel
Compared to Rob Clark's RFC I've ditched the prepare/finish hooks
and corresponding ioctls on the dma_buf file. The major reason for
that is that many people seem to be under the impression that this is
also for synchronization with outstanding asynchronous processsing.
I'm pretty massively opposed
On Wed, Apr 18, 2012 at 9:21 AM, Takashi Iwai wrote:
> The check of the encoder type in the commit [e00e8b5e: drm/radeon/kms:
> fix analog load detection on DVI-I connectors] is obviously wrong, and
> it's the culprit of the regression on my workstation with DVI-analog
> connection resulting in th
From: Alex Deucher
Reported-by: Takashi Iwai
Signed-off-by: Alex Deucher
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_connectors.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
b/drivers/gpu/drm/radeon/rade
1 - 100 of 114 matches
Mail list logo
