[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160504/36225c1c/attachment.html>

[Bug 87682] Horizontal lines in radeon driver on kernel 3.15 and upwards

bed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160504/667875ff/attachment.html>

[PATCH RESEND v3 2/2] drm/fsl-dcu: use bus_flags for pixel clock polarity

The drivers current default configuration drives the pixel data on rising edge of the pixel clock. However, most display sample data on rising edge... This leads to color shift artefacts visible especially at edges. This patch changes the relevant defines to be useful and actually set the bits,

[PATCH RESEND v3 1/2] drm: introduce bus_flags in drm_display_info

Introduce bus_flags to specify display bus properties like signal polarities. This is useful for parallel display buses, e.g. to specify the pixel clock or data enable polarity. Suggested-by: Thierry Reding Acked-by: Philipp Zabel Acked-by: Manfred Schlaegl Acked-by: Daniel Vetter

[PATCH RESEND v3 0/2] drm: introduce bus_flags for pixel clock polarity

This resend is just rebased on drm-next as of today (+Daniels Ack). Dropped the first patch in version 3 since that is already applied in v4.6. Also moved all generic changes (including the changes in panel-simple) to the first, generic patch. Instead of using struct drm_display_mode to convey

[Bug 94900] HD6950 GPU lockup with various steam games (octodad, saints row 4)

hives/dri-devel/attachments/20160504/30ede3c3/attachment.html>

[PATCH] drm: sun4i: print DMA address correctly

-- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160504/459377c2/attachment-0001.sig>

[PATCH] drm/sun4i: add COMMON_CLK dependency

ons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160504/4e0a095f/attachment.sig>

[PATCH v4 00/11] drm: Add Allwinner A10 display engine support

nctions in the DRM core to > push it in the drivers. > - Fixed a few bitmasks on some bitfields definition > - Fixed the RGB connector mode validation that was not testing the > right values Applied the DT patches. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160504/797aca40/attachment.sig>

[PATCH v3 4/4] drm/i915: Determine DP++ type 1 DVI adaptor presence based on VBT

Reviewed-by: Shashank Sharma Regards Shashank On 5/4/2016 5:15 PM, ville.syrjala at linux.intel.com wrote: > From: Ville Syrjälä > > DP dual mode type 1 DVI adaptors aren't required to implement any > registers, so it's a bit hard to detect them. The best way would > be to check the state of

[PATCH v3 3/4] drm/i915: Enable/disable TMDS output buffers in DP++ adaptor as needed

On 5/4/2016 5:19 PM, Ville Syrjälä wrote: > On Wed, May 04, 2016 at 03:43:30PM +0530, Sharma, Shashank wrote: >> >> On 5/3/2016 12:38 AM, ville.syrjala at linux.intel.com wrote: >>> From: Ville Syrjälä >>> >>> To save a bit of power, let's try to turn off the TMDS output buffers >>> in DP++

[PATCH 2/3] drm/fb_helper: Fix references to dev->mode_config.num_connector

On Wed, May 04, 2016 at 11:28:52AM -0400, Lyude wrote: > During boot, MST hotplugs are generally expected (even if no physical > hotplugging occurs) and result in DRM's connector topology changing. > This means that using num_connector from the current mode configuration > can lead to the number

[Bug 117591] amdgpu: Black screens on A10-8700P (Carrizo) + R7 M260/M265 (Topaz) Combo

https://bugzilla.kernel.org/show_bug.cgi?id=117591 --- Comment #9 from Jani Väinölä --- I guess I should leave the bug open so you can investigate why this discrete card is not running properly in normal mode? (BTW: I noticed now that my card is an R7 M260X according to the laptop-box). --

[Bug 117591] amdgpu: Black screens on A10-8700P (Carrizo) + R7 M260/M265 (Topaz) Combo

https://bugzilla.kernel.org/show_bug.cgi?id=117591 --- Comment #8 from Jani Väinölä --- Yes it did! :) Perfect! Thanks! I have been running the laptop now for an hour and it is still working great. Now if I run lspci -vv I get: 04:00.0 Display controller: Advanced Micro Devices, Inc.

[PATCH 1/3] drm/i915/fbdev: Fix num_connector references in intel_fb_initial_config()

On Wed, May 04, 2016 at 11:28:51AM -0400, Lyude wrote: > During boot time, MST devices usually send a ton of hotplug events > irregardless of whether or not any physical hotplugs actually occurred. > Hotplugs mean connectors being created/destroyed, and the number of DRM > connectors changing

[Intel-gfx] [PATCH 3/3] drm/fb_helper: Fix a few typos

On Wed, May 04, 2016 at 11:28:53AM -0400, Lyude wrote: > s/modest/modeset/ > s/aftert/after/ > > Signed-off-by: Lyude Applied to drm-misc, thanks. -Daniel > --- > drivers/gpu/drm/drm_fb_helper.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git

[PATCH] drm/edid : calculate vsync and hsync from range limits block according to the EDID 1.4

On Tue, 03 May 2016, Vitaly Prosyak wrote: > Do calculation of vsync and hsync from range limits > EDID block according to the spec. EDID 1.4. > > Signed-off-by: Vitaly Prosyak > --- > drivers/gpu/drm/drm_edid.c | 16 > 1 file changed, 8 insertions(+), 8 deletions(-) > > diff

[GIT PULL v3] drm-hisilicon-next for 4.7

On 29 April 2016 at 18:40, Xinliang Liu wrote: > Hi Dave, > > v3: > This driver should only work on arm64 system. > So add ARM64 depends on to the Kconfig in this commit: > 23e7b2ab9a8f drm/hisilicon: Add hisilicon kirin drm master driver > > The 32-bit system compilation warnings and errors

[PATCH] drm: Fix up markup fumble

On Wed, 04 May 2016, Daniel Vetter wrote: > It's & for struct references, not #. > > Signed-off-by: Daniel Vetter > --- > include/drm/drm_modeset_helper_vtables.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/drm/drm_modeset_helper_vtables.h >

[PATCH V3 4/4] soc/tegra: pmc: Register PMC child devices as platform device

Power Management Controller(PMC) of Tegra does the multiple chip power related functionality for internal and IO interfacing. Some of the functionalities are power gating of IP blocks, IO pads voltage and power state configuration, system power state configurations, wakeup controls etc. Different

[PATCH V3 3/4] soc/tegra: pmc: Add support for IO pads power state and voltage

The IO pins of Tegra SoCs are grouped for common control of IO interface like setting voltage signal levels and power state of the interface. The group is generally referred as IO pads. The power state and voltage control of IO pins can be done at IO pads level. Tegra generation SoC supports the

[PATCH V3 2/4] soc/tegra: pmc: Correct type of variable for tegra_pmc_readl()

The function tegra_pmc_readl() returns the u32 type data and hence change the data type of variable where this data is stored to u32 type. Signed-off-by: Laxman Dewangan --- Changes from V1: -This is new in series as per discussion on V1 series to use u32 for tegra_pmc_readl. Changes from V2:

[PATCH V3 1/4] soc/tegra: pmc: Use BIT macro for register field definition

Use BIT macro for register field definition and make constant as U when using in shift operator like (3 << 30) to (3U << 30) Signed-off-by: Laxman Dewangan --- Changes from V1: - Remove the indenting of line which is not for BIT macro usage. Changes from V2: - None --- drivers/soc/tegra/pmc.c

[PATCH V3 0/4] soc/tegra: Add support for IO pads power and voltage control

The IO pins of Tegra SoCs are grouped for common control of IO interface like setting voltage signal levels and power state of the interface. The group is generally referred as IO pads. The power state and voltage control of IO pins can be done at IO pads level. Tegra124 onwards IO pads support

[GIT PULL v3] drm-hisilicon-next for 4.7

On 4 May 2016 at 15:24, Dave Airlie wrote: > On 29 April 2016 at 18:40, Xinliang Liu wrote: >> Hi Dave, >> >> v3: >> This driver should only work on arm64 system. >> So add ARM64 depends on to the Kconfig in this commit: >> 23e7b2ab9a8f drm/hisilicon: Add hisilicon kirin drm master driver >> >>

[PATCH v2 4/4] drm/i915: Determine DP++ type 1 DVI adaptor presence based on VBT

On 5/3/2016 12:38 AM, ville.syrjala at linux.intel.com wrote: > From: Ville Syrjälä > > DP dual mode type 1 DVI adaptors aren't required to implement any > registers, so it's a bit hard to detect them. The best way would > be to check the state of the CONFIG1 pin, but we have no way to > do

[PATCH 5/9] drm/i915: Enable i915 perf stream for Haswell OA unit

On Wed, May 04, 2016 at 02:24:14PM +0100, Robert Bragg wrote: > On Wed, May 4, 2016 at 1:24 PM, Daniel Vetter wrote: > > > On Wed, May 04, 2016 at 10:49:53AM +0100, Robert Bragg wrote: > > > On Wed, May 4, 2016 at 10:09 AM, Martin Peres < > > martin.peres at linux.intel.com> > > > wrote: > > > >

[PATCH v3 3/4] drm/i915: Enable/disable TMDS output buffers in DP++ adaptor as needed

On 5/3/2016 12:38 AM, ville.syrjala at linux.intel.com wrote: > From: Ville Syrjälä > > To save a bit of power, let's try to turn off the TMDS output buffers > in DP++ adaptors when we're not driving the port. > > v2: Let's not forget DDI, toss in a debug message while at it > v3: Just do the

[PATCH] drm: Fix up markup fumble

It's & for struct references, not #. Signed-off-by: Daniel Vetter --- include/drm/drm_modeset_helper_vtables.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/drm/drm_modeset_helper_vtables.h b/include/drm/drm_modeset_helper_vtables.h index

[PATCH v2 2/4] drm/i915: Respect DP++ adaptor TMDS clock limit

Reviewed-by: Shashank Sharma Regards Shashank On 5/3/2016 12:38 AM, ville.syrjala at linux.intel.com wrote: > From: Ville Syrjälä > > Try to detect the max TMDS clock limit for the DP++ adaptor (if any) > and take it into account when checking the port clock. > > Note that as with the sink

[PATCH v2] drm/exynos: fix cancel page flip code

Driver code did not remove event from the list of pending events before destroy. As a result drm core later tried to inspect invalid memory location. The patch replaces removal code with call to core helper. The bug was detected using KASAN: [ 10.107249]

[PATCH v3 3/4] drm/i915: Enable/disable TMDS output buffers in DP++ adaptor as needed

On Wed, May 04, 2016 at 03:43:30PM +0530, Sharma, Shashank wrote: > > On 5/3/2016 12:38 AM, ville.syrjala at linux.intel.com wrote: > > From: Ville Syrjälä > > > > To save a bit of power, let's try to turn off the TMDS output buffers > > in DP++ adaptors when we're not driving the port. > > >

[PATCH v3 4/4] drm/i915: Determine DP++ type 1 DVI adaptor presence based on VBT

From: Ville Syrjälä DP dual mode type 1 DVI adaptors aren't required to implement any registers, so it's a bit hard to detect them. The best way would be to check the state of the CONFIG1 pin, but we have no way to do that. So as a last resort, check the VBT to

[PATCH] drm/core: Do not preserve framebuffer on rmfb, v4.

It turns out that preserving framebuffers after the rmfb call breaks vmwgfx userspace. This was originally introduced because it was thought nobody relied on the behavior, but unfortunately it seems there are exceptions. drm_framebuffer_remove may fail with -EINTR now, so a straight revert is

[PATCH 5/9] drm/i915: Enable i915 perf stream for Haswell OA unit

ation where we see this kind of message too frequently which might > indicate an issue to investigate. > > >> - reading 0 sounds more like bad synchronization. > > > I suppose I haven't thoroughly considered if we should return zero in any > case - normally that would imply EOF so we get to choose what that implies > here. I don't think the driver should ever return 0 from read() currently. > > A few concious choices re: read() return values have been: > > - never ever return partial records (or rather even if a partial record > were literally copied into the userspace buffer, but an error were hit in > the middle of copying a full sample then that record wouldn't be accounted > for in the byte count returned.) > > - Don't throw away records successfully copied, due to a later error. This > simplifies error handling paths internally and reporting > EAGAIN/ENOSPC/EFAULT errors and means data isn't lost. The precedence for > what we return is 1) did we successfully copy some reports? report bytes > copied for complete records. 2) did we encounter an error? report that if > so. 3) return -EAGAIN. (though for a blocking fd this will be handled > internally). > > > >> Have you tried quiescing > > the entire gpu (to make sure nothing is happen) and disabling OA, then >> updating, and then restarting? At least on a very quick look I didn't >> spot that. Random delays freak me out a bit, but wouldn't be surprised >> if really needed. >> > > Experimenting yesterday, it seems I can at least reduce the delay to > around 15ms (granted that's still pretty huge), and it's also workable to > have userspace sleep for this time (despite the mdelay I originally went > with) > > Haven't tried this, but yeah could be interesting to experiment if the MUX > config lands faster in different situation such as when the HW is idle. > Hmm, maybe a stretch, but 15ms is perhaps coincidentally close to the vblank period, the MUX relates to a fabric across the whole gpu... not totally in-plausible there could be an interaction there too. another one to experiment with. - Robert > > Thanks, > - Robert > > >> >> Cheers, Daniel >> -- >> Daniel Vetter >> Software Engineer, Intel Corporation >> http://blog.ffwll.ch >> > > -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160504/d6cca70b/attachment-0001.html>

[PATCH] drm: Fixup locking WARN_ON mistake around gem_object_free_unlocked

Embarrassingly while fixing up the old paths for i915 I managed to misplace a locking check for the new _unlocked paths. That's what I get for not retesting on radeon. Fixes: 9f0ba539d13a ("drm/gem: support BO freeing without dev->struct_mutex") Cc: Chris Wilson Cc: Alex Deucher Cc: Lucas Stach

[PATCH v2 4/4] drm/i915: Determine DP++ type 1 DVI adaptor presence based on VBT

On Wed, May 04, 2016 at 03:54:41PM +0530, Sharma, Shashank wrote: > > > On 5/3/2016 12:38 AM, ville.syrjala at linux.intel.com wrote: > > From: Ville Syrjälä > > > > DP dual mode type 1 DVI adaptors aren't required to implement any > > registers, so it's a bit hard to detect them. The best

[PATCH 14/14] drm/amdgpu: fetch cu_info once at init

Fetch this info once at init and just store the results for future requests. Reviewed-by: Christian König Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/amdgpu.h | 20 +--- drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c | 4 +---

[PATCH 13/14] drm/amd: cleanup remaining spaces and tabs v2

From: Christian König This is the result of running the following commands: find drivers/gpu/drm/amd/ -name "*.h" -exec sed -i 's/[ \t]\+$//' {} \; find drivers/gpu/drm/amd/ -name "*.c" -exec sed -i 's/[ \t]\+$//' {} \; find drivers/gpu/drm/amd/ -name "*.h" -exec sed

[PATCH 12/14] drm/amdgpu: remove define for reserved client ID

From: Christian König Just set it to zero instead. Signed-off-by: Christian König Reviewed-by: Chunming Zhou Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 - drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 2 +- 2 files changed, 1

[PATCH 11/14] drm/amdgpu: remove owner cleanup v2

From: Christian König The client ID is now unique, so no need to resert the owner fields any more. v2: remove unused variables as well Signed-off-by: Christian König Reviewed-by: Chunming Zhou (v1) Signed-off-by: Alex Deucher ---

[PATCH 10/14] drm/amdgpu: make the VMID owner always 64bit

From: Christian König Otherwise we could (in theory) run into problems on 32bit systems. Signed-off-by: Christian König Reviewed-by: Chunming Zhou Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/amdgpu.h| 2 +-

[PATCH 09/14] drm/amdgpu: two minor 80 char fixes

From: Christian König Signed-off-by: Christian König Reviewed-by: Tom St Denis Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/amdgpu.h | 10 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c| 3 ++-

[PATCH 08/14] drm/amdgpu: hdp flush should always do

From: Monk Liu This fixes Tonga vm-fault issue when running disaster (a multiple context GL heavy tests), We should always flush & invalidate hdp no matter vm used or not. Signed-off-by: Monk Liu Reviewed-by: Christian König Reviewed-by: Chunming Zhou Signed-off-by: Alex

[PATCH 07/14] drm/amd/amdgpu: Enable CG for UVD6 on Carrizo

From: Tom St Denis Tested via vdpau/mpv. Signed-off-by: Tom St Denis Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/vi.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c

[PATCH 06/14] drm/amdgpu: add pipeline sync for compute job

From: Chunming Zhou hardware ring is async processed, the job is executed in parallel. In some case, this will result vm fault, like jobs with different vmids. This works around a CPC hw issue which will eventually be fixed in fw. Signed-off-by: Chunming Zhou Reviewed-by:

[PATCH 05/14] drm/amdgpu: use fence_context to judge ctx switch

From: Monk Liu use ctx pointer is not safe, cuz they are likely already be assigned to another ctx when doing comparing. fence_context is always increasing and have rare chance to overback to used number for jobs that scheduled to ring continueonsly Signed-off-by: Monk Liu

[PATCH 04/14] drm/amdgpu: keep vm in job instead of ib (v2)

From: Monk Liu ib.vm is a legacy way to get vm, after scheduler implemented vm should be get from job, and all ibs from one job share the same vm, no need to keep ib.vm just move vm field to job. this patch as well add job as paramter to ib_schedule so it can get vm from

[PATCH 03/14] drm/amdgpu: make vmid owner be client_id

From: Chunming Zhou Using the pointer is not adequate. Signed-off-by: Chunming Zhou Reviewed-by: Alex Deucher Reviewed-by: Monk Liu Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff

[PATCH 02/14] drm/amdgpu: add client id for every vm

From: Chunming Zhou This adds a unique id for each vm client so we can properly track them. Signed-off-by: Chunming Zhou Reviewed-by: Alex Deucher Reviewed-by: Monk Liu Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/amdgpu.h| 6 ++

[PATCH 01/14] drm/amdgpu: fix wrong release of vmid owner

From: Chunming Zhou The release of the vmid owner was not handled correctly. We need to take the lock and walk the lru list. Signed-off-by: Chunming Zhou Reviewed-by: Alex Deucher Reviewed-by: Monk Liu Signed-off-by: Alex Deucher ---

[PATCH 5/9] drm/i915: Enable i915 perf stream for Haswell OA unit

On Wed, May 04, 2016 at 10:49:53AM +0100, Robert Bragg wrote: > On Wed, May 4, 2016 at 10:09 AM, Martin Peres linux.intel.com> > wrote: > > > On 03/05/16 23:03, Robert Bragg wrote: > > > >> > >> > >> On Tue, May 3, 2016 at 8:34 PM, Robert Bragg >> > wrote: > >> >

[PATCH 5/9] drm/i915: Enable i915 perf stream for Haswell OA unit

- reading 0 sounds more like bad synchronization. I suppose I haven't thoroughly considered if we should return zero in any case - normally that would imply EOF so we get to choose what that implies here. I don't think the driver should ever return 0 from read() currently. A few concious choices re: read() return values have been: - never ever return partial records (or rather even if a partial record were literally copied into the userspace buffer, but an error were hit in the middle of copying a full sample then that record wouldn't be accounted for in the byte count returned.) - Don't throw away records successfully copied, due to a later error. This simplifies error handling paths internally and reporting EAGAIN/ENOSPC/EFAULT errors and means data isn't lost. The precedence for what we return is 1) did we successfully copy some reports? report bytes copied for complete records. 2) did we encounter an error? report that if so. 3) return -EAGAIN. (though for a blocking fd this will be handled internally). > Have you tried quiescing the entire gpu (to make sure nothing is happen) and disabling OA, then > updating, and then restarting? At least on a very quick look I didn't > spot that. Random delays freak me out a bit, but wouldn't be surprised > if really needed. > Experimenting yesterday, it seems I can at least reduce the delay to around 15ms (granted that's still pretty huge), and it's also workable to have userspace sleep for this time (despite the mdelay I originally went with) Haven't tried this, but yeah could be interesting to experiment if the MUX config lands faster in different situation such as when the HW is idle. Thanks, - Robert > > Cheers, Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch > -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160504/c0a76005/attachment-0001.html>

[PATCH i-g-t] tests/kms: Add test for testing rmfb framebuffer removal handling.

Add some tests to BAT to ensure rmfb/lastclose handling doesn't break again. The test will set framebuffers on each crtc, and then try rmfb or close. Afterwards it rechecks to make sure the framebuffers are removed. Signed-off-by: Maarten Lankhorst --- diff --git a/tests/Makefile.sources

[pull] radeon and amdgpu drm-next-4.7

Hi Dave, This is the first big radeon/amdgpu pull request for 4.7. Highlights: - Polaris support in amdgpu Current display stack on par with other asics, for advanced features DAL is required Power management support Support for GFX, Compute, SDMA, UVD, VCE - VCE and UVD init/fini cleanup

[PATCH] drm/edid : calculate vsync and hsync from range limits block according to the EDID 1.4

___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch -- next part -- A non-text attachment was scrubbed... Name: range_limits_1.4_edid_block.JPG Type: image/jpeg Size: 177026 bytes Desc: range_limits_1.4_edid_block.JPG URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160504/bb90e41a/attachment-0001.jpe>

[Bug 95261] R5 M330 GPU lockup with DPM + high power states

ext part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160504/57a1c7b6/attachment.html>

[PATCH 5/9] dt-bindings: msm/dsi: Some binding doc cleanups

On 05/03/2016 07:35 PM, Philipp Zabel wrote: > Am Dienstag, den 03.05.2016, 16:27 +0530 schrieb Archit Taneja: >> Some cleanups: >> >> - Use simpler names for DT nodes in the example >> - Fix phandle for specifying data lane mapping in the example. >> - Use references instead of dumping Document

[Bug 95261] R5 M330 GPU lockup with DPM + high power states

bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160504/18367b82/attachment.html>

[Bug 95261] R5 M330 GPU lockup with DPM + high power states

: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160504/82f2b577/attachment.html>

[PATCH 8/9] dt-bindings: msm/dsi: Modify port and PHY bindings

On 05/03/2016 07:32 PM, Philipp Zabel wrote: > Am Dienstag, den 03.05.2016, 16:28 +0530 schrieb Archit Taneja: >> The DSI node now has two ports that describe the connection between the >> MDP interface output and the DSI input, and the connection between the DSI >> output and the connected

[Bug 95261] R5 M330 GPU lockup with DPM + high power states

|| -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160504/8b8a5ef2/attachment.html>

[Bug 95261] R5 M330 GPU lockup with DPM + high power states

bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160504/26250eaf/attachment.html>

[Bug 95261] R5 M330 GPU lockup with DPM + high power states

archives/dri-devel/attachments/20160504/5e2b6804/attachment.html>

[PATCH 2/3] drm: Add DP port types from DP 1.3 specification

On Tue, 2016-05-03 at 10:35 -0400, Ilia Mirkin wrote: > > On May 3, 2016 9:49 AM, "Mika Kahola" wrote: > > > > DP specification 1.3 defines DP downstream ports for > > DP++ and wireless devices. Let's add these to port > > definitions. > > > > Signed-off-by: Mika Kahola > > --- > >

[pull] radeon and amdgpu drm-fixes-4.6

Hi Dave, A few small fixes for 4.6: - fix a hang in the display engine seen with some bad modes - Metadata use after free fix The following changes since commit ea99697814d6e64927e228675a6eb7fa76014648: Merge branch 'drm-fixes-4.6' of git://people.freedesktop.org/~agd5f/linux into drm-fixes

[PATCH 19/35] drm/imx: Use lockless gem BO free callback

Am Mittwoch, den 04.05.2016, 12:28 +0200 schrieb Daniel Vetter: > On Wed, Apr 27, 2016 at 02:01:35PM +0200, Philipp Zabel wrote: > > Am Mittwoch, den 27.04.2016, 13:21 +0200 schrieb Daniel Vetter: > > > On Wed, Apr 27, 2016 at 12:29:34PM +0200, Philipp Zabel wrote: > > > > Am Dienstag, den

[PATCH 19/35] drm/imx: Use lockless gem BO free callback

On Wed, Apr 27, 2016 at 02:01:35PM +0200, Philipp Zabel wrote: > Am Mittwoch, den 27.04.2016, 13:21 +0200 schrieb Daniel Vetter: > > On Wed, Apr 27, 2016 at 12:29:34PM +0200, Philipp Zabel wrote: > > > Am Dienstag, den 26.04.2016, 19:29 +0200 schrieb Daniel Vetter: > > > > No dev->struct_mutex

[PATCH] drm/gem: support BO freeing without dev->struct_mutex

On Tue, May 03, 2016 at 11:59:19AM -0400, Alex Deucher wrote: > On Mon, May 2, 2016 at 4:40 AM, Daniel Vetter > wrote: > > Finally all the core gem and a lot of drivers are entirely free of > > dev->struct_mutex depencies, and we can start to have an entirely > > lockless unref path. > > > > To

[PATCH 2/9] drm/msm: Drop the gpu binding

On 05/03/2016 06:12 PM, Rob Herring wrote: > On Tue, May 3, 2016 at 5:57 AM, Archit Taneja > wrote: >> The driver currently identifies the GPU components it needs by parsing >> a phandle list from the 'gpus' DT property. >> >> This isn't the right binding to go with. So, for now, just search

[Intel-gfx] [PATCH 5/9] drm/i915: Enable i915 perf stream for Haswell OA unit

pam of generating all of those context switch reports. > >> The driver is already usable with gputop with this delay and considering >> how config changes are typically associated with user interaction I >> wouldn't see this as a show stopper - even though it's not ideal. I >> think the assertions about it being unusable with GL, were a little >> overstated based on making frequent OA config changes which is not >> really how the interface is intended to be used. >> > > Yeah, but a performance warning in mesa, I would be OK with this change. > Thanks for taking the time to explain! A performance warning sounds like a sensible idea yup. Regards, - Robert > > >> >> Thanks for starting to take a look through the code. >> >> Kind Regards, >> - Robert >> > > Martin > -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160504/5c906ba4/attachment.html>

[PATCH 1/5] drm/displayid: Enhance version reporting

On Wed, May 04, 2016 at 06:36:48AM +1000, Dave Airlie wrote: > From: Tomas Bzatek > > Cosmetic change, let's report more precise revisions and IDs. > > https://bugs.freedesktop.org/show_bug.cgi?id=95207 > > Signed-off-by: Dave Airlie > --- > drivers/gpu/drm/drm_edid.c | 6 +++--- >

[PATCH 5/9] drm/i915: Enable i915 perf stream for Haswell OA unit

On 03/05/16 23:03, Robert Bragg wrote: > > > On Tue, May 3, 2016 at 8:34 PM, Robert Bragg > wrote: > > Sorry for the delay replying to this, I missed it. > > On Sat, Apr 23, 2016 at 11:34 AM, Martin Peres > wrote: > >

[Intel-gfx] [PATCH 5/9] drm/i915: Enable i915 perf stream for Haswell OA unit

On 03/05/16 22:34, Robert Bragg wrote: > Sorry for the delay replying to this, I missed it. No worries! > > On Sat, Apr 23, 2016 at 11:34 AM, Martin Peres > wrote: > > On 20/04/16 17:23, Robert Bragg wrote: > > Gen graphics hardware can be set up to

[PATCH] drm/exynos: fix cancel page flip code

Hi Inki, Gently ping. Regards Andrzej On 03/24/2016 11:52 AM, Andrzej Hajda wrote: > Driver code did not remove event from the list of pending events before > destroy. > As a result drm core tried later to inspect invalid memory location. > The patch replaces removal code with call to core

[PATCH 3/6] drm/exynos/hdmi: expose HDMI-PHY clock as pipeline clock

Hi Inki, It looks like this patch felt through the cracks. It is a part of "drm/exynos: add pipeline clock support" patchset. Other patches from the patchset were taken already. Could you queue it to next pull request? Regards Andrzej On 03/23/2016 02:25 PM, Andrzej Hajda wrote: > HDMI-PHY

[PATCH -fixes] drm/vmwgfx: Kill some lockdep warnings

Some global KMS state that is elsewhere protected by the mode_config mutex here needs to be protected with a local mutex. Remove corresponding lockdep checks and introduce a new driver-private global_kms_state_mutex, and make sure its locking order is *after* the crtc locks in order to avoid

[PATCH 3/3] drm/fb_helper: Fix a few typos

s/modest/modeset/ s/aftert/after/ Signed-off-by: Lyude --- drivers/gpu/drm/drm_fb_helper.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index 15204c0..7778a0e 100644 ---

[PATCH 2/3] drm/fb_helper: Fix references to dev->mode_config.num_connector

During boot, MST hotplugs are generally expected (even if no physical hotplugging occurs) and result in DRM's connector topology changing. This means that using num_connector from the current mode configuration can lead to the number of connectors changing under us. This can lead to some nasty

[PATCH 1/3] drm/i915/fbdev: Fix num_connector references in intel_fb_initial_config()

During boot time, MST devices usually send a ton of hotplug events irregardless of whether or not any physical hotplugs actually occurred. Hotplugs mean connectors being created/destroyed, and the number of DRM connectors changing under us. This isn't a problem if we use fb_helper->connector_count

[PATCH 5/5] drm/edid: add displayid detailed 1 timings to the modelist.

On Tue, 03 May 2016, Dave Airlie wrote: > From: Dave Airlie > > The tiled 5K Dell monitor appears to be hiding it's tiled mode > inside the displayid timings block, this patch parses this > blocks and adds the modes to the modelist. > > Bugzilla:

[PATCH 3/5] drm/edid: move displayid tiled block parsing into separate function.

On Tue, 03 May 2016, Dave Airlie wrote: > From: Dave Airlie > > This just makes the code easier to follow. Swapping the order of patches 2 and 3 would make the patch series easier to follow. ;) BR, Jani. > > Signed-off-by: Dave Airlie > --- > drivers/gpu/drm/drm_edid.c | 110 >

