Hi
Am 22.10.19 um 21:03 schrieb Daniel Vetter:
> On Tue, Oct 22, 2019 at 7:16 PM Thomas Zimmermann wrote:
>>
>> Hi,
>>
>> there are two types of callbacks in struct
>> drm_simple_display_pipe_funcs: functions that are genuine to simple KMS,
>> and functions that are merely forwarded from another
From: "Lowry Li (Arm Technology China)"
Adds gamma and color-transform support for DOU-IPS.
Adds two caps members fgamma_coeffs and ctm_coeffs to komeda_improc_state.
If color management changed, set gamma and color-transform accordingly.
v5: Rebase with drm-misc-next
Signed-off-by: Lowry Li (A
This function is used to convert drm color lut to komeda HW required curve
coeffs values.
Signed-off-by: james qian wang (Arm Technology China)
Reviewed-by: Mihail Atanassov
---
.../arm/display/komeda/komeda_color_mgmt.c| 52 +++
.../arm/display/komeda/komeda_color_mgmt.h
This function is for converting drm_color_ctm matrix to komeda hardware
required required Q2.12 2's complement CSC matrix.
v2:
Move the fixpoint conversion function s31_32_to_q2_12() to drm core
as a shared helper.
Signed-off-by: james qian wang (Arm Technology China)
Reviewed-by: Mihail Ata
Add a new helper function drm_color_ctm_s31_32_to_qm_n() for driver to
convert S31.32 sign-magnitude to Qm.n 2's complement that supported by
hardware.
V4: Address Mihai, Daniel and Ilia's review comments.
V5: Includes the sign bit in the value of m (Qm.n).
V6: Allows m = 0 according to Mihail's c
Hi:
This series enable CRTC color-mgmt for komeda driver, for current komeda HW
which only supports color conversion and forward gamma for CRTC.
This series actually are regrouped from:
- drm/komeda: Enable layer/plane color-mgmt:
https://patchwork.freedesktop.org/series/60893/
- drm/komeda: E
2019. 10. 22. 22:57 keltezéssel, Ilia Mirkin írta:
On Tue, Oct 22, 2019 at 11:50 AM Böszörményi Zoltán wrote:
Hi,
I have the below configuration for an Intel based POS system that,
while advertises 3 outputs (DP1, VGA1 and HDMI1 with xf86-video-intel),
only two are usable. DP1 for the built-i
No functional change.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_plane.c | 36 +++---
1 file changed, 21 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c
b/drivers/gpu/drm/virtio/virtgpu_plane.c
index 0b5a760bc293..bc4b
Return early for the no framebuffer (or disabled output) case.
Results in a simpler code flow for the remaining cases.
No functional change.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_plane.c | 62 ++
1 file changed, 33 insertions(+), 29 deletions(-)
Be consistent with the rest of the code base.
No functional change.
v2:
- fix sparse warnings for virtio_gpu_cmd_transfer_to_host_2d call.
- move convert_to_hw_box helper function.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 5 +++--
drivers/gpu/drm/virtio/virtg
Little patch series doing some cleanups in the virtio driver.
Patches #1 + #2 have been on the list before as single patches,
includes here again for patch dependency reasons.
v2:
- fix sparse errors.
- drop merged patches (#1 + #2).
please review,
Gerd
Gerd Hoffmann (3):
drm/virtio: fix b
On 22/10/2019 23:47, Sean Paul wrote:
From: Sean Paul
This reverts commit 23b482252836ab3c5e6b3b20ed3038449cbc7679.
This patch does not have an acceptable open source userspace
implementation, and as such it does not meet the requirements for adding
new UAPI.
Discussion is in the Link.
Link:
Hi Daniel,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[cannot apply to v5.4-rc4 next-20191022]
[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
On Tue, Oct 22, 2019 at 4:36 AM Daniel Vetter wrote:
>
> On Mon, Oct 21, 2019 at 01:52:49PM -0500, Navid Emamdoost wrote:
> > In the impelementation of v3d_submit_cl_ioctl() there are two memory
> > leaks. One is when allocation for bin fails, and the other is when bin
> > initialization fails. If
On Tue, Oct 22, 2019 at 12:09 PM Michel Dänzer wrote:
>
> On 2019-10-20 11:21 p.m., Meelis Roos wrote:
> > I tried 5.2, 5.3 and 5.4-rc4 on my old Fujitsu RX220 with integrated
> > Radeon RV100. Dmesg tells that GPU acceleration is disabled. I do not
> > know if it has been enabled in the past - no
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #125 from Shmerl ---
Just built 5.4-rc4.
I still get these in dmesg when using ksysguard with amdgpu sensors:
[ 323.750015] amdgpu: [powerplay] failed send message: TransferTableSmu2Dram
(18) param: 0x0006 response 0x
https://bugs.freedesktop.org/show_bug.cgi?id=109955
--- Comment #118 from Rodney A Morris ---
(In reply to haro41 from comment #117)
> ...are this craches more frequently with VSYNC enabled?
>
> If yes, it could be the same thing like this bug:
>
> https://bugs.freedesktop.org/show_bug.cgi?id=1
https://bugs.freedesktop.org/show_bug.cgi?id=112104
Bug ID: 112104
Summary: 2 displays, only 1 hdmi/dp device listed, sound played
in both devices if selected
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
Hi Daniel,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[cannot apply to v5.4-rc4 next-20191022]
[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 s
On Tue, Oct 22, 2019 at 5:14 PM Rajat Jain wrote:
>
> Hi Folks,
>
> On Mon, Oct 7, 2019 at 11:13 PM Jani Nikula
> wrote:
>>
>> On Mon, 07 Oct 2019, Mat King wrote:
>> > That makes sense; just to confirm can a property be added or removed
>> > after the connector is registered?
>>
>> You need to
Certain laptops now come with panels that have integrated privacy
screens on them. This patch adds support for such panels by adding
a privacy-screen property to the drm_connector for the panel, that
the userspace can then use to control and check the status. The idea
was discussed here:
https://l
https://bugs.freedesktop.org/show_bug.cgi?id=110574
Joakim changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Tue, Oct 22, 2019 at 10:47 PM Sean Paul wrote:
>
> From: Sean Paul
>
> This reverts commit 23b482252836ab3c5e6b3b20ed3038449cbc7679.
>
> This patch does not have an acceptable open source userspace
> implementation, and as such it does not meet the requirements for adding
> new UAPI.
>
> Discu
On Tue, Oct 22, 2019 at 11:50 AM Böszörményi Zoltán wrote:
>
> Hi,
>
> I have the below configuration for an Intel based POS system that,
> while advertises 3 outputs (DP1, VGA1 and HDMI1 with xf86-video-intel),
> only two are usable. DP1 for the built-in touchscreen and VGA1 for
> the external VG
From: Sean Paul
This reverts commit 23b482252836ab3c5e6b3b20ed3038449cbc7679.
This patch does not have an acceptable open source userspace
implementation, and as such it does not meet the requirements for adding
new UAPI.
Discussion is in the Link.
Link: https://lists.freedesktop.org/archives/
On Mon, Oct 21, 2019 at 10:36:02PM -0400, Lyude Paul wrote:
> This probably hasn't caused any problems up until now since it's
> probably nearly impossible to encounter this in the wild, however if we
> were to receive a connection status notification from the MST hub after
> resume while we're in
On Mon, Oct 21, 2019 at 10:36:01PM -0400, Lyude Paul wrote:
> This is a complicated one. Essentially, there's currently a problem in the MST
> core that hasn't really caused any issues that we're aware of (emphasis on
> "that
> we're aware of"): locking.
>
> When we go through and probe the link
https://bugs.freedesktop.org/show_bug.cgi?id=112103
Bug ID: 112103
Summary: Asrock 5700 XT Taichi fails to boot/hangs when a fifth
monitor is connected
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
On Tue, Oct 22, 2019 at 6:30 AM Laurent Pinchart
wrote:
>
> Hi Rob,
>
> Thank you for the patch.
>
> On Mon, Oct 21, 2019 at 04:45:48PM -0500, Rob Herring wrote:
> > Add support in CMA helpers to handle callers specifying
> > DRM_MODE_DUMB_KERNEL_MAP flag. Existing behavior is maintained with this
On Tue, Oct 22, 2019 at 6:40 AM Geert Uytterhoeven wrote:
>
> Hi Laurent,
>
> On Tue, Oct 22, 2019 at 1:30 PM Laurent Pinchart
> wrote:
> > On Mon, Oct 21, 2019 at 04:45:48PM -0500, Rob Herring wrote:
>
> > > --- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> > > +++ b/drivers/gpu/drm/rockchip/r
From: "Paul E. McKenney"
This commit replaces the use of rcu_swap_protected() with the more
intuitively appealing rcu_replace() as a step towards removing
rcu_swap_protected().
Link:
https://lore.kernel.org/lkml/CAHk-=wiAsJLw1egFEE=z7-ggtm6wcvtyytxza1+bhqta4gg...@mail.gmail.com/
Reported-by: Li
On Tue, Oct 22, 2019 at 7:16 PM Thomas Zimmermann wrote:
>
> Hi,
>
> there are two types of callbacks in struct
> drm_simple_display_pipe_funcs: functions that are genuine to simple KMS,
> and functions that are merely forwarded from another structure (crtc,
> plane, etc).
>
> In the former catego
On Tue, Oct 22, 2019 at 7:33 PM Thomas Zimmermann wrote:
>
> Hi
>
> Am 22.10.19 um 17:25 schrieb Daniel Vetter:
> > Should help new people pick suitable tasks.
> >
> > Cc: Rodrigo Siqueira
> > Cc: Manasi Navare
> > Cc: Sean Paul
> > Signed-off-by: Daniel Vetter
> > ---
> > Documentation/gpu/t
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #124 from yam...@yamagi.org ---
Interestingly I've got the problem the other way round. My 5700XT was running
fine since I got it about two weeks ago. This is Arch Linux, I've run Mesa
19.2.1 and llvm-libs 9.0.0 since day one. The car
Hi
Am 22.10.19 um 17:25 schrieb Daniel Vetter:
> Should help new people pick suitable tasks.
>
> Cc: Rodrigo Siqueira
> Cc: Manasi Navare
> Cc: Sean Paul
> Signed-off-by: Daniel Vetter
> ---
> Documentation/gpu/todo.rst | 73 ++
> 1 file changed, 73 insert
https://bugs.freedesktop.org/show_bug.cgi?id=111986
--- Comment #16 from Daniel Suarez ---
(In reply to Sabbie from comment #15)
> I'm having the same issue on a 5700 (non-xt).
>
> It seems to be this bug:
>
> https://bugs.freedesktop.org/show_bug.cgi?id=111481#c9
Yeah, apologies I have not pr
https://bugs.freedesktop.org/show_bug.cgi?id=111481
Daniel Suarez changed:
What|Removed |Added
Priority|not set |highest
--
You are receiving this mail
On Fri, 11 Oct 2019 15:54:53 +0200
Andrzej Hajda wrote:
> On 26.08.2019 17:26, Boris Brezillon wrote:
> > The encoder->enable() can't report errors and is expected to always
> > succeed. If we call pm_runtime_put() in the exynos_dsi_enable() error
> > path (as currently done) we'll have unbalance
Hi Rob,
On 21/10/2019 23:45, Rob Herring wrote:
> The only reason the Mediatek driver doesn't use the CMA helpers is it
> sets DMA_ATTR_NO_KERNEL_MAPPING and does a vmap() on demand. Using
> vmap() is not even guaranteed to work as DMA buffers may not have a
> struct page. Now that the CMA helpers
On Tuesday, 22 October 2019 17:37:17 BST Daniel Vetter wrote:
> This is not something we'll fix, because failing to clean up stuff (or
> doing it in the wrong order) is a driver bug. The offending FIXME goes
> all the way back to the original modeset merge.
>
> We've added a WARN_ON in
>
> commit
Hi,
there are two types of callbacks in struct
drm_simple_display_pipe_funcs: functions that are genuine to simple KMS,
and functions that are merely forwarded from another structure (crtc,
plane, etc).
In the former category are enable(), disable(), check(), and update().
Those should probably r
On Tue, Oct 22, 2019 at 05:25:30PM +0200, Daniel Vetter wrote:
> Should help new people pick suitable tasks.
>
> Cc: Rodrigo Siqueira
> Cc: Manasi Navare
> Cc: Sean Paul
Reviewed-by: Sean Paul
> Signed-off-by: Daniel Vetter
> ---
> Documentation/gpu/todo.rst | 73 ++
On Tue, Oct 22, 2019 at 05:25:29PM +0200, Daniel Vetter wrote:
> Done with
>
> commit aef9f33b7658a7489f71df5d6e6ecb47f2521e8a
> Author: Imre Deak
> Date: Tue Oct 23 17:43:10 2018 +0300
>
> drm/i915: Ensure proper HDA suspend/resume ordering with a device link
>
> Cc: Imre Deak
> Signed-
On Fri, Oct 18, 2019 at 05:41:20PM +0200, Arnd Bergmann wrote:
> The mach/hardware.h is included in lots of places, and it provides
> three different things on pxa:
Acked-by: Mark Brown
signature.asc
Description: PGP signature
___
dri-devel mailing li
This is not something we'll fix, because failing to clean up stuff (or
doing it in the wrong order) is a driver bug. The offending FIXME goes
all the way back to the original modeset merge.
We've added a WARN_ON in
commit 2b677e8c08eed11e4ebe66a7c334f03e389a19a3
Author: Daniel Vetter
Date: Mon
Hi Laurent,
Did you have any time to look into this series?
Thanks,
Fab
> From: Fabrizio Castro
> Sent: 28 August 2019 19:37
> Subject: [PATCH v3 0/8] Add dual-LVDS panel support to EK874
>
> Dear All,
>
> this series adds support for dual-LVDS panel IDK-2121WR
> from Advantech:
> https://buy
On Tue, Oct 08, 2019 at 07:48:14PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Use the new drm_hdmi_avi_infoframe_bars() helper instead
> of hand rolling it.
>
> Cc: Eric Anholt
> Cc: Boris Brezillon
> Signed-off-by: Ville Syrjälä
Series pushed to drm-misc-next with Boris's irc rb:
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #123 from Sabbie ---
I'm having the same problem on an RX 5700, running Arch.
- 3.5.7 Kernel
- mesa-git 1:19.3.0_devel.116477.3ad6154f4eb-1
- llvm-git 10.0.0_r329841.1c982af0599-1
GPU crashes on various activities and seemingly at
https://bugs.freedesktop.org/show_bug.cgi?id=111986
--- Comment #15 from Sabbie ---
I'm having the same issue on a 5700 (non-xt).
It seems to be this bug:
https://bugs.freedesktop.org/show_bug.cgi?id=111481#c9
--
You are receiving this mail because:
You are the assignee for the bug.__
On 2019-10-20 11:21 p.m., Meelis Roos wrote:
> I tried 5.2, 5.3 and 5.4-rc4 on my old Fujitsu RX220 with integrated
> Radeon RV100. Dmesg tells that GPU acceleration is disabled. I do not
> know if it has been enabled in the past - no old kernels handy at the
> moment.
>
> From dmesg it looks like
On Mon, Oct 21, 2019 at 10:36:00PM -0400, Lyude Paul wrote:
> Currently, MST lacks locking in a lot of places that really should have
> some sort of locking. Hotplugging and link address code paths are some
> of the offenders here, as there is actually nothing preventing us from
> running a link ad
On 10/22/19 3:21 AM, Neil Armstrong wrote:
> Hi John,
>
> On 21/10/2019 21:03, John Stultz wrote:
>> Lucky number 13! :)
>>
>> Last week in v12 I had re-added some symbol exports to support
>> later patches I have pending to enable loading heaps from
>> modules. He reminded me that back around v3
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #122 from Marko Popovic ---
(In reply to bugs from comment #121)
> I have the same problem using archlinux. I tried mesa+llvm stable
> (19.2/9.0), the git-versions with amdgpu and even with plain modesetting. I
> have random freezes
On Tue, Oct 22, 2019 at 1:21 AM Neil Armstrong wrote:
>
> Hi John,
>
> On 21/10/2019 21:03, John Stultz wrote:
> > Lucky number 13! :)
> >
> > Last week in v12 I had re-added some symbol exports to support
> > later patches I have pending to enable loading heaps from
> > modules. He reminded me th
Passing the wrong type feels icky, everywhere else we use the pipe as
the first parameter. Spotted while discussing patches with Thomas
Zimmermann.
Cc: Thomas Zimmermann
Cc: Noralf Trønnes
Cc: Gerd Hoffmann
Cc: Eric Anholt
Cc: Emil Velikov
Cc: virtualizat...@lists.linux-foundation.org
Cc: Lin
On Tue, Oct 22, 2019 at 11:51 AM Jani Nikula
wrote:
>
> On Tue, 22 Oct 2019, Thierry Reding wrote:
> > On Tue, Oct 22, 2019 at 11:16:51AM +0300, Jani Nikula wrote:
> >> On Wed, 16 Oct 2019, Patrik Jakobsson wrote:
> >> > Fix typo where bits got compared (x < y) instead of shifted (x << y).
> >>
Hi,
I have the below configuration for an Intel based POS system that,
while advertises 3 outputs (DP1, VGA1 and HDMI1 with xf86-video-intel),
only two are usable. DP1 for the built-in touchscreen and VGA1 for
the external VGA connector.
I wanted to use an USB DisplayLink device as the 3rd outpu
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #121 from b...@thschuetz.de ---
I have the same problem using archlinux. I tried mesa+llvm stable (19.2/9.0),
the git-versions with amdgpu and even with plain modesetting. I have random
freezes with xfce (with and without compositor)
On Tue, Oct 22, 2019 at 4:41 PM Thomas Zimmermann wrote:
>
> Hi
>
> Am 22.10.19 um 16:14 schrieb Daniel Vetter:
> > On Tue, Oct 22, 2019 at 12:25:16PM +0200, Thomas Zimmermann wrote:
> >> Passing the plane structure to prepare_fb() and cleanup_fb() of
> >> struct drm_simple_display_pipe_funcs unif
On Tue, Oct 22, 2019 at 02:06:22PM +, Harry Wentland wrote:
>
>
> On 2019-10-22 8:20 a.m., Ville Syrjälä wrote:
> > On Tue, Oct 22, 2019 at 03:29:44PM +0530, Shashank Sharma wrote:
> >> This patch adds a scaling filter mode porperty
> >> to allow:
> >> - A driver/HW to showcase it's scaling f
On Tue, Oct 22, 2019 at 08:51:20PM +0530, Sharma, Shashank wrote:
>
> On 10/22/2019 5:56 PM, Ville Syrjälä wrote:
> > On Tue, Oct 22, 2019 at 03:29:44PM +0530, Shashank Sharma wrote:
> >> This patch adds a scaling filter mode porperty
> >> to allow:
> >> - A driver/HW to showcase it's scaling filt
* H. Nikolaus Schaller [191022 15:12]:
> Hm. How should that work? Some SoC have the sgx544 as single
> core and others as dual core. This imho does not fit into
> the "img,sgx544-$revision" scheme which could be matched to.
Well don't you have then just two separate child nodes,
one for each cor
Hello Harry,
Thanks for your comments, please find mine inline.
On 10/22/2019 7:36 PM, Harry Wentland wrote:
On 2019-10-22 8:20 a.m., Ville Syrjälä wrote:
On Tue, Oct 22, 2019 at 03:29:44PM +0530, Shashank Sharma wrote:
This patch adds a scaling filter mode porperty
to allow:
- A driver/HW t
Should help new people pick suitable tasks.
Cc: Rodrigo Siqueira
Cc: Manasi Navare
Cc: Sean Paul
Signed-off-by: Daniel Vetter
---
Documentation/gpu/todo.rst | 73 ++
1 file changed, 73 insertions(+)
diff --git a/Documentation/gpu/todo.rst b/Documentation/g
Hello Mihail,
Thanks for your review, my comments inline.
On 10/22/2019 6:56 PM, Mihail Atanassov wrote:
Hi Shashank,
On Tuesday, 22 October 2019 10:59:44 BST Shashank Sharma wrote:
This patch adds a scaling filter mode porperty
to allow:
- A driver/HW to showcase it's scaling filter capabili
Done with
commit aef9f33b7658a7489f71df5d6e6ecb47f2521e8a
Author: Imre Deak
Date: Tue Oct 23 17:43:10 2018 +0300
drm/i915: Ensure proper HDA suspend/resume ordering with a device link
Cc: Imre Deak
Signed-off-by: Daniel Vetter
---
Documentation/gpu/todo.rst | 7 ---
1 file changed,
On 10/22/2019 5:56 PM, Ville Syrjälä wrote:
On Tue, Oct 22, 2019 at 03:29:44PM +0530, Shashank Sharma wrote:
This patch adds a scaling filter mode porperty
to allow:
- A driver/HW to showcase it's scaling filter capabilities.
- A userspace to pick a desired effect while scaling.
This option wi
Hello Ville,
Thanks for the comments, mine inline.
On 10/22/2019 5:50 PM, Ville Syrjälä wrote:
On Tue, Oct 22, 2019 at 03:29:44PM +0530, Shashank Sharma wrote:
This patch adds a scaling filter mode porperty
to allow:
- A driver/HW to showcase it's scaling filter capabilities.
- A userspace to
Hi Tony,
> Am 22.10.2019 um 17:02 schrieb Tony Lindgren :
>
> * H. Nikolaus Schaller [191021 18:08]:
>>
>>> Am 21.10.2019 um 19:25 schrieb Tony Lindgren :
>>>
>>> * H. Nikolaus Schaller [191021 15:46]:
> Am 21.10.2019 um 17:07 schrieb Rob Herring :
> On Fri, Oct 18, 2019 at 1:46 PM H.
* H. Nikolaus Schaller [191021 18:08]:
>
> > Am 21.10.2019 um 19:25 schrieb Tony Lindgren :
> >
> > * H. Nikolaus Schaller [191021 15:46]:
> >>> Am 21.10.2019 um 17:07 schrieb Rob Herring :
> >>> On Fri, Oct 18, 2019 at 1:46 PM H. Nikolaus Schaller
> >>> wrote:
> +Optional properties:
>
On 10/22/19 5:09 AM, Jani Nikula wrote:
The DCS command has been named SET_PARTIAL_ROWS in the DCS spec since
v1.02, for more than a decade. Rename the enumeration to match the spec.
Cc: David Lechner
Cc: Vandita Kulkarni
Signed-off-by: Jani Nikula
---
I guess all of my documents are old an
On Tue, Oct 22, 2019 at 03:42:07PM +0100, Russell King - ARM Linux admin wrote:
> On Tue, Oct 22, 2019 at 10:50:42AM +0200, Daniel Vetter wrote:
> > On Tue, Oct 22, 2019 at 10:48 AM Russell King - ARM Linux admin
> > wrote:
> > > I had a patches, which is why I raised the problem with the core:
>
From: Thierry Reding
During the discussion of patches that enhance the drm_dp_link helpers it
was concluded that these helpers aren't very useful to begin with. Start
pushing the equivalent code into individual drivers to ultimately remove
them.
v4: use bulk DPCD writes if possible (Daniel Vette
On Tue, Oct 22, 2019 at 10:50:42AM +0200, Daniel Vetter wrote:
> On Tue, Oct 22, 2019 at 10:48 AM Russell King - ARM Linux admin
> wrote:
> > I had a patches, which is why I raised the problem with the core:
> >
> > 6961edfee26d bridge hacks using device links
> >
> > but it never went further tha
Hi
Am 22.10.19 um 16:14 schrieb Daniel Vetter:
> On Tue, Oct 22, 2019 at 12:25:16PM +0200, Thomas Zimmermann wrote:
>> Passing the plane structure to prepare_fb() and cleanup_fb() of
>> struct drm_simple_display_pipe_funcs unifies the interface with
>> struct drm_plane_helper_funcs. Implementation
Reviewed-by: Anthony Koo
-Original Message-
From: sunpeng...@amd.com
Sent: Monday, October 21, 2019 3:44 PM
To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
lskre...@gmail.com
Cc: Koo, Anthony ; Wentland, Harry
; Li, Sun peng (Leo)
Subject: [PATCH v2] drm/amdgpu: A
On Tue, Oct 22, 2019 at 12:25:16PM +0200, Thomas Zimmermann wrote:
> Passing the plane structure to prepare_fb() and cleanup_fb() of
> struct drm_simple_display_pipe_funcs unifies the interface with
> struct drm_plane_helper_funcs. Implementations of these functions
> can now be shared between simp
On 2019-10-22 8:20 a.m., Ville Syrjälä wrote:
> On Tue, Oct 22, 2019 at 03:29:44PM +0530, Shashank Sharma wrote:
>> This patch adds a scaling filter mode porperty
>> to allow:
>> - A driver/HW to showcase it's scaling filter capabilities.
>> - A userspace to pick a desired effect while scaling.
>
On Mon, Oct 21, 2019 at 04:34:30PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> Use microsecond sleeps for the clock recovery and channel equalization
> delays during link training. The duration of these delays can be from
> 100 us up to 16 ms. It is rude to busy-loop for that amount o
On Mon, Oct 21, 2019 at 04:34:37PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> During the discussion of patches that enhance the drm_dp_link helpers it
> was concluded that these helpers aren't very useful to begin with. After
> all other drivers have been converted not to use these h
On Mon, Oct 21, 2019 at 04:34:36PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> During the discussion of patches that enhance the drm_dp_link helpers it
> was concluded that these helpers aren't very useful to begin with. Start
> pushing the equivalent code into individual drivers to u
On Mon, Oct 21, 2019 at 04:34:35PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> During the discussion of patches that enhance the drm_dp_link helpers it
> was concluded that these helpers aren't very useful to begin with. Start
> pushing the equivalent code into individual drivers to u
On Mon, Oct 21, 2019 at 09:18:07AM +, Brian Starkey wrote:
> On Sat, Oct 19, 2019 at 09:41:27AM -0400, Andrew F. Davis wrote:
> > On 10/18/19 2:57 PM, Ayan Halder wrote:
> > > On Fri, Oct 18, 2019 at 11:49:22AM -0700, John Stultz wrote:
> > >> On Fri, Oct 18, 2019 at 11:41 AM Ayan Halder wrote
On Mon, Oct 21, 2019 at 04:34:33PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> During the discussion of patches that enhance the drm_dp_link helpers it
> was concluded that these helpers aren't very useful to begin with. Start
> pushing the equivalent code into individual drivers to u
Den 17.10.2019 18.27, skrev Noralf Trønnes:
>
>
> Den 17.10.2019 13.49, skrev Andy Shevchenko:
>> GCC complains about dubious bitwise OR operand:
>>
>> drivers/gpu/drm/drm_mipi_dbi.c:1024:49: warning: dubious: x | !y
>> CC [M] drivers/gpu/drm/drm_mipi_dbi.o
>>
>> As long as buffer is consist
On Tuesday, 22 October 2019 14:26:38 BST Mihail Atanassov wrote:
> Hi Shashank,
>
> On Tuesday, 22 October 2019 10:59:44 BST Shashank Sharma wrote:
> > This patch adds a scaling filter mode porperty
> > to allow:
> > - A driver/HW to showcase it's scaling filter capabilities.
> > - A userspace to
On Mon, Oct 21, 2019 at 04:34:32PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> During the discussion of patches that enhance the drm_dp_link helpers it
> was concluded that these helpers aren't very useful to begin with. Start
> pushing the equivalent code into individual drivers to u
Hi Shashank,
On Tuesday, 22 October 2019 10:59:44 BST Shashank Sharma wrote:
> This patch adds a scaling filter mode porperty
> to allow:
> - A driver/HW to showcase it's scaling filter capabilities.
> - A userspace to pick a desired effect while scaling.
>
> This option will be particularly usefu
Hey,
On Tue, 22 Oct 2019 at 11:30, Daniel Vetter wrote:
> On Tue, Oct 22, 2019 at 10:58:02AM +0200, Rohan Garg wrote:
> > This approach also future proof's us to be able to label any handles, not
> > just
> > GEM handle.
>
> I don't expect we'll ever merge any non-gem drivers in the future anymo
On Tue, Oct 22, 2019 at 2:45 PM Mika Westerberg
wrote:
>
> On Tue, Oct 22, 2019 at 11:16:14AM +0200, Karol Herbst wrote:
> > I think there is something I totally forgot about:
> >
> > When there was never a driver bound to the GPU, and if runtime power
> > management gets enabled on that device, r
On Tue, Oct 22, 2019 at 6:14 AM Laurent Pinchart
wrote:
>
> Hi Rob,
>
> Thank you for the patch.
>
> On Mon, Oct 21, 2019 at 04:45:46PM -0500, Rob Herring wrote:
> > Introduce a new flag, DRM_MODE_DUMB_KERNEL_MAP, for struct
> > drm_mode_create_dumb. This flag is for internal kernel use to indicat
On Tue, Oct 22, 2019 at 11:16:14AM +0200, Karol Herbst wrote:
> I think there is something I totally forgot about:
>
> When there was never a driver bound to the GPU, and if runtime power
> management gets enabled on that device, runtime suspend/resume works
> as expected (I am not 100% sure on if
On Tue, Oct 22, 2019 at 03:29:44PM +0530, Shashank Sharma wrote:
> This patch adds a scaling filter mode porperty
> to allow:
> - A driver/HW to showcase it's scaling filter capabilities.
> - A userspace to pick a desired effect while scaling.
>
> This option will be particularly useful in the sce
On Tue, Oct 22, 2019 at 10:12:29AM +, Sharma, Shashank wrote:
> Hey Daniel,
>
> > -Original Message-
> > From: Daniel Vetter On Behalf Of Daniel Vetter
> > Sent: Tuesday, October 22, 2019 3:39 PM
> > To: Sharma, Shashank
> > Cc: dri-devel@lists.freedesktop.org; intel-...@lists.freed
On Tue, Oct 22, 2019 at 03:29:44PM +0530, Shashank Sharma wrote:
> This patch adds a scaling filter mode porperty
> to allow:
> - A driver/HW to showcase it's scaling filter capabilities.
> - A userspace to pick a desired effect while scaling.
>
> This option will be particularly useful in the sce
On 10/21/2019 12:58 PM, Jason Gunthorpe wrote:
On Mon, Oct 21, 2019 at 11:55:51AM -0400, Dennis Dalessandro wrote:
On 10/15/2019 2:12 PM, Jason Gunthorpe wrote:
This is still being tested, but I figured to send it to start getting help
from the xen, amd and hfi drivers which I cannot test here.
https://bugs.freedesktop.org/show_bug.cgi?id=111244
--- Comment #34 from Carmen Bianca Bakker ---
Created attachment 145793
--> https://bugs.freedesktop.org/attachment.cgi?id=145793&action=edit
failed suspend 5.4.0rc2
Issue still occurs on 5.4rc2. In these logs, on the second suspension.
Thin
Hi Laurent,
On Tue, Oct 22, 2019 at 1:30 PM Laurent Pinchart
wrote:
> On Mon, Oct 21, 2019 at 04:45:48PM -0500, Rob Herring wrote:
> > --- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> > @@ -419,6 +419,7 @@ int rockchip_gem_dumb_create(stru
Hi Rob,
Thank you for the patch.
On Mon, Oct 21, 2019 at 04:45:48PM -0500, Rob Herring wrote:
> Add support in CMA helpers to handle callers specifying
> DRM_MODE_DUMB_KERNEL_MAP flag. Existing behavior is maintained with this
> change. drm_gem_cma_dumb_create() always creates a kernel mapping as
Hi Rob,
Thank you for the patch.
On Mon, Oct 21, 2019 at 04:45:47PM -0500, Rob Herring wrote:
> In preparation to allow DRM CMA users to adjust the DMA_ATTR_* flags,
> convert the CMA helper code to use the dma_*_attr APIs instead of the
> dma_*_wc variants.
>
> Only the DMA_ATTR_WRITE_COMBINE a
1 - 100 of 172 matches
Mail list logo
