The global integrated clock source bit resides in DPLL B on VLV, but we
were treating it as a per-pipe resource. It needs to be set whenever
any PLL is active, so pull setting the bit out of vlv_update_pll and
into vlv_enable_pll. Also add a vlv_disable_pll to prevent disabling it
when pipe B shu
On Fri, 27 Sep 2013 23:09:26 +0300
Ville Syrjälä wrote:
> On Fri, Sep 27, 2013 at 12:22:11PM -0700, Jesse Barnes wrote:
> > The global integrated clock source bit resides in DPLL B on VLV, but we
> > were treating it as a per-pipe resource. It needs to be set whenever
> > any PLL is active,
>
>
On VLV/BYT, backlight controls a per-pipe, so when adjusting the
backlight we need to pass the correct info. So make the externally
visible backlight functions take a connector argument, which can be used
internally to figure out the pipe backlight to adjust.
Signed-off-by: Jesse Barnes
---
dri
With the connector and pipe passed around, we can now set the backlight
on the right pipe on VLV/BYT.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_reg.h| 10 ++
drivers/gpu/drm/i915/intel_panel.c | 65 +++---
2 files changed, 63 insertions(+),
On Fri, 27 Sep 2013 21:45:39 +0100
Chris Wilson wrote:
> On Fri, Sep 27, 2013 at 12:57:23PM -0700, Jesse Barnes wrote:
> > We're shutting the crtc off and don't want to hang forever.
>
> That scares me ever so slightly, especially ignoring the failure. Do you
> want to reset the display controll
On Fri, Sep 27, 2013 at 7:48 AM, Jani Nikula wrote:
> Detailed cap info at address 80h is not available with DPCD ver
> 1.0. Whether such devices exist in the wild I don't know, but there
> should be no harm done in having the defines for downstream port 0 in
> address 05h.
>
> Signed-off-by: Jani
On Fri, Sep 27, 2013 at 12:57:23PM -0700, Jesse Barnes wrote:
> We're shutting the crtc off and don't want to hang forever.
That scares me ever so slightly, especially ignoring the failure. Do you
want to reset the display controller if the interrupts die, or just
report a WARN, or propagate the f
On Fri, 27 Sep 2013 22:11:33 +0200
Daniel Vetter wrote:
> On Fri, Sep 27, 2013 at 09:05:24PM +0100, Chris Wilson wrote:
> > On Fri, Sep 27, 2013 at 12:57:24PM -0700, Jesse Barnes wrote:
> > > This avoids a divide by zero and warns appropriately on this serious bug.
> > >
> > > Signed-off-by: Jes
On Fri, Sep 27, 2013 at 09:05:24PM +0100, Chris Wilson wrote:
> On Fri, Sep 27, 2013 at 12:57:24PM -0700, Jesse Barnes wrote:
> > This avoids a divide by zero and warns appropriately on this serious bug.
> >
> > Signed-off-by: Jesse Barnes
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 5 +++
On Fri, Sep 27, 2013 at 12:22:11PM -0700, Jesse Barnes wrote:
> The global integrated clock source bit resides in DPLL B on VLV, but we
> were treating it as a per-pipe resource. It needs to be set whenever
> any PLL is active,
Actually AFAIU the cri clock has to be running even if we just attemp
On Fri, Sep 27, 2013 at 12:57:26PM -0700, Jesse Barnes wrote:
> To handle disabling DP after the CPU pipe is disabled, per the
> workaround.
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=58152
> Signed-off-by: Jesse Barnes
This also applies to g4x apparently and really encoder typ
On Fri, Sep 27, 2013 at 12:57:24PM -0700, Jesse Barnes wrote:
> This avoids a divide by zero and warns appropriately on this serious bug.
>
> Signed-off-by: Jesse Barnes
> ---
> drivers/gpu/drm/i915/intel_display.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/i9
We're shutting the crtc off and don't want to hang forever.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index bc25481..8d
On Fri, Sep 27, 2013 at 12:22:11PM -0700, Jesse Barnes wrote:
> The global integrated clock source bit resides in DPLL B on VLV, but we
> were treating it as a per-pipe resource. It needs to be set whenever
> any PLL is active, so pull setting the bit out of vlv_update_pll and
> into vlv_enable_pl
On Fri, Sep 27, 2013 at 12:07:29PM -0700, Todd Previte wrote:
> Yep. Good to go.
>
> Reviewed-by: Todd Previte
Queued for -next, thanks for the patch.
-Daniel
>
>
> On Fri, Sep 27, 2013 at 4:51 AM, Jani Nikula
> wrote:
>
> > On Fri, 20 Sep 2013, Todd Previte wrote:
> > > On 09/20/2013 06:42
The global integrated clock source bit resides in DPLL B on VLV, but we
were treating it as a per-pipe resource. It needs to be set whenever
any PLL is active, so pull setting the bit out of vlv_update_pll and
into vlv_enable_pll. Also add a vlv_disable_pll to prevent disabling it
when pipe B shu
This avoids a divide by zero and warns appropriately on this serious bug.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 8da1c96..9a83
To handle disabling DP after the CPU pipe is disabled, per the
workaround.
References: https://bugs.freedesktop.org/show_bug.cgi?id=58152
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 58
1 file changed, 53 insertions(+), 5 deletions(
It indicates a probable BIOS bug, but it appears to be harmless, and
there's nothing the user can do about it anyway, so reduce to a debug
msg. I've filed a bug with the BIOS folks about it anyway, so hopefully
they'll fix whatever GT SB read they were doing when the GT was off.
References: https
On Fri, Sep 27, 2013 at 10:40:54AM -0700, Jesse Barnes wrote:
> It indicates a probable BIOS bug, but it appears to be harmless, and
> there's nothing the user can do about it anyway, so reduce to a debug
> msg. I've filed a bug with the BIOS folks about it anyway, so hopefully
> they'll fix whate
On Fri, Sep 27, 2013 at 06:36:05PM +0300, Ville Syrjälä wrote:
> On Fri, Sep 27, 2013 at 12:11:47PM +0100, Damien Lespiau wrote:
> > Daniel noticed that it wasn't very smart to keep using one bit per stereo
> > layout now that we don't have to or them. It's a nice final touch to the new
> > stereo
On Fri, Sep 27, 2013 at 09:15:58AM +0100, Chris Wilson wrote:
> On Thu, Sep 26, 2013 at 05:55:58PM -0700, Jesse Barnes wrote:
> > We need to use the clock control reg to figure out how many CZ clks are in
> > 30ns and use that as the basis for our RC6 residency calculations.
> >
> > v2: use ULL ev
On Thu, Sep 26, 2013 at 01:09:26PM +0300, Mika Kuoppala wrote:
> ville.syrj...@linux.intel.com writes:
>
> > From: Ville Syrjälä
> >
> > vlv_find_best_dpll() has an open coded DIV_ROUND_CLOSEST(). Replace it
> > with the real thing.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/d
On Fri, Sep 27, 2013 at 01:07:19PM +0300, Ville Syrjälä wrote:
> On Fri, Sep 27, 2013 at 03:31:00PM +0800, Chon Ming Lee wrote:
> > CDCLK is used to generate the gmbus clock. This is normally done by
> > BIOS. Program the value if the BIOS-less system doesn't do it.
> >
> > v2: Move this to intel
On Fri, Sep 27, 2013 at 09:21:51PM +0200, Daniel Vetter wrote:
> On Fri, Sep 27, 2013 at 7:34 AM, Ben Widawsky wrote:
> > At this point it just seems like you're intentionally making it harder
> > for me to ever merge PPGTT.
>
> I have two issues with the merged patches:
> 1. There's a regression
The global integrated clock source bit resides in DPLL B on VLV, but we
were treating it as a per-pipe resource. It needs to be set whenever
any PLL is active, so pull setting the bit out of vlv_update_pll and
into vlv_enable_pll. Also add a vlv_disable_pll to prevent disabling it
when pipe B shu
On Fri, Sep 27, 2013 at 7:34 AM, Ben Widawsky wrote:
> At this point it just seems like you're intentionally making it harder
> for me to ever merge PPGTT.
I have two issues with the merged patches:
1. There's a regression, and QA is meanwhile at the 3rd or so dupe
report. So it's not really an a
Yep. Good to go.
Reviewed-by: Todd Previte
On Fri, Sep 27, 2013 at 4:51 AM, Jani Nikula wrote:
> On Fri, 20 Sep 2013, Todd Previte wrote:
> > On 09/20/2013 06:42 AM, Jani Nikula wrote:
> >> Per DP1.2 spec.
> >>
> >> Signed-off-by: Jani Nikula
> >> ---
> >> drivers/gpu/drm/i915/intel_dp.c |
Looks good.
Reviewed-by: Todd Previte
On Fri, Sep 27, 2013 at 4:48 AM, Jani Nikula wrote:
> Detailed cap info at address 80h is not available with DPCD ver
> 1.0. Whether such devices exist in the wild I don't know, but there
> should be no harm done in having the defines for downstream port
On Fri, Sep 27, 2013 at 7:27 PM, Woody Suwalski wrote:
> Daniel Vetter wrote:
>>
>> On Thu, Sep 26, 2013 at 2:36 PM, Woody Suwalski
>> wrote:
>>>
>>> Daniel, I have noticed these warnings on 3.12-rc1, did not go away on
>>> 3.12-rc2.
>>> I see it only on EeePC with i915,not on ThinkPad with Radeo
On Fri, 2013-09-27 at 14:48 +0300, Jani Nikula wrote:
> We haven't read the downstream port caps for DPCD 1.0, so don't use
> them.
>
> v2: use defines for DPCD 1.0 downstream port types
>
> Signed-off-by: Jani Nikula
I don't know if I've ever seen a DPCD 1.0 device, but the changes make
sense.
On Fri, 27 Sep 2013, Yves-Alexis Perez wrote:
> On ven., 2013-09-27 at 12:20 -0300, Henrique de Moraes Holschuh wrote:
> > Some testing on a *60 (T60,X60...) would also be best, I cannot test
> > this on
> > my T43.
> >
> > Anyway, the code itself looks fine, so:
>
> I can test on T61, would that
It indicates a probable BIOS bug, but it appears to be harmless, and
there's nothing the user can do about it anyway, so reduce to a debug
msg. I've filed a bug with the BIOS folks about it anyway, so hopefully
they'll fix whatever GT SB read they were doing when the GT was off.
References: https
On Fri, Sep 27, 2013 at 12:11:47PM +0100, Damien Lespiau wrote:
> Daniel noticed that it wasn't very smart to keep using one bit per stereo
> layout now that we don't have to or them. It's a nice final touch to the new
> stereo mode API extension that we should fix before committing to it.
Assumin
On ven., 2013-09-27 at 12:20 -0300, Henrique de Moraes Holschuh wrote:
> Some testing on a *60 (T60,X60...) would also be best, I cannot test
> this on
> my T43.
>
> Anyway, the code itself looks fine, so:
I can test on T61, would that help?
Regards,
--
Yves-Alexis
signature.asc
Description:
On Tue, 24 Sep 2013, Aaron Lu wrote:
> The tpacpi_acpi_handle_locate function makes use of acpi_get_devices to
> locate handle for ACPI video by HID, the problem is, ACPI video node
> doesn't really have HID defined(i.e. no _HID control method is defined
> for video device), so.. that function woul
On Thu, 26 Sep 2013, Aaron Lu wrote:
> I checked the git log for the commit to use tpacpi_acpi_handle_locate to
> locate video controller's ACPI handle, it's:
>
> commit 122f26726b5e16174bf8a707df14be1d93c49d62
> Author: Henrique de Moraes Holschuh
> Date: Mon Aug 9 23:48:18 2010 -0300
Yeah...
On Fri, Sep 27, 2013 at 03:10:44PM +0300, Jani Nikula wrote:
> Neither the DP spec nor the compliance test spec state or imply that we
> should write the DP_TRAINING_PATTERN_SET at every voltage swing and
> pre-emphasis change. Indeed we probably shouldn't. So don't.
>
> Bugzilla: https://bugs.fre
2013/9/27 Jani Nikula :
> Neither the DP spec nor the compliance test spec state or imply that we
> should write the DP_TRAINING_PATTERN_SET at every voltage swing and
> pre-emphasis change. Indeed we probably shouldn't. So don't.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49402
> S
From: Ville Syrjälä
Everyone else uses intel_PLL_is_valid(), so make VLV use it as well.
We don't have any special p and m limits on VLV, so skip those tests,
and we also need to skip the m1<=m2 test line PNV.
Reorganize the function a bit to move the n check alongside the rest of
the test for
From: Ville Syrjälä
Rewrite vlv_find_best_dpll() to use intel_clock_t rather than
an army of local variables.
Also extract the code to calculate the derived values into
vlv_clock().
v2: Split up the earlier fixes, extract vlv_clock()
v3: Initialize best_clock
Signed-off-by: Ville Syrjälä
---
On Fri, Sep 27, 2013 at 02:55:32PM +0300, Mika Kuoppala wrote:
> ville.syrj...@linux.intel.com writes:
>
> > From: Ville Syrjälä
> >
> > Rewrite vlv_find_best_dpll() to use intel_clock_t rather than
> > an army of local variables.
> >
> > Also extract the code to calculate the derived values into
On Thu, Sep 26, 2013 at 06:30:55PM +0300, Mika Kuoppala wrote:
> ville.syrj...@linux.intel.com writes:
>
> > From: Ville Syrjälä
> >
> > Rewrite vlv_find_best_dpll() to use intel_clock_t rather than
> > an army of local variables.
> >
> > Also extract the code to calculate the derived values into
On Fri, Sep 27, 2013 at 03:08:27PM +0300, Jani Nikula wrote:
> We have some code duplication related to EDID duplication. Add a helper.
git grep kmemdup.*edid drivers/gpu/drm/ also returns 3 hits in nouveau
here, should anyone be bored.
--
Damien
___
I
On Fri, Sep 27, 2013 at 03:08:27PM +0300, Jani Nikula wrote:
> We have some code duplication related to EDID duplication. Add a helper.
Lgtm, debated the merits of assuming GFP_KERNEL and inlining, then thought
better of it.
All 3, Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open S
Neither the DP spec nor the compliance test spec state or imply that we
should write the DP_TRAINING_PATTERN_SET at every voltage swing and
pre-emphasis change. Indeed we probably shouldn't. So don't.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49402
Signed-off-by: Jani Nikula
---
I
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/exynos/exynos_drm_vidi.c |8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index 4400330..26e089f 100644
--- a/drivers/gpu/drm/exynos/ex
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c |8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 95a3159..aed9d67 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/
We have some code duplication related to EDID duplication. Add a helper.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 12
include/drm/drm_crtc.h |1 +
2 files changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
ind
ville.syrj...@linux.intel.com writes:
> From: Ville Syrjälä
>
> Rewrite vlv_find_best_dpll() to use intel_clock_t rather than
> an army of local variables.
>
> Also extract the code to calculate the derived values into
> vlv_clock().
>
> v2: Split up the earlier fixes, extract vlv_clock()
>
> Sig
On Fri, 20 Sep 2013, Todd Previte wrote:
> On 09/20/2013 06:42 AM, Jani Nikula wrote:
>> Per DP1.2 spec.
>>
>> Signed-off-by: Jani Nikula
>> ---
>> drivers/gpu/drm/i915/intel_dp.c |7 ++-
>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_dp
We haven't read the downstream port caps for DPCD 1.0, so don't use
them.
v2: use defines for DPCD 1.0 downstream port types
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm
Detailed cap info at address 80h is not available with DPCD ver
1.0. Whether such devices exist in the wild I don't know, but there
should be no harm done in having the defines for downstream port 0 in
address 05h.
Signed-off-by: Jani Nikula
---
include/drm/drm_dp_helper.h |8
1 fil
Now that the coding of stereo layout has changed from a bit field to an
enum, we need remove that check.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_crtc.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 807309f..2ce8
The kernel shouldn't accept invalid modes, just say No.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_crtc.c | 3 +++
include/drm/drm_crtc.h | 2 ++
include/uapi/drm/drm_mode.h | 4
3 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm
This allows us to use fewer bits in the mode structure, leaving room for
future work while allowing more stereo layouts types than we could have
ever dreamt of.
I also exposed the previously private DRM_MODE_FLAG_3D_MASK to set in
stone that we are using 5 bits for the stereo layout enum, reservin
Daniel noticed that it wasn't very smart to keep using one bit per stereo
layout now that we don't have to or them. It's a nice final touch to the new
stereo mode API extension that we should fix before committing to it.
--
Damien
___
Intel-gfx mailing
On Tue, Sep 24, 2013 at 05:47:28PM +0800, Aaron Lu wrote:
> v3:
> 1 Add a new patch 4/4 to fix some problems in thinkpad-acpi module;
> 2 Remove unnecessary function acpi_video_unregister introduced in
> patch 2/3 as pointed out by Jani Nikula.
>
> v2:
> v1 has the subject of "Rework ACPI video
On Fri, Sep 27, 2013 at 03:31:00PM +0800, Chon Ming Lee wrote:
> CDCLK is used to generate the gmbus clock. This is normally done by
> BIOS. Program the value if the BIOS-less system doesn't do it.
>
> v2: Move this to intel_i2c_reset to allow reprogram the gmbus frequency
> during resume. (Danie
On Thu, Sep 26, 2013 at 02:39:14PM -0700, Jesse Barnes wrote:
> This fixes resume on my test platform, since I think some DPIO bits need
> recalibration.
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=69166
> Signed-off-by: Jesse Barnes
> ---
> drivers/gpu/drm/i915/intel_display.c
On Thu, Sep 26, 2013 at 2:36 PM, Woody Suwalski wrote:
> Daniel, I have noticed these warnings on 3.12-rc1, did not go away on
> 3.12-rc2.
> I see it only on EeePC with i915,not on ThinkPad with Radeon.
> It is a 32-bit kernel with overlayfs and TuxOnIce patches, so not perfectly
> clean, however
Hi Dave,
First feature pull request for 3.13. Highlights:
drm-intel-next-2013-09-21:
- clock state handling rework from Ville
- l3 parity handling fixes for hsw from Ben
- some more watermark improvements from Ville
- ban badly behaved context from Mika
- a few vlv improvements from Jesse
- VGA p
On Thu, Sep 26, 2013 at 05:55:58PM -0700, Jesse Barnes wrote:
> We need to use the clock control reg to figure out how many CZ clks are in
> 30ns and use that as the basis for our RC6 residency calculations.
>
> v2: use ULL everywhere for consistency (Chris)
> factor out bias for clarity (Chri
Summary
We covered the platform: Baytrail-M, Haswell mobile, HSW desktop, HSW ULT,
IvyBridge, SandyBridge, IronLake.
In this circle, 13 new bugs are filed, 34 bugs are still opened, no WONTFIX
bugs, 2 NOTABUG bugs, no NOTOURBUG bugs, 1 Duplicated bugs, no REOPENED bugs, 2
bugs are fixed, 9 bugs
CDCLK is used to generate the gmbus clock. This is normally done by
BIOS. Program the value if the BIOS-less system doesn't do it.
v2: Move this to intel_i2c_reset to allow reprogram the gmbus frequency
during resume. (Daniel)
v3: Change GMBUS_FREQ to GMBUSFREQ_VLV, and use VLV_DISPLAY_BASE.
(Vi
65 matches
Mail list logo
