Does this solve a problem? If so, you could write that in the commit message.
Regards
//Ernst
Den tors 22 nov. 2018 kl 19:22 skrev Liu, Shaoyun :
>
> Driver shouldn't try to access any GFX registers until RLC is idle.
> During the test, it took 12 seconds for RLC to clear the BUSY bit
> in
On 11/22/2018 02:03 PM, Christian König wrote:
> Am 22.11.18 um 16:44 schrieb Grodzovsky, Andrey:
>>
>> On 11/22/2018 06:16 AM, Christian König wrote:
>>> How about using a lock per hive and then acquiring that with trylock()
>>> instead?
>>>
>>> This way you should at least catch cases where
From: Philip Yang
[ Upstream commit c837243ff4017f493c7d6f4ab57278d812a86859 ]
The bug limits the IH ring wptr address to 40bit. When the system memory
is bigger than 1TB, the bus address is more than 40bit, this causes the
interrupt cannot be handled and cleared correctly.
Reviewed-by:
On 11/22/2018 02:43 PM, Kazlauskas, Nicholas wrote:
> On 11/22/18 2:39 PM, Grodzovsky, Andrey wrote:
>>
>> On 11/22/2018 12:34 PM, Nicholas Kazlauskas wrote:
>>> [Why]
>>> Atomic check can't truly be non-blocking if amdgpu_dm is waiting for
>>> hw_done and flip_done in atomic check. This
On 11/22/18 2:39 PM, Grodzovsky, Andrey wrote:
>
>
> On 11/22/2018 12:34 PM, Nicholas Kazlauskas wrote:
>> [Why]
>> Atomic check can't truly be non-blocking if amdgpu_dm is waiting for
>> hw_done and flip_done in atomic check. This introduces waits when
>> any previous non-blocking commits
Am 22.11.18 um 16:44 schrieb Grodzovsky, Andrey:
On 11/22/2018 06:16 AM, Christian König wrote:
How about using a lock per hive and then acquiring that with trylock()
instead?
This way you should at least catch cases where multiple causes try to
reset the same hive at the same time. True that
Driver shouldn't try to access any GFX registers until RLC is idle.
During the test, it took 12 seconds for RLC to clear the BUSY bit
in RLC_GPM_STAT register which is un-acceptable for driver.
As per RLC engineer, it would take RLC Ucode less than 10,000 GFXCLK
cycles to finish its critical
The other one i after driver enable the CP interrupt (set register
CP_INT_CNTL_RING0) . I think it still needed but maybe can be moved
under if statement
Regards
shaoyun.liu
On 2018-11-22 12:18 p.m., Kuehling, Felix wrote:
> On 2018-11-22 12:03 p.m., Liu, Shaoyun wrote:
>> Driver shouldn't
Hi Boris,
Just because I happened to read the docs in here, one typo below:
On Thu, Nov 22, 2018 at 12:23:29PM +0100, Boris Brezillon wrote:
>We have 3 drivers defining the "underscan", "underscan hborder" and
>"underscan vborder" properties (radeon, amd and nouveau) and we are
>about to add the
[Why]
Atomic check can't truly be non-blocking if amdgpu_dm is waiting for
hw_done and flip_done in atomic check. This introduces waits when
any previous non-blocking commits queued work on a worker thread and
a new atomic commit attempts to do another full update/modeset.
[How]
Drop the waits
[Why]
Two non-blocking commits in succession can result in a sequence where
the same dc->current_state is queried for both commits.
1. 1st commit -> check -> commit -> swaps atomic state -> queues work
2. 2nd commit -> check -> commit -> swaps atomic state -> queues work
3. 1st commit work
Driver shouldn't try to access any GFX registers until RLC is idle.
During the test, it took 12 seconds for RLC to clear the BUSY bit
in RLC_GPM_STAT register which is un-acceptable for driver.
As per RLC engineer, it would take RLC Ucode less than 10,000 GFXCLK
cycles to finish its critical
Hi,
I am facing a common issue with a screen artifacts whenever I start my Xorg on
AMDGPU driver with display set to 75 Hz 1920x1080. It appears to be hitting all
the users of AMDGPU driver.
https://bugs.freedesktop.org/show_bug.cgi?id=96868
On 11/22/2018 06:16 AM, Christian König wrote:
> How about using a lock per hive and then acquiring that with trylock()
> instead?
>
> This way you should at least catch cases where multiple causes try to
> reset the same hive at the same time. True that there is still some
> racing involved,
Signed-off-by: Monk Liu
---
drivers/gpu/drm/drm_mm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index 3cc5fbd..369fd9b 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -318,6 +318,8 @@ static struct drm_mm_node
Am 22.11.18 um 07:56 schrieb Sharma, Deepak:
when returned fence is not valid mostly due to userspace ignored
previous error causes NULL pointer dereference.
Again, this is clearly incorrect. The my other mails on the earlier patch.
If you have already pushed the patch then please revert.
Applying an underscan setup is just a matter of scaling all planes
appropriately and adjusting the CRTC X/Y offset to account for the
horizontal and vertical border.
Create an vc4_plane_underscan_adj() function doing that and call it from
vc4_plane_setup_clipping_and_scaling() so that we are
We have 3 drivers defining the "underscan", "underscan hborder" and
"underscan vborder" properties (radeon, amd and nouveau) and we are
about to add the same kind of thing in VC4.
Define generic underscan props and add new fields to the drm_connector
state so that the property parsing logic can
Hello,
This is an attempt at providing generic support for underscan connector
props. We already have 3 drivers defining the same underscan, underscan
vborder and underscan hborder properties (amd, radeon and nouveau) and
I am about to add a new one, hence my proposal to put the prop parsing
code
Now that the plane code takes the underscan setup into account, we can
safely attach the underscan props to the HDMI connector.
We also take care of filling AVI infoframes correctly to expose the
top/botton/left/right bar.
Note that these underscan props match pretty well the
Am 22.11.18 um 03:36 schrieb Sharma, Deepak:
when returned fence is not valid mostly due to userspace ignored
previous error causes NULL pointer dereference
NAK, when the fence is NULL then this means it is already signaled and
no longer in the container.
In other words this is a normal
How about using a lock per hive and then acquiring that with trylock()
instead?
This way you should at least catch cases where multiple causes try to
reset the same hive at the same time. True that there is still some
racing involved, but it's at least a good start.
Additional to that I
Am 21.11.18 um 17:39 schrieb Alex Deucher:
On Wed, Nov 21, 2018 at 11:37 AM Zeng, Oak wrote:
No need to add a new file for this. Just add this to vega20_reg_init.c.
Agreed.
Also, please use the doorbell enums rather than hardcoding the numbers.
Ok. Where should I put the doorbell enums
23 matches
Mail list logo
