The VOP in Rockchip SoCs that support YUV planes also support swapping
of the U and V elements. Supporting the swapped variants, especially
NV21, would be beneficial for multimedia applications, as the hardware
video decoders only output NV21, and supporting this pixel format in
the display
Am 14.01.22 um 00:26 schrieb John Stultz:
On Thu, Jan 13, 2022 at 5:05 AM Christian König
wrote:
Am 13.01.22 um 14:00 schrieb Ruhl, Michael J:
-Original Message-
From: dri-devel On Behalf Of
Ruhl, Michael J
-Original Message-
From: dri-devel On Behalf Of
ctx->next_bridge is checked for NULL twice in a row. The second
conditional is redundant, so remove it.
Signed-off-by: Drew Davenport
---
drivers/gpu/drm/bridge/ite-it66121.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ite-it66121.c
Hi, Nancy:
On Mon, 2022-01-10 at 16:46 +0800, Nancy.Lin wrote:
> Add drm ovl_adaptor sub driver. Bring up ovl_adaptor sub driver if
> the component exists in the path.
>
> Signed-off-by: Nancy.Lin
> ---
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 16
>
On Fri, 2022-01-07 at 10:23 +0100, AngeloGioacchino Del Regno wrote:
> Il 06/01/22 10:13, Chunfeng Yun ha scritto:
> > On Mon, 2022-01-03 at 15:53 +0100, AngeloGioacchino Del Regno
> > wrote:
> > > Use the dev_err_probe() helper to simplify error handling during
> > > probe.
> > >
> > >
Read out the Vendor/Chip/Version ID registers from the chip before
performing any configuration, and validate that the registers have
correct values. This is mostly a simple test whether DSI register
access does work, since that tends to be broken on various bridges.
Signed-off-by: Marek Vasut
Both example code [1], [2] as well as one provided by custom panel vendor
set register SYS_CTRL_1 to 0x88. What exactly does the value mean is unknown
due to unavailable datasheet. Align this register value with example code.
[1]
The driver currently hard-codes HS/VS polarity to active-low and DE to
active-high, which is not correct for a lot of supported DPI panels.
Add the missing mode flag handling for HS/VS/DE polarity.
Signed-off-by: Marek Vasut
Cc: Jagan Teki
Cc: Robert Foss
Cc: Sam Ravnborg
Cc: Thomas
Implement .atomic_get_input_bus_fmts callback, which sets up the
input (DSI-end) format, and that format can then be used in pipeline
format negotiation between the DSI-end of this bridge and the other
component closer to the scanout engine.
Signed-off-by: Marek Vasut
Cc: Jagan Teki
Cc: Robert
The DSI burst mode is more energy efficient than the DSI sync pulse mode,
make use of the burst mode since the chip supports it as well. Disable the
generation of EoT packet, the chip ignores it, so no point in emitting it.
Enable transmission of data in LP mode, otherwise register read via DSI
Rename function ICN6211_DSI() to chipone_writeb() to keep all function
names lower-case. No functional change.
Signed-off-by: Marek Vasut
Cc: Jagan Teki
Cc: Robert Foss
Cc: Sam Ravnborg
Cc: Thomas Zimmermann
To: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/bridge/chipone-icn6211.c |
The driver currently hard-codes DSI lane count to two, however the chip
is capable of operating in 1..4 DSI lanes mode. Parse 'data-lanes' DT
property and program the result into DSI_CTRL register.
Signed-off-by: Marek Vasut
Cc: Jagan Teki
Cc: Robert Foss
Cc: Sam Ravnborg
Cc: Thomas
The ICN6211 chip starts in I2C configuration mode after cold boot.
Implement support for configuring the chip via I2C in addition to
the current DSI LP command mode configuration support. The later
seems to be available only on chips which have additional MCU on
the panel/bridge board which
The chip is capable of swapping DPI RGB channels. The driver currently
does not implement support for this functionality. Write the MIPI_PN_SWAP
register to 0 to assure the color swap is disabled.
Signed-off-by: Marek Vasut
Cc: Jagan Teki
Cc: Robert Foss
Cc: Sam Ravnborg
Cc: Thomas Zimmermann
The chip contains fractional PLL, however the driver currently hard-codes
one specific PLL setting. Implement generic PLL parameter calculation code,
so any DPI panel with arbitrary pixel clock can be attached to this bridge.
The datasheet for this bridge is not available, the PLL behavior has
The HFP_HSW_HBP_HI register must be programmed with 2 LSbits of each
Horizontal Front Porch/Sync/Back Porch. Currently the driver programs
this register to 0, which breaks displays with either value above 255.
The HFP_MIN register must be set to the same value as HFP_LI, otherwise
there is
Retrieve display mode structure from panel or atomic state in
bridge_to_mode(). This completes the transition to the atomic
API.
Signed-off-by: Marek Vasut
Cc: Jagan Teki
Cc: Robert Foss
Cc: Sam Ravnborg
Cc: Thomas Zimmermann
To: dri-devel@lists.freedesktop.org
---
Use the atomic version of the enable/disable operations to continue
the transition to the atomic API, started with the introduction of
.atomic_get_input_bus_fmts(). This will be needed to access the mode
from the atomic state.
Signed-off-by: Marek Vasut
Cc: Jagan Teki
Cc: Robert Foss
Cc: Sam
The chip register layout has nothing to do with MIPI DCS, the registers
incorrectly marked as MIPI DCS in the driver are regular chip registers
often with completely different function.
Fill in the actual register names and bits from [1] and [2] and add the
entire register layout, since the
Quoting Kuogee Hsieh (2022-01-13 15:53:36)
> diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
> b/drivers/gpu/drm/msm/dp/dp_display.c
> index 7cc4d21..b3c5404 100644
> --- a/drivers/gpu/drm/msm/dp/dp_display.c
> +++ b/drivers/gpu/drm/msm/dp/dp_display.c
> @@ -83,6 +83,7 @@ struct
Hi,
Thank you for your comment.
On 2022/01/14 2:56, Bas Nieuwenhuizen wrote:
I think we'll also want to do a conditional disable for DC
(drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c) since it only
enables modifiers on newer HW. Something like "if (modifiers == NULL)
Hi Daniel-san,
Thank you for your comments.
On 2022/01/13 22:44, Daniel Stone wrote:
Hi Esaki-san,
On Thu, 13 Jan 2022 at 09:44, Tomohito Esaki wrote:
Some drivers whose planes only support linear layout fb do not support format
modifiers.
These drivers should support modifiers, however the
Hi Robert,
22. 1. 12. 오후 7:05에 Robert Foss 이(가) 쓴 글:
> Thank you again for catching this and submitting a revert.
>
> Reviewed-by: Robert Foss
> Applied to drm-misc-next.
>
Trivial thing I think but just notice. With this applying - original patch set
and revert one, merge conflict may
On Thu, Jan 13, 2022 at 6:19 PM Philippe Cornu
wrote:
>
> DRM DRIVERS FOR STI
> -M: Benjamin Gaignard
> L: dri-devel@lists.freedesktop.org
> S: Maintained
> T: git git://anongit.freedesktop.org/drm/drm-misc
If there is no longer a maintainer, I suppose it should also be
Each DP link training contains link training 1 followed by link
training 2. There is maximum of 5 retries of DP link training
before declared link training failed. It is required to stop link
training at end of link training 2 if it is failed so that next
link training 1 can start freshly. This
From: Kuogee Hsieh
Some DP sinkers prefer to use tps4 instead of tps3 during training #2.
This patch will use tps4 to perform link training #2 if sinker's DPCD
supports it.
Changes in V2:
-- replace dp_catalog_ctrl_set_pattern() with
dp_catalog_ctrl_set_pattern_state_bit()
Changes in V3:
--
DP CTS test case 4.2.2.6 has valid edid with bad checksum on purpose
and expect DP source return correct checksum. During drm edid read,
correct edid checksum is calculated and stored at
connector::real_edid_checksum.
The problem is struct dp_panel::connector never be assigned, instead the
Current DP drivers have regulators, clocks, irq and phy are grouped
together within a function and executed not in a symmetric manner.
This increase difficulty of code maintenance and limited code scalability.
This patch divides the driver life cycle of operation into four states,
resume
Group below 4 dp driver related patches into one series.
Kuogee Hsieh (4):
drm/msm/dp: do not initialize phy until plugin interrupt received
drm/msm/dp: populate connector of struct dp_panel
drm/msm/dp: add support of tps4 (training pattern 4) for HBR3
drm/msm/dp: stop link training
On Thu, Jan 13, 2022 at 5:05 AM Christian König
wrote:
> Am 13.01.22 um 14:00 schrieb Ruhl, Michael J:
> >> -Original Message-
> >> From: dri-devel On Behalf Of
> >> Ruhl, Michael J
> >>> -Original Message-
> >>> From: dri-devel On Behalf Of
> >>> guangming@mediatek.com
>
Quoting Kuogee Hsieh (2022-01-13 14:14:27)
>
> On 1/13/2022 1:52 PM, Stephen Boyd wrote:
> > Quoting Kuogee Hsieh (2022-01-13 12:44:16)
> >> On 1/13/2022 11:47 AM, Stephen Boyd wrote:
> >>> Quoting Kuogee Hsieh (2022-01-13 09:51:42)
> On 1/12/2022 8:13 PM, Stephen Boyd wrote:
> -
Reviewed-by: Robert Foss
Applied to drm-misc-next.
On Thu, 13 Jan 2022 at 20:43, Jagan Teki wrote:
>
> On Fri, Nov 12, 2021 at 11:47 AM Jagan Teki
> wrote:
> >
> > Replace atomic version of the enable/disable operations to
> > continue the transition to the atomic API.
> >
> > Also added
On 1/13/2022 1:52 PM, Stephen Boyd wrote:
Quoting Kuogee Hsieh (2022-01-13 12:44:16)
On 1/13/2022 11:47 AM, Stephen Boyd wrote:
Quoting Kuogee Hsieh (2022-01-13 09:51:42)
On 1/12/2022 8:13 PM, Stephen Boyd wrote:
- if (dp->usbpd->orientation == ORIENTATION_CC2)
- flip =
Helge Deller writes:
> I may have missed some discussions, but I'm objecting against this patch:
>
> b3ec8cdf457e5 ("fbdev: Garbage collect fbdev scrolling acceleration,
> part 1 (from TODO list)")
>
> Can we please (partly) revert it and restore the scrolling behaviour,
> where fbcon
Quoting Kuogee Hsieh (2022-01-13 12:44:16)
>
> On 1/13/2022 11:47 AM, Stephen Boyd wrote:
> > Quoting Kuogee Hsieh (2022-01-13 09:51:42)
> >> On 1/12/2022 8:13 PM, Stephen Boyd wrote:
> >> - if (dp->usbpd->orientation == ORIENTATION_CC2)
> >> - flip = true;
> >> +
Each DP link training contains link training 1 followed by link
training 2. There is maximum of 5 retries of DP link training
before declared link training failed. It is required to stop link
training at end of link training 2 if it is failed so that next
link training 1 can start freshly. This
From: Kuogee Hsieh
Some DP sinkers prefer to use tps4 instead of tps3 during training #2.
This patch will use tps4 to perform link training #2 if sinker's DPCD
supports it.
Changes in V2:
-- replace dp_catalog_ctrl_set_pattern() with
dp_catalog_ctrl_set_pattern_state_bit()
Changes in V3:
--
DP CTS test case 4.2.2.6 has valid edid with bad checksum on purpose
and expect DP source return correct checksum. During drm edid read,
correct edid checksum is calculated and stored at
connector::real_edid_checksum.
The problem is struct dp_panel::connector never be assigned, instead the
Current DP drivers have regulators, clocks, irq and phy are grouped
together within a function and executed not in a symmetric manner.
This increase difficulty of code maintenance and limited code scalability.
This patch divides the driver life cycle of operation into four states,
resume
Group below 4 dp driver related patches into one series.
Kuogee Hsieh (4):
drm/msm/dp: do not initialize phy until plugin interrupt received
drm/msm/dp: populate connector of struct dp_panel
drm/msm/dp: add support of tps4 (training pattern 4) for HBR3
drm/msm/dp: stop link training
Quoting Maxime Ripard (2022-01-12 03:46:52)
> Hi Stephen,
>
> Thanks for your answer
>
> On Tue, Jan 11, 2022 at 07:37:15PM -0800, Stephen Boyd wrote:
> > Sorry for being super delayed on response here. I'm buried in other
> > work. +Jerome for exclusive clk API.
> >
> > Quoting Maxime Ripard
On 1/13/2022 11:47 AM, Stephen Boyd wrote:
Quoting Kuogee Hsieh (2022-01-13 09:51:42)
On 1/12/2022 8:13 PM, Stephen Boyd wrote:
- if (dp->usbpd->orientation == ORIENTATION_CC2)
- flip = true;
+ dp_power_init(dp->power, false);
+
Hi Maxime,
I love your patch! Yet something to improve:
[auto build test ERROR on drm/drm-next]
[also build test ERROR on drm-intel/for-linux-next v5.16 next-20220113]
[cannot apply to anholt/for-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting
Hi Biju,
On Thu, Jan 13, 2022 at 2:45 PM Biju Das wrote:
>
> Hi All,
>
> RZ/G2{H, M, N} SoC has dw_hdmi IP and it was working ok(colour) till the
> commit
> 7cd70656d1285b79("drm/bridge: display-connector: implement bus fmts
> callbacks").
>
> After this patch, the screen becomes greenish(may
Quoting Kuogee Hsieh (2022-01-13 09:51:42)
>
> On 1/12/2022 8:13 PM, Stephen Boyd wrote:
> - if (dp->usbpd->orientation == ORIENTATION_CC2)
> - flip = true;
> + dp_power_init(dp->power, false);
> + dp_ctrl_reset_irq_ctrl(dp->ctrl, true);
> +
On Fri, Nov 12, 2021 at 11:47 AM Jagan Teki wrote:
>
> Replace atomic version of the enable/disable operations to
> continue the transition to the atomic API.
>
> Also added default drm atomic operations for duplicate, destroy
> and reset state API's in order to have smooth transition on
> atomic
On 1/13/2022 10:13, Matthew Brost wrote:
Add a cancel request selftest that results in an engine reset to cancel
the request as it is non-preemptable. Also insert a NOP request after
the cancelled request and confirm that it completes successfully.
v2:
(Tvrtko)
- Skip test if preemption
Applied. Thanks!
Alex
On Thu, Jan 13, 2022 at 8:38 AM Chen, Guchun wrote:
>
> Series is:
> Reviewed-by: Guchun Chen
>
> Regards,
> Guchun
>
> -Original Message-
> From: Yang Li
> Sent: Thursday, January 13, 2022 3:12 PM
> To: airl...@linux.ie; Chen, Guchun
> Cc: dan...@ffwll.ch;
Add a cancel request selftest that results in an engine reset to cancel
the request as it is non-preemptable. Also insert a NOP request after
the cancelled request and confirm that it completes successfully.
v2:
(Tvrtko)
- Skip test if preemption timeout compiled out
- Skip test if engine
In the i915 there are several hacks in place to make request cancellation
work with an old version of the GuC which delivered the G2H indicating
schedule disable is done before G2H indicating a context reset. Version
69 fixes this, so we can remove these hacks.
v2:
(Checkpatch)
-
Remove a hack required because schedule disable done G2H was received
before context reset G2H in GuC firmware 62.0.0. Since we have upgraded
69.0.3, this is no longer required.
Also revive selftest which proves this works before / after change.
v2:
- Address John Harrion's comments
On Thu, Jan 13, 2022 at 09:59:35AM -0800, John Harrison wrote:
> On 1/13/2022 09:34, Matthew Brost wrote:
> > On Thu, Jan 13, 2022 at 09:33:12AM -0800, John Harrison wrote:
> > > On 1/11/2022 15:11, Matthew Brost wrote:
> > > > Add a cancel request selftest that results in an engine reset to
On 1/13/2022 09:34, Matthew Brost wrote:
On Thu, Jan 13, 2022 at 09:33:12AM -0800, John Harrison wrote:
On 1/11/2022 15:11, Matthew Brost wrote:
Add a cancel request selftest that results in an engine reset to cancel
the request as it is non-preemptable. Also insert a NOP request after
the
Now that the error capture is fully decoupled from fence signalling
(request retirement to free memory, which is turn depends on resets) we
can safely flush the G2H handler during a GT reset. This is eliminates
corner cases where GuC generated G2H (e.g. engine resets) race with a GT
reset.
Allocate intel_engine_coredump_alloc with ALLOW_FAIL rather than
GFP_KERNEL do fully decouple the error capture from fence signalling.
Fixes: 8b91cdd4f8649 ("drm/i915: Use __GFP_KSWAPD_RECLAIM in the capture code")
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/i915_gpu_error.c | 2 +-
After a small fix to error capture code, we now can flush G2H during a
GT reset which simplifies code and seals some extreme corner case races.
Signed-off-by: Matthew Brost
Matthew Brost (2):
drm/i915: Allocate intel_engine_coredump_alloc with ALLOW_FAIL
drm/i915/guc: Flush G2H handler
I think we'll also want to do a conditional disable for DC
(drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c) since it only
enables modifiers on newer HW. Something like "if (modifiers == NULL)
fb_modifiers_not_supported = true;" in amdgpu_dm_plane_init.
On Thu, Jan 13, 2022 at 10:44 AM
On 1/12/2022 8:13 PM, Stephen Boyd wrote:
Quoting Kuogee Hsieh (2022-01-12 14:17:54)
On 1/12/2022 12:00 PM, Stephen Boyd wrote:
Quoting Kuogee Hsieh (2022-01-11 10:43:23)
Current DP drivers have regulators, clocks, irq and phy are grouped
together within a function and executed not in a
Hi All,
RZ/G2{H, M, N} SoC has dw_hdmi IP and it was working ok(colour) till the commit
7cd70656d1285b79("drm/bridge: display-connector: implement bus fmts callbacks").
After this patch, the screen becomes greenish(may be it is setting it into YUV
format??).
By checking the code, previously it
On Thu, Jan 13, 2022 at 09:33:12AM -0800, John Harrison wrote:
> On 1/11/2022 15:11, Matthew Brost wrote:
> > Add a cancel request selftest that results in an engine reset to cancel
> > the request as it is non-preemptable. Also insert a NOP request after
> > the cancelled request and confirm that
On 1/11/2022 15:11, Matthew Brost wrote:
Add a cancel request selftest that results in an engine reset to cancel
the request as it is non-preemptable. Also insert a NOP request after
the cancelled request and confirm that it completes successfully.
v2:
(Tvrtko)
- Skip test if preemption
On 1/11/2022 15:11, Matthew Brost wrote:
In the i915 there are several hacks in place to make request cancelation
work with an old version of the GuC which delivered the G2H indicating
schedule disable is done before G2H indicating a context reset. Version
69 fixes this, so we can remove these
Add Alain as sti maintainer for both drm/sti & cec/sti.
Add Raphaël as stm maintainer for drm/stm.
Signed-off-by: Philippe Cornu
---
MAINTAINERS | 3 +++
1 file changed, 3 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 6bea080d0159..708f8c86e4c9 100644
--- a/MAINTAINERS
+++
From: Benjamin Gaignard
Update Benjamin Gaignard address and remove it from no more maintained
drivers.
Signed-off-by: Benjamin Gaignard
---
MAINTAINERS | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 7a2345ce8521..6bea080d0159 100644
This short serie contains the maintainer status update sent recently by
Benjamin Gaignard (see [1] for details) and add new maintainers for
various stm & sti files.
[1]
https://lore.kernel.org/lkml/20210706163033.795805-1-benjamin.gaign...@collabora.com/
Benjamin Gaignard (1):
MAINTAINERS:
On 1/13/22 09:51, Thomas Zimmermann wrote:
> ping!
>
> This patchset got lost. Patches 4 and 5 still need a review.
for patches 4 & 5:
Acked-by: Helge Deller
Helge
>
> Am 01.12.21 um 12:46 schrieb Thomas Zimmermann:
>> Fix a number of compiler warnings in the AGP drivers. No functional
>>
I may have missed some discussions, but I'm objecting against this patch:
b3ec8cdf457e5 ("fbdev: Garbage collect fbdev scrolling acceleration,
part 1 (from TODO list)")
Can we please (partly) revert it and restore the scrolling behaviour,
where fbcon uses fb_copyarea() to copy the
Move the multi-lrc guc_id from the lower allocation partition (0 to
number of multi-lrc guc_ids) to upper allocation partition (number of
single-lrc to max guc_ids).
This will help when a native driver transitions to a PF after driver
load time. If the perma-pin guc_ids (kernel contexts) are in a
From: Rob Clark
Reported-by: Danylo Piliaiev
Fixes: 3ab1c5cc3939 ("drm/msm: Add param for userspace to query suspend count")
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
Hi Hans,
On 13/01/2022 11:15, Hans Verkuil wrote:
On 13/01/2022 11:11, AngeloGioacchino Del Regno wrote:
Il 11/01/22 11:57, AngeloGioacchino Del Regno ha scritto:
Il 12/11/21 11:55, Yong Wu ha scritto:
After this patchset, mtk_vcodec_release_enc_pm has only one line.
then remove that
Il 10/01/22 09:46, Nancy.Lin ha scritto:
Add mt8195 vdosys1 clock driver name and routing table to
the driver data of mtk-mmsys.
Signed-off-by: Nancy.Lin
Reviewed-by: AngeloGioacchino Del Regno
Il 10/01/22 09:46, Nancy.Lin ha scritto:
Add cmdq support for mtk-mmsys config API.
The mmsys config register settings need to take effect with the other
HW settings(like OVL_ADAPTOR...) at the same vblanking time.
If we use CPU to write the mmsys reg, we can't guarantee all the
settings can be
Il 10/01/22 09:46, Nancy.Lin ha scritto:
Add mmsys config API. The config API is used for config mmsys reg.
Some mmsys regs need to be setting according to the HW engine binding
to the mmsys simultaneously.
Signed-off-by: Nancy.Lin
Reviewed-by: AngeloGioacchino Del Regno
Il 10/01/22 09:46, Nancy.Lin ha scritto:
MT8195 vdosys1 has more than 32 reset bits and a different reset base
than other chips. Modify mmsys for support 64 bit and different reset
base.
Signed-off-by: Nancy.Lin
Reviewed-by: AngeloGioacchino Del Regno
Il 10/01/22 09:46, Nancy.Lin ha scritto:
Add mtk-mutex support for mt8195 vdosys1.
The vdosys1 path component contains ovl_adaptor, merge5,
and dp_intf1. Ovl_adaptor is composed of several sub-elements.
Signed-off-by: Nancy.Lin
Reviewed-by: AngeloGioacchino Del Regno
Il 10/01/22 09:46, Nancy.Lin ha scritto:
This is a preparation for adding support for mt8195 vdosys1 mutex.
The vdosys1 path component contains ovl_adaptor, merge5,
and dp_intf1. Ovl_adaptor is composed of several sub-elements,
so change it to support multi-bit control.
Signed-off-by: Nancy.Lin
Il 10/01/22 09:46, Nancy.Lin ha scritto:
Add drm ovl_adaptor sub driver. Bring up ovl_adaptor sub driver if
the component exists in the path.
Signed-off-by: Nancy.Lin
Reviewed-by: AngeloGioacchino Del Regno
Il 10/01/22 09:46, Nancy.Lin ha scritto:
Add driver data of mt8195 vdosys1 to mediatek-drm.
Signed-off-by: Nancy.Lin
Reviewed-by: AngeloGioacchino Del Regno
Il 10/01/22 09:46, Nancy.Lin ha scritto:
MT8195 have two mmsys. Modify drm for MT8195 multi-mmsys support.
The two mmsys (vdosys0 and vdosys1) will bring up two drm drivers,
only one drm driver register as the drm device.
Each drm driver binds its own component. The last bind drm driver
On Thu, Jan 13, 2022 at 03:18:14PM +0100, Michal Wajdeczko wrote:
>
>
> On 13.01.2022 00:26, Matthew Brost wrote:
> > On Thu, Jan 13, 2022 at 12:21:17AM +0100, Michal Wajdeczko wrote:
> >> On 11.01.2022 17:30, Matthew Brost wrote:
>
> ...
>
> >>> @@ -1863,6 +1861,33 @@ static void
On Thu, Jan 13, 2022 at 08:48:06AM +, Xu Wang wrote:
> 'destroy_workqueue()' already drains the queue before destroying it, so
> there is no need to flush it explicitly.
>
> Remove the redundant 'flush_workqueue()' calls.
>
> Signed-off-by: Xu Wang
Reviewed-by: Daniel Thompson
Daniel.
On 1/13/22 12:44, Maarten Lankhorst wrote:
Now that we require the object lock for all ops, some code handling
race conditions can be removed.
This is required to not take short-term pins inside execbuf.
Signed-off-by: Maarten Lankhorst
Acked-by: Niranjana Vishwanathapura
Reviewed-by:
On 1/13/22 12:44, Maarten Lankhorst wrote:
We want to remove more members of i915_vma, which requires the locking to be
Checkpatch.pl warning.
On 1/13/22 12:44, Maarten Lankhorst wrote:
Because we will start to require the obj->resv lock for unbinding,
ensure these shrinker functions also take the lock.
Perhaps "vma eviction utilities" rather than "shrinker functions"?
This requires some function signature changes, to ensure that
This adds support for DRM_BRIDGE_ATTACH_NO_CONNECTOR by adding the
bridge get_edid() and detect() callbacks after refactoring the connector
get_modes() and connector_detect() callbacks.
In order to keep the bridge working, extra code in get_modes() has been
moved to more logical places.
On 13-01-2022 15:33, Thomas Hellström (Intel) wrote:
>
> On 1/13/22 12:44, Maarten Lankhorst wrote:
>> i915_gem_evict_vm will need to be able to evict objects that are
>> locked by the current ctx. By testing if the current context already
>> locked the object, we can do this correctly. This
> >>> Note that this leaves some unmerged identical Bifrost feature lists, as
> >>> there are more features affecting Bifrost kernel space that we do not
> >>> yet hanlde.
> >>
> >> NIT: s/hanlde/handle/ ;)
> >>
> >> Do you have any features in mind that we're missing? The list looks very
> >>
On 1/13/22 12:44, Maarten Lankhorst wrote:
i915_gem_evict_vm will need to be able to evict objects that are
locked by the current ctx. By testing if the current context already
locked the object, we can do this correctly. This allows us to
evict the entire vm even if we already hold some
On 13.01.2022 00:26, Matthew Brost wrote:
> On Thu, Jan 13, 2022 at 12:21:17AM +0100, Michal Wajdeczko wrote:
>> On 11.01.2022 17:30, Matthew Brost wrote:
...
>>> @@ -1863,6 +1861,33 @@ static void guc_submit_request(struct i915_request
>>> *rq)
>>> spin_unlock_irqrestore(_engine->lock,
In addition to the RGB444 output, the BCM2711 HDMI controller supports
the YUV444 and YUV422 output formats.
Let's add support for them in the driver, but still use RGB as the
preferred format.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 289
In the function that validates that the clock isn't too high, we've only
taken our controller limitations into account so far.
However, the sink can have a limit on the maximum TMDS clock it can deal
with too which is exposed through the EDID and the drm_display_info.
Make sure we check it.
Currently we take the max_bpc property as the bpc value and do not try
anything else.
However, what the other drivers seem to be doing is that they would try
with the highest bpc allowed by the max_bpc property and the hardware
capabilities, test if it results in an acceptable configuration, and
The current code only base its decision for whether the scrambler must be
enabled or not on the pixel clock of the mode, but doesn't take the bits
per color into account.
Let's leverage the new function to compute the clock rate in the
scrambler setup code.
Signed-off-by: Maxime Ripard
---
The code to compute our clock rate for a given setup will be called in
multiple places in the next patches, so let's create a separate function
for it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 49 +++---
1 file changed, 34 insertions(+), 15
Our code is doing the same clock rate validation in multiple instances.
Let's create a helper to share the rate validation.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 26 +++---
1 file changed, 15 insertions(+), 11 deletions(-)
diff --git
In order to support the YUV output, we'll need the atomic state to know
what is the state of the associated property in the CSC setup callback.
Let's change the prototype of that callback to allow us to access it.
Acked-by: Thomas Zimmermann
Signed-off-by: Maxime Ripard
---
The current CSC setup code for the BCM2711 uses a sequence of register
writes to configure the CSC depending on whether we output using a full
or limited range.
However, with the upcoming introduction of the YUV output, we're going
to add new matrices to perform the conversions, so we should
On BCM2711, the HDMI_CSC_CTL register value has been hardcoded to an
opaque value. Let's replace it with properly defined values.
Acked-by: Thomas Zimmermann
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 5 ++---
drivers/gpu/drm/vc4/vc4_regs.h | 3 +++
2 files changed, 5
The CSC callbacks takes a boolean as an argument to tell whether we're
using the full range or limited range RGB.
However, with the upcoming YUV support, the logic will be a bit more
complex. In order to address this, let's make the callbacks take the
entire mode, and call our new helper to tell
On the BCM2711, the HDMI_VEC_INTERFACE_XBAR register configuration
depends on whether we're using an RGB or YUV output. Let's move that
configuration to the CSC setup.
Acked-by: Thomas Zimmermann
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 3 ++-
1 file changed, 2
1 - 100 of 151 matches
Mail list logo
