https://bugs.freedesktop.org/show_bug.cgi?id=43477
Andreas Boll changed:
What|Removed |Added
AssignedTo|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
On Mon, 2012-08-13 at 18:22 +0200, Sven Joachim wrote:
> On 2012-08-08 08:18 +0200, Sven Joachim wrote:
>
> > On 2012-08-08 08:08 +0200, Ben Skeggs wrote:
> >
> >> On Wed, Aug 08, 2012 at 08:00:21AM +0200, Sven Joachim wrote:
> >>> Not for me on my GeForce 8500 GT, and I still cannot suspend more
https://bugs.freedesktop.org/show_bug.cgi?id=43477
--- Comment #5 from maximlevit...@gmail.com 2012-08-14 04:51:48 UTC ---
This still happens on nouveau, despite OpenGL 3.0 advertised.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail
Need to turn on the error correction when enabling training or it
might not get enabled in time.
This seems to fix the FDI-B/FDI-C link training problem.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_display.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
di
Doesn't make sense to disable in the other order.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_display.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b099a17..754
Just a bit of cleanup; it appears to have no effect.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_display.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7106807..952
This is left over from the old PLL sharing code and isn't useful now
that PLLs are shared when possible.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_crt.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i91
IVB shares 4 lanes between FDI B and FDI C. When sharing, compute the
maximum BPC based on the available bandwidth.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_display.c | 101 +++---
1 file changed, 94 insertions(+), 7 deletions(-)
diff --git a/driv
These should probably all look like
enabled |= (1 << pipe)
so that the intent is clear...
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_pm.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel
This is the complete set of patches that yield a working 3-pipe mode
setting configuration on my test machines. It does not make DPMS work,
so I still need to figure that out. As the DPMS paths are almost
entirely different from mode setting (whose crazy idea was that,
anyway?), that may take a bit
display_bpc might not have been set before comparing with the
requested mode, so wait until afterwards before comparing with the
supported fdi bandwidth. Not a significant change as any case that
mattered would have worked; this just makes the debug messages look nicer.
Signed-off-by: Keith Packar
Need to turn on the error correction when enabling training or it
might not get enabled in time.
This seems to fix the FDI-B/FDI-C link training problem.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_display.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
di
Doesn't make sense to disable in the other order.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_display.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b099a17..754
These should probably all look like
enabled |= (1 << pipe)
so that the intent is clear...
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_pm.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel
display_bpc might not have been set before comparing with the
requested mode, so wait until afterwards before comparing with the
supported fdi bandwidth. Not a significant change as any case that
mattered would have worked; this just makes the debug messages look nicer.
Signed-off-by: Keith Packar
Just a bit of cleanup; it appears to have no effect.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_display.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7106807..952
IVB shares 4 lanes between FDI B and FDI C. When sharing, compute the
maximum BPC based on the available bandwidth.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_display.c | 101 +++---
1 file changed, 94 insertions(+), 7 deletions(-)
diff --git a/driv
This is left over from the old PLL sharing code and isn't useful now
that PLLs are shared when possible.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_crt.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i91
This is the complete set of patches that yield a working 3-pipe mode
setting configuration on my test machines. It does not make DPMS work,
so I still need to figure that out. As the DPMS paths are almost
entirely different from mode setting (whose crazy idea was that,
anyway?), that may take a bit
When SWIOTLB is configured, if without this patch kernel compilation
fails with such error messages:
drivers/gpu/drm/radeon/radeon_ttm.c: In function 'radeon_ttm_tt_populate':
drivers/gpu/drm/radeon/radeon_ttm.c:606:2: error: implicit declaration of
function 'swiotlb_nr_tbl'
drivers/gpu/drm/radeo
On Sun, 12 Aug 2012 10:01:44 +0100, Russell King - ARM Linux wrote:
> While reading through the Intel driver code, I spotted this in
> I830SetPortAttributeOverlay:
>
> } else if (attribute == xvPipe) {
> xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(scrn);
>
On 13.08.2012 14:53, Sylvain BERTRAND wrote:
>> It's not 100% complete cause page table updates should be made with the DMA
>> ring, but we haven't released documentation for that yet, so I currently
>> use CP memory writes instead.
> Sad. Any release time hint? (the DMA ring will cleanup a lot of
On 13.08.2012 18:19, Jerome Glisse wrote:
> On Mon, Aug 13, 2012 at 6:26 AM, Christian K?nig
> wrote:
>> Currently doing the update with the CP.
>>
>> Signed-off-by: Christian K?nig
> NAK until point below are addressed
[SNIP]
> For this to work properly you will need patch :
> http://people.free
On 2012-08-08 08:18 +0200, Sven Joachim wrote:
> On 2012-08-08 08:08 +0200, Ben Skeggs wrote:
>
>> On Wed, Aug 08, 2012 at 08:00:21AM +0200, Sven Joachim wrote:
>>> Not for me on my GeForce 8500 GT, and I still cannot suspend more than
>>> once, subsequent attempts fail:
>>>
>>> ,
>>> | Aug 8
On Mon, 13 Aug 2012, Daniel Vetter wrote:
> On Sun, Aug 12, 2012 at 11:49:22PM -0400, George Spelvin wrote:
>> (Bringing this back to the mailing lists after a bit of uninteresting private
>> conversation.)
>>
>> > Honestly, I think we need a way to force disable gmbus with a module
>> > paramet
[this one ideally should make 3.6 - it fixes the very annoying mode setting bug]
From: Forest Bond
This causes the pipe to be forced off prior to initial mode set, which
roughly mirrors the behavior of the i915 driver. It fixes initial mode
setting on my Intel DN2800MT (Cedarview) board. Witho
From: Forest Bond
This is set when setting DPMS on and off, but it isn't checked anywhere,
so just remove it.
Signed-off-by: Forest Bond
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/cdv_intel_display.c |2 --
drivers/gpu/drm/gma500/psb_intel_drv.h |1 -
2 files changed, 3 d
From: Forest Bond
Signed-off-by: Forest Bond
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/cdv_intel_display.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/gma500/cdv_intel_display.c
b/drivers/gpu/drm/gma500/cdv_intel_display.c
index bfb0565..24
When SWIOTLB is configured, if without this patch kernel compilation
fails with such error messages:
drivers/gpu/drm/radeon/radeon_ttm.c: In function 'radeon_ttm_tt_populate':
drivers/gpu/drm/radeon/radeon_ttm.c:606:2: error: implicit declaration of
function 'swiotlb_nr_tbl'
drivers/gpu/drm/radeo
Hi Hans,
The patch seems to cover most of the requirement. I find 2 gaps:
> +/* DV-class control IDs defined by V4L2 */
> +#define V4L2_CID_DV_CLASS_BASE (V4L2_CTRL_CLASS_DV | 0x900)
> +#define V4L2_CID_DV_CLASS (V4L2_CTRL_CLASS_DV | 1)
> +
> +#define
river-initial-patch.patch
Type: application/octet-stream
Size: 369305 bytes
Desc: 0001-Siliconmotion-new-kernel-driver-initial-patch.patch
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120813/9fc4abf7/attachment-0001.obj>
Hi Linus,
radeon and intel fixes mostly, one fix to the mgag200 driver to not hang
on certain server variants.
Dave.
The following changes since commit 0d7614f09c1ebdbaa1599a5aba7593f147bf96ee:
Linux 3.6-rc1 (2012-08-02 16:38:10 -0700)
are available in the git repository at:
git://peopl
https://bugzilla.kernel.org/show_bug.cgi?id=17782
Alan changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://bugzilla.kernel.org/show_bug.cgi?id=17692
Alan changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
On Sat, Aug 11, 2012 at 6:51 PM, Russell King - ARM Linux
wrote:
> Hi,
>
> While looking at the kernel DRM code, I've noticed that in many places
> we kmalloc() memory to store the raw EDID information, whether it be
> from a DDC adapter, or loaded from firmware.
>
> Nowhere can I find where this
https://bugzilla.kernel.org/show_bug.cgi?id=17511
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #
On Sun, Aug 12, 2012 at 11:49:22PM -0400, George Spelvin wrote:
> (Bringing this back to the mailing lists after a bit of uninteresting private
> conversation.)
>
> > Honestly, I think we need a way to force disable gmbus with a module
> > parameter or something anyway. It's not the first time gm
On Mon, Aug 13, 2012 at 3:50 PM, Paul Menzel
wrote:
> Dear Huacai,
>
>
> Am Montag, den 13.08.2012, 15:16 +0800 schrieb Huacai Chen:
>> On Mon, Aug 13, 2012 at 3:00 PM, Paul Menzel wrote:
>
>> > thanks for your patch.
>> >
>> > Firstly, is Chen your first or last name? If it is your first name, yo
https://bugzilla.kernel.org/show_bug.cgi?id=17511
Alan changed:
What|Removed |Added
CC||alan at lxorguk.ukuu.org.uk
Component|Ot
https://bugzilla.kernel.org/show_bug.cgi?id=17241
Alan changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://bugzilla.kernel.org/show_bug.cgi?id=16581
Alan changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://bugzilla.kernel.org/show_bug.cgi?id=16560
Alan changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
CC|
On Mon, Aug 13, 2012 at 3:00 PM, Paul Menzel
wrote:
> Dear Chen,
>
>
> thanks for your patch.
>
> Firstly, is Chen your first or last name? If it is your first name, your
> From address should be switched.
Chen is may last name.
>
> Am Montag, den 13.08.2012, 10:09 +0800 schrieb Huacai Chen:
>> W
On Mon, 2012-08-13 at 20:40 +0800, Huacai Chen wrote:
> When SWIOTLB is configured, if without this patch kernel compilation
> fails with such error messages:
>
> drivers/gpu/drm/radeon/radeon_ttm.c: In function 'radeon_ttm_tt_populate':
> drivers/gpu/drm/radeon/radeon_ttm.c:606:2: error: implici
> It's not 100% complete cause page table updates should be made with the DMA
> ring, but we haven't released documentation for that yet, so I currently
> use CP memory writes instead.
Sad. Any release time hint? (the DMA ring will cleanup a lot of code).
BTW, maybe at the same time the HDP_NONSU
Hey,
Op 11-08-12 21:39, Daniel Vetter schreef:
> +
> + if (!ret) {
> + cb->base.flags = 0;
> + cb->base.func = __dma_fence_wake_func;
> + cb->base.private = priv;
> + cb->fence = fence;
> + cb->func = func;
On Mon August 13 2012 13:48:28 Soby Mathew wrote:
> Hi Hans,
>The patch seems to cover most of the requirement. I find 2 gaps:
>
> > +/* DV-class control IDs defined by V4L2 */
> > +#define V4L2_CID_DV_CLASS_BASE (V4L2_CTRL_CLASS_DV | 0x900)
> > +#define V4L2_CID_DV_CLASS
On Mon, Aug 13, 2012 at 04:56:33PM +0800, Aaron.Chen ??? wrote:
>
> Since there is no response for the last mail. Maybe it didn't sent
> successfully. So I send it again. Here is the initial patch for siliconmotion
> kernel driver.
What's with the #ifdef 0 or #ifdef 1?
Why is there a bunch of
On Mon, Aug 13, 2012 at 05:26:03PM +0800, Huacai Chen wrote:
> When SWIOTLB is configured, if without this patch kernel compilation
> fails with such error messages:
>
> drivers/gpu/drm/radeon/radeon_ttm.c: In function 'radeon_ttm_tt_populate':
> drivers/gpu/drm/radeon/radeon_ttm.c:606:2: error: i
GMBUS was enabled over bit-banging as the default in commits:
commit c3dfefa0a6d235bd465309e12f4c56ea16e7
Author: Daniel Vetter
Date: Tue Feb 14 22:37:25 2012 +0100
drm/i915: reenable gmbus on gen3+ again
and
commit 0fb3f969c8683505fb7323c06bf8a999a5a45a15
Author: Daniel Vetter
Date
Refactor the connector update part of intel_ddc_get_modes() into a separate
intel_connector_update_modes() function for reuse. No functional changes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_drv.h |2 ++
drivers/gpu/drm/i915/intel_modes.c | 31 ++-
Alex, Maciej, please test the following to see if it fixes the issue
[1], thanks.
BR,
Jani.
[1] https://bugzilla.kernel.org/show_bug.cgi?id=45881
Jani Nikula (2):
drm/i915: extract connector update from intel_ddc_get_modes() for
reuse
drm/i915: fall back to bit-banging if GMBUS fails in
On Mon, Aug 13, 2012 at 12:53 PM, Christian K?nig
wrote:
> On 13.08.2012 18:19, Jerome Glisse wrote:
>>
>> On Mon, Aug 13, 2012 at 6:26 AM, Christian K?nig
>> wrote:
>>>
>>> Currently doing the update with the CP.
>>>
>>> Signed-off-by: Christian K?nig
>>
>> NAK until point below are addressed
>
On Mon, 2012-08-13 at 18:22 +0200, Sven Joachim wrote:
> On 2012-08-08 08:18 +0200, Sven Joachim wrote:
>
> > On 2012-08-08 08:08 +0200, Ben Skeggs wrote:
> >
> >> On Wed, Aug 08, 2012 at 08:00:21AM +0200, Sven Joachim wrote:
> >>> Not for me on my GeForce 8500 GT, and I still cannot suspend more
Currently doing the update with the CP.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/ni.c | 20 ++
drivers/gpu/drm/radeon/nid.h |1 +
drivers/gpu/drm/radeon/radeon.h |2 +
drivers/gpu/drm/radeon/radeon_asic.c |3 ++
drivers/gpu/drm/radeon/
Makes it easier to move it into the rings.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/ni.c | 22 +++---
drivers/gpu/drm/radeon/radeon.h | 12 ++--
drivers/gpu/drm/radeon/radeon_asic.c |3 ---
drivers/gpu/drm/radeon/radeon_asic.h |7
Removing the need to wait for anything.
Still not ideal, since we need to free pt on va remove.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h |4 +-
drivers/gpu/drm/radeon/radeon_cs.c | 28 +
drivers/gpu/drm/radeon/radeon_gart.c | 107 +++--
Move binding onto the ring, simplifying handling a bit.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/ni.c| 20 ++---
drivers/gpu/drm/radeon/radeon.h| 30 +++-
drivers/gpu/drm/radeon/radeon_asic.c |9 +--
drivers/gpu/drm/radeon/radeon_asic.h |4
Move flushing the VMs as function into the rings.
First step to make VM operations async.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/ni.c | 31 ---
drivers/gpu/drm/radeon/radeon.h |6 --
drivers/gpu/drm/radeon/radeon_asic.c | 1
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_cs.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index 0a9d1eb..85a80e4 100644
--- a/drivers/gpu/drm/radeon/rad
It actually isn't very useful.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/ni.c | 11 ---
drivers/gpu/drm/radeon/radeon.h |2 --
drivers/gpu/drm/radeon/radeon_asic.c |3 ---
drivers/gpu/drm/radeon/radeon_gart.c |1 -
drivers/gpu/drm/radeon/si.c
So it looks more like the rest of the driver.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h | 35 +---
drivers/gpu/drm/radeon/radeon_asic.c | 50 ++
drivers/gpu/drm/radeon/radeon_gart.c | 16 +--
3 files
Store a reference to the VM into the IB structure, that
makes calculating the IBs address a bit less complicated.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/ni.c |5 +++--
drivers/gpu/drm/radeon/r100.c|2 +-
drivers/gpu/drm/radeon/r600.c|2 +-
From: Jerome Glisse
Virtual address need to be fenced to know when we can safely remove it.
This patch also properly clear the pagetable. Previously it was
serouisly broken.
Kernel 3.5/3.4 need a similar patch but adapted for difference in mutex locking.
v2: For to update pagetable when unbindi
Yeah, I know I'm on vacation, but without coding I die of boringness in less
than a week.
This patchset is currently based on Jeromes VA fencing patch, but in the end
makes it superfluous. It just moves the whole VM handling into the CP ring,
removing the need to wait for anything directly in the
On Mon, Aug 13, 2012 at 6:25 AM, Christian K?nig
wrote:
> Yeah, I know I'm on vacation, but without coding I die of boringness in less
> than a week.
>
> This patchset is currently based on Jeromes VA fencing patch, but in the end
> makes it superfluous. It just moves the whole VM handling into th
On Mon, Aug 13, 2012 at 6:26 AM, Christian K?nig
wrote:
> Currently doing the update with the CP.
>
> Signed-off-by: Christian K?nig
NAK until point below are addressed
> ---
> drivers/gpu/drm/radeon/ni.c | 20 ++
> drivers/gpu/drm/radeon/nid.h |1 +
> drivers/gp
On Sun, 12 Aug 2012 10:01:44 +0100, Russell King - ARM Linux
wrote:
> While reading through the Intel driver code, I spotted this in
> I830SetPortAttributeOverlay:
>
> } else if (attribute == xvPipe) {
> xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(scrn);
>
On Mon, Aug 13, 2012 at 04:56:33PM +0800, Aaron.Chen 陈俊杰 wrote:
>
> Since there is no response for the last mail. Maybe it didn't sent
> successfully. So I send it again. Here is the initial patch for siliconmotion
> kernel driver.
What's with the #ifdef 0 or #ifdef 1?
Why is there a bunch of
On Mon, Aug 13, 2012 at 05:26:03PM +0800, Huacai Chen wrote:
> When SWIOTLB is configured, if without this patch kernel compilation
> fails with such error messages:
>
> drivers/gpu/drm/radeon/radeon_ttm.c: In function 'radeon_ttm_tt_populate':
> drivers/gpu/drm/radeon/radeon_ttm.c:606:2: error: i
m line and paste it after the Subject line?
wereHamster on #git suggested to use
git send-email --from 'Huacai Chen '
and it should do the right thing.
Thanks,
Paul
> > [1] http://lists.freedesktop.org/archives/dri-devel/2012-July/025200.html
-- next part
On Fri, Aug 10, 2012 at 6:52 PM, Russell King - ARM Linux
wrote:
> At the moment, there is an inconsistency in the way modes are named.
> Modes with timings parsed from the EDID information will call
> drm_mode_set_name(), which will name the mode using this form:
>
> x
>
> eg, 1920x1080i
> One thing of interest would be the exact .config you use to build the
> kernel and the output of lsmod (after the kernel crashed). I guess the
> issue is with the combination of drivers you have (i2c_detect in the
> calltrace calls back into other registered i2c drivers ...).
The lsmod will take
On Mon, Aug 13, 2012 at 12:53 PM, Christian König
wrote:
> On 13.08.2012 18:19, Jerome Glisse wrote:
>>
>> On Mon, Aug 13, 2012 at 6:26 AM, Christian König
>> wrote:
>>>
>>> Currently doing the update with the CP.
>>>
>>> Signed-off-by: Christian König
>>
>> NAK until point below are addressed
>
When SWIOTLB is configured, if without this patch kernel compilation
fails.
Signed-off-by: Huacai Chen
Signed-off-by: Hongliang Tao
Signed-off-by: Hua Yan
Cc: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/radeon/radeon_ttm.c |4
1 files changed, 4 insertions(+), 0 deletions(-
On 13.08.2012 14:53, Sylvain BERTRAND wrote:
It's not 100% complete cause page table updates should be made with the DMA
ring, but we haven't released documentation for that yet, so I currently
use CP memory writes instead.
Sad. Any release time hint? (the DMA ring will cleanup a lot of code).
On 13.08.2012 18:19, Jerome Glisse wrote:
On Mon, Aug 13, 2012 at 6:26 AM, Christian König
wrote:
Currently doing the update with the CP.
Signed-off-by: Christian König
NAK until point below are addressed
[SNIP]
For this to work properly you will need patch :
http://people.freedesktop.org/
es from the
beginning as for example Alex Deucher is doing [1].
[?]
Thanks,
Paul
[1] http://lists.freedesktop.org/archives/dri-devel/2012-July/025200.html
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120813/112079d5/attachment.pgp>
On 08/12/2012 04:31 PM, Paul Menzel wrote:
> So I vote for getting this into stable and hopefully the maintainers
> agree.
Paul -
We obviously disagree on whether this makes sense for -stable. If you
feel strongly that it should go in, I suggest that you go ahead and
submit it for inclusion.
Th
https://bugzilla.kernel.org/show_bug.cgi?id=17782
Alan changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://bugzilla.kernel.org/show_bug.cgi?id=17692
Alan changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
On 2012-08-08 08:18 +0200, Sven Joachim wrote:
> On 2012-08-08 08:08 +0200, Ben Skeggs wrote:
>
>> On Wed, Aug 08, 2012 at 08:00:21AM +0200, Sven Joachim wrote:
>>> Not for me on my GeForce 8500 GT, and I still cannot suspend more than
>>> once, subsequent attempts fail:
>>>
>>> ,
>>> | Aug 8
On Mon, Aug 13, 2012 at 6:25 AM, Christian König
wrote:
> Yeah, I know I'm on vacation, but without coding I die of boringness in less
> than a week.
>
> This patchset is currently based on Jeromes VA fencing patch, but in the end
> makes it superfluous. It just moves the whole VM handling into th
On Mon, Aug 13, 2012 at 6:26 AM, Christian König
wrote:
> Currently doing the update with the CP.
>
> Signed-off-by: Christian König
NAK until point below are addressed
> ---
> drivers/gpu/drm/radeon/ni.c | 20 ++
> drivers/gpu/drm/radeon/nid.h |1 +
> drivers/gp
https://bugzilla.kernel.org/show_bug.cgi?id=17511
Alex Deucher changed:
What|Removed |Added
CC||alexdeuc...@gmail.com
--- Comment #2 f
https://bugzilla.kernel.org/show_bug.cgi?id=17511
Alan changed:
What|Removed |Added
CC||a...@lxorguk.ukuu.org.uk
Component|Other
https://bugzilla.kernel.org/show_bug.cgi?id=17241
Alan changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
Dear Chen,
thanks for your patch.
Firstly, is Chen your first or last name? If it is your first name, your
https://bugzilla.kernel.org/show_bug.cgi?id=16581
Alan changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://bugzilla.kernel.org/show_bug.cgi?id=16560
Alan changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
CC|
[this one ideally should make 3.6 - it fixes the very annoying mode setting bug]
From: Forest Bond
This causes the pipe to be forced off prior to initial mode set, which
roughly mirrors the behavior of the i915 driver. It fixes initial mode
setting on my Intel DN2800MT (Cedarview) board. Witho
From: Forest Bond
This is set when setting DPMS on and off, but it isn't checked anywhere,
so just remove it.
Signed-off-by: Forest Bond
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/cdv_intel_display.c |2 --
drivers/gpu/drm/gma500/psb_intel_drv.h |1 -
2 files changed, 3 d
From: Forest Bond
Signed-off-by: Forest Bond
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/cdv_intel_display.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/gma500/cdv_intel_display.c
b/drivers/gpu/drm/gma500/cdv_intel_display.c
index bfb0565..24
On Fri, Aug 10, 2012 at 6:52 PM, Russell King - ARM Linux
wrote:
> At the moment, there is an inconsistency in the way modes are named.
> Modes with timings parsed from the EDID information will call
> drm_mode_set_name(), which will name the mode using this form:
>
> x
>
> eg, 1920x1080i
On 08/12/2012 04:31 PM, Paul Menzel wrote:
> So I vote for getting this into stable and hopefully the maintainers
> agree.
Paul -
We obviously disagree on whether this makes sense for -stable. If you
feel strongly that it should go in, I suggest that you go ahead and
submit it for inclusion.
Th
On Mon, 13 Aug 2012, Daniel Vetter wrote:
> On Sun, Aug 12, 2012 at 11:49:22PM -0400, George Spelvin wrote:
>> (Bringing this back to the mailing lists after a bit of uninteresting private
>> conversation.)
>>
>> > Honestly, I think we need a way to force disable gmbus with a module
>> > paramet
On Sat, Aug 11, 2012 at 6:51 PM, Russell King - ARM Linux
wrote:
> Hi,
>
> While looking at the kernel DRM code, I've noticed that in many places
> we kmalloc() memory to store the raw EDID information, whether it be
> from a DDC adapter, or loaded from firmware.
>
> Nowhere can I find where this
On Sun, Aug 12, 2012 at 11:49:22PM -0400, George Spelvin wrote:
> (Bringing this back to the mailing lists after a bit of uninteresting private
> conversation.)
>
> > Honestly, I think we need a way to force disable gmbus with a module
> > parameter or something anyway. It's not the first time gm
On Mon, 2012-08-13 at 20:40 +0800, Huacai Chen wrote:
> When SWIOTLB is configured, if without this patch kernel compilation
> fails with such error messages:
>
> drivers/gpu/drm/radeon/radeon_ttm.c: In function 'radeon_ttm_tt_populate':
> drivers/gpu/drm/radeon/radeon_ttm.c:606:2: error: implici
Hi Hans,
The patch seems to cover most of the requirement. I find 2 gaps:
> +/* DV-class control IDs defined by V4L2 */
> +#define V4L2_CID_DV_CLASS_BASE (V4L2_CTRL_CLASS_DV | 0x900)
> +#define V4L2_CID_DV_CLASS (V4L2_CTRL_CLASS_DV | 1)
> +
> +#define
1 - 100 of 138 matches
Mail list logo
