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.
v2: HSW handles the rotated buffer offset automagically
Cc
From: Ville Syrjälä
Use the new drm_mode_create_rotation_property() in omapdrm.
v5: Fixed conflict due to change in the prior patch in call to
drm_property_create_bitmask()
Cc: David Airlie
Cc: Rob Clark
Cc: Sagar Kamble
Cc: "Ville Syrjälä"
Cc: Tomi Valkeinen
Cc: Greg Kroah-Hartman
Cc: dr
From: Sagar Kamble
With clipped sprites these transformations are not working. these
functions transform complete sprite irrespective of clipping present.
This leads to invisible portion of sprite show up when rotate 180 if
it was out of visible area before.
v4: Moved rotate transform for source
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.
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: David Airlie
Cc: dri-de...@lists.freedesktop.org
Cc: linux-ker...@vger
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 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.
v2: HSW handles the rotated buffer offset automagically
Cc
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.
Cc: David Airlie
Cc: dri-de...@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Ville Syrjälä
From: Ville Syrjälä
Add a function to create a standards compliant rotation property.
v4: For creating rotation bitmask property send number of values
as only number of set rotations
Cc: David Airlie
Cc: dri-de...@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Ville Syrj
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.
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: David Airlie
Cc: dri-de...@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.o
From: Sagar Kamble
Primary planes support 180 degree rotation. Expose the feature
through rotation drm property.
v2: Calculating linear/tiled offsets based on pipe source width and
height. Added 180 degree rotation support in ironlake_update_plane.
v3: Checking if CRTC is active before issueing
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.
v5
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.
Cc: David Airlie
Cc: Tomi Valkeinen
Cc: Dave Airlie
Cc: Rob Clark
Cc: Daniel Vetter
Cc: Archit Taneja
Cc: dri-de...@lists.freedesktop.org
Cc: linux-ker...@
From: Sagar Kamble
These patches will enable 180 degree rotation for CRTC and Sprite planes.
Changelog:
1. drm: Add support_bits parameter to drm_property_create_bitmask()
Fixed caller of this function in omapdrm for bisectability of this patch.
2. drm/omap: Switch omapdrm over to drm_mode_create
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/intel_dp.c between commit 4e6b788c3f23 ("drm/i915:
Disable dp aux irq on g4x") from the drm-intel-fixes tree and commit
5ed12a19078b ("drm/i915: Factor out a function returning the AUX_CTL
value to start
On Fri, Feb 7, 2014 at 8:45 AM, wrote:
> 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
On Fri, Feb 7, 2014 at 8:45 AM, wrote:
> From: Ville Syrjälä
>
> Use the new drm_mode_create_rotation_property() in omapdrm.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Rob Clark
> ---
> drivers/gpu/drm/omapdrm/omap_plane.c | 17 +++--
> 1 file changed, 7 insertions(+), 10 del
On Sun, 2014-02-09 at 14:25 +0100, Paul Bolle wrote:
> On Sun, 2014-02-09 at 13:15 +, Steven Newbury wrote:
> > PCI resource allocation is undergoing some changes at the moment, it's
> > definitely a bug if the Flush Page isn't getting allocated. I'm looking
> > forward to hopefully getting pc
On Sun, 2014-02-09 at 13:15 +, Steven Newbury wrote:
> PCI resource allocation is undergoing some changes at the moment, it's
> definitely a bug if the Flush Page isn't getting allocated. I'm looking
> forward to hopefully getting pci_bus_alloc_resource_fit() behaviour in
> mainline, it will p
On Sun, 2014-02-09 at 01:02 +0100, Daniel Vetter wrote:
> On Sat, Feb 8, 2014 at 9:22 PM, Paul Bolle wrote:
> > Daniel Vetter schreef op za 08-02-2014 om 20:59 [+0100]:
> >> Hm, if this is really a regression between 3.13 and 3.14-rc1 then I
> >> don't see any quick candidates - relevant functions
Aside: Your quoting is a bit strange, it looks like part of Chris' mail is
indented differently than other paragraphs from the same mail, which then
in turn match the indent for my reply. And the indent-levels are wrong, my
replay has >> but Chris's has only one >. Rather confusing.
I suggest you
20 matches
Mail list logo
