The __dma_fence_unwrap_merge() function is supposed to return NULL on
error. But the dma_fence_allocate_private_stub() returns error pointers
so check for that and covert the error pointers to NULL returns.
Otherwise, the callers do not expect error pointers and it leads to an
Oops.
Fixes:
This change adds the ability to read or write a "1" or a "0" to the
newly added "connected" attribute of a connector in the vkms entry in
configfs.
A write will trigger a call to drm_kms_helper_hotplug_event, causing a
hotplug uevent.
With this we can write virtualized multidisplay tests that
Hi,
On 2023/7/5 18:29, Geert Uytterhoeven wrote:
Hi Sui,
On Tue, Jun 27, 2023 at 4:57 PM Sui Jingfeng wrote:
On 2023/6/22 17:21, Geert Uytterhoeven wrote:
When the device is unbound from the driver, the display may be active.
Make sure it gets shut down.
would you mind to give a short
On 7/5/23 21:58, Quan, Evan wrote:
[AMD Official Use Only - General]
Hi Andrew,
I discussed with Mario about your proposal/concerns here.
We believe some changes below might address your concerns.
- place/move the wbrf_supported_producer check inside
acpi_amd_wbrf_add_exclusion and
[AMD Official Use Only - General]
Hi Andrew,
I discussed with Mario about your proposal/concerns here.
We believe some changes below might address your concerns.
- place/move the wbrf_supported_producer check inside
acpi_amd_wbrf_add_exclusion and acpi_amd_wbrf_add_exclusion
- place the
Add dt-binding documentation of dp-tx for MediaTek MT8188 SoC.
Signed-off-by: Shuijing Li
Signed-off-by: Jitao Shi
---
Changes in v2:
add a mediatek,mt8188-edp-tx compatible per suggestion from the previous thread:
https://lore.kernel.org/lkml/c4a4a900-c80d-b110-f10e-7fa2dae8b...@collabora.com/
Add dt-binding documentation of dp-tx for MediaTek MT8188 SoC.
Mainly add the following two flag:
1.The audio packet arrangement function is to only arrange audio
packets into the Hblanking area. In order to align with the HW
default setting of g1200, this function needs to be turned off.
2.Due
Mainly add the following two flag:
1.The audio packet arrangement function is to only arrange audio
packets into the Hblanking area. In order to align with the HW
default setting of g1200, this function needs to be turned off.
2.Due to the difference of HW, different dividers need to be set.
Julia,
> The functions vmalloc_array and vcalloc were introduced in
>
> commit a8749a35c399 ("mm: vmalloc: introduce array allocation functions")
>
> but are not used much yet. This series introduces uses of
> these functions, to protect against multiplication overflows.
Applied #7 and #24 to
Hi Dmitry,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on linus/master v6.4 next-20230705]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use
On 6/29/2023 6:44 PM, Alan Previn wrote:
After recent discussions with Mesa folks, it was requested
that we optimize i915's GET_PARAM for the PXP_STATUS without
changing the UAPI spec.
Add these additional optimizations:
- If any PXP initializatoin flow failed, then ensure that
we
On 7/5/2023 12:30 PM, Ryan McCann wrote:
For a device core dump, the registers of sub-blocks are printed under a
title formatted as . For example, the csc sub-block
for an SSPP main block "sspp_0" would be printed "sspp_0_sspp_csc0". The
title is clearly redundant due to the duplicate "sspp"
On 7/5/2023 12:30 PM, Ryan McCann wrote:
Some sub-blocks in the hw catalog have not been given a name, so when the
registers from that block are dumped, there is no name to reference.
Define names for relevant sub-blocks to fix this.
Signed-off-by: Ryan McCann
---
On 7/5/2023 12:30 PM, Ryan McCann wrote:
Drop unused parameter "num" from VIG_SBLK_NOSCALE and DMA sub-block
macros. Update calls to relevant macros to reflect change.
Signed-off-by: Ryan McCann
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 20 ++--
1 file changed,
On 7/5/2023 12:30 PM, Ryan McCann wrote:
Device core dump add block method adds hardware blocks to dumping queue
with stack behavior which causes the hardware blocks to be printed in
reverse order. Change the addition to dumping queue data structure
from "list_add" to "list_add_tail" for FIFO
https://bugzilla.kernel.org/show_bug.cgi?id=217636
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC|
On 05/07/2023 23:39, Ryan McCann wrote:
On 7/5/2023 1:22 PM, Dmitry Baryshkov wrote:
On 05/07/2023 22:30, Ryan McCann wrote:
Currently, the device core dump mechanism does not dump registers of
sub-blocks within the DSPP, SSPP, DSC, and PINGPONG blocks. Edit
dpu_kms_mdp_snapshot function to
On 7/5/2023 1:22 PM, Dmitry Baryshkov wrote:
On 05/07/2023 22:30, Ryan McCann wrote:
Currently, the device core dump mechanism does not dump registers of
sub-blocks within the DSPP, SSPP, DSC, and PINGPONG blocks. Edit
dpu_kms_mdp_snapshot function to account for sub-blocks.
Signed-off-by:
On 05/07/2023 22:30, Ryan McCann wrote:
Some sub-blocks in the hw catalog have not been given a name, so when the
registers from that block are dumped, there is no name to reference.
Define names for relevant sub-blocks to fix this.
Signed-off-by: Ryan McCann
---
https://bugzilla.kernel.org/show_bug.cgi?id=217636
Bug ID: 217636
Summary: Commit edcfed8671 disables previously supported video
resolutions (on AMD Rembrandt)
Product: Drivers
Version: 2.5
Hardware: All
On 05/07/2023 22:30, Ryan McCann wrote:
Currently, the device core dump mechanism does not dump registers of
sub-blocks within the DSPP, SSPP, DSC, and PINGPONG blocks. Edit
dpu_kms_mdp_snapshot function to account for sub-blocks.
Signed-off-by: Ryan McCann
---
On 05/07/2023 22:30, Ryan McCann wrote:
For a device core dump, the registers of sub-blocks are printed under a
title formatted as . For example, the csc sub-block
for an SSPP main block "sspp_0" would be printed "sspp_0_sspp_csc0". The
title is clearly redundant due to the duplicate "sspp" and
On 05/07/2023 22:30, Ryan McCann wrote:
Drop unused parameter "num" from VIG_SBLK_NOSCALE and DMA sub-block
macros. Update calls to relevant macros to reflect change.
Signed-off-by: Ryan McCann
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 20 ++--
1 file changed, 10
On 05/07/2023 19:53, Maxime Ripard wrote:
On Wed, Jul 05, 2023 at 06:20:13PM +0300, Dmitry Baryshkov wrote:
On Wed, 5 Jul 2023 at 17:24, Maxime Ripard wrote:
On Wed, Jul 05, 2023 at 04:37:57PM +0300, Dmitry Baryshkov wrote:
Either way, I'm not really sure it's a good idea to multiply the
Early release TTM BOs when the kernel default setting is init_on_free to
wipe out and reinitialize system memory chunks. This could potentially
optimize performance when an application does a lot of malloc/free style
allocations with unified system memory.
Signed-off-by: Rajneesh Bhardwaj
---
Currently, the device core dump mechanism does not dump registers of
sub-blocks within the DSPP, SSPP, DSC, and PINGPONG blocks. Edit
dpu_kms_mdp_snapshot function to account for sub-blocks.
Signed-off-by: Ryan McCann
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 106
The purpose of this patch series is to add support to print the registers
of sub-blocks in the DPU hardware catalog and fix the order in which all
hardware blocks are dumped for a device core dump. This involves:
1. Changing data structure from stack to queue to fix the printing order
of the
Drop unused parameter "num" from VIG_SBLK_NOSCALE and DMA sub-block
macros. Update calls to relevant macros to reflect change.
Signed-off-by: Ryan McCann
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git
For a device core dump, the registers of sub-blocks are printed under a
title formatted as . For example, the csc sub-block
for an SSPP main block "sspp_0" would be printed "sspp_0_sspp_csc0". The
title is clearly redundant due to the duplicate "sspp" and "0" that exist
in both the mainBlkName and
Some sub-blocks in the hw catalog have not been given a name, so when the
registers from that block are dumped, there is no name to reference.
Define names for relevant sub-blocks to fix this.
Signed-off-by: Ryan McCann
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 20
Device core dump add block method adds hardware blocks to dumping queue
with stack behavior which causes the hardware blocks to be printed in
reverse order. Change the addition to dumping queue data structure
from "list_add" to "list_add_tail" for FIFO queue behavior.
Fixes: 98659487b845
On 7/5/23 18:54, Gurchetan Singh wrote:
> On Wed, Jun 28, 2023 at 8:58 AM Gurchetan Singh
> wrote:
>>
>> We don't want to create a fence for every command submission. It's
>> only necessary when userspace provides a waitable token for submission.
>> This could be:
>>
>> 1) bo_handles, to be used
Hi Daniel,
On Wed, Jul 05, 2023 at 03:07:31PM +0100, Daniel Thompson wrote:
> On Tue, Jul 04, 2023 at 07:07:31PM +0200, Sam Ravnborg wrote:
> > Hi Daniel,
> >
> > > > @@ -200,8 +200,8 @@ static int led_bl_probe(struct platform_device
> > > > *pdev)
> > > > props.type = BACKLIGHT_RAW;
> >
Hi Paul,
On Mon, Jul 03, 2023 at 11:47:14PM +0200, Paul Cercueil wrote:
> Register a backlight device to be able to switch between all the gamma
> levels.
>
> Signed-off-by: Paul Cercueil
> ---
> drivers/gpu/drm/panel/panel-samsung-ld9040.c | 40
> 1 file changed, 40
Hi Alexander,
On Wed, Jul 05, 2023 at 03:22:39PM +0200, Alexander Stein wrote:
> Hi,
>
> another gentle ping
>
> Best regards,
> Alexander
>
> Am Mittwoch, 25. Januar 2023, 15:52:15 CEST schrieb Alexander Stein:
> > From: Markus Niebel
> >
> > The DE signal is active high on this display,
Hi Paul,
On Wed, Jul 05, 2023 at 04:38:05PM +0200, Paul Cercueil wrote:
> Hi Neil,
>
> Le mercredi 05 juillet 2023 à 15:57 +0200, Neil Armstrong a écrit :
> > On 03/07/2023 23:47, Paul Cercueil wrote:
> > > Register a backlight device to be able to switch between all the
> > > gamma
> > >
Hi Faiz,
On Tue, Jul 04, 2023 at 10:04:54PM +0530, Faiz Abbas wrote:
> The Komeda driver always expects the remote connector node to initialize
> an encoder. It uses the component aggregator framework which consists
> of component->bind() calls used to initialize the remote encoder and attach
>
On Wed, Jul 05, 2023 at 06:20:13PM +0300, Dmitry Baryshkov wrote:
> On Wed, 5 Jul 2023 at 17:24, Maxime Ripard wrote:
> >
> > On Wed, Jul 05, 2023 at 04:37:57PM +0300, Dmitry Baryshkov wrote:
> > > > > >
> > > > > > Either way, I'm not really sure it's a good idea to multiply the
> > > > > >
Hi Ville,
On Mon, Jul 11, 2022 at 2:34 PM Geert Uytterhoeven wrote:
> On Mon, Jul 11, 2022 at 2:17 PM Ville Syrjälä
> wrote:
> > On Fri, Jul 08, 2022 at 08:21:43PM +0200, Geert Uytterhoeven wrote:
> > > Signed-off-by: Geert Uytterhoeven
> > > ---
> > > Any better suggestion than appending
On 7/4/23 01:08, Pekka Paalanen wrote:
On Mon, 3 Jul 2023 14:06:56 -0700
Michael Banack wrote:
Hi, I can speak to the virtual mouse/console half of this from the
VMware-side.
I believe Zack's preparing a new set of comments here that can speak to
most of your concerns, but I'll answer
On Wed, Jul 5, 2023 at 5:17 PM Geert Uytterhoeven
wrote:
>
> On 32-bit:
>
> ../tests/amdgpu/amdgpu_stress.c: In function ‘alloc_bo’:
> ../tests/amdgpu/amdgpu_stress.c:178:49: warning: format ‘%lx’ expects
> argument of type ‘long unsigned int’, but argument 4 has type ‘uint64_t’ {aka
>
On 05/07/2023 16:24, Maxime Ripard wrote:
On Wed, Jul 05, 2023 at 04:37:57PM +0300, Dmitry Baryshkov wrote:
Either way, I'm not really sure it's a good idea to multiply the
capabilities flags of the DSI host, and we should just stick to the
spec. If the spec says that we have to support DSC
On Wed, Jun 28, 2023 at 8:58 AM Gurchetan Singh
wrote:
>
> We don't want to create a fence for every command submission. It's
> only necessary when userspace provides a waitable token for submission.
> This could be:
>
> 1) bo_handles, to be used with VIRTGPU_WAIT
> 2) out_fence_fd, to be used
On Wed, Jul 5, 2023 at 3:32 AM Michel Dänzer wrote:
>
> On 7/5/23 08:30, Marek Olšák wrote:
> > On Tue, Jul 4, 2023, 03:55 Michel Dänzer wrote:
> > On 7/4/23 04:34, Marek Olšák wrote:
> > > On Mon, Jul 3, 2023, 03:12 Michel Dänzer > > wrote:
> > > On 6/30/23 22:32, Marek Olšák
On Sun, 02 Jul 2023 20:23:08 +0200, Krzysztof Kozlowski wrote:
> The DTS code coding style expects spaces around '=' sign.
>
> Signed-off-by: Krzysztof Kozlowski
>
> ---
>
> Rob,
>
> Maybe this could go via your tree? Rebased on your for-next:
> v6.4-rc2-45-gf0ac35049606
> ---
>
Add support for drawing the SMPTE and tiles patterns in buffers using
semi-planar YUV formats with non-subsampled chroma planes.
Signed-off-by: Geert Uytterhoeven
---
tests/util/pattern.c | 4
1 file changed, 4 insertions(+)
diff --git a/tests/util/pattern.c b/tests/util/pattern.c
index
Add support for creating buffers using semi-planar YUV formats with
non-subsampled chroma planes.
Signed-off-by: Geert Uytterhoeven
---
tests/modetest/buffers.c | 20
1 file changed, 20 insertions(+)
diff --git a/tests/modetest/buffers.c b/tests/modetest/buffers.c
index
Hi all,
This patch series adds support for semi-planar YUV formats with
non-subsampled chroma planes.
It has been tested with the shmob_drm driver on the R-Mobile A1-based
Atmark Techno Armadillo-800-EVA development board.
Thanks for your comments!
Geert Uytterhoeven (3):
util: Add
Add the missing entries for semi-planar YUV formats with
non-subsampled chroma planes.
Signed-off-by: Geert Uytterhoeven
---
tests/util/format.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tests/util/format.c b/tests/util/format.c
index 1ca1b82ce947b2f4..f825027227ddba24 100644
---
On Wed, 5 Jul 2023 at 17:24, Maxime Ripard wrote:
>
> On Wed, Jul 05, 2023 at 04:37:57PM +0300, Dmitry Baryshkov wrote:
> > > > >
> > > > > Either way, I'm not really sure it's a good idea to multiply the
> > > > > capabilities flags of the DSI host, and we should just stick to the
> > > > >
On 32-bit:
../tests/amdgpu/amdgpu_stress.c: In function ‘alloc_bo’:
../tests/amdgpu/amdgpu_stress.c:178:49: warning: format ‘%lx’ expects
argument of type ‘long unsigned int’, but argument 4 has type ‘uint64_t’ {aka
‘long long unsigned int’} [-Wformat=]
fprintf(stdout, "Allocated
On 32-bit:
../amdgpu/amdgpu_bo.c: In function ‘amdgpu_find_bo_by_cpu_mapping’:
../amdgpu/amdgpu_bo.c:554:13: warning: cast to pointer from integer of
different size [-Wint-to-pointer-cast]
cpu < (void*)((uintptr_t)bo->cpu_ptr + bo->alloc_size))
^
Indeed, as
On Wed, Jul 05, 2023 at 03:36:46PM +0100, Måns Rullgård wrote:
> Daniel Thompson writes:
>
> > On Wed, Jul 05, 2023 at 03:24:14PM +0100, Mans Rullgard wrote:
> >> The condition for the initial power state based on the default
> >> brightness value is reversed. Fix it.
> >>
> >> Furthermore, use
On Tue, Jul 4, 2023 at 10:20 AM Dmitry Baryshkov
wrote:
>
> On Tue, 4 Jul 2023 at 19:36, Rob Clark wrote:
> >
> > From: Rob Clark
> >
> > Recently, a WARN_ON() was introduced to ensure that revn is filled before
> > adreno_is_aXYZ is called. This however doesn't work very well when revn is
> >
Hi Neil,
Le mercredi 05 juillet 2023 à 15:57 +0200, Neil Armstrong a écrit :
> On 03/07/2023 23:47, Paul Cercueil wrote:
> > Register a backlight device to be able to switch between all the
> > gamma
> > levels.
> >
> > Signed-off-by: Paul Cercueil
> > ---
> >
On Wed, Jul 05, 2023 at 03:24:14PM +0100, Mans Rullgard wrote:
> The condition for the initial power state based on the default
> brightness value is reversed. Fix it.
>
> Furthermore, use the actual state of the LEDs rather than the default
> brightness specified in the devicetree as the latter
On Wed, Jul 05, 2023 at 04:37:57PM +0300, Dmitry Baryshkov wrote:
> > > >
> > > > Either way, I'm not really sure it's a good idea to multiply the
> > > > capabilities flags of the DSI host, and we should just stick to the
> > > > spec. If the spec says that we have to support DSC while video is
>
On Tue, Jul 04, 2023 at 05:19:52PM +0100, Mans Rullgard wrote:
> The condition for the initial power state based on the default
> brightness value is reversed. Fix it.
>
> Furthermore, use the actual state of the LEDs rather than the default
> brightness specified in the devicetree as the latter
On Tue, Jul 04, 2023 at 07:07:31PM +0200, Sam Ravnborg wrote:
> Hi Daniel,
>
> > > @@ -200,8 +200,8 @@ static int led_bl_probe(struct platform_device *pdev)
> > > props.type = BACKLIGHT_RAW;
> > > props.max_brightness = priv->max_brightness;
> > > props.brightness = priv->default_brightness;
On 03/07/2023 23:47, Paul Cercueil wrote:
Register a backlight device to be able to switch between all the gamma
levels.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/panel/panel-samsung-ld9040.c | 40
1 file changed, 40 insertions(+)
diff --git
Hi
On 03/07/2023 23:47, Paul Cercueil wrote:
I have no idea what the prior magic values mean, and I have no idea
what my replacement (extracted from [1]) magic values mean.
What I do know, is that these new values result in a much better
picture, where the blacks are really black (as you would
https://bugzilla.kernel.org/show_bug.cgi?id=217621
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC|
On 05/07/2023 16:29, Maxime Ripard wrote:
On Wed, Jul 05, 2023 at 03:05:33PM +0200, Neil Armstrong wrote:
On 05/07/2023 14:04, Maxime Ripard wrote:
Hi,
On Tue, May 30, 2023 at 03:36:04PM +0300, Dmitry Baryshkov wrote:
On 30/05/2023 15:15, AngeloGioacchino Del Regno wrote:
Il 30/05/23 13:44,
On Wed, Jul 05, 2023 at 03:05:33PM +0200, Neil Armstrong wrote:
> On 05/07/2023 14:04, Maxime Ripard wrote:
> > Hi,
> >
> > On Tue, May 30, 2023 at 03:36:04PM +0300, Dmitry Baryshkov wrote:
> > > On 30/05/2023 15:15, AngeloGioacchino Del Regno wrote:
> > > > Il 30/05/23 13:44, Dmitry Baryshkov ha
Hi,
another gentle ping
Best regards,
Alexander
Am Mittwoch, 25. Januar 2023, 15:52:15 CEST schrieb Alexander Stein:
> From: Markus Niebel
>
> The DE signal is active high on this display, fill in the missing
> bus_flags. This aligns panel_desc with its display_timing.
>
> Fixes:
On Mon, 2023-06-26 at 10:38 -0500, Adam Ford wrote:
> On Mon, Jun 26, 2023 at 8:22 AM Frank Binns wrote:
> > Hi Adam,
> >
> > On Sat, 2023-06-17 at 07:48 -0500, Adam Ford wrote:
> > > On Tue, Jun 13, 2023 at 10:20 AM Sarah Walker
> > > wrote:
> > > > Read the GPU ID register at probe time and
On 05/07/2023 14:04, Maxime Ripard wrote:
Hi,
On Tue, May 30, 2023 at 03:36:04PM +0300, Dmitry Baryshkov wrote:
On 30/05/2023 15:15, AngeloGioacchino Del Regno wrote:
Il 30/05/23 13:44, Dmitry Baryshkov ha scritto:
On Tue, 30 May 2023 at 10:24, Neil Armstrong
wrote:
Hi Marijn, Dmitry,
On Wed, 05 Jul 2023 14:17:20 +0200,
Alex Deucher wrote:
>
> On Wed, Jul 5, 2023 at 2:26 AM Takashi Iwai wrote:
> >
> > Hi Dave, Alex,
> >
> > it seems that the last PR for AMDGPU 6.4 fixes wasn't taken by Linus
> > due to the missing signed tag:
> >
> >
Am 04.07.23 um 17:24 schrieb Arnd Bergmann:
On Tue, Jul 4, 2023, at 16:51, Christian König wrote:
Am 04.07.23 um 16:31 schrieb Arnd Bergmann:
On Tue, Jul 4, 2023, at 14:33, Christian König wrote:
Modern AMD GPUs have 16GiB of local memory (VRAM), making those
accessible to a CPU which can
On Wed, Jul 5, 2023 at 2:26 AM Takashi Iwai wrote:
>
> Hi Dave, Alex,
>
> it seems that the last PR for AMDGPU 6.4 fixes wasn't taken by Linus
> due to the missing signed tag:
>
> https://lore.kernel.org/lkml/CAHk-=wiOCgiwzVPOwORHPML9eBphnbtM2DhRcv+v=-tnrrg...@mail.gmail.com/
>
> And more
On Wed, 05 Jul 2023, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Commit 2caffbf11762 ("drm/i915: Revoke mmaps and prevent access to fence
> registers across reset") removed the temporary implementation of a reset
> under stop machine but forgot to remove this one commented out define.
>
>
Hi,
On Tue, May 30, 2023 at 03:36:04PM +0300, Dmitry Baryshkov wrote:
> On 30/05/2023 15:15, AngeloGioacchino Del Regno wrote:
> > Il 30/05/23 13:44, Dmitry Baryshkov ha scritto:
> > > On Tue, 30 May 2023 at 10:24, Neil Armstrong
> > > wrote:
> > > >
> > > > Hi Marijn, Dmitry, Caleb, Jessica,
>
On 07/05/ , Matthew Auld wrote:
> On Wed, 5 Jul 2023 at 11:08, Lang Yu wrote:
> >
> > bo->kref is increased once(kref_init()) in ttm_bo_release,
> > but decreased twice(ttm_bo_put()) respectively in
> > ttm_bo_delayed_delete and ttm_bo_cleanup_refs,
> > which is unbalanced.
> >
> > Just clean up
Applied to drm-misc-fixes
Thanks
Stanislaw
On Mon, Jul 03, 2023 at 10:07:24AM +0200, Stanislaw Gruszka wrote:
> From: Karol Wachowski
>
> Incorrect REGB_WR32() macro was used to access VPUIP register.
> Use correct REGV_WR32().
>
> Fixes: 35b137630f08 ("accel/ivpu: Introduce a new DRM driver
On Wed, 5 Jul 2023 at 11:08, Lang Yu wrote:
>
> bo->kref is increased once(kref_init()) in ttm_bo_release,
> but decreased twice(ttm_bo_put()) respectively in
> ttm_bo_delayed_delete and ttm_bo_cleanup_refs,
> which is unbalanced.
>
> Just clean up bo resource in one place for a delayed deleted
Hi Sui,
On Tue, Jun 27, 2023 at 4:57 PM Sui Jingfeng wrote:
> On 2023/6/22 17:21, Geert Uytterhoeven wrote:
> > When the device is unbound from the driver, the display may be active.
> > Make sure it gets shut down.
>
> would you mind to give a short description why this is necessary.
That's a
bo->kref is increased once(kref_init()) in ttm_bo_release,
but decreased twice(ttm_bo_put()) respectively in
ttm_bo_delayed_delete and ttm_bo_cleanup_refs,
which is unbalanced.
Just clean up bo resource in one place for a delayed deleted bo.
Fixes: 9bff18d13473 ("drm/ttm: use per BO cleanup
On 7/4/23 19:06, Sebastian Wick wrote:
> On Sat, Jul 1, 2023 at 4:09 AM André Almeida wrote:
>>
>> @@ -949,6 +949,15 @@ struct hdr_output_metadata {
>> * Request that the page-flip is performed as soon as possible, ie. with no
>> * delay due to waiting for vblank. This may cause tearing to be
From: Tvrtko Ursulin
Commit 2caffbf11762 ("drm/i915: Revoke mmaps and prevent access to fence
registers across reset") removed the temporary implementation of a reset
under stop machine but forgot to remove this one commented out define.
Signed-off-by: Tvrtko Ursulin
---
Thomas Zimmermann writes:
> Hi
>
> Am 05.07.23 um 10:49 schrieb Javier Martinez Canillas:
[...]
>>
>> The #define FBINFO_FLAG_DEFAULT FBINFO_DEFAULT seems to be there since
>> the
>> original v2.6.12-rc2 git import in commit 1da177e4c3f4, so is hard to know
>> why was introduced.
Convert all instances of dev_err() -> return to dev_err_probe() and
where it makes sense to, change instances of `return ret` at the end
of probe functions to `return 0`, as errors are returned earlier.
Signed-off-by: AngeloGioacchino Del Regno
Reviewed-by: Alexandre Mergnat
Reviewed-by: CK Hu
Instead of open coding calls to platform_get_resource() followed by
devm_ioremap_resource(), perform a single call to the helper
devm_platform_ioremap_resource().
Also, in order to drop the now useless struct resource pointer in
all of the probe functions, it was also necessary to remove a
Simplify the error path of return functions and drop the call to
pm_runtime_disable() in remove functions by switching to
devm_pm_runtime_enable() where possible.
Signed-off-by: AngeloGioacchino Del Regno
Reviewed-by: Alexandre Mergnat
Reviewed-by: CK Hu
---
This series performs some cleanups in drm/mediatek; specifically, changes
it to use devm_platform_ioremap_resource(), dev_err_probe() and
devm_pm_runtime_enable, hence harmonizing log formats and removing some
unneeded lines of code.
Changes in v2:
- Switched from
Hi Inki,
Le mardi 04 juillet 2023 à 08:49 +0900, 대인기/Tizen Platform Lab(SR)/삼성전자
a écrit :
> Hi,
>
> > -Original Message-
> > From: dri-devel On Behalf
> > Of
> > Paul Cercueil
> > Sent: Tuesday, July 4, 2023 6:47 AM
> > To: Krzysztof Kozlowski ; Rob
> > Herring
> > ; Conor Dooley ;
Thomas Zimmermann writes:
[...]
>>> + info->flags |= FBINFO_VIRTFB;
>>
>> I see that all fbdev drivers just do: info->flags = FBINFO_FLAG_DEFAULT |
>> FBINFO_VIRTFB
>>
>> Guess you are doing in two assignments to be consistent with drm_fbdev_dma.c
>> ?
>> I was just curious about the
Hi
Am 05.07.23 um 10:49 schrieb Javier Martinez Canillas:
Thomas Zimmermann writes:
Set fbdev default flags FBNFO_DEFAULT and mark the framebuffer with
FBINFO_DEFAULT, or did you meand FBINFO_FLAG_DEFAULT (the flag your patch
is actually using) ?
I just noticed that are the same... and in
From: Tvrtko Ursulin
Commit ade8a0f59844 ("drm/i915: Make all GPU resets atomic") added a
preempt disable section over the hardware reset callback to prepare the
driver for being able to reset from atomic contexts.
In retrospect I can see that the work item at a time was about removing
the
Hi Javier
Am 05.07.23 um 10:34 schrieb Javier Martinez Canillas:
Thomas Zimmermann writes:
Set fbdev default flags FBNFO_DEFAULT and mark the framebuffer with
FBINFO_VIRTFB. The framebuffer range is in DMA-able memory and should
be accessed with the CPU's regular memory ops.
Signed-off-by:
Thomas Zimmermann writes:
[...]
>>
>> The comment for I/O memory helpers says:
>>
>> /*
>> * Initializes struct fb_ops for framebuffers in I/O memory.
>> */
>>
>> I think that would be good to have consistency between these two,
>
> Sure, I had the same thought. I think I'll rather
Hi Javier
Am 05.07.23 um 10:23 schrieb Javier Martinez Canillas:
Thomas Zimmermann writes:
Hello Thomas,
Add initializer macros for struct fb_ops for framebuffers in DMA-able
memory areas. Also add a corresponding Kconfig token. As of now, this
is equivalent to system framebuffers and
Thomas Zimmermann writes:
> Remove the initializer macro FB_DEFAULT_SYS_OPS and its helper macro
> __FB_DEFAULT_SYS_OPS_MMAP. There are no users.
>
> Signed-off-by: Thomas Zimmermann
> Cc: Helge Deller (maintainer:FRAMEBUFFER LAYER)
> ---
Reviewed-by: Javier Martinez Canillas
--
Best
Thomas Zimmermann writes:
> Set fbdev default flags FBNFO_DEFAULT and mark the framebuffer with
FBINFO_DEFAULT. I noticed that the same typo is in patch 04/10 as well.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
I was just to complain that this is certainly incorrect.
But it's strange that ttm_mem_evict_first causes the warning in the
first place since it should never try to evict a BO which is about to be
destroyed.
Regards,
Christian.
Am 05.07.23 um 10:31 schrieb Lang Yu:
Please ignore this
Thomas Zimmermann writes:
> The fbdev emulation currently uses fbdev's default mmap code, which
> has been written for I/O memory. Provide an mmap that uses GEM's mmap
> infrastructure.
>
> Utilize fine-grained fbdev macros to initialize struct fb_ops. The
> macros set the read/write and the
Thomas Zimmermann writes:
> Use the mmap callback in struct drm_gem_object_funcs to set the
> VM flags. Replace a number of mmap helpers in omapdrm with their
> GEM helper counterparts. Generate DRM's file-operations instance
> with GEM's DEFINE_DRM_GEM_FOPS.
>
> Signed-off-by: Thomas Zimmermann
On 04/07/2023 18:01, Jonathan Marek wrote:
Note that with this, DMA4/DMA5 are still non-functional, but at least
display *something* in modetest instead of nothing or underflow.
Fixes: efcd0107727c ("drm/msm/dpu: add support for SM8550")
Signed-off-by: Jonathan Marek
---
Thomas Zimmermann writes:
> Set fbdev default flags FBNFO_DEFAULT and mark the framebuffer with
FBINFO_DEFAULT, or did you meand FBINFO_FLAG_DEFAULT (the flag your patch
is actually using) ?
I just noticed that are the same... and in patch 04/10 you used the former
for the tegra driver, but
1 - 100 of 122 matches
Mail list logo