[PATCH] drm/exynos: fix cancel page flip code

Hi Andrzej, On 24 March 2016 at 10:52, Andrzej Hajda wrote: > @@ -229,24 +229,12 @@ void exynos_drm_crtc_cancel_page_flip(struct drm_crtc > *crtc, > struct drm_file *file) > { > struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc); > -

[PATCH 5/9] drm/i915: Enable i915 perf stream for Haswell OA unit

ar as that goes it makes sense to me to expect bad data if we don't wait for the MUX config to land properly. Something I don't really know is how come we're seemingly lucky to have the reports be cleanly invalid with a zero report-id, instead of just having junk data that would be harder to recognise. > I am a bit swamped with other tasks right now, but I would love to spend > more time reviewing your code as I really want to see this upstream! > No worries. I can hopefully send out my i-g-t tests this afternoon too which should hopefully give us all the pieces to be able seriously consider hopefully landing things soon. Regards, - Robert > Martin > -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160504/b0bd7e71/attachment-0001.html>

[PATCH] drm/edid : cache edid range limits in drm connector

On Wed, 04 May 2016, "Prosyak, Vitaly" wrote: > We are going to use min/max vertical refresh rate when enter/exit to > the dynamic refresh rate mode ,it is known as 'freesync', enter/exit > to full screen games. As Daniel said, we should see the patch using them too. It's hard to say whether

