On Mon, Aug 19, 2013 at 05:25:34PM -0700, Ben Widawsky wrote:
> On Tue, Aug 20, 2013 at 01:08:22AM +0100, Damien Lespiau wrote:
> > On Mon, Aug 19, 2013 at 04:20:40PM -0700, Ben Widawsky wrote:
> > > runtime with the module option i915.preliminary_hw_support=1; this
> > > option changes the
On Tue, Aug 20, 2013 at 01:08:22AM +0100, Damien Lespiau wrote:
> On Mon, Aug 19, 2013 at 04:20:40PM -0700, Ben Widawsky wrote:
> > We generally don't want people or distros to use this option unless they
> > know what they're doing. I missed the initial conversation but it's
> > likely a way for p
On Tue, Aug 20, 2013 at 01:08:22AM +0100, Damien Lespiau wrote:
> On Mon, Aug 19, 2013 at 04:20:40PM -0700, Ben Widawsky wrote:
> > We generally don't want people or distros to use this option unless they
> > know what they're doing. I missed the initial conversation but it's
> > likely a way for p
On Mon, Aug 19, 2013 at 04:20:40PM -0700, Ben Widawsky wrote:
> We generally don't want people or distros to use this option unless they
> know what they're doing. I missed the initial conversation but it's
> likely a way for people who have a built-in i915.ko and have no other
> way to change the
We generally don't want people or distros to use this option unless they
know what they're doing. I missed the initial conversation but it's
likely a way for people who have a built-in i915.ko and have no other
way to change the behavior.
As such:
Set default to n
Display message f
On Mon, Aug 19, 2013 at 04:01:13PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> If LCPLL is disabled, there's a chance we might be in package C8 state
> or deeper, and we'll get a hard hang when restoring LCPLL (also, a red
> led lights up on my motherboard). So grab the force_wake, which
On Mon, Aug 19, 2013 at 09:59:14AM +0300, Dan Carpenter wrote:
> Hello Ben Widawsky,
>
> Here is another use after free warning. It's some new static checker
> stuff that I haven't pushed because it has lots of false postives.
>
> The patch f7795b1d0b47: "drm/i915: Switch eviction code to use vm
On Mon, Aug 19, 2013 at 05:18:47PM -0300, Paulo Zanoni wrote:
> 2013/8/19 Jesse Barnes :
> > The existing code was trying different vswing and preemphasis settings
> > in the wrong place, and wasn't trying them enough. So add a loop to
> > walk through them, properly disabling FDI TX and RX in bet
2013/8/19 Jesse Barnes :
> The existing code was trying different vswing and preemphasis settings
> in the wrong place, and wasn't trying them enough. So add a loop to
> walk through them, properly disabling FDI TX and RX in between if a
> failure is detected.
>
> v2: remove unneeded reg writes, a
On Mon, Aug 19, 2013 at 02:49:50PM +0100, Damien Lespiau wrote:
> On Thu, Aug 15, 2013 at 05:12:00PM +0200, Thierry Reding wrote:
> > On Wed, Aug 14, 2013 at 06:19:12PM +0100, Damien Lespiau wrote:
> > [...]
> > > +#define HDMI_IDENTIFIER 0x000c03
> >
> > HDMI_IDENTIFIER sounds really generic. Per
From: Paulo Zanoni
If LCPLL is disabled, there's a chance we might be in package C8 state
or deeper, and we'll get a hard hang when restoring LCPLL (also, a red
led lights up on my motherboard). So grab the force_wake, which will
get us out of RC6 and, as a consequence, out of PC8+ (since we need
The code directly uses the registers and ring->mmio_base.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_ringbuffer.h | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 5e6be84..432ad53 100
This define hasn't been used since:
commit cfdf1fa23f4074c9f8766dc67a928bbf680b1ac9
Author: Kristian Høgsberg
Date: Wed Dec 16 15:16:16 2009 -0500
drm/i915: Implement IS_* macros using static tables
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/i915_drv.h | 1 -
1 file
The code using this was removed in:
commit 88f23b8fa3e6357c423af24ec31c661fc12f884b
Author: Chris Wilson
Date: Sun Dec 5 15:08:31 2010 +
drm/i915: Avoid using PIPE_CONTROL on Ironlake
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/i915_drv.h | 2 --
1 file changed, 2
This define hasn't been used since:
commit 652c393a3368af84359da37c45afc35a91144960
Author: Jesse Barnes
Date: Mon Aug 17 13:31:43 2009 -0700
drm/i915: add dynamic clock frequency control
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/i915_drv.h | 2 --
1 file changed, 2
A small series to remove a few of those. I guess it's debatable if the
i915_READ_* for ring registers should be removed or the code ported to always
use those macros.
--
Damien
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.fre
On Mon, Aug 19, 2013 at 01:18:09PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> This patch allows PC8+ states on Haswell. These states can only be
> reached when all the display outputs are disabled, and they allow some
> more power savings.
>
> The fact that the graphics device is allowi
On Mon, Aug 19, 2013 at 01:18:07PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> If LCPLL is disabled, there's a chance we might be in package C8 state
> or deeper, and we'll get a hard hang when restoring LCPLL (also, a red
> led lights up on my motherboard). So grab the force_wake, which
On Sun, 18 Aug 2013 21:09:59 +0200
Daniel Vetter wrote:
> On Mon, Apr 08, 2013 at 05:50:07PM -0300, Paulo Zanoni wrote:
> > Hi
> >
> > 2013/3/28 Jesse Barnes :
> > > The existing code was trying different vswing and preemphasis settings
> > > in the wrong place, and wasn't trying them enough. S
The existing code was trying different vswing and preemphasis settings
in the wrong place, and wasn't trying them enough. So add a loop to
walk through them, properly disabling FDI TX and RX in between if a
failure is detected.
v2: remove unneeded reg writes, add delays around bit lock checks (Je
From: Paulo Zanoni
This test chekcs our code that enables Package C8+. The environment
requirements for this test are quite complicated:
- The machine needs to be properly configured to reach PC8+ when
possible, which means all the power management policies and device
drivers must be pr
From: Paulo Zanoni
We currently only enter PC8+ after all its required conditions are
met, there's no rendering, and we stay like that for at least 5
seconds.
I chose "5 seconds" because this value is conservative and won't make
us enter/leave PC8+ thousands of times after the screen is off: som
From: Paulo Zanoni
This should be working, so enable it by default. Also easy to revert.
v2: Rebase, s/allow/enable/.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_drv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drive
From: Paulo Zanoni
Make it print the value of the variables on the PC8 struct.
v2: Update to recent renames and add the new fields.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_debugfs.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/gpu/dr
From: Paulo Zanoni
This patch allows PC8+ states on Haswell. These states can only be
reached when all the display outputs are disabled, and they allow some
more power savings.
The fact that the graphics device is allowing PC8+ doesn't mean that
the machine will actually enter PC8+: all the othe
From: Paulo Zanoni
This was causing WARNs in one machine, so instead of trying to guess
exactly which hotplug bits should exist, just do the test on the
non-HPD bits. We don't care about the state of the hotplug bits, we
just care about the others, that need to be 1.
Signed-off-by: Paulo Zanoni
From: Paulo Zanoni
If LCPLL is disabled, there's a chance we might be in package C8 state
or deeper, and we'll get a hard hang when restoring LCPLL (also, a red
led lights up on my motherboard). So grab the force_wake, which will
get us out of RC6 and, as a consequence, out of PC8+ (since we need
h new besides some bug fixing and an additional module option
to allow some tuning on how often we reach PC8+.
If you want to test everything, please check the c8-wip-20130819 branch of my
Kernel tree: http://cgit.freedesktop.org/~pzanoni/linux/?h=c8-wip-20130819 .
Thanks,
Paulo
Paulo Zanoni (6
On Thu, Aug 15, 2013 at 04:45:56PM +0200, Thierry Reding wrote:
> On Wed, Aug 14, 2013 at 06:19:09PM +0100, Damien Lespiau wrote:
> > Just like:
> >
> > Author: Damien Lespiau
> > Date: Mon Aug 12 11:53:24 2013 +0100
> >
> > video/hdmi: Don't let the user of this API create invalid i
HDMI_IDENTIFIER was felt too generic, rename it to what it is, the IEEE
OUI corresponding to HDMI Licensing, LLC.
http://standards.ieee.org/develop/regauth/oui/oui.txt
Cc: Thierry Reding
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_edid.c | 2 +-
drivers/video/hdmi.c | 4 ++--
i
With all the common infoframe bits now in place, we can finally write
the vendor specific infoframes in our driver.
Signed-off-by: Damien Lespiau
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 2 ++
drivers/gpu/drm/i915/intel_hdmi.c | 28
2 file
This can then be used by DRM drivers to setup their vendor infoframes.
v2: Fix hmdi typo (Simon Farnsworth)
v3: Adapt to the hdmi_vendor_infoframe rename
Signed-off-by: Damien Lespiau
Reviewed-by: Simon Farnsworth
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 36
We just got rid of the version of hdmi_vendor_infoframe that had a byte
array for anyone to poke at. It's now time to shuffle around the naming
of hdmi_hdmi_infoframe to make hdmi_vendor_infoframe become the HDMI
vendor specific structure.
Cc: Thierry Reding
Signed-off-by: Damien Lespiau
---
dr
With this last bit, hdmi_infoframe_pack() is now able to pack any
infoframe we support.
At the same time, because it's impractical to make two commits out of
this, we get rid of the version that encourages the open coding of the
vendor infoframe packing. We can do so because the only user of this
We'll need the HDMI OUI for the HDMI vendor infoframe data, so let's
move the DRM one to hdmi.h, might as well use the hdmi header to store
some hdmi defines.
(Note that, in fact, infoframes are part of the CEA-861 standard, and
only the HDMI vendor specific infoframe is special to HDMI, but
detai
I just wrote the bits to define and pack HDMI vendor specific infoframe.
Port the host1x driver to use those so I can refactor the infoframe code
a bit more.
This changes the length of the infoframe payload from 6 to 5, which is
enough for the "frame packing" stereo format.
v2: Pimp up the commit
Provide the same programming model than the other infoframe types.
The generic _pack() function can't handle those yet as we need to move
the vendor OUI in the generic hdmi_vendor_infoframe structure to know
which kind of vendor infoframe we are dealing with.
v2: Fix the value of Side-by-side (ha
HDMI 1.4 adds 4 "4k x 2k" modes in the the CEA vendor specific block.
With this commit, we now parse this block and expose the 4k modes that
we find there.
v2: Fix the "4096x2160" string (nice catch!), add comments about
do_hdmi_vsdb_modes() arguments and make it clearer that offset is
re
Just like:
Author: Damien Lespiau
Date: Mon Aug 12 11:53:24 2013 +0100
video/hdmi: Don't let the user of this API create invalid infoframes
But this time for the horizontal/vertical bar data present bits.
Signed-off-by: Damien Lespiau
Reviewed-by: Ville Syrjälä
---
drivers/video
To set the active aspect ratio value in the AVI infoframe today, you not
only have to set the active_aspect field, but also the active_info_valid
bit. Out of the 1 user of this API, we had 100% misuse, forgetting the
_valid bit. This was fixed in:
Author: Damien Lespiau
Date: Tue Aug 6 20:3
v2: Fix hmdi typo (Simon Farnsworth, Ville Syrjälä)
Suggested-by: Ville Syrjälä
Signed-off-by: Damien Lespiau
Reviewed-by: Ville Syrjälä
Reviewed-by: Simon Farnsworth
---
drivers/gpu/drm/drm_edid.c | 68 ++
1 file changed, 62 insertions(+), 6 deleti
A few styles issues have crept in here, fix them before touching this
code again.
v2: constify arguments that can be (Ville Syrjälä)
v3: constify, but better (Ville Syrjälä)
Signed-off-by: Damien Lespiau
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 12 +++-
1 file change
This function is only used inside drm_edid.c.
Signed-off-by: Damien Lespiau
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 5 ++---
include/drm/drm_crtc.h | 1 -
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid
Follow up on v3:
http://lists.freedesktop.org/archives/dri-devel/2013-August/043696.html
Changes between v3 and v4:
- Future proof the sending of 3D_Ext_Data
- Renamed struct hdmi_hdmi_infoframe to hdmi_vendor_infoframe (by, in turn,
renaming the hdmi_vendor_infoframe enum to hdmi_vendor
Ping.
Пятница, 16 августа 2013, 14:31 +04:00 от Ибрагимов
Ринат:
> libvdpau uses second DRI driver name to determine which VDPAU driver
> to use. This patch will allow libvdpau choose libvdpau_i965.so on systems
> with Intel GPUs, libvdpau_nvidia.so on those with nVidia ones, and so on.
> I'm exp
On Thu, Aug 15, 2013 at 05:12:00PM +0200, Thierry Reding wrote:
> On Wed, Aug 14, 2013 at 06:19:12PM +0100, Damien Lespiau wrote:
> [...]
> > +#define HDMI_IDENTIFIER 0x000c03
>
> HDMI_IDENTIFIER sounds really generic. Perhaps HDMI_INFOFRAME_OUI_HDMI?
This identifier is not infoframe specific, it
On Mon, Aug 19, 2013 at 10:49 AM, Mika Kuoppala
wrote:
>>> Mika pasted an oops on #intel-gfx. Chris and Ville had is solved before
>>> I woke up. It's pretty strange, Chris said the bug existed in the
>>> original ppgtt2 branch (I'm too lazy to check). In many runs for myself,
>>> and QA, I'd not
I always wondered how the pipe config compare could work with an
all-zero mode. Now I've finally realized that we read out the crtc
timings, but drm_mode_debug_printmodeline prints out the original
mode, which we don't reconstruct. And which is also rather irrelevant
when computing the pipe config.
Daniel Vetter writes:
> On Mon, Aug 19, 2013 at 12:35 AM, Ben Widawsky wrote:
>> On Sun, Aug 18, 2013 at 07:26:57PM +0200, Daniel Vetter wrote:
>>> On Fri, Aug 16, 2013 at 11:31:12PM +0100, Chris Wilson wrote:
>>> > On Fri, Aug 16, 2013 at 01:29:33PM -0700, Ben Widawsky wrote:
>>> > > The vma wi
On Mon, Aug 19, 2013 at 09:53:23AM +0300, Dan Carpenter wrote:
> We sometimes call i915_vma_unbind() inside the loop and that can free
> the vma.
Oh. That is bad. The vma needs to be pinned here to prevent it being freed as
otherwise we lose track of it during the execbuffer.
Ben?
-Chris
--
Chri
On Mon, Aug 19, 2013 at 09:59:14AM +0300, Dan Carpenter wrote:
> Hello Ben Widawsky,
>
> Here is another use after free warning. It's some new static checker
> stuff that I haven't pushed because it has lots of false postives.
>
> The patch f7795b1d0b47: "drm/i915: Switch eviction code to use vm
Hello Ben Widawsky,
Here is another use after free warning. It's some new static checker
stuff that I haven't pushed because it has lots of false postives.
The patch f7795b1d0b47: "drm/i915: Switch eviction code to use vmas"
from Aug 14, 2013, leads to the following warning:
"drivers/gpu/drm/i9
We sometimes call i915_vma_unbind() inside the loop and that can free
the vma.
Signed-off-by: Dan Carpenter
---
Static checker stuff. Untested.
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 9b3b5f8..5249735 100644
--- a/drivers/gpu/d
On Fri, Aug 16, 2013 at 9:31 PM, Ian Romanick wrote:
> On 08/14/2013 01:19 AM, Sedat Dilek wrote:
>>
>> AFAICS, there are more updates needed to be in sync with recent
>> kernel-drm.
>>
>> I fell over the misspelling when digging into an issue in Linux-next.
>> The spelling should be consistent in
On Mon, Aug 19, 2013 at 12:35 AM, Ben Widawsky wrote:
> On Sun, Aug 18, 2013 at 07:26:57PM +0200, Daniel Vetter wrote:
>> On Fri, Aug 16, 2013 at 11:31:12PM +0100, Chris Wilson wrote:
>> > On Fri, Aug 16, 2013 at 01:29:33PM -0700, Ben Widawsky wrote:
>> > > The vma will [possibly] be destroyed dur
55 matches
Mail list logo
