> -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
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
---
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
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
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
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
---
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
---
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.
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...
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
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
_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
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
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
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
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
_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
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
> >> ---
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
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
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 ++
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
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
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
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
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
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
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
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
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
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
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
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:
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
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
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
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
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],
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
> -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 ;
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
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
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
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
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
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
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
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 +++-
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
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:
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
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
+++
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
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
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
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
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 _gpuva
* @va: the _gpuva to link
+ * @vm_bo: the _gpuvm_bo to add the _gpuva to
*
- * This
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
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
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
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
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
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
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
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
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
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
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
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
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 _gpuva
> * @va: the _gpuva to link
> + * @vm_bo: the _gpuvm_bo to add the _gpuva to
> *
> - * This adds the given to the GPU VA list
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
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
Am 04.09.23 um 09:08 schrieb Thomas Zimmermann:
Hi
Am 01.09.23 um 10:22 schrieb Helge Deller:
On 8/29/23 16:15, Thomas Zimmermann wrote:
Only build fb_logo.c if CONFIG_LOGO has been selected. Otherwise
provide empty implementations of the contained interfaces and avoid
using the exported
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 doesn't
On Wed, Aug 30, 2023 at 08:13:04AM +0200, Javier Martinez Canillas wrote:
> Thierry Reding writes:
>
> Hello Thierry,
>
> > From: Thierry Reding
> >
> > Tegra DRM doesn't support display on Tegra234 and later, so make sure
> > not to remove any existing framebuffers in that case.
> >
>
> I
On Wed, 6 Sep 2023 15:30:04 -0400
Harry Wentland wrote:
> On 2023-08-10 12:02, Melissa Wen wrote:
> > Add 3D LUT property for plane gamma correction using a 3D lookup table.
> > Since a 3D LUT has a limited number of entries in each dimension we want
> > to use them in an optimal fashion. This
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 locking [2].
>
> It also provides a
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 block names to get the transfer function
> >>>
Hi,
Here's this week drm-misc-fixes PR
Maxime
drm-misc-fixes-2023-09-07:
One doc fix for drm/connector, one fix for amdgpu for an crash when
VRAM usage is high, and one fix in gm12u320 to fix the timeout units in
the code
The following changes since commit
Only compile ivpu_debugfs.c file with CONFIG_DEBUG_FS.
Signed-off-by: Stanislaw Gruszka
---
drivers/accel/ivpu/Makefile | 3 ++-
drivers/accel/ivpu/ivpu_debugfs.h | 4
drivers/accel/ivpu/ivpu_drv.c | 2 --
3 files changed, 6 insertions(+), 3 deletions(-)
diff --git
Use new drm debugfs helpers. This is needed after changes from
commit 78346ebf9f94 ("drm/debugfs: drop debugfs_init() for the render
and accel node v2").
Signed-off-by: Stanislaw Gruszka
---
drivers/accel/ivpu/ivpu_debugfs.c | 50 +++
1 - 100 of 110 matches
Mail list logo
