https://bugs.freedesktop.org/show_bug.cgi?id=91202
Lars Wendler changed:
What|Removed |Added
CC||polynomia...@gentoo.org
--- Comment #28
tree: git://people.freedesktop.org/~agd5f/linux.git amd-mainline-dkms-5.2
head: a48b0cc1cdf3900e3e73801f9de64afbb70dc193
commit: faafc170760aa44876ca6d04bc0b461945c9c98d [2699/2834] drm/amdkcl: drop
kcl_drm_fb_helper_{alloc,unregister}_fbi
config: x86_64-randconfig-e001-201944 (attached as
tree: git://people.freedesktop.org/~agd5f/linux.git amd-mainline-dkms-5.2
head: a48b0cc1cdf3900e3e73801f9de64afbb70dc193
commit: cc8e420623914e7a903534abddf086dad609a455 [2701/2834] drm/amdkcl: drop
kcl_drm_atomic_helper_update_legacy_modeset_state
config: x86_64-randconfig-e004-201944
tree: git://people.freedesktop.org/~agd5f/linux.git amd-mainline-dkms-5.2
head: a48b0cc1cdf3900e3e73801f9de64afbb70dc193
commit: fa3a28572dee89436a969d4c9b15b7f3d65102b4 [2700/2834] drm/amdkcl: drop
kcl_drm_fb_helper_set_suspend_unlocked
config: x86_64-randconfig-e004-201944 (attached as
https://bugs.freedesktop.org/show_bug.cgi?id=111763
--- Comment #25 from Ben Klein ---
Created attachment 145918
--> https://bugs.freedesktop.org/attachment.cgi?id=145918=edit
Journal excerpt vega56 ring gfx timeout, then gpu reset
I think I'm having this problem on a Vega 56, I didn't see
Hi Flora,
FYI, the error/warning still remains.
tree: git://people.freedesktop.org/~agd5f/linux.git amd-mainline-dkms-5.0
head: 7af3b66aba4c3982167d540c01ea71735e9a1264
commit: f460c248a3f0bca3a875602cf40693de672485c4 [3697/4201] drm/amd/autoconf:
refactor dma_fence header check
config:
tree: git://people.freedesktop.org/~agd5f/linux.git amd-mainline-dkms-5.2
head: a48b0cc1cdf3900e3e73801f9de64afbb70dc193
commit: faafc170760aa44876ca6d04bc0b461945c9c98d [2699/2834] drm/amdkcl: drop
kcl_drm_fb_helper_{alloc,unregister}_fbi
config: x86_64-randconfig-e004-201944 (attached as
tree: git://people.freedesktop.org/~agd5f/linux.git amd-mainline-dkms-5.2
head: a48b0cc1cdf3900e3e73801f9de64afbb70dc193
commit: 45978f4e7fc258a4a8ecb042f5fa3a9bc5dd0255 [2698/2834] drm/amdkcl: drop
kcl_drm_fb_helper_cfb_xxx
config: x86_64-randconfig-e001-201944 (attached as .config)
In case of tiled displays, if we hotplug just one connector,
fbcon currently just selects the preferred mode and if it is
tiled mode then that becomes a problem if rest of the tiles are
not present.
So in the fbdev driver on hotplug when we probe the client modeset,
if we dont find all the
On Thu, 2019-11-07 at 08:38 -0500, Sean Paul wrote:
> On Thu, Nov 07, 2019 at 01:54:22AM -0800, Joe Perches wrote:
> > On Thu, 2019-11-07 at 12:29 +0300, Wambui Karuga wrote:
> > > Replace the use of the dev_err macro with the DRM_DEV_ERROR
> > > DRM helper macro.
> >
> > The commit message
Hi Laurent,
On Fri, 2019-11-08 at 09:13:25 -0800, Laurent Pinchart wrote:
> Hi Hyun,
>
> (CC'ing Daniel, with a question for him below)
>
> On Fri, Sep 27, 2019 at 05:04:57PM -0700, Hyun Kwon wrote:
> > On Wed, 2019-09-25 at 16:55:42 -0700, Laurent Pinchart wrote:
> > > From: Hyun Kwon
> > >
On Fri, Nov 08, 2019 at 03:12:28PM -0700, Jeffrey Hugo wrote:
> On Fri, Nov 8, 2019 at 2:29 PM Stephan Gerhold wrote:
> >
> > At the moment, the MSM DSI driver calls drm_panel_enable() rather early
> > from the DSI bridge pre_enable() function. At this point, the encoder
> > (e.g. MDP5) is not
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #221 from William Casarin ---
mesa 19.3.0-rc2 + RADV_PERFTEST=aco fixed this for me
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
Am Freitag, den 08.11.2019, 22:32 +0100 schrieb Arnd Bergmann:
> struct timespec is being removed from the kernel because it often leads
> to code that is not y2038-safe.
>
> In the etnaviv driver, monotonic timestamps are used, which do not suffer
> from overflow, but using ktime_t still leads
tree: git://people.freedesktop.org/~agd5f/linux.git amd-mainline-dkms-5.2
head: a48b0cc1cdf3900e3e73801f9de64afbb70dc193
commit: 45978f4e7fc258a4a8ecb042f5fa3a9bc5dd0255 [2698/2834] drm/amdkcl: drop
kcl_drm_fb_helper_cfb_xxx
config: x86_64-randconfig-e004-201944 (attached as .config)
https://bugs.freedesktop.org/show_bug.cgi?id=111481
Marco Liedtke changed:
What|Removed |Added
Attachment #145904|0 |1
is obsolete|
struct timespec is being removed from the kernel because it often leads
to code that is not y2038-safe.
In the etnaviv driver, monotonic timestamps are used, which do not suffer
from overflow, but using ktime_t still leads to better code overall.
The conversion is straightforward for the most
The timespec structure and associated interfaces are deprecated and will
be removed in the future because of the y2038 overflow.
The use of ktime_to_timespec() in timeout_to_jiffies() does not
suffer from that overflow, but is easy to avoid by just converting
the ktime_t into jiffies directly.
These are updates to devidce drivers and file systems that for some
reason or another were not included in the kernel in the previous
y2038 series.
I've gone through all users of time_t again to make sure the
kernel is in a long-term maintainable state.
Posting these as a series for better
At the moment, the MSM DSI driver calls drm_panel_enable() rather early
from the DSI bridge pre_enable() function. At this point, the encoder
(e.g. MDP5) is not enabled, so we have not started transmitting
video data.
However, the drm_panel_funcs documentation states that enable()
should be
Hi Dave, Daniel,
Fixes for 5.5.
The following changes since commit cea35f5ad5ffac06ea29e0d7a7f748683e1f1b7d:
drm/i915: Don't select BROKEN (2019-11-06 05:46:04 +1000)
are available in the Git repository at:
git://people.freedesktop.org/~agd5f/linux tags/drm-next-5.5-2019-11-08
for you to
tree: git://people.freedesktop.org/~agd5f/linux.git amd-mainline-dkms-5.2
head: a48b0cc1cdf3900e3e73801f9de64afbb70dc193
commit: 4d49aa8a40ceecfd8a6b2d4e1b86396fbeedbb01 [1794/2834]
drm/amdkcl/autoconf: generate config.h for in-tree build
config: i386-randconfig-e004-201944 (attached as
https://bugzilla.kernel.org/show_bug.cgi?id=205093
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC|
https://bugs.freedesktop.org/show_bug.cgi?id=111762
Alex Deucher changed:
What|Removed |Added
Severity|normal |enhancement
--
You are receiving this
https://bugs.freedesktop.org/show_bug.cgi?id=111762
--- Comment #15 from Alex Deucher ---
pp_od_clk_voltage isn't implemented yet for navi. There are patches on the
mailing list:
https://patchwork.freedesktop.org/series/69152/
--
You are receiving this mail because:
You are the assignee for
https://bugs.freedesktop.org/show_bug.cgi?id=111762
--- Comment #14 from Alex Deucher ---
(In reply to tempel.julian from comment #13)
> It might be that, just not in hex. E.g. VddcLookupTable entry 1 returns a
> Vdd of 65282.
Correct. 65282 is 0xff02 which is a virtual voltage id. The driver
https://bugs.freedesktop.org/show_bug.cgi?id=112234
--- Comment #1 from Matt Coffin ---
Bisected, and traced back to
faa695c715e5c9203af824315127037499b33921
drm/amd/powerplay: do proper cleanups on hw_fini
--
You are receiving this mail because:
You are the assignee for the
https://bugzilla.kernel.org/show_bug.cgi?id=205093
Andrey Grodzovsky (andrey.grodzov...@amd.com) changed:
What|Removed |Added
CC|
https://bugs.freedesktop.org/show_bug.cgi?id=111762
--- Comment #13 from tempel.jul...@gmail.com ---
It might be that, just not in hex. E.g. VddcLookupTable entry 1 returns a Vdd
of 65282.
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=108965
--- Comment #3 from harish.chego...@intel.com ---
There are two issues associated with this bug:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7252/fi-kbl-8809g/igt@amdgpu_amd_ba...@semaphore.html
https://bugs.freedesktop.org/show_bug.cgi?id=111762
--- Comment #12 from Alex Deucher ---
(In reply to tempel.julian from comment #11)
> It was just a bit inconvenient that for my Polaris card the Vdds were
> defined as garbage values when parsing the default pp_table. Though
> specifying custom
On Fri, Nov 8, 2019 at 11:59 AM Laurent Pinchart
wrote:
>
> From: Hyun Kwon
>
> The bindings describe the ZynqMP DP subsystem. They don't support the
> interface with the programmable logic (FPGA) or audio yet.
>
> Signed-off-by: Hyun Kwon
> Signed-off-by: Laurent Pinchart
> ---
> Changes
https://bugs.freedesktop.org/show_bug.cgi?id=111762
--- Comment #11 from tempel.jul...@gmail.com ---
That really looks suspicious.
Looks like the issue of voltage resetting itself to default I mentioned earlier
when using custom power play stables might not apply to Navi:
https://bugs.freedesktop.org/show_bug.cgi?id=111762
--- Comment #10 from zamundaa...@gmail.com ---
I'm already using ppfeaturemask=0xfffd7fff, it doesn't unlock anything - or at
least CoreCtrl doesn't show anything.
In the journald log I see a lot of these lines, always grouped together:
On Fri, Nov 8, 2019 at 7:07 PM John Donnelly wrote:
>
>
>
> > On Nov 8, 2019, at 9:06 AM, Thomas Zimmermann wrote:
> >
> > Hi
> >
> > Am 08.11.19 um 13:55 schrieb John Donnelly:
> >>
> >>
> >>> On Nov 8, 2019, at 1:46 AM, Thomas Zimmermann wrote:
> >>>
> >>> Hi John
> >>>
> >>> Am 07.11.19 um
On Fri, Nov 08, 2019 at 05:02:07PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> The purpose of BAR1 is primarily to make memory accesses coherent.
> However, some GPUs do not have BAR1 functionality. For example, the
> GV11B found on the Xavier SoC is DMA coherent and therefore
> On Nov 8, 2019, at 9:06 AM, Thomas Zimmermann wrote:
>
> Hi
>
> Am 08.11.19 um 13:55 schrieb John Donnelly:
>>
>>
>>> On Nov 8, 2019, at 1:46 AM, Thomas Zimmermann wrote:
>>>
>>> Hi John
>>>
>>> Am 07.11.19 um 23:14 schrieb John Donnelly:
> On Nov 7, 2019, at 10:13 AM,
Add a DT node for the DisplayPort subsystem, a hard IP present in the
Zynq Ultrascale+ MPSoC.
Signed-off-by: Laurent Pinchart
---
Changes since v9:
- Update to the latest DPDMA DT bindings
---
arch/arm64/boot/dts/xilinx/zynqmp-clk.dtsi | 4
arch/arm64/boot/dts/xilinx/zynqmp.dtsi | 22
From: Hyun Kwon
The bindings describe the ZynqMP DP subsystem. They don't support the
interface with the programmable logic (FPGA) or audio yet.
Signed-off-by: Hyun Kwon
Signed-off-by: Laurent Pinchart
---
Changes since v9:
- Fix constraints on clock-names
- Document dp_apb_clk as the APB
Enable the dpsub device and wire it up to the PS-GTR PHY lanes routed to
the DisplayPort connector.
Signed-off-by: Laurent Pinchart
---
.../arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts | 16
1 file changed, 16 insertions(+)
diff --git
Hello,
Here's a new version of the Xilinx ZynqMP DisplayPort Subsystem driver,
the second version since I took over v8 of the series ([1]) from Hyun.
This new version only brings small changes. The most notable difference
is a conversion of the DT bindings to YAML. Other small changes are
The pull request you sent on Fri, 8 Nov 2019 16:57:59 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-11-08
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/efc61f7cbc283995bb1b3a5e925b8c7f79849f86
Thank you!
--
Deet-doot-dot, I am a bot.
https://bugs.freedesktop.org/show_bug.cgi?id=112235
--- Comment #4 from Sylvain BERTRAND ---
could you log the bug for me? I am waiting for my mesa gitlab bugzilla account
registration. I am blocked by google javascript capcha *bip* as I use no
javascript/ basic (x)html browers, I did contact
https://bugs.freedesktop.org/show_bug.cgi?id=112235
--- Comment #2 from Alex Deucher ---
Probably a mesa bug rather than a kernel bug.
--
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=112235
--- Comment #3 from Sylvain BERTRAND ---
Created attachment 145915
--> https://bugs.freedesktop.org/attachment.cgi?id=145915=edit
xorg log
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=112235
--- Comment #1 from Sylvain BERTRAND ---
Created attachment 145914
--> https://bugs.freedesktop.org/attachment.cgi?id=145914=edit
kernel log
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=112235
Bug ID: 112235
Summary: [AMD tahiti xt] random crashes of GL/vulkan games
Product: DRI
Version: DRI git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
The thc63lvd1024 driver requests a supply using regulator_get_optional()
but both the name of the supply and the usage pattern suggest that it is
being used for the main power for the device and is not at all optional
for the device for function, there is no handling at all for absent
supplies.
https://bugzilla.kernel.org/show_bug.cgi?id=205393
--- Comment #14 from tempel.jul...@gmail.com ---
(In reply to Alex Deucher from comment #13)
> (In reply to tempel.julian from comment #12)
> >
> > Would the same be required for Navi as well?
>
> No. IIRC, vega12 and newer handle voltage
https://bugzilla.kernel.org/show_bug.cgi?id=205393
--- Comment #13 from Alex Deucher (alexdeuc...@gmail.com) ---
(In reply to tempel.julian from comment #12)
>
> Would the same be required for Navi as well?
No. IIRC, vega12 and newer handle voltage differently.
--
You are receiving this mail
Hi,
On Tuesday, November 5, 2019 3:27:55 PM CET Daniel Vetter wrote:
> On Thu, Oct 31, 2019 at 09:29:56AM +0100, Janusz Krzysztofik wrote:
> > We need dmabuf specific pwrite() callback utilizing dma-buf API,
> > otherwise GEM_PWRITE IOCTL will no longer work with dma-buf backed
> > (i.e., PRIME
https://bugzilla.kernel.org/show_bug.cgi?id=205393
--- Comment #12 from tempel.jul...@gmail.com ---
(In reply to Alex Deucher from comment #11)
> Created attachment 285835 [details]
> patch for smu7
>
> Try this.
Thank you, I can confirm that it fixes the issue on Polaris.
Would the same be
Hi Hyun,
(CC'ing Daniel, with a question for him below)
On Fri, Sep 27, 2019 at 05:04:57PM -0700, Hyun Kwon wrote:
> On Wed, 2019-09-25 at 16:55:42 -0700, Laurent Pinchart wrote:
> > From: Hyun Kwon
> >
> > The Xilinx ZynqMP SoC has a hardened display pipeline named DisplayPort
> > Subsystem.
On Fri, Nov 8, 2019 at 10:15 AM Laurent Pinchart
wrote:
>
> On Fri, Nov 08, 2019 at 06:12:26PM +0200, Laurent Pinchart wrote:
> > On Fri, Nov 08, 2019 at 06:01:20PM +0200, Laurent Pinchart wrote:
> > > On Fri, Nov 08, 2019 at 09:57:55AM -0600, Rob Herring wrote:
> > >> On Fri, Nov 8, 2019 at 8:32
https://bugzilla.kernel.org/show_bug.cgi?id=203471
--- Comment #21 from Michel Dänzer (mic...@daenzer.net) ---
(In reply to Haxk20 from comment #20)
> Not only that but it started happening in video too on firefox and that is
> really horrible.
Sounds like you're referring to
On Fri, Nov 08, 2019 at 05:27:59PM +0100, Daniel Vetter wrote:
> On Fri, Oct 25, 2019 at 09:30:42AM +0200, Daniel Vetter wrote:
> > On Thu, Oct 24, 2019 at 02:18:59PM -0500, Rob Herring wrote:
> > > Commit c40069cb7bd6 ("drm: add mmap() to drm_gem_object_funcs")
> > > introduced a GEM object
On Fri, Nov 08, 2019 at 11:23:27AM -0500, Sean Paul wrote:
> On Fri, Nov 08, 2019 at 09:59:19AM +0100, Daniel Vetter wrote:
> > On Fri, Nov 08, 2019 at 09:46:48AM +0100, Daniel Vetter wrote:
> > > On Fri, Nov 08, 2019 at 10:16:59AM +0200, Pekka Paalanen wrote:
> > > > On Thu, 7 Nov 2019 16:02:59
https://bugs.freedesktop.org/show_bug.cgi?id=112234
Bug ID: 112234
Summary: [REGRESSION] navi10: writing to pp_table fails
(5.4-rc6 = working)
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS:
On Fri, 8 Nov 2019 at 15:55, Steven Price wrote:
>
> On 08/11/2019 13:10, Emil Velikov wrote:
> > On Fri, 1 Nov 2019 at 13:34, Steven Price wrote:
> >>
> >> On 01/11/2019 13:03, Emil Velikov wrote:
> >>> From: Emil Velikov
> >>>
> >>> As of earlier commit we have address space separation. Yet
On Fri, Nov 08, 2019 at 03:36:57PM +0200, Ville Syrjälä wrote:
> On Thu, Nov 07, 2019 at 06:40:14PM +0100, Daniel Vetter wrote:
> > On Thu, Nov 07, 2019 at 05:17:14PM +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > This thing can get called several thousand times per LUT
> > >
On Fri, Nov 08, 2019 at 04:08:50PM +0100, Heiko Stübner wrote:
> Hi Daniel, Sandy,
>
> Am Mittwoch, 9. Oktober 2019, 16:50:08 CET schrieb Daniel Vetter:
> > On Thu, Sep 26, 2019 at 04:24:47PM +0800, Sandy Huang wrote:
> > > These new format is supported by some rockchip socs:
> > >
> > >
On Fri, Nov 8, 2019 at 11:29 AM Colin King wrote:
>
> From: Colin Ian King
>
> Variable status is redundant, it is being initialized with a value
> that is over-written later and this is being returned immediately
> after the assignment. Clean up the code by removing status and
> just returning
Applied. thanks!
Alex
On Fri, Nov 8, 2019 at 9:42 AM Mikita Lipski wrote:
>
> Thanks!
>
> Reviewed-by: Mikita Lipski
>
> On 08.11.2019 9:38, Colin King wrote:
> > From: Colin Ian King
> >
> > Currently pointer aconnector is being dereferenced by the call to
> > to_dm_connector_state before
On Fri, Nov 8, 2019 at 9:45 AM Colin King wrote:
>
> From: Colin Ian King
>
> Variable grph_obj_type is being assigned twice, one of these is
> redundant so remove it.
>
> Addresses-Coverity: ("Evaluation order violation")
> Signed-off-by: Colin Ian King
Applied. Thanks!
> ---
>
From: Colin Ian King
Variable status is redundant, it is being initialized with a value
that is over-written later and this is being returned immediately
after the assignment. Clean up the code by removing status and
just returning the value returned from the call to function
On Fri, Oct 25, 2019 at 09:30:42AM +0200, Daniel Vetter wrote:
> On Thu, Oct 24, 2019 at 02:18:59PM -0500, Rob Herring wrote:
> > Commit c40069cb7bd6 ("drm: add mmap() to drm_gem_object_funcs")
> > introduced a GEM object mmap() hook which is expected to subtract the
> > fake offset from vm_pgoff.
On Fri, Nov 08, 2019 at 09:59:19AM +0100, Daniel Vetter wrote:
> On Fri, Nov 08, 2019 at 09:46:48AM +0100, Daniel Vetter wrote:
> > On Fri, Nov 08, 2019 at 10:16:59AM +0200, Pekka Paalanen wrote:
> > > On Thu, 7 Nov 2019 16:02:59 -0500
> > > Sean Paul wrote:
> > >
> > > > From: Sean Paul
> > >
https://bugzilla.kernel.org/show_bug.cgi?id=205393
--- Comment #11 from Alex Deucher (alexdeuc...@gmail.com) ---
Created attachment 285835
--> https://bugzilla.kernel.org/attachment.cgi?id=285835=edit
patch for smu7
Try this.
--
You are receiving this mail because:
You are watching the
On Fri, Nov 08, 2019 at 06:12:26PM +0200, Laurent Pinchart wrote:
> On Fri, Nov 08, 2019 at 06:01:20PM +0200, Laurent Pinchart wrote:
> > On Fri, Nov 08, 2019 at 09:57:55AM -0600, Rob Herring wrote:
> >> On Fri, Nov 8, 2019 at 8:32 AM Laurent Pinchart wrote:
> >>> On Fri, Nov 08, 2019 at
Hi Rob,
On Fri, Nov 08, 2019 at 06:01:20PM +0200, Laurent Pinchart wrote:
> On Fri, Nov 08, 2019 at 09:57:55AM -0600, Rob Herring wrote:
> > On Fri, Nov 8, 2019 at 8:32 AM Laurent Pinchart wrote:
> >> On Fri, Nov 08, 2019 at 04:10:40PM +0200, Laurent Pinchart wrote:
> >>> On Fri, Nov 08, 2019 at
On Mon, Nov 04, 2019 at 11:12:27PM +0100, Andrzej Pietrasiewicz wrote:
> There are afbc helpers available.
>
> Signed-off-by: Andrzej Pietrasiewicz
> ---
> .../arm/display/komeda/komeda_format_caps.h | 1 -
> .../arm/display/komeda/komeda_framebuffer.c | 44 +++
> 2 files
On Fri, Nov 08, 2019 at 03:06:44PM +0100, Heiko Stübner wrote:
> Hi,
>
> [it seems your Reply-To mail header is set strangely as
> Reply-To: 20191107133851.GF63329@art_vandelay
> which confuses my MTA]
>
> Am Freitag, 8. November 2019, 13:46:30 CET schrieb Wambui Karuga:
> > On Thu, Nov 07, 2019
From: Thierry Reding
The purpose of BAR1 is primarily to make memory accesses coherent.
However, some GPUs do not have BAR1 functionality. For example, the
GV11B found on the Xavier SoC is DMA coherent and therefore doesn't
need BAR1.
Implement a variant of FIFO channels that work without a
Hi Rob,
On Fri, Nov 08, 2019 at 09:57:55AM -0600, Rob Herring wrote:
> On Fri, Nov 8, 2019 at 8:32 AM Laurent Pinchart wrote:
> > On Fri, Nov 08, 2019 at 04:10:40PM +0200, Laurent Pinchart wrote:
> > > On Fri, Nov 08, 2019 at 04:07:33PM +0200, Laurent Pinchart wrote:
> > > > On Thu, Sep 26, 2019
On Fri, Nov 8, 2019 at 8:32 AM Laurent Pinchart
wrote:
>
> On Fri, Nov 08, 2019 at 04:10:40PM +0200, Laurent Pinchart wrote:
> > On Fri, Nov 08, 2019 at 04:07:33PM +0200, Laurent Pinchart wrote:
> > > On Thu, Sep 26, 2019 at 09:57:29AM -0500, Rob Herring wrote:
> > > > On Thu, Sep 26, 2019 at
On 08/11/2019 13:10, Emil Velikov wrote:
> On Fri, 1 Nov 2019 at 13:34, Steven Price wrote:
>>
>> On 01/11/2019 13:03, Emil Velikov wrote:
>>> From: Emil Velikov
>>>
>>> As of earlier commit we have address space separation. Yet we forgot to
>>> remove the respective comment and DRM_AUTH in the
On Wed, Nov 6, 2019 at 6:01 PM Stephan Gerhold wrote:
> This is a collection of fixes to make DSI video mode work better
> using the MCDE driver. With these changes, MCDE appears to work
> properly for the video mode panel I have been testing with.
>
> Note: The patch that fixes the DSI link
Den 08.11.2019 13.33, skrev Thomas Zimmermann:
> The udl driver can use the generic fbdev implementation. Convert it.
>
> Signed-off-by: Thomas Zimmermann
> ---
> diff --git a/drivers/gpu/drm/udl/udl_drv.c b/drivers/gpu/drm/udl/udl_drv.c
> index 563cc5809e56..55c0f9dfee29 100644
> ---
In the highly unlikely event that we fail to allocate the "radeon-crtc"
workqueue, we should bail cleanly rather than blindly marching on with a
NULL pointer installed for the 'flip_queue' field of the 'radeon_crtc'
structure.
This was reported previously by Nicolas, but I don't think his fix was
Hi, Emil!
On 11/8/19 2:14 PM, Emil Velikov wrote:
> On Fri, 1 Nov 2019 at 13:05, Emil Velikov wrote:
>> From: Emil Velikov
>>
>> Move the render_client hunk for require_exist alongside the rest.
>> Keeping all the reasons why an existing object is needed, in a single
>> place makes it easier to
Hi Daniel, Sandy,
Am Mittwoch, 9. Oktober 2019, 16:50:08 CET schrieb Daniel Vetter:
> On Thu, Sep 26, 2019 at 04:24:47PM +0800, Sandy Huang wrote:
> > These new format is supported by some rockchip socs:
> >
> > DRM_FORMAT_NV12_10/DRM_FORMAT_NV21_10
> > DRM_FORMAT_NV16_10/DRM_FORMAT_NV61_10
> >
Hi
Am 08.11.19 um 13:55 schrieb John Donnelly:
>
>
>> On Nov 8, 2019, at 1:46 AM, Thomas Zimmermann wrote:
>>
>> Hi John
>>
>> Am 07.11.19 um 23:14 schrieb John Donnelly:
>>>
>>>
On Nov 7, 2019, at 10:13 AM, John Donnelly
wrote:
> On Nov 7, 2019, at 7:42 AM,
From: Colin Ian King
Currently the error check on the call to drm_dp_atomic_find_vcpi_slots
is always false because an unsigned dm_new_connector_state->vcpi_slots
is being checked for a less than zero. Fix this by casting this to
an int on the comparison.
Addresses-Coverity: ("Unsigned compared
Hi Jitao,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[cannot apply to v5.4-rc6 next-20191108]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify
From: Colin Ian King
Variable grph_obj_type is being assigned twice, one of these is
redundant so remove it.
Addresses-Coverity: ("Evaluation order violation")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c | 3 +--
1 file changed, 1 insertion(+), 2
Thanks!
Reviewed-by: Mikita Lipski
On 08.11.2019 9:38, Colin King wrote:
> From: Colin Ian King
>
> Currently pointer aconnector is being dereferenced by the call to
> to_dm_connector_state before it is being null checked, this could
> lead to a null pointer dereference. Fix this by checking
On 10/18/19 5:41 PM, Arnd Bergmann wrote:
> Only the pxafb driver uses this header, so move it into the
> same directory. The SMART_* macros are required by some
> platform data definitions and can go into the
> linux/platform_data/video-pxafb.h header.
>
> Cc: Bartlomiej Zolnierkiewicz
> Cc:
On 10/18/19 5:41 PM, Arnd Bergmann wrote:
> There are two identical copies of mach/bitfield.h, one for
> mach-sa1100 and one for mach-pxa. The pxafb driver only
> makes use of two macros, which can be trivially open-coded
> in the header.
>
> Cc: Bartlomiej Zolnierkiewicz
> Cc:
From: Colin Ian King
Currently pointer aconnector is being dereferenced by the call to
to_dm_connector_state before it is being null checked, this could
lead to a null pointer dereference. Fix this by checking that
aconnector is null before dereferencing it.
Addresses-Coverity: ("Dereference
On Fri, Nov 08, 2019 at 04:10:40PM +0200, Laurent Pinchart wrote:
> On Fri, Nov 08, 2019 at 04:07:33PM +0200, Laurent Pinchart wrote:
> > On Thu, Sep 26, 2019 at 09:57:29AM -0500, Rob Herring wrote:
> > > On Thu, Sep 26, 2019 at 9:23 AM Laurent Pinchart wrote:
> > >> On Thu, Sep 26, 2019 at
On Fri, 8 Nov 2019 09:50:30 +0100
Daniel Vetter wrote:
> On Fri, Nov 08, 2019 at 10:16:59AM +0200, Pekka Paalanen wrote:
> > Is it ok to build userspace to rely on these trace events during normal
> > operations, e.g. for continuous adjustment of timings/timers?
>
> Aside discussion on this:
Hi Rob,
On Fri, Nov 08, 2019 at 04:07:33PM +0200, Laurent Pinchart wrote:
> On Thu, Sep 26, 2019 at 09:57:29AM -0500, Rob Herring wrote:
> > On Thu, Sep 26, 2019 at 9:23 AM Laurent Pinchart wrote:
> >> On Thu, Sep 26, 2019 at 09:15:01AM -0500, Rob Herring wrote:
> >>> On Wed, Sep 25, 2019 at 6:56
Hi Rob,
On Thu, Sep 26, 2019 at 09:57:29AM -0500, Rob Herring wrote:
> On Thu, Sep 26, 2019 at 9:23 AM Laurent Pinchart wrote:
> > On Thu, Sep 26, 2019 at 09:15:01AM -0500, Rob Herring wrote:
> > > On Wed, Sep 25, 2019 at 6:56 PM Laurent Pinchart wrote:
> > > >
> > > > From: Hyun Kwon
> > > >
>
Hi,
[it seems your Reply-To mail header is set strangely as
Reply-To: 20191107133851.GF63329@art_vandelay
which confuses my MTA]
Am Freitag, 8. November 2019, 13:46:30 CET schrieb Wambui Karuga:
> On Thu, Nov 07, 2019 at 08:38:51AM -0500, Sean Paul wrote:
> > On Thu, Nov 07, 2019 at 01:54:22AM
https://bugs.freedesktop.org/show_bug.cgi?id=111922
--- Comment #6 from Pierre Ossman ---
Hmmm... I did get this from that patch though:
> [ 98.391016] amdgpu :38:00.0: GPU mode1 reset
> [ 98.391072] [drm] psp mode 1 reset not supported now!
> [ 98.391074] amdgpu :38:00.0: GPU
From: Ville Syrjälä
This thing can get called several thousand times per LUT
so seems like we want to inline it to:
- avoid the function call overhead
- allow constant folding
A quick synthetic test (w/o any hardware interaction) with
a ridiculously large LUT size shows about 50% reduction in
https://bugs.freedesktop.org/show_bug.cgi?id=111922
--- Comment #5 from Pierre Ossman ---
That's a shame.
I did find bug 111811, which looks very similar. Through that I found this
patch:
https://www.mail-archive.com/amd-gfx@lists.freedesktop.org/msg40304.html
Unfortunately it does not solve
On Thu, Nov 07, 2019 at 10:33:02PM -0800, Christoph Hellwig wrote:
> On Thu, Nov 07, 2019 at 08:06:08PM +, Jason Gunthorpe wrote:
> > >
> > > enum mmu_range_notifier_event {
> > > MMU_NOTIFY_RELEASE,
> > > };
> > >
> > > ...assuming that we stay with "mmu_range_notifier" as a core name for
On Thu, Nov 07, 2019 at 06:40:14PM +0100, Daniel Vetter wrote:
> On Thu, Nov 07, 2019 at 05:17:14PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > This thing can get called several thousand times per LUT
> > so seems like we want to inline it to:
> > - avoid the function call
On Fri, 1 Nov 2019 at 13:05, Emil Velikov wrote:
>
> From: Emil Velikov
>
> Move the render_client hunk for require_exist alongside the rest.
> Keeping all the reasons why an existing object is needed, in a single
> place makes it easier to follow.
>
> Cc: VMware Graphics
> Cc: Thomas Hellstrom
1 - 100 of 190 matches
Mail list logo
