Am Montag, den 13.08.2012, 03:08 + schrieb Xu, Anhua:
> Sorry, Deniel/Greg, late response for your email because of a busy work last
> work.
> I will response to you guys ASAP :), below is the updated patch:
>
>
> From 33eb95a3a711b2354985361ff208ea150a5ba235 Mon Sep 17 00:00:00 2001
> Fro
On Mon, Aug 13, 2012 at 03:08:33AM +, Xu, Anhua wrote:
> Sorry, Deniel/Greg, late response for your email because of a busy work last
> work.
> I will response to you guys ASAP :), below is the updated patch:
>
>
> From 33eb95a3a711b2354985361ff208ea150a5ba235 Mon Sep 17 00:00:00 2001
> Fr
Hi, Paul
Thanks for your advice. I update my patch. Please review, for your question,
please see my reply below.
>From d11080eda81c0503b5035ea40667b06fe2ee0fb5 Mon Sep 17 00:00:00 2001
From: Anhua Xu
Date: Tue, 31 Jul 2012 17:16:50 +0800
Subject: [PATCH v3] drm/i915: fix wrong order of paramet
On Sun, Aug 12, 2012 at 08:12:02PM +0100, Chris Wilson wrote:
> On Sun, 12 Aug 2012 17:01:08 +0100, Chris Wilson
> wrote:
> > On Sun, 12 Aug 2012 17:47:46 +0200, Daniel Vetter wrote:
> > > On Sun, Aug 12, 2012 at 12:04:39PM +0100, Chris Wilson wrote:
> > > > In order to be able to ioremap_wc the
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
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 ++-
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
I'm struggling to get back to a version that works on the Shark Bay /
Haswell platform that I have.
I did get it to work once...but have since updated the BIOS, so am not
sure if that may have an effect on this test.
v3.5 also gave a stack (below) - so without a working version, I
cannot do the b
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
Hi Mihai, could you test the following patch to see if it fixes the problem,
please?
BR,
Jani.
Jani Nikula (1):
drm/i915: ensure i2c adapter is all set before adding it
drivers/gpu/drm/i915/intel_i2c.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
--
1.7.9.5
i2c_add_adapter() may do i2c transfers on the bus to detect supported
devices. Therefore the adapter needs to be all set before adding it. This
was not the case for the bit-banging fallback, resulting in an oops if the
device detection GMBUS transfers timed out. Fix the issue by calling
i2c_add_ada
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 Mon, Aug 13, 2012 at 05:03:24PM +0200, Mihai Moldovan wrote:
> Hi Jani,
>
> * On 13.08.2012 04:33 PM, Jani Nikula wrote:
> > Hi Mihai, could you test the following patch to see if it fixes the problem,
> > please?
> >
> > BR,
> > Jani.
> >
> >
> > Jani Nikula (1):
> > drm/i915: ensure i2c ada
On Mon, Aug 13, 2012 at 05:33:02PM +0300, Jani Nikula wrote:
> i2c_add_adapter() may do i2c transfers on the bus to detect supported
> devices. Therefore the adapter needs to be all set before adding it. This
> was not the case for the bit-banging fallback, resulting in an oops if the
> device dete
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 Sun, Aug 12, 2012 at 08:47:56PM +0100, Chris Wilson wrote:
> On Sun, 12 Aug 2012 19:27:07 +0200, Daniel Vetter
> wrote:
> > Hi all,
> >
> > I've noticed that a few prep patches of the modeset rework series haven't
> > been
> > merged nor reviewed yet, so I've split them out in this resend. M
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
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
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
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
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
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
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
Daniel Vetter writes:
> Cc: Keith Packard
I tried this on top of v3.5, appears to work just fine. Thanks!
Tested-by: Keith Packard
--
keith.pack...@intel.com
pgpqnQvHYzFB4.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists
After reset we unconditionally reinitialize lists. If the context switch
hasn't yet completed before the suspend the default context object will
end up on lists that are going to go away when we resume.
The patch forces the context switch to be synchronous before suspend
assuring that the active/i
This is possible with the new force paramter in do_switch. As stated in
that patch, the goal is to get a real context stored at the time of
initialization.
References: https://bugs.freedesktop.org/show_bug.cgi?id=52429
Tested-by: Guang A Yang
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915
A force parameter for switch currently only has one use, the first time
we load the default context.
Slightly hand-wavy explanation: We want to get the default context
actually loaded so that the GPU has some real state to load (instead of
garbage) after a reset or resume
Therefore, the benefit t
The previous state is bogus when we've gone into idle. Actually there
would be a known state of idle (ie. all units are done), but since it
differs for every platform, we can just set 0, and let the hangcheck
progress as normal.
References: https://bugs.freedesktop.org/show_bug.cgi?id=52429
Tested
On Mon, 13 Aug 2012, Mihai Moldovan wrote:
> Had another look at the code and would like to apologize for the confusion...
No worries Mihai, thanks for testing!
BR,
Jani.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedeskt
30 matches
Mail list logo
