The dpu_crtc_atomic_check() compares blending stage with DPU_STAGE_MAX
(maximum amount of blending stages supported by the driver), however we
should compare it against .max_mixer_blendstages, the maximum blend
stage supported by the mixer.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry
The helper drm_atomic_helper_check_plane_state() already checks whether
the scaled and clipped plane falls into the CRTC visible region (and
clears plane_state->visible if it doesn't). Drop the redundant check
from dpu_crtc_atomic_check().
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry
In preparation to adding fully virtualized planes, move struct
dpu_hw_sspp instance from struct dpu_plane to struct dpu_plane_state, as
it will become a part of state (variable, changes during runtime) rather
than part of a plane (ideally should be statically allocated during boot).
The sspp
Typically SSPP can support rectangle with width up to 2560. However it's
possible to use multirect feature and split source to use the SSPP to
output two consecutive rectangles. This commit brings in this capability
to support wider screen resolutions.
Signed-off-by: Dmitry Baryshkov
---
From: Abhinav Kumar
After cleaning up the older multirect support the function
dpu_plane_validate_multirect_v2() is unused. Lets remove it.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 111 --
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 7
Enable SmartDMA features for the rest of the platforms where it is
supposed to work.
Signed-off-by: Dmitry Baryshkov
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 54 ---
1 file changed, 23 insertions(+), 31 deletions(-)
diff --git
Rework the code flushing CSC settings for the plane. Separate out the
pipe and pipe_cfg as a preparation for r_pipe support.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 47 +--
1 file changed, 27 insertions(+),
The code doesn't use dpu_caps::smart_dma_rev field. It checks if the
corresponding feature is enabled in the SSPP features. Drop the
smart_dma_rev field completely.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 13 -
Downstream driver uses dpu->caps->smart_dma_rev to update
sspp->cap->features with the bit corresponding to the supported SmartDMA
version. Upstream driver does not do this, resulting in SSPP subdriver
not enabling setup_multirect callback. Add corresponding SmartDMA SSPP
feature bits to dpu hw
Neither source split nor multirect are properly supported at this
moment. Both of these checks depend on normalized_zpos being equal for
several planes (which is never the case for normalized zpos).
Drop these checks to simplify dpu_crtc_atomic_check(). The actual
support for either of these
There is no need to pass full dpu_hw_sspp_cfg instance to
_dpu_hw_sspp_setup_scaler3, pass just struct dpu_format pointer.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 9 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h | 9
Move plane state updates from dpu_crtc_atomic_check() to the function
where they belong: to dpu_plane_atomic_check().
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 18 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 18 ++
Rework _dpu_crtc_blend_setup_mixer() to split away pipe handling to a
separate functon. This is a preparation for the r_pipe support.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 79 +++-
1 file changed, 50 insertions(+), 29 deletions(-)
Split pipe-dependent code from dpu_plane_sspp_atomic_update() into the
separate function dpu_plane_sspp_update_pipe(). This is one of
preparational steps to add r_pipe support.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 113 --
1 file
Split pipe-dependent code from dpu_plane_atomic_check() into the
separate function dpu_plane_atomic_check_pipe(). This is one of
preparational steps to add r_pipe support.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 90 ++-
1 file changed,
Now as all accesses to pipe_cfg and pstate have been cleaned, add
struct dpu_hw_sspp_cfg to struct dpu_plane_state, so that
dpu_plane_atomic_check() and dpu_plane_atomic_update() do not have a
chance to disagree about src/dst rectangles (currently
dpu_plane_atomic_check() uses unclipped
Remove dpu_hw_fmt_layout instance from struct dpu_hw_sspp_cfg, leaving
only src_rect and dst_rect. This way all the pipes used by the plane
will have a common layout instance (as the framebuffer is shared between
them), while still keeping a separate src/dst rectangle configuration
for each pipe.
The pipe's layout is not cached, corresponding data structure is zeroed
out each time in the dpu_plane_sspp_atomic_update(), right before the
call to _dpu_plane_set_scanout() -> dpu_format_populate_layout().
Drop plane_addr comparison against previous layout and corresponding
EAGAIN handling.
Wrap SSPP and multirect index/mode into a single structure that
represents software view on the pipe used.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c| 9 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h | 16 ++-
For all hardware blocks except SSPP the corresponding struct is named
after the block. Rename dpu_hw_pipe (SSPP structure) to dpu_hw_sspp.
Also rename struct dpu_hw_pipe_cfg to dpu_hw_sspp_cfg to follow this
change.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
Set SSPP_SRCn_ADDR registers to 0 while setting up solid fill, as we can
not be sure that the previous address is still valid.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 5 +
1 file changed, 5 insertions(+)
diff --git
As struct dpu_hw_sspp_cfg describes only the source and destination
rectangles, it is a software pipe configuration now. Rename it
accordingly.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h | 6 +++---
Where feasible, use dpu_sw_pipe rather than a combo of dpu_hw_sspp and
multirect_index/_mode arguments.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 59 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h | 46
There no more need for the dpu_plane_pipe() function, crtc code can
access pstate->pipe_hw.idx directly.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 4 ++--
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 5 -
Move stride programming to dpu_hw_sspp_setup_sourceaddress(), so that
dpu_hw_sspp_setup_rects() programs only source and destination
rectangles.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 57 +++--
1 file
[AMD Official Use Only - General]
Series is acked-by: Evan Quan
> -Original Message-
> From: amd-gfx On Behalf Of
> Guchun Chen
> Sent: Friday, March 10, 2023 9:02 AM
> To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> Deucher, Alexander ; Zhang, Hawking
> ;
Hi Dave, Daniel,
Fixes for 6.3. Same pull as yesterday, but drop the KFD patch that
caused a regression.
The following changes since commit 66305069eb6d17d9190cbcd196f3f7487df47ae8:
Merge tag 'drm-misc-fixes-2023-02-23' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
>
> From: Sean Paul
>
> This patch moves the hdcp atomic check from i915 to drm_hdcp so other
> drivers can use it. No functional changes, just cleaned up some of the code
> when moving it over.
>
> Acked-by: Jani Nikula
> Acked-by: Jani Nikula
> Reviewed-by: Rodrigo Vivi
> Reviewed-by:
On 10/03/2023 05.39, Karol Herbst wrote:
> On Thu, Mar 9, 2023 at 9:24 PM Faith Ekstrand
> wrote:
>>
>> On Thu, 2023-03-09 at 15:04 +0900, Asahi Lina wrote:
>>> On 08/03/2023 02.34, Björn Roy Baron wrote:
> +// SAFETY: This is just the ioctl
> argument, which
After commit 3fb16866b51d ("driver core: fw_devlink: Make cycle
detection more robust"), fw_devlink prints an error when consumer
devices don't have their fwnode set. This used to be ignored silently.
Set the fwnode mipi_dsi_device so fw_devlink can find them and properly
track their
The returned array size for input formats is set through
atomic_get_input_bus_fmts()'s 'num_input_fmts' argument, so use
'num_input_fmts' to represent the array size in the function's kdoc,
not 'num_output_fmts'.
Fixes: ("91ea83306bfa drm/bridge: Fix the bridge kernel doc")
Fixes: ("f32df58acc68
During reboot test on arm64 platform, it may failure
on boot.
The error message are as follows:
[6.996395][ 7] [ T295] [drm:amdgpu_device_ip_late_init [amdgpu]] *ERROR*
late_init of IP block failed -22
[7.006919][ 7] [ T295] amdgpu :04:00.0:
During reboot test on arm64 platform, it may failure
on boot.
The error message are as follows:
[6.996395][ 7] [ T295] [drm:amdgpu_device_ip_late_init [amdgpu]] *ERROR*
late_init of IP block failed -22
[7.006919][ 7] [ T295] amdgpu :04:00.0:
> -Original Message-
> From: Intel-gfx On Behalf Of Mark
> Yacoub
> Sent: Thursday, January 19, 2023 1:00 AM
> To: quic_khs...@quicinc.com; linux-arm-...@vger.kernel.org; dri-
> de...@lists.freedesktop.org; freedr...@lists.freedesktop.org;
> devicet...@vger.kernel.org;
Hi Linus,
Weekly fixes, msm and amdgpu are the vast majority of these, otherwise
some straggler misc from last week for nouveau and cirrus and a
mailmap update for a drm developer.
Regards,
Dave.
drm-fixes-2023-03-10:
drm fixes for 6.3-rc2
mailmap
- add an entry
nouveau:
- fix system shutdown
Expose intel_rps_read_actual_frequency_fw to read the actual freq without
taking forcewake for use by PMU. The code is refactored to use a common set
of functions across sysfs and PMU. Using common functions with sysfs in PMU
solves the issues of missing support for MTL and missing support for
Expose intel_rps_read_actual_frequency_fw to read the actual freq without
taking forcewake for use by PMU. The code is refactored to use a common set
of functions across sysfs and PMU. Using common functions with sysfs in PMU
solves the issues of missing support for MTL and missing support for
The fallback to requested freq does not work for SLPC because SLPC does not
use 'struct intel_rps'. Also for SLPC requested freq can only be obtained
from a hw register after acquiring forcewake which we don't want to do for
PMU. Therefore remove fallback to requested freq for SLPC. The actual
Some amd asics having reliable hotplug support don't call
drm_kms_helper_poll_init in driver init sequence. However,
due to the unified suspend/resume path for all asics, because
the output_poll_work->func is not set for these asics, a warning
arrives when suspending.
[ 90.656049]
[
On 3/9/2023 11:32 AM, Alex Deucher wrote:
Caution: This message originated from an External Source. Use proper caution
when opening attachments, clicking links, or responding.
On Thu, Mar 9, 2023 at 12:16 PM Felix Kuehling wrote:
Am 2023-03-08 um 23:38 schrieb Alex Deucher:
Hi Dave,
On Thu, Mar 9, 2023 at 11:03 AM Pekka Paalanen wrote:
>
> On Thu, 9 Mar 2023 01:56:11 +0100
> Sebastian Wick wrote:
>
> > On Wed, Mar 8, 2023 at 9:59 AM Pekka Paalanen wrote:
> > >
> > > On Tue, 7 Mar 2023 10:10:52 -0500
> > > Harry Wentland wrote:
> > >
> > > > From: Joshua Ashton
> > > >
>
On Thu, 2023-03-09 at 15:04 +0900, Asahi Lina wrote:
> On 08/03/2023 02.34, Björn Roy Baron wrote:
> > > + // SAFETY: This is just the ioctl
> > > argument, which hopefully has the right type
> > > + // (we've done our best checking the
> > >
On 3/7/23 18:50, Javier Martinez Canillas wrote:
There are DRM fourcc formats that have pixels smaller than a byte, but the
conversion_buf_size() function assumes that pixels are a multiple of bytes
and use the struct drm_format_info .cpp field to calculate the dst_pitch.
Instead, calculate it
On Thu, Mar 9, 2023 at 12:16 PM Felix Kuehling wrote:
>
>
> Am 2023-03-08 um 23:38 schrieb Alex Deucher:
> > Hi Dave, Daniel,
> >
> > Fixes for 6.3.
> >
> > The following changes since commit 66305069eb6d17d9190cbcd196f3f7487df47ae8:
> >
> >Merge tag 'drm-misc-fixes-2023-02-23' of
> >
Hi,
On 07/03/23 18:50, Javier Martinez Canillas wrote:
> There are DRM fourcc formats that have pixels smaller than a byte, but the
> conversion_buf_size() function assumes that pixels are a multiple of bytes
> and use the struct drm_format_info .cpp field to calculate the dst_pitch.
>
>
Add the ability for the Mediatek DRM driver to control the bit depth register.
If the DTS indicates the device supports 10-bit overlays and the current format
has a fourcc of AR30, BA30, or RA30, we set the bit depth register to 10 bit.
The next patch in the series actually enables 10-bit
On Thu, Mar 9, 2023 at 4:24 PM Marek Szyprowski
wrote:
>
> devm_regulator_get_enable_optional() returns -ENODEV if requested
> optional regulator is not present. Adjust code for that, because in the
> 67d0a30128c9 I've incorrectly assumed that it also returns 0 when
> regulator is not present.
>
On 10/03/2023 06.16, Faith Ekstrand wrote:
> On Tue, 2023-03-07 at 23:25 +0900, Asahi Lina wrote:
>> A DRM File is the DRM counterpart to a kernel file structure,
>> representing an open DRM file descriptor. Add a Rust abstraction to
>> allow drivers to implement their own File types that
On Tue, 2023-03-07 at 23:25 +0900, Asahi Lina wrote:
> A DRM File is the DRM counterpart to a kernel file structure,
> representing an open DRM file descriptor. Add a Rust abstraction to
> allow drivers to implement their own File types that implement the
> DriverFile trait.
>
> Signed-off-by:
[...]
= of_graph_get_remote_node(dsi->dev.of_node, 1, -1);
> + if (!dsi1) {
> + dev_err(dev, "cannot get secondary DSI node.\n");
> + return -ENODEV;
> + }
> +
> + dsi1_host = of_find_mipi_dsi_host_by_node(dsi1);
Follow the example of all other hw blocks and initialize SSPP blocks in
Resource Manager.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 17 -
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c| 22 ++
As SSPP blocks are now visible through dpu_kms->rm.sspp_blocks, move
SSPP debugfs creation from dpu_plane to dpu_kms. We are going to break
the 1:1 correspondence between planes and SSPPs, so it makes no sense
anymore to create SSPP debugfs entries in dpu_plane.c
Reviewed-by: Abhinav Kumar
This patchset brings in multirect usage to support using two SSPP
rectangles for a single plane. Full virtual planes support is omitted
from this pull request, it will come later.
Changes since v4:
- Incorporate two fixes and two cleanup patches from Abhinav
Changes since v3:
- moved if
Add the ability for the Mediatek DRM driver to control the bit depth register.
If the DTS indicates the device supports 10-bit overlays and the current format
has a fourcc of AR30, BA30, or RA30, we set the bit depth register to 10 bit.
The next patch in the series actually enables 10-bit
Add an DDP component interface for querying pixel format support and move list
of supported pixel formats into DDP components instead of mtk_drm_plane.c
Tested by running Chrome on an MT8195.
Signed-off-by: Justin Green
---
drivers/gpu/drm/mediatek/mtk_disp_drv.h | 4 ++
This patch series adds support for 10-bit overlays to the Mediatek DRM driver.
Specifically, we add support for AR30 and BA30 overlays on MT8195 devices and
lay the groundwork for supporting more 10-bit formats on more devices.
1. Refactor plane initialization logic to allow individual DDP
Modify the overlay driver data for MT8195 to enable bit depth control and
enable support for AR30 and BA30 framebuffer formats. This patch in
combination with the previous two patches in the series will allow MT8195
devices to scanout AR30 and BA30 framebuffers.
Tested using "modetest -P" on an
Hi Chun-Kuang,
Thanks for the review! This patch was tested like the previous one, by
running Chrome on an MT8195 and looking for regressions. I'll post a
new series with the updated patch descriptions.
Regards,
Justin
On Wed, Mar 8, 2023 at 6:34 PM Chun-Kuang Hu wrote:
>
> Hi, Justin:
>
>
On 10/03/2023 00:20, Jordan Crouse wrote:
While booting with amd,imageon on a headless target the GPU probe was
failing with -ENOSPC in get_pages() from msm_gem.c.
Investigation showed that the driver was using the default 16MB VRAM
carveout because msm_use_mmu() was returning false since
dpu_plane_atomic_check() checks for the format to make sure its
not YUV before using multirect.
However the format is not initialized before this. This causes
a compilation issue and also would not work if YUV content
is tried.
Fix it by setting the format before the check.
Signed-off-by:
Lets print the multirect_index as well in _dpu_crtc_blend_setup_pipe()
as it will give the complete information of the sw_pipe as well.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git
_dpu_crtc_blend_setup_mixer() should call _dpu_crtc_blend_setup_pipe()
to stage the rectangles of the sspp for both the left and right
halves.
However, it incorrectly invokes it only for the left half causing
basic wide planes to not work and only half the screen is shown
on the display.
This
After cleaning up the older multirect support the function
dpu_plane_validate_multirect_v2() is unused. Lets remove it.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 111 --
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 7 --
2 files
While validating the DPU wide planes series [1], some issues were seen
so decided to send this out in a separate series.
Changes include compilation fixes, critical bug fixes and cleanups.
These can easily be absorbed into that series as well but for the sake
of having a clean series and also to
Jumping in here quick... (Sorry, I was out yesterday and was ignoring
my e-mail on Tuesday so I could finally type some compiler code.)
On Thu, 2023-03-09 at 18:14 +0900, Asahi Lina wrote:
> On 09/03/2023 17.05, Christian König wrote:
> > Am 09.03.23 um 07:30 schrieb Asahi Lina:
> > > On
On Thu, 2023-03-09 at 18:43 +0900, Asahi Lina wrote:
> On 09/03/2023 17.42, Christian König wrote:
> > Am 08.03.23 um 20:37 schrieb Asahi Lina:
> > > On 09/03/2023 03.12, Christian König wrote:
> > > > Am 08.03.23 um 18:32 schrieb Asahi Lina:
> > > > > [SNIP]
> > > > > Yes but... none of this
On Thu, Mar 9, 2023 at 9:24 PM Faith Ekstrand
wrote:
>
> On Thu, 2023-03-09 at 15:04 +0900, Asahi Lina wrote:
> > On 08/03/2023 02.34, Björn Roy Baron wrote:
> > > > +// SAFETY: This is just the ioctl
> > > > argument, which hopefully has the right type
> > > > +
We should be checking if drm_dp_dpcd_read() returns the size that we are
asking it to read instead of just checking if it is greater than zero.
Also, we should WARN_ON() here since this condition is only ever met, if
there is an issue worth investigating. So, compare the return value of
Hi Nirmoy,
On Thu, Mar 09, 2023 at 05:49:05PM +0100, Nirmoy Das wrote:
> Stolen memory is not usable for MTL A0 stepping beyond
> certain access size and we have no control over userspace
> access size of /dev/fb which can be backed by stolen memory.
> So disable stolen memory backed fb by
From: Abhinav Kumar
Lets print the multirect_index as well in _dpu_crtc_blend_setup_pipe()
as it will give the complete information of the sw_pipe as well.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
Rework bandwidth/clock calculation functions to use mode directly rather
than fetching it through the plane data.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 39 ++-
1 file changed, 17 insertions(+), 22
The plane's clipped coordinates has already been validated against FB
size in the drm_atomic_plane_check(). There is no need to check them
again. Remove corresponding checks and inline dpu_plane_validate_src().
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 30
Rework static color fill code to separate the pipe / pipe_cfg handling.
This is a preparation for the r_pipe support.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 69 +--
1 file changed, 40 insertions(+), 29 deletions(-)
diff --git
Rewrite dpu_plane's QoS related functions to take struct dpu_sw_pipe and
struct dpu_format as arguments rather than fetching them from the
pstate or drm_framebuffer.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 98
Am 2023-03-08 um 16:37 schrieb Chia-I Wu:
kgd_mem should be accessed with p->mutex locked, or it could have been
freed by kfd_ioctl_free_memory_of_gpu.
Thank you for the patch. It's not just about accessing kgd_mem with
p->mutex held. It's also about holding the mutex continuously. I'd
Hi Dave,
A few fixes for v6.3. Summary below. There is a back-merge of
last-cycles -fixes to avoid a merge conflict in commit 6153c44392b0
("drm/msm/adreno: fix runtime PM imbalance at unbind")
The following changes since commit 92dd0575729a423aa5524d89055e34295152a2dd:
Merge tag
On 2/24/23 19:14, Uwe Kleine-König wrote:
A remove callback just returning 0 is equivalent to no remove callback
at all. So drop the useless function.
Signed-off-by: Uwe Kleine-König
Applied to drm-misc-next.
Best Regards,
- Maíra Canal
---
Hello,
the remove function was introduced in
Hi Johan,
thanks for your patch!
On Mon, Mar 6, 2023 at 11:35 AM Johan Hovold wrote:
[...]
> @@ -325,23 +325,23 @@ static int meson_drv_bind_master(struct device *dev,
> bool has_components)
>
> ret = meson_encoder_hdmi_init(priv);
I'm wondering if component_bind_all() can be moved
This driver uses a single GEM object even when there are multiple
planes. Starting with commit 746b9c62cc86 ("drm/gem: Ignore color planes
that are unused by framebuffer format"), multiple plane support was
broken on armada because the object pointers for the additional planes
were empty and
On Thu, 09 Mar 2023 01:20:09 -0800, Tvrtko Ursulin wrote:
>
Hi Tvrtko,
> On 09/03/2023 03:46, Ashutosh Dixit wrote:
> > Expose intel_rps_read_actual_frequency_fw to read the actual freq without
> > taking forcewake for use by PMU. The code is refactored to use a common set
> > of functions
In order to catch issues in other drivers to ensure proper call
sequence of polling function.
v2: drop Fixes tag in commit message
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2411
Reported-by: Bert Karwatzki
Suggested-by: Dmitry Baryshkov
Signed-off-by: Guchun Chen
---
The item which have the mediatek,mt8192-disp-ccorr as const compatible
already exist above. Merge all compatibles which have the same fallback
under the same item.
Acked-by: Krzysztof Kozlowski
Reviewed-by: AngeloGioacchino Del Regno
Reviewed-by: Rob Herring
Signed-off-by: Alexandre Mergnat
The first QMP PHY is an USB3/DP combo phy, switch to the newly
documented bindings and register the clocks to the GCC
and DISPCC controllers.
Reviewed-by: Dmitry Baryshkov
Tested-by: Dmitry Baryshkov #SM8350-HDK
Signed-off-by: Neil Armstrong
---
arch/arm64/boot/dts/qcom/sm8350.dtsi | 42
Add the Display Port controller subnode to the MDSS node.
Tested-by: Dmitry Baryshkov #SM8350-HDK
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Neil Armstrong
---
arch/arm64/boot/dts/qcom/sm8350.dtsi | 79
1 file changed, 79 insertions(+)
diff --git
The SM8450 & SM350 shares the same DT TX IP version, use the
SM8350 compatible as fallback for SM8450.
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Neil Armstrong
---
.../bindings/display/msm/dp-controller.yaml| 25 +-
1 file changed, 15 insertions(+), 10
The QMP PHY is a USB3/DP combo phy, switch to the newly
documented bindings and register the clocks to the GCC
and DISPCC controllers.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Neil Armstrong
---
arch/arm64/boot/dts/qcom/sm8450.dtsi | 42 +---
1 file changed,
Add the Display Port controller subnode to the MDSS node.
Signed-off-by: Neil Armstrong
---
arch/arm64/boot/dts/qcom/sm8450.dtsi | 79
1 file changed, 79 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8450.dtsi
b/arch/arm64/boot/dts/qcom/sm8450.dtsi
On 09.03.2023 10:43, Tvrtko Ursulin wrote:
On 09/03/2023 09:34, Andrzej Hajda wrote:
On 09.03.2023 10:08, Tvrtko Ursulin wrote:
On 08/03/2023 15:39, Andrzej Hajda wrote:
Write-combining memory allows speculative reads by CPU.
ggtt->error_capture is WC mapped to CPU, so CPU/MMU can try
Thomas Zimmermann writes:
> Implement fbdev emulation that is optimized for drivers that use
> DMA helpers. The buffers may no tbe moveable, may not require damage
"may not be"
Is may the correct verb here though? I guess you meant "shall not".
> handling and have to be located in system
On Mon, 2023-03-06 at 22:58 +0200, Ville Syrjälä wrote:
> On Mon, Mar 06, 2023 at 09:23:50PM +0100, Maarten Lankhorst wrote:
> > Hey,
> >
> > On 2023-03-06 16:23, Souza, Jose wrote:
> > > On Mon, 2023-03-06 at 15:16 +0100, Maarten Lankhorst wrote:
> > > > As a fallback if we decide not to merge
On 2023-03-09 12:04, Hogander, Jouni wrote:
On Mon, 2023-03-06 at 22:58 +0200, Ville Syrjälä wrote:
On Mon, Mar 06, 2023 at 09:23:50PM +0100, Maarten Lankhorst wrote:
Hey,
On 2023-03-06 16:23, Souza, Jose wrote:
On Mon, 2023-03-06 at 15:16 +0100, Maarten Lankhorst wrote:
As a fallback if
Am 09.03.23 um 08:06 schrieb Thomas Hellström:
Hi, Christian,
Thanks for reviewing these.
Ack to merge reviewed patches through drm-misc-next?
Sure.
Christian.
Thanks,
Thomas
On 3/8/23 09:49, Christian König wrote:
Am 07.03.23 um 15:46 schrieb Thomas Hellström:
New code is
Am 08.03.23 um 20:37 schrieb Asahi Lina:
On 09/03/2023 03.12, Christian König wrote:
Am 08.03.23 um 18:32 schrieb Asahi Lina:
[SNIP]
Yes but... none of this cleans up jobs that are already submitted by the
scheduler and in its pending list, with registered completion callbacks,
which were
On 09/03/2023 17.05, Christian König wrote:
> Am 09.03.23 um 07:30 schrieb Asahi Lina:
>> On 09/03/2023 05.14, Christian König wrote:
I think you mean wake_up_interruptible(). That would be
drm_sched_job_done(), on the fence callback when a job completes, which
as I keep saying is
On 08/03/2023 07:40, Uwe Kleine-König wrote:
>The .remove() callback for a platform driver returns an int which makes many
>driver authors wrongly assume it's possible to do error handling by returning
>an error code. However the value returned is (mostly) ignored >and this
>typically results
On 09.03.2023 10:08, Tvrtko Ursulin wrote:
On 08/03/2023 15:39, Andrzej Hajda wrote:
Write-combining memory allows speculative reads by CPU.
ggtt->error_capture is WC mapped to CPU, so CPU/MMU can try
to prefetch memory beyond the error_capture, ie it tries
to read memory pointed by next
Hello there Laurent,
>Would you be able to send a patch to fix this ?
Sadly, no. My success rate with kernel patches is low enough to make it not
worth trying.
Regards
David Binderman
From: Laurent Pinchart
Sent: 09 March 2023 09:26
To: David Binderman
Cc: andrzej.ha...@intel.com ;
Hi Andy,
On Wed, Mar 8, 2023 at 11:31 PM Andy Shevchenko
wrote:
>
> On Wed, Mar 08, 2023 at 09:51:19PM +0800, Pin-yen Lin wrote:
> > On Mon, Mar 6, 2023 at 8:03 PM Andy Shevchenko
> > wrote:
> > > On Fri, Mar 03, 2023 at 10:33:50PM +0800, Pin-yen Lin wrote:
>
> ...
>
> > > > +
Hi,
On 3/9/23 06:14, Zack Rusin wrote:
On Wed, 2023-03-08 at 10:10 +0100, Christian König wrote:
Am 08.03.23 um 06:14 schrieb Zack Rusin:
On Tue, 2023-02-28 at 09:34 +0100, Christian König wrote:
VMWGFX is the only remaining user of this and should probably moved over
to drm_exec when it
On 09/03/2023 07:48, Guchun Chen wrote:
In order to catch issues in other drivers to ensure proper call
sequence of polling function.
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2411
Fixes: a4e771729a51("drm/probe_helper: sort out poll_running vs poll_enabled")
Previously it was
1 - 100 of 321 matches
Mail list logo
