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 to specify
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.
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 -
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
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=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 specify
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
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://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.
>
>
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
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:
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
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
> > > +++
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:
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
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
> > ---
> >
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
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
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
https://bugs.freedesktop.org/show_bug.cgi?id=111481
Daniel Suarez changed:
What|Removed |Added
Priority|not set |highest
--
You are receiving this
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
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
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
>
>
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
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
>
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
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:
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:
>
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
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
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
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
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
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
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:
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
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
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
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
* 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
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
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
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
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
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
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
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. 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
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
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
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.
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:
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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;
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
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
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=edit
failed suspend 5.4.0rc2
Issue still occurs on 5.4rc2. In these logs, on the second suspension.
Thinkpad
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
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
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
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 indicate
> if dumb buffer allocation needs a kernel mapping. This is needed
On Hyper-V, Generation 1 VMs can directly use VM's physical memory for
their framebuffers. This can improve the efficiency of framebuffer and
overall performence for VM. The physical memory assigned to framebuffer
must be contiguous. We use CMA allocator to get contiguouse physicial
memory when
tags/du-next-20191022
for you to fetch changes up to aad1552f1defd3a5334cd4b2573fae9963d4db57:
drm: rcar-du: crtc: Register GAMMA_LUT properties (2019-10-22 13:21:18 +0300)
- R-Car DU Color Management Module support
0191016' of git://linuxtv.org/pinchartl/media into
> drm-next (2019-10-22 15:04:07 +1000)
>
> are available in the Git repository at:
>
> git://linuxtv.org/pinchartl/media.git tags/du-next-20191022
>
> for you to fetch changes up to 153f2971b58764b7238989489bd45ca0f491f74a:
>
-20191022
for you to fetch changes up to 153f2971b58764b7238989489bd45ca0f491f74a:
arm64: dts: renesas: Add CMM units to Gen3 SoCs (2019-10-22 13:21:18 +0300)
- R-Car DU Color Management Module support
This patch implements prepare_fb() and cleanup_fb() in hibmc with the
GEM VRAM helpers. In the current code, pinning the BO is performed by
hibmc_plane_atomic_update(), where the operation does not belong.
This patch also fixes a bug where the pinned BO was never unpinned.
Pinning multiple BOs
GEM VRAM provides an implementation for prepare_fb() and cleanup_fb()
of struct drm_plane_helper_funcs. Switch over vboxvideo.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/vboxvideo/vbox_mode.c | 61 ++-
1 file changed, 4 insertions(+), 57 deletions(-)
diff
The new helpers pin and unpin a framebuffer's GEM VRAM objects during
plane updates. This should be sufficient for most drivers prepare_fb and
cleanup_fb implementations.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_vram_helper.c | 81 +++
GEM VRAM provides an implementation for prepare_fb() and cleanup_fb()
of struct drm_simple_display_pipe_funcs. Switch over bochs.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/bochs/bochs_kms.c | 26 ++
1 file changed, 2 insertions(+), 24 deletions(-)
diff --git
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 simple-pipeline and 'full-pipeline' drivers.
Before, the functions received
The implementation of the plane's call-back functions prepare_fb() and
cleanup_fb() for GEM VRAM helpers are sharable among drivers.
The first patch adapts the the interface of simple KSM helpers such that
bochs can benefit from the shared code. We add the helper functions in
patch #2. Patches #3
On Tue, Oct 22, 2019 at 10:36:24AM +0200, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> The GPIO backlight driver currently requests the line 'as is', without
> acively setting its direction. This can lead to problems: if the line
> is in input mode by default, we won't be able to
1 - 100 of 162 matches
Mail list logo
