21. 4. 13. 오후 6:48에 Daniel Vetter 이(가) 쓴 글:
> Since
>
> commit 890880ddfdbe256083170866e49c87618b706ac7
> Author: Paul Kocialkowski
> Date: Fri Jan 4 09:56:10 2019 +0100
>
> drm: Auto-set allow_fb_modifiers when given modifiers at plane init
>
> this is done automatically as part of pla
We already don't have accurate BO fences in some cases. Instead, BOs can
have fences which are equal to the last seen command buffer for each queue.
It's practically the same as if the kernel had no visibility into command
submissions and just added a fence into all queues when it needed to wait
fo
https://bugzilla.kernel.org/show_bug.cgi?id=212729
Bug ID: 212729
Summary: amdgpu: WARN_ON
drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:1
19 set_reg_field_values.constprop.0+0xbe/0xe0
Product: Drivers
Vers
Arnd Bergmann wrote on Mon, Apr 19, 2021 at 02:16:36PM +0200:
> In some cases, you can use the device_link infrastructure to deal
> with dependencies between devices. Not sure if this would help
> in your case, but have a look at device_link_add() etc in drivers/base/core.c
I'll need to actually t
On 2021-04-11 17:01, Dmitry Baryshkov wrote:
msm_dsi_phy_get_clk_provider() always returns two provided clocks, so
return 0 instead of returning incorrect -EINVAL error code.
Fixes: 5d13459650b3 ("drm/msm/dsi: push provided clocks handling into
a generic code")
Signed-off-by: Dmitry Baryshkov
On 2021-04-09 18:19, Dmitry Baryshkov wrote:
The parent_name initialization was lost in refactoring, restore it now.
Fixes: 5d13459650b3 ("drm/msm/dsi: push provided clocks handling into
a generic code")
Reported-by: kernel test robot
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
On Mon, Apr 19, 2021 at 06:55:05PM -0400, Lyude Paul wrote:
> When moving around drm_dp_aux_register() calls, it turned out we
> accidentally managed to cause issues with the Tegra driver due to the fact
> the Tegra driver would attempt to retrieve a reference to the AUX channel's
> i2c adapter - w
And finally, convert all of the code in drm_dp_mst_topology.c over to using
drm_err() and drm_dbg*(). Note that this refactor would have been a lot
more complicated to have tried writing a coccinelle script for, so this
whole thing was done by hand.
v2:
* Fix line-wrapping in drm_dp_mst_atomic_che
Next step in the conversion, move everything in drm_dp_dual_mode_helper.c
over to using drm_err() and drm_dbg_kms(). This was done using the
following cocci script:
@@
expression list expr;
@@
(
- DRM_DEBUG_KMS(expr);
+ drm_dbg_kms(dev, expr);
|
- DRM_ERROR(expr);
+ drm_err(dev,
Since this is one of the few functions in drm_dp_mst_topology.c that
doesn't have any way of getting access to a drm_device, let's pass the
drm_dp_mst_topology_mgr down to this function so that it can use
drm_dbg_kms().
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_mst_topology.c |
Now that we've added a back-pointer to drm_device to drm_dp_aux, made
drm_dp_aux available to any functions in drm_dp_helper.c which need to
print to the kernel log, and ensured all of our logging uses a consistent
format, let's do the final step of the conversion and actually move
everything over
While this shouldn't really be something that happens all that often, since
we're going to be using the drm_dbg_* log helpers in DRM helpers it's
technically possible that a driver could use an AUX adapter before it's
been associated with it's respective drm_device. While drivers should take
care t
Since we're about to be using drm_dbg_*() throughout the DP helpers, we'll
need to be able to access the DRM device in the dual mode DP helpers as
well. Note however that since drm_dp_dual_mode_detect() can be called with
DDC adapters that aren't part of a drm_dp_aux struct, we need to pass down
th
So that we can start using drm_dbg_*() throughout the DRM DP helpers.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_dual_mode_helper.c | 8 +---
drivers/gpu/drm/i915/display/intel_lspcon.c | 12 +++-
include/drm/drm_dp_dual_mode_helper.h | 4 ++--
3 files changed, 14
Another function we need to pass drm_device down to in order to start using
drm_dbg_*().
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_dual_mode_helper.c | 3 ++-
drivers/gpu/drm/i915/display/intel_hdmi.c | 2 +-
include/drm/drm_dp_dual_mode_helper.h | 2 +-
3 files changed, 4 inserti
Another function that we'll need to pass a drm_device (and not drm_dp_aux)
down to so that we can move over to using drm_dbg_*().
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_dual_mode_helper.c | 3 ++-
drivers/gpu/drm/i915/display/intel_hdmi.c | 3 +--
include/drm/drm_dp_dual_mode_helpe
Since we're about to convert everything in drm_dp_helper.c over to using
drm_dbg_*(), let's also make our logging more consistent in drm_dp_helper.c
while we're at it to ensure that we always print the name of the AUX
channel in question.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_help
Another function to pass drm_device * down to so we can start using the
drm_dbg_*() in the DRM DP helpers.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_dual_mode_helper.c | 5 +++--
include/drm/drm_dp_dual_mode_helper.h | 2 +-
2 files changed, 4 insertions(+), 3 deletions(-)
diff -
So that we can start using drm_dbg_*() for
drm_dp_link_train_channel_eq_delay() and
drm_dp_lttpr_link_train_channel_eq_delay().
Signed-off-by: Lyude Paul
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 2 +-
drivers/gpu/drm/drm_dp_helper.c
So that we can start using drm_dbg_*() in
drm_dp_link_train_clock_recovery_delay().
Signed-off-by: Lyude Paul
Reviewed-by: Laurent Pinchart
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 2 +-
drivers/gpu/drm/drm_dp_helper.c | 3 ++-
The docs we had for drm_dp_aux_init() and drm_dp_aux_register() were mostly
correct, except for the fact that they made the assumption that all AUX
devices were grandchildren of their respective DRM devices. This is the
case for most normal GPUs, but is almost never the case with SoCs and
display b
This is something that we've wanted for a while now: the ability to
actually look up the respective drm_device for a given drm_dp_aux struct.
This will also allow us to transition over to using the drm_dbg_*() helpers
for debug message printing, as we'll finally have a drm_device to reference
for d
Since AUX adapters on nouveau have their respective DRM connectors as
parents, we need to make sure that we register then after their connectors.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 25 -
1 file changed, 20 insertions(+), 5 deletions(-)
Just adds some missing calls to
drm_dp_aux_register()/drm_dp_aux_unregister() for when we attach/detach the
bridge.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/br
When moving around drm_dp_aux_register() calls, it turned out we
accidentally managed to cause issues with the Tegra driver due to the fact
the Tegra driver would attempt to retrieve a reference to the AUX channel's
i2c adapter - which wouldn't be initialized until drm_dp_aux_register() is
called.
Since we're about to make it so that drm_dp_aux_init() can fail (and thus -
should have it's return value checked) - we should require that callers of
drm_dp_aux_register() also check it's return value since drm_dp_aux_init()
can be called from there.
Signed-off-by: Lyude Paul
---
include/drm/dr
While working on moving i2c device registration into drm_dp_aux_init() - I
realized that in order to do so we need to make sure that drivers calling
drm_dp_aux_init() handle any errors it could possibly return. In the
process of doing that, I noticed that the majority of AMD's code for DP
connector
Since it's been asked quite a few times on some of the various DP
related patch series I've submitted to use the new DRM printk helpers,
and it technically wasn't really trivial to do this before due to the
lack of a consistent way to find a drm_device for an AUX channel, this
patch series aims to
On Mon 19-04-21 17:44:13, Christian König wrote:
> Am 19.04.21 um 17:19 schrieb peter.enderb...@sony.com:
> > On 4/19/21 5:00 PM, Michal Hocko wrote:
> > > On Mon 19-04-21 12:41:58, peter.enderb...@sony.com wrote:
> > > > On 4/19/21 2:16 PM, Michal Hocko wrote:
> > > > > On Sat 17-04-21 12:40:32, P
On Mon 19-04-21 12:41:58, peter.enderb...@sony.com wrote:
> On 4/19/21 2:16 PM, Michal Hocko wrote:
> > On Sat 17-04-21 12:40:32, Peter Enderborg wrote:
> >> This adds a total used dma-buf memory. Details
> >> can be found in debugfs, however it is not for everyone
> >> and not always available. dm
On Sun, Apr 18, 2021 at 1:03 AM Dave Airlie wrote:
>
> Hi Zack,
>
> Please make sure to always cc dri-devel and/or Daniel on these so if
> I'm away they don't get lost, but also so that they make it into
> patchwork for processing.
>
> If you have a chance can you resend it, I'll see if we can pro
On 4/19/21 10:10 AM, Randy Dunlap wrote:
> On 4/19/21 2:01 AM, Robert Foss wrote:
>> The DRM_SIL_SII8620 kconfig has a weak `imply` dependency
>> on EXTCON, which causes issues when sii8620 is built
>> as a builtin and EXTCON is built as a module.
>>
>> The symptoms are 'undefined reference' errors
On Mon, Apr 19, 2021, 19:11 Randy Dunlap wrote:
> On 4/19/21 2:01 AM, Robert Foss wrote:
> > The DRM_SIL_SII8620 kconfig has a weak `imply` dependency
> > on EXTCON, which causes issues when sii8620 is built
> > as a builtin and EXTCON is built as a module.
> >
> > The symptoms are 'undefined ref
On 4/19/21 2:01 AM, Robert Foss wrote:
> The DRM_SIL_SII8620 kconfig has a weak `imply` dependency
> on EXTCON, which causes issues when sii8620 is built
> as a builtin and EXTCON is built as a module.
>
> The symptoms are 'undefined reference' errors caused
> by the symbols in EXTCON not being av
Add an entry for the new uAPI needed for DG1. Also add the overall
upstream plan, including some notes for the TTM conversion.
v2(Daniel):
- include the overall upstreaming plan
- add a note for mmap, there are differences here for TTM vs i915
- bunch of other suggestions from Daniel
v3:
(D
I can not remember why the original code did return 0 rather than an error, but
-ENOMEM seems indeed way more fitting.
Reviewed-by: Pierre Moreau
On 2021-04-14 — 08:58, Dan Carpenter wrote:
> If nouveau_get_backlight_name() fails then this should return -ENOMEM
> but currently it returns success
Add the E Ink Corporation to the vendor bindings.
Signed-off-by: Alistair Francis
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml
b/Documentation/devicetree/bindings/vendor-pr
Add support for the 10.3" E Ink panel described at:
https://www.eink.com/product.html?type=productdetail&id=7
Signed-off-by: Alistair Francis
---
drivers/gpu/drm/panel/panel-simple.c | 29
1 file changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-sim
Tested-by: Nirmoy Das
On 4/19/21 11:28 AM, Christian König wrote:
vmwgfx is the only driver actually using this. Move the handling into
the driver instead.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 11 ---
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 10 ++
Am 19.04.21 um 18:11 schrieb Michal Hocko:
On Mon 19-04-21 17:44:13, Christian König wrote:
Am 19.04.21 um 17:19 schrieb peter.enderb...@sony.com:
On 4/19/21 5:00 PM, Michal Hocko wrote:
On Mon 19-04-21 12:41:58, peter.enderb...@sony.com wrote:
On 4/19/21 2:16 PM, Michal Hocko wrote:
On Sa
On Sat 17-04-21 12:40:32, Peter Enderborg wrote:
> This adds a total used dma-buf memory. Details
> can be found in debugfs, however it is not for everyone
> and not always available. dma-buf are indirect allocated by
> userspace. So with this value we can monitor and detect
> userspace application
On 4/19/21 5:00 PM, Michal Hocko wrote:
> On Mon 19-04-21 12:41:58, peter.enderb...@sony.com wrote:
>> On 4/19/21 2:16 PM, Michal Hocko wrote:
>>> On Sat 17-04-21 12:40:32, Peter Enderborg wrote:
This adds a total used dma-buf memory. Details
can be found in debugfs, however it is not for
Not going to comment on everything on the first pass...
On Mon, Apr 19, 2021 at 5:48 AM Marek Olšák wrote:
>
> Hi,
>
> This is our initial proposal for explicit fences everywhere and new memory
> management that doesn't use BO fences. It's a redesign of how Linux graphics
> drivers work, and it
Am 19.04.21 um 17:19 schrieb peter.enderb...@sony.com:
On 4/19/21 5:00 PM, Michal Hocko wrote:
On Mon 19-04-21 12:41:58, peter.enderb...@sony.com wrote:
On 4/19/21 2:16 PM, Michal Hocko wrote:
On Sat 17-04-21 12:40:32, Peter Enderborg wrote:
This adds a total used dma-buf memory. Details
can
Hi,
On Fri, Apr 16, 2021 at 7:32 PM kernel test robot wrote:
>
> Hi Douglas,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on next-20210416]
> [cannot apply to wsa/i2c/for-next robh/for-next linus/master v5.12-rc7
> v5.12-rc6 v5.12-rc5 v5.12-rc7]
> [If your patch is
On Mon, Apr 19, 2021 at 7:02 AM Matthew Auld wrote:
>
> On 16/04/2021 17:38, Jason Ekstrand wrote:
> > On Thu, Apr 15, 2021 at 11:04 AM Matthew Auld
> > wrote:
> >>
> >> Add an entry for the new uAPI needed for DG1.
> >>
> >> v2(Daniel):
> >>- include the overall upstreaming plan
> >>- a
Replace the deprecated API with new helpers, according to the TODO list
of the DRM subsystem. The new API has been introduced with commit
b7ea04d299c7: DRM_MODESET_LOCK_ALL_BEGIN() simplifies grabbing all modeset
locks using a local context and has the advantage of reducing boilerplate.
Signed-off
Replace the deprecated API with new helpers, according to the TODO list
of the DRM subsystem. The new API has been introduced with commit
b7ea04d299c7: DRM_MODESET_LOCK_ALL_BEGIN() simplifies grabbing all modeset
locks using a local context and has the advantage of reducing boilerplate.
Signed-off
Replace the deprecated API with new helpers, according to the TODO list
of the DRM subsystem. The new API has been introduced with commit
b7ea04d299c7: DRM_MODESET_LOCK_ALL_BEGIN() simplifies grabbing all modeset
locks using a local context. This has the advantage of reducing boilerplate.
Change
On 19/04/2021 15:37, Matthew Auld wrote:
On 19/04/2021 15:07, Tvrtko Ursulin wrote:
On 19/04/2021 12:30, Matthew Auld wrote:
On 15/04/2021 12:05, Tvrtko Ursulin wrote:
On 15/04/2021 10:23, Matthew Auld wrote:
On Thu, 15 Apr 2021 at 09:21, Tvrtko Ursulin
wrote:
On 14/04/2021 17:20, Matt
On Mon, 19 Apr 2021, Fabio M. De Francesco wrote:
> On Monday, April 19, 2021 3:08:51 PM CEST Julia Lawall wrote:
> > On Mon, 19 Apr 2021, Fabio M. De Francesco wrote:
> > > Replace the deprecated API with new helpers, according to the TODO list
> > > of the DRM subsystem.
> >
> > The commit me
On 19/04/2021 15:07, Tvrtko Ursulin wrote:
On 19/04/2021 12:30, Matthew Auld wrote:
On 15/04/2021 12:05, Tvrtko Ursulin wrote:
On 15/04/2021 10:23, Matthew Auld wrote:
On Thu, 15 Apr 2021 at 09:21, Tvrtko Ursulin
wrote:
On 14/04/2021 17:20, Matthew Auld wrote:
On Wed, 14 Apr 2021 at 16:
On 16/04/2021 15:25, Matthew Auld wrote:
On 14/04/2021 16:33, Tvrtko Ursulin wrote:
On 12/04/2021 10:05, Matthew Auld wrote:
From: Anusha Srivatsa
In the scenario where local memory is available, we have
rely on CPU access via lmem directly instead of aperture.
v2:
gmch is only relevant fo
On 16/04/2021 16:04, Matthew Auld wrote:
On 14/04/2021 16:01, Tvrtko Ursulin wrote:
On 12/04/2021 10:05, Matthew Auld wrote:
From: CQ Tang
Add "REGION_STOLEN" device info to dg1, create stolen memory
region from upper portion of local device memory, starting
from DSMBASE.
v2:
- s/drm_
On 19/04/2021 12:30, Matthew Auld wrote:
On 15/04/2021 12:05, Tvrtko Ursulin wrote:
On 15/04/2021 10:23, Matthew Auld wrote:
On Thu, 15 Apr 2021 at 09:21, Tvrtko Ursulin
wrote:
On 14/04/2021 17:20, Matthew Auld wrote:
On Wed, 14 Apr 2021 at 16:22, Tvrtko Ursulin
wrote:
On 12/04/2021
On Monday, April 19, 2021 3:08:51 PM CEST Julia Lawall wrote:
> On Mon, 19 Apr 2021, Fabio M. De Francesco wrote:
> > Replace the deprecated API with new helpers, according to the TODO list
> > of the DRM subsystem.
>
> The commit message will perhaps not be very meaningful one year from now.
> Yo
On 4/18/21 9:27 PM, Alice Guo (OSS) wrote:
> From: Alice Guo
>
> Update all the code that use soc_device_match because add support for
> soc_device_match returning -EPROBE_DEFER.
>
> Signed-off-by: Alice Guo
> ---
[ ... ]
> drivers/watchdog/renesas_wdt.c| 2 +-
> 48 files chan
On Mon, Apr 19, 2021 at 05:28:53PM +0800, Christian König wrote:
> vmwgfx is the only driver actually using this. Move the handling into
> the driver instead.
>
> Signed-off-by: Christian König
Acked-by: Huang Rui
> ---
> drivers/gpu/drm/ttm/ttm_bo.c | 11 ---
> drivers/gpu/drm/
From: Zack Rusin
commit ab4d9913632b1e5ffcf3365783e98718b3c83c7f upstream.
We were not correctly unpinning no longer needed buffers. In particular
vmw_buffer_object, which is internally often pinned on creation wasn't
unpinned on destruction and none of the internal MOB buffers were
unpinned bef
On Mon, 19 Apr 2021, Fabio M. De Francesco wrote:
> Replace the deprecated API with new helpers, according to the TODO list
> of the DRM subsystem.
The commit message will perhaps not be very meaningful one year from now.
You could say for example DRM_MODESET_LOCK_ALL_BEGIN was introduced in
c
On 4/19/21 2:16 PM, Michal Hocko wrote:
> On Sat 17-04-21 12:40:32, Peter Enderborg wrote:
>> This adds a total used dma-buf memory. Details
>> can be found in debugfs, however it is not for everyone
>> and not always available. dma-buf are indirect allocated by
>> userspace. So with this value we
Replace the deprecated API with new helpers, according to the TODO list
of the DRM subsystem.
Signed-off-by: Fabio M. De Francesco
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/driv
Replace the deprecated API with new helpers, according to the TODO list
of the DRM subsystem.
Signed-off-by: Fabio M. De Francesco
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amd
According to the TODO list of the DRM subsystem, replace the deprecated
drm_modeset_*_all() with DRM_MODESET_LOCK_ALL_*().
Fabio M. De Francesco (2):
drm/amd/amdgpu/amdgpu_device.c: Replace drm_modeset_*_all with
DRM_MODESET_LOCK_ALL_*
drm/amd/amdgpu/amdgpu_drv.c: Replace drm_modeset_*_all
On Mon, Apr 19, 2021 at 11:33 AM Dominique MARTINET
wrote:
> Geert Uytterhoeven wrote on Mon, Apr 19, 2021 at 11:03:24AM +0200:
>
> > soc_device_match() should only be used as a last resort, to identify
> > systems that cannot be identified otherwise. Typically this is used for
> > quirks, which
Hi all,
I'm working on a Wayland extension [1] that, among other things, allows
compositors to advertise the preferred device to be used by Wayland
clients.
In general, compositors will send a render node. However, in the case
of split render/display SoCs, things get a little bit complicated.
Th
On 16/04/2021 17:38, Jason Ekstrand wrote:
On Thu, Apr 15, 2021 at 11:04 AM Matthew Auld wrote:
Add an entry for the new uAPI needed for DG1.
v2(Daniel):
- include the overall upstreaming plan
- add a note for mmap, there are differences here for TTM vs i915
- bunch of other suggesti
Reviewed-by: Karol Herbst
On Fri, Apr 16, 2021 at 4:38 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/dispnv50/disp.c:2599:1: warning: no previous
> prototype for ‘nv50_display_create’ [-Wmissing-prototypes]
>
> Cc: Ben Skeggs
> Cc: David
Reviewed-by: Karol Herbst
On Fri, Apr 16, 2021 at 4:38 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/nouveau_ioc32.c:2: warning: Cannot understand *
> file mga_ioc32.c
>
> Cc: Ben Skeggs
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: dri
Reviewed-by: Karol Herbst
On Fri, Apr 16, 2021 at 4:38 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/nouveau_ioc32.c:52: warning: Function parameter or
> member 'filp' not described in 'nouveau_compat_ioctl'
> drivers/gpu/drm/nouveau/nouv
On Fri, Apr 16, 2021 at 4:38 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/nouveau_svm.c: In function ‘nouveau_pfns_map’:
> drivers/gpu/drm/nouveau/nouveau_svm.c:810:6: warning: variable ‘ret’ set but
> not used [-Wunused-but-set-variable]
Reviewed-by: Karol Herbst
On Fri, Apr 16, 2021 at 4:38 PM Lee Jones wrote:
>
> Fixes the following build error:
>
> drivers/gpu/drm/nouveau/dispnv50/disp.c:2530:1: error: conflicting types for
> ‘nv50_display_fini’
> In file included from drivers/gpu/drm/nouveau/dispnv50/disp.c:71:
> drivers
Reviewed-by: Karol Herbst
On Fri, Apr 16, 2021 at 4:38 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/dispnv50/headc57d.c:173:1: warning: no previous
> prototype for ‘headc57d_olut’ [-Wmissing-prototypes]
>
> Cc: Ben Skeggs
> Cc: David Air
On Fri, Apr 16, 2021 at 4:38 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/dispnv50/disp.c: In function ‘nv50_mstm_cleanup’:
> drivers/gpu/drm/nouveau/dispnv50/disp.c:1357:6: warning: variable ‘ret’ set
> but not used [-Wunused-but-set-vari
Reviewed-by: Karol Herbst
On Fri, Apr 16, 2021 at 4:38 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/dispnv04/crtc.c:462: warning: Function parameter or
> member 'crtc' not described in 'nv_crtc_mode_set_regs'
> drivers/gpu/drm/nouveau/di
Reviewed-by: Karol Herbst
On Fri, Apr 16, 2021 at 4:37 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/nouveau_bo.c: In function ‘nouveau_ttm_tt_populate’:
> drivers/gpu/drm/nouveau/nouveau_bo.c:1228:17: warning: variable ‘dev’ set
> but no
Reviewed-by: Karol Herbst
On Fri, Apr 16, 2021 at 4:37 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c:53: warning: Function
> parameter or member 'speedo' not described in 'gk20a_volt_get_cvb_voltage'
> drivers/gpu
Reviewed-by: Karol Herbst
On Fri, Apr 16, 2021 at 4:37 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c:992: warning: Function
> parameter or member 'gr' not described in 'gf100_gr_wait_idle'
>
> Cc: Ben Skeggs
> Cc: D
On Fri, Apr 16, 2021 at 4:37 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/dispnv50/disp.c:1381:6: warning: variable ‘ret’ set
> but not used [-Wunused-but-set-variable]
>
not a big fan of just ignoring return codes, I'd rather see it handl
Reviewed-by: Karol Herbst
On Fri, Apr 16, 2021 at 4:37 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:584: warning: Function
> parameter or member 'init' not described in 'init_reserved'
> drivers/gpu/drm/nouveau/nv
On 15/04/2021 12:05, Tvrtko Ursulin wrote:
On 15/04/2021 10:23, Matthew Auld wrote:
On Thu, 15 Apr 2021 at 09:21, Tvrtko Ursulin
wrote:
On 14/04/2021 17:20, Matthew Auld wrote:
On Wed, 14 Apr 2021 at 16:22, Tvrtko Ursulin
wrote:
On 12/04/2021 10:05, Matthew Auld wrote:
From: Venkata S
struct tegra_dc is declared at 13rd line.
The declaration here is unnecessary. Remove it.
Signed-off-by: Wan Jiabing
---
drivers/gpu/drm/tegra/hub.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/tegra/hub.h b/drivers/gpu/drm/tegra/hub.h
index 3efa1be07ff8..23c4b2115ed1 10064
Add a note about the two-step process.
v2(Tvrtko):
- Also document the other method of just passing in a buffer which is
large enough, which avoids two ioctl calls. Can make sense for
smaller query items.
v3: prefer kernel-doc references for structs and members
Suggested-by: Daniel Vett
Add some example usage for the extension chaining also, which is quite
nifty.
v2: (Daniel)
- clarify that the name is just some integer, also document that the
name space is not global
v3: prefer kernel-doc references for structs
Suggested-by: Daniel Vetter
Signed-off-by: Matthew Auld
Cc:
Add section for drm/i915 uAPI and pull in i915_drm.h.
Suggested-by: Daniel Vetter
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Jordan Justen
Cc: Daniel Vetter
Cc: Kenneth Graunke
Cc: Jason Ekstrand
Cc: Dave Airlie
Cc: dri-devel@lists.freedesktop.org
Cc: mesa-...@lists.freedesktop.or
Fix the cases where it is almost already valid kernel doc, for the
others just nerf the warnings for now.
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Jordan Justen
Cc: Daniel Vetter
Cc: Kenneth Graunke
Cc: Jason Ekstrand
Cc: Dave Airlie
Cc: dri-devel@lists.freedesktop.org
Cc: mesa-.
Hi,
This is our initial proposal for explicit fences everywhere and new memory
management that doesn't use BO fences. It's a redesign of how Linux
graphics drivers work, and it can coexist with what we have now.
*1. Introduction*
(skip this if you are already sold on explicit fences)
The curren
Lee Jones 於 2021年4月19日 週一 下午3:24寫道：
>
> On Mon, 19 Apr 2021, Lee Jones wrote:
>
> > On Mon, 19 Apr 2021, Lee Jones wrote:
> >
> > > On Mon, 19 Apr 2021, ChiYuan Huang wrote:
> > >
> > > > Hi, Linux mfd reviewers:
> > > >It's been three weeks not to get any response from you.
> > > > Is there s
Hi Joonas and Rodrigo -
Here's the gen to ver conversion topic branch to be merged to both
drm-intel-next and drm-intel-gt-next.
Lots of Cc's for heads up.
BR,
Jani.
topic/intel-gen-to-ver-2021-04-19:
Gen to ver conversions across the driver
The main change is Lucas' series [1], with Ville'
Hey Neil,
Thanks for the quick respin.
Reviewed-by: Robert Foss
On Mon, 19 Apr 2021 at 09:12, Neil Armstrong wrote:
>
> From: Phong LE
>
> This commit is a simple driver for bridge HMDI it66121.
> The input format is RBG and there is no color conversion.
> Audio, HDCP and CEC are not supporte
Geert Uytterhoeven wrote on Mon, Apr 19, 2021 at 11:03:24AM +0200:
> > This is going to need quite some more work to be acceptable, in my
> > opinion, but I think it should be possible.
>
> In general, this is very hard to do, IMHO. Some drivers may be used on
> multiple platforms, some of them
vmwgfx is the only driver actually using this. Move the handling into
the driver instead.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 11 ---
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 10 ++
include/drm/ttm/ttm_bo_api.h | 19 ---
3 fil
Hi Dominique,
CC Arnd (soc_device_match() author)
On Mon, Apr 19, 2021 at 7:03 AM Dominique MARTINET
wrote:
> Alice Guo (OSS) wrote on Mon, Apr 19, 2021 at 12:27:22PM +0800:
> > From: Alice Guo
> > Update all the code that use soc_device_match
>
> A single patch might be difficult to accept for
The DRM_SIL_SII8620 kconfig has a weak `imply` dependency
on EXTCON, which causes issues when sii8620 is built
as a builtin and EXTCON is built as a module.
The symptoms are 'undefined reference' errors caused
by the symbols in EXTCON not being available
to the sii8620 driver.
Fixes: 688838442147
Hi Alice,
CC Arnd (soc_device_match() author)
On Mon, Apr 19, 2021 at 6:28 AM Alice Guo (OSS) wrote:
> From: Alice Guo
>
> In i.MX8M boards, the registration of SoC device is later than caam
> driver which needs it. Caam driver needs soc_device_match to provide
> -EPROBE_DEFER when no SoC devic
Remove trailing whitespaces. No functional change.
Signed-off-by: Krzysztof Kozlowski
---
drivers/gpu/drm/gma500/backlight.c| 4 +--
drivers/gpu/drm/gma500/cdv_intel_dp.c | 50 +--
2 files changed, 26 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/gma5
Correct kerneldoc (remove wrong /** marker and adjust function name) to
fix W=1 warnings:
drivers/gpu/drm/gma500/cdv_intel_lvds.c:27: warning:
expecting prototype for LVDS I2C backlight control macros(). Prototype was
for BRIGHTNESS_MAX_LEVEL() instead
drivers/gpu/drm/gma500/intel_gmbus.
Hi Thomas,
On Fri, Apr 16, 2021 at 11:00 AM Thomas Zimmermann wrote:
> This patchset adds support for simple-framebuffer platform devices and
> a handover mechanism for native drivers to take-over control of the
> hardware.
>
> The new driver, called simpledrm, binds to a simple-frambuffer platfo
The MT8167 SoC have a hard limit on the maximal supported HDMI TMDS clock,
and is not validated and supported for HDMI modes out of HDMI CEA modes,
so add a configuration entry linked to the MT8167 compatible.
Signed-off-by: Fabien Parent
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/mediat
Some SoCs like the MT8167 have a hard limit on the maximal supported HDMI TMDS
clock, so add a configuration value to filter out those modes.
Signed-off-by: Fabien Parent
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/mediatek/mtk_hdmi.c | 5 +
1 file changed, 5 insertions(+)
diff --git
1 - 100 of 114 matches
Mail list logo
