https://bugs.freedesktop.org/show_bug.cgi?id=108919
--- Comment #4 from Evan Goers ---
I am using an RX580 and also have this issue. Forcing OpenGL 4.2(4.3 and above
causes the issue) with the mesa environment variable allows the game to run
without artifacts but some shaders do not work, such
On 12/6/2018 7:50 PM, Daniel Vetter wrote:
On Tue, Nov 27, 2018 at 04:13:31PM +0530, Ramalingam C wrote:
Implement the required WA sequence for KBL to fix the
incorrect positioning of the window of oppurtunity and enc_en
signalling.
Signed-off-by: Ramalingam C
---
On 12/6/2018 6:57 PM, Daniel Vetter wrote:
On Tue, Nov 27, 2018 at 04:13:07PM +0530, Ramalingam C wrote:
Implements the link integrity check once in 500mSec.
Once encryption is enabled, an ongoing Link Integrity Check is
performed by the HDCP Receiver to check that cipher synchronization
is
https://bugzilla.kernel.org/show_bug.cgi?id=201815
siyia (eutychio...@gmail.com) changed:
What|Removed |Added
Kernel Version|4.20rc3-rc4 |4.20rc3-rc5
--
You are
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #26 from Shmerl ---
And I don't see ERROR* REG_WAIT anymore. I'm using latest Vega firmware.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #25 from Shmerl ---
Just built 4.20-rc5+. This is indeed fixed, and KWin Wayland session is finally
working with DisplayPort 1.2 enabled!
--
You are receiving this mail because:
You are the assignee for the
On 12/6/2018 4:00 PM, Daniel Vetter wrote:
On Tue, Nov 27, 2018 at 04:13:04PM +0530, Ramalingam C wrote:
Considering that HDCP2.2 is more secure than HDCP1.4, When a setup
supports HDCP2.2 and HDCP1.4, HDCP2.2 will be enabled.
When HDCP2.2 enabling fails and HDCP1.4 is supported, HDCP1.4 is
https://bugzilla.kernel.org/show_bug.cgi?id=201815
--- Comment #7 from siyia (eutychio...@gmail.com) ---
A workaround that works is to enable software cursor in Xorg,
i edited 10-amdgpu.conf and 10-radeon.conf
and added:
Option "SWCursor" "True"
--
You are receiving this mail because:
You
On 12/6/2018 3:53 PM, Daniel Vetter wrote:
On Tue, Nov 27, 2018 at 04:13:03PM +0530, Ramalingam C wrote:
Defining the mei-i915 interface functions and initialization of
the interface.
Signed-off-by: Ramalingam C
Signed-off-by: Tomas Winkler
---
drivers/gpu/drm/i915/i915_drv.h | 2 +
https://bugzilla.kernel.org/show_bug.cgi?id=201815
--- Comment #6 from siyia (eutychio...@gmail.com) ---
that was an issue with the kernel fedora mainline repo, kernel 4.20rc5 boots on
my laptop on archlinux, but the mouse pointer issue remains
--
You are receiving this mail because:
You are
https://bugs.freedesktop.org/show_bug.cgi?id=108892
--- Comment #6 from Zheng Luo ---
(In reply to sunnanyong from comment #5)
> Hi brother , does the kernel upgrade work？
I switched between 4.19 and 4.20rc4/5 these days. However with none of the two
kernels I can reproduce this bug.
--
You
On 12/6/2018 3:33 PM, Daniel Vetter wrote:
On Tue, Nov 27, 2018 at 04:13:02PM +0530, Ramalingam C wrote:
Add the HDCP2.2 initialization to the existing HDCP1.4 stack.
With the comments below addressed the commit message is a bit untrue,
since this just wires up a basic hdcp2_supported flag in
> -Original Message-
> From: dri-devel On Behalf Of
> Andrey Grodzovsky
> Sent: Friday, December 07, 2018 1:41 AM
> To: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org;
> ckoenig.leichtzumer...@gmail.com; e...@anholt.net;
> etna...@lists.freedesktop.org
> Cc: Liu, Monk
>
msm maintains a separate structure to define vblank
work definitions and a list to track events submitted
to the workqueue. We can avoid this redundant list
and its protection mechanism, if we subclass the
work object to encapsulate vblank event parameters.
changes in v2:
- subclass
msm is using msm wq for dispatching commit and vblank
events. Switch idle power collapse feature also to use
msm wq to handle delayed work handlers so that
msm can get rid of redundant display threads.
changes in v2:
- patch introduced in v2
changes in v3:
- none
changes in v4:
use kthread_destroy_worker to destroy workers and
release their associated kthreads.
changes in v3:
- introduced in the series
changes in v4:
- none
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/msm_drv.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
Since there are no clients using these threads,
cleaning it up.
changes in v2:
- switch all the dependent clients to use system wq
before removing the disp_threads (Sean Paul)
changes in v3:
- none
changes in v4:
- none
Signed-off-by: Jeykumar Sankaran
---
DPU was using one thread per display to dispatch async commits and
vblank requests. Since clean up already happened in msm to use the
common thread for all the display commits, display threads are only
used to cater vblank requests. Since a single thread is sufficient
to do the job without any
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c
between commit:
c679fd55 ("drm/amd/display: Fix 6x4K displays light-up on Vega20 (v2)")
from the drm-fixes tree and commit:
24f7dd7ea98d
On 2018-12-06 10:56, Jeykumar Sankaran wrote:
On 2018-11-07 07:55, Sean Paul wrote:
On Tue, Nov 06, 2018 at 02:36:30PM -0800, Jeykumar Sankaran wrote:
msm maintains a separate structure to define vblank
work definitions and a list to track events submitted
to the workqueue. We can avoid this
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
between commit:
49f1c44b581b ("rm/amd/display: Fix unintialized max_bpc state values")
from the drm-fixes tree and commits:
c1ee92f94ce3 ("drm/amd: Add abm level drm
On Fri, Nov 30, 2018 at 10:46:04AM +0100, Daniel Vetter wrote:
> > Being able to dip into CMA and maybe iommu coalescing if we want to
> > get fancy is indeed the only reason for this API. If we just wanted
> > to map pages we could already do that now with just a little bit
> > of boilerplate
Hi Linus,
This is the regular fixes pull. I'm off on holidays for a few days but
will likely still have access to stuff, just not doing much else, I
should be back for 2 days at the end of next week to line up more
fixes, and likely send you the -next pull request before going on
holidays until
Hi Andrzej,
18. 12. 6. 오후 8:06에 Andrzej Hajda 이(가) 쓴 글:
> Hi Inki,
>
> On 06.12.2018 10:38, Andrzej Hajda wrote:
>> Hi Inki,
>>
>> This small patchset adds dynamic zpos support for DECON and FIMD.
>> It was tested on tm2 and trats2.
>
>
> I have realized that this patchset interferes with
On Thu, Dec 06, 2018 at 12:32:47PM +, Kieran Bingham wrote:
> My main initial idea for a libumlinux is to provide infrastructure such
> as our linked-lists and other kernel formatting so that we can take
> kernel code directly to userspace for test and debug (assuming that
> there are no
On Wed, Dec 5, 2018 at 5:43 PM Brendan Higgins
wrote:
>
> On Tue, Dec 4, 2018 at 5:41 AM Rob Herring wrote:
> >
> > On Mon, Dec 3, 2018 at 6:14 PM Brendan Higgins
> > wrote:
> > >
> > > On Thu, Nov 29, 2018 at 4:40 PM Randy Dunlap
> > > wrote:
> > > >
> > > > On 11/28/18 12:56 PM, Rob Herring
On Thu, Dec 06, 2018 at 02:48:36PM +0530, Swati Sharma wrote:
> Fix the skip for kms_color/gamma subtest
>
> Test requirement not met in function run_tests_for_pipe, file kms_color.c:858:
> Test requirement: igt_pipe_obj_has_prop(>display.pipes[p],
> IGT_CRTC_DEGAMMA_LUT_SIZE)
> Subtest
On Wed, Nov 21, 2018 at 08:48:00AM +, eugen.hris...@microchip.com wrote:
> From: Cristian Birsan
>
> PDA 91-00156-A0 5.0 is a 5.0" WVGA TFT LCD panel.
> This panel with backlight is found in PDA 5" LCD screen (TM5000 series or
> AC320005-5).
> Adding Device Tree bindings for this panel.
>
>
On Wed, 21 Nov 2018 08:47:57 +, wrote:
> Precision Design Associates, Inc. (PDA) manufactures standard and custom
> capacitive touch screens, LCD's embedded controllers and custom embedded
> software. They specialize in industrial, rugged and outdoor applications.
> Website:
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #24 from Shmerl ---
Does KWin Wayland session work for you now? It was crashing also because of
this.
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #23 from Sibren Vasse ---
Switching to tty now works for me , I still get the [drm:generic_reg_wait
[amdgpu]] *ERROR* REG_WAIT timeout 10us * 3000 tries -
dce110_stream_encoder_dp_blank line:944 message though
--
You are receiving
o build test ERROR on v4.20-rc5]
> [cannot apply to next-20181206]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/jglisse-redhat-com/mmu-notifier-contextual-informati
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #22 from Shmerl ---
Great news! Debian didn't get 4.20 rc kernels yet, but I can try building one
from source to test.
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #21 from Sibren Vasse ---
(In reply to Jerry Zuo from comment #20)
> The fix is showing up since 4.20-rc5. Please give a try.
4.20-rc5 solves the problem for me!
--
You are receiving this mail because:
You are the assignee for
On 12/06/2018 01:33 PM, Christian König wrote:
> Am 06.12.18 um 18:41 schrieb Andrey Grodzovsky:
>> Decauple sched threads stop and start and ring mirror
>> list handling from the policy of what to do about the
>> guilty jobs.
>> When stoppping the sched thread and detaching sched fences
>> from
Decauple sched threads stop and start and ring mirror
list handling from the policy of what to do about the
guilty jobs.
When stoppping the sched thread and detaching sched fences
from non signaled HW fenes wait for all signaled HW fences
to complete before rerunning the jobs.
v2: Fix
Expedite job deletion from ring mirror list to the HW fence signal
callback instead from finish_work, together with waiting for all
such fences to signal in drm_sched_stop we garantee that
already signaled job will not be processed twice.
Remove the sched finish fence callback and just submit
Hi Jérôme,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.20-rc5]
[cannot apply to next-20181206]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com
Hi Jérôme,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.20-rc5]
[cannot apply to next-20181206]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com
Hi Jérôme,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.20-rc5]
[cannot apply to next-20181206]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #20 from Jerry Zuo ---
The fix is showing up since 4.20-rc5. Please give a try.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
Hi Jérôme,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.20-rc5]
[cannot apply to next-20181206]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com
The TFP410 supports configurable pixel clock sampling edge and data
de-skew adjustments. The configuration can be set through I2C or
dedicated chip pins.
Report the configuration through the drm_bridge timings. As the
ti-tftp410 driver doesn't support configuring the chip through I2C, we
simply
The TFP410 supports configuration of several input bus parameters
through either the I2C port or chip pins. In the latter case, we need to
specify those parameters in DT.
Two new properties are added, ti,deskew to specify the data de-skew
configuration (as set through the DK[3:1] pins), and
Hello,
This small patch series improves the ti-tfp410 driver with three new features,
in patch 2/5 to 5/5. Patch 1/5 has been previously posted by Stefan, and I've
included it here to support patch 5/5 that needs to store other polarity
information in the bridge timings than the sampling edges.
From: Stefan Agner
The DRM bus flags convey additional information on pixel data on
the bus. All current available bus flags might be of interest for
a bridge. Remove the sampling_edge field and use bus_flags.
In the case at hand a dumb VGA bridge needs a specific data enable
polarity
The TFP410 has a powerdown pin that can be connected to a GPIO to
control power saving. The DT bindings define a corresponding property,
but the driver doesn't implement support for it. Fix that.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/ti-tfp410.c | 24
The TI TFP410 is a DVI encoder, not a full HDMI encoder. Its output can
be routed to a DVI-D connector, even if in many cases embedded systems
will use an HDMI connector to carry the DVI signals.
Instead of hardcoding the connector type to HDMI, retrieve the connector
type from its DT node.
On Thu, 06 Dec 2018 10:59:17 -0800
Eric Anholt wrote:
> > +
> > + /*
> > +* SCALER_PITCH0_SINK_PIX does not seem to work for SAND
> > +* formats. Specify a negative START_X instead, even if it's
> > +* less efficient.
> > +*/
> > +
Boris Brezillon writes:
> Hello,
>
> As suggested by Ville, this version uses the already available TV
> margin props to define left/right/top/bottom margins insted of adding
> new underscan props.
>
> This works pretty well for what we want to do in VC4: allow one to
> define the visible area
Boris Brezillon writes:
> Add support for X/Y reflection when the plane is using linear or T-tiled
> formats. X/Y reflection hasn't been tested on SAND formats, so we reject
> them until proper testing/debugging has been done.
>
> Signed-off-by: Boris Brezillon
> ---
> Eric, I dropped your
Boris Brezillon writes:
> Commit 3e407417b192 ("drm/vc4: Fix X/Y positioning of planes using
> T_TILES modifier") fixed the problem with T_TILES format, but left
> things in a non-working state for SAND formats. Address that now.
>
> Signed-off-by: Boris Brezillon
> ---
> Hi Eric,
>
> So, I
On 2018-11-07 07:55, Sean Paul wrote:
On Tue, Nov 06, 2018 at 02:36:30PM -0800, Jeykumar Sankaran wrote:
msm maintains a separate structure to define vblank
work definitions and a list to track events submitted
to the workqueue. We can avoid this redundant list
and its protection mechanism, if
Am 06.12.18 um 18:41 schrieb Andrey Grodzovsky:
Decauple sched threads stop and start and ring mirror
list handling from the policy of what to do about the
guilty jobs.
When stoppping the sched thread and detaching sched fences
from non signaled HW fenes wait for all signaled HW fences
to
Am 06.12.18 um 17:58 schrieb Chris Wilson:
> Quoting jgli...@redhat.com (2018-12-06 15:47:04)
>> From: Jérôme Glisse
>>
>> The debugfs take reference on fence without dropping them. Also the
>> rcu section are not well balance. Fix all that ...
> Wouldn't the code be a lot simpler (and a
Am 06.12.18 um 17:18 schrieb jgli...@redhat.com:
> From: Jérôme Glisse
>
> The debugfs take reference on fence without dropping them.
>
> Signed-off-by: Jérôme Glisse
> Cc: Christian König
> Cc: Daniel Vetter
> Cc: Sumit Semwal
> Cc: linux-me...@vger.kernel.org
> Cc:
On 12/06/2018 12:41 PM, Andrey Grodzovsky wrote:
> Expedite job deletion from ring mirror list to the HW fence signal
> callback instead from finish_work, together with waiting for all
> such fences to signal in drm_sched_stop we garantee that
> already signaled job will not be processed twice.
>
From: Thierry Reding
Remove the temporary workaround of storing the Tegra186 HDMI/DP I/O pad
ID in the SOR driver. The definition has long been available in the
soc/tegra/pmc.h header file.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/sor.c | 8
1 file changed, 8
From: Thierry Reding
If the SOR is already up and running when the kernel driver is probed,
setting a mode will typically fail. This can be seen for example on
Jetson TX2. Under certain circumstances the generic power domain code
will cause the SOR to be reset. However, if the power domain is
Decauple sched threads stop and start and ring mirror
list handling from the policy of what to do about the
guilty jobs.
When stoppping the sched thread and detaching sched fences
from non signaled HW fenes wait for all signaled HW fences
to complete before rerunning the jobs.
Suggested-by:
Expedite job deletion from ring mirror list to the HW fence signal
callback instead from finish_work, together with waiting for all
such fences to signal in drm_sched_stop we garantee that
already signaled job will not be processed twice.
Remove the sched finish fence callback and just submit
On 2018-12-06 5:46 p.m., Joe Perches wrote:
> On Thu, 2018-12-06 at 17:39 +0800, Zhang, Jerry(Junwei) wrote:
>> On 12/6/18 5:33 PM, Koenig, Christian wrote:
>>> Am 06.12.18 um 10:09 schrieb Michel Dänzer:
On 2018-12-06 3:43 a.m., Zhang, Jerry(Junwei) wrote:
> On 12/6/18 12:56 AM, Michel
Quoting jgli...@redhat.com (2018-12-06 15:47:04)
> From: Jérôme Glisse
>
> The debugfs take reference on fence without dropping them. Also the
> rcu section are not well balance. Fix all that ...
Wouldn't the code be a lot simpler (and a consistent snapshot) if it used
On Thu, 2018-12-06 at 17:39 +0800, Zhang, Jerry(Junwei) wrote:
> On 12/6/18 5:33 PM, Koenig, Christian wrote:
> > Am 06.12.18 um 10:09 schrieb Michel Dänzer:
> > > On 2018-12-06 3:43 a.m., Zhang, Jerry(Junwei) wrote:
> > > > On 12/6/18 12:56 AM, Michel Dänzer wrote:
> > > > > From: Michel Dänzer
Replace internal usage of struct videomode with struct drm_display_mode
in order to avoid converting needlessly between the data structures.
Signed-off-by: Laurent Pinchart
---
Changes since v1:
- Set mode.crtc_* fields and mode name in venc_check_timings()
---
On Thu, 2018-12-06 at 15:41 +0100, Michel Dänzer wrote:
> On 2018-12-06 1:23 p.m., Joe Perches wrote:
> > On Thu, 2018-12-06 at 12:52 +0100, Michel Dänzer wrote:
> > > In contrast to the 2b case, the pr_debug output isn't visible by default
> > > with 1b, so the latter doesn't fit "always produce
On Thu, Dec 06, 2018 at 04:08:12PM +, Koenig, Christian wrote:
> Am 06.12.18 um 16:21 schrieb Jerome Glisse:
> > On Thu, Dec 06, 2018 at 08:09:28AM +, Koenig, Christian wrote:
> >> Am 06.12.18 um 02:41 schrieb jgli...@redhat.com:
> >>> From: Jérôme Glisse
> >>>
> >>> The debugfs take
From: Jérôme Glisse
The debugfs take reference on fence without dropping them.
Signed-off-by: Jérôme Glisse
Cc: Christian König
Cc: Daniel Vetter
Cc: Sumit Semwal
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Cc: Stéphane Marchesin
the default is -1 (auto). Power management has always been enabled by
default on CI. the option is mainly there to disable power management
(amdgpu.dpm=0). Since there are two implementations for CI (the older
one ported from radeon and the newer powerplay one), explicitly
setting it to 1 was
On Thu, Dec 06, 2018 at 12:16:53PM +0530, Jayant Shekhar wrote:
> _dpu_crtc_vblank_enable_no_lock releases crtc_lock as
> its needed for power handle operations. This opens up a
> window where in a thread running dpu_crtc_disable and a thread
> running dpu_crtc_vblank can race in using
On 2018-12-06 5:10 p.m., Daniel Thompson wrote:
> On Thu, Dec 06, 2018 at 03:41:16PM +0100, Michel Dänzer wrote:
>> On 2018-12-06 1:23 p.m., Joe Perches wrote:
>>> On Thu, 2018-12-06 at 12:52 +0100, Michel Dänzer wrote:
In contrast to the 2b case, the pr_debug output isn't visible by default
OK, thanks. Although for reference, if DPM is now enabled by default I
would have expected amdgpu.dpm=1 to be a no-op rather than cause a black
screen and an oops... ;-).
Cheers,
Chris
On Thu, 6 Dec 2018 at 16:09, Alex Deucher wrote:
> Then you should be fine to remove it.
>
> Alex
> On Thu,
On Wed, Dec 05, 2018 at 09:51:47PM +0530, Jayant Shekhar wrote:
> In case of msm drm bind failure, pm runtime put sync
> is called from dsi driver which issues an asynchronous
> put on mdss device. Subsequently when dpu_mdss_destroy
> is triggered the change will make sure to put the mdss
> device
On Thu, Dec 06, 2018 at 03:41:16PM +0100, Michel Dänzer wrote:
> On 2018-12-06 1:23 p.m., Joe Perches wrote:
> > On Thu, 2018-12-06 at 12:52 +0100, Michel Dänzer wrote:
> >> In contrast to the 2b case, the pr_debug output isn't visible by default
> >> with 1b, so the latter doesn't fit "always
Then you should be fine to remove it.
Alex
On Thu, Dec 6, 2018 at 10:58 AM Chris Rankin wrote:
>
> Yes, all 4.19.x kernels have been fine without the amdgpu.dpm=1 kernel
> parameter. In fact, this is how I am running my kernel right now. With the
> 4.18.x series I did specify amdgpu.dpm=1
Am 06.12.18 um 16:21 schrieb Jerome Glisse:
> On Thu, Dec 06, 2018 at 08:09:28AM +, Koenig, Christian wrote:
>> Am 06.12.18 um 02:41 schrieb jgli...@redhat.com:
>>> From: Jérôme Glisse
>>>
>>> The debugfs take reference on fence without dropping them. Also the
>>> rcu section are not well
Yes, all 4.19.x kernels have been fine without the amdgpu.dpm=1 kernel
parameter. In fact, this is how I am running my kernel right now. With the
4.18.x series I did specify amdgpu.dpm=1 explicitly on the GRUB2 command
line, and I inherited this setting when I migrated to 4.19.
On Thu, 6 Dec 2018
Does it work without amdgpu.dpm=1 on your kernel command line? You
don't need to specify it, it;s enabled by default. The default dpm
implementation changed so specifying dpm=1 will change the dpm
implementation used by the driver.
Alex
On Thu, Dec 6, 2018 at 10:47 AM Alex Deucher wrote:
>
> I
From: Jérôme Glisse
The debugfs take reference on fence without dropping them. Also the
rcu section are not well balance. Fix all that ...
Changed since v1:
- moved fobj logic around to be rcu safe
Signed-off-by: Jérôme Glisse
Cc: Christian König
Cc: Daniel Vetter
Cc: Sumit Semwal
Cc:
I can't reproduce this. Can you bisect?
Alex
On Thu, Dec 6, 2018 at 8:38 AM Chris Rankin wrote:
>
> Hi,
>
> I'm still unable to enable DPM with my R7 360, AMDGPU driver, Linux 4.19.7
> kernel. Dmesg log is attached, showing that it is correctly using PCIE gen2
> speeds.
>
> Cheers,
> Chris
>
https://bugzilla.kernel.org/show_bug.cgi?id=201815
--- Comment #5 from siyia (eutychio...@gmail.com) ---
kernel 4.20rc5 completely broke on my laptop cannot boot or look at logs it
freezes after grub with cursor blink and cpu fan at 100%
--
You are receiving this mail because:
You are watching
KASAN caught something during today's piglit run, see the attached dmesg
excerpt.
Looks like amdgpu destroys the VM while the scheduler still has a
reference to its entity?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast |
On Thu, Dec 06, 2018 at 08:09:28AM +, Koenig, Christian wrote:
> Am 06.12.18 um 02:41 schrieb jgli...@redhat.com:
> > From: Jérôme Glisse
> >
> > The debugfs take reference on fence without dropping them. Also the
> > rcu section are not well balance. Fix all that ...
> >
> > Signed-off-by:
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Lyude Paul
commit 97b2a3180a559a33852ac0cd77904166069484fd upstream.
Currently on driver bringup with KASAN enabled, meson triggers an OOB
memory access as shown below:
[ 117.904528]
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Lyude Paul
commit 995b278e4723b26f8ebf0e7c119286d16c712747 upstream.
Seeing as we use this registermap in the context of our IRQ handlers, we
need to be using spinlocks for reading/writing
On 2018-12-06 1:23 p.m., Joe Perches wrote:
> On Thu, 2018-12-06 at 12:52 +0100, Michel Dänzer wrote:
>> In contrast to the 2b case, the pr_debug output isn't visible by default
>> with 1b, so the latter doesn't fit "always produce output" either.
>
> I think you are mistaken here.
Still puzzled
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Lyude Paul
commit 97b2a3180a559a33852ac0cd77904166069484fd upstream.
Currently on driver bringup with KASAN enabled, meson triggers an OOB
memory access as shown below:
[ 117.904528]
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Lyude Paul
commit 995b278e4723b26f8ebf0e7c119286d16c712747 upstream.
Seeing as we use this registermap in the context of our IRQ handlers, we
need to be using spinlocks for reading/writing
>
> On Thu, Dec 06, 2018 at 05:55:58AM -0500, Frediano Ziglio wrote:
> >
> > > qxl surfaces (used for framebuffers and gem objects) can live in both
> > > VRAM and PRIV ttm domains. Update placement setup to include both. Put
> > > PRIV first in the list so it is preferred, so VRAM will have
On Tue, Nov 27, 2018 at 04:12:58PM +0530, Ramalingam C wrote:
> This series enables the HDCP2.2 for I915. The sequence for HDCP2.2
> authentication and encryption is implemented as a generic flow
> between HDMI and DP. Encoder specific implementations are moved
> into hdcp_shim.
>
> Intel HWs
qdev->monitors_config->max_allowed is effectively set by the
qxl.num_heads module parameter, stored in the qxl_num_crtc variable.
Lets get rid of the indirection and use the variable qxl_num_crtc
directly. The kernel doesn't need to dereference pointers each time it
needs the value, and when
Now that the plane code takes the margins setup into account, we can
safely attach margin props to the HDMI connector.
We also take care of filling AVI infoframes correctly to expose the
top/botton/left/right bar.
Note that those margin props match pretty well the
Applyin margins is just a matter of scaling all planes appropriately
and adjusting the CRTC X/Y offset to account for the
left/right/top/bottom borders.
Create a vc4_plane_margins_adj() function doing that and call it from
vc4_plane_setup_clipping_and_scaling() so that we are ready to attach
TV margins properties can only be added as part of the SDTV TV
connector properties creation, but we might need those props for HDMI
TVs too, so let's move the margins props creation in a separate
function and expose it to drivers.
We also add an helper to attach margins props to a connector.
All margins are expressed in pixels. Clarify that in the doc.
Signed-off-by: Boris Brezillon
---
include/drm/drm_connector.h | 2 +-
include/drm/drm_mode_config.h | 8
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/include/drm/drm_connector.h
Hello,
As suggested by Ville, this version uses the already available TV
margin props to define left/right/top/bottom margins insted of adding
new underscan props.
This works pretty well for what we want to do in VC4: allow one to
define the visible area on a TV.
The first 2 patches are fixing
The in the kernel-doc header did not match the function name.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/drm_connector.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index fa9baacc863b..408082a57171
> > qdev->monitors_config->max_allowed is effectively set by a module
> > parameter. So using the module parameter variable qxl_num_crtc
> > directly is better IMO. The kernel doesn't need to dereference pointers
> > each time it needs the value, and when reading the code you don't have
> > to
On Tue, Nov 27, 2018 at 04:13:31PM +0530, Ramalingam C wrote:
> Implement the required WA sequence for KBL to fix the
> incorrect positioning of the window of oppurtunity and enc_en
> signalling.
>
> Signed-off-by: Ramalingam C
> ---
> drivers/gpu/drm/i915/intel_hdcp.c | 29
On Tue, Nov 27, 2018 at 04:13:30PM +0530, Ramalingam C wrote:
> Commits the content protection change of a connector,
> without crtc modeset. This improves the user experience.
>
> Originally proposed by Sean Paul at v3 of HDCP1.4 framework
> https://patchwork.freedesktop.org/patch/191759/. For
1 - 100 of 204 matches
Mail list logo
