Am 07.09.23 um 18:33 schrieb suijingfeng:
Hi,
On 2023/9/7 17:08, Christian König wrote:
I strongly suggest that you just completely drop this here
Drop this is OK, no problem. Then I will go to develop something else.
This version is not intended to merge originally, as it's a RFC.
Also,
The drm_colorspace enum member DRM_MODE_COLORIMETRY_COUNT has been
properly documented by moving the description out of the enum to the
member description list to get rid of an additional warning and improve
documentation clarity.
Signed-off-by: Javier Carrasco
Reviewed-by: Randy Dunlap
---
Chan
There are 'enum drm_ioctl_flags' and 'bool drm_ioctl_flags(...)' with the
same name, which is not a problem in C, but it can lead to
'WARNING: Duplicate C declaration' when generating documentation.
According to the purpose of the function, rename 'drm_ioctl_flags(...)' to
'drm_ioctl_flags_check(.
The supported_colorspaces parameter was added to the following
functions without documenting it:
drm_mode_create_dp_colorspace_property
drm_mode_create_hdmi_colorspace_property
The missing descriptions generate warnings when compiling the
documentation. Add the descriptions to document the
suppor
On 2023/9/7 5:13, Zack Rusin wrote:
Can we follow the namespace_action naming convention here? i.e.
drm_ioctl_flags_check instead. I find it a lot easier to look up/memorise the
api if
naming is consistent.
z
you are right!
I will send a new patch.
Hi Biju
On Tue, Jul 04, 2023 at 10:04:46AM +0100, Biju Das wrote:
> The LCD controller is composed of Frame Compression Processor (FCPVD),
> Video Signal Processor (VSPD), and Display Unit (DU).
>
> It has DPI/DSI interfaces and supports a maximum resolution of 1080p
> along with 2 RPFs to support
On 9/6/23 11:22 AM, Stefan x Nilsson wrote:
Add a new driver for the Sitronix st7735s display controller
together with a 0.96" 80x160 color TFT display by Winstar.
The driver is very similar to the st7735r driver, but uses a
different pipe_enable sequence and also allows for an
optional regulato
On 9/7/23 01:29, David Lechner wrote:
On 9/6/23 11:22 AM, Stefan x Nilsson wrote:
Add a new driver for the Sitronix st7735s display controller
together with a 0.96" 80x160 color TFT display by Winstar.
The driver is very similar to the st7735r driver, but uses a
different pipe_enable sequence a
The local variable loc in nvkm_acr_lsfw_load_sig_image_desc_v2()
is set but not used. Remove the variable and related code.
Signed-off-by: Bo Liu
---
drivers/gpu/drm/nouveau/nvkm/subdev/acr/lsfw.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/
> -Original Message-
> From: Intel-gfx On Behalf Of Jani
> Nikula
> Sent: Thursday, September 7, 2023 2:58 PM
> To: dri-devel@lists.freedesktop.org
> Cc: Nikula, Jani ; intel-...@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 2/6] drm/eld: replace uint8_t with u8
>
> Unify on kern
Since the commit b962a12050a3 ("drm/atomic: integrate modeset lock with
private objects") the DRM framework no longer requires the external
lock for private objects. Drop the lock, letting the DRM to manage
private object locking.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/mdp5
The Shared Memory Pool (SMP) state is a part of the MDP5's private
object state. Use existing infrastructure, atomic_print_state()
callback, to dump SMP state (which also makes it included into
debugfs/dri/N/state). This allows us to drop the custom debugfs file
too.
Signed-off-by: Dmitry Baryshko
While debugging one of the features in DRM/MSM I noticed that MSM
subdrivers still wrap private object access with manual modeset locking.
Since commit b962a12050a3 ("drm/atomic: integrate modeset lock with
private objects") this is no longer required, as the DRM framework
handles private objects i
Add calls to finalise global state object and corresponding lock.
Fixes: de3916c70a24 ("drm/msm/dpu: Track resources in global state")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/
Since the commit b962a12050a3 ("drm/atomic: integrate modeset lock with
private objects") the DRM framework no longer requires the external
lock for private objects. Drop the lock, letting the DRM to manage
private object locking.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1
The drm_atomic_print_new_state() already prints private object state via
drm_atomic_private_obj_print_state(). Add private object state dumping
to __drm_state_dump(), so that it is also included into drm_state_dump()
output and into debugfs/dri/N/state file.
Signed-off-by: Dmitry Baryshkov
---
d
The pull request you sent on Fri, 8 Sep 2023 12:45:13 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-next-2023-09-08
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/a48fa7efaf1161c1c898931fe4c7f0070964233a
Thank you!
--
Deet-doot-dot, I am a bot.
https://kor
On Thu, 7 Sept 2023 at 19:45, Dave Airlie wrote:
>
> Just a poke about the outstanding drm CI support pull request since I
> haven't see any movement on that in the week, hopefully it's not as
> difficult a problem as bcachefs :-)
I was assuming that it wouldn't interfere with anything else... an
Hey Linus,
Regular rounds of rc1 fixes, a large bunch for amdgpu since it's 3
weeks in one go, one i915, one nouveau and one ivpu. I think there
might be a few more fixes in misc that I haven't pulled in yet, but we
should get them all for rc2.
Just a poke about the outstanding drm CI support pul
On 19/08/2023 13:24, Mina Almasry wrote:
> On Sat, Aug 19, 2023 at 8:22 AM Jesper Dangaard Brouer
> wrote:
>>
>>
>>
>> On 19/08/2023 16.08, Willem de Bruijn wrote:
>>> On Sat, Aug 19, 2023 at 5:51 AM Jesper Dangaard Brouer
>>> wrote:
On 10/08/2023 03.57, Mina Almasry wrote:
>>
On 08/09/2023 04:26, Abhinav Kumar wrote:
_dpu_plane_calc_bw() uses integer variables to calculate the bandwidth
used during plane bandwidth calculations. However for high resolution
displays this overflows easily and leads to below errors
[dpu error]crtc83 failed performance check -7
Promote t
_dpu_plane_calc_bw() uses integer variables to calculate the bandwidth
used during plane bandwidth calculations. However for high resolution
displays this overflows easily and leads to below errors
[dpu error]crtc83 failed performance check -7
Promote the intermediate variables to u64 to avoid ov
On 08/09/2023 03:52, Abhinav Kumar wrote:
On 9/7/2023 5:35 PM, Dmitry Baryshkov wrote:
On 08/09/2023 03:32, Abhinav Kumar wrote:
_dpu_plane_calc_bw() uses integer variables to calculate the bandwidth
used during plane bandwidth calculations. However for high resolution
displays this overflows
On 9/7/2023 5:35 PM, Dmitry Baryshkov wrote:
On 08/09/2023 03:32, Abhinav Kumar wrote:
_dpu_plane_calc_bw() uses integer variables to calculate the bandwidth
used during plane bandwidth calculations. However for high resolution
displays this overflows easily and leads to below errors
Can we
On 09/08/2023 18:57, Mina Almasry wrote:
> Add a netdev_dmabuf_binding struct which represents the
> dma-buf-to-netdevice binding. The netlink API will bind the dma-buf to
> an rx queue on the netdevice. On the binding, the dma_buf_attach
> & dma_buf_map_attachment will occur. The entries in the sg
On 08/09/2023 03:32, Abhinav Kumar wrote:
_dpu_plane_calc_bw() uses integer variables to calculate the bandwidth
used during plane bandwidth calculations. However for high resolution
displays this overflows easily and leads to below errors
Can we move the u64 conversion closer to the place wher
_dpu_plane_calc_bw() uses integer variables to calculate the bandwidth
used during plane bandwidth calculations. However for high resolution
displays this overflows easily and leads to below errors
[dpu error]crtc83 failed performance check -7
Promote the intermediate variables to u64 to avoid ov
Quoting Dmitry Baryshkov (2023-09-07 14:48:54)
> On 08/09/2023 00:34, Stephen Boyd wrote:
> > Quoting Dmitry Baryshkov (2023-09-03 15:24:32)
> >> diff --git a/drivers/gpu/drm/msm/dp/dp_panel.c
> >> b/drivers/gpu/drm/msm/dp/dp_panel.c
> >> index 97ba41593820..1cb54f26f5aa 100644
> >> --- a/drivers/
On 08/09/2023 00:34, Stephen Boyd wrote:
Quoting Dmitry Baryshkov (2023-09-03 15:24:32)
diff --git a/drivers/gpu/drm/msm/dp/dp_panel.c
b/drivers/gpu/drm/msm/dp/dp_panel.c
index 97ba41593820..1cb54f26f5aa 100644
--- a/drivers/gpu/drm/msm/dp/dp_panel.c
+++ b/drivers/gpu/drm/msm/dp/dp_panel.c
@@ -
Quoting Jani Nikula (2023-09-01 07:20:34)
> The DP CTS test for EDID last block checksum expects the checksum for
> the last block, invalid or not. Skip the validity check.
>
> For the most part (*), the EDIDs returned by drm_get_edid() will be
> valid anyway, and there's the CTS workaround to get
Quoting Dmitry Baryshkov (2023-09-03 15:24:32)
> diff --git a/drivers/gpu/drm/msm/dp/dp_panel.c
> b/drivers/gpu/drm/msm/dp/dp_panel.c
> index 97ba41593820..1cb54f26f5aa 100644
> --- a/drivers/gpu/drm/msm/dp/dp_panel.c
> +++ b/drivers/gpu/drm/msm/dp/dp_panel.c
> @@ -162,6 +162,11 @@ int dp_panel_re
On 8/16/2023 16:13, Daniele Ceraolo Spurio wrote:
If we can't load the HuC due to an injected failure, we don't want
to throw and error and trip CI. Using the gt_probe_error macro for
logging ensure that the error is only printed if it wasn't explicitly
injected.
v2: keep the line to less than 1
On 8/29/2023 12:03 PM, Uma Shankar wrote:
Add the documentation for the new proposed Plane Color Pipeline.
Co-developed-by: Chaitanya Kumar Borah
Signed-off-by: Chaitanya Kumar Borah
Signed-off-by: Uma Shankar
---
.../gpu/rfc/plane_color_pipeline.rst | 394 ++
1
https://bugzilla.kernel.org/show_bug.cgi?id=205089
Alexey Kuznetsov (a...@me.com) changed:
What|Removed |Added
CC||a...@me.com
--- Comment
Hi,
On 2023/9/7 17:08, Christian König wrote:
I strongly suggest that you just completely drop this here
Drop this is OK, no problem. Then I will go to develop something else.
This version is not intended to merge originally, as it's a RFC.
Also, the core mechanism already finished, it is
Am 07.09.23 um 17:26 schrieb suijingfeng:
[SNIP]
Then, I'll give you another example, see below for elaborate description.
I have one AMD BC160 GPU, see[1] to get what it looks like.
The GPU don't has a display connector interface exported.
It actually can be seen as a render-only GPU or comp
Hi,
On 2023/9/7 20:43, Christian König wrote:
Am 07.09.23 um 14:32 schrieb suijingfeng:
Hi,
On 2023/9/7 17:08, Christian König wrote:
Well, I have over 25 years of experience with display hardware and
what you describe here was never an issue.
I want to give you an example to let you kno
Hi Thomas,
On Thu, Sep 07, 2023 at 03:53:39PM +0200, Thomas Hellström wrote:
> Check that object freeing from within drm_exec_fini() works as expected
> and is unlikely to generate any warnings.
>
> v3:
> - Condition the test on CONFIG_DEBUG_LOCK_ALLOC
> - Make the test fail if the situation that
On Thu, 7 Sep 2023 15:53:38 +0200, Thomas Hellström wrote:
> when using __drm_kunit_helper_alloc_drm_device() the driver may be
> dereferenced by device-managed resources up until the device is
> freed, which is typically later than the kunit-managed resource code
> frees it. Fix this by simply ma
Am 07.09.23 um 16:47 schrieb Thomas Hellström:
Hi,
On 9/7/23 16:37, Christian König wrote:
Am 07.09.23 um 15:53 schrieb Thomas Hellström:
While trying to replicate a weird drm_exec lock alloc tracking warning
using the drm_exec kunit test, the warning was shadowed by a UAF
warning
from KASAN
Hi,
On 9/7/23 16:37, Christian König wrote:
Am 07.09.23 um 15:53 schrieb Thomas Hellström:
While trying to replicate a weird drm_exec lock alloc tracking warning
using the drm_exec kunit test, the warning was shadowed by a UAF warning
from KASAN due to a bug in the drm kunit helpers.
Patch 1 f
Am 07.09.23 um 15:53 schrieb Thomas Hellström:
While trying to replicate a weird drm_exec lock alloc tracking warning
using the drm_exec kunit test, the warning was shadowed by a UAF warning
from KASAN due to a bug in the drm kunit helpers.
Patch 1 fixes that drm kunit UAF.
Patch 2 introduces a
On Wed, 06 Sep 2023 22:47:38 +0200, Javier Carrasco wrote:
> The drm_colorspace enum member DRM_MODE_COLORIMETRY_COUNT has been
> properly documented by moving the description out of the enum to the
> member description list to get rid of an additional warning and improve
> documentation clarity.
>
On 9/7/2023 2:58 PM, Andi Shyti wrote:
From: Tvrtko Ursulin
Walk all GTs when doing the respective bits of drop_caches work.
Signed-off-by: Tvrtko Ursulin
Signed-off-by: Andi Shyti
Reviewed-by: Nirmoy Das
---
Hi,
I'm proposing this new version of the series I sent here[*].
Patch 1 from
On Tue, Sep 05, 2023 at 12:12:58PM -0700, Doug Anderson wrote:
> Hi,
>
> On Tue, Sep 5, 2023 at 9:45 AM Doug Anderson wrote:
> >
> > As per our discussion, in V2 we will make drm_panel_remove() actually
> > unprepare / disable a panel if it was left enabled. This would
> > essentially fold in the
On Tue, Sep 05, 2023 at 09:45:49AM -0700, Doug Anderson wrote:
> > > In any case, I don't think there's any need to switch this to
> > > refcounting as part of this effort. Someone could, in theory, do it as
> > > a separate patch series.
> >
> > I'm sorry, but I'll insist on getting a solution tha
On 2023-09-07 03:49, Pekka Paalanen wrote:
> On Wed, 6 Sep 2023 16:15:10 -0400
> Harry Wentland wrote:
>
>> On 2023-08-25 10:18, Melissa Wen wrote:
>>> On 08/22, Pekka Paalanen wrote:
On Thu, 10 Aug 2023 15:02:47 -0100
Melissa Wen wrote:
> Instead of relying on color bl
when using __drm_kunit_helper_alloc_drm_device() the driver may be
dereferenced by device-managed resources up until the device is
freed, which is typically later than the kunit-managed resource code
frees it. Fix this by simply make the driver device-managed as well.
In short, the sequence leadin
Check that object freeing from within drm_exec_fini() works as expected
and is unlikely to generate any warnings.
v3:
- Condition the test on CONFIG_DEBUG_LOCK_ALLOC
- Make the test fail if the situation that generates the lockdep
warning occurs. (Maxime Ripard)
Cc: Maxime Ripard
Cc: Christian
While trying to replicate a weird drm_exec lock alloc tracking warning
using the drm_exec kunit test, the warning was shadowed by a UAF warning
from KASAN due to a bug in the drm kunit helpers.
Patch 1 fixes that drm kunit UAF.
Patch 2 introduces a drm_exec kunit subtest that fails if the condit
On Thu, Sep 07, 2023 at 02:58:08PM +0200, Andi Shyti wrote:
> From: Tvrtko Ursulin
>
> Walk all GTs when doing the respective bits of drop_caches work.
>
> Signed-off-by: Tvrtko Ursulin
> Signed-off-by: Andi Shyti
Reviewed-by: Rodrigo Vivi
> ---
> Hi,
>
> I'm proposing this new version of
Hi Jani,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-tip/drm-tip]
url:
https://github.com/intel-lab-lkp/linux/commits/Jani-Nikula/drm-edid-split-out-drm_eld-h-from-drm_edid-h/20230907-173011
base: git://anongit.freedesktop.org/drm/drm-tip drm
On Thu, 07 Sep 2023, Donald Robson wrote:
> On Thu, 2023-09-07 at 15:14 +0300, Jani Nikula wrote:
>> On Wed, 06 Sep 2023, Sarah Walker wrote:
>> > From: Donald Robson
>> >
>> > Signed-off-by: Donald Robson
>> > ---
>> > include/drm/drm_gpuva_mgr.h | 27 +++
>> > 1 file
On Thu, 2023-09-07 at 15:14 +0300, Jani Nikula wrote:
> On Wed, 06 Sep 2023, Sarah Walker wrote:
> > From: Donald Robson
> >
> > Signed-off-by: Donald Robson
> > ---
> > include/drm/drm_gpuva_mgr.h | 27 +++
> > 1 file changed, 27 insertions(+)
> >
> > diff --git a/inc
From: Tvrtko Ursulin
Walk all GTs when doing the respective bits of drop_caches work.
Signed-off-by: Tvrtko Ursulin
Signed-off-by: Andi Shyti
---
Hi,
I'm proposing this new version of the series I sent here[*].
Patch 1 from that series is not necessary so taht I'm going to
propose the origina
Am 07.09.23 um 14:32 schrieb suijingfeng:
Hi,
On 2023/9/7 17:08, Christian König wrote:
Well, I have over 25 years of experience with display hardware and
what you describe here was never an issue.
I want to give you an example to let you know more.
I have a ASRock AD2550B-ITX board[1],
Wh
Hi,
On 2023/9/7 17:08, Christian König wrote:
Well, I have over 25 years of experience with display hardware and
what you describe here was never an issue.
I want to give you an example to let you know more.
I have a ASRock AD2550B-ITX board[1],
When another discrete video card is mounted i
> -Original Message-
> From: Pekka Paalanen
> Sent: Tuesday, September 5, 2023 5:03 PM
> To: Shankar, Uma
> Cc: intel-...@lists.freedesktop.org; Borah, Chaitanya Kumar
> ; dri-devel@lists.freedesktop.org; wayland-
> de...@lists.freedesktop.org; Harry Wentland ;
> Sebastian Wick ; ville.
On Mi, 2023-09-06 at 07:28 -0700, Douglas Anderson wrote:
> As per the discussion on the lists [1], changes to this driver
> generally flow through drm-misc. If they need to be coordinated with
> v4l2 they sometimes go through Philipp Zabel's tree instead. List both
> trees in MAINTAINERS. Also upd
On Wed, 06 Sep 2023, Sarah Walker wrote:
> From: Donald Robson
>
> Signed-off-by: Donald Robson
> ---
> include/drm/drm_gpuva_mgr.h | 27 +++
> 1 file changed, 27 insertions(+)
>
> diff --git a/include/drm/drm_gpuva_mgr.h b/include/drm/drm_gpuva_mgr.h
> index ed8d50200cc
Hi Jani,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-tip/drm-tip]
url:
https://github.com/intel-lab-lkp/linux/commits/Jani-Nikula/drm-edid-split-out-drm_eld-h-from-drm_edid-h/20230907-173011
base: git://anongit.freedesktop.org/drm/drm-tip drm
Hi,
On 04/09/2023 09:54, Daniel Vetter wrote:
On Wed, 30 Aug 2023 at 17:14, Helen Koike > wrote: >> >> On 30/08/2023 11:57, Maxime Ripard wrote: >>> >>> I
agree that we need a baseline, but that baseline should be >>> defined
by the tests own merits, not their outcome on a >>> particular plat
On Thu, 7 Sep 2023 11:41:11 +0200
Danilo Krummrich wrote:
> On 9/7/23 10:42, Boris Brezillon wrote:
> > On Wed, 6 Sep 2023 23:47:13 +0200
> > Danilo Krummrich wrote:
> >
> >> +void drm_gpuvm_bo_destroy(struct kref *kref);
> >
> > I usually keep kref's release functions private so people a
Il 25/08/23 14:24, Vignesh Raman ha scritto:
Enable regulator
Enable MT6397 RTC driver
Signed-off-by: Vignesh Raman
---
drivers/gpu/drm/ci/arm64.config | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/ci/arm64.config b/drivers/gpu/drm/ci/arm64.config
index 817e18ddfd4f..
Hi, Maxime,
On 9/6/23 12:08, Maxime Ripard wrote:
On Tue, Sep 05, 2023 at 02:43:00PM +0200, Thomas Hellström wrote:
Hi maxime,
On 9/5/23 14:06, Maxime Ripard wrote:
On Tue, Sep 05, 2023 at 10:58:30AM +0200, Thomas Hellström wrote:
when using __drm_kunit_helper_alloc_drm_device() the driver m
Hey,
On Wed, Sep 06, 2023 at 10:55:25AM +0100, Sarah Walker wrote:
> +examples:
> + - |
> +#include
> +#include
> +#include
> +
> +gpu: gpu@fd0 {
This "gpu" label isn't used and can be dropped if you respin.
Otherwise, this seems fine to me,
Reviewed-by: Conor Dooley
Th
base: linus/master
patch link:
https://lore.kernel.org/r/20230903170736.513347-16-dmitry.osipenko%40collabora.com
patch subject: [PATCH v16 15/20] drm/shmem-helper: Add memory shrinker
config: x86_64-randconfig-161-20230907
(https://download.01.org/0day-ci/archive/20230907/202309070814.jygjojzy
for_each_child_of_node performs an of_node_get on each
iteration, so a break out of the loop requires an
of_node_put.
This was done using the Coccinelle semantic patch
iterators/for_each_child.cocci
Signed-off-by: Julia Lawall
---
drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c |4 +++-
dr
Add of_node_put on a break out of an of_node loop.
---
arch/powerpc/kexec/file_load_64.c|8 ++--
arch/powerpc/platforms/powermac/low_i2c.c|4 +++-
arch/powerpc/platforms/powermac/smp.c|4 +++-
drivers/bus/arm-cci.c
On Wed, 06 Sep 2023, suijingfeng wrote:
> Another limitation of the 'nomodeset' parameter is that
> it is only available on recent upstream kernel. Low version
> downstream kernel don't has this parameter supported yet.
> So this create inconstant developing experience. I believe that
> there alwa
On 9/7/23 10:42, Boris Brezillon wrote:
On Wed, 6 Sep 2023 23:47:13 +0200
Danilo Krummrich wrote:
+void drm_gpuvm_bo_destroy(struct kref *kref);
I usually keep kref's release functions private so people are not
tempted to use them.
I think I did that because drm_gpuvm_bo_put() needs it.
On Mon, 21 Aug 2023, Mitul Golani wrote:
> Add wrapper functions to facilitate extracting Short Audio
> Descriptor (SAD) information from EDID-Like Data (ELD) pointers
> with different constness requirements.
>
> 1. `drm_eld_sad`: This function returns a constant `uint8_t`
> pointer and wraps the
Occasionally it's necessary for drivers to modify the SADs of an ELD,
but it's not so cool to have drivers poke at the ELD buffer directly.
Using the helpers to translate between 3-byte SAD and struct cea_sad,
add ELD helpers to get/set the SADs from/to an ELD.
Cc: Mitul Golani
Signed-off-by: Ja
Add helpers to pack/unpack SADs. Both ways and non-static, as follow-up
work needs them.
Cc: Mitul Golani
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 33 -
drivers/gpu/drm/drm_internal.h | 6 ++
2 files changed, 30 insertions(+), 9 deleti
Unify on kernel types.
Cc: Mitul Golani
Signed-off-by: Jani Nikula
---
include/drm/drm_eld.h | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/include/drm/drm_eld.h b/include/drm/drm_eld.h
index 9bde89bd96ea..7b674256b9aa 100644
--- a/include/drm/drm_eld.h
+++ b
It's arguably easier on the eyes, and drops a set of parenthesis too.
Cc: Mitul Golani
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 202
Reduce the dependencies on drm_eld.h. Some files might be able to drop
the dependency on drm_edid.h too with the direct inclusion of drm_eld.h.
Cc: Mitul Golani
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c| 1 +
drivers/gpu/drm/drm_edid.c
The drm_edid.[ch] files are starting to be a bit crowded, and with plans
to add more ELD related functionality, it's perhaps cleanest to split
the ELD code out to a header of its own.
Include drm_eld.h from drm_edid.h for starters, and leave it to
follow-up work to only include drm_eld.h where nee
Split out drm_eld.[ch] from drm_edid.h, add some helpers to convert and
modify SADs.
This should make it easier and more robust to implement things like [1],
with ELD parsing details hidden in drm_eld.[ch].
for (i = 0; i < drm_eld_sad_count(eld); i++) {
struct cea_sad sad;
1. Instead of multiplying 2 variable of different types. Change to
assign a value of one variable and then multiply the other variable.
2. Add a int variable for multiplier calculation instead of calculating
different types multiplier with dma_addr_t variable directly.
Fixes: 1a64a7aff8da ("drm/m
On 9/7/23 10:16, Boris Brezillon wrote:
On Wed, 6 Sep 2023 23:47:13 +0200
Danilo Krummrich wrote:
@@ -812,15 +967,20 @@ EXPORT_SYMBOL_GPL(drm_gpuva_remove);
/**
* drm_gpuva_link() - link a &drm_gpuva
* @va: the &drm_gpuva to link
+ * @vm_bo: the &drm_gpuvm_bo to add the &drm_gpuva to
Am 07.09.23 um 04:30 schrieb Sui Jingfeng:
Hi,
On 2023/9/6 17:40, Christian König wrote:
Am 06.09.23 um 11:08 schrieb suijingfeng:
Well, welcome to correct me if I'm wrong.
You seem to have some very basic misunderstandings here.
The term framebuffer describes some VRAM memory used for sca
Hi,
On 9/6/23 10:34, Christian König wrote:
Am 05.09.23 um 16:29 schrieb Thomas Hellström:
Hi, Christian
On 9/5/23 15:14, Christian König wrote:
Am 05.09.23 um 10:58 schrieb Thomas Hellström:
If *any* object of a certain WW mutex class is locked, lockdep will
consider *all* mutexes of that c
On 9/7/23 09:56, Boris Brezillon wrote:
On Wed, 6 Sep 2023 23:47:10 +0200
Danilo Krummrich wrote:
Rename struct drm_gpuva_manager to struct drm_gpuvm including
corresponding functions. This way the GPUVA manager's structures align
very well with the documentation of VM_BIND [1] and VM_BIND lo
Fix a number of warnings from checkpatch.pl in this code before
moving it into a separate file. This includes
* Prefer 'unsigned int' to bare use of 'unsigned'
* space required after that ',' (ctx:VxV)
* space prohibited after that open parenthesis '('
* suspect code indent for conditional sta
Remove all unnecessary include statements from fbmem.c. Most of
them were for functionality that has meanwhile been moved into
other files.
Signed-off-by: Thomas Zimmermann
Acked-by: Javier Martinez Canillas
---
drivers/video/fbdev/core/fbmem.c | 19 +--
1 file changed, 1 insert
The interfaces for the fbdev logo are not used outside of the fbdev
module. Hence declare the fbdev logo functions in the internal header
file and remove their symbol exports. Only build the functions if
CONFIG_LOGO has been selected.
Signed-off-by: Thomas Zimmermann
Acked-by: Javier Martinez Can
Remove the two empty helpers for the case the CONFIG_FB_LOGO_EXTRA
has not been set. They are internal functions and only called once.
Providing empty replacements seems like overkill. Instead protect
the call sites with a test for CONFIG_FB_LOGO_EXTRA.
Signed-off-by: Thomas Zimmermann
Acked-by:
Move the fbdev function for displaying boot-up logos into their
own file fb_logo.c. Only build fb_logo.c if CONFIG_LOGO has been
selected. No functional changes.
v2:
* include fb_internal.h (kernel test robot)
* simplify option-parsing ifdefs
* build fb_logo.o iff CONFIG_LO
The fbcon module takes care of displaying the logo, if any. Remove
the code form au1200fb. If we want to display the logo without fbcon,
we should implement this in the fbdev core code.
Signed-off-by: Thomas Zimmermann
Acked-by: Javier Martinez Canillas
---
drivers/video/fbdev/au1200fb.c | 9 --
The fbcon module takes care of displaying the logo, if any. Remove
the code form mmpfb. It is probably no tworking as expected, as it
interferes with the framebuffer console. If we want to display the
logo without fbcon, we should implement this in the fbdev core code.
v2:
* add a note on
The boot-up logo is a feature of the fbcon console; with only a few
external callers. Move it from the core fbdev code into its own file.
Patches 1 and 2 remove the logo setup from fbdev drivers. The logo
requires a configured output, which is provided by the framebuffer
console. Drivers should no
Hi Danilo,
kernel test robot noticed the following build warnings:
[auto build test WARNING on 6bd3d8da51ca1ec97c724016466606aec7739b9f]
url:
https://github.com/intel-lab-lkp/linux/commits/Danilo-Krummrich/drm-gpuva_mgr-allow-building-as-module/20230907-054931
base
Thomas Zimmermann writes:
[...]
>> That's a good point. However I recall from earlier attempts at doing
>> something like this in Nouveau (although this is now very long ago) that
>> it's not very easy. The problem, as I recall, is that the driver is a
>> singleton, so we would essentially be su
On Wed, 6 Sep 2023 23:47:13 +0200
Danilo Krummrich wrote:
> +void drm_gpuvm_bo_destroy(struct kref *kref);
I usually keep kref's release functions private so people are not
tempted to use them.
> +
> +/**
> + * drm_gpuvm_bo_get() - acquire a struct drm_gpuvm_bo reference
> + * @vm_bo: the &drm
Hi
Am 07.09.23 um 10:03 schrieb Thierry Reding:
On Thu, Aug 31, 2023 at 10:04:29AM +0200, Daniel Vetter wrote:
On Thu, 31 Aug 2023 at 08:33, Mikko Perttunen wrote:
On 8/30/23 13:19, Thomas Zimmermann wrote:
Hi
Am 25.08.23 um 15:22 schrieb Thierry Reding:
From: Thierry Reding
Tegra DRM d
Hi Michael,
On 06.09.23 11:56, Michael Tretter wrote:
> Hi Frieder,
>
> On Wed, 06 Sep 2023 11:31:45 +0200, Frieder Schrempf wrote:
>> On 04.09.23 16:02, Frieder Schrempf wrote:
>>> On 28.08.23 17:59, Michael Tretter wrote:
I tested the i.MX8M Nano EVK with the NXP supplied MIPI-DSI adapter,
On Wed, 6 Sep 2023 23:47:13 +0200
Danilo Krummrich wrote:
> @@ -812,15 +967,20 @@ EXPORT_SYMBOL_GPL(drm_gpuva_remove);
> /**
> * drm_gpuva_link() - link a &drm_gpuva
> * @va: the &drm_gpuva to link
> + * @vm_bo: the &drm_gpuvm_bo to add the &drm_gpuva to
> *
> - * This adds the given &va
Thierry Reding writes:
Hello Thierry,
> On Wed, Aug 30, 2023 at 08:13:04AM +0200, Javier Martinez Canillas wrote:
[...]
>> I also wonder if is worth to move the drm_num_crtcs() function from
>> drivers/gpu/drm/drm_crtc.c to include/drm/drm_crtc.h and use that helper
>> instead?
>
> I've been l
Am 06.09.23 um 12:12 schrieb Javier Martinez Canillas:
Thomas Zimmermann writes:
Only build fb_logo.c if CONFIG_LOGO has been selected. Otherwise
provide empty implementations of the contained interfaces and avoid
using the exported variables.
Signed-off-by: Thomas Zimmermann
Ah! You are
1 - 100 of 109 matches
Mail list logo
