At Wed, 25 Apr 2012 10:14:51 +0200,
Takashi Iwai wrote:
>
> At Thu, 19 Apr 2012 20:11:53 +0200,
> Takashi Iwai wrote:
> >
> > At Thu, 19 Apr 2012 13:55:04 -0400,
> > Adam Jackson wrote:
> > >
> > > On Thu, 2012-04-19 at 18:10 +0200, Takashi Iwai wrote:
> > >
> > > > This patch adds a flag to di
On Mon, 7 May 2012 14:31:51 -0700, Paul Berry wrote:
> This patch adds a new function,
> drm_intel_bufmgr_gem_set_aub_annotations(), which can be used to
> annotate the type and subtype of data stored in various sections of
> each buffer. This data is used to populate type and subtype fields
> w
On Mon, 7 May 2012 14:31:52 -0700, Paul Berry wrote:
> ---
> configure.ac |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index 6a1d98e..538d0d8 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -20,7 +20,7 @@
>
> AC_PREREQ([2.
2012/5/9 Eugeni Dodonov :
>
> Without this, I am getting a nice black screen though . But the latest
> theory is that perhaps we just need to send any infoframe for the hardware
> to catch up and work in HDMI mode?
>
I finally tested this :) I don't think anymore this is the case since
the ddi_func
On 05/09/2012 09:34 PM, Paulo Zanoni wrote:
2012/5/9 Eugeni Dodonov:
Haswell has different DIP control registers and offsets which we need to
use for infoframes, which this patch adds.
Note that this does not adds full DIP frames support, but only the basic
functionality necessary for HDMI to w
2012/5/9 Eugeni Dodonov :
> Haswell has different DIP control registers and offsets which we need to
> use for infoframes, which this patch adds.
>
> Note that this does not adds full DIP frames support, but only the basic
> functionality necessary for HDMI to work in early enablement.
>
> Signed-o
On Haswell, the recommended PCH-connected output is the one driven by DDI
E in FDI mode, used for VGA connection. All the others are handled by the
CPU.
Note that this does not accounts for Haswell/PPT combination yet, so if we
encounter such combination an error message is thrown to indicate that
This attempts to enable all the available power wells during the
initialization.
Those power wells can be enabled in parallel or on-demand, and disabled
when no longer needed, but this is out of scope of this initial
enablement. Proper tracking of who uses which power well will require
a considera
On Thu, 10 May 2012 00:40:20 +0200
Daniel Vetter wrote:
> Inspired by the recent ppgtt regression report, where switching of
> dmar only for the gpu seems to fix things completely, I've looked
> again at the semaphores+vt-d situation.
>
> Contrary to my earlier testing a few months back my syste
Inspired by the recent ppgtt regression report, where switching of
dmar only for the gpu seems to fix things completely, I've looked
again at the semaphores+vt-d situation.
Contrary to my earlier testing a few months back my system is now
stable with dmar disabled for the igd, and not only when di
In many places we wish to iterate over the rings associated with the
GPU, so refactor them to use a common macro.
Along the way, there are a few code removals that should be side-effect
free and some rearrangement which should only have a cosmetic impact,
such as error-state.
Signed-off-by: Chris
On Wed, May 09, 2012 at 03:37:30PM -0300, Eugeni Dodonov wrote:
> Move intel_hdmi data structure and support functions to a shared location,
> to allow their usage from intel_ddi module.
>
> Reviewed-by: Jesse Barnes
> Signed-off-by: Eugeni Dodonov
> ---
> drivers/gpu/drm/i915/intel_drv.h |
On Wed, May 09, 2012 at 03:37:15PM -0300, Eugeni Dodonov wrote:
> On Haswell, the recommended PCH-connected output is the one driven by DDI
> E in FDI mode, used for VGA connection. All the others are handled by the
> CPU.
>
> Note that this does not accounts for Haswell/PPT combination yet, so if
On Wed, May 09, 2012 at 03:37:16PM -0300, Eugeni Dodonov wrote:
> This attempts to enable all the available power wells during the
> initialization.
>
> Those power wells can be enabled in parallel or on-demand, and disabled
> when no longer needed, but this is out of scope of this initial
> enabl
Currently the code re-reads PCH_IIR during the hotplug interrupt
processing. Not only is this a wasted read, but introduces a potential
for handling a spurious interrupt as we then may not clear all the
interrupts processed (since the re-read IIR may contains more interrupts
asserted than we clear
We can take advantage that the PCH_IIR is a subordinate register to
reduce one of the required IIR reads, and that we only need to clear
interrupts handled to reduce the writes. And by simply tidying the code
we can reduce the line count and hopefully make it more readable.
v2: Split out the bugfi
On Wed, May 09, 2012 at 11:56:28AM +0100, Chris Wilson wrote:
> Currently we call gen6_enable_rps() (which writes into the per-ring
> register mmio space) from intel_modeset_init_hw() which is called before
> we initialise the rings. If we defer intel_modeset_init_hw() until
> afterwards (in the in
On Wed, May 09, 2012 at 03:41:27PM +0530, Sateesh Kavuri wrote:
> The repository hosted at git.debian.org does not have my changes, but the
> one at freedesktop does. Which is the maintained repo?
>
> apt-get source prints the repository being at
> git://git.debian.org/git/pkg-xorg/app/intel-gpu-t
This patch enables i915 driver to handle Haswell devices. It should go in
last, when things are working stable enough.
Signed-off-by: Eugeni Dodonov
---
drivers/char/agp/intel-agp.c|4
drivers/gpu/drm/i915/i915_drv.c |7 +++
2 files changed, 11 insertions(+)
diff --git a/dr
On Haswell, we need to properly train the DDI buffers prior to enabling
HDMI, and enable the required clocks with correct dividers for the desired
frequency.
Also, we cannot simple reuse HDMI routines from previous generations of
GPU, as most of HDMI-specific stuff is being done via the DDI port
p
Move intel_hdmi data structure and support functions to a shared location,
to allow their usage from intel_ddi module.
Reviewed-by: Jesse Barnes
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/intel_drv.h | 19 ++-
drivers/gpu/drm/i915/intel_hdmi.c | 19 +++--
This table is used for programming WR PLL clocks, used by HDMI and DVI outputs.
I split it into a separate patch to simplify the HDMI enabling patch which was
getting huge.
Note that this table is a temporary solution for WR PLL programming. It
will be reworked into a more exact algorithm at a lat
Those are driven by DDIs on Haswell architecture, so we need to keep track
of which DDI is being used on each output.
Reviewed-by: Jesse Barnes
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/intel_hdmi.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/
Digital port detection on Haswell is indicated by the presence of a bit in
DDI_BUF_CTL for port A, and by a different register for ports B, C and D.
So we check for those bits during the initialization time and let the hdmi
function know about those.
Note that this bit does not indicates whether t
The iCLKIP clock is used to drive the VGA pixel clock on the PCH. In order
to do so, it must be programmed to properly do the clock ticks according
to the divisor, phase direction, phase increments and a special auxiliary
divisor for 20MHz clock.
v2: calculate divisor values directly instead of re
This can be acomplished by simple writing 0 to the DDI function control
register too, but better be explicit about what fields we are unsetting
here to prevent possible issues.
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/intel_display.c | 10 ++
1 file changed, 10 insertions
The line time can be programmed according to the number of horizontal
pixels vs effective pixel rate ratio.
v2: improve comment as per Chris Wilson suggestion
v3: incorporate latest changes in specs.
v4: move into wm update routine, also mention that the same routine can
program IPS watermarks.
For now, we simple reuse the Ivy Bridge routines here.
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/intel_pm.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index bd9549d..452a9bc 100644
--- a/driver
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/intel_display.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index dbd8222..944a876 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm
Starting with Haswell, DDI ports can work in FDI mode to support
connectivity with the outputs located on the PCH.
This commit adds support for such connections in the intel_ddi module, and
provides Haswell-specific functionality to make it work.
v2: simplify the commit as per Daniel Vetter sugge
DDI is introduced starting with Haswell GPU generation. So to simplify its
management in the future, we also add intel_ddi.c to hold all the
DDI-related items.
Buffer translations for DDI links must be initialized prior to enablement.
For FDI and DP, first 9 pairs of values are used to select the
On Haswell, only one pipe can work in FDI mode, so this patch prevents
messing with wrong registers when FDI is being used by non-first pipe. And
to prevent this, we also specify that the VGA can only be used on pipe 0
for now in the crtc_mask value.
Reviewed-by: Jesse Barnes
Signed-off-by: Eugen
Prevent bogus asserts on DDI-related paths.
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/intel_display.c | 35 --
1 file changed, 25 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display
Avoid bogus asserts and PCH PLL accesses on Lynx Point.
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/intel_display.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
in
This should be already configured when FDI auto-negotiation is done.
Reviewed-by: Rodrigo Vivi
Reviewed-by: Jesse Barnes
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/intel_display.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_di
This attempts to enable all the available power wells during the
initialization.
Those power wells can be enabled in parallel or on-demand, and disabled
when no longer needed, but this is out of scope of this initial
enablement. Proper tracking of who uses which power well will require
a considera
On Haswell, the recommended PCH-connected output is the one driven by DDI
E in FDI mode, used for VGA connection. All the others are handled by the
CPU.
Note that this does not accounts for Haswell/PPT combination yet, so if we
encounter such combination an error message is thrown to indicate that
This will throw a BUG() message when an unknown sdvox register is
given to intel_hdmi_init. When this happens, things could going to be pretty
much broken afterwards, so we better detect this as soon as possible.
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/intel_hdmi.c |4
1
As suggested by Chris Wilson and Daniel Vetter, this chunk of code can be
simplified with a more simple check.
Also, as noticed by Jesse Barnes, it is worth mentioning that plane is an
enum and num_pipe is an int, so we could be more paranoid here about those
validation checks eventually.
CC: Dan
This adds proper support for calculating those watermarks, checking for
number of available pipes instead of specific GPU variants when deciding
if watermarks for 3rd pipe are necessary.
Reviewed-by: Jesse Barnes
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/intel_pm.c |3 +--
1 fi
With Lynx Point, we need to use SBI to communicate with the display clock
control. This commit adds helper functions to access the registers via
SBI.
v2: de-inline the function and address changes in bits names
v3: protect operations with dpio_lock, increase timeout to 100 for
paranoia sake.
v4:
Haswell interrupts are mostly similar with Ivy Bridge, so we share same
routines with it.
This patch also simplifies the vblank counter handling for all the Gen5+
architectures.
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/i915_irq.c | 11 +--
1 file changed, 9 insertions(+)
Haswell has different DIP control registers and offsets which we need to
use for infoframes, which this patch adds.
Note that this does not adds full DIP frames support, but only the basic
functionality necessary for HDMI to work in early enablement.
Signed-off-by: Eugeni Dodonov
---
drivers/gp
Hi,
Essentially those are the same patches as in the previous round, rebased on
yesterday's drm-intel-next-queued, and with the following comments and
suggestions from Daniel and Jesse addressed:
- Added all the new DIP controls, and a switch into hsw_write_infoframe to
properly write frame c
As suggested by Daniel, rip out the independent timers for device and
crtc busyness and integrate the manual powermanagement of the display
engine into the GEM core and its request tracking. The benefits are that
the code is a lot smaller, fewer moving parts and should fit more neatly
into the over
Currently we call gen6_enable_rps() (which writes into the per-ring
register mmio space) from intel_modeset_init_hw() which is called before
we initialise the rings. If we defer intel_modeset_init_hw() until
afterwards (in the intel_modeset_gem_init() phase) all is well.
v2: Rectify ordering of ge
The repository hosted at git.debian.org does not have my changes, but the
one at freedesktop does. Which is the maintained repo?
apt-get source prints the repository being at
git://git.debian.org/git/pkg-xorg/app/intel-gpu-tools.git
--
Sateesh
On 05/09/2012 02:41 PM, Sateesh Kavuri wrote:
Da
Daniel,
I sent the patch for intel-gpu-tools port to Android and I remember you
mentioning that it is merged. But I do not see my patches in the
intel-gpu-tools git repo.
Have the patches been merged?
--
Sateesh
On 05/09/2012 01:03 PM, iyshwarya wrote:
Chad Versace linux.intel.com> writes:
>
> We need to run the intel gpu tools test in Android(ICS). As you have said here
> ,we require the libpciaccess for the intel GPU tools tests to be run in
> Android. I
> have not found any method so far as how to put the libpciaccess into Android.
> Can u help us on this ASAP?
>
I remember se
Chad Versace linux.intel.com> writes:
>
> On 12/28/2011 07:11 AM, Purushothaman, Vijay A wrote:
> > You need libpciaccess in Android if you want to use intel-gpu-tools in
Android. We have already ported
> these tools to work in Android.
> >
> > Thanks,
> > Vijay
>
> Vijay, please share the s
Chad Versace linux.intel.com> writes:
>
> On 12/28/2011 07:11 AM, Purushothaman, Vijay A wrote:
> > You need libpciaccess in Android if you want to use intel-gpu-tools in
Android. We have already ported
> these tools to work in Android.
> >
> > Thanks,
> > Vijay
>
> Vijay, please share the so
On Wed, May 09, 2012 at 07:51:35AM +0100, Dave Airlie wrote:
> On Tue, May 8, 2012 at 12:19 PM, Daniel Vetter wrote:
> > ... given that I essentially run the show already, let's make this
> > official.
>
> Acked-by: Dave Airlie
>
> probably just push it via your -next.
Will do.
Thanks, Daniel
52 matches
Mail list logo
