On Wed, May 30, 2012 at 11:31 PM, Dave Jones wrote:
> On this hardware:
>
> 00:02.0 VGA compatible controller: Intel Corporation 82945G/GZ Integrated
> Graphics Controller (rev 02)
>
> I get this every boot with Linus current tree (up to
> af56e0aa35f3ae2a4c1a6d1000702df1dd78cb76)
Just a quick
On Wed, May 30, 2012 at 01:41:28PM -0700, Ben Widawsky wrote:
> On Wed, 30 May 2012 20:21:33 +0200
> Daniel Vetter wrote:
>
> > Both need to do the same dance (or at least should). Some slight
> > changes:
> > - busy_ioctl now unconditionally checks for olr. Before emitting a
> > require flush
On Mon, May 28, 2012 at 04:43:00PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> On IVB and older, we basically have two registers: the control and the
> data register. We write a few consecutitve times to the control
> register, and we need these writes to arrive exactly in the specified
>
On Wed, 30 May 2012 20:21:33 +0200
Daniel Vetter wrote:
> Both need to do the same dance (or at least should). Some slight
> changes:
> - busy_ioctl now unconditionally checks for olr. Before emitting a
> require flush would have prevent the olr check and hence required a
> second call to the
Both need to do the same dance (or at least should). Some slight
changes:
- busy_ioctl now unconditionally checks for olr. Before emitting a
require flush would have prevent the olr check and hence required a
second call to the busy ioctl to really emit the request.
- the timeout wait now also
On 05/30/2012 12:15 PM, Daniel Vetter wrote:
Already discovered in
commit 5a117db77e47e3946d1aaa7ce8deafafd9d76746
Author: Eugeni Dodonov
Date: Thu Jan 5 09:34:29 2012 -0200
drm/i915: there is no pipe CxSR on ironlake
but we've failed to rip out the code from the ironlake specific code.
Already discovered in
commit 5a117db77e47e3946d1aaa7ce8deafafd9d76746
Author: Eugeni Dodonov
Date: Thu Jan 5 09:34:29 2012 -0200
drm/i915: there is no pipe CxSR on ironlake
but we've failed to rip out the code from the ironlake specific code.
Cc: Eugeni Dodonov
Signed-Off-by: Daniel Vet
Am Mittwoch, den 30.05.2012, 13:52 +0200 schrieb Daniel Vetter:
Typo in »change« in the commit message.
> We should only frob adjusted_mode. This is in preparation of
> a massive patch by Laurent Pinchart to make the mode argument
> const.
>
> After the prevous prep patch to use adjusted_mode->c
Instead of abusing into mode->clock, because we should touch that
one at all. First prep step to constify the mode argument to the
intel_dp_mode_fixup function.
The next patch will stop us from modifying mode->clock.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 16 +
On Wed, 30 May 2012 14:52:26 +0200, Daniel Vetter
wrote:
> Jesse extracted this nice helper in his i9xx_crtc_mode_set refactor,
> but we have the identical code in ironlake_ccrtc_mode_set. And that
> function is huge, so extracting some code full of magic numbers is
> always nice.
>
> Noticed wh
Jesse extracted this nice helper in his i9xx_crtc_mode_set refactor,
but we have the identical code in ironlake_ccrtc_mode_set. And that
function is huge, so extracting some code full of magic numbers is
always nice.
Noticed while trying to get a handle on our dp clock code.
Signed-Off-by: Daniel
On Wed, May 30, 2012 at 01:18:35PM +0100, Chris Wilson wrote:
> On Wed, 30 May 2012 13:52:02 +0200, Daniel Vetter
> wrote:
> > ... instead of changing mode->clock, which we should leave as-is.
> >
> > We only touch that if it's a panel, and then adjusted mode->clock
> > equals adjusted_mode->clo
On Wed, 30 May 2012 13:52:02 +0200, Daniel Vetter
wrote:
> ... instead of changing mode->clock, which we should leave as-is.
>
> We only touch that if it's a panel, and then adjusted mode->clock
> equals adjusted_mode->clock. Outside of intel_dp.c we only use
> ajusted_mode->clock in the mode_se
On Mon, May 28, 2012 at 04:43:01PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> This function is supposed to be used at mode set time, so prevent
> against future mistakes by adding a WARN().
>
> Problems when calling it when the HDMI port is enabled:
> - It may disable sending DIPs (on
We should only frob adjusted_mode. This is in preparation of
a massive patch by Laurent Pinchart to make the mode argument
const.
After the prevous prep patch to use adjusted_mode->clock instead of
mode->clock the only thing left is to clean up things a bit. I've
opted to pass in an adjust_mode pa
... instead of changing mode->clock, which we should leave as-is.
We only touch that if it's a panel, and then adjusted mode->clock
equals adjusted_mode->clock. Outside of intel_dp.c we only use
ajusted_mode->clock in the mode_set functions.
Within intel_dp.c we only use it to calculate the dp di
On Wed, May 30, 2012 at 11:58:43AM +0100, Chris Wilson wrote:
> On Wed, 30 May 2012 12:28:04 +0200, Daniel Vetter
> wrote:
> > We should only frob adjusted_mode. This is in preparation of
> > a massive patch by Laurent Pinchart to make the mode argument
> > const.
> >
> > The only thing we actua
On Wed, May 30, 2012 at 11:27:46AM +0100, Chris Wilson wrote:
> On Wed, 30 May 2012 12:31:58 +0200, Daniel Vetter
> wrote:
> > Let's be a bit more paranoid here.
> >
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/i915/intel_display.c |6 ++
> > 1 files changed, 6 insertio
On Wed, 30 May 2012 12:28:04 +0200, Daniel Vetter
wrote:
> We should only frob adjusted_mode. This is in preparation of
> a massive patch by Laurent Pinchart to make the mode argument
> const.
>
> The only thing we actually touch is mode->clock, but only if
> it's a panel. And in that case we al
On Wed, 30 May 2012 12:31:57 +0200, Daniel Vetter
wrote:
> Bspec Vol 3, Part 3, Section 3.8.1.1, bit 30:
>
> "[DevIBX] Writing to this bit only takes effect when port is enabled.
> Due to hardware issue it is required that this bit be cleared when port
> is disabled. To clear this bit software m
On Wed, 30 May 2012 12:31:56 +0200, Daniel Vetter
wrote:
> Instead of checking for !CPT, check for IBX to make it clearer that
> this is a IBX-specific workaround. No functional change because we
> smash the PPT PCH into the HAS_PCH_CPT check and atm DP isn't enabled
> on the haswell LPT PCH yet.
Il 30/05/2012 04:39, Matt Turner ha scritto:
fyi, I just filed a request for gstreamer-vaapi yesterday:
https://bugs.gentoo.org/show_bug.cgi?id=418077
Well done, I opened a bug for this issue too:
https://bugs.freedesktop.org/show_bug.cgi?id=50390
In the meantime you can find a gst-plugins-vaa
On Wed, 30 May 2012 12:31:58 +0200, Daniel Vetter
wrote:
> Let's be a bit more paranoid here.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_display.c |6 ++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
We should only frob adjusted_mode. This is in preparation of
a massive patch by Laurent Pinchart to make the mode argument
const.
The only thing we actually touch is mode->clock, but only if
it's a panel. And in that case we also set adjusted_mode->clock
to the same value. All the generic code alr
Let's be a bit more paranoid here.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 3c71850..a9bc673 100644
--- a/
Bspec Vol 3, Part 3, Section 3.8.1.1, bit 30:
"[DevIBX] Writing to this bit only takes effect when port is enabled.
Due to hardware issue it is required that this bit be cleared when port
is disabled. To clear this bit software must temporarily enable this
port on transcoder A."
Unfortunately the
Instead of checking for !CPT, check for IBX to make it clearer that
this is a IBX-specific workaround. No functional change because we
smash the PPT PCH into the HAS_PCH_CPT check and atm DP isn't enabled
on the haswell LPT PCH yet.
See Bspec Vol 3, Part 3, Section 4.[3-5].1 about DP[BCD], bit 30
But isn't this a decision to be made by the mainline maintainers?
Obviously, but why shouldn't they reject a widely requested feature when
the code is mature enough?
There was nothing ever rejected, as no patch was ever recieved. So I was
told on the MPlayer-users mailing list. MPlayer deve
28 matches
Mail list logo
