arg.version is indirectly controlled by user-space, hence leading to
a potential exploitation of the Spectre variant 1 vulnerability.
This issue was detected with the help of Smatch:
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:4526 vmw_execbuf_ioctl() warn:
potential spectre issue 'copy_offset' [w]
On 15/08/2018 at 22:40, Sam Ravnborg wrote:
Hi Lee.
+
+static const struct mfd_cell lcdc_cells[] = {
+ {
+ .name = "atmel-lcdc-pwm",
+ .of_compatible = "atmel,lcdc-pwm",
+ },
+ {
+ .name = "atmel-lcdc-dc",
+
https://bugs.freedesktop.org/show_bug.cgi?id=107572
--- Comment #11 from madc...@atlas.cz ---
Just out of curiosity, do either of you have a card that is supposed to have
some small overclocking done by the manufacturer? My RX570 is supposed to have
this and I’m wondering if it could be
On Tue, Aug 14, 2018 at 05:12:25PM +0300, Eugeniy Paltsev wrote:
> Hi Lucas, Christoph,
>
> After switching ARC to generic dma_noncoherent cache ops
> etnaviv driver start failing on dma maping functions because of
> dma_mask lack.
>
> So I'm wondering is it valid case to have device which is
>
We got a bug report that this function oopses when trying to do a kasprintf().
PC is at string+0x2c/0x60
LR is at vsnprintf+0x28c/0x4ec
pc : [] lr : [] pstate: a0c00049
sp : ff80095fb540
x29: ff80095fb540 x28: ff8008ad42bc
x27: ffd8 x26:
x25:
On Monday, 13 August 2018 20:48:25 MSK Dmitry Osipenko wrote:
> On Friday, 10 August 2018 02:12:11 MSK Dmitry Osipenko wrote:
> > From time to time new bugs are popping up, causing some host1x client to
> > fail its initialization. Currently a single clients initialization failure
> > causes whole
for_each_available_child_of_node will get and put the node properly,
the following of_node_put will lead to the double put. So just
remove it.
Signed-off-by: zhong jiang
---
drivers/gpu/drm/zte/zx_drm_drv.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git
On 2018-08-03 10:51, jacopo mondi wrote:
> On Fri, Aug 03, 2018 at 10:40:02AM +0200, Peter Rosin wrote:
>> On 2018-08-03 10:11, jacopo mondi wrote:
>>> Hi Peter!
>>>
>>> On Fri, Aug 03, 2018 at 09:23:07AM +0200, Peter Rosin wrote:
With bus-type/bus-width properties in the endpoint nodes, the
From: Randy Dunlap
Spell the vesafb "inverse" option correctly and tell what it does.
Signed-off-by: Randy Dunlap
Cc: Bartlomiej Zolnierkiewicz
Cc: dri-devel@lists.freedesktop.org
Cc: linux-fb...@vger.kernel.org
Cc: Jonathan Corbet
Cc: linux-...@vger.kernel.org
Cc: Antonino A. Daplas
---
Fix comile warning like,
CC [M] drivers/gpu/drm/i915/gvt/execlist.o
CC [M] drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.o
CC [M] drivers/gpu/drm/radeon/btc_dpm.o
CC [M] drivers/isdn/hisax/avm_a1p.o
CC [M] drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_dpp.o
On Thu, Aug 16, 2018 at 12:31 AM Daniel Vetter wrote:
>
> On Wed, Aug 15, 2018 at 03:49:14PM -0400, Sean Paul wrote:
> > From: Guenter Roeck
> >
> > 0day reports:
> >
> > >> drivers/gpu/drm/bridge/ti-sn65dsi86.o: In function
> > `ti_sn_bridge_remove':
> > >>
On Thu, 16 Aug 2018, Daniel Vetter wrote:
> On Thu, Aug 16, 2018 at 02:54:14PM -0400, Sean Paul wrote:
>> From: Sean Paul
>>
>> DRM_MIPI_DSI is included via both "select" and "depends on", this is
>> trouble waiting to happen since this will result in different behavior
>> depending on which is
On Fri, Aug 17, 2018 at 12:22 AM, John Stultz wrote:
> On Thu, Aug 16, 2018 at 3:16 PM, Daniel Vetter wrote:
>> On Thu, Aug 16, 2018 at 11:21 PM, John Stultz wrote:
>>> On Thu, Aug 16, 2018 at 1:46 PM, Daniel Vetter wrote:
You happen to have set drm_fb_overalloc respectively
https://bugs.freedesktop.org/show_bug.cgi?id=107595
--- Comment #5 from Przemek ---
Full valid git bisect log:
git bisect log
git bisect start
# bad: [5024f8dfe478c1f56ef8812dabc55f2793024e93] drm/amdgpu:change VEGA
booting with firmware loaded by PSP
git bisect bad
On Fri, Aug 17, 2018 at 10:21:38AM +0200, Thomas Zimmermann wrote:
> The gma500 driver has no dependencies on drm_global.h. Remove the include
> statement.
>
> Signed-off-by: Thomas Zimmermann
Applied, thanks for your patch.
-Daniel
> ---
> drivers/gpu/drm/gma500/psb_drv.h | 1 -
> 1 file
The gma500 driver has no dependencies on drm_global.h. Remove the include
statement.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/gma500/psb_drv.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/gma500/psb_drv.h b/drivers/gpu/drm/gma500/psb_drv.h
index
https://bugs.freedesktop.org/show_bug.cgi?id=105880
--- Comment #38 from Chí-Thanh Christopher Nguyễn ---
Created attachment 141163
--> https://bugs.freedesktop.org/attachment.cgi?id=141163=edit
patch against 4.18.1
I tried the latest patch too, and LVDS is now working (as expected, VGA does
https://bugs.freedesktop.org/show_bug.cgi?id=107482
Michel Dänzer changed:
What|Removed |Added
CC||sunpeng...@amd.com
--- Comment #6 from
Am 17.08.2018 um 12:08 schrieb Huang Rui:
I continue to work for bulk moving that based on the proposal by Christian.
Background:
amdgpu driver will move all PD/PT and PerVM BOs into idle list. Then move all of
them on the end of LRU list one by one. Thus, that cause so many BOs moved to
the
https://bugs.freedesktop.org/show_bug.cgi?id=107454
--- Comment #3 from amonpaike ---
today the repository padoka ppa has updated the drivers so I could test blender
2.8 ... all the problems are now solved! (Except the shadow ESMs that probably
depend on blender, I will present to the blender
On Thu, Aug 09, 2018 at 01:48:42PM +0100, Chris Wilson wrote:
> Quoting Daniel Vetter (2018-08-09 13:45:44)
> > dma_fence_default_wait is the default now, same for the trivial
> > enable_signaling implementation.
> >
> > Also remove the ->signaled callback, vgem can't peek ahead with a
> >
https://bugs.freedesktop.org/show_bug.cgi?id=107482
--- Comment #7 from Sebastian Luncan ---
(In reply to Michel Dänzer from comment #6)
> Can you try if current upstream xf86-video-amdgpu Git master works better
> with DC?
It's the same.
I've also tried videos with gamma 3. All hardware
The idea and proposal is originally from Christian, and I continue to work to
deliver it.
Background:
amdgpu driver will move all PD/PT and PerVM BOs into idle list. Then move all of
them on the end of LRU list one by one. Thus, that cause so many BOs moved to
the end of the LRU, and impact
From: Christian König
Add bulk move pos to store the pointer of first and last buffer object.
The list in between will be bulk moved on lru list.
Signed-off-by: Christian König
Signed-off-by: Huang Rui
Tested-by: Mike Lothian
Tested-by: Dieter Nützel
Acked-by: Chunming Zhou
Reviewed-by:
From: Christian König
When move a BO to the end of LRU, it need remember the BO positions.
Make sure all moved bo in between "first" and "last". And they will be bulk
moving together.
Signed-off-by: Christian König
Signed-off-by: Huang Rui
Tested-by: Mike Lothian
Tested-by: Dieter Nützel
https://bugs.freedesktop.org/show_bug.cgi?id=107572
--- Comment #12 from Paju ---
I'm using reference RX480 with default clocks.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
https://bugzilla.kernel.org/show_bug.cgi?id=199425
Daniel Vetter (dan...@ffwll.ch) changed:
What|Removed |Added
CC||dan...@ffwll.ch
---
From: Nickey Yang
Support Kingdisplay kd097d04 9.7" 1536x2048 TFT LCD panel,
it is a MIPI dual-DSI panel.
v4:
- address Philipp's comments
- real range for usleep_range and
- poweroff ordering in kingdisplay_panel_prepare
- return value beautification in panel_probe
- update author naming
On Thu, Aug 16, 2018 at 02:54:14PM -0400, Sean Paul wrote:
> From: Sean Paul
>
> DRM_MIPI_DSI is included via both "select" and "depends on", this is
> trouble waiting to happen since this will result in different behavior
> depending on which is used.
>
> This patch resolves the problem by:
>
https://bugs.freedesktop.org/show_bug.cgi?id=107559
--- Comment #4 from zamundaa...@gmail.com ---
With amdgpu.dc=0 it seems to work just fine. I've booted up with my normal
setup, switched the cables so I am connected by HDMI directly and I get good
colors
--
You are receiving this mail
https://bugs.freedesktop.org/show_bug.cgi?id=107559
--- Comment #2 from zamundaa...@gmail.com ---
Created attachment 141164
--> https://bugs.freedesktop.org/attachment.cgi?id=141164=edit
dmesg with amdgpu.dc=0
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=107559
--- Comment #3 from zamundaa...@gmail.com ---
Created attachment 141165
--> https://bugs.freedesktop.org/attachment.cgi?id=141165=edit
dmesg with amdgpu.dc=1
--
You are receiving this mail because:
You are the assignee for the
On Thu, Aug 16, 2018 at 08:41:44AM +0800, Dieter Nützel wrote:
> For the series
>
> Tested-by: Dieter Nützel
>
> on RX580,
> amd-staging-drm-next
> #5024f8dfe478
>
Thank you so much, will add tested-by in next version.
Thanks,
Ray
> Dieter
>
> Am 13.08.2018 11:58, schrieb Huang Rui:
> >
The new bulk moving functionality is ready, the overhead of moving PD/PT bos to
LRU is fixed. So move them on LRU again.
Signed-off-by: Huang Rui
Tested-by: Mike Lothian
Tested-by: Dieter N??tzel
Acked-by: Chunming Zhou
Reviewed-by: Junwei Zhang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c |
This function allow us to bulk move a group of BOs to the tail of their LRU.
The positions of group of BOs are stored on the (first, last) bulk_move_pos
structure.
Signed-off-by: Christian König
Signed-off-by: Huang Rui
Tested-by: Mike Lothian
Tested-by: Dieter Nützel
Acked-by: Chunming Zhou
I continue to work for bulk moving that based on the proposal by Christian.
Background:
amdgpu driver will move all PD/PT and PerVM BOs into idle list. Then move all of
them on the end of LRU list one by one. Thus, that cause so many BOs moved to
the end of the LRU, and impact performance
It would be really nice to have support for the automatic
extension-less fullscreen game scenario. Maybe you don't have to solve
everything in the first implementation...
So a friendly ping here!
Regards
//Ernst
Den tis 24 apr. 2018 kl 23:58 skrev Daniel Vetter :
>
> On Tue, Apr 24, 2018 at 4:28
https://bugs.freedesktop.org/show_bug.cgi?id=104817
Marcus Husar changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugzilla.kernel.org/show_bug.cgi?id=199653
Marcus Husar (marcus.hu...@gmail.com) changed:
What|Removed |Added
Status|NEW |RESOLVED
From: Hans Verkuil
Add DisplayPort CEC-Tunneling-over-AUX support to nouveau.
Signed-off-by: Hans Verkuil
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
tree: git://people.freedesktop.org/~agd5f/linux.git vega20_psp_smu
head: 9b9ef18df4349dd2d2b8941e76c032ed8acf2529
commit: 27480799ed68e17e8228372a4afac7d5dcfbf01a [28/44] drm/amd/powerplay: new
interfaces for overdrive vega20 sclk and mclk
config: arm-allmodconfig (attached as .config)
Enable and initialize plane color features.
v2: Rebase and some cleanup
v3: Updated intel_plane_color_init to call
drm_plane_color_create_prop function, which will
in turn create plane color properties.
v4: Rebase
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/i915_drv.h | 5
Load plane color luts as part of atomic plane updates.
This will be done only if the plane color luts are changed.
v4: Rebase
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_atomic_plane.c | 4
drivers/gpu/drm/i915/intel_color.c| 8
Define helper function to enable Plane color features
to attach plane color properties to plane structure.
v2: Rebase
v3: Modiefied the function to use updated property names.
v4: Rebase
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/drm_plane.c | 42
https://bugs.freedesktop.org/show_bug.cgi?id=107604
Bug ID: 107604
Summary: tes dhfhdghgdfgdshgfhs
Product: DRI
Version: DRI git
Hardware: Other
OS: All
Status: NEW
Severity: blocker
Priority:
Add Plane Degamma as a blob property and plane degamma size as
a range property.
v2: Rebase
v3: Fixed Sean, Paul's review comments. Moved the property from
mode_config to drm_plane. Created a helper function to instantiate
these properties and removed from drm_mode_create_standard_properties
Existing LUT precision structure is having only 16 bit
precision. This is not enough for upcoming enhanced hardwares
and advance usecases like HDR processing. Hence added a new
structure with 32 bit precision values. Also added the code,
for extracting the same from values passed from userspace.
Add plane gamma as blob property and size as a
range property.
v2: Rebase
v3: Fixed Sean, Paul's review comments. Moved the property from
mode_config to drm_plane. Created a helper function to instantiate
these properties and removed from drm_mode_create_standard_properties
Added property
Implement Plane Gamma feature for BDW and Gen9 platforms.
v2: Used newly added drm_color_lut_ext structure for enhanced
precision for Gamma LUT entries.
v3: Rebase
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/i915_pci.c | 5 +++-
drivers/gpu/drm/i915/i915_reg.h | 25
This patch series adds properties for plane color features. It adds
properties for degamma used to linearize data, CSC used for gamut
conversion, and gamma used to again non-linearize data as per panel
supported color space. These can be utilize by user space to convert
planes from one format to
Add a blob property for plane CSC usage.
v2: Rebase
v3: Fixed Sean, Paul's review comments. Moved the property from
mode_config to drm_plane. Created a helper function to instantiate
these properties and removed from drm_mode_create_standard_properties
Added property documentation as suggested
https://bugs.freedesktop.org/show_bug.cgi?id=107604
Daniel Stone changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=107607
Bug ID: 107607
Summary: [drm:generic_reg_wait [amdgpu]] *ERROR* REG_WAIT
timeout 10us * 3000 tries -
enc1_stream_encoder_dp_blank line:804
Product: DRI
Version:
From: Hans Verkuil
If aux->transfer == NULL, then just return without doing
anything. In that case the function is likely called for
a non-(e)DP connector.
This never happened for the i915 driver, but the nouveau and amdgpu
drivers need this check.
The alternative would be to add this check in
From: Hans Verkuil
When parsing the reply of a DP_REMOTE_DPCD_READ DPCD command the
result is wrong due to a missing idx increment.
This was never noticed since DP_REMOTE_DPCD_READ is currently not
used, but if you enable it, then it is all wrong.
Signed-off-by: Hans Verkuil
---
From: Hans Verkuil
Add DisplayPort CEC-Tunneling-over-AUX support to amdgpu.
Signed-off-by: Hans Verkuil
Acked-by: Alex Deucher
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 13 +++--
.../drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 2 ++
2 files changed, 13
From: Hans Verkuil
Repost because I wasn't a member of the nouveau mailinglist the
first time around and this series was blocked. I also updated this
cover letter for the part about the amdgpu patch after receiving
feedback from Alex Deucher. The patches are unchanged (except for
adding Alex'
From: Hans Verkuil
A big problem with DP CEC-Tunneling-over-AUX is that it is tricky
to find adapters with a chipset that supports this AND where the
manufacturer actually connected the HDMI CEC line to the chipset.
Add a mention of the MegaChips 2900 chipset which seems to support
this feature
The flag will prevent another thread from same process to
reinsert the entity queue into scheduler's rq after it was already
removed from there by another thread during drm_sched_entity_flush.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/scheduler/sched_entity.c | 10 +-
On 2018-08-16 16:36, Stephen Boyd wrote:
We got a bug report that this function oopses when trying to do a
kasprintf().
PC is at string+0x2c/0x60
LR is at vsnprintf+0x28c/0x4ec
pc : [] lr : [] pstate: a0c00049
sp : ff80095fb540
x29: ff80095fb540 x28: ff8008ad42bc
x27:
For multi-planar formats, while calculating offsets in planes with index
greater than 0
(ie second plane, third plane, etc), one needs to divide (src_x * cpp) with
horizontal
chroma subsampling factor and (src_y * pitch) with vertical chroma subsampling
factor.
The reason being that the planes
https://bugzilla.kernel.org/show_bug.cgi?id=200809
--- Comment #2 from Jaya Balan Aaron (bucket.s...@gmail.com) ---
Problem is with kernel 4.18.0-rc8 build from a 3rd party =>
https://github.com/M-Bab/linux-kernel-amdgpu-binaries.
Not sure if the amd-staging-drm-next is in it. It only says:
On 08/16/2018 08:09 PM, Wen Yang wrote:
> Fix comile warning like,
> CC [M] drivers/gpu/drm/i915/gvt/execlist.o
> CC [M] drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.o
> CC [M] drivers/gpu/drm/radeon/btc_dpm.o
> CC [M] drivers/isdn/hisax/avm_a1p.o
> CC [M]
On 8/17/2018 5:06 AM, Stephen Boyd wrote:
We got a bug report that this function oopses when trying to do a kasprintf().
PC is at string+0x2c/0x60
LR is at vsnprintf+0x28c/0x4ec
pc : [] lr : [] pstate: a0c00049
sp : ff80095fb540
x29: ff80095fb540 x28: ff8008ad42bc
x27:
From: "abhin...@codeaurora.org"
Add the device tree bindings for Truly NT35597 panel driver.
This panel driver supports both single DSI and dual DSI.
However, this patch series supports only dual DSI.
Changes in v6:
- Change the compatible string to indicate the
reference board and the
From: "abhin...@codeaurora.org"
Add support for Truly NT35597 panel driver used
in MSM reference platforms.
This panel driver supports both single DSI and dual DSI
modes.
However, this patch series adds support only for
dual DSI mode.
Changes in v6:
- Introduce panel config to store panel
https://bugzilla.kernel.org/show_bug.cgi?id=200809
--- Comment #3 from Jaya Balan Aaron (bucket.s...@gmail.com) ---
Might have committed a blunder while testing.
I have a "DELL ST2220L" connected on analog VGA and "Panasonic Tv" connected on
HDMI.
All the while primary might have been selected
https://bugzilla.kernel.org/show_bug.cgi?id=200809
--- Comment #4 from Jaya Balan Aaron (bucket.s...@gmail.com) ---
Unable to reproduce any error with HDMI display unplugged, primary display is
being selected as VGA device.
Kernel used: Problem is with kernel 4.18.0 build from a 3rd party =>
https://bugzilla.kernel.org/show_bug.cgi?id=200809
--- Comment #5 from Jaya Balan Aaron (bucket.s...@gmail.com) ---
Created attachment 277921
--> https://bugzilla.kernel.org/attachment.cgi?id=277921=edit
dmesg of 4.18.0 kernel with drm.debug=4
--
You are receiving this mail because:
You are
https://bugs.freedesktop.org/show_bug.cgi?id=102322
--- Comment #47 from Andrey Grodzovsky ---
Created attachment 141174
--> https://bugs.freedesktop.org/attachment.cgi?id=141174=edit
add_debug_info.patch
A am attaching a basic debug patch, please try to apply it. It should give a
bit more
https://bugzilla.kernel.org/show_bug.cgi?id=200809
Jaya Balan Aaron (bucket.s...@gmail.com) changed:
What|Removed |Added
Severity|blocking|low
--
You
There's console font corruption when using the mach64 driver in 24bpp
mode.
In 24bpp mode, the mach64 accelerator is set up for 8-bpp mode (with
horizontal width and stride multiplied by 3). In this mode, the
accelerator can't even possibly support color expansion. Consquently, we
have to use an
This patch fixes the debugging printks. Use pr_cont, so that the lines are
not broken up. Use printk when starting a new line (a long string of
pr_cont's without any printks causes missing characters in the console
output on sparc).
Signed-off-by: Mikulas Patocka
---
From: Mikulas Patocka
Date: Fri, 17 Aug 2018 15:19:37 -0400 (EDT)
> On Sun Ultra 5, it happens that the dot clock is not set up properly for
> some videomodes. For example, if we set the videomode "r1024x768x60" in
> the firmware, Linux would incorrectly set a videomode with refresh rate
> 180Hz
On Sun Ultra 5, it happens that the dot clock is not set up properly for
some videomodes. For example, if we set the videomode "r1024x768x60" in
the firmware, Linux would incorrectly set a videomode with refresh rate
180Hz when booting (suprisingly, my LCD monitor can display it, although
display
This patch needs to now incorporate the newly added slice_row_per_frame
parameter in PPS_16.
Anusha
>-Original Message-
>From: Navare, Manasi D
>Sent: Tuesday, July 31, 2018 2:07 PM
>To: intel-...@lists.freedesktop.org
>Cc: Navare, Manasi D ; Singh, Gaurav K
>;
76 matches
Mail list logo
