On Tue, 29 May 2012 19:41:37 -0700, Linus Torvalds
wrote:
> On Mon, May 28, 2012 at 12:06 AM, Chris Wilson
> wrote:
> >
> > No, the i915_error_state had everything I needed to see. It is the old
> > ddx bug that was hardcoding a maximum relocation address that never
> > corresponded with an act
On Tue, 29 May 2012 19:41:37 -0700, Linus Torvalds
wrote:
> On Mon, May 28, 2012 at 12:06 AM, Chris Wilson
> wrote:
> >
> > No, the i915_error_state had everything I needed to see. It is the old
> > ddx bug that was hardcoding a maximum relocation address that never
> > corresponded with an act
On Tue, May 29, 2012 at 07:41:37PM -0700, Linus Torvalds wrote:
> On Mon, May 28, 2012 at 12:06 AM, Chris Wilson
> wrote:
> >
> > No, the i915_error_state had everything I needed to see. It is the old
> > ddx bug that was hardcoding a maximum relocation address that never
> > corresponded with an
On Mon, May 28, 2012 at 08:51:51PM +0200, Daniel Vetter wrote:
> On Mon, May 28, 2012 at 1:09 AM, Linus Torvalds
> wrote:
> > A new worry about excessively verbose i915 driver "errors" that don't
> > actually seem to be errors.
> >
> > I got myself a micro-DP to VGA adapter so that I can use my Ma
On Wed, May 30, 2012 at 01:01:08AM +0200, Laurent Pinchart wrote:
> The passed mode must not be modified by the operation, make it const.
>
> Signed-off-by: Laurent Pinchart
Acked-by: Daniel Vetter
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
__
Hi Daniel,
On Wednesday 30 May 2012 11:18:56 Daniel Vetter wrote:
> On Wed, May 30, 2012 at 01:01:08AM +0200, Laurent Pinchart wrote:
> > The passed mode must not be modified by the operation, make it const.
> >
> > Signed-off-by: Laurent Pinchart
>
> Acked-by: Daniel Vetter
Thank you for the
On Wed, May 30, 2012 at 11:24:50AM +0200, Laurent Pinchart wrote:
> Hi Daniel,
>
> On Wednesday 30 May 2012 11:18:56 Daniel Vetter wrote:
> > On Wed, May 30, 2012 at 01:01:08AM +0200, Laurent Pinchart wrote:
> > > The passed mode must not be modified by the operation, make it const.
> > >
> > > S
Hi Daniel,
On Wednesday 30 May 2012 12:02:19 Daniel Vetter wrote:
> On Wed, May 30, 2012 at 11:24:50AM +0200, Laurent Pinchart wrote:
> > On Wednesday 30 May 2012 11:18:56 Daniel Vetter wrote:
> > > On Wed, May 30, 2012 at 01:01:08AM +0200, Laurent Pinchart wrote:
> > > > The passed mode must not
Hi Linus,
just regular fixes, bunch from intel, quieting some of the over zealous
power warnings, and the rest just misc.
I've got another pull with the remaining dma-buf bits, since the vmap bits
are in your tree now. I'll send tomorrow just to space things out a bit.
Dave.
The following ch
On Tue, May 29, 2012 at 08:20:35PM +0200, Lars-Peter Clausen wrote:
> This patchset introduces a set of helper function for implementing the KMS
> framebuffer layer for drivers which use the drm gem CMA helper function.
I just integrated this into my series. Works great, thanks.
Would be great to
On Wed, May 30, 2012 at 12:11:49PM +0200, Laurent Pinchart wrote:
> Hi Daniel,
>
> On Wednesday 30 May 2012 12:02:19 Daniel Vetter wrote:
> > On Wed, May 30, 2012 at 11:24:50AM +0200, Laurent Pinchart wrote:
> > > On Wednesday 30 May 2012 11:18:56 Daniel Vetter wrote:
> > > > On Wed, May 30, 2012
We should only frob adjusted_mode. This is in preparation of
a massive patch by Laurent Pinchart to make the mode argument
const.
The only thing we actually touch is mode->clock, but only if
it's a panel. And in that case we also set adjusted_mode->clock
to the same value. All the generic code alr
On Wed, 30 May 2012 12:28:04 +0200, Daniel Vetter
wrote:
> We should only frob adjusted_mode. This is in preparation of
> a massive patch by Laurent Pinchart to make the mode argument
> const.
>
> The only thing we actually touch is mode->clock, but only if
> it's a panel. And in that case we al
https://bugzilla.kernel.org/show_bug.cgi?id=43295
Alan changed:
What|Removed |Added
Status|NEW |NEEDINFO
CC|
https://bugzilla.kernel.org/show_bug.cgi?id=43295
--- Comment #3 from Alan 2012-05-30 11:26:43 ---
*** Bug 43288 has been marked as a duplicate of this bug. ***
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
Yo
On Mit, 2012-05-30 at 00:58 +0200, Laurent Pinchart wrote:
> DRM_IOCTL_MODESET_CTL must only be used for UMS drivers. Make it a no-op
> for KMS drivers.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/drm_irq.c |5 -
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
> My
On Wed, May 30, 2012 at 11:58:43AM +0100, Chris Wilson wrote:
> On Wed, 30 May 2012 12:28:04 +0200, Daniel Vetter
> wrote:
> > We should only frob adjusted_mode. This is in preparation of
> > a massive patch by Laurent Pinchart to make the mode argument
> > const.
> >
> > The only thing we actua
... instead of changing mode->clock, which we should leave as-is.
We only touch that if it's a panel, and then adjusted mode->clock
equals adjusted_mode->clock. Outside of intel_dp.c we only use
ajusted_mode->clock in the mode_set functions.
Within intel_dp.c we only use it to calculate the dp di
We should only frob adjusted_mode. This is in preparation of
a massive patch by Laurent Pinchart to make the mode argument
const.
After the prevous prep patch to use adjusted_mode->clock instead of
mode->clock the only thing left is to clean up things a bit. I've
opted to pass in an adjust_mode pa
On Wed, May 30, 2012 at 1:06 AM, Rafał Miłecki wrote:
> 2012/5/30 Sean Paul :
>> On Tue, May 29, 2012 at 5:23 PM, Alex Deucher wrote:
>>> On Tue, May 29, 2012 at 4:33 PM, Sean Paul wrote:
On Tue, May 29, 2012 at 10:43 AM, Alex Deucher
wrote:
> On Mon, May 28, 2012 at 1:20 PM, Sea
On Wed, 30 May 2012 13:52:02 +0200, Daniel Vetter
wrote:
> ... instead of changing mode->clock, which we should leave as-is.
>
> We only touch that if it's a panel, and then adjusted mode->clock
> equals adjusted_mode->clock. Outside of intel_dp.c we only use
> ajusted_mode->clock in the mode_se
Hi everybody,
Here's a new DRM driver for the Renesas SH Mobile display controller
(a.k.a. LCDC). The hardware is pretty simple and consists of a single CRTC and
four (non-scalable) planes that can be alpha-blended (first two planes only),
overlayed or composed using ROP3.
The first two patches w
Remove direct dependency on the MERAM driver implementation by
introducing inline wrappers for MERAM operations.
Signed-off-by: Laurent Pinchart
---
drivers/video/sh_mobile_meram.c | 24
include/video/sh_mobile_meram.h | 28
2 files chang
Signed-off-by: Laurent Pinchart
---
drivers/video/sh_mobile_lcdcfb.c | 18 +++---
1 files changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/video/sh_mobile_lcdcfb.c b/drivers/video/sh_mobile_lcdcfb.c
index 7a0b301..671685d 100644
--- a/drivers/video/sh_mobile_lcdcfb.c
Signed-off-by: Laurent Pinchart
---
include/drm/drm_fourcc.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index bdf0152..fac7235 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -106,6 +106,8 @
On Wed, May 30, 2012 at 01:18:35PM +0100, Chris Wilson wrote:
> On Wed, 30 May 2012 13:52:02 +0200, Daniel Vetter
> wrote:
> > ... instead of changing mode->clock, which we should leave as-is.
> >
> > We only touch that if it's a panel, and then adjusted mode->clock
> > equals adjusted_mode->clo
https://bugzilla.kernel.org/show_bug.cgi?id=12677
Alan changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://bugzilla.kernel.org/show_bug.cgi?id=12677
Alan changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--
Configure bugmail: https://bugzilla
On Wed, May 30, 2012 at 02:32:58PM +0200, Laurent Pinchart wrote:
> Signed-off-by: Laurent Pinchart
> ---
> include/drm/drm_fourcc.h |2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
> index bdf0152..fac7235 100644
Hi Ville,
Thank you for the review.
On Wednesday 30 May 2012 16:09:25 Ville Syrjälä wrote:
> On Wed, May 30, 2012 at 02:32:58PM +0200, Laurent Pinchart wrote:
> > Signed-off-by: Laurent Pinchart
> > ---
> >
> > include/drm/drm_fourcc.h |2 ++
> > 1 files changed, 2 insertions(+), 0 deletio
Am Mittwoch, den 30.05.2012, 13:52 +0200 schrieb Daniel Vetter:
Typo in »change« in the commit message.
> We should only frob adjusted_mode. This is in preparation of
> a massive patch by Laurent Pinchart to make the mode argument
> const.
>
> After the prevous prep patch to use adjusted_mode->c
Hi Laurent,
On Wed, May 30, 2012 at 02:32:59PM +0200, Laurent Pinchart wrote:
> The SH Mobile LCD controller (LCDC) DRM driver supports the main
> graphics plane in RGB and YUV formats, as well as the overlay planes (in
> alpha-blending mode only).
>
> Only flat panel outputs using the parallel i
On 05/30/2012 03:43 PM, Sascha Hauer wrote:
> Hi Laurent,
>
> On Wed, May 30, 2012 at 02:32:59PM +0200, Laurent Pinchart wrote:
>> The SH Mobile LCD controller (LCDC) DRM driver supports the main
>> graphics plane in RGB and YUV formats, as well as the overlay planes (in
>> alpha-blending mode onl
On Wed, May 30, 2012 at 03:20:09PM +0200, Laurent Pinchart wrote:
> Hi Ville,
>
> Thank you for the review.
>
> On Wednesday 30 May 2012 16:09:25 Ville Syrjälä wrote:
> > On Wed, May 30, 2012 at 02:32:58PM +0200, Laurent Pinchart wrote:
> > > Signed-off-by: Laurent Pinchart
> > > ---
> > >
> >
Hi Ville,
On Wednesday 30 May 2012 17:05:10 Ville Syrjälä wrote:
> On Wed, May 30, 2012 at 03:20:09PM +0200, Laurent Pinchart wrote:
> > On Wednesday 30 May 2012 16:09:25 Ville Syrjälä wrote:
> > > On Wed, May 30, 2012 at 02:32:58PM +0200, Laurent Pinchart wrote:
> > > > Signed-off-by: Laurent Pin
From: Alex Deucher
radeon_cs_parser_init is called by both the legacy UMS
CS ioctl and the KMS CS ioctl. Protect KMS specific
pieces of the code by checking that rdev is not NULL.
Reported-by: Michael Burian
Signed-off-by: Alex Deucher
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/radeon/r
Hi Sascha,
On Wednesday 30 May 2012 15:43:24 Sascha Hauer wrote:
> Hi Laurent,
>
> On Wed, May 30, 2012 at 02:32:59PM +0200, Laurent Pinchart wrote:
> > The SH Mobile LCD controller (LCDC) DRM driver supports the main
> > graphics plane in RGB and YUV formats, as well as the overlay planes (in
>
On Wed, May 30, 2012 at 02:32:59PM +0200, Laurent Pinchart wrote:
> +static struct drm_framebuffer *
> +shmob_drm_fb_create(struct drm_device *dev, struct drm_file *file_priv,
> + struct drm_mode_fb_cmd2 *mode_cmd)
> +{
> + const struct shmob_drm_format_info *format;
> + str
On 5/30/12 8:05 AM, Sean Paul wrote:
Yes, definitely. The reason I can't set it via xrandr (easily) is
because we look for lvds downclock modes (in i915) on the driver init.
Since the driver initializes way before we have a chance to add a new
mode via xrandr, the driver won't have a downclock m
https://bugzilla.kernel.org/show_bug.cgi?id=12796
Jonathan Nieder changed:
What|Removed |Added
CC||jrnie...@gmail.com
Alan changed:
https://bugzilla.kernel.org/show_bug.cgi?id=12796
Alan changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--
Configure bugmail: https://bugzilla
On 05/30/2012 02:32 PM, Laurent Pinchart wrote:
> [...]
> + for (i = 0; i < (format->yuv ? 2 : 1); ++i) {
> + obj = drm_gem_object_lookup(dev, file_priv,
> + mode_cmd->handles[i]);
> + if (obj == NULL) {
> + dev
On 05/30/2012 04:45 PM, Lars-Peter Clausen wrote:
> On 05/30/2012 02:32 PM, Laurent Pinchart wrote:
>> [...]
>> +for (i = 0; i < (format->yuv ? 2 : 1); ++i) {
>> +obj = drm_gem_object_lookup(dev, file_priv,
>> +mode_cmd->handles[i]);
>> +
On Wed, May 30, 2012 at 10:16 AM, Adam Jackson wrote:
> On 5/30/12 8:05 AM, Sean Paul wrote:
>
>> Yes, definitely. The reason I can't set it via xrandr (easily) is
>> because we look for lvds downclock modes (in i915) on the driver init.
>> Since the driver initializes way before we have a chance
This patch introduces a set of helper function for implementing the KMS
framebuffer layer for drivers which use the drm gem CMA helper function.
Signed-off-by: Lars-Peter Clausen
---
Changes since v1:
* Some spelling fixes
* Add missing kfree in drm_fb_cma_alloc error path
On Tue, May 29, 2012 at 6:25 AM, Laurent Pinchart
wrote:
> Hi Tomasz,
Hi Tomasz, Laurent, Mauro,
>
> On Wednesday 23 May 2012 14:10:14 Tomasz Stanislawski wrote:
>> Hello everyone,
>> This patchset adds support for DMABUF [2] importing to V4L2 stack.
>> The support for DMABUF exporting was moved t
On Wed, May 30, 2012 at 1:27 AM, Daniel Vetter wrote:
>
> Ok, Chris couldn't reproduce this on his mba. Can you please boot with
> drm.debug=0xe, reproduce the noise and then attach the full dmesg?
Hmm. Now *I* can't reproduce it either.
I have updated my system in the meantime, so maybe this is
Hi Sascha,
Thank you for the patch. I've successfully tested the helper with the new SH
Mobile DRM driver. Just a couple of comments below in addition to Lars'
comments (this is not a full review, just details that caught my attention
when comparing the code with my implementation, and trying t
On Wed, May 30, 2012 at 08:39:13AM -0700, Linus Torvalds wrote:
> On Wed, May 30, 2012 at 1:27 AM, Daniel Vetter wrote:
> >
> > Ok, Chris couldn't reproduce this on his mba. Can you please boot with
> > drm.debug=0xe, reproduce the noise and then attach the full dmesg?
>
> Hmm. Now *I* can't repr
https://bugzilla.kernel.org/show_bug.cgi?id=13132
Alan changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://bugzilla.kernel.org/show_bug.cgi?id=13132
Alan changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--
Configure bugmail: https://bugzilla
On Wed, May 30, 2012 at 9:00 AM, Daniel Vetter wrote:
>
> Hm, that's pretty strange that you can't reproduce this any more. We check
> this has_edp stuff once at boot and then never touch it again.
Actually, I think I just figured out how to reproduce it: try to
suspend with the micro-DP <-> VGA
On Wed, May 30, 2012 at 12:42 AM, Daniel Vetter wrote:
>
> Really, please upgrade your userspace - this is by far not the only bug
> fixed since then that can result in a gpu hang.
I *can't* upgrade my userpsace.
F14 is the last one that has a sane window manager. After that, the
gnome3 shit hap
On Wed, May 30, 2012 at 12:25 AM, Chris Wilson wrote:
>
> You've reported this bug in the past, though maybe on a different machine:
It's quite likely the same machine - but in the past it may have
happened once per six months or something. Now it happened twice in
two days.
Li
https://bugzilla.kernel.org/show_bug.cgi?id=13170
Alan changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
CC|
https://bugzilla.kernel.org/show_bug.cgi?id=13170
Alan changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--
Configure bugmail: https://bugzilla
On Wed, May 30, 2012 at 05:40:13PM +0200, Laurent Pinchart wrote:
> Hi Sascha,
>
> Thank you for the patch. I've successfully tested the helper with the new SH
> Mobile DRM driver. Just a couple of comments below in addition to Lars'
> comments (this is not a full review, just details that caugh
On Wed, May 30, 2012 at 02:32:59PM +0200, Laurent Pinchart wrote:
> The SH Mobile LCD controller (LCDC) DRM driver supports the main
> graphics plane in RGB and YUV formats, as well as the overlay planes (in
> alpha-blending mode only).
>
> Only flat panel outputs using the parallel interface are
Hi Michel,
On Wednesday 30 May 2012 13:29:06 Michel Dänzer wrote:
> On Mit, 2012-05-30 at 00:58 +0200, Laurent Pinchart wrote:
> > DRM_IOCTL_MODESET_CTL must only be used for UMS drivers. Make it a no-op
> > for KMS drivers.
> >
> > Signed-off-by: Laurent Pinchart
> > ---
> >
> > drivers/gpu/d
On Sun, 27 May 2012 13:16:54 -0700, Ben Widawsky wrote:
> diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
> index b776d2f..695a449 100644
> --- a/intel/intel_bufmgr_gem.c
> +++ b/intel/intel_bufmgr_gem.c
> @@ -1478,6 +1478,32 @@ drm_intel_gem_bo_wait_rendering(drm_intel_bo *bo)
>
On Wed, 30 May 2012 10:41:20 -0700
Eric Anholt wrote:
> On Sun, 27 May 2012 13:16:54 -0700, Ben Widawsky wrote:
> > diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
> > index b776d2f..695a449 100644
> > --- a/intel/intel_bufmgr_gem.c
> > +++ b/intel/intel_bufmgr_gem.c
> > @@ -147
https://bugs.freedesktop.org/show_bug.cgi?id=45018
--- Comment #56 from Alexandre Demers 2012-05-30
11:18:28 PDT ---
(In reply to comment #55)
> (In reply to comment #54)
> > On latest git (3cd7bee48f7caf7850ea64d40f43875d4c975507), in
> > src/gallium/drivers/r600/r66_hw_context.c, on line 194,
On Wed, May 30, 2012 at 7:41 PM, Eric Anholt wrote:
> I guess GL_ALREADY_SIGNALED handling will be done using a check for
> bo_busy() before calling this.
I've just read through the mesa code and gl_already_signalled seems to
be handled already by core mesa code in _mesa_ClientWaitSync (if the
dr
On Wed, 30 May 2012 21:07:57 +0200
Daniel Vetter wrote:
> On Wed, May 30, 2012 at 7:41 PM, Eric Anholt wrote:
> > I guess GL_ALREADY_SIGNALED handling will be done using a check for
> > bo_busy() before calling this.
>
> I've just read through the mesa code and gl_already_signalled seems to
> b
6 bytes seems to be a reasonable default so far, but for the desperate
it's worth exposing this.
Bugzilla: https://bugzilla.redhat.com/582559
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/dr
On this hardware:
00:02.0 VGA compatible controller: Intel Corporation 82945G/GZ Integrated
Graphics Controller (rev 02)
I get this every boot with Linus current tree (up to
af56e0aa35f3ae2a4c1a6d1000702df1dd78cb76)
[8.046291] udevadm used greatest stack depth: 4952 bytes left
[8.15320
On Wed, May 30, 2012 at 11:31 PM, Dave Jones wrote:
> On this hardware:
>
> 00:02.0 VGA compatible controller: Intel Corporation 82945G/GZ Integrated
> Graphics Controller (rev 02)
>
> I get this every boot with Linus current tree (up to
> af56e0aa35f3ae2a4c1a6d1000702df1dd78cb76)
Just a quick
On Wed, May 30, 2012 at 11:51:54PM +0200, Daniel Vetter wrote:
> On Wed, May 30, 2012 at 11:31 PM, Dave Jones wrote:
> > On this hardware:
> >
> > 00:02.0 VGA compatible controller: Intel Corporation 82945G/GZ Integrated
> > Graphics Controller (rev 02)
> >
> > I get this every boot with L
On Wed, May 30, 2012 at 05:58:48PM -0400, Dave Jones wrote:
> On Wed, May 30, 2012 at 11:51:54PM +0200, Daniel Vetter wrote:
> > On Wed, May 30, 2012 at 11:31 PM, Dave Jones wrote:
> > > On this hardware:
> > >
> > > 00:02.0 VGA compatible controller: Intel Corporation 82945G/GZ
> Integ
On Wed, May 30, 2012 at 10:09 AM, wrote:
> From: Alex Deucher
>
> radeon_cs_parser_init is called by both the legacy UMS
> CS ioctl and the KMS CS ioctl. Protect KMS specific
> pieces of the code by checking that rdev is not NULL.
>
> Reported-by: Michael Burian
>
> Signed-off-by: Alex Deucher
On Wed, 30 May 2012 21:07:57 +0200, Daniel Vetter wrote:
> On Wed, May 30, 2012 at 7:41 PM, Eric Anholt wrote:
> > I guess GL_ALREADY_SIGNALED handling will be done using a check for
> > bo_busy() before calling this.
>
> I've just read through the mesa code and gl_already_signalled seems to
> b
https://bugs.freedesktop.org/show_bug.cgi?id=49981
--- Comment #1 from Brad Campbell 2012-05-30 19:13:12
PDT ---
Created attachment 62305
--> https://bugs.freedesktop.org/attachment.cgi?id=62305
The hack I use to enable 3 heads on my iMac without torching the Radeon
--
Configure bugmail: htt
https://bugs.freedesktop.org/show_bug.cgi?id=49981
--- Comment #2 from Brad Campbell 2012-05-30 19:15:29
PDT ---
I can replicate this on all radeon enabled kernels including current.
It appears than when more than one head is enabled, a separate set of power
profiles is used which attempts to s
https://bugzilla.kernel.org/show_bug.cgi?id=43295
--- Comment #4 from Thanigaivelan 2012-05-31
02:51:44 ---
My System hangs when panic occurred switching back to text console. I have to
restart it again. it happen many time. Please tell me what is the problem in
kernel file.
I am using ke
DRM_IOCTL_MODESET_CTL must only be used for UMS drivers. Make it a no-op
for KMS drivers.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/drm_irq.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
My understanding of the DRM framework tells me that calling
DRM_IOCTL_MODESET_CT
The passed mode must not be modified by the operation, make it const.
Signed-off-by: Laurent Pinchart
---
This will break the i915 driver, as it modifies mode->clock in
intel_dp_mode_fixup(), hence the RFC state. Is this incorrect behaviour from
the i915 driver ?
drivers/gpu/drm/exynos/exynos_
https://bugs.freedesktop.org/show_bug.cgi?id=50149
--- Comment #12 from Roman ?makal 2012-05-29
21:35:06 PDT ---
With this settings textures are rendered, but they are red-shaded instead, so
its not a fix for the issue
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
2012/5/30 Sean Paul :
> On Tue, May 29, 2012 at 5:23 PM, Alex Deucher
> wrote:
>> On Tue, May 29, 2012 at 4:33 PM, Sean Paul wrote:
>>> On Tue, May 29, 2012 at 10:43 AM, Alex Deucher
>>> wrote:
On Mon, May 28, 2012 at 1:20 PM, Sean Paul
wrote:
> On Wed, Jan 18, 2012 at 10:06 AM
On Tue, 29 May 2012 19:41:37 -0700, Linus Torvalds wrote:
> On Mon, May 28, 2012 at 12:06 AM, Chris Wilson
> wrote:
> >
> > No, the i915_error_state had everything I needed to see. It is the old
> > ddx bug that was hardcoding a maximum relocation address that never
> > corresponded with an actu
0x0314e050: 0x61010006: STATE_BASE_ADDRESS
0x0314e054: 0x0001:general state base address 0x
0x0314e058: 0x0001:surface state base address 0x
0x0314e05c: 0x0001:indirect state base address 0x
0x0314e060: 0x0001:instruct
On Tue, 29 May 2012 19:41:37 -0700, Linus Torvalds wrote:
> On Mon, May 28, 2012 at 12:06 AM, Chris Wilson
> wrote:
> >
> > No, the i915_error_state had everything I needed to see. It is the old
> > ddx bug that was hardcoding a maximum relocation address that never
> > corresponded with an actu
On Tue, May 29, 2012 at 07:41:37PM -0700, Linus Torvalds wrote:
> On Mon, May 28, 2012 at 12:06 AM, Chris Wilson
> wrote:
> >
> > No, the i915_error_state had everything I needed to see. It is the old
> > ddx bug that was hardcoding a maximum relocation address that never
> > corresponded with an
On Mon, May 28, 2012 at 08:51:51PM +0200, Daniel Vetter wrote:
> On Mon, May 28, 2012 at 1:09 AM, Linus Torvalds
> wrote:
> > A new worry about excessively verbose i915 driver "errors" that don't
> > actually seem to be errors.
> >
> > I got myself a micro-DP to VGA adapter so that I can use my Ma
On Wed, May 30, 2012 at 01:01:08AM +0200, Laurent Pinchart wrote:
> The passed mode must not be modified by the operation, make it const.
>
> Signed-off-by: Laurent Pinchart
Acked-by: Daniel Vetter
--
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48
Hi Daniel,
On Wednesday 30 May 2012 11:18:56 Daniel Vetter wrote:
> On Wed, May 30, 2012 at 01:01:08AM +0200, Laurent Pinchart wrote:
> > The passed mode must not be modified by the operation, make it const.
> >
> > Signed-off-by: Laurent Pinchart
>
> Acked-by: Daniel Vetter
Thank you for the
On Wed, May 30, 2012 at 11:24:50AM +0200, Laurent Pinchart wrote:
> Hi Daniel,
>
> On Wednesday 30 May 2012 11:18:56 Daniel Vetter wrote:
> > On Wed, May 30, 2012 at 01:01:08AM +0200, Laurent Pinchart wrote:
> > > The passed mode must not be modified by the operation, make it const.
> > >
> > > S
Hi Daniel,
On Wednesday 30 May 2012 12:02:19 Daniel Vetter wrote:
> On Wed, May 30, 2012 at 11:24:50AM +0200, Laurent Pinchart wrote:
> > On Wednesday 30 May 2012 11:18:56 Daniel Vetter wrote:
> > > On Wed, May 30, 2012 at 01:01:08AM +0200, Laurent Pinchart wrote:
> > > > The passed mode must not
Hi Linus,
just regular fixes, bunch from intel, quieting some of the over zealous
power warnings, and the rest just misc.
I've got another pull with the remaining dma-buf bits, since the vmap bits
are in your tree now. I'll send tomorrow just to space things out a bit.
Dave.
The following ch
On Tue, May 29, 2012 at 08:20:35PM +0200, Lars-Peter Clausen wrote:
> This patchset introduces a set of helper function for implementing the KMS
> framebuffer layer for drivers which use the drm gem CMA helper function.
I just integrated this into my series. Works great, thanks.
Would be great to
On Wed, May 30, 2012 at 12:11:49PM +0200, Laurent Pinchart wrote:
> Hi Daniel,
>
> On Wednesday 30 May 2012 12:02:19 Daniel Vetter wrote:
> > On Wed, May 30, 2012 at 11:24:50AM +0200, Laurent Pinchart wrote:
> > > On Wednesday 30 May 2012 11:18:56 Daniel Vetter wrote:
> > > > On Wed, May 30, 2012
We should only frob adjusted_mode. This is in preparation of
a massive patch by Laurent Pinchart to make the mode argument
const.
The only thing we actually touch is mode->clock, but only if
it's a panel. And in that case we also set adjusted_mode->clock
to the same value. All the generic code alr
On Wed, 30 May 2012 12:28:04 +0200, Daniel Vetter
wrote:
> We should only frob adjusted_mode. This is in preparation of
> a massive patch by Laurent Pinchart to make the mode argument
> const.
>
> The only thing we actually touch is mode->clock, but only if
> it's a panel. And in that case we al
https://bugzilla.kernel.org/show_bug.cgi?id=43295
Alan changed:
What|Removed |Added
Status|NEW |NEEDINFO
CC|
https://bugzilla.kernel.org/show_bug.cgi?id=43295
--- Comment #3 from Alan 2012-05-30 11:26:43 ---
*** Bug 43288 has been marked as a duplicate of this bug. ***
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
Yo
On Mit, 2012-05-30 at 00:58 +0200, Laurent Pinchart wrote:
> DRM_IOCTL_MODESET_CTL must only be used for UMS drivers. Make it a no-op
> for KMS drivers.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/drm_irq.c |5 -
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
> My
On Wed, May 30, 2012 at 11:58:43AM +0100, Chris Wilson wrote:
> On Wed, 30 May 2012 12:28:04 +0200, Daniel Vetter
> wrote:
> > We should only frob adjusted_mode. This is in preparation of
> > a massive patch by Laurent Pinchart to make the mode argument
> > const.
> >
> > The only thing we actua
... instead of changing mode->clock, which we should leave as-is.
We only touch that if it's a panel, and then adjusted mode->clock
equals adjusted_mode->clock. Outside of intel_dp.c we only use
ajusted_mode->clock in the mode_set functions.
Within intel_dp.c we only use it to calculate the dp di
We should only frob adjusted_mode. This is in preparation of
a massive patch by Laurent Pinchart to make the mode argument
const.
After the prevous prep patch to use adjusted_mode->clock instead of
mode->clock the only thing left is to clean up things a bit. I've
opted to pass in an adjust_mode pa
On Wed, May 30, 2012 at 1:06 AM, Rafa? Mi?ecki wrote:
> 2012/5/30 Sean Paul :
>> On Tue, May 29, 2012 at 5:23 PM, Alex Deucher
>> wrote:
>>> On Tue, May 29, 2012 at 4:33 PM, Sean Paul wrote:
On Tue, May 29, 2012 at 10:43 AM, Alex Deucher
wrote:
> On Mon, May 28, 2012 at 1:20 PM,
On Wed, 30 May 2012 13:52:02 +0200, Daniel Vetter
wrote:
> ... instead of changing mode->clock, which we should leave as-is.
>
> We only touch that if it's a panel, and then adjusted mode->clock
> equals adjusted_mode->clock. Outside of intel_dp.c we only use
> ajusted_mode->clock in the mode_se
1 - 100 of 152 matches
Mail list logo