[Bug 87682] Horizontal lines in radeon driver on kernel 3.15 and upwards

, is that possible ? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160504/1dac63d7/attachment.html>

drm/radeon/kms: add dpm support for KB/KV

Same thing in kv_init_fps_limits from amdgpu. drivers/gpu/drm/amd/amdgpu/kv_dpm.c:1446 kv_init_fps_limits() error: wrong number of bits for 'cpu_to_be16' (8 vs 16) left= 'pi->fps_low_t' pi->fps_low_t = (__builtin_bswap16(((tmp regards, dan carpenter

[PULL] drm-amdkfd-next

Hi Dave, Here are a few amdkfd patches for 4.7, all of them fixes according to the Coccinelle tool. Thanks, Oded The following changes since commit b89359bdf0f1e95a4c5f92300594ba9dde323fc4: Merge branch 'for-next' of http://git.agner.ch/git/linux-drm-fsl-dcu into drm-next (2016-04-29

[PATCH] drm: Fixup locking WARN_ON mistake around gem_object_free_unlocked

On Wed, May 4, 2016 at 8:29 AM, Daniel Vetter wrote: > Embarrassingly while fixing up the old paths for i915 I managed to > misplace a locking check for the new _unlocked paths. That's what I > get for not retesting on radeon. > > Fixes: 9f0ba539d13a ("drm/gem: support BO freeing without

[PATCH 9/9] dt-bindings: msm/dsi: Add assigned clocks bindings

On Tue, May 03, 2016 at 04:28:01PM +0530, Archit Taneja wrote: > The PLL in the DSI PHY block generates 2 clock outputs (Byte and Pixel > clocks) that are fed into the Multimedia Clock Controller (MMCC). The MMCC > uses these as source clocks for some of its RCGs to generate clocks that > finally

[PATCH 4/9] dt-bindings: msm/mdp: Remove connector and gpu bindings

On Tue, May 03, 2016 at 04:27:56PM +0530, Archit Taneja wrote: > The MDP DT node now contains a list of ports that describe how it connects > to external encoder interfaces like DSI and HDMI. These follow the > standard of_graph bindings, and allow us to get rid of the 'connectors' > phandle that

[PATCH 2/2] drm/exynos/dsi: use of_graph_get_endpoint_by_regs helper

On 05/03/2016 03:47 PM, Philipp Zabel wrote: > This allows to remove the local of_graph_get_port_by_reg(), > of_graph_get_endpoint_by_reg(), and of_get_child_by_name_reg() > functions. > > Signed-off-by: Philipp Zabel Reviewed-by: Andrzej Hajda -- Regards Andrzej > --- >

[PATCH 1/2] drm/exynos/dpi: use of_graph_get_endpoint_by_regs helper

On 05/03/2016 03:47 PM, Philipp Zabel wrote: > This allows to remove the local of_graph_get_port_by_reg(), > of_graph_get_endpoint_by_reg(), of_get_child_by_name_reg(), > and of_graph_get_remote_port_parent() functions. > > Signed-off-by: Philipp Zabel Thanks for the patch. Reviewed-by:

[Bug 95247] System hangs after ~10 minutes when using Radeon R9 390

bed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160504/6bff9e5b/attachment.html>

[PATCH 5/5] drm/edid: add displayid detailed 1 timings to the modelist.

From: Dave Airlie The tiled 5K Dell monitor appears to be hiding it's tiled mode inside the displayid timings block, this patch parses this blocks and adds the modes to the modelist. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95207 Signed-off-by: Dave Airlie ---

[PATCH 4/5] drm/edid: move displayid validation to it's own function.

From: Dave Airlie We need to use this for validating modeline additions. Signed-off-by: Dave Airlie --- drivers/gpu/drm/drm_edid.c | 45 +++-- 1 file changed, 27 insertions(+), 18 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c

[PATCH 3/5] drm/edid: move displayid tiled block parsing into separate function.

From: Dave Airlie This just makes the code easier to follow. Signed-off-by: Dave Airlie --- drivers/gpu/drm/drm_edid.c | 110 - 1 file changed, 59 insertions(+), 51 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c

[PATCH 2/5] drm/displayid: Iterate over all DisplayID blocks

From: Tomas Bzatek This will iterate over all DisplayID blocks found in the buffer. Previously only the first block was parsed. https://bugs.freedesktop.org/show_bug.cgi?id=95207 Signed-off-by: Dave Airlie --- drivers/gpu/drm/drm_edid.c | 124

[PATCH 1/5] drm/displayid: Enhance version reporting

From: Tomas Bzatek Cosmetic change, let's report more precise revisions and IDs. https://bugs.freedesktop.org/show_bug.cgi?id=95207 Signed-off-by: Dave Airlie --- drivers/gpu/drm/drm_edid.c | 6 +++--- include/drm/drm_displayid.h | 6 -- 2 files changed, 7

[rfc] drm/edid: add support for displayid timings

It appears that Dell 5K monitors hide some mode timings in the displayid block, this set of patches fixes up a few bits of displayid support, then add support for extracting the type 1 detailed timings that the Dell monitors use. The first two patches are missing signoff but I've asked for Tomas

  1   2   >