On 2023/4/30 19:23, XuDong Liu wrote:
Smatch reports:
drivers/gpu/drm/sun4i/sun4i_tcon.c:805 sun4i_tcon_init_clocks() warn:
'tcon->clk' from clk_prepare_enable() not released on lines: 792,801.
In the function sun4i_tcon_init_clocks(), tcon->clk and tcon->sclk0 are
not disabled in the error hand
On Fri, May 05, 2023 at 10:22:09AM +0200, Christian König wrote:
> Am 05.05.23 um 05:03 schrieb ye.xingc...@zte.com.cn:
> > From: Ye Xingchen
> >
> > convert the fget() use to fdget().
>
> Well the rational is missing. Why should we do that?
We very definitely should not. The series appears to
On 11/05/2023 00:03, Jessica Zhang wrote:
On 5/9/2023 11:33 PM, Marijn Suijten wrote:
On 2023-05-09 15:06:50, Jessica Zhang wrote:
Introduce MSM-specific DSC helper methods, as some calculations are
common between DP and DSC.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Jessica Zhang
---
On 11/05/2023 09:18, Marijn Suijten wrote:
On 2023-05-11 07:26:28, Dmitry Baryshkov wrote:
On 11/05/2023 01:35, Jessica Zhang wrote:
On 5/9/2023 11:29 PM, Marijn Suijten wrote:
On 2023-05-09 15:06:48, Jessica Zhang wrote:
From: Dmitry Baryshkov
Add a helper setting config values which are
On 2023-05-11 07:26:28, Dmitry Baryshkov wrote:
> On 11/05/2023 01:35, Jessica Zhang wrote:
> >
> >
> > On 5/9/2023 11:29 PM, Marijn Suijten wrote:
> >> On 2023-05-09 15:06:48, Jessica Zhang wrote:
> >>> From: Dmitry Baryshkov
> >>>
> >>> Add a helper setting config values which are typically co
On 2023-05-10 14:03:14, Jessica Zhang wrote:
>
>
> On 5/9/2023 11:33 PM, Marijn Suijten wrote:
> > On 2023-05-09 15:06:50, Jessica Zhang wrote:
> >> Introduce MSM-specific DSC helper methods, as some calculations are
> >> common between DP and DSC.
> >>
> >> Reviewed-by: Dmitry Baryshkov
> >> Si
On Fri, May 05, 2023 at 10:18:47AM +0800, ye.xingc...@zte.com.cn wrote:
> From: Ye Xingchen
>
> convert the fget() use to fdget().
NAK.
On Fri, May 05, 2023 at 11:03:39AM +0800, ye.xingc...@zte.com.cn wrote:
> From: Ye Xingchen
>
> convert the fget() use to fdget().
NAK.
On 11/05/2023 01:07, Kuogee Hsieh wrote:
Unset DSC_ACTIVE bit at dpu_hw_ctl_reset_intf_cfg_v1(),
dpu_encoder_unprep_dsc() and dpu_encoder_dsc_pipe_clr() functions
to tear down DSC data path if DSC data path was setup previous.
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/disp/dpu1/dpu_
On 11/05/2023 01:07, Kuogee Hsieh wrote:
Unset DSC_ACTIVE bit at dpu_hw_ctl_reset_intf_cfg_v1(),
dpu_encoder_unprep_dsc() and dpu_encoder_dsc_pipe_clr() functions
to tear down DSC data path if DSC data path was setup previous.
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/disp/dpu1/dpu_
On 11/05/2023 01:07, Kuogee Hsieh wrote:
Add support for DSC 1.2 by providing the necessary hooks to program
the DPU DSC 1.2 encoder.
Changes in v3:
-- fixed kernel test rebot report that "__iomem *off" is declared but not
used at dpu_hw_dsc_config_1_2()
-- unrolling thresh loops
Changes in
On 11/05/2023 07:42, Abhinav Kumar wrote:
On 5/10/2023 9:39 PM, Dmitry Baryshkov wrote:
On 11/05/2023 07:38, Abhinav Kumar wrote:
On 5/10/2023 9:29 PM, Dmitry Baryshkov wrote:
On 11/05/2023 01:07, Kuogee Hsieh wrote:
DPU < 7.0.0 requires the PINGPONG block to be involved during
DSC settin
On 5/10/2023 9:39 PM, Dmitry Baryshkov wrote:
On 11/05/2023 07:38, Abhinav Kumar wrote:
On 5/10/2023 9:29 PM, Dmitry Baryshkov wrote:
On 11/05/2023 01:07, Kuogee Hsieh wrote:
DPU < 7.0.0 requires the PINGPONG block to be involved during
DSC setting up. Since DPU >= 7.0.0, enabling and sta
On 11/05/2023 07:38, Abhinav Kumar wrote:
On 5/10/2023 9:29 PM, Dmitry Baryshkov wrote:
On 11/05/2023 01:07, Kuogee Hsieh wrote:
DPU < 7.0.0 requires the PINGPONG block to be involved during
DSC setting up. Since DPU >= 7.0.0, enabling and starting the DSC
encoder engine moved to INTF with th
On 5/10/2023 9:29 PM, Dmitry Baryshkov wrote:
On 11/05/2023 01:07, Kuogee Hsieh wrote:
DPU < 7.0.0 requires the PINGPONG block to be involved during
DSC setting up. Since DPU >= 7.0.0, enabling and starting the DSC
encoder engine moved to INTF with the help of the flush mechanism.
Nit: was
On 11/05/2023 01:07, Kuogee Hsieh wrote:
DPU < 7.0.0 has DPU_PINGPONG_DSC feature bit set to indicate it requires
both dpu_hw_pp_setup_dsc() and dpu_hw_pp_dsc_{enable,disable}() to be
executed to complete DSC configuration if DSC hardware block is present.
Hence test DPU_PINGPONG_DSC feature bit
On 11/05/2023 01:07, Kuogee Hsieh wrote:
DPU < 7.0.0 has DPU_PINGPONG_DSC feature bit set to indicate it requires
both dpu_hw_pp_setup_dsc() and dpu_hw_pp_dsc_{enable,disable}() to be
executed to complete DSC configuration if DSC hardware block is present.
Hence test DPU_PINGPONG_DSC feature bit
On 11/05/2023 01:07, Kuogee Hsieh wrote:
DPU < 7.0.0 requires the PINGPONG block to be involved during
DSC setting up. Since DPU >= 7.0.0, enabling and starting the DSC
encoder engine moved to INTF with the help of the flush mechanism.
Nit: was moved.
Add a DPU_PINGPONG_DSC feature bit to res
On 11/05/2023 01:35, Jessica Zhang wrote:
On 5/9/2023 11:29 PM, Marijn Suijten wrote:
On 2023-05-09 15:06:48, Jessica Zhang wrote:
From: Dmitry Baryshkov
Add a helper setting config values which are typically constant across
operating modes (table E-4 of the standard) and mux_word_size (whi
On Wed, 10 May 2023 at 23:31, Kuogee Hsieh wrote:
>
> The internal_hpd flag was introduced to handle external DP HPD derived from
> GPIO
> pinmuxed into DP controller. HPD plug/unplug interrupts cannot be enabled
> until
> internal_hpd flag is set to true.
> At both bootup and resume time, the D
On 5/10/2023 4:55 PM, Stephen Boyd wrote:
Quoting Kuogee Hsieh (2023-05-10 13:31:04)
The internal_hpd flag was introduced to handle external DP HPD derived from GPIO
pinmuxed into DP controller.
Was it? It looks more like it was done to differentiate between eDP and
DP, because internal_hpd
On 4/13/2023 12:38 AM, Stanislaw Gruszka wrote:
Use DMA_RESV_USAGE_BOOKKEEP reservation for buffer objects, except for
command buffers for which we use DMA_RESV_USAGE_WRITE (since VPU can
write to command buffer context save area).
Fixes: 0ec8671837a6 ("accel/ivpu: Fix S3 system suspend when not
Quoting Kuogee Hsieh (2023-05-10 13:31:04)
> The internal_hpd flag was introduced to handle external DP HPD derived from
> GPIO
> pinmuxed into DP controller.
Was it? It looks more like it was done to differentiate between eDP and
DP, because internal_hpd is set only if DRM_BRIDGE_OP_HPD is set o
Hi Stephen
On 5/10/2023 4:19 PM, Kuogee Hsieh wrote:
internal_hpd is referenced at both plug and unplug handle.
The majority purpose of mutext is try to serialize internal_hpd between
dp_bridge_hpd_disable() and either plug or unplug handle.
On 5/10/2023 4:11 PM, Abhinav Kumar wrote:
On
internal_hpd is referenced at both plug and unplug handle.
The majority purpose of mutext is try to serialize internal_hpd between
dp_bridge_hpd_disable() and either plug or unplug handle.
On 5/10/2023 4:11 PM, Abhinav Kumar wrote:
On 5/10/2023 3:46 PM, Stephen Boyd wrote:
Quoting Kuogee
On 5/10/2023 3:46 PM, Stephen Boyd wrote:
Quoting Kuogee Hsieh (2023-05-10 13:31:05)
Intrenal_hpd is referenced by event thread but set by drm bridge callback
context. Add mutex to protect internal_hpd to avoid conflicts between
threads.
Signed-off-by: Kuogee Hsieh
---
This patch looks co
Correct the math for slice_last_group_size so that it matches the
calculations downstream.
Fixes: c110cfd1753e ("drm/msm/disp/dpu1: Add support for DSC")
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Marijn Suijten
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c | 5 ++
hdisplay for compressed images should be calculated as bytes_per_slice *
slice_count. Thus, use MSM DSC helper to calculate hdisplay for
dsi_timing_setup instead of directly using mode->hdisplay.
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Marijn Suijten
Signed-off-by: Jessica Zhang
---
drivers
There are some overlap in calculations for MSM-specific DSC variables
between DP and DSI. In addition, the calculations for initial_scale_value
and det_thresh_flatness that are defined within the DSC 1.2 specifications,
but aren't yet included in drm_dsc_helper.c.
This series moves these calculati
Introduce MSM-specific DSC helper methods, as some calculations are
common between DP and DSC.
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/Makefile | 1 +
drivers/gpu/drm/msm/msm_dsc_helper.c | 26 ++
drivers/gpu/drm/msm/msm_dsc_helper.h | 69 +++
From: Dmitry Baryshkov
Use new DRM DSC helpers to setup DSI DSC configuration. The
initial_scale_value needs to be adjusted according to the standard, but
this is a separate change.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/ms
Use MSM and DRM DSC helper methods to configure DSC for DSI.
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Marijn Suijten
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/dsi/dsi_host.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host
The current dpu_hw_dsc calculation for det_thresh_flatness does not
match the downstream calculation or the DSC spec.
Use the DRM DSC helper for det_thresh_flatness to match downstream
implementation and the DSC spec.
Fixes: c110cfd1753e ("drm/msm/disp/dpu1: Add support for DSC")
Reviewed-by: Dmi
From: Dmitry Baryshkov
Add a helper setting config values which are typically constant across
operating modes (table E-4 of the standard) and mux_word_size (which is
a const according to 3.5.2).
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Marijn Suijten
Signed-off-by: Jessica Zhang
---
driv
Add helpers to calculate det_thresh_flatness and initial_scale_value as
these calculations are defined within the DSC spec.
Signed-off-by: Jessica Zhang
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Marijn Suijten
Signed-off-by: Jessica Zhang
---
include/drm/display/drm_dsc_helper.h | 11 +
Quoting Kuogee Hsieh (2023-05-10 13:31:05)
> Intrenal_hpd is referenced by event thread but set by drm bridge callback
> context. Add mutex to protect internal_hpd to avoid conflicts between
> threads.
>
> Signed-off-by: Kuogee Hsieh
> ---
This patch looks completely unnecessary. How can dp_bridg
The current dpu_hw_dsc calculation for det_thresh_flatness does not
match the downstream calculation or the DSC spec.
Use the DRM DSC helper for det_thresh_flatness to match downstream
implementation and the DSC spec.
Fixes: c110cfd1753e ("drm/msm/disp/dpu1: Add support for DSC")
Reviewed-by: Dmi
hdisplay for compressed images should be calculated as bytes_per_slice *
slice_count. Thus, use MSM DSC helper to calculate hdisplay for
dsi_timing_setup instead of directly using mode->hdisplay.
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Marijn Suijten
Signed-off-by: Jessica Zhang
---
drivers
Introduce MSM-specific DSC helper methods, as some calculations are
common between DP and DSC.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/Makefile | 1 +
drivers/gpu/drm/msm/msm_dsc_helper.c | 26 ++
drivers/gpu/drm/msm/msm_dsc_helper
Correct the math for slice_last_group_size so that it matches the
calculations downstream.
Fixes: c110cfd1753e ("drm/msm/disp/dpu1: Add support for DSC")
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Marijn Suijten
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c | 5 ++
From: Dmitry Baryshkov
Use new DRM DSC helpers to setup DSI DSC configuration. The
initial_scale_value needs to be adjusted according to the standard, but
this is a separate change.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/ms
There are some overlap in calculations for MSM-specific DSC variables
between DP and DSI. In addition, the calculations for initial_scale_value
and det_thresh_flatness that are defined within the DSC 1.2 specifications,
but aren't yet included in drm_dsc_helper.c.
This series moves these calculati
Use MSM and DRM DSC helper methods to configure DSC for DSI.
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Marijn Suijten
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/dsi/dsi_host.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host
Add helpers to calculate det_thresh_flatness and initial_scale_value as
these calculations are defined within the DSC spec.
Signed-off-by: Jessica Zhang
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Marijn Suijten
Signed-off-by: Jessica Zhang
---
include/drm/display/drm_dsc_helper.h | 11 +
From: Dmitry Baryshkov
Add a helper setting config values which are typically constant across
operating modes (table E-4 of the standard) and mux_word_size (which is
a const according to 3.5.2).
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Marijn Suijten
Signed-off-by: Jessica Zhang
---
driv
On 5/9/2023 11:29 PM, Marijn Suijten wrote:
On 2023-05-09 15:06:48, Jessica Zhang wrote:
From: Dmitry Baryshkov
Add a helper setting config values which are typically constant across
operating modes (table E-4 of the standard) and mux_word_size (which is
a const according to 3.5.2).
Signed
On 2023-05-10 15:00:03, Teres Alexis, Alan Previn wrote:
>
> alan:snip
>
> > This is why I asked if it was it was "basically certain that in a
> > production environment, then it will eventually return 1 meaning it's
> > ready". Alan's response was a little ambiguous on this point.
> alan: if we
Hi,
On Tue, May 09, 2023 at 09:59:42AM -0700, fei.y...@intel.com wrote:
> From: Fei Yang
>
> To comply with the design that buffer objects shall have immutable
> cache setting through out their life cycle, {set, get}_caching ioctl's
> are no longer supported from MTL onward. With that change cac
Unset DSC_ACTIVE bit at dpu_hw_ctl_reset_intf_cfg_v1(),
dpu_encoder_unprep_dsc() and dpu_encoder_dsc_pipe_clr() functions
to tear down DSC data path if DSC data path was setup previous.
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 44 +
Current DSC flush update is piggyback inside dpu_hw_ctl_intf_cfg_v1().
This patch separates DSC flush away from dpu_hw_ctl_intf_cfg_v1() by
adding dpu_hw_ctl_update_pending_flush_dsc_v1() to handle both per
DSC engine and DSC flush bits at same time to make it consistent with
the location of flush
Disabling the crossbar mux between DSC and PINGPONG currently
requires a bogus enum dpu_pingpong value to be passed when calling
dsc_bind_pingpong_blk() with enable=false, even though the register
value written is independent of the current PINGPONG block. Replace
that `bool enable` parameter with
From: Abhinav Kumar
Add DSC 1.2 hardware blocks to the catalog with necessary sub-block and
feature flag information. Each display compression engine (DCE) contains
dual hard slice DSC encoders so both share same base address but with
its own different sub block address.
changes in v4:
-- delet
Add support for DSC 1.2 by providing the necessary hooks to program
the DPU DSC 1.2 encoder.
Changes in v3:
-- fixed kernel test rebot report that "__iomem *off" is declared but not
used at dpu_hw_dsc_config_1_2()
-- unrolling thresh loops
Changes in v4:
-- delete DPU_DSC_HW_REV_1_1
-- delete
DPU < 7.0.0 has DPU_PINGPONG_DSC feature bit set to indicate it requires
both dpu_hw_pp_setup_dsc() and dpu_hw_pp_dsc_{enable,disable}() to be
executed to complete DSC configuration if DSC hardware block is present.
Hence test DPU_PINGPONG_DSC feature bit and assign DSC related functions
to the ops
DPU < 7.0.0 requires the PINGPONG block to be involved during
DSC setting up. Since DPU >= 7.0.0, enabling and starting the DSC
encoder engine moved to INTF with the help of the flush mechanism.
Add a DPU_PINGPONG_DSC feature bit to restrict the availability of
dpu_hw_pp_setup_dsc() and dpu_hw_pp_d
From: Abhinav Kumar
There are some platforms has DSC blocks but it is not declared at catalog.
For completeness, this patch adds DSC blocks for platforms which missed
them.
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h |
This series adds the DPU side changes to support DSC 1.2 encoder. This
was validated with both DSI DSC 1.2 panel and DP DSC 1.2 monitor.
The DSI and DP parts will be pushed later on top of this change.
This seriel is rebase on [1], [2] and catalog fixes from rev-4 of [3].
[1]: https://patchwork.fr
alan:snip
> This is why I asked if it was it was "basically certain that in a
> production environment, then it will eventually return 1 meaning it's
> ready". Alan's response was a little ambiguous on this point.
alan: if we get a '2' and never transition to '1' - thats a kernel bug or
firmware
On Sun, May 07, 2023 at 06:25:26PM +0200, 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
On Sun, May 07, 2023 at 06:25:25PM +0200, 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
...fixing some Cc email addresses I somehow mangled.
On 2023-05-10 12:40:07, Souza, Jose wrote:
> On Mon, 2023-05-08 at 17:49 +, Teres Alexis, Alan Previn wrote:
> > On Fri, 2023-05-05 at 00:39 -0700, Justen, Jordan L wrote:
> > > On 2023-05-04 22:30:07, Teres Alexis, Alan Previn wrote:
> > >
On Sun, May 07, 2023 at 06:25:24PM +0200, 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
On 5/9/2023 11:33 PM, Marijn Suijten wrote:
On 2023-05-09 15:06:50, Jessica Zhang wrote:
Introduce MSM-specific DSC helper methods, as some calculations are
common between DP and DSC.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/Makefile | 1
From: John Harrison
A recent change bumped a 'notice' message up to 'error' level for
debug builds to help trap incorrect configurations in CI systems.
Unfortunaetly, tha error condition in question is triggered by the
error injection probe test. So change the message again to be 'probe
error' le
On Wed, 2023-05-10 at 16:19 +0200, Thomas Hellström wrote:
> Each VM has two rebind lists, one protected by the VM resv, the other
> one protected essentially by the VM notifier.list_lock. This series
> intends to fix two points of illegal access.
>
> Patch 1 fixes an access of VM rebind_lists' li
Intrenal_hpd is referenced by event thread but set by drm bridge callback
context. Add mutex to protect internal_hpd to avoid conflicts between
threads.
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_display.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git
There is bug report on exteranl DP display does not work.
This patch add below two patches to fix the problem.
1) enable HDP plugin/unplugged interrupts to hpd_enable/disable
2) add mutex to protect internal_hpd against race condition between different
threads
Kuogee Hsieh (2):
drm/msm/dp:
The internal_hpd flag was introduced to handle external DP HPD derived from GPIO
pinmuxed into DP controller. HPD plug/unplug interrupts cannot be enabled until
internal_hpd flag is set to true.
At both bootup and resume time, the DP driver will enable external DP
plugin interrupts and handle plugi
Fix the STI console to be able to execute either the 64-bit STI ROM code
or the 32-bit STI ROM code.
This is necessary on 64-bit only machines (e.g. C8000 workstation) which
otherwise won't show the STI text console with HP graphic cards like
Visualize-FX5/FX10/FXe.
When calling 32-bit code from
Fix the STI console to be able to execute either the 64-bit STI ROM code
or the 32-bit STI ROM code.
This is necessary on 64-bit only machines (e.g. C8000 workstation) which
otherwise won't show the STI text console with HP graphic cards like
Visualize-FX5/FX10/FXe.
When calling 32-bit code from
Hello,
On Wed, May 10, 2023 at 04:59:01PM +0200, Maarten Lankhorst wrote:
> The misc controller is not granular enough. A single computer may have any
> number of
> graphics cards, some of them with multiple regions of vram inside a single
> card.
Extending the misc controller to support dynami
Dne petek, 05. maj 2023 ob 07:21:08 CEST je Roman Beranek napisal(a):
> While the rate of TCON0's DCLK matches dotclock for parallel and LVDS
> outputs, this doesn't hold for DSI. According manuals from Allwinner,
> DCLK is an abbreviation of Data Clock, not dotclock, so go with that
> instead.
>
Dne petek, 05. maj 2023 ob 07:21:07 CEST je Roman Beranek napisal(a):
> TCON0's source clock can be fed from either PLL_MIPI, or PLL_VIDEO0(2X),
> however MIPI DSI output only seems to work when PLL_MIPI is selected and
> thus the choice must be hardcoded in.
>
> Currently, this driver can't propa
Dne ponedeljek, 08. maj 2023 ob 16:08:32 CEST je Frank Oltmanns napisal(a):
> Hello again,
>
> On 2023-05-08 at 08:54:28 +0200, Frank Oltmanns wrote:
> > Hello Roman,
> >
> > On 2023-05-03 at 16:22:32 +0200, "Roman Beranek" wrote:
> >> Hello everyone,
> >>
> >> I apologize for my absence from
Loading i915 on UBSAN enabled kernels (CONFIG_UBSAN/CONFIG_UBSAN_BOOL)
causes the following warning:
UBSAN: invalid-load in drivers/gpu/drm/i915/gt/uc/intel_uc.c:558:2
load of value 255 is not a valid value for type '_Bool'
Call Trace:
dump_stack_lvl+0x57/0x7d
ubsan_epilogue+0x5/0x40
Hi, Thomas
I love your patch, yet something to improve:
On 2023/5/10 19:05, Thomas Zimmermann wrote:
Fix coding style. No functional changes.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Arnd Bergmann
Reviewed-by: Sam Ravnborg
Reviewed-by: Sui Jingfeng
Tested-by: Sui Jingfeng
---
dri
Add MTL's function for ARB session creation using PXP firmware
version 4.3 ABI structure format.
While relooking at the ARB session creation flow in intel_pxp_start,
let's address missing UAPI documentation. Without actually changing
backward compatible behavior, update i915's drm-uapi comments
th
Because of the additional firmware, component-driver and
initialization depedencies required on MTL platform before a
PXP context can be created, UMD calling for PXP creation as a
way to get-caps can take a long time. An actual real world
customer stack has seen this happen in the 4-to-8 second ran
Add helper functions into a new file for heci-packet-submission.
The helpers will handle generating the MTL GSC-CS Memory-Header
and submission of the Heci-Cmd-Packet instructions to the engine.
NOTE1: These common functions for heci-packet-submission will be used
by different i915 callers:
1
Enable PXP with MTL-GSC-CS: add the has_pxp into device info
and increase the debugfs teardown timeouts to align with
new GSC-CS + firmware specs.
Now that we have 3 places that are selecting pxp timeouts
based on tee vs gsccs back-end, let's add a helper.
Signed-off-by: Alan Previn
Reviewed-by:
Add GSC engine based method for sending PXP firmware packets
to the GSC firmware for MTL (and future) products.
Use the newly added helpers to populate the GSC-CS memory
header and send the message packet to the FW by dispatching
the GSC_HECI_CMD_PKT instruction on the GSC engine.
We use non-priv
On legacy platforms, KCR HW enabling is done at the time the mei
component interface is bound. It's also disabled during unbind.
However, for MTL onwards, we don't depend on a tee component
to start sending GSC-CS firmware messages.
Thus, immediately enable (or disable) KCR HW on PXP's init,
fini
For MTL, the PXP back-end transport uses the GSC engine to submit
HECI packets through the HW to the GSC firmware for PXP arb
session management. This submission uses a non-priveleged
batch buffer, a buffer for the command packet and of course
a context targeting the GSC-CS.
Thus for MTL, we need
Add MTL hw-plumbing enabling for KCR operation under PXP
which includes:
1. Updating 'pick-gt' to get the media tile for
KCR interrupt handling
2. Adding MTL's KCR registers for PXP operation
(init, status-checking, etc.).
While doing #2, lets create a separate registers header file for PXP
This series enables PXP on MTL. On ADL/TGL platforms, we rely on
the mei driver via the i915-mei PXP component interface to establish
a connection to the security firmware via the HECI device interface.
That interface is used to create and teardown the PXP ARB session.
PXP ARB session is created wh
Thomas Zimmerman writes:
>
> I found this casting mess even more unreadable. I went back to v2, fixed
> the style issues and committed the patch as v4 (still under your name).
>
> https://cgit.freedesktop.org/drm/drm-tip/commit?id=1b617bc93178912fa36f87a957c15d1f1708c299
Will this patch make it i
On Wed, May 10, 2023 at 08:57:03AM -0600, Jeffrey Hugo wrote:
> On 5/3/2023 4:41 AM, Dan Carpenter wrote:
> > Smatch complains that these are not initialized if get_cntl_version()
> > fails but we still print them in the debug message. Not the end of
> > the world, but true enough. Let's just ini
Remove the pointless check. If an IOMMU is providing transparent DMA API
ops for any device(s) we care about, the DT code will have enforced the
appropriate probe ordering already.
Signed-off-by: Robin Murphy
---
v2: Rebase to 6.4-rc1
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 4
1 file cha
On 5/10/23 11:24, Liu Ying wrote:
The single LCDIF embedded in i.MX93 SoC may drive multiple displays
simultaneously. Look at LCDIF output port's remote port parents to
find all enabled first bridges. Add an encoder for each found bridge
and attach the bridge to the encoder. This is a preparat
On 5/10/23 11:24, Liu Ying wrote:
A valid bridge is already found in lcdif_attach_bridge() and set
to lcdif->bridge, so lcdif->bridge cannot be a NULL pointer. Drop
the unnecessary NULL pointer check in KMS stage.
Tested-by: Alexander Stein
Reviewed-by: Alexander Stein
Signed-off-by: Liu Ying
On Wed, May 10, 2023 at 10:52:39AM +0200, Maximilian Weigand wrote:
> From: Maximilian Weigand
>
> Use backlight_is_blank() to determine if the led strings should be turned
> off in the update_status() functions of both strings.
>
> Reviewed-by: Daniel Thompson
> Signed-off-by: Maximilian Weiga
On 07/05/2023 17:25, 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 in
There is apparently no reasons to open-code of_device_uevent() besides:
- The helper receives a struct device while we want to use the of_node
member of the struct device *parent*.
- of_device_uevent() could not be called by modules because of a missing
EXPORT_SYMBOL*().
In practice, the forme
Move the content of the helper providing printable modaliases in
module.c. Call this new function from an of_device.c inline helper.
There is no functional changes. However, as a side effect, we fix the
return value of the inline helper (in the !CONFIG_OF case) which should
be a ssize_t instead of
Let's move the logic of the former helper into module.c and use it from
an inline helper located under of_device.c. This way there is no change
for users while the logic gets moved to an OF-only file.
Signed-off-by: Miquel Raynal
---
drivers/of/device.c | 23 ---
driver
Hello,
As part of a previous series, Rob suggested that keeping too much logic
in of/device.c was backward and would benefit from a gradual cleanup
with the hope some day to move the remaining helpers into inline
functions wrapping the proper of_*() methods.
Link:
https://lore.kernel.org/lkml/ca
The content of of_uevent() is currently hardcoded in a driver that can
be compiled as a module. Nothing prevents of_uevent() to be exported to
modules, most of the other helpers in of_device.c actually are.The
reason why this helper was not exported is because it has been so far
only useful in driv
Move the OF related logic inside of/module.c and use it from of_device.h
with an inline helper so there is no visible change from the users point
of view.
Signed-off-by: Miquel Raynal
---
drivers/of/device.c | 42 ---
drivers/of/module.c | 41 +
On Wed, May 10, 2023, at 16:27, Thomas Zimmermann wrote:
> Am 10.05.23 um 16:15 schrieb Arnd Bergmann:
>> On Wed, May 10, 2023, at 16:03, kernel test robot wrote:
>> I think that's a preexisting bug and I have no idea what the
>> correct solution is. Looking for HD64461 shows it being used
>> bot
Hi Geert
Am 10.05.23 um 16:34 schrieb Geert Uytterhoeven:
Hi Thomas,
On Wed, May 10, 2023 at 4:20 PM Thomas Zimmermann wrote:
Am 10.05.23 um 14:34 schrieb Geert Uytterhoeven:
On Wed, May 10, 2023 at 1:06 PM Thomas Zimmermann wrote:
Implement framebuffer I/O helpers, such as fb_read*() and
1 - 100 of 156 matches
Mail list logo
