On Wed, Feb 19, 2014 at 06:59:26PM +0200, mika.kuopp...@intel.com wrote:
> From: Mika Kuoppala
>
> as they don't exists.
>
> Signed-off-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/intel_uncore.c |9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gp
On Wed, Feb 19, 2014 at 06:59:25PM +0200, mika.kuopp...@intel.com wrote:
> From: Mika Kuoppala
>
> When we get control from BIOS there might be mt forcewake
> bits already set. Apparently double write into mt forcewake
> without proper clear/ack sequence in between will cause
> system hang.
>
I
Hi Ville/All,
We gave a presentation on design on this framework, few months ago, in one of
our common forum with OTC folks.
We discussed, took review comments, and re-designed the framework, as per the
feedbacks.
We also discussed the benefits of providing the controls directly from /sysfs
Pasi Kärkkäinen wrote on 2014-02-21:
> On Thu, Feb 20, 2014 at 07:59:04AM +, Cui, Dexuan wrote:
>> Hi all,
>> We're pleased to announce an update to XenGT since its first disclosure in
>> last Sep.
>
> Are you going to work on upstreaming this stuff? Xen 4.4 will be
> released soon(ish), so th
On Wed, Feb 19, 2014 at 9:20 PM, Josh Boyer wrote:
> Hi All,
>
> We've had a rather weird report[1] of the brightness adjustments being
> broken in a specific case with Thinkpad x220 hardware (SandyBridge
> based). If you boot the machine with it in a dock and then undock,
> the brightness adjust
From: "Yu(Alex) Dai"
Add "zorder" property to crtc to control Z-order of sprite and
primary planes. The alpha channel of the planes can be enabled
or disabled during Z-order change.
Signed-off-by: Yu(Alex) Dai
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_reg.h
This got lost when we shuffled around our internal branch and
GEN7_FEATURES macro. There were no HW changes to support FBC, so we just
need to set the flag.
v2: Don't allow FBC for any pipe but A on platforms with DDI. (Paulo)
Cc: Daisy Sun
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/
On Thu, Feb 20, 2014 at 12:39:57PM -0800, Jesse Barnes wrote:
> Useful for bug reports.
Hey, this would be useful for error state as well :)
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesk
On Thu, Feb 20, 2014 at 12:28:07PM -0800, Jesse Barnes wrote:
> In the move over to use BIOS connector configs, we lost the ability to
> force a specific set of connectors on or off. Try to remedy that by
> dropping back to the old behavior if we detect a hard coded connector
> config.
>
> v2: do
Useful for bug reports.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_debugfs.c |4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index b737583..1cb56f7 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.
In the move over to use BIOS connector configs, we lost the ability to
force a specific set of connectors on or off. Try to remedy that by
dropping back to the old behavior if we detect a hard coded connector
config.
v2: don't deref connector state for disabled connectors (Jesse)
Reported-by: Vi
Am Montag, den 10.02.2014, 09:58 +0100 schrieb Daniel Vetter:
> On Sat, Feb 08, 2014 at 07:30:54PM +0100, Thomas Meyer wrote:
> > Am Samstag, den 08.02.2014, 17:38 +0100 schrieb Daniel Vetter:
> > > On Sat, Feb 8, 2014 at 12:51 PM, Thomas Meyer wrote:
> > > > Am Freitag, den 07.02.2014, 09:46 +010
On Wed, 19 Feb 2014 14:29:44 +0200
Ville Syrjälä wrote:
> On Tue, Feb 18, 2014 at 12:02:20AM +0200, Imre Deak wrote:
> > Based on an early draft from Jesse.
> >
> > Add support for powering on/off the dynamic power wells on VLV by
> > registering its display and dpio dynamic power wells with the
On Tue, 18 Feb 2014 00:02:18 +0200
Imre Deak wrote:
> We'll need to disable/re-enable the display-side IRQs when turning
> off/on the VLV display power well. Factor out the helper functions
> for this. For now keep the display IRQs enabled by default, so the
> functionality doesn't change. This w
On Tue, 18 Feb 2014 00:02:15 +0200
Imre Deak wrote:
> On VLV at least the display IRQ register access and functionality
> depends on its power well to be on, so move the power domain HW init
> before we install the IRQs.
>
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/i915_dma.c | 4
On Tue, 18 Feb 2014 00:02:19 +0200
Imre Deak wrote:
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_pm.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 21ccf89..68f58e
The previous allocation mechanism would get 2 contiguous allocations,
one for the page directories, and one for the page tables. As each page
table is 1 page, and there are 512 of these per page directory, this
goes to 2MB. An unfriendly request at best. Worse still, our HW now
supports 4 page dire
On Tue, 18 Feb 2014 00:02:16 +0200
Imre Deak wrote:
> This way we can reuse the check on other platforms too. Also factor out
> a version of the function that doesn't check if the power is on, we'll
> need to call this from within the power domain framework.
>
> Signed-off-by: Imre Deak
> ---
>
This patch converts insert_entries and clear_range, both functions which
are specific to the VM. These functions tend to encapsulate the gen
specific PTE writes. Passing absolute addresses to the insert_entries,
and clear_range will help make the logic clearer within the functions as
to what's goin
At one time it was expected to be called in multiple places by kref_put.
At the current time however, it is all contained within
i915_gem_context.c.
This patch makes an upcoming required addition a bit nicer since it too
doesn't need to be defined in a header file.
Signed-off-by: Ben Widawsky
--
GEN8 never freed the PPGTT struct. As GEN8 doesn't use full PPGTT, the
leak is small and only found on a module reload. ie. I don't think this
needs to go to stable.
v2: The very naive, kfree in gen8 ppgtt cleanup, is subject to a double
free on PPGTT initialization failure. (Spotted by Imre). Ins
On Tue, 18 Feb 2014 00:02:13 +0200
Imre Deak wrote:
> In the upcoming patches we'll need to access the rest of the fields in
> the punit power gating register, so prepare for that.
>
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/i915_reg.h | 29 +++--
> dr
On Thu, Feb 20, 2014 at 11:17:31AM -0800, Jesse Barnes wrote:
> On Tue, 18 Feb 2014 00:02:03 +0200
> Imre Deak wrote:
>
> > These functions are used only by a single call site and are simple
> > enough to just fold them in.
> >
> > No functional change.
There should be a much better reason (or
On Wed, 19 Feb 2014 14:39:58 +0200
Imre Deak wrote:
> On Wed, 2014-02-19 at 14:35 +0200, Ville Syrjälä wrote:
> > On Tue, Feb 18, 2014 at 12:02:09AM +0200, Imre Deak wrote:
> > > The connector detect and get_mode handlers need to access the port
> > > specific HW blocks to read the EDID etc. Get/
On Tue, 18 Feb 2014 00:02:11 +0200
Imre Deak wrote:
> We can read out the pipe HW state only if the required power domain is
> on. If not we consider the pipe to be off.
>
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_display.c | 19 +++
> 1 file changed, 15 ins
On Tue, 18 Feb 2014 00:02:10 +0200
Imre Deak wrote:
> Since the encoder is tied to its port, we need to make sure the power
> domain for that port is on before reading out the encoder HW state.
>
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 2 +-
> drivers/gpu/drm
On Thu, Feb 20, 2014 at 12:37:19PM +0200, Imre Deak wrote:
> On Wed, 2014-02-19 at 22:05 -0800, Ben Widawsky wrote:
> > This patch converts insert_entries and clear_range, both functions which
> > are specific to the VM. These functions tend to encapsulate the gen
> > specific PTE writes. Passing a
On Tue, 18 Feb 2014 00:02:07 +0200
Imre Deak wrote:
> An always-on power well can be already recognized by the lack of
> is_enabled handler, so just depend on that. Suggested by Daniel.
>
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 -
> drivers/gpu/drm/i915/intel_pm.
On Tue, 18 Feb 2014 00:02:06 +0200
Imre Deak wrote:
> Split the 'set' power well handler into an 'enable', 'disable' and
> 'sync_hw' handler. This maps more conveniently to higher level
> operations, for example it allows us to push the hsw package c8 handling
> into the corresponding hsw/bdw ena
On Tue, 18 Feb 2014 00:02:08 +0200
Imre Deak wrote:
> Parts that poke port specific HW blocks like the encoder HW state
> readout or connector hotplug detect code need a way to check whether
> required power domains are on or enable/disable these. For this purpose
> add a set of power domains tha
On Tue, 18 Feb 2014 00:02:05 +0200
Imre Deak wrote:
> These macros are used only locally, so move them to the .c file.
>
> Also since logically the init power domain should be part of all power
> wells add it to the always-on power wells too for consistency. Since
> always-on power wells have no
On Tue, 18 Feb 2014 00:02:02 +0200
Imre Deak wrote:
> The power domains framework is internal to the i915 driver, so pass
> drm_i915_private instead of drm_device to its functions.
>
> Also remove a dangling intel_set_power_well() declaration.
>
> No functional change.
>
> Signed-off-by: Imre
On Tue, 18 Feb 2014 00:02:04 +0200
Imre Deak wrote:
> These functions will be needed by the valleyview specific power well
> update functionality added in an upcoming patch, so move them earlier.
>
> No functional change.
>
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_display
On Tue, 18 Feb 2014 00:02:03 +0200
Imre Deak wrote:
> These functions are used only by a single call site and are simple
> enough to just fold them in.
>
> No functional change.
>
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_pm.c | 37 +
>
On Wed, 19 Feb 2014 13:09:31 -0800
Sinclair Yeh wrote:
> V2: edit the commit message to contain more info
> The W/A spreadsheet says this is still required, but the b-spec says
> it's not for BYT-T. So the documentation is not clear. However,
> our experience with the other SKUs of BYT-I/M on
From: Thierry Reding
Implements an I2C-over-AUX I2C adapter on top of the generic drm_dp_aux
infrastructure. It extracts the retry logic from existing drivers, which
should help in porting those drivers to this new helper.
Reviewed-by: Alex Deucher
Reviewed-by: Jani Nikula
Signed-off-by: Thier
From: Thierry Reding
Hi,
This small series introduces some infrastructure to support AUX channels
in a generic way. Drivers make use of it by embedding and filling in a
struct drm_dp_aux. Various helpers can then be used to for example read
from or write to the DPCD.
Patch 1 adds the basic infr
From: Thierry Reding
Add a helper to probe a DP link (read out the supported DPCD revision,
maximum rate, link count and capabilities) as well as power up the DP
link and configure it accordingly.
Reviewed-by: Alex Deucher
Reviewed-by: Jani Nikula
Signed-off-by: Thierry Reding
---
Changes in
From: Thierry Reding
This is a superset of the current i2c_dp_aux bus functionality and can
be used to transfer native AUX in addition to I2C-over-AUX messages.
Helpers are provided to read and write the DPCD, either blockwise or
byte-wise. Many of the existing helpers for DisplayPort take a cop
From: Thierry Reding
The function reads the link status (6 bytes starting at offset 0x202)
from the DPCD so that it can be conveniently passed to other DPCD
helpers.
Reviewed-by: Alex Deucher
Reviewed-by: Jani Nikula
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_dp_helper.c | 16
On Thu, 2014-02-20 at 13:14 +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> The docs are a bit lacking when it comes to describing when certain
> timing related events occur in the hardware. Draw a picture which
> tries to capture the most important ones.
>
> v2: Clarify a
On Thu, Feb 20, 2014 at 06:07:21PM +0530, Shashank Sharma wrote:
> Color manager is a new framework in i915 driver, which provides
> a unified interface for various color correction methods supported
> by intel hardwares. The high level overview of this change is:
Would have been good to discuss
On Wed, 2014-02-19 at 22:05 -0800, Ben Widawsky wrote:
> Like cleanup in an earlier patch, the code becomes much more readable,
> and easier to extend if we extract out helper functions for the various
> stages of init.
>
> Note that with this patch it becomes really simple, and tempting to begin
This patch is third extension to color manager framework.
It adds implementataion of color manager property "Brightness
and Contrast correctio"n in intel color manager framework.
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_clrmgr.c | 98 ++-
1 f
This patch is second extension to color manager framework.
It adds implementataion of color manager property Gamma
correction in intel color manager framework.
Gamma correction is possible at various levels like:
1. PIPE level = (primary plane + sprite)
2. Plane level = (primary plane only)
3. Spr
This patch is fourth extension to color manager framework.
It adds implementataion of color manager property "Hue and
Saturation correction" in intel color manager framework.
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_clrmgr.c | 84 +++
1 file
This patch adds functions:
1. save_color_manager_status: to save color manager
correction values during a display suspend and
2. restore_color_manager_status: to restore color
correction values during display resume time.
This will help to give consistent color correction across
suspend resume cyc
Color manager is a new framework in i915 driver, which provides
a unified interface for various color correction methods supported
by intel hardwares. The high level overview of this change is:
1. Intel hardwares support various color correction methods like
a. csc(wide gamut) correction
Intel color manager is a new framework to provide control over
few of the color properties (supported by intel Gen 7 and+
hardware) via sysfs interface. Currently supported properties
are:
1. CSC correction (wide gamute)
2. Gamma correction
3. Hue and Saturation correction
4. Brightness and contras
This patch is first extension to color manager framework.
It adds implementataion of color manager property CSC
correction (wide gamute) in intel color manager framework.
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_clrmgr.c | 117 +--
1 file cha
On Wed, 2014-02-19 at 22:05 -0800, Ben Widawsky wrote:
> The previous allocation mechanism would get 2 contiguous allocations,
> one for the page directories, and one for the page tables. As each page
> table is 1 page, and there are 512 of these per page directory, this
> goes to 2MB. An unfriendl
Hi,
To support a plethora of MIPI panels, the VBT has been enhanced to support
multiple panels in a generic manner. This involves adding one MIPI configuration
block (#52) which provide all panel specific configuration data along with the
dphy configuration information as per panel/tcon specs. Als
MIPI Block #52 which provides configuration details for the MIPI panel
including dphy settings as per panel and tcon specs
Block #53 gives information on panel enable sequences
v2: Address review comemnts from Jani
- Move panel ids from intel_dsi.h to intel_bios.h
- bdb_mipi_config struct
The parser extracts the config block(#52) and sequence(#53) data
and store in private data structures.
v2: Address review comments by Jani
- adjust code for the structure changes for bdb_mipi_config
- add boundry and buffer overflow checks as suggested
- use kmemdup instead of kmalloc
From: Ville Syrjälä
The docs are a bit lacking when it comes to describing when certain
timing related events occur in the hardware. Draw a picture which
tries to capture the most important ones.
v2: Clarify a few details (Imre)
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c
From: Ville Syrjälä
On gen2 the scanline counter behaves a bit differently from the
later generations. Instead of adding one to the raw scanline
counter value, we must subtract one.
v2: Remove the gen3 FIXME. Gen3 behaves like gen4
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_ir
On Wed, 2014-02-19 at 22:05 -0800, Ben Widawsky wrote:
> This patch converts insert_entries and clear_range, both functions which
> are specific to the VM. These functions tend to encapsulate the gen
> specific PTE writes. Passing absolute addresses to the insert_entries,
> and clear_range will hel
On Wed, 2014-02-19 at 22:05 -0800, Ben Widawsky wrote:
> GEN8 never freed the PPGTT struct. As GEN8 doesn't use full PPGTT, the
> leak is small and only found on a module reload. ie. I don't think this
> needs to go to stable.
>
> Reported-by: Ville Syrjälä
> Signed-off-by: Ben Widawsky
> ---
>
After a hang and failed reset, we cannot use the GPU to execute the page
flip instructions. Instead we can force a synchronous mmio flip. (Later,
we can reduce the synchronicity of the mmio flip by moving some of the
delays off to a worker, like the current page flip code; see vblank
tasks.)
Refer
On Wed, Feb 19, 2014 at 01:02:57PM +0200, Ville Syrjälä wrote:
> On Wed, Feb 19, 2014 at 09:33:11AM +, Goel, Akash wrote:
> > Thanks for your inputs.
> >
> > Actually for our use cases, the 'scaling_mode' property currently being
> > used for 'lvds' & 'dp', cannot be used as it is.
> >
> > F
Hi all,
We're pleased to announce an update to XenGT since its first disclosure in last
Sep. XenGT is a full GPU virtualization solution with mediated pass-through, on
Intel Processor Graphics. A virtual GPU instance is maintained for each VM,
with part of performance critical resources directly
61 matches
Mail list logo
