* Tony Lindgren [240118 08:57]:
> * Andrew Davis [240117 15:52]:
> > On 1/10/24 2:29 AM, Tony Lindgren wrote:
> > > * Andrew Davis [240109 17:20]:
> > > > --- a/arch/arm/boot/dts/ti/omap/dra7.dtsi
> > > > +++ b/arch/arm/boot/dts/ti/omap/dra7.dtsi
> > > > @@ -850,12 +850,19 @@ target-module@56000
The ITE IT6505 display bridge can take one I2S input and transmit it
over the DisplayPort link.
Add #sound-dai-cells (= 0) to the binding for it.
Signed-off-by: Chen-Yu Tsai
---
The driver side changes [1] are still being worked on, but given the
hardware is very simple, it would be nice if we c
> >> Currently this driver creates a SGT table using the CPU as the
> >> target device, then performs the dma_sync operations against
> >> that SGT. This is backwards to how DMA-BUFs are supposed to behave.
> >> This may have worked for the case where these buffers were given
> >> only back to the
On Fri, Jan 5, 2024 at 8:51 AM Zack Rusin wrote:
>
> Some drivers require the mapped tt pages to be decrypted. In an ideal
> world this would have been handled by the dma layer, but the TTM page
> fault handling would have to be rewritten to able to do that.
>
> A side-effect of the TTM page fault
[AMD Official Use Only - General]
> The vmf_insert_pfn_prot could cause unnecessary double faults
> on a device pfn. Because currently the vmf_insert_pfn_prot does
> not make the pfn writable so the pte entry is normally
> read-only or dirty catching.
> >>>
Just FYI I'm pulling this into drm-fixes straight as is, since if
fixes the regression and avoids the revert, however please keep
discussing until we are sure things are right, and we can deal with
any fixes in a follow-up patch.
Dave.
On Fri, 26 Jan 2024 at 03:32, Matthew Brost wrote:
>
> On T
On 1/22/24 4:17 PM, H. Peter Anvin wrote:
On January 22, 2024 4:04:33 PM PST, Alexey Makhalov
wrote:
On 1/22/24 10:28 AM, H. Peter Anvin wrote:
On January 22, 2024 8:32:22 AM PST, Dave Hansen wrote:
On 1/9/24 00:40, Alexey Makhalov wrote:
+#ifdef CONFIG_INTEL_TDX_GUEST
+unsigned long
The dp_power submodule is limited to handling the clocks only following
previous cleanups. Fold it into the dp_ctrl submodule, removing one
unnecessary level of indirection.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/Makefile| 1 -
drivers/gpu/drm/msm/dp/dp_ctrl.c| 150
Remove two levels of indirection and fetch next bridge directly in
dp_display_probe_tail().
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_display.c | 43 -
drivers/gpu/drm/msm/dp/dp_parser.c | 14
drivers/gpu/drm/msm/dp/dp_parser.
Rather than parsing the I/O addresses from dp_parser and then passing
them via a struct pointer to dp_catalog, handle I/O region parsing in
dp_catalog and drop it from dp_parser.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_catalog.c | 125 ++--
d
There is little point in going trough dp_parser->io indirection each
time the driver needs to access the PHY. Store the pointer directly in
dp_ctrl_private.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_ctrl.c| 37 +
drivers/gpu/drm/msm/dp/
Finally drop separate "parsing" submodule. There is no need in it
anymore. All submodules handle DT properties directly rather than
passing them via the separate structure pointer.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/Makefile| 1 -
drivers/gpu/drm/msm/dp/dp_aux.h
Instead of passing link properties through the separate struct, parse
them directly in the dp_panel.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_display.c | 8 -
drivers/gpu/drm/msm/dp/dp_display.h | 1 -
drivers/gpu/drm/msm/dp/dp_panel.c | 66 ++
All supported platforms use the same clocks configuration. Instead of
parsing names from DT in a pretty complex manner, use the static
configuration. If at some point newer (or older) platforms have
different clock configuration, this clock config can be moved to the
device data.
Signed-off-by: Dm
There is little point in sharing phy configuration structure between
several modules. Move it to dp_ctrl, which becomes the only submodule
re-configuring the PHY.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_catalog.c | 19 -
drivers/gpu/drm/msm/dp/dp_catalog.h |
Inline dp_catalog_aux_update_cfg() and call phy_calibrate() from dp_aux
functions directly.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_aux.c | 9 +++--
drivers/gpu/drm/msm/dp/dp_aux.h | 1 +
drivers/gpu/drm/msm/dp/dp_catalog.c | 12
drivers/gpu/drm/m
Split the dp_ctrl_clk_enable() beast into four functions, each of them
doing just a single item: enabling or disabling core or link clocks.
This allows us to cleanup the dss_module_power structure and makes
several dp_ctrl functions return void.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/dr
There is only a single DP_STREAM_PM clock, stream_pixel. Instead of
using a separate dss_module_power instance for this single clock, handle
this clock directly. This allows us to drop several wrapping functions.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_ctrl.c | 91 +++
In preparation to cleanup of the dp_power module, inline dp_power_init()
and dp_power_deinit() functions, which are now just turning the clocks
on and off.
Reviewed-by: Konrad Dybcio
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_display.c | 4 ++--
drivers/gpu/drm/msm/dp/dp_pow
It makes little sense to split the submodule get and actual DT parsing.
Call dp_parser_parse() directly from dp_parser_get(), so that the parser
data is fully initialised once it is returned to the caller.
Reviewed-by: Konrad Dybcio
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_
Drop several unused and obsolete definitions from the dp_parser module.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_parser.h | 46 --
1 file changed, 46 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_parser.h
b/drivers/gpu/drm/msm/dp/d
Reshuffle code in the DP driver, cleaning up clocks and DT parsing and
dropping the dp_power and dp_parser submodules.
Initially I started by looking onto stream_pixel clock handling only to
find several wrapping layers around a single clocks. After inlining
and/or dropping them (and thus dp_power
Drop unused and obsolete fields from struct dp_power_private.
Reviewed-by: Konrad Dybcio
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_power.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_power.c
b/drivers/gpu/drm/msm/dp/dp_power.c
index c4843
Hi Dave, Sima,
Fixes for 6.8.
The following changes since commit b16702be210bb49256f8a32df2c310383134dd57:
Merge tag 'exynos-drm-fixes-for-v6.8-rc2' of
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-fixes
(2024-01-25 14:22:15 +1000)
are available in the Git reposi
On 1/24/24 04:57, Zeng, Oak wrote:
Thanks a lot Danilo.
Maybe I wasn't clear enough. In the solution I proposed, each device still have
separate vm/page tables. Each device still need to manage the mapping, page
table flags etc. It is just in svm use case, all devices share one drm_gpuvm
inst
On 25/01/2024 21:38, Paloma Arellano wrote:
Modify dp_catalog_hw_revision to make the major and minor version values
known instead of outputting the entire hex value of the hardware version
register in preparation of using it for VSC SDP programming.
Signed-off-by: Paloma Arellano
---
drivers
On 25/01/2024 21:38, Paloma Arellano wrote:
All the components of YUV420 over DP are added. Therefore, let's mark the
connector property as true for DP connector when the DP type is not eDP
and when VSC SDP is supported.
Signed-off-by: Paloma Arellano
---
drivers/gpu/drm/msm/dp/dp_display.c |
On 25/01/2024 21:38, Paloma Arellano wrote:
Reserve CDM blocks for DP if the mode format is YUV420. Currently this
reservation only works for writeback and DP if the format is YUV420. But
this can be easily extented to other YUV formats for DP.
Signed-off-by: Paloma Arellano
---
drivers/gpu/d
On 25/01/2024 21:38, Paloma Arellano wrote:
CDM block supports formats other than H1V2 for DP. Since we are now
adding support for CDM over DP, relax the checks to allow all other
formats for DP other than H1V2.
Signed-off-by: Paloma Arellano
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_cdm.c | 2
On 25/01/2024 21:38, Paloma Arellano wrote:
Adjust the encoder format programming in the case of video mode for DP
to accommodate CDM related changes.
Signed-off-by: Paloma Arellano
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 16 +
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
On Fri, 26 Jan 2024 at 04:28, Daniel Vetter wrote:
>
> On Tue, Jan 23, 2024 at 05:25:38PM +1000, Dave Airlie wrote:
> > From: Dave Airlie
> >
> > fences are signalled on nvidia hw using non-stall interrupts.
> >
> > non-stall interrupts are not latched from my reading.
> >
> > When nouveau emits
On 1/25/24 13:19, Boris Brezillon wrote:
> On Fri, 5 Jan 2024 21:46:16 +0300
> Dmitry Osipenko wrote:
>
>> +static bool drm_gem_shmem_is_evictable(struct drm_gem_shmem_object *shmem)
>> +{
>> +return (shmem->madv >= 0) && shmem->base.funcs->evict &&
>> +refcount_read(&shmem->page
On 1/25/24 20:24, Daniel Vetter wrote:
> On Fri, Jan 05, 2024 at 09:46:03PM +0300, Dmitry Osipenko wrote:
>> Add lockless drm_gem_shmem_get_pages() helper that skips taking reservation
>> lock if pages_use_count is non-zero, leveraging from atomicity of the
>> refcount_t. Make drm_gem_shmem_mmap()
On 25/01/2024 21:38, Paloma Arellano wrote:
DP controller can be setup to operate in either SDP update flush mode or
peripheral flush mode based on the DP controller hardware version.
Starting in DP v1.2, the hardware documents require the use of
peripheral flush mode for SDP packets such as PPS
On 25/01/2024 21:38, Paloma Arellano wrote:
From: Kuogee Hsieh
Introduce a peripheral flushing mechanism to decouple peripheral
metadata flushing from timing engine related flush.
Signed-off-by: Kuogee Hsieh
Signed-off-by: Paloma Arellano
---
.../drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
On 25/01/2024 21:38, Paloma Arellano wrote:
Add support to pack and send the VSC SDP packet for DP. This therefore
allows the transmision of format information to the sinks which is
needed for YUV420 support over DP.
Signed-off-by: Paloma Arellano
---
drivers/gpu/drm/msm/dp/dp_catalog.c | 147
On 1/26/24 00:41, Dmitry Osipenko wrote:
> On 1/5/24 21:46, Dmitry Osipenko wrote:
>> for (i = page_offset; i < page_offset + NUM_FAULT_PAGES; i++) {
>> +/* Can happen if the last fault only partially filled this
>> + * section of the pages array before failing. In that
On 1/5/24 21:46, Dmitry Osipenko wrote:
> for (i = page_offset; i < page_offset + NUM_FAULT_PAGES; i++) {
> + /* Can happen if the last fault only partially filled this
> + * section of the pages array before failing. In that case
> + * we skip already fi
On 25/01/2024 21:38, Paloma Arellano wrote:
Parity calculation is necessary for VSC SDP implementation, therefore
move it to dp_catalog so it usable by both SDP programming and
dp_audio.c
Signed-off-by: Paloma Arellano
---
drivers/gpu/drm/msm/dp/dp_audio.c | 100
On 25/01/2024 21:38, Paloma Arellano wrote:
Change all relevant DP controller related programming for YUV420 cases.
Namely, change the pixel clock math to consider YUV420, program the
configuration control to indicate YUV420, as well as modify the MVID
programming to consider YUV420.
Too many i
On 25/01/2024 21:38, Paloma Arellano wrote:
INTF_CONFIG2 register cannot have widebus enabled when DP format is
YUV420. Therefore, program the INTF to send 1 ppc.
I think this is handled in the DP driver, where we disallow wide bus for
YUV 4:2:0 modes.
Signed-off-by: Paloma Arellano
---
On 25/01/2024 21:38, Paloma Arellano wrote:
Widebus enablement is decided by the interfaces based on their specific
checks and that already happens with DSI/DP specific helpers. Let's
invoke these helpers from dpu_encoder_is_widebus_enabled() to make it
cleaner overall.
Signed-off-by: Paloma Are
On 25/01/2024 21:38, Paloma Arellano wrote:
YUV420 format is supported only in the VSC SDP packet and not through
MSA. Hence add an API which indicates the sink support which can be used
by the rest of the DP programming.
This API ideally should go to drm/display/drm_dp_helper.c
Signed-off-b
On 25/01/2024 21:38, Paloma Arellano wrote:
Wide bus is not supported when the mode is YUV420 in DP. In preparation
for changing the DPU programming to reflect this, the value and
assignment location of wide_bus_en for the DP submodules must be
changed. Move it from boot time in dp_init_sub_modul
On 25/01/2024 21:38, Paloma Arellano wrote:
Rename wide_bus_en to wide_bus_supported in dp_display_private to
correctly establish that the parameter is referencing if wide bus is
supported instead of enabled.
Signed-off-by: Paloma Arellano
---
drivers/gpu/drm/msm/dp/dp_display.c | 42
On 25/01/2024 21:38, Paloma Arellano wrote:
Move dpu_encoder_helper_phys_setup_cdm to dpu_encoder in preparation for
implementing CDM compatibility for DP.
Nit: s/CDM compatibility/YUV support/. It might make sense to spell it
out that YUV over DP requires CDM.
Signed-off-by: Paloma Arella
On 25/01/2024 21:38, Paloma Arellano wrote:
Generalize dpu_encoder_helper_phys_setup_cdm to be compatible with DP.
Signed-off-by: Paloma Arellano
---
.../gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 4 +--
.../drm/msm/disp/dpu1/dpu_encoder_phys_wb.c | 31 ++-
2 files chang
On Fri, 22 Dec 2023 18:41:51 +0100, Alex Bee wrote:
> This is version 4 of my series that aims to add support for the display
> controller (VOP) and the HDMI controller block of RK3128 (which is very
> similar to the one found in RK3036). The original intention of this series
> was to add support f
> -Original Message-
> From: Daniel Vetter
> Sent: Thursday, January 25, 2024 1:33 PM
> To: Christian König
> Cc: Zeng, Oak ; Danilo Krummrich ;
> Dave Airlie ; Daniel Vetter ; Felix
> Kuehling ; Welty, Brian ; dri-
> de...@lists.freedesktop.org; intel...@lists.freedesktop.org; Bommu,
On Thu, Jan 25, 2024 at 09:29:37PM +0100, Uwe Kleine-König wrote:
> On Thu, Jan 25, 2024 at 11:32:47AM -0800, Florian Fainelli wrote:
> > On 1/25/24 04:08, Uwe Kleine-König wrote:
> > > Currently a pwm_chip stores in its struct device *dev member a pointer
> > > to the parent device. Preparing a ch
Hello Doug,
On Thu, Jan 25, 2024 at 09:47:42AM -0800, Doug Anderson wrote:
> On Thu, Jan 25, 2024 at 4:11 AM Uwe Kleine-König
> wrote:
> >
> > struct pwm_chip::dev is about to change. To not have to touch this
> > driver in the same commit as struct pwm_chip::dev, use the macro
> > provided for e
Hello Doug,
On Thu, Jan 25, 2024 at 09:48:04AM -0800, Doug Anderson wrote:
> On Thu, Jan 25, 2024 at 4:11 AM Uwe Kleine-König
> wrote:
> > @@ -1374,7 +1374,7 @@ static void ti_sn_pwm_pin_release(struct ti_sn65dsi86
> > *pdata)
> >
> > static struct ti_sn65dsi86 *pwm_chip_to_ti_sn_bridge(struct
On Thu, Jan 25, 2024 at 11:32:47AM -0800, Florian Fainelli wrote:
> On 1/25/24 04:08, Uwe Kleine-König wrote:
> > Currently a pwm_chip stores in its struct device *dev member a pointer
> > to the parent device. Preparing a change that embeds a full struct
> > device in struct pwm_chip, this accesso
On Tue, Jan 23, 2024 at 04:12:26PM -0600, Andrew Davis wrote:
> Currently this driver creates a SGT table using the CPU as the
> target device, then performs the dma_sync operations against
> that SGT. This is backwards to how DMA-BUFs are supposed to behave.
> This may have worked for the case whe
On Tue, Jan 23, 2024 at 05:20:55PM +, Matthew Wilcox wrote:
> We're currently trying to remove page->mapping from the entire kernel.
> This has me interested in fb_defio and since I made such a mess of it
> with commits ccf953d8f3d6 / 0b78f8bcf495, I'd like to discuss what to
> do before diving
Reserve CDM blocks for DP if the mode format is YUV420. Currently this
reservation only works for writeback and DP if the format is YUV420. But
this can be easily extented to other YUV formats for DP.
Signed-off-by: Paloma Arellano
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 20 +++
All the components of YUV420 over DP are added. Therefore, let's mark the
connector property as true for DP connector when the DP type is not eDP
and when VSC SDP is supported.
Signed-off-by: Paloma Arellano
---
drivers/gpu/drm/msm/dp/dp_display.c | 5 -
1 file changed, 4 insertions(+), 1 de
Add support to pack and send the VSC SDP packet for DP. This therefore
allows the transmision of format information to the sinks which is
needed for YUV420 support over DP.
Signed-off-by: Paloma Arellano
---
drivers/gpu/drm/msm/dp/dp_catalog.c | 147
drivers/gpu/drm/
Wide bus is not supported when the mode is YUV420 in DP. In preparation
for changing the DPU programming to reflect this, the value and
assignment location of wide_bus_en for the DP submodules must be
changed. Move it from boot time in dp_init_sub_modules() to run time in
dp_display_mode_set.
Sign
From: Kuogee Hsieh
Introduce a peripheral flushing mechanism to decouple peripheral
metadata flushing from timing engine related flush.
Signed-off-by: Kuogee Hsieh
Signed-off-by: Paloma Arellano
---
.../drm/msm/disp/dpu1/dpu_encoder_phys_vid.c| 3 +++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw
Adjust the encoder format programming in the case of video mode for DP
to accommodate CDM related changes.
Signed-off-by: Paloma Arellano
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 16 +
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 8 +
.../drm/msm/disp/dpu1/dpu_encoder_
DP controller can be setup to operate in either SDP update flush mode or
peripheral flush mode based on the DP controller hardware version.
Starting in DP v1.2, the hardware documents require the use of
peripheral flush mode for SDP packets such as PPS OR VSC SDP packets.
In-line with this guidan
CDM block supports formats other than H1V2 for DP. Since we are now
adding support for CDM over DP, relax the checks to allow all other
formats for DP other than H1V2.
Signed-off-by: Paloma Arellano
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_cdm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
YUV420 format is supported only in the VSC SDP packet and not through
MSA. Hence add an API which indicates the sink support which can be used
by the rest of the DP programming.
Signed-off-by: Paloma Arellano
---
drivers/gpu/drm/msm/dp/dp_display.c | 3 ++-
drivers/gpu/drm/msm/dp/dp_panel.c |
Widebus enablement is decided by the interfaces based on their specific
checks and that already happens with DSI/DP specific helpers. Let's
invoke these helpers from dpu_encoder_is_widebus_enabled() to make it
cleaner overall.
Signed-off-by: Paloma Arellano
---
drivers/gpu/drm/msm/disp/dpu1/dpu_
Modify dp_catalog_hw_revision to make the major and minor version values
known instead of outputting the entire hex value of the hardware version
register in preparation of using it for VSC SDP programming.
Signed-off-by: Paloma Arellano
---
drivers/gpu/drm/msm/dp/dp_catalog.c | 12 +---
INTF_CONFIG2 register cannot have widebus enabled when DP format is
YUV420. Therefore, program the INTF to send 1 ppc.
Signed-off-by: Paloma Arellano
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dp
Generalize dpu_encoder_helper_phys_setup_cdm to be compatible with DP.
Signed-off-by: Paloma Arellano
---
.../gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 4 +--
.../drm/msm/disp/dpu1/dpu_encoder_phys_wb.c | 31 ++-
2 files changed, 18 insertions(+), 17 deletions(-)
diff --git
Parity calculation is necessary for VSC SDP implementation, therefore
move it to dp_catalog so it usable by both SDP programming and
dp_audio.c
Signed-off-by: Paloma Arellano
---
drivers/gpu/drm/msm/dp/dp_audio.c | 100
drivers/gpu/drm/msm/dp/dp_catalog.h | 72 +++
Change all relevant DP controller related programming for YUV420 cases.
Namely, change the pixel clock math to consider YUV420, program the
configuration control to indicate YUV420, as well as modify the MVID
programming to consider YUV420.
Signed-off-by: Paloma Arellano
---
drivers/gpu/drm/msm/
Rename wide_bus_en to wide_bus_supported in dp_display_private to
correctly establish that the parameter is referencing if wide bus is
supported instead of enabled.
Signed-off-by: Paloma Arellano
---
drivers/gpu/drm/msm/dp/dp_display.c | 42 ++---
1 file changed, 21 inser
Move dpu_encoder_helper_phys_setup_cdm to dpu_encoder in preparation for
implementing CDM compatibility for DP.
Signed-off-by: Paloma Arellano
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 78 +
.../gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 9 ++
.../drm/msm/disp/dpu1/dp
The Chroma Down Sampling (CDM) block is a hardware component in the DPU
pipeline that includes a CSC block capable of converting RGB input from
the DPU to YUV data.
This block can be used with either HDMI, DP, or writeback interfaces.
This series adds support for the CDM block to be used with DP i
On 1/25/24 04:08, Uwe Kleine-König wrote:
Currently a pwm_chip stores in its struct device *dev member a pointer
to the parent device. Preparing a change that embeds a full struct
device in struct pwm_chip, this accessor macro should be used in all
drivers directly accessing chip->dev now. This w
On Tue, Jan 23, 2024 at 01:04:24PM +, Matt Coster wrote:
> From: Donald Robson
>
> When the kernel driver 'loses' the device, for instance if the firmware
> stops communicating, the driver calls drm_dev_unplug(). This is
> currently done inside the drm_dev_enter() critical section, which isn'
On Mon, Dec 11, 2023 at 9:33 PM Adam Ford wrote:
>
> When using video sync pulses, the HFP, HBP, and HSA are divided between
> the available lanes if there is more than one lane. For certain
> timings and lane configurations, the HFP may not be evenly divisible.
> If the HFP is rounded down, it e
Sorry, I realized there is a mistake in this patch after sending it out. It
results in a use-after-free of "entry". I've sent out an updated version which
should avoid the issue.
On 1/25/24 10:03, Erik Kurzinger wrote:
> During syncobj_eventfd_entry_func, dma_fence_chain_find_seqno may set
> the
During syncobj_eventfd_entry_func, dma_fence_chain_find_seqno may set
the fence to NULL if the given seqno is signaled and a later seqno has
already been submitted. In that case, the eventfd should be signaled
immediately which currently does not happen.
This is a similar issue to the one addresse
> -Original Message-
> From: Felix Kuehling
> Sent: Thursday, January 25, 2024 12:16 PM
> To: Zeng, Oak ; Christian König
> ; Danilo Krummrich ; Dave
> Airlie ; Daniel Vetter ; Shah, Ankur N
> ; Winiarski, Michal
> Cc: Welty, Brian ; dri-devel@lists.freedesktop.org;
> intel-
> x...@lis
On Wed, Jan 24, 2024 at 09:33:12AM +0100, Christian König wrote:
> Am 23.01.24 um 20:37 schrieb Zeng, Oak:
> > [SNIP]
> > Yes most API are per device based.
> >
> > One exception I know is actually the kfd SVM API. If you look at the
> > svm_ioctl function, it is per-process based. Each kfd_proce
On Tue, Jan 23, 2024 at 05:25:38PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> fences are signalled on nvidia hw using non-stall interrupts.
>
> non-stall interrupts are not latched from my reading.
>
> When nouveau emits a fence, it requests a NON_STALL signalling,
> but it only calls th
On Tue, Jan 23, 2024 at 06:09:05AM +, Jason-JH Lin (林睿祥) wrote:
> Hi Maxime, Daniel,
>
> We encountered similar issue with mediatek SoCs.
>
> We have found that in drm_atomic_helper_commit_rpm(), when disabling
> the cursor plane, the old_state->legacy_cursor_update in
> drm_atomic_wait_for_v
On Mon, Jan 22, 2024 at 10:31:50AM +0100, Anna-Maria Behnsen wrote:
> Hi,
>
> this is a repost of the RFC queue
> https://lkml.kernel.org/r/20240116151456.48238-1-anna-ma...@linutronix.de
>
> Jonathan Corbet is fine with this change and mentioned in an answer the
> following:
>
> "The kernel-d
On Fri, Jan 19, 2024 at 08:32:06AM -0800, Erik Kurzinger wrote:
> When waiting for a syncobj timeline point whose fence has not yet been
> submitted with the WAIT_FOR_SUBMIT flag, a callback is registered using
> drm_syncobj_fence_add_wait and the thread is put to sleep until the
> timeout expires.
On Fri, Jan 19, 2024 at 03:13:57PM +0100, Paul Cercueil wrote:
> These functions should be used by device drivers when they start and
> stop accessing the data of DMABUF. It allows DMABUF importers to cache
> the dma_buf_attachment while ensuring that the data they want to access
> is available for
During syncobj_eventfd_entry_func, dma_fence_chain_find_seqno may set
the fence to NULL if the given seqno is signaled and a later seqno has
already been submitted. In that case, the eventfd should be signaled
immediately which currently does not happen.
This is a similar issue to the one addresse
Hi Ma Jun,
Greetings again.
So, I just tested the recommended patch and the issue with the graphical login
screen was successfully resolved.
Thank you very much for your prompt reviews and recommended patches.
God bless.
Best regards,
Mirsad Todorovac
On 1/25/24 10:29, Mirsad Todorovac wrote
On Thu, Jan 25, 2024 at 04:00:16PM +0100, Christian König wrote:
> Am 24.01.24 um 11:58 schrieb Paul Cercueil:
> > [SNIP]
> > > > The problem was then that dma_buf_unmap_attachment cannot be called
> > > > before the dma_fence is signaled, and calling it after is already
> > > > too
> > > > late (b
Hi,
On Thu, Jan 25, 2024 at 4:11 AM Uwe Kleine-König
wrote:
>
> This prepares the pwm driver of the ti-sn65dsi86 to further changes of
> the pwm core outlined in the commit introducing devm_pwmchip_alloc().
> There is no intended semantical change and the driver should behave as
> before.
>
> Sig
Hi,
On Thu, Jan 25, 2024 at 4:11 AM Uwe Kleine-König
wrote:
>
> struct pwm_chip::dev is about to change. To not have to touch this
> driver in the same commit as struct pwm_chip::dev, use the macro
> provided for exactly this purpose.
>
> Signed-off-by: Uwe Kleine-König
> ---
> drivers/gpu/drm/
On Thu, Jan 25, 2024 at 10:24:24AM +0100, Vlastimil Babka wrote:
> On 1/24/24 22:08, Matthew Brost wrote:
> > All entities must be drained in the DRM scheduler run job worker to
> > avoid the following case. An entity found that is ready, no job found
> > ready on entity, and run job worker goes id
On Thu, Jan 25, 2024 at 04:12:58PM +0100, Christian König wrote:
>
>
> Am 24.01.24 um 22:08 schrieb Matthew Brost:
> > All entities must be drained in the DRM scheduler run job worker to
> > avoid the following case. An entity found that is ready, no job found
> > ready on entity, and run job wor
On Fri, Jan 05, 2024 at 09:46:03PM +0300, Dmitry Osipenko wrote:
> Add lockless drm_gem_shmem_get_pages() helper that skips taking reservation
> lock if pages_use_count is non-zero, leveraging from atomicity of the
> refcount_t. Make drm_gem_shmem_mmap() to utilize the new helper.
>
> Acked-by: Ma
On 2024-01-24 20:17, Zeng, Oak wrote:
Hi Christian,
Even though I mentioned KFD design, I didn’t mean to copy the KFD
design. I also had hard time to understand the difficulty of KFD under
virtualization environment.
The problem with virtualization is related to virtualization design
cho
On 1/5/2024 3:50 PM, Dmitry Baryshkov wrote:
We have several reports of vblank timeout messages. However after some
debugging it was found that there might be different causes to that.
Include the actual CTL_FLUSH value into the timeout message. This allows
us to identify the DPU block that ge
Hi Chunming,
From: 周春明(日月)
Sent: Thursday, January 25, 2024 6:01 AM
To: Zeng, Oak ; Christian König ;
Danilo Krummrich ; Dave Airlie ; Daniel
Vetter ; Felix Kuehling ; Shah, Ankur
N ; Winiarski, Michal
Cc: Brost, Matthew ; thomas.hellst...@linux.intel.com;
Welty, Brian ; dri-devel@lists.fre
Am Donnerstag, dem 25.01.2024 um 17:27 +0100 schrieb Christian Gmeiner:
> Hi Philipp
>
> >
> > Turn the etnaviv_is_model_rev() macro into a static inline function.
> > Use the raw model number as a parameter instead of the chipModel_GC
> > defines. This reduces synchronization requirements fo
On 05/01/2024 18:46, Dmitry Osipenko wrote:
> To simplify the drm-shmem refcnt handling, we're moving away from
> the implicit get_pages() that is used by get_pages_sgt(). From now on
> drivers will have to pin pages while they use sgt. Panfrost's shrinker
> doesn't support swapping out BOs, hence
On 05/01/2024 18:46, Dmitry Osipenko wrote:
> From: Boris Brezillon
>
> If some the pages or sgt allocation failed, we shouldn't release the
> pages ref we got earlier, otherwise we will end up with unbalanced
> get/put_pages() calls. We should instead leave everything in place
> and let the BO r
Hi Christian,
I got a few more questions inline
From: Christian König
Sent: Wednesday, January 24, 2024 3:33 AM
To: Zeng, Oak ; Danilo Krummrich ; Dave
Airlie ; Daniel Vetter ; Felix Kuehling
Cc: Welty, Brian ; dri-devel@lists.freedesktop.org;
intel...@lists.freedesktop.org; Bommu, Krishnaia
1 - 100 of 160 matches
Mail list logo
