[Bug 82201] [HAWAII] GPU doesn't reclock, poor 3D performance

-- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141024/da421176/attachment.html>

[PATCH] regulator: stub out devm_regulator_get_exclusive

et_voltage() for a range rather than specifying the correct voltage. -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: Digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/at

[Bug 82201] [HAWAII] GPU doesn't reclock, poor 3D performance

-- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141024/c72e231e/attachment.html>

[PATCH] regulator: stub out devm_regulator_get_exclusive

ists.freedesktop.org/archives/dri-devel/attachments/20141024/b562/attachment.sig>

[PATCH] regulator: stub out devm_regulator_get_exclusive

/pgp-signature Size: 473 bytes Desc: Digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141024/9ce9a9ea/attachment-0001.sig>

[Bug 85107] A10-7800: Boot problems (CPU stuck) and dpm not working correctly

You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141024/a847d012/attachment.html>

[GIT PULL] Armada DRM fixes

David, Please incorporate the latest Armada DRM fixes, which can be found at: git://ftp.arm.linux.org.uk/~rmk/linux-arm.git drm-armada-fixes with SHA1 178e561f514fca4863c06a4af3501172e5627eb1. Three changes for the Armada DRM driver: 1. Add back the flags which tell the DRM core that we can

[PATCH 2/2] drm/i915: remove unneeded visible check

From: Gustavo Padovan The fb check introduced to drm_plane_helper_check_update() just make this check impossible to branch in. Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/i915/intel_display.c | 21 + 1 file changed, 5 insertions(+),

[PATCH 1/2] drm: make sure visible is set to false if fb is null

From: Gustavo Padovan We can't let visible set true while the fb is null, some places of the code only check for visible to base its decisions. Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/drm_plane_helper.c | 5 + 1 file changed, 5 insertions(+)

[PATCH] allow 32bpp framebuffers for cirrus drm

turn false; > + > + if (pitch > max_pitch) > + return false; > + > + if (pitch * height > max_size) > + return false; > + > + return true; > +} > -- > 2.1.0.rc2.206.gedb03e5 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141024/38e2344c/attachment-0001.html>

[Intel-gfx] [PATCH v4 5/5] drm/i915: remove intel_crtc_cursor_set_obj()

On Fri, Oct 24, 2014 at 02:51:35PM +0100, Gustavo Padovan wrote: > From: Gustavo Padovan > > Merge it into the plane update_plane() callback and make other > users use the update_plane() functions instead. > > The fb != crtc->cursor->fb was already inside intel_crtc_cursor_set_obj() > so we

[PATCH v4 4/5] drm/i915: only flip frontbuffer if crtc is active

On Fri, Oct 24, 2014 at 02:51:34PM +0100, Gustavo Padovan wrote: > From: Gustavo Padovan > > There is no point in flipping a buffer for a disabled crtc. That thing doesn't actually flip but just signal the frontbuffer tracking code that either has just flipped or is going to real soon now (tm).

[Bug 83461] hdmi screen flicker/unusable

https://bugzilla.kernel.org/show_bug.cgi?id=83461 --- Comment #13 from Christian K?nig --- (In reply to kb from comment #12) > note xrandr is on good kernel, dmesg in on bad Those outputs should work fine. Going to make a patch for this, but this might take a while. -- You are receiving this

[PATCH] regulator: stub out devm_regulator_get_exclusive

