ELD info should be updated dynamically according to hot plug event.
For haswell chip, clear/set the eld valid bit and output enable bit
from callback intel_disable/eanble_ddi().
Signed-off-by: Wang Xingchao
---
drivers/gpu/drm/i915/intel_ddi.c | 18 ++
1 file changed, 18 insert
Hi Vivi,
> -Original Message-
> From: Rodrigo Vivi [mailto:rodrigo.v...@gmail.com]
> Sent: Tuesday, January 15, 2013 1:00 AM
> To: Wang, Xingchao
> Cc: Daniel Vetter; intel-gfx; Zanoni, Paulo R
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: HDMI/DP - ELD info refresh support
> for Haswell
>
On Fri, 18 Jan 2013 00:04:24 +0100
Daniel Vetter wrote:
> On Thu, Jan 17, 2013 at 12:45:18PM -0800, Ben Widawsky wrote:
> > Similar to gtt_mappable_entries we don't usually want the entries,
> > it's easy enough to calculate it when you need.
> >
> > v2: Move relevant fields above pre-gen6 init
On Thu, Jan 17, 2013 at 12:45:17PM -0800, Ben Widawsky wrote:
> Mappable_end, ie. size is almost always what you want as opposed to the
> number of entries. Since we already have that information, we can scrap
> the number of entries and only calculate it when needed.
>
> If gtt_start is !0, this
On Thu, Jan 17, 2013 at 12:45:19PM -0800, Ben Widawsky wrote:
> Reviewed-by: Rodrigo Vivi
> Signed-off-by: Ben Widawsky
> ---
> drivers/gpu/drm/i915/i915_drv.h| 2 ++
> drivers/gpu/drm/i915/i915_gem_gtt.c| 7 ---
> drivers/gpu/drm/i915/i915_gem_stolen.c | 8
> 3 files ch
On Thu, Jan 17, 2013 at 12:45:18PM -0800, Ben Widawsky wrote:
> Similar to gtt_mappable_entries we don't usually want the entries,
> it's easy enough to calculate it when you need.
>
> v2: Move relevant fields above pre-gen6 init
>
> Reviewed-by: Rodrigo Vivi
> Signed-off-by: Ben Widawsky
[sni
Nothing is shared anymore between AGP and drm/i915 driver. Pre-GEN6
still uses AGP, but all necessary info is encapsulated per driver.
v2: Conflict resolution from earlier rebase
Reviewed-by: Rodrigo Vivi
Signed-off-by: Ben Widawsky
---
drivers/char/agp/intel-gtt.c| 7 ---
drivers
We already had a mapping in both (minus the phys_addr in AGP).
Reviewed-by: Rodrigo Vivi
Signed-off-by: Ben Widawsky
---
drivers/char/agp/intel-gtt.c| 9 +
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_gem_gtt.c | 16
include/drm/intel-
And, move it to where the rest of the logic is.
There is some slight functionality changes. There was extra paranoid
checks in AGP code making sure we never do idle maps on gen2 parts. That
was not duplicated as the simple PCI id check should do the right thing.
v2: use IS_GEN5 && IS_MOBILE check
The reasoning behind our code taking two paths depending upon whether or
not we may have been configured for IOMMU isn't clear to me. It should
always be safe to use the pci mapping functions as they are designed to
abstract the decision we were handling in i915.
Aside from simpler code, removing
Reviewed-by: Rodrigo Vivi
Signed-off-by: Ben Widawsky
---
drivers/char/agp/intel-gtt.c | 35 +--
include/drm/intel-gtt.h | 11 +--
2 files changed, 22 insertions(+), 24 deletions(-)
diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-g
Reviewed-by: Rodrigo Vivi
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h| 2 ++
drivers/gpu/drm/i915/i915_gem_gtt.c| 7 ---
drivers/gpu/drm/i915/i915_gem_stolen.c | 8
3 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i
Similar to gtt_mappable_entries we don't usually want the entries,
it's easy enough to calculate it when you need.
v2: Move relevant fields above pre-gen6 init
Reviewed-by: Rodrigo Vivi
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h | 3 +++
drivers/gpu/drm/i915/i915_gem_
Mappable_end, ie. size is almost always what you want as opposed to the
number of entries. Since we already have that information, we can scrap
the number of entries and only calculate it when needed.
If gtt_start is !0, this will have slightly different behavior. This
difference can only occur in
We have enough info to not use the intel_gtt bridge stuff.
v2: Move setup of mappable_base above the legacy init stuff because we
still need that on older platforms. (Daniel)
v3: Remove the dev_priv hunk which was rebased in by accident
Reviewed-by: Rodrigo Vivi (v2)
Signed-off-by: Ben Widawsky
The purpose of the gtt structure is to help isolate our gtt specific
properties from the rest of the code (in doing so it help us finish the
isolation from the AGP connection).
The following members are pulled out (and renamed):
gtt_start
gtt_total
gtt_mappable_end
gtt_mappable
gtt_base_addr
gsm
With the assertion from the previous patch in place, it should be safe
to get rid gtt_mappable_total. Keeps things saner to not have to track
the same info in two places.
In order to keep the diff as simple as possible and keep with the
existing gtt_setup semantics we opt to keep gtt_mappable_end.
Both DRI1 and DRI2 can never specify a mappable size which goes past the
GTT size. Don't pretend otherwise.
Reviewed-by: Rodrigo Vivi
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/
It's duplicated in the more useful gtt_total.
Reviewed-by: Rodrigo Vivi
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i915/i915_gem_gtt.c | 3 +--
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers
Rebased on a nightly branch which had some decent rebase conflicts resolved for
Daniel. Rodrigo's reviewed-by applied, and a few minor fixes here and there.
Needs some testing on pre-GEN6 platforms.
Ben Widawsky (13):
drm/i915: Kill gtt_end
drm/i915: Mappable_end can't ever be > end
drm/i91
On Thu, Jan 17, 2013 at 03:01:06PM +0100, Egbert Eich wrote:
> Hi Daniel,
>
> On Fri, Jan 11, 2013 at 09:34:08PM +0100, Daniel Vetter wrote:
> >
> > Nice work, and we know that we need this since quite a while. But
> > unfortunately we've not yet come around to implement something. Some
> > high-
From: Ville Syrjälä
The AVI infoframe is able to inform the display whether the source is
sending full or limited range RGB data.
As per CEA-861 [1] we must first check whether the display reports the
quantization range as selectable, and if so we can set the approriate
bits in the AVI inforfram
From: Ville Syrjälä
drm_rgb_quant_range_selectable() will report whether the monitor
claims to support for RGB quantization range selection.
The information can be found in the CEA Video capability block.
v2: s/quantzation/quantization/ in the comment
Reviewed-by: Paulo Zanoni
Signed-off-by:
From: Ville Syrjälä
Add a new "Automatic" mode to the "Broadcast RGB" range property.
When selected the driver automagically selects between full range and
limited range output.
Based on CEA-861 [1] guidelines, limited range output is selected if the
mode is a CEA mode, except 640x480. Otherwise
From: Ville Syrjälä
The RGB color range select bit on the DP/SDVO/HDMI registers
disappeared when PCH was introduced, and instead a new PIPECONF bit
was added that performs the same function.
Add a new INTEL_MODE_LIMITED_COLOR_RANGE private mode flag, and set
it in the encoder mode_fixup if limi
Third attempt at handling the RGB quantization range for HDMI and DP.
Changes since the last time:
- Addressed all of Paulo's review comments.
I think this is ready to go in, unless someone complains loudly.
___
Intel-gfx mailing list
Intel-gfx@lists.fr
Hi Dave
More important fixes for 3.9:
- error_state improvements to help debug the new scanline wait code added
for gen6+ - bug reports started popping up :( patch from Chris Wilson.
- fix a panel power sequence confusion between the eDP and lvds detection
code resulting in black screens - reg
Hi Daniel,
On Fri, Jan 11, 2013 at 09:34:08PM +0100, Daniel Vetter wrote:
>
> Nice work, and we know that we need this since quite a while. But
> unfortunately we've not yet come around to implement something. Some
> high-level comments on how I think this should best be handled:
>
> - imo dv_pr
Reviewed-by: Rodrigo Vivi
On Wed, Jan 16, 2013 at 4:22 PM, Ben Widawsky wrote:
> The reasoning behind our code taking two paths depending upon whether or
> not we may have been configured for IOMMU isn't clear to me. It should
> always be safe to use the pci mapping functions as they are designe
Reviewed-by: Rodrigo Vivi
On Wed, Jan 16, 2013 at 4:22 PM, Ben Widawsky wrote:
> Similar to gtt_mappable_entries we don't usually want the entries,
> it's easy enough to calculate it when you need.
>
> v2: Move relevant fields above pre-gen6 init
>
> Signed-off-by: Ben Widawsky
> ---
> drivers
Hi
2013/1/16 :
> From: Ville Syrjälä
>
> Add a new "Automatic" mode to the "Broadcast RGB" range property.
> When selected the driver automagically selects between full range and
> limited range output.
>
> Based on CEA-861 guidelines, limited range output is selected if the
> mode is a CEA mode
Reviewed-by: Rodrigo Vivi
On Wed, Jan 16, 2013 at 4:22 PM, Ben Widawsky wrote:
> Mappable_end, ie. size is almost always what you want as opposed to the
> number of entries. Since we already have that information, we can scrap
> the number of entries and only calculate it when needed.
>
> If gtt
Reviewed-by: Rodrigo Vivi
On Wed, Jan 16, 2013 at 4:20 PM, Ben Widawsky wrote:
> We have enough info to not use the intel_gtt bridge stuff.
>
> v2: Move setup of mappable_base above the legacy init stuff because we
> still need that on older platforms. (Daniel)
>
> Signed-off-by: Ben Widawsky
>
ops, I just noticed this v2 here...
same for this one:
Reviewed-by: Rodrigo Vivi
On Wed, Jan 16, 2013 at 4:23 PM, Ben Widawsky wrote:
> Nothing is shared anymore between AGP and drm/i915 driver. Pre-GEN6
> still uses AGP, but all necessary info is encapsulated per driver.
>
> v2: Conflict resolu
Reviewed-by: Rodrigo Vivi
On Tue, Jan 15, 2013 at 7:26 PM, Ben Widawsky wrote:
> Nothing is shared anymore between AGP and drm/i915 driver. Pre-GEN6
> still uses AGP, but all necessary info is encapsulated per driver.
>
> Signed-off-by: Ben Widawsky
> ---
> drivers/char/agp/intel-gtt.c
Hi
2013/1/16 :
> From: Ville Syrjälä
>
> The RGB color range select bit on the DP/SDVO/HDMI registers
> disappeared when PCH was introduced, and instead a new PIPECONF bit
> was added that performs the same function.
>
> Add a new INTEL_MODE_LIMITED_COLOR_RANGE private mode flag, and set
> it in
On Thu, Jan 17, 2013 at 10:16:46AM -0200, Paulo Zanoni wrote:
> Hi
>
> 2013/1/16 :
> > From: Ville Syrjälä
> >
> > The AVI infoframe is able to inform the display whether the source is
> > sending full or limited range RGB data.
> >
> > As per CEA-861 we must first check whether the display repo
Hi
2013/1/16 :
> From: Ville Syrjälä
>
> The AVI infoframe is able to inform the display whether the source is
> sending full or limited range RGB data.
>
> As per CEA-861 we must first check whether the display reports the
> quantization range as selectable, and if so we can set the approriate
Hi
2013/1/16 :
> From: Ville Syrjälä
>
> drm_rgb_quant_range_selectable() will report whether the monitor
> claims to support for RGB quantization range selection.
>
> The information can be found in the CEA Video capability block.
Looks correct (checked against the spec, did not really test).
On Thu, Jan 17, 2013 at 10:56:28AM +, Beauchesne, Gwenole wrote:
> > On Fri, Jan 11, 2013 at 09:41:05AM +0100, Daniel Vetter wrote:
> > I'm not against doing that, it'll shed more light/review/etc on the
> > assembler (I
> > assume patches would have to hit this list first).
> >
> > Xiang, Ho
On Thu, Jan 17, 2013 at 12:39 PM, Jani Nikula wrote:
> Right, I just didn't feel very confident making strong claims here based
> on more or less anecdotal evidence. (And even the original "never read
> FORCEWAKE" feels like folklore...) Making rc6 more stable on one machine
> was implied, but I c
On Thu, 17 Jan 2013, Chris Wilson wrote:
> On Thu, 17 Jan 2013 10:24:09 +0200, Jani Nikula wrote:
>> We stopped reading FORCEWAKE for posting reads in
>>
>> commit 8dee3eea3ccd3b6c00a8d3a08dd715d6adf737dd
>> Author: Ben Widawsky
>> Date: Sat Sep 1 22:59:50 2012 -0700
>>
>> drm/i915: Neve
On Thu, 17 Jan 2013 10:24:09 +0200, Jani Nikula wrote:
> We stopped reading FORCEWAKE for posting reads in
>
> commit 8dee3eea3ccd3b6c00a8d3a08dd715d6adf737dd
> Author: Ben Widawsky
> Date: Sat Sep 1 22:59:50 2012 -0700
>
> drm/i915: Never read FORCEWAKE
>
> and started using something f
We stopped reading FORCEWAKE for posting reads in
commit 8dee3eea3ccd3b6c00a8d3a08dd715d6adf737dd
Author: Ben Widawsky
Date: Sat Sep 1 22:59:50 2012 -0700
drm/i915: Never read FORCEWAKE
and started using something from the same cacheline instead. It turns out
reading ECOBUS as posting rea
44 matches
Mail list logo
