Mostly code refactoring and cleanup.
Please note that FW API headers are maintained by a separate team
and I would prefer not to modify them.
Jacek Lawrynowicz (5):
accel/ivpu: Rename TILE_SKU_BOTH_MTL to TILE_SKU_BOTH
accel/ivpu: Remove legacy firmware name
accel/ivpu: Update FW API header
We are now using NPU IP generation based FW names instead of platform
code names, so mtl_vpu.bin can be removed.
Signed-off-by: Jacek Lawrynowicz
---
drivers/accel/ivpu/ivpu_fw.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/accel/ivpu/ivpu_fw.c b/drivers/accel/ivpu/ivpu_fw.c
inde
From: "Wachowski, Karol"
Reserve/allocate and free doorbells for command queues when needed
using xarray. This allows to avoid reserving a doorbell for
a contexts that never issues a job.
Signed-off-by: Wachowski, Karol
---
drivers/accel/ivpu/ivpu_drv.c | 4
drivers/accel/ivpu/ivpu_drv.h
Update Boot API to 3.22.0 and JSM API to 3.15.6
Signed-off-by: Jacek Lawrynowicz
---
drivers/accel/ivpu/vpu_boot_api.h | 46 ++-
drivers/accel/ivpu/vpu_jsm_api.h | 32 ++---
2 files changed, 55 insertions(+), 23 deletions(-)
diff --git a/drivers/acce
Remove legacy postfix from TILE_SKU_BOTH macro.
This was missed when renaming MTL to VPU37XX.
Signed-off-by: Jacek Lawrynowicz
---
drivers/accel/ivpu/ivpu_hw_37xx.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/accel/ivpu/ivpu_hw_37xx.c
b/drivers/accel/ivpu/ivp
ivpu_reset_engine_fn and ivpu_reset_engine_fops were separated during
merge so move them back together to keep the file consistent.
Signed-off-by: Jacek Lawrynowicz
---
drivers/accel/ivpu/ivpu_debugfs.c | 32 +++
1 file changed, 16 insertions(+), 16 deletions(-)
diff
From: Krystian Pradzynski
Add support for FW boot API param system_time_us.
According to the API description this field should
be set to system time in microseconds starting from 1970.
Signed-off-by: Krystian Pradzynski
---
drivers/accel/ivpu/ivpu_fw.c | 6 ++
1 file changed, 6 insertions(
From: "Wachowski, Karol"
Rename BO allocate/create functions, so the code is more consistent.
There are now two matching buffer creation functions:
- ivpu_bo_create_ioctl() - create a BO from user space
- ivpu_bo_create() - create a BO from kernel space
ivpu_bo_alloc() is now only used to al
VPU was renamed to NPU but due to large overhead of renaming
all the sources only user visible messages are being updated.
Signed-off-by: Jacek Lawrynowicz
---
drivers/accel/ivpu/ivpu_drv.c | 8
drivers/accel/ivpu/ivpu_drv.h | 2 +-
drivers/accel/ivpu/ivpu_fw.c | 2 +-
d
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 functions in
drivers/video/hdmi.c, as we already
Am 13.02.24 um 23:42 schrieb Randy Dunlap:
Correct a spello/typo in comments.
Signed-off-by: Randy Dunlap
Cc: Thomas Zimmermann
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Thomas Zimmermann
Thanks. I'll add the patch to our tree.
---
v2: don't change "set up" to "setup" (Thomas)
Am 13.02.24 um 18:37 schrieb Danilo Krummrich:
Hi Christian,
What's the status of this effort? Was there ever a follow-up?
It's unfortunately on hold for the moment since I have to look into some
internal things with highest priority. No idea when this will calm down
again.
Christian.
-
Dmitry Baryshkov writes:
Hello Dmitry,
> 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 (
Am 13.02.24 um 07:17 schrieb Randy Dunlap:
Fix some typos and punctuation.
Signed-off-by: Randy Dunlap
Cc: Alex Deucher
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Reviewed-by: Thomas Zimmermann
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 ([1]). Drop the BM_CMDLINE which
duplicate the comm
On Tue Feb 13, 2024 at 3:44 PM CET, Ricardo B. Marliere wrote:
> Since commit d492cc2573a0 ("driver core: device.h: make struct
> bus_type a const *"), the driver core can properly handle constant
> struct bus_type, move the host1x_bus_type variable to be a constant
> structure as well, placing it
On Wed, 14 Feb 2024 07:28:37 +
"Shankar, Uma" wrote:
> > -Original Message-
> > From: dri-devel On Behalf Of Pekka
> > Paalanen
> > Sent: Tuesday, February 13, 2024 3:07 PM
> > To: Shankar, Uma
> > Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> > ville.syrj.
Hi,
On 15/01/2024 14:57, Devarsh Thakkar wrote:
TI keystone display subsystem present in AM65 and other SoCs such as AM62
support two separate register spaces namely "common" and "common1" which
can be used by two separate hosts to program the display controller as
described in respective Techni
On 14/02/2024 11:10, Tomi Valkeinen wrote:
Hi,
On 15/01/2024 14:57, Devarsh Thakkar wrote:
TI keystone display subsystem present in AM65 and other SoCs such as AM62
support two separate register spaces namely "common" and "common1" which
can be used by two separate hosts to program the display
On Mon Jan 22, 2024 at 12:27 PM CET, Luca Weiss wrote:
> On Fri Jan 12, 2024 at 11:26 AM CET, wrote:
> > On 12/01/2024 11:23, Linus Walleij wrote:
> > > On Fri, Jan 12, 2024 at 10:52 AM Luca Weiss
> > > wrote:
> > >
> > >> Since there's zero indication Truly is involved in this panel in my
> >
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
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 10 +-
1 file changed, 5 insertio
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.
Acked-by: Douglas Anderson
Signed-off-by: Uwe Kleine-König
---
drivers/gpu/
Hello,
this is v6 of the series introducing better lifetime tracking for
pwmchips that addresses (for now theoretic) lifetime issues of pwm
chips. Addressing these is a necessary precondition to introduce chardev
support for PWMs.
Locking got more complicated due to non-sleeping chips, so I dropp
On Tue, Feb 13, 2024 at 04:40:19PM +0200, Jani Nikula wrote:
> On Tue, 13 Feb 2024, Maxime Ripard wrote:
> > On Mon, Feb 12, 2024 at 12:53:05PM +0200, Jani Nikula wrote:
> >> On Mon, 12 Feb 2024, Thomas Hellström
> >> wrote:
> >> > The indicated commit below added a device argument to the
> >> >
On 14/02/2024 10:33, Luca Weiss wrote:
On Mon Jan 22, 2024 at 12:27 PM CET, Luca Weiss wrote:
On Fri Jan 12, 2024 at 11:26 AM CET, wrote:
On 12/01/2024 11:23, Linus Walleij wrote:
On Fri, Jan 12, 2024 at 10:52 AM Luca Weiss wrote:
Since there's zero indication Truly is involved in this pan
Hi,
On Tue, 2024-02-13 at 10:56 +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> clang-16 warns about a cast between incompatible function types:
>
> drivers/gpu/drm/xe/xe_range_fence.c:155:10: error: cast from 'void
> (*)(const void *)' to 'void (*)(struct xe_range_fence *)' converts to
>
On Wed, Feb 14, 2024, at 11:10, Thomas Hellström wrote:
> On Tue, 2024-02-13 at 10:56 +0100, Arnd Bergmann wrote:
>>
>> +static void xe_range_fence_free(struct xe_range_fence * rfence)
>
> There's a checkpatch.pl style error above: s/* rfence/*rfence/. I can
> fix that up when pushing if it's ok
Hi Heiko
On 1/31/24 16:53, Conor Dooley wrote:
On Wed, Jan 31, 2024 at 10:28:44AM +0100, Dario Binacchi wrote:
Allow 'port' property (coming from panel-common.yaml) to be used in DTS:
st/stm32f769-disco-mb1166-reva09.dtb: panel@0: 'port' does not match any of
the regexes: 'pinctrl-[0-9]+'
On Wed, 07 Feb 2024, Jani Nikula wrote:
> Hi Dave & Sima -
>
> drm-intel-next-2024-02-07:
> drm/i915 feature pull for v6.9:
Ping, this hasn't been merged yet.
BR,
Jani.
--
Jani Nikula, Intel
Hi Tomi, Vignesh,
On 14/02/24 14:53, Tomi Valkeinen wrote:
> On 14/02/2024 11:10, Tomi Valkeinen wrote:
>> Hi,
>>
>> On 15/01/2024 14:57, Devarsh Thakkar wrote:
>>> TI keystone display subsystem present in AM65 and other SoCs such as AM62
>>> support two separate register spaces namely "common" an
Many a times images are blurred or upscaled content is also not as
crisp as original rendered image. Traditional sharpening techniques often
apply a uniform level of enhancement across entire image, which sometimes
result in over-sharpening of some areas and potential loss of natural detail
This allows the user to set the intensity
so as to get the sharpness effect.
It is useful in scenario when the output is blurry
and user want to sharpen the pixels.
Signed-off-by: Nemesa Garg
---
drivers/gpu/drm/drm_atomic_uapi.c | 4
drivers/gpu/drm/drm_crtc.c| 17 +++
The strength value should be greater than zero to
set to the scaler flag true and if the second scaler
is free then it can be used for sharpening purpose.
Signed-off-by: Nemesa Garg
---
drivers/gpu/drm/i915/display/intel_display.c | 7 +-
.../drm/i915/display/intel_display_types.h| 1 +
.
Scaler coefficient values are based on experiments
and vary for different tap value/win size. These values
are normalized by taking the sum of all values and then
dividing each value with a sum.
Signed-off-by: Nemesa Garg
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm
Add new registers and related bits. Compute the strength
value and tap value based on display mode.
Signed-off-by: Nemesa Garg
---
.../drm/i915/display/intel_display_types.h| 1 +
.../drm/i915/display/intel_sharpen_filter.c | 84 +++
.../drm/i915/display/intel_sharpen_filt
Load the lut values during pipe enable.
Signed-off-by: Nemesa Garg
---
drivers/gpu/drm/i915/display/intel_crtc.c| 3 +++
drivers/gpu/drm/i915/display/intel_display.c | 12 +++-
drivers/gpu/drm/i915/display/skl_scaler.c| 11 ++-
3 files changed, 24 insertions(+), 2 deleti
Am 13.02.24 um 16:50 schrieb Pierre-Eric Pelloux-Prayer:
This new event can be used to trace where a given dma_fence is added
as a dependency of some other work.
I plan to use it in amdgpu.
Signed-off-by: Pierre-Eric Pelloux-Prayer
---
drivers/dma-buf/dma-fence.c | 1 +
include/trace/
Am 13.02.24 um 16:50 schrieb Pierre-Eric Pelloux-Prayer:
Useful to identify why sdma jobs are submitted.
Signed-off-by: Pierre-Eric Pelloux-Prayer
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 16
2 files changed, 18 in
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 belong to
the same submission (without this, the first
Am 13.02.24 um 16:50 schrieb Pierre-Eric Pelloux-Prayer:
This makes it possible to understand the dependencies between jobs.
Possible usage of this trace:
* stuttering issues like Mesa !9189
* incorrect synchronization: I don't have a link for this one, but having
these events was very usef
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 enabling the cycle counter and timestamp registers would
incur i
Some users of Panfrost expressed interest in being able to gather fdinfo
stats for running jobs, on production builds with no built-in debugfs
support. Sysfs was first considered, but eventually it was realised
timestamp and cycle counting don't incur in additional power consumption
when the GPU is
From: Mikko Perttunen
On Tegra186, other software components may rely on the kernel to
keep Host1x operational even during suspend. As such, as a quirk,
skip asserting Host1x's reset on Tegra186.
We don't need to keep the clocks enabled, as BPMP ensures the clock
stays on while Host1x is being u
TI keystone display subsystem present in AM65 and other SoCs such as AM62
support two separate register spaces namely "common" and "common1" which
can be used by two separate hosts to program the display controller as
described in respective Technical Reference Manuals [1].
The common1 register sp
This adds DSS common1 region for respective SoCs supporting it.
Devarsh Thakkar (2):
dt-bindings: display: ti,am65x-dss: Add support for common1 region
arm64: dts: ti: Add common1 register space for AM62x, AM62A & AM65x
SoCs
.../devicetree/bindings/display/ti/ti,am65x-dss.yaml | 7
This adds common1 register space for AM62x, AM62A and AM65x SoC's which are
using TI's Keystone display hardware and supporting it as described in
Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
Signed-off-by: Devarsh Thakkar
---
V2: Add common1 region for AM62A SoC too
---
arch/a
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
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
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
Sign
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 (
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 st
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 went
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 e
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 on
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 r
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 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, TRACE
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
h
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
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(+)
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
the
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 be
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 contex
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 w
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 fun
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/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 me
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 a
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
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:
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 ++--
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
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: Palom
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
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 S
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
Rev
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
---
.../gpu/drm/msm/dis
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
---
dri
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 simplificat
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 supporte
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 ab
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:
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
---
driver
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
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
---
drivers/gpu
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 d
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
Signe
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 thi
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 Murth
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 mo
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
> 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 th
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: 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 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 fun
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 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 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 into
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 parall
1 - 100 of 146 matches
Mail list logo
