On Tue, Feb 13, 2024 at 09:23:40AM -0800, Rob Clark wrote:
> From: Rob Clark
>
> The brute force iommu_flush_iotlb_all() was good enough for unmap, but
> in some cases a map operation could require removing a table pte entry
> to replace with a block entry. This also requires tlb invalidation.
Hi Doug,
On Wed, Feb 14, 2024 at 12:44:23PM -0800, Doug Anderson wrote:
> On Wed, Feb 14, 2024 at 1:34 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 accessor
> > function
On 27.01.24 14:14, Salvatore Bonaccorso wrote:
>
> In Debian (https://bugs.debian.org/1061449) we got the following
> quotred report:
>
> On Wed, Jan 24, 2024 at 07:38:16PM +0100, Patrice Duroux wrote:
>> Package: src:linux
>> Version: 6.7.1-1~exp1
>> Severity: normal
>>
>> Giving a try to 6.7,
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 2c3b09aac00d7835023bbc4473ee06696be64fa8 Add linux-next specific
files for 20240214
Error/Warning: (recently discovered and may have been fixed)
iptable_nat.c:(.ref.text+0x1a): undefined
On Wed, Feb 14, 2024 at 11:24:31PM +0200, Abel Vesa wrote:
> Document the DPU for Qualcomm X1E80100 platform in the SM8650 schema, as
> they are similar.
>
> Signed-off-by: Abel Vesa
> ---
> Documentation/devicetree/bindings/display/msm/qcom,sm8650-dpu.yaml | 4 +++-
> 1 file changed, 3
On Wed, Feb 14, 2024 at 11:24:30PM +0200, Abel Vesa wrote:
> Document the MDSS hardware found on the Qualcomm X1E80100 platform.
>
> Reviewed-by: Krzysztof Kozlowski
> Signed-off-by: Abel Vesa
> ---
> .../bindings/display/msm/qcom,x1e80100-mdss.yaml | 252
> +
> 1 file
On Fri, 2024-02-02 at 17:14 +, Timur Tabi wrote:
> On Fri, 2024-02-02 at 01:05 +0100, Danilo Krummrich wrote:
> > nouveau_abi16_ioctl_channel_alloc() and nouveau_cli_init() simply call
> > their corresponding *_fini() counterpart. This can lead to
> > nouveau_sched_fini() being called without
Marcelo Mendes Spessoto Junior (3):
drm/amd/display: clean codestyle errors
drm/amd/display: clean codestyle errors
drm/amd/display: clean codestyle errors
drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h | 6 +++---
drivers/gpu/drm/amd/display/dmub/src/dmub_dcn32.c | 2 +-
Use () for macro and adjust initial brace for dmub/src/dmub_dcn35.c
Signed-off-by: Marcelo Mendes Spessoto Junior
---
drivers/gpu/drm/amd/display/dmub/src/dmub_dcn35.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dmub/src/dmub_dcn35.c
Use () for complex macro in dmub/src/dmub_dcn32.c
Signed-off-by: Marcelo Mendes Spessoto Junior
---
drivers/gpu/drm/amd/display/dmub/src/dmub_dcn32.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dmub/src/dmub_dcn32.c
Use flexible array members in dmub/inc/dmub_cmd.h
Signed-off-by: Marcelo Mendes Spessoto Junior
---
drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h
On Wed, Feb 14, 2024 at 03:57:54PM -0600, Mario Limonciello wrote:
> Some manufacturers have intentionally put an EDID that differs from
> the EDID on the internal panel on laptops. Drivers that prefer to
> fetch this EDID can set a bit on the drm_connector to indicate that
> the DRM EDID helpers
Hi,
On Tue, Feb 13, 2024 at 10:25 PM Hsin-Yi Wang wrote:
>
> On Wed, Feb 14, 2024 at 2:23 PM Douglas Anderson
> wrote:
> >
> > If an eDP panel is not powered on then any attempts to talk to it over
> > the DP AUX channel will timeout. Unfortunately these attempts may be
> > quite slow.
s.org/project/devicetree-bindings/patch/20240214-x1e80100-display-v2-2-cf05ba887...@linaro.org
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure
labs.org/project/devicetree-bindings/patch/20240214-x1e80100-display-v2-1-cf05ba887...@linaro.org
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make s
Some manufacturers have intentionally put an EDID that differs from
the EDID on the internal panel on laptops.
Attempt to fetch this EDID if it exists and prefer it over the EDID
that is provided by the panel. If a user prefers to use the EDID from
the panel, offer a module parameter that would
Rather than inventing a wrapper to acpi_video_get_edid() use the
one provided by drm. This fixes two problems:
1. A memory leak that the memory provided by the ACPI call was
never freed.
2. Validation of the BIOS provided blob.
Convert the usage in nouveau_connector_detect_lvds() to use
struct
Many drivers ab(use) `select BACKLIGHT_CLASS_DEVICE` to avoid
dependency problems. This however makes it impossible for DRM
core to be able to add a dependency on ACPI_VIDEO. Switch users
of `select BACKLIGHT_CLASS_DEVICE` to `depends on BACKLIGHT_CLASS_DEVICE`.
Signed-off-by: Mario Limonciello
Many DRM drivers (ab)use `select ACPI_VIDEO` and to avoid problems
will then select all the dependencies for ACPI_VIDEO. This creates
a soft dependency, but makes it very hard to use ACPI_VIDEO in DRM
core. Switch everything else over to use `depends on ACPI_VIDEO`
instead.
Signed-off-by: Mario
Some manufacturers have intentionally put an EDID that differs from
the EDID on the internal panel on laptops. Drivers that prefer to
fetch this EDID can set a bit on the drm_connector to indicate that
the DRM EDID helpers should try to fetch it and it is preferred if
it's present.
This series adds the ability to fetch the EDID through ACPI for laptop
panels. Drivers need to opt into the behavior.
In this series it's enabled by default for all eDP or LVDS panels with
AMDGPU and certain panels for Nouveau.
Mario Limonciello (5):
drm: Stop using `select ACPI_VIDEO` in all
On 12.02.2024 15:45, Neil Armstrong wrote:
> On 12/02/2024 11:46, Konrad Dybcio wrote:
>> On 12.02.2024 11:37, Neil Armstrong wrote:
>>> Add support for the A750 GPU found on the SM8650 platform
>>>
>>> Unlike the the very close A740 GPU on the SM8550 SoC, the A750 GPU
>>> doesn't have an HWCFG
Hi,
On Tue, Feb 13, 2024 at 11:24 PM Hsin-Yi Wang wrote:
>
> This reverts commit 70e0d5550f5cec301ad116703b840a539fe985dc.
>
> The overridden mode fixes the panel glitching issue on mt8186 chromebook.
> However, it causes the internal display not working on mt8173 chromebook.
> Revert the
Add definitions for the display hardware used on the Qualcomm X1E80100
platform.
Co-developed-by: Abhinav Kumar
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Abel Vesa
---
.../drm/msm/disp/dpu1/catalog/dpu_9_2_x1e80100.h | 449 +
This patchset adds support for display for X1E80100.
The support for embedded DisplayPort on this platform will not
be enabled using the connetor type from driver match data,
but through some 'is-edp' property via DT. This subsequent work
will be part of a separate patchset.
Signed-off-by: Abel
Add support for MDSS on X1E80100.
Signed-off-by: Abel Vesa
---
drivers/gpu/drm/msm/msm_mdss.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c
index 35423d10aafa..6eda501e2a1a 100644
---
Document the MDSS hardware found on the Qualcomm X1E80100 platform.
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Abel Vesa
---
.../bindings/display/msm/qcom,x1e80100-mdss.yaml | 252 +
1 file changed, 252 insertions(+)
diff --git
Document the DPU for Qualcomm X1E80100 platform in the SM8650 schema, as
they are similar.
Signed-off-by: Abel Vesa
---
Documentation/devicetree/bindings/display/msm/qcom,sm8650-dpu.yaml | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
Remove unused structs, members, and file. Many of these are written but
never read.
Signed-off-by: Ian Forbes
---
drivers/gpu/drm/vmwgfx/ttm_object.c| 4 -
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h| 27 -
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c| 12 ---
Hi,
On Wed, Feb 14, 2024 at 1:34 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 accessor
> function provided for exactly this purpose.
>
> Signed-off-by: Uwe Kleine-König
> ---
>
On 2/14/2024 11:20 AM, Dmitry Baryshkov wrote:
On Wed, 14 Feb 2024 at 20:02, Abhinav Kumar wrote:
On 2/8/2024 6:50 AM, 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.
To
On 2/14/2024 11:39 AM, Dmitry Baryshkov wrote:
On Wed, 14 Feb 2024 at 20:04, 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.
Changes in v3:
On Wed, 14 Feb 2024 at 21:39, Ville Syrjälä
wrote:
>
> On Wed, Feb 14, 2024 at 09:17:06PM +0200, Dmitry Baryshkov wrote:
> > On Wed, 14 Feb 2024 at 20:47, Ville Syrjälä
> > wrote:
> > >
> > > On Wed, Feb 14, 2024 at 08:37:02PM +0200, Ville Syrjälä wrote:
> > > > On Thu, Sep 14, 2023 at
On Wed, 14 Feb 2024 at 20:04, 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
On Wed, 14 Feb 2024 at 20:04, 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.
>
> Changes in v3:
> - Create a new struct,
On Wed, Feb 14, 2024 at 09:17:06PM +0200, Dmitry Baryshkov wrote:
> On Wed, 14 Feb 2024 at 20:47, Ville Syrjälä
> wrote:
> >
> > On Wed, Feb 14, 2024 at 08:37:02PM +0200, Ville Syrjälä wrote:
> > > On Thu, Sep 14, 2023 at 08:06:55AM +0300, Dmitry Baryshkov wrote:
> > > > The helper
Currently, the V3D driver uses PAGE_SHIFT over the assumption that
PAGE_SHIFT = 12, as the PAGE_SIZE = 4KB. But, the RPi 5 is using
PAGE_SIZE = 16KB, so the MMU PAGE_SHIFT is different than the system's
PAGE_SHIFT.
Enable V3D to be used in system's with any PAGE_SIZE by making sure that
On Wed, 14 Feb 2024 at 20:02, Abhinav Kumar wrote:
>
>
>
> On 2/8/2024 6:50 AM, 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.
> > To allow us to identify the DPU block
On Wed, 14 Feb 2024 at 20:41, Abhinav Kumar wrote:
>
>
>
> On 9/13/2023 10:06 PM, Dmitry Baryshkov wrote:
> > Provide atomic_print_state callback to the DPU's private object. This
> > way the debugfs/dri/0/state will also include RM's internal state.
> >
>
> I like this idea !
>
> >
On Wed, 14 Feb 2024 at 20:47, Ville Syrjälä
wrote:
>
> On Wed, Feb 14, 2024 at 08:37:02PM +0200, Ville Syrjälä wrote:
> > On Thu, Sep 14, 2023 at 08:06:55AM +0300, Dmitry Baryshkov wrote:
> > > The helper drm_atomic_helper_check_plane_state() runs several checks on
> > > plane src and dst
On Wed, 14 Feb 2024 at 20:08, Abhinav Kumar wrote:
>
>
>
> On 2/14/2024 10:02 AM, Ville Syrjälä wrote:
> > On Wed, Feb 14, 2024 at 09:17:34AM -0800, Abhinav Kumar wrote:
> >>
> >>
> >> On 2/14/2024 12:15 AM, Dmitry Baryshkov wrote:
> >>> On Wed, 14 Feb 2024 at 01:45, Abhinav Kumar
> >>> wrote:
On 9/13/2023 10:06 PM, Dmitry Baryshkov wrote:
Take into account the plane rotation and flipping when calculating src
positions for the wide plane parts.
This is not an issue yet, because rotation is only supported for the
UBWC planes and wide UBWC planes are rejected anyway because in
On Wed, Feb 14, 2024 at 08:37:02PM +0200, Ville Syrjälä wrote:
> On Thu, Sep 14, 2023 at 08:06:55AM +0300, Dmitry Baryshkov wrote:
> > The helper drm_atomic_helper_check_plane_state() runs several checks on
> > plane src and dst rectangles, including the check whether required
> > scaling fits
On Wed, 14 Feb 2024, Ville Syrjälä wrote:
> On Tue, Feb 13, 2024 at 01:30:59PM +0200, Jani Nikula wrote:
>> Drop the duplicate read of DP_MSTM_CAP DPCD register, and the duplicate
>> logic for choosing MST mode, and store the chosen mode in struct
>> intel_dp. Rename intel_dp_configure_mst() to
On 9/13/2023 10:06 PM, Dmitry Baryshkov wrote:
Provide atomic_print_state callback to the DPU's private object. This
way the debugfs/dri/0/state will also include RM's internal state.
I like this idea !
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 4
On Thu, Sep 14, 2023 at 08:06:55AM +0300, Dmitry Baryshkov wrote:
> The helper drm_atomic_helper_check_plane_state() runs several checks on
> plane src and dst rectangles, including the check whether required
> scaling fits into the required margins. The msm driver would benefit
> from having a
On Tue, Feb 13, 2024 at 01:31:00PM +0200, Jani Nikula wrote:
> Abstract the MST mode disconnect to a separate function.
>
> Cc: Arun R Murthy
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 24
On Tue, Feb 13, 2024 at 01:30:59PM +0200, Jani Nikula wrote:
> Drop the duplicate read of DP_MSTM_CAP DPCD register, and the duplicate
> logic for choosing MST mode, and store the chosen mode in struct
> intel_dp. Rename intel_dp_configure_mst() to intel_dp_mst_configure()
> while at it.
>
> Cc:
On 9/13/2023 10:06 PM, Dmitry Baryshkov wrote:
The helper drm_atomic_helper_check_plane_state() runs several checks on
plane src and dst rectangles, including the check whether required
scaling fits into the required margins. The msm driver would benefit
from having a function that does all
On Tue, Feb 13, 2024 at 01:30:58PM +0200, Jani Nikula wrote:
> Clarify the conditions for choosing the MST mode to use by adding a new
> function intel_dp_mst_mode_choose(). This also prepares for being able
> to extend the MST modes to single-stream sideband messaging.
>
> Cc: Arun R Murthy
>
On Tue, Feb 13, 2024 at 01:30:57PM +0200, Jani Nikula wrote:
> Rename intel_dp_can_mst() to intel_dp_mst_detect(), and move all DP MST
> detect debug logging there. Debug log the sink's MST capability,
> including single-stream sideband messaging support, and the decision
> whether to enable MST
On Tue, Feb 13, 2024 at 01:30:56PM +0200, Jani Nikula wrote:
> Amend drm_dp_read_mst_cap() to return an enum, indicating "SST", "SST
> with sideband messaging", or "MST". Modify all call sites to take the
> new return value into account.
>
> v2:
> - Rename enumerators (Ville)
>
> Cc: Arun R
On 2/14/2024 10:02 AM, Ville Syrjälä wrote:
On Wed, Feb 14, 2024 at 09:17:34AM -0800, Abhinav Kumar wrote:
On 2/14/2024 12:15 AM, Dmitry Baryshkov wrote:
On Wed, 14 Feb 2024 at 01:45, Abhinav Kumar wrote:
intel_dp_vsc_sdp_pack() can be re-used by other DRM drivers as well.
Lets move
Adjust the encoder format programming in the case of video mode for DP
to accommodate CDM related changes.
Changes in v2:
- Move timing engine programming to a separate patch from this
one
- Move update_pending_flush_periph() invocation completely to
this patch
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 there is a CDM block available.
Changes in v3:
- Move setting the connector's ycbcr_420_allowed parameter so
that it is not
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
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.
Changes in v2:
- Minor code simplification
Signed-off-by: Paloma Arellano
Reviewed-by:
Adjust the encoder timing engine setup programming in the case of video
mode for YUV420 over DP to accommodate CDM.
Changes in v3:
- Move drm_display_mode's hskew division to another patch
- Minor cleanup
Changes in v2:
- Move timing engine programming to this patch
Change relevant DP controller related programming for YUV420 cases.
Program the configuration control register to indicate YUV420.
Changes in v2:
- Create a new patch only for configuration control programming
Signed-off-by: Paloma Arellano
Reviewed-by: Dmitry Baryshkov
---
From: Kuogee Hsieh
Introduce a peripheral flushing mechanism to decouple peripheral
metadata flushing from timing engine related flush.
Changes in v2:
- Fixed some misalignment issues
Signed-off-by: Kuogee Hsieh
Signed-off-by: Paloma Arellano
Reviewed-by: Dmitry Baryshkov
---
In the DP driver, check if VSC SDP is supported and propagate this value
to dp_panel. In dp_display's dp_mode, the out_fmt_is_yuv_420 parameter
must also utilize this value since YUV420 is only allowed when VSC SDP
is supported.
Changes in v2:
- Move DP programming when VSC SDP is
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.
Changes in v2:
- Add fixes tag
- Move patch to top of series
Fixes: 0afac0ba6024 ("drm/msm/dpu: add dpu_hw_cdm
Change all relevant DP controller related programming for YUV420 cases.
Namely, change the pixel clock math to consider YUV420 and modify the
MVID programming to consider YUV420.
Changes in v2:
- Move configuration control programming to a different commit
- Slight code
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
Reviewed-by: Dmitry Baryshkov
---
Generalize dpu_encoder_helper_phys_setup_cdm to be compatible with DP.
Changes in v2:
- Minor formatting changes
- Move the modification of the dimensions for CDM setup to a new
patch
Signed-off-by: Paloma Arellano
Reviewed-by: Dmitry Baryshkov
---
Move dpu_encoder_helper_phys_setup_cdm to dpu_encoder in preparation for
implementing YUV420 over DP, which requires CDM compatibility.
Changes in v2:
- Slightly change the wording of the commit text to make clear
that YUV over DP requires CDM
Signed-off-by: Paloma Arellano
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.
Changes in v3:
- Create a new struct, msm_dp_sdp_with_parity, which holds the
packing information for VSC
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
Setting up the timing engine when the physical encoder has a split role
neglects dividing the drm_display_mode's hskew parameter. Let's fix this
since this must also be done in preparation for implementing YUV420 over
DP.
Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Signed-off-by:
Parity calculation is necessary for VSC SDP implementation. Therefore
create new files dp_utils.c and dp_utils.h and move the parity
calculating functions here. This ensures that they are usable by SDP
programming in both dp_catalog.c and dp_audio.c
Changes in v3:
- Change ordering of the
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
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_display.c | 42
Modify the output width and height parameters of hw_cdm to utilize the
physical encoder's data instead of obtaining the information from the
framebuffer. CDM is to be set up to utilize the actual output data since
at CDM setup, there is no difference between the two sources.
Changes in v2:
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.
On Wed, Feb 14, 2024 at 09:17:34AM -0800, Abhinav Kumar wrote:
>
>
> On 2/14/2024 12:15 AM, Dmitry Baryshkov wrote:
> > On Wed, 14 Feb 2024 at 01:45, Abhinav Kumar
> > wrote:
> >>
> >> intel_dp_vsc_sdp_pack() can be re-used by other DRM drivers as well.
> >> Lets move this to drm_dp_helper to
On 2/8/2024 6:50 AM, 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.
To allow us to identify the DPU block that gets stuck, include the
actual CTL_FLUSH value into the timeout
On Mon, 12 Feb 2024 11:40:55 +
Steven Price wrote:
> On 22/01/2024 16:30, Boris Brezillon wrote:
> > Tiler heap growing requires some kernel driver involvement: when the
> > tiler runs out of heap memory, it will raise an exception which is
> > either directly handled by the firmware if some
On 2/14/2024 12:15 AM, Dmitry Baryshkov wrote:
On Wed, 14 Feb 2024 at 01:45, Abhinav Kumar wrote:
intel_dp_vsc_sdp_pack() can be re-used by other DRM drivers as well.
Lets move this to drm_dp_helper to achieve this.
Signed-off-by: Abhinav Kumar
My preference would be to have packing
Le 14/02/2024 à 16:10, Steven Rostedt a écrit :
On Wed, 14 Feb 2024 13:00:16 +0100
Christian König wrote:
+DEFINE_EVENT(dma_fence_from, dma_fence_sync_to,
For a single event you should probably use TRACE_EVENT() instead of
declaring a class. A class is only used if you have multiple events
On 22/01/2024 16:30, Boris Brezillon wrote:
> This is the piece of software interacting with the FW scheduler, and
> taking care of some scheduling aspects when the FW comes short of slots
> scheduling slots. Indeed, the FW only expose a few slots, and the kernel
> has to give all submission
Le 14/02/2024 à 13:09, Christian König a écrit :
Am 13.02.24 um 16:50 schrieb Pierre-Eric Pelloux-Prayer:
amdgpu_cs_ioctl already exists but serves a different
purpose.
amdgpu_cs_ioctl2 marks the beginning of the kernel processing of
the ioctl which is useful for tools to map which events
Am 14.02.24 um 17:38 schrieb Pierre-Eric Pelloux-Prayer:
Le 14/02/2024 à 13:09, Christian König a écrit :
Am 13.02.24 um 16:50 schrieb Pierre-Eric Pelloux-Prayer:
amdgpu_cs_ioctl already exists but serves a different
purpose.
amdgpu_cs_ioctl2 marks the beginning of the kernel processing of
Am 13.02.24 um 09:42 schrieb Thomas Zimmermann:
Resolved the proxy include via , which does not require the
backlight header.
Signed-off-by: Thomas Zimmermann
Acked by Jani via IRC
Acked-by: Jani Nikula
---
drivers/staging/fbtft/fb_ssd1351.c | 2 ++
1 file changed, 2 insertions(+)
Hi Maxime,
Thanks for the quick reply.
On 13/02/24 19:34, Maxime Ripard wrote:
> Hi Devarsh,
>
> On Thu, Feb 08, 2024 at 06:26:17PM +0530, Devarsh Thakkar wrote:
>> Hi Maxime,
>>
>> Thanks a lot for checking on this.
>>
>> On 26/01/24 17:45, Maxime Ripard wrote:
>>> Hi,
>>>
>>> Thanks a lot for
On 2/13/24 21:11, Mina Almasry wrote:
On Tue, Feb 13, 2024 at 5:28 AM Pavel Begunkov wrote:
...
A bit of a churn with the padding and nesting net_iov but looks
sturdier. No duplication, and you can just check positions of the
structure instead of per-field NET_IOV_ASSERT_OFFSET, which you
On Wed, 14 Feb 2024 13:00:16 +0100
Christian König wrote:
> > +DEFINE_EVENT(dma_fence_from, dma_fence_sync_to,
>
> For a single event you should probably use TRACE_EVENT() instead of
> declaring a class. A class is only used if you have multiple events with
> the same parameters.
FYI,
On Wed, 14 Feb 2024 at 00:11, Abhinav Kumar wrote:
>
>
>
> On 2/13/2024 1:16 PM, Dmitry Baryshkov wrote:
> > On Tue, 13 Feb 2024 at 23:10, Abhinav Kumar
> > wrote:
> >>
> >>
> >>
> >> On 2/13/2024 11:31 AM, Dmitry Baryshkov wrote:
> >>> On Tue, 13 Feb 2024 at 20:46, Abhinav Kumar
> >>> wrote:
On 14/02/2024 10:30, Helen Koike wrote:
On 14/02/2024 05:37, Dmitry Baryshkov wrote:
If the ADV7511 bridge driver is compiled as a module, while DRM_MSM is
built-in, the clk_disable_unused congests with the runtime PM handling
of the DSI PHY for the clk_prepare_lock(). This causes apq8016
On 10/02/2024 15:20, Maíra Canal wrote:
On 2/10/24 15:17, Maíra Canal wrote:
On 1/30/24 12:03, Vignesh Raman wrote:
Uprev IGT and add amd, v3d, vc4 and vgem specific
tests to testlist. Have testlist.txt per driver
and include a base testlist so that the driver
specific tests will run only
Hi Adrián,
On 14/02/2024 12:14, Adrián Larumbe wrote:
> A driver user expressed interest in being able to access engine usage stats
> through fdinfo when debugfs is not built into their kernel. In the current
> implementation, this wasn't possible, because it was assumed even for
> inflight jobs
On Tue, Feb 13, 2024 at 10:00:13AM -0800, Abhinav Kumar wrote:
> I do agree that pm runtime eDP driver got merged that time but I think
> the issue is either a combination of that along with DRM aux bridge
> https://patchwork.freedesktop.org/series/122584/ OR just the latter as
> even that
Hi Raphael
On 2/5/24 10:06, Raphael Gallais-Pou wrote:
This serie aims to enable display support for the stm32mp135f-dk board
Those are only patches of the device-tree since the driver support has
already been added [1].
It respectivelly:
- adds support for the display controller on
On 14/02/2024 05:37, Dmitry Baryshkov wrote:
If the ADV7511 bridge driver is compiled as a module, while DRM_MSM is
built-in, the clk_disable_unused congests with the runtime PM handling
of the DSI PHY for the clk_prepare_lock(). This causes apq8016 runner to
fail without completing any jobs
From: Matthew Auld
Sanity check DRM_BUDDY_CONTIGUOUS_ALLOCATION.
v2: Fix checkpatch warnings.
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3097
Signed-off-by: Matthew Auld
Cc: Arunpravin Paneer Selvam
Cc: Limonciello
Cc: Christian König
Reviewed-by: Arunpravin Paneer Selvam
Few users have observed display corruption when they boot
the machine to KDE Plasma or playing games. We have root
caused the problem that whenever alloc_range() couldn't
find the required memory blocks the function was returning
SUCCESS in some of the corner cases.
The right approach would be if
On 13.02.24 19:00, Abhinav Kumar wrote:
>
> Thanks for the report.
>
> I do agree that pm runtime eDP driver got merged that time but I think
> the issue is either a combination of that along with DRM aux bridge
> https://patchwork.freedesktop.org/series/122584/ OR just the latter as
> even that
1 - 100 of 146 matches
Mail list logo
