Reviewed-by: Mikko Perttnuen
On 07/08/2018 22.07, Dmitry Osipenko wrote:
Currently gathers of a hung job are getting NOP'ed and a restarted CDMA
executes the NOP'ed gathers. There shouldn't be a reason to not restart
CDMA execution starting with a next job, avoiding the unnecessary churning
Reviewed-by: Mikko Perttunen
On 07/08/2018 22.07, Dmitry Osipenko wrote:
There is a chance that the last job has been completed at the time of
CDMA timeout handler invocation. In this case there is no need to complete
the completed job.
Signed-off-by: Dmitry Osipenko
---
On 2018-10-08 20:09, Jordan Crouse wrote:
On Mon, Oct 08, 2018 at 02:57:29PM +0530, Sravanthi Kollukuduru wrote:
The interconnect framework is designed to provide a
standard kernel interface to control the settings of
the interconnects on a SoC.
The interconnect API uses a
Move and maintain RM initialization flag checks
from KMS to RM.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 6 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 12
Validate layer mixer pairs for compatibility before retrieving
the connected pingpong blocks.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 61 ++
1 file changed, 17 insertions(+), 44 deletions(-)
diff --git
Get rid of hw block pointer in RM iter as we can
access the same through dpu_hw_blk.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
we don't have enough reasons why the HW block looping's
cannot happen in the same function. So merge them.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 63 ++
1 file changed, 26 insertions(+), 37 deletions(-)
diff --git
msm_display_topology was used for providing HW block
layout of the pipeline for a specific display topology.
We already got rid of its usage from DSI driver. In DPU,
it was used to provide the details on HW blocks while
reserving resources. Since we can use the crtc state used
for storing the
Encoder uses test_only flag to differentiate RM reservations
invoked from atomic check and atomic_commit phases.
After reserving the HW blocks, if test_only was set, RM
releases the reservation. Retains them if not. Since we
got rid of RM reserve call from atomic_commit path, get rid
of this flag.
Replacing with simpler linked list helper iterators.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 120 +
1 file changed, 46 insertions(+), 74 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
RM was using encoder id's to tag HW block's to reserve
and retrieve later for display pipeline. Now
that all the reserved HW blocks for a display are
maintained in its crtc state, no retrieval is needed.
This patch cleans up RM of encoder id tagging.
Signed-off-by: Jeykumar Sankaran
---
Since HW reservations are happening through atomic_check
and all the display commits are catered by a single commit thread,
it is not necessary to protect the interfaces by a separate
mutex.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 24
Unused variable in the driver.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 12
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 2 --
2 files changed, 14 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
Instead of letting encoder make a centralized reservation for
all of its display DRM components, this path splits the
responsibility between CRTC and Encoder, each requesting
RM for the HW mapping of its own domain.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
Usage of hw block iterators are only RM internal. Instead
of using generic void pointers for HW blocks, use dpu
specific structure. It helps us to get rid of duplicate
hw block id's maintained in RM wrapper.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 27
HW blocks reserved for a display are stored in crtc state.
No one outside RM is interested in using these API's for
HW block list iterations.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 37 ++-
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 46
We cleaned up RM reserve api's enough to get rid of
most of its unwanted checks and release handlers. To
improve further the readability of the function, merging
down the individual HW type allocators into one function.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
hw_mdp block is common for displays. No need
to reserve per display.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 7 ++-
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 20
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 10 --
3 files
Now that we have crtc state tracking the reserved
HW resources, we have access to them after atomic swap.
So avoid reserving the resources in mode_set.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 17 ++---
1 file changed, 2 insertions(+), 15
DPU maintained reservation lists to cache assigned
HW blocks for the display and a retrieval mechanism for
the individual DRM components to query their respective
HW blocks.
This patch uses the sub-classed CRTC state to store
and track HW blocks assigned for different components
of the display
struct dpu_hw_blk has hw block type info. Remove duplicate
type tracking in struct dpu_rm_hw_blk.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 17 -
1 file changed, 4 insertions(+), 13 deletions(-)
diff --git
This flag was introduced as a fix to notify modeset complete
when hw reservations were happening in both atomic_check
and atomic_commit paths. Now that we are reserving only in
atomic_check, we can get rid of this flag.
Signed-off-by: Jeykumar Sankaran
---
Submitting series of patches to clean up DPU resource manager (RM)
of complicated hw iterations, redundant data maintenence and eventually
modifying the DPU to reserve display HW blocks only in atomic check
and caching the assigned HW blocks in atomic CRTC state.
Thanks,
Jeykumar S.
Jeykumar
Use the hw block pointers stored in crtc state to
release them back to RM resource pool. This change
is made to uncouple RM reservation from encoder_id.
Separate change is submitted to clean up RM of
encoder id tagging.
Signed-off-by: Jeykumar Sankaran
---
RM was equipped with reservation tracking structure RSVP
to cache HW reservation of displays for certain clients
where atomic_checks (atomic commit with TEST_ONLY) for all
the displays are called before their respective atomic_commits.
Since DPU doesn't support the sequence anymore, clean up
the
Not used. Remove from RM.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 3 +--
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 7 ++-
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 6 +-
3 files changed, 4 insertions(+), 12 deletions(-)
diff --git
Layer mixer/pingpong block counts and hw ctl block counts
will not be same for all the topologies (e.g. layer
mixer muxing to single interface)
Use the encoder's split_role info to retrieve the
respective control path for programming.
Signed-off-by: Jeykumar Sankaran
---
Definition was removed already. Clean up header declaration.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h
index
Not actively used. Clean up the crtc mixer struct.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 2 --
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 2 --
2 files changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
https://bugs.freedesktop.org/show_bug.cgi?id=108272
--- Comment #5 from Jan Vesely ---
These look like two separate problems. The luxmark failure is known. Luxmark
requires more than 22 global buffers currently supported by radeonsi. without
asserts
On Tue, Oct 9, 2018 at 11:29 AM Ben Skeggs wrote:
>
> On Fri, Oct 5, 2018 at 5:50 PM Daniel Vetter wrote:
> >
> > On Fri, Oct 05, 2018 at 04:45:54PM +1000, Ben Skeggs wrote:
> > > The following changes since commit
> > > 3483f08106fcd0e8edad2b9f2fc4726d25177799:
> > >
> > >
On Fri, Oct 5, 2018 at 5:50 PM Daniel Vetter wrote:
>
> On Fri, Oct 05, 2018 at 04:45:54PM +1000, Ben Skeggs wrote:
> > The following changes since commit 3483f08106fcd0e8edad2b9f2fc4726d25177799:
> >
> > drm/nouveau/devinit: fix warning when PMU/PRE_OS is missing
> > (2018-09-13 10:56:58
VESA eDP 1.4 specification has separate fields defined in
EDP_DPCD_REV for eDP 1.4a and 1.4b eDP revisions.
This patch defines those. Found this when one of my eDP panels
advertises eDP 1.4a (04h) in the EDP_DPCD_REV DPCD field.
Cc: Jani Nikula
Cc: Ville Syrjala
Signed-off-by: Manasi Navare
While creating display and event threads per crtc, validate
them before setting their priorities.
changes in v2:
- use dev_warn (Abhinav Kumar)
changes in v3:
- fix compilation error
Change-Id: I1dda805286df981c0f0e2b26507d089d3a21ff6c
Signed-off-by: Jeykumar Sankaran
---
While creating display and event threads per crtc, validate
them before setting their priorities.
changes in v2:
- use dev_warn (Abhinav Kumar)
Change-Id: I1dda805286df981c0f0e2b26507d089d3a21ff6c
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/msm_drv.c | 49
Currently we set intel_connector->mst_port to NULL to signify that the
MST port has been removed from the system so that we can prevent further
action on the port such as connector probes, mode probing, etc.
However, we're going to need access to intel_connector->mst_port in
order to fixup
Since we need to be able to allow DPMS on->off prop changes after an MST
port has disappeared from the system, we need to be able to make sure we
can compute a config for the resulting atomic commit. Currently this is
impossible when the port has disappeared, since the VCPI slot searching
we try
Currently, i915 appears to rely on blocking modesets on
no-longer-present MSTB ports by simply returning NULL for
->best_encoder(), which in turn causes any new atomic commits that don't
disable the CRTC to fail. This is wrong however, since we still want to
allow userspace to disable CRTCs on
Next version of https://patchwork.freedesktop.org/series/49878/
Still no functional changes, just removing a duplicate s-b to make CI
happy.
Lyude Paul (5):
drm/atomic_helper: Disallow new modesets on unregistered connectors
drm/nouveau: Fix nv50_mstc->best_encoder()
drm/i915: Don't unset
As mentioned in the previous commit, we currently prevent new modesets
on recently-removed MST connectors by returning no encoder from our
->best_encoder() callback once the MST port has disappeared. This is
wrong however, because it prevents legacy modesetting users from being
able to disable
With the exception of modesets which would switch the DPMS state of a
connector from on to off, we want to make sure that we disallow all
modesets which would result in enabling a new monitor or a new mode
configuration on a monitor if the connector for the display in question
is no longer
Currently, i915 appears to rely on blocking modesets on
no-longer-present MSTB ports by simply returning NULL for
->best_encoder(), which in turn causes any new atomic commits that don't
disable the CRTC to fail. This is wrong however, since we still want to
allow userspace to disable CRTCs on
Since we need to be able to allow DPMS on->off prop changes after an MST
port has disappeared from the system, we need to be able to make sure we
can compute a config for the resulting atomic commit. Currently this is
impossible when the port has disappeared, since the VCPI slot searching
we try
Next version of https://patchwork.freedesktop.org/series/49878/
No functional changes, just a typo fix
Lyude Paul (5):
drm/atomic_helper: Disallow new modesets on unregistered connectors
drm/nouveau: Fix nv50_mstc->best_encoder()
drm/i915: Don't unset intel_connector->mst_port
drm/i915:
Currently we set intel_connector->mst_port to NULL to signify that the
MST port has been removed from the system so that we can prevent further
action on the port such as connector probes, mode probing, etc.
However, we're going to need access to intel_connector->mst_port in
order to fixup
As mentioned in the previous commit, we currently prevent new modesets
on recently-removed MST connectors by returning no encoder from our
->best_encoder() callback once the MST port has disappeared. This is
wrong however, because it prevents legacy modesetting users from being
able to disable
With the exception of modesets which would switch the DPMS state of a
connector from on to off, we want to make sure that we disallow all
modesets which would result in enabling a new monitor or a new mode
configuration on a monitor if the connector for the display in question
is no longer
Currently we set intel_connector->mst_port to NULL to signify that the
MST port has been removed from the system so that we can prevent further
action on the port such as connector probes, mode probing, etc.
However, we're going to need access to intel_connector->mst_port in
order to fixup
As mentioned in the previous commit, we currently prevent new modesets
on recently-removed MST connectors by returning no encoder from our
->best_encoder() callback once the MST port has disappeared. This is
wrong however, because it prevents legacy modesetting users from being
able to disable
Currently, i915 appears to rely on blocking modesets on
no-longer-present MSTB ports by simply returning NULL for
->best_encoder(), which in turn causes any new atomic commits that don't
disable the CRTC to fail. This is wrong however, since we still want to
allow userspace to disable CRTCs on
Since we need to be able to allow DPMS on->off prop changes after an MST
port has disappeared from the system, we need to be able to make sure we
can compute a config for the resulting atomic commit. Currently this is
impossible when the port has disappeared, since the VCPI slot searching
we try
With the exception of modesets which would switch the DPMS state of a
connector from on to off, we want to make sure that we disallow all
modesets which would result in enabling a new monitor or a new mode
configuration on a monitor if the connector for the display in question
is no longer
Latest version of https://patchwork.freedesktop.org/series/49878/
Lyude Paul (5):
drm/atomic_helper: Disallow new modesets on unregistered connectors
drm/nouveau: Fix nv50_mstc->best_encoder()
drm/i915: Don't unset intel_connector->mst_port
drm/i915: Skip vcpi allocation for MSTB ports
https://bugs.freedesktop.org/show_bug.cgi?id=99923
--- Comment #38 from Marek Olšák ---
The initial fix is here: https://reviews.llvm.org/D52907
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
https://bugs.freedesktop.org/show_bug.cgi?id=107928
--- Comment #6 from dwagner ---
@ Vik-T: Thanks for testing, so at least we know it's a different bug that
haunts your system.
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=108272
Jan Vesely changed:
What|Removed |Added
Blocks||99553
Depends on|99553
https://bugs.freedesktop.org/show_bug.cgi?id=108272
Jan Vesely changed:
What|Removed |Added
Depends on|99510 |99553
Referenced Bugs:
https://bugs.freedesktop.org/show_bug.cgi?id=99510
Jan Vesely changed:
What|Removed |Added
Blocks|108272 |
Referenced Bugs:
https://bugs.freedesktop.org/show_bug.cgi?id=99510
Jan Vesely changed:
What|Removed |Added
Blocks||108272
Referenced Bugs:
https://bugs.freedesktop.org/show_bug.cgi?id=108272
Jan Vesely changed:
What|Removed |Added
Depends on||99510
Summary|opencl-mesa:
https://bugzilla.kernel.org/show_bug.cgi?id=201275
--- Comment #30 from quirin.blae...@freenet.de ---
(In reply to Alex Deucher from comment #28)
> (In reply to quirin.blaeser from comment #27)
> > I can´t find "c3df50abc84b" from https://lkml.org/lkml/2018/9/15/172
> > but "drm/amd/pp: Convert
https://bugzilla.kernel.org/show_bug.cgi?id=201275
--- Comment #29 from quirin.blae...@freenet.de ---
Created attachment 278965
--> https://bugzilla.kernel.org/attachment.cgi?id=278965=edit
git diff -p
93b100ddda3be284be160e9ccba28c7f8f21ab73..93b100ddda3be284be160e9ccba28c7f8f21ab73^1
git
From: Colin Ian King
The NOUVEAU_GETPARAM_PCI_DEVICE case is missing a break statement and falls
through to the following NOUVEAU_GETPARAM_BUS_TYPE case and may end up
re-assigning the getparam->value to an undesired value. Fix this by adding
in the missing break.
Detected by CoverityScan,
https://bugzilla.kernel.org/show_bug.cgi?id=201275
--- Comment #28 from Alex Deucher (alexdeuc...@gmail.com) ---
(In reply to quirin.blaeser from comment #27)
> I can´t find "c3df50abc84b" from https://lkml.org/lkml/2018/9/15/172
> but "drm/amd/pp: Convert clock unit to KHz as defined" is
>
https://bugzilla.kernel.org/show_bug.cgi?id=201275
--- Comment #27 from quirin.blae...@freenet.de ---
I can´t find "c3df50abc84b" from https://lkml.org/lkml/2018/9/15/172
but "drm/amd/pp: Convert clock unit to KHz as defined" is
23ec3d1479fd79658cd52c47618d8ddd2f32550b
--
You are receiving this
https://bugzilla.kernel.org/show_bug.cgi?id=201275
--- Comment #26 from Alex Deucher (alexdeuc...@gmail.com) ---
(In reply to quirin.blaeser from comment #25)
> (In reply to Alex Deucher from comment #24)
> > This patch shouldn't have been applied to 4.18. It looks like it was
> > autoselected:
https://bugzilla.kernel.org/show_bug.cgi?id=201275
--- Comment #25 from quirin.blae...@freenet.de ---
(In reply to Alex Deucher from comment #24)
> This patch shouldn't have been applied to 4.18. It looks like it was
> autoselected:
> https://lkml.org/lkml/2018/9/15/172
> It should be reverted.
> -Original Message-
> From: Guenter Roeck On Behalf Of Guenter Roeck
> Sent: Monday, October 8, 2018 1:41 PM
> To: Deucher, Alexander
> Cc: Koenig, Christian ; Peng Hao
> ; airl...@linux.ie; linux-ker...@vger.kernel.org;
> dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org
>
From: Sean Paul
This patch uses the proper do_div() macro to perform u64 division and
guards against overflow if the result is too large for the unsigned long
return type
Fixes: a2c3c0a54d4c drm/msm/a6xx: Add devfreq support for a6xx
Cc: Sharat Masetty
Signed-off-by: Sean Paul
---
From: Sean Paul
A small fixup I posted with my v2 patch [1] that was dropped.
[1]- https://lists.freedesktop.org/archives/freedreno/2018-October/003647.html
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff
Am 08.10.2018 um 19:46 schrieb Guenter Roeck:
> On Mon, Oct 08, 2018 at 05:22:24PM +, Koenig, Christian wrote:
>> Am 08.10.2018 um 17:57 schrieb Deucher, Alexander:
>> One thing I found missing in the discussion was the reference to the
>> C standard.
>> The C99 standard states in
Am 08.10.2018 um 20:01 schrieb Nayan Deshmukh:
> Thanks for all the explanations. Looks like this part of scheduler has
> a lot of bugs.
>
> On Tue, Oct 9, 2018 at 2:55 AM Christian König
> wrote:
>> Am 08.10.2018 um 19:40 schrieb Nayan Deshmukh:
>>> Hi Christian,
>>>
>>> I am a bit confused with
Thanks for all the explanations. Looks like this part of scheduler has
a lot of bugs.
On Tue, Oct 9, 2018 at 2:55 AM Christian König
wrote:
>
> Am 08.10.2018 um 19:40 schrieb Nayan Deshmukh:
> > Hi Christian,
> >
> > I am a bit confused with this patch. It will be better if you can
> > explain
Am 08.10.2018 um 19:40 schrieb Nayan Deshmukh:
Hi Christian,
I am a bit confused with this patch. It will be better if you can
explain what these 3 functions are supposed to do. From my
understanding this is what they are supposed to do:
1. drm_sched_job_timedout: This function is called when
On Thu, Jun 14, 2018 at 09:01:10PM -0700, Abhinav Kumar wrote:
> Currenty the VCO rate in the 10nm PLL driver relies
> on the parent rate which is not configured.
>
> Configure the VCO rate to 19.2 Mhz as required by
> the 10nm PLL driver.
>
> Signed-off-by: Abhinav Kumar
Sorry for missing
On Mon, Oct 8, 2018 at 12:53 AM Zhou, David(ChunMing)
wrote:
> >> Another general comment (no good place to put it) is that I think we
> want two kinds of waits: Wait for time point to be completed and wait for
> time point to become available. The first is the usual CPU wait for
> completion
Hi Christian,
I am a bit confused with this patch. It will be better if you can
explain what these 3 functions are supposed to do. From my
understanding this is what they are supposed to do:
1. drm_sched_job_timedout: This function is called when a job has been
executing for more than "timeout"
On Tue, Oct 9, 2018 at 2:24 AM Christian König
wrote:
>
> Am 08.10.2018 um 16:40 schrieb Nayan Deshmukh:
> > On Mon, Oct 8, 2018 at 8:36 PM Christian König
> > wrote:
> >> Cleanup starting the timeout a bit.
> >>
> >> Signed-off-by: Christian König
> >> ---
> >>
Am 08.10.2018 um 16:40 schrieb Nayan Deshmukh:
On Mon, Oct 8, 2018 at 8:36 PM Christian König
wrote:
Cleanup starting the timeout a bit.
Signed-off-by: Christian König
---
drivers/gpu/drm/scheduler/sched_main.c | 29 +
1 file changed, 17 insertions(+), 12
Am 08.10.2018 um 17:57 schrieb Deucher, Alexander:
One thing I found missing in the discussion was the reference to the
C standard.
The C99 standard states in section 6.7.8 (Initialization) clause 19:
"... all
subobjects that are not initialized explicitly shall be
On 10/08, Chris Wilson wrote:
> Quoting Rodrigo Siqueira (2018-10-08 15:52:20)
> > For historical reason, the function drm_wait_vblank_ioctl always return
> > -EINVAL if something gets wrong. This scenario limits the flexibility
> > for the userspace make detailed verification of the problem and
From: Colin Ian King
There are several switch statements that are missing break statements.
Add missing breaks to handle any fall-throughs corner cases.
Detected by CoverityScan, CID#1457175 ("Missing break in switch")
Fixes: 18aafc59b106 ("drm/amd/powerplay: implement fw related smu interface
> -Original Message-
> From: Guenter Roeck On Behalf Of Guenter Roeck
> Sent: Monday, October 8, 2018 10:11 AM
> To: Koenig, Christian ; Peng Hao
>
> Cc: airl...@linux.ie; linux-ker...@vger.kernel.org; dri-
> de...@lists.freedesktop.org; amd-...@lists.freedesktop.org; Deucher,
>
'default n' is the default value for any bool or tristate Kconfig
setting so there is no need to write it explicitly.
Also since commit f467c5640c29 ("kconfig: only write '# CONFIG_FOO
is not set' for visible symbols") the Kconfig behavior is the same
regardless of 'default n' being present or
https://bugs.freedesktop.org/show_bug.cgi?id=107266
--- Comment #6 from dallase ---
amd-staging-drm-next (built Oct 7 2018)
[ 61.701281] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma0 timeout,
signaled seq=888, emitted seq=890
[ 61.701285] [drm] GPU recovery disabled.
[
On Wed, Oct 03, 2018 at 08:52:06AM +0530, Jagan Teki wrote:
> On Tuesday 02 October 2018 06:50 PM, Maxime Ripard wrote:
> > On Thu, Sep 27, 2018 at 11:15:50PM +0530, Jagan Teki wrote:
> > > On Thu, Sep 27, 2018 at 10:28 PM Maxime Ripard
> > > wrote:
> > > >
> > > > On Thu, Sep 27, 2018 at
On Mon, Oct 01, 2018 at 01:39:17PM +0530, Jagan Teki wrote:
> On Saturday 29 September 2018 07:23 PM, Maxime Ripard wrote:
> > On Thu, Sep 27, 2018 at 09:50:34PM +0530, Jagan Teki wrote:
> > > On Thu, Sep 27, 2018 at 8:51 PM Maxime Ripard
> > > wrote:
> > > >
> > > > On Thu, Sep 27, 2018 at
Quoting Rodrigo Siqueira (2018-10-08 15:52:20)
> For historical reason, the function drm_wait_vblank_ioctl always return
> -EINVAL if something gets wrong. This scenario limits the flexibility
> for the userspace make detailed verification of the problem and take
> some action. In particular, the
For historical reason, the function drm_wait_vblank_ioctl always return
-EINVAL if something gets wrong. This scenario limits the flexibility
for the userspace make detailed verification of the problem and take
some action. In particular, the validation of “if (!dev->irq_enabled)”
in the
https://bugs.freedesktop.org/show_bug.cgi?id=104289
Michel Dänzer changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
On Mon, Oct 8, 2018 at 8:36 PM Christian König
wrote:
>
> Cleanup starting the timeout a bit.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/scheduler/sched_main.c | 29 +
> 1 file changed, 17 insertions(+), 12 deletions(-)
>
> diff --git
On Mon, Oct 08, 2018 at 02:57:29PM +0530, Sravanthi Kollukuduru wrote:
> The interconnect framework is designed to provide a
> standard kernel interface to control the settings of
> the interconnects on a SoC.
>
> The interconnect API uses a consumer/provider-based model,
> where the providers
Since commit c86f51737f8d ("ARM: clps711x: Switch to MULTIPLATFORM")
ARCH_CLPS711X depends on ARCH_MULTIPLATFORM to be enabled so the old
CLPS711x LCD support driver (enabled by the FB_CLPS711X_OLD config
option) can't be selected any longer. Remove all FB_CLPS711XX_OLD
code as it has been dead
https://bugzilla.kernel.org/show_bug.cgi?id=201345
--- Comment #2 from Matthias Heinz (m...@familie-heinz.name) ---
Created attachment 278955
--> https://bugzilla.kernel.org/attachment.cgi?id=278955=edit
Shader clock and fps after setting performance level back to auto
--
You are receiving
https://bugzilla.kernel.org/show_bug.cgi?id=201345
--- Comment #1 from Matthias Heinz (m...@familie-heinz.name) ---
Created attachment 278953
--> https://bugzilla.kernel.org/attachment.cgi?id=278953=edit
Shader clock and fps after setting performance level to high
--
You are receiving this
https://bugzilla.kernel.org/show_bug.cgi?id=201345
Bug ID: 201345
Summary: Micro stuttering in RocketLeague
Product: Drivers
Version: 2.5
Kernel Version: 4.19.0-rc6
Hardware: x86-64
OS: Linux
Tree: Mainline
https://bugzilla.kernel.org/show_bug.cgi?id=201275
--- Comment #24 from Alex Deucher (alexdeuc...@gmail.com) ---
This patch shouldn't have been applied to 4.18. It looks like it was
autoselected:
https://lkml.org/lkml/2018/9/15/172
It should be reverted.
--
You are receiving this mail because:
On Mon, Oct 08, 2018 at 07:29:03PM +0530, Sharat Masetty wrote:
>
>
> On 10/5/2018 8:37 PM, Jordan Crouse wrote:
> >On Fri, Oct 05, 2018 at 06:38:35PM +0530, Sharat Masetty wrote:
> >>The last level system cache can be partitioned to 32 different slices
> >>of which GPU has two slices
On 10/5/2018 8:37 PM, Jordan Crouse wrote:
On Fri, Oct 05, 2018 at 06:38:35PM +0530, Sharat Masetty wrote:
The last level system cache can be partitioned to 32 different slices
of which GPU has two slices preallocated. One slice is used for caching GPU
buffers and the other slice is used for
Use REG_GET to avoid the temp variable.
Add pr_err_once if hdmi_cec_clear_tx_fifo() fails in hdmi4_cec_irq().
Signed-off-by: Hans Verkuil
---
Note: the FIFOs are cleared almost immediately (after just one try), so adding
delays is overkill.
---
diff --git
1 - 100 of 210 matches
Mail list logo
