On Thu, 06 Mar 2025, Jani Nikula wrote:
> On Sat, 01 Mar 2025, Dmitry Baryshkov wrote:
>> Existing DPCD access functions return an error code or the number of
>> bytes being read / write in case of partial access. However a lot of
>> drivers either (incorrectly) ign
s
> compatibility.
I think that description is for earlier versions of the series, it's the
other way round now.
Regardless, glanced through the series quickly, I like it, this is
Acked-by: Jani Nikula
>
> This series targets only the DRM helpers code. If the approach is foun
au and i915 trees.
Either way is fine with me, up to you. But please try to ensure these
get into drm-misc-next pull request by this cycle, so we can backmerge
and catch up sooner rather than later.
Acked-by: Jani Nikula
>
>> drm/msm/dp: Add support for LTTPR handling
>>
&
this results in a boilerplate code which compares
> returned value with the size.
>
> Implement new set of DPCD access helpers, which ignore partial access,
> always return 0 or an error code. Implement existing helpers using the
> new functions to ensure backwards compatibility.
&g
hat only checked for < 0
with the old functions.
I glanced through the series, I didn't spot anything obviously wrong,
but didn't do a thorough review either. I can do once we have wider
buy-in for the idea in general, so the effort won't be wasted.
For now,
Acked-by:
= drm_dp_dpcd_write_data(aux_dev->aux, pos, buf, todo);
> if (res <= 0)
> break;
>
> - pos += res;
> + pos += todo;
> }
>
> if (pos != iocb->ki_pos)
--
Jani Nikula, Intel
On Mon, 30 Dec 2024, Dmitry Baryshkov wrote:
> On Mon, Dec 30, 2024 at 03:18:35PM +0200, Jani Nikula wrote:
>> On Thu, 26 Dec 2024, Abel Vesa wrote:
>> > On 24-12-11 15:42:27, Johan Hovold wrote:
>> >> On Wed, Dec 11, 2024 at 03:
his
> doesn't happen would just make the implementation more ugly without any
> benefit, IMO.
>
>>
>> > + return 0;
>>
>> I'd check for errors instead of success here and do the rollback before
>> returning -EINVAL.
>>
>
> Yes, I think it would
driver currently uses, but why not
>> EXPORT_SYMBOL_GPL?
>
> $ git grep EXPORT_SYMBOL drivers/gpu/drm/*.c | wc -l
> 962
> $ git grep EXPORT_SYMBOL_GPL drivers/gpu/drm/*.c | wc -l
> 93
It's even more tilted under display/.
BR,
Jani.
--
Jani Nikula, Intel
v
Reviewed-by: Jani Nikula
and
Acked-by: Jani Nikula
for merging via whichever tree you find best.
> ---
> drivers/gpu/drm/i915/display/intel_audio.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_audio.c
> b/drivers/gpu
2001,11 @@ struct drm_connector {
> struct drm_encoder *encoder;
>
> #define MAX_ELD_BYTES128
> - /** @eld: EDID-like data, if present */
> + /** @eld: EDID-like data, if present, protected by @eld_mutex */
> uint8_t eld[MAX_ELD_BYTES];
> + /** @eld_mutex: protection for concurrenct access to @eld */
> + struct mutex eld_mutex;
> +
> /** @latency_present: AV delay info from ELD, if found */
> bool latency_present[2];
> /**
--
Jani Nikula, Intel
ernatives seem more appropriate for the task. Not having to worry
about hostprogs build is a bonus.
BR,
Jani.
--
Jani Nikula, Intel
have. The dependency table got updated afterwards.
Now, what's the status for more modules depending on python? I for one
would like to use it for i915.ko, but I'm a bit uneasy about it as long
as it's "optional". Conversely, how many more users would we need to
switch the status from "optional" to "required"?
BR,
Jani.
--
Jani Nikula, Intel
hkov
Acked-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 2 +-
> include/drm/drm_modeset_helper_vtables.h| 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm
Acked-by: Jani Nikula
--
Jani Nikula, Intel
m_encoder_slave to nouveau
> is really the best course for now.
Granted, the dvo part of i915 is ugly, but it's also only relevant for
the oldest hardware i915 supports. Like 20 years old. Not sure there's
much return on investment in big refactoring, more risk that it breaks
without nobody noticing. Just let it be in i915?
BR,
Jani.
--
Jani Nikula, Intel
_lttpr_max_link_rate(const u8 caps[DP_LTTPR_COMMON_CAP_SIZE]);
>> +int drm_dp_lttpr_set_transparent_mode(struct drm_dp_aux *aux, bool enable);
>> int drm_dp_lttpr_max_lane_count(const u8 caps[DP_LTTPR_COMMON_CAP_SIZE]);
>> bool drm_dp_lttpr_voltage_swing_level_3_supported(const u8
>> caps[DP_LTTPR_PHY_CAP_SIZE]);
>> bool drm_dp_lttpr_pre_emphasis_level_3_supported(const u8
>> caps[DP_LTTPR_PHY_CAP_SIZE]);
>>
>> --
>> 2.34.1
>>
--
Jani Nikula, Intel
uldn't be
>> forgotten as easily.
>
> Ping, anyone have thoughts on this? I'd like to get something
> like this in at some point to make the legacy state (ab)users
> easily visible...
On the approach,
Acked-by: Jani Nikula
with or without converting legacy into a point
struct drm_framebuffer *old_fb;
>> +} legacy;
and
} __legacy;
struct __plane_legacy_or_something *legacy;
and initially unconditionally:
p->legacy = &p->__legacy;
but later, once atomic drivers have been fixed:
if (!drm_core_check_feature(dev, DRIVER_COMPUTE_ATOMIC))
p->legacy = &p->__legacy;
It would make the last update really simple.
BR,
Jani.
>>
>> /** @funcs: plane control functions */
>> const struct drm_plane_funcs *funcs;
>> --
>> 2.45.2
--
Jani Nikula, Intel
dependencies, and make them harder to reduce.
BR,
Jani.
>
> #endif /* __DRM_CRTC_H__ */
--
Jani Nikula, Intel
On Sun, 22 Sep 2024, Dmitry Baryshkov wrote:
> The pll_cmp_to_fdata() was never used by the working code. Drop it to
> prevent warnings with W=1 and clang.
>
> Reported-by: Jani Nikula
> Closes:
> https://lore.kernel.org/dri-devel/3553b1db35665e6ff08592e35eb438a574d1ad65.17259
On Mon, 20 May 2024, Doug Anderson wrote:
> Hi,
>
> On Sun, May 19, 2024 at 2:01 AM Dmitry Baryshkov
> wrote:
>>
>> On Tue, May 14, 2024 at 03:55:14PM +0300, Jani Nikula wrote:
>> > Prefer the struct drm_edid based functions for reading the EDI
On Sun, 19 May 2024, Dmitry Baryshkov wrote:
> On Tue, May 14, 2024 at 03:55:14PM +0300, Jani Nikula wrote:
>> Prefer the struct drm_edid based functions for reading the EDID and
>> updating the connector.
>>
>> Simplify the flow by updating the EDID property when the
Prefer the struct drm_edid based functions for reading the EDID and
updating the connector.
Simplify the flow by updating the EDID property when the EDID is read
instead of at .get_modes.
Signed-off-by: Jani Nikula
---
Cc: Rob Clark
Cc: Abhinav Kumar
Cc: Dmitry Baryshkov
Cc: Sean Paul
Cc
On Fri, 10 May 2024, Mauro Carvalho Chehab wrote:
> Em Fri, 10 May 2024 11:08:38 +0300
> Jani Nikula escreveu:
>
>> On Thu, 09 May 2024, Dmitry Baryshkov wrote:
>> > The drm/msm driver had adopted using Python3 script to generate register
>> > header files
is time?
BR,
Jani.
[1] https://devguide.python.org/versions/
> == ===
>
>
> .. [#f1] Sphinx is needed only to build the Kernel documentation
>
> ---
> base-commit: 704ba27ac55579704ba1289392448b0c66b56258
> change-id: 20240509-python-version-a8b6ca2125ff
>
> Best regards,
--
Jani Nikula, Intel
gument('--xml', type=str, required=True)
> - parser.add_argument('--validate', action=argparse.BooleanOptionalAction)
> + parser.add_argument('--validate', default=False, action='store_true')
> + parser.add_argument('--no-validate', dest='validate',
> action='store_false')
>
> subparsers = parser.add_subparsers()
> subparsers.required = True
--
Jani Nikula, Intel
On Mon, 22 Apr 2024, Jani Nikula wrote:
> Surprisingly many places depend on debugfs.h to be included via
> drm_print.h. Fix them.
>
> v3: Also fix armada, ite-it6505, imagination, msm, sti, vc4, and xe
>
> v2: Also fix ivpu and vmwgfx
>
> Reviewed-by: Andrzej Hajda
&
/20240410141434.157908-1-jani.nik...@intel.com
Signed-off-by: Jani Nikula
---
Cc: Jacek Lawrynowicz
Cc: Stanislaw Gruszka
Cc: Oded Gabbay
Cc: Russell King
Cc: David Airlie
Cc: Daniel Vetter
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Robert Foss
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej
On Mon, 08 Apr 2024, Dmitry Baryshkov wrote:
> On Mon, 8 Apr 2024 at 11:09, Jani Nikula wrote:
>> Thanks! Do you take this via the msm tree?
>
> Yes, I will
Forgot to mention, there's a Tested-by at [1].
Tested-by: Aishwarya TCV
[1] https://lore.kernel.org/r/157e69d4-850f
On Fri, 05 Apr 2024, Dmitry Baryshkov wrote:
> On Fri, Apr 05, 2024 at 12:29:07PM +0300, Jani Nikula wrote:
>> Logging u32 pixel formats using %4.4s format string with a pointer to
>> the u32 is somewhat questionable, as well as dependent on byte
>> order. There's
x the reported build warning:
include/drm/drm_print.h:536:35: warning: '%4.4s' directive argument is
null [-Wformat-overflow=]
Reported-by: Aishwarya TCV
Closes: https://lore.kernel.org/r/2ac758ce-a196-4e89-a397-488ba3101...@arm.com
Signed-off-by: Jani Nikula
---
Tip: 'git s
Abhinav Kumar
Acked-by: Jani Nikula
> ---
> drivers/gpu/drm/display/drm_dp_helper.c | 78 +
> drivers/gpu/drm/i915/display/intel_dp.c | 71 +-
> include/drm/display/drm_dp_helper.h | 3 +
> 3 files changed, 83 insertions(+), 69 deleti
p_helper.h
> @@ -100,6 +100,7 @@ struct drm_dp_vsc_sdp {
>
> void drm_dp_vsc_sdp_log(const char *level, struct device *dev,
> const struct drm_dp_vsc_sdp *vsc);
> +bool drm_dp_vsc_sdp_supported(struct drm_dp_aux *aux, const u8
> dpcd[DP_RECEIVER_CAP_SIZE]);
>
> int drm_dp_psr_setup_time(const u8 psr_cap[EDP_PSR_RECEIVER_CAP_SIZE]);
--
Jani Nikula, Intel
and acks, pushed to drm-misc-next, even if I
didn't get an ack from Jaroslav or Takashi. Seems rather benign anyway.
BR,
Jani.
--
Jani Nikula, Intel
On Thu, 04 Jan 2024, Jani Nikula wrote:
> hdmi-codec.h does not appear to directly need drm/drm_edid.h for
> anything. Remove it.
Jaroslav, Takashi, ack for merging this via the drm trees, please?
BR,
Jani.
>
> There are some files that get drm/drm_edid.h by proxy; include it wh
: Jani Nikula
---
drivers/gpu/drm/bridge/lontium-lt9611.c| 1 +
drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 1 +
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 1 +
drivers/gpu/drm/msm/dp/dp_display.c| 1 +
drivers/gpu/drm/tegra/hdmi.c | 1 +
drivers/gpu/drm/vc4/vc4_hdmi.c
On Mon, 20 Nov 2023, Heiner Kallweit wrote:
> v4:
> - more ack and review tags
Please do not send new versions just to record the acks and
reviews. They should be added while applying the patches.
Thanks,
Jani.
--
Jani Nikula, Intel
On Tue, 12 Sep 2023, Abhinav Kumar wrote:
> Hi Jani
>
> On 9/12/2023 5:16 AM, Jani Nikula wrote:
>> On Thu, 07 Sep 2023, Stephen Boyd wrote:
>>> Quoting Jani Nikula (2023-09-01 07:20:34)
>>>> The DP CTS test for EDID last block checksum expects the checksum
On Thu, 07 Sep 2023, Stephen Boyd wrote:
> Quoting Jani Nikula (2023-09-01 07:20:34)
>> The DP CTS test for EDID last block checksum expects the checksum for
>> the last block, invalid or not. Skip the validity check.
>>
>> For the most part (*), the EDIDs returne
: Abhinav Kumar
Cc: Dmitry Baryshkov
Cc: Kuogee Hsieh
Cc: Marijn Suijten
Cc: Rob Clark
Cc: Sean Paul
Cc: Stephen Boyd
Cc: linux-arm-...@vger.kernel.org
Cc: freedreno@lists.freedesktop.org
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/msm/dp/dp_panel.c | 21 ++---
1
On Wed, 12 Jul 2023, Uwe Kleine-König wrote:
> Hello Jani,
>
> On Wed, Jul 12, 2023 at 05:34:28PM +0300, Jani Nikula wrote:
>> On Wed, 12 Jul 2023, Uwe Kleine-König wrote:
>> > Hello,
>> >
>> > while I debugged an issue in the imx-lcdc driver I
i.e. struct drm_device *. As shown by the numbers above.
If folks insist on following through with this anyway, I'm firmly in the
camp the name should be "drm" and nothing else.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
gt; +{
> + return 2 << (dsc->bits_per_component - 8);
> +}
kernel-doc? Maybe make them regular functions instead of static inline?
BR,
Jani.
> +
> #endif /* _DRM_DSC_HELPER_H_ */
--
Jani Nikula, Intel Open Source Graphics Center
drm_dsc_get_bpp_int(const struct drm_dsc_config *dsc)
> +{
> + WARN_ON_ONCE(dsc->bits_per_pixel & 0xf);
> + return dsc->bits_per_pixel >> 4;
> +}
> +
> static inline u8 drm_dsc_initial_scale_value(const struct drm_dsc_config
> *dsc)
> {
>
display/dsc: include the rest of pre-SCR parameters
> drm/display/dsc: add YCbCr 4:2:2 and 4:2:0 RC parameters
>
> drivers/gpu/drm/display/drm_dsc_helper.c | 986 ++
> drivers/gpu/drm/i915/display/intel_vdsc.c | 443 ++
> include/drm/display/drm_dsc_helper.h | 9 +
> 3 files changed, 1042 insertions(+), 396 deletions(-)
--
Jani Nikula, Intel Open Source Graphics Center
rivers can use
>> it. No functional changes, just cleaned up some of the code when moving it
>> over.
>>
>> Acked-by: Jani Nikula
>> Reviewed-by: Rodrigo Vivi
>> Reviewed-by: Dmitry Baryshkov
>> Signed-off-by: Sean Paul
>> Signed-off-by: Mark Y
On Wed, 08 Mar 2023, Dmitry Baryshkov wrote:
> On Wed, 8 Mar 2023 at 12:14, Jani Nikula wrote:
>>
>> On Tue, 07 Mar 2023, Dmitry Baryshkov wrote:
>> > The array of rc_parameters contains a mixture of parameters from DSC 1.1
>> > and DSC 1.2 standards. Split
drm/display/drm_dsc_helper.h
> b/include/drm/display/drm_dsc_helper.h
> index 1681791f65a5..c634bb2935d3 100644
> --- a/include/drm/display/drm_dsc_helper.h
> +++ b/include/drm/display/drm_dsc_helper.h
> @@ -10,12 +10,17 @@
>
> #include
>
> +enum drm_dsc_params_kind {
> + DRM_DSC_1_2_444,
> + DRM_DSC_1_1_PRE_SCR, /* legacy params from DSC 1.1 */
> +};
> +
> void drm_dsc_dp_pps_header_init(struct dp_sdp_header *pps_header);
> int drm_dsc_dp_rc_buffer_size(u8 rc_buffer_block_size, u8 rc_buffer_size);
> void drm_dsc_pps_payload_pack(struct drm_dsc_picture_parameter_set *pps_sdp,
> const struct drm_dsc_config *dsc_cfg);
> void drm_dsc_set_rc_buf_thresh(struct drm_dsc_config *vdsc_cfg);
> -int drm_dsc_setup_rc_params(struct drm_dsc_config *vdsc_cfg);
> +int drm_dsc_setup_rc_params(struct drm_dsc_config *vdsc_cfg, enum
> drm_dsc_params_kind kind);
> int drm_dsc_compute_rc_parameters(struct drm_dsc_config *vdsc_cfg);
>
> #endif /* _DRM_DSC_HELPER_H_ */
--
Jani Nikula, Intel Open Source Graphics Center
-- a/include/drm/display/drm_dsc_helper.h
> +++ b/include/drm/display/drm_dsc_helper.h
> @@ -10,12 +10,17 @@
>
> #include
>
> +enum drm_dsc_params_kind {
> + DRM_DSC_1_2_444,
> + DRM_DSC_1_1_PRE_SCR, /* legacy params from DSC 1.1 */
> +};
> +
> void drm_dsc_dp_pps_header_init(struct dp_sdp_header *pps_header);
> int drm_dsc_dp_rc_buffer_size(u8 rc_buffer_block_size, u8 rc_buffer_size);
> void drm_dsc_pps_payload_pack(struct drm_dsc_picture_parameter_set *pps_sdp,
> const struct drm_dsc_config *dsc_cfg);
> void drm_dsc_set_rc_buf_thresh(struct drm_dsc_config *vdsc_cfg);
> -int drm_dsc_setup_rc_params(struct drm_dsc_config *vdsc_cfg);
> +int drm_dsc_setup_rc_params(struct drm_dsc_config *vdsc_cfg, enum
> drm_dsc_params_kind kind);
> int drm_dsc_compute_rc_parameters(struct drm_dsc_config *vdsc_cfg);
>
> #endif /* _DRM_DSC_HELPER_H_ */
--
Jani Nikula, Intel Open Source Graphics Center
{ 0, 4, 10 }, { 2, 7, 8 }, { 4, 9, 6 }, { 6, 11, 4 },
> + { 9, 11, 2 }, { 9, 11, 0 }, { 9, 12, -2 }, { 10, 12, -4 },
> + { 11, 12, -6 }, { 11, 13, -8 }, { 12, 14, -10 },
> + { 13, 15, -10 }, { 13, 16, -12 }, { 15, 21, -12 },
> + { 21, 23, -12 }
> + }
> + }
> +},
> { /* sentinel */ }
> };
--
Jani Nikula, Intel Open Source Graphics Center
gt; +{ DSC_BPP(6), 8,
I was kind of hoping for a patch that would clean up the hideous
indentation in the tables. Please at least let's not add more with the
one space indent?
> /* 6BPP/8BPC */
With designated initializers I think we could just toss the comments
out.
_limit1 = rc_params->rc_quant_incr_limit1;
> -
> - for (i = 0; i < DSC_NUM_BUF_RANGES; i++) {
> - vdsc_cfg->rc_range_params[i].range_min_qp =
> - rc_params->rc_range_params[i].range_min_qp;
> - vdsc_cfg->rc_ra
return COLUMN_INDEX_12BPC;
> + case 14:
> + return COLUMN_INDEX_14BPC;
> + case 16:
> + return COLUMN_INDEX_16BPC;
> + default:
> + return -EINVAL;
> + }
> +}
> +
> +static const struct rc_parameters *get_rc_param
; + * Only 8 bits are allowed for programming RcBufThreshold
> + */
Not sure how appropriate the hardware references are, maybe clean it up
a bit.
With that, and +static and -export mentioned earlier,
Reviewed-by: Jani Nikula
> + vdsc_cfg->rc_buf_
mpressed_bpp == 8 &&
> + vdsc_cfg->bits_per_component == 14)
> + vdsc_cfg->rc_range_params[0].range_bpg_offset = 0;
> + }
> +
I wonder if we shouldn't just use the updated values...
Maybe add a FIXME comment above the block to co
On Tue, 28 Feb 2023, Dmitry Baryshkov wrote:
> On Tue, 28 Feb 2023 at 14:25, Jani Nikula wrote:
>>
>> On Tue, 28 Feb 2023, Dmitry Baryshkov wrote:
>> > The rc_buf_thresh values are common to all DSC implementations. Move
>> > them to the common helper together w
rm_dsc_helper.h
> @@ -14,6 +14,7 @@ void drm_dsc_dp_pps_header_init(struct dp_sdp_header
> *pps_header);
> int drm_dsc_dp_rc_buffer_size(u8 rc_buffer_block_size, u8 rc_buffer_size);
> void drm_dsc_pps_payload_pack(struct drm_dsc_picture_parameter_set *pps_sdp,
> const struct drm_dsc_config *dsc_cfg);
> +void drm_dsc_set_rc_buf_thresh(struct drm_dsc_config *vdsc_cfg);
> int drm_dsc_compute_rc_parameters(struct drm_dsc_config *vdsc_cfg);
>
> #endif /* _DRM_DSC_HELPER_H_ */
--
Jani Nikula, Intel Open Source Graphics Center
o, this is just 1.1, we will add more tables for 1.2. So we will
>>>>> have to end up changing both 1.1 and 1.2 tables as they are
>>>>> different for QC.
>>>>
>>>> I haven't heard back from Kuogee about the possible causes of using
>>>> rc/qp values from 1.2 even for 1.1 panels. Maybe you can comment on
>>>> that? In other words, can we always stick to the values from 1.2
>>>> standard? What will be the drawback?
>>>>
>>>> Otherwise, we'd have to have two different sets of values, like you
>>>> do in your vendor driver.
>>>>
>>>
>>> I have responded to this in the other email.
>>>
>>> All this being said, even if the rc tables move the drm_dsc_helper
>>> either now or later on, we will still need MSM specific calculations
>>> for many of the other encoder parameters (which are again either
>>> hard-coded or calculated). Please refer to the
>>> sde_dsc_populate_dsc_config() downstream. And yes, you will not find
>>> those in the DP spec directly.
>>>
>>> So we will still need a dsc helper for MSM calculations to be common
>>> for DSI / DP irrespective of where the tables go.
>>>
>>> So, lets finalize that first.
>>
>> I went on and trimmed sde_dsc_populate_dsc_config() to remove
>> duplication with the drm_dsc_compute_rc_parameters() (which we already
>> use for the MSM DSI DSC).
>>
>> Not much is left:
>>
>> dsc->first_line_bpg_offset set via the switch
>>
>> dsc->line_buf_depth = bpc + 1;
>> dsc->mux_word_size = bpc > 10 ? DSC_MUX_WORD_SIZE_12_BPC:
>> DSC_MUX_WORD_SIZE_8_10_BPC;
>>
>> if ((dsc->dsc_version_minor == 0x2) && (dsc->native_420))
>> dsc->nsl_bpg_offset = (2048 *
>> (DIV_ROUND_UP(dsc->second_line_bpg_offset,
>> (dsc->slice_height - 1;
>>
>> dsc->initial_scale_value = 8 * dsc->rc_model_size /
>> (dsc->rc_model_size - dsc->initial_offset);
>>
>>
>> mux_word_size comes from the standard (must)
>> initial_scale_value calculation is recommended, but not required
>> nsl_bpg_offset follows the standard (must), also see below (*).
>>
>> first_line_bpg_offset calculation differs between three drivers. The
>> standard also provides a recommended formulas. I think we can leave it
>> as is for now.
>>
>> I think, that mux_word_size and nsl_bpg_offset calculation should be
>> moved to drm_dsc_compute_rc_parameters(), while leaving
>> initial_scale_value in place (in the driver code).
>>
>> * I think nsl_bpg_offset is slightly incorrectly calculated. Standard
>> demands that it is set to 'second_line_bpg_offset / (slice_height - 1),
>> rounded up to 16 fraction bits', while SDE driver code sets it to the
>> value rounded up to the next integer (having 16 fraction bits
>> representation).
>>
>> In my opinion correct calculation should be:
>> dsc->nsl_bpg_offset = DIV_ROUND_UP(2048 * dsc->second_line_bpg_offset,
>> (dsc->slice_height - 1));
>>
>> Could you please check, which one is correct according to the standard?
>>
>>
>
> Sure, i will check about nsl_bpg_offset. But sorry if I was not more
> clear about this but sde_dsc_populate_dsc_config() is only one example
> which from your analysis can be moved to the drm_dsc_helper() but not
> the initial line calculation _dce_dsc_initial_line_calc(),
> _dce_dsc_ich_reset_override_needed() , _dce_dsc_setup_helper().
>
> All of these are again common between DSI and DP.
>
> So in addition to thinking about what can be moved to the drm_dsc_helper
> also think about what is specific to MSM but common to DSI and DP modules.
>
> That was the bigger picture I was trying to convey.
--
Jani Nikula, Intel Open Source Graphics Center
iew https://github.com/intel-lab-lkp/linux
> git fetch --no-tags linux-review
> Jani-Nikula/drm-connector-move-HDR-sink-metadata-to-display-info/20230124-174322
> git checkout 1e92b5478cfc1b0df6615365217e9548b0d5
> # save the config file
> mkdir build
On Tue, 24 Jan 2023, Dmitry Baryshkov wrote:
> Extract drm_kms_helper_enable_hpd() and drm_kms_helper_disable_hpd(),
> two helpers that enable and disable HPD handling on all device's
> connectors.
Thanks for separating this, it makes the other patch easier to read.
Reviewed-b
: Alain Volmat
Cc: Emma Anholt
Cc: Maxime Ripard
Signed-off-by: Jani Nikula
---
Sorry about the crazy Cc list, but this touches a lot of drivers, and I
didn't want to blind side anyone.
---
drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 6 +--
drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
funcs->disable_hpd(connector);
> - }
> - drm_connector_list_iter_end(&conn_iter);
> -
> - cancel_delayed_work_sync(&dev->mode_config.output_poll_work);
> -}
> -
> /**
> * drm_kms_helper_poll_disable - disable output polling
> * @dev: drm_d
+838,6 @@ bool drm_kms_helper_is_poll_worker(void)
>> > }
>> > EXPORT_SYMBOL(drm_kms_helper_is_poll_worker);
>> >
>> > -static void drm_kms_helper_poll_disable_fini(struct drm_device *dev, bool
>> > fini)
>> > -{
>> > - struct drm_connector *connector;
>> > - struct drm_connector_list_iter conn_iter;
>> > -
>> > - if (!dev->mode_config.poll_enabled)
>> > - return;
>> > -
>> > - if (fini)
>> > - dev->mode_config.poll_enabled = false;
>> > -
>> > - drm_connector_list_iter_begin(dev, &conn_iter);
>> > - drm_for_each_connector_iter(connector, &conn_iter) {
>> > - const struct drm_connector_helper_funcs *funcs =
>> > - connector->helper_private;
>> > -
>> > - if (funcs && funcs->disable_hpd)
>> > - funcs->disable_hpd(connector);
>> > - }
>> > - drm_connector_list_iter_end(&conn_iter);
>> > -
>> > - cancel_delayed_work_sync(&dev->mode_config.output_poll_work);
>> > -}
>> > -
>> > /**
>> > * drm_kms_helper_poll_disable - disable output polling
>> > * @dev: drm_device
>> > @@ -848,7 +854,12 @@ static void drm_kms_helper_poll_disable_fini(struct
>> > drm_device *dev, bool fini)
>> > */
>> > void drm_kms_helper_poll_disable(struct drm_device *dev)
>> > {
>> > - drm_kms_helper_poll_disable_fini(dev, false);
>> > + if (dev->mode_config.poll_running)
>> > + drm_kms_helper_disable_hpd(dev);
>> > +
>> > + cancel_delayed_work_sync(&dev->mode_config.output_poll_work);
>> > +
>> > + dev->mode_config.poll_running = false;
>> > }
>> > EXPORT_SYMBOL(drm_kms_helper_poll_disable);
>> >
>> > @@ -886,7 +897,12 @@ EXPORT_SYMBOL(drm_kms_helper_poll_init);
>> > */
>> > void drm_kms_helper_poll_fini(struct drm_device *dev)
>> > {
>> > - drm_kms_helper_poll_disable_fini(dev, true);
>> > + if (!dev->mode_config.poll_enabled)
>> > + return;
>> > +
>> > + drm_kms_helper_poll_disable(dev);
>> > +
>> > + dev->mode_config.poll_enabled = false;
>> > }
>> > EXPORT_SYMBOL(drm_kms_helper_poll_fini);
>> >
>> > --
>> > 2.39.0
>> >
--
Jani Nikula, Intel Open Source Graphics Center
I certainly
> don't have that clout.
>
> The spec, as far as I can tell, says that it's up to the panel vendor
> to use whatever means they want to decide on the "preferred" refresh
> rate. Thus, as far as the spec is concerned this decision is made on
> an individual panel basis. ;-) This was really the justification for
> why my patch was just on one panel.
>
> In any case, as I said I'm OK w/ dropping this. We'll find other ways
> to work around the issue.
FWIW, if the EDID reported preferred mode works, I also think that's
what we should prefer.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
t; + if (connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort)
If we're doing this primarily to appease the CTS, this is fine.
If we think this is a functional improvement for regular use, I suppose
we should consider doing this also for DRM_MODE_CONNECTOR_eDP. Which is
On Tue, 10 May 2022, Tomeu Vizoso wrote:
> And use it to store expectations about what the drm/msm driver is
> supposed to pass in the IGT test suite.
>
> Also include a configuration file that points to the out-of-tree CI
> scripts.
>
> By storing the test expectations along the code we can make
> drivers/gpu/drm/msm/dp/dp_link.c| 99 +-
> drivers/gpu/drm/msm/dp/dp_panel.c | 43 +++--
> drivers/gpu/drm/msm/dp/dp_parser.c | 2 +-
> drivers/gpu/drm/msm/dp/dp_power.c | 20 ---
> 9 files changed, 283 insertions(+), 187 deletions(-)
--
Jani Nikula, Intel Open Source Graphics Center
e/drm/drm_writeback.h
> +++ b/include/drm/drm_writeback.h
> @@ -31,7 +31,7 @@ struct drm_writeback_connector {
> * by passing the @enc_funcs parameter to drm_writeback_connector_init()
>* function.
>*/
> - struct drm_encoder encoder;
> + struct drm_encoder *encoder;
>
> /**
>* @pixel_formats_blob_ptr:
--
Jani Nikula, Intel Open Source Graphics Center
On Fri, 07 Jan 2022, Stephen Boyd wrote:
> Quoting Jani Nikula (2022-01-07 05:07:59)
>> On Thu, 06 Jan 2022, Stephen Boyd wrote:
>> > This allows aggregate driver writers to use the device passed to their
>> > probe/remove/shutdown functions properly instead of tr
nent_match *match;
> + struct aggregate_driver *adrv;
> +
> + int id;
> +};
> +
> +static inline struct aggregate_device *to_aggregate_device(struct device *d)
> +{
> + return container_of(d, struct aggregate_device, dev);
> +}
>
> /**
> * struct aggregate_driver - Aggregate driver (made up of other drivers)
--
Jani Nikula, Intel Open Source Graphics Center
x27;d have to know and list all the drm subdirectories when looking up
stuff that's part of drm but not drivers.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
On Mon, 13 Dec 2021, Thomas Zimmermann wrote:
> Hi
>
> Am 13.12.21 um 14:34 schrieb Jani Nikula:
>> On Mon, 13 Dec 2021, Thomas Zimmermann wrote:
>>> Split-off DisplayPort functions from KMS helper library and move them
>>> into their own module. Reduces the
3f422828221d9ceefcddef0be33561b1646a1cbe
> prerequisite-patch-id: c2b2f08f0eccc9f5df0c0da49fa1d36267deb11d
> prerequisite-patch-id: c67e5d886a47b7d0266d81100837557fda34cb24
> --
> 2.34.1
>
--
Jani Nikula, Intel Open Source Graphics Center
/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -45,7 +45,7 @@
> #include
> #include
>
> -#include "drm_crtc_helper_internal.h"
> +#include "drm_dp_helper_internal.h"
> #include "drm_dp_mst_topology_internal.h"
>
> /**
> diff --git a/drivers/gpu/drm/drm_kms_helper_common.c
> b/drivers/gpu/drm/drm_kms_helper_common.c
> index 47e92400548d..88260d26409c 100644
> --- a/drivers/gpu/drm/drm_kms_helper_common.c
> +++ b/drivers/gpu/drm/drm_kms_helper_common.c
> @@ -29,6 +29,7 @@
>
> #include
>
> +#include "drm_dp_helper_internal.h"
> #include "drm_crtc_helper_internal.h"
>
> MODULE_AUTHOR("David Airlie, Jesse Barnes");
--
Jani Nikula, Intel Open Source Graphics Center
let's see if this makes it thru email servers...
> ---
> block/fops.c | 1 +
> drivers/gpu/drm/drm_gem_shmem_helper.c| 1 +
> drivers/gpu/drm/i915/gt/intel_gtt.c | 1 +
> drivers/gpu/drm/i915/i915_request.c | 1 +
For the i915 parts,
Acked-by: Jani Nikula
--
Jani Nikula, Intel Open Source Graphics Center
On Fri, 15 Oct 2021, Ville Syrjälä wrote:
> On Fri, Oct 15, 2021 at 03:44:48PM +0300, Jani Nikula wrote:
>> On Fri, 15 Oct 2021, Claudio Suarez wrote:
>> > Once EDID is parsed, the monitor HDMI support information is available
>> > through drm_display_info.is_hdmi. Ret
or =
> drm_detect_hdmi_monitor(edid);
> intel_sdvo->has_hdmi_audio =
> drm_detect_monitor_audio(edid);
> + intel_sdvo->has_hdmi_monitor =
> +
> intel_connector_is_hdmi_monitor(connector);
> }
> } else
> status = connector_status_disconnected;
--
Jani Nikula, Intel Open Source Graphics Center
ges coming in via drm-misc they usually will cause conflicts for
> people during drm-tip rebuild. Also I would expect to see an ack
> requested from i915 maintainers for merging anything significant via
> drm-misc, which I don't think happened in this case.
Indeed. All other things aside, it looks like it has enough conflict
potential to warrant merging via drm-intel anyway.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
y 0-day and
> yamllint and incorporated early review feedback from the dt/dts reviews.
>
> Please take a look,
I'll try to ping folks to get someone to review the i915 parts, but the
general idea of moving common HDCP code from i915 to drm is, I hope
obviously,
Acked-by: Jani Nikula
&
+-
> drivers/gpu/drm/msm/dp/dp_display.c | 14 ++--
> drivers/gpu/drm/msm/dp/dp_panel.c | 9 ++-
> 4 files changed, 102 insertions(+), 61 deletions(-)
--
Jani Nikula, Intel Open Source Graphics Center
cing +
> selftests")
>
> Signed-off-by: Rajkumar Subbiah
> Signed-off-by: Kuogee Hsieh
>
> Reviewed-by: Stephen Boyd
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
gt; + drm_dp_mst_dump_sideband_msg_tx(&p, txmsg);
> + }
> return ret;
> }
Seems like a sensible thing to do.
(I'd probably rip out the "unlikely" while at it, as it feels like
unnecessary optimization, but *shrug*.)
Re
gt; + "failed to register backlight (%d)\n", ret);
> + goto free_ddc;
> + }
> +
> + platform_set_drvdata(pdev, bd);
> +
> + return 0;
> +
> +free_ddc:
> + if (ddc)
> + put_device(&ddc->dev);
> +
>
/drm/bridge/ti-sn65dsi86.c | 26 +++
> drivers/gpu/drm/drm_dp_aux_backlight.c | 191
> +
> include/drm/drm_dp_aux_backlight.h | 29
> 7 files changed, 264 insertions(+)
> create mode 100644 drivers/gpu/drm/drm_dp_
c;
> struct device *dev;
> + struct drm_device *drm_dev;
Bikeshed, I would probably have called it just drm for brevity, but no
strong feelings.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
___
Freedreno mailing lis
drm/i915/selftests/mock_gem_device.c
> index ce4d4303229c..4725dad63e0a 100644
> --- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
> +++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
> @@ -86,9 +86,6 @@ static struct drm_driver mock_driver = {
> .name = "mock",
>
6: Change commit message
>
> Signed-off-by: Chandan Uddaraju
> Signed-off-by: Vara Reddy
> Signed-off-by: Tanmay Shah
Acked-by: Jani Nikula
for merging via drm-misc if that helps you.
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 2 +-
> include/drm/drm_dp_helper.h
e/drm/drm_displayid.h | 2 +-
> include/uapi/drm/i915_drm.h | 4 ++--
Not sure it's worth touching uapi headers. They're full of both [0] and
[]. Again, please at least split it to a separate patch to be decided
separately.
BR,
Jani.
--
Jani Nikul
_vblank_timestamp()
> * simplify function names
>
> Signed-off-by: Thomas Zimmermann
Acked-by: Jani Nikula
for the approach and for merging through whichever tree makes most
sense, *however* needs detailed review on the whole.
> ---
> drivers/gpu/drm/i915/display/intel_display
On Fri, 10 Jan 2020, Thomas Zimmermann wrote:
> Hi
>
> Am 10.01.20 um 12:59 schrieb Jani Nikula:
>> On Fri, 10 Jan 2020, Thomas Zimmermann wrote:
>>> The callback struct drm_driver.get_scanout_position() is deprecated in
>>> favor of struct drm_crtc_
able(struct drm_i915_private *dev_priv,
>u8 pipe_mask);
>
> -bool i915_get_crtc_scanoutpos(struct drm_device *dev, unsigned int pipe,
> - bool in_vblank_irq, int *vpos, int *hpos,
> - ktime_t *stime,
ns vpos as a positive number while in active scanout area.
> + * Returns vpos as a negative number inside vblank, counting the number
> + * of scanlines to go until end of vblank, e.g., -1 means "one scanline
> + * until
On Mon, 02 Dec 2019, Chandan Uddaraju wrote:
> The constant N value (0x8000) is used by multiple DP
> drivers. Define this value in header file and use this
> in the existing i915 display driver.
>
> Signed-off-by: Chandan Uddaraju
Reviewed-by: Jani Nikula
and ack for merging
On Tue, 24 Sep 2019, Jani Nikula wrote:
> drm/print: move drm_debug variable to drm_print.[ch]
> drm/print: add drm_debug_enabled()
> drm/etnaviv: use drm_debug_enabled() to check for debug categories
> drm/i2c/sil164: use drm_debug_enabled() to check for debug categories
>
On Tue, 01 Oct 2019, Eric Engestrom wrote:
> On Tuesday, 2019-10-01 14:03:55 +0300, Jani Nikula wrote:
>> On Thu, 26 Sep 2019, Eric Engestrom wrote:
>> > On Tuesday, 2019-09-24 15:58:56 +0300, Jani Nikula wrote:
>> >> Hi all, v2 of [1], a little refactor
On Thu, 26 Sep 2019, Eric Engestrom wrote:
> On Tuesday, 2019-09-24 15:58:56 +0300, Jani Nikula wrote:
>> Hi all, v2 of [1], a little refactoring around drm_debug access to
>> abstract it better. There shouldn't be any functional changes.
>>
>> I'd apprec
Allow better abstraction of the drm_debug global variable in the
future. No functional changes.
v2: Move unlikely() to drm_debug_enabled()
Cc: Rob Clark
Cc: Sean Paul
Cc: linux-arm-...@vger.kernel.org
Cc: freedreno@lists.freedesktop.org
Reviewed-by: Rob Clark
Signed-off-by: Jani Nikula
g
Cc: freedreno@lists.freedesktop.org
Cc: Francisco Jerez
Cc: Lucas Stach
Cc: Russell King
Cc: Christian Gmeiner
Cc: etna...@lists.freedesktop.org
[1] cover.1568375189.git.jani.nikula@intel.com">http://mid.mail-archive.com/cover.1568375189.git.jani.nikula@intel.com
Jani Nikula (9):
drm/print: mov
Allow better abstraction of the drm_debug global variable in the
future. No functional changes.
Cc: Rob Clark
Cc: Sean Paul
Cc: linux-arm-...@vger.kernel.org
Cc: freedreno@lists.freedesktop.org
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 4 ++--
1 file changed, 2
1 - 100 of 116 matches
Mail list logo
