On 23 June 2017 03:21:11 BST, "Michel Dänzer" wrote:
> On 22/06/17 11:45 PM, Eric Engestrom wrote:>
> > On Thursday, 2017-06-22 10:42:21 +0900, Michel Dänzer wrote:>
> >>>
> >> Also, there are downsides to exposing library API calls as inline>
> >> functions: E.g. if drmIoctl(2) ever needs a c
On 22.06.2017 15:34, Boris Brezillon wrote:
> On Thu, 22 Jun 2017 15:16:47 +0200
> Andrzej Hajda wrote:
>
>> On 22.06.2017 14:41, Boris Brezillon wrote:
>>> On Thu, 22 Jun 2017 14:29:07 +0200
>>> Andrzej Hajda wrote:
>>>
On 22.06.2017 11:23, Boris Brezillon wrote:
> On Thu, 22 Jun 20
Hi,
On Tue, Jun 13, 2017 at 06:05:57PM +0800, Chen-Yu Tsai wrote:
> > That's not true. DE1's can output to several TCONs (or rather, TCONs
> > can select multiple engines as their input). The A31 for example is in
> > this case.
>
> Actually that's not true. The TCON is bound to the backend. I do
On Fri, 23 Jun 2017 09:22:15 +0200
Andrzej Hajda wrote:
> On 22.06.2017 15:34, Boris Brezillon wrote:
> > On Thu, 22 Jun 2017 15:16:47 +0200
> > Andrzej Hajda wrote:
> >
> >> On 22.06.2017 14:41, Boris Brezillon wrote:
> >>> On Thu, 22 Jun 2017 14:29:07 +0200
> >>> Andrzej Hajda wrote:
> >>
On Thu, Jun 22, 2017 at 4:54 PM, Liviu Dudau wrote:
> On Wed, Jun 21, 2017 at 08:28:03PM +0200, Daniel Vetter wrote:
>> Hi all,
>>
>> This is Thierry's deferred fbdev setup series, with the locking rework almost
>> entirely redone. The much wider scope is to get rid of drm_modeset_lock_all
>> call
On Bay Trail devices either the Crystal Cove PMIC's pwm or the LPSS'
pwm is used to control the backlight. Other drivers take core of
providing a backlight_pwm alias through pwm_add_table, but it is
still useful to know which pwm device actually ends up being used
for debugging backlight issues, so
assert_rpm_wakelock_held is triggered from i915_pmic_bus_access_notifier
even though it gets unregistered on (runtime) suspend, this is caused
by a race happening under the following circumstances:
intel_runtime_pm_put does:
atomic_dec(&dev_priv->pm.wakeref_count);
pm_runtime_mark_last_bus
intel_uncore_forcewake_reset() does forcewake puts and gets as such
we need to make sure that no-one tries to access the PUNIT->PMIC bus
(on systems where this bus is shared) while it runs, otherwise bad
things happen.
Normally this is taken care of by the i915_pmic_bus_access_notifier()
which doe
Hi All,
These 4 patches fix a number of real issues, yet they have seen 0
feedback so far, please review (and merge).
Regards,
Hans
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
intel_uncore_suspend() unregisters the uncore code's PMIC bus access
notifier and gets called on both normal and runtime suspend.
intel_uncore_resume_early() re-registers the notifier, but only on
normal resume. Add a new intel_uncore_runtime_resume() function which
only re-registers the notifier
Quoting Ville: "the forcewake timer might still be active until the uncore
suspend, and having active forcewakes while we've already told the GT wake
stuff to stop acting normally doesn't seem quite right to me."
Reported-by: Ville Syrjälä
Suggested-by: Imre Deak
Signed-off-by: Hans de Goede
--
On Thu, Jun 22, 2017 at 10:48:10AM +0200, Peter Rosin wrote:
> On 2017-06-22 08:36, Daniel Vetter wrote:
> > On Wed, Jun 21, 2017 at 11:40:52AM +0200, Peter Rosin wrote:
> >> On 2017-06-21 09:38, Daniel Vetter wrote:
> >>> On Tue, Jun 20, 2017 at 09:25:25PM +0200, Peter Rosin wrote:
> This mak
On Thu, Jun 22, 2017 at 08:54:51AM -0400, Alex Deucher wrote:
> On Wed, Jun 21, 2017 at 4:28 AM, Daniel Vetter wrote:
> > Both drivers shut down all crtc beforehand already, which will shut up
> > any pending vblank (the only thing vblank_cleanup really does is
> > disable the disable timer). Henc
On Thu, Jun 15, 2017 at 01:41:24PM -0700, Eric Anholt wrote:
> If the panel-bridge is being set up after the drm_mode_config_reset(),
> then the connector's state would never get initialized, and we'd
> dereference the NULL in the hotplug path. We also need to register
> the connector, so that use
On Thu, Jun 22, 2017 at 11:42 AM, Sharma, Shashank
wrote:
>> You should explain in 1-2 sentences what exactly this function does, and
>> when a driver should use it. Just documenting the input/output stuff
>> doesn't make the kerneldoc all that useful.
>
> Did you miss the first 3 lines above ?
>
On Thu, Jun 22, 2017 at 10:33 AM, Sharma, Shashank
wrote:
>> - The property values should be limited to what the driver can support, I
>>guess that would mean limiting the available ycbcr modes? Or does all
>>our hw support all the modes, including 420 (on the sink side)?
>
> This property
On Thu, Jun 22, 2017 at 07:03:10AM +0200, Peter Rosin wrote:
> The default implementation should be used.
>
> Signed-off-by: Peter Rosin
Purely optional refactor idea, since you're not the first one to stumble
over this, and in hindsight it makes sense to have these functions as the
defaults:
-
On Thu, Jun 22, 2017 at 11:49:34AM +, Philippe CORNU wrote:
>
>
> On 06/22/2017 08:06 AM, Peter Rosin wrote:
> > The redundant fb helper .load_lut is no longer used, and can not
> > work right without also providing the fb helpers .gamma_set and
> > .gamma_get thus rendering the code in this
Signed-off-by: Fengguang Wu
---
arcpgu_crtc.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c
b/drivers/gpu/drm/arc/arcpgu_crtc.c
index 99fbdae..611af74 100644
--- a/drivers/gpu/drm/arc/arcpgu_crtc.c
+++ b/drivers/gpu/drm/arc/arcpgu_c
tree: git://anongit.freedesktop.org/drm-intel drm-intel-nightly
head: cd6f0ef4478545aa014d92cabe4d794bfe54fe33
commit: 2b3d860efa3461af109469e6de2eea48f6ef5cdd [1499/1516] drm: arcpgu: Use
crtc->mode_valid() callback
reproduce:
# apt-get install sparse
git checkout 2b3d860efa34
Regards
Shashank
On 6/23/2017 2:42 PM, Daniel Vetter wrote:
On Thu, Jun 22, 2017 at 11:42 AM, Sharma, Shashank
wrote:
You should explain in 1-2 sentences what exactly this function does, and
when a driver should use it. Just documenting the input/output stuff
doesn't make the kerneldoc all t
Regards
Shashank
On 6/23/2017 2:50 PM, Daniel Vetter wrote:
On Thu, Jun 22, 2017 at 10:33 AM, Sharma, Shashank
wrote:
- The property values should be limited to what the driver can support, I
guess that would mean limiting the available ycbcr modes? Or does all
our hw support all the
On Thu, Jun 22, 2017 at 12:03:36PM -0700, Puthikorn Voravootivat wrote:
> This patch set contain 3 patches which are already reviewed by DK.
> Another 6 patches in previous version was already merged in v7 and v9.
> - First patch sets the PWM freqency to match data in panel vbt.
> - Next patch adds
On Fri, Jun 23, 2017 at 03:35:30PM +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 6/23/2017 2:50 PM, Daniel Vetter wrote:
> > On Thu, Jun 22, 2017 at 10:33 AM, Sharma, Shashank
> > wrote:
> > > > - The property values should be limited to what the driver can support,
> > > > I
On Fri, Jun 23, 2017 at 05:54:18PM +0800, kbuild test robot wrote:
>
> Signed-off-by: Fengguang Wu
Oops, missed that, applied.
Btw, for regression fixes like that, could you perhaps auto-generate the
Fixes: line per the kernel process? Makes it easier for me to know where
to apply something :-)
Hi Daniel,
On Fri, Jun 23, 2017 at 12:30:17PM +0200, Daniel Vetter wrote:
On Fri, Jun 23, 2017 at 05:54:18PM +0800, kbuild test robot wrote:
Signed-off-by: Fengguang Wu
Oops, missed that, applied.
Btw, for regression fixes like that, could you perhaps auto-generate the
Fixes: line per the
On Thu, Jun 22, 2017 at 02:46:17PM +0100, Chris Wilson wrote:
> When the caller maps their dmabuf and we return an sg_table, the caller
> doesn't expect the pages beneath that sg_table to vanish on a whim (i.e.
> under mempressure). The contract is that the pages are pinned for the
> duration of th
On Fri, Jun 23, 2017 at 01:02:53PM +0200, Daniel Vetter wrote:
> Anyway looks all good, will push to drm-misc-fixes.
Correction, pushed to -misc-next because it conflicts with the dma-buf
import stuff from Laura and other bits. If you want it in -fixes I need a
backport. I left the cc: stable in j
On Fri, Jun 23, 2017 at 06:51:05PM +0800, Fengguang Wu wrote:
> Hi Daniel,
>
> On Fri, Jun 23, 2017 at 12:30:17PM +0200, Daniel Vetter wrote:
> > On Fri, Jun 23, 2017 at 05:54:18PM +0800, kbuild test robot wrote:
> > >
> > > Signed-off-by: Fengguang Wu
> >
> > Oops, missed that, applied.
> >
>
Quoting Daniel Vetter (2017-06-23 12:02:53)
> On Thu, Jun 22, 2017 at 02:46:17PM +0100, Chris Wilson wrote:
> > + /* Flush the object from the CPU cache so that importers can rely
> > + * on coherent indirect access via the exported dma-address.
> > + */
> > drm_clflush_pages(pa
https://bugs.freedesktop.org/show_bug.cgi?id=101561
--- Comment #4 from Andy Furniss ---
Yea, this commit also breaks (asserts) Unigine Valley on R9 285.
I'll open a bug on llvm tracker and link back to this one.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=101561
--- Comment #5 from Andy Furniss ---
(In reply to Andy Furniss from comment #4)
> Yea, this commit also breaks (asserts) Unigine Valley on R9 285.
>
> I'll open a bug on llvm tracker and link back to this one.
https://bugs.llvm.org/show_bug.cg
On Fri, Jun 23, 2017 at 01:08:17PM +0200, Daniel Vetter wrote:
On Fri, Jun 23, 2017 at 06:51:05PM +0800, Fengguang Wu wrote:
Hi Daniel,
On Fri, Jun 23, 2017 at 12:30:17PM +0200, Daniel Vetter wrote:
> On Fri, Jun 23, 2017 at 05:54:18PM +0800, kbuild test robot wrote:
> >
> > Signed-off-by: Feng
On Fri, Jun 23, 2017 at 09:38:49AM +0200, Daniel Vetter wrote:
> On Thu, Jun 22, 2017 at 4:54 PM, Liviu Dudau wrote:
> > On Wed, Jun 21, 2017 at 08:28:03PM +0200, Daniel Vetter wrote:
> >> Hi all,
> >>
> >> This is Thierry's deferred fbdev setup series, with the locking rework
> >> almost
> >> en
From: Thierry Reding
FB helper code falls back to a 1024x768 mode if no outputs are connected
or don't report back any modes upon initialization. This can be annoying
because outputs that are added to FB helper later on can't be used with
FB helper if they don't support a matching mode.
The fall
https://bugs.freedesktop.org/show_bug.cgi?id=98238
--- Comment #20 from almos ---
I confirm that Marek's patch fixes Witcher 2.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedes
On 6/22/2017 7:04 PM, Boris Brezillon wrote:
On Thu, 22 Jun 2017 15:16:47 +0200
Andrzej Hajda wrote:
On 22.06.2017 14:41, Boris Brezillon wrote:
On Thu, 22 Jun 2017 14:29:07 +0200
Andrzej Hajda wrote:
On 22.06.2017 11:23, Boris Brezillon wrote:
On Thu, 22 Jun 2017 13:47:43 +0530
Archi
https://bugs.freedesktop.org/show_bug.cgi?id=101565
Bug ID: 101565
Summary: Intermittent graphical corruption since "radeonsi:
don't emit partial flushes at the end of IBs (v2)"
(c9040dc9)
Product: Mesa
Version: g
On Wed, Jun 21, 2017 at 10:28:45AM +0200, Daniel Vetter wrote:
> Either not relevant (in the load error paths) or done better already
> (in the unload code, by calling drm_atomic_helper_shutdown). Drop it.
>
> Cc: Mark Yao
> Signed-off-by: Daniel Vetter
Reviewed-by: Sean Paul
> ---
> drivers
On Wed, Jun 21, 2017 at 10:28:48AM +0200, Daniel Vetter wrote:
> Again stopping the vblank before uninstalling the irq handler is kinda
> the wrong way round, but the fb_off stuff should take care of
> disabling the dsiplay at least in most cases. So drop the
> drm_vblank_cleanup code since it's no
On Tue, Jun 13, 2017 at 05:51:42PM +0800, Icenowy Zheng wrote:
>
>
> 于 2017年6月13日 GMT+08:00 下午3:44:32, Maxime Ripard
> 写到:
> >On Sun, Jun 11, 2017 at 02:43:42PM +0800, icen...@aosc.io wrote:
> >> 在 2017-06-07 17:38，Maxime Ripard 写道：
> >> > On Mon, Jun 05, 2017 at 12:01:45AM +0800, Icenowy Zheng
On 06/22/2017 07:56 PM, Eric Anholt wrote:
> Signed-off-by: Eric Anholt
> ---
>
> This fixup would be squashed into patch 1 of your series.
Hi Eric,
and many thanks for the two patches, I will follow your suggestion for
the v5 serie.
By the way, do you have more comments on the "drm/stm: ltdc
On Wed, Jun 21, 2017 at 10:28:37AM +0200, Daniel Vetter wrote:
> Hi all,
>
> This is the resend of the driver patches which haven't seen and ack/r-b yet
> and
> so aren't merged yet. I'd really like to get them all merged. Review/acks very
> much appreciated.
>
> Thanks, Daniel
>
> Daniel Vette
https://bugs.freedesktop.org/show_bug.cgi?id=100785
--- Comment #14 from Hi-Angel ---
Created attachment 132157
--> https://bugs.freedesktop.org/attachment.cgi?id=132157&action=edit
fix
FTR, attaching the fix. However I don't know when I get it sent to the ML
because I can't finish piglit test
From: Vijendar Mukunda
Added quirk DW_I2S_QUIRK_16BIT_IDX_OVERRIDE to Designware
driver. This quirk will set idx value to 1.
By setting this quirk, it will override supported format
as 16 bit resolution and bus width as 2 Bytes.
Reviewed-by: Alex Deucher
Signed-off-by: Vijendar Mukunda
Signed
This patch set updates the AMD GPU and Audio CoProcessor (ACP)
audio drivers and the designware i2s driver for Stoney (ST).
ST is an APU similar to Carrizo (CZ) which already has ACP audio
support. The i2s controller and ACP audio DMA engine are part of
the GPU and both need updating so I would li
From: Vijendar Mukunda
Added condition checks for CZ specific code based on asic_type.
Stoney specific code will be added in a future commit.
Reviewed-by: Alex Deucher
Signed-off-by: Vijendar Mukunda
Signed-off-by: Alex Deucher
---
sound/soc/amd/acp-pcm-dma.c | 62 +++
From: Vijendar Mukunda
Added DW_I2S_QUIRK_16BIT_IDX_OVERRIDE quirk for Stoney.
Supported format and bus width for I2S controller read
from I2S Component Parameter registers.
These are ready only registers.
For Stoney, I2S Component Parameter registers are programmed
to support 32 bit format and
From: Vijendar Mukunda
asic_type information is passed to ACP DMA Driver as platform data.
We need this to determine whether the asic is Carrizo (CZ) or
Stoney (ST) in the acp sound driver.
Reviewed-by: Alex Deucher
Signed-off-by: Vijendar Mukunda
Signed-off-by: Alex Deucher
---
drivers/gpu/
From: Vijendar Mukunda
Added DMA driver changes for Stoney platform.
Below are the key differences between Stoney and CZ:
- Memory Gating is disabled
- SRAM Banks won't be turned off
- No Of SRAM Banks reduced to 6
- DAGB Garlic Interface used
- 16 bit resolution is supported.
- SRAM bank 1 & SRA
From: Akshu Agrawal
The driver is used for AMD board using rt5650 codec.
Reviewed-by: Alex Deucher
Signed-off-by: Akshu Agrawal
Signed-off-by: Alex Deucher
---
sound/soc/amd/Kconfig | 7 ++
sound/soc/amd/Makefile | 2 +
sound/soc/amd/acp-rt5645.c | 210 ++
From: Vijendar Mukunda
Stoney uses 16kb SRAM memory for playback and 16Kb
for capture. Modified Max buffer size to have the
correct mapping between System Memory and SRAM.
Added snd_pcm_hardware structures for playback
and capture for Stoney.
Reviewed-by: Alex Deucher
Signed-off-by: Vijendar M
From: Vijendar Mukunda
Power Gating is disabled in Stoney platform.
Reviewed-by: Alex Deucher
Signed-off-by: Vijendar Mukunda
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c | 33 ++---
1 file changed, 18 insertions(+), 15 deletions(-)
dif
Am 23.06.2017 um 18:34 schrieb Alex Deucher:
From: Vijendar Mukunda
asic_type information is passed to ACP DMA Driver as platform data.
We need this to determine whether the asic is Carrizo (CZ) or
Stoney (ST) in the acp sound driver.
Reviewed-by: Alex Deucher
Signed-off-by: Vijendar Mukunda
This is the plumbing for supporting fb modifiers on planes. Modifiers
have already been introduced to some extent, but this series will extend
this to allow querying modifiers per plane. Based on this, the client to
enable optimal modifications for framebuffers.
This patch simply allows the DRM dr
v2:
Support sprite plane.
Support pipe C/D limitation on GEN9.
This requires rebase on the correct Ville patches
Cc: Daniel Stone
Cc: Kristian Høgsberg
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/intel_display.c | 34 +--
drivers/gpu/drm/i915/intel_sprite.
These patches create the blob property for modifiers, and the implementation for
i915 modifiers. This [generally] has been tested in Weston by Daniel Stone as
well as an earlier version of kmscube. This patch series was formerly known as
"GET_PLANE2" because the interface for obtaining the modifier
This was based on a patch originally by Kristian. It has been modified
pretty heavily to use the new callbacks from the previous patch.
v2:
- Add LINEAR and Yf modifiers to list (Ville)
- Combine i8xx and i965 into one list of formats (Ville)
- Allow 1010102 formats for Y/Yf tiled (Ville)
v
Updated blob layout (Rob, Daniel, Kristian, xerpi)
v2:
* Removed __packed, and alignment (.+)
* Fix indent in drm_format_modifier fields (Liviu)
* Remove duplicated modifier > 64 check (Liviu)
* Change comment about modifier (Liviu)
* Remove arguments to blob creation, use plane instead (Liviu)
*
On Fri, Jun 23, 2017 at 12:43 PM, Christian König
wrote:
> Am 23.06.2017 um 18:34 schrieb Alex Deucher:
>>
>> From: Vijendar Mukunda
>>
>> asic_type information is passed to ACP DMA Driver as platform data.
>> We need this to determine whether the asic is Carrizo (CZ) or
>> Stoney (ST) in the acp
This allows a BO to have busy placements that are not part of its normal
placements.
Users that want the busy placements to be the same can change the
placement.busy_placement pointer and corresponding count to be the same as
the regular placements.
Signed-off-by: John Brooks
---
drivers/gpu/dr
Signed-off-by: John Brooks
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 3 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 5 +
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 ++
3 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/am
When the AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED flag is given by userspace,
it should only be treated as a hint to initially place a BO somewhere CPU
accessible, rather than having a permanent effect on BO placement.
Instead of the flag being set in stone at BO creation, set the flag when a
page fa
Performing expensive BO moves asynchronously reduces the direct burden on
the CS path, but it can still indirectly cause occasional stalls because
the worker may reserve the BO for a long time during evictions, and if this
coincides with it being needed by CS, the CS path will have to wait.
Instea
Allow specifying a limit on visible VRAM via a module parameter. This is
helpful for testing performance under visible VRAM pressure.
Signed-off-by: John Brooks
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 4
drivers/gpu/drm/amd/amdgpu/amdgpu_
This patch series is intended to improve performance when limited CPU-visible
VRAM is under pressure.
Moving BOs into visible VRAM is essentially a housekeeping task. It's faster to
access them in VRAM than GTT, but it isn't a hard requirement for them to be in
VRAM. As such, it is unnecessary to
There is no need for page faults to force BOs into visible VRAM if it's
full, and the time it takes to do so is great enough to cause noticeable
stuttering. Add GTT as a possible placement so that if visible VRAM is
full, page faults move BOs to GTT instead of evicting other BOs from VRAM.
Signed-
amdgpu_ttm_placement_init() callers that are using both VRAM and GTT as
domains usually don't want visible VRAM as a busy placement.
Signed-off-by: John Brooks
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu
Moving CPU-accessible BOs from GTT to visible VRAM reduces latency on the
GPU and improves average framerate. However, it's an expensive operation.
When visible VRAM is full and evictions are necessary, it can easily take
tens of milliseconds. On the CS path, that directly increases the frame
time
The BO move throttling code is designed to allow VRAM to fill quickly if it
is relatively empty. However, this does not take into account situations
where the visible VRAM is smaller than total VRAM, and total VRAM may not
be close to full but the visible VRAM segment is under pressure. In such
sit
https://bugs.freedesktop.org/show_bug.cgi?id=101565
Marek Olšák changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=101330
--- Comment #6 from Vincent B. ---
Core was generated by `pcsxr'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0xe64f8128 in radeon_bo_do_map (bo=0x931b0f8) at radeon_drm_bo.c:466
466 radeon_drm_bo.c: Aucun fichier ou doss
https://bugs.freedesktop.org/show_bug.cgi?id=101561
--- Comment #6 from Andy Furniss ---
(In reply to Andy Furniss from comment #5)
> Though I couldn't add the author to CC :-(
Oops ignore that bit - the author is addable, I was trying to add the llvm
username which is different.
--
You are r
Philippe CORNU writes:
> On 06/22/2017 07:56 PM, Eric Anholt wrote:
>> Signed-off-by: Eric Anholt
>> ---
>>
>> This fixup would be squashed into patch 1 of your series.
>
> Hi Eric,
> and many thanks for the two patches, I will follow your suggestion for
> the v5 serie.
> By the way, do you ha
On Thu, Jun 15, 2017 at 01:41:28PM -0700, Eric Anholt wrote:
> This doesn't yet cover input, but the driver does get the display
> working when the firmware is disabled from talking to our I2C lines.
>
> Signed-off-by: Eric Anholt
> ---
> .../panel/raspberrypi,7inch-touchscreen.txt| 49
On Fri, Jun 16, 2017 at 1:02 AM, Emil Velikov wrote:
> Hi Mike,
>
> On 16 June 2017 at 05:48, Mike Mestnik wrote:
>> I can tell by the 2 color(green and violet) rendering that this driver
>> is experimental. Attached is kern.log from some testing I've done.
>>
> You might be interested in the fo
https://bugs.freedesktop.org/show_bug.cgi?id=98238
--- Comment #21 from Shmerl ---
It's now in master. It should eventually land in /etc/drirc in distros, but
until then, build Mesa from source and set this variable when running the game:
glsl_correct_derivatives_after_discard=true
--
You are
The "supported input formats" table in dw_hdmi.h was incorrectly formatted,
using "+" signs where "|" needs to be. That, in turn, causes the PDF build
to fail.
Fixes: def23aa7e9821a3dfe3fb7b139dd0229a89fdeb0
Signed-off-by: Jonathan Corbet
---
include/drm/bridge/dw_hdmi.h | 70 ++
https://bugs.freedesktop.org/show_bug.cgi?id=101222
James Le Cuirot changed:
What|Removed |Added
Summary|[amd-staging] No HDMI/DP|[amd-staging] No
|s
Hi John,
I haven't read your patches. Just a question based on the cover letter.
I understand that visible VRAM is the biggest pain point. But could the
same reasoning make sense for invisible VRAM? That is, doing all the
migrations to VRAM in a workqueue?
Regards,
Felix
On 17-06-23 01:39 PM
On Mon, Jun 19, 2017 at 11:51 AM, Philippe CORNU wrote:
> On 06/08/2017 05:40 PM, Rob Herring wrote:
>> On Fri, Jun 02, 2017 at 04:37:11PM +0200, Philippe CORNU wrote:
>>> This patch adds documentation of device tree bindings for the
>>> Synopsys DesignWare MIPI DSI host DRM bridge driver.
>>>
>>>
On Mon, Jun 19, 2017 at 06:28:01PM +0200, Philippe CORNU wrote:
> This patch adds documentation of device tree bindings for the
> Synopsys DesignWare MIPI DSI host DRM bridge driver.
You missed Archit's comment on v3. Bindings are for h/w, not drivers.
Rob
___
On Mon, Jun 19, 2017 at 06:28:04PM +0200, Philippe CORNU wrote:
> This patch adds documentation of device tree bindings for the STM32
> DSI host driver based on the Synopsys DW MIPI DSI bridge driver.
Same comment here. With that,
Acked-by: Rob Herring
>
> Signed-off-by: Philippe CORNU
> Revi
Archit Taneja writes:
> On 06/22/2017 01:20 PM, Benjamin Gaignard wrote:
>> 2017-06-20 19:31 GMT+02:00 Eric Anholt :
>>> Archit Taneja writes:
>>>
On 06/16/2017 08:13 PM, Eric Anholt wrote:
> Archit Taneja writes:
>
>> On 06/16/2017 02:11 AM, Eric Anholt wrote:
>>> If the p
After applying the patches from the bug report the lockup was
immediate, black screen.
Jun 23 15:50:48 agartha kernel: [ 199.021303] amdgpu :01:00.0:
GPU fault detected: 146 0x0b22080c
Jun 23 15:50:48 agartha kernel: [ 199.021308] amdgpu :01:00.0:
VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00
Boris Brezillon writes:
> On Thu, 22 Jun 2017 13:47:43 +0530
> Archit Taneja wrote:
>
>> On 06/22/2017 01:20 PM, Benjamin Gaignard wrote:
>> > 2017-06-20 19:31 GMT+02:00 Eric Anholt :
>> >> Archit Taneja writes:
>> >>
>> >>> On 06/16/2017 08:13 PM, Eric Anholt wrote:
>> Archit Taneja
https://bugs.freedesktop.org/show_bug.cgi?id=98619
--- Comment #8 from Mike Mestnik
---
I've confirmed this VM Fault is preset with the patch applied for Doom.
https://lists.freedesktop.org/archives/dri-devel/2017-June/145248.html
--
You are receiving this mail because:
You are the assignee f
On Fri, Jun 23, 2017 at 05:02:58PM -0400, Felix Kuehling wrote:
> Hi John,
>
> I haven't read your patches. Just a question based on the cover letter.
>
> I understand that visible VRAM is the biggest pain point. But could the
> same reasoning make sense for invisible VRAM? That is, doing all the
https://bugzilla.kernel.org/show_bug.cgi?id=196117
--- Comment #6 from Paul K. Gerke (paulkge...@craftware.nl) ---
Success! Everything seems to be fixed... "everything":
I tried the amdstaging-kernel for 4.11.0+ and it works now! Jippieh!
This is the log for the working driver (I cut away a bit
https://bugzilla.kernel.org/show_bug.cgi?id=196117
--- Comment #7 from Paul K. Gerke (paulkge...@craftware.nl) ---
Created attachment 257145
--> https://bugzilla.kernel.org/attachment.cgi?id=257145&action=edit
kernel config file for a working for the RX480 system
--
You are receiving this mail
https://bugzilla.kernel.org/show_bug.cgi?id=196117
Paul K. Gerke (paulkge...@craftware.nl) changed:
What|Removed |Added
Status|NEW |RESOLVED
https://bugs.freedesktop.org/show_bug.cgi?id=101572
Bug ID: 101572
Summary: glMemoryBarrier is backwards
Product: Mesa
Version: git
Hardware: All
OS: All
Status: NEW
Severity: major
Priority: med
92 matches
Mail list logo
