It never quite worked despite the numerous workarounds, yet I still see
people trying to use this hardware and filing bug reports. As we no
longer even try to implement the workarounds, since 6a233c78878
(drm/i915/ringbuffer: kill snb blt workaround), simply disable the ring.
v2: Add a message to
On Thu, 05 Jul 2012 14:57:41 -0700, Eric Anholt wrote:
> Chris Wilson writes:
>
> > It never quite worked despite the numerous workarounds, yet I still see
> > people trying to use this hardware and filing bug reports. As we no
> > longer even try to implement the workarounds, since 6a233c78878
Chris Wilson writes:
> It never quite worked despite the numerous workarounds, yet I still see
> people trying to use this hardware and filing bug reports. As we no
> longer even try to implement the workarounds, since 6a233c78878
> (drm/i915/ringbuffer: kill snb blt workaround), simply disable t
On Thu, 5 Jul 2012 15:02:17 +0100
Chris Wilson wrote:
> There is little point waking up every 10ms to service an interrupt which
> we then promptly ignore. So only program the the PMIER to enable
> interrupts for those events which we do handle, not all of them!
>
> Signed-off-by: Chris Wilson
It never quite worked despite the numerous workarounds, yet I still see
people trying to use this hardware and filing bug reports. As we no
longer even try to implement the workarounds, since 6a233c78878
(drm/i915/ringbuffer: kill snb blt workaround), simply disable the ring.
Signed-off-by: Chris
Hi,
I recently bought a HP Elitebook 2540p, which is arrandale based and
features a displayport connector (VGA as well).
Because quality over VGA is quite bad with my Asus VW266H monitor
(1920x1200; vga, hdmi, dvi) I bought a displayport<-->hdmi cable so I
could use the digital output.
However, a
On Thu, Jul 05, 2012 at 10:10:10AM +0100, Chris Wilson wrote:
> + if (INTEL_INFO(dev)->gen >= 4 && (x|y) & ~4095) {
> + DRM_ERROR("CRTC offset too larget (%d, %d)\n", x, y);
larget?
OG.
___
Intel-gfx mailing list
Intel-gfx@lists.freede
On Thu, 5 Jul 2012 19:22:37 +0200, Olivier Galibert wrote:
> On Thu, Jul 05, 2012 at 10:10:10AM +0100, Chris Wilson wrote:
> > + if (INTEL_INFO(dev)->gen >= 4 && (x|y) & ~4095) {
> > + DRM_ERROR("CRTC offset too larget (%d, %d)\n", x, y);
>
> larget?
Not even a humorous typo. Daniel
Having had to dive into the bspec to understand what each stage of the
workaround meant, and how that the ring broadcasting IDLE corresponded
with the GT powering down the ring (i.e. rc6) add comments to aide
the next reader.
And since the register "is used to control all aspects of PSMI and power
Having had to dive into the bspec to understand what each stage of the
workaround meant, and how that the ring broadcasting IDLE corresponded
with the GT powering down the ring (i.e. rc6) add comments to aide
the next reader.
And since the register "is used to control all aspects of PSMI and power
There is little point waking up every 10ms to service an interrupt which
we then promptly ignore. So only program the the PMIER to enable
interrupts for those events which we do handle, not all of them!
Signed-off-by: Chris Wilson
Cc: Jesse Barnes
Cc: Eugeni Dodonov
Cc: Ben Widawsky
---
drive
On Thu, Jul 05, 2012 at 09:58:53AM -0300, Paulo Zanoni wrote:
> 2012/7/4 Eugeni Dodonov :
> > This is required for a stable FDI connection.
> >
> > v2: fix and simplify the FDI_RX_MISC bits as noticed by Paulo Zanoni.
> >
> > CC: Paulo Zanoni
>
> Reviewed-by: Paulo Zanoni
Patch queued for -next,
On Thu, Jul 05, 2012 at 09:50:24AM +0200, Daniel Vetter wrote:
> We already have this pattern at quite a few places, and moving part of
> the modeset helper stuff into the driver will add more.
>
> v2: Don't clobber the crtc struct name with the macro parameter ...
>
> v3: Convert two more places
2012/7/4 Eugeni Dodonov :
> This is required for a stable FDI connection.
>
> v2: fix and simplify the FDI_RX_MISC bits as noticed by Paulo Zanoni.
>
> CC: Paulo Zanoni
Reviewed-by: Paulo Zanoni
> Signed-off-by: Eugeni Dodonov
> ---
> drivers/gpu/drm/i915/i915_reg.h | 3 +++
> drivers/gpu/dr
On Thu, Jul 05, 2012 at 01:29:36PM +0200, Daniel Vetter wrote:
> On Thu, May 24, 2012 at 09:01:24PM +0200, Daniel Vetter wrote:
> > On Thu, May 24, 2012 at 09:49:15PM +0300, Ville Syrjälä wrote:
> > > On Thu, May 24, 2012 at 11:31:32AM -0700, Jesse Barnes wrote:
> > > > On Thu, 24 May 2012 21:08:58
On Thu, Jul 05, 2012 at 01:27:47PM +0200, Daniel Vetter wrote:
> On Thu, May 24, 2012 at 09:08:55PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Make sure the the framebuffer stride is smaller than the maximum
> > accepted by any plane.
> >
> > Also when using a ti
On Thu, Jul 05, 2012 at 11:29:10AM +0100, Chris Wilson wrote:
> On Thu, 5 Jul 2012 12:17:30 +0200, Daniel Vetter
> wrote:
> > The tileoffset register only supports a limited offset in x/y of 4096,
> > so for giant screen configuration with a shared fb we wrap around.
> >
> > Fix this by computi
On Thu, May 24, 2012 at 09:08:59PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> MI display flips can't handle some changes in the framebuffer
> format or layout. Return an error in such cases.
>
> Signed-off-by: Ville Syrjälä
Queued for -next, thanks for the patch. I've
On Thu, May 24, 2012 at 09:01:24PM +0200, Daniel Vetter wrote:
> On Thu, May 24, 2012 at 09:49:15PM +0300, Ville Syrjälä wrote:
> > On Thu, May 24, 2012 at 11:31:32AM -0700, Jesse Barnes wrote:
> > > On Thu, 24 May 2012 21:08:58 +0300
> > > ville.syrj...@linux.intel.com wrote:
> > >
> > > > From:
On Thu, May 24, 2012 at 09:08:56PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Zero initialize the mode_cmd structure when creating the kernel
> framebuffer. Avoids having uninitialized data in offsets[0] for
> instance.
>
> Signed-off-by: Ville Syrjälä
Queued for -nex
On Thu, May 24, 2012 at 09:08:55PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Make sure the the framebuffer stride is smaller than the maximum
> accepted by any plane.
>
> Also when using a tiled memory make sure the object stride matches
> the framebuffer stride.
>
>
On Thu, 5 Jul 2012 12:17:30 +0200, Daniel Vetter
wrote:
> The tileoffset register only supports a limited offset in x/y of 4096,
> so for giant screen configuration with a shared fb we wrap around.
>
> Fix this by computing a linear offset in tiles (pages) and only use
> the tileoffset register
On Thu, 5 Jul 2012 12:17:30 +0200, Daniel Vetter
wrote:
> The tileoffset register only supports a limited offset in x/y of 4096,
> so for giant screen configuration with a shared fb we wrap around.
>
> Fix this by computing a linear offset in tiles (pages) and only use
> the tileoffset register
The tileoffset register only supports a limited offset in x/y of 4096,
so for giant screen configuration with a shared fb we wrap around.
Fix this by computing a linear offset in tiles (pages) and only use
the tileoffset register to offset within the tile.
Signed-Off-by: Daniel Vetter
---
drive
To avoid recomputing the display framebuffer offset on gen2/3
pageflips. This is also prep work to do similar trickery on gen4+
Also:
- kill "Start", such upper-case remnants from the ddx must surely die.
- rename "Offset" to linear_offset, to make it clearer that on gen4+
this is only used by t
On gen4+, we program the CRTC offset into the DSPTILEOFF register, which
is limited to 12-bits of integer precision in both the x and the y axes.
Programming a value larger than or equal to 4096 results in a wraparound
of the CRTC location and a distorted output. This is undesirable, so
abort the o
We already have this pattern at quite a few places, and moving part of
the modeset helper stuff into the driver will add more.
v2: Don't clobber the crtc struct name with the macro parameter ...
v3: Convert two more places noticed by Paulo Zanoni.
Reviewed-by: Paulo Zanoni
Signed-Off-by: Daniel
On Wed, Jul 04, 2012 at 09:54:09PM +0100, Chris Wilson wrote:
> On Wed, 4 Jul 2012 22:18:38 +0200, Daniel Vetter
> wrote:
> > Hi all,
> >
> > I took me a while to see the real issues Chris has been complaining about,
> > but I
> > think the reworked patches take them all into account now. The
Dear Sirs,
We have an issue on Chrome OS.
The issue is that we can’t apply high resolution picture as desktop background.
Could you please help to check if Intel VGA driver can support high resolution
picture as desktop background?
Thanks~
BRs,
Joyce
_
On Thu, Jul 05, 2012 at 01:00:10AM +0100, Chris Wilson wrote:
> On Wed, 4 Jul 2012 20:07:02 -0300, Eugeni Dodonov
> wrote:
> > Noticed by Chris Wilson, this got through in the last iteration of the rps
> > for Haswell patch.
>
> That's the fix. Hopefully there is enough time for Daniel to rewri
On Fri, Jun 29, 2012 at 03:39:32PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Only bits 30:28, bit 31 is PIPE_DDI_FUNC_ENABLE.
>
> Signed-off-by: Paulo Zanoni
Queued for -next, thanks for the patch.
-Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
On Wed, Jul 04, 2012 at 08:19:24PM -0300, Eugeni Dodonov wrote:
> On 07/04/2012 02:41 PM, Paulo Zanoni wrote:
> > 2012/6/28 Eugeni Dodonov :
> >> This pollutes dmesg output even if we do not have FBC for the device, so
> >> move the DRM_DEBUG_KMS statement lower.
> >>
> >> v2: just kill the message
32 matches
Mail list logo
