On Sat, 28 Sep 2013, Jesse Barnes wrote:
> On VLV/BYT, backlight controls a per-pipe, so when adjusting the
> backlight we need to pass the correct info. So make the externally
> visible backlight functions take a connector argument, which can be used
> internally to figure out the pipe backlight
On Sat, 28 Sep 2013, Jesse Barnes wrote:
> With the connector and pipe passed around, we can now set the backlight
> on the right pipe on VLV/BYT.
>
> Signed-off-by: Jesse Barnes
> ---
> drivers/gpu/drm/i915/i915_reg.h| 10 ++
> drivers/gpu/drm/i915/intel_panel.c | 65
>
On Mon, Sep 30, 2013 at 10:33 AM, Jani Nikula
wrote:
> Anyway, I think you need to add per pipe save/restore to
> i915_save_display/i915_restore_display too.
I'm trying (very slowly at that) to move the register save/restore
stuff out of there into more suitable places. Either we should now
what
Today's linux-next merge of the drm-intel tree got conflicts in
drivers/gpu/drm/i915/intel_display.c
I fixed it up (see below). Please check if the resolution looks correct.
Thanks,
Thierry
---
diff --cc drivers/gpu/drm/i915/intel_display.c
index e5822e7,cbbdab6..76870f0
--- a/drivers/gp
On Mon, Sep 30, 2013 at 1:26 PM, Thierry Reding
wrote:
> Today's linux-next merge of the drm-intel tree got conflicts in
>
> drivers/gpu/drm/i915/intel_display.c
>
> I fixed it up (see below). Please check if the resolution looks correct.
Looks good.
-Daniel
--
Daniel Vetter
Software Eng
On Mon, Sep 30, 2013 at 11:18:28AM +0300, Jani Nikula wrote:
> On Sat, 28 Sep 2013, Jesse Barnes wrote:
> > On VLV/BYT, backlight controls a per-pipe, so when adjusting the
> > backlight we need to pass the correct info. So make the externally
> > visible backlight functions take a connector argu
On Mon, Sep 30, 2013 at 2:15 PM, Ville Syrjälä
wrote:
> I was discussing things a bit with Jani, and I'll repeat my thoughts
> here for others to see. Feel free to kick me if I get things totally
> wrong as I don't know the backlight code, nor do I really want to.
>
> We may need to handle backlig
On Fri, Sep 27, 2013 at 06:13:11PM +0300, Ville Syrjälä wrote:
[snip]
> OK, so it looks like I didn't find anything really wrong with this
> patch itself, and now the code matches the spec much better, so:
> Reviewed-by: Ville Syrjälä
Queued for -next, thanks for the patch. I agree with Ville's
When booting with i915.fastboot=1, we always take tha code path and end
up undoing what we're trying to do with adjusted_mode.
Hopefully, as the fastboot hardware readout code is using adjusted_mode
as well, it should be equivalent.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_d
Instead of it just being on the mailing list, let's put Jesse's
explanation next to the code in question.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_display.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
Here's a slightly improved version of the VGA stop_machine() patch.
The main new thing is switching ctg/elk over to port IO. That appears to have
cured the hangs from Chris's lid_notify riddled ctg machine.
What I'd really like is some kind of tested-by note from Alex Williamson to
make sure I di
From: Ville Syrjälä
We have several problems with out VGA handling:
- We try to use the GMCH control VGA disable bit even though it may
be locked
- If we manage to disable VGA throuh GMCH control, we're no longer
able to correctly disable the VGA plane
- Taking part in the VGA arbitration is
I was fiddling about with the sprite code a bit and managed to collect a bunch
of fixes and cleanups. Some of there originated from my watermark work,
but as I now have a bit more of them I figured it's high time to post them,
___
Intel-gfx mailing list
From: Ville Syrjälä
If the primary gets marked as disabled while the pipe is off for
instance, we should still re-enable it when the pipe is turned on,
unless the sprite covers it fully also in that configuration.
Unfortunately we do the plane visibility checks only in the sprite code,
which is e
From: Ville Syrjälä
We allow cursors to be set up when the pipe is disabled. Do the same for
sprites as well.
We need to be somewhat careful with the primary disable logic as we
don't want to accidentally enable the primary plane on a disabled pipe.
Signed-off-by: Ville Syrjälä
---
drivers/gp
From: Ville Syrjälä
If the pipe is disabled there's no point in writing the sprite
registers. If necessary, they will get written when the pipe gets
enabled.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_sprite.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletio
From: Ville Syrjälä
Let's not use goto when a simple if suffices. This is not error handling
code or anything, so the goto looks out of place.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_sprite.c | 21 +
1 file changed, 9 insertions(+), 12 deletions(-)
diff
From: Ville Syrjälä
If the setplane operation fails, we shouldn't save the user's requested
plane coordinates. Since we adjust the coordinates during the clipping
process, make a copy of the originals, and once the operation has
succeeded save them for later reuse when the plane gets re-enabled.
From: Ville Syrjälä
IPS should be OK as long as one plane is enabled on the pipe, but
it does seem to cause problems when going between primary only and
sprite only.
This needs more investigations, but for now just disable IPS whenever
the primary plane is disabled.
Signed-off-by: Ville Syrjälä
On Mon, Sep 30, 2013 at 05:08:31PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> We have several problems with out VGA handling:
> - We try to use the GMCH control VGA disable bit even though it may
> be locked
> - If we manage to disable VGA throuh GMCH control, we're n
From: Ville Syrjälä
Disable fbc before disabling the primary plane, and enable fbc after
the primary plane has been enabled again.
Also use intel_disable_fbc() to disable FBC to avoid the pointless
overhead of intel_update_fbc(), and especially avoid having to clean
up and set up the stolen mem
From: Ville Syrjälä
We used to call the entire intel specific update_plane hook while
holding struct_mutex. Actually we only need to hold struct_mutex while
pinning/unpinning the obj. The plane state itself is protected by the
kms locks, and as the object is pinned we can dig out the offset and
t
On Mon, Sep 30, 2013 at 05:23:57PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> If the primary gets marked as disabled while the pipe is off for
> instance, we should still re-enable it when the pipe is turned on,
> unless the sprite covers it fully also in that configura
From: Ville Syrjälä
Move the variable initialization to where the variables are declared,
and kill a pointless to_intel_crtc() cast when we already have the
casted pointer.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_sprite.c | 14 +-
1 file changed, 5 insertions(+)
On Mon, Sep 30, 2013 at 03:24:37PM +0100, Chris Wilson wrote:
> On Mon, Sep 30, 2013 at 05:08:31PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > We have several problems with out VGA handling:
> > - We try to use the GMCH control VGA disable bit even though it may
>
On Mon, 2013-09-30 at 17:08 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> We have several problems with out VGA handling:
> - We try to use the GMCH control VGA disable bit even though it may
> be locked
> - If we manage to disable VGA throuh GMCH control, we're no longe
From: Ville Syrjälä
Add some helper functions to move drm_rects between different rotated
coordinate spaces. One function does the forward transform and
another does the inverse.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_rect.c | 140 +
in
Recently some people from inside Intel have showed some interest in 180
degree plane rotation. To avoid a huge mess, I decided that I should
implement the feature properly.
So I snatched the rotation property from omapdrm, and moved some of the
code into drm_crtc.c, added a bunch of helper stuff t
From: Ville Syrjälä
drm_rotation_simplify() can be used to eliminate unsupported rotation
flags. It will check if any unsupported flags are present, and if so
it will modify the rotation to an alternate form by adding 180 degrees
to rotation angle, and flipping the reflect x and y bits. The hope
From: Ville Syrjälä
The rotation property stuff should be standardized among all drivers.
Move the bits to drm_crtc.h from omap_drv.h.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/omapdrm/omap_drv.h | 7 ---
include/drm/drm_crtc.h | 8
2 files changed, 8 insertions
From: Ville Syrjälä
Make drm_property_create_bitmask() a bit more generic by allowing the
caller to specify which bits are in fact supported. This allows multiple
callers to use the same enum list, but still create different versions
of the same property with different list of supported bits.
Si
From: Ville Syrjälä
Use the new drm_mode_create_rotation_property() in omapdrm.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/omapdrm/omap_plane.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c
b/drivers/gpu/drm/o
From: Ville Syrjälä
Add a function to create a standards compliant rotation property.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_crtc.c | 18 ++
include/drm/drm_crtc.h | 2 ++
2 files changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gp
From: Ville Syrjälä
The sprite planes (in fact all display planes starting from gen4)
support 180 degree rotation. Add the relevant low level bits to the
sprite code to make use of that feature.
The upper layers are not yet plugged in.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i91
From: Ville Syrjälä
Propagate the error from intel_update_plane() up through
intel_plane_restore() to the caller. This will be used for
rollback purposes when setting properties fails.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_drv.h| 2 +-
drivers/gpu/drm/i915/intel_spri
From: Ville Syrjälä
Sprite planes support 180 degree rotation. The lower layers are now in
place, so hook in the standard rotation property to expose the feature
to the users.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_sprite.c | 42
On Mon, Sep 30, 2013 at 05:41:44PM +0300, Ville Syrjälä wrote:
> On Mon, Sep 30, 2013 at 03:24:37PM +0100, Chris Wilson wrote:
> > On Mon, Sep 30, 2013 at 05:08:31PM +0300, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > We have several problems with out VGA handli
ville.syrj...@linux.intel.com writes:
> I only wanted to do some small cleanups to vlv_find_best_dpll(),
> but it seems I went slightly mad again.
>
> After realizing that I have to cook up quite a few more patches,
> I decided to also split up the functional changes from my earlier
> vlv_find_bes
On Mon, Sep 30, 2013 at 08:43:51AM -0600, Alex Williamson wrote:
> On Mon, 2013-09-30 at 17:08 +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > We have several problems with out VGA handling:
> > - We try to use the GMCH control VGA disable bit even though it may
> >
On Mon, Sep 30, 2013 at 03:53:10PM +0100, Chris Wilson wrote:
> On Mon, Sep 30, 2013 at 05:41:44PM +0300, Ville Syrjälä wrote:
> > On Mon, Sep 30, 2013 at 03:24:37PM +0100, Chris Wilson wrote:
> > > On Mon, Sep 30, 2013 at 05:08:31PM +0300, ville.syrj...@linux.intel.com
> > > wrote:
> > > > From:
On Mon, Sep 30, 2013 at 10:44 AM, wrote:
> Recently some people from inside Intel have showed some interest in 180
> degree plane rotation. To avoid a huge mess, I decided that I should
> implement the feature properly.
>
> So I snatched the rotation property from omapdrm, and moved some of the
>
On Mon, 2013-09-30 at 18:09 +0300, Ville Syrjälä wrote:
> On Mon, Sep 30, 2013 at 08:43:51AM -0600, Alex Williamson wrote:
> > On Mon, 2013-09-30 at 17:08 +0300, ville.syrj...@linux.intel.com wrote:
> > > From: Ville Syrjälä
> > >
> > > We have several problems with out VGA handling:
> > > - We t
On Mon, Sep 30, 2013 at 06:10:23PM +0300, Ville Syrjälä wrote:
> On Mon, Sep 30, 2013 at 03:53:10PM +0100, Chris Wilson wrote:
> > On Mon, Sep 30, 2013 at 05:41:44PM +0300, Ville Syrjälä wrote:
> > > On Mon, Sep 30, 2013 at 03:24:37PM +0100, Chris Wilson wrote:
> > > > On Mon, Sep 30, 2013 at 05:08
On Fri, Sep 06, 2013 at 08:08:38PM +0100, Damien Lespiau wrote:
> This series makes testdisplay able to display top and bottom, side by side
> half
> and frame packing stereo framebuffers. The final fb is composited from
> separate
> left and right images using cairo.
Pushed an up-to-date and cl
On Mon, Sep 30, 2013 at 12:15:06PM -0400, Rob Clark wrote:
> On Mon, Sep 30, 2013 at 10:44 AM, wrote:
> > Recently some people from inside Intel have showed some interest in 180
> > degree plane rotation. To avoid a huge mess, I decided that I should
> > implement the feature properly.
> >
> > So
On Mon, Sep 30, 2013 at 10:45:03AM -0600, Alex Williamson wrote:
> On Mon, 2013-09-30 at 18:09 +0300, Ville Syrjälä wrote:
> > On Mon, Sep 30, 2013 at 08:43:51AM -0600, Alex Williamson wrote:
> > > On Mon, 2013-09-30 at 17:08 +0300, ville.syrj...@linux.intel.com wrote:
> > > > From: Ville Syrjälä
On Mon, Sep 30, 2013 at 1:09 PM, Ville Syrjälä
wrote:
> On Mon, Sep 30, 2013 at 12:15:06PM -0400, Rob Clark wrote:
>> On Mon, Sep 30, 2013 at 10:44 AM, wrote:
>> > Recently some people from inside Intel have showed some interest in 180
>> > degree plane rotation. To avoid a huge mess, I decided
On Mon, Sep 30, 2013 at 7:46 PM, Rob Clark wrote:
> I guess the main thing I care about is that we don't advertise things
> to userspace that we can't actually do. I'm not sure what other hw
> out there supports rotation in hw in some form or another, but it
> might be a good time to hear from 'e
On Mon, Sep 30, 2013 at 01:46:11PM -0400, Rob Clark wrote:
> On Mon, Sep 30, 2013 at 1:09 PM, Ville Syrjälä
> wrote:
> > On Mon, Sep 30, 2013 at 12:15:06PM -0400, Rob Clark wrote:
> >> On Mon, Sep 30, 2013 at 10:44 AM, wrote:
> >> > Recently some people from inside Intel have showed some interes
On Mon, Sep 30, 2013 at 08:21:33PM +0200, Daniel Vetter wrote:
> On Mon, Sep 30, 2013 at 7:46 PM, Rob Clark wrote:
> > I guess the main thing I care about is that we don't advertise things
> > to userspace that we can't actually do. I'm not sure what other hw
> > out there supports rotation in hw
On Mon, 2013-09-30 at 15:24 +0100, Chris Wilson wrote:
> On Mon, Sep 30, 2013 at 05:08:31PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > We have several problems with out VGA handling:
> > - We try to use the GMCH control VGA disable bit even though it may
> > be
On Thu, Sep 26, 2013 at 08:05:59PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> For some reason, every single time I try to run module_reload
> something tries to read the connector sysfs files. This happens
> after we destroy the encoders and before we destroy the connectors, so
> when th
On Sat, Sep 28, 2013 at 04:46:56PM +0100, Damien Lespiau wrote:
> Signed-off-by: Damien Lespiau
Not sure why I made it non-static in the first place.
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_drv.h | 1 -
> drivers/gpu/drm/i915/intel_pm.c | 2 +-
> 2 files changed, 1 inse
On Sat, Sep 28, 2013 at 08:05:14AM -0700, Jesse Barnes wrote:
> On Sat, 28 Sep 2013 11:54:21 +0200
> Daniel Vetter wrote:
>
> > On Fri, Sep 27, 2013 at 04:02:29PM -0700, Jesse Barnes wrote:
> > > The global integrated clock source bit resides in DPLL B on VLV, but we
> > > were treating it as a p
On Tue, 1 Oct 2013 00:19:55 +0300
Ville Syrjälä wrote:
> On Sat, Sep 28, 2013 at 08:05:14AM -0700, Jesse Barnes wrote:
> > On Sat, 28 Sep 2013 11:54:21 +0200
> > Daniel Vetter wrote:
> >
> > > On Fri, Sep 27, 2013 at 04:02:29PM -0700, Jesse Barnes wrote:
> > > > The global integrated clock sour
This is another drm-intel-collector updated notice:
http://cgit.freedesktop.org/~vivijim/drm-intel/log/?h=drm-intel-collector
Here goes the update list in order for better reviewers assignment:
Patch drm/i915: check that the i965g/gm 4G limit is really obeyed -
Reviewer: Damien Lespiau
Pat
Did you compile or boot this? I get a warning since you are using edid
uninitialised, I guess you meant to duplicate intel_connector->edid.
Dave.
> drivers/gpu/drm/i915/intel_dp.c |8 +---
> 1 file changed, 1 insertion(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b
On Tue, Oct 01, 2013 at 12:14:57AM +0300, Ville Syrjälä wrote:
> On Sat, Sep 28, 2013 at 04:46:56PM +0100, Damien Lespiau wrote:
> > Signed-off-by: Damien Lespiau
>
> Not sure why I made it non-static in the first place.
>
> Reviewed-by: Ville Syrjälä
Queued for -next, thanks for the patch.
-D
On Mon, Sep 30, 2013 at 03:20:44PM -0700, Jesse Barnes wrote:
> On Tue, 1 Oct 2013 00:19:55 +0300
> Ville Syrjälä wrote:
>
> > On Sat, Sep 28, 2013 at 08:05:14AM -0700, Jesse Barnes wrote:
> > > On Sat, 28 Sep 2013 11:54:21 +0200
> > > Daniel Vetter wrote:
> > >
> > > > On Fri, Sep 27, 2013 at
59 matches
Mail list logo