On Fri, Oct 24, 2014 at 5:18 PM, Mark Brown wrote: > On Fri, Oct 24, 2014 at 04:36:24PM -0400, Rob Clark wrote: > >> iirc, I was using _get_exclusive() in a few places where I wanted to >> be sure not to get dummy-regulator in cases where I should >> -EPROBE_DEFER instead (since probe order with

[Intel-gfx] [PATCH v3 05/11] drm/i915: remove intel_crtc_cursor_set_obj()

On Fri, Oct 24, 2014 at 02:23:35PM +0100, Gustavo Padovan wrote: > 2014-10-07 Ville Syrj?l? : > > > On Wed, Sep 24, 2014 at 02:20:26PM -0300, Gustavo Padovan wrote: > > > From: Gustavo Padovan > > > > > > Merge it into the plane update_plane() callback and make other > > > users use the

tile property contents

>> > > There are also configurations where users configure multiple heads to >> > > drive power walls that they want to be treated as one logical monitor, >> > > similar to the DP MST tiled display case. Normally, those powerwall >> > > configurations don't have any layout information from the

[Intel-gfx] [PATCH v3 11/11] drm/i915: remove intel_pipe_set_base()

On Fri, Oct 24, 2014 at 02:59:44PM +0100, Gustavo Padovan wrote: > 2014-10-07 Ville Syrj?l? : > > > On Wed, Sep 24, 2014 at 02:20:32PM -0300, Gustavo Padovan wrote: > > > From: Gustavo Padovan > > > > > > After some refactor intel_primary_plane_setplane() does the same > > > as

[PATCH] regulator: stub out devm_regulator_get_exclusive

On Fri, Oct 24, 2014 at 4:11 PM, Mark Brown wrote: > On Fri, Oct 24, 2014 at 02:15:11PM -0500, Felipe Balbi wrote: >> If we don't stup that call out, we will have >> build failures for any drivers using that function >> when .config happens to have CONFIG_REGULATOR=n. >> >> One such case below,

[PULL] drm-intel-next, take 3

Hi Dave, Ok, new attempt, this time around with full ppgtt disabled again. drm-intel-next-2014-10-03: - first batch of skl stage 1 enabling - fixes from Rodrigo to the PSR, fbc and sink crc code - kerneldoc for the frontbuffer tracking code, runtime pm code and the basic interrupt

[PATCH v2 6/9] drm: Decouple EDID parsing from I2C adapter

On Fri, Oct 24, 2014 at 2:58 PM, Laurent Pinchart wrote: > --- a/include/drm/drm_edid.h > +++ b/include/drm/drm_edid.h > @@ -279,4 +279,8 @@ int > drm_hdmi_vendor_infoframe_from_display_mode(struct hdmi_vendor_infoframe > *frame, >

[PATCH v2 9/9] ARM: shmobile: koelsch: Add DU HDMI output support

Add DT nodes for the ADV7511 HDMI encoder and its HDMI output connector and configure the DISP pin group that drives the HDMI transmitter DE pin. Signed-off-by: Laurent Pinchart --- arch/arm/boot/dts/r8a7791-koelsch.dts | 50

[PATCH v2 8/9] drm: Add adv7511 encoder driver

From: Lars-Peter Clausen This patch adds a driver for the Analog Devices adv7511. The adv7511 is a standalone HDMI transmitter chip. It features a HDMI output interface on one end and video and audio input interfaces on the other. Signed-off-by: Lars-Peter Clausen

[PATCH v2 7/9] video: Add ADV751[13] DT bindings documentation

The ADV7511, ADV7511W and ADV7513 are HDMI audio and video transmitters compatible with HDMI 1.4 and DVI 1.0. They're described in DT using the OF graph bindings and a list of custom properties pertaining to the input video bus configuration. Cc: devicetree at vger.kernel.org Cc: Lars-Peter

[PATCH v2 6/9] drm: Decouple EDID parsing from I2C adapter

From: Lars-Peter Clausen The drm_get_edid() function performs direct I2C accesses to read EDID blocks, assuming that the monitor DDC interface is directly connected to the I2C bus. It can't thus be used with HDMI encoders that control the DDC bus and expose EDID blocks through a

[PATCH v2 5/9] drm: rcar-du: Add HDMI encoder and connector support

SoCs that integrate the DU have no internal HDMI encoder, support external encoders only. Signed-off-by: Laurent Pinchart --- drivers/gpu/drm/rcar-du/Kconfig | 11 ++- drivers/gpu/drm/rcar-du/Makefile | 2 +

[PATCH v2 4/9] drm: rcar-du: Replace drm_encoder with drm_slave_encoder

DRM slave encoders require their associated struct drm_encoder instance to be embedded in a struct drm_slave_encoder. This makes processing encoders regardless of their types needlessly and painfully complex in drivers that use a mix of slave encoders and custom encoders. Such a driver will need

[PATCH v2 3/9] drm: rcar-du: Replace direct DRM encoder access with cast macro

Add a new macro to downcast an rcar_du_encoder pointer to a drm_encoder pointer and use it. This prepares for the replacement of the rcar_drm_encoder encoder field with a drm_slave_encoder. Signed-off-by: Laurent Pinchart ---

[PATCH v2 2/9] drm: rcar-du: Pass the encoder DT node to rcar_du_encoder_init()

The encoder DT node will be needed to register an external HDMI encoder. Pass it to the rcar_du_encoder_init() function to prepare for HDMI support. Signed-off-by: Laurent Pinchart --- drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 5 +++--

[PATCH v2 1/9] drm: rcar-du: Remove platform data support

All platforms now instantiate the DU through DT, platform data support isn't needed anymore. Signed-off-by: Laurent Pinchart --- drivers/gpu/drm/rcar-du/rcar_du_crtc.h| 10 - drivers/gpu/drm/rcar-du/rcar_du_drv.c | 4 +-

[PATCH v2 0/9] Renesas R-Car DU HDMI support

Hello, This patch set adds support for the HDMI output port present on the Renesas Koelsch board. Doing so requires two components, a driver for the external ADV7511W HDMI encoder, and support for HDMI encoders in the DU driver. The HDMI encoder drivers uses the DRM slave encoder framework and

[Bug 84500] [radeonsi] radeon 0000:01:00.0: Packet0 not allowed!

are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141024/696d7e8f/attachment.html>

[Bug 84944] tearing on radeonsi vdpau deinterlacer

ingly to comment8 it looks like also other players also behave in such way... -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141024/6de8379d/attachment.html>

[PATCH] regulator: stub out devm_regulator_get_exclusive

19 bytes Desc: Digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141024/83d352f7/attachment-0001.sig>

[Intel-gfx] [PATCH v3 11/11] drm/i915: remove intel_pipe_set_base()

2014-10-07 Ville Syrj?l? : > On Wed, Sep 24, 2014 at 02:20:32PM -0300, Gustavo Padovan wrote: > > From: Gustavo Padovan > > > > After some refactor intel_primary_plane_setplane() does the same > > as intel_pipe_set_base() so we can get rid of it and replace the calls > > with

[PATCH v4 5/5] drm/i915: remove intel_crtc_cursor_set_obj()

From: Gustavo Padovan Merge it into the plane update_plane() callback and make other users use the update_plane() functions instead. The fb != crtc->cursor->fb was already inside intel_crtc_cursor_set_obj() so we fold intel_crtc_cursor_set_obj() inside

[PATCH v4 4/5] drm/i915: only flip frontbuffer if crtc is active

From: Gustavo Padovan There is no point in flipping a buffer for a disabled crtc. Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/i915/intel_display.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH v4 3/5] drm/i915: use intel_fb_obj() macros to assign gem objects

From: Gustavo Padovan Use the macros makes the code cleaner and it also checks for a NULL fb. Signed-off-by: Gustavo Padovan Reviewed-by: Ville Syrj?l? --- drivers/gpu/drm/i915/intel_sprite.c | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff

[PATCH v4 2/5] drm/i915: create a prepare phase for sprite plane updates

From: Gustavo Padovan take out pin_fb code so the commit phase can't fail anymore. Signed-off-by: Gustavo Padovan Reviewed-by: Ville Syrj?l? --- drivers/gpu/drm/i915/intel_sprite.c | 63 +++-- 1 file changed, 40 insertions(+),

[PATCH v4 1/5] drm/i915: create a prepare step for primary planes updates

From: Gustavo Padovan Take out the pin_fb code so commit phase can't fail anymore. Signed-off-by: Gustavo Padovan Reviewed-by: Ville Syrj?l? --- drivers/gpu/drm/i915/intel_display.c | 35 ++- 1 file changed, 26 insertions(+), 9

[Intel-gfx] [PATCH v3 05/11] drm/i915: remove intel_crtc_cursor_set_obj()

2014-10-07 Ville Syrj?l? : > On Wed, Sep 24, 2014 at 02:20:26PM -0300, Gustavo Padovan wrote: > > From: Gustavo Padovan > > > > Merge it into the plane update_plane() callback and make other > > users use the update_plane() functions instead. > > > > The fb != crtc->cursor->fb was already

[PATCH] regulator: stub out devm_regulator_get_exclusive

On Fri, Oct 24, 2014 at 02:15:11PM -0500, Felipe Balbi wrote: > If we don't stup that call out, we will have > build failures for any drivers using that function > when .config happens to have CONFIG_REGULATOR=n. > > One such case below, found with randconfig > >

[PATCH] regulator: stub out devm_regulator_get_exclusive

If we don't stup that call out, we will have build failures for any drivers using that function when .config happens to have CONFIG_REGULATOR=n. One such case below, found with randconfig drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c: In function ?mdp4_kms_init?:

tile property contents

On Fri, Oct 24, 2014 at 05:25:58PM +1000, Dave Airlie wrote: > >> > > There are also configurations where users configure multiple heads to > >> > > drive power walls that they want to be treated as one logical monitor, > >> > > similar to the DP MST tiled display case. Normally, those powerwall

[RFC 1/2] PM / Domains: Power on domain early during system resume

On czw, 2014-10-23 at 19:20 +0300, Grygorii Strashko wrote: > Hi Krzysztof, > > On 10/23/2014 04:48 PM, Krzysztof Kozlowski wrote: > > When resuming the system the power domain has to be powered on early so > > any runtime PM aware devices could resume. > > > > This fixes following scenario

[Bug 75112] Meta Bug for HyperZ issues on r600g and radeonsi

Please help testing. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141024/7287945a/attachment.html>

[Bug 75011] [hyperz] Performance drop since git-01e6371 (disable hyperz by default) with radeonsi

for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141024/c2e97aef/attachment.html>

[Bug 84944] tearing on radeonsi vdpau deinterlacer

rom xwininfo? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141024/0d51dffb/attachment.html